Разница между 3NF и BCNF простыми словами (нужно уметь объяснить 8-летнему ребенку)

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

Однако у меня возникли проблемы с пониманием 3.5NF или BCNF, как они называются. Вот что я понимаю:

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

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

Если что-то не так с моим пониманием, пожалуйста, поправьте меня и поблагодарите за любую помощь, которую вы можете предоставить.


person Arnab Datta    schedule 08.12.2011    source источник
comment
Это настолько странное мнение, что только опубликованный учебник может дать краткое и точное описание концепции. Если вы посмотрите ответы на этот (действительно старый) вопрос, вы увидите, что ни один из высоко оцененных вопросов не является расплывчатым или неточным. Проблема не в алгебраическом определении, а в понимании концепции на реальных примерах. Что касается цитаты в моем исходном вопросе, Google, так что помогите мне, Кодд, найти источник цитат. В этом нет ничего расплывчатого.   -  person Arnab Datta    schedule 18.12.2018
comment
Откуда, по вашему мнению, источники, не относящиеся к учебникам, берут информацию? Есть также много плохих учебников, но учебники рецензируются несколькими людьми, имеющими академическое образование, и гораздо более вероятно, что это не ерунда, чем другие интерпретации учебников. Высокие оценки неосведомленных и дезинформированных людей не делают что-то правильным. Я оставил этот комментарий для людей, которые пришли к вашему вопросу. Ничего, кроме ключевой фразы, бесполезно. Конечно, важно иметь правильное определение, потому что без него понимание концепции невозможно.   -  person philipxy    schedule 18.12.2018


Ответы (5)


В вашей пицце может быть ровно три вида начинки:

  • один вид сыра
  • один вид мяса
  • один вид овощей

Итак, заказываем две пиццы и выбираем следующие начинки:

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, потому что нет столбца (ни ключевого, ни неключевого), который функционально зависит от чего-либо, кроме этого ключа.

Поскольку в каждой пицце должно быть ровно по одному топпингу каждого типа, мы знаем, что (Пицца, Тип топпинга) - это ключ-кандидат. Мы также интуитивно знаем, что данный топпинг не может одновременно принадлежать к разным типам. Таким образом, (Пицца, Топпинг) должна быть уникальной и, следовательно, также может быть ключом-кандидатом. Итак, у нас есть два перекрывающихся ключа-кандидата.

Я показал аномалию, когда мы пометили моцареллу как неправильный тип начинки. Мы знаем, что это неправильно, но правило, которое делает это неправильным, - это зависимость Topping -> Topping Type, которая не является допустимой зависимостью для BCNF для этой таблицы. Это зависимость от чего-то другого, а не от целого ключа кандидата.

Чтобы решить эту проблему, мы извлекаем тип топпинга из таблицы «Пицца» и делаем его неключевым атрибутом в таблице «топпинг».

person Bill Karwin    schedule 08.12.2011
comment
Это зависимость от чего-то другого, а не от целого ключа кандидата. - Спасибо - person gnsb; 15.12.2016
comment
Таким образом, в любой таблице, имеющей только один ключ-кандидат и находящейся в 3NF - не совсем. Приведенный вами пример соответствует этому условию. Однако это не пример 3NF, потому что это не 2NF. Ключ (1NF), весь ключ (2NF) и ничего, кроме ключа (3NF). Ключ - (Pizza, Topping), а столбец ToppingType зависит от ключа и ничего, кроме ключа, но не зависит от всего ключа. Следовательно, это не 2NF и, следовательно, не 3NF или BCNF. Это 1НФ. Создание 2NF позволит обойти проблему, которую вы пытаетесь проиллюстрировать. - person Daniel Barbalace; 21.02.2017
comment
@DanielBarbalace, суть этой таблицы в том, что у нее есть альтернативный ключ-кандидат для этой таблицы: (Pizza, ToppingType). Поскольку ToppingType является подмножеством этого ключа-кандидата, он удовлетворяет 2NF. - person Bill Karwin; 22.02.2017
comment
Извините, мне пришлось проголосовать против. Пример, который вы показали, не относится к 3NF. Чтобы понять назначение BCNF, я должен увидеть пример, где он находится в 3NF, но не в i BCNF. Прямо сейчас я не вижу цели BCNF. - person Spero; 28.01.2018
comment
Почему это НЕ обрабатывается в 2NF? С моей точки зрения, первичным ключом исходной таблицы является Pizza + Topping, а Topping Type зависит от Topping, так что разве это не частичная зависимость, о которой следует позаботиться на этапе 2NF? - person GreenPenguin; 05.03.2018
comment
@DanielBarbalace Нарушение 2NF можно охарактеризовать как случай, когда CK частично определяет атрибут non-prime (он же не-CK). Но здесь все атрибуты первостепенны. Так что нарушения 2NF быть не может. Также вы не цитируете определения 1NF, 2NF или 3NF - если вы не знаете. - person philipxy; 18.12.2018
comment
В примере с пиццей, разве разложение не снимает ограничение, согласно которому в каждой пицце может быть только одна начинка каждого типа? Теперь в одной пицце может быть более одной начинки одного типа. Хотя это в BCNF. Похоже на этот пример, но с другими столбцами порядок. - person Ruben9922; 26.04.2019
comment
Это правда, что BCNF действует иначе, чем 3NF, только когда есть несколько перекрывающихся ключей-кандидатов. Но это бесполезно для характеристики BCNF, 3NF-но-не-BCNF или 3NF по сравнению с BCNF. 3NF + перекрывающиеся CK - это условие между 3NF и BCNF - это необходимо, но недостаточно для BCNF и не препятствует 3NF-но-не-BCNF. Вы не можете четко охарактеризовать 3NF и BCNF. Утверждения и доводы следующего абзаца также не ясны. (Ваши презентации о НФ часто нечеткие.) (Как и большинство.) PS (Пицца, Тип топпинга) - кандидат, которому противоречит ключ (Пицца, Топпинг) должен быть уникальным. - person philipxy; 08.04.2020
comment
@philipxy Я не понимаю (Pizza, Topping Type) - кандидат, которому противоречит ключ (Pizza, Topping), должен быть уникальным. Они оба СК, поэтому оба уникальны. - person iBug; 17.05.2021
comment
@iBug Это PS неправильно, и я не знаю, пытался ли я сказать что-то еще. Я подозреваю, что принял (Пицца, Тип топпинга) за (Пицца, Топпинг, Тип Топпинга). - person philipxy; 17.05.2021
comment
@gnsb К сожалению, эта цитата неверна. Он должен быть на чем-то отличном от расширенного набора CK, а не только на целом CK. - person philipxy; 17.05.2021

Тонкое различие состоит в том, что 3NF делает различие между ключевыми и неключевыми атрибутами (также называемыми неосновными атрибутами), тогда как BCNF этого не делает.

Лучше всего это объяснить, используя определение 3NF, данное Заниоло, которое эквивалентно Кодда:

Отношение R находится в 3NF тогда и только тогда, когда для каждого нетривиального FD (X-> A), удовлетворяющего R, выполняется хотя бы ОДНО из следующих условий:

(а) X - это супер-ключ для R, или

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

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

Отношение R находится в BCNF тогда и только тогда, когда для любого нетривиального FD (X-> A), удовлетворяющего R, выполняется следующее условие:

(а) X - суперключ для R

Таким образом, BCNF более строгий.

Разница настолько тонкая, что то, что многие люди неофициально называют 3NF, на самом деле является BCNF. Например, вы заявили здесь, что 3NF означает «данные зависят от ключа [ключей] ... и ничего, кроме ключа [ключей]», но на самом деле это неформальное описание BCNF, а не 3NF. 3NF можно было бы более точно описать как «неключевые данные зависят от ключей ... и ничего, кроме ключей».

Вы также заявили:

цитата 3NF явно говорит «ничего, кроме ключа», что означает, что все атрибуты зависят исключительно от первичного ключа.

Это чрезмерное упрощение. 3NF, BCNF и все нормальные формы связаны со всеми ключами-кандидатами и / или суперключами, а не только с одним «первичным» ключом.

person nvogel    schedule 09.12.2011
comment
Вот это да. Профессор Дзаниоло на самом деле ведет мой класс (CS 143, UCLA), и я наткнулся на этот ответ, когда готовился к выпускному экзамену. Приятно видеть имя моего профессора и спасибо за подробный ответ! - person DV.; 10.12.2012
comment
не могли бы вы привести пример отношения, которое есть в 3NF, но не в BCNF? мне сложно представить ... - person Leo; 09.06.2013
comment
R {A, B, C}, где {A, B} - ключ. Учитывая зависимость C- ›B, R удовлетворяет требованиям 3NF, но не BCNF. - person nvogel; 09.06.2013
comment
Что именно означает ключ, когда он используется в определении? Это просто первичный ключ, любой из ключей-кандидатов или все ключи-кандидаты? - person user; 25.02.2016
comment
Ключ означает ключ-кандидат. Ключ attribute означает атрибут, который является частью ключа-кандидата, также известный как главный атрибут. - person nvogel; 25.02.2016
comment
Что означает основной (или неосновной) атрибут? - person ; 30.06.2016
comment
Атрибут является первичным, если он является частью любого ключа-кандидата; непростое, если оно не входит ни в один из возможных ключей. - person nvogel; 30.06.2016
comment
Это определение не имеет смысла, когда вы рассматриваете наборы атрибутов. Означает ли ключевой атрибут набор, состоящий только из ключевых атрибутов? - person AleksandrH; 04.11.2019
comment
@AleksandrH Атрибут, который является элементом CK, называется ключевым атрибутом или основным атрибутом. Таким образом, ключевой атрибут обычно означает атрибут, который является элементом СК. Заниоло определяет X- ›A как обозначение X -› {A}. Также, когда мы говорим о наборе атрибутов с одним элементом, мы небрежно используем атрибут для обозначения набора атрибутов. Таким образом, ключевой атрибут может означать набор атрибутов, который является CK и имеет ровно один атрибут. Но этот ответ не касается мощности CK, поэтому он не использует его в этом смысле. - person philipxy; 08.04.2020

Разница между BCNF и 3NF

Использование определения BCNF

Если и только если для каждой из его зависимостей X → Y выполняется хотя бы одно из следующих условий:

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

и определение 3NF

Если и только если для каждой из его функциональных зависимостей X → A выполняется хотя бы одно из следующих условий:

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

Проще говоря, мы видим следующую разницу:

  • В BCNF: каждый частичный ключ (основной атрибут) может только зависеть от суперключа,

в то время как

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

Где

  1. первичный атрибут - это атрибут, найденный в потенциальном ключе, и
  2. ключ-кандидат - это минимальный суперключ для этого отношения, и
  3. суперключ - это набор атрибутов переменной отношения, для которой он утверждает, что во всех отношениях, присвоенных этой переменной, нет двух отдельных кортежей (строк), которые имеют одинаковые значения для атрибутов в этом наборе. Эквивалентно суперключ также может быть определен как набор атрибутов схемы отношения, на которой все атрибуты схемы функционально зависимы. (Суперключ всегда содержит ключ-кандидат / ключ-кандидат всегда является подмножеством суперключа. Вы можете добавить любой атрибут в отношение, чтобы получить один из суперключей.)

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

Таблица / отношение, не входящие в BCNF, подвержены аномалиям, таким как аномалии обновления, упомянутые в примере с пиццей другим пользователем. К несчастью,

  • BNCF не всегда может быть получен, в то время как
  • всегда можно получить.

Пример 3NF и BCNF

Пример различия в настоящее время можно найти в "Таблица 3NF не соответствует BCNF (Boyce– Нормальная форма Кодда) "в Википедии, где следующая таблица соответствует 3NF, но не BCNF, потому что" Теннисный корт "(частичный ключевой / главный атрибут) зависит от" Типа ставки "(частичный ключевой / главный атрибут, который < em> not суперключ), что является зависимостью, которую мы могли бы определить, спросив клиентов базы данных, теннисный клуб:

Сегодняшние заказы на теннисные корты (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: частичный ключ / главный атрибут «Суд» зависит от чего-то другого, кроме суперключа. Вместо этого он зависит от частичного ключевого / основного атрибута «Тип скорости». Это означает, что пользователь должен вручную изменить тип ставки, если мы обновляем корт, или вручную изменить корт, если он хочет применить изменение ставки.

  • Но что, если пользователь обновил корт, но не забыл увеличить скорость? Или что, если в суд применяется неправильный тип ставки?

(С технической точки зрения мы не можем гарантировать, что функциональная зависимость «Тип ставки» -> «Суд» не будет нарушена.)

Решение 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

Проблема решена. Теперь, если мы обновим суд, мы можем гарантировать, что тип ставки будет отражать это изменение, и мы не сможем назначить неправильную цену за суд.

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

person AGéoCoder    schedule 27.10.2015

Все хорошие ответы. Выражаясь простым языком [BCNF] Никакой частичный ключ не может зависеть от ключа.

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

person smartnut007    schedule 13.02.2013
comment
Почему нет? Допустим, есть отношение R (A, B, C, D, E), а (A, B) и (C, D) - ключи-кандидаты. Тогда AB- ›D. Поскольку AB является суперключом R, значит, R должен быть в BCNF, верно? (Просто вопрос, пытаюсь понять это.) - person peteykun; 13.05.2014

Это старый вопрос с ценными ответами, но я все еще был немного сбит с толку, пока не нашел реальный пример, показывающий проблему с 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.
person jferard    schedule 17.12.2018