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

Habe ich gelesen, die Zitat :
Daten hängt von der Taste [1NF], die ganze Taste [2NF] und nichts als der Schlüssel [3NF].

Aber ich habe Schwierigkeiten zu verstehen, 3.5 NF oder BCNF wie es heißt. Hier ist, was ich verstehe :

  • BCNF ist strenger als 3NF
  • linke Seite einer FD in der Tabelle muss ein superkey (oder zumindest ein Kandidaten-Schlüssel)

Also, warum ist es dann, dass einige 3NF-Tabellen sind nicht in BCNF? Ich meine, die 3NF zitieren, der ausdrücklich sagt: "nichts aber der Schlüssel", was bedeutet, dass alle Attribute ausschließlich abhängig von der primary key. Der Primärschlüssel ist, nachdem alle, ein Kandidaten-Schlüssel, bis Sie gewählt, um unsere Primärschlüssel.

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

InformationsquelleAutor der Frage Arnab Datta | 2011-12-08

  1. 140

    Ihre pizza genau drei topping-Typen:

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

    Also bestellen wir zwei Pizzen und wählen Sie die folgenden toppings:

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

    Warten Sie eine Sekunde, mozzarella kann nicht sein, die beiden Käse und Fleisch! Und Wurst ist kein Käse!

    Wir müssen verhindern, dass diese Art von Fehler zu machen, mozzarella immer Käse. Wir sollten einen separaten Tabelle für diese, also wir schreiben eine Tatsache, die in nur einem Ort.

    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, dass ein 8-jähriger kann verstehen. Hier ist die eher technische version.

    BCNF anders wirkt als 3NF nur, wenn es mehrere sich überlappende Kandidaten Tasten.

    Der Grund dafür ist, dass die funktionale Abhängigkeit X -> Y ist natürlich wahr, wenn Y ist eine Teilmenge von X. Also in einer Tabelle, die nur einen Kandidaten-Schlüssel, und ist in 3NF, es ist bereits in BCNF, weil es keine Spalte (entweder key oder nicht key) , ist funktional abhängig von irgendetwas außer dem Schlüssel.

    Weil jede pizza muss genau ein jedes topping geben, wissen wir, dass (Pizza Topping-Typ) ist ein Kandidaten-Schlüssel. Wir wissen auch intuitiv, dass ein Belag nicht gehören verschiedenen Arten gleichzeitig. So (Pizza-Belag) muss eindeutig sein und ist daher auch ein candidate key. So haben wir zwei sich überlappende Kandidaten Tasten.

    Ich zeigte eine Anomalie, wo wir markiert mozarella als das falsche topping geben. Wir wissen, dass dies falsch ist, aber die Regel macht, dass es falsch ist, eine Abhängigkeit Topping -> Topping Type ist keine gültige Abhängigkeiten BCNF für diese Tabelle. Es ist eine Abhängigkeit, die auf etwas anderes als einen kompletten Kandidaten-Schlüssel.

    Also um dies zu lösen, nehmen wir Richtfest Typ aus der Pizza-Tabelle und machen es zu einem nicht-Schlüssel-Attribut in einem Toppings Tabelle.

    InformationsquelleAutor der Antwort Bill Karwin

  2. 78

    Der feine Unterschied ist, dass die 3NF macht eine Unterscheidung zwischen Schlüssel-und nicht-Schlüssel-Attribute (auch als nicht-prime Attribute), während die BCNF nicht.

    Dies ist am besten zu erklären mit Zaniolo definition der 3NF entspricht der Codd ' s:

    Einer relation R ist in 3NF iff für jede nicht-triviale FD (X->A) zufrieden
    von R mindestens EINE der folgenden Bedingungen erfüllt ist:

    (a) X ein superkey für R, oder

    (b) a ist Ein Schlüsselattribut für R

    BCNF verlangt (a) ist aber nicht behandeln, (b) als ein besonderer Fall von seiner eigenen. In anderen Worten BCNF verlangt, dass jede nicht-triviale Determinante ist ein superkey auch die von Ihr abhängigen Attributen geschehen, ein Teil von einem Schlüssel.

    Einer relation R ist in BCNF iff für jede nicht-triviale FD (X->A) zufrieden
    von R die folgende Bedingung erfüllt ist:

    (a) X ein superkey für R

    BCNF ist daher strenger.

    Der Unterschied ist so subtil, dass das, was viele Menschen informell beschreiben als 3NF ist eigentlich BCNF. Zum Beispiel, du sagtest hier, dass 3NF bedeutet "Daten hängt von der Taste[s]... und nichts als die Schlüssel[s]", aber das ist wirklich eine informelle Beschreibung der BCNF und nicht 3NF. 3NF könnte genauer beschrieben werden als "nicht-Schlüssel-Datenhängt von den keys... und nichts als die Schlüssel".

    Ihnen auch gesagt:

    die 3NF zitieren, der ausdrücklich sagt: "nichts aber der Schlüssel", was bedeutet, dass alle
    Parametern hängt einzig und allein auf den Primärschlüssel.

    Das ist eine grobe Vereinfachung. 3NF und BCNF und alle Normalen Formen beschäftigen sich mit alle Kandidaten-Schlüssel und/oder superkeys, nicht nur eine "primäre" - Taste.

    InformationsquelleAutor der Antwort sqlvogel

  3. 21

    Der Unterschied zwischen BCNF und 3NF

    Mithilfe der BCNF-definition

    Wenn und nur wenn für alle Abhängigkeiten X → Y, die mindestens eine der folgenden Bedingungen halten:

    • X → Y eine triviale funktionale Abhängigkeit (Y ⊆ X), oder
    • X ist ein super-Schlüssel für die schema-R

    und die 3NF definition

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

    • X enthält (X → A ist trivial funktionale Abhängigkeit), oder
    • X ein superkey oder
    • Jedes element von A-X, die Menge Unterschied zwischen A und X, ist ein prime-Attribut (d.h., jedes Attribut in A-X enthalten ist, und in einigen Kandidaten-Schlüssel)

    Wir finden Sie unter den folgenden Unterschied in einfachen Worten:

    • In BCNF: Jeden partiellen Schlüssel (prim-Attribut) können nur hängt ein superkey,

    in der Erwägung, dass

    • In 3NF: Ein Teil-Schlüssel (prim-Attribut) können auch abhängig von einem Attribut, das nicht ein superkey (d.h. andere partielle Schlüssel/prime-Attribut oder gar eine nicht-prime Attribut).

    Wo

    1. Eine prime-Attribut ist ein Attribut gefunden, in der ein Kandidat Schlüssel, und
    2. Eine kandidatenschlüssel ist eine minimal-superkey für dieses Verhältnis, und
    3. Eine superkey ist ein Satz von Attributen einer relation sind Variablen, für die gilt, dass in allen Beziehungen zugeordnet, die variable gibt es keine zwei verschiedene Tupel (Zeilen), die die gleichen Werte für die Attribute in diesem set.Gleich ein superkey kann auch definiert werden als eine Menge von Attributen einer relation schema, auf dem alle Attribute des Schemas sind funktional abhängig. (Superkey enthält immer ein Kandidat Schlüssel/ein Kandidat Schlüssel ist immer eine Teilmenge von einem superkey. Sie können eine beliebige Attribut in einer relation zu erhalten, eine der superkeys.)

    Ist, keine Teilmenge (jede nicht triviale Teilmenge außer dem full set) eines Kandidaten-Schlüssel funktional abhängig von alles andere als ein superkey.

    Einer Tabelle/relation nicht in BCNF ist, unterliegen Anomalien wie die update-Anomalien in der pizza-Beispiel von einem anderen user. Leider

    • BNCF nicht immer erhalten werdenwährend
    • 3NF können immer erhalten werden.

    3NF Vs. BCNF-Beispiel

    Ein Beispiel für den Unterschied können derzeit gefunden werden, an "3NF Tabelle nicht treffen BCNF (Boyce–Codd normal form)" auf Wikipedia, wo die folgende Tabelle erfüllt 3NF, aber nicht BCNF, weil "Tennis Court" (einem partiellen Schlüssel/prime Attribut) davon abhängt, "Rate Type" (einem partiellen Schlüssel/prime-Attribut ist, dass nicht ein superkey), das ist eine Abhängigkeit, die wir ermitteln konnten, indem Sie die Kunden von der Datenbank -, der tennis-club:

    Heutigen 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

    In der Tabelle superkeys 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

    Die 3NF problem:
    Die partiellen Schlüssel/prime Attribut "Gericht" ist abhängig von etwas anderem als einem superkey. Stattdessen ist es abhängig von der partiellen Schlüssel/prime Attribut "Rate Type". Dies bedeutet, dass der Benutzer muss manuell die Frequenz ändern, geben Sie, wenn wir ein upgrade ein Gericht, oder ändern Sie manuell das Gericht, wenn zu wollen, gilt eine rate ändern.

    • Aber was ist, wenn die Benutzer-upgrades, die das Gericht aber nicht daran erinnern, um die Geschwindigkeit zu erhöhen? Oder was ist, wenn die falsche Art der rate angewendet wird, um ein Gericht?

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

    Die BCNF-Lösung:
    Wenn wir wollen, dass die oben genannten Tabelle in BCNF können wir zerlegen die relation/Tabelle in die beiden folgenden Relationen/Tabellen (vorausgesetzt, wir wissen, dass die Satz-Typ abhängig ist, nur dem Gericht und den status der Mitgliedschaft, die wir entdecken konnten, indem Sie die Kunden in unserer Datenbank, der Besitzer von tennis-club):

    Kurstypen (BCNF und die schwächeren 3NF, die indirekt durch BCNF)

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

    Heutigen Tennisplatz Buchungen (BCNF und die schwächeren 3NF, die indirekt durch 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 Gelöst:
    Nun, wenn wir ein upgrade des Gerichts können wir garantieren, dass die Art der rate, wird diese änderung widerzuspiegeln, und wir können nicht laden Sie den falschen Preis für ein Gericht.

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

    InformationsquelleAutor der Antwort AGéoCoder

  4. 5

    Alle gute Antworten. Um es in einfacher Sprache [BCNF] Keine teilweise-Taste kann abhängig von einem Schlüssel.

    ich.e Keine Teilmenge ( ich.e) jede nicht-triviale Teilmenge außer dem full set ) eines Kandidaten-Schlüssel funktional abhängig von einigen Kandidaten-Schlüssel.

    InformationsquelleAutor der Antwort smartnut007

  5. 4

    Antworten von 'smartnut007', 'Bill Karwin " und " sqlvogel' sind ausgezeichnet. Doch lassen Sie mich eine interessante Perspektive.

    Gut, wir haben prime und non-prime-Tasten.

    Wenn wir uns darauf konzentrieren, wie nicht-Primzahlen hängt von Primzahlen, sehen wir zwei Fälle:

    Nicht-Primzahlen kann abhängig sein oder nicht.

    • Wenn abhängig: sehen wir Sie verlassen müssen, auf eine volle Kandidaten-Schlüssel. Dies ist 2NF.

    • Wenn Sie nicht abhängig: es kann keine Abhängigkeit oder transitive Abhängigkeit

      • Auch nicht transitive Abhängigkeit: Nicht wissen was Normalisierung theoretisch damit befasst.
      • Wenn transitiv abhängig: Es gilt als unerwünscht. Dies ist 3NF.

    Was über die Abhängigkeiten zwischen Primzahlen?

    Nun sehen Sie, wir sind nicht der Bewältigung der Abhängigkeit zu Primzahlen von entweder 2. oder 3. NF.
    Weitere solche Abhängigkeit, wenn überhaupt, nicht wünschenswert und somit haben wir eine einzige Regel, um dagegen anzugehen. Dies ist BCNF.

    Unter Bezugnahme auf das Beispiel von Bill Karwin's hier posten, Sie werden feststellen, dass beide 'Topping' und 'Topping Geben' sind die wichtigsten Tasten und eine Abhängigkeit. Hatten Sie nicht-Primzahlen mit Abhängigkeit, dann 3NF hätte Sie getreten.

    Hinweis:

    Die definition von BCNF ist sehr allgemein und ohne Unterscheidung der Attribute zwischen prime und non-prime. Doch in der oben beschriebenen Weise zu denken, hilft zu verstehen, wie einige Anomalie sickerte durch, auch nach dem 2. und 3. NF.

    Fortgeschrittene Thema: Mapping generische BCNF zu 2NF & 3NF

    Jetzt, dass wir wissen, BCNF enthält eine generische definition ohne Bezug zu irgendeiner Primzahl/nicht-prime-Eigenschaften, lassen Sie uns sehen, wie BCNF und 2/3 NF s verwandt sind.


    Erste, BCNF verlangt (außer dem trivialen Fall), dass für jede funktionale Abhängigkeit X -> Y (FD), X ist super-Taste.
    Wenn Sie nur zu prüfen, alle FD, dann haben wir drei Fälle - (1) X und Y Beide nicht prim, (2) Beide prim und (3) X prim und Y nicht prim, das verwerfen der (unsinnigen) Fall X nicht-prime-und Y-prime.


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


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


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

    InformationsquelleAutor der Antwort KGhatak

Schreibe einen Kommentar