Normalisierung: 2. und 3. Normalform
Die 1. Normalform sorgt dafür, dass in jeder Zelle nur ein atomarer Wert steht. Das beseitigt die offensichtlichsten Probleme – aber nicht die tieferliegenden. Eine Tabelle kann in 1NF sein und trotzdem Redundanzen enthalten, die zu Anomalien beim Einfügen, Ändern oder Löschen führen. Die 2. und 3. Normalform packen genau diese Probleme an – sie zerlegen Tabellen so, dass jede Information nur an genau einer Stelle steht.
Das Zauberwort heißt funktionale Abhängigkeit: Ein Attribut B ist funktional abhängig von Attribut A, wenn A eindeutig B bestimmt. Beispiel: Die plz bestimmt eindeutig die stadt – wer 50667 hat, ist in Köln. 2NF und 3NF analysieren diese Abhängigkeiten und sorgen dafür, dass jede Abhängigkeit nur an einer einzigen Stelle implementiert wird.
1) Die Normalisierungsstufen im Slider
Hier siehst du dieselbe Bestellungs-Tabelle in vier Stufen: ohne jegliche Normalisierung (0NF) bis hin zu 3NF. Beobachte, wie aus einer großen, redundanten Tabelle mit jedem Schritt mehr kleine, saubere Tabellen werden:
2) Funktionale Abhängigkeit – das zentrale Konzept
Bevor wir 2NF und 3NF präzise definieren, brauchen wir den Begriff der funktionalen Abhängigkeit. Schreibweise: A → B bedeutet: „A bestimmt B", also: Wer den Wert von A kennt, kennt automatisch den Wert von B.
Beispiele aus der Bestellungs-Tabelle:
k_id → k_name, strasse, plz– aus einer Kunden-ID folgen automatisch alle Kundendaten.plz → stadt– die PLZ bestimmt eindeutig die Stadt (50667 → Köln, niemals etwas anderes).a_id → artikelname– aus der Artikel-ID folgt der Name.(b_nr, a_id) → menge, preis– nur im Kontext einer konkreten Bestellung und eines konkreten Artikels sind Menge und Preis bestimmt.
Solche Abhängigkeiten zu identifizieren ist die Kernkompetenz bei der Normalisierung. Pro funktionale Abhängigkeit gehört genau eine Tabelle – das ist im Grunde die einzige Regel, die du dir merken musst. Der Rest sind Anwendungen davon.
3) Die 2NF – keine partielle Abhängigkeit
Die 2. Normalform (2NF) richtet sich an Tabellen mit zusammengesetzten Primärschlüsseln (also Schlüsseln aus mehreren Spalten). Sie fordert: Jedes Nicht-Schlüssel-Attribut muss von dem GANZEN Primärschlüssel abhängen, nicht nur von einem Teil davon.
In Klartext: Wenn der Primärschlüssel aus (A, B) besteht und es ein Attribut C gibt, das schon allein von A bestimmt wird (also A → C, ohne B zu brauchen), dann ist das eine partielle Abhängigkeit und verletzt 2NF.
(b_nr, a_id), in denen Bestelldaten (Datum, Kunde) mit hineingerutscht sind.4) Die 3NF – keine transitive Abhängigkeit
Die 3. Normalform (3NF) packt das letzte verbliebene Redundanzproblem an: Nicht-Schlüssel-Attribute dürfen nicht von anderen Nicht-Schlüssel-Attributen abhängen. Solche Ketten Schlüssel → A → B heißen transitive Abhängigkeit und verletzen 3NF.
Klassisches Beispiel: In der Kunden-Tabelle gibt es k_id, plz, stadt. Die k_id bestimmt die plz – das ist okay. Aber die plz bestimmt auch die stadt: Sie ist nicht direkt vom Schlüssel abhängig, sondern hängt indirekt über die plz ab. Das ist eine transitive Abhängigkeit. Lösung: Eine eigene plz_ort-Tabelle anlegen.
Eine einprägsame Faustregel für die 3NF lautet: „Jedes Nicht-Schlüssel-Attribut muss vom Schlüssel abhängen, vom ganzen Schlüssel und nichts als dem Schlüssel – so wahr mir Codd helfe." Das ist eine humorvolle Anspielung auf den Eid vor Gericht – und stammt von Datenbank-Lehrern, weil sie die drei Normalformen perfekt zusammenfasst (vom Schlüssel = 1NF braucht überhaupt einen Schlüssel; vom ganzen Schlüssel = 2NF; nichts als dem Schlüssel = 3NF, keine Umwege).
5) Was passiert, wenn man NICHT normalisiert?
Die ganze Theorie wäre Selbstzweck, wenn sie keine konkreten Probleme verhindern würde. Tatsächlich verhindert Normalisierung drei klassische Anomalien:
Insert-Anomalie
Man kann bestimmte Daten nicht einfügen, weil andere Pflichtfelder fehlen.
Neuen Artikel anlegen, aber keine Bestellung dafür? In unnormalisierter Tabelle unmöglich.Update-Anomalie
Eine Änderung muss an vielen Stellen gleichzeitig erfolgen. Vergisst man eine, sind die Daten inkonsistent.
Müller zieht um → in 200 Zeilen ändern. Eine vergessen → Datenleiche.Delete-Anomalie
Löschen einer Zeile löscht ungewollt andere wichtige Daten.
Letzte Bestellung von Meier löschen → Kunde Meier verschwindet komplett aus dem System.6) Der praktische Workflow
So gehst du in einer IHK-Aufgabe oder im Praxisprojekt vor, wenn du eine Tabelle in 3NF bringen sollst:
- 1NF prüfen: Gibt es mehrwertige Zellen oder zusammengesetzte Werte? → Aufteilen.
- Primärschlüssel bestimmen: Welche Spalten identifizieren eine Zeile eindeutig?
- Funktionale Abhängigkeiten listen: Welches Attribut bestimmt welches? Notation:
A → B. - 2NF prüfen: Ist der Schlüssel zusammengesetzt? Hängen alle Nicht-Schlüssel-Attribute vom ganzen Schlüssel ab? Wenn nicht: Auslagern in eigene Tabelle.
- 3NF prüfen: Hängen alle Nicht-Schlüssel-Attribute nur direkt vom Schlüssel ab, ohne Umweg? Wenn nicht: Transitive Abhängigkeit auslagern.
- Fremdschlüssel setzen: Verbindungen zwischen den entstandenen Tabellen über Foreign Keys herstellen.
Dieser Workflow ist ein Garant für korrekte Lösungen. Wer ihn anwendet, kommt zwingend bei einem normalisierten Schema heraus.
7) Boyce-Codd, 4NF, 5NF – muss man die kennen?
Es gibt höhere Normalformen, die theoretisch interessant sind: Boyce-Codd-Normalform (BCNF), 4NF, 5NF. Sie behandeln Spezialfälle mit mehreren überlappenden Schlüssel-Kandidaten oder mit mehrwertigen Abhängigkeiten. Für die IHK-Abschlussprüfung sind sie nicht relevant – und auch in 95 % aller Praxis-Projekte reicht 3NF völlig aus.
Faustregel: Wenn ein Schema bis zur 3NF normalisiert ist, ist es im realen Leben „gut genug". Höhere Normalformen kosten weiteren Aufwand für minimale Vorteile und werden oft sogar bewusst ignoriert. Und manchmal geht man sogar zurück in Richtung Redundanz – das ist Thema der nächsten Lektion Denormalisierung.
Zusammenfassung
Die 2. Normalform (2NF) verlangt, dass in Tabellen mit zusammengesetztem Primärschlüssel alle Nicht-Schlüssel-Attribute vom gesamten Schlüssel abhängen – nicht nur von einem Teil. Eine partielle Abhängigkeit liegt vor, wenn ein Attribut nur einen Teil des Schlüssels braucht; die Lösung ist, dieses Attribut in eine eigene Tabelle auszulagern. Die 3. Normalform (3NF) verbietet transitive Abhängigkeiten: Nicht-Schlüssel-Attribute dürfen nicht von anderen Nicht-Schlüssel-Attributen abhängen (klassisches Beispiel: plz → stadt in einer Kunden-Tabelle). Lösung: die abhängige Information in eine eigene Tabelle. Funktionale Abhängigkeit (A → B) ist das zentrale Werkzeug zum Erkennen. Nicht-normalisierte Tabellen leiden unter drei Anomalien: Insert (Daten lassen sich nicht einfügen), Update (Änderungen an vielen Stellen), Delete (Löschen vernichtet zu viel). 3NF löst all das. Höhere Normalformen wie BCNF, 4NF, 5NF sind für IHK und Praxis kaum relevant. Merksatz: „Vom Schlüssel, vom ganzen Schlüssel, und nichts als dem Schlüssel."
Verwandte Lektionen: 1. Normalform · Denormalisierung · ER-Modell zu Schema · und mehrWeitere relevante LektionenWas ist eine Datenbank?Entity-Relationship-ModellPrimary & Foreign KeyReferenzielle IntegritätJOINsCREATE TABLEDatenbankindizes