Normalisierung und Datenorganisation
Stell dir vor, du entwirfst eine Datenbank für einen Online-Shop.
In einer ersten Version legst du einfach alle Informationen in eine große Tabelle:
| Kundennr | Kundenname | Stadt | Produkt | Preis |
|---|---|---|---|---|
| 1001 | Anna Beispiel | Berlin | T-Shirt | 19,99 € |
| 1001 | Anna Beispiel | Berlin | Hoodie | 39,99 € |
| 1002 | Max Mustermann | Hamburg | T-Shirt | 19,99 € |
Das funktioniert — aber nur am Anfang.
Wenn Anna umzieht, müsstest du den Ort „Berlin“ in mehreren Zeilen ändern.
Vergisst du eine, entsteht ein Datenfehler.
Oder: Wenn du ein Produkt löscht, verlierst du vielleicht versehentlich auch Kundendaten.
Diese Probleme heißen Anomalien:
Einfüge-Anomalie: Du kannst keinen Kunden speichern, wenn er noch nichts bestellt hat.
Änderungs-Anomalie: Eine Änderung muss an mehreren Stellen erfolgen.
Lösch-Anomalie: Beim Löschen eines Produkts verschwindet evtl. auch der Kunde.
Genau hier hilft die Normalisierung.
1. Was bedeutet Normalisierung?
Normalisierung ist der Prozess, eine Datenbank in logisch saubere, kleine Tabellen zu zerlegen,
damit jede Information nur einmal gespeichert wird.
Ziel ist es, Redundanzen zu vermeiden und logische Zusammenhänge über Schlüssel herzustellen.
Merksatz:
„Jedes Datum gehört genau an eine Stelle – und wird dort eindeutig gepflegt.“
2. Warum das wichtig ist
Wenn du Daten normalisierst, erreichst du:
Keine doppelten Daten mehr
Einfachere Pflege (z. B. Stadtname nur einmal ändern)
Weniger Fehlerquellen
Mehr Konsistenz und Datenintegrität
Natürlich wird dadurch das System komplexer (mehr Tabellen, mehr Joins) –
aber in der Praxis ist das die Grundlage für jede stabile Datenbank.
3. Die drei wichtigsten Normalformen (einfach erklärt)
Erste Normalform (1NF):
Jede Zelle enthält nur einen Wert, und jede Zeile ist eindeutig.
Schlecht:
| Kundennr | Name | Produkte |
|---|---|---|
| 1001 | Anna Beispiel | T-Shirt, Hoodie |
→ Mehrere Produkte in einer Zelle = nicht atomar.
Korrekt (1NF):
| Kundennr | Name | Produkt |
|---|---|---|
| 1001 | Anna Beispiel | T-Shirt |
| 1001 | Anna Beispiel | Hoodie |
→ Jede Zelle enthält genau einen Wert.
Aber: Kundendaten sind jetzt doppelt – das sehen wir in der nächsten Stufe.
Zweite Normalform (2NF):
Die Tabelle ist in 1NF, und jedes Attribut hängt vom gesamten Primärschlüssel ab.
Das klingt theoretisch – also Beispiel:
| Kundennr | Produktnr | Kundenname |
|---|---|---|
| 1001 | P01 | Anna Beispiel |
| 1001 | P02 | Anna Beispiel |
Hier ist der zusammengesetzte Primärschlüssel (Kundennr, Produktnr).
Aber „Kundenname“ hängt nur von „Kundennr“ ab, nicht vom Produkt.
→ Verstoß gegen 2NF.
Lösung: Aufteilen in mehrere Tabellen:
Kunden
| Kundennr | Name |
|---|---|
| 1001 | Anna Beispiel |
Produkte
| Produktnr | Name |
|---|---|
| P01 | T-Shirt |
| P02 | Hoodie |
Bestellungen
| Kundennr | Produktnr |
|---|---|
| 1001 | P01 |
| 1001 | P02 |
Jetzt hängt jedes Attribut genau von seinem Schlüssel ab → 2NF erfüllt.
Dritte Normalform (3NF):
Die Tabelle ist in 2NF, und kein Nicht-Schlüssel-Attribut hängt von einem anderen Nicht-Schlüssel-Attribut ab.
Beispiel:
| Kundennr | Name | PLZ | Stadt |
|---|---|---|---|
| 1001 | Anna Beispiel | 10115 | Berlin |
→ Die Stadt hängt nicht direkt von der Kundennr ab,
sondern von der PLZ – also ein „Umweg“.
Das führt zu doppelten Städten und Inkonsistenzen.
Lösung: Orte auslagern.
Kunden
| Kundennr | Name | PLZ |
|---|---|---|
| 1001 | Anna Beispiel | 10115 |
Orte
| PLZ | Stadt |
|---|---|
| 10115 | Berlin |
| 20095 | Hamburg |
Damit gilt:
Kunden hängen von PLZ ab.
PLZ bestimmt Stadt.
→ Keine Abhängigkeiten mehr zwischen Nicht-Schlüsseln → 3NF erreicht.
4. Vergleich der drei Normalformen
| Normalform | Bedingung | Ziel | Beispiel |
|---|---|---|---|
| 1NF | Nur atomare Werte | Grundstruktur | Keine Listen in Zellen |
| 2NF | Abhängigkeit vom gesamten Primärschlüssel | Redundanzen vermeiden | Kundendaten auslagern |
| 3NF | Keine Abhängigkeit zwischen Nicht-Schlüsseln | Datenlogik sichern | PLZ → Stadt auslagern |
5. Beispielhafte SQL-Struktur
CREATE TABLE kunden (
kundennr INT PRIMARY KEY,
name VARCHAR(50),
plz CHAR(5)
);
CREATE TABLE orte (
plz CHAR(5) PRIMARY KEY,
stadt VARCHAR(50)
);
CREATE TABLE bestellungen (
bestellnr INT PRIMARY KEY,
kundennr INT,
produktnr VARCHAR(10),
FOREIGN KEY (kundennr) REFERENCES kunden(kundennr)
);
Jetzt gilt:
Ein Kunde kann viele Bestellungen haben (1:n)
Jede Bestellung gehört zu einem Kunden
Städte werden nur einmal gespeichert
Normalisierung Schritt für Schritt
Sieh dir an, wie sich eine unstrukturierte Tabelle durch die Normalisierung verändert. Wähle eine Stufe aus, um zu sehen, wie Redundanzen entfernt und logische Beziehungen hergestellt werden.
Unnormalisierte Tabelle
| Kundennr | Name | Stadt | Produkte | Preis |
|---|---|---|---|---|
| 1001 | Anna Beispiel | Berlin | T-Shirt, Hoodie | 19,99 € / 39,99 € |
| 1002 | Max Mustermann | Hamburg | T-Shirt | 19,99 € |
Mehrere Produkte in einer Zelle – Daten nicht atomar. Änderungen an Kunden müssen mehrfach durchgeführt werden.
6. Zusammenfassung
Warum normalisieren wir?
Damit die Datenbank:
stabil, logisch und fehlerfrei bleibt,
Änderungen konsistent bleiben,
und Redundanz minimiert wird.
Kurz gesagt:
Normalisierung bringt Ordnung ins Datenchaos – sie macht eine Datenbank logisch und zuverlässig.