4. Der Königsweg: Normalisierung

4.1 Grundlagen

4.1.1 Was ist Normalisierung?

Die Normalisierung erfolgt in mehreren Schritten:

• Nullte Normalform
• Erster Normalform (1NF)
• Zweite Normalform (2NF)
• Dritte Normalform (3NF)
• Boyce-Codd Normalform (BCNF)
• Vierte Normalform (4NF)
• Fünfte Normalform (5NF)

Wir werden im folgenden als Beispiel die Reisekostentabelle aus Abschnitt 3 betrachten.
Wir werden auch aufzeigen, in welche Tabelle die berechneten Datenfelder "Gesamtvergütung" und "Summe" (siehe Formular in Abschnitt 1) aufzunehmen sind, wenn sie nicht entfernt werden.

4.1.2 Das Schlüsselkonzept

• Ein Schlüssel ist eine Menge von Attributen (also eines oder mehrere), die eine Datenzeile (Tupel) einer Tabelle eindeutig identifiziert

• Ein Schlüsselkandidat ist ein Schlüssel mit minimaler Anzahl Attribute

• Eine Relation kann mehrere Schlüsselkandidaten haben

• Ein Primärschlüssel ist ein beliebig ausgewählter Schlüsselkandidat, der zur eindeutigen Identifizierung jeder Zeile benutzt wird. Besteht der Primärschlüssel aus mehreren Attributen (dies ist dann der Fall, wenn ein Attribut zur eindeutigen Identifizierung nicht ausreicht), wird er als zusammengsetzter Primärschlüssel bezeichnet.

 
• Ein Schlüsselattribut ist ein Attribut, das Teil mindestens eines Schlüsselkandidaten ist. Alle anderen Attribute sind Nicht-Schlüsselattribute

Fettgedruckte Attribute: Primärschlüssel
 

4.2 Nullte Normalform

4.3 Erste Normalform (1NF)

4.3.1 Definition

4.3.2 Erklärung

Abhilfe:
Attribute mit Nicht-atomaren-Attributwerten werden in mehrere Attribute aufgeteilt. Eine Wiederholungsgruppe wird aus der Tabelle entfernt und in einer eigenen Tabelle untergebracht.

Unsere Reisekostentabelle enthält keine nicht-atomaren Attributwerte, ist also bereits in der ersten Normalform.
 

4.4 Zweite Normalform (2NF)

4.4.1 Definition

4.4.2 Erklärung

Vollständig funktional abhängig bedeutet, daß das Nicht-Schlüsselattribut nicht nur von einem Teil der Attribute eines zusammengesetzten Schlüsselkandidaten funktional abhängig ist, sondern von allen Teilen.

Beispiel:
In der Reisekostentabelle sind die Attribute "Datum", "Name", "Vorname", "Straße", "PLZ" und "Ort" nur funktional abhängig vom Attribut "Rechnungsnummer" und völlig unabhängig vom Attribut "Kostenart".
Das Attribut "Einzelvergütung" ist dagegen nur funktional abhängig von der "Kostenart" und hat nichts mit der "Rechnungsnummer" zu tun. Lediglich das Attribut "Anzahl" ist vom zusammengesetzten Primärschlüssel voll funktional abhängig.

Abhilfe:
Datenfelder, die von einem Schlüsselkandidaten (hier nur der Primärschlüssel) nicht vollständig funktional abhängig sind, werden in weiteren Tabellen untergebracht. Der Teil des Schlüsselkandidaten, von dem ein ausgelagertes Datenfeld funktional abhängig ist, wird Primärschlüssel der neuen Tabelle. Als Ergebnis erhalten wird die drei folgenden Tabellen.
 

Fettgedruckte Attribute: Primärschlüssel

Das berechnete Attribut "Summe" wäre hier in der Tabelle "Reise" zu führen. Das berechnete Attribut "Gesamtvergütung" kann nicht in "Positionen" geführt werden, da es nur von der "Anzahl" und der "Kostenart" funktional abhängig ist, aber nicht von der Rechnungsnummer. Das Attribut "Gesamtvergütung" könnte dann in einer weiteren Tabelle "Vergütung" mit den Attributen "Kostenart", "Anzahl" und "Gesamtvergütung" ("Kostenart" und "Anzahl" wären dann zusammengesetzter Primärschlüssel) untergebracht werden. Die berechneten Datenfelder verbleiben, falls sie mitgeführt werden, auch bei den folgenden Normalisierungen in den genannten Tabellen.

Beachten Sie:

• Besteht der Primärschlüssel nur aus einem einzigen Attribut (ist er also nicht zusammengesetzt), so ist ein Datensatz in Erster Normalform bereits automatisch in Zweiter Normalform.

4.4.3 Verbindung zwischen Tabellen

1 : n Beziehung

Zwischen den Tabellen "Kostenarten" und "Positionen" besteht ebenfalls eine 1:n Beziehung, da jede in "Kostenarten" aufgeführte Kostenart mehrfach in der Tabelle "Positionen" erscheinen kann (nämlich bei verschiedenen Rechnungsnummern).

Dagegen besteht zwischen den Tabellen "Reise" und "Kostenarten" gar keine Beziehung, da sie kein gemeinsames Attribut aufweisen.

Wir werden in Abschnitt 5 näher auf Beziehungen zwischen Tabellen eingehen.
 

4.5 Dritte Normalform (3NF)

4.5.1 Definition

4.5.2 Erklärung

Beispiel:
In der Tabelle "Reise" sind die Attribute "Vorname", "Straße" und "PLZ" abhängig vom Attribut "Name", nicht vom Primärschlüssel. Außerdem ist "Ort" abhängig von "PLZ" (X=Rechnungsnummer, Y=PLZ, Z=Ort; zu jeder Rechnungsnummer gehört eine PLZ und zu jeder PLZ ein Ort, also zu jeder Rechnungsnummer ein Ort).

Abhilfe:
Die transitiv abhängigen Datenfelder werden in weitere Tabellen ausgelagert, da sie nicht direkt vom Schlüsselkandidaten abhängen, sondern nur indirekt.
Da ein Name nicht eindeutig ist, wird jedem Angestellten eine Personalnummer zugeordnet. Diese ist Primärschlüssel der neuen Tabelle "Personal". Alternativ könnte ein zusammengesetzter Primärschlüssel aus Name, Vorname und Geburtsdatum benutzt werden (dieser sollte hinreichend eindeutig sein).
 

Fettgedruckte Attribute: Primärschlüssel

Wiederum besteht zwischen den Tabellen "Personal" und "Reise" sowie zwischen "PLZ" und "Personal" eine 1:n Beziehung, da ein Mitarbeiter mit einer bestimmten Personalnummer mehrere Dienstreisen machen kann und mehrere Mitarbeiter dieselbe Postleitzahl haben können.

Nach der dritten Normalisierung ergeben sich also folgende Tabellen, Datenfelder und Beziehungen:

Beachten Sie:

• Bei der Festlegung der Beziehungen kommt es auf die Reihenfolge der Tabellen an:

Die Tabelle "PLZ" steht in einer 1:n Beziehung zur Tabelle "Personal", die Tabelle "Personal" dagegen in einer n:1 Beziehung (und nicht 1:n) zur Tabelle "PLZ"

• Eine Relationale Datenbank speichert nicht nur die Daten der Tabellen sondern auch die Beziehungen zwischen den Tabellen

• Die in Abschnitt 3.4 beschriebenen Beschränkungen der ursprünglichen Form der Reisekostentabelle sind nun überwunden, z. B. kann ein Angestellter in der Tabelle "Personal" bereits existieren, ohne jemals eine Reise gemacht zu haben

• Die drei folgenden Normalformen (BCNF, 4NF, 5NF) werden nur in seltenen Fällen benötigt. Die bisher betrachtete Reisekostendatenbank erfüllt bereits die Kriterien dieser Normalformen

4.6 Boyce-Codd Normalform (BCNF)

4.6.1 Definition

4.6.2 Erklärung

Die Boyce-Codd-Normalform ist eine Weiterentwicklung der Dritten Normalform. In der Dritten Normalform kann es vorkommen, daß ein Teil eines (zusammengesetzten) Schlüsselkandidaten funktional abhängig ist von einem Teil eines anderen Schlüsselkandidaten. Die Boyce-Codd-Normalform verhindert dies.

Beispiel:
Der Tabelle "Positionen" wird das Attribut "Kostenartnummer" hinzugefügt. Dieses Attribut ist eindeutig für jede "Kostenart". Dann sind "Rechnungsnummer" und "Kostenart" sowie "Rechnungsnummer" und "Kostenartnummer" zusammengesetzte Schlüsselkandidaten.
 

Fettgedruckte Attribute: Primärschlüssel
Kursiv gedruckte Attribute: weiterer Schlüsselkandidat

Die Relation "Positionen" ist in Erster Normalform, da sie keine Wiederholungsgruppe hat und in Zweiter Normalform, da "Anzahl" als einziges Nicht-Schlüsselattribut von beiden Schlüsselkandidaten voll funktional abhängig ist. Sie ist auch in Dritter Normalform, da es außer "Anzahl" keine weiteren Nicht-Schlüsselattribute gibt. Offensichtlich gibt es aber eine funktionale Abhängigkeit von "Kostenart" und "Kostenartnummer", die nichts mit der Rechnungsnummer zu tun hat.

Die Relation ist nicht in Boyce-Codd Normalform. Das Attribut "Kostenartnummer" ist Determinant, da "Kostenart" funktional abhängig von "Kostenartnummer" ist. Der Determinant ist aber nicht Schlüsselkandidat, sondern nur Teil eines Schlüsselkandidaten.

Abhilfe:
Aufteilung der Tabelle "Positionen" in die zwei folgenden Tabellen. Geht man von der ursprünglichen Reisekostendatenbank aus, so würde die Tabelle "Kostenarten" noch das Feld "Einzelvergütung" enthalten.
 

Beachten Sie:

• Jede Relation in Boyce-Codd-Normalform ist auch in Dritter Normalform

• Einen Unterschied zwischen Dritter Normalform und Boyce-Codd Normalform gibt es nur, wenn es mehrere Schlüsselkandidaten mit überlappenden Attributen gib

4.7 Vierte Normalform (4NF)

4.7.1 Definition

4.6.2 Mehrwertige Abhängigkeit (Multivalued Dependency, MVD)

Die Personalnummer bestimmt unter Umständen nicht nur ein einziges Haustier, sondern eine ganze Liste verschiedener Haustiere. Hier liegt eine mehrwertige Abhängigkeit (im Gegensatz zur funktionalen Abhängigkeit) vor. Eine mehrwertige Abhängigkeit einer Attributmenge Y von einer Attributmenge X ist trivial, wenn Y Teil von X ist oder die Relation nur aus X und Y besteht. Im Beispiel ist Y=Haustier, X=Personalnummer und die Relation besteht nur aus X und Y. Anschaulich: die mehrwertige Abhängigkeit ist trivial, wenn sich die Tabelle nicht weiter zerlegen läßt.

4.7.3 Erklärung

Zwischen Personalnummer und Haustier sowie zwischen Personalnummer und Fahrzeugtyp gibt es eine mehrwertige Abhängigkeit. Zwischen Haustier und Fahrzeugtyp gibt es keinerlei Abhängigkeit, so daß zu jeder Personalnummer alle Kombinationen dieser beiden Attribute auftauchen können. Die Relation ist in Boyce-Codd-Normalform, da es keine funktionale Abhängigkeit zwischen Attributen gibt. Die Personalnummer alleine ist aber kein Schlüsselkandidat der Relation.

Wie soll aber z. B. in dieser Tabelle eine Personalnummer gespeichert werden, zu der zwei Haustiere und zwei Fahrzeuge gehören? Mögliche Varianten:
 

NULL repräsentiert einen nicht vorhandenen Wert. Auf den ersten Blick ist die letzte Variante die sinnvollste, da hier klar hervorgeht, das zwischen "Haustier" und "Fahrzeugtyp" keinerlei Abhängigkeit besteht. Die sogenannte Existentielle Integrität verlangt aber, daß kein Schlüsselattribut einen NULL-Wert hat.

Abhilfe:
Aufteilung der Tabelle in zwei Tabellen:
 

Dann liegen nur noch triviale mehrwertige Abhängigkeiten vor und die Relationen sind in Vierter Normalform.

4.8 Fünfte Normalform (5NF)

4.8.1 Definition

Die Fünfte Normalform wird auch als Project Join Normalform (PJNF) bezeichnet.

4.8.2 Join-Abhängigkeit (Join Dependency)

Eine Relation R genügt der Join-Abhängigkeit (R1, R2, ..., Rn) genau dann, wenn R gleich dem Join von R1, R2, ..., Rn ist. Die R1, R2, ... sind Teilmengen aller Attribute von R. Eine Join-Abhängigkeit ist trivial, wenn ein Ri aus (R1, R2, ..., Rn) gleich R ist

Beispiel:
 

Da jede Kombination von Haustier und Fahrzeugtyp auftaucht, ist die Relation R=(Personalnummer, Haustier, Fahrzeugtyp) gleich dem Join von R1=(Personalnummer, Haustier) und R2=(Personalnummer, Fahrzeugtyp). Also genügt R der Join-Abhängigkeit (R1, R2).

4.8.3 Erklärung

Jedes Fach bietet verschiedene Kurse an, die von verschiedenen Teilnehmern besucht werden. Kein Teilnehmer besucht alle Kurse und kein Kurs wird von allen Teilnehmern besucht. Also sind alle drei Attribute wichtig, um die nötige Information darzustellen. Im Gegensatz zum obigen Beispiel bei der vierten Normalform gibt es keine mehrwertigen Abhängigkeiten, da "Kurs" und "Name" nicht unabhängig sind, sondern die Paarungen wichtige Information enthalten.

Die Relation enthält redundante Information, läßt sich aber nicht als Join von R1=(Fach, Kurs) und R2=(Fach, Name) darstellen (es tauchen überflüssige Zeilen auf). Die Relation genügt also nicht der Join-Abhängigkeit (R1, R2). Eine Aufteilung der Tabelle in die zwei Tabellen R1 und R2 ist nicht sinnvoll.
 

Wichtig:
Obwohl wir hier mehr Zeilen haben als vorher, haben wir plötzlich weniger Informationen, da die Information über die wirklichen Kombinationen von "Kurs" und "Name" teilweise verlorengeht.

Interessanterweise genügt die Relation aber zwei anderen Join-Abhängigkeiten, nämlich der trivialen Join-Abhängigkeit R=R1=(Fach, Kurs, Name) sowie der Join-Abhängigkeit R1=(Fach, Kurs), R2=(Fach, Name) und R3=(Kurs, Name). Wie man leicht nachprüft, ist R gleich dem Join von R3 mit dem Join von R1 und R2:
 

Ist die Relation dann in Fünfter Normalform?
Nein, da weder R1, R2 oder R3 Schlüsselkandidaten sind. Der einzige Schlüsselkandidat besteht aus allen drei Attributen "Fach", "Kurs" und "Name".

Abhilfe:
Aufteilung der Tabelle in die drei folgenden Tabellen (für die es dann nur noch triviale Join-Abhängigkeiten gibt):
 

Relationen in Fünfter Normalform lassen sich nicht weiter aufteilen.