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

Subtelna różnica polega na tym, że 3NF rozróżnia atrybuty key i non-key (zwane również atrybutami non-prime), podczas gdy bcnf nie.

Relacja, R, jest w 3NF iff dla każdego nietrywialnego FD (X->A) spełnionego przez R spełniony jest co najmniej jeden z następujących warunków:

(a) X jest superkey dla R, lub

B) A jest kluczowym atrybutem dla R

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

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

(a) X jest superkeyem dla R

BCNF jest więc bardziej rygorystyczny.

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

Napisałeś także:

Cytat 3NF mówi wprost "nic poza kluczem", co oznacza, że wszystkie atrybuty zależą wyłącznie na głównym kluczu.

To uproszczenie. 3NF i BCNF oraz wszystkie normalne formy dotyczą WSZYSTKICH kluczy kandydujących i / lub superkeys, a nie tylko jednego" podstawowego " klucza.

Różnica między BCNF i 3NF

Używając definicji BCNF

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

• X → Y jest trywialną zależnością funkcyjną (Y ⊆ X) lub
• x jest super kluczem do schematu R

I definicja 3NF

wtedy i tylko wtedy, gdy dla każdej z jego zależności funkcyjnych X → a, co najmniej jeden z następujących warunków posiada:

• x Zawiera A (tzn. X → A jest trywialną zależnością funkcyjną), lub
• X jest superkey lub
Każdy element A-X, różnica zestawu między A i X, jest atrybutem pierwszym (tzn. każdy atrybut A-X jest zawarty w jakimś kluczu kandydującym)

Widzimy następującą różnicę, w prostych słowach:

• W BCNF : każdy klucz częściowy (atrybut prime) Może tylko zależeć od superkey,

]}

• W 3NF: klucz częściowy (atrybut prime) Możerównież zależeć od atrybutu, który jest nie superkey (tj. inny częściowy atrybut klucz / prime lub nawet atrybut nie-prime).

Gdzie

1. a atrybut prime jest atrybutem znalezionym w kluczu kandydata i
2. a klucz kandydata jest minimalnym superkeyem dla tej relacji, a
3. A superkey jest zbiorem atrybutów zmiennej relacji, dla której utrzymuje, że we wszystkich relacjach przypisanych do tej zmiennej nie ma dwóch odrębnych krotek (wierszy), które mają takie same wartości dla atrybutów w tym zbiorze.Równoważnie superkey może być również zdefiniowany jako zbiór atrybutów schematu relacji, od którego wszystkie atrybuty schematu są funkcjonalnie zależne. (Klucz superkey zawsze zawiera klucz kandydata/klucz kandydata jest zawsze podzbiorem klucza superkey. Ty może dodać dowolny atrybut w relacji, aby uzyskać jeden z superkluczy.)

Oznacza to, że żaden częściowy podzbiór (dowolny Nie trywialny podzbiór z wyjątkiem pełnego zestawu) klucza kandydata nie może być funkcjonalnie zależny od niczego innego niż superkey.

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

• BNCF nie można zawsze otrzymać , while
• 3NF zawsze można otrzymać.

3NF kontra Bcnf przykład

Przykład różnicy można obecnie znaleźć w" tabela 3NF nie spełniająca bcnf (Boyce–Codd normal form) "na Wikipedii, gdzie poniższa tabela spełnia 3NF, ale nie BCNF, ponieważ" kort tenisowy "(częściowy klucz/atrybut prime) zależy od" Rate Type " (częściowy klucz/atrybut prime, który jest , a nie superkey), która jest zależnością możemy określić za pomocą pytanie do 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 tabeli 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 z 3NF : Atrybut partial key / prime "Court" jest zależny od czegoś innego niż superkey. Zamiast tego jest on zależny od częściowego atrybutu key / prime "Rate Type". Oznacza to, że użytkownik musi ręcznie zmienić typ stawki, jeśli ulepszymy sąd, lub ręcznie zmienić sąd, jeśli chce zastosować zmianę stawki.

• ale co, jeśli użytkownik ulepszy sąd, ale nie pamięta, aby zwiększyć stawkę? A co jeśli do sądu zostanie zastosowany niewłaściwy typ stawki?

(pod względem technicznym nie możemy zagwarantować, że zależność funkcjonalna "typu stopy" -> "sądu" nie zostanie naruszona.)

Rozwiązanie BCNF : Jeśli chcemy umieścić powyższą tabelę w BCNF możemy rozłożyć daną relację/tabelę na następujące dwie relacje / tabele (zakładając, że wiemy, że typ stawki zależy tylko od kortu i statusu członkostwa, które możemy odkryć pytając klientów naszej bazy danych, właścicieli klubu tenisowego): {]}

typy stawek (BCNF i słabszy 3NF, który jest implikowany 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, który jest implikowany przez 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 ulepszymy sąd możemy zagwarantować, że typ stawki będzie odzwierciedlał tę zmianę i nie możemy pobierać niewłaściwej ceny za sąd.

(pod względem technicznym możemy zagwarantować, że funkcjonalna zależność "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.

Tzn. żaden podzbiór częściowy (tzn. żaden nie trywialny podzbiór z wyjątkiem pełnego zbioru ) klucza kandydata nie może być funkcjonalnie zależny od jakiegoś klucza kandydata.

Odpowiedzi użytkownika ' smartnut007', 'Bill Karwin " i " sqlvogel " są doskonałe. Pozwolę sobie jednak spojrzeć na to z ciekawej perspektywy.

Kiedy skupiamy się na tym, jak nie-pierwsze zależą od liczb pierwszych, widzimy dwa przypadki:

Non-primes mogą być zależne lub nie.

• gdy są zależne: widzimy, że muszą zależeć od pełnego klucza kandydata. To jest 2NF .

• Gdy nie jest zależna: nie może być-zależność lub zależność przechodnia

  • nawet zależność przechodnia: Nie wiem, jaka teoria normalizacji to rozwiązuje.
  • gdy jest zależna przejściowo: jest uważana za niepożądaną. To jest 3NF .

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

Teraz widzisz, nie zajmujemy się relacją zależności między pierwsze przez 2. lub 3. NF. Dalsze takie zależności, jeśli w ogóle istnieją, nie są pożądane i dlatego mamy jedną regułę, aby się tym zająć. To jest BCNF .

Nawiązując do przykładu z Billa Karwina , zauważysz, że zarówno' Topping', jak i' topping Type ' są kluczami pierwszymi i mają zależność. Gdyby nie były primami z zależnością, to 3NF by zadziałało.

Uwaga:

The definicja BCNF jest bardzo ogólna i bez różnicowania atrybutów między prime i non-prime. Jednak powyższy sposób myślenia pomaga zrozumieć, w jaki sposób pewna anomalia jest perkolowana nawet po 2. i 3. NF.

Temat zaawansowany: mapowanie generycznego BCNF na 2NF i 3NF

teraz, gdy wiemy, że BCNF zawiera ogólną definicję bez odniesienia do jakichkolwiek atrybutów prime / non-prime, zobaczmy, jak BCNF i 2/3 NF są ze sobą powiązane.

Po pierwsze, bcnf wymaga (poza trywialny przypadek), że dla każdej zależności funkcyjnej X -> Y (FD), X powinien być super-kluczem. Jeśli weźmiemy pod uwagę dowolny FD, to mamy trzy przypadki-(1) zarówno X, jak i Y nie-prime, (2) zarówno prime, jak i (3) X prime i Y non-prime, odrzucając (bezsensowny) przypadek X non-prime i Y prime.