Rechnungsverwaltung: Das Datenmodell

Mit diesem Artikel beginnen wir eine neue Reihe. Schritt für Schritt bauen wir eine vollständige Rechnungsverwaltung auf – mit Kunden, Artikeln, Rechnungen und Positionen, später mit Formularen zur Eingabe und Berichten für den Ausdruck. Bevor davon irgendetwas entstehen kann, brauchen wir ein tragfähiges Fundament: die Tabellen. Und gerade bei einer Rechnungsverwaltung ist das Fundament kein Nebenschauplatz, denn hier gelten Regeln, die eine einfache Adressverwaltung nicht kennt. Warum wir welche Tabelle, welches Feld und welchen Datentyp wählen – und warum manche Entscheidung anders ausfällt, als man zunächst denkt -, liest Du in diesem Artikel.

Beispieldatenbank

Die fertige Datenbank dieses Artikels findest Du unter dem Namen Rechnungsverwaltung_Datenmodell.accdb. Alle folgenden Artikel der Reihe bauen darauf auf. Gegebenenfalls werden noch Erweiterungen daran vorgenommen.

Der Überblick: neun Tabellen

Eine Rechnungsverwaltung besteht aus mehr Tabellen, als man auf den ersten Blick vermutet. Unsere umfasst neun. Es lohnt sich, sie vorab in zwei Gruppen zu sortieren, weil daraus die Reihenfolge folgt, in der wir sie anlegen.

Die erste Gruppe sind die Nachschlagetabellen – kleine Tabellen mit festen Auswahlwerten, auf die andere verweisen: tblAnreden, tblLaender, tblEinheiten, tblSteuersaetze und tblRechnungsstatus. Sie stehen am Anfang, weil spätere Tabellen ihre Schlüssel brauchen.

Die zweite Gruppe sind die Kerntabellen, in denen das eigentliche Geschehen steckt: tblKunden, tblArtikel, tblRechnungen und tblRechnungspositionen. Ihr Zusammenspiel zeigt Bild 1.

Bild 1: Das vollständige Datenmodell im Beziehungsfenster

Wir legen die Tabellen komplett über die Entwurfsansicht an. Das ist für ein Datenmodell der anschaulichste Weg – wir sehen bei jedem Feld die Auswahl des Datentyps und seine Eigenschaften.

Eine Grundsatzentscheidung vorweg: Historisierung

Eine Regel zieht sich durch das ganze Modell, deshalb klären wir sie zuerst. Eine Rechnung ist ein Dokument, das nicht mehr verändert werden darf, sobald es den Betrieb verlassen hat.

Verschickst Du heute eine Rechnung und der Kunde zieht nächsten Monat um, dann muss auf Deiner Rechnung weiterhin die alte Adresse stehen. Änderst Du im Kundenstamm die Adresse, darf sich die längst gestellte Rechnung nicht rückwirkend mitändern.

Genau das würde aber passieren, wenn die Rechnung ihre Kundendaten über die KundeID immer frisch aus tblKunden holte. Deshalb kopieren wir beim Erstellen einer Rechnung die Kundendaten in die Rechnung hinein.

Dieses Prinzip heißt Historisierung, und es ist der Grund, warum in tblRechnungen Felder wie KundeFirma und KundeStrasse auftauchen, obwohl es dieselben Angaben schon in tblKunden gibt. Dasselbe gilt für die Positionen: Sie speichern ihren eigenen Preis, ihre eigene Bezeichnung und ihren eigenen Steuersatz – nicht den, der heute im Artikelstamm steht, sondern den, der bei Rechnungsstellung galt.

Das mag nach Verschwendung aussehen, ist aber das Gegenteil: Es ist die Voraussetzung dafür, dass eine Rechnung ein verlässliches Dokument bleibt.

Behalte diesen Gedanken im Hinterkopf – er erklärt viele der doppelt wirkenden Felder weiter unten.

Die Nachschlagetabellen: tblAnreden

Wir beginnen mit der kleinsten Tabelle. Eine Anrede ist Herr oder Frau, vielleicht später noch etwas weiteres. Statt diesen Text bei jedem Kunden neu einzutippen – mit dem Risiko von Tippfehlern -, legen wir ihn einmal in einer eigenen Tabelle ab und verweisen von überall darauf.

Die Tabelle tblAnreden hat nur zwei Felder: AnredeID als Autowert und Primärschlüssel sowie Anrede als Kurzer Text. Den Autowert als Primärschlüssel verwenden wir bei jeder Tabelle – er ist eindeutig, unveränderlich und von Access selbst vergeben (siehe Bild 2). Auch für das Feld Anrede legen wir einen eindeutigen Index fest, damit jede Anrede nur einmal in der Tabelle auftauchen kann.

Bild 2: Der Entwurf von tblAnreden – ein Autowert und ein Textfeld

Nach dem Speichern tragen wir gleich die beiden Werte ein, denn ohne sie können wir später keinem Kunden eine Anrede zuweisen (siehe Bild 3).

Bild 3: Die Datenblattansicht von tblAnreden mit den Einträgen Herr und Frau

tblLaender

Ein Länderverzeichnis besteht ebenfalls aus wiederkehrenden Werten. tblLaender bekommt neben LandID und Land drei weitere Felder: ein Ja/Nein-Feld EU, das kennzeichnet, ob ein Land zur Europäischen Union gehört – wichtig für die Umsatzsteuer -, sowie die beiden Ländercodes ISO2 und ISO3.