Normalformen

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.

NF² (Non-First-Normal-Form)

Als NF² wird jede unnormalisierte Relation bezeichnet, sozusagen eine Relation, die nichtmal der ersten Normalform genügt.

Student

MNr	Name	PrüfFachNr	PrüfFachBezeichung	ProfNr	ProfName	Note
005	Meier	10,12,16	Analysis, Algebra, Datenbanken	90,90,65	A,A,D	2,1,2
006	Müller	16,17	Datenbanken, Techn. Informatik	65,68	D,F	2,3
...	...	...	...	...	...	...

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:

1. Das Mehrfachattribut wird innerhalb des Datensatzes in mehrer Einfachattribute zerlegt, d.h. der Datensatz erhält mehr Attribute.
2. 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
005	Meier	10	Analysis	90	A	2
005	Meier	12	Algebra	90	A	1
005	Meier	16	Datenbanken	65	D	2
006	Müller	16	Datenbanken	65	D	2
006	Müller	17	Techn. Informatik	68	F	3
...	...	...	...	...	...	...

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.

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 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üfungen MNr PrüfFachNr Note 005 10 2 005 12 1 005 16 2 006 16 2 006 17 3

Studenten MNr Name 005 Meier 006 Müller

Prüfungsfächer PrüfFachNr PrüfFachBezeichung ProfNr ProfName 10 Analysis 90 A 12 Algebra 90 A 16 Datenbanken 65 D 17 Techn. Informatik 68 F

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, die nicht zum Primärschlüssel gehören, beseitigt 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)

Änderungsanomalie

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.

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üfungen MNr PrüfFachNr Note 005 10 2 005 12 1 005 16 2 006 16 2 006 17 3

Studenten MNr Name 005 Meier 006 Müller

Prüfungsfächer PrüfFachNr PrüfFachBezeichung ProfNr 10 Analysis 90 12 Algebra 90 16 Datenbanken 65 17 Techn. Informatik 68

Prüfer ProfNr ProfName 90 A 65 D 68 F

Prüfung (↑MNr, ↑PrüfFachNr, Note)
Studenten (MNr, Name)
Prüfungsfächer (PrüfFachNr, PrüfFachBezeichung, ↑ProfNr)
Prüfer (ProfNr, ProfName)

Mit der Überführung in die dritte Normalform sind in dem Beispiel alle Anomalien / Redundanzen beseitigt worden.

Welche Anomalien kommen in der 3.NF nicht mehr vor?

Änderungsanomalie

Fall 4: Wenn der Name des Professors / der Professorin sich ändert, muss dies in allen Zeilen geschehen! (beseitigt)

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.

weitere Normalformen

Die ersten drei Normalformen decken in der Regel die häufigsten Probleme ab, die bei einem Datenmodell auftreten können. Daher soll es an dieser Stelle genügen, nur die ersten drei Normalformen ausführlich zu erläutern und die weiteren Normalformen im Folgenden kurz zu erwähnen.

Boyce-Codd-Normalform

Als Ersatz für die dritte Normalform wird häufig die Boyce-Codd-Normalform angewendet.

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)

• Gegebenfalls 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.