Diskussion:Surrogatschlüssel

Was sind den nun genau Surrogatschlüssel, und was dann die Nachteile?

Bei nochmaligem Lesen muss ich aber auch sagen das nicht klar wird, was eigentlich ein Surrogatschlüssel ist. Sind Schlüssel die vom Fachanwender manuell über die Pflege von STammdatentabellen vergeben werden auch Surrogatschlüssel,wenn diese keinen Bezug auf Objektattribute nehmen, sondern z.B. die Kostenstellen durch 10 stellige Nummern eindeutig kennzeichnen?

Wir ein Surrogatschlüssel immer vom Programm vergeben oder können Surrogatschlüssel auch extern von den Anwendern vergeben werden? Für mich bringt der Artikel auf diese Frage keine Klarheit.

So wie Surrogatschlüssel im Artikel definiert sind, müssen diese ja nicht vom Programm als GUID o.ä generiert und vergeben werden. Meine unten geschilderten Nachteile beziehen sich aber auf genau diesen Umstand, der z.B bei EP-SYstemen dann zu den unten genannten Nachteilen und Folgeproblemen führt. Ich habe also zwei Anliegen:

• bitte hier in Diskussion u/o Artikel die Definition von Surrogatschlüssel klären.

abhängig vom dann geklärten Wording möchte ich dann untengenannte Nachteile hier in der Diskussion klären und danach in den Artikel einarbeiten.

Den nachfolgenden Absatz den ich im Artikel eingefügt hatte wurde von User:Sparti m.E. nicht zutreffenden, bzw. nicht hinlänglich verständlichen Begründung wieder aus dem Artikel rausgelöscht und ich stelle den Passus hier mal zur Diskussion.

Nachteile von Surrogatschlüsseln

In geschäftsdatenorientierten Anwendungen, beispielsweise ERP-Systeme werden die Schlüssel der Geschäftsobjekte häufig bereits von den Fachbereichen mit eindeutigen Objektschlüsseln bezeichnet, wie Kostenstellennummern, Sachkontennummern, Kostenartennummern usw. Bei Berichtsauswertungen auf Bewegungsdaten, welche diese Objektkennungen als Attribute und Fremdschlüssel als Kontierungsmerkmale enthalten, muss in aller Regel nach diesen fachlichen Schlüsseln, die oft auch als zusammengesetzte Schlüssel hierarchische Zusammenhänge abbilden selektiert, gruppiert und summiert werden. Wenn diese Schlüssel als Surrogatschlüssel abgebildet werden, muss bei jeder Selektion vorgängig auf den Stammdatentabellen der entsprechenden Geschäftsobjekten selektiert werden oder aber es müssen mittels SQL-JOINS alle beteiligten Stammdatentabellen in die Abfrage hinzugezogen werden. Dadurch steigt die Anzahl der notwendigen SQL-Abfragen für eine Auswertung oder die Anzahl und Breite der Jointabellen. Dies beeinflusst die Performance bzw. Ausführungszeit für die Abfragen in negativer Weise. Aus diesen Ueberlegungen und aus Erfahrungen aus der Implementierung von grossen Geschäftsdatendaten, empfielt sich die Verwendung Primärschlüssel, welche vom Fach vorgegeben werden und über deren entsprechenden objektbezogenen Fachschlüssel in den STammdaten auch aufgebaut und konsistent gepflegt werden.

Gruss, --ollio 01:07, 2. Aug. 2008 (CEST)

Hallo Ollio,

Ich sehe im wesentlichen zwei Gruende, warum die oben beschriebenen Nachteile nicht mit Surrogatschluesseln zu tun haben:

1. Ein Surrogatschluessel wird nicht von den Daten abgeleitet, die er beschreibt. In dem Augenblick, wo eine Instanz ausserhalb der Datenbank dem Schluessel eine Bedeutung beimisst gibt es also einen semantischen Zusammenhang zwischen den Stammdaten und dem Schluessel. Somit haben wir keinen Surrogatschluessel mehr.

2. Etwas weniger formal, dafuer sicherlich nachvollziehbarer ist aber, dass Dein Problem schlicht eine Folge eines Normalisierungsschrittes ist. In eurem Fall habt ihr Stammdaten von den Transaktionsdaten getrennt, daher die zusaetzlichen Joins. Aufgabe des Surrogatschluessel ist es aber nicht diesen Join zu erzwingen sondern im Gegenteil, die Folgen dieser Trennung zu lindern. Er soll die Joinanfragen von natuerlichen Schluesseln unabhaengig machen. Damit die SQL Statements effizienter werden und weil man nun die Stammdaten aendern koennte (zB neue Kostenstellennummern), ohne die Fremdschluessel anpassen zu muessen. Das heisst der Surrogatschluessel waere in diesem Fall noch ein weiteres Attribut, das nur der Datenbank fuer eine schnelle Zuordnung dient. -- Viele Gruesse sparti 10:07, 2. Aug. 2008 (CEST)

Hallo Sparti, danke für die Klärung bezüglich der Definition von Surrogatschluessel, wie oben von Dir unter Pkt. 1 detailliert. Das kann man im Artikel auch noch präzisieren. Die Mindestanzahl der Joins für eine Berichtsabfrage ist durch das normalisierte Datenmodell bestimmt und normalisierte Daten sind in aller Regel durchaus effizient selektierbar. Das Problem mit den Surrogatschlüssel ist, dass bei einer mit fachlichen Schlüsselnparameter abgesetzen Reportabfrage entwender die Anzahl der notwendigen JOINS oder aber die Anzahl Datenbankzugriffe verdoppelt wird.

Ausgehend von dieser Begriffsdefinition sehe ich somit sehr wohl, und äusserst schwere Nachteile von Datenmodellen, welche die semantischen Objekte konsequent mittels Surrogatschlüssel unkenntlich machen. Du kannst davon ausgehen, dass mein skiziertes ERP-Datenmodell in der dritten Normalform vorliegt und dass alle Entitäten mit semantisch bedeutsamen, d.h. auch ausserhalb der DB dem Fachanwender geläufigen primären Objektschlüsseln modelliert sind. Folgendes ganz allgemeine und alltägliche Anwendungsbeispiel soll nun die gravierenden Nachteile von Surrogatschlüsseln aufzeigen. Wenn aus 2 Mio Bewegungsdaten [Bsp: Buchungen mit PK Belegnummer, und Bezug zu Buchungskreis und buchungskreisbezogener Kostenstelle], diejenigen selektiert werden sollen, die Tochterunternehmen X betreffen und Kostenstelle Y, und X und Y als Selektionskriterien vom Anwender beim Berichtsaufruf als Parameter vorgegeben werden so sind mit einer Datenmodellierung über Surrogatschlüssel

• die 2 Mio Bewegungsdaten mit dem Unternehmesstamm und dem Kostenstellenstamm gefiltert auf dem Unternehmen X zu selektieren, es gibt also drei zusätzliche Joins und das sit dann ziemlich ineffizient. U.u. werden gar die Bewegungsdaten alle selektiert und über die Surrogatschlüssel mit den Stammdatentabellen gejoint und erst dann nach den Attributen der natürlichen Schlüssel Ug=X und Kst=Y selektiert, ein graus.
• ggf. besser ist dann auf Kostenstellenstamm die Surrogatschlüssel für Kostenstelle Y bestimmen, auf Unternehmensstamm den Surrogatschlüssel

das Ug X zu selektieren, worauf dann mit den so aus Uebersetzung gewonnenen Surrogatschlüsseln mit einfachem SELECT und WHERE-Clause auf die Bewegungsdaten zuzugreifen. Normalerweise bleiben bei komplexen Geschäftsprozessauswertungen dann aber nicht zwei sondern 10-20 solche Stammdatenabfragen notwendig - zusätzlich e Entitäten wie Währungscode, etc, etc. Also löst die einfache Berichtsabfrage 10-20 Stammdatenabfragen aus, und dann erst die Hauptabfrage auf den Bewegungsdaten. Dieser Mehraufwand belastet den Datenbankserver, insbesondere fallen fallen im Tagesgeschäft zig solche Abfragen an und da leitet nun mal ein ERP-System welches die Anwendungslogik konsequent mittels Surrogatschlüssel abstrahiert und entkoppelt ziemlich arg. Zweiter Nachteil: Interaktives Recherches mit SQL wird für einen Fachinformatiker damit zum Alptraum. Wer macht schon gern 21 SQL-Abfragen, wenns eigentlich auch mit einer einzigen Abfrage gehen würde, wenn nicht eine irrwitzige ERP-Datenbankarchitektur mit Surrogatschlüsseln aufgebaut wurde, bei der jede fachliche Anfrage mit vorgegebenen Selektionsschlüssel zuerst in arbiträre Surrogatschlüssel übersetzt werden muss.

Ich meine das der DB-Architekt welcher eine DB-Datenmodell auf Surrogatschlüsseln fundiert, weil damit alle Abhängigkeiten von der realen Welt vermeintlich für immer behoben sind, und so alle künftigen Migrationen 'ganz einfach' durchzuführen sind, einen folgenschweren Denkfehler gemacht hat. Richtig ist, das eine Datenbank mit semantischen Schlüsseln u.U bei einer Migration umgeschlüsselt werden muss. Solche Migrationsprojekte sind dann auch etwas anspruchsvoll und aufwändig, können aber über weite Strecken vermieden werden, solange die Fachanwender bei der Bildung und Ausgestaltung der semantischen Schlüssel vorausschauend und intelligent vorgehen. Wenn dann mal bei einer Fusion oder Systemumstellung trotzdem migriert werden muss, so sind die Migrationskosten nur ein kleiner Teil im ganzen Kostenblock der Fusionskosten. Dem Argument das Surrogatschlüssel solche Umschlüsselungen vermeiden helfen, greift damit zu kurz weil solche Umschlüsselungen im Betrieb der ERP-Geschäftsdatensysteme kaum mehr als alle 2-10 Jahre auftreten, während die tägliche Umschlüsselungen von fachllch-semantischen Objektschlüsseln (Kontonummern, Kostenstellennummern, Kundennummern, Niederlassungsnummer etc. ein ERP mag tausende solcher fachlichen Entitäten haben) in die datenbankinterne Surrogatschlüsseldarstellung täglich millionenfach zu DB-Zugriffen führt, die einzig und allein quasi einer online-Migration der semantischen Objektschlüssel in die technischen Surrogatschlüssel dient. Aus diesem Grund argumentiere ich dass ein ERP-Datenmodell dass seine Entitäten konsequent mit Surrogatschlüsseln als Primärschlüssel definiert, ein schwerer Designfehler darstellt und eigetlich nur Nachteile aufweist. Sparti, ich bitte Dich die Konsequenzen deiner meiner Sicht doch sehr einseitigen Begeisterung für Surrogatschlüssel nochmals zu überdenken. Weiter meine ich, dass im Artikel sehr wohl auf die NAchteile von Surrogatschlüssel aufmerksam gemacht werden sollte. Wenn Surrogatschlüssel für Datenmodelle von ERP-Systeme nichts taugen, ist allenfalls hervorzuheben, in welchen Anwendungsbereichen sie denn sonst eine Berechtigung hätten. Freundliche Grüsse, ollio 22:01, 2. Aug. 2008 (CEST)

Hallo Ollio,

ich habe noch immer nicht verstanden, warum glaubst, dass man eine Tabelle fuer den Einsatz eines Surrogatschluessels aufteilen sollte. Es ist immernoch umgekehrt: Hat meine eine Tabelle zerlegt, kann ein Surrogatschluessel helfen, die negativen Folgen zu lindern. Das hat auch nichts mit Begeisterung zu tun, sondern ist reine Mathematik. Statt einem Join ueber 2 oder mehr natuerliche Schluesselattribute wird ein einzelner Surrogatschluessel eingefuehrt. Es bleibt aber vorher wie nachher bei genau einem Join. Zusaetzlich zur hoeheren Effizienz, sichert man den Join gegen Aenderungen der natuerlichen Schluessel ab. Oftmals ist das aber nur ein praktischer Nebeneffekt.

Einfaches Beispiel mit einer Entitaet Anschriften:

Anschriften: Vorname, Name, Strasse, Ort

Da eine Person mehrer Anschriften haben kann, wird die Tabelle in Personen und Anschriften Zerlegt:

Anschriften: Vorname, Name, Strasse, Ort (Vorname, Name -> Personen.Vorname, Personen.Name)

Personen: Vorname, Name

So, Vorname und Name als Fremdschluessel ist natuerlich quatsch. Und daher fuegt man einen Surrogatschluessel SK ein:

Anschriften: FK, Strasse, Ort (FK->Personen.SK)

Personen  : SK, Name, Vorname

Wenn man mag, kann man nun den SK zur Personal Nummer erklaeren. Dann muss bei einer Aenderung aber die Datenbank migriert werden. Oder man fuegt noch zusaetzlich die Personal Nummer ein:

Anschriften: FK, Strasse, Ort (FK->Personen.SK)

Personen  : SK, PersNr, Name, Vorname

Eine Anfrage nach den Adressen einer Person ist also genau ein Join. Dabei kann man wahlweise ueber die PersNr oder ueber Name, Vorname gehen. Das ist eigentlich recht banal, oder?

-- sparti 02:33, 3. Aug. 2008 (CEST)

Hallo Sparti, Dein Beispiel kann uns der Sache bzw. Problemstellung näher bringen. Deine Ausführungen oben vor dem Beispiel verstehe ich nicht ganz, zeigen aber auch das Du mich bisher noch nicht verstanden hast. Ich versuche das mal hier rum zu erklären:

• Stell Dir doch mal vor, auch die Fachbereiche arbeiten nicht einfach mit Namen und Vornamen der Kunden sondern haben auch eine eindeutige Kundennummer. In aller Regel haben alle ERP-Entitäten wie Kostenstellen, Sachkonten, Unternehmen, Filialen, Geschäftspartner, Mitarbeiter etc eine Nummer. Diese Nummern werden in aller Regel NICHT von der Datenbank als Surrogatschlüssel vorgegeben, sondern die Nummern solcher Entitäten werden von den Fachbereichen vorgeben, wenn diese

Objekte vom Fachbereich in der entsprechenden Stammdatentabelle angelegt werden.

• Wenn nun der DB-Datenmodellierer meint, er müsse hierzu einen Surrogatschlüssel erzeugen, quasi eine GUID-Nummer die dann auch mit grösster Wahrscheinlichkeit weltweit eindeutig ist, weil eine 24-stellige Dezimalzahl repräsentiert, dann
  • wird damit mein oben genanntes Problem erzeugt
  • ist dieser Surrogatschlüssel hoffentlich vom Anwender verborgen, weil völlig unhandlich und unbrauchbar für interaktive Anwendung, ineffiziente Tipparbeit, Memorisierbarkeit etc.~
  • In Berichtsaufrufen die Aufrufparameter für die Selektion oder Auswahl der Berichtsobjekte wie Mitarbeiternummer, Kostenstelle etc. werden dann natürlich auf die fachlichen Schlüssel vergeben.

Kannst Du vor diesem Hintergrund die Problemstellung einer Lösung mit Surrogatschlüssel und die daraus entstehenden Nachteile allenfalls erfassen? Das Problem besteht auf den Punkt gebracht darin, wer die Schlüsselbildungskompetenz hat. Soll dies das Fachbereihc im Unternehmen sein oder der DB-Techniker? Indem sich der DB-Techniker anmasst die Objektschlüssel von STammdaten per Programmlogik automatisiert zu vergeben, entstehen die von mir genannten Nachteile in der Arbeit mit Surrogatschlüsseln. Für die Codierung von Stammdatenobjekten, also für die Codierung aller Strukturdaten des Unternehmens sollten deshalb keine Surrogatschlüssel verwendet werden, sondern der Fachbereich ist anzuhalten, diese Daten inklusive deren konsistente und eindeutigen Fachschlüssel anzulegen in entsprechenden Stammdatentabellen. Diese Fachschlüssel sollten dann auch als Primär- und Fremdschlüssel in allen Datenrelationen verwendet werden. Dieser Einwand betrifft vor alle die Stammdaten und weniger die Bewegungsdaten, wo transaktionsorientierte Entitäten mit Belegnummern, Transaktionsnummern durchaus mit intern generierten Nummern also Surrogatschlüssel durchcodiert werden können. Gruss --ollio 11:56, 4. Aug. 2008 (CEST)

Hallo Ollio,

also gut, wenn ich dich jetzt richtig verstanden habe, dann möchtest du den Join zwischen Stammdatentabelle und anderen Tabellen einsparen indem du direkt auf den Fachschlüssel gehst. Allerdings wundert es mich, daß du diesen Join nicht trotzdem machen musst, um an einige wichtigen Daten in der Stammdatentabelle zu gelangen und wie du oben bereits geschrieben hast ist das Joinen von normalisierten Tabellen in der Regel effizient durchführbar. Und da Surrogatschlüssel, Fachschlüssel und natürliche Schlüssel eine friedliche Koexistenz haben können ist mir der Nachteil noch immer nicht klar.

Vielleicht hilft es, wenn wir uns zu einem Chat auf irc://irc.freenode.net/wikipedia-de-informatik treffen. Das ist vielleicht etwas effektiver, als die Diskussion hier. -- sparti 13:06, 4. Aug. 2008 (CEST)

Revert - Einseitigkeit, Unverständis

Hallo Ollio,

sorry aber das doch vollkommen einseitig. Ein Surrogatschlussel ist ein Datenbank internes Konzept. Dass du das staendig mit Fachkonzepten vermengen willst ist schlicht am Thema vorbei. Bitte akzeptiere doch, dass es nicht entweder oder gibt. Insbesondere gibt es jede Menge Datenbanken ausserhalb wirtschaftswissenschaftlicher Problemstellungen. Deine Aenderungen ignorieren diesen Umstand vollstaendig.

Ausserdem ist ein Satz wie "Surrogatschlüssel werden häufig dort als primäre Identifikationsschlüssel eingesetzt, wo durch die Fachbereiche keine solchen eindeutigen als Primärschlüssel geeignenten Kennzeichner vorgegeben werden. Dies ist z.B bei Belegnummern oder Auftragsnummern der Fall." nicht nur unverstaendlich sondern ohne Beleg voellig unakzeptabel um nicht zu sagen NPOV.

Eine Abgrenzung zwischen Surrogat und Fachschlussel ist unnoetig, da das eine nichts mit dem anderen zu tun hat. Ein Surrogatschlussel bietet einen alternativen Zugriff auf eine Menge von natuerlichen Schlusselattributen!

Ausserdem zur Aenderunge weiter unten: Surrogatschlussel sollten NIE manuell geschrieben oder gelesen werden. Nochmal es ist ein Datenbank internes Konzept!

Und dass du diesen Satz "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 Attribut als Fremdschlüssel verwaltet werden." ersatzlos gestrichen hast, zeigt mir dass wir hier von voellig verschiedenen Konzepten reden. Vielleicht schaust du dir nochmal en:Surrogate Key an, um zu verstehen worum es hier geht. Gruss -- sparti 00:50, 12. Aug. 2008 (CEST)

Hallo Sparti,

ich würde es begrüssen, wenn Du dich einer fachlichen Diskussion stellen würdest und mit Deinen ständigen einseitig qualifizierten und schwach begründeten Reverts aufhören würdest. Der ganze Artikel Surrogatekey verletzt in der jetzigen Form in verschiedenen Punkt NPOV und strotzt von banalisierenden und tendenziösen und z.T falschen Aussagen. Ich möchte deshalb diesbezügliche Klarstellungen einbringen. Das wir momentan das Heu nicht auf der gleichen Bühne haben, bzw. grundsätzlich verschiedene Schulungen von Datenbankdesign vertreten scheint Dir hoffentlich auch klar geworden sein. Ich bitte Dich deshalb der Diskussion zu stellen entweder hier oder im vorerst mal in Chat. Meine diesbezügliche Chat-Anfrage hat bei Dir ja bisher kein Echo ausgelöst.

Eine Datenbank ist nie Selbstzweck und hat immer einen Fachanwender. Das muss nicht ein betriebswirtschaftlicher Anwender sein, sondern kann auch ein Wissenschaftler sein, der mit Klimadaten arbeitet, oder ein Informatiker der IT-Metricsdaten auswertet. In all diesen Fällen kann sehr wohl zwischen datenbank-technischen, internen Implementierungsdetails unterschieden werden und anwendungsbezogenen, externen Entitäten und Attributen. Primärschlüssel sind meines Erarchtens in beinahe allen Fällen das wesentlichste Attribute, das auch Extern aus fachlicher Sicht relevant ist. Du solltest Dir mal überlegen ob nicht die unkritische Verwendung von Surrogatschlüsseln zu einem autistischen Datenbankdesign führt. Ganz klar fehlt im Artikel auch wer denn in welchen Fällen die Kompetenz zur Primärschlüsselung der Entitäten haben soll. Das ist z.B eine Frage die in jedem Datenbank-Anwendungsmodell diskutiert und begründet werden sollte. Der Artikel geht in keiner Weise auf diese Problemstellungen ein. Sorry, aber wir haben Klärungsbedarf. Gruss --ollio 10:56, 12. Aug. 2008 (CEST)

Soso du findest also deinen Beitrag [1] einseitig, tendenzioes und sogar falsch. Interessant, dabei haette ich diesen Teil weitgehend mitgetragen.

Vielleicht koenntest du mal die Stellen angeben, die einseitig, tendenzioes oder gar falsch sein sollen? Momentan gibt es fuer deine Behauptungen naemlich garkeine Begruendung.

Meiner Ansicht nach ist der Artikel heute auch nicht wertend, denn er beschreibt eine Loesung fuer eine typisches Problem beim Datenbankdesign. Dort steht weder das es die beste noch einzige ist. Was ist daran also wertend??

Und vielleicht muessen wir bereits bei den Termini anfagen uns zu einigen.

Fuer mich ist das was du als Fachschluessel bezeichnest ein natuerlicher Schluessel. Ich habe den anderen Begriff bisher noch nicht gehoert und Google kennt ihn praktisch auch nicht. Ich wuerde es daher bei dem zweiteren belassen. Das ist der allgemein (auch unter nicht wirtschaftswissenschaftlern) anerkannte Begriff.

Was die Frage nach dem Primaerschluessel anbelangt. Ich bezweifle, dass es Anwender gibt, die es interessiert, was das ist, noch wie er entsteht. Ein Anwender hat Anforderungen, wie er in der Datenbank suchen moechte. Wie dieser Suchschluessel heisst ist ihm wurst, hauptsache er kann so arbeiten, wie es fuer ihn am Besten ist. Diese Behauptung ist jetzt vielleicht tendenzioes, aber wohlkaum eine Streitfrage, oder?

Was den Chat anbelangt, habe ich ebenfalls mehrfach erfolglos auf dich gewartet. Vielleicht sollen wir einen konkreten Termin ausmachen (Heute abend 21.00)?

Es waere hilfreich, wenn wir dabei gezielt einige Punkte abklaeren.

1. Termini

2. Auf welche anerkannten Quellen koennen wir uns stuzten?

3. Was unterscheidet unsere UseCases? (Vorallem, warum sind die SKs fuer dich schlecht?)

4. Welche Aspekte im Artikel sind falsch oder zumindest fragwuerdig?

Gruss -- sparti 15:40, 12. Aug. 2008 (CEST)

Kann es sein, das ihr zwei echt an einader vorbei redet?

Ein Surrogate key is ein künstlich eingefügtes Attribut was nur einen zweck erfüllt: Eine Entität über dieses eine Attribut klar und eindeutig bestimmen zu können.
D.h. diese Attribute gehört ganz klar ins Entity-Relationship-Modell.
D.h. @sparti ein Surrogate key is nicht einfach nur ein internes Konzept einer Datenbank sonder findet sich auch schon zu begin der Datenmodellierung, dort kann man schon mit Surrogate keys arbeiten.
Der Datenbank Admin muß das sogar wissen, weil er ja für die generierung dieser Keys verantwortlich ist, weil @Ollio die Keys doch automatisch von der Datenbank erstellt und vergeben werde oder zumindest sollten sie das!
Die ganzen Nummern die @Ollio aufgeführt hat, also sowas wie Kunden-Nr., Personal-Nr, Rechnugs-Nr, Martrikel-Nr usw. sind Surrogate keys: ein Künstlich eingefügtes Attribut zur besserne Verwaltung und bestimmung der Datensätze.
Allerdings merkt man kaum noch das es sich eigentlich um Künstliche Attribut handelt, weil es uns mitlerweile einfach natürlich vorkommt. Natürlich hat eine Kunde eine Kunden-ID so wie ganz natürlich ein Student eine Matrikelnummer hat, wir kennen es neute garnicht anders.
Wie diese Nummern aufegabut sind ist Sache der Spezifikation, die von irgentwem vorgegeben wird. Aber vergeben werde diese Nummern dan hoffentlich automatisch:
D.h. der Datenbankadmin nutzt die vorhanden mechanismen und diese Nummern erstellen zu lassen z.B.: CREATE SEQUENCE kunden_id... und über einen Trigger werden die IDs dann in die Datensäze beim insert eingetragen.
Also @Ollio keiner schaut z.B. nach, welche Kunden-Nr. gerade frei ist und gibt diese dan beim insert an (o.ä.), zumindest hoffe ich das!

Surrogate key als internes Konzept einer Datenbank gibt es aber auch: MongoDB z.B. fügt jedem Eintrag automatisch ein _id:ObjectId Attribut hinzu.
Erst wenn man diese Attribut selber beim Insert setzt tut MongoDB das nicht. (nicht signierter Beitrag von 2001:4DD3:7F05:0:E04B:DA8D:6C92:9C1B (Diskussion) 01:43, 27. Apr. 2021 (CEST))

Belege

Der Artikel sollte mit Belegen ergänzt werden.

Aber umbedingt! Ich finde ZDNet als Quelle absolut unzureichen, zumal dort selbe keine Quellen angegeben sind. Unter Literatur ist ein Buch angegeben, es wurd aber anscheinden nicht benutzt da keine Einzelnachweise daraus entnommen wurden. (nicht signierter Beitrag von 2001:4DD3:7F05:0:E04B:DA8D:6C92:9C1B (Diskussion) 23:41, 26. Apr. 2021 (CEST))

Weiterer Nachteil

Ist nicht ein weiterer Nachteil von Surrogatschlüsseln, dass bei einer Fremdschlüsselreferenzierung zuerst der Surrogatschlüssel, der zu dem zu referenzierenden Tupel gehört, ermittelt werden (und wenn dieser nicht existiert, ein neues Tupel angelegt) muss? Während bei einem "natürlichen" Schlüssel einfach die neuen Tupel einfügen kann, da man ja weiß was man referenziert? Zum Beispiel: a) mit Surrogatschlüssel: Relation A: (a,b,c) Relation B: (c, d, e) Surrogatschlüssel c Bei einem neu einzufügenden Wert für Relation A und B muss in B zuerst gesucht werden, ob dieser eventuell existiert, und diesen dann im einzufügenden Tupel der Relation A referenzieren.

b) ohne Surrogatschlüssel: Relation A: (a,b,d) Relation B: (d, e) natürlicher Primärschlüssel d Hier kann einfach in A und B eingefügt werden; in Relation A wird einfach der bekannte Wert d aus Relation B referenziert. --80.128.220.102 21:16, 23. Mai 2015 (CEST)

Defekter Weblink

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieses Fehlers finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://www.dfpug.de/konf/konf_1997/04_data/d_data/d_data.htm
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Netzwerk-Fehler (7) andere Artikel, gleiche Domainhttp://giftbot.dwl.invalid/http://www.dfpug.de/konf/konf_1997/04_data/d_data/d_data.htm

– GiftBot (Diskussion) 09:55, 23. Dez. 2015 (CET)

Fehler bei Vorteil!

Im Text werden die Attribute Vornamen, Nachnamen und Geburtstag als möglicher Schlüsse betrachtet, das ist aber falsch!
Das Tupel (Vornamen, Nachnamen, Geburtstag) ist kein Schlüssel, nichtmal ein Superschlüssel.
Zwei Personen können die selben Namen haben und am selben Tag geboren sein.
Den Wohnort hinzuzunehmen änder daran nichts, (Vornamen, Nachnamen, Geburtstag, PLZ) ist eben so wenig ein Superschlüssel.
Da die zwei Personen ja im selben Ort wohnen können, sie könnte sogar im selben Haus wohnen.

Das ist leider falsch, besser: nicht ganz richtig. Unterscheiden sollte man den Fall einer Tabelle, so wie sie vorliegt, und einer Tabelle, wie sie aussehen könnte. Unterscheiden sich alle Vornamen, ist sogar der Vorname ein Schlüsselkandidat. Ein Surrogatschlüssel hilft rein gar nicht, erst, wenn er zu einer Personalnummer mit eigenem Attribut erhoben wird.

Schlüsselchaos

Seit Jahrzehnten wurde der Artikel nicht mehr angefasst, weshalb ich ihn ein wenig bereinigte. (nicht signierter Beitrag von Abrev (Diskussion | Beiträge) 19:01, 23. Sep. 2024 (CEST))