Шоста нормальна форма.Таблиця знаходиться у 6NF, якщо вона знаходиться у 5NF та задовольняє вимозі відсутності нетривіальних залежностей. Зазвичай 6NF ототожнюють з DKNF.
Цілі нормалізації наступні: Виключити дублювання інформації в таблицях. Забезпечити можливість змін у структурі таблиць. Зменшити вплив структурних змін бази даних на роботу додатків, які забезпечують користувачам доступ до даних.
10. Аномалії вставки. Аномалії вилучення.
Аномалії видалення - видалення зайвої інформації при видаленні запису.
Для відносини "Студент" (ПІБ, Група, Староста), видалення студента може призвести до видалення з БД і ПІБ старости групи (в тому випадку, якщо для даної групи запис - єдина).
Аномалії вставки - додавання зайвої інформації або виникнення суперечать значень в деяких стовпцях при вставці нового запису
Для відносини "Студент" (ПІБ, Група, Староста), де у стовпці "Група" зберігається повна назва групи, а стовпець "Староста" містить ПІБ старости групи, додавання назви нової групи спричинить обов'язкове визначення ПІБ студента і старости, в той час як ці дані можуть бути поки не відомі. У той же час, при додаванні нового студента значення поля "Староста" в новому записі може не співпадати із значенням даного поля для іншого студента цієї ж групи.
11. Функціональні залежності. Процес нормалізації. Перша нормальна форма (1НФ)
Функціональна залежність - це зв'язок між атрибутами. Припустімо, якщо нам відоме значення одного атрибута, тоді можемо знайти значення іншого атрибута. Наприклад, якщо нам відомий номер рахунку клієнта, тоді ми можемо визначити стан цього рахунку. У такому разі ми можемо сказати, що атрибут СтанРахункуКлієнта функціонально залежить від атрибута Номер Рахунку Клієнта. Іншими словами, якщо нам відоме значення X, ми можемо визначити значення Y. Функціональні залежності позначаються так: НомерСтудента -> Спеціальність.
Вираз читається так: атрибут НомерСтудента функціонально визначає атрибут Спеціальність, або атрибут Спеціальність залежить від атрибута НомерСтудента. Атрибути з правого боку від стрілки називаються детермінантами.
У функціональні залежності можуть бути включені групи атрибутів. Розглянемо відношення Оцінки (НомерСтудента, Дисципліна, Оцінка). Функціональна залежність (НомерСтудента, Дисципліна) -> Оцінка визначає оцінку студента з дисципліни.
Ключ (key) - це група з одного або більше атрибутів, яка унікальним чином ідентифікує рядок. Розглянемо відношення Секція, яке має атрибути НомерСтудента, Секція, Плата (табл. 2.6).
Відношення Секція
| НомерСтудента | Секція | Плата |
| 10701 | Боротьба | 70 |
| 15002 | Плавання | 45 |
| 20003 | Гімнастика | 80 |
Перша нормальна форма (1НФ, 1NF) утворює ґрунт для структурованої схеми бази даних:
Кожна таблиця повинна мати основний ключ: мінімальний набір колонок, які ідентифікують запис.
Уникнення повторень груп (категорії даних, що можуть зустрічатись різну кількість разів в різних записах) правильно визначаючи неключові атрибути.
Атомарність: кожен атрибут повинен мати лише одне значення, а не множину значень
На цьому етапі створюється двовимірна таблиця, що містить всі потрібні атрибути ІМ, і виділяються ключові атрибути. Саме вони однозначно визначають кожен рядок в таблиці, тобто запис. Усі інші атрибути функціонально залежатимуть від ключових. Розрізняють повну функціональну залежність і часткову, коли деякі неключові атрибути залежать лише від частини ключа. В цьому випадку можуть спостерігатися аномалії розміщення даних:
аномалії включення, які викликані тим, що ключові елементи не можуть приймати нульових значень;
аномалії поновлення. При поновленні даних потрібно заповнити дані у всіх атрибутах, хоча деякі з их в цей момент і не змінюють свого значення
аномалії знищення. При знищенні запису із таблиці втрачаються усі пов”язані із ним дані
Процес нормалізації полягає в зведенні таблиць до так званих нормальних форм. Існує кілька видів нормальних форм : перша нормальна форма (1НФ), друга нормальна форма (2НФ), третя нормальна форма (3НФ), нормальна форма Бойса-Кодда (НФБК), четверта нормальна форма (4НФ), п”ята нормальна форма (5НФ). З практичної точки зору досить трьох перших форм - варто враховувати час, що затрачається системою для “з”єднання” таблиць при відображенні їх на екрані. Тому ми обмежимося вивченням процесу зведення відношень до перших трьох форм
Цей процес включає:
усунення груп, що повторюються (зведення до 1НФ)
знищення частково залежних атрбутів (зведення до 2НФ)
знищення транзитивно залежних атрибутів (зведення до 3НФ).
12. Друга нормальна форма (2НФ).
Друга нормальна форма (2НФ, 2NF) — нормальна форма використовна нормалізації баз даних. 2НФ первісно була визначена Едгаром Коддом в 1971.[1] Щоб бути в другій нормальній формі, таблиця, що знаходиться в першій нормальній формі, має відповідати додатковим критеріям. А саме: 1НФ таблиця знаходиться в 2НФ тоді і тільки тоді, коли для будь-якого потенційного ключа K і будь-якого атрибута A, який не є частиною потенційного ключа, A залежить саме від цілого потенційного ключа, а не від його частини.
Трошки більш формально: 1NF таблиця знаходиться в 2НФ тоді і тільки тоді, коли всі її неключові атрибути функціонально залежні від цілих потенційних ключів.
Зауважимо, що коли 1НФ таблиця не має складних потенційних ключів (таких, що складаються більш ніж з одного атрибута), тоді таблиця автоматично знаходиться в 2НФ.
Друга нормальна форма (2НФ, 2NF) вимагає, аби дані, що зберігаються в таблицях із композитним ключем не залежали лише від частини ключа:
Схема бази даних повинна відповідати вимогам першої нормальної форми.
Дані, що повторно з'являються в декількох рядках виносяться в окремі таблиці.
Наступний важливий крок в процесі нормалізації полягає у знищенні всіх неключових атрибуті, які залежать лише від частини первинного ключа. Такі атрибути називаються частково залежними. Неключові атрибути містять в собі інформацію про дану сутність предметної області, але не ідентифікують її унікальним чином.
На цьому етапі досягається повна функціональна залежність усіх атрибутів від ключа за рахунок розбиття даних на кілька таблиць. До основних аномалій відноситься аномалія дублювання даних. Можливе дублювання даних виявляється шляхом встановлення тих атрибутів, які однозначно залежать від інших атрибутів , що не є ключовими (транзитивний зв”язок). Для усунення вказаного недоліку модель приводиться до третьої нормальної форми.
13.Третя нормальна форма (3НФ) — нормальна форма використовна в нормалізації баз даних. 3НФ первісно була визначена Едгаром Коддом в 1971.[1]Визначення: Кодд каже, що таблиця знаходиться в 3НФ тоді і тільки тоді, коли виконуються наступні умови:
Відношення R (таблиця) знаходиться в 2НФ
Кожен неключовий атрибут відношення R нетранзитивно залежить (тобто залежить безпосередньо) від кожного потенційного ключа в R.
Неключовий атрибут R — атрибут, що не є частиною будь-якого потенційного ключа.[2] Транзитивною називають таку функціональну залежність, в якій X→ Z (X визначає Z) непрямо, а через X → Y і Y → Z (і невірно, що Y → X).[3]
Інше визначення 3НФ тотожне до визначення Кодда, дав Карло Заніоло в 1982. Це визначення стверджує, що таблиця в 3НФ тоді і тільки тоді, коли для кожної її функціональної залежності X → A, вірна хочаб одна з наступних умов:
X містить A (тоді X → A це тривіальна функціональна залежність), або
X це суперключ, або
A-X, різниця множин A і X це ключовий атрибут (тобто, A-X міститься в потенційному ключі)
Третя нормальна форма (3НФ, 3NF) вимагає, аби дані в таблиці залежали винятково від основного ключа:
Схема бази даних повинна відповідати всім вимогам другої нормальної форми.
Будь-яке поле, що залежить від основного ключа та від будь-якого іншого поля, має виноситись в окрему таблицю.
Щоб привести базу до третьої нормальної форми, треба:
1. Визначити, в яких полях яких таблиць мається взаємозалежність. Як щойно йшлося, поля, які залежать більше один від одного (як місто від штату), ніж від ряду в цілому. У базі форуму такої проблеми немає. Поглянувши на таблицю повідомлень, побачите, що кожен заголовок, кожне тіло повідомлення ставиться до свого message ID.
2. Створіть відповідні таблиці. Якщо є проблемний стовпець в кроці 1, створюйте роздільні таблиці для нього. Як міста та штати, в прикладі з клієнтами.
3. Створіть або виділіть первинні ключі. Кожна таблиця повинна мати первинний ключ. Для прикладу з клієнтами це будуть city ID і state ID.
4. Створіть необхідні зовнішні ключі, які утворюють будь-яке з відносин. У нашому прикладі потрібно додати state ID в таблицю міст і city ID в таблицю клієнтів. Це зв'яже кожного клієнта з містом та штатом, де вони живуть.
14. Нормальна форма Бойса — Кодда
Відношення знаходиться в НФБК, тоді і лише тоді коли детермінант кожної функціональної залежності є потенційним ключем. Якщо це правило не виконується, тоді щоб привести вказане відношення до НФБК його слід розділити на два відношення шляхом двох операцій проекції на кожну функціональну залежність детермінант, якої не є потенційним ключем.
Проекція без атрибутів залежної частини такої функціональної залежності;
Проекція на всі атрибути цієї функціональної залежності.
Визначення НФБК не потребує жодних умов попередніх нормальних форм. Якщо проводити нормалізацію послідовно, то в переважній більшості випадків при досягненні 3НФ автоматично будуть задовольнятися вимоги НФБК. 3НФ не збігається з НФБК лише тоді, коли одночасно виконуються такі 3 умови:
Відношення має 2 або більше потенційних ключів.
Ці потенційні ключі складені (містять більш ніж один атрибут)
Ці потенційні ключі перекриваються, тобто мають щонайменше один спільний атрибут.
15. Четверта нормальна форма (4NF) - одна з можливих нормальних форм відношення реляційної бази даних.Відношення знаходиться в 4NF якщо воно знаходиться в BCNF і в ньому відсутні багатозначні залежності, які не є функціональними залежностями.
Четверта нормальна форма стосується відношень, в яких є повторювані набори даних. Декомпозиція, заснована на функціональних залежностях, не призводить до виключення такої надмірності. У цьому випадку використовують декомпозицію, засновану на багатозначних залежностях.
Багатозначна залежність є узагальненням функціональної залежності і розглядає відповідності між множинами значеньатрибутів.
Приведення відношення до 4NF дозволяє виключити тип аномалій оновлення. Для приведення відношення з BCNF до 4NF слід виконати проекції вихідного відношення на пари атрибутів, створюючих багатозначні залежності. Четверта нормальна форма (4NF) є окремим випадком 5НФ, коли повна декомпозиція повинна бути з'єднанням рівно двох проекцій. Досить не просто підібрати реальну таблицю, яка перебувала б у 4NF, але не була б у 5НФ.
Дана Нормальна форма має більший інтерес для теоретичних досліджень, ніж для практики проектування баз даних.
16. Доменно-ключова нормальна форма - це нормальна форма що використовується в нормалізації баз даних і вимагає щоб база даних не містила жодних інших обмежень крім обмежень доменів і обмежень ключів.
Обмеження домену - обмеження, яке наказує використовувати для певного атрибуту значення тільки з деякого заданого домену. Обмеження по своїй суті є заданням переліку (або логічного еквіваленту переліку) допустимих значень типу і оголошенням про те, що вказаний атрибут має даний тип.
Обмеження ключа – обмеження, яке стверджує, що деякий атрибут чи комбінація атрибутів є потенційним ключем.
Будь-яка змінна відношення, що знаходиться в ДКНФ, обов'язково знаходиться в 5НФ. Але не будь-яку змінну відношення можна привести до ДКНФ.
17. Реляційна модель даних — логічна модель даних.
У реляційній моделі досягається більш високий рівень абстракції даних, ніж в ієрархічній або мережевій. У згаданій статті Е. Ф. Кодда стверджується, що «реляційна модель надає засоби опису даних на основі тільки їх природної структури, тобто без потреби введення якоїсь додаткової структури для цілей машинного представлення». Іншими словами, подання даних не залежить від способу їх фізичної організації. Це забезпечується за рахунок використання математичного поняття відношення (сама назва «реляційна» походить від англійського relation — «відношення»).
До складу реляційної моделі даних зазвичай включають теорію нормалізації. Крістофер Дейт визначив три складові частини реляційної моделі даних:
структурна
маніпуляційна
цілісна
Структурна частина моделі визначає, що єдиною структурою даних є нормалізоване n-арне відношення. Відношення зручно представляти у формі таблиць, де кожен рядок є кортеж, а кожен стовпець — атрибут, визначений на деякому домені. Даний неформальний підхід до поняття відношення дає більш звичну для розробників і користувачів форму представлення, де реляційна база даних являє собою кінцевий набір таблиць.
Маніпуляційна частина моделі визначає два фундаментальних механізми маніпулювання даними — реляційну алгебру і реляційне числення. Основною функцією маніпуляційної частини реляційної моделі є забезпечення заходів реляційності будь-якої конкретної мови реляційних БД: мова називається реляційною, якщо вона має не меншу виразність і потужність, ніж реляційна алгебра або реляційне числення.
Цілісна частина моделі визначає вимоги цілісності сутностей і цілісності посилань. Перша вимога полягає в тому, що будь-який кортеж будь-якого відношення відмінний від будь-якого іншого кортежу цього відношення, тобто іншими словами, будь-яке відношення має володіти первинним ключем. Вимога цілісності щодо посилань, або вимога зовнішнього ключа полягає в тому, що для кожного значення зовнішнього ключа, що з'являється у відношенні, на яке веде посилання, повинен знайтися кортеж з таким же значенням первинного ключа, або значення зовнішнього ключа повинно бути невизначеним (тобто ні на що не вказувати).
Null-значення
Основне призначення баз даних полягає в тому, щоб зберігати і надавати інформацію про реальний світ. Для представлення цієї інформації в базі даних використовуються звичні для програмістів типи даних – Рядкові, чисельні, логічні і т.п. Однак у реальному світі часто зустрічається ситуація, коли дані невідомі або не повні. Наприклад, місце проживання або дата народження людини можуть бути невідомі (База даних розшукуваних злочинців). Якщо замість невідомої адреси доречно було б вводити порожній рядок, то що вводити замість невідомої дати? Відповідь – порожню дату – не цілком задовільний, тому що найпростіший запит "видати список людей у порядку зростання дат народження" дасть явно неправильних відповідь.
Для того щоб обійти проблему неповних або невідомих даних, в базах даних можуть використовуватися типи даних, поповнені так званим null-значенням. Null-значення – це, власне, не значення, а якийсь маркер, який показує, що значення невідоме.
Таким чином, у ситуації, коли можлива поява невідомих або неповних даних, розробник має на вибір два варіанти.
Перший варіант полягає в тому, щоб обмежитися використанням звичайних типів даних і не використовувати null-значення, а замість невідомих даних вводити або нульові значення, або значення спеціального виду – наприклад, домовитися, що рядок "Адреса невідома" і є ті дані, які потрібно вводити замість невідомої адреси. У будь-якому випадку на користувача (або на розробника) лягає відповідальність на правильне трактування таких даних. Зокрема, може знадобитися написання спеціального програмного коду, що у потрібних випадках "виловлював" би такі дані. Проблеми, що виникають при цьому очевидні – Не всі дані стають рівноправні, потрібен додатковий програмний код, "відслідковує" цю нерівноправність, в результаті чого ускладнюється розробка і супровід додатків.
Другий варіант полягає у використанні null-значень замість невідомих даних. За здавалося б природністю такого підходу ховаються менш очевидні і більш глибокі проблеми. Найбільш кидається в очі проблемою є необхідність використання тризначної логіки при оперуванні з даними, які можуть містити null-значення. У цьому випадку при неакуратному формулюванні запитів, навіть самі природні запити можуть давати неправильні відповіді. Є більш фундаментальні проблеми, пов'язані з теоретичним обгрунтуванням коректності введення null-значень, наприклад, незрозуміло взагалі, чи входять null-значення в домени чи ні.
Докладне обговорення проблем використання null-значень виходить за межі даної роботи. Можна тільки сказати про те, що це питання в теорії реляційних баз даних остаточно не вирішене. Основоположник реляційного підходу Кодд вважав null-значення невід'ємною частиною реляційної моделі. К. Дейт, один з найбільших теоретиків реляційної моделі виступає категорично проти null-значень (докладне обговорення проблем, що виникають при використанні null-значень наведено у книзі.
Практично всі реалізації сучасних реляційних СУБД дозволяють використовувати null-значення, незважаючи на їх недостатню теоретичну обгрунтованість. Таку ситуацію можна порівняти з ситуацією, що склалася на початку століття з теорією множин. Майже відразу після створення Кантором теорії множин, в ній були виявлені внутрішні суперечності (антиномії). Були розроблені більш суворі теорії, що дозволяють уникнути цих протиріч (конструктивна теорія множин). Однак у реальній роботі більшість математиків користується класичною теорією множин, тому що більш суворі теорії більш обмежені і негнучкий в застосуванні саме в силу своєї більшої строгості.
Думка автора (дуже скромне порівняно з думкою корифеїв реляційної теорії) полягає в тому, що бажано уникати null-значень. Тим не менш, приведемо тут опис тризначної логіки, необхідної для роботи з null-значеннями.
Тризначна логіка (3VL)
Оскільки null-значення позначає насправді той факт, що значення невідоме, то будь-які алгебраїчні операції (додавання, множення, конкатенація рядків і т.д.) повинні давати також невідоме значення, тобто null. Дійсно, якщо, наприклад, вага деталі невідома, то невідомо також, скільки важать 10 таких деталей.
При порівнянні виразів, що містять null-значення, результат також може бути невідомий, наприклад, значення істинності для виразу
є null, якщо один або обидва аргументи є null. Таким чином, визначення істинності логічних виразів базується на тризначної логіці(three-valued logic, 3VL), В якій крім значень T – ІСТИНА і F – БРЕХНЯ, введено значення U – НЕВІДОМО. Логічне значення U – це те ж саме, що і null-значення. Тризначна логіка базується на наступних таблицях істинності:| AND | F | T | U |
| F | F | F | F |
| T | F | T | U |
| U | F | U | U |
Таблиця 1 Таблиця істинності AND
| OR | F | T | U |
| F | F | T | U |
| T | T | T | T |
| U | U | T | U |
Таблиця 2 Таблиця істинності OR
| NOT | |
| F | T |
| T | F |
| U | U |
Таблиця 3 Таблиця істинності NOT
18.
Потенційний ключ для K для відношення R — це підмножина множини атрибутів R, що характеризується такими двома властивостями:
Властивість унікальності.
Немає двох різних кортежів в R з однаковим значенням K.
Властивість мінімальності (ненадмірності).
Ніяка з підмножин K не володіє властивістю унікальності.
Правильно, що кожне відношення має, щонайменше, один потенційний ключ через те, що не містить двох однакових кортежів; тобто комбінація всіх атрибутів володіє властивістю унікальності і тому можливі два варіанти.
Або ця комбінація володіє властивістю мінімальності, тобто є потенційним ключем (єдиним).
Або існує як мінімум одна підмножина цієї комбінації, що явно володіє властивістю унікальності, а також мінімальності.
У відношенні може бути декілька потенційних ключів. Один з них може бути вибраний в якості первинного ключа відношення, тоді інші називають альтернативними ключами.
Зазвичай на практиці первинний ключ обирають виходячи з міркувань ефективності.
Потенційні ключі забезпечують основний механізм адресації на рівні кортежів. Тобто, єдиний гарантований спосіб точно вказати який-небудь кортеж — це вказати значення якогось потенційного ключа. В інструкції SQL це, зазвичай, робиться в частині WHERE.
Таким чином потенційні ключі мають таке саме фундаментальне значення для успішної роботи реляційної системи, як адресація основної пам'яті для успішної роботи машини, на якій ця система встановлена.
Зовнішній ключ — атрибут (набір атрибутів) в деякому відношенні R, який відповідає первинному ключу іншого відношення або того ж таки відношення R.
В реляційних базах даних зовнішній ключ задається обмеженням FOREIGN KEY. Наприклад[1],
CREATE TABLE fools (
id INTEGER PRIMARY KEY AUTO_INCREMENT,
name CHAR(20),
folly_id INTEGER,
FOREIGN KEY(folly_id)
REFERENCES follies(id) ON DELETE CASCADE);
19 Мова SQL. Формат SQL-операторів. Маніпулювання даними
В ідеалі, будь-яка мова роботи з базами даних повинна надавати користувачу наступні можливості:
• створювати базу даних і таблиці з повним описом їх структури;
• виконувати основні операції маніпулювання даними, такі як вставка, модифікація і видалення даних з таблиць;
• виконувати прості і складні запити, що здійснюють перетворення необроблених даних в необхідну інформацію.
Крім того, мова роботи з базами даних повинна вирішувати всі вказані вище задачі при мінімальних зусиллях з боку користувача, а структура і синтаксис його команд повинні бути достатньо прості і доступні для вивчення. І, нарешті, вона повинна бути універсальною, тобто відповідати деякому визнаному стандарту, що дозволить використовувати один і той же синтаксис і структуру команд при переході від однієї СУБД до іншої. Мова SQL задовольняє практично всім цим вимогам.
SQL є прикладом мови з трансформуючою орієнтацією, або ж мови, призначеного для роботи з таблицями з метою перетворення вхідних даних до необхідного вихідного вигляду. Мова SQL має два основних компоненти:
• Мова DDL (Data Definition Language), призначена для визначення структур бази даних;
• Мова DML (Data Manipulation Language), призначена для вибірки і оновлення даних.
Мова SQL відносно проста у вивченні.
• Це не процедурна мова, тому в ній необхідно вказувати, яка інформація повинна бути одержана, а не як її можна одержати. Інакше кажучи, мова SQL не вимагає вказівки методів доступу до даних.
• Як і більшість сучасних мов, SQL підтримує вільний формат запису операторів. Це означає, що при введенні окремі елементи операторів не пов'язані з фіксованими позиціями екрану.
• Структура команд задається набором ключових слів, що є звичайними словами англійської мови — такі, як
CREATE TABLE (Створити таблицю), INSERT (Вставити), SELECT (Вибрати).
Наприклад:
CREATE TABLE staff(sno VARCHAR(5), Iname VARCHAR(15), salary DECIMAL(7,2));
INSERT INTO staff
VALUES ('SG16', 'Brown', 8300);
SELECT sno, Iname, salary
FROM staff
WHERE salary > 10000;
• Мова SQL може використовуватися широким колом користувачів, включаючи адміністраторів баз даних (АБД), керівний персонал компанії, прикладних програмістів і багатьох інших типів кінцевих користувачів.
Визначення мови SQL в стандарті ANSI передбачає розділення мови DDL на два компоненти: власне мова DDL, призначеної для визначення структури бази даних, і мови DCL (Data Control Language), що використовується для управління доступом до даних.
1 2 3 4 5 6 7 8 9