Kategorie: Tabellen und Datenmodellierung

Seit Access 2010 können Tabellenfelder einen berechneten Ausdruck enthalten – etwa die Verknüpfung von Vor- und Nachname oder das Produkt aus Menge und Preis. Die Funktion klingt praktisch, hat aber erhebliche Einschränkungen: Viele Funktionen stehen nicht zur Verfügung, das Ergebnis ist schreibgeschützt und berechnete Felder lassen sich weder indizieren noch in Verknüpfungen verwenden. Dieser Beitrag zeigt, was geht, was nicht geht – und warum berechnete Spalten in Abfragen fast immer die bessere Wahl sind.

In unseren Access-Audits mit unseren Kunden treffen wir immer wieder auf das folgende Problem: Es gibt Tabellen, die zwar über ein Feld Datensätze aus anderen Tabellen referenzieren, aber es wurde gar keine Beziehung für diese Zuordnung definiert. Und wenn eine Beziehung angelegt wurde, wurde für diese keine referenzielle Integrität festgelegt. Das birgt verschiedene Gefahren, die unter Umständen sogar Auswirkungen auf den Unternehmensumsatz haben. Welche das sind und wie Sie diese Probleme beheben, zeigen wir in diesem Beitrag. Die Definition von Beziehungen mit referenzieller Integrität ist essenziell und sollte, wenn diese noch nicht vorhanden sind, schnellstens nachgerüstet werden. Das funktioniert in vielen Fällen aber gar nicht so leicht, weil die Tabellen bereits inkonsistente Daten enthalten. Auch zur Identifizierung und Korrektur solcher Datensätze liefert dieser Beitrag die passenden Lösungen.

Manchmal legt man eine 1:n-Beziehung zwischen zwei Tabellen an, um später festzustellen, dass eine m:n-Beziehung doch die funktionalere Variante ist. Ein Beispiel sind reflexive Beziehungen, mit denen man etwa Vater-Kind-Beziehungen abbildet oder Partner-Beziehungen. Andere Beispiele sind solche wie zwischen Produkten und Kategorien – man dachte zunächst, dass es reicht, wenn man jedes Produkt nur einer Kategorie zuordnen kann, aber man dann erkennt, dass es für verschiedene Anwendungsfälle doch günstiger wäre, wenn man ein Produkt mehr als einer Kategorie zuordnen kann. Ähnliche Fälle sind Mitarbeiter und Funktionen oder Abteilungen. In diesem Beitrag schauen wir uns das Beispiel eines Kunden an, der in seinem Sportverein partnerschaftliche Beziehungen über ein Fremdschlüsselfeld der Tabelle tblMitglieder auf diese selbst abgebildet hat. Hier gab es mehrere Gründe, um diese Beziehung in eine m:n-Beziehung umzuwandeln. Welche das sind und wie wir die Umwandlung durchgeführt haben, lesen Sie in diesem Beitrag.

Mehrwertige Felder sind eine Erfindung von Microsoft, um den Umgang mit Datenkonstrukten, bei denen für ein Feld mehrere Werte ausgewählt werden können, zu vereinfachen. In einem mehrwertigen Feld können wir aus einer Liste von Werten, die entweder aus einer Wertliste oder aus einer anderen Tabelle stammen, keinen, einen oder mehrere Einträge auswählen. Aus einer verknüpfen Tabelle mehrere Werte zuordnen? Das hört sich ja eigentlich nach dem Einsatzzweck einer m:n-Beziehung an. Genau das bildet Microsoft intern ab. Allerdings funktioniert das nur innerhalb des Access-Biotops. Sollen die Daten einmal zum SQL Server oder einer anderen Datenbank wandern, wird es kompliziert. Hier können wir solche Konstrukte nämlich nicht mehr einfach abbilden – wir müssen diese also ersetzen. Wie wir die mehrwertigen Felder loswerden, zeigen wir in diesem Beitrag.

Eigentlich wollten wir nur ein kleines Datenmodell erstellen, das einige Tabellen enthält, die alle Beziehungstypen und Felddatentypen abbildet. Dieses wollten wir als Beispiel für eine SQL Server-Migration verwenden. Allerdings ist das Datenmodell so umfangreich geworden, dass wir uns entschieden haben, dieses einmal in einem Beitrag vorzustellen. Es enthält alle wichtigen Datentypen, alle Beziehungstypen und auch verschiedene Eigenschaften wie eindeutige und nicht eindeutige Indizes, Fremdschlüsselfelder, Felder, die den Wert Null enthalten dürfen und solche, die es nicht dürfen und vieles mehr. Dies ist ein Entwurf für ein solches Datenmodell, das keinen Anspruch auf Vollständigkeit hat – und es werden auch nicht alle Aspekte behandelt, die man vielleicht noch in einer solchen Verwaltung erwartet. Die Verwaltung von Gehältern, Urlauben et cetera würden wir gegebenenfalls in weiteren Beiträgen vorstellen.

Der Felddatentyp „Datum/Uhrzeit erweitert“ wurde mit Access 2021 beziehungsweise mit Access aus Office 365 eingeführt. Er speichert genau wie der Datentyp „Datum/Uhrzeit“ Datums- und Zeitangaben. Allerdings hat er eine höhere Genauigkeit und Uhrzeiten können nun auch Bruchteile von Sekunden enthalten. Der Grund für die Einführung ist die Herstellung von Kompatibilität mit dem SQL Server, der den Datentyp „datetime2“ enthält. Wenn wir Tabellenverknüpfungen zu den Tabellen einer SQL Server-Datenbank herstellen, werden Felder des Typs „datetime2“ automatisch mit dem neuen Access-Datentyp „Datum/Uhrzeit erweitert“ übersetzt. Allerdings bringt das diverse Probleme mit sich. Zum Beispiel können die in Access eingebauten Datumsfunktionen nicht richtig mit diesem Datentyp umgehen. Was das im Detail bedeutet und welche Lösungsmöglichkeiten es gibt, erläutern wir in diesem Beitrag.

Für Felder in Tabellen kann man jeweils einen Standardwert im Tabellenentwurf festlegen, der beim Anlegen eines neuen Datensatzes in dieser Tabelle vorbelegt wird. Etwas anspruchsvoller ist es, wenn wir Standardwerte durch den Benutzer festlegen wollen. Noch einen Schritt weiter gehen wir, wenn der Standardwert für ein Fremdschlüsselfeld verwendet werden soll – also zur Auswahl eines Datensatzes aus einer verknüpften Tabelle. Einfache Beispiele sind Anreden, Zahlungsmethoden, Prioritäten oder Kategorien. Hier können wir jeweils einen Eintrag anwendungsweit festlegen. Es geht aber auch noch anspruchsvoller: Wenn wir beispielsweise Adressen für Kunden in einer eigenen Tabelle speichern, wo mehrere Adressen je Kunde angelegt werden können und nur eine als Standard verwendet werden soll. Spätestens hier müssen wir auch beim Datenmodell umdenken. In diesem Beitrag schauen wir uns erst einmal an, wie wir Standardwerte für Nachschlagefelder komfortabel auswählen können.

Im ersten Teil dieser Beitragsreihe haben wir die grundlegenden Ideen vorgestellt, die wir zum Thema Bestellungen/Rechnungen/Lieferungen haben. Uns ist jedoch noch eine Feinheit entgangen, die wir in diesem Beitrag noch nachreichen wollen. Dabei geht es darum, eventuelle Inkonsistenzen beim Erstellen von Rechnungspositionen auf Basis von Bestellpositionen zu vermeiden. Normalerweise sollte mit dem aktuellen Datenmodell nichts schiefgehen, aber das Datenmodell sollte so viele Probleme wie möglich bereits durch die enthaltenen Restriktionen in Form von Beziehungen verhindern.

Beim Schreiben von Anwendungen, mit denen Rechnungen erstellt werden sollen, stellt sich immer wieder die Frage nach dem korrekten Datenmodell. Davon ausgehend, dass es nicht das perfekte Datenmodell für alle Anwendungsfälle gibt, wollen wir in diesem Beitrag einmal unterschiedliche Ansätze betrachten und diskutieren. Diese haben eines gemein: Die Anwendung mit diesem Datenmodell soll die Möglichkeit bieten, sowohl Bestellungen zu erfassen als auch Rechnungen und Lieferscheinen zu erstellen. Wie welche Daten gespeichert werden und welche Möglichkeiten es gibt, schauen wir uns nun an.

Standardwerte für Felder legt in der Regel der Entwickler beim Definieren des Datenmodells in der Entwurfsansicht der Tabellen fest. Während man in bestimmten Maßen dynamische Werte nutzen kann wie beispielsweise mit der Datum()-Funktion für Datumsfelder, ist man ansonsten recht unflexibel. Leider lassen sich dort nur einige eingebaute Funktionen nutzen, wir können keine benutzerdefinierten VBA-Funktionen einsetzen. Aber welche benutzerdefinierten Standardwerte wollen wir überhaupt nutzen – und wo wollen wir diese festlegen? Die Einsatzzwecke sind vielfältig und prinzipiell können wir jedes Feld mit einem benutzerdefinierten Standardwert nutzen. Wichtig ist der Gedanke dahinter: Sinnvoll gewählte Standardwerte sparen dem Benutzer wertvolle Zeit bei der Dateneingabe. Wenn wir zum Beispiel eine Datenbank planen, die überwiegend weibliche Kontakte verwaltet, ist es sinnvoll, als Anrede „Frau“ vorzugeben. Oder wir haben eine Autowerkstatt, die hauptsächlich Fahrzeuge einer bestimmten Marke repariert – dann macht es Sinn, diese vorzubelegen. Wir können auch dynamisch den zuletzt verwendeten Eintrag als Standardwert angeben oder auch den meistgenutzen. Wie wir dies realisieren, zeigen wir im vorliegenden Beitrag.