Datenmodelle für die Rechnungsverwaltung, Teil 2

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.

Mögliche Inkonsistenz bei den Rechnungspositionen

Die Ausgabe 6/2023 war bereits fertig gesetzt, als unserem Lektor Carsten Gromberg eine mögliche Quelle für Inkonsistenzen in den Daten aufgefallen ist. Dabei geht es um den Teil, wo wir Rechnungen den Bestellungen zuweisen und Rechnungspositionen den Bestellpositionen. Dabei haben wir die Tabellen tblBestellungen und tblRechnungen über die Verknüpfungstabelle tblRechnungenBestellungen miteinander verknüpft (siehe Bild 1). Der Hintergrund war, dass es sowohl vorkommen kann, dass eine Rechnung mehrere Bestellungen zusammenfasst als auch dass eine Bestellung in mehreren Rechnungen abgerechnet wird. Für die Beziehung zwischen den Rechnungspositionen und den Bestellpositionen reichte uns eine einfache 1:n-Beziehung. Hier könnte man sich bereits die folgende Frage stellen:

Auszug des Datenmodells mit der Möglichkeit von Inkonsistenzen

Bild 1: Auszug des Datenmodells mit der Möglichkeit von Inkonsistenzen

Ist hier die 1:n-Beziehung der richtige Ansatz? Reicht nicht eine 1:1-Beziehung aus, weil wir zu jeder Bestellposition nur eine Rechnungsposition benötigen? Nein, die 1:1-Beziehung reicht nicht aus: Theoretisch soll es sogar möglich sein, eine Bestellposition mit einer Menge von mehr als eins auf mehrere Rechnungspositionen und auch Rechnungen aufzuteilen.

Es kann vorkommen, dass der Kunde zwei Exemplare des gleichen Produkts bestellt, aber nur eines lieferbar ist. Dann bekommt er zunächst nur die Lieferung des einen Exemplars und die entsprechende Rechnung.

Tatsächlich geht es um eine andere Frage: Angenommen, wir haben zwei Bestellungen B1 und B2. B1 enthält die Bestellpositionen B1-1 und B1-2. B2 enthält die Bestellposition B2-1. Wir erstellen darauf basierend nun eine Rechnung R1, die über die Tabelle tblRechnungenBestellungen mit der Bestellung B1 verknüpft ist. Und wir verarbeiten die Bestellpositionen B1-1 und B1-2 in zwei Rechnungspositionen R1-1 und R1-2.

Beide sind über das Fremdschlüsselfeld RechnungID der Tabelle tblRechnungspositionen mit der richtigen Rechnung verknüpft, nämlich R1. Und das Fremdschlüsselfeld BestellpositionID der gleichen Tabelle verknüpfen wir von R1-1 zu B1-1 und von R1-2 zu B1-2.

[

Soweit, so gut: Es wäre aber theoretisch möglich, dass wir das Feld BestellpositionID der Rechnungsposition R1-2 mit der Bestellposition B2-1 verknüpfen, während diese Position über die Tabelle tblRechnungen und tblRechnungenBestellungen mit der Bestellung B1 verknüpft ist.

Das wäre dann die mögliche Inkonsistenz. Aber wie wollen wir diese verhindern? Und benötigen wir die Zuordnung von Rechnungsposition zur Bestellposition überhaupt? Letzteres ist notwendig, damit wir prüfen können, ob eine Bestellposition bereits in einer Rechnungsposition erfasst wurde – und gegebenenfalls auch abgleichen können, ob die in der Bestellposition angegebene Menge vollständig in Rechnung gestellt wurde.

Wie wir die Datenintegrität sicher stellen wollen, schauen wir uns im folgenden Abschnitt an.

Verhindern der Inkonsistenz

Die Aufgabe lautet nun also: Wie können wir dafür sorgen, dass man für eine Rechnungsposition in der Tabelle tblRechnungspositionen keine Bestellposition für das Fremdschlüsselfeld BestellpositionID auswählen kann, die nicht zu der Bestellung aus der Tabelle tblBestellungen gehört, die über die Verknüpfungstabelle tblRechnungenBestellungen mit der zu der Rechnung aus tblRechnungen gehörenden Rechnung verknüpft ist?

Der Clou ist: Wir fügen der Tabelle tblRechnungspositionen ein weiteres Feld namens BestellungID hinzu. Dann erstellen wir eine Beziehung zwischen der Tabelle tblRechnungspositionen und tblRechnungenBestellungen, welche die beiden Felder RechnungID und BestellungID der beiden Tabellen umfasst und die im Fenster Beziehungen bearbeiten wie in Bild 2 aussieht.

Anlegen einer Beziehung über zwei Felder

Bild 2: Anlegen einer Beziehung über zwei Felder

Wechseln wir zurück zum Beziehungen-Fenster, sehen wir die Beziehung wie in Bild 3.

Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...

den kompletten Artikel im PDF-Format mit Beispieldatenbank

diesen und alle anderen Artikel mit dem Jahresabo

Schreibe einen Kommentar