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 gesamten Schlüssel [2NF] und nichts als dem Schlüssel [3NF] ab .

Ich habe jedoch Probleme, 3.5NF oder BCNF, wie es heißt, zu verstehen. Folgendes verstehe ich:

• BCNF ist strenger als 3NF
• Die linke Seite eines FD in der Tabelle muss ein Superkey (oder zumindest ein Kandidatenschlüssel) sein.

Warum befinden sich dann einige 3NF-Tabellen nicht in BCNF? Ich meine, das 3NF-Zitat sagt explizit "nichts als den Schlüssel", was bedeutet, dass alle Attribute ausschließlich vom Primärschlüssel abhängen. Der Primärschlüssel ist schließlich ein Kandidatenschlüssel, bis er als unser Primärschlüssel ausgewählt wird.

Wenn etwas in Bezug auf mein bisheriges Verständnis nicht stimmt, korrigieren Sie mich bitte und bedanken Sie sich für jede Hilfe, die Sie leisten können.

Ihre Pizza kann genau drei Belagsarten haben:

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

Also bestellen wir zwei Pizzen 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 nicht gleichzeitig Käse und 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 technischere Version.

BCNF verhält sich nur dann anders als 3NF, wenn sich mehrere Kandidatenschlüssel überlappen.

Der Grund ist, dass die funktionale Abhängigkeit X -> Ynatürlich wahr ist, wenn Yes sich um eine Teilmenge von handelt X. In jeder Tabelle, die nur einen Kandidatenschlüssel enthält und sich in 3NF befindet, befindet sie sich bereits in BCNF, da es keine Spalte (weder Schlüssel noch Nichtschlüssel) gibt, die funktional von etwas anderem als diesem Schlüssel abhängig ist.

Da jede Pizza genau einen von jedem Belagstyp haben muss, wissen wir, dass (Pizza, Belagstyp) ein Kandidatenschlüssel ist. Wir wissen auch intuitiv, dass ein gegebener Belag 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 Typedie für diese Tabelle keine gültige Abhängigkeit für BCNF ist. Es ist eine Abhängigkeit von etwas anderem als einem ganzen Kandidatenschlüssel.

Um dies zu lösen, nehmen wir Topping Type aus der Pizzas-Tabelle und machen es zu einem Nicht-Schlüsselattribut in einer Toppings-Tabelle.

Der subtile Unterschied besteht darin, dass 3NF zwischen Schlüssel- und Nicht-Schlüsselattributen (auch als Nicht-Primat- Attribute bezeichnet) unterscheidet, während BCNF dies nicht tut.

Dies lässt sich am besten mit Zaniolos 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 wird, mindestens EINE der folgenden Bedingungen erfüllt ist:

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

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

BCNF erfordert (a), behandelt (b) jedoch nicht als eigenen Sonderfall. Mit anderen Worten, BCNF erfordert, dass jede nichttriviale Determinante ein Superkey ist, selbst wenn ihre abhängigen Attribute Teil eines Schlüssels sind.

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

(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 beschreiben, tatsächlich BCNF ist. Zum Beispiel haben Sie hier angegeben, dass 3NF bedeutet "Daten hängen von den Schlüsseln ab ... und nichts als den Schlüsseln", aber das ist wirklich eine informelle Beschreibung von BCNF und nicht von 3NF. 3NF könnte genauer als " Nicht-Schlüsseldaten" beschrieben werden hängen von den Schlüsseln ab ... und nichts als den Schlüsseln".

Sie sagten auch:

Das 3NF-Zitat sagt ausdrücklich "nichts als der Schlüssel", was bedeutet, dass alle Attribute ausschließlich vom Primärschlüssel abhängen.

Das ist eine Vereinfachung. 3NF und BCNF sowie alle Normalformen 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, gilt mindestens eine der folgenden Bedingungen :

• 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 gilt:

• X enthält A (dh X → A ist eine triviale funktionale Abhängigkeit) oder
• X ist ein Superkey oder
• Jedes Element von AX, die festgelegte Differenz zwischen A und X, ist ein Hauptattribut (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 Teilschlüssel ( Primatattribut ) kann auch von einem Attribut abhängen, das kein Superkey ist (dh ein anderes Teilschlüssel- / Primatattribut oder sogar ein Nicht-Primatattribut).

Wo

1. Ein Hauptattribut ist ein Attribut, das in einem Kandidatenschlüssel gefunden wird, und
2. Ein Kandidatenschlüssel ist ein minimaler Superschlüssel für diese Beziehung, und
3. Ein Superkey ist eine Menge von Attributen einer Beziehungsvariablen, für die er besagt, dass es in allen dieser Variablen zugewiesenen Beziehungen keine zwei unterschiedlichen Tupel (Zeilen) gibt, die dieselben Werte für die Attribute in dieser Menge haben. Gleichermaßen kann dies auch ein Superkey als eine Reihe von Attributen eines Beziehungsschemas definiert werden, von denen alle Attribute des Schemas funktional abhängig sind. (Ein Superkey enthält immer einen Kandidatenschlüssel / ein Kandidatenschlüssel ist immer eine Teilmenge eines Superkeys. Sie können ein beliebiges Attribut in einer Beziehung hinzufügen, um einen der Superkeys zu erhalten.)

Das heißt, keine Teiluntermenge (jede nicht triviale Untermenge mit Ausnahme der vollständigen Menge) eines Kandidatenschlüssels kann funktional von etwas anderem als einem Superschlüssel abhängig sein.

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

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

3NF versus BCNF Beispiel

Ein Beispiel für den Unterschied finden Sie derzeit bei " 3NF-Tabelle entspricht nicht BCNF (Boyce-Codd-Normalform) " auf Wikipedia, wo die folgende Tabelle 3NF, jedoch nicht BCNF erfüllt, da "Tennisplatz" (ein Teilschlüssel- / Primattribut) davon abhängt zu "Rate Type" (ein Teilschlüssel- / Primattribut, das kein Superkey ist), eine Abhängigkeit, die wir ermitteln können, indem wir die Kunden der Datenbank, den Tennisclub, fragen:

Heutige Tennisplatzbuchungen ( 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 Superkeys des Tisches 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 Teilschlüssel- / Primattribut "Court" hängt von etwas anderem als einem Superkey ab. Stattdessen ist es abhängig vom Teilschlüssel- / Primatattribut "Rate Type". Dies bedeutet, dass der Benutzer den Tariftyp manuell ändern muss, wenn wir ein Gericht aktualisieren, oder das Gericht manuell ändern muss, wenn er eine Tarifänderung anwenden möchte.

• Aber was ist, wenn der Benutzer das Gericht aktualisiert, sich aber nicht daran erinnert, die Rate zu erhöhen? Oder was ist, wenn die falsche Tarifart auf ein Gericht angewendet wird?

(In technischer Hinsicht können wir nicht garantieren, dass die funktionale Abhängigkeit von "Rate Type" -> "Court" nicht verletzt wird.)

Die BCNF-Lösung : Wenn wir die obige Tabelle in BCNF platzieren möchten, können wir die angegebene Beziehung / Tabelle in die folgenden zwei Beziehungen / Tabellen zerlegen (vorausgesetzt, wir wissen, dass der Tarif nur vom Gericht und dem Mitgliedschaftsstatus abhängt, was wir könnten Entdecken Sie dies, indem Sie die Kunden unserer Datenbank, die Eigentümer des Tennisclubs, fragen:

Rate Types ( BCNF und der schwächere 3NF, was durch BCNF impliziert wird)

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

Heutige Tennisplatzbuchungen ( BCNF und der schwächere 3NF, der von BCNF impliziert wird)

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 gelöst : Wenn wir jetzt das Gericht aufrüsten, können wir garantieren, dass die Tarifart diese Änderung widerspiegelt, und wir können nicht den falschen Preis für ein Gericht berechnen.

(In technischer Hinsicht können wir garantieren, dass die funktionale Abhängigkeit "Rate Type" -> "Court" nicht verletzt wird.)

Alles gute Antworten. Einfach ausgedrückt [BCNF] Kein Teilschlüssel kann von einem Schlüssel abhängen.

dh Keine Teiluntermenge (dh keine nicht triviale Untermenge mit Ausnahme der vollständigen Menge) eines Kandidatenschlüssels kann funktional von einem Kandidatenschlüssel abhängig sein.

Die Antworten von ' smartnut007 ', ' Bill Karwin ' und ' sqlvogel ' sind ausgezeichnet. Lassen Sie mich dennoch eine interessante Perspektive einbringen.

Nun, wir haben Prim- und Nicht-Prim-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: Ich bin mir nicht sicher, welche Normalisierungstheorie dies anspricht.
  • Wenn transitiv abhängig: Es wird als unerwünscht angesehen. Das ist 3NF .

Was ist mit Abhängigkeiten zwischen Primzahlen?

Sie sehen, wir befassen uns weder mit der 2. noch mit der 3. NF mit der Abhängigkeitsbeziehung zwischen Primzahlen . Darüber hinaus ist eine solche Abhängigkeit, falls vorhanden, nicht wünschenswert, und daher haben wir eine einzige Regel, um dies zu beheben. Das ist BCNF .

Wenn Sie sich auf das Beispiel aus Bill Karwins Beitrag hier beziehen , werden Sie feststellen, dass sowohl " Topping " als auch " Topping Type " Hauptschlüssel sind und eine Abhängigkeit haben. Wären sie keine Primzahlen mit Abhängigkeit gewesen, wäre 3NF eingetreten.

Hinweis:

Die Definition von BCNF ist sehr allgemein und ohne Unterscheidung zwischen Primzahlen und Nicht-Primzahlen. Die obige Denkweise hilft jedoch zu verstehen, wie eine Anomalie auch nach der 2. und 3. NF versickert.

Erweitertes Thema: Zuordnung von generischem BCNF zu 2NF und 3NF

Nachdem wir nun wissen, dass BCNF eine generische Definition ohne Bezugnahme auf Prim- / Nicht-Primat-Attribute bereitstellt, wollen wir sehen, wie BCNF und 2/3 NFs zusammenhängen.

Erstens erfordert BCNF (außer im trivialen Fall), dass X -> YX für jede funktionale Abhängigkeit (FD) ein Superschlüssel sein muss. Wenn Sie nur eine FD betrachten, dann haben wir drei Fälle - (1) Sowohl X als auch Y nicht prim, (2) sowohl prim als auch (3) X prim und Y nicht prim, wobei der (unsinnige) Fall X non verworfen wird -prime und Y prime.

Für Fall (1) kümmert sich 3NF darum.

Für Fall (3) kümmert sich 2NF darum.

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

Dies ist eine alte Frage mit wertvollen Antworten, aber ich war immer noch etwas verwirrt, bis ich ein Beispiel aus dem wirklichen Leben fand, das das Problem mit 3NF zeigt. Vielleicht nicht für ein 8-jähriges Kind geeignet, aber ich hoffe, es hilft.

Morgen werde ich die Lehrer meiner ältesten Tochter in einem dieser vierteljährlichen Eltern- / Lehrertreffen treffen. So sieht mein Tagebuch aus (Namen und Räume wurden geändert):

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 

Es gibt nur einen Lehrer pro Raum und sie bewegen sich nie. Wenn Sie einen Blick haben, werden Sie feststellen , dass: (1) für jedes Attribut Teacher, Date, Roomhaben wir nur einen Wert pro Zeile. (2) Superschlüssel sind : (Teacher, Date, Room), (Teacher, Date)und (Date, Room)und Kandidatenschlüssel sind offensichtlich (Teacher, Date)und (Date, Room).

_{(Teacher, Room) ist kein Superkey, weil ich die Tabelle im nächsten Quartal vervollständigen werde und möglicherweise eine Reihe wie diese habe (Herr Smith hat sich nicht bewegt!):}

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

Was können wir daraus schließen? (1) ist eine informelle, aber korrekte Formulierung von 1NF. Aus (2) sehen wir, dass es kein "Nicht-Prim-Attribut" gibt: 2NF und 3NF werden kostenlos vergeben.

Mein Tagebuch ist 3NF. Gut! Nein, nicht wirklich, weil kein Datenmodellierer dies in einem DB-Schema akzeptieren würde. Das RoomAttribut ist vom Attribut abhängig Teacher(wieder: Lehrer bewegen sich nicht!), Aber das Schema spiegelt diese Tatsache nicht wider. Was würde ein vernünftiger Datenmodellierer tun? Teilen Sie die Tabelle in zwei Teile:

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

Und

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

3NF befasst sich jedoch nicht mit Abhängigkeiten von Hauptattributen. Dies ist das Problem: Die 3NF-Konformität reicht unter bestimmten Umständen nicht aus, um ein solides Tabellenschema zu gewährleisten .

Bei BCNF ist es Ihnen egal, ob das Attribut ein Hauptattribut ist oder nicht, in 2NF- und 3NF-Regeln. Für jede nicht triviale Abhängigkeit (Teilmengen werden offensichtlich durch ihre Obermengen bestimmt) ist die Determinante ein vollständiger Superschlüssel. Mit anderen Worten, nichts wird durch etwas anderes als einen vollständigen Superschlüssel bestimmt (ausgenommen triviale FDs). (Siehe andere Antworten für die formale Definition).

Sobald es darauf Roomankommt Teacher, Roommuss es sich um eine Teilmenge von Teacher(das ist nicht der Fall) oder Teacherum einen Superschlüssel handeln (das ist in meinem Tagebuch nicht der Fall, aber das ist der Fall, wenn Sie die Tabelle teilen).

Zusammenfassend: BNCF ist strenger, aber meiner Meinung nach leichter zu verstehen als 3NF:

• In den meisten Fällen ist BCNF identisch mit 3NF.
• In anderen Fällen ist BCNF das, was Sie denken / hoffen, was 3NF ist.