<\/p>\n
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.<\/p>\n
Die fertige Datenbank dieses Artikels findest Du unter dem Namen Rechnungsverwaltung_Datenmodell.accdb<\/b>. Alle folgenden Artikel der Reihe bauen darauf auf. Gegebenenfalls werden noch Erweiterungen daran vorgenommen.<\/p>\nDer Überblick: neun Tabellen<\/h2>\n
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.<\/p>\n
Die erste Gruppe sind die Nachschlagetabellen<\/b> – kleine Tabellen mit festen Auswahlwerten, auf die andere verweisen: tblAnreden<\/b>, tblLaender<\/b>, tblEinheiten<\/b>, tblSteuersaetze<\/b> und tblRechnungsstatus<\/b>. Sie stehen am Anfang, weil spätere Tabellen ihre Schlüssel brauchen.<\/p>\n
Die zweite Gruppe sind die Kerntabellen<\/b>, in denen das eigentliche Geschehen steckt: tblKunden<\/b>, tblArtikel<\/b>, tblRechnungen<\/b> und tblRechnungspositionen<\/b>. Ihr Zusammenspiel zeigt Bild 1.<\/p>\n
Bild 1: Das vollständige Datenmodell im Beziehungsfenster<\/p>\n 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.<\/p>\n 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.<\/p>\n Verschickst Du heute eine Rechnung und der Kunde zieht nächsten Monat um, dann muss auf Deiner Rechnung weiterhin die alte<\/b> Adresse stehen. Änderst Du im Kundenstamm die Adresse, darf sich die längst gestellte Rechnung nicht rückwirkend mitändern.<\/p>\n Genau das würde aber passieren, wenn die Rechnung ihre Kundendaten über die KundeID<\/b> immer frisch aus tblKunden<\/b> holte. Deshalb kopieren<\/b> wir beim Erstellen einer Rechnung die Kundendaten in die Rechnung hinein.<\/p>\n Dieses Prinzip heißt Historisierung<\/b>, und es ist der Grund, warum in tblRechnungen<\/b> Felder wie KundeFirma<\/b> und KundeStrasse<\/b> auftauchen, obwohl es dieselben Angaben schon in tblKunden<\/b> gibt. Dasselbe gilt für die Positionen: Sie speichern ihren eigenen Preis, ihre eigene Bezeichnung und ihren eigenen Steuersatz – nicht den, der heute<\/b> im Artikelstamm steht, sondern den, der bei Rechnungsstellung galt.<\/p>\n Das mag nach Verschwendung aussehen, ist aber das Gegenteil: Es ist die Voraussetzung dafür, dass eine Rechnung ein verlässliches Dokument bleibt.<\/p>\n Behalte diesen Gedanken im Hinterkopf – er erklärt viele der doppelt wirkenden Felder weiter unten.<\/p>\n Wir beginnen mit der kleinsten Tabelle. Eine Anrede ist Herr<\/b> oder Frau<\/b>, 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.<\/p>\n Die Tabelle tblAnreden<\/b> hat nur zwei Felder: AnredeID<\/b> als Autowert<\/b> und Primärschlüssel sowie Anrede<\/b> als Kurzer Text<\/b>. 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 <\/b>legen wir einen eindeutigen Index fest, damit jede Anrede nur einmal in der Tabelle auftauchen kann.<\/p>\n Bild 2: Der Entwurf von tblAnreden – ein Autowert und ein Textfeld<\/p>\n 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).<\/p>\n Bild 3: Die Datenblattansicht von tblAnreden mit den Einträgen Herr und Frau<\/p>\n Ein Länderverzeichnis besteht ebenfalls aus wiederkehrenden Werten. tblLaender<\/b> bekommt neben LandID<\/b> und Land<\/b> drei weitere Felder: ein Ja\/Nein-Feld EU<\/b>, das kennzeichnet, ob ein Land zur Europäischen Union gehört – wichtig für die Umsatzsteuer -, sowie die beiden Ländercodes ISO2<\/b> und ISO3<\/b>.<\/p>\n Bei den ISO-Feldern zeigt sich zum ersten Mal, dass die Feldgröße<\/b> eine bewusste Entscheidung ist. Ein ISO-2-Code ist immer<\/b> genau zwei Zeichen lang (DE<\/b>, AT<\/b>, CH<\/b>), ein ISO-3-Code genau drei (DEU<\/b>).<\/p>\n Wir setzen die Feldgröße deshalb auf 2<\/b> beziehungsweise 3<\/b>. Das ist nicht Sparsamkeit um ihrer selbst willen – die Feldgröße ist die einfachste Plausibilitätsprüfung, die es gibt. In ein Feld der Größe 2 passt kein dreistelliger Tippfehler.<\/p>\n Damit kein Land und kein Code doppelt vorkommt, versehen wir Land<\/b>, ISO2<\/b> und ISO3<\/b> jeweils mit einem eindeutigen Index<\/b> (Feldeigenschaft Indiziert<\/b> auf Ja (Ohne Duplikate)<\/b>). Den Entwurf zeigt Bild 4.<\/p>\n Bild 4: Der Entwurf von tblLaender mit ISO-Codes und EU-Kennzeichen<\/p>\n Die ersten drei Länder tragen wir gleich ein (siehe Bild 5).<\/p>\n Bild 5: Die Datenblattansicht mit Deutschland, Österreich und der Schweiz<\/p>\n Artikel werden in Einheiten berechnet – Stunden, Stück, Pauschalen. tblEinheiten<\/b> erhält neben Einheit-ID<\/b> das Feld Einheit<\/b> für den Klartext und ein zusätzliches Feld EinheitCode<\/b> mit der Feldgröße 3<\/b>. Der Code ist die genormte Kurzform, wie sie auf Rechnungen im internationalen Verkehr verlangt wird (HUR<\/b> für Stunde, C62<\/b> für Stück). Für das Feld Einheit haben wir einen eindeutigen Index definiert, für EinheitCode hingegen nicht: Es kann nämlich sein, dass es mehrere Einheiten gibt, die den gleichen internationalen Code für die Einheit verwenden (siehe Bild 6).<\/p>\n Bild 6: Der Entwurf von tblEinheiten<\/p>\n Die ersten Einträge in dieser Tabelle sehen wir in Bild 7.<\/p>\n Bild 7: Die Datenblattansicht mit den vorbereiteten Einheiten<\/p>\n Jetzt wird es lehrreich. tblSteuersaetze<\/b> hält die gültigen Umsatzsteuersätze fest: den Regelsatz von 19 Prozent, den ermäßigten von 7 Prozent und den Nullsatz.<\/p>\n Sie hat vier Felder: SteuersatzID<\/b>, Bezeichnung<\/b>, Umsatzsteuersatz<\/b> und ein Ja\/Nein-Feld Aktiv<\/b>, mit dem sich ein Satz ausblenden lässt, ohne ihn zu löschen (siehe Bild 8).<\/p>\n Bild 8: Der Entwurf von tblSteuersaetze mit dem Dezimalfeld und dem Prozentformat<\/p>\n Die Frage ist: Welchen Datentyp bekommt Umsatzsteuersatz<\/b>? Ein Prozentsatz ist eine Kommazahl, und die naheliegende Wahl wäre Zahl<\/b> mit der Feldgröße Single<\/b> oder Double<\/b>. Genau das aber führt später zu falschen Rechnungsbeträgen.<\/p>\n Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!<\/span>![\"Das](\"..\/tl_files\/images\/pic_719_015.png\")
<\/a><\/p>\nEine Grundsatzentscheidung vorweg: Historisierung<\/h2>\n
Die Nachschlagetabellen: tblAnreden<\/h2>\n
<\/a><\/p>\n<\/a><\/p>\ntblLaender<\/h2>\n
<\/a><\/p>\n<\/a><\/p>\ntblEinheiten<\/h2>\n
<\/a><\/p>\n<\/a><\/p>\ntblSteuersaetze – und der erste knifflige Datentyp<\/h2>\n
<\/a><\/p>\n
\nHier geht es zur Bestellung des Jahresabonnements des Magazins Access [basics]<\/strong>:<\/span>
\nZur Bestellung ...<\/a><\/span>
\nDanach greifen Sie sofort auf alle rund 400 Artikel<\/strong> unseres Angebots zu - auch auf diesen hier!<\/span>
\nOder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:<\/span><\/p>\n<\/div>\n\n\t\n\t