Surrogatschlüssel

Ein Surrogatschlüssel (Stellvertreterschlüssel, englisch surrogate key wörtlich ‚Ersatzschlüssel‘, auch künstlicher Schlüssel oder synthetischer Schlüssel genannt) ist ein Datenbankschlüssel, der nicht aus den Daten in der Tabelle abgeleitet wird. Surrogatschlüssel werden i. d. R. automatisch gebildet (z. B. als fortlaufende Nummer), häufig als Primärschlüssel verwendet und dienen dem einfacheren Zugriff auf Datensätze.

Abgrenzung zu Natürlichen Schlüsseln

Im Gegensatz zu einem natürlichen Schlüssel, auch „sprechender Schlüssel“ genannt, werden Surrogatschlüssel künstlich erzeugt. Der natürliche Schlüssel hingegen wird aus den Feldern, die ein Datenobjekt beschreiben (z. B. der Vorname, der Nachname und das Geburtsdatum beschreiben den Kunden), intuitiv abgeleitet.

Erzeugung

Der Surrogatschlüssel ist häufig, aber nicht zwingend, eine fortlaufende Nummer (Sequenznummer oder Autowert). Der Schlüssel kann entweder durch das Datenbanksystem oder durch ein Anwendungsprogramm vergeben werden. Im ersteren Fall wird die Spalte je nach Datenbanksystem Sequenz, Auto-Inkrement oder Identität genannt. Klassische Anwendungen sind hier ETL-Tools für Data-Warehouses.

Bekannte Vertreter von Surrogatschlüsseln, die keine Sequenznummern sind, sind die Universally Unique Identifier (UUIDs) und Globally Unique Identifier (GUIDs).

Vorteile

Die wichtigste Eigenschaft eines Surrogatschlüssels ist, dass er die Referenz auf ein Datenelement vereinfacht. Im Gegensatz zu einem zusammengesetzten Schlüssel muss lediglich ein einzelnes Feld als Fremdschlüssel verwaltet werden.[1]

Ein weiterer Vorteil ist, dass beim Ändern eines Datenobjektes der Wert des Surrogatschlüssels unverändert bleibt, da er keinerlei Beziehung zu den Daten hat. Folglich ist auch eine Änderung des Fremdschlüssels unnötig.[2]

Schließlich ist es in der Praxis oft nicht klar, welche Felder einen sprechenden Schlüssel bilden (oder ein Schlüssel, der ursprünglich eindeutig war, muss aufgrund geänderter Anforderungen später um weitere Felder ergänzt werden. Sobald es z. B. einen Kunden mit gleichem Vornamen, Nachnamen und Geburtstag gibt, muss z. B. die PLZ noch hinzugefügt werden).[3]

Beispiel

In der Mitarbeiter-Datenbank eines Unternehmens A wird die interne Mitarbeiter-Nummer als sprechender Schlüssel gewählt. Später kommen durch einen Zusammenschluss mit einem weiteren Unternehmen B neue Mitarbeiter hinzu. Deren Mitarbeiter-Nummern kollidieren mit Nummern von Mitarbeitern aus A (weil sie in B vor dem Zusammenschluss mit A vergeben wurden). In diesem Falle muss der Schlüssel geändert werden (etwa durch Hinzufügen eines weiteren Feldes für die Herkunft des Mitarbeiters).

Eine spätere Änderung des Schlüssels (also eine Änderung der Liste der Felder) ist aber äußerst aufwändig, weil sie in allen abhängigen Tabellen und in allen Programmen, die eine dieser Tabellen benutzen, nachvollzogen werden muss.

Nachteile

Wird nur der Surrogatschlüssel in der Datenbank hinterlegt, kann es beim Einfügen oder Ändern zu Duplikaten kommen.[4]

Ein weiterer Nachteil ist, dass Surrogatschlüssel ein zusätzliches Feld hinzufügen.[5]

Noch ein Nachteil ist, dass getrennte Datenbanken, wenn sie ähnliche Tabellen verwalten, identische Surrogatschlüssel erzeugen können, wenn keine Vorkehrungen dagegen getroffen werden; bei einem natürlichen Schlüssel würde solch ein doppelter Schlüssel nicht entstehen.[6]

Anwendungen

Surrogatschlüssel spielen bei der Integration von Daten in ein Data-Warehouse eine wichtige Rolle. Hier werden Daten aus operativen Datenbanken extrahiert und in ein Sternschema überführt. Dabei werden die Daten in Fakten und Dimensionen aufgeteilt. Die Faktentabellen enthalten hier oft eine große Anzahl von Fremdschlüsseln, die auf die Dimensionstabellen verweisen. Diese Aufteilung ist ohne Surrogatschlüssel in der Praxis nicht durchführbar.

Literatur

  • Vinek/Rennert/Tjoa: Datenmodellierung – Theorie und Praxis des Datenbankentwurfes Physica-Verlag, 1982, ISBN 3-7908-0225-5

Weblinks

Einzelnachweise

  1. ↑ Surrogat- oder natürlicher Schlüssel: So trifft man die richtige Entscheidung – 2. Der Primärschlüssel sollte so kompakt wie möglich sein. In: ZDNet vom 19. Mai 2011
  2. ↑ Surrogat- oder natürlicher Schlüssel: So trifft man die richtige Entscheidung – 3. Es kann natürliche Schlüssel mit nur einem Feld geben. In: ZDNet vom 19. Mai 2011
  3. ↑ Surrogat- oder natürlicher Schlüssel: So trifft man die richtige Entscheidung – 4. Primärschlüsselwerte sollten stabil sein. In: ZDNet vom 19. Mai 2011
  4. ↑ Surrogat- oder natürlicher Schlüssel: So trifft man die richtige Entscheidung – 6. Es sind keine doppelten Einträge zulässig. In: ZDNet vom 19. Mai 2011
  5. ↑ Surrogat- oder natürlicher Schlüssel: So trifft man die richtige Entscheidung – 8. Surrogatschlüssel fügen ein unnötiges Feld hinzu. In: ZDNet vom 19. Mai 2011
  6. ↑ Surrogat- oder natürlicher Schlüssel: So trifft man die richtige Entscheidung – 10. Manche Umstände scheinen einen natürlichen Schlüssel zu erfordern In: ZDNet vom 19. Mai 2011