6.8. Нормальна форма Бойса - Кодда (нфбк)

Відносини бази даних проектуються таким чином, щоб виключити в них присутність часткових чи транзитивних залежностей, оскільки ці залежності приводять до появи аномалій відновлення, розглянутих у розділі 6.2. Дотепер ми використовували визначення другої і третій, нормальних форм, для одержання яких потрібно знайти і виключити часткові і транзитивні залежності від первинного ключа. Однак у цих визначеннях не розглядаються такі ж залежності від потенційних ключів відносини, якщо такі маються.

6.8.1. Визначення нормальної форми Бойса - Кодда

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

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

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

Розходження між ЗНФ і НФБК полягає в тім, що функціональна залежність А -> У допускається в ЗНФ - відношенні, якщо атрибут У є первинним ключем, а атрибут А не обов'язково є потенційним ключем. Тоді як у НФБК - відношенні ця залежність допускається тільки тоді, коли атрибут А є потенційним ключем. Отже, нормальна форма Бойса - Кодда є твердою версією форми ЗНФ, оскільки кожне НФБК - відношення є ЗНФ - відношенням, але не всяке ЗНФ - відношення є НФБК - відношенням.

Перед тим як звернутися до чергового приклада, ще раз розглянемо відносини Customer, Rental, Property_for_Rent і Owner, представлені в табл. 6.13-6.16. Відносини Customer, Property_for_Rent і Owner є НФБК - відносинами, тому що кожне з них має тільки один детермінант, що у той же час є потенційним ключем цього відношення. Отут варто нагадати, що відношення Rental містить три детермінанти - (Customer_No, Property_No), (Customer_No, RentStart) і (Property_No, RentStart), - які були виявлені нами в прикладі 6.5 і мають вид, показаний нижче.

fdl CustomerJto, Property_No -> RentStart, RentFinish

fd5* Customer_No, RentStart -> Property_No RentFinish

fd6* Property_No, RentStart -> CustomerJto, RentFinish

Оскільки цих три детермінанти відносини Rental є також потенційними ключами, то відношення Rental знаходиться в НФБК. Порушення вимог НФБК відбуваються вкрай рідко, оскільки це може случитися тільки тоді, коли:

• маються два (чи більш) складених потенційних ключі;

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

У наступному прикладі описується ситуація, коли відношення порушує вимоги НФБК, і представлений метод перетворення цього відношення в НФБК.

Приклад 6.6. Нормальна форма Бойса-Кодда (нфбк)

У цьому прикладі ми розглянемо відношення Client Interview, що містить зведення про співбесіди клієнтів зі співробітниками компанії DreamHome. Для проведення співбесіди в той день, на який призначена зустріч із клієнтом, у розпорядження співробітника надається особлива кімната. Однак протягом робочого дня ця кімната може використовуватися декількома різними співробітниками. З клієнтом проводиться тільки одна співбесіда в день, але він може брати участь у декількох співбесідах у різні дні. Обговорюване відношення має три потенційних ключі: (Client No, Interview Date), (Staff_No, Interview Date, Interview Time) і (Room No, Interview Date, Interview Time). Отже, відношення Client Interview володіє трьома складеними потенційними ключами, що перекриваються, тобто ними спільно використовується один загальний атрибут - Interview Date. Як первинний ключ даного відношення обрана комбінація атрибутів (Client No, Interview Date). Це відношення представлене в табл. .6.17 і має, що випливає вид:

Client_Interview (Client_No, Interview Date, Interview_Time, Staff_No, Room_No)

Воно містить наступні функціональні залежності

fd1 Client_No, Interview_Date -> Interview_Time, Staff_No, Room_No Первинний ключ

fd2 StaffJto, Interview_Date, Interview_Time -> Client_No Потенційний ключ

fd3 Room_No, Interview_Date, Interview_Time -> Staff_No, Client_No Потенційний ключ

fd4 Staff_No, Interview_Date -> Room_No

Розглянемо ці функціональні залежності для визначення нормальної форми відносини Client_lnterview. Оскільки функціональні залежності fdl, fd2 і fd3 є потенційними ключами цього відношення, то вони не викликають ніяких проблем. Нам буде потрібно розглянути тільки функціональну залежність Staff_No, Interview_Date -> Room_No (залежність fd4). Навіть якщо комбінація атрибутів (Staff_No, Interview_Date) не є потенційним ключем відносини Client_Interview, ця функціональна залежність допускається в ЗНФ, тому що атрибут Room_No є атрибутом первинного ключа і частиною потенційного ключа (Room_No, Interview_Date, Interview_Time). Оскільки в цьому відношенні немає ніяких часткових чи транзитивних залежностей від первинного ключа (Client_No, Interview_Date) і допускається наявність, функціональної залежності fd4, можна вважати, що відношення Client_tnterview знаходиться в ЗНФ.

Однак це відношення не знаходиться в НФБК (більш строгий варіант ЗНФ), тому що в ньому є присутнім детермінант (Staff_No, Interview_Date), що не є потенційним ключем цього відношення. У НФБК потрібно, щоб усі детермінанти відносини були його потенційними ключами. У противному випадку відношення Client_Interview може страждати від аномалій відновлення. Наприклад, 13 травня 1998 року (значення '13-мау-98') при зміні номера кімнати, виділеної співробітнику 'SG5', буде потрібно обновити значення в двох рядках. Якщо при цьому буде обновлена тільки один рядок, то база даних буде приведена в суперечливий стан. Для перетворення відносини Client_Interview у форму НФБК необхідно усунути функціональну залежність, що порушує її обмеження, за допомогою створення двох нових відносин - Interview і Staff_Room - представлених у табл. 6.18 і 6.19 відповідно. Відносини Interview і Staff_Room мають наступний вид:

Interview (Client_No, Interview_Date, Interview_Time, Staff_No)

S taff_Room (Staff_No, Interview_Date, Room_No)

Б удь-яке відношення, що не знаходиться в НФБК, можна декомпозувати з утворенням НФБК - відносин, однак робити це не завжди бажано. Наприклад, декомпозиція буде небажана, якщо в результаті її виконання втрачається деяка функціональна залежність (тобто детермінант і обумовлені їм атрибути містяться в різні відносини). У цій ситуації буде важко забезпечити вихідну функціональну залежність відносини і важливе обмеження може бути утрачено. Якщо має місце згадана ситуація, то краще закінчити процес нормалізації на етапі утворення ЗНФ - відносин, у яких усі необхідні залежності завжди зберігаються. Зверніть увагу на те, що в прикладі 6.6 при створенні двох нових НФБК - відносин на основі вихідного відношення Client_Interview утрачається наступна функціональна залежність; Room_No, Interview_Date, Interview_Time -> Staff_No, Client_No (залежність fd3), оскільки детермінант цієї залежності більше не буде знаходитися в тім же відношенні, що й обумовлені їм атрибути. Однак варто визнати, що якщо не усунути функціональну залежність Staff_So, Interview_Date -> Room_No (залежність fd4), те відношення Client_Interview буде мати надмірність даних.