Tabellen [basics]: Primärschlüsselfelder mit Autowert

Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.

Primärschlüsselfelder Was soll das denn sein Und gibt es dann auch Sekundärschlüsselfelder Die Antworten auf diese Fragen sind existenziell für den Datenbankentwickler, denn sinnvoll gewählte und definierte Primärschlüsselfelder sind die Grundlage für die Arbeit mit den Daten in einer Tabelle. Und es geht noch darüber hinaus: Auch für das Herstellen von Verknüpfungen zwischen den Datensätzen zweier Tabellen sind die Primärschlüssel unerlässlich. Warum das der Fall ist, wie Du ein Primärschlüsselfeld definierst und was dabei zu beachten ist, erläutern wir hier.

Eindeutige Identifizierung

Was im echten Leben gilt, hat auch in der Datenbankwelt Gültigkeit: Viele Dinge müssen eindeutig identifizierbar sein. Und auch wenn beispielsweise Menschen ziemlich einzigartig sind, besteht der Gesetzgeber in den meisten Ländern auf einer eindeutigen Identifizierungsmöglichkeit. In Deutschland gibt es dazu beispielsweise Sozialversicherungsnummern oder Personalausweisnummern.

Der Hintergrund: Wenn ein Mensch eine eindeutige Nummer hat, dann kann man auch die Daten, die zu diesem Menschen an verschiedenen Stellen gespeichert sind, eindeutig zuordnen. Zum Beispiel liegen hinter der Sozialversicherungsnummer die Daten für die Rente.

So ähnlich läuft es auch in der Tabelle einer Datenbank ab. Auch wenn die Daten von Kunden je nach der Menge der erhobenen Eigenschaften möglicherweise eindeutig sind, wenn man sie als Gesamtheit betrachtet (also beispielsweise als Vorname plus Nachname plus Adresse plus Geburtsdatum und so weiter), ist dieses zusammengefasste eindeutige Merkmal doch hier und da etwas unhandlich.

Zum Beispiel dann, wenn es darum geht, einen bestimmten Kunden schnell zu identifizieren – etwa zum Zwecke des Aufrufs in der Kundendatenbank, wenn der Kunde sich telefonisch meldet und eine Frage zu einer Bestellung hat. Deshalb fragen Telekom und Co. vor dem eigentlichen Kontakt mit einem menschlichen Mitarbeiter auch immer schon automatisch die Kundennummer ab – so hat der Mitarbeiter im Optimalfall schon die Maske mit den jeweiligen Kundendaten geöffnet, wenn das eigentliche Gespräch beginnt. Okay, in der Realität fragt der Kundenberater diese Daten trotzdem immer nochmal ab, aber das ist ein anderes Thema …

Eine eindeutige Identifizierung wie etwa eine Kundennummer ist auf jeden Fall hilfreich, schnell den richtigen Kunden zu finden.

Eindeutige Zuordnung

Ein weiterer Aspekt, für den eine eindeutige Identifizierung notwendig und sinnvoll ist, tritt dann eher in der Datenbankwelt auf: Hier treffen wir auf sogenannte Beziehungen zwischen den Datensätzen zweier Tabellen. Stellen wir uns also vor, dass wir nicht mehr mit dem Kundenberater der Telekom telefonieren und wechseln in die Welt der Projekte. Hier ruft der Kunde beim Projektmanager an und möchte mit diesem ein Projekt besprechen – beispielsweise zum Starten des Projekts oder auch während der Durchführung.

Der Projektmanager holt sich dann über die Eingabemaske seiner Projektverwaltung erst einmal den Kundendatensatz hervor (da Projektmanager üblicherweise keine Kundenanzahl haben wie ein Kommunikationsunternehmen, dürfte der Firmen- oder Nachname des Kunden reichen, um diesen zu finden). Die Maske mit dem Kundendatensatz zeigt direkt alle Projekte in der Übersicht an, die mit diesem Kunden bisher durchgeführt wurden oder noch laufen.

Und genau dort wird ein eindeutiges Feld zur Identifikation interessant: Wenn wir schon die Kundendaten und die Projektdaten jeweils in eigene Tabellen geschrieben haben, dann wollen wir auch die Zuordnung von Projekten zu Kunden auf möglichst effiziente Weise realisieren. Und der effizienteste Weg ist, der Kundentabelle ein Feld mit einem eindeutigen Identifizierer hinzuzufügen, das wir in der Projekttabelle in einem weiteren Feld eintragen, mit dem wir den Kunden für dieses Projekt festlegen.

Primär- und Sekundärschlüssel

Dieses Feld in der Kundentabelle nennen wir schließlich Primärschlüsselfeld. Primär deshalb, weil es noch andere Schlüsselfelder gibt – und zwar Sekundärschlüsselfelder. Dies sind schlicht Schlüsselfelder, die zum schnelleren Durchsuchen der Datensätze einer Tabelle nach anderen Feldern als dem Primärschlüsselfeld gedacht sind.

Datentyp eines Primärschüsselfeldes

Das Anlegen eines Primärschlüsselfeldes schauen wir uns am Beispiel der Kundentabelle an. Üblicherweise starten wir das Erstellen einer Tabelle mit dem Hinzufügen des Primärschlüsselfeldes. Aber welchen Datentyp sollte das Primärschlüsselfeld haben

Grundsätzlich kann man Felder fast aller Datentypen zu Primärschlüsselfeldern machen. Wir könnten beispielsweise ein Textfeld als Primärschlüsselfeld verwenden. Vielleicht denkst Du, dass dies nötig ist, weil Du eine neue Kundendatenbank programmierst und in diese Daten einer alten Datenbank importieren musst, die eine aus Buchstaben und Zahlen bestehende Kundennummer enthält.

In diesem Fall könntest Du, nachdem Du die benötigten Felder im Tabellenentwurf angelegt hast, einfach das Feld Kundennummer als Primärschlüsselfeld festlegen. Dies erfordert nur wenig Aufwand: Du markierst das Feld in der Entwurfsansicht und betätigst dann den Befehl Primärschlüssel im Ribbon (siehe Bild 1).

Einstellen eines Feldes als Primärschlüsselfeld

Bild 1: Einstellen eines Feldes als Primärschlüsselfeld

Vielleicht ist der passende Ribbonbefehl gerade nicht sichtbar – dann kannst Du auch mit der rechten Maustaste in die Zeile mit dem Feld Kundennummer klicken und den Befehl Primärschlüssel aus dem Kontextmenü auswählen (siehe Bild 2).

Alternative zum Festlegen des Primärschlüsselfelds

Bild 2: Alternative zum Festlegen des Primärschlüsselfelds

Woher wissen wir nun, ob ein Feld einen Primärschlüssel enthält Das sehen wir zuerst im Entwurf. Nach dem Hinzufügen des Primärschlüssels wird zuallererst ein entsprechendes Symbol im linken Bereich der Felddefinition in der Entwurfsansicht angezeigt. Außerdem werden die Schaltflächen zum Hinzufügen eines Primärschlüssels im Ribbon und im Kontextmenü hervorgehoben, sodass leicht zu erkennen ist, dass hier bereits ein Primärschlüssel definiert wurde (siehe Bild 3).

Merkmale für das Vorhandensein des Primärschlüssels

Bild 3: Merkmale für das Vorhandensein des Primärschlüssels

Primärschlüsselfelder erfordern eindeutige Werte

Damit ist der Primärschlüssel allerdings noch nicht wirklich angelegt, sondern Du hast damit lediglich angegeben, dass dieser beim nächsten Speichern des Entwurfs der Tabelle hinzugefügt werden soll. Es steht nämlich noch eine Prüfung aus. Eine der wichtigsten Aufgaben eines Primärschlüsselfeldes ist nämlich, die Eindeutigkeit der im betroffenen Feld enthaltenen Datensätze sicherzustellen. Das bedeutet, dass in diesem Feld kein Wert doppelt vorkommen darf. Wenn wir nun einen Primärschlüssel für dieses Feld definieren und diesen speichern wollen, führt Access zunächst eine Prüfung durch, ob diese Voraussetzung erfüllt ist. Was bringt ein Primärschlüsselfeld, wenn von Anfang an die wichtigste Eigenschaft nicht erfüllt ist

Wenn das Feld Kundennummer nun mindestens einen Wert zwei Mal enthält, können wir den Entwurf mit dem hinzugefügten Primärschlüssel gar nicht erst speichern, sondern erhalten eine Fehlermeldung mit folgendem Text:

Die von Ihnen gewünschten Änderungen an der Tabelle konnten nicht vorgenommen werden, da der Index, der Primärschlüssel oder die Beziehung mehr vorkommende Werte enthalten würde. Ändern Sie die Daten in den Feldern, die gleiche Daten enthalten, entfernen Sie den Index, oder definieren Sie den Index neu, damit doppelte Einträge möglich sind, und versuchen Sie es erneut.

Die Meldung ist etwas irreführend, denn zumindest das Ändern der Daten ist ohne vorheriges Entfernen des Primärschlüssels nicht möglich – die Tabelle lässt sich ja nicht speichern und ohne Speichern können wir nicht in die Datenblattansicht wechseln, um die Daten anzupassen. Die Vorgehensweise wäre also in diesem Fall, zuerst den Primärschlüssel wieder vom Feld Kundennummer zu entfernen, die Tabelle zu speichern, in die Datenblattansicht zu wechseln und dann eventuelle Dubletten zu entfernen beziehungsweise umzuändern.

Primärschlüssel entfernen

Um einen Primärschlüssel wieder zu entfernen, gehst Du genauso vor wie beim Anlegen: Du markierst das Feld mit dem zu entfernenden Primärschüssel und betätigst den Befehl Primärschlüssel entweder über das Ribbon oder das Kontextmenü.

Optimaler Datentyp für Primärschlüsselfelder: Zahl

Computer arbeiten am liebsten und schnellsten mit Zahlen. Wenn schon nicht nur 0 und 1, dann doch wenigstens mit Zahlen, aber nicht mit Buchstaben. Das gilt auch für das Auffinden von Datensätzen nach verschiedenen Kriterien. Die Suche nach Werten in Zahlenfeldern ist immer schneller als die nach Texten. Und es gibt mehrere Fälle, wo sich dies speziell auf die eindeutigen Identifizierer von Datensätzen auswirkt. Einer davon sind Beziehungen, über die wir in verschiedenen anderen Artikeln sprechen – zum Beispiel in Tabellen [basics]: 1:n-Beziehungen (www.access-basics.de/571).

Wenn wir nämlich eine Beziehung zwischen zwei Tabellen anlegen, dann bedeutet das, dass wir in der einen Tabelle ein Feld definieren, das genau die Primärschlüsselwerte der Datensätze der anderen Tabelle aufnimmt, um jeweils einen Datensatz der beiden Tabellen zu verknüpfen.

Nun sucht man beispielsweise nach den Projekten eines Kunden. Wenn nun die Projektetabelle ein Primärschlüsselfeld aufweist, das komplizierte, aus Buchstaben und Zahlen bestehende Projektnummern enthält, dann dauert die Suche nach den Projekten eines Kunden viel länger, als wenn die Projekte einen eindeutigen Identifizierer hätten, der nur aus einer Zahl besteht.

Das Ziel sollte also sein, für eindeutige Identifizierung eines Datensatzes ein Zahlenfeld zu nutzen. Das ist beim Neuanlegen einer Datenbank leicht zu realisieren. Aber was, wenn Du bestehende Daten, beispielsweise aus einer Excel-Tabelle, übernehmen musst

Auch das ist kein Problem: Dann ist es immer noch sinnvoller, neben den bestehenden Projektnummern (oder auch Kundennummern) zusätzlich ein Primärschlüsselfeld auf Basis eines neuen Zahlenfeldes zu erstellen.

Zusätzliches Feld als Primärschlüsselfeld

Angenommen also, wir haben die Daten aus einer Excel-Tabelle in die Tabelle unserer neuen Datenbank übernommen und wollen dieser neben der dort gepflegten Kundennummer noch ein Feld hinzufügen, das zur eindeutigen Identifizierung der Datensätze und außerdem als Primärschlüsselfeld zur Verknüpfung mit anderen Tabellen dienen soll.

Dann ist der erste Schritt, ein neues Feld vor dem bestehenden Feld Kundennummer einzufügen. Das gelingt am schnellsten durch Markieren der Zeile mit dem Feld Kundennummer und Auswahl des Kontextmenübefehls Zeilen einfügen (siehe Bild 4).

Einfügen eines neuen Feldes

Bild 4: Einfügen eines neuen Feldes

Das neue Feld nennen wir KundeID und stellen den Felddatentyp Zahl ein. Schließlich haben wir oben geschrieben, dass Zahlenfelder besser zum schnellen Suchen als Textfelder sind.

Primärschlüsselfelder dürfen nicht leer sein

Wenn wir nun allerdings versuchen, den Entwurf der bereits mit Daten gefüllten Tabelle zu speichern, erhalten wir eine Fehlermeldung wie in Bild 5.

Hinzufügen eines zusätzlichen Feldes als Primärschlüsselfeld

Bild 5: Hinzufügen eines zusätzlichen Feldes als Primärschlüsselfeld

Damit lernen wir neben der Regel zur Eindeutigkeit der enthaltenen Daten gleich die zweite Regel für Primärschlüsselfelder kennen: Primärschüsselfelder müssen zwingend einen Wert enthalten.

Wir haben allerdings in diesem Beispiel das Feld KundeID zu einer Tabelle hinzugefügt, die bereits Datensätze enthält. Dieses Feld wird natürlich nicht automatisch für die Datensätze der Tabelle mit Werten gefüllt. Das sehen wir, wenn wir den Primärschlüssel vorerst wieder entfernen (sonst können wir den Entwurf nicht speichern) und zur Datenblattansicht der Tabelle wechseln. Das Feld KundeID ist für alle Datensätze leer (siehe Bild 6). Logisch: Woher soll Access auch wissen, welche Werte dieses Feld für die verschiedenen Datensätze enthalten soll Aber es gibt auch für diesen Fall eine Lösung.

Das neue, als Primärschlüsselfeld gedachte Feld ist leer

Bild 6: Das neue, als Primärschlüsselfeld gedachte Feld ist leer

Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...

Testzugang

eine Woche kostenlosen Zugriff auf diesen und mehr als 1.000 weitere Artikel

diesen und alle anderen Artikel mit dem Jahresabo

Schreibe einen Kommentar