hwr-notes/Datenbanken/Zusammenfassungen/e_NFs - zusammenfassung.md

# Normalisierung – Zusammenfassung
**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–41**

---

## 1. Einführung (Folien 1–6)

### Was ist Normalisierung?

Die relationale Darstellung einer entworfenen Datenbank kann noch **verfeinert** werden. Die Basis dafür bilden die **Normalformen** der Tabellen.

**Normalisierung** = Aufteilung von Attributen in mehrere Relationen (Tabellen) mithilfe der Normalisierungsregeln, sodass eine Struktur entsteht, die **keine vermeidbaren Redundanzen** mehr enthält.

### Ziele der Normalisierung

| Ziel | Beschreibung |
|---|---|
| **Redundanzbeseitigung** | Nur notwendige Redundanz bleibt erhalten |
| **Anomalienvermeidung** | Funktionelle und transitive Abhängigkeiten werden aufgelöst |
| **Klare Struktur** | Erstellung eines klar strukturierten Datenbankmodells |

### Praktische Bedeutung

- Praktisch wichtig sind nur die **ersten drei Normalformen** (1NF, 2NF, 3NF)
- Manchmal ist es sinnvoll, auf Normalformen aus **Performancegründen** zu verzichten (z. B. lange Laufzeiten, große Anzahl der Tabellen)
- Jede nächste Normalform **basiert auf der vorigen**

### Funktionale Abhängigkeit (Folie 4)

**Definition:** Man betrachtet eine Relation, X und Y sind Mengen der Attribute. Y ist von X **funktional abhängig** (X → Y), wenn für alle Tupel t1 und t2 gilt:

```
Wenn t1 ∩ X = t2 ∩ X, dann gilt auch t1 ∩ Y = t2 ∩ Y
```

- Y hängt von X ab, wenn X die Werte von Y **eindeutig bestimmt**
- X bestimmt alle anderen Attribute → X ist ein **Superschlüssel**
- Ist X auch **minimal**, dann ist X ein **Kandidat für Primärschlüssel**

### Arten der Abhängigkeit (Folie 5)

| Art | Notation | Beschreibung |
|---|---|---|
| **Funktionale Abhängigkeit** | X → Y | X bestimmt Y eindeutig |
| **Mehrwertige Abhängigkeit** (multivalued) | X →→ Y | X bestimmt eine Menge von Y-Werten |

### Überblick Normalformen (Folie 6)

Die Normalformen bilden eine **aufsteigende Kette**: 1NF → 2NF → 3NF → BCNF → 4NF → 5NF

---

## 2. Erste Normalform – 1NF (Folien 7–16)

### Definition (Folie 8)

Eine Tabelle liegt in **1NF** vor, wenn ihre Zellen nur **atomare Werte** beinhalten, d. h. sie enthalten nicht mehr als einen Wert (keine Auflistungen).

**"Atomar"** bedeutet: Die Werte können nicht weiter in kleinere Komponenten zerlegt werden, die **einzeln einen Sinn** im Anwendungsbereich ergeben.

### Regeln der 1NF

- Wiederholungsgruppen werden vermieden, indem jede Gruppe in eine **separate Tabelle** eingefügt und durch eine **1:N-Beziehung** verbunden wird
- Ob ein Attribut atomar ist, hängt **stark von der Mini-Welt** ab
- Laut E. F. Codd müssen Tabellen in 1NF **nicht unbedingt einen Primärschlüssel** haben – dieser ist erst für weitere Normalformen nötig

### Mini-Welt-Beispiele: Adresse (Folien 9–10)

| Mini-Welt | Kontext | Atomar? |
|---|---|---|
| **Logistik-Firma (Müll-Abfuhr)** | PLZ, Straße, Hausnummer werden einzeln für Routenberechnung benötigt | PLZ, Straße, Hausnummer sind **jeweils atomar** |
| **Buchhaltung (Gehaltsabrechnung)** | Nur die gesamte Adresse wird für Briefversand benötigt | Gesamte Adresse ist **als Ganzes atomar** |

### Beispiel: Bahnwagen (Folien 12–13)

**Ausgangstabelle (nicht in 1NF):**
```
Wagen = { [ WagenID, Beschreibung, Status, Ankunft, Station ] }
PK = [WagenID, Ankunft]
```

**Problem:** Feld "Beschreibung" enthält: `'Wagentyp, Leergewicht, Kapazität, Hersteller, Baujahr'` → **nicht atomar**

**In 1NF gebracht:**
```
W1 = { [ WagenID, Status, Ankunft, Station, WagenType,
         Leergewicht, Kapazitaet, Hersteller, Baujahr ] }
```

### Beispiel: Vertragsdaten (Folien 14–16)

**Ausgangstabelle (nicht in 1NF):**

| Vertragsdatum | Kunde | Produkt |
|---|---|---|
| 01.02.2010 | Kohl | VW 30.000, BMW 40.000, Opel 40.000 |
| 03.01.2012 | Schröder | VW 32.000, Mercedes 35.000 |

**In 1NF gebracht** – Produkt und Preis werden getrennt, jede Kombination ist eine eigene Zeile:

| Vertragsdatum | Kunde | Produkt | Preis |
|---|---|---|---|
| 01.02.2010 | Kohl | VW | 30.000 |
| 01.02.2010 | Kohl | BMW | 40.000 |
| 01.02.2010 | Kohl | Opel | 40.000 |
| 03.01.2012 | Schröder | VW | 32.000 |
| 03.01.2012 | Schröder | Mercedes | 35.000 |

**Erweitertes Beispiel (Folie 15–16):** Tabelle mit Produkt+Herkunftsland und Menge+V.art als nicht-atomare Felder → Zerlegung in 7 separate Spalten (Vertragsdatum, Kunde, Produkt, Herkunftsland, V-Art, Lieferadresse, Menge). In 1NF ist hier **kein PK nötig**.

---

## 3. Zweite Normalform – 2NF (Folien 17–24)

### Definition (Folie 17)

Eine Tabelle liegt in **2NF** vor, wenn sie:
1. In **1NF** vorliegt
2. Jedes Feld, das **nicht** zum Primärschlüssel gehört, vom **ganzen** Primärschlüssel abhängt

**Regel:** Besteht der Primärschlüssel nur aus **einem Feld**, liegt die Tabelle **automatisch in 2NF** vor.

### Vorgang (Folie 18)

Felder, die nur vom **Teil des Primärschlüssels** abhängig sind, werden zusammen mit dem Teilschlüssel in **neue Tabellen ausgelagert**:

```
Vorher:  PK = [S1, S2] → alle Felder
Nachher: Tabelle 1: PK = [S1, S2] → Felder die vom ganzen PK abhängen
         Tabelle 2: PK = [S2]     → Felder die nur von S2 abhängen (DepS2)
```

### Beispiel: Bahnwagen (Folie 19)

Die Felder [WagenType], [Leergewicht], [Kapazitaet], [Hersteller], [Baujahr] hängen nur von **[WagenID]** ab, aber **nicht** von [Ankunft] → **nicht in 2NF**.

**Aufteilung in 2NF:**
```
W11 = { [ WagenID, Ankunft, Status, Station ] }         ← PK = [WagenID, Ankunft]
W12 = { [ WagenID, WagenType, Leergewicht, Kapazitaet,
          Hersteller, Baujahr ] }                         ← PK = [WagenID]
```

### Beispiel: Vertragsdaten (Folien 20–22)

**PK festgelegt:** [Vertragsdatum, Kunde, Produkt]

**Analyse der Abhängigkeiten:**
- [Herkunftsland] hängt nur von [Produkt] ab → **verletzt 2NF**
- [Lieferadresse] hängt nur von [Kunde] ab → **verletzt 2NF**
- [V-Art] hängt nur von [Produkt] ab → **verletzt 2NF**

**Aufteilung:**
```
T-1 = { [ Vertragsdatum, Kunde, Produkt, Herkunftsland, Menge ] }
T-2 = { [ Produkt, Herkunftsland ] }          ← falls V-Art unabhängig
T-3 = { [ Kunde, Lieferadresse ] }
```

Wenn [V-Art] nur von [Produkt] abhängig ist, wird T-2 weiter aufgeteilt:
```
T-3-1 = { [ Produkt, Herkunftsland ] }
T-3-2 = { [ Produkt, V-Art ] }
```

### Beispiel: Bestellungen (Folie 23)

| RNr | ArtNr | LagerOrt | Anzahl |
|---|---|---|---|
| 100100 | 1010 | 22 | 1 |
| 100100 | 1020 | 15 | 2 |
| 100103 | 1040 | 13 | 10 |

Bei ArtNr : LagerOrt = 1:1 gibt es **zwei Schlüsselkandidaten**: [RNr, ArtNr] und [RNr, LagerOrt]. Die **2NF ist in beiden Fällen verletzt**, da [LagerOrt] vom Teilschlüssel [ArtNr] abhängt (bzw. umgekehrt).

**Lösung:**
```
Tabelle 1 = { [ RNr, ArtNr, Anzahl ] }
Tabelle 2 = { [ ArtNr, LagerOrt ] }
```

### ERM-Bezug (Folie 24)

Wenn man vom **ERM ausgeht** und den konzeptuellen Entwurf korrekt in den logischen umwandelt, kommt man direkt zu Tabellen, die die 2NF nicht verletzen – die Normalisierung ist dann nicht nötig.

---

## 4. Dritte Normalform – 3NF (Folien 25–28)

### Definition (Folie 25)

Eine Tabelle liegt in **3NF** vor, wenn sie:
1. In **2NF** vorliegt
2. Alle Felder, die **nicht** zum Primärschlüssel gehören, **voneinander unabhängig** sind

**Regel:** Wenn nur **ein Nichtschlüsselfeld** in der Tabelle vorhanden ist, liegt die Tabelle **automatisch in 3NF** vor.

**Wichtig:** In der Praxis ist die 3NF oft ausreichend, um eine perfekte Balance aus **Redundanz, Performance und Flexibilität** zu gewährleisten. Es gibt Sonderfälle (z. B. wissenschaftlicher Bereich), wo weiter normalisiert werden muss.

### Vorgang (Folie 26)

Funktionale Abhängigkeiten unter Nicht-PK-Feldern werden durch **Aufteilung der Tabelle** aufgelöst:

```
Vorher:  PK = [S1, S2], Feld F hängt von DepF ab (beide Nicht-PK)
Nachher: Tabelle 1: [S1, S2, F]      ← F bleibt als FK
         Tabelle 2: [F, DepF]         ← F wird PK der neuen Tabelle
```

### Beispiel: Bahnwagen (Folie 27)

Aus der 2NF: `W12 = { [ WagenID, WagenType, Leergewicht, Kapazitaet, Hersteller, Baujahr ] }`

[Leergewicht], [Kapazitaet], [Hersteller] und ggf. [Baujahr] sind vom Feld [WagenType] abhängig → **nicht in 3NF**.

**Variante a** (Baujahr ist vom WagenType abhängig):
```
W121a = { [ WagenID, WagenType ] }
W122a = { [ WagenType, Leergewicht, Kapazitaet, Hersteller, Baujahr ] }
```

**Variante b** (Baujahr ist vom WagenType unabhängig):
```
W121b = { [ WagenID, WagenType, Baujahr ] }
W122b = { [ WagenType, Leergewicht, Kapazitaet, Hersteller ] }
```

### Beispiel: Kunden (Folie 28)

**Ausgangstabelle:** `{ [ KundenID, Adresse, Telefon ] }`

Wenn Adresse und Telefon voneinander unabhängig sind (nur vom PK KundenID abhängig), ist die Tabelle bereits in 3NF. Falls nicht → Aufteilung:
```
Tabelle 1 = { [ KundenID, Adresse ] }
Tabelle 2 = { [ KundenID, Telefon ] }
```

---

## 5. Boyce-Codd-Normalform – BCNF (Folien 29–30)

### Definition (Folie 29)

Eine Tabelle liegt in **BCNF** vor, wenn sie:
1. In **3NF** vorliegt
2. **Kein Teil** eines Schlüsselkandidaten funktional von keinem Teil eines **anderen** Schlüsselkandidaten abhängig ist

**Kern:** BCNF behandelt die **Abhängigkeiten zwischen Teilen mehrerer Schlüsselkandidaten**, falls diese sich teilweise **überlappen**.

**Regel:** Gibt es nur **einen Schlüsselkandidaten** oder liegt **keine Überlappung** vor, befindet sich die Tabelle **automatisch in BCNF**.

### Beispiel: Sportvereine (Folie 30)

| Name | Sportart | Verein |
|---|---|---|
| Schulz | Fußball | FC Berlin |
| Mayer | Fußball | FC Berlin |
| Zimmermann | Fußball | FC Marzahn |
| Mayer | Volleyball | VC Hamburg |

**Beziehung:** Sportart : Verein = 1 : N (ein Verein betreibt nur eine Sportart, aber zu einer Sportart gehören mehrere Vereine)

**Schlüsselkandidaten:** [Name, Sportart] und [Name, Verein] → **Überlappung** (Name)

**Problem:** [Sportart] hängt vom Nicht-Schlüssel-Feld [Verein] ab → verletzt BCNF

**Lösung:**
```
Tabelle 1 = { [ Name, Verein ] }
Tabelle 2 = { [ Sportart, Verein ] }
```

---

## 6. Vierte Normalform – 4NF (Folie 31)

### Definition

Eine Tabelle liegt in **4NF** vor, wenn sie:
1. In **BCNF** vorliegt
2. Nur **semantisch verbundene** Nichtschlüsselattribute sich in der Tabelle befinden

Die 4NF trennt **semantisch (thematisch, inhaltlich) unabhängige** Entitäten durch Aufteilung der Tabelle.

### Beispiel: Bahnwagen

Aus der 3NF: `W122a = { [ WagenType, Leergewicht, Kapazitaet, Hersteller, Baujahr ] }`

[Leergewicht] und [Kapazitaet] werden **viel öfter** verwendet als [Hersteller] und [Baujahr] (historische Bedeutung) → **unterschiedliche Semantik** → werden nie gleichzeitig benötigt.

**Aufteilung in 4NF:**
```
W122a1 = { [ WagenType, Leergewicht, Kapazitaet ] }    ← technische Daten
W122a2 = { [ WagenType, Hersteller, Baujahr ] }         ← historische Daten
```

---

## 7. Fünfte Normalform – 5NF (Folien 32–34)

### Definition (Folie 32)

Eine Tabelle liegt in **5NF** vor, wenn sie:
1. In **4NF** vorliegt
2. Nicht mehr in Tabellen eines **geringeren Grades** zerlegt werden kann

**Kern:** Die neuen Tabellen können jederzeit den ursprünglichen Zustand **ohne Informationsverlust** wieder herstellen (durch JOIN).

**Nachteil:** Man braucht in der Praxis ständig die ganzen Informationen und muss daher ständig die vereinfachten Tabellen wieder **vereinigen** (JOIN).

### Beispiel 1: Touristik-Firma (Folie 33)

```
T10 = { [ PersID, TourNr, Trans-Unternehmen ] }    ← PK = alle drei Attribute
```

Keine mehrwertigen Abhängigkeiten, da die drei Felder zusammen eine informative Einheit bilden. Trotzdem zerlegbar in:

```
T11 = { [ PersID, TourNr ] }
T12 = { [ PersID, Trans-Unternehmen ] }
T13 = { [ TourNr, Trans-Unternehmen ] }
```

Diese drei Tabellen können durch JOIN wieder die Originaltabelle herstellen.

### Beispiel 2: Hersteller-Produkt-Person (Folie 34)

| HerstID | ProduktID | PersID |
|---|---|---|
| 1 | Stift | 006 |
| 1 | Ordner-L | 007 |
| 1 | Kopierpapier | 007 |
| 2 | Ordner-Z | 006 |
| 3 | Kopierpapier | 007 |

**Zerlegung in 5NF:**
```
TA = { [ HerstID, ProduktID ] }
TB = { [ PersID, ProduktID ] }
TC = { [ HerstID, PersID ] }
```

---

## 8. Bedeutung des ERM (Folien 35–41)

### ERM als Alternative zur Normalisierung (Folie 35)

- Für die Praxis ist es empfehlenswert, dass Tabellen sich in **3NF** befinden
- Höhere Normalformen sind eher für **theoretische Untersuchungen** wichtig
- In der Praxis gelten Richtlinien (z. B. Geschwindigkeit), die manchmal den Verzicht auf 3NF (sogar 2NF) erfordern

**Wichtige Erkenntnis:** Wenn man vom **ERM ausgeht** und den konzeptuellen Entwurf korrekt in den logischen umwandelt (inkl. Vereinfachung), bekommt man **ziemlich wahrscheinlich** Tabellen in 3NF.

### Anomalien ohne Normalisierung (Folien 36–38)

**Beispiel:** Eine Tabelle mit Mitarbeitern, Abteilungen und Projekten (nicht normalisiert):

| PersID | Name | AbtNr | Abteilung | ProjNr | ProjBeschreibung |
|---|---|---|---|---|---|
| 1 | Anna | 42 | Second Level | BE | Bergland ... |
| 1 | Anna | 42 | Second Level | NO | Nordsee ... |
| 2 | Arnold | 42 | Second Level | NO | Nordsee ... |
| 2 | Arnold | 42 | Second Level | OG | Ostgipfel ... |
| 3 | Betty | 53 | First Dept | OG | Ostgipfel ... |
| 3 | Betty | 53 | First Dept | WO | West-Ozean ... |
| 4 | Chris | 53 | First Dept | WO | West-Ozean ... |

**Probleme (Anomalien):**

| Anomalie | Problem |
|---|---|
| **Einfüge-Anomalie** | Neuer Mitarbeiter mit mehreren Projekten → mehrere Zeilen, Vertippen möglich |
| **Änderungs-Anomalie** | Projektumbenennung → mehrere Zeilen ändern, Übersehen möglich |
| **Lösch-Anomalie** | Mitarbeiter löschen → mehrere Zeilen entfernen, Übersehen möglich |

### Normalisierung → 3NF (Folie 39)

**Ergebnis der Normalisierung:**
```
Mitarbeiter   = { [ PersID, Name, AbtNr ] }
Abteilung     = { [ AbtNr, Abteilung ] }
arbeitet_an   = { [ PersID, ProjNr ] }
Projekt       = { [ ProjNr, ProjBeschreibung ] }
```

### ERM-Ansatz liefert dasselbe Ergebnis (Folie 40)

Wenn man mit dem **ERM anfängt** (konzeptuellen Entwurf richtig durchführt):

```
Abteilung (1) — gehört zu — (N) Mitarbeiter (M) — arbeitet an — (N) Projekt
```

Die Überführung in die relationale Darstellung liefert **dieselben Tabellen** wie die Normalisierung → ERM und Normalisierung sind **komplementäre Ansätze** zum gleichen Ziel.

---

## Zusammenfassung

| Normalform | Voraussetzung | Regel | Automatisch erfüllt wenn... |
|---|---|---|---|
| **1NF** | — | Nur atomare Werte in Zellen | Keine Auflistungen vorhanden |
| **2NF** | 1NF | Jedes Nicht-PK-Feld hängt vom **ganzen** PK ab | PK besteht aus nur einem Feld |
| **3NF** | 2NF | Nicht-PK-Felder sind **voneinander unabhängig** | Nur ein Nicht-PK-Feld vorhanden |
| **BCNF** | 3NF | Keine Abhängigkeiten zwischen Teilen verschiedener Schlüsselkandidaten | Nur ein Schlüsselkandidat oder keine Überlappung |
| **4NF** | BCNF | Nur semantisch verbundene Nicht-PK-Attribute zusammen | Alle Attribute thematisch zusammengehörig |
| **5NF** | 4NF | Nicht weiter in Tabellen geringeren Grades zerlegbar | Zerlegung würde Informationsverlust verursachen |

### Durchgängiges Beispiel: Bahnwagen

```
Ausgangstabelle:  { [ WagenID, Beschreibung, Status, Ankunft, Station ] }
→ 1NF:  W1   = { [ WagenID, Status, Ankunft, Station, WagenType, Leergewicht, Kapazitaet, Hersteller, Baujahr ] }
→ 2NF:  W11  = { [ WagenID, Ankunft, Status, Station ] }
        W12  = { [ WagenID, WagenType, Leergewicht, Kapazitaet, Hersteller, Baujahr ] }
→ 3NF:  W11  = { [ WagenID, Ankunft, Status, Station ] }
        W121 = { [ WagenID, WagenType ] }
        W122 = { [ WagenType, Leergewicht, Kapazitaet, Hersteller, Baujahr ] }
→ 4NF:  W122a1 = { [ WagenType, Leergewicht, Kapazitaet ] }
        W122a2 = { [ WagenType, Hersteller, Baujahr ] }
```