CLS: Tipps & Tricks: Access-Tabellen



Tipps & Tricks: Access-Tabellen

Auf dieser Seite finden Sie 6 Tipps & Tricks für Access-Tabellen. Soweit keine Einschränkungen dazu genannt werden, gelten diese Tipps & Tricks für alle Versionen von Access.

Wenn in den folgenden Erläuterungen Texte wie MsgBox formatiert sind, handelt es sich um konkret einzugebende Inhalte wie VBA-Code oder die Eingabe von Werten. Menüs wie Datei Speichern sind wie hier zu sehen formatiert. Schaltflächen oder Registerkarten auf Dialogen werden wie Menüs behandelt.

Alle Tipps sind nach bestem Wissen geprüft, aber selbstverständlich ohne Gewähr. Sollten Sie doch einen Fehler darin entdecken, würden wir uns freuen, wenn Sie uns per eMail Bescheid sagen.

Die typische Beziehung zwischen zwei Tabellen in einer relationalen Datenbank ist die 1:n-Verknüpfung. Dabei haben beliebig viele Datensätze aus der Detailtabelle (die "n"-Seite") eine Beziehung zu je einem Datensatz der Mastertabelle (die "1"er-Seite). Anwendungsbeispiele dafür sind Lieferant:Artikeln, Bankkunde:Konten, Projekt:Vorgängen, Kurs:Teilnehmern oder Konto:Ein-/Auszahlungen.

Dabei muss die Mastertabelle ein eindeutiges Erkennungsfeld besitzen, im einfachsten Fall ein Feld mit AutoWert. Für die Lieferanten könnte das lfrID (Lieferanten-Identifikation) heißen. In der Detailtabelle nimmt ein Feld wie artlfrIDRef (in der Artikeltabelle auf die lfrID eine Referenz) dann Bezug auf die lfrID. Das mag kein besonders wohlklingender Name sein (siehe auch Tipp "Namenskonventionen (2): Ungarische Notation"), aber er ist beschreibend und innerhalb der Datenbank eindeutig.

Die vielfach genutzte Technik, beide Felder identisch zu benennen, kann ich nicht empfehlen, denn

  • gleichnamige Felder in der Datenbank bedeuten, dass diese zur Unterscheidung mit Tabellennamen geschrieben werden müssen (also [tblArtikel Stammdaten].[Name] statt [artName]).
  • viele Benutzer/innen wissen nicht, in welches der beiden Felder sie nun schreiben dürfen oder nicht
Die eigentliche Verknüpfung zwischen den Tabellen findet via Extras Beziehungen statt. Ziehen Sie dort das Master-Feld (hier lfrID) genau auf das Detailfeld (hier artlfrIDRef). Sobald Sie die Maus loslassen, erscheint der BeziehungenBearbeiten-Dialog schon mit den passend eingetragenen Feldern.

Wenn Sie das so beließen, wäre das nett und unverbindlich, doch erst das Ankreuzen von Referentielle Integrität sorgt später dafür, dass

  • in artlfrIDRef nur Werte gespeichert werden können, die in lfrID auch enthalten sind, und
  • Datensätze mit einer lfrID, die in irgendeiner artlfrIDRef bereits benutzt wird, nicht gelöscht werden können.
Damit sind Sie sicher, dass keiner der Detail-Datensätze "verwaist" ist, also ohne zugehörigen Master-Datensatz. Alle Artikel besitzen damit garantiert einen Lieferanten. Es darf durchaus Lieferanten geben, denen keine Artikel zugeordnet sind, aber solange sie wenigstens einen Artikel liefern, lassen sie sich nicht löschen.

Der letzte Punkt lässt sich im BeziehungenBearbeiten-Dialog übrigens ändern durch Ankreuzen der Option Löschweitergabe .... Beim Löschen eines Lieferanten warnt Access dann eher allgemein, dass "...ein Datensatz aus dieser Tabelle sowie verwandte Datensätze..." gelöscht würden. Sobald Sie das bestätigen, werden erst seine zugehörigen Artikel und dann der Lieferant selber gelöscht.

In einer Tabelle speichern Sie typischerweise die Eigenschaften des Objekts. In einer Kunden-Tabelle also Name, Anschrift und Rabatt oder in einer Artikel-Tabelle also Bezeichnung, Lieferant und Preis. Wirklich? NEIN! In so einer Tabeller dürfen nämlich nur die untrennbaren und unveränderlichen Eigenschaften gespeichert werden.

Falls Sie den Rabatt daher mit den übrigen Kundendaten in der gleichen Tabelle speichern, darf er sich nie wieder ändern. Schließlich greifen Sie per Abfrage darauf zu, wenn Sie eine Rechnung schreiben. Mit wechselndem Inhalt können Sie jedoch am Jahresende keine Januar-Rechnung mehr ermitteln, weil der alte Rabatt inzwischen überschrieben wurde. Ebenso wäre ein Preis in der Artikel-Tabelle für immer und ewig fixiert.

Die Datenbank-theoretisch saubere Lösung wäre die Auslagerung dieser (Rabattt- und Preis-)Daten in eine eigene Tabelle, in der auch das jeweilige Datum der letzten Änderung stünde. Dann müssten Sie zu jedem Verkauf mühsam den an diesem Tag gültigen Preis oder Rabatt erst ermitteln.

Die einfachere und vor allem bedeutend schnellere Variante besteht darin, in der Verkaufstabelle zu jedem Datensatz den jeweils aktuellen Rabatt und Preis zu speichern. Bis zur nächsten Rabatt-/Preis-Änderung sind das zwar redundante Daten und sie gelten damit als Verstoß gegen die Regeln für relationale Datenbanken (zu denen Access gehört, siehe auch "Normalisierung"). Aber danach enthalten sie die historischen Daten, die Ihnen ja sonst fehlen würden.

Die automatische Übernahmen der Preis-/Rabatt-Daten von der Artikel-/Kunden-Tabelle in die Verkaufstabelle sollte per Makro oder VBA aufgrund eines Ereignisses erfolgen. Gut geeignet ist dabei das Beim Klicken-Ereignis eines Kombinationsfeldes, mit dem ein Artikel oder Kunde ausgewählt wird.

Mit einem AutoWert lässt sich jeder Datensatz immer eindeutig identifizieren. Das verhindert aber nicht, dass gleiche Inhalte mehrfach eingetragen werden können. Wenn Sie in einer Kunden-Tabelle "Michaela Müller, Berlin" doppelt eingeben, sind das aus Sicht der Datenbank zwei eigenständige Personen. Gerade bei einer so großen Stadt wie Berlin kann das ja durchaus richtig sein.

Wenn Sie aber noch die Merkmal Geburtstag und Straße hinzunehmen, dürfte es keine gleichen Inhalte mehr geben. Jetzt müssen Sie Access nur noch anweisen, das auch zu überprüfen und gegebenenfalls doppelte Datensätze abzulehnen. Das ist nicht die Indiziert-Eigenschaft eines einzelnen Felder, sondern geschieht über Ansicht Indizes. In diesem Fenster finden Sie vermutlich schon einen Primary Key-Eintrag.

Tragen Sie nun in der ersten freien Zeile der ersten Spalte einen beliebigen eigenen Namen wie NixDoppelt ein und in der zweiten Spalte daneben sowie darunter alle Felder, die gemeinsam geprüft werden sollen. Nur in der ersten Zeile der neuen Felder steht in der ersten Spalte eine Bezeichnung, denn sie gilt für die folgenden Zeilen mit.

Nur mit markierter erster Zeile (die mit dem Indexnamen NixDoppelt) können Sie im unteren Teil des Fensters dann Eindeutig auf Ja stellen. Ab jetzt ist es ausgeschlossen, einen Datensatz zu speichern, der in allen hier aufgelisteten Feldern einem bereits vorhandenen gleicht.

AutoWert-Felder in Access beginnen unerbittlich immer bei 1 und werden in 1er-Schritten erhöht, bis bei ca. 2,1 Mrd. (nämlich der Grenze des Long-Datentyps) Schluß ist. Eine der wenigen Alternativen zu diesen weitergezählten Nummern besteht darin, im Tabellen-Entwurf für das AutoWert-Feld die Neue Werte-Eigenschaft auf Zufall zu stellen.

Eine echte eigene automatische Nummerierung für Datensätze in Tabellen ist grundsätzlich deswegen nicht möglich, weil Access keine so genannten Trigger kennt, also Ereignisse, die in Tabellen z.B. beim Neuanlegen eines Datensatzes auftreten. Der Tipp "Eigene AutoWert-Nummerierung" zeigt, dass eine eigene Nummerierung in einem Formular anhand seiner Ereignisse machbar ist.

Alle Objekte im Datenbankfenster können Sie ausblenden, wenn Sie per Rechtsklick deren Eigenschaften-Dialog öffnen und dort Ausblenden anklicken.

Um sie wieder einzublenden, müssen Sie in Extras Optionen Ansicht die Option Ausgeblendete Objekte anzeigen aktivieren. Diese sind dann mit einem helleren Symbol gekennzeichnet und können per Rechtsklick wieder zurückgeschaltet werden.

Anders als das offizielle Ausblenden gilt die hier beschriebene Technik nur für Tabellen und Abfragen: wenn der Name mit USys beginnt, werden sie wie Systemobjekte behandelt.

Deren Anzeige ist abhängig von Extras Optionen Ansicht und dem Kontrollkästchen Systemobjekte. Das betrifft normalerweise nur Tabellen, die mit MSys beginnen und außerdem mit einer Eigenschaft als System gekennzeichnet sind. Für USys-Tabellen und -Abfragen reicht dieser spezielle Namensanfang. Allerdings halten sie sich damit nicht mehr an die Regeln der Ungarischen Notation (siehe Tipp "Namenskonventionen (2): Ungarische Notation").