Dezember 2010 / Normalisierung

Normalisierung


Im Modul 104 - Datenmodell erstellen und implementieren befassen wir uns mit der Planung und Erstellung von Datenbanken.
Nun haben wir uns dem Thema Normalisierung gewitmet.
Im Fachdeutsch bedeutet die Normalisierung die schrittweise Zerlegung von Relationen, um Redundanzen innerhalb eines Datenschemas zu vermeiden.
In meinen eigenen Worten würde ich die Normalisierung so beschreiben:
Die Normalisierung ist ein Vorgehen, mit welchem man überprüfen kann, ob die Tabellen und Beziehung korrekt sind. Entsprechen Sie nicht den vorgegebenen Richtlinien, werden Sie korrigiert.
Das Ziel der gesamten Normalisierung ist es, die Kosistenz der Datenbank zu erhöhen und so Fehlerquellen zu verringern.
Sie wird bei der Plangung der Datenbank durchgeführt.
Die Normalisierung besteht aus 6 Normalformen, wovon wir jedoch nur die ersten 3 benötigen.


Um die 1. Normalform zu erreichen, müssen folgende Punkte eingehalten werden:
- Es sind keine Zusammengesetzen Attributwerte vorhanden
Beispiel: Adresse muss in PLZ, Ort, Strasse, Hausnummer aufgeteilt werden.
- Es dürfen nicht mehrere Werte innerhalb eines Wertfeldes vorkommen
Beispiel: Mehrere Titel-Namen einer Audio-CD in einem Wertefeld

Hier noch das Beispiel aus Wikipedia:
Datenschema in der "0." Normalform.



Datenschema nach der Normalisierung in der 1. Normalform.


Wie man sieht, wurden die Mehrfachen Titel in einzelne Felder aufgeteilt und das Album vom Interpret getrennt.
Nun bilden CD_ID und Track einen Verbundschlüssel, welchen den Primärschlüssel repräsentiert.

Damit sich ein Datenschema in der 2. Normalform befindet, müssen folgende Punkte eingehalten werden:
- Das Datenschema muss sich in der 1. Normalform befinden
- Jedes Attribut, welches keinen Schlüssel darstellt, ist von Allen Schlüsseln(also vom gesamten Verbundschlüssel) abhängig
Beispiel: In der 1. NF sind Album von der CD_ID abhängig, nicht aber vom Track.

Um dieses Datenschema in die 2. Normalform zu bringen müssen folgende Schritte vorgenommen werden:
Da die Attribute Album, Interpret und Jahr der Gründung nicht von beidem Schlüsselteilen abhängig ist, wird die Tabelle in mehrere Tabellen aufgeteilt. Anschliessend werden die Redundanten Daten gelöscht. Daraus ergeben sich folgende Tabellen:

In der 2. Tabelle stellt CD_ID einen fremdschlüssel dar, da er auf die CD_ID der 1. Tabelle verweisst.

Damit sich ein Datenschema in der 3. Normalform befindet, müssen alle Transiven abhängigkeiten von nicht-schlüssel-Attributen auf schlüssel-Attribute aufgelöst werden. Eine Transive Abhängigkeit wird folgendermassen beschrieben:

Hängt das Attribut C vom Attribut B ab und das Attribut B vom Attribut A, hängt das Attribut C transiv(also indirekt) vom Attribut A ab.

In unserem Beispiel gibt es ebenfalls so einen Fall.
Das Jahr der Gründung hängt vom Interpreten ab, der Interpret wiederum hängt vom Album ab. Also ist das Jahr der Gründung Transiv vom Album abhängig. Das führt zu redundanten (mehrfach vorkommenden) Daten.
Um das zu verhindern, muss eine 3. Tabelle erstellt werden.

Dabei bildet Interpret den Primärschlüssel und bei der 1. Tabelle wird Interpret als Fremdschlüssel hinzugefügt:

Dieses Datenschema befindet sich nun in der 3. Normalform und kann so realisiert werden. Was in diesesm Falle etwas speziell ist, ist der Zusammengesetzte Fremdschlüssel in der 3. Tabelle. Der Titel ist immer vom Track und von der CD_ID abhängig. Das bedeutet, dass man keine Titel ohne dazugehöriges Album und der Track-Nummer erfassen kann und keine CD ohne Titel.