Normalisierung
Einführung
Die Normalisierung eines relationalen Datenbankmodells bezeichnet den strukturierten Prozess, Attribute anhand fester Regeln (Normalformen) auf mehrere Relationen (Tabellen) aufzuteilen. Das primäre Ziel dieses Vorgangs ist es, ein Datenbankschema zu erstellen, das frei von vermeidbaren Redundanzen (Datenverdopplungen) ist.
Eine redundanzarme Datenspeicherung ist essenziell für die Datenintegrität. Enthält ein Schema Redundanzen, führt dies bei Aktualisierungen häufig zu Anomalien (Einfüge-, Änderungs- oder Löschanomalien). Mehrfach gespeicherte Daten könnten beispielsweise nur teilweise geändert werden, was zu widersprüchlichen und inkonsistenten Datenbeständen führt. Zudem belegt redundante Speicherung unnötigen Speicherplatz.
Es gibt verschiedene formale Grade der Normalisierung (Erste, Zweite, Dritte Normalform etc.). Ein relationales Schema wird normalisiert, indem es anhand seiner funktionalen Abhängigkeiten schrittweise in kleinere Relationen zerlegt (dekomponiert) wird. Diese Zerlegung muss zwingend verlustfrei erfolgen – es dürfen keine Informationen verloren gehen.
In der Praxis wird vor allem in der Entwurfsphase einer relationalen Datenbank normalisiert. Ein sauberer logischer Modellentwurf, beispielsweise durch ein Entity-Relationship-Modell (ERM), erfüllt oft bereits von vornherein die wichtigsten Normalformen. Dennoch dient die formale Normalisierung als wichtiges Prüfinstrument, um verbliebene Redundanzen aufzudecken.
Beispiel der Normalisierungsschritte
Folgendes Schema wird exemplarisch aus einem denormalisierten Ausgangszustand schrittweise in die 3. Normalform überführt.
Ausgangssituation (Nicht normalisiert)
In diesem Zustand weist die Tabelle zwei massive Strukturfehler auf: Es existieren Attribute mit mehreren Werten (Wiederholungsgruppen beim Termindatum) und nicht atomare Werte (Vor- und Nachname stehen gemeinsam in einem Feld).
| Kundenname | Mitarbeitername | Salon | Termindatum |
|---|---|---|---|
| Klaus Meyer | Sabine Krause | Hammer Haare | 11.10.2012, 14.10.2012 |
| Paula Meyer | Claudia Schrotter | Friedrich List Frisuren | 09.11.2012 |
---
Die 1. Normalform (1NF)
Ein Relationenschema befindet sich in der 1. Normalform (kurz 1NF), wenn die Wertebereiche aller Attribute atomar sind. Das bedeutet, dass jeder Attributwert eine unteilbare Informationseinheit darstellen muss (z. B. muss eine Adresse in Straße, Hausnummer, PLZ und Ort aufgeteilt werden). Zudem sind Wiederholungsgruppen (Listen oder Arrays in einem Feld) unzulässig.
Um ein Schema in die 1NF zu überführen, müssen zusammengesetzte Attribute aufgespalten und Wiederholungsgruppen durch das Anlegen neuer Datensätze (Zeilen) aufgelöst werden.
Umsetzung: Die Spalten Mitarbeitername und Kundenname werden jeweils in Vor- und Nachname (KVorname, KNachname, MVorname, MNachname) zerlegt. Für die beiden Termindaten von Klaus Meyer wird die Zeile dupliziert, sodass pro Zelle nur noch ein Datum steht.
| KVorname | KNachname | MVorname | MNachname | Salon | Termindatum |
|---|---|---|---|---|---|
| Klaus | Meyer | Sabine | Krause | Hammer Haare | 11.10.2012 |
| Klaus | Meyer | Sabine | Krause | Hammer Haare | 14.10.2012 |
| Paula | Meyer | Claudia | Schrotter | Friedrich List Frisuren | 09.11.2012 |
Die Relation erfüllt nun die Kriterien der 1. Normalform.
---
Die 2. Normalform (2NF)
Ein Relationenschema befindet sich in der 2. Normalform (kurz 2NF), wenn es sich in der 1NF befindet und jedes Nicht-Schlüsselattribut von jedem Schlüsselkandidaten voll funktional abhängig ist.
Um diese Bedingung zu prüfen, muss zunächst ein Primärschlüssel identifiziert werden. Im obigen Beispiel aus der 1NF gibt es keine natürliche Attributkombination, die einen Termin eindeutig identifiziert (ein Kunde könnte am selben Tag beim selben Mitarbeiter mehrere Termine haben).
Umsetzung: Die praktikabelste Lösung ist die Einführung eines künstlichen Primärschlüssels (Surrogatschlüssel). Die Tabelle wird um die Spalte `IdTermin` erweitert, die fortlaufend durchnummeriert wird.
| IdTermin | KVorname | KNachname | MVorname | MNachname | Salon | Termindatum |
|---|---|---|---|---|---|---|
| 1 | Klaus | Meyer | Sabine | Krause | Hammer Haare | 11.10.2012 |
| 2 | Klaus | Meyer | Sabine | Krause | Hammer Haare | 14.10.2012 |
| 3 | Paula | Meyer | Claudia | Schrotter | Friedrich List Frisuren | 09.11.2012 |
Die Relation befindet sich nun in der 2NF: Jedes Attribut in der Tabelle wird eindeutig und voll funktional durch den Primärschlüssel IdTermin bestimmt.
---
Die 3. Normalform (3NF)
Ein Relationenschema befindet sich in der 3. Normalform (kurz 3NF), wenn es in der 2NF vorliegt und kein Nicht-Schlüsselattribut transitiv vom Primärschlüssel abhängt. Ein Nicht-Schlüsselattribut darf also nicht durch ein anderes Nicht-Schlüsselattribut bestimmt werden.
Betrachten wir die Relation aus der 2NF: Der Primärschlüssel `IdTermin` bestimmt eindeutig den Mitarbeiter und den Salon. Allerdings hängt der Salonname fachlich von der Identität des Salons ab und somit nur indirekt (transitiv) vom Termin. Gleiches gilt für die Kunden (Kunden-ID bestimmt KVorname und KNachname) und Mitarbeiter.
Umsetzung: Um transitive Abhängigkeiten aufzulösen, werden die zusammengehörigen Kunden-, Mitarbeiter- und Saloninformationen in eigene Relationen ausgelagert und über Fremdschlüssel verknüpft.
Tabelle: Salon
| SNR | Salonname |
|---|---|
| 1 | Hammer Haare |
| 2 | Friedrich List Frisuren |
Tabelle: Mitarbeiter
| MNR | MVorname | MNachname | FK_SNR |
|---|---|---|---|
| 1 | Sabine | Krause | 1 |
| 2 | Claudia | Schrotter | 2 |
Tabelle: Kunde
| KNR | KVorname | KNachname |
|---|---|---|
| 1 | Klaus | Meyer |
| 2 | Paula | Meyer |
Tabelle: Termin
| IdTermin | FK_KNR | FK_MNR | Termindatum |
|---|---|---|---|
| 1 | 1 | 1 | 11.10.2012 |
| 2 | 1 | 1 | 14.10.2012 |
| 3 | 2 | 2 | 09.11.2012 |
Das Schema befindet sich nun vollständig in der 3NF. Es existieren ausschließlich direkte, voll funktionale Abhängigkeiten vom jeweiligen Primärschlüssel der Tabelle. Die Verknüpfung der Daten bleibt durch die Fremdschlüssel erhalten, während das Ziel der redundanzfreien Datenhaltung erreicht wurde.