Bis 1978 wurden von E. F. Codd drei Normalformen aufgestellt, die entsprechend als erste, zweite und dritte Normalform bezeichnet werden. Daneben gibt es noch vier weitere Normalformen, die jedoch in der Praxis nicht so relevant sind, da Probleme, die durch diese Normalformen beseitigt werden, nur selten vorkommen bzw. die Arbeit mit den durch diese Normalformen erzeugten Tabellen komplexer wird.
NF² (Non-First-Normal-Form)
Als NF² wird jede unnormalisierte Relation bezeichnet, sozusagen eine Relation, die nicht mal der ersten Normalform genügt.
1. Normalform
Definition: 1. Normalform
Eine Relation (Tabelle) ist in der ersten Normalform (1. NF), wenn die Werte der Attribute elementar (atomar) sind, d.h. pro Datenfeld darf nur maximal ein Wert enthalten sein.
Im obigen Beispiel sind die Werte der Attribute PrüfFachNr … Note nicht elementar (atomar). In diesen Attributen sind jeweils mehrere Werte gespeichert, auf die damit nicht einzeln zugegriffen werden kann.
Ein evtl. erfasstes Geburtsdatum setzt sich zwar aus den Komponenten Tag, Monat und Jahr zusammen, es ist aber als Ganzes anzusehen. Dem widerspricht nicht, dass über spezielle Funktionen auf einzelne Komponenten des Datums zugegriffen werden kann (z. B.: Gruppiere die Geburtstage der Mitglieder nach Monaten).
In einigen relationalen Datenbanksystemen können auch komplexe Objekte wie Bilder, Videosequenzen und Tonfolgen als elementare Attribute gespeichert werden. Dies bedingt, dass keine Abfragen auf bestimmte Inhalte der Attribute durchgeführt werden können (z.B. die Suche nach einer bestimmten Tonfolge).
Damit sind z.B. Mengen, Folgen und Arrays als Attributwerte ausgeschlossen. Elementar bedeutet, dass der Wert als Ganzes zu sehen ist und keine Teile des Wertes getrennt verarbeitet werden sollen.
In der Definition heißt es: „… maximal einen Wert …“. Demnach ist es erlaubt, in ein Datenfeld keinen Wert (d.h. einen Nullwert) einzutragen. das kann sinnvoll sein, wenn z.B. das Attribut noch keinen Wert besitzt (noch nicht vergebene Punktzahl in einem Kurs).
Es gibt zwei Arten Mehrfachattribute zu beseitigen:
- Das Mehrfachattribut wird innerhalb des Datensatzes in mehrer Einfachattribute zerlegt, d.h. der Datensatz erhält mehr Attribute.
- Wenn das Mehrfachattribut eine Liste von typgleichen Daten enthält, wird jedem Wert der Liste eine eigener Datensatz zugeordnet.
Die Ausgangsrelation dürfte in der 1.NF so aussehen:
Prüfung (MNr, Name, PrüfFachNr, PrüfFachBezeichung, ProfNr, ProfName, Note)
Als Primärschlüssel wird man, um eine Prüfung einem Schüler eindeutig zuordnen zu können, nun die Attributkombination {MNr, PrüfFachNr} wählen müssen. Mit dieser einfach durchzuführenden Auflösung von Mehrfachbelegungen sind aber Datenredundanzen entstanden, die man eigentlich vermeiden sollte. Diese werden erst in der 2. und 3. Normalform wieder beseitigt.
Welche Fehlermöglichkeiten kann es in der 1.NF geben?
Einfüge-Anomalie
Fall 1: Zur bestehenden Prüfungsfachnummer erfolgt ein weiterer Eintrag mit anderer Prüffachbezeichnung
Fall 2: Zur selben Matrikelnummer erfolgt ein Eintrag mit anderem Studentennamen
Fall 3: Der Eintrag eines Studenten, der noch kein Prüfungsfach gewählt hat liefert Nullwerte in der Prüfungsfachnummer, da dies aber Teil des Primärschlüssels ist, darf dies nicht sein. Es verletzt die Integrität.
Änderungs-Anomalie
Fall 4: Wenn der Name des Professors / der Professorin sich ändert, muss dies in allen Zeilen geschehen!
Fall 5: Den einzelnen Prüfungsfächern werden neue Prüfer zugeordnet. Überall!
Lösch-Anomalie
… Gehen Daten unwiederbringlich verloren, wenn ein Tupel gelöscht wird?
2. Normalform
Die zweite Normalform bezieht sich ausschließlich auf Tabellen, deren Primärschlüssel aus mehreren Attributen zusammengesetzt ist.
Definition: 2. Normalform
Eine Relation ist in der zweiten Normalform (2.NF), wenn sie sich in der 1.NF befindet und jedes nicht zum Primärschlüssel gehörige Attribut voll von diesem abhängig ist.
Der Primärschlüssel der Relation in der 1.NF ist MNr und PrüfFachNr. Da weder der Name des Studenten noch die Bezeichnung des Prüfungsfachs voll vom Primärschlüssel abhängig sind, müssen diese in andere Relationen überführt werden. Das Attribut Note ist voll vom Primärschlüssel abhängig und bleibt in der Relation. Demzufolge ergeben sich folgende Relationen in zweiter Normalform:
Prüfung (↑MNr, ↑PrüfFachNr, Note)
Studenten (MNr, Name)
Prüfungsfächer (PrüfFachNr, PrüfFachBezeichung, ProfNr, ProfName)
In allen entstandenen Relationen sind alle Nicht-Primärschlüssel-Attribute voll funktional abhängig von den jeweiligen Primärschlüsseln.
Die Gesamtinformation ist durch die Überführung in die zweite Normalform nicht geändert worden. Die Verbindung zwischen den Relationen geschieht durch sogenannte korrespondierende Attribute; so tritt die Matrikelnummer sowohl in der Relation Prüfungen als auch in der Relation Studenten auf. Diese in verschiedenen Relationen auftretenden Attribute nennt man global im Gegensatz zu lokalen Attributen, die nur in einer Relation vorkommen.
Durch die Transformation in die 2.NF wurden die Redundanzen weitgehend beseitigt; allerdings fällt auf, dass das Attribut ProfName mehrmals vorkommt, obwohl mit ProfNr der Name des Professors schon gegeben wäre. Diese Redundanzen von Attributen beseitigt nun die Überführung in die dritte Normalform.
Welche Anomalien kommen in der 2.NF nicht mehr vor?
Einfüge-Anomalie
Fall 1: Zur bestehenden Prüfungsfachnummer erfolgt ein weiterer Eintrag mit anderer Prüffachbezeichnung (beseitigt)
Fall 2: Zur selben Matrikelnummer erfolgt ein Eintrag mit anderem Studentennamen (beseitigt)
Fall 3: Der Eintrag eines Studenten, der noch kein Prüfungsfach gewählt hat liefert Nullwerte in der Prüfungsfachnummer, da dies aber Teil des Primärschlüssels ist, darf dies nicht sein. (beseitigt)
Änderungs-Anomalie
Fall 4: Wenn der Name des Professors / der Professorin sich ändert, muss dies in allen Zeilen geschehen (nicht beseitigt!)
Fall 5: Den einzelnen Prüfungsfächern werden neue Prüfer zugeordnet. Überall! (beseitigt)
3. Normalform
Die dritte Normalform bezieht sich auf funktionale Abhängigkeiten zwischen Nichtschlüssel- Attributen.
Definition: 3. Normalform
Eine Relation befindet sich dann in der dritten Normalform (3.NF), wenn sie sich in der 1.NF und in der 2.NF befindet und wenn alle Nichtschlüssel-Attribute ausschließlich vom Primärschlüssel funktional abhängig sind, und nicht transitiv über ein Nichtschlüssel-Attribut.
Durch die Transformation in die 2. Normalform wurden die Redundanzen weitgehend beseitigt; allerdings fällt auf, dass das Attribut ProfName mehrmals vorkommt, obwohl mit ProfNr der Name des Professors schon gegeben wäre. Diese Redundanzen von Attributen, die nicht zum Primärschlüssel gehören, beseitigt die Überführung in die 3. Normalform.
Prüfung (↑MNr, ↑PrüfFachNr, Note)
Studenten (MNr, Name)
Prüfungsfächer (PrüfFachNr, PrüfFachBezeichung, ↑ProfNr)
Prüfer (ProfNr, ProfName)
Welche Anomalien kommen in der 3.NF nicht mehr vor?
Änderungs-Anomalie
Fall 4: Wenn der Name des Professors / der Professorin sich ändert, muss dies in allen Zeilen geschehen! (beseitigt)
Mit der Überführung in die dritte Normalform sind nun in dem Beispiel alle Anomalien / Redundanzen beseitigt worden.
weitere Normalformen
In den meisten Fällen ist man in der Lage, auf Basis der 3 Normalformen ein redundanzfreies, konsistentes und realitätsgetreues Datenmodell zu erstellen. Unter bestimmten Voraussetzungen können jedoch auch bei Relationen, die sich in der 3. Normalform befinden, Anomalien auftreten und zwar, wenn
- die Relation mehrere Schlüsselkandidaten hat (Prüfungsfachnr. vs. Prüffachbezeichnung)
- die Schlüsselkandidaten zusammengesetzt sind, also aus mehr als einem Attribut bestehen
- die Schlüsselkandidaten sich mit dem Primärschlüssel überlappen, d.h. mindestens ein Attribut mit dem Primärschlüssel gemeinsam haben.
Da die ersten drei Normalformen in der Regel die häufigsten Probleme abdecken, soll es an dieser Stelle genügen, die weiteren Normalformen im Folgenden nur kurz zu erwähnen.
Boyce-Codd-Normalform
Als Ersatz für die dritte Normalform wird häufig die Boyce-Codd-Normalform angewendet.
Definition: Boyce-Codd-Normalform
Eine Relation ist in Boyce-Codd-Normalform (BCNF), wenn jedes determinierende Attribut zugleich Schlüsselkandidat ist.
Beispiel
Belegung (KursNr, KursBez, SNr, Note)
In der Relation Belegung liegen folgende funktionale Abhängigkeiten vor:
{KursNr} → {KursBez}
{KursBez} → {KursNr}
{KursNr, SNr} → {Note}
{KursBez, SNr} → {Note}
Schlüsselkandidaten sind nur die Kombinationen {KursNr, SNr} und {KursBez, SNr}. Ein Schlüsselkandidat {KursNr, KursBez, SNr} ist nicht möglich, da damit die 2.NF nicht erfüllt wäre.
Damit ist aber die BCNF nicht erfüllt, da es Determinanten gibt, die keine Schlüsselkandidaten sind, nämlich KursNr bzw. KursBez. Um auch hier BCNF zu erreichen, muss wiederum eine Zerlegung durchgeführt werden, so dass eine derjenigen Determinanten, die nicht Schlüsselkandidaten sind, in eine neue Relation ausgelagert wird.
Belegung (KursNr, SNr, Note)
Kurs (KursNr, KursBez)
Die Untersuchung, ob sich eine Relation in BCNF befindet, macht nur Sinn, wenn die Relation zusammengesetzte Primärschlüssel besitzen, ansonsten ist die BCNF gleichzusetzen mit der 3.NF. Daher kann die Relation Belegung aus dem Beispiel auch durch die Einführung eines Attributes BNr als Primärschlüssel in die BCNF umgewandelt werden.
4. und 5. Normalform
Die vierte und die fünfte Normalform beschäftigen sich mit so genannten mehrwertigen Abhängigkeiten. Mehrwertige Abhängigkeiten treten nur auf, wenn der Primärschlüssel aus zwei oder mehr Attributen zusammengesetzt ist. In der Regel versucht man Primärschlüssel auf ein, höchstens zwei Attribute zu beschränken. Deshalb soll hier auf diese Normalformen nicht näher eingegangenwerden.
Zusammenfassung
Das Ziel der Normalisierung ist die Vermeidung redundanter Daten. Dabei finden (hauptsächlich) drei Normalformen Anwendung, die man nacheinander auf Tabellen anwenden sollte, um diese zu überprüfen.
Folgende Schritte sind zur Erfüllung der drei Normalformen durchzuführen:
1. Normalform
- Attribute mit mehreren Werten, z.B. Adresse, in atomare Attribute aufspalten
- Wiederholgruppen, z.B. Kinder von Kunden, in mehrere Zeilen aufteilen
2. Normalform
- Überprüfen der vollen funktionalen Abhängigkeit der Nichtschlüssel-Attribute zum Primärschlüssel
- Gegebenenfalls Aufteilen der Tabelle nach deren voller funktionaler Abhängigkeit (nur bei zusammengesetzten Primärschlüsseln notwendig)
3. Normalform
- Überprüfen von transitiven Abhängigkeiten des Primärschlüssels zu den Nichtschlüssel-Attributen (Ausnahme: Funktionale Abhängigkeit von einem Schlüsselkandidaten)
- Gegebenenfalls Aufteilen der Tabelle, so dass transitiv abhängige Attribute mit ihrem funktional abhängigen Attribut eine eigene Tabelle bilden und transitiv abhängiges Attribut in Originaltabelle erhalten bleibt
Generell gilt, dass ein sauber modelliertes ER-Modell bereits in ein redundanzfreies Relationenmodell überführt wird.
Dennoch sollte die Normalisierung in drei Fällen angewendet werden. Zum einen zur nachträglichen Überprüfung von Tabellen, bei denen man Unstimmigkeiten vermutet. Zum anderen zur Überprüfung, wenn nachträglich Attribute zur Datenbank hinzugefügt werden sollen. Und schließlich um eine bereits vorhandene relationale Datenbankstruktur nachträglich zu normalisieren. Häufig werden in Firmen relationale Datenbanken erstellt ohne vorab ein konzeptionelles und logisches Modell zu entwerfen. In diesem Fall eignet sich die Normalisierung als nachträgliche Designtechnik um das Datenmodell redundanzfrei zu entwerfen.
