docs: add obsidian hwr docs

Datenbanken/Zusammenfassungen/e_NFs - zusammenfassung.md

@@ -0,0 +1,423 @@
+# 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 ] }
+```