Разница между 3NF и BCNF в простых терминах (должна быть в состоянии объяснить 8-летнему ребенку)
Я прочитал цитату:данные зависят от ключа [1NF], всего ключа [2NF] и только от ключа [3NF].
Однако у меня возникают проблемы с пониманием 3.5NF или BCNF, как они называются. Вот что я понимаю:
- BCNF является более строгим, чем 3NF
- Левая сторона любого FD в таблице должна быть суперключом (или, по крайней мере, ключом-кандидатом)
Так почему же тогда некоторые таблицы 3NF отсутствуют в BCNF? Я имею в виду, что цитата 3NF явно говорит "ничего, кроме ключа", что означает, что все атрибуты зависят исключительно от первичного ключа. В конце концов, первичный ключ - это ключ-кандидат, пока он не будет выбран в качестве нашего первичного ключа.
Если что-то не так с моим пониманием, пожалуйста, поправьте меня и спасибо за любую помощь, которую вы можете оказать.
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
Это было объяснение, которое 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: частичный ключ (первичный атрибут) также может зависеть от атрибута, который не является суперключем (то есть другой частичный ключ / первичный атрибут или даже непростой атрибут).
куда
- Основной атрибут - это атрибут, найденный в ключе-кандидате, и
- Ключ-кандидат - это минимальный суперключ для этого отношения, и
- Суперключ - это набор атрибутов переменной отношения, для которого он считает, что во всех отношениях, назначенных этой переменной, нет двух разных кортежей (строк), которые имеют одинаковые значения для атрибутов в этом наборе. Эквивалентно также суперключ может быть определенным как набор атрибутов схемы отношений, от которых все атрибуты схемы являются функционально зависимыми. (Суперключ всегда содержит ключ-кандидат / ключ-кандидат всегда является подмножеством суперключа. Вы можете добавить любой атрибут в отношение, чтобы получить один из суперключей.)
То есть никакое частичное подмножество (любое нетривиальное подмножество, кроме полного набора) ключа-кандидата не может быть функционально зависимым от чего-либо, кроме суперключа.
Таблица / отношение, отсутствующее в 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
Проблема решена: теперь, если мы модернизируем корт, мы можем гарантировать, что тип ставки будет отражать это изменение, и мы не можем взимать неправильную цену за корт.
(В техническом плане мы можем гарантировать, что функциональная зависимость "Тип ставки" -> "Суд" не будет нарушена.)
Это старый вопрос с ценными ответами, но я все еще был немного смущен, пока не нашел реальный пример, показывающий проблему с 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.
Все хорошие ответы. Проще говоря, [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