Normalisierung1NF2NF3NFAnomalienFunktionale AbhängigkeitSchlüssel

Funktionale Abhängigkeiten und Normalisierung

Nach der Überführung eines ER-Modells in Relationen stellt sich die Frage: Sind diese Relationen gut strukturiert? Speichern sie Daten redundant? Drohen beim Ändern, Einfügen oder Löschen Inkonsistenzen?

Dieser Abschnitt führt drei aufeinander aufbauende Konzepte ein: Anomalien als Probleme schlecht strukturierter Datenbanken, funktionale Abhängigkeiten als formales Werkzeug zur Analyse, und Normalisierung als systematisches Verfahren zur Optimierung.

Anomalien

Bevor die Normalisierung formal eingeführt wird, lohnt ein Blick auf die konkreten Probleme, die in unzureichend strukturierten Relationen entstehen. Diese Probleme heißen Anomalien und entspringen alle derselben Ursache: Redundanz — also dieselbe Information, mehrfach gespeichert.

Folgende, bewusst schlecht entworfene Relation einer Schulbibliothek dient als Ausgangspunkt. Schnell fällt auf: Buchdaten (Titel, Autor, Standort) und Schülerdaten (Name, Klasse) tauchen mehrfach auf. Genau diese Vermischung verursacht die drei klassischen Anomalien.

Untersuche in der interaktiven Demo die drei verschiedenen Anomalien:

Das Buch „1984" soll in einen anderen Raum (205) aufbewahrt werden. Was passiert, wenn nicht alle betroffenen Zeilen synchron geändert werden.

Bibliothek_schlecht
BuchID	Titel	Autor	Standort	SchuelerID	SchuelerName	Klasse
B001	1984	Orwell	Raum 203	S123	Anna Schmidt	10a
B001	1984	Orwell	Raum 203	S456	Max Müller	10b
B002	Harry Potter	Rowling	Raum 204	S123	Anna Schmidt	10a
B003	Der Prozess	Kafka	Raum 203	NULL	NULL	NULL

Wähle aus, wie viele Zeilen geändert werden:

nur die erste B001-Zeilealle B001-Zeilen

Hinweis: Das Buch B001 kommt in zwei Zeilen vor — die Information „Standort" ist redundant gespeichert.

verantwortliche FABuchID → Titel, Autor, Standort — die Buchdaten hängen allein von BuchID ab, also nur von einem Teil des Schlüssels {BuchID, SchuelerID}.

Update-Anomalie

Wird das Buch 1984 von Raum 203 nach Raum 205 verlegt, müssen alle Zeilen mit B001 geändert werden. Wird auch nur eine vergessen, steht das Buch laut Datenbank gleichzeitig in zwei Räumen — ein Widerspruch, den die Datenbank selbst nicht auflösen kann.

Update-Anomalie: dieselbe Information mehrfach gespeichert — bei einer Änderung müssen alle Kopien synchron aktualisiert werden.

Einfüge-Anomalie

Ein neues Buch Faust (B004) soll in die Bibliothek aufgenommen werden, ist aber noch nicht ausgeliehen. Die Tabellenstruktur erzwingt jedoch Werte für SchuelerID, SchuelerName und Klasse. Drei Auswege bleiben — keiner überzeugt:

• NULL-Werte (verfälschen Auswertungen),
• Dummy-Werte (verfälschen die Daten),
• gar kein Eintrag (die Bibliothek "kennt" das Buch nicht).

Einfüge-Anomalie: Daten lassen sich nicht speichern, weil dafür künstlich abhängige Werte erfunden werden müssten.

Lösch-Anomalie

Gibt Max Müller (S456) sein einziges ausgeliehenes Buch zurück und wird die zugehörige Zeile gelöscht, verschwindet mit der Ausleihinformation auch Max Müller selbst: Die Schule weiß nicht mehr, dass er existiert oder in welche Klasse er geht.

Lösch-Anomalie: Beim Löschen verschwinden unbeabsichtigt unabhängige Informationen mit.

Gemeinsame Ursache

Anomalie	Symptom
Update	Inkonsistenzen bei Änderungen
Einfügen	Neue Daten nicht ohne Krücken speicherbar
Löschen	Unbeabsichtigter Verlust unabhängiger Daten

Alle drei Anomalien wurzeln in Redundanz: Derselbe Wert muss sich wiederholen — und er wiederholt sich genau dann, wenn er von etwas bestimmt wird, das nicht der Schlüssel der Tabelle ist. Konkret hängen in der Bibliothekstabelle Titel, Autor und Standort allein von BuchID ab, während SchuelerName und Klasse allein von SchuelerID abhängen — keines davon vom vollständigen Schlüssel {BuchID, SchuelerID}. Deshalb werden die Buchdaten für jede Ausleihe erneut gespeichert (Update-Anomalie), können ohne Ausleihe gar nicht erst existieren (Einfüge-Anomalie) und verschwinden mit der letzten Ausleihe (Lösch-Anomalie).

Solche Beziehungen „X bestimmt Y" heißen funktionale Abhängigkeiten — das systematische Werkzeug, um Redundanz aufzuspüren. Und um zu beurteilen, ob eine solche Abhängigkeit „am Schlüssel hängt" oder eben nicht, brauchen wir zusätzlich einen präzisen Schlüsselbegriff. Beide führen die nächsten Abschnitte ein.

Training — Anomalien erkennen

Gegeben sei folgendes nicht-normalisiertes Relationenschema:

Bestellung(Kunden_ID, Kunde_Name, Kunde_Adresse, Artikel_Name, Artikel_Preis, Lieferant, Lieferant_Telefon, Menge, Datum)

1. Erkläre an einem eigenen Beispiel, wie eine Update-Anomalie entstehen kann.
2. Beschreibe eine Situation, in der eine Einfüge-Anomalie das Speichern wichtiger Informationen verhindert.
3. Konstruiere einen Fall, in dem das Löschen eines einzelnen Tupels zu einer Lösch-Anomalie führt.

Funktionale Abhängigkeiten (FA)

Definition

Sei $R$ eine Relation mit Attributmenge $\mathcal{A}$, und seien $X,Y\subseteq \mathcal{A}$ Attributteilmengen. Eine funktionale Abhängigkeit $X\to Y$ liegt vor, wenn für alle Tupel $t_1,t_2$ in $R$ gilt:

$$t_1[X]=t_2[X]\Rightarrow t_1[Y]=t_2[Y].$$

• $t[X]$ bezeichnet die Werte, die das Tupel $t$ in den Attributen $X$ trägt. Siehe Tupel.
• $X\to Y$ liest sich „X bestimmt Y" oder „Y ist funktional abhängig von X".

In Worten: Stimmen zwei Tupel in den Werten von $X$ überein, dann zwangsläufig auch in den Werten von $Y$. Die Werte von $X$ legen die von $Y$ eindeutig fest.

Einzelne und zusammengesetzte Determinanten

Determinante: linke Seite einer funktionalen Abhängigkeit $X\to Y$, also die Attribute, die andere Werte „determinieren" (festlegen).

Oft bestimmt schon ein einzelnes Attribut weitere Werte (einfache Determinante):

Schüler(SchuelerID, Name, Geburtsdatum, Klasse, Klassenlehrer)

mit den Abhängigkeiten

• Klasse → Klassenlehrer
• SchuelerID → Name, Geburtsdatum, Klasse

Schüler
SchuelerID	Name	Geburtsdatum	Klasse	Klassenlehrer
S001	Anna Schmidt	2008-04-12	10a	Frau Meyer
S002	Max Müller	2008-09-03	10a	Frau Meyer
S003	Lisa Weber	2007-11-21	10b	Herr Schmidt
S004	Tom Koch	2008-02-08	10b	Herr Schmidt

Konkret in der Tabelle ablesbar: Die Zeilen S001 und S002 stimmen in Klasse überein (beide 10a) und tragen folglich denselben Klassenlehrer (Frau Meyer). Genauso bei S003 und S004: gleiche Klasse 10b, gleicher Klassenlehrer Herr Schmidt. Das ist Klasse → Klassenlehrer.

In anderen Fällen genügt ein einzelnes Attribut nicht — erst die Kombination mehrerer Attribute bestimmt einen Wert eindeutig (zusammengesetzte Determinante):

Prüfung(SchuelerID, FachID, Datum, Note, Punktzahl)

Prüfung
SchuelerID	FachID	Datum	Note	Punktzahl
S001	MAT	2024-03-15	1.7	13
S001	MAT	2024-06-20	2.3	11
S001	DEU	2024-03-15	2.0	12
S002	MAT	2024-03-15	2.7	9

In der Tabelle lassen sich alle „kleineren" Determinanten ausschließen. Zum Beispiel:

• SchuelerID allein reicht nicht — Anna (S001) hat drei verschiedene Noten.
• FachID allein reicht nicht — in MAT stehen drei unterschiedliche Noten (1.7, 2.3, 2.7).
• ...

Erst die volle Kombination {SchuelerID, FachID, Datum} → Note bestimmt die Note eindeutig.

Schlüssel

Ob eine funktionale Abhängigkeit zu Redundanz führt, entscheidet sich daran, ob ihre Determinante ein Schlüssel der Relation ist — der Begriff ist daher der Maßstab für alles Folgende. Ein Schlüssel ist eine Attributmenge, deren Werte jedes Tupel eindeutig identifizieren: keine zwei Tupel stimmen in ihnen überein. Genauer unterscheidet man drei zusammenspielende Begriffe:

• Superschlüssel: eine Attributmenge $X\subseteq \mathcal{A}$, die alle Attribute des Schemas funktional bestimmt ($X\to \mathcal{A}$) — kein zweites Tupel hat dieselben Werte in $X$. Darf „zu groß" sein, also überflüssige Attribute enthalten.
• Kandidatenschlüssel: ein minimaler Superschlüssel — keine echte Teilmenge ist noch Superschlüssel. Eine Relation kann mehrere haben.
• Primärschlüssel: einer der Kandidatenschlüssel, vom Modellierer als Hauptschlüssel ausgewählt (mit Unterstreichung markiert).

Daraus folgt die für die Normalformen entscheidende Unterscheidung:

• Ein Schlüsselattribut kommt in mindestens einem Kandidatenschlüssel vor.
• Alle übrigen heißen Nichtschlüsselattribute.

Hierarchie auf einen Blick: $\text{Superschlu¨ssel}\supseteq \text{Kandidatenschlu¨ssel}\supseteq \text{Prima¨rschlu¨ssel}$.

Diese Begriffe lassen sich an einem Schema mit mehreren Kandidatenschlüsseln am besten nachvollziehen.

Schlüssel-Demo

Gegeben sei das Schema

Schüler(SchuelerID, Ausweisnummer, Vorname, Nachname, Geburtsdatum, Klasse)

mit der Annahme, dass {SchuelerID}, {Ausweisnummer} und {Vorname, Nachname, Geburtsdatum} jeweils einen Schüler eindeutig identifizieren. Klicke in der Demo auf die Spaltennamen und beobachte, welche Auswahl zu einem Kandidatenschlüssel, einem Superschlüssel oder zu keinem Schlüssel führt:

Klicke Spalten an, um eine Attributmenge X auszuwählen. Die Komponente prüft, ob X ein Kandidatenschlüssel, ein Superschlüssel (nicht minimal) oder kein Schlüssel ist.

SchuelerID	Ausweisnummer	Vorname	Nachname	Geburtsdatum	Klasse
S001	AW-4711	Anna	Schmidt	12.04.2008	10a
S002	AW-3892	Max	Müller	03.09.2008	10a
S003	AW-5501	Lisa	Weber	21.11.2007	10b
S004	AW-2284	Anna	Becker	12.04.2008	10a
S005	AW-7720	Tim	Schmidt	21.11.2007	10b
S006	AW-8821	Anna	Schmidt	21.11.2007	10b

Wähle mindestens eine Spalte aus, um die Klassifikation zu sehen.

Hinweis: Minimalität gilt je Kandidatenschlüssel

Mehrere Kandidatenschlüssel können unterschiedlich groß sein. Hier existieren z. B. {SchuelerID} (ein Attribut) und gleichzeitig {Vorname, Nachname, Geburtsdatum} (drei Attribute). „Minimal" heißt nicht möglichst klein im Vergleich zu anderen Schlüsseln, sondern in sich minimal: keine echte Teilmenge dieses Schlüssels ist selbst noch Superschlüssel. Es gibt also nicht den kleinsten Kandidatenschlüssel — verschieden große Kandidatenschlüssel können nebeneinander existieren.

Kurz zusammengefasst:

• Es gibt drei Kandidatenschlüssel: {SchuelerID}, {Ausweisnummer} und {Vorname, Nachname, Geburtsdatum} — jeweils in sich minimal, dürfen aber durchaus unterschiedlich groß sein.
• Jede Obermenge eines Kandidatenschlüssels ist ein Superschlüssel, z. B. {SchuelerID, Klasse}. Die zusätzlichen Attribute sind redundant.
• Als Primärschlüssel wählen wir {SchuelerID} — interne IDs sind stabiler als z. B. eine Ausweisnummer, die sich bei Verlust ändern kann.
• Schlüsselattribute sind alle Attribute, die in mindestens einem Kandidatenschlüssel vorkommen: SchuelerID, Ausweisnummer, Vorname, Nachname, Geburtsdatum. Nur Klasse ist ein Nichtschlüsselattribut.

Volle vs. partielle Abhängigkeit

Ein Attribut $Y$ ist voll funktional abhängig von $X$, wenn $X\to Y$ gilt und keine echte Teilmenge von $X$ schon $Y$ bestimmt. Andernfalls liegt eine partielle Abhängigkeit vor.

Praktisch relevant wird das, wenn $X$ ein Kandidatenschlüssel und $Y$ ein Nichtschlüsselattribut ist: Eine partielle Abhängigkeit bedeutet dann, dass $Y$ schon von einem Teil des Schlüssels bestimmt wird — genau diese Fälle beseitigt die 2NF.

Faustregel: Lässt sich aus der linken Seite ein Attribut weglassen, ohne die Abhängigkeit zu verlieren? Dann ist sie partiell.

In der Prüfungsrelation oben ist Note voll abhängig von {SchuelerID, FachID, Datum}. Eine vereinfachte Variante mit Zwei-Attribut-Schlüssel und ergänztem SchuelerName zeigt dagegen ein Problem:

Prüfung_schlecht(SchuelerID, FachID, SchuelerName, Note)

Prüfung_schlecht
SchuelerID	FachID	SchuelerName	Note
S001	MAT	Anna Schmidt	1.7
S001	DEU	Anna Schmidt	2.0
S002	MAT	Max Müller	2.7
S002	DEU	Max Müller	1.3

In der Tabelle direkt sichtbar: Annas Name steht in jeder ihrer Prüfungszeilen erneut. SchuelerName hängt nur von SchuelerID ab — FachID spielt für seine Bestimmung keine Rolle. Man sagt: SchuelerName ist partiell abhängig vom zusammengesetzten Schlüssel {SchuelerID, FachID} und führt direkt zu Redundanz.

Transitive Abhängigkeit

Wenn $A\to B$ und $B\to C$ gelten, $B$ aber kein Schlüsselattribut ist, dann ist $C$ transitiv abhängig von $A$.

In einer reduzierten Schüler-Relation, die nur Klasseninformation trägt:

Schüler(SchuelerID, Klasse, Klassenlehrer)

Schüler
SchuelerID	Klasse	Klassenlehrer
S001	10a	Frau Meyer
S002	10a	Frau Meyer
S003	10b	Herr Schmidt
S004	10b	Herr Schmidt

Der Klassenlehrer hängt eigentlich an der Klasse, nicht am Schüler — Frau Meyer taucht zweimal auf (für jede 10a-Schülerzeile), Herr Schmidt ebenfalls. Über den Umweg Klasse ergibt sich eine indirekte Abhängigkeit von SchuelerID.

Die Folge sind Redundanzen. Wechselt die 10a den Klassenlehrer, müssen sämtliche Schülerzeilen der 10a angepasst werden.

Eine transitive Abhängigkeit „springt" über ein Nichtschlüsselattribut. Genau das wird in der 3NF beseitigt.

Übersicht

Typ	Bedeutung	Beispiel
Funktionale Abhängigkeit	$X\to Y$	SchuelerID → Name
Volle funktionale Abhängigkeit	$Y$ braucht alle Attribute aus $X$	{SchuelerID, FachID} → Note
Partielle Abhängigkeit	$Y$ hängt schon von einer echten Teilmenge von $X$ ab	{SchuelerID, FachID} → SchuelerName
Transitive Abhängigkeit	$A\to B\to C$, $B$ kein Schlüssel	SchuelerID → Klasse → Klassenlehrer

Interaktive Demo

Probiere die drei Typen funktionaler Abhängigkeiten selbst aus: Wähle eine oder mehrere Spalten als Determinante X — die Demo zeigt, welche Attribute Y dadurch bestimmt werden und ob die Abhängigkeit voll, partiell oder transitiv ist.

Klicke auf eine oder mehrere Spalten, um sie als Determinante X auszuwählen. Die Komponente zeigt, welche Attribute Y dadurch funktional bestimmt werden (X → Y) und ob die Abhängigkeit voll, partiell oder transitiv ist.

Vorschläge:

SchuelerID	FachID	SchuelerName	Klasse	Klassenlehrer	Note
S001	MAT	Anna Schmidt	10a	Frau Meyer	1,7
S001	DEU	Anna Schmidt	10a	Frau Meyer	2,0
S002	MAT	Max Müller	10a	Frau Meyer	2,7
S003	MAT	Lisa Weber	10b	Herr Schmidt	1,3
S003	DEU	Lisa Weber	10b	Herr Schmidt	2,3

Wähle eine oder mehrere Spalten aus, um die funktionalen Abhängigkeiten anzuzeigen.

Training — Funktionale Abhängigkeiten

In der Datenbank des Onlineshops werden alle Bestellungen in einer zentralen Liste erfasst. Gegeben sei die Relation

Bestellungen(BestellNr, ProduktID, Produktname, Kategorie, Preis, KundenNr, Email, Stadt)

1. Liste alle funktionalen Abhängigkeiten auf, die sich aus dem Schema ergeben.
2. Untersuche die Abhängigkeiten der Nicht-Schlüsselattribute. Welche sind voll funktional vom Primärschlüssel abhängig, welche nur partiell?
3. Überprüfe, ob transitive Abhängigkeiten zwischen Nicht-Schlüsselattributen bestehen. Begründe dein Ergebnis.

Normalisierung

Normalisierung ist ein schrittweises Verfahren, das Relationen so umformt, dass Redundanzen verschwinden und Anomalien strukturell ausgeschlossen sind. Die einzelnen Normalformen bauen aufeinander auf — jede strenger als die vorhergehende.

Erste Normalform (1NF)

Eine Relation ist in 1NF, wenn alle Attributwerte atomar sind — also nicht weiter zerlegbar (keine Listen, keine zusammengesetzten Werte, etc.).

Folgende Relation verletzt die 1NF, weil das Attribut Hobbys mehrere Werte enthält:

Schüler_alt
SchuelerID	Vorname	Nachname	Hobbys
S001	Anna	Schmidt	Tennis, Lesen, Schwimmen
S002	Max	Müller	Fußball, Gitarre

Die saubere Lösung lagert die mehrwertige Eigenschaft in eine eigene Relation aus:

Schüler
SchuelerID	Vorname	Nachname
S001	Anna	Schmidt
S002	Max	Müller

Hobby
SchuelerID	Hobby
S001	Tennis
S001	Lesen
S001	Schwimmen
S002	Fußball
S002	Gitarre

Zweite Normalform (2NF)

Eine Relation ist in 2NF, wenn sie in 1NF ist und jedes Nichtschlüsselattribut voll funktional abhängig vom gesamten Primärschlüssel ist — also keine partiellen Abhängigkeiten existieren.

2NF ist nur dann ein Thema, wenn der Primärschlüssel mehrere Attribute umfasst — bei einem einattributigen Primärschlüssel kann es per Definition keine partielle Abhängigkeit geben.

Folgende Prüfungsrelation hat den zusammengesetzten Schlüssel {SchuelerID, FachID}:

Prüfung
SchuelerID	FachID	SchuelerName	Fachname	Note
S001	MAT	Anna Schmidt	Mathematik	1.7
S001	DEU	Anna Schmidt	Deutsch	2.3
S002	MAT	Max Müller	Mathematik	2.0

SchuelerName hängt nur von SchuelerID ab, Fachname nur von FachID — beides sind partielle Abhängigkeiten. Die 2NF stellt sie ab, indem sie diese Attribute in eigene Relationen auslagert:

Schüler
SchuelerID	SchuelerName
S001	Anna Schmidt
S002	Max Müller

Fach
FachID	Fachname
MAT	Mathematik
DEU	Deutsch

Prüfung
SchuelerID	FachID	Note
S001	MAT	1.7
S001	DEU	2.3
S002	MAT	2.0

Dritte Normalform (3NF)

Eine Relation ist in 3NF, wenn sie in 2NF ist und kein Nichtschlüsselattribut transitiv vom Primärschlüssel abhängt.

Schüler
SchuelerID	Name	Klasse	Klassenlehrer	Raum
S001	Anna Schmidt	10a	Frau Meyer	A201
S002	Max Müller	10a	Frau Meyer	A201
S003	Lisa Weber	10b	Herr Schmidt	A202

Hier gilt Klasse → Klassenlehrer und Klasse → Raum zwischen Nichtschlüsselattributen. Klassenlehrer und Raum werden für jeden Schüler einer Klasse erneut gespeichert (Redundanz). Die Auflösung trennt den Klassenkontext in eine eigene Relation ab:

Schüler
SchuelerID	Name	Klasse
S001	Anna Schmidt	10a
S002	Max Müller	10a
S003	Lisa Weber	10b

Klasse
Klassenname	Klassenlehrer	Raum
10a	Frau Meyer	A201
10b	Herr Schmidt	A202

Übersicht der Normalformen

NF	Bedingung (zusätzlich zur Vorgängerstufe)
1NF	atomare Attributwerte
2NF	keine partiellen Abhängigkeiten vom Primärschlüssel
3NF	kein Nichtschlüsselattribut ist transitiv vom Primärschlüssel abhängig

In der Praxis ist die 3NF der übliche Zielzustand: Sie beseitigt die wesentlichen Redundanzen und erhält dabei alle funktionalen Abhängigkeiten.

Training — Schulbibliothek

Gegeben sei folgende Relation einer Schulbibliothek. Die AusleihID wird pro Buch fortlaufend vergeben — derselbe AusleihID-Wert kann also bei verschiedenen Büchern erneut auftauchen, weshalb erst die Kombination aus BuchID und AusleihID einen Ausleihvorgang eindeutig identifiziert.

Bibliothek(BuchID, AusleihID, Buchtitel, Autor, ISBN, SchuelerID, SchuelerName, Klasse, Ausleihdatum, Rückgabedatum)

1. Gebe alle funktionalen Abhängigkeiten an.
2. Begründe, warum {BuchID, AusleihID} der Primärschlüssel ist. Gibt es weitere Schlüsselkandidaten und Superschlüssel? Was sind die Schlüsselattribute?
3. In welcher Normalform ist die Relation? Begründe.
4. Überführe die Relation schrittweise in 2NF und 3NF und gib das resultierende Relationenschema an.
5. Skizziere ein passendes ER-Diagramm mit (min,max)-Notation zur normalisierten Lösung.

Training — Krankenhaus

In einem Krankenhaus wird jede Behandlung durch Patient, Arzt und Datum eindeutig identifiziert. Ein Arzt gehört genau einer Abteilung an, jede Krankenkasse hat genau einen Hauptsitz.

Behandlung(PatientenID, ArztID, Datum, PatientenName, Krankenkasse, KassenHauptsitz, ArztName, Fachgebiet, Abteilung, Abteilungsleiter, Diagnose, Behandlungsdauer)

1. Gib alle funktionalen Abhängigkeiten an.
2. Begründe den Primärschlüssel. Gibt es weitere Schlüsselkandidaten, Superschlüssel, Schlüsselattribute?
3. In welcher Normalform ist die Relation? Begründe mit konkreten Verstößen.
4. Überführe schrittweise in 2NF und 3NF. Gib jeweils das vollständige Schema an.
5. Skizziere ein ER-Diagramm mit (min,max)-Notation.