BCNF/3NF в релационни бази данни

Как да разберете дали връзката R е в BCNF и 3NF?

Чета учебник и той ми казва, че има 3 основни атрибута, които разглеждате, но имам проблеми с разбирането на това, което казват, или поне с прилагането на това, което казват, когато ми е дадена връзка и ФД.

3-те атрибута: Дадено е отношение R с атрибута A и X подмножество от атрибути на R, за всеки FD X⟶A във F едно от следните твърдения е вярно:

  • A ∈ X; това е тривиално FD (∈ което означава „се намира в X“)
  • X е суперключ
  • A е част от някакъв ключ за R

Първите два съответстват на BCNF, а 3NF включват третия.


database relational-database relation 3nf
person dxu    schedule 16.10.2011    source източник
comment
Започнете с изброяване на атрибутите в публикацията -- подозирам, че са от стандартна теорема и изброяването им ще помогне за фокусиране на отговорите.   -  person    schedule 16.10.2011
comment
Третият израз - A е част от някакъв ключ за R - ми прилича повече на 2NF, отколкото на 3NF - вижте en .wikipedia.org/wiki/Second_normal_form .   -  person    schedule 19.10.2011

Отговори (1)


arrow_upward
4
arrow_downward

Книгата SQL Antipatterns от Бил Карвин има хубав пример за BCNF и 3NF на страница 303, които е малко сложно, но вярвам, че посочва разликата по-сбито от всяко описание на разликата, което съм чел досега.

Да предположим например, че имаме три типа тагове: тагове, които описват въздействието на грешката, тагове за подсистемата, която засяга грешката, и тагове, които описват корекцията на грешката. Ние решаваме, че всеки бъг трябва да има най-много един таг от определен тип. Нашият кандидат-ключ може да бъде bug_id плюс tag, но може да бъде и bug_id плюс tag_type. Всяка двойка колони ще бъде достатъчно специфична, за да адресира всеки ред поотделно.

bug_id tag      tag_type
------------------------
1234   crash    impact
3456   printing subsystem
3456   crash    impact
5678   report   subsystem
5678   crash    impact
5678   data     fix

След това книгата променя тази единична таблица (която удовлетворява 3NF) в две таблици, които удовлетворяват BCNF:

bug_id tag
----------
1234   crash
3456   printing
3456   crash
5678   report
5678   crash
5678   data

tag       tag_type
------------------
crash     impact
printing  subsystem
report    subsystem
data      fix
person sarnold    schedule 16.10.2011
comment
Усеща се, че тук е приложена лека ръка. Започнахте с {id,type -› таг; tag -› type} и се разлага от 3NF релацията (id, tag, type) към BCNF релациите (id, tag) и (tag, type). Това разлагане би било присъединяване без загуби, но не сте запазили FD (id, type -› таг): сега ще е възможно да вмъкнете в (bug_id, таг) стойности (3456, отчет), докато преди това би се счупило ключовото ограничение. Понякога това е приемливо, но трябва да сте наясно, че сте облекчили ограничението. - person beldaz; 11.09.2013