16 KiB
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:
- In 1NF vorliegt
- 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:
- In 2NF vorliegt
- 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:
- In 3NF vorliegt
- 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:
- In BCNF vorliegt
- 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:
- In 4NF vorliegt
- 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 ] }