Die Normalisierung ist ein Verfahren zur Strukturierung von Datenbanken. Ziel ist es, Redundanzen zu vermeiden und Datenbankanomalien (Einfüge-, Änderungs- und Löschanomalien) zu verhindern.
Eine Tabelle befindet sich in der ersten Normalform, wenn:
Nicht 1NF:
Kunde | Telefonnummern ---------------------- Müller | 1234, 5678
1NF:
Kunde | Telefonnummer --------------------- Müller | 1234 Müller | 5678
Eine Tabelle befindet sich in der zweiten Normalform, wenn:
Teilabhängigkeiten dürfen nicht vorhanden sein.
Beispiel:
Bestellung ------------------------------------------ BestellNr | ArtikelNr | ArtikelName ------------------------------------------ 1001 | A10 | Monitor
Der Artikelname hängt nur von der Artikelnummer ab und nicht vom gesamten zusammengesetzten Schlüssel.
Lösung: Artikel in eine eigene Tabelle auslagern.
Eine Tabelle befindet sich in der dritten Normalform, wenn:
Das bedeutet: Nichtschlüsselattribute dürfen nicht voneinander abhängen.
Beispiel:
Mitarbeiter -------------------------------------- PersonalNr | Abteilung | Abteilungsort -------------------------------------- 100 | IT | Berlin
Der Abteilungsort hängt von der Abteilung ab, nicht von der Personalnummer. Deshalb sollte eine separate Tabelle für Abteilungen erstellt werden.
| Normalform | Bedingung | Ziel |
|---|---|---|
| 1. Normalform | Atomare Werte, keine Mehrfachwerte | Strukturierte Datenspeicherung |
| 2. Normalform | Keine Teilabhängigkeiten | Redundanzen reduzieren |
| 3. Normalform | Keine transitiven Abhängigkeiten | Datenkonsistenz verbessern |
Das Kernproblem der 2NF
Die 2NF ist nur relevant, wenn der Primärschlüssel aus mehreren Spalten besteht (zusammengesetzter Schlüssel).
Bei einem einfachen Schlüssel (eine Spalte) bist du automatisch in 2NF.
Die Frage lautet: Hängt jedes Attribut vom gesamten Schlüssel ab — oder reicht schon ein Teil des Schlüssels?
---------------------
## Konkret am Beispiel
Unsere 1NF-Tabelle hatte den Primärschlüssel **(BestellID + Artikel)** — zwei Spalten zusammen.
| **BestellID** | **Artikel** | Kunde | Kategorie | Stadt |
|-------------------|---------------|-----------|---------------|-------|
| 1 | Laptop | Anna | IT | Berlin |
| 1 | Maus | Anna | IT | Berlin |
| 2 | Monitor | Bob | IT | Hamburg |
`Kunde` und `Stadt` hängen nur von der `BestellID` ab — den `Artikel` brauchen sie gar nicht. Das ist eine **partielle Abhängigkeit** — und die verletzt die 2NF.
---
## Warum ist das ein Problem?
Weil `Anna` und `Berlin` jetzt in jeder Zeile wiederholt werden, in der BestellID = 1 vorkommt. Hat Anna 10 Artikel bestellt, steht ihr Name 10 Mal drin. Ändert sich ihr Name — muss man 10 Zeilen anfassen.
---
## Die Lösung: aufteilen
| BestellID | Artikel | Kategorie |
|-----------|---------|-----------|
| 1 | Laptop | IT |
| 1 | Maus | IT |
**Bestellungen** — enthält nur Dinge, die von BestellID allein abhängen:
| BestellID | Kunde | Stadt |
|-----------|-------|-------|
| 1 | Anna | Berlin |
| 2 | Bob | Hamburg |
Jetzt steht `Anna` nur noch einmal. Problem gelöst.
---
## Merksatz
> Jedes Nicht-Schlüssel-Attribut muss vom **ganzen** Schlüssel abhängen — nicht nur von einem Teil.
3. Normalform: Die Tabelle befindet sich in der 2. Normalform
und es existieren keine transitiven Abhängigkeiten zwischen Nichtschlüsselattributen.
## 3NF — nochmal in Ruhe
### Das Kernproblem
In der 3NF geht es um **transitive Abhängigkeiten**. Das klingt kompliziert, ist aber simpel:
> Attribut A bestimmt Attribut B, und B bestimmt Attribut C — also hängt C *indirekt* von A ab. Das ist verboten.
---
### Am Beispiel
Nach der 2NF haben wir diese Tabelle:
| **BestellID** | Kunde | Stadt |
|---------------|-------|-------|
| 1 | Anna | Berlin |
| 2 | Bob | Hamburg |
Jetzt die Frage: Wovon hängt `Stadt` ab?
```
BestellID → Kunde → Stadt
```
`Stadt` hängt von `Kunde` ab — nicht direkt von `BestellID`.
Das ist die transitive Abhängigkeit. `Kunde` ist kein Schlüssel, aber bestimmt trotzdem `Stadt`.
---
### Warum ist das ein Problem?
Stell dir vor, Anna zieht von Berlin nach München.
In dieser Tabelle muss man **jede Zeile ändern**, in der Anna vorkommt. Bei 100 Bestellungen = 100 Änderungen. Und vergisst man eine — hat man inkonsistente Daten.
---
### Die Lösung: auch das aufteilen
**Bestellungen** — nur der direkte Zusammenhang:
| BestellID | KundenID |
|-----------|----------|
| 1 | K1 |
| 2 | K2 |
**Kunden** — Kunde und Stadt zusammen, wo sie hingehören:
| KundenID | Kunde | Stadt |
|----------|-------|-------|
| K1 | Anna | Berlin |
| K2 | Bob | Hamburg |
Zieht Anna um → eine einzige Änderung in der Kunden-Tabelle. Fertig.
---
### 2NF vs. 3NF — der Unterschied auf einen Blick
| | Abhängigkeit | Beispiel |
|----------------|----------------------------------------------------------------|---------------------------------------------------------|
| 2NF-Problem | Attribut hängt von *Teil* des Schlüssels ab | `Stadt` hängt nur von `BestellID`, nicht von `BestellID + Artikel` |
| 3NF-Problem | Attribut hängt von einem *Nicht-Schlüssel-Attribut* ab | `Stadt` hängt von `Kunde` — der ist kein Schlüssel |
---
### Merksatz
> Jedes Attribut muss direkt vom Schlüssel abhängen — **nicht über Umwege**.
Wenn man sagen kann: „Der Wert hängt eigentlich von *dieser anderen normalen Spalte* ab" — dann raus damit in eine eigene Tabelle.
Passt das? Oder soll ich ein frisches Beispiel zum Üben aufmachen?