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

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

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

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

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

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

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

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

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

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

Это было объяснение, которое 8-летний мог понять. Вот более техническая версия.

BCNF действует иначе, чем 3NF, только когда есть несколько перекрывающихся ключей-кандидатов.

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

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

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

Таким образом, чтобы решить эту проблему, мы берем Topping Type из таблицы Pizzas и делаем его неключевым атрибутом в таблице Toppings.

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

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

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

(а) X является суперключем для R, или

(б) А является ключевым атрибутом для R

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

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

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

BCNF, следовательно, более строгий.

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

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

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

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

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

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

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

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

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

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

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

Мы видим следующее различие в простых терминах:

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

в то время как

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

куда

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

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

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

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

Пример 3NF против BCNF

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

Сегодняшние заказы на теннисный корт ( 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

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

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

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

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

Ответы ' smartnut007 ', ' Bill Karwin ' и ' sqlvogel ' превосходны. Тем не менее, позвольте мне представить интересную перспективу.

Ну, у нас есть простые и не простые ключи.

Когда мы фокусируемся на том, как не простые числа зависят от простых чисел, мы видим два случая:

Непростые числа могут быть зависимыми или нет .

• При зависимости: мы видим, что они должны зависеть от полного ключа кандидата. Это 2NF .

• Когда не зависит: может быть отсутствие зависимости или транзитивная зависимость

  • Даже не транзитивная зависимость: не уверен, что теория нормализации решает эту проблему.
  • Когда транзитивно зависим: это считается нежелательным. Это 3NF .

Как насчет зависимостей между простыми числами?

Теперь вы видите, что мы не обращаемся к отношениям зависимости между простыми числами ни 2-й, ни 3-й NF. Кроме того, такая зависимость, если таковая имеется, нежелательна, и поэтому у нас есть одно правило для ее устранения. Это BCNF .

Обращаясь к примеру из поста Билла Карвина , вы заметите, что и Topping , и Topping Type являются простыми ключами и имеют зависимость. Если бы они не были простыми числами с зависимостью, тогда 3NF вступил бы в силу.

Примечание:

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

Расширенная тема: отображение общего BCNF на 2NF и 3NF

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

Во-первых, BCNF требует (кроме тривиального случая), что для каждой функциональной зависимости X -> Y(FD) X должен быть суперключом. Если вы просто рассмотрите любой FD, то у нас есть три случая - (1) оба X и Y не просты, (2) оба просты и (3) X просты и Y не просты, отбрасывая (бессмысленный) случай X не -прайм и Y премьер.

Для случая (1), 3NF заботится о.

Для случая (3) 2NF заботится о.

Для случая (2) мы находим использование BCNF

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