Unterschied zwischen 3NF und BCNF in einfachen Worten (muss einem 8-Jährigen erklären können)

Ich habe das Zitat gelesen: Daten hängen vom Schlüssel [1NF], dem ganzen Schlüssel [2NF] und nichts als dem Schlüssel [3NF] ab .

Jedoch habe ich Probleme, 3.5NF oder BCNF zu verstehen, wie es genannt wird. Hier ist, was ich verstehe:

  • BCNF ist strenger als 3NF
  • Die linke Seite einer FD in der Tabelle muss ein Superkey (oder zumindest ein Kandidat Key) sein

Warum ist es dann so, dass einige 3NF-Tabellen nicht in BCNF sind? Ich meine, das 3NF-Zitat sagt explizit “nichts als der Schlüssel”, was bedeutet, dass alle Attribute nur vom Primärschlüssel abhängen. Der Primärschlüssel ist schließlich ein Kandidatenschlüssel, bis er als Primärschlüssel ausgewählt wird.

Wenn etwas in Bezug auf mein Verständnis bisher nicht in Ordnung ist, bitte korrigieren Sie mich und danke für jede Hilfe, die Sie zur Verfügung stellen können.

Ihre Pizza kann genau drei Topping-Typen haben:

  • eine Art Käse
  • eine Art von Fleisch
  • eine Art von Gemüse

Also bestellen wir zwei Pizzas und wählen die folgenden Beläge:

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

Moment mal, Mozzarella kann kein Käse und kein Fleisch sein! Und Wurst ist kein Käse!

Wir müssen diese Art von Fehlern vermeiden, damit Mozzarella immer Käse ist. Wir sollten dafür eine separate Tabelle verwenden, also schreiben wir diese Tatsache nur an einer Stelle auf.

 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 

Das war die Erklärung, die ein 8-Jähriger verstehen könnte. Hier ist die technische Version.

BCNF unterscheidet sich nur dann von 3NF, wenn mehrere überlappende Kandidatenschlüssel vorhanden sind.

Der Grund ist, dass die funktionale Abhängigkeit X -> Y natürlich wahr ist, wenn Y eine Teilmenge von X . In jeder Tabelle, die nur einen Kandidatenschlüssel hat und sich in 3NF befindet, ist sie bereits in BCNF vorhanden, da es keine Spalte (Schlüssel oder Nicht-Schlüssel) gibt, die funktional von irgendetwas neben diesem Schlüssel abhängig ist.

Da jede Pizza genau einen von jedem Topping-Typ haben muss, wissen wir, dass (Pizza, Topping Type) ein Kandidatenschlüssel ist. Wir wissen auch intuitiv, dass ein gegebenes Topping nicht gleichzeitig zu verschiedenen Typen gehören kann. Also (Pizza, Topping) muss eindeutig sein und ist daher auch ein Kandidatenschlüssel. Wir haben also zwei überlappende Kandidatenschlüssel.

Ich zeigte eine Anomalie, bei der wir Mozarella als den falschen Belagstyp markierten. Wir wissen, dass dies falsch ist, aber die Regel, die es falsch macht, ist eine Abhängigkeit Topping -> Topping Type die keine gültige Abhängigkeit für BCNF für diese Tabelle ist. Es ist eine Abhängigkeit von etwas anderem als einem ganzen Kandidatenschlüssel.

Um das zu lösen, nehmen wir den Topping-Typ aus der Pizzas-Tabelle und machen ihn zu einem Nicht-Schlüssel-Attribut in einer Toppings-Tabelle.

Der feine Unterschied besteht darin, dass 3NF zwischen Schlüssel- und Nicht-Schlüssel-Attributen (auch Nicht-Prime- Attribute genannt) unterscheidet, während BCNF dies nicht tut.

Dies lässt sich am besten anhand der Zaniolo-Definition von 3NF erklären, die der von Codd entspricht:

Eine Beziehung R ist in 3NF, wenn für jede nichttriviale FD (X-> A), die von R erfüllt ist, mindestens EINE der folgenden Bedingungen zutrifft:

(a) X ist ein Superkey für R, oder

(b) A ist ein Schlüsselattribut für R

BCNF erfordert (a), behandelt aber (b) nicht als einen speziellen Fall für sich. Mit anderen Worten, BCNF erfordert, dass jede nichttriviale Determinante ein Superkey ist, selbst wenn die abhängigen Attribute Teil eines Schlüssels sind.

Eine Beziehung, R, ist in BCNF, wenn für jede nichttriviale FD (X-> A), die durch R erfüllt ist, die folgende Bedingung zutrifft:

(a) X ist ein Superkey für R

BCNF ist daher strenger.

Der Unterschied ist so subtil, dass das, was viele Leute informell als 3NF bezeichnen, tatsächlich BCNF ist. Zum Beispiel haben Sie hier angegeben, dass 3NF bedeutet “Daten hängen von den Schlüsseln … ab und nichts außer den Schlüsseln [s]”, aber das ist wirklich eine informelle Beschreibung von BCNF und nicht 3NF. 3NF könnte genauer beschrieben werden als ” Nicht-Schlüssel-Daten hängen von den Schlüsseln ab … und nichts außer den Schlüsseln”.

Du hast auch gesagt:

Das 3NF-Zitat sagt explizit “nichts als der Schlüssel”, was bedeutet, dass alle Attribute nur vom Primärschlüssel abhängen.

Das ist eine zu starke Vereinfachung. 3NF und BCNF und alle normalen Formulare betreffen alle Kandidatenschlüssel und / oder Superschlüssel, nicht nur einen “Primärschlüssel”.

Der Unterschied zwischen BCNF und 3NF

Verwenden der BCNF-Definition

Wenn und nur wenn für jede seiner Abhängigkeiten X → Y mindestens eine der folgenden Bedingungen gilt :

  • X → Y ist eine triviale funktionale Abhängigkeit (Y ⊆ X), oder
  • X ist ein Superschlüssel für Schema R

und die 3NF-Definition

Wenn und nur wenn für jede seiner funktionalen Abhängigkeiten X → A mindestens eine der folgenden Bedingungen zutrifft:

  • X enthält A (dh X → A ist eine triviale funktionale Abhängigkeit) oder
  • X ist ein Superkey oder
  • Jedes Element von AX, der Satzunterschied zwischen A und X, ist ein primäres Attribut (dh jedes Attribut in AX ist in einem Kandidatenschlüssel enthalten).

Wir sehen den folgenden Unterschied, in einfachen Worten:

  • In BCNF : Jeder Teilschlüssel (Primattribut) kann nur von einem Superkey abhängen,

wohingegen

  • In 3NF : Ein partieller Schlüssel (prime-Attribut) kann auch von einem Attribut abhängen, das kein Superkey ist (dh ein anderes partielles Schlüssel / prim-Attribut oder sogar ein nicht-primäres Attribut).

Woher

  1. Ein primäres Attribut ist ein Attribut, das in einem Kandidatenschlüssel gefunden wird, und
  2. Ein Kandidatenschlüssel ist ein minimaler Superkey für diese Beziehung und
  3. Ein Superkey ist eine Menge von Attributen einer Beziehungsvariablen, für die es gilt, dass in allen Beziehungen, die dieser Variablen zugewiesen sind, keine zwei unterschiedlichen Tupel (Zeilen) mit den gleichen Werten für die Attribute in dieser Menge vorhanden sind. Ein Superkey kann dies ebenfalls sein definiert sein als eine Menge von Attributen eines Beziehungsschemas, von dem alle Attribute des Schemas funktional abhängig sind. (Ein Superkey enthält immer einen Kandidatenschlüssel / ein Kandidatenschlüssel ist immer eine Teilmenge eines Superschlüssels. Sie können jedes Attribut in einer Relation hinzufügen, um einen der Superkeys zu erhalten.)

Das heißt, dass keine Teiluntermenge (irgendeine nicht triviale Teilmenge außer der vollständigen Menge) eines Kandidatenschlüssels funktionell von irgendetwas anderem als einem Superschlüssel abhängig sein kann.

Eine Tabelle / Relation, die nicht in BCNF enthalten ist, unterliegt Anomalien, wie z. B. den Aktualisierungsanomalien, die im Pizza-Beispiel von einem anderen Benutzer erwähnt wurden. Unglücklicherweise,

  • BNCF kann nicht immer erhalten werden , während
  • 3NF kann immer erhalten werden .

3NF gegen BCNF Beispiel

Ein Beispiel für den Unterschied findet sich derzeit bei ” 3NF-Tabelle, die BCNF (Boyce-Codd Normalform) nicht trifft” auf Wikipedia, wo die folgende Tabelle 3NF aber nicht BCNF trifft, weil “Tennis Court” (ein Teilschlüssel / Primattribut) abhängt auf “Rate Type” (ein Teilschlüssel / prime-Attribut, das kein Superkey ist), was eine Abhängigkeit ist, die wir ermitteln könnten, indem wir die Kunden der database, den Tennisclub, fragen:

Heutige Tennisplatz Buchungen ( 3NF, nicht 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 

Die Supertasten der Tabelle sind:

 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 

Das 3NF-Problem : Das Partial-Key / Prime-Attribut “Court” ist von etwas anderem als einem Superkey abhängig. Stattdessen ist es abhängig von dem Partial Key / Prime-Attribut “Rate Type”. Dies bedeutet, dass der Benutzer den Preistyp manuell ändern muss, wenn wir ein Gericht aufwerten, oder das Gericht manuell ändern, wenn er eine Kursänderung anwenden möchte.

  • Aber was, wenn der Benutzer das Gericht aufwertet, aber nicht daran denkt, die Rate zu erhöhen? Oder was passiert, wenn der falsche Zinstyp auf ein Gericht angewendet wird?

(In technischer Hinsicht können wir nicht garantieren, dass die funktionale Abhängigkeit “Tarifart” -> “Gericht” nicht verletzt wird.)

Die BCNF-Lösung : Wenn wir die obige Tabelle in BCNF platzieren wollen, können wir die gegebene Relation / Tabelle in die folgenden zwei Relationen / Tabellen zerlegen (vorausgesetzt, wir wissen, dass der Rate-Typ nur vom Gerichts- und Mitgliedsstatus abhängt) entdecken Sie, indem Sie die Kunden unserer database, die Besitzer des Tennisclubs fragen):

Zinsarten ( BCNF und die schwächere 3NF, die von BCNF impliziert wird)

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

Die heutigen Tennis Court Bookings ( BCNF und die schwächere 3NF, die BCNF impliziert)

 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 getriggers : Jetzt, wenn wir das Gericht aufwerten, können wir garantieren, dass der Preistyp diese Änderung widerspiegelt, und wir können keinen falschen Preis für ein Gericht berechnen.

(Technisch können wir garantieren, dass die funktionale Abhängigkeit “Tarifart” -> “Gericht” nicht verletzt wird.)

Alle guten Antworten. Um es in eine einfache Sprache zu bringen [BCNF] Kein Teilschlüssel kann von einem Schlüssel abhängen.

dh eine Teiluntermenge (dh keine nicht triviale Teilmenge außer der vollständigen Menge) eines Kandidatenschlüssels kann funktional von einem Kandidatenschlüssel abhängen.

Antworten von ” smartnut007 “, ” Bill Karwin ” und ” sqlvogel ” sind ausgezeichnet. Aber lassen Sie mich eine interessante Perspektive dazu geben.

Nun, wir haben Prime und Non-Prime-Schlüssel.

Wenn wir uns darauf konzentrieren, wie Nicht-Primzahlen von Primzahlen abhängen, sehen wir zwei Fälle:

Nicht-Primzahlen können abhängig sein oder nicht .

  • Wenn abhängig: wir sehen, dass sie von einem vollständigen Kandidatenschlüssel abhängen müssen. Das ist 2NF .
  • Wenn nicht abhängig: Es kann keine Abhängigkeit oder transitive Abhängigkeit geben

    • Nicht einmal transitive Abhängigkeit: Nicht sicher, was die Normalisierungstheorie anspricht.
    • Wenn transitiv abhängig: Es wird als unerwünscht angesehen. Das ist 3NF .

Was ist mit Abhängigkeiten zwischen Primzahlen?

Nun sehen Sie, wir sprechen nicht die Abhängigkeitsbeziehung zwischen Primzahlen durch entweder 2. oder 3. NF an. Eine weitere solche Abhängigkeit ist, wenn überhaupt, nicht wünschenswert, und daher haben wir eine einzige Regel, die das angeht. Das ist BCNF .

In Bezug auf das Beispiel aus Bill Karwins Beitrag hier werden Sie feststellen, dass sowohl ” Topping ” als auch ” Topping Type ” Pring Keys sind und eine Abhängigkeit haben. Wären sie keine Abhängigkeiten gewesen, wäre 3NF eingetreten.

Hinweis:

Die Definition von BCNF ist sehr allgemein und ohne differenzierende Attribute zwischen Primzahl und Nicht-Primzahl. Die obige Denkweise hilft jedoch zu verstehen, wie eine Anomalie selbst nach dem 2. und 3. NF durchdrungen ist.

Advanced Topic: Zuordnen von generischem BCNF zu 2NF & 3NF

Jetzt, da wir wissen, dass BCNF eine generische Definition ohne Bezug auf irgendwelche Prim / Non-Prime-Attribute liefert, wollen wir sehen, wie BCNF und 2/3 NF’s zusammenhängen.

Erstens benötigt BCNF (außer dem trivialen Fall), dass für jede funktionale Abhängigkeit X -> Y (FD) X ein Superschlüssel sein sollte. Wenn Sie nur irgendeine FD betrachten, dann haben wir drei Fälle – (1) Sowohl X als auch Y nicht-Primzahl, (2) Primzahl und (3) X Primzahl und Y Nicht-Primzahl, Vercasting des (unsinnigen) Falls X nicht -Prime und Y Prime.

Für den Fall (1) sorgt 3NF.

Für Fall (3) sorgt 2NF.

Für den Fall (2) finden wir die Verwendung von BCNF