Różnica między 3NF i BCNF w prostych słowach (musi być w stanie wyjaśnić 8-latkowi)

Przeczytałem cytat: dane zależą od klucza [1NF], całego klucza [2NF] i nic oprócz klucza [3NF] .

Jednak mam problem ze zrozumieniem 3.5NF lub BCNF, jak to się nazywa. Oto co rozumiem:

• BCNF jest bardziej rygorystyczny niż 3NF
• lewa strona dowolnego FD w tabeli musi być superkluczem (lub przynajmniej kluczem kandydującym)

Dlaczego więc jest tak, że niektóre tabele 3NF nie znajdują się w BCNF? Mam na myśli, że cytat 3NF wyraźnie mówi „tylko klucz”, co oznacza, że ​​wszystkie atrybuty zależą wyłącznie od klucza podstawowego. W końcu klucz podstawowy jest kluczem kandydującym, dopóki nie zostanie wybrany jako nasz klucz podstawowy.

Jeśli do tej pory coś jest nie w porządku, popraw mnie i dziękuję za wszelką pomoc, jakiej możesz udzielić.

Twoja pizza może mieć dokładnie trzy rodzaje dodatków:

• jeden rodzaj sera
• jeden rodzaj mięsa
• jeden rodzaj warzyw

Zamawiamy więc dwie pizze i wybieramy następujące dodatki:

Pizza    Topping     Topping Type
-------- ----------  -------------
1        mozzarella  cheese
1        pepperoni   meat
1        olives      vegetable
2        mozzarella  meat
2        sausage     cheese
2        peppers     vegetable

Chwileczkę, mozzarella nie może być jednocześnie serem i mięsem! A kiełbasa to nie ser!

Musimy zapobiegać tego rodzaju błędom, aby mozzarella zawsze była serem. Powinniśmy użyć do tego osobnej tabeli, więc zapisujemy ten fakt tylko w jednym miejscu.

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

To było wyjaśnienie, które ośmiolatek mógłby zrozumieć. Oto bardziej techniczna wersja.

BCNF działa inaczej niż 3NF tylko wtedy, gdy istnieje wiele nakładających się kluczy kandydujących.

Powodem jest to, że zależność funkcjonalna X -> Yjest oczywiście prawdziwa, jeśli Yjest podzbiorem X. Tak więc w każdej tabeli, która ma tylko jeden klucz kandydujący i znajduje się w 3NF, znajduje się już w BCNF, ponieważ nie ma kolumny (ani klucza, ani nieklucza), która jest funkcjonalnie zależna od czegokolwiek poza tym kluczem.

Ponieważ każda pizza musi mieć dokładnie jeden z każdego rodzaju polewy, wiemy, że (Pizza, rodzaj polewy) jest kluczem kandydującym. Wiemy też intuicyjnie, że dany topping nie może należeć jednocześnie do różnych typów. Tak więc (Pizza, Topping) musi być niepowtarzalna i dlatego jest również kluczem kandydującym. Mamy więc dwa nakładające się klucze kandydatów.

Pokazałem anomalię, w której oznaczyliśmy mozarellę jako niewłaściwy rodzaj polewy. Wiemy, że to jest złe, ale regułą, która czyni to błędnym, jest zależność, Topping -> Topping Typektóra nie jest poprawną zależnością dla BCNF dla tej tabeli. Jest to zależność od czegoś innego niż cały klucz kandydata.

Aby rozwiązać ten problem, usuwamy typ toppingu z tabeli Pizze i ustawiamy go jako atrybut niebędący kluczem w tabeli Toppings.

Subtelna różnica polega na tym, że 3NF rozróżnia atrybuty kluczowe i niekluczowe (zwane również atrybutami innymi niż główne ), podczas gdy BCNF nie.

Najlepiej można to wyjaśnić, używając definicji 3NF Zaniolo , która jest równoważna z definicją Codda:

Relacja R jest w 3NF iff dla każdego nietrywialnego FD (X-> A) spełnianego przez R przynajmniej JEDEN z poniższych warunków jest prawdziwy:

(a) X jest superkluczem dla R lub

(b) A jest kluczowym atrybutem dla R.

BCNF wymaga (a), ale nie traktuje (b) jako własnego przypadku specjalnego. Innymi słowy, BCNF wymaga, aby każdy nietrywialny wyznacznik był superkluczem, nawet jego atrybuty zależne są częścią klucza.

Relacja R jest w BCNF iff dla każdego nietrywialnego FD (X-> A) spełnianego przez R, spełniony jest następujący warunek:

(a) X jest superkluczem dla R

Dlatego BCNF jest bardziej rygorystyczny.

Różnica jest tak subtelna, że ​​to, co wielu ludzi określa nieformalnie jako 3NF, jest w rzeczywistości BCNF. Na przykład, napisałeś tutaj, że 3NF oznacza „dane zależą od klucza [ów]… i nic poza kluczem [s]”, ale jest to naprawdę nieformalny opis BCNF, a nie 3NF. 3NF można dokładniej opisać jako „ dane niekluczowe zależą od kluczy… i tylko od kluczy”.

Stwierdziłeś również:

cytat 3NF wyraźnie mówi „tylko klucz”, co oznacza, że ​​wszystkie atrybuty zależą wyłącznie od klucza podstawowego.

To nadmierne uproszczenie. 3NF i BCNF oraz wszystkie formularze normalne dotyczą wszystkich kluczy kandydujących i / lub superkluczy, a nie tylko jednego klucza „podstawowego”.

Różnica między BCNF i 3NF

Korzystanie z definicji BCNF

Wtedy i tylko wtedy, gdy dla każdej z jego zależności X → Y zachodzi przynajmniej jeden z następujących warunków :

• X → Y to trywialna zależność funkcjonalna (Y ⊆ X) lub
• X jest super kluczem dla schematu R.

i definicję 3NF

Wtedy i tylko wtedy, gdy dla każdej z jego zależności funkcjonalnych X → A zachodzi przynajmniej jeden z poniższych warunków:

• X zawiera A (to znaczy X → A jest trywialną zależnością funkcjonalną) lub
• X to superklucz lub
• Każdy element AX, różnica zestawu między A i X, jest atrybutem głównym (tj. Każdy atrybut w AX jest zawarty w jakimś kluczu kandydującym)

W prostych słowach widzimy następującą różnicę:

• W BCNF : każdy klucz częściowy (atrybut główny) może zależeć tylko od superklucza,

natomiast

• W 3NF : Klucz częściowy (atrybut główny) może również zależeć od atrybutu, który nie jest superkluczem (tj. Inny częściowy atrybut klucza / główny lub nawet atrybut inny niż główny).

Gdzie

1. Główny atrybut to atrybut znaleziony w kluczu kandydującym, a
2. Klucz potencjalny to minimalna nadkluczem w tym zakresie, a
3. Nadkluczem to zestaw atrybutów zmiennej relacji, dla których uznaje, że we wszystkich stosunkach przypisanych do tej zmiennej, nie istnieją dwa odrębne krotki (wiersze), które mają te same wartości atrybutów w tym set.Equivalently nadkluczem może również być zdefiniowany jako zbiór atrybutów schematu relacji, od których wszystkie atrybuty schematu są funkcjonalnie zależne. (Superklucz zawsze zawiera klucz kandydujący / klucz kandydujący jest zawsze podzbiorem superklucza. Możesz dodać dowolny atrybut w relacji, aby uzyskać jeden z superkluczy).

Oznacza to, że żaden częściowy podzbiór (dowolny nietrywialny podzbiór z wyjątkiem pełnego zestawu) klucza kandydującego nie może być funkcjonalnie zależny od czegokolwiek innego niż superklucz.

Tabela / relacja nie w BCNF podlega anomaliom, takim jak anomalie aktualizacji wspomniane w przykładzie pizzy przez innego użytkownika. Niestety,

• BNCF nie zawsze można uzyskać , natomiast
• Zawsze można uzyskać 3NF .

Przykład 3NF kontra BCNF

Przykład różnicy można obecnie znaleźć pod adresem „ Tabela 3NF niezgodna z BCNF (normalna forma Boyce-Codda) ” w Wikipedii, gdzie poniższa tabela spełnia wymagania 3NF, ale nie BCNF, ponieważ „Tennis Court” (częściowy atrybut klucza / pierwszego) zależy na "Rate Type" (częściowy atrybut klucza / prime, który nie jest superkluczem), który jest zależnością, którą możemy określić, pytając klientów bazy danych, klub tenisowy:

Dzisiejsze rezerwacje kortów tenisowych ( 3NF, nie 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

Superklucze stołu to:

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

Problem 3NF : częściowy atrybut klucza / numeru głównego „Court” zależy od czegoś innego niż superklucz. Zamiast tego jest zależny od częściowego klucza / atrybutu głównego „Typ stawki”. Oznacza to, że użytkownik musi ręcznie zmienić typ stawki, jeśli aktualizujemy kort lub ręcznie zmienić kort, jeśli chce zastosować zmianę stawki.

• Ale co, jeśli użytkownik ulepszy kort, ale nie pamięta o podwyższeniu stawki? A co, jeśli do sądu zostanie zastosowany niewłaściwy rodzaj stawki?

(Z technicznego punktu widzenia nie możemy zagwarantować, że zależność funkcjonalna „Typ stawki” -> „Sąd” nie zostanie naruszona.)

Rozwiązanie BCNF : Jeśli chcemy umieścić powyższą tabelę w BCNF, możemy zdekomponować podaną relację / tabelę na następujące dwie relacje / tabele (zakładając, że wiemy, że typ stawki zależy tylko od sądu i statusu członkostwa, które moglibyśmy dowiedz się pytając klientów naszej bazy danych, właścicieli klubu tenisowego):

Typy stawek ( BCNF i słabszy 3NF, co jest implikowane przez BCNF)

Rate Type   Court   Member Flag
---------   -----   -----------
SAVER       1       Yes
STANDARD    1       No
PREMIUM-A   2       Yes
PREMIUM-B   2       No

Dzisiejsze rezerwacje kortów tenisowych ( BCNF i słabszy 3NF, co sugeruje 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

Problem rozwiązany : Teraz, jeśli zaktualizujemy kort, możemy zagwarantować, że typ stawki będzie odzwierciedlał tę zmianę i nie możemy naliczyć niewłaściwej ceny za sąd.

(Z technicznego punktu widzenia możemy zagwarantować, że zależność funkcjonalna „Typ stawki” -> „Sąd” nie zostanie naruszona.)

Wszystkie dobre odpowiedzi. Mówiąc prostym językiem [BCNF] Żaden klucz częściowy nie może zależeć od klucza.

tj. żaden częściowy podzbiór (tj. dowolny nietrywialny podzbiór poza pełnym zestawem) klucza kandydującego nie może być funkcjonalnie zależny od jakiegoś klucza kandydującego.

Odpowiedzi udzielone przez „ smartnut007 ”, „ Bill Karwin ” i „ sqlvogel ” są doskonałe. Pozwólcie jednak, że przedstawię to z interesującej perspektywy.

Cóż, mamy klucze pierwsze i inne niż pierwsze.

Kiedy skupiamy się na tym, jak liczby inne niż liczby pierwsze zależą od liczb pierwszych, widzimy dwa przypadki:

Liczby inne niż liczby pierwsze mogą być zależne lub nie .

• Gdy są zależne: widzimy, że muszą polegać na pełnym kluczu kandydata. To jest 2NF .

• Gdy nie jest zależny: może istnieć zależność niezależna lub zależność przechodnia

  • Nawet zależność przechodnia: nie wiem, która teoria normalizacji rozwiązuje ten problem.
  • W przypadku przejściowego uzależnienia: jest uważane za niepożądane. To jest 3NF .

A co z zależnościami między liczbami pierwszymi?

Teraz widzisz, nie zajmujemy się zależnością między liczbami pierwszymi przez 2. lub 3. NF. Dalsza taka zależność, jeśli taka istnieje, nie jest pożądana, dlatego mamy jedną regułę, która to rozwiązuje. To jest BCNF .

Odwołując się do przykładu z posta Billa Karwina , zauważysz, że zarówno „ Topping ”, jak i „ Topping Type ” są kluczami pierwszymi i mają zależność. Gdyby nie były liczbami pierwszymi i były zależne, wtedy włączyłby się 3NF.

Uwaga:

Definicja BCNF jest bardzo ogólna i nie rozróżnia atrybutów między liczbą pierwszą a inną. Jednak powyższy sposób myślenia pomaga zrozumieć, w jaki sposób pewna anomalia jest przenoszona nawet po 2 i 3 NF.

Temat zaawansowany: Mapowanie ogólnego BCNF na 2NF i 3NF

Teraz, gdy wiemy, że BCNF zapewnia ogólną definicję bez odniesienia do żadnych atrybutów głównych / innych niż pierwsze, zobaczmy, jak BCNF i 2/3 NF są powiązane.

Po pierwsze, BCNF wymaga (poza trywialnym przypadkiem), że dla każdej zależności funkcjonalnej X -> Y(FD) X powinien być superkluczem. Jeśli weźmiemy pod uwagę dowolną FD, mamy trzy przypadki - (1) Zarówno X, jak i Y nie są pierwsze, (2) Zarówno pierwsze, jak i (3) X pierwsze i Y nie są pierwsze, odrzucając (bezsensowne) przypadki X nie -pierwsza i Y pierwsza.

W przypadku (1) zajmie się 3NF.

W przypadku (3) zajmie się 2NF.

W przypadku (2) znajdujemy użycie BCNF

To stare pytanie z cennymi odpowiedziami, ale nadal byłem nieco zdezorientowany, dopóki nie znalazłem przykładu z życia, który pokazuje problem z 3NF. Może nie nadaje się dla 8-letniego dziecka, ale mam nadzieję, że pomoże.

Jutro spotkam się z nauczycielami mojej najstarszej córki na jednym z tych kwartalnych spotkań rodziców / nauczycieli. Oto jak wygląda mój pamiętnik (nazwy i pokoje zostały zmienione):

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 

Na pokój przypada tylko jeden nauczyciel i nigdy się nie ruszają. Jeśli spojrzeć, zobaczysz, że: (1) dla każdego atrybutu Teacher, Date, Roommamy tylko jedną wartość rzędu. (2) Super-klucze to: (Teacher, Date, Room), (Teacher, Date)a (Date, Room)klawisze i kandydujące są oczywiście (Teacher, Date)i (Date, Room).

_{(Teacher, Room) nie jest superkluczem, ponieważ uzupełnię tabelę w następnym kwartale i mogę mieć wiersz taki jak ten (Pan Smith się nie poruszył!):}

Teacher  | Date             | Room
---------|------------------| ----
Mr Smith | 2019-03-19 18:15 | A12

Co możemy wywnioskować? (1) to nieformalne, ale poprawne sformułowanie 1NF. Z punktu (2) widzimy, że nie ma „atrybutu innego niż pierwszy”: 2NF i 3NF są podawane bezpłatnie.

Mój pamiętnik to 3NF. Dobry! Nie. Niezupełnie, ponieważ żaden projektant danych nie zaakceptowałby tego w schemacie bazy danych. RoomAtrybut jest zależny od Teacheratrybutu (znowu: nauczyciele nie ruszać!), Ale schemat nie odzwierciedla ten fakt. Co zrobiłby rozsądny projektant danych? Podziel tabelę na dwie części:

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

I

Teacher   | Room
----------|-----
Mr Smith  | A12
Mr Jones  | B10
Ms Doe    | C21
Ms Rogers | A08

Ale 3NF nie zajmuje się zależnościami atrybutów głównych. Na tym polega problem: zgodność 3NF nie wystarczy, aby w pewnych okolicznościach zapewnić prawidłowy projekt schematu tabeli.

W przypadku BCNF nie ma znaczenia, czy atrybut jest atrybutem głównym, czy nie w regułach 2NF i 3NF. Dla każdej nietrywialnej zależności (podzbiory są oczywiście określane przez ich nadzbiory) wyznacznikiem jest kompletny superklucz. Innymi słowy, nic nie jest określone przez coś innego niż kompletny super klucz (z wyłączeniem trywialnych FD). (Zobacz inne odpowiedzi dla formalnej definicji).

Tak szybko, jak Roomzależy Teacher, Roommusi być podzbiorem Teacher(tak nie jest) lub Teachermusi być super kluczem (tak nie jest w moim dzienniku, ale tak jest, gdy dzielisz stół).

Podsumowując: BNCF jest bardziej rygorystyczne, ale moim zdaniem łatwiejsze do ogarnięcia niż 3NF:

• w większości przypadków BCNF jest identyczny z 3NF;
• w innych przypadkach BCNF jest tym, czym myślisz / masz nadzieję, że jest 3NF.