Datenbank-Normalformen einfach erklärt: 1NF, 2NF und 3NF

Wenn dieselbe Information an mehreren Stellen gespeichert wird, können Änderungen auseinanderlaufen. Solche Redundanzen begünstigen Einfüge-, Änderungs- und Löschanomalien. Die Normalisierung ist ein Verfahren, mit dem Tabellen anhand ihrer Abhängigkeiten strukturiert werden, um solche Probleme zu verringern.

Die Normalformen beschreiben Regeln für die Struktur relationaler Tabellen. Hier geht es um die ersten drei Normalformen und die funktionalen Abhängigkeiten, auf die sie sich beziehen.

Das Grundproblem: Datenredundanz und ihre fatalen Folgen

Stellen Sie sich eine einfache Tabelle vor, in der Kundenbestellungen verwaltet werden. In dieser Tabelle werden pro Bestellung nicht nur die Bestelldetails, sondern auch die vollständigen Kundendaten (Name, Adresse, Ort) gespeichert. Wenn ein Kunde nun zehn verschiedene Bestellungen aufgibt, werden seine Adressdaten zehnmal identisch in der Datenbank gespeichert. Dies ist die Definition von Datenredundanz.

Diese Redundanz ist die Brutstätte für sogenannte Anomalien, die die Konsistenz der gesamten Datenbank gefährden. Die Folgen reichen von fehlerhaften Berichten für das Management bis hin zu operativen Pannen, wie dem Versand von Waren an eine veraltete Adresse.

Die drei Anomalien der Dateninkonsistenz

• Änderungsanomalie: Zieht der erwähnte Kunde um, muss seine Adresse an allen zehn Stellen, an denen sie gespeichert ist, manuell geändert werden. Wird nur eine einzige Instanz übersehen, ist die Datenbank inkonsistent. Das System enthält nun widersprüchliche Informationen über den Wohnort des Kunden.
• Einfügeanomalie: Angenommen, Sie möchten einen neuen potenziellen Kunden im System anlegen, der aber noch keine Bestellung aufgegeben hat. Wenn die Struktur der Tabelle eine gültige Bestellnummer erfordert, ist das Anlegen dieses Kunden unmöglich. Sie können keine Kundendaten ohne zugehörige Bestelldaten einfügen.
• Löschanomalie: Löschen Sie die einzige Bestellung eines Kunden aus dem System, könnten damit auch alle Informationen über diesen Kunden verloren gehen – einschließlich seines Namens und seiner Adresse. Das Löschen einer Transaktion führt unbeabsichtigt zum Verlust eines gesamten Stammdatensatzes.

Die Normalisierung ist der systematische Weg, um genau diese Probleme zu verhindern, indem Daten logisch aufgeteilt und intelligent miteinander verknüpft werden.

Schritt 1: Die Erste Normalform (1NF) – Das Prinzip der Atomarität

Die erste und grundlegendste Regel der Normalisierung ist die Herstellung der Ersten Normalform (1NF). Sie ist die Voraussetzung für alle weiteren Schritte und stellt eine minimale Anforderung an jede relationale Datenbanktabelle.

Die Regel: Jeder Attributwert (d. h. der Inhalt einer einzelnen Zelle) in einer Tabelle muss atomar sein. Atomar bedeutet, dass der Wert nicht weiter in kleinere, sinnvolle Einheiten zerlegt werden kann. Listen, durch Kommata getrennte Werte oder andere zusammengesetzte Informationen in einer einzigen Zelle verstoßen gegen dieses Prinzip.

Praktische Umsetzung der 1NF

Nehmen wir an, unsere ursprüngliche Bestelltabelle hat eine Spalte namens „Bestellte_Produkte“, in der steht: „Schrauben (10 Stück), Nägel (50 Stück)“. Dieser Wert ist nicht atomar, da er sowohl mehrere Produkte als auch deren jeweilige Menge enthält.

1. Um die 1NF zu erreichen, lösen wir diese Struktur auf.
2. Statt einer Zeile für die gesamte Bestellung erstellen wir für jeden bestellten Artikel eine eigene Zeile.
3. Die Tabelle enthält nun Spalten wie Bestell-Nr, Kunden-ID, Produkt-ID, Produkt-Name und Anzahl.

Das Ergebnis ist eine Tabelle, in der jede Zeile genau eine Bestellposition repräsentiert und jede Zelle nur noch einen einzigen, unteilbaren Wert enthält. Obwohl die Redundanz (z.B. der Kundenname wird für jede Bestellposition wiederholt) dadurch kurzfristig sogar zunehmen kann, haben wir die Daten nun so strukturiert, dass wir sie im nächsten Schritt sinnvoll aufteilen können.

Schritt 2: Die Zweite Normalform (2NF) – Volle funktionale Abhängigkeit

Nachdem die Atomarität sichergestellt ist, widmet sich die Zweite Normalform (2NF) der Abhängigkeit von Attributen vom Primärschlüssel.

Die Regel: Eine Tabelle befindet sich in der 2NF, wenn sie in der 1NF ist und jedes Nicht-Schlüssel-Attribut voll funktional vom gesamten Primärschlüssel abhängt. Diese Regel ist besonders relevant, wenn der Primärschlüssel aus mehreren Spalten zusammengesetzt ist (ein sogenannter zusammengesetzter Primärschlüssel).

Praktische Umsetzung der 2NF

In unserer Tabelle aus dem 1NF-Beispiel ist die Bestell-Nr allein kein eindeutiger Schlüssel mehr, da sie für mehrere Artikel vorkommen kann. Der Primärschlüssel, der eine Zeile eindeutig identifiziert, ist die Kombination aus Bestell-Nr und Produkt-ID.

Nun prüfen wir die Abhängigkeiten:

• Die Anzahl ist vom gesamten Schlüssel (Bestell-Nr + Produkt-ID) abhängig. Sie gibt an, wie viele Einheiten eines bestimmten Produkts in einer bestimmten Bestellung enthalten sind. Das ist korrekt.
• Der Kunden-Name und Kunden-Ort hängen jedoch nur von der Bestell-Nr ab. Welches Produkt bestellt wurde, ist für die Adresse des Kunden irrelevant. Dies ist eine Verletzung der 2NF.
• Der Produkt-Name und Produkt-Preis hängen nur von der Produkt-ID ab. Sie sind unabhängig von der Bestellung. Auch dies ist eine Verletzung der 2NF.

Die Lösung besteht darin, die Tabelle in mehrere logische Einheiten aufzuteilen, die jeweils ein Thema abbilden:

1. Kunden-Tabelle: Enthält Kunden-ID (Primärschlüssel), Kunden-Name, Kunden-Ort.
2. Produkte-Tabelle: Enthält Produkt-ID (Primärschlüssel), Produkt-Name, Produkt-Preis.
3. Bestellungen-Tabelle: Verknüpft Bestellungen mit Kunden und enthält z.B. Bestell-Nr (Primärschlüssel) und Kunden-ID (Fremdschlüssel).
4. Bestellpositionen-Tabelle: Die eigentliche Verknüpfungstabelle, die Bestell-Nr und Produkt-ID (zusammen der Primärschlüssel) sowie die Anzahl enthält.

Durch diese Aufteilung wird die Redundanz drastisch reduziert. Kundendaten und Produktdaten sind jetzt nur noch ein einziges Mal gespeichert. Die Tabellen sind über Fremdschlüssel miteinander verbunden.

Schritt 3: Die Dritte Normalform (3NF) – Beseitigung transitiver Abhängigkeiten

Die Dritte Normalform (3NF) geht noch einen Schritt weiter und eliminiert eine subtilere Form der Abhängigkeit innerhalb einer Tabelle.

Die Regel: Eine Tabelle befindet sich in der 3NF, wenn sie in der 2NF ist und kein Nicht-Schlüssel-Attribut von einem anderen Nicht-Schlüssel-Attribut abhängt. Eine solche unerwünschte Kettenreaktion wird als transitive Abhängigkeit bezeichnet.

Praktische Umsetzung der 3NF

Betrachten wir unsere neue Kunden-Tabelle aus dem 2NF-Schritt. Sie enthält Kunden-ID, Kunden-Name und Kunden-Ort. Nehmen wir an, wir fügen eine Spalte Länderkennzeichen (z.B. “DE”) hinzu. Hier ergibt sich folgende Abhängigkeitskette:

´Kunden-ID´ → ´Kunden-Ort´ → ´Länderkennzeichen´

Das Länderkennzeichen hängt nicht direkt vom Primärschlüssel (Kunden-ID) ab, sondern vom Kunden-Ort, der selbst kein Schlüssel ist. Dies ist eine transitive Abhängigkeit. Das Problem: Ändert sich das Länderkennzeichen eines Ortes, müsste dies bei jedem Kunden, der in diesem Ort wohnt, angepasst werden – eine klassische Änderungsanomalie.

Die Lösung ist konsequent: Wir lagern auch diese Abhängigkeit in eine eigene Tabelle aus:

1. Orte-Tabelle: Enthält Orts-ID (Primärschlüssel), Ortsname und Länderkennzeichen.
2. Kunden-Tabelle (angepasst): Enthält nun Kunden-ID (Primärschlüssel), Kunden-Name und die Orts-ID als Fremdschlüssel.

Nach diesem Schritt sind alle unsere Tabellen in der Dritten Normalform. Jede Tabelle beschreibt nur noch einen einzigen Sachverhalt, Redundanzen sind auf ein Minimum reduziert und die Datenintegrität ist maximal geschützt.

Fazit: Nutzen und Abwägungen der Normalisierung

Die Normalisierung kann Redundanzen und bestimmte Änderungsanomalien verringern. Ein normalisiertes Schema kann außerdem leichter konsistent zu pflegen sein. Die Auswirkungen auf Abfrageaufwand und Laufzeit hängen jedoch von Datenbank, Abfragen und Zugriffsmustern ab; zusätzliche Tabellen und Verknüpfungen können Abfragen komplexer machen. In manchen Systemen wird daher gezielt denormalisiert, nachdem die Anforderungen und Auswirkungen geprüft wurden.

Normalformen sind damit ein Entwurfswerkzeug, keine Garantie für fehlerfreie Daten oder schnelle Abfragen. Das Schema sollte sich an fachlichen Regeln und den tatsächlichen Anforderungen der Anwendung orientieren.