{"id":55000585,"date":"2022-06-01T00:00:00","date_gmt":"2022-06-01T00:00:00","guid":{"rendered":"http:\/\/access-basics.de\/585"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Tabellen_basics_Primaerschluesselfelder_mit_Autowert","status":"publish","type":"post","link":"https:\/\/access-basics.de\/index.php\/Tabellen_basics_Primaerschluesselfelder_mit_Autowert.html","title":{"rendered":"Tabellen [basics]: Primärschlüsselfelder mit Autowert"},"content":{"rendered":"

\"\"<\/p>\n

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.<\/p>\n

Eindeutige Identifizierung<\/h2>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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 …<\/p>\n

Eine eindeutige Identifizierung wie etwa eine Kundennummer ist auf jeden Fall hilfreich, schnell den richtigen Kunden zu finden.<\/p>\n

Eindeutige Zuordnung<\/h2>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Primär- und Sekundärschlüssel<\/h2>\n

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.<\/p>\n

Datentyp eines Primärschüsselfeldes<\/h2>\n

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<\/p>\n

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.<\/p>\n

In diesem Fall könntest Du, nachdem Du die benötigten Felder im Tabellenentwurf angelegt hast, einfach das Feld Kundennummer <\/b>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 <\/b>im Ribbon (siehe Bild 1).<\/p>\n

\"Einstellen<\/a><\/p>\n

Bild 1: Einstellen eines Feldes als Primärschlüsselfeld<\/p>\n

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

\"Alternative<\/a><\/p>\n

Bild 2: Alternative zum Festlegen des Primärschlüsselfelds<\/p>\n

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).<\/p>\n

\"Merkmale<\/a><\/p>\n

Bild 3: Merkmale für das Vorhandensein des Primärschlüssels<\/p>\n

Primärschlüsselfelder erfordern eindeutige Werte<\/h2>\n

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<\/p>\n

Wenn das Feld Kundennummer <\/b>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:<\/p>\n

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.<\/pre>\n
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 <\/b>zu entfernen, die Tabelle zu speichern, in die Datenblattansicht zu wechseln und dann eventuelle Dubletten zu entfernen beziehungsweise umzuändern.<\/p>\n
Primärschlüssel entfernen<\/h2>\n
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 <\/b>entweder über das Ribbon oder das Kontextmenü.<\/p>\n
Optimaler Datentyp für Primärschlüsselfelder: Zahl<\/h2>\n
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 <\/b>(www.access-basics.de\/571<\/b>).<\/p>\n
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.<\/p>\n
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.<\/p>\n
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<\/p>\n
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.<\/p>\n
Zusätzliches Feld als Primärschlüsselfeld<\/h2>\n
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.<\/p>\n
Dann ist der erste Schritt, ein neues Feld vor dem bestehenden Feld Kundennummer <\/b>einzufügen. Das gelingt am schnellsten durch Markieren der Zeile mit dem Feld Kundennummer <\/b>und Auswahl des Kontextmenübefehls Zeilen einfügen <\/b>(siehe Bild 4).<\/p>\n
\"Einfügen<\/a><\/p>\n
Bild 4: Einfügen eines neuen Feldes<\/p>\n
Das neue Feld nennen wir KundeID<\/b> und stellen den Felddatentyp Zahl <\/b>ein. Schließlich haben wir oben geschrieben, dass Zahlenfelder besser zum schnellen Suchen als Textfelder sind.<\/p>\n
Primärschlüsselfelder dürfen nicht leer sein<\/h2>\n
Wenn wir nun allerdings versuchen, den Entwurf der bereits mit Daten gefüllten Tabelle zu speichern, erhalten wir eine Fehlermeldung wie in Bild 5.<\/p>\n
\"Hinzufügen<\/a><\/p>\n
Bild 5: Hinzufügen eines zusätzlichen Feldes als Primärschlüsselfeld<\/p>\n
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.<\/p>\n
Wir haben allerdings in diesem Beispiel das Feld KundeID <\/b>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 <\/b>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.<\/p>\n
\"Das<\/a><\/p>\n
Bild 6: Das neue, als Primärschlüsselfeld gedachte Feld ist leer<\/p>\n
Primärschlüsselwerte automatisch generieren<\/h2>\n
Es gibt verschiedene Möglichkeiten, dass die Werte eines Feldes automatisch von Access gefüllt werden. Die eine Möglichkeit ist die Vergabe eines Standardwertes. Wenn es jedoch darum geht, Zahlenwerte für ein Primärschlüsselfeld zu vergeben, ist die Autowert<\/b>-Funktion die zu bevorzugende Variante.<\/p>\n
Neue Werte mit Autowert<\/h2>\n
Die Autowert<\/b>-Funktion ist eigentlich auch eine Funktion, die beim Erstellen eines Datensatzes einen Standardwert vorgibt. Die Funktion lautet: Ermittle den Wert des zuletzt angegebenen Wertes in diesem Feld und zähle Eins dazu. Der Unterschied zu einem Standardwert ist allerdings, dass wir diese Funktion nicht für die Eigenschaft Standardwert <\/b>des Feldes eintragen, sondern dass es einen eigenen Datentyp gibt für Felder, welche diese Funktion nutzen sollen.<\/p>\n
Diesen wählst Du einfach über das Auswahlfeld in der Spalte Felddatentyp <\/b>in der Entwurfsansicht der Tabelle aus (siehe Bild 7).<\/p>\n
\"Festlegen<\/a><\/p>\n
Bild 7: Festlegen des Datentyps auf Autowert<\/p>\n
Wenn wir nun wieder den Primärschlüssel zur Tabelle hinzufügen und den Tabellenentwurf speichern, liefert Access keine Fehlermeldung mehr. Den Grund sehen wir, wenn wir nach dem Speichern zur Datenblattansicht wechseln. Hier sehen wir, dass Access für das Autowertfeld automatisch Werte eingetragen hat (siehe Bild 8). Diese beginnen mit 1 und sind dann durchnummeriert.<\/p>\n
\"Das<\/a><\/p>\n
Bild 8: Das neue Autowert-Feld wurde automatisch mit Daten gefüllt.<\/p>\n
Legen wir einen neuen Datensatz in der Tabelle an, erhält dieser im Autowertfeld automatisch den zuletzt vergebenen Wert plus Eins, in diesem Fall 4<\/b> (siehe Bild 9).<\/p>\n
\"Neue<\/a><\/p>\n
Bild 9: Neue Datensätze erhalten im Autowertfeld normalerweise die nächsthöhere Zahl.<\/p>\n
Primärschlüsselfeld plus Autowert in einer neuen Tabelle<\/h2>\n
Wenn Du eine neue Tabelle anlegst und dort direkt ein Primärschlüsselfeld mit dem Datentyp Autowert <\/b>hinzufügst, ist der Vorgang noch einfacher. Ist die Tabelle noch leer, müssen beispielsweise keine Prüfungen erfolgen, ob das Primärschlüsselfeld bereits für alle Datensätze gefüllt ist. Das Feld wird dann für den ersten Datensatz mit dem Wert 1 <\/b>gefüllt und für alle folgenden dann nach der oben erwähnten Vorgehensweise.<\/p>\n
Autowerte mit Lücken<\/h2>\n
Die Autowert<\/b>-Funktion garantiert übrigens keine lückenlose Durchnummerierung von Datensätzen im Primärschlüsselfeld. Wir haben weiter oben geschrieben, dass der Autowert den Wert liefert, welcher der zuletzt vergebenen Zahl plus Eins entspricht.<\/p>\n
Das bedeutet:<\/p>\n