Relationen, Schlüssel und Normalisierung

Das relationale Modell beschreibt Daten als Relationen. Praktisch denkt man dabei meistens an Tabellen.

Eine gute relationale Struktur vermeidet Redundanzen und sorgt dafür, dass Daten konsistent bleiben.

Relation, Tupel und Attribut

Beispiel: Eine Kundentabelle ist eine Relation. Ein einzelner Kunde ist ein Tupel. Nachname ist ein Attribut.

Primärschlüssel

Ein Primärschlüssel identifiziert jeden Datensatz eindeutig.

Beispiele:

• Kundennummer
• Film-ID
• Ticket-ID
• Rechnungsnummer

Eigenschaften:

• eindeutig
• möglichst stabil
• nicht leer
• möglichst kurz

Fremdschlüssel

Ein Fremdschlüssel verweist auf einen Primärschlüssel in einer anderen Tabelle.

Beispiel:

Vorstellung(Film-ID) verweist auf Film(Film-ID)
Ticket(Vorstellung-ID) verweist auf Vorstellung(Vorstellung-ID)

Fremdschlüssel sichern Beziehungen zwischen Tabellen.

Redundanz

Redundanz bedeutet, dass dieselbe Information mehrfach gespeichert wird.

Beispiel: Bei jedem Kundenauftrag werden Kundennummer, Kundenname und Adresse erneut gespeichert.

Problem: Ändert sich die Adresse, muss sie an vielen Stellen geändert werden. Passiert das nicht überall, entstehen widersprüchliche Daten.

Anomalien

Schlechtes Datenbankdesign führt zu Anomalien.

Normalisierung reduziert diese Probleme.

Funktionale Abhängigkeit

Ein Attribut B ist funktional abhängig von A, wenn zu jedem Wert von A höchstens ein Wert von B gehört.

Beispiel:

Kundennummer -> Kundenname

Wenn die Kundennummer bekannt ist, ist der zugehörige Kundenname eindeutig bestimmbar.

Voll funktionale Abhängigkeit

Ein Attribut ist voll funktional abhängig, wenn es vom gesamten zusammengesetzten Schlüssel abhängt und nicht nur von einem Teil davon.

Das ist besonders bei Tabellen mit zusammengesetzten Schlüsseln wichtig.

Transitive Abhängigkeit

Eine transitive Abhängigkeit liegt vor, wenn ein Nichtschlüsselattribut von einem anderen Nichtschlüsselattribut abhängt.

Beispiel:

Kundennummer -> PLZ
PLZ -> Ort

Dann hängt Ort indirekt von Kundennummer ab.

1. Normalform

Eine Tabelle ist in 1NF, wenn jeder Zellwert atomar ist.

Das bedeutet:

• keine Listen in einer Zelle
• keine Wiederholgruppen
• pro Zeile und Spalte genau ein Wert

Schlecht:

Kunde: 1
Telefonnummern: 0664..., 0732...

Besser: Telefonnummern in eigener Tabelle speichern.

2. Normalform

Eine Tabelle ist in 2NF, wenn sie in 1NF ist und jedes Nichtschlüsselattribut voll vom gesamten Schlüssel abhängt.

Relevant ist das vor allem bei zusammengesetzten Primärschlüsseln.

Problembeispiel:

Rechnungsnummer, Positionsnummer -> Artikelnummer, Artikelname, Preis

Wenn Artikelname nur von Artikelnummer abhängt, gehört er nicht sauber in diese Tabelle.

3. Normalform

Eine Tabelle ist in 3NF, wenn sie in 2NF ist und keine transitiven Abhängigkeiten enthält.

Beispiel:

Kunde(Kundennummer, Name, PLZ, Ort)

Wenn Ort von PLZ abhängt, kann eine eigene Tabelle sinnvoll sein:

Kunde(Kundennummer, Name, PLZ)
Ort(PLZ, Ort)

Warum bis zur 3NF?

Die dritte Normalform ist oft ein guter Kompromiss aus:

• wenig Redundanz
• weniger Anomalien
• klarer Struktur
• noch brauchbarer Performance
• guter Wartbarkeit

Merksatz

Normalisierung bedeutet nicht, Tabellen kompliziert zu machen. Sie macht Abhängigkeiten sichtbar und verhindert, dass dieselbe Wahrheit an vielen Stellen gepflegt werden muss.