Kategorie: Tabellen und Datenmodellierung

In vielen Beispieltabellen, die wir in diesem Magazin vorstellen, verwenden wir einfach das Primärschlüsselfeld als Kundennummer, Bestellnummer und so weiter. In manchen Fällen ist das nicht praktikabel, weil diese Nummern nach bestimmten anderen Regeln erstellt werden müssen. Dann bietet es sich an, dennoch ein Primärschlüsselfeld mit Autowertfunktion zu nutzen, um die Datensätze eindeutig zu identifizieren und dieses auch für das Herstellen von Beziehungen zu nutzen. Die Kundennummern oder Bestellnummern möchte man aber dennoch nicht von Hand eingeben, sondern die Datenbank soll das erledigen. Wie Sie das realisieren können, zeigt der vorliegende Beitrag.

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.

Im Laufe der Zeit können sich einen Menge Daten ansammeln, die Sie in Zusammenhang mit Kunden, Produkten oder ähnlichen Entitäten speichern wollen. Dabei möchten Sie vielleicht nicht für jede neue Eigenschaft ein neues Feld anlegen und damit den Tabellenentwurf ändern. Das gilt umso mehr, wenn eine Anwendung bereits von vielen Kunden genutzt wird. Es gibt jedoch eine Alternative: Sie können eine zusätzliche Tabelle hinzufügen, die in jedem Datensatz eine Eigenschaft mit dem jeweiligen Wert für die Entität speichert. Die Frage ist nur: Wie können wir diese Daten genauso nutzen, als wenn diese wie üblich in der gleichen Tabelle wie der Kunde oder das Produkt gespeichert werden

Autowertfelder verwendet man, um sich keine Sorgen mehr um die automatisch vergebenen Werte für Primärschlüsselfelder machen zu müssen. Manchmal geraten die Werte dieser Felder allerdings aus dem Takt oder Sie möchten selbst festlegen, welchen Wert der nächste Datensatz erhalten soll. Dieser Beitrag zeigt, wie Sie die Autowerte in Ihren Tabellen im Griff haben.

In den meisten Fällen ist die Wahl des Datentyps “Long” für ein Autowertfeld sinnvoll. Da es die Standardeinstellung ist, denkt man vielleicht gar nicht über alternative Datentypen nach. Manchmal kann es jedoch Vorteile haben, den Datentyp GUID zu wählen. Dann landen keine durchnummerierten Zahlen im Primärschlüsselfeld, sondern Zeichenketten im Format einer GUID. Die Nutzung der GUID ist vor allem dann anzuraten, wenn mehrere Datenbanken parallel existieren, deren Daten gelegentlich zusammengeführt werden. In diesem Fall kann man die Primärschlüsselwerte einfach weiterverwenden und muss sich nicht darum kümmern, dass der gleiche Primärschlüsselwert in mehreren Datenbanken vorkommt und angepasst werden muss.

Im Beitrag “Berichte und Unterberichte konfigurieren” haben wir die Aufgabe, für Kombinationen aus Tabellen und Abfragen herauszufinden, ob eine Beziehung zwischen den beiden Datenquellen besteht und über welche Felder diese realisiert wird. In diesem Fall nutzen wir dies, um automatisch die Verknüpfungsfelder für die Datensatzquellen von Haupt- und Unterberichten zu ermitteln. Wir erhalten also die Tabelle/Abfrage des Hauptberichts und des Unterberichts und benötigen nun die Felder, über welche die Beziehung zwischen den beiden Datenquellen hergestellt wird. Wie das gelingt, zeigt der vorliegende Beitrag.

Die Tabelle MSysResources ist relativ unbekannt. Kein Wunder, denn als Systemtabelle bleibt sie dem Benutzer in der Standardeinstellung verborgen, obwohl sie bereits seit Access 2010 in allen Datenbanken mit der Dateiendung .accdb sofort angelegt wird, wenn der Benutzer Objekte in der Datenbank anlegt. Dennoch ist sie sehr wichtig, denn sie speichert zum Beispiel die Bilddateien, die Sie Formularen in Bildsteuerelementen oder Schaltflächen zugewiesen haben. Genau um diese wollen wir uns in diesem Beitrag auch kümmern und eine Möglichkeit vorstellen, sich schnell einen Überblick über die enthaltenen Bilder zu verschaffen und schnell Bilder zu dieser Tabelle hinzuzufügen. Diese stehen dann zum Einfügen in Bildsteuerelemente und Schaltflächen bereit.

Wenn mehrere Benutzer über Frontend-Anwendungen an verschiedenen Arbeitsplätzen auf die Daten einer Backend-Datenbank zugreifen, ist das kein Problem. In vielen Anwendungen ist es dabei sinnvoll, die Möglichkeit zum Speichern von Optionen je Benutzer vorzusehen. Oft legt man dabei eine Tabelle namens “tblOptionen” im Frontend an. Das ist aber nur sinnvoll, wenn auch immer der gleiche Benutzer am gleichen Frontend arbeitet – anderenfalls würde er ja die Optionen eines anderen Benutzers vorgesetzt bekommen. Oder Sie führen ein Update des Frontends durch – auch dann wären die Optionen des Benutzers nicht mehr vorhanden. Welche Alternativen dazu gibt es Sie könnten zum Beispiel die Optionen in einer Tabelle im Backend speichern und diese beim Anmelden des Benutzers auslesen und in eine lokale Optionentabelle übertragen. Oder Sie fügen dem Frontend ein lokales Backend hinzu, das nur die Daten enthält, die beim Update des Frontends nicht überschrieben werden sollen. Wie das gelingt, zeigen wir im vorliegenden Artikel.