Navi: Hauptseite→Lektionen→Lernfeld 6→Datenbank-Design 7: Primärschlüssel

Datenbank-Design 7: Primärschlüssel

In einer Excel-Tabelle ist jedes Feld eindeutig identifizierbar, indem man einfach die Koordinaten aus Spalte (in Buchstaben) und Zeile (in Zahlen) angibt, ähnlich wie bei den Koordinaten auf einem Schachfeld.

Im nachfolgenden Beispiel sieht man die Jahressumme in einem Feld, das man über Spalte und Zeile eindeutig als C14 identifizieren kann:

In Datenbanktabellen sieht das anders aus. Hier noch einmal die Access-Tabelle, die in Teil 2 bereits gezeigt wurde:

Dass es hier auf den ersten Blick kein solches Koordinatensystem gibt, täuscht jedoch.

Eindeutigkeit der Spalte

Jede Spalte einer Datenbanktabelle lässt sich eindeutig identifizieren, da der Attributname (die Überschrift einer Spalte) eindeutig sein muss. Anders als in Excel darf keine Spaltenüberschrift mehrfach verwendet werden, beispielsweise der Spaltenname "Wohnort". Bei einem Zweitwohnsitz müsste man sich für dieses Attribut eine andere Bezeichnung ausdenken.

Diese Bedingung wird in fast allen Datenbanksystemen automatisch überwacht. Der Versuch einer Mehrfachbenutzung wird mit einer Fehlermeldung quittiert.

Damit ist schon mal ein Teil des Koordinatensystems vorhanden.

Eindeutigkeit der Zeile

Jetzt fehlt uns noch die Eindeutigkeit der Zeile. Da es in einer Datenbanktabelle keine Zeilennummern wie in Excel gibt, müssen wir etwas von Hand hinzufügen. Es muss ein Feld sein, dessen Inhalt eindeutig ist und auch bleiben wird.

So etwas nennt sich im Datenbank-Design "Primärschlüsselfeld" oder "Primärschlüssel" (abgekürzt "PS", als Symbol auch durch einen Schlüssel dargestellt).

Für die Abschlussprüfung der IHK sollte man diesen Begriff auch in englischer Sprache kennen. Dort lautet er "Primary Key" (abgekürzt "PK").

Man kann selbst bestimmen, welche Spalte zum Primärschlüssel werden soll. Nur sollte man dabei zwei wichtige Punkte beachten:

1. In einem Primärschlüssel darf es keine Nullwerte (leere Felder) geben.
    
   Beispiel: Ein Feld mit dem Namen "email" eignet sich nicht, da es Personen ohne E-Mail-Adresse geben kann. Und leere Felder sind in einem Primärschlüsselfeld nicht erlaubt.
    
2. Eine Primärschlüsselspalte muss eindeutige Inhalte haben, kein Inhalt darf mehrfach vorkommen.
    
   Beispiel: Die Spalte "nachname" eignet sich nicht, da beispielsweise der Nachname "Meier" in einer Adresstabelle mehrfach vorkommen kann. Der Inhalt wäre dann nicht mehr eindeutig.

Man könnte sich ein anderes Feld mit eindeutigen Inhalten heraussuchen, doch birgt dies immer die Gefahr, dass es in dieser Spalte später einmal Inhalte geben könnte, die die Eindeutigkeit wieder aufheben.

Beispiel: Stellen Sie sich eine Fahrzeugliste beim Straßenverkehrsamt vor. Dort sind sämtliche KFZ-Kennzeichen gespeichert. Ein Kennzeichen ist eindeutig und sollte immer nur ein einziges Mal vorkommen. Der Halter eines Fahrzeuges lässt sich darüber eindeutig herausfinden, daher könnten wir doch eigentlich aus dem Kennzeichenfeld einen Primärschlüssel machen.

Aber was würde passieren, wenn ein Fahrzeug verkauft wird und der neue Besitzer das übernommene Kennzeichen behalten will? Dann ließe sich der aktuelle Halter nur noch über eine Kombination mit dem Datum herausfinden.

Wir sehen jetzt, dass auch ein scheinbar sicheres Feld irgendwann einmal Probleme bereiten kann, wenn man es zum Primärschlüssel macht.

Kombinierte Primärschlüssel

Es gibt aber noch eine andere Möglichkeit. In Access lässt sich ein Primärschlüssel auch aus mehreren Feldern kombinieren, beispielsweise aus den Feldern "Vorname" und "Nachname".

Hätten wir einen Primärschlüssel aus Vor- und Nachnamen, so dürfte jeder Vorname (z.B. "Claire") mehrfach vorkommen. Auch jeder Nachname (z.B. "Grube") dürfte jetzt mehrfach vorkommen. Lediglich die Kombination ("Claire Grube") müsste einmalig sein.

Aber was wäre, wenn es mehrere Personen mit diesem Namen gäbe? Eine kurze Suche bei Google würde diesen Verdacht ziemlich sicher bestätigen. Was machen wir dann? Natürlich könnte der Primärschlüssel um beliebig viele Felder erweitert werden. Es wäre vorstellbar, dass er aus dem Vornamen, dem Nachnamen, der Straße, der Postleitzahl, dem Ort und vielleicht sogar aus dem Geburtsdatum zusammengesetzt wird.

Trotz dieser Kombination kann es passieren, dass zwei Personen mit identischem Namen existieren, die vielleicht sogar ein identisches Geburtsdatum haben und zufälligerweise auch noch im selben Haus wohnen.

Unglaublich? Vielleicht. Aber es ist nicht unmöglich. Und was passiert dann?

Ein Fall von Dozentenredundanz

Damit es gar nicht erst zu einem solchen Problem kommt, sollte man für einen Primärschlüssel immer eine weitere Spalte zur Tabelle hinzufügen. Diese wird in der Regel "ID" (für "Identification" oder "Index") genannt. Dieser Name ist aber nicht bindend. Wichtig ist nur die Eindeutigkeit der Inhalte.

Wir kennen solche Felder aus allen Bereichen des Alltags. Beispielsweise tragen die Rechnungen, die uns der Postbote freundlicherweise in den Postkasten steckt, eine eindeutige Identifikationsnummer. Es handelt sich um die Rechnungsnummer, die bei der Überweisung mit angegeben werden sollte. Über diese Nummer kann jede Rechnung eindeutig identifiziert werden.

Aber auch eine Artikelnummer, eine Auftragsnummer, eine Kursnummer, eine Mitarbeiternummer und selbst die Personalausweisnummer sind nichts anderes als Primärschlüssel in Datenbanktabellen.

"AutoWert"

MS Access bietet übrigens einen besonderen Datentyp für Primärschlüsselfelder an. Dieser nennt sich "AutoWert" und sorgt dafür, dass jeder neue Datensatz automatisch fortlaufend durchnummeriert wird.

Und was noch wichtiger ist: Access sorgt dafür, dass jede Nummer nur einmal und nach einer Löschung nie wieder erneut vergeben wird.

Die erneute Verwendung einer einmal gelöschten Indexnummer wäre schlimm. Man stelle sich nur mal vor, ein Vereinsmitglied müsste noch eine Rechnung begleichen, ist aber aus dem Verein ausgetreten. Die Mitgliedsnummer wäre jetzt frei und könnte nach der Löschung für ein neu eingetretenes Mitglied vergeben werden. Dummerweise verschickt der Kassierer des Vereins eine Zahlungserinnerung an das Mitglied, dessen Mitgliedsnummer er zu kennen glaubt. Dann würde das neue Mitglied ein unschönes Begrüßungsschreiben erhalten ...