Нормалізація - це розбивка таблиці на дві або більше, що володіють кращими властивостями при включенні, зміні й видаленні даних. Остаточна мета нормалізації зводиться до одержання такого проекту бази даних, у якому кожний факт з'являється лише в одному місці, тобто виключена надмірність інформації. Це робиться не стільки з метою економії пам'яті, скільки для виключення можливої суперечливості збережених даних.
Кожна таблиця в реляційної БД задовольняє умові, відповідно до якого в позиції на перетині кожного рядка й стовпця таблиці завжди перебуває єдине атомарне значення( тобто в одній комірці перебуває одне значення: у текстовій - текст, у числовій тільки одне число, а не група чисел перерахованих через кому ), і ніколи не може бути множини таких значень. Будь-яка таблиця, що задовольняє цій умові, називається нормалізованою. Фактично, ненормалізовані таблиці, тобто таблиці, що містять повторювані групи, навіть не допускаються в реляційній БД.
Усяка нормалізована таблиця автоматично вважається таблицею в першій нормальній формі, скорочено 1НФ. Таким чином, строго кажучи, "нормалізована" і "перебуває в 1НФ" означають те саме . Однак на практиці термін "нормалізована" часто використається в більше вузькому змісті - "повністю нормалізована", що означає, що в проекті не порушуються ніякі принципи нормалізації.
Таблиця перебуває в першій нормальній формі (1НФ) тоді й тільки тоді, коли жодна з її рядків не містить у будь-якім своєму полі більше одного значення й жодне з її ключових полів не порожнє.
Для розгляду 2НФ і 3НФ уведемо додаткові поняття. Функціональна залежність. Поле В таблиці функціонально залежить від поля А тієї ж таблиці в тім і тільки в тому випадку, коли в будь-який заданий момент часу для кожного з різних значень поля А обов'язково існує тільки одне з різних значень поля В. Відзначимо, що тут допускається, що поля А і В можуть бути складовими.
Повна функціональна залежність. Поле В перебуває в повній функціональній залежності від складеного поля А, якщо воно функціонально залежить від А і не залежить функціонально від будь-якої підмножини поля А.
Таблиця перебуває в другій нормальній формі (2НФ), якщо вона задовольняє визначенню 1НФ і всього її поля, що не входять у первинний ключ, зв'язані повною функціональною залежністю з первинним ключем.
Таблиця перебуває в третій нормальній формі (3НФ), якщо вона задовольняє визначенню 2НФ і не одне з її неключових полів не залежить функціонально від будь-якого іншого неключового поля.
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
2НФ
Відношення перебуває в 2НФ, якщо воно перебуває в 1НФ, і при цьому всі неключові атрибути залежать тільки від ключа цілком, а не від якоїсь його частини.
(ПІБ. Номер зал.кн.. Група. Дисципліна. Оцінка)
Тому що кожний студент здає цілий набір дисциплін у процесі сесії, те первинним ключем відносини може бути (Номер, зал.кн.. Дисципліна), що однозначно визначає кожну стоку, відносини. З іншого боку, атрибути ПІБ й Група залежать тільки від частини первинного ключа - від значення атрибута Номер зал., кн., тому ми повинні констатувати наявність неповних функціональних залежностей у даному відношенні. Для приведення даного відношення до другої нормальної форми варто розбити його на проекції, при цьому повинне бути дотримане умова відновлення вихідного відношення без втрат. Такими проекціями можуть бути двоє відносин:
(ПІБ, Номер.зал.кн.. Група) (Номер зал.кн.. Дисципліна. Оцінка)
А чому треба приводити відносини до другої нормальної форми? Інакше кажучи, які аномалії або незручності можуть виникнути, якщо ми залишимо вихідне відношення й не будемо його розбивати на два? Давайте розглянемо ситуацію, коли студент переведений з однієї групи в іншу. Тоді в першому випадку (якщо ми не розбивали вихідне відношення на два) ми повинні знайти всі записи з даним студентом і в них змінити значення атрибута Група на нове. У другому ж випадку міняється тільки один кортеж у першому відношенні. І звичайно, небезпека порушення коректності (несуперечності змісту) БД у першому випадку вище. Може вийти так, що частина кортежів поміняє значення атрибута Група, а частина через збої в роботі апаратур залишиться в старому стані. І тоді наша БД буде містити запису, які відносять одного студента одночасно до різних груп. Щоб цього не відбулося, ми повинні приймати додаткові непрості міри, наприклад організовувати процес погодженої зміни з використанням складного механізму транзакцій, що ми будемо розглядати в главах, присвячених питанням розподіленого доступу до БД. Якщо ж ми перейшли до другої нормальної форми, то ми міняємо тільки один кортеж. Крім того, якщо в нас є студенти, які ще не здавали іспити, то у вихідному відношенні ми взагалі не можемо зберігати про їх інформацію, а в другій схемі інформація про студентів і їхню приналежність до конкретної групи зберігається окремо від інформації, що зв'язана зі здачею іспитів, і тому ми можемо в цьому випадку окремо працювати зі студентами й окремо зберігати й обробляти інформацію про успішність і здачу іспитів, що в дійсності й відбувається
3НФ
Щоб привести відношення до 3НФ, необхідно усунути функціональні залежності між неключовими атрибутами. Інакше кажучи, дані, що збережені в таблиці, повинні залежати тільки від ключа.
Функціональна залежність R.A -> R.B називається транзитивною, якщо існує набір атрибутів С такий, що:
С не є підмножиною А.
С не містить у собі В.
Існує функціональна залежність R.A -> R.C.
Не існує функціональної залежності R.C -> R.A.
Існує функціональна залежність R.C -> R.B.
ПР.1
Розглянемо відношення, що зв'язує студентів із групами, факультетами й спеціальностями, на яких вони вчаться.
(ПІБ. Номер зал.кн. Група. Факультет, Спеціальність, Випускаюча кафедра)
Первинним ключем відношень є Номер зал.кн., однак розглянемо інші функціональні залежності. Група, у якій учиться студент, однозначно визначає Факультет, на якому він учиться, а також Спеціальність і Випускаючу кафедру. Крім того, Випускаюча кафедра однозначно визначає Факультет, на якому навчаються Студенти, що випускаються даною кафедрою. Але якщо ми припустимо, що одну Спеціальність можуть випускати кілька кафедр, то Спеціальність не визначає Випускаючу кафедру. У цьому випадку в нас є наступні функціональні залежності:
Номер зал. кн. -> ПІБ
Номер зал.кн. -> Група
Номер зал.кн. -> Факультет
Номер зал.кн. -> Спеціальність
Номер зал.кн. -> Випускаюча кафедра
Група -> Факультет
Група -> Спеціальність
Група -> Випускаюча кафедра
Випускаюча кафедра -> Факультет
І ці залежності утворять транзитивні групи.
((С - спеціальність
А - кафедра
В - факультет)
А->C
C ~->A
C->B)
Для того щоб уникнути цього, ми можемо запропонувати наступний набір відносин:
(Номер. зал. кн., ПІБ. Спеціальність. Група) (Група. Випускаюча кафедра) (Випускаюча кафедра, Факультет)
Первинні ключі відносин виділені.
Тепер необхідно впевнитися, що при природному з'єднанні ми не втратимо ні одного рядка й не одержимо зайвих кортежів. Цю вправу самостійно.
Отриманий набір відносин перебуває в третій нормальній формі.
Пр2.
Табл 5а.
Найм. Місто Адреса Ел. почта WWW Функція Посада ПІБ Тел.
Табл 5б
Місто Код_міста
((А – ПІБ (людина)
С – посада
В - телефон)
А->C
C ~->A
C->B)
У нашому випадку присутнія функціональна залежність між атрибутами "ПІБ.", "Посада" і "Тел." Очевидно, що на підприємстві якась людина займає певну посаду й має у своєму розпорядженні певний робочий телефон. Зворотне в загальному випадку невірно - на підприємстві може бути кілька аналогічних штатних одиниць, наприклад, менеджери по збуту, і кілька людей можуть користуватися одним робочим телефоном.
Щоб позбутися від даної функціональної залежності, проведемо декомпозицію таблиці 5а на дві таблиці.
Перша з них зберігає факти, що відносяться безпосередньо до самого підприємства:
Табл. 6а
Найм. Місто Адреса Ел. пошта WWW Функція
Друга таблиця зберігає факти, що відносяться до конкретної особи, що виконує деякий обов'язок на даному підприємстві:
Табл. 6б
Найм. Місто ПІБ Посада Тел.
Разом з таблицею 5б даний набір таблиць являє собою нашу вихідну базу даних, приведену до 3НФ.
НФБК
Відношення перебуває в нормальній формі Бойса-Кодда, якщо воно перебуває в третій нормальній формі й кожний детермінант відношеня є можливим ключем відношеня.
Розглянемо відношення, що моделює здачу студентом поточних іспитів. Припустимо, що студент може здавати екзамен з однієї дисципліни кілька разів, якщо він одержав незадовільну оцінку. Допустимо, що щоб уникнути можливих повних однофамільців ми можемо однозначно ідентифікувати студента номером його залікової книги, але, з іншого боку, у нас ведеться електронний облік поточної успішності студентів, тому кожному студентові привласнюється в період його навчання у вузі унікальний номер-ідентифікатор. Відношення, що моделює здачу поточної сесії, має наступну структуру:
(Номер зал.кн.. Ідентифікатор_студента. Дисципліна. Дата. Оцінка)
Можливими ключами відносини є: 1) Номер_зал.кн, Дисципліна, Дата й 2) Ідентифікатор_студента, Дисципліна, Дата.
Які функціональні залежності в нас є?
Номер_зал.кн, Дисципліна. Дата -> Оцінка;
Ідентифікатор_студента, Дисципліна. Дата -> Оцінка;
Номер зал.кн. -> Ідентифікатор_студента;
Ідентифікатор_студента -> Номер зал.кн.
Звідки узялися дві останні функціональні залежності? Але адже ми попередньо описали, що кожному студентові ставиться у відповідність одні номер залікової книжки й один Ідентифікатор_студента, тому за значенням Номер зач.кн. можна однозначно визначити Ідентифікатор_студента (це третя залежність) і назад (і це четверта залежність). Оцінимо це відношення,
Це відношення перебуває в третій нормальній формі, тому що неповних функціональних залежностей непервинних атрибутів від атрибутів можливого ключа тут нема і немає транзитивних залежностей. А як же третя й четверта залежності, хіба вони не є неповними? Ні, тому що залежним не є непервинний атрибут, тобто атрибут, що не входить ні в один можливий ключ. Тому причепитися до цього ми не можемо. Але от під четверту нормальну форму наше відношення не підходить, тому що в нас є два детермінанти Номер зал.кн. і Ідентифікатор_студента, які не є можливими ключами відносини. Для приведення відношення до нормальної форми Бойса-Кодда треба розділити відношення, наприклад, на два з наступними схемами:
(Ідентифікатор_студента. Дисципліна. Дата. Оцінка)
(Номер зал.кн.. Ідентифікатор_студента)
або навпаки:
(Номер зал.кн., Дисципліна. Дата, Оцінка)
(Номер зач.кн.. Ідентифікатор_студента)
Ці схеми рівнозначні з погляду теорії нормалізації, тому вибирати проектувальникам треба виходячи з деяких додаткових міркувань. Ну, наприклад, якщо врахувати, що залікові книжки можуть губитися, то як вони будуть відновлюватися: якщо з тим же самим номером, те немає різниці, але якщо з новим номером, те тоді першій схемі можна надати перевагу.
У більшості випадків досягнення третьої нормальної форми або навіть форми Бойса-Кодда вважається достатнім для реальних проектів баз даних.