Datenbanknormalisierung: 1NF, 2NF und 3NF

Eine Normalform ist ein Regelsatz für Tabellen. Jede Normalform schließt die Regeln der vorherigen ein: Wer die 3NF erfüllt, erfüllt auch die 2NF und die 1NF. Spalten heißen auch Felder oder Attribute. Eine Tabelle heißt in der Datenbanktheorie auch Relation.

Zur 1NF: Jedes Attribut muss einen atomaren Wertebereich haben, und die Tabelle muss frei von Wiederholungsgruppen sein. Atomar heißt: Zusammengesetzte, mengenwertige oder geschachtelte Wertebereiche sind nicht erlaubt. Eine Adresse darf deshalb nicht als einzelnes Attribut stehen, sondern wird in PLZ, Ort, Straße und Hausnummer aufgeteilt, wenn der zugrunde liegende Prozess es erfordert und erlaubt. Eine Wiederholungsgruppe ist zum Beispiel eine Spalte Telefon, die mehrere Telefonnummern enthält. Auch eine Spaltengruppe Telefon1, Telefon2, Telefon3 kann eine sein. In einer Fassung der Regel (bei Wikibooks) gehört zur 1NF außerdem, dass jede Tabelle einen Primärschlüssel enthält.

Beispiel für Verstöße: In einer Tabelle CD_Lied enthält das Feld Album die Werte Interpret und Albumtitel zusammen. Das Feld Titelliste enthält eine Menge von Titeln. Beide Felder verletzen die 1NF.

Zur 2NF: Die Tabelle muss in 1NF sein, und kein Nichtprimärattribut darf von einer echten Teilmenge eines Schlüsselkandidaten funktional abhängen. Ein Nichtprimärattribut (auch Nichtschlüsselattribut) ist ein Attribut, das nicht Teil eines Schlüsselkandidaten ist. Was ein Schlüsselkandidat ist, siehst du im nächsten Abschnitt. Beispiel: CD_Lied hat nach dem Aufteilen von Album und Titelliste den Schlüssel aus CD_ID und Track. Albumtitel, Interpret, Gründungsjahr und Erscheinungsjahr hängen nur von CD_ID ab, nicht von Track. Das verletzt die 2NF. Besteht jeder Schlüsselkandidat nur aus einem einzigen Attribut, erfüllt eine Tabelle in 1NF automatisch die 2NF.

Zur 3NF: Die Tabelle erfüllt die 2NF, und die Nichtschlüsselattribute hängen nicht funktional voneinander ab. Ein Nichtschlüsselattribut darf nur direkt von einem Primärschlüssel oder Schlüsselkandidaten abhängen. Beispiel: In der Tabelle CD (CD_ID, Albumtitel, Interpret, Gründungsjahr, Erscheinungsjahr) lässt sich der Interpret aus der CD_ID bestimmen. Das Gründungsjahr hängt vom Interpreten und damit transitiv von der CD_ID ab. Das verletzt die 3NF.

Eine funktionale Abhängigkeit liegt vor, wenn einige Attribute die Werte anderer Attribute eindeutig bestimmen. In einer Relation R(A,B) ist B von A funktional abhängig, falls zu jedem Wert von A genau ein Wert von B gehört. Man schreibt A → B oder A, B → C. Der Pfeil liest sich als „bestimmt eindeutig“.

Mit solchen Abhängigkeiten lässt sich auch ein Schlüssel erklären. Bestimmen einige Attribute eindeutig die Werte aller Attribute der Relation, nennt man sie einen Superschlüssel. Ein Schlüsselkandidat ist ein minimaler Superschlüssel: Keine echte Teilmenge seiner Attribute bestimmt vollständig die Werte aller anderen Attribute der Relation. Unter den Schlüsselkandidaten wird ein Primärschlüssel ausgewählt.

Eine partielle Abhängigkeit gibt es bei einem zusammengesetzten Schlüssel: Ein Nichtschlüsselattribut hängt nur von einem Teil des Schlüsselkandidaten ab. In CD_Lied mit dem Schlüssel aus CD_ID und Track hängen Albumtitel, Interpret, Gründungsjahr und Erscheinungsjahr nur von CD_ID ab, nicht von Track. Das sind partielle Abhängigkeiten. Dagegen heißt B von den Schlüsselattributen S1 und S2 voll funktional abhängig, wenn B von (S1, S2) zusammen abhängt, nicht aber von S1 oder S2 allein. Der Titel eines Liedes hängt voll von CD_ID und Track ab. Die 2NF beseitigt alle partiellen Abhängigkeiten.

Eine transitive Abhängigkeit ist eine funktionale Abhängigkeit zwischen Nichtschlüsselattributen. Hängt die Attributmenge A1 von P1 ab und das Attribut A2 von A1, dann ist A2 transitiv von P1 abhängig. Das gilt aber nur, wenn A1 kein Schlüsselkandidat ist. Beispiel: CD_ID → Interpret → Gründungsjahr. Die 3NF beseitigt diese Abhängigkeiten.

Wir zerlegen die Tabelle CD_Lied Schritt für Schritt. Zuerst die 1NF: Das Feld Album wird in Albumtitel und Interpret gespalten. Das Feld Titelliste wird in die Felder Track und Titel gespalten und auf mehrere Datensätze aufgeteilt. Jetzt ist jeder Wertebereich atomar, und die Tabelle hat einen eindeutigen Primärschlüssel: den Verbundschlüssel aus CD_ID und Track, also einen aus zwei Spalten zusammengesetzten Schlüssel.

Dann die 2NF: Die Daten werden in zwei Tabellen CD und Lied aufgeteilt. Die Tabelle CD enthält nur noch Felder, die voll funktional von CD_ID abhängen, und hat CD_ID als Primärschlüssel. Eine Zeile lautet: 4711, Not That Kind, Anastacia, 1999, 2000. Die Tabelle Lied enthält nur noch Felder, die voll funktional von CD_ID und Track abhängen. Das Attribut CD_ID in Lied ist ein Fremdschlüssel, der auf den Primärschlüssel der Tabelle CD verweist. Zugleich bilden CD_ID und Track den zusammengesetzten Primärschlüssel von Lied.

Dann die 3NF: Die beiden voneinander abhängigen Daten Interpret und Gründungsjahr kommen in eine eigene Tabelle Künstler. Der Schlüssel der neuen Tabelle muss als Fremdschlüssel in der alten Tabelle erhalten bleiben. Ohne eigene ID gilt diese Lösung nur, wenn der Interpret weltweit eindeutig ist. Sonst braucht die Tabelle Künstler eine synthetische ID, also eine künstlich vergebene Nummer: Künstler (Interpret_ID, Interpret, Gründungsjahr) und CD (CD_ID, Albumtitel, Interpret_ID, Erscheinungsjahr). Die Tabelle Lied bleibt unverändert. Mit synthetischer ID gehört in Künstler die Zeile 311, Anastacia, 1999.

Eine Zerlegung muss die ursprüngliche Tabelle wiederherstellbar lassen. Ein weiteres Beispiel von Wikibooks: Aus einer Tabelle Fahrzeuge werden Hersteller und Typ in die neue Tabelle Fahrzeugtypen übertragen. In Fahrzeuge werden beide Spalten durch einen Fremdschlüssel ersetzt, der auf Fahrzeugtypen verweist.

Normalisierung dient dazu, redundante Speicherung von Informationen und damit Inkonsistenz und Anomalien zu vermeiden. Redundanz ist das mehrfache Festhalten des gleichen Sachverhalts. Anomalien entstehen zum Beispiel, wenn eine Änderung nicht an allen Stellen gemacht wird.

Beispiel Update-Anomalie: In der Tabelle CD_Lied steht der Albumtitel in jeder Zeile einer CD. Man könnte den Albumtitel für das Lied Not That Kind in I Don’t Mind ändern, ohne die Einträge für I’m Outta Love und Cowboys & Kisses zu ändern. Danach passen die Daten über die ganze Tabelle nicht mehr zusammen. Diesen Zustand nennt man Dateninkonsistenz.

Auch ein Verstoß gegen die 3NF führt zu Redundanz: Wird zu einem schon vorhandenen Interpreten eine neue CD eingeführt, so wird das Gründungsjahr redundant gespeichert.

Ein Kunde kann mehrere Aufträge haben. Stünden die Kundendaten in der Auftragstabelle, kämen sie dort mehrfach vor. Gibt man in einem Auftrag eine fehlerhafte Adresse ein und im nächsten die richtige, kann es zu widersprüchlichen Daten kommen. Bei einer normalisierten Datenbank gibt es für die Kundendaten nur einen einzigen Eintrag in der Kundentabelle, mit der jeder Auftrag dieses Kunden verknüpft wird, üblicherweise über die Kundennummer. Das spart bei sehr vielen Datensätzen auch Speicherplatz, weil ein Auftrag nur auf den Kunden verweist.

So wird die Aktualisierung einfacher: Änderungen sind nur an einer Stelle nötig. Die Redundanzfreiheit steht aber in speziellen Anwendungsfällen in Konkurrenz zur Verarbeitungsgeschwindigkeit. Deshalb kann es sinnvoll sein, auf Normalisierung zu verzichten oder sie durch Denormalisierung rückgängig zu machen.