Datenbanknormalisierung — 1NF, 2NF, 3NF in einem Satz

Datenbanknormalisierung lässt sich in einem Satz zusammenfassen: „Speichere dieselbe Tatsache nur an genau einer Stelle.“ Der systematische Weg dorthin ist 1NF → 2NF → 3NF.

Warum das wichtig ist: Wenn dieselbe Information über mehrere Zeilen verstreut ist, reicht schon eine einzige Änderung an nur einer Stelle, damit der Rest inkonsistent bleibt. Das nennt man eine Änderungsanomalie. Probiere es unten selbst aus.

Das Labor von Prof.A hat sich geändert, aber in einer nicht normalisierten Tabelle müssen beide Zeilen manuell angepasst werden. Wenn auch nur eine vergessen wird, entsteht der Widerspruch: „Prof.A ist in Room 301 und gleichzeitig in Room 502.“ In einer 3NF-Tabelle reicht genau eine Zeile — fertig.

Das ist im Grunde schon die ganze Normalisierung — alles Weitere sind nur Regeln, mit denen man entscheidet, welche Spalte wohin gehört, damit eine Tatsache nur einmal gespeichert wird.

Funktionale Abhängigkeit — das Kriterium für Normalisierung

Bei der Normalisierung fragt man: „Wovon hängt diese Spalte ab?“ Das nennt man funktionale Abhängigkeit.

Zum Beispiel bedeutet student_id → student_name: „Wenn man die student_id kennt, ist der Name eindeutig bestimmt.“

Achte im Diagramm unten auf die Farben der Pfeile:

• Grün = hängt vom gesamten Schlüssel ab (in Ordnung)
• Gelb = hängt nur von einem Teil des Schlüssels ab (partielle Abhängigkeit → Verstoß gegen 2NF)
• Rot gestrichelt = hängt über ein Nichtschlüsselattribut ab (transitive Abhängigkeit → Verstoß gegen 3NF)

Die gelben und roten Pfeile zu entfernen = die Tabelle aufzuteilen = zu normalisieren.

1NF → 2NF → 3NF auf einen Blick

Klicke dich unten durch die einzelnen Schritte und sieh direkt, wie die Tabelle aufgeteilt wird. Rote Zellen markieren: „Diese Spalte sollte hier nicht stehen.“

1NF: Ein Wert pro Zelle

Wenn in einer Zelle mehrere Werte wie MATH101, CS102 stehen, kann man weder sauber suchen noch sinnvoll JOINs ausführen.

Regel: Jede Zelle muss atomar sein, also genau einen Wert enthalten.

Spalten wie phone1, phone2, phone3 haben im Grunde dasselbe Problem — die Werte wurden nur im Spaltennamen versteckt.

2NF: Partielle Abhängigkeiten entfernen

In einer Tabelle mit dem zusammengesetzten Schlüssel (student_id, course_id) hängt student_name nur von student_id ab. Also nicht vom gesamten Schlüssel, sondern nur von einem Teil davon — das ist eine partielle funktionale Abhängigkeit.

Regel: Alle Nichtschlüsselattribute müssen vom gesamten Schlüssel abhängen.

Wenn es eine partielle Abhängigkeit gibt, nimmt man die betreffende Spalte heraus und macht daraus eine eigene Tabelle.

Wenn der Schlüssel nur aus einer einzigen Spalte besteht? Dann sind partielle Abhängigkeiten gar nicht möglich — 1NF bedeutet dann automatisch auch 2NF.

3NF: Transitive Abhängigkeiten entfernen

In der Tabelle Courses hängt instructor_office nicht direkt von course_id (dem Schlüssel) ab. Es gibt den Pfad course_id → instructor_id → instructor_office — also hängt ein Nichtschlüsselattribut von einem anderen Nichtschlüsselattribut ab. Das ist eine transitive Abhängigkeit.

Regel: Nichtschlüsselattribute dürfen nur über den Schlüssel abhängen. Sie dürfen nicht über andere Nichtschlüsselattribute laufen.

Lösung: instructor_office in eine eigene Tabelle Instructors auslagern.

Statt Auswendiglernen: eine einzige Frage

„Alle Nichtschlüsselattribute müssen dem Schlüssel, dem ganzen Schlüssel und nichts als dem Schlüssel folgen.“

Dieser eine Satz ist alles:

• dem Schlüssel = 1NF (eine Tatsache muss über einen Schlüssel identifizierbar sein)
• dem ganzen Schlüssel = 2NF (Abhängigkeit vom ganzen Schlüssel, nicht nur von einem Teil)
• und nichts als dem Schlüssel = 3NF (direkte Abhängigkeit vom Schlüssel, nicht über Nichtschlüsselattribute)

Wenn in einer Prüfung eine Aufgabe zur Normalisierung kommt, stell dir einfach diese Frage: „Wovon hängt diese Spalte ab? Vom ganzen Schlüssel, von einem Teil des Schlüssels oder von einem Nichtschlüsselattribut?“

Häufige Fehler

„Bei 3NF ist man fertig.“ — 3NF ist ein guter Startpunkt, aber nicht immer das Ende. Manchmal braucht man das strengere BCNF, und manchmal denormalisiert man bewusst aus Performance-Gründen.

„Je mehr Tabellen, desto besser.“ — Das Ziel der Normalisierung ist nicht, möglichst viele Tabellen zu erzeugen, sondern dafür zu sorgen, dass jede Tabelle genau eine Art von Tatsache verantwortet. Wenn man ohne echten Grund (also ohne Abhängigkeitsproblem) aufteilt, werden nur die JOINs unnötig kompliziert.

„Bei NoSQL braucht man keine Normalisierung.“ — Normalisierung ist zwar ein Begriff aus relationalen DBs, aber das Problem „Wie halte ich redundante Daten konsistent?“ gibt es in jeder Art von Datenbank. Auch beim Denormalisieren sollte man genau wissen, worauf man verzichtet.

Selbst überprüfen

Nimm eine Tabelle aus deinem eigenen Projekt und geh so vor:

1. Schreib auf, was der Schlüssel ist.
2. Prüfe für jedes Nichtschlüsselattribut, ob es vom ganzen Schlüssel oder nur von einem Teil abhängt. → Wenn nur von einem Teil, ist das ein Verstoß gegen 2NF.
3. Prüfe, ob ein Nichtschlüsselattribut von einem anderen Nichtschlüsselattribut abhängt. → Wenn ja, ist das ein Verstoß gegen 3NF.

Mit diesen drei Schritten findest du die meisten Normalisierungsprobleme.