Startseite   Erweiterte Modellierung	Erweiterte Modellierung Projekt: Modellieren einer Datenbank, um eine Buchhaltung zu erstellen Du bist nun schon ziemlich weit in diesem Lehrgang vorangekommen. Es fehlen dir eigentlich nur ein paar Kniffe, um echter Datenbankprofi zu werden. In diesem Kapitel werden wir gemeinsam eine Datenbank modellieren. Und das von Anfang an. Wir wagen uns gleich an ein schwieriges Problem der Buchhaltung eines Unternehmens. In diesem Kapitel benötigen wir das Wissen der vorangegangen Kapitel und werden diese damit etwas wiederholen. Daten 1. Aussehen eines typischen Buchungssatzes In Buchhaltunsprogrammen werden Buchungssätze verwaltet. Für alle, die mit Buchhaltung bisher noch keine Erfahrung gemacht haben, zeige ich euch einen typischen Buchungssatz. Er besteht aus: 1. Nummer:1 2. Datum:2004-09-15 3. PersonFa. Eisen-Maier 4. GrundEinkauf von Rohstoffen und einer unbestimmten Anzahl von Konten mit Beträgen: 5. Konto 1Rohstoffe 6. Betrag 11000,-- 7. Konto 2Vorsteuer 8. Betrag 2160,-- 9. Konto 3Verbindlichkeiten 10. Betrag 3-1160,-- Auch wenn du diesen Buchungssatz nicht verstehst, macht das nichts. Hier einige Erklärungen: Diesem Buchungssatz liegt der Einkauf von Rohstoffen zugrunde, z.B. von Schrauben. Jeder Buchungsatz hat eine eindeutige fortlaufende Nummer (ID) und ein Buchungsdatum. Der Anlass für den Buchungssatz wurde hier als "Grund" beschrieben und die Person, mit der wir zu tun haben, also woher wir etwas beziehen, ist die Person. Unsere Aufgabe ist nicht, Buchungssätze zu schreiben, wir wollen die Daten einfach nur in Tabellen speichern. Probieren wir, die Daten in einer einzigen Tabelle unterzubringen: Nr Datum Person Grund Kto1 Betr1 Kto2 Betr2 Kto3 Betr3 1 2004-09-15 Eisen-Müller Ein-kauf Roh-stoffe 1000 Vor-steuer 160 Verbindl. -1160 Das hat doch sehr einfach funktioniert. Doch diese Tabelle hat einen wichtigen Nachteil. Wir wissen bei einem Buchungssatz nie, wie viele Konten darin "angesprochen" werden. Es sind immer mindestens zwei, es können aber auch mal 10 sein oder mehr. Eine riesige Tabelle zu erzeugen, deren meisten Spalten dann aber ständig leer wären ist nicht klug. Ich unternehme einen zweiten Versuch! Ich nehme für jedes Konto/Betrag eine eigene Zeile. Dann sieht unsere Tabelle so aus: Nr Datum Person Grund Kto Betrag 1 2004-09-15 Eisen-Müller Einkauf Rohstoffe 1000 1 2004-09-15 Eisen-Müller Einkauf Vorsteuer 160 1 2004-09-15 Eisen-Müller Einkauf Verbindlichkeiten -1160 In diesem Ansatz sind wie im obigen alle Informationen des Buchungssatzes enthalten. Eine beliebige Anzahl von Konten kann verwaltet werden. Aus der Tabelle kann der ursprüngliche Buchungssatz in jedem Fall rekonstruiert werden. Leider ist ein Teil der Information in großem Maße redundant. Die ersten vier Spalten enthalten mehrfach dieselben Informationen. Der Nachteil der Redundanz liegt weniger im größeren Speicherbeadarf auf einem Datenträger. Moderne Computersysteme verfügen für unsere Verhältnisse über ausreichende Ressourcen. Wird aber ein Eintrag verändert, z.B. der Name des Empfängers geändert, so kann es passieren, dass die Änderung nur in einer Zeile durchgeführt wird. Ein Buchungssatz hätte dann unterschiedliche Daten, die Datenbank wäre inkonsistent, sie würde nicht mehr eindeutige Informationen enthalten. Daher sollte Redundanz unbedingt vermieden werden. Dies ist möglich, indem abhängige Daten in eigene Tabellen ausgelagert werden. Wir teilen also die Tabelle auf in zwei Tabellen: Tabelle Buchungssatz LfdNr Datum Person Grund 1 2004-09-15 Eisen-Meier Einkauf Tabelle Konten Nr Konto Betrag 1 Rohstoffe 1000,-- 2 Vorsteuer 160,-- 3 Verbindlichkeiten 1160,-- Auf den ersten Blick sieht es so aus, als ob wir damit schon fertig wären. Doch kann man aus diesen beiden Tabellen den ursprünglichen Buchungssatz wieder rekonstruieren? Nur auf den ersten Blick, sobald ein weiterer Buchungssatz hinzugefügt wird, ist es nämlich nicht mehr möglich zu entscheiden, zu welchem Buchungssatz eine Kontoveränderung gehört. Aber dieser Mangel ist leicht zu beheben. Wir fügen einfach ein zusätzliches Attribut in die Tabelle Kontoveränderungen ein, nämlich den Fremdschlüssel BuchungsNr. Ergebnis: Tabelle Buchungssatz LfdNr Datum Person Grund 1 2004-09-15 Eisen-Meier Einkauf Tabelle Konten Nr Konto Betrag BuchungsNr 1 Rohstoffe 1000,-- 1 2 Vorsteuer 160,-- 1 3 Verbindlichkeiten 1160,-- 1 Was wir eben gemacht haben ist eigentlich nicht der übliche Weg, nämlich durch Probieren eine Datenbank aufgestellt. Besser ist es, sich rechtzeitig das Klassendiagramm zu überlegen. Oft kommen wir zu einer guten Lösung, wenn wir uns die Objekte der realen Welt vorstellen und daraus Klassen bilden und Beziehungen entwerfen. Dies ist bei einer recht abstrakten Welt der Buchungssätze nicht immer so einfach. Auch sollte dieses Beispiel nochmals verdeutlichen, was man unter Redundanz versteht. Übung macht den Meister... Übung 1: Stelle für die eben über die Tabellen hergeleitete Datenbank das Klassendiagramm auf. Übung 2: Gib den SQL-Befehl an, mit dem aus dieser Datenbank der aktuelle Kassenbestand abgefragt werden kann. Übung 3: Gib den SQL-Befehl an, mit dem alle Kontenbestände abgefragt werden können. Übung 4: Konten werden in der Regel geordnet in einer bestimmten Reihenfolge ausgegeben! Ergänze das Klassendiagramm um die notwendigen Attribute, um eine geordnete Ausgabe zu ermöglichen. Übung 5: Gib abschließend den SQL-Befehl an, mit dem die Konten sortiert ausgegeben werden können! Lösungsansatz Übung 1: BUCHUNGSSATZ{ID:integer; Datum:date;Person: VARCHAR(60); Grund: VARCHAR(60)}, KONTENVERÄNDERUNG{ID:integer;Konto:VARCHAR(30);Betrag: DECIMAL(10,2); Buchungsnr:integer} Lösungsansatz Übung 2: SELECT sum(betrag) from buchung where Konto="Kasse" Lösungsansatz Übung 3: SELECT Konto, sum(betrag) from buchung GROUP BY Konto Lösungsansatz Übung 4: Die Klasse BUCHUNGSVERÄNDERUNG wird um das Attribut Reihenfolge ergänzt (integer). Lösungsansatz Übung 5: SELECT Konto,sum(betrag) from buchung GROUP BY Konto ORDER BY Reihenfolge Aufgaben Hausaufgaben Aufgabe 1 Wieder ist es nicht getan, die Sache theoretisch durchzulesen. Erfolgreich wirst du erst, wenn du es selbst ausprobiert hast. Setze das Buchhaltungsmodell in eine Datenbank um. Gib einen (oder mehrere) Buchungssätze in das System ein und führe Abfragen durch. Beachte dabei, dass sich bei jedem Buchungssatz die Summen der Kontoveränderungen ausgleichen müssen. Buchhalter teilen die Beträge ein in Soll und Haben, wobei sie der Übersichtlichkeit SOLL links und HABEN rechts schreiben, in der Datenbank ist es durch positive und negative Zahlen realisiert. Positive Zahlen sind SOLL und negative HABEN. Die Betragssummen eines Buchungssatzes müssen immer 0 ergeben. Aufgabe 2 Gib folgende Buchungssätze in die Datenbank ein. Beachte, welche Daten in welche Tabelle eingefügt werden müssen und welche Beträge positiv und welche negativ sein müssen. Nr. Datum Person Grund Sollkonot> Sollbetrag Habenkonto Habenbetrag 1. 01.01.2004 selbst Umbuchung Kasse 100,-- Bank 100,-- 2. 05.01.2004 Müller Lohn Lohnaufwand 1500,-- Bank 1100,--             sonst. Vbl.  400,--  Grundwissen Redundanz: Bezeichnung dafür, dass eine Information mehrmals in einer Datenbank gespeichert ist, ohne zusätzliche Informationen zu geben. Noch ein Beispiel gefällig: In der Schule gibt es eine Tabelle mit Lehrern und eine Tabelle mit Klassenleitern. Frau Müller heiratet und heißt fortan Schmidt. Ihr Name muss in zwei Tabellen geändert werden. Ihr Name war also redundant vorhanden. Diese Redundanz hätte man vermeiden könne, indem man in die Tabelle der Klassenleiter nur die Personen-ID aufgenommen hätte und nicht den Namen. Redundanz lässt sich ganz vermeiden, oft entstehen dann aber sehr viele Klassen und viele Beziehungen, die die Datenbank auch wieder unübersichtlich werden lassen. Oftmals geht man daher einen Kompromiss ein und lässt Redundanz in geringem Umfang zu. Je mehr du mit Datenbanken arbeitest, um so leichter bekommst du ein Gefühl für gutes Datenkbank-Modellieren. Copyright 2003 - Letzte Änderung am 4. September 2004