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 (xte) Normalform, dh. 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)
In der zweiten Normalform sind alle Attribute einer Relation nur vom Primärschlüssel dieser Relation abhängig.
Beispiel:
Gegeben sei eine Tabelle mit folgenden Feldern:
| Kd_Nr | Kd_Name | Kd_Ort | Kd_Betreuer_Nr | Kd_Betreuer_Vorname | Kd_Betreuer_Name |
|---|---|---|---|---|---|
| 1 | Meier AG | Müllhausen | 123 | Reiner | Zufall |
| 2 | Holz Bank | Waldhausen | 144 | Frank | Frei |
| 3 | Fa. Schaffel | Woauchimmer | 123 | Reiner | Zufall |
| 4 | Kinder KG | Frankfurt | 123 | Reiner | Zufall |
Problem:
Die Felder Kd_Betreuer_Vorname und Kd_Betreuer_Name sind zwar vom Feld Kd_Betreuer_Nr abhängig - nicht aber vom Feld Kd_Nr.
Die Informationen in diesen drei Feldern sind, am Beispiel des Betreuers Reiner Zufall, mehrfach vorhanden. Der hieraus resultierende Zustand der Datenredundanz verletzt die Integrität der Daten. Es ist möglich, den Nachnamen des Betreuers für Kunde Nr. 4 zu ändern, ohne die passenden Einträge bei den Kunden 1 und 3 zu ändern.
| Kd_Nr | Kd_Name | Kd_Ort | Kd_Betreuer_Nr | Kd_Betreuer_Vorname | Kd_Betreuer_Name |
|---|---|---|---|---|---|
| 1 | Meier AG | Müllhausen | 123 | Reiner | Zufall |
| 2 | Holz Bank | Waldhausen | 144 | Frank | Frei |
| 3 | Fa. Schaffel | Woauchimmer | 123 | Reiner | Zufall |
| 4 | Kinder KG | Frankfurt | 123 | Reiner | Zufall |
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 werde in zwei Tabellen aufgeteilt: Kunden und Personal. In jeder Tabelle existiert nur ein Primärschlüssel und alle Felder sind von diesem direkt abhängig.
|
|
Es existiert nun keine Verbindung mehr zwischen den beiden Tabellen. Deshalb ist es notwendig, dass der Primärschlüssel der Tabelle Personal als Fremdschlüssel in der Tabelle Kunden verbleibt.
|
|
Damit ist die Redundanz der Daten aufgelöst. In jedem Kundendatensatz gibt es nur noch einen Verweis auf den Betreuer. 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:
| 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 | 2005 |
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.
|
|
Boyce / Codd Normalform (BCNF)
Die Boyce/Codd Normalform war ursprünglich als Vereinfachung der dritten Normalform gedacht, fasst jedoch diese 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 Schlüsselkandidat ist.
Beispiel:
| 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:
| Standortsnummer | Standortsname | Stadt |
|---|---|---|
| 10001 | Produktion 1 | Stuttgart |
| 20003 | Verwaltung | Berlin |
| 30012 | 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 gezeigt 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, wo bei 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.