BCNF - нормальна форма Бойса-Кодда
Проектування реляційних БД. Нормальні форми вищих порядків
BCNF - нормальна форма Бойса-Кодда
Ця нормальна форма вводить додаткове обмеження в порівнянні з 3НФ.
При приведенні відношень за допомогою алгоритму нормалізації до відношень у 3НФ неявно передбачалося, що усі відношення містять один потенційний ключ. Це не завжди вірно. Розглянемо наступний приклад відношення, що містить два ключі.
Приклад 1. Нехай потрібно зберігати дані про постачання деталей певними постачальниками. Припустимо, що найменування постачальників є унікальними. Крім того, кожен постачальник має свій унікальний номер. Дані про постачання можна зберігати в наступному відношенні:
| Номер постачальника PNUM | Найменування постачальника PNAME | Номер деталі DNUM | Кількість, що поставляється VOLUME |
| Фірма 1 | |||
| Фірма 1 | |||
| Фірма 1 | |||
| Фірма 2 | |||
| Фірма 2 | |||
| Фірма 3 |
Таблиця 1 Відношення "Поставки"
Дане відношення містить два потенційних ключі - { PNUM, DNUM } і { PNAME, DNUM }. Видно, що дані зберігаються у відношенні з надлишковістю - при зміні найменування постачальника, це найменування потрібно змінити у всіх кортежах, де воно зустрічається.
Чи можна цю аномалію усунути за допомогою алгоритму нормалізації, розглянутого на попередній лекції? Для цього потрібно виявити наявні функціональні залежності (курсивом виділені ключові атрибути):
|
|
|
PNUM -> PNAME - найменування постачальника залежить від номера постачальника.
PNAME -> PNUM - номер постачальника залежить від найменування постачальника.
{ PNUM, DNUM } -> VOLUME - кількість, що поставляється, залежить від першого ключа відношення.
{ PNUM, DNUM } -> PNAME - найменування постачальника залежить від першого ключа відношення.
{ PNAME, DNUM } -> VOLUME - кількість, що поставляється, залежить від другого ключа відношення.
{ PNAME, DNUM } -> PNUM - номер постачальника залежить від другого ключа відношення.
Дане відношення не містить неключових атрибутів, що залежать від частини складеного ключа (див. визначення 2НФ). Дійсно, від частини складеного ключа залежать атрибути PNAME і PNUM, але вони самі є ключовими. Таким чином, відношення знаходиться в 2НФ.
Крім того, відношення не містить залежних друг від друга неключових атрибутів, тому що неключовий атрибут лише один - VOLUME (див. визначення 3НФ). Таким чином, показано, що відношення "Постачання" знаходиться в 3НФ.
Таким чином, описаний раніше алгоритм нормалізації не можна застосувати до даного відношення. Очевидно, однак, що аномалія даного відношення усувається шляхом декомпозиції його на два наступних відношення:
|
|
|
| Номер постачальника PNUM | Найменування постачальника PNAME |
| Фірма 1 | |
| Фірма 2 | |
| Фірма 3 |
Таблиця 2 Відношення "Постачальники"
| Номер постачальника PNUM | Номер деталі DNUM | Кількість, що поставляється VOLUME |
Таблиця 3 Відношення "Поставки-2"
Визначення 1. Відношення R знаходиться в нормальній формі Бойса-Кодда (НФБК) тоді і тільки тоді, коли детермінанти усіх функціональних залежностей є потенційними ключами.
Нагадаємо визначення детермінанту: детермінант – це довільний атрибут, від якого повністю функціонально залежить деякий інший атрибут
Зауваження. Якщо відношення знаходиться в НФБК, то воно автоматично знаходиться й у 3НФ. Дійсно, це відразу випливає з визначення 3НФ.
Ситуація, коли відношення буде знаходиться в 3нф (3NF), але не в НФБК (BCNF), виникає за умови, що відношення має два (чи більш) можливих ключі, що є складеними і мають спільний атрибут. Помітимо, що на практиці така ситуація зустрічається досить рідко, для всіх інших відносин 3NF і НФБК (BCNF) еквівалентні.
Відношення "Поставки" не знаходиться в НФБК, тому що є залежності (PNUM ® PNAME і PNAME ® PNUM), детермінанти яких не є потенційними ключами.
|
|
|
Для того щоб усунути залежність від детермінантів, що не є потенційними ключами, необхідно провести декомпозицію, виносячи ці детермінанти і залежні від них частини в окреме відношення. Відношення "Постачальники" і "Поставки-2", отримані в результаті декомпозиції знаходяться в НФБК.
Зауваження. Наведена декомпозиція відносини "Постачання" на відношення "Постачальники" і "Поставки-2" не є єдино можливою. Альтернативною декомпозицією є декомпозиція на наступні відношення:
| Номер постачальника PNUM | Найменування постачальника PNAME |
| Фірма 1 | |
| Фірма 2 | |
| Фірма 3 |
Таблиця 4 Відношення "Постачальники"
| Найменування постачальника PNAME | Номер деталі DNUM | Кількість, що поставляється VOLUME |
| Фірма 1 | ||
| Фірма 1 | ||
| Фірма 1 | ||
| Фірма 2 | ||
| Фірма 2 | ||
| Фірма 3 |
Таблиця 5 Відношення "Поставки-3"
На перший погляд, така декомпозиція гірше, ніж перша. Дійсно, найменування постачальників як і раніше повторюються, і при зміні найменування постачальника, це найменування доведеться змінювати одночасно в кількох місцях (тим більше відразу в двох відносинах!). Здається, що ситуація стала ще гірше, ніж була до декомпозиції. Однак таке відчуття виникає від того, що ми інтуїтивно вважаємо, що найменування постачальників можуть мінятися, а номера - ні. Якщо ж припустити, що номера постачальників теж можуть мінятися (чому б ні - директор наказав перенумерувати постачальників!), то перша декомпозиція виходить такою же "поганою" як і друга - повторювані номери доведеться змінювати одночасно в кількох місцях і також відразу в двох відношеннях.
|
|
|
Насправді ніякого протиріччя отут немає. У відношенні "Поставки-3" атрибут "Найменування постачальника" (PNAME) є зовнішнім ключем, що служить для зв'язку з відношенням "Постачальники". Тому, при зміні найменування постачальника, ця зміна здійснюється у відношенні "Постачальники" і каскадно (див. стратегії підтримки посилальної цілісності в гл. 3) поширюється на відношення "Постаки-3" зовсім так, як зміна номера постачальника каскадно поширюється на відношення "Поставки-2". Тому, формально обидві декомпозиції зовсім рівноправні. У реальній роботі розробник вибере, звичайно, першу декомпозицію, але отут важливо підкреслити, що його вибір заснований зовсім на інших міркуваннях, що не стосується формальної теорії нормальних форм.
Зауваження. Відношення "Поставки-2", отримане в результаті декомпозиції, має лише один потенційний ключ. Тому, для аналізу відношення "Поставки-2" не потрібно залучати визначення НФБК, досить визначення 3НФ. Хоча відношення "Постачальники" має два потенційних ключі, але, тому що інших атрибутів у ньому нема, воно вже так просто улаштовано, що спростити його далі не можна. Виникає питання, чи є нетривіальні приклади відношень у НФБК, що не знаходяться в 3НФ і не такі прості, як відношення "Постачальники"?
Приклад 2. Припустимо, що нам як і раніше необхідно обліковувати поставки, але кожний акт постачання повинний мати деякий унікальний номер (назвемо його "наскрізний номер поставки"). Відношення може мати наступний вигляд:
| Номер постачальника PNUM | Номер деталі DNUM | Кількість, що поставляється VOLUME | Наскрізний номер поставки NN |
Таблиця 6 Відношення "Поставки-з-номером"
Одним потенційним ключем даного відношення є, як і раніш, пари атрибутів { PNUM, DNUM }. Іншим ключем, у силу унікальності наскрізного номера, є атрибут NN. У даному відношенні є наступні функціональні залежності:
Залежність атрибутів від першого ключа відношення:
{ PNUM, DNUM } -> VOLUME,
{ PNUM, DNUM } -> NN,
Залежність атрибутів від другого ключа відношення:
NN -> PNUM,
NN -> DNUM,
NN -> VOLUME,
Залежності, що є наслідком залежностей від ключів відношення:
{ PNUM, DNUM } -> { VOLUME, NN },
NN -> { PNUM, DNUM },
NN -> { PNUM, VOLUME},
NN -> { DNUM, VOLUME},
Дата добавления: 2016-01-05; просмотров: 16; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!