Was ist die Normalisierung?
Inhaltsverzeichnis
Die Modellierung alleine liefert nicht immer ein redundanzfreies Datenbankschema, beispielsweise könnte die Aufgabe einer Bestellung wie folgt modelliert werden:
Das zugehörige Schema könnte wie folgt aussehen:
Schema: Kunde ( Name, .... ) Produkt ( Bez, .... ) bestellt( Name, Bez, AuftrNr, Datum )
Die Redundanz liegt hierbei in einem Kundenauftrag für mehrere Produkte:
| Name | Bez | AuftrNr | Datum |
| Huber | Schraube | 01 | 01.01.02 |
| Huber | Nagel | 01 | 01.01.02 |
| Huber | Schraube | 02 | 01.02.02 |
| Meier | Schraube | 03 | 05.01.02 |
Hier kann es folgende Redundanzen geben:
- Es sind zwei verschiedene Daten zu einem Auftrag möglich
- Es sind zwei verschiedene Kunden zu einem Auftrag möglich
Redundanzen entstehen durch funktionale Abhängigkeiten: das Datum ist funktional abhängig von AuftrNr und der Name ist funktional abhängig von AuftrNr. Gründe für die Normalisierung von relationalen Modellen sind daher
- Die Vermeidung unerwünschter Anomalien (Einfügen, Löschen, Änderungen)
- Vermeidung von Redundanz
- Eine verbesserte Übersichtlichkeit des Datenmodells
Oft sind diese Probleme durch “Vermischung” von Entities, Zerlegung und wiederholte Speicherung von Entities und dergleichen hervorgerufen. Normalisierung von Relationen hilft daher, einen gegebenen Entwurf zu verbessern.
Es existieren verschiedene Normalformen, die aufeinander aufbauen:
- 1NF – Erste Normalform
- 2NF – Zweite Normalform
- 3NF – Dritte Normalform
- BCNF – Boyce-Codd-Normalform
- 4NF – Vierte Normalform
- 5NF – Fünfte Normalform
Die Normalisierung erfolgt somit schrittweise:
- 1NF: enthält normalisierte Relationen (einfache Attribute)
- 2NF: enthält keine partiellen (funktionalen) Abhängigkeiten
- 3NF: enthält keine transitiven Abhängigkeiten (jedes Nicht-Primärattribut ist direkt von jedem SK abhängig)
- BCNF: jeder Determinant ist Schlüsselkandidat
In der Praxis erfolgt die Normalisierung bis zur dritten Normalform.
Im Relationenmodell ist die 1NF immer erforderlich, eine Umwandlung in die 2NF und 3NF ist immer möglich. Die Normalisierung gemäß der 2NF und 3NF unterstützt die Gewährleistung referentieller Integrität insbesondere bei schreibenden, d.h. verändernden Zugriffen – für lesende Zugriffe ist sie nicht zwingend notwendig.
Aber auch: Normalisierung – insbesondere die 3NF – führt u.U. zu reduzierter Laufzeit-Performance (Informationen müssen bei jedem Zugriff u.U. aus mehreren Tabellen zusammengefügt werden). In der Praxis wird – zur Performance-Optimierung – teilweise auf die 3NF verzichtet („Denormalisierung“).
Die Empfehlung lautet daher, bereits bei der Entity-Relationship-Modellierung „normalisiert“ zu denken und danach zuerst zu normalisieren und nur bei Performance-Problemen, die nachweislich auf die NF zurückzuführen sind, u.U. zu „denormalisieren“.
Was ist die erste Normalform?
Definition: „Ein Relationenschema ist in erster Normalform, wenn alle Attribute nur atomare Werte enthalten können“. Das bedeutet, dass kein Attribut (keine Spalte) innerhalb einer Relation (einer Zeile) mehr als einen Wert haben darf.
Daraus folgt auch, dass für Attributwerte nur einfache Datentypen erlaubt sind, z.B. Integer, String, Decimal, …, also Listen, Mengen oder Relationen als Attribute nicht erlaubt sind.
In der folgenden Personen-Tabelle enthält das Feld „Telefonnummern“ eine Liste von Einträgen und verstößt damit gegen die 1NF. Obwohl der Name und der Wohnort noch weiter unterteilt werden könnten, verstoßen diese Spalten nicht gegen die 1NF:
| PersonID | Name | Vorname | Ort | Straße | Telefonnummern |
| 91 | Köster | Gabi | Bremen | Hauptstraße 1 | 04421 / 392881, 0173 / 3849234 |
| 98 | Steward | Maria | Oldenburg | 0441 / 3495012 |
Abbildung 52: Tabelle mit Listen in einem Attribut
Zur Lösung kann man entweder mehrere Attribute vorsehen (z.B. Festnetznummer, Handynummer, Telefax) – oder eine neue Tabelle einführen, welche eine 1:mc-Beziehung zur Tabelle Person hat.
Was ist die zweite Normalform?
Definition: „Eine Tabelle erfüllt die 2. Normalform, wenn sie die 1NF erfüllt und jedes Attribut, das nicht zum Primärschlüssel gehört, voll von diesem abhängig ist“. Die Betonung liegt hier auf dem Wort „voll“, d.h. es gibt kein Attribut, welches schon von einem Teil des Schlüssels funktional abhängt. Ist der Primärschlüssel einfach (also nicht aus mehreren Attributen zusammengesetzt), dann ist die 2NF trivialerweise erfüllt.
Die Motivation der 2NF ist es zu verhindern, dass Attribute nicht vom gesamten Schlüssel voll funktional abhängig sind, sondern nur von einem Teil davon. Die 2NF vermeidet einige der Anomalien dadurch, indem nicht voll funktional (partiell) abhängige Attribute eliminiert werden, also verschiedene Entity-Mengen in eigene Relationen separiert werden.
Funktionale Abhängigkeit
Definition: Y ist funktional abhängig von X, geschrieben X→Y, wenn es keine Relation vom Typ R geben kann, in der zwei Tupel denselben Wert für X, aber verschiedene Werte für Y haben.
| R | |||
| A | B | C | D |
| a | 1 | f | 9 |
| a | 1 | g | 9 |
| b | 3 | f | 7 |
| b | 3 | g | 6 |
In dieser Tabelle gelten folgende funktionale Abhängigkeiten:
A → B (d.h. aus „A = a“ folgt „B = 1“ oder „A = b“ folgt „B = 3“, alle Tupel)
B → A (d.h. aus „B = 1“ folgt „A = a“ oder „B = 3“ folgt „A = b“, alle Tupel)
D → B (d.h. aus „D = 9“ folgt „B = 1“, Tupel 1 und 2)
D → A (d.h. aus „D = 9“ folgt „A = a“, Tupel 1 und 2)
AD → B (d.h. aus „AD = 1/9“ folgt „B = 1“, Tupel 1 und 2)
BD → A (d.h. aus „BD = 1/9 folgt „A = a“, Tupel 1 und 2)
Funktional abhängig zu sein heißt also, dass aus einem Attribut (oder aus einer Attributkombination) auf das oder die anderen geschlossen werden kann. Die Tabelle
zeigt, dass B von A funktional abhängt, nämlich ein Wert von A jenen von B bestimmt, es also eindeutig festgelegte (A, B)-Kombinationen gibt:
| A | B |
| 1 | a |
| 2 | b |
| 1 | a |
| 4 | d |
Umgekehrt ist das nicht der Fall, d.h. A hängt nicht von B ab, denn der B-Wert „a“ kommt sowohl in Kombination mit dem A-Wert „1“ als auch mit dem A-Wert „3“ vor.
Noch ein Beispiel dazu: die Artikel-Bezeichnung in der folgenden Tabelle ist funktional abhängig von der Artikel-ID (die Teil des Primärschlüssels ist), da man aus der Artikel-ID auf die Artikel-Bezeichnung schließen kann:
| KundeID | ArtikelID | LfdNr | ArtikelBezeichnung | Menge | BestellDatum |
| 13 | 2 | 1 | Motor | 5 | 2005-12-01 |
| 13 | 2 | 2 | Motor | 12 | 2006-10-12 |
| 12 | 2 | 1 | Motor | 1 | 2006-04-01 |
| 3 | 3 | 1 | Akku | 5 | 2006-07-03 |
| 13 | 5 | 1 | Schraube | 1 | 2010-11-01 |
Funktionale Abhängigkeit der Artikelbezeichnung
Konsequenz ist die Auslagerung der Artikel-ID-zu-Artikel-Bezeichnung-Verbindung in eine eigene Tabelle, z.B. wie folgt:
| KundeID | ArtikelID | LfdNr | Menge | BestellDatum | |||
| 13 | 2 | 1 | 5 | 2005-12-01 | |||
| 13 | 2 | 2 | 12 | 2006-10-12 | ArtikelID | ArtikelBezeichnung | |
| 12 | 2 | 1 | 1 | 2006-04-01 | 2 | Motor | |
| 3 | 3 | 1 | 5 | 2006-07-03 | 3 | Akku | |
| 13 | 5 | 1 | 1 | 2010-11-01 | 5 | Schraube |
Was ist die dritte Normalform?
Die zweite Normalform hat sich auf die Abhängigkeit von Attributen von Schlüsseln konzentriert. Damit ist aber immer noch nicht eine volle Redundanzfreiheit gesichert, da noch Attributkombinationen auftreten können, die zwar mit einem Schlüssel nichts zu tun haben, aber dennoch Redundanz beinhalten.
Die folgende beispielhafte Tabelle erfüllt 2NF, jedoch gibt es noch die Abhängigkeit zwischen der ArtikelID und der Artikelbezeichnung:
| BestellungID | KundeID | ArtikelID | ArtikelBezeichnung | Menge | BestellDatum |
| 1 | 13 | 2 | Motor | 5 | 2005-12-01 |
| 2 | 13 | 2 | Motor | 12 | 2006-10-12 |
| 3 | 12 | 2 | Motor | 1 | 2006-04-01 |
| 4 | 3 | 3 | Akku | 5 | 2006-07-03 |
Die Überführung von 2NF in 3NF ist grundsätzlich die gleiche wie zuvor, nämlich dass diese Abhängigkeiten wieder in eine eigene Tabelle ausgelagert werden und in diesem Beispiel die ArtikelID zum Fremdschlüssel wird:
| BestellungID | KundeID | ArtikelID | Menge | BestellDatum | |||
| 1 | 13 | 2 | 5 | 2005-12-01 | |||
| 2 | 13 | 2 | 12 | 2006-10-12 | ArtikelID | ArtikelBezeichnung | |
| 3 | 12 | 2 | 1 | 2006-04-01 | 2 | Hilfsmotoren | |
| 4 | 3 | 3 | 5 | 2006-07-03 | 3 | Akku |
Was ist die Boyce-Codd-Normalform?
Anmerkung: es gibt verschiedene, leicht unterschiedliche Definitionen der 3NF. Gelegentlich wird auch die Boyce-Codd-Normalform bereits als dritte Normalform bezeichnet.
Die Definition der dritten Normalform hat gewisse Schwächen bei Relationen mit mehreren, sich überlappenden Schlüsselkandidaten. Ziel ist die Beseitigung der Anomalien für Primärattribute. Dabei wird ein Attribut (oder eine Gruppe von Attributen), von dem andere voll funktional abhängen, als Determinant bezeichnet.
Was ist die vierte und fünfte Normalform?
Primärschlüssel und alternative Schlüssel sind möglichst so zu wählen, dass sie nur aus ein oder höchstens zwei Attributen bestehen. Dies sind Aussage und Inhalt der vierten (Vermeidung transitiver Abhängigkeiten) und fünften Normalform (Rekonstruktion aus JOINS).
Besitzt eine Relation einen nicht zusammengesetzten Primärschlüssel, so fallen die Definitionen der dritten, vierten und fünften Normalform zusammen. Die 4NF und 5NF haben in der Praxis auch deshalb wenig Bedeutung, weil diese Situationen bei einem sorgfältigen Entwurf eines ER-Schemas nicht auftreten.