Datenbanken 6: Normalisierung

Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Datenbanken 6: Normalisierung
Ronald Ortner
26. IV. 2016
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Outline
1
Organisatorisches
2
SQL
3
Überblick Datenbankdesign
4
Normalisierung
Erste Normalform
Zweite Normalform
Dritte Normalform
Boyce-Codd Normal Form
Vierte Normalform
Ronald Ortner
Normalisierung
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Organisatorisches
In zwei Wochen, am 10. Mai findet der zweite Zwischentest statt.
Aufsicht übernimmt Martin Antenreiter.
VO entfällt an diesem Tag.
Fragestunde bereits nächste Woche
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
SQL
Nachbesprechung Zwischentest
korrelierte Subqueries
Ronald Ortner
Normalisierung
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Nachbesprechung Zwischentest
LIKE vs. =
COUNT vs. SUM
Subquery statt WHERE
HAVING statt WHERE
DISTINCT für Abgabesystem
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Datenbankdesign bisher:
zeichne Entitäten, Relationen, und Attribute in ein ER-Diagramm
leite aus dem ER-Diagramm ein Datenbankschema ab
Nun beschäftigen wir uns mit einem verfeinerten Zugang
(’Normalisierung’).
Die Grundlage dafür ist der Begriff der funktionalen Abhängigkeit.
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Funktionale Abhängigkeit
Zur Erinnerung:
Definition (funktionale Abhängigkeit)
Gegeben sei ein abstraktes relationales Datenbankschema R
sowie (Mengen von) Attribute(n) α, β in R.
Wir sagen, dass β funktional abhängig von α ist (α → β), wenn für alle
Realisierungen R of R:
Immer wenn zwei Tupel (Zeilen) dieselben Werte für α haben, so
haben sie auch gleiche Werte für β.
Achtung:
Für unsere Belange ist nur diese Art von Abhängigkeit relevant.
Andere Formen von Abhängigkeit (z.B. Korrelation) spielen keine Rolle
und dürfen nicht mit funktionaler Abhängigkeit verwechselt werden!
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Normalisierung: Ausblick
Wir kennen inzwischen:
funktionale Abhängigkeiten (FDs)
Eigenschaften guter Zerlegungen
(Verlustlosigkeit, Abhängigkeitserhaltung)
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Normalisierung: Ausblick
Wir kennen inzwischen:
funktionale Abhängigkeiten (FDs)
Eigenschaften guter Zerlegungen
(Verlustlosigkeit, Abhängigkeitserhaltung)
Wir hätten gerne:
guten Weg, um eine gegebene Relation R in kleinere Relationen
zu zerlegen
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Normalisierung: Ausblick
Wir kennen inzwischen:
funktionale Abhängigkeiten (FDs)
Eigenschaften guter Zerlegungen
(Verlustlosigkeit, Abhängigkeitserhaltung)
Wir hätten gerne:
guten Weg, um eine gegebene Relation R in kleinere Relationen
zu zerlegen
Wir machen dies über:
Schritt-für-Schritt Normalisierung
Mit jedem Schritt erreichen wir eine höhere Normalisierungsstufe
(1 bis 4).
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Normalisierung: Ausblick
Wir hätten gerne:
guten Weg, um eine gegebene Relation R in kleinere Relationen
zu zerlegen
Wir machen dies über:
Schritt-für-Schritt Normalisierung
Mit jedem Schritt erreichen wir eine höhere Normalisierungsstufe
(1 bis 4).
Normalisierung erreicht:
verlustlose Zerlegung
manchmal auch abhängigkeitserhaltende Zerlegung
In den entstehenden Relationen gibt es nur mehr interessante
FDs zwischen Schlüssel- und Nichtschlüsselattributen.
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Normalisierung
Alternatives Material zu Normalisierung:
Kapitel 2 von
Andreas Meier: “Relationale und postrelationale Datenbanken”,
Springer (innerhalb der MUL frei als pdf zum Download)
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Erste Normalform
Outline
1
Organisatorisches
2
SQL
3
Überblick Datenbankdesign
4
Normalisierung
Erste Normalform
Zweite Normalform
Dritte Normalform
Boyce-Codd Normal Form
Vierte Normalform
Ronald Ortner
Normalisierung
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Erste Normalform
Erste Normalform
Definition (1NF)
Eine Relation ist in 1NF, wenn alle Attribute atomar sind.
Diese Voraussetzung haben wir bereits gemacht.
Beispiel einer Tabelle/Relation, die nicht in 1NF:
Ronald Ortner
Vater
Mutter
Kinder
Karl
Ronald
Andreas
Maria
Elisabeth
Marianne
{Fritz, Franziska}
{Hannes, Kathrin}
{Sophia}
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Erste Normalform
Erste Normalform – Beispiel
Beispiel einer Tabelle/Relation, die nicht in 1NF:
Vater
Mutter
Kinder
Karl
Ronald
Andreas
Maria
Elisabeth
Marianne
{Fritz, Franziska}
{Hannes, Kathrin}
{Sophia}
→ kann leicht in 1NF konvertiert werden:
Ronald Ortner
Vater
Mutter
Kind
Karl
Karl
Ronald
Ronald
Andreas
Maria
Maria
Elisabeth
Elisabeth
Marianne
Fritz
Franziska
Hannes
Kathrin
Sophia
Organisatorisches
SQL
Überblick Datenbankdesign
Zweite Normalform
Outline
1
Organisatorisches
2
SQL
3
Überblick Datenbankdesign
4
Normalisierung
Erste Normalform
Zweite Normalform
Dritte Normalform
Boyce-Codd Normal Form
Vierte Normalform
Ronald Ortner
Normalisierung
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Zweite Normalform
Zweite Normalform
Definition (2NF)
Eine Relation ist in 2NF, wenn sie in 1NF ist und jedes
Nichtschlüsselattribut voll funktional abhängig von jedem
Kandidatenschlüssel ist.
(Zur Erinnerung: β ist voll funktional abhängig von α, wenn α → β mit
α minimal.)
Intuition: Jedes Attribut im Schlüssel ist wichtig.
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Zweite Normalform
Zweite Normalform – Beispiel
Betrachten folgende Tabelle mit Studenteninformationen:
(Annahme: nur ein Studium pro Student)
Vname
Nname
MNr
Stkz
Studium
LvaNr
Lva
Datum
Note
Wie sieht Schlüssel in dieser Tabelle aus?
D.h. welche Werte müssen festgelegt werden, um eine Zeile eindeutig
zu identifizieren?
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Zweite Normalform
Zweite Normalform – Beispiel
Betrachten folgende Tabelle mit Studenteninformationen:
(Annahme: nur ein Studium pro Student)
Vname
Nname
MNr
Stkz
Studium
LvaNr
Lva
Datum
Note
Wie sieht Schlüssel in dieser Tabelle aus?
D.h. welche Werte müssen festgelegt werden, um eine Zeile eindeutig
zu identifizieren?
Legt man Matrikelnummer, Lehrveranstaltungsnummer sowie Datum
fest, kann es zu den gegebenen Werten nur eine Zeile in der Tabelle
geben.
{MNr,LvaNr,Datum} bildet (Super-)Schlüssel der Tabelle.
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Zweite Normalform
Zweite Normalform – Beispiel
Vname
Nname
MNr
Stkz
Studium
LvaNr
Lva
Datum
Note
Listen für jedes Nichtschlüsselattribut jene Schlüsselattribute auf, von
denen es voll funktional abhängt:
Vname:
Nname:
Stkz:
Studium:
Lva:
Note:
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Zweite Normalform
Zweite Normalform – Beispiel
Vname
Nname
MNr
Stkz
Studium
LvaNr
Lva
Datum
Note
Listen für jedes Nichtschlüsselattribut jene Schlüsselattribute auf, von
denen es voll funktional abhängt:
Vname: MNr
Nname:
Stkz:
Studium:
Lva:
Note:
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Zweite Normalform
Zweite Normalform – Beispiel
Vname
Nname
MNr
Stkz
Studium
LvaNr
Lva
Datum
Note
Listen für jedes Nichtschlüsselattribut jene Schlüsselattribute auf, von
denen es voll funktional abhängt:
Vname: MNr
Nname: MNr
Stkz:
Studium:
Lva:
Note:
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Zweite Normalform
Zweite Normalform – Beispiel
Vname
Nname
MNr
Stkz
Studium
LvaNr
Lva
Datum
Note
Listen für jedes Nichtschlüsselattribut jene Schlüsselattribute auf, von
denen es voll funktional abhängt:
Vname: MNr
Nname: MNr
Stkz: MNr
Studium:
Lva:
Note:
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Zweite Normalform
Zweite Normalform – Beispiel
Vname
Nname
MNr
Stkz
Studium
LvaNr
Lva
Datum
Note
Listen für jedes Nichtschlüsselattribut jene Schlüsselattribute auf, von
denen es voll funktional abhängt:
Vname: MNr
Nname: MNr
Stkz: MNr
Studium: MNr
Lva:
Note:
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Zweite Normalform
Zweite Normalform – Beispiel
Vname
Nname
MNr
Stkz
Studium
LvaNr
Lva
Datum
Note
Listen für jedes Nichtschlüsselattribut jene Schlüsselattribute auf, von
denen es voll funktional abhängt:
Vname: MNr
Nname: MNr
Stkz: MNr
Studium: MNr
Lva: LvaNr
Note:
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Zweite Normalform
Zweite Normalform – Beispiel
Vname
Nname
MNr
Stkz
Studium
LvaNr
Lva
Datum
Note
Listen für jedes Nichtschlüsselattribut jene Schlüsselattribute auf, von
denen es voll funktional abhängt:
Vname: MNr
Nname: MNr
Stkz: MNr
Studium: MNr
Lva: LvaNr
Note: MNr, LvaNr, Datum
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Zweite Normalform
Zweite Normalform – Beispiel
Vname
Nname
MNr
Stkz
Studium
LvaNr
Lva
Datum
Note
Listen für jedes Nichtschlüsselattribut jene Schlüsselattribute auf, von
denen es voll funktional abhängt:
Vname: MNr
Nname: MNr
Stkz: MNr
Studium: MNr
Lva: LvaNr
Note: MNr, LvaNr, Datum
Diese Tabelle ist nicht in 2NF!
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Zweite Normalform
Zweite Normalform – Beispiel
bekommen 2NF, indem Attribute, die von derselben Menge von
Schlüsselattributen abhängen, in einer Tabelle zusammengefasst
werden:
MNr
LvaNr
Lva
Vname
Nname
MNr
Stkz
Studium
LvaNr
Datum
Note
Falls es kein Nichtschlüsselattribut gibt, das vom gesamten Schlüssel
abhängt, gibt es eine zusätzliche Tabelle, die nur die Schlüsselwerte
enthält!
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Dritte Normalform
Outline
1
Organisatorisches
2
SQL
3
Überblick Datenbankdesign
4
Normalisierung
Erste Normalform
Zweite Normalform
Dritte Normalform
Boyce-Codd Normal Form
Vierte Normalform
Ronald Ortner
Normalisierung
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Dritte Normalform
Dritte Normalform
Definition (3NF)
Eine Relation ist in 3NF, wenn sie in 1NF ist und für jede FD α → β
mindestens eine der folgenden Bedingungen gilt:
1
β ⊆ α, d.h. die FD α → β ist trivial,
2
β ist in einem Kandidatenschlüssel enthalten,
3
α ist ein Superschlüssel.
Insbesondere ist eine Relation nicht in 3NF, wenn es FDs zwischen
Attributen gibt, die nicht Teil eines (Kandidaten-/Super-)Schlüssels
sind.
Intuition: wollen keine FDs zwischen Nichtschlüsselattributen
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Dritte Normalform
Dritte Normalform – Beispiel
Beispiel.
MNr
LvaNr
Ronald Ortner
Lva
Vname
Nname
MNr
Stkz
Studium
LvaNr
Datum
Note
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Dritte Normalform
Dritte Normalform – Beispiel
Beispiel.
MNr
LvaNr
Lva
Vname
Nname
MNr
Stkz
Studium
LvaNr
Datum
Note
Die FD Stkz → Studium erfüllt keine der Bedingungen zur 3NF..
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Dritte Normalform
Dritte Normalform – Beispiel
Beispiel.
Zerlegung, die 3NF erfüllt:
MNr
Vname
LvaNr
Ronald Ortner
Lva
Nname
Stkz
MNr
Stkz
LvaNr
Datum
Studium
Note
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Dritte Normalform
Synthesealgorithmus für 3NF
Gegeben: Relation R, Menge F von FDs
Wir wollen: verlustlose und abhängigkeitserhaltende Zerlegung
R1 , . . . , Rn , sodass jedes Ri in 3NF ist
Algorithmus:
1
Bestimme kanonische Überdeckung Fc von F (siehe Unit 5).
2
Lege für jede FD α → β in Fc eine Relation Rα := α ∪ β an
(und bestimme entsprechende Menge von FDs Fα ).
3
Wenn eine der Relationen Rα einen Kandidatenschlüssel von R
enthält, sind wir fertig.
Ansonsten lege weitere Relation Rκ für einen
Kandidatenschlüssel κ von R an (mit Fκ = ∅).
4
Lösche Relationen Rα0 , die in anderen Relationen Rα enthalten
sind, d.h. Rα0 ⊆ Rα .
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Dritte Normalform
Synthesealgorithmus – Beispiel
Betrachten folgende Tabelle mit Studenteninformationen:
(Annahme: nur ein Studium pro Student)
Vname
Nname
MNr
Stkz
Studium
Funktionale Abhängigkeiten:
MNr → Vname, Nname, Stkz, Studium
Stkz → Studium
LvaNr → Lva
MNr, LvaNr, Datum → Note
Ronald Ortner
LvaNr
Lva
Datum
Note
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Dritte Normalform
Synthesealgorithmus – Beispiel
Betrachten folgende Tabelle mit Studenteninformationen:
(Annahme: nur ein Studium pro Student)
Vname
Nname
MNr
Stkz
Studium
Kanonische funktionale Abhängigkeiten:
MNr → Vname, Nname, Stkz
Stkz → Studium
LvaNr → Lva
MNr, LvaNr, Datum → Note
Ronald Ortner
LvaNr
Lva
Datum
Note
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Dritte Normalform
Synthesealgorithmus – Beispiel
Betrachten folgende Tabelle mit Studenteninformationen:
(Annahme: nur ein Studium pro Student)
Vname
Nname
MNr
Stkz
Tabellen:
MNr, Vname, Nname, Stkz
Stkz, Studium
LvaNr, Lva
MNr, LvaNr, Datum, Note
Ronald Ortner
Studium
LvaNr
Lva
Datum
Note
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Dritte Normalform
Synthesealgorithmus – Beispiel
Betrachten folgende Tabelle mit Studenteninformationen:
(Annahme: nur ein Studium pro Student)
Vname
Nname
MNr
Stkz
Studium
LvaNr
Lva
Datum
Tabellen:
MNr, Vname, Nname, Stkz
Stkz, Studium
LvaNr, Lva
MNr, LvaNr, Datum, Note
Die letzte Tabelle enthält Kandidatenschlüssel der ursprünglichen
Tabelle, also sind wir fertig.
Ronald Ortner
Note
Organisatorisches
SQL
Überblick Datenbankdesign
Boyce-Codd Normal Form
Outline
1
Organisatorisches
2
SQL
3
Überblick Datenbankdesign
4
Normalisierung
Erste Normalform
Zweite Normalform
Dritte Normalform
Boyce-Codd Normal Form
Vierte Normalform
Ronald Ortner
Normalisierung
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Boyce-Codd Normal Form
Boyce-Codd Normalform
Definition (BCNF)
Eine Relation ist in BCNF, wenn sie in 1NF ist und für jede FD α → β
mindestens eine der folgenden eine der folgenden Bedingungen gilt:
1
β ⊆ α, d.h. die FD α → β ist trivial,
2
α ist ein Superschlüssel.
Unterschied zu 3NF:
β darf nicht mehr Teil eines Kandidatenschlüssels sein.
Intuition: Wie für 3NF wollen wir für BCNF keine FDs zwischen
Nichtschlüsselattributen haben (inkl. Attribute, die Teil eines
Kandidatenschlüssels sind, aber nicht als Primärschlüssel verwendet
werden).
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Boyce-Codd Normal Form
Boyce-Codd Normalform – Beispiel
Beispiel.
MNr
LvaNr
Semester
Semesterabk
WS 2015/16
W15
Datum
Note
Die Relation zwischen Semester und Semesterabk ist 1:1,
sodass { MNr, LvaNr, Semester, Datum } ein
Kandidatenschlüssel ist.
Wir haben FDs:
{Semester}→{Semesterabk} und
{Semesterabk}→{Semester}
Weder Semster noch Semesterabk ist Superschlüssel, noch
sind die FDs trivial.
Tabelle ist nicht in BCNF
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Boyce-Codd Normal Form
Boyce-Codd Normalform – Beispiel
Lösung: neue Tabelle für Semester
MNr
LvaNr
Semesterabk
Semesterabk
Ronald Ortner
Datum
Semester
Note
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Boyce-Codd Normal Form
Dekompositionsalgorithmus für BCNF
Gegeben: Relation R, Menge F von FDs
Wir wollen: Zerlegung R1 , . . . , Rn in BCNF
Dekompositionsalgorithmus:
Initialisiere Z := {R};
while (es gibt Ri in Z , das nicht in BCNF) do
1
Finde FD α → β in Ri mit α ∩ β = ∅ und α 6→ Ri .
2
Zerlege Ri in Ri1 := α ∪ β und Ri2 := Ri − β.
3
Ersetze Ri in Z durch Ri1 und Ri2 , d.h.
Z := (Z − {Ri }) ∪ {Ri1 , Ri2 }.
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Boyce-Codd Normal Form
3NF vs. BCNF
Der Synthesealgorithmus garantiert Zerlegung, die
verlustlos,
abhängigkeitserhaltend und
in 3NF ist.
Der Dekompositionsalgorithmus garantiert Zerlegung, die
verlustlos und
in BCNF ist.
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Boyce-Codd Normal Form
3NF vs. BCNF
Der Synthesealgorithmus garantiert Zerlegung, die
verlustlos,
abhängigkeitserhaltend und
in 3NF ist.
Der Dekompositionsalgorithmus garantiert Zerlegung, die
verlustlos und
in BCNF ist.
Unglücklicherweise gilt:
In einigen Fällen ist eine BCNF Zerlegung nicht
abhängigkeitserhaltend.
In diesen Fällen gibt man sich mit 3NF zufrieden.
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Vierte Normalform
Outline
1
Organisatorisches
2
SQL
3
Überblick Datenbankdesign
4
Normalisierung
Erste Normalform
Zweite Normalform
Dritte Normalform
Boyce-Codd Normal Form
Vierte Normalform
Ronald Ortner
Normalisierung
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Vierte Normalform
Vierte Normalform und mehrwertige Abhängigkeiten
Beispiel:
möchten gerne Sprach- und Sportkurse für Studierende in Tabelle
speichern:
MNr
Sprachkurs
Sportkurs
1335335
1335335
1335335
1335335
1335335
1335335
Italienisch
Italienisch
Italienisch
Spanisch
Spanisch
Spanisch
Schifahren
Fechten
Fußball
Schifahren
Fechten
Fußball
Es ist offensichtlich keine gute Idee, zwei (oder mehr) N : M
Relationen in einer Tabelle zu speichern.
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Vierte Normalform
Mehrwertige Abhängigkeiten
Die Abhängigkeiten
{MNr} →→ {Sprachkurs} und
{MNr} →→ {Sportkurs}
sind sogenannte mehrwertige Abhängigkeiten (MVDs).
Idee: Bei FD α → β bestimmt gegebener Wert für α eindeutig einen
Wert für β. Bei MVD α →→ β bestimmt gegebener Wert für α eindeutig
eine Menge von Werten für β.
Definition (MVD)
β ist mehrwertig abhängig von α (Notation: α →→ β), wenn es für alle
Tupel mit identischen α-Werten mehrere Tupel mit vertauschten
β-Werten gibt.
(MVDs sind eine Verallgemeinerung von FDs.)
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Vierte Normalform
Mehrwertige Abhängigkeiten
Definition (MVD)
β ist mehrwertig abhängig von α (Notation: α →→ β), wenn es für alle
Tupel mit identischen α-Werten mehrere Tupel mit vertauschten
β-Werten gibt.
Im Beispiel:
Wenn es Zeilen
1335335, Italienisch, Fechten und
1335335, Spanisch, Fußball
gibt, dann auch Zeilen
1335335, Spanisch, Fechten und
1335335, Italienisch, Fußball.
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Vierte Normalform
Vierte Normalform
Idee: Keine Tabelle enthält mehr als eine mehrwertige Relation.
Definition (4NF)
Eine Relation R ist in 4NF, wenn sie in 1NF ist und für jede MVD
α →→ β mindestens eine der folgenden Bedingungen gilt:
1
die MVD α →→ β ist trivial, d.h. entweder β ⊆ α oder β = R − α,
2
α ist ein Superschlüssel von R.
Anmerkung: Jede Relation in 4NF ist auch in BCNF.
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Vierte Normalform
Vierte Normalform – Beispiel
MVDs:
MNr
Sprachkurs
Sportkurs
1335335
1335335
1335335
1335335
1335335
1335335
Italienisch
Italienisch
Italienisch
Spanisch
Spanisch
Spanisch
Schifahren
Fechten
Fußball
Schifahren
Fechten
Fußball
{MNr} →→ {Sprachkurs} und
{MNr} →→ {Sportkurs}
Tabelle nicht in 4NF
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Vierte Normalform
Vierte Normalform – Beispiel
Beispiel.
MNr
Sprachkurs
1335335
1335335
Italienisch
Spanisch
Ronald Ortner
MNr
Sportkurs
1335335
1335335
1335335
Schifahren
Fechten
Fußball
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Vierte Normalform
Verallgemeinerter Dekompositionsalgorithmus für 4NF
Gegeben: Relation R, Menge F von MVDs
Wir wollen: Zerlegung R1 , . . . , Rn in 4NF
Verallgemeinerter Dekompositionsalgorithmus:
Initialisiere Z := {R};
while (es gibt Ri in Z , das nicht in 4NF) do
1
Finde MVD α →→ β in Ri mit α ∩ β = ∅ und α 6→ Ri .
2
Zerlege Ri in Ri1 := α ∪ β und Ri2 := Ri − β.
3
Ersetze Ri in Z durch Ri1 und Ri2 , d.h.
Z := (Z − {Ri }) ∪ {Ri1 , Ri2 }.
(Nachdem jede Relation in 4NF auch in BCNF ist, gibt es Fälle, wo
eine 4NF Zerlegung nicht abhängigkeitserhaltend ist.)
Ronald Ortner
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Vierte Normalform
Weiteres Beispiel
Datenbank Personalabteilung:
pers_no
name
lohn
abt
chef
projekt
FDs:
{pers_no} → {name, lohn, abt, chef}
{abt} → {chef}
{chef} → {abt}
MVDs:
{pers_no} →→ {projekt}
{pers_no} →→ {kurs}
Ronald Ortner
kurs
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Vierte Normalform
Weiteres Beispiel
Wenden Dekompositionsalgorithmus an:
FD {pers_no} → {name, lohn, abt, chef} gibt Zerlegung
pers_no
name
pers_no
Ronald Ortner
lohn
projekt
abt
kurs
chef
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Vierte Normalform
Weiteres Beispiel
Wenden Dekompositionsalgorithmus an:
FD {abt} → {chef} gibt Zerlegung
pers_no
name
lohn
pers_no
Ronald Ortner
abt
projekt
abt
kurs
chef
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Vierte Normalform
Weiteres Beispiel
Wenden Dekompositionsalgorithmus an:
MVDs {pers_no} →→ {projekt} und {pers_no} →→ {kurs}
geben Zerlegung
pers_no
pers_no
Ronald Ortner
name
lohn
projekt
abt
abt
pers_no
chef
kurs
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Vierte Normalform
Weiteres Beispiel
Wenden Dekompositionsalgorithmus an:
MVDs {pers_no} →→ {projekt} und {pers_no} →→ {kurs}
geben Zerlegung
pers_no
pers_no
ist in 4NF
Ronald Ortner
name
lohn
projekt
abt
abt
pers_no
chef
kurs
Organisatorisches
SQL
Überblick Datenbankdesign
Normalisierung
Vierte Normalform
Weiteres Beispiel
Wenn mehr Informationen zu Projekten und Kursen gespeichert
werden sollen:
pers_no
pers_no
projekt_nr
Ronald Ortner
name
lohn
projekt_nr
name
...
abt
abt
chef
pers_no
kurs_nr
kurs_nr
name
...