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

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

Функціональні залежності відносин Prop, Staff .і Prop_Inspect показані нижче.

Відношення Ргор

fd2 Property_No -> PAddress

Відношення Staff

d3 Staff_No -> SName

Відношення Prop_Inspection

fdl* Property_No, IDate,ITime, Comments, Staff_No, Car_Reg.

fd4 Sfaff_No, IDafe -> Car_Reg

d5* Car_Reg, IDafe,ITime -> Property_No, Comments, Staff_No

fd6* Staff_No, IDate, ITime -> Property_No, Comments

Можна помітити, що відносини Prop і Staff уже находятсй у НФБК, оскільки детермінант кожних їхніх цих відносин є потенційним ключем. Єдиним ЗНФ -відношенням, що не знаходиться в НФБК є відношення Prop_Inspect, тому що воно містить детермінант (Staff_No, IDate), що не є потенційним ключем (ця залежність позначена як fd4). Унаслідок цього відношення Prop_Inspect може страждати від аномалій відновлення. Наприклад, для зміни даних про автомобіль, замовленому для співробітника з номером 'SG14' на 22 квітня 1996 року ('22-арг-96'), буде потрібно виконати відповідне відновлення значень відразу в двох рядках. Але якщо номер автомобіля буде змінений тільки в одному рядку, те це приведе базу даних у протиречний стан.

Для перетворення відносини Prop_Inspect у НФБК необхідно усунути залежність, що порушує вимоги НФБК, що досягається шляхом створення двох нових відносин Staff_Саг і Inspection, уміст яких представлене в табл. 6.26 і 6.27 відповідно. Нові відносини мають наступний вид:

Staff_Car (Staff_No, IDate, Car_Reg)

I nspection (Property_No, IDate, ITime, Comments, Staff_No)

Відносини Staff_Car і inspection знаходяться в НФБК, оскільки детермінант кожних їхніх цих відносин є потенційним ключем.

У підсумку декомпозиція показаного в табл. 6.21 вихідного відношення Ргореrtу_Inspection (аж до НФБК - відношень) буде мати схематичний вид, показаний на мал. 6.9. У результаті виконання всіх етапів нормалізації, декомпозиція вихідного відношення Property_Inspection з утворенням НФБК - відношень приводить до утрати функціональної залежності Car_Reg, IDate, ITime -> Property_No, Comments, Staff_No (ця залежність позначена як fd5*). Однак, варто визнати, що якщо не усунути функціональну залежність Staff_No, IDate -> Car_Reg (ця залежність позначена як fd4), те відношення Prop_Inspection буде характеризуватися деякою надмірністю даних.

Отримані в результаті виконаної нормалізації відносини будуть мати наступний вид:

Prop (Property_No, PAddress)

Staff (Staff_No, SName)

Inspection (Property_No, IDate, ITime, Comments, Staff_No)

Staff_Car (Staff_No, IDate, Car_Reg)

Відношення Property_Inspection, представлене в табл. 6.21, може бути відновлене у вихідному стані за допомогою з'єднання відносин Prop, Staff, Inspection і Staff_Саг за допомогою механізму первинних зовнішніх ключів. Наприклад, атрибут Staff_No є первинним ключем відносини Staff, а, у відношенні Inspection він відіграє роль зовнішнього ключа. Наявність цього зовнішнього ключа дозволяє зв'язати відносини Staff_Inspection з метою визначення імені співробітника, що виконує, перевірку стану даного об'єкта нерухомості.