Головна    Статті    Карта    Зв'язок   

Нормалізація схеми бази даних

березень 2015

Аналіз інформації за тематикою "Нормалізація схеми бази даних" за ресурсом http://uk.wikipedia.org/
Для ознайомлення розглянуто лише перші три форми нормалізації Баз Даних.

Таблиця даних реляційної Бази Даних.



представлення таблиці Баз Даних

Визначення

Нормалізація схеми бази даних — покроковий процес розбиття одного відношення (на практиці: таблиці) відповідно до алгоритму нормалізації на декілька відношень на базі функціональних залежностей.


Метою нормалізації є усунення недоліків структури БД, які призводять до шкідливої надмірності в даних, яка в свою чергу потенційно призводить до різних аномалій і порушень цілісності даних.

Нормальна форма — властивість відношення в реляційній моделі даних, що характеризує його з точки зору надмірності, яка потенційно може призвести до логічно помилкових результатів вибірки або зміни даних. Нормальна форма визначається як сукупність вимог, яким має задовольняти відношення.


Нормальна форма — формальна властивість відношення, яка характеризує ступінь надмірності збережуваних даних і можливі проблеми. Кожна наступна нормальна форма в нижченаведеному списку (крім ДКНФ) в деякому сенсі є досконалішою, ніж попередня, з точки зору усунення надмірності.


Нормальні форми:
Перша нормальна форма (1НФ, 1NF)
Друга нормальна форма (2НФ, 2NF)
Третя нормальна форма (3НФ, 3NF)
Нормальна форма Бойса — Кодда (НФБК, BCNF)
Четверта нормальна форма (4НФ, 4NF)
П'ята нормальна форма (5НФ, 5NF)
Доменно-ключова нормальна форма (ДКНФ, DKNF).


Перша нормальна форма (1НФ, 1NF)

Перша нормальна форма (1НФ, 1NF) утворює ґрунт для структурованої схеми бази даних:
- Кожна таблиця повинна мати основний ключ: мінімальний набір колонок, які ідентифікують запис.
- Уникнення повторень груп (категорії даних, що можуть зустрічатись різну кількість разів в різних записах) правильно визначаючи неключові атрибути.
- Атомарність: кожен атрибут повинен мати лише одне значення, а не множину значень.


Приклад

приклад нормалізації таблиці 1NF

Друга нормальна форма (2НФ, 2NF)

Друга нормальна форма (2НФ, 2NF) вимагає, аби дані, що зберігаються в таблицях із композитним ключем не залежали лише від частини ключа:
- Схема бази даних повинна відповідати вимогам першої нормальної форми.
- Дані, що повторно з'являються в декількох рядках виносяться в окремі таблиці.

Щоб бути в другій нормальній формі, таблиця, що знаходиться в першій нормальній формі, має відповідати додатковим критеріям. А саме: 1НФ таблиця знаходиться в 2НФ тоді і тільки тоді, коли для будь-якого потенційного ключа K і будь-якого атрибута A, який не є частиною потенційного ключа, A залежить саме від цілого потенційного ключа, а не від його частини.

Трошки більш формально: 1NF таблиця знаходиться в 2НФ тоді і тільки тоді, коли всі її неключові атрибути функціонально залежні від цілих потенційних ключів.
Зауважимо, що коли 1НФ таблиця не має складних потенційних ключів (таких, що складаються більш ніж з одного атрибута), тоді таблиця автоматично знаходиться в 2НФ.

Приклад

Розглянемо таблицю, що описує вміння працівників:

приклад нормалізації таблиці 2NF

Ані {Працівник} ані {Вміння} не є потенційними ключами для таблиці. Через те, що «Працівник» може мати декілька вмінь, а «Вміння» може з'являтись у більше ніж одного Працівника. Саме складний ключ {Працівник, Вміння} підходить як потенційний ключ для таблиці.

Інші атрибути, «Поточне місце роботи», залежні від частини потенційного ключа, від Працівника. Тобто таблиця не в 2НФ. Зауважте на надлишковість в представленні атрибута «Поточне місце роботи»: ми тричі кажемо, що Палій працює на Бузковому провулці, 7, і двічі, що Мамай працює на проспекті Троянд, 49. Ця надлишковість робить таблицю вразливою для аномалій оновлення: це, наприклад, можливість оновити місце роботи Палія на його записах про "Друкування" і "Стенографію" і не оновити запис про "Мосяжництво". Отримані дані будуть припускати суперечливі відповіді на питання «Де працює Палій?»

Варіант в 2NF для цього набору даних буде містити дві таблиці: «Працівник» з потенційним ключем {Працівник}, "Вміння працівників" з потенційним ключем {Працівник, Вміння}:

приклад нормалізації таблиці 2NF

Жодна з цих таблиць не постраждає від аномалій оновлення.

Однак, не всі таблиці в 2НФ унебезпечені від аномалій оновлення. Приклад таблиці в 2НФ, яка може постраждати від аномалій оновлення:

приклад нормалізації таблиці 2NF

Попри те, що «Переможець» і «Дата народження переможця» визначається через цілий ключ {Змагання / Рік} і не є його частиною, саме поєднання «Переможець» / «Дата народження переможця» створює надлишковість. Це призводить до аномалій оновлення: якщо оновлення не потурбувалось про цілісність, можемо отримати переможця з двома різними датами народження.

Проблема полягає в транзитивній залежності атрибута «Дата народження переможця». «Дата народження переможця» залежить від «Переможець», який в свою чергу залежить від ключа.

2НФ і потенційні ключі

Таблиці в яких немає часткових функціональних залежностей від первинного ключа зазвичай, але не завжди, в 2НФ. В додаток до первинного ключа, таблиця може містити інші потенційні ключі; необхідно встановити, що немає неключових атрибутів, які мають часткову залежність від будь-якого потенційного ключа.

Кілька потенційних ключів зустрічаються в наступній таблиці:

приклад нормалізації таблиці 2NF

Навіть якщо проектувальник визначить первинний ключ як {Повна назва}, таблиця не в 2НФ. {Виробник, Модель} також потенційний ключ, і «Країна виробник» залежить від його підмножини «Виробник». Для переведення в 2НФ необхідно перейти до двох таблиць:

приклад нормалізації таблиці 2NF


Третя нормальна форма (3НФ, 3NF)

Третя нормальна форма (3НФ, 3NF) вимагає, аби дані в таблиці залежали винятково від основного ключа:
- Схема бази даних повинна відповідати всім вимогам другої нормальної форми.
- Будь-яке поле, що залежить від основного ключа та від будь-якого іншого поля, має виноситись в окрему таблицю.



Третя нормальна форма (3НФ) — нормальна форма використовна в нормалізації баз даних. 3НФ первісно була визначена Едгаром Коддом в 1971.

Визначення: Кодд каже, що таблиця знаходиться в 3НФ тоді і тільки тоді, коли виконуються наступні умови:
- Відношення R (таблиця) знаходиться в 2НФ
- Кожен неключовий атрибут відношення R нетранзитивно залежить (тобто залежить безпосередньо) від кожного потенційного ключа в R.

Неключовий атрибут R — атрибут, що не є частиною будь-якого потенційного ключа.

Транзитивною називають таку функціональну залежність, в якій X > Z (X визначає Z) непрямо, а через X > Y і Y > Z (і невірно, що Y > X).


Інше визначення 3НФ тотожне до визначення Кодда, дав Карло Заніоло в 1982.
Це визначення стверджує, що таблиця в 3НФ тоді і тільки тоді, коли для кожної її функціональної залежності X > A, вірна хочаб одна з наступних умов:
- X містить A (тоді X > A це тривіальна функціональна залежність), або
- X це суперключ, або
- A-X, різниця множин A і X це ключовий атрибут (тобто, A-X міститься в потенційному ключі)

Визначення Заніоло вносить ясність врізниці між 3НФ і строгішою нормальною формою Бойса-Кодда. НФБК просто виключає третій варіант («A це ключовий атрибут»).


"Нічого окрім ключа"

Вікопомне підсумкове визначення Кодда 3НФ було дане Біллом Кентом: кожен неключовий атрибут «має надавати факт про ключ, цілий ключ, і ні про що окрім ключа.»

Часто це визначення доповнюють клятвою: «тож допоможи мені Кодд» (використовується схожість звучання Кодд (англ. Codd) і Бог (англ. God) анлійською).


Вимога, щоб неключовий атрибут знаходився в залежності від «цілого ключа», гарантує, що таблиця знаходиться в 2НФ;
наступна вимога, щоб неключові атрибути були залежні від «нічого окрім ключа», гарантує, що таблиця знаходиться в 3НФ.


Крістофер Дейт згадував підсумок Кента, як «інтуїтивно привабливу характеризацію» 3НФ, і зауважував, що з невеличкою адаптацією він може слугувати, як визначення трошки сильнішої нормальної форми Бойса-Кодда: «Кожен атрибут має уособлювати факт про ключ, про цілий ключ, і нічого окрім ключа.»

Версія визначення для 3НФ слабша за варіант Дейта для БКНФ, бо попередня забезпечує гарантію залежності від ключів лише для неключових атрибутів.

Ключові атрибути (які є ключами або їх частиною) мають бути вільними від функціональної залежності взагалі; кожен з них подає факт про ключ в сенсі надання частини ключа або цілого ключа.

(Тут треба зауважити, що це правило застосовується тільки для функціонально залежних атрибутів, застосування його до всіх атрибутів спричинить неявну заборону складних потенційних ключів, бо кожна частина такого ключа буде порушувати умову «цілого ключа».)


Приклад таблиці в 2НФ, що порушує вимоги 3НФ:

приклад нормалізації таблиці 3NF

Через те, що кожний рядок таблиці має сказати нам, хто виграв конкретне змагання конкретного року, складний ключ {Змагання, Рік} - це найменший набір атрибутів, який гарантовано визначає рядок. Тобто, {Змагання, Рік} є потенційним ключем для цієї таблиці.

Таблиця не знаходиться в 3НФ, бо неключовий атрибут «Дата народження переможця» транзитивно залежить від потенційного ключа {Змагання, Рік} через неключовий атрибут «Переможець».

Функціональна залежність «Дата народження переможця» від «Переможець» призводить до логічних несумісностей, в цій таблиці ніщо не заважає одній особі мати дві дати народження в різних записах.

В порядку відображення цього факту без порушення 3НФ, необхідно розбити таблицю на дві:

приклад нормалізації таблиці 3NF

Аномалії оновлення не можуть статися в цих таблицях, бо обидві в 3НФ.

Заключення

- Власне нормалізація таблиць Баз даних насправді корисна штука, але, вважаю, для великих проектів, де справді можливо наплутати з введенням, оновленням, видаленням даних.

- Якщо ж даних мало, то форми визначення структурування таблиць дещо складноваті :)
Хоча можливо все це лише справа практики.

Та ще раз, можете переглянути версію Посібник Г.А.Гайна Основи проектування баз даних.