Eine Tabelle ist in der zweiten Normalform, wenn:
- Sie sich bereits in der ersten Normalform (1NF) befindet.
- Jede Nicht-Schlüssel-Spalte vom gesamten Primärschlüssel abhängt und nicht nur von einem Teil davon.
Wenn der Primärschlüssel aus mehreren Feldern besteht (also ein zusammengesetzter Schlüssel ist), darf kein Nicht-Schlüssel-Attribut (Spalte) nur von einem Teil dieses Schlüssels abhängen. Anders gesagt: 2NF beseitigt partielle Abhängigkeiten.
Beispiel für einen 2NF-Verstoß
Stell dir vor, wir haben eine Tabelle student_courses (Studenten und Kurse), die Infos über Studenten, ihre Kurse und die Dozenten speichert:
| student_id | course_id | course_name | instructor_name |
|---|---|---|---|
| 1 | 101 | Mathematik | Lin |
| 1 | 102 | Literatur | Song |
| 2 | 101 | Mathematik | Lin |
student_idundcourse_idzusammen bilden den zusammengesetzten Primärschlüssel.- Achte aber mal auf die Spalten
course_nameundinstructor_name. Die hängen nur voncourse_idab, nicht vom ganzen Paar (student_id,course_id).
Da ist sie, die partielle Abhängigkeit! course_name und instructor_name hängen nur von einem Teil des zusammengesetzten Schlüssels (course_id) ab. Das ist ein Verstoß gegen die 2NF-Regeln.
Wie bringe ich die Tabelle in 2NF?
Unsere Aufgabe: Die partielle Abhängigkeit loswerden, indem wir die Tabelle aufteilen. So vermeiden wir Redundanz und verbessern die Datenkonsistenz.
Wir packen die Kursinfos in eine eigene Tabelle courses:
| course_id | course_name | instructor_name |
|---|---|---|
| 101 | Mathematik | Lin |
| 102 | Literatur | Song |
Die Haupttabelle sieht dann so aus:
| student_id | course_id |
|---|---|
| 1 | 101 |
| 1 | 102 |
| 2 | 101 |
Jetzt hängt jede Spalte vom gesamten Primärschlüssel ab. Wir haben die Daten logisch getrennt und das 2NF-Problem gelöst.
Die Magie der Redundanzbeseitigung
Schau dir die Tabelle vor der Normalisierung an. In der Spalte instructor_name taucht der Name "Lin" mehrfach auf. Und wie oft würde das wohl in einer echten Datenbank mit tausenden Einträgen passieren? Durch das Aufteilen der Tabellen haben wir Redundanz entfernt und die Fehlerwahrscheinlichkeit gesenkt, zum Beispiel Tippfehler ("Lin" vs "Ling").
Beispiel aus dem echten Leben
Stell dir vor, du verwaltest Bestellungen für Produkte. Du hast eine Tabelle order_items (Bestellungen und Produkte), wo order_id und item_id zusammen den Primärschlüssel bilden:
| order_id | item_id | item_name | price |
|---|---|---|---|
| 1 | 101 | Laptop | 50000 |
| 1 | 102 | Maus | 1000 |
| 2 | 101 | Laptop | 50000 |
Wie du siehst, wiederholen sich Preise und Produktnamen. Das ist ein Zeichen für einen 2NF-Verstoß, weil item_name und price nur von item_id abhängen.
Um die Tabelle in 2NF zu bringen, erstellen wir eine items-Tabelle:
| item_id | item_name | price |
|---|---|---|
| 101 | Laptop | 50000 |
| 102 | Maus | 1000 |
Und wir ändern die order_items-Tabelle, sodass nur noch Bestell- und Produkt-IDs drinstehen:
| order_id | item_id |
|---|---|
| 1 | 101 |
| 1 | 102 |
| 2 | 101 |
Jetzt sind die Daten so sauber wie Code nach dem Review – keine Redundanz mehr.
Praxisaufgabe: Probier’s selbst!
Angenommen, du hast eine Tabelle employee_projects, die Infos über Mitarbeitende, ihre Projekte und die Projektmanager enthält:
| employee_id | project_id | project_name | manager_name |
|---|---|---|---|
| 1 | 201 | CRM Upgrade | Lin |
| 2 | 202 | Website Revamp | Ming |
| 1 | 202 | Website Revamp | Ming |
Versuch mal:
- Finde die Abhängigkeiten, die gegen die 2NF-Regeln verstoßen.
- Teile die Tabelle so auf, dass der Verstoß behoben ist.
Warum ist 2NF überhaupt wichtig?
Warum sollte man sich überhaupt an die zweite Normalform (2NF) halten? Ganz einfach: Damit Daten nicht doppelt vorkommen und kein Chaos entsteht. Wenn du partielle Abhängigkeiten entfernst, werden die Tabellen sauberer – ohne wiederholte Infos wie denselben Dozentennamen in jeder Zeile. Das spart Speicherplatz und verhindert Inkonsistenzen: Änderst du einen Namen an einer Stelle, ist überall alles aktuell.
Außerdem sind Abfragen auf so einer Datenbank einfacher: Wenn die Struktur logisch ist und die Daten nicht über zig Zeilen verteilt sind, funktionieren Filter und Gruppierungen schneller und zuverlässiger. Klar, du musst ein bisschen mehr mit SQL-JOINs arbeiten, weil es mehr Tabellen gibt. Aber lieber ein JOIN als hundert Zeilen mit denselben Nachnamen. In den meisten Fällen lohnt sich die Normalisierung echt.
Integration in echte Projekte
Das Wissen über 2NF hilft dir:
- Beim Datenbank-Design: Damit du kein Tabellen-Chaos bekommst.
- Im Vorstellungsgespräch: Oft wird gefragt, wie man Tabellen normalisiert oder in Normalformen bringt.
- Im echten Job: Wenn du mal eine bestehende Datenbank optimieren sollst und die "monolithischen" Tabellen in normalisierte aufteilst.
Die zweite Normalform (2NF) hilft dir, partielle Abhängigkeiten in Tabellen mit zusammengesetzten Schlüsseln zu beseitigen. Wir teilen Tabellen in logische Blöcke, sodass jede Spalte nur vom gesamten Schlüssel abhängt, nicht von einem Teil davon. Das verbessert die Datenqualität, entfernt Redundanz und macht die Datenbank flexibler. Bereit für die dritte Normalform? Dann geht’s weiter!
GO TO FULL VERSION