Kategorie: Tabellen und Datenmodellierung

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.

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.

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.

Im Beitrag “Rechnungsverwaltung: Kundenadressen ausgliedern” (www.access-im-unternehmen.de/1470) verwalten wir zu jedem Kunden mehrere Adressen, die dem Kunden über ein Fremdschlüsselfeld in der Adresstabelle zugewiesen sind. Für jeden Kunden legen wir in dieser Tabelle eine Standardadresse fest. Damit ist einiger Pflegeaufwand verbunden, denn wir müssen sicherstellen, dass immer genau eine Adresse je Kunde als Standardadresse markiert ist. In diesem Beitrag schauen wir uns an, wie wir sicherstellen können, dass die Daten immer konsistent sind und wir nicht plötzlich mehrere Standardadressen je Kunde vorfinden – oder gar keine.

Während wir den Beitrag “1:n-Beziehung mit Standardzuordnung verwalten” (www.access-im-unternehmen.de/1469) schrieben, haben wir uns gefragt, ob man die Einhaltung der Konstistenz bei 1:n-Beziehungen mit Standardzuordnung nicht auch auf andere Weise sicherstellen kann als per VBA-Code. Zumal wir diesen auch noch in allen Formularen erneut programmieren müssten, welche die Daten aus dieser 1:n-Beziehung darstellen. Uns fielen zwei Lösungsansätze ein: Der erste sind die mit Access 2010 eingeführten Datenmakros, also eine Art Trigger für Access-Datenbanken. Die zweite sind die echten Trigger, und zwar die vom SQL Serve. In diesem Beitrag schauen wir uns nun die Variante mit den Datenmakros an. Kann man unser Vorhaben damit abbilden? Und wenn ja, wie?

In vielen Datenbankanwendungen fallen temporäre Daten an, also Daten, die in Tabellen geschrieben und in der gleichen Session wieder gelöscht werden. Das kann in nicht aufgeteilten Datenbanken der Fall sein, aber auch in aufgeteilten Datenbanken mit Frontend und Backend geschehen. Man könnte denken, die Größe der Datenbankdatei würde nach dem Anfügen und Löschen von Daten einigermaßen konstant sein. Das ist jedoch nicht der Fall: Gelöschte Daten sind zwar nicht mehr in den Tabellen zu finden, allerdings benötigt die Datenbank anschließend ungefähr genauso viel Speicherplatz wie vor dem Löschen. Wie das zu erklären ist und wie wir durch die Komprimierung einer Datenbank dennoch dafür sorgen können, dass eine Datenbank sich durch die Verwendung temporärer Daten nicht allzusehr aufbläht, beschreiben wir in diesem Beitrag.