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

Ответ 1

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

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

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

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) является ключом-кандидатом. Мы также интуитивно знаем, что данная вершина не может принадлежать к разным типам одновременно. Таким образом (пицца, топпинг) должны быть уникальными и, следовательно, также являться кандидатом. Таким образом, у нас есть два совпадающих ключа-кандидата.

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

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

Ответ 2

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

Это лучше всего объяснить с помощью определения Zaniolo 3NF, что эквивалентно Codd's:

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

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

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

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

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

(a) X является суперклеером для R

BCNF является более строгим.

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

Вы также указали:

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

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

Ответ 3

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

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

Таблица/отношение, отсутствующее в 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

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

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

Ответ 4

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

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

Ответ 5

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

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

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

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

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

• Если не зависит: не может быть зависимой или транзитивной зависимости

  • Даже не транзитивная зависимость: Не знаете, к какой теории нормализации это относится.
  • При транзитивной зависимости: Это считается нежелательным. Это 3NF.

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

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

Обращаясь к примеру из статьи Bill Karwin, вы заметите, что оба типа "Topping" и "Topping Type" являются основными ключами и имеют зависимость. Если бы они были несимметриями с зависимостью, тогда 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

Ответ 6

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