Datenbanksysteme: Normalformen
Das Ziel der Verwendung von Normalformen ist es, Redundanzen zu eliminieren und Anomalien zu vermeiden.
1. Normalform (1 NF)
Beispiel
Tabelle PERSONAL-PROJEKT, in der alle Mitarbeiter aufgeführt sind, die an einem Projekt beteiligt sind oder waren. Die Mitarbeiter können an mehreren Projekten beteiligt sein; es wird jeweils notiert, wie viele Stunden sie in einem Projekt geleistet haben.
Pers-Nr | Pers-Name | Abt-Nr | Abt-Name | Pj-Nr | Pj-Name | Pj-Std. |
101 | Müller | 1 | Motoren | 11, 12 | A, B | 60, 50 |
102 | Meier | 2 | Karosserie | 13 | C | 120 |
103 | Krause | 2 | Karosserie | 12, 12, 13 | A, B, C | 20, 50, 30 |
104 | Schmitt | 1 | Motoren | 11, 13 | A, C | 70, 20 |
Eine Tabelle liegt in der ersten Normalform vor, wenn jeder Attributwert eine atomare, d.h. nicht weiter zerlegbare Dateneinheit ist. Es dürfen also nicht mehrere Attributwerte in einer Zelle auftreten, wie etwa hier in der Spalte Pj-Nr.
Denn nur dann können über Abfragen wichtige Informationen aus der Tabelle herausgefiltert werden (z.B. „Welche Mitarbeiter waren an Projekt 11 beteiligt?“).
Um dies zu erreichen, lagert man die nicht atomaren Attribute in verschiedene Zeilen oder mehree Spalten (z.B. Adresse in PLZ, Ort, Straße) aus. Dabei muss ggf. der Primärschlüssel um ein oder mehrere Attribute erweitert werden. Es können dennoch noch alle besprochenen Anomalien auftreten.
Pers-Nr | Pers-Name | Abt-Nr | Abt-Name | Pj-Nr | Pj-Name | Pj-Std |
101 | Müller | 1 | Motoren | 11 | A | 60 |
101 | Müller | 1 | Motoren | 12 | B | 50 |
102 | Meier | 2 | Karosserien | 13 | C | 120 |
. . . |
2. Normalform (2 NF)
Eine Tabelle liegt in der zweiten Normalform vor, wenn jedes Attribut, das kein Teil des Primärschlüssels ist, vom gesamten Primärschlüssel funktional abhängig ist.
Dies ist der Fall, wenn z.B. das Attribut „Pers-Name“ ausschließlich vom Primärschlüssel-Teil „Pers-Nr“ abhängt, in keiner Weise jedoch vom Primärschlüssel-Teil „Pj-Nr“.
Im Beispiel sind die Attribute Pers-Name, Abt-Nr und Abt-Name vom Attribut Pers-Nr funktional abhängig, werden also allein durch dieses Attribut bereits bestimmt und benötigen das Attribut Pj-Nr nicht. Das Attribut Pj-Name dagegen ist funktional abhängig vom Attribut Pj-Nr.
Das Attribut Pj-Std wiederum ist funktional abhängig vom gesamten Primärschlüssel, der aus beiden Attributen Pers-Nr und Pj-Nr besteht. Also muss die vorgegebene Tabelle in drei eigenständige Tabellen zerlegt werden.
PERSONAL
Pers-Nr | Pers-Name | Abt-Nr | Abt-Name |
101 | Müller | 1 | Motoren |
102 | Meier | 2 | Karosserie |
103 | Krause | 2 | Karosserie |
104 | Schmitt | 1 | Motoren |
PROJEKT
Pj-nr | Pj-Name |
11 | A |
12 | B |
13 | C |
PERSONAL_PROJEKT
Pers-Nr | Pj-Nr | Pj-Std |
101 | 11 | 60 |
101 | 12 | 50 |
102 | 13 | 120 |
In jeder der drei Tabellen gilbt nun, dass jedes Attribut, das nicht selbst Primärschlüssel ist, vom Primärschlüssel voll funktional abhängig ist.
3. Normalform (3 NF)
Betrachtet man die Tabelle PERSONAL näher, so sieht man, dass das Attribut Abt-Name funktional abhängig vom Primärschlüssel Pers-Nr ist, aber andererseits bereits von dem Attribut Abt-Nr festgelegt ist. Man sagt, Abt-Name ist transitiv abhängig vom Primärschlüssel Pers-Nr, und zwar über das Nicht-Primärschlüssel-Attribut Abt-Nr. Das führt zu Redundanzen, wie sofort erkennbar ist.
Eine Tabelle liegt in der dritten Normalform vor, wenn jedes Attribut, das kein Teil des Primärschlüssels ist, nicht transitiv abhängig vom Primärschlüssel ist, also nicht bereits durch ein Nicht-Primärschlüssel-Attribut festgelegt ist. Dies kann man beheben, indem man die transitiv abhängigen Attribute in eigene Tabellen auslagert.
PERSONAL
Pers-Nr | Pers-Name | Abt-Nr |
101 | Müller | 1 |
102 | Meier | 2 |
103 | Krause | 2 |
104 | Schmitt | 1 |
PROJEKT
Pj-nr | Pj-Name |
11 | A |
12 | B |
13 | C |
PERSONAL_PROJEKT
Pers-Nr | Pj-Nr | Pj-Std |
101 | 11 | 60 |
101 | 12 | 50 |
102 | 13 | 120 |
ABTEILUNG
Abt-Nr | Abt-Name |
1 | Motoren |
2 | Karosserie |
Wie man sieht, sind nun sämtliche Redundanzen beseitigt. Ändert sich etwa ein Abteilungsname (von Motoren zu Maschinen), so muss diese Änderung auch nur einmal, nämlich in der Tabelle ABTEILUNG, vorgenommen werden.
So kann es auch nicht zu den unerwünschten Änderungs-Anomalien kommen. Auch die Lösch- und Einfüge-Anomalien werden auf diese Weise vermieden. Man bezeichnet einen solchen Datenbank-Entwurf in der dritten Normalform deshalb als einen „guten“ Datenbankentwurf.
Der Nachteil an dieser Form ist, dass bestimmte Informationen, z.B. „An welchen Projekten hat Herr Müller mitgearbeitet?“, nicht mehr unmittelbar aus den Tabellen abgelesen werden können, sondern müssen in SQL mit Joins über mehrere Tabellen abgefragt werden.