Prinzipien der dritten Normalform (3NF)

Die dritte Normalform (3NF) ist ein weiterer Schritt zu noch mehr Ordnung in unseren Daten. Kurz gesagt, eine Tabelle ist in 3NF, wenn:

1. Sie schon in der zweiten Normalform (2NF) ist.
2. Alle Nicht-Schlüssel-Attribute nur vom Primärschlüssel abhängen und von sonst nichts (keine transitiven Abhängigkeiten!).

Anders gesagt: 3NF verlangt, dass alle Daten in der Tabelle direkt mit dem Primärschlüssel verknüpft sind und nicht von anderen Nicht-Schlüssel-Attributen abhängen.

Eine transitive Abhängigkeit entsteht, wenn Attribut A von Attribut B abhängt und Attribut B von Attribut C abhängt – das ergibt eine Kette von Abhängigkeiten A → B → C. Zum Beispiel: „Mitarbeiter“ hängt vom „Abteilung“ ab, und „Abteilung“ hängt vom „Standort“ ab. Das heißt, „Mitarbeiter“ hängt transitiv vom „Standort“ ab.

Beispiel für einen 3NF-Verstoß

Nehmen wir an, wir haben eine Tabelle employees, die Infos über Mitarbeiter speichert:

Hier gilt:

• employee_id – Primärschlüssel.
• department und department_manager – Nicht-Schlüssel-Attribute.

Auf den ersten Blick sieht alles okay aus, aber wenn wir genauer hinschauen, fällt ein Problem auf: department_manager hängt nicht von employee_id ab, sondern von department. Das ist eine transitive Abhängigkeit: employee_id → department → department_manager.

Probleme, die auftreten können

Wenn wir den Namen des Abteilungsleiters („Finance“) ändern, müssen wir alle Zeilen aktualisieren, in denen diese Abteilung steht. Wenn wir aus Versehen eine Zeile vergessen, werden die Daten inkonsistent. Das ist ein Kopfschmerz, den man sich sparen kann.

Wie bringe ich die Tabelle in die 3NF?

Um die transitiven Abhängigkeiten loszuwerden, teilen wir die Tabelle in zwei auf: Eine speichert die Mitarbeiterdaten, die andere die Abteilungen.

Tabelle employees

Tabelle departments

Jetzt ist alles schön strukturiert und jede Tabelle macht ihren eigenen Job:

1. Die Tabelle employees speichert Infos über Mitarbeiter.
2. Die Tabelle departments speichert Infos über Abteilungen und deren Manager.

Wenn sich der Manager einer Abteilung ändert, müssen wir nur eine Zeile in der Tabelle departments aktualisieren, nicht alle Mitarbeiter-Einträge.

Wie erkenne ich, dass eine Tabelle gegen 3NF verstößt?

Um zu checken, ob eine Tabelle gegen 3NF verstößt, prüfe:

1. Gibt es in der Tabelle transitive Abhängigkeiten? Zum Beispiel: Attribut A hängt von Attribut B ab, das wiederum von Attribut C abhängt.
2. Hängen alle Nicht-Schlüssel-Attribute direkt vom Primärschlüssel ab? Wenn etwas von einem anderen Nicht-Schlüssel-Attribut abhängt, ist die Tabelle nicht in 3NF.

Praktisches Beispiel: Shop

Schauen wir uns die Tabelle sales an, die Verkaufsdaten enthält:

Hier sehen wir ganz klar Redundanz: Die Info über den Produktpreis wiederholt sich bei jedem Verkauf. Wenn sich der Preis ändert, sind die Daten sofort inkonsistent.

Um den 3NF-Verstoß zu beheben, teilen wir die Tabelle in zwei auf:

1. Die Tabelle sales speichert die Verkaufsinfos.
2. Die Tabelle products – Infos über Produkte und deren Preise.

Tabelle sales

Tabelle products

Jetzt, wenn sich der Preis eines Produkts ändert, aktualisieren wir einfach eine Zeile in der Tabelle products und die Daten bleiben konsistent.

Praktische Aufgabe

Hier eine kleine Challenge: Du hast die Tabelle students_courses in folgender Form:

Teile die Tabelle so auf, dass sie der 3NF entspricht. Tipp: Du brauchst drei Tabellen (students, courses, teachers) und musst sie richtig verknüpfen.

Warum ist es wichtig, die 3NF einzuhalten?

Warum sollte man sich überhaupt mit der dritten Normalform (3NF) beschäftigen? Weil sie das Leben echt leichter macht. Wenn Tabellen in 3NF sind, sind die Daten viel sauberer – kein unnötiges Duplizieren, also weniger Risiko, dass man versehentlich was kaputt macht. Updates laufen schneller und einfacher, weil alles an einem Ort gespeichert ist und nicht überall reinkopiert wird.

Außerdem wird die Struktur der Datenbank flexibler. Willst du ein neues Feld hinzufügen oder ein altes ändern – musst du nicht gleich das ganze System umbauen.

Aber wie bei jeder guten Story gibt’s einen Haken: Zu viel Normalisierung kann in viele kleine Tabellen und komplexe Queries mit vielen JOINs ausarten. Das kann manchmal echt langsam werden. Also: Maß halten! Wo’s Sinn macht, normalisieren – und wo ein bisschen Redundanz einfacher ist, keine Angst davor.

Als Nächstes gehen wir noch tiefer: Wir lernen, wie man Beziehungen zwischen Tabellen richtig aufbaut und Datenbanken erstellt, die sowohl praktisch als auch zuverlässig sind. Los geht’s zum perfekten Datenbank-Design!