Різниця між 3NF та BCNF простими словами (повинна бути здатна пояснити 8-річному)


157

Я прочитав цитату: дані залежать від ключа [1NF], всього ключа [2NF] і нічого, крім ключа [3NF] .

Однак у мене виникають проблеми з розумінням 3.5NF або BCNF, як його називають. Ось що я розумію:

  • BCNF суворіший за 3NF
  • ліва сторона будь-якого FD у таблиці повинна бути супер-ключем (або принаймні ключем-кандидатом)

То чому ж тоді деякі таблиці 3NF не знаходяться в BCNF? Я маю на увазі, цитата 3NF прямо говорить «нічого, крім ключа», тобто всі атрибути залежать виключно від первинного ключа. Зрештою, первинний ключ - це кандидатський ключ, поки він не буде обраний для нас основним ключем.

Якщо що-небудь даремно стосується мого розуміння, будь ласка, виправте мене і дякую за будь-яку допомогу, яку ви можете надати.


Це настільки дивні настрої, що лише опублікований підручник може дати стислий, точний опис поняття. Якщо ви подивитесь на відповіді на це (справді старе) питання, то побачите, що жоден із високо оцінених неясний чи неточний. Не було алгебраїчного визначення, проблема не була, розуміння концепції на прикладі реального світу було. Що стосується цитати в моєму первісному запитанні, google "так допоможіть мені Кодд", щоб знайти походження цитат. У цьому немає нічого неясного.
Арнаб Датта

1
Тільки де ви думаєте, з яких джерел не підручники отримують свою інформацію? Існує також багато бідних підручників, але підручники переглядаються багатьма людьми з академічним стажуванням, і набагато більше шансів на те, що це не дурниці, ніж інтерпретації підручників інших. Високі рейтинги неінформованих та дезінформованих людей не роблять щось правильне. Я розміщую там цей коментар для людей, які прийшли на ваше запитання. Ця фраза, окрім ключових, є менш марною. Правильне визначення, безумовно, полягає в тому, що без розуміння поняття "неможливо".
філіппі

Відповіді:


162

Ваша піца може містити рівно три сорти:

  • один вид сиру
  • один вид м’яса
  • один вид овочів

Тому ми замовляємо дві піци і вибираємо наступні начинки:

Pizza    Topping     Topping Type
-------- ----------  -------------
1        mozzarella  cheese
1        pepperoni   meat
1        olives      vegetable
2        mozzarella  meat
2        sausage     cheese
2        peppers     vegetable

Зачекайте секунду, моцарелла не може бути і сиром, і м'ясом! І ковбаса - це не сир!

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

Pizza    Topping
-------- ----------
1        mozzarella
1        pepperoni
1        olives
2        mozzarella 
2        sausage
2        peppers

Topping     Topping Type
----------  -------------
mozzarella  cheese
pepperoni   meat
olives      vegetable
sausage     meat
peppers     vegetable

Це було пояснення, яке може зрозуміти восьмирічний. Ось більш технічна версія.

BCNF діє по-різному від 3NF лише тоді, коли є кілька перекриваються кандидатських ключів.

Причина полягає в тому, що функціональна залежність X -> Y, звичайно, вірна, якщо Yце підмножина X. Отже, у будь-якій таблиці, що має лише один кандидат-ключ і знаходиться в 3NF, він вже є в BCNF, оскільки немає колонки (ні ключа, ні ключа), яка функціонально залежить від будь-якого, крім цього ключа.

Оскільки кожна піца повинна мати саме один тип кожного відливу, ми знаємо, що (Pizza, Topping Type) є ключовим кандидатом. Ми також інтуїтивно знаємо, що дане додавання одночасно не може належати до різних типів. Тож (Піца, Топінг) має бути унікальним, а тому є і ключовим кандидатом. Таким чином, у нас є два перекриваються ключі кандидата.

Я показав аномалію, де ми позначили моцарелу неправильним типом. Ми знаємо, що це неправильно, але правило, яке робить його неправильним, це залежність, Topping -> Topping Typeяка не є дійсною залежністю для BCNF для цієї таблиці. Це залежність від чогось іншого, ніж цілий ключ-кандидат.

Отже, щоб вирішити це, ми витягуємо Topping Type з таблиці Pizzas і робимо його не ключовим атрибутом у таблиці Toppings.


3
"Це залежність від чогось іншого, ніж цілого ключа кандидата". - Дякую
gnsb

12
"Так що в будь-якій таблиці, яка має лише один кандидатський ключ і знаходиться в 3NF" - Не зовсім. Приклад, який ви наводите, відповідає цій умові. Однак це не приклад 3NF, оскільки це не 2NF. Ключ (1NF), весь ключ (2NF) і нічого, крім ключа (3NF). Ключ (Pizza, Topping), і стовпець ToppingType залежить від ключа і нічого, крім ключа, але він не залежить від усього ключа. Отже, це не 2NF, а значить, не 3NF або BCNF. Це 1NF. Створення 2NF обмине проблему, яку ви намагаєтесь проілюструвати.
Даніель Барбалас

4
@DanielBarbalace, Суть цієї таблиці полягає в тому, що в ній є альтернативний ключ кандидата для цієї таблиці: (Піца, ToppingType). Оскільки ToppingType є підмножиною цього ключа-кандидата, він задовольняє 2NF.
Білл Карвін

6
Вибачте, що мені довелося його зняти. Приклад, який ви показали, не в 3NF. Щоб зрозуміти мету BCNF, я повинен побачити приклад, де він знаходиться в 3NF, але не в BCNF. Зараз я не бачу мети BCNF.
Сперо

5
Чому це вже не обробляється в 2NF? З моєї точки зору, первинним ключем оригінальної таблиці є Піца + Топінг, а Тип Топінгу залежить від Топінгу, тож чи не часткова залежність, про яку слід подбати на етапі 2NF?
GreenPenguin

91

Тонка відмінність полягає в тому, що 3NF розрізняє ключові та не ключові атрибути (їх також називають атрибутами, що не є простими ), тоді як BCNF - ні.

Це найкраще пояснити, використовуючи визначення Заніоло 3NF, яке еквівалентно Кодду:

Відношення, R, є в 3NF iff для кожного нетривіального FD (X-> A), задоволеного R принаймні ОДНІМ з наступних умов, є правдою:

(a) X - це суперлюдина для R, або

(b) A - ключовий атрибут для R

BCNF вимагає (a), але не розглядає (b) як окремий випадок. Іншими словами, BCNF вимагає, щоб кожна нетривіальна детермінанта була надвисокою, навіть її залежні атрибути є частиною ключа.

Відношення, R, є у BCNF iff для кожного нетривіального FD (X-> A), задоволеного R, справедливо таке умова:

(a) X - це суперквітка для R

Тому BCNF є більш суворим.

Різниця настільки тонка, що те, що багато людей неофіційно описують як 3NF, насправді є BCNF. Наприклад, ви заявили тут, що 3NF означає "дані залежать від ключа [s] ... і нічого, крім ключа [s]", але це дійсно неофіційний опис BCNF, а не 3NF. 3NF можна було б більш точно описати як " неклавішні дані залежать від клавіш ... і нічого, крім клавіш".

Ви також заявили:

цитата 3NF прямо говорить "нічого, крім ключа", тобто всі атрибути залежать виключно від первинного ключа.

Це надмірне спрощення. 3NF та BCNF та всі Нормальні форми стосуються всіх кандидатських ключів та / або супер- ключів, а не лише одного "первинного" ключа.


7
Ого. Професор Заніоло насправді викладає мій клас (CS 143, UCLA), і я натрапив на цю відповідь, готуючись до випускного іспиту. Чудово бачити ім'я мого професора, і дякую за детальну відповідь!
DV.

Ви можете навести приклад відношення, яке знаходиться в 3NF, але не в BCNF? мені важко уявити ...
Лев

10
R {A, B, C}, де {A, B} - ключ. Враховуючи залежність C-> B, R задовольняє вимогам 3NF, але не BCNF.
nvogel

2
Ключ означає ключ кандидата. Ключовий атрибут означає атрибут, який є частиною кандидата, AKA - основний атрибут .
nvogel

3
Атрибут є простим, якщо він є частиною будь-якого ключа-кандидата; непримітна, якщо вона не є частиною будь-якого ключа-кандидата.
nvogel

26

Різниця між BCNF та 3NF

Використання визначення BCNF

Якщо і тільки якщо для кожної з її залежностей X → Y, принаймні одна з таких умов виконується :

  • X → Y - тривіальна функціональна залежність (Y ⊆ X), або
  • X - це супер ключ для схеми R

та визначення 3NF

Якщо і лише тоді, коли для кожної з її функціональних залежностей X → A виконується принаймні одна з таких умов:

  • X містить A (тобто X → A - тривіальна функціональна залежність), або
  • X - це суперлюдина, або
  • Кожен елемент AX, задана різниця між A і X, є основним атрибутом (тобто кожен атрибут в AX міститься в якомусь ключі-кандидата)

Ми бачимо таку різницю простими словами:

  • У BCNF : Кожен частковий ключ (основний атрибут) може залежати лише від супер ключа ,

тоді як

  • У 3NF : Частковий ключ (основний атрибут) також може залежати від атрибута, який не є надключовим ключем (тобто іншого атрибута часткового ключа / проста чи навіть атрибута, який не є простим).

Де

  1. Простий атрибут - це атрибут, знайдений у ключовому ключі та
  2. А Ключ кандидат є мінімальним суперключ для цього відносини, і
  3. Суперключ являє собою набір атрибутів змінних відносин , для яких вона вважає , що в усіх відношеннях , привласнених цього змінний, немає два різних кортежів (рядків) , які мають однакові значення атрибутів в цьому set.Equivalently суперключ може також визначається як набір атрибутів схеми відношень, від яких функціонально залежать усі атрибути схеми. (Супер ключ завжди містить ключ-кандидат / кандидат-ключ - це завжди підмножина супер-ключа. Ви можете додати будь-який атрибут у відношенні, щоб отримати один із супер-ключів.)

Тобто, жоден частковий підмножина (будь-яке нетривіальне підмножина, крім повного набору) ключа-кандидата не може бути функціонально залежним від будь-якого, крім супер-ключа.

Таблиця / співвідношення, що не знаходиться в BCNF, піддається таким аномаліям, як аномалії оновлення, згадані у прикладі піци іншим користувачем. На жаль,

  • ЦНБФ НЕ завжди виходить , в той час як
  • Завжди можна отримати 3NF .

Приклад 3NF проти BCNF

Приклад різниці на даний момент можна знайти на " таблиці 3NF, що не відповідає BCNF (нормальна форма Бойса-Кодда) " у Вікіпедії, де в наступній таблиці зустрічається 3NF, але не BCNF, оскільки "Тенісний корт" (частковий ключ / основний атрибут) залежить на "Тип тарифу" (частковий атрибут "ключ" / "prime", який не є надключовим ключем ), що є залежністю, яку ми могли б визначити, запитуючи клієнтів бази даних, тенісний клуб:

Сьогоднішні бронювання тенісних кортів ( 3NF , а не BCNF )

Court   Start Time  End Time    Rate Type
------- ----------  --------    ---------
1       09:30       10:30       SAVER
1       11:00       12:00       SAVER
1       14:00       15:30       STANDARD
2       10:00       11:30       PREMIUM-B
2       11:30       13:30       PREMIUM-B
2       15:00       16:30       PREMIUM-A

Клавіші таблиці:

S1 = {Court, Start Time}
S2 = {Court, End Time}
S3 = {Rate Type, Start Time}
S4 = {Rate Type, End Time}
S5 = {Court, Start Time, End Time}
S6 = {Rate Type, Start Time, End Time}
S7 = {Court, Rate Type, Start Time}
S8 = {Court, Rate Type, End Time}
ST = {Court, Rate Type, Start Time, End Time}, the trivial superkey

Проблема 3NF : Частковий атрибут "key" / prime "Court" залежить від чогось іншого, ніж надбудова. Натомість це залежить від часткового атрибута key / prime "Тип тарифу". Це означає, що користувач повинен змінити тип тарифу вручну, якщо ми оновимо суд, або вручну змінити суд, якщо хоче застосувати зміну ставки.

  • Але що робити, якщо користувач модернізує суд, але не пам’ятає про підвищення тарифу? Або що робити, якщо неправильний тип ставки застосовується до суду?

(У технічному плані ми не можемо гарантувати, що функціональна залежність "Тип ставки" -> "Суд" не буде порушена.)

Розчин BCNF : Якщо ми хочемо розмістити вищевказану таблицю в BCNF, ми можемо розкласти дане співвідношення / таблицю на наступні два відносини / таблиці (якщо припустимо, що ми знаємо, що тип ставки залежить тільки від статусу суду та членства, який ми могли б дізнайтеся, запитавши клієнтів нашої бази даних, власників тенісного клубу):

Типи ставок ( BCNF і слабший 3NF, що мається на увазі під BCNF)

Rate Type   Court   Member Flag
---------   -----   -----------
SAVER       1       Yes
STANDARD    1       No
PREMIUM-A   2       Yes
PREMIUM-B   2       No

Сьогоднішні бронювання тенісних кортів ( BCNF та слабкіший 3NF, на які мається на увазі BCNF)

Member Flag     Court     Start Time   End Time
-----------     -----     ----------   --------
Yes             1         09:30        10:30
Yes             1         11:00        12:00
No              1         14:00        15:30
No              2         10:00        11:30
No              2         11:30        13:30
Yes             2         15:00        16:30

Проблема вирішена : Якщо ми модернізуємо суд, ми можемо гарантувати, що тип ставки відобразить цю зміну, і ми не можемо стягувати неправильну ціну за суд.

(У технічному плані ми можемо гарантувати, що функціональна залежність "Тип ставки" -> "Суд" не буде порушена.)


6

Усі хороші відповіді. Якщо говорити простою мовою [BCNF] Жоден частковий ключ не може залежати від ключа.

тобто жоден частковий підмножина (тобто будь-яке нетривіальне підмножина, крім повного набору) ключа-кандидата не може бути функціонально залежним від певного ключа-кандидата.


2
Чому ні? Скажімо, є відношення R (A, B, C, D, E) і (A, B) і (C, D) - ключові слова кандидата. Тоді AB-> D. Оскільки AB - це супервивірка R, то R має бути в BCNF, правда? (Просто запитання, намагаючись зрозуміти це.)
peteykun

3

Відповіді " smartnut007 ", " Білла Карвіна " та " sqlvogel " - чудові. Але дозвольте мені поставити цікаву перспективу.

Ну, у нас є прості та непрості ключі.

Коли ми зосередимось на тому, як залежать від простих праймес, ми бачимо два випадки:

Непрості можуть бути залежними чи ні .

  • Залежно: ми бачимо, що вони повинні залежати від повного ключа кандидата. Це 2NF .
  • Якщо не залежить: не може бути залежності або перехідна залежність

    • Навіть не перехідна залежність: Не впевнений, яка теорія нормалізації вирішує це.
    • Коли є транзитивно залежними: Це вважається небажаним. Це 3NF .

А як щодо залежності серед простих?

Тепер ви бачите, що ми не вирішуємо залежність між праймерами ні 2-м, ні 3-м НФ. Далі така залежність, якщо така є, небажана, і тому ми маємо єдине правило, щоб її вирішити. Це BCNF .

Посилаючись на приклад з публікації Білла Карвіна тут, ви помітите, що і " Топінг ", і " Тип відливу " є простими ключами і мають залежність. Якби вони не були простими людьми із залежністю, то 3NF би запустив.

Примітка:

Визначення BCNF є дуже загальним і без розмежування атрибутів між простим і не простим. Тим не менш, вищевказаний спосіб мислення допомагає зрозуміти, як деяка аномалія переживається навіть після 2-го та 3-го НФ.

Розширена тема: Картографування загальних BCNF до 2NF та 3NF

Тепер, коли ми знаємо, що BCNF надає загальне визначення без посилання на атрибути прості / непрості, давайте подивимося, як пов'язані BCNF та 2/3 NF.

По-перше, BCNF вимагає (за винятком тривіального випадку), що для кожної функціональної залежності X -> Y(FD) X має бути надключовим. Якщо ви просто враховуєте будь-який FD, то у нас є три випадки - (1) І X і Y непрості, (2) Обидва простих і (3) X простих і Y непрості, відкидаючи (безглуздий) випадок X не -prime і Y prime.

Для випадку (1) опікується 3NF.

Для випадку (3) опікується 2NF.

Для випадку (2) ми знаходимо використання BCNF


3

Це старе запитання з цінними відповідями, але я все ще трохи розгубився, поки не знайшов приклад реального життя, який показує проблему з 3NF. Можливо, не підходить для 8-річної дитини, але сподіваюся, що це допоможе.

Завтра я зустрінусь із вчителями моєї старшої дочки на одній із таких щоквартальних зборів батьків / вчителів. Ось як виглядає мій щоденник (змінилися імена та номери):

Teacher   | Date             | Room
----------|------------------|-----
Mr Smith  | 2018-12-18 18:15 | A12 
Mr Jones  | 2018-12-18 18:30 | B10 
Ms Doe    | 2018-12-18 18:45 | C21 
Ms Rogers | 2018-12-18 19:00 | A08 

У кімнаті є лише один вчитель, і вони ніколи не рухаються. Якщо ви подивіться, ви побачите , що: (1) для кожного атрибута Teacher, Date, Room, у нас є тільки одне значення для кожного рядка. (2) супер-клавіші: (Teacher, Date, Room), (Teacher, Date)а (Date, Room)клавіші і кандидати, очевидно , (Teacher, Date)і (Date, Room).

(Teacher, Room) це не суперкілька, тому що я заповнять таблицю в наступному кварталі, і, можливо, у мене буде такий ряд, як цей (містер Сміт не рухався!):

Teacher  | Date             | Room
---------|------------------| ----
Mr Smith | 2019-03-19 18:15 | A12

Що можемо зробити висновок? (1) - це неофіційна, але правильна формулювання 1NF. З (2) ми бачимо, що немає "атрибуту, який не є простим": 2NF і 3NF даються безкоштовно.

Мій щоденник - 3NF. Добре! Ні. Насправді не тому, що жоден модельєр даних не прийняв би це у схемі БД. RoomАтрибут залежить від Teacherатрибута (знову ж : вчителі не рухатися!) , Але схема не відображає цей факт. Що б зробив здоровий модельєр даних? Розділіть таблицю на два:

Teacher   | Date
----------|-----------------
Mr Smith  | 2018-12-18 18:15
Mr Jones  | 2018-12-18 18:30
Ms Doe    | 2018-12-18 18:45
Ms Rogers | 2018-12-18 19:00

І

Teacher   | Room
----------|-----
Mr Smith  | A12
Mr Jones  | B10
Ms Doe    | C21
Ms Rogers | A08

Але 3NF не має відношення до основних атрибутивних залежностей. У цьому полягає проблема: відповідність 3NF недостатня для забезпечення розробки схеми обгрунтованої таблиці за певних обставин.

З BCNF вам не байдуже, чи атрибут є основним атрибутом чи ні в правилах 2NF та 3NF. Для кожної нетривіальної залежності (підмножини, очевидно, визначаються їх наборами), визначальним фактором є повний супер ключ. Іншими словами, ніщо не визначається чимось іншим, ніж повний супер ключ (за винятком тривіальних FD). (Див. Інші відповіді для формального визначення).

Як тільки це Roomзалежить Teacher, Roomповинно бути підмножина Teacher(це не так) або Teacherмає бути супер-ключ (це не так у моєму щоденнику, але такий випадок, коли ви розділите таблицю).

Підводячи підсумок: BNCF є більш суворим, але, на мій погляд, легше зрозуміти, ніж 3NF:

  • у більшості випадків BCNF ідентичний 3NF;
  • в інших випадках BCNF - це те, на що ви думаєте / сподіваєтесь, що це 3NF.
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.