Разница между 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 : частичный ключ (основной атрибут) может также зависеть от атрибута, который не суперключ (т.е. другой частичный ключ / простой атрибут или даже не простой атрибут).
Где
- A простой атрибут - это атрибут, найденный в ключе-кандидате, а
- A ключ-кандидат - минимальный суперключ для этого отношения, а
- A superkey - это набор атрибутов переменной отношения, для которого он считает, что во всех отношениях, назначенных этой переменной, нет двух различных кортежей (строк), которые имеют те же значения для атрибутов в этом наборе. Эквивалентно суперключ также может быть определен как набор атрибутов схемы отношений, от которых функционально зависят все атрибуты схемы. (Суперключ всегда содержит ключ-кандидат / ключ-кандидат всегда является подмножеством суперключа. Вы можете добавить любой атрибут в отношение, чтобы получить один из суперключей.)
То есть, никакое частичное подмножество (любое нетривиальное подмножество, кроме полного набора) ключа-кандидата не может быть функционально зависимым от чего-либо, кроме суперключа.
Таблица / отношение, отсутствующее в 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
Superkeys таблицы:
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 :
Если мы хотим тo поместив приведенную выше таблицу в 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
Проблема решена :
Теперь, если мы модернизируем корт, мы можем гарантировать, что тип ставки будет отражать это изменение, и мы не можем взимать неправильную цену за корт.
(В техническом плане мы можем гарантировать, что функциональная зависимость «Тип ставки» -> «Суд» не будет нарушена.)