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, das heißt, 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 oder Fehler) 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 zum Beispiel 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). Insbesondere sind keine Aufzählungen oder Listen als Attributwerte erlaubt.
Praktischer Nutzen
Die Möglichkeit einer formalen Abfrage wird verbessert, da die Attribute elementar sind (die Ausprägungen eines Attributes sind sich somit formal sehr ähnlich).
Beispiel:
Ein Feld „Name“ beinhaltet Vornamen und Nachnamen einer Person.
Ein Feld „Adresse“ beinhaltet Land, Ort, PLZ, Strasse, Hausnummer.
Ein Feld „Kinder“ beinhaltet eine Aufzählung der Kinder einer Person.
Fehler/Problem:
Zur Sortierung nach Nachnamen muss das Feld in Vornamen und Nachnamen aufgeteilt werden.
Die Kinder können (mit einfachen Mitteln) nur alle gleichzeitig oder gar nicht dargestellt werden.
Lösung:
Man benötigt die Felder „Vorname“ und „Nachname“, die diese Informationen getrennt aufnehmen.
Aufzählungsattribute werden in eigene Tabellen ausgelagert.
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, KC) und jedes Attribut a der Relation gilt:
- a gehört zu KC oder
- a ist von keiner echten Teilmenge von KC abhängig.
Praktischer Nutzen:
Datenredundanz und die damit einhergehende Gefahr der Dateninkonsistenz durch Anomalien kann behoben werden. Nur logisch zusammenhängende Daten finden sich in einer Relation. Dadurch fällt das Verständnis der Datenstrukturen leichter.
Beispiel:
Gegeben sei eine Tabelle mit folgenden Feldern:
| 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 Kind 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).
| CD_ID | CD_Titel | CD_Interpret | CD_Preis | TrackID | LiedTitel |
|---|---|---|---|---|---|
| 4711 | Not That Kind | Anastacia | 15,99€ | 1 | Not That Kind |
| 4711 | Not That Kind | 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.
|
|
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.
|
|
Mit Hilfe dieser verlustfreien Zerlegung sind die genannten Redundanzen der Daten beseitigt. In jedem Datensatz aus der Tabelle Lieder 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 sich die Relation in 2NF befindet und 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 (Formaler: P1->P2 ^ P2->A1 => P1->A1).
Vielleicht einfacher ausgedrückt: Die Bedingungen der 2. NF müssen erfüllt sein UND kein Nicht-Schlüsselfeld darf von einem anderen Nicht- Schlüsselfeld abhängig sein (ein Fremdschlüssel ist KEIN Nicht-Schlüsselfeld).
Siehe auch: Transitivität (Mathematik), Synthesealgorithmus-Normalform
Praktischer Nutzen:
Verfeinerung der 2NF in Bezug auf Datenredundanz und die damit einhergehende Gefahr der Dateninkonsistenz. Durch die Aufteilung der transitiven Abhängigkeiten auf mehrere Tabellen können Abfragen auf die Datenbank schneller bearbeitet werden. Die transitiven Abhängigkeiten muss das System nicht irgendwie wissen, sondern sind durch die Struktur der Tabellen wiedergegeben.
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 | 204 |
| 144 | Frank | Frei | Verkauf | 206 |
| 146 | Susi | Sorglos | Einkauf | 204 |
| 148 | Frey | Erfunden | Einkauf | 205 |
Da die Abteilung Einkauf die Kostenstelle 204 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 204 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 diese jedoch schärfer und führte so zu einem neuen Typ der Normalform. Alle Relationen können zwar in die dritte Normalform übertragen werden, nicht aber in die Boyce-Codd-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.
Die Überführung in die BCNF ist zwar immer verlustfrei, aber häufig nicht abhängigkeitserhaltend.
Beispiel:
| KST_Nr | KST_Abteilung | KST_Leiter |
|---|---|---|
| 204 | Einkauf | Schmidt |
| 306 | Verkauf | Maier |
| 308 | Marketing | Maier |
Das Attribut KST_Nr beeinflusst in diesem Beispiel zusammen mit KST_Abteilung das Feld KST_Leiter. Dies ist eine funktionale Abhängigkeit. Des Weiteren 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:
| Standortnummer | Standortname | Stadt |
|---|---|---|
| 10001 | Stuttgart Produktion 1 | Stuttgart |
| 20003 | Berlin Verwaltung | Berlin |
| 30012 | München Vertrieb | München |
Die Standortnummer bestimmt den Namen des Standortes. In dieser Relation würde die Standortnummer aber auch noch den Namen der Stadt beeinhalten, welcher sich aber vom Standortnamen 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 Standortnummer und Standortname, und in einer zweiten Standortname 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 Structured-ERM (SERM) und das E3R-Modell, entwickelt von Professor Mario Jeckle.
Weblinks
- Kent, William: A Simple Guide to Five Normal Forms in Relational Database Theory, Communications of the ACM 26(2), Feb. 1983, 120-125. (engl. Paper)
- http://www.itse-guide.de/artikel/25
- http://www.rent-a-database.de/mysql/mysql-253.html
- http://home.t-online.de/home/dieter.spiess/informatik/datenbanken/normalisierung.htm
- http://v.hdm-stuttgart.de/~riekert/lehre/db-kelz/chap4.htm
- http://www.tinohempel.de/info/info/datenbank/normalisierung.htm
Literatur
- Kemper, Alfons; Eickler, Andre: Datenbanksysteme - Eine Einführung, 2004, ISBN 3486273922