6.7. Третя нормальна форма (знф)

Хоча ЗНФ - відношення в меншому ступені мають надмірність даних, чим 1НФ-відношення, вони усе ще можуть страждати від аномалій відновлення. Так, при спробі відновлення імені власника нерухомості (наприклад, Tony Shaw з номером З093 (атрибут Owner_No)) буде потрібно обновити двох рядків відносини Ргорerty_0vner, представленого в табл. 6.10. Якщо обновити тільки одну з цих двох рядків, база даних потрапить у суперечливий стан. Ця аномалія відновлення викликається транзитивною залежністю, що є присутнім у даному відношенні. Вона може бути усунута шляхом приведення даного відношення до третьої нормальної форми. У цьому розділі транзитивні залежності розглядаються разом із третьою нормальною формою.

6.7.1. Транзитивна залежність

Транзитивна залежність Якщо для атрибутів А, В и С деякого відношення існують залежності виду А -> В и В -> С, те говорять, що атрибут Із транзитивно залежить від атрибута А через атрибут У (за умови, що атрибут А функціонально не залежить ні від атрибута В, ні від атрибута С).

Транзитивна залежність є описом такого типу функціональної залежності, що виникає при наявності наступних функціональних залежностей між атрибутами А, В и С:

А -> В и В -> С.

У даному випадку транзитивна залежність А -> С здійснюється через атрибут В. Це твердження справедливе тільки в тому випадку, якщо атрибут А функціонально не залежить від атрибутів В и С. Наприклад, розглянемо наступні функціональні залежності усередині відношення Staff_Branch, представленого в табл. 6.3.

Staff_No -> Branch_No і Branch_No -> BAddress

У цьому випадку транзитивна залежність Staff_So -> BAddress здійснюється через атрибут Branch_No. Дане твердження справедливе, оскільки атрибут Staff_Nо не залежить функціонально від атрибутів Branch_No і BAddress. Інші приклади транзитивних залежностей приводяться в наступних розділах.

6.7.2. Визначення третьої нормальної форми

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

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

Приклад 6.5. Третя нормальна форма (3нф)

Спочатку розглянемо функціональні залежності, що існують у відносинах

C ustomer, Rental і Property_Owner.

Усі не вхідні в первинний ключ атрибути відносин Customer і Rental функціонально залежні тільки від їхніх первинних ключів. Отже, відносини Customer і Rental не мають транзитивних залежностей, а тому вони вже знаходяться в третій нормальній формі (ЗНФ). (Зверніть увагу на те, що позначення деяких функціональних залежностей (fd) позначені зірочкою (*), що означає зміну цієї залежності (у порівнянні з вихідною функціональною залежністю)

Усі не вхідні в первинний ключ атрибути відносини Property_Owner функціонально залежать від первинного ключа, за винятком атрибута OName, що також залежить і від атрибута Owner_No (залежність fd4). Це типовий приклад транзитивної залежності, що має місце при наявності залежності не вхідного в первинний ключ атрибута (OName) від одного чи декількох інших атрибутів, що також не входять у первинний ключ (Owner_No). Дана транзитивна залежність схематично показана на мал. 6.5.

Для перетворення відносини Property_0wner у третю нормальну форму необхідно насамперед видалити згадану вище транзитивну залежність шляхом створення двох нових відносин Property_for_Rent і Owner, що представлені в табл. 6.11 і 6.12 відповідно. Нові відносини мають наступний вид:

Property_for_Rent (Property No, PAddress, Rent, Ovner_No)

O wner (Owner_No, OName)

Відносини Property_for_Rent і Owner знаходяться в третій нормальній формі, оскільки в них немає ніяких транзитивних залежностей від первинного ключа. У результаті виконання нормалізації представлене в табл. 6.5 вихідне відношення Customer_Rental було перетворено в чотири окремих відношення, кожне з який знаходиться в третій нормальній формі. На мал. 6.6 приведена схема даного процесу, що пояснює, як 1НФ - відношення було перетворено в чотири ЗНФ - відношень, що мають наступний вид:

Customer (Customer_No, СName)

Rental (Customer Nо, Property_No, RentStart, RentFinish)

Property_for_Rent (Propcrty_No, PAddress, Rent, Owner_No)

Owner (Owner_No, OName)

В ихідне відношення Customer_Rental, представлене в табл. 6.5, може бути відновлене шляхом з'єднання відносин Customer, Rental, Property_for_Rent і Owner. Дана мета досягається за рахунок використання первинних і зовнішніх ключів. Наприклад, атрибут Owner_No є первинним ключем відносини Owner і, крім того, є присутнім у відношенні Property_for_Rent як його зовнішній ключ. Атрибут Owner_No, використовуваний для створення пари з первинного і зовнішнього ключів, дозволяє зв'язати відносини Property_for_Rent і Owner з метою визначення імен власників об'єктів нерухомості, що здаються в оренду.

Атрибут Customer_No є первинним ключем відносини Customer і, додатково, зовнішнім ключем відносини Rental. Зверніть увагу на те, що у відношенні Rental атрибут Customer_No виконує функції як зовнішнього, так і частини первинного ключа. Аналогічним образом, атрибут Property_No є первинним ключем відносини Property_for_Rent і, додатково, у відношенні Rental виконує функції як зовнішнього ключа, так і частини первинного ключа.

Інакше кажучи, процес нормалізації полягає в декомпозиції вихідного відношення Customer Rental за допомогою послідовного виконання декількох операцій проекції реляційної алгебри (див. роздягнув 3.4). Отримані в результаті декомпозиції відносини забезпечують виконання їхнього з'єднання без утрат, тому дану процедуру інакше називають безпрограшної (nonloss) (чи неадитивної (nonadditive)) декомпозицією. Результати декомпозиції можна звернути за допомогою операції природного з'єднання.

Остаточний вид відносин Customer, Rental, Property_for_Rent і Owner, отриманих у результаті декомпозиції, представлений у табл. 6.13, 6.14, 6.15 і 6.16 відповідно.