Топ питань
Часова шкала
Чат
Перспективи
Нормальна форма Бойса — Кодда
нормальна форма в нормалізації баз даних З Вікіпедії, вільної енциклопедії
Remove ads
Нормальна форма Бойса — Кодда (або НФБК, або БКННФ, або 3.5НФ) — нормальна форма використовна в нормалізації баз даних. Це трошки сильніша версія третьої нормальної форми (3НФ). Таблиця знаходиться в НФБК тоді і тільки тоді, коли для кожної її нетривіальної функціональної залежності X → Y, X це суперключ — тобто, X або потенційний ключ, або його надмножина.
НФБК була віднайдена в 1974 Реймондом Бойсом і Едгаром Коддом через деякі типи аномалій з якими не спрацьовувала 3НФ як було заявлено.[1]
Крістофер Дейт вказав, що визначення того, що ми знаємо як НФБК, в 1971 опублікував Ян Хіт.[2] Дейт писав:
«Через те, що це визначення випередило визначення Бойса і Кодда на три роки, мені здається, що НФБК по праву має називатись нормальна форма Хіта. Але це не так.»[3]
Remove ads
Таблиці в 3НФ, які не відповідають НФБК
Узагальнити
Перспектива
Лише зрідка таблиця в 3НФ не відповідає вимогам НФБК. Таблиця в 3НФ, яка не має кількох потенційних ключів, що перетинаються, гарантовано в НФБК.[4] Залежно від своїх функціональних залежностей, таблиця в 3НФ з двома або більше потенційними ключами, що перетинаються може бути або не бути в НФБК.
Приклад таблиці в 3НФ, яка не є в НФБК:
- Кожен рядок в таблиці представляє замовлення корту в тенісному клубі, який має один корт з твердим покриттям (Корт 1) і один з ґрунтовим (Корт 2)
- Замовлення визначається замовленим кортом і проміжком часу, на який корт замовлено
- Додатково, кожне замовлення має «Тип оплати» асоційований з ним. Існує чотири різних типи оплати:
- БЕРЕЖЛИВИЙ, для замовлень корту 1 членами клубу
- СТАНДАРТНИЙ, для замовлень корту 1 не членами клубу
- ПРЕМІАЛЬНИЙ-A, для замовлень корту 2 членами клубу
- ПРЕМІАЛЬНИЙ-Б, для замовлень корту 2 не членами клубу
Потенційні ключі таблиці:
- {Корт, Час початку}
- {Корт, Час завершення}
- {Тип оплати, Час початку}
- {Тип оплати, Час завершення}
Згадаймо, що 2НФ забороняє часткові функціональні залежності неключових атрибутів від потенційних ключів, і що 3НФ забороняє транзитивні функціональні залежності неключових атрибутів від потенційних ключів. В таблиці «Замовлення кортів на сьогодні» немає неключових атрибутів: тобто, всі атрибути належать потенційним ключам.
Таблиця не знаходиться в НФБК через залежність «Тип оплати» → «Корт», де визначальний атрибут («Тип оплати») ані потенційний ключ, ані його надмножина.
Залежність «Тип оплати» → «Корт» відображає, що певний тип оплати застосовується саме для одного корту.
Дизайн можна виправити так, щоб він відповідав НФБК:
Потенційними ключами для таблиці «Тип оплати» є {Тип оплати} і {Корт, Членство}; потенційними ключами для таблиці «Сьогоднішнє замовлення» є {Тип оплати, Час початку} і {Тип оплати, Час завершення}. Обидві таблиці знаходяться в НФБК. Тепер мати один тип оплати асоційований з двома різними кортами неможливо, тож можливі аномалії первісної таблиці виключені.
Remove ads
Досяжність НФБК
Узагальнити
Перспектива
В деяких випадках, не НФБК таблиця не може бути розкладена в таблиці, що задовільняють НФБК із збереженням залежностей початкової таблиці. Бірі і Бернштейн у 1979 показали, що, наприклад, набір функціональних залежностей {AB → C, C → B} не може бути представлений НФБК.[5] Таким чином, на відміну від перших трьох нормальних форм, НФБК не завжди досяжна.
Уявімо таблицю не в НФБК чиї функціональні залежності відповідають шаблону {AB ? C, C ? B}:
Для кожної комбінації «Особа» / «Тип магазину», таблиця каже нам який з магазинів цього типу географічно найближчий до помешкання певної особи. Для простоти ми припускаємо, що один магазин не може одночасно бути декількох типів.
Потенційні ключі таблиці:
- {Особа, Тип магазину}
- {Особа, Найближчий магазин}
Через те, що всі три атрибути ключові (тобто належить потенційному ключу), таблиця в 3НФ. Таблиця не в НФБК, бо «Тип магазину» функціонально залежний від не суперключа: «Найближчий магазин».
Невідповідність до НФБК значить, що таблиця вразлива для аномалій. Наприклад, Орлине око може змінити свій тип на «Оптометрія» на запису для Ковтуна, залишивши тип «Оптика» на запису для Скиби. Це викличе суперечливі відповіді на запитання: «Який тип має магазин Орлине око?» Здається розумним зберігати тип для кожного магазину тільки один раз, це унебезпечить від цієї аномалії:
В цьому переглянутому дизайні, таблиця «Магазин біля особи» має потенційний ключ {Особа, Магазин}, і таблиця «Магазин» має потенційний ключ {Магазин}. Хоча цей дизайн знаходиться у НФБК, він неприйнятний з іншої причини: він дозволяє нам записати декілька магазинів одного типу для однієї особи. Інакше кажучи, цей дизайн не гарантує виконання функціональної залежності {Особа, Тип магазину} → {Магазин}.
Дизайн, який виключає всі ці аноммалії (але не задовільняє умовам НФБК) можливий.[6] Цей дизайн містить початкову таблицю «Найближчий магазин» і додає таблицю «Магазин» описану нижче.
Якщо обмеження цілісності посилань визначити так, щоб {Тип магазину, Найближчий магазин} з першої таблиці посилалось на {Тип магазину, Магазин} з другої таблиці, тоді аномалії оновлення даних описані вище будуть усунуті.
Remove ads
Примітки
Посилання
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads