Ein Schlüssel dient in einer relationalen Datenbank dazu, die Tupel (Datensätze, „Zeilen“) einer Relation (Tabelle) eindeutig zu identifizieren, sie zu nummern. Ein Schlüssel ist dann eine Gruppe von Spalten (oder eine einzelne), die so ausgewählt wird, dass jede Tabellenzeile über die Werte dieser Spaltengruppe eine einmalige (und damit eindeutige) Wertekombination hat.

Einführung

In der Theorie der relationalen Datenbanken sind pro Entitätstyp (pro Tabelle) ein oder mehrere Schlüsselkandidaten (Spaltenkombinationen, die als Schlüssel möglich wären) erforderlich, welche definitionsgemäß jeweils eindeutig sein müssen. Von diesen Schlüsselkandidaten wird einer als Primärschlüssel ausgewählt und bei der Umsetzung der Entität als Datenbanktabelle als solcher implementiert. Abweichend von dieser Konvention gibt es auch Datenbanksysteme, die Tabellendefinitionen erlauben, ohne dass ein Primärschlüssel definiert wird. Solche Tabellen erlauben damit auch doppelte Datensätze und sind damit definitionsgemäß keine relationalen Entitäten.

In Relationalen Datenbanken unterscheidet man die Schlüsselbegriffe

Superschlüssel (gelegentlich auch Oberschlüssel genannt)

Menge von Attributen (Spalten) in einer Relation (Tabelle), die die Tupel (Zeilen) in dieser Relation eindeutig identifizieren, also bei paarweise ausgewählten Tupeln immer unterschiedliche Werte enthalten (man sagt auch „eindeutig sind“). Ein trivialer Superschlüssel wäre zum Beispiel die Menge aller Attribute einer Relation gemeinsam. (Trivial deswegen, weil eine Relation eine Menge von Tupeln ist. Die Elemente von Mengen müssen eindeutig sein, also darf es in einer Relation keine zwei gleichen Tupel geben.) Das bedeutet, ein Superschlüssel kann auch „unnötige Spalten“ beinhalten, die für die Schlüssel-Eigenschaft gar nicht notwendig sind.

Schlüsselkandidat (auch Kandidatenschlüssel oder Alternativschlüssel genannt)

Eine minimale Teilmenge der Attribute (Spalten) eines Superschlüssels, welche die Identifizierung der Tupel ermöglicht (Schlüsselkandidaten ⊆ Superschlüssel). „Minimal“: Bei einem Schlüsselkandidat kann keine Spalte mehr weggelassen werden; er würde dann nicht mehr eindeutig identifizieren.

Primärschlüssel

Der ausgewählte Schlüsselkandidat, der für die Abbildung der Relationen verwendet wird (für die Tabelle tatsächlich verwendet wird). Die Werte dieses Schlüssels werden in anderen, referenzierenden Tabellen als Fremdschlüssel verwendet: Wenn sich eine andere Tabelle auf die hiesige bezieht, wird dort der Primärschlüssel verwendet, um auf einen Datensatz der hiesigen Tabelle zu zeigen.

Schlüsselkandidat

Ein Schlüsselkandidat (englisch candidate key) ist eine minimale Menge von Attributen, die die Tupel (Datensätze) einer Relation eindeutig identifiziert. Die formale Definition lautet: Ist ${\displaystyle R(A)}$ eine Relation über der Menge von Attributen ${\displaystyle A:=\{A_{1},...,A_{n}\}}$, so gilt: ${\displaystyle \alpha \subseteq A}$ ist genau dann ein Schlüsselkandidat von R, wenn gilt: ${\displaystyle \alpha {\dot {\rightarrow }}A}$.

Hierbei wird der Begriff der vollen funktionalen Abhängigkeit – dargestellt durch ${\displaystyle \alpha {\dot {\rightarrow }}A}$ – verwendet. Hier ist A von ${\displaystyle \alpha }$ voll funktional abhängig, was bedeutet:

1. Haben zwei Tupel in den Schlüsselattributen (${\displaystyle \alpha }$) dieselben Werte, so haben sie auch in allen übrigen Attributen (A) dieselben Werte. Und:
2. Entfernt man ein Attribut aus ${\displaystyle \alpha }$, so gilt Eigenschaft 1 nicht mehr.

Im Gegensatz zum Superschlüssel werden hier also nur noch diejenigen Attributmengen betrachtet, die nicht mehr verkleinert werden können, ohne ihre Schlüsseleigenschaft zu verlieren; man sagt auch, sie seien minimal identifizierend. Für die Beispielrelationen der Einleitung ergeben sich folgende Schlüsselkandidaten:

a

{ISBN}, {Autor, Buchtitel}

b

{Name, Geburtstag}

c

{Vorgesetzter, Untergebener}

Aus der Liste der Superschlüssel wurden also gerade diejenigen ausgewählt, die minimal sind. Gelegentlich wird auch die Bezeichnung Kandidatenschlüssel verwendet, was eine wörtliche Übersetzung des englischen Fachbegriffs candidate key ist.

Primärschlüssel und Alternativschlüssel

Um die Tupel (=Zeilen) in einer Relation (=Tabelle) eindeutig identifizieren zu können, wird für die Relation ein Primärschlüssel angegeben – einer der Schlüsselkandidaten. Der Primärschlüssel wird üblicherweise so ausgewählt, dass er möglichst klein ist, das heißt möglichst wenige Attribute umfasst bzw. einen möglichst simplen Datentyp hat. Er sollte zeitlich stabil sein, seine Werte sollten sich also während des gesamten Lebenszyklus der betroffenen Tabellen nicht ändern, da dies auch Änderungen an den zugehörigen Fremdschlüsselwerten mit sich zöge (was durch sogenannte Kaskadierung zwar prinzipiell möglich, aber oft aufwendig ist).

Darüber hinaus muss der ausgewählte Primärschlüssel tatsächlich die eindeutige Identifizierbarkeit der realen Objekte erlauben, die durch die Tupel der Relation repräsentiert werden. Wählt man beispielsweise die Kombination {Name, Geburtstag} als Primärschlüssel aus, so legt man damit auch fest, dass es keine zwei gleichnamigen Personen geben darf, die am gleichen Tag Geburtstag haben (Eindeutigkeit, uniqueness). Durch die Einführung von Surrogatschlüsseln (künstliche Schlüssel, z. B. eine Laufnummer) wird dieses Problem in jedem Fall vermieden. Für die Beispielrelationen aus der Einleitung bieten sich die folgenden Primärschlüssel an (sind Schlüsselkandidaten):

a

{ISBN}

b

{Name, Geburtstag}

c

{Vorgesetzter, Untergebener}

Unter der Voraussetzung, dass keine Surrogatschlüssel eingeführt werden sollen, ist die Entscheidung bei den Beispielen b) und c) hinfällig, denn es gibt jeweils nur einen Schlüsselkandidaten; folglich muss dieser auch als Primärschlüssel verwendet werden. In Beispiel a) entscheidet man sich für {ISBN} als Primärschlüssel, weil dies der kleinste Schlüssel ist (er hat im Gegensatz zu {Autor, Buchtitel, …} nur ein Attribut), zudem wird dadurch die Realität genau wiedergegeben. Besteht ein Primärschlüssel aus mehreren Attributen, spricht man auch von einem kombinierten (auch: zusammengesetzten) Primärschlüssel oder einem Verbundschlüssel. Durch die Auswahl des Primärschlüssels werden alle anderen Schlüsselkandidaten der Relation automatisch zu Alternativschlüsseln. In unseren Beispielrelationen wären dies:

a

{Autor, Buchtitel}

b

keine

c

keine

Alternativschlüssel haben den Zweck, dass in der Tabelle Eindeutigkeit bei allen Schlüsselkandidaten durchgesetzt wird, nicht nur beim Primärschlüssel. (Dadurch sind Alternativschlüssel prinzipiell geeignet, in einer anderen Relation als Fremdschlüssel verwendet zu werden).

Sekundärschlüssel

Sekundärschlüssel sind Attributgruppen, die häufig zur Beschreibung einzelner und mehrerer Tupel benutzt werden (Suchbegriff). So kann etwa die Postleitzahl in einer Adresstabelle als Sekundärschlüssel infrage kommen.

In der Datenbank können Sekundärschlüssel durch Sekundärindizes (umgangssprachlich einfach nur „Indizes“) implementiert werden. Ein Sekundärindex ist eine optionale, zusätzliche Suchstruktur einer Datenbank, die Tupel schneller auffindbar macht, indem das Durchsuchen des gesamten Datenbestandes vermieden wird (genau so wie der Index eines Buches, durch den Begriffe gezielt aufgefunden werden können).

Sekundärschlüssel müssen nicht notwendigerweise eindeutig sein (lediglich die sogenannten Alternativschlüssel, die automatisch auch Sekundärschlüssel sind, sind eindeutig). Aber auch Fremdschlüssel (ebenfalls nicht zwingend eindeutig) sind Sekundärschlüssel, weil sie dazu dienen, Datensätze zu beschreiben (ordnen, gruppieren etc.).

Stellvertretender Schlüssel

Es ist möglich, dass alle Schlüsselkandidaten einer Relation aus mehreren Attributen bestehen, oder dass alle Schlüsselkandidaten die tatsächlichen Verhältnisse nur unzureichend widerspiegeln. Von unseren Beispielen ist b) ein solcher Fall. Will man in der Tabelle Kunde eine Person identifizieren, muss man stets Name und Geburtstag gleichzeitig angeben. Es ist daher oft wünschenswert, ein zusätzliches Attribut einzuführen, das als Primärschlüssel dient: Man nennt dies einen stellvertretenden Schlüssel (englisch surrogate key). Für Beispiel b) würde sich eine geschäftseigene Identifikationsnummer wie „Kundennummer“ oder eine fortlaufende Nummer anbieten.

Fremdschlüssel

Ein Fremdschlüssel ist ein Attribut oder eine Attributkombination einer Relation, welches auf einen Primärschlüssel (bzw. Schlüsselkandidaten) einer anderen oder der gleichen Relation verweist.

Er dient als Verweis zwischen zwei Relationen, d. h., er zeigt an, welche Tupel der Relationen inhaltlich miteinander in Verbindung stehen. Beispiele für Fremdschlüssel sind die beiden Attribute „Vorgesetzter“ und „Untergebener“ aus der Beispielrelation c) der Einleitung: Hier wird jeweils die „Personalnummer“ eines Angestellten angegeben. Doch mit einer solchen Nummer lässt sich im Alltag eher wenig anfangen; viel wichtiger sind Name, Abteilung, Beschäftigung und ähnliche Informationen. Deshalb wird hier höchstwahrscheinlich eine weitere Relation existieren, die Attribute wie {Personalnummer, Name, Abteilung, Beschäftigung, …} enthält. Diese Relation wird ebenso höchstwahrscheinlich den Primärschlüssel {Personalnummer} besitzen; es bietet sich also an, Personalnummer als Fremdschlüssel zu benutzen.

Anderweitige Begriffsverwendungen

Folgende Begriffe sind keine Schlüssel im Sinne der relationalen Datenbanken:

• Suchschlüssel: Ein Attribut oder eine Attributkombination einer Relation, die als Suchkriterium dient. Ein Suchschlüssel muss nicht notwendigerweise auch ein identifizierender Schlüssel sein. Es können sich also auch mehrere Datensätze über den gleichen Schlüsselwert qualifizieren.

Schlüssel können auch nach der Kategorie ihrer Herleitung als natürliche oder künstliche Schlüssel unterschieden werden.

• sprechender Schlüssel (auch natürlicher Schlüssel genannt): Ein Schlüsselkandidat, der im Tupel auf natürliche Weise vorhanden ist. Ein solcher Schlüssel besitzt also auch in der realen Welt eine Bedeutung, wie z. B. „Fahrgestellnummer“ bei polizeilich zugelassenen Kfz. Bei sprechenden Schlüssel ist zu beachten, dass die Schlüsseldomäne zerbrechen kann, falls die Felddomäne nicht mit Bedacht gewählt wird. So können etwa fünfstellige Kfz-Nummern aufgrund des Wachstums in den Neufahrzeugzulassungen irgendwann mal zu klein sein, was eine entsprechende Reorganisation der Schlüsselbezeichnungen erfordert. Wenn versucht wird, im Schlüssel auch sprechende Gruppenzuordnungen zu codieren, sind Schlüsselbrüche sehr wahrscheinlich, da die Nummernbereiche nicht fortlaufend verwendet werden. Darüber hinaus verletzt eine solche Praxis auch das Normalisierungsgebot, deshalb sollte eine Gruppenzuordnung über ein Attributfeld oder gar eine N:M-Zuordnungstabelle vorgenommen werden. Oft sind natürliche Schlüssel sinnvoll, um beispielsweise die Datensätze in der Chronologie ihrer Entstehung zu sortieren, oder werden vom Auftraggeber zwingend verlangt. Beispielsweise folgen die Kontennummern den Vorgaben des Kontenrahmens. Bei der Auslegung der Schlüsseldomäne sind Kriterien wie geplante Kardinalität, Lesbarkeit und Handhabung durch die Anwender genügend zu berücksichtigen.
• stellvertretender Schlüssel (Surrogatschlüssel): Ein künstlich erzeugtes, im Tupel zuvor gar nicht vorkommendes Attribut, das die Tupel der Relation identifiziert, das häufig als Primärschlüssel herangezogen wird. Triviales Beispiel: Fortlaufende Belegnummer. Surrogatschlüssel werden etwa in der OLAP-Technologie angewendet, wo sehr breite, zusammengesetzte Schlüssel auf einen kompakteren, künstlichen Surrogatekey umgeschlüsselt werden. In heterogenen Anwendungssystemen wird der Surrogatekey für eine bestimmte Entität vom hierzu gekennzeichneten führenden System vergeben. Werden Datensätze über Schnittstelle an Zweitsysteme durchgereicht, so müssen neben dem Schlüsselattribut, welches beispielsweise in einer Bewegungstabelle verwendet wird, allenfalls auch die zugehörige Entität mit den Stammdaten ans Zweitsystem übergeben werden.

Siehe auch

• Integritätsbedingung

Literatur

• Andreas Heuer, Gunter Saake: Datenbanken. Konzepte und Sprachen. MITP Verlag, ISBN 3-8266-0619-1
• A. Eickler, A. Kemper: Datenbanksysteme. Oldenbourg Verlag, ISBN 3-486-27392-2