Databases Reference
In-Depth Information
4.3
Zweite Normalform
Mit der zweiten Normalform wird eine wichtige Problemquelle
bei redundanter Datenhaltung in der Tabelle angegangen.
Projektmitarbeit
MiNr
Name
AbtNr
Abteilung
ProNr
Projekt
1
Egon
42
DB
1
Infra
1
Egon
42
DB
2
Portal
2
Erna
42
DB
2
Portal
2
Erna
42
DB
3
Frame
3
Uwe
43
GUI
1
Infra
3
Uwe
43
GUI
3
Frame
Abb. 4-8:
Aktuelle Tabelle Projektmitarbeit
In Abb. 4-8 ist die Tabelle Projektmitarbeit dargestellt. Da sie
nur einen Schlüsselkandidaten hat, kann dieser einfach einge-
zeichnet werden. Betrachtet man die Tabelle genauer und geht
auf die bekannten funktionalen Abhängigkeiten ein, so erkennt
man, dass es Nichtschlüsselattribute gibt, die nur von Teilen
des Schlüsselkandidaten abhängen, genauer gilt {MiNr}
→
{Name} und {ProNr}
{Projekt}. Dies bedeutet, dass in der Ta-
belle Details enthalten sind, die nichts mit dem gesamten
Schlüsselkandidaten zu tun haben. Eine solche Tabelle ist nicht
in zweiter Normalform.
→
Definition zweite Normalform:
Sei eine Tabelle in erster
Normalform. Dann ist diese Tabelle in
zweiter Normal-
form
, wenn jede nicht leere Teilmenge der Nichtschlüs-
selattribute von jedem Schlüsselkandidaten voll funktio-
nal abhängig ist.
Die Definition kann auch wie folgt gelesen werden: Jedes
Nichtschlüsselattribut ist von jedem ganzen Schlüsselkandida-
ten funktional abhängig.
Zur praktischen Überprüfung, ob eine Tabelle in zweiter Nor-
malform ist, geht man jedes Nichtschlüsselattribut einzeln
durch und prüft, ob es wirklich von jedem Schlüsselkandidaten
voll funktional abhängig ist.
Im Beispiel der Tabelle Projektmitarbeit gibt es nur den Schlüs-
selkandidaten {MiNr, ProNr}. Eine schrittweise Überprüfung
ergibt hier den Extremfall, dass alle Nichtschlüsselattribute
nicht vom Schlüsselkandidaten, sondern nur von einer Teil-
Prüfung auf
zweite Normal-
form
85
