Schlüssel und Constraints

Wie sichern Schlüssel und Constraints die Datenqualität?

Die Hierarchie der Schlüssel: Datensätze eindeutig identifizieren

Stell dir eine Datenbanktabelle für die Mitarbeitenden deines Unternehmens vor. Damit das System fehlerfrei arbeitet, muss jede Zeile (jedes Tupel) eindeutig identifizierbar sein. Diese Eigenschaft nennt man Entitätsintegrität. Um sie zu garantieren, nutzt das relationale Modell eine Hierarchie von Schlüsseln, die wie ineinandergreifende Mengen funktionieren:

Superschlüssel (Superkey): Eine beliebige Spalte oder Kombination von Spalten, die einen Datensatz eindeutig macht. Die Kombination (Personalnummer, Nachname) ist ein Superschlüssel. Da die Personalnummer allein aber schon ausreicht, ist diese Kombination nicht minimal.
Kandidatenschlüssel (Candidate Key): Ein minimaler Superschlüssel. Du kannst keine Spalte aus ihm entfernen, ohne die Eindeutigkeit zu verlieren. In der Mitarbeitendentabelle könnten sowohl die Personalnummer als auch die Sozialversicherungsnummer eigenständige Kandidatenschlüssel sein.
Primärschlüssel (Primary Key): Aus allen Kandidatenschlüsseln wählst du exakt einen als Hauptidentifikator aus. Er darf niemals leer sein (NULL) und sollte sich idealerweise nie ändern. Meist wählt man dafür eine kurze, künstliche ID wie die Personalnummer.

Constraints: Geschäftsregeln direkt in der Datenbank verankern

Während Schlüssel die Eindeutigkeit von Datensätzen regeln, definieren Constraints (Einschränkungen) die inhaltlichen Spielregeln für einzelne Spalten. Sie setzen Geschäftsregeln auf Datenbankebene durch und verhindern fehlerhafte Eingaben, was die Datenqualität massiv erhöht:

NOT NULL (Vollständigkeit): Erzwingt, dass eine Spalte zwingend einen Wert enthalten muss. Bei einer Registrierung darf das Feld für die E-Mail-Adresse beispielsweise nicht leer bleiben.
UNIQUE (Einzigartigkeit): Garantiert, dass ein Wert in einer Spalte nur ein einziges Mal vorkommt, selbst wenn diese Spalte kein Primärschlüssel ist. So stellst du sicher, dass sich nicht zwei Personen mit demselben Benutzernamen anmelden.
CHECK (Wertebereich): Prüft Daten gegen eine definierte logische Regel, bevor sie gespeichert werden. Ein CHECK-Constraint kann beispielsweise erzwingen, dass in der Spalte Rabatt nur Werte zwischen 0 und 100 eingetragen werden dürfen.
DEFAULT (Standardwerte): Greift ein, wenn beim Erstellen eines Datensatzes kein Wert übergeben wird. Wird bei einer neuen Bestellung kein Status angegeben, setzt der DEFAULT-Constraint automatisch den Wert "Eingegangen".

Schlüssel und Constraints — dec-databases-relational-databases-data-modeling-keys-and-constraints_page1.svg

Wie schützt referentielle Integrität vor Datenchaos?

Fremdschlüssel und die Gefahr verwaister Datensätze

Du weißt bereits, wie man Beziehungen zwischen Entitäten modelliert. Technisch umgesetzt werden diese durch den Fremdschlüssel (Foreign Key). Er ist eine Spalte in einer Tabelle, die exakt auf den Primärschlüssel einer anderen Tabelle verweist. In einer Tabelle Bestellungen zeigt der Fremdschlüssel Kundennummer_FK auf den Primärschlüssel der Tabelle Kundschaft.

Hier greift das Konzept der referentiellen Integrität: Ein Fremdschlüssel darf nur Werte enthalten, die in der verknüpften Primärschlüsseltabelle auch tatsächlich existieren (oder er muss NULL sein).

Ohne diese Regel entstünden verwaiste Datensätze. Stell dir vor, eine Person wird aus der Tabelle Kundschaft gelöscht, aber ihre Bestellungen bleiben erhalten. Diese Bestellungen würden nun auf eine Kundennummer verweisen, die ins Leere führt. Das System könnte keine Rechnungen mehr zuordnen und Auswertungen wären fehlerhaft.

Strategien bei Datenänderungen (ON DELETE / ON UPDATE)

Um verwaiste Datensätze aktiv zu verhindern, bietet SQL Mechanismen an. Diese definieren, wie die Datenbank reagieren soll, wenn ein referenzierter Primärschlüssel gelöscht (ON DELETE) oder geändert (ON UPDATE) wird:

RESTRICT / NO ACTION: Dies ist der sichere Standard. Die Datenbank blockiert das Löschen der Person aus der Kundschaft, solange noch Bestellungen für sie existieren, und wirft eine Fehlermeldung.
CASCADE (Kaskadieren): Wird die Person gelöscht, löscht die Datenbank automatisch auch alle zugehörigen Bestellungen. Dies ist nützlich bei schwachen Entitäten, aber gefährlich, da unbeabsichtigt große Datenmengen verschwinden können.
SET NULL: Wird die Person gelöscht, bleiben die Bestellungen erhalten, aber ihr Fremdschlüssel Kundennummer_FK wird auf NULL gesetzt. Die Bestellung existiert noch (z. B. für die anonymisierte Umsatzstatistik), ist aber niemandem mehr zugeordnet.
SET DEFAULT: Ähnlich wie SET NULL, nur dass der Fremdschlüssel auf einen vorher definierten Standardwert gesetzt wird (z. B. eine Dummy-Kundennummer für "Gelöschte Accounts").

Schlüssel und Constraints — dec-databases-relational-databases-data-modeling-keys-and-constraints_page2.svg

Teste dein Wissen

Du modellierst eine Kundentabelle. Die Kombination (Kundennummer, E-Mail) identifiziert jeden Datensatz eindeutig, ist aber nicht minimal. Welcher Schlüsseltyp liegt hier vor?