Kategorie: Tabellen und Datenmodellierung

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.

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.

Neulich bat mich ein Kunde, mir einmal ein Netzwerkproblem beim ihm anzusehen. Aufgrund der Fehlermeldung konnte es keine andere Ursache geben – sie lautete “Aktualisieren nicht möglich, momentane Sperrung durch eine andere Sitzung auf diesem Rechner”. Also haben wir uns diese Sache gemeinsam angesehen und zunächst schien die Meldung plausibel – immerhin arbeitete eine andere Mitarbeiterin gerade mit der Datenbank und es konnte gut sein, dass der Datensatz gesperrt war. Allerdings trat das Problem später immer noch auf, obwohl niemand sonst mehr mit der Datenbank arbeitete. Gemeinsam sind wir dem Problem dann auf die Schliche gekommen. Die Überschrift deutet es bereits an: Ein Memofeld spielte eine große Rolle bei der Lösung des Problems.

Wozu sollte man Tabellenfeldbeschriftungen im Griff haben? Und was ist das überhaupt? Die Eigenschaft “Beschriftung” von Tabellenfeldern kennen viele Entwickler gar nicht. Dabei könnten sie sich eine Menge Zeit sparen, wenn sie diese Eigenschaft nutzen würden. Trägt man nämlich beispielsweise für ein Feld wie “EMail” eine Beschriftung wie “E-Mail” ein, dann wir diese statt des Feldnamens als Spaltenüberschrift der Tabelle in der Datenblattansicht angezeigt. Und es geht noch weiter: Wenn man in Formularen und Berichten Steuerelemente auf Basis dieser Felder anlegt, übernimmt Access auch dort den Wert der Eigenschaft Beschriftung statt des Feldnamens für die Bezeichnungsfelder Steuerelemente. Man braucht als nur an einer Stelle eine Änderung vorzunehmen und profitiert an vielen anderen Stellen davon. Und wenn man nun nicht in jeder neuen Datenbank die Beschriftungen erneut anlegen müsste … doch auch dafür haben wir in diesem Beitrag eine Lösung.

Nachdem wir im Beitrag “Rechnungsverwaltung: Datenmodell” das Datenmodell für die Rechnungsverwaltung definiert haben, könnten wir eigentlich zur Programmierung der für die Dateneingabe benötigten Formulare übergehen. Allerdings macht die Programmierung von Formularen deutlich mehr Spaß, wenn bereits einige Beispieldaten vorliegen und man direkt damit ausprobieren kann, ob die Formulare funktionieren. Als Hilfsmittel zum Erstellen der Beispieldaten verwenden wir das im Beitrag “Beispieldaten generieren mit .NET und Bogus” vorgestellte Werkzeug.

In einer Beitragsreihe namens “Rechnungsverwaltung” wollen wir eine kleine Rechnungs-ver-waltung programmieren. Im ersten Teil kümmern wir uns um das Datenmodell der Rech-nungsverwaltung und zeigen an einem Praxisbeispiel in einem weiteren Teil, wie Sie die im Beitrag “Beispieldaten generieren mit .NET und Bogus” (www.access-im-unternehmen.de/1359) vorgestellte Technik zum Erstellen von Beispieldaten einsetzen können. Das resultierende Datenmodell mit seinen Daten ist die Grundlage für weitere Beitragsteile, in denen wir Formulare zur Verwaltung der Rechnungen vorstellen sowie einen Rechnungsbericht erstellen, der gleich noch einen EPC-QR-Code zum schnellen Überweisen per Smartphone enthält. Außerdem schauen wir uns noch an, wie Sie mithilfe von Kontoumsätzen schnell abgleichen können, welche Rechnungen bezahlt sind.

Bestellpositionen speichern wir in einer eigenen Tabelle beispielsweise namens tblBe-stellpositionen, die als m:n-Verknüpfungstabelle zwischen Tabellen wie tblBestellungen und tblProdukte dient. Diese Tabelle nimmt dann jeweils noch Felder auf wie Einzelpreis, Mehrwertsteuersatz und Einheit, die wir aus der Produkte-Tabelle in die Bestellpositionen-Tabelle kopieren. Damit das automatisch beim Anlegen einer Bestellposition geschieht, fügen wir normalerweise ein Ereignis zum Eingabeformular für die Bestellpositionen hinzu, das diese Daten ausliest und in die Bestellposition einträgt. Es gibt jedoch noch eine Alternative: Dabei verwenden wir ein Datenmakro, das durch das Ereignis “Vor Änderung” des Datensatzes ausgelöst wird und verlegen die Logik damit in die Tabelle selbst. Wie das gelingt, zeigt der vorliegende Beitrag.