Normalisierung (Datenbank)

Unter Normalisierung des Datenmodells einer relationalen Datenbank versteht man die Anwendung von Kriterien, damit das Modell einen bestimmten Zustand erreicht. Diesen nennt man (x^te) Normalform, d.h. wenn ein Datenmodell bestimmte (in jeder Stufe verschärfte) Bedingungen erfüllt, hat es die dadurch definierte Normalform, kurz xNF.

Der Sinn der Normalisierung besteht darin, Redundanzen (doppelt vorhandene Einträge) mit der dadurch verbundenen Gefahr von Anomalien (einander widersprechende Dateninhalte) zu vermeiden, und so die Wartung einer Datenbank zu vereinfachen sowie deren Konsistenz zu gewährleisten.

Neben den Abhängigkeiten, die für diese Normalformen "bereinigt" wurden, gibt es noch weitere, wie z.B. die Inklusionsabhängigkeit, die Template-Abhängigkeit und die Domain-Key-Normalform (DKNF).

Normalformen

Es gibt sechs Normalformen, von denen in der zweiten die Hauptarbeit steckt (siehe Bemerkungen):

1. Normalform (1NF)

Jedes Attribut der Relation ist atomar (unteilbar). Eine Information in einem Attribut ist dann atomar, wenn sie nicht mehr weiter in Einzelinformationen zerlegt werden kann (muss).

Beispiel:
Ein Feld "Name" beinhaltet Vornamen und Nachnamen einer Person.

Fehler/Problem:
Zur Sortierung nach Nachnamen muss das Feld in Vornamen und Nachnamen aufgeteilt werden.

Lösung:
Man benötigt die Felder "Vorname" und "Nachname", die diese Informationen getrennt aufnehmen.

Wenn für jedes dieser Felder die Bedingung "atomar" erfüllt ist, dann hat das Datenmodell die erste Normalform (1NF)

2. Normalform (2NF)

Eine Relation ist in zweiter Normalform, wenn alle Attribute vom ganzen Primärschlüssel abhängig sind.

Diese informelle Definition kann wie folgt präzisiert werden:

Eine Relation ist genau dann in zweiter Normalform, wenn sie

in der ersten Normalform ist und
für jeden Schlüsselkandidaten (Key Candidate) und jedes Attribut a der Relation gilt:
- a gehört zu KC oder
- a ist von keiner echten Teilmenge von KC abhängig.

Beispiel:
Gegeben sei eine Tabelle mit folgenden Feldern:

**CDLieder**
CD_ID	CD_Titel	CD_Interpret	CD_Preis	TrackID	LiedTitel
4711	Not That Kind	Anastacia	14,59€	1	Not That Kind
4711	Not That Kind	Anastacia	14,59€	2	I'm Outta Love
4711	Not That Kind	Anastacia	14,59€	3	Cowboys & Kisses
4712	Wish You Were Here	Pink Floyd	15,99€	1	Shine On You Crazy Diamond

Problem:
Der Primärschlüssel der Relation ist aus den Feldern CD_ID und TrackID zusammengesetzt. Die Felder CD_Titel und CD_Preis sind zwar vom Feld CD_ID abhängig - nicht aber vom Feld TrackID.

Die Informationen aus diesen beiden Feldern sind, wie am Beispiel der CD Not That Ki(n)d zu erkennen, mehrfach vorhanden. Der hieraus resultierende Zustand der Datenredundanz kann zu Verletzungen der Integrität der Daten führen. Es ist möglich, den Namen der CD und den Preis für die Lieder Not That Kind und Cowboys & Kisses zu ändern ohne die passenden Einträge beim Lied I'm Outta Love zu ändern (Update-Anomalie).

**CDLieder**
CD_ID	CD_Titel	CD_Interpret	CD_Preis	TrackID	LiedTitel
4711	Not That Kind	Anastacia	15,99€	1	Not That Kind
4711	Not That Kid	Anastacia	14,59€	2	I'm Outta Love
4711	Not That Kind	Anastacia	15,99€	3	Cowboys & Kisses
4712	Wish You Were Here	Pink Floyd	15,99€	1	Shine On You Crazy Diamond

In diesem Fall ist ein Zustand erreicht, den man als Dateninkonsistenz bezeichnet. Über die komplette Tabelle betrachtet, "passen" die Daten nicht mehr zusammen.

Lösung:
Die Daten in der Tabelle werden in zwei Tabellen aufgeteilt: CD und Lieder. In jeder Tabelle gibt es einen einfachen - also nicht zusammengesetzten - Primärschlüssel. Tabellen, die in der ersten Normalform vorliegen und einen einfachen Primärschlüssel haben, sind stets in der 2. Normalform.

CD
ID	Interpret	Titel	Preis
4711	Anastacia	Not That Kind	14.99€
4712	Pink Floyd	Wish You Were Here	15,99€

**Lieder**
TrackID	LiedTitel
1	Not That Kind
2	I'm Outta Love
3	Cowboys & Kisses
1	Shine On You Crazy Diamond

Da es keine Verbindung zwischen den beiden Tabellen gibt, ist es notwendig, dass der Primärschlüssel der Tabelle CD als Fremdschlüssel in der Tabelle Lieder verbleibt.

CD
ID	Interpret	Titel	Preis
4711	Anastacia	Not That Kind	14.99€
4712	Pink Floyd	Wish You Were Here	15,99€

**Lieder**
CD_ID	TrackID	LiedTitel
4711	1	Not That Kind
4711	2	I'm Outta Love
4711	3	Cowboys & Kisses
4712	1	Shine On You Crazy Diamond

Mit Hilfe dieser verlustfreien Zerlegung sind die genannten Redundanzen der Daten beseitigt. In jedem Datensatz aus der Tabelle Lied gibt es nur noch einen Verweis auf die passende CD. Die Tabellen haben nun die zweite Normalform (2NF).

3. Normalform (3NF)

Die dritte Normalform ist erreicht, wenn man in den Relationen keine transitiven Abhängigkeiten hat. Hierbei handelt es sich um eine Abhängigkeit, bei der ein Attribut über ein anderes Attribut vom Primärattribut der Relation abhängig ist. D.h. wenn Attribut P2 von Attribut P1 (dem Primärattribut) abhängt und Attribut A1 hängt von P2 ab, dann ist es transitiv abhängig von P1. Siehe auch: Transitivität (Mathematik)

Beispiel:
Gegeben sei eine Firma, die in Abteilungen unterteilt ist. Innerhalb jeder Abteilung gibt es mehrere Kostenstellen. Eine Kostenstelle ist aber nur einer Abteilung zugeordnet. Es existiert eine Personaltabelle, die unter anderem folgende Felder enthält:

**Personal**
Pers_Nr	Pers_Vorname	Pers_Name	Pers_Abteilung	Pers_Kostenstelle
123	Reiner	Zufall	Einkauf	2004
144	Frank	Frei	Verkauf	2006
146	Susi	Sorglos	Einkauf	2004
148	Frey	Erfunden	Einkauf	2004

Da die Abteilung Einkauf die Kostenstelle 2004 hat, kann keine andere Abteilung diese Kostenstelle haben. Dementsprechend geht aus dem Attribut Kostenstelle in der Relation die Abteilung eindeutig hervor. Diese ist damit von der Kostenstelle abhängig und nur indirekt von der Personalnummer.

Problem:
Damit existiert ein ähnliches Problem wie bei der zweiten Normalform: Datenredundanz. Hier kann die Tabelle derart abgeändert werden, dass zwei Mitarbeitern auf der Kostenstelle 2004 unterschiedliche Abteilungen zugewiesen werden können.

Lösung:
Auch hier muss die Redundanz durch das Aufteilen der Daten in zwei Tabellen aufgelöst werden.

**Personal**
Pers_Nr	Pers_Vorname	Pers_Name	Pers_Kostenstelle
123	Reiner	Zufall	2004
144	Frank	Frei	2006
146	Susi	Sorglos	2004
148	Frey	Erfunden	2005

**Kostenstellen**
KST_Nr	KST_Abteilung
2004	Einkauf
2005	Einkauf
2006	Verkauf

Boyce / Codd Normalform (BCNF)

Die Boyce/Codd Normalform war ursprünglich als Vereinfachung der dritten Normalform gedacht, fasst diese jedoch schärfer und führte so zu einem neuen Typ der Normalform.

Relationen, die sich in der BCNF befinden, sind von Anomalien befreit, die noch in der 3NF auftreten konnten. Eine Relation ist dann in BCNF, wenn sie die Voraussetzungen der 3NF erfüllt und gleichzeitig jede Determinante (Menge von Attributen, von denen andere voll funktional abhängen) Schlüsselkandidat ist.

Beispiel:

**Kostenstellen**
KST_Nr	KST_Abteilung	KST_Leiter
2004	Einkauf	Schmidt
3006	Verkauf	Maier
3008	Marketing	Maier

Die Entität KST_Nr beeinflusst in diesem Beispiel zusammen mit KST_Abteilung das Feld KST_Leiter. Dies ist eine funktionale Abhängigkeit. Desweiteren bestimmt das Feld KST_Leiter, welche erste Ziffer KST_Nr hat. "Schmidt" hat immer die 2, Maier immer die 3 usw.

Durch diese Konstellation ist die Relation nur in 3NF, nicht in BCNF. Wenn die transitive Abhängigkeit gelöst wird, und die im Beispiel aufgeführte Relation in zwei Relationen aufgeteilt wird, ist die Datenbank in BCNF.

4. Normalform (4NF)

Die 4. Normalform beschreibt vor allem die Mehrwertige Abhängigkeit, und welche Anomalien dadurch auftreten können. Eine Datenbank ist dann in der 4. Normalform, wenn sie nur noch triviale mehrwertige Abhängigkeiten enthält.

Beispiel:

**Standort**
Standortsnummer	Standortsname	Stadt
10001	Stuttgart Produktion 1	Stuttgart
20003	Berlin Verwaltung	Berlin
30012	München Vertrieb	München

Die Standortsnummer bestimmt den Namen des Standorts. In dieser Relation würde die Standortsnummer aber auch noch den Namen der Stadt beeinhalten, welcher sich aber vom Standortsnamen bildet (fiktives Beispiel!). So können Änderungsanomalien wie z.B. Einfügeanomalien oder auch Löschanomalien entstehen. Um die im Beispiel gezeigte Relation in 4NF zu überführen, müsste man zwei Relationen erstellen - einmal Standortsnummer und Standortsname, und in einer zweiten Standortsname und Stadt.

5. Normalform (5NF)

Die 5NF beschreibt diesmal keine Abhängigkeiten unter den einzelnen Attributen, sondern beschäftigt sich mit Anomalien, die durch Projektions- und Verbundsoperationen auftreten können. So können Relationen in einzelne Abfragen aufgeteilt werden, und durch spätere Verbundsoperationen wieder zusammengefügt werden, wobei ein sog. kartesisches Produkt entsteht.

Bemerkungen

In der Praxis der Datenmodellierung werden die erste und dritte Normalform vom Modellierenden unwillkürlich eingehalten, wenn das Normalisierungsverfahren als alleiniges Modellierungsverfahren benutzt wird. Die Hauptarbeit steckt in diesem Fall im Erreichen der zweiten Normalform.

Eine mögliche Herangehensweise an die Erstellung eines Datenmodells ist die Benutzung des Entity-Relationship-Modells (ERM) für die reine Erstellung und die Benutzung der Regeln der Normalisierung als Kontrollinstrument. Neben dem reinen ERM-Modell gibt es auch das E3R-Modell, entwickelt von Professor Mario Jeckle.