Schlüssel in Datenbank-Management-Systemen (DBMS)

Ein Schlüssel dient in einer relationalen Datenbank dazu, die Tupel (Datensätze) einer Relation (Tabelle) zu identifizieren. Ein Schlüssel ist eine Gruppe von Spalten, die so ausgewählt wird, dass jede Zeile über den Werten dieser Spaltengruppe eine einmalige Wertekombination hat.

Bei einem Primärschlüssel handelt es sich um die Spalte (oder Spalten) einer Tabelle, mit der oder mit denen sich die Zeilen dieser Tabelle eindeutig identifizieren lassen.

KUNDEN

In dieser Tabelle ist zum Beispiel Kundennummer der Primärschlüssel.

Die Werte in den Spalten für Primärschlüssel müssen für jede Zeile eindeutig sein – Duplikate sind nicht zulässig. Außerdem dürfen sich in den Spalten für Primärschlüssel keine Nullen befinden. Die Verwendung von einer Spalte oder  mehreren Spalten als Primärschlüssel ist möglich. Wie legt man nun fest, welche Spalte hierfür verwenden sollten (und wie viele)?

Gelegentlich ist es ratsam oder sogar unerlässlich, mehrere Spalten zu verwenden. Falls man allerdings keinen triftigen Grund für die Verwendung mehrerer Spalten erkennen kann, sollten man nur eine nehmen. Das ist aber keine absolute Regel, nur ein Tipp. Besteht ein Primärschlüssel aus nur einer Spalte, lässt er sich in der Regel einfacher verwalten und bietet einen schnellen Betrieb. Für die Abfrage der Datenbank bedeutet es normalerweise schnellere Antworten, falls die Tabellen Primärschlüssel mit nur einer Spalte enthalten.

Die einfachste Möglichkeit zur Auswahl einer Spalte als Primärschlüssel (und damit eine Methode, die häufig angewandt wird) ist: Die Datenbank weist jeder Zeile automatisch eine eindeutige Nummer zu.

In einer Tabelle mit den Namen von Mitarbeitern, ist die Spalte mit den Vornamen eine schlechte Wahl, da man keine Kontrolle über die Vornamen der Mitarbeiter hat. Wie im Fall oben gibt es oft nur eine sinnvolle Möglichkeit für den Primärschlüssel. Sollte es mehrere Möglichkeiten geben, werden diese als Kandidatenschlüssel bezeichnet – wie der Name sagt, handelt es sich hierbei um Kandidaten für die Rolle des Primärschlüssels.

Legt man die Definition oben zugrunde – laut der ein Primärschlüssel aus mehr als einer Spalte bestehen kann und eine eindeutige Identifizierung der Zeilen gewährleistet – kann man zum Beispiel Mitarbeiternummer UND Vorname als Primärschlüssel festlegen. Dies erfüllt zwar die Anforderungen, macht allerdings nicht viel Sinn, da man unnötigerweise die Komplexität erhöht. Es wäre auch ein hervorragendes Beispiel für einen Superschlüssel. „Super“ steht in diesem Fall nicht als Synonym für großartig, sondern vielmehr für überzählig. Die Verwendung von Superschlüsseln wird nicht empfohlen.

Bei Fremdschlüsseln handelt es sich um Spalten, die auf Spalten mit Primärschlüsseln verweisen. So ist beispielsweise Auftragsnummer der Primärschlüssel für die Tabelle AUFTRÄGE unten. Bei Kundennummer handelt es sich damit um einen Fremdschlüssel, der auf den Primärschlüssel in der Tabelle KUNDEN verweist.

AUFTRÄGE

Falls man es ganz genau nimmt, müssen Fremdschlüssel nicht unbedingt auf einen Primärschlüssel verweisen. Die einzig echte Anforderung für eine Spalte, auf die ein Fremdschlüssel verweist, ist: Sie muss eindeutige Werte enthalten. Hier ein Beispiel:

MITARBEITER

Tatsächlich handelt es sich bei der Sozialversicherungsnummer um den Primärschlüssel der Tabelle. Allerdings haben wir an jeden Mitarbeiter eine Nummer vergeben, die ebenfalls eindeutig ist. In diesem Fall kann „AUFTRÄGE.Mitarbeiternummer“ als Fremdschlüssel auf „MITARBEITER.Mitarbeiternummer“ verweisen – selbst wenn es sich bei dieser Spalte nicht um einen Primärschlüssel handelt. Die eigentlich zu beachtende Regel ist ein bisschen subtiler: Ein Fremdschlüssel muss auf einen Kandidatenschlüssel verweisen.

Bei einem Kandidatenschlüssel handelt es sich um eine Spalte, die alle Anforderungen für einen Primärschlüssel erfüllt. Sie besitzt somit das Potential, selbst als Primärschlüssel zu fungieren. In der Praxis verweisen Fremdschlüssel so gut wie immer auf Primärschlüssel.

Der größte Teil dieser Definition basiert auf dem Buch Inside Relational Databases von Mark Whitehorn und Bill Marklyn, veröffentlicht im Springer Verlag.