Kategorie: Tabellen und Datenmodellierung

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.

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.

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.