Von der 2. zur 3. Normalform – was genau ist eine transitive Abhängigkeit?

Dein Beispiel ist perfekt, das ist praktisch der Schulbuchfall.

Transitiv heißt: über eine Zwischenstation. Formal liegt eine transitive Abhängigkeit vor, wenn der Schlüssel A ein Attribut B bestimmt und dieses B wiederum ein weiteres Nichtschlüsselattribut C bestimmt – ohne dass C direkt vom Schlüssel abhängt.

In deiner Tabelle:

• BestellNr → KundenNr (jede Bestellung gehört zu einem Kunden)
• KundenNr → KundenName, KundenOrt (die Kundennummer bestimmt Name und Ort)
• also: BestellNr → KundenNr → KundenName

KundenName hängt eben nicht von der Bestellnummer ab, sondern nur vom Kunden. Er ist über die KundenNr durchgereicht – das ist die Transitivität.

Und jetzt zu deiner eigentlichen Frage, warum das ein Problem ist. Die Daten sind richtig, solange nichts passiert. Sobald sich etwas ändert, entstehen die drei klassischen Anomalien:

• Änderungsanomalie: Zieht der Kunde um, musst du den Ort in allen seinen Bestellzeilen ändern. Wird eine vergessen, hat derselbe Kunde zwei Wohnorte – und die Datenbank kann dir nicht sagen, welcher stimmt.
• Einfügeanomalie: Du kannst einen neuen Kunden nicht erfassen, solange er nichts bestellt hat. Es gibt keinen Platz für ihn.
• Löschanomalie: Löschst du die letzte Bestellung eines Kunden, verschwinden auch seine Stammdaten.

Die Lösung ist immer dieselbe: Das transitiv abhängige Bündel wandert in eine eigene Tabelle, und in der Ursprungstabelle bleibt nur der Fremdschlüssel stehen. Also Kunde(KundenNr, KundenName, KundenOrt) und Bestellung(BestellNr, Datum, KundenNr).

Zum Erkennen im Prüfungsstress hilft ein Merksatz, der die ersten drei Normalformen in einem Satz zusammenfasst:

„Der Schlüssel, der ganze Schlüssel und nichts als der Schlüssel.“

• 1. NF – alle Attributwerte sind atomar, keine Mehrfachwerte in einer Zelle: der Schlüssel.
• 2. NF – jedes Nichtschlüsselattribut hängt vom ganzen zusammengesetzten Schlüssel ab, nicht nur von einem Teil davon (das war die partielle Abhängigkeit).
• 3. NF – jedes Nichtschlüsselattribut hängt nur vom Schlüssel ab und von nichts anderem: nichts als der Schlüssel.

Praktische Erkennungsregel: Geh die Spalten durch und frag bei jeder „Kann ich diesen Wert aus einer anderen Nichtschlüsselspalte ableiten?“ Wenn ja, ist es transitiv. Zwei Klassiker, die dir immer wieder begegnen:

• PLZ → Ort in einer Adresstabelle
• ArtikelNr → Artikelbezeichnung → MwSt-Satz in einer Positionstabelle

Nebenbei: Die 2. NF ist nur dann überhaupt eine Hürde, wenn der Primärschlüssel zusammengesetzt ist. Bei einem einspaltigen Schlüssel kann es keine partielle Abhängigkeit geben – dann geht es direkt um die 3. NF, und deshalb ist sie in der Praxis die wichtigste der drei.

Zwei Ergänzungen für die Vollständigkeit: Über der 3. NF steht noch die Boyce-Codd-Normalform, die zusätzlich Abhängigkeiten zwischen Schlüsselkandidaten ausschließt – die brauchst du selten, sie taucht aber gern als Zusatzfrage auf. Und in der Praxis wird bewusst wieder denormalisiert, etwa in Data Warehouses, wo Lesegeschwindigkeit wichtiger ist als Redundanzfreiheit. Das ist kein Widerspruch zur Theorie: Man normalisiert erst sauber und weicht dann begründet ab.