CodeGym /Kurse /SQL SELF /Prinzipien der zweiten Normalform (2NF)

Prinzipien der zweiten Normalform (2NF)

SQL SELF
Level 25 , Lektion 2
Verfügbar

Eine Tabelle ist in der zweiten Normalform, wenn:

  1. Sie sich bereits in der ersten Normalform (1NF) befindet.
  2. 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_id und course_id zusammen bilden den zusammengesetzten Primärschlüssel.
  • Achte aber mal auf die Spalten course_name und instructor_name. Die hängen nur von course_id ab, 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:

  1. Finde die Abhängigkeiten, die gegen die 2NF-Regeln verstoßen.
  2. 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!

2
Aufgabe
SQL SELF, Level 25, Lektion 2
Gesperrt
Umwandlung einer Tabelle in die 2NF
Umwandlung einer Tabelle in die 2NF
Kommentare
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION