Surrogatschlüssel

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Surrogate Key)
Zur Navigation springen Zur Suche springen

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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

Weblinks[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  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
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Surrogatschlüssel&oldid=193056661“