Alles zum Thema Normalisieren

Ein gutes Datenbankdesign zeichnet sich durch ein Minimum an Redundanzen aus.

Normalisierung ist ein Entwurfsansatz für relationale Datenbanken mit dem Ziel, Redundanzen und die damit einhergehenden Anomalien zu vermeiden.

Dabei werden die Daten durch Anwendung von Regeln strukturiert, bis sie den Anforderungen der entsprechenden Normalform genügen.

Beispieltabelle

Schauen wir uns folgende Tabelle des Beispielunternehmens xy an. Dort werden in nur einer Tabelle Informationen über die Mitarbeiter, Abteilungen, Projekte sowie die Zuordnung der Mitarbeiter zu einem Projekt gespeichert.

Der alte Admin (der nicht mehr in der Firma arbeitet) hatte damals beim Erstellen der Tabelle festgelegt, dass alle Spalten den Constraint NOT NULL erhalten. Der neue Admin wiederum hatte in der Ausbildung das Thema Constraints und generell Tabellenmanagement verpasst, weiß also nicht, wie man diese nervige Einschränkung entfernt.

Der NOT NULL Constraint verhindert, dass beim Einfügen von Zeilen eine Spalte leer bleibt, sie muss also mit irgendeinem Wert befüllt werden.

Die drei Abteilungsleiter (ID 107, 108 und 109) sind keinem Projekt zugeordnet und konnten nur eingefügt werden, weil ein "dummy" Projekt verwendet wurde (Alle Attribute -).

Anomalien

In der Beispieltabelle können verschiedene Dinge schief gehen sobald sie aktualisiert werden muss.

Diese Dinge, die schief gehen können, werden Anomalien genannt. Sie treten beim Einfügen, Löschen oder Ändern von Daten auf und führen zu ungewollten Nebeneffekten, Datenverlust oder Dateninkonsistenz.

Einfügeanomalie

Das Problem ist, dass neue Daten nur unvollständig oder gar nicht eingefügt werden können.

Beispiel:

• Neue Abteilung: Eine neue Abteilung kann nur angelegt werden, wenn sie gleichzeitig mit einem Mitarbeiter und einem Projekt verknüpft wird. Man könnte sich hier mit einem Dummymitarbeiter und einem Dummyprojekt behelfen, eine gute Lösung ist das aber nicht.

Mit neuen Mitarbeitern, Projekten und Sachverhalten wie "neuer Mitarbeiter ohne Projekt- oder Abteilungszuweisung" ergibt sich das gleiche Problem.

Löschanomalie

Beim Löschen von Datensätzen können ungewollt andere Informationen verloren gehen.

Beispiele:

• Mitarbeiter kündigt: Wenn Sarah Klein(ID 105) die Firma verlässt, gehen alle Informationen zum Projekt "Recruiting Portal" (P005) verloren. Ebenso alle Informationen über die Personalabteilung.

• Projektende: Wenn das Projekt P005 beendet wird und die Mitarbeiterin Sarah Klein gelöscht wird, gehen wieder alle Informationen über die Personalabteilung verloren.

Änderungsanomalie

Das Problem bei Änderungen ist, dass sie an mehreren Stellen vorgenommen werden müssen. Das Vergessen einer einzigen Stelle reicht aus, um die Datenbank in einem inkonsistenten Zustand zu hinterlassen.

Beispiele:

• Abteilungsleiter wechselt: Wenn Klaus Weber nicht mehr IT-Leiter ist, muss die Änderung bei allen IT-Mitarbeitern (101,102,104,107) erfolgen.

• Abteilung zieht um: Wenn die IT-Abteilung von Frankfurt nach Berlin umzieht, müssen 4 Zeilen geändert werden.

• Projektbudget ändert sich: Wenn das CRM System Budget von 50.000€ auf 60.000 steigt, muss dieser Wert bei allen Mitarbeitern geändert werden, die an diesem Projekt (P001) arbeiten.

Normalisierung

Die Normalisierung löst all diese Probleme, indem jede Information nur einmal gespeichert wird und über Fremdschlüssel referenziert wird. Dadurch werden Änderungen nur an einer Stelle vorgenommen und Inkonsistenzen werden strukturell verhindert.

1. Normalform

Anforderungen der NF1:

• Jedes Attribut einer Tabelle muss einen atomaren Wertebereich haben. Ein Attribut ist atomar, wenn es sich nicht weiter sinnvoll zerlegen lässt.

• Die Tabelle muss frei von Wiedeholungsgruppen sein. Das bedeutet, dass Attribute, die gleiche oder gleichartige Informationen enthalten, in eine neue Zeile ausgelagert werden müssen.

2. Normalform

Anforderungen der NF2:

• Die Tabelle erfüllt die NF1.

• Alle Nichtschlüsselattribute sind vollständig vom gesamten Primärschlüssel abhängig und nicht nur von einem Teil des Schüssels.

Diese Anforderung kann nur verletzt werden, wenn die Tabelle einen zusammengesetzten Primärschlüssel hat, wenn sich der Schlüssel also aus mehr als einer Spalte zusammensetzt.

Eine Tabelle, die die 1. Normalform erfüllt und deren Primärschlüssel nur aus einer Spalte besteht, erfüllt automatisch die 2. Normalform

3. Normalform

Anforderungen der NF3:

• Die Tabelle erfüllt die NF2.

• Kein Nichtschlüsselattribut darf von einem anderen Nichtschlüsselattribut abhängen.

• Alle Nichtschlüsselattribute sind vollständig vom Primärschlüssel abhängig.

Normalformen anwenden

Was das alles bedeutet, schauen wir uns jetzt an, indem wir die Beispieltabelle Schritt für Schritt in die 3. Normalform überführen und die Probleme anschauen, die im Verlauf der Normalisierung entstehen.

Überführung in 1. Normalform

Wir schauen uns nochmal die Beispieltabelle an und untersuchen, ob sie die NF1 erfüllt.

• Es dürfen nur atomare Werte vorkommen und die Spalte MitarbeiterName verletzt diese Anforderung. Das lässt sich leicht lösen, in dem diese Spalte in zwei Spalten aufgetrennt wird, MitarbeiterVorname und MitarbeiterNachname. Ähnlich würde man bei z.B. Addressen vorgehen.

• Das zweite Problem sind die Wiederholungsgruppen in den Spalten ProjektNr, ProjektName und ProjektBudget. Es sind gleiche und gleichartige Werte vorhanden, deswegen müssen wir für jeden Wert einen neuen Datensatz anlegen.

Folgendes Bild zeigt, wie die Tabelle nach Anwendung der beiden Regeln aussieht:

Problem
Durch das Einfügen der Wiederholungsgruppen hat die Spalte MitarbeiterID ihren Status als Primärschlüsselspalte verloren.

Wir nehmen die Spalte ProjektNr zum Primärschlüssel hinzu und erhalten zusammen mit MitarbeiterID eine einzigartige Kombination aus Werten, die sich für die eindeutige Identifizierung jeder einzigen Zeile eignet. Wir haben jetzt einen zusammengesetzten Primärschlüssel.

Die Tabelle erfüllt jetzt die 1. Normalform

Überführung in 2. Normalform

Eine Tabelle kann die 2. Normalform nur dann verletzen, wenn sie einen zusammengesetzten Primärschlüssel hat. Das ist hier der Fall, wir müssen also sicherstellen, dass alle Regeln eingehalten werden.

Die Erfüllung der 1. Normalform ist eine Voraussetzung für das Erfüllen der 2. (und 3.) Normalform und das ist hier gegeben.

Abhängigkeiten

Jetzt müssen wir untersuchen, ob alle Nichtschlüsselattribute auschließlich vom gesamtem Primärschlüssel abhängen oder möglicherweise nur einem Teil des Schlüssels.

Wenn ein Attribut b von einem anderen Attribut a abhängt, bedeutet das, dass der Wert von b eindeutig durch den Wert von a bestimmt wird.

In unserer Tabelle hängen die Attribute MitarbeiterVorname, MitarbeiterNachname, MitarbeiterGehalt und AbteilungsID alle von MitarbeiterID ab, einem Teil des Primärschlüssels, die 2. NF ist also verletzt.

Genau das gleiche Problem haben wir mit den Attributen ProjektName und ProjektBudget, die beide von ProjektNr abhängen, einem anderen Teil des Primärschlüssels:

Die rot gekennzeichneten Abhängigkeiten verletzen die 2. Normalform nicht, da AbteilungsID nicht Teil des Primärschlüssels ist.

Lösung

Um die Tabelle in die 2. Normalform zu bringen, müssen alle abhängigen Attribute mitsamt ihrem Teilschlüssel in eine eigene Tabelle ausgelagert werden. In der ursprünglichen Tabelle bleibt nur der Teilschlüssel zurück.

In unserem Beispiel ist AbteilungsID eins dieser abhängigen Attribute, es muss also ausgelagert werden. Da die Informationen zur Abteilung von diesem Attribut abhängig sind, müssen sie auch mitausgelagert werden.

Die Tabellen erfüllen jetzt die 2. Normalform

Überführung in 3. Normalform

Das Erfüllen der 2. Normalform ist Voraussetzung für das Erfüllen der 3. Normalform.

Unsere Tabellen liegen in 2. Normalform vor und müssen jetzt daraufhin untersucht werden, ob es Nichtschlüsselattribute gibt, die von einem anderen Nichtschlüsselattribut abhängen.

Transitive Abhängigkeiten

Wie wir bereits im vorherigen Schritt gesehen haben, hängen die Attribute AbteilungsName, AbteilungsLeiterID und AbteilungsStandort vom Attribut AbteilungsID ab. Dieses ist ein Nichtschlüsselattribut, welches wiederum vom Primärschlüssel abhängt. Diese Attribute hängen also indirekt von einem anderen Attribut ab:

Diese Abhängigkeit nennt man transitive Abhängigkeit und man sagt z.B. AbteilungsName ist transitiv von MitarbeiterID abhängig.

MitarbeiterID -> AbteilungsID und AbteilungsID -> AbteilungsName
==>
MitarbeiterID -> AbteilungsName (transitiv)

Eine transitive Abhängigkeit ist eine Verletzung der 3. Normalform

Lösung

Um die Tabelle in die 3. Normalform zu bringen, lagert man wieder alle abhängigen Attribute mitsamt dem Nichtschlüsselattribut, vom dem sie abhängen, in eine neue Tabelle aus. In der ursprünglichen Tabelle bleibt nur das Nichtschlüsselattribut zurück, von dem die anderen Attribute abhängen:

Fazit

Durch die schrittweise Anwendungen der Regeln haben wir die Ursprüngliche Tabelle in die 3. Normalform überführt, was zur Folge hat, dass Änderungen an den Tabellen deutlich weniger Angriffsfläche für Fehler bieten.

Vollständige Tabellen in der 3. Normalform:

Die Information, dass Klaus Weber Leiter der IT-Abteilung ist, ist nur noch einmal gespeichert, eine Änderungen muss also nur noch an einer Stelle erfolgen (in der Tabelle Abteilung).

Generell sind keine Redundanzen mehr vorhanden, das spart auch Speicherplatz!

Außerdem können Projekte, Mitarbeiter usw angelegt werden, ohne dass andere Datensätze hinzugefügt oder verknüpft werden müssen. Auf Notlösungen wie "dummy" Datensätze kann verzichtet werden.

Zuletzt können Datensätze gelöscht werden, ohne ungewollte Nebeneffekte zu verursachen.

Übung

Hier geht's zur Übung 1
Hier zur Übung 2