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

157

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

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

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

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

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

Арнаб Датта
источник
Это настолько странное чувство, что только опубликованный учебник может дать краткое и точное описание концепции. Если вы посмотрите на ответы на этот (действительно старый) вопрос, то увидите, что ни один из высоко оцененных вопросов не является неопределенным или неточным. Наличие алгебраического определения не было проблемой, понимание концепции на реальных примерах было. Что касается цитаты в моем первоначальном вопросе, Google "так помогите мне Codd", чтобы найти источник цитат. В этом нет ничего смутного.
Арнаб Датта
1
Как вы думаете, откуда источники информации, не относящиеся к учебникам, получают информацию? Существует также много плохих учебников, но учебники рассматриваются многими людьми, имеющими академическое образование, и они с гораздо большей вероятностью будут не глупыми, чем другие толкования учебников. Высокие оценки неинформированных и дезинформированных людей не делают что-то правильное. Я разместил этот комментарий для людей, которые пришли на ваш вопрос. Эта фраза «не что иное, как ключ» не имеет смысла. Правильное определение, безусловно, является проблемой, потому что «понимание концепции» невозможно без нее.
Philipxy

Ответы:

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

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

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

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

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

Я показал аномалию, где мы отметили моцареллу как неправильный тип топпинга. Мы знаем, что это неправильно, но правило, которое делает это неправильно, является зависимостью, 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, смысл этой таблицы в том, что у нее есть альтернативный ключ-кандидат для этой таблицы: (Pizza, ToppingType). Поскольку ToppingType является подмножеством этого ключа-кандидата, он удовлетворяет 2NF.
Билл Карвин
6
Извините, что пришлось понизить это. Пример, который вы показали, не в 3NF. Чтобы понять цель BCNF, я должен увидеть пример, где он находится в 3NF, но не в BCNF. Прямо сейчас я не вижу цели BCNF.
Spero
5
Почему это НЕ обрабатывается в 2NF уже? С моей точки зрения, первичным ключом исходной таблицы является Pizza + Topping, а тип Topping зависит от Topping, так не является ли это частичной зависимостью, о которой следует позаботиться на этапе 2NF?
GreenPenguin
91

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

nvogel
источник
7
Вот это да. Профессор Заниоло фактически преподает мой класс (CS 143, UCLA), и я наткнулся на этот ответ, готовясь к заключительному экзамену. Приятно видеть имя моего профессора, и спасибо за подробный ответ!
Д.В.
Не могли бы вы привести пример отношения, которое находится в 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 - тривиальная функциональная зависимость), или
  • Х это суперключ, или
  • Каждый элемент 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

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

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

AGéoCoder
источник
6

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

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

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

Ответы ' 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

KGhatak
источник
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.
jferard
источник