ER Modellierung

[Janosh]

Hi zusammen

Ich möchte ein ERM für eine Buchhaltungs-Software erstellen.

Ist das ein Thema, das ich auch hier in diesem Forum ansprechen darf? Es bezieht sich ja vorerst eigentlich nicht direkt auf Delphi, auch wenn ich es dann später in Delphi realisieren werde.

Falls ja.. so möchte ich mal kurz die Entitäten auflisten, die ich bis jetzt habe. Denkt ihr, dass dies eine gute Basis wäre? Was müsste ich noch ändern oder hinzufügen?

tbl_Buchungen
ID
Geschäftsfall-Nr
Buchungsdatum
Mandanten-Nr
Konto-Nr
Betrag (+/-)
Fremdwährungsbetrag
Buchungstext
Menge
Referenz-Nr
Vertrags-Nr

tbl_kontos
ID
Konto-Nr
Bezeichnung
Währungs ID
Anfangsbestand
group_id
konto-typ (1=aktiv, 2=passiv, 3=aufwand, 4=ertrag, 5=hilfskonto wie z.b. kostenträger,kostenstelle,kundennummer etc)

tbl_fremdwährungen
...
tbl_kontogruppen
...
tbl_mandanten
...

Grüsse,
Janosh

[mkinzler]

Bei tbl_Buchungen fehlt das Gegenkonto.

MySQL 4.1 ist u.U. nicht das geeignete datenbanksystem ( wenn MYSQL dann= >5)

[Daniel G]

Kurze Frage:

Wofür steht ER? Ich möchte ja nicht dumm sterben, und "Emergency Room" wird's in diesem Fall sicher nicht sein, näch? :stupid:

[fwsp]

Entity Relationship

[Phoenix]

Der Kontotyp ergibt sich normalerweise aus der Kontonummer. Dafür gibts ja Kontenrahmen. z.B sind Erlöse nach dem Datev-Kontenrahmen die 4000er und Verbindlichkeiten die 3000er.

Also brauchst Du den Kontentyp nicht noch extra zu hinterlegen sondern es reicht, den verwendeten Kontenrahmen einmal zentral anzugeben.

[Daniel G]

Zitat:

Zitat von fwsp

Entity Relationship

Danke :wink:

[Janosh]

Vielen Dank für die Antworten.

@mkinzler:
Um auch Sammelbuchungen zu unterstützen, hab ich kein Gegenkonto drin. Eine normale Buchung (z.b. Bank/Kasse) wird dann durch 2 Datensätze gespeichert, die aber natürlich die gleiche Geschäftsfall-Nummer haben. Ich denke, das sollte so funktionieren?

@Phoenix:
Ja, du hast recht. Aber andererseits könnte es "gefährlich" sein, in eine ID-Nummber Logik zu speichern. Ausserdem muss es ja nicht unbedingt ein fixer Kontenplan sein, das System sollte ja dann auch mandantenfähig sein. jeder Mandant könnte theoretisch seinen eigenen Kontenplan haben. Da fällt mir gleich auf, dass somit in tbl_kontos noch die Mandanten-ID fehlt.

Natürlich könnte ich auch MySQL 5 einsetzen. Inwiefern wäre das besser?

Gibt es weitere Sachen zu berücksichtigen?

Grüsse,
Janosh

[mkinzler]

Zitat:

@mkinzler:
Um auch Sammelbuchungen zu unterstützen, hab ich kein Gegenkonto drin. Eine normale Buchung (z.b. Bank/Kasse) wird dann durch 2 Datensätze gespeichert, die aber natürlich die gleiche Geschäftsfall-Nummer haben. Ich denke, das sollte so funktionieren?

Ja, bin halt "Datev"-verzogen. :mrgreen:

Zitat:

Ja, du hast recht. Aber andererseits könnte es "gefährlich" sein, in eine ID-Nummber Logik zu speichern. Ausserdem muss es ja nicht unbedingt ein fixer Kontenplan sein, das System sollte ja dann auch mandantenfähig sein. jeder Mandant könnte theoretisch seinen eigenen Kontenplan haben. Da fällt mir gleich auf, dass somit in tbl_kontos noch die Mandanten-ID fehlt.

Dann würde ich das mit dem Mandant verknüpfen und nicht mit der Buchung.

Zitat:

Natürlich könnte ich auch MySQL 5 einsetzen. Inwiefern wäre das besser?

Hängt eher an der Art der Storage Engine (Transaktionen).[ot] Aber mit v.5 werden halt Feature eingeführt, die bei anderen DBMS schon lange Standard sind[/ot]

[Janosh]

Zitat:

Dann würde ich das mit dem Mandant verknüpfen und nicht mit der Buchung.

Wie meinst du das genau?

Gut, MySQL 5 ist OK.

Ein weiteres Problem ist mir noch aufgefallen. Es gibt ja auch Debitoren und Kreditorenbuchungen. Eigentlich wollte ich allen Debitoren ein eigenens Konto vom Typ 5 (Hilfskonto) geben. Angenommen, es wird folgendes gebucht:
Debitor XYZ / Warenertrag 1000.--
Dann würden folgende Datensätze generiert:
a) Debitoren (Typ 1) 1000
b) Debitor XYZ (Typ 5) 1000
c) Warenertrag (Typ 4) -1000

Ich muss berücksichtigen, dass ich in einem neuen Geschäftsjahr auch die Debitorenposten der vergangenen Jahren haben sollte. Wer hat z.B. welche letztjährige Rechnung noch nicht bezahlt? Nach meiner obigen Idee wäre die Antwort dann im Konto "Debitor XYZ". Im Konto "Debitoren" hingegen sind alle per Ende Geschäftsjahr offenen Debitoren im Anfangsbestand aufsummiert.

Ich weiss nicht, ob diese Methode üblich bzw. praktisch ist. Wie soll ich das am besten machen?

Grüsse,
Janosh

[alzaimar]

Eine Sache solltes Du nie(!) machen: Tabellen über externe 'Nummern' verknüpfen. Du solltest in der Tabelle Buchungen keine Kontonummer eintragen, sondern eine 'KontoID'. Diese KontoID verweist auf eine Tabelle 'Buchungskonten'. Dort steht neben der KontoID (irgeneine eindeutige Nummer) auch die Kontonummer und weitere Informationen drin.

Weiterhin enthält die Tabelle eine 'MandantenNr', eine 'GeschäftsfallNr', eine 'Referenz-Nr' und eine 'Vertrags-Nr'. Wenn es sich bei diesen Nummern nicht nur um ein belangloses Merkmal handelt, sondern sich auf andere Objekte bezieht ('Mandanten' sind Objekte, Geschäftsfälle, Veträge und Referenzen u.U. auch) gilt für dies Nummern das Gleiche.

Ich glaube aber, das Dir das klar ist, weil Du diese 'ID'-Geschichte ansonsten durchziehst.

Desweiteren solltest Du dir jetzt schon Gedanken über die Nomenklatur der Tabellen und der -Felder machen. Es gibt verschiedene Ansätze, ich mache es so:
1.Jede Tabelle bekommt einen eindeutigen 2- oder 3-Buchstabigen Präfix. ('Bch' für Buchungen z.B., 'Knd', für Kunden etc.). Andere nehmen hier gleich den Tabellennamen. Ich bin schreibfaul, also 2-3 Buchstaben.
2.Jedes Feld besteht aus dem Präfix sowie der Beschreibung des Inhaltes. Die Kundennummer wäre dann z.B. 'KndNummer', der Name 'KndName' etc.
3.Felder mit semantisch gleichem Inhalt ('Nummer', 'Name', 'Beschreibung') heißen in den Tabellen auch gleich (Natürlich mit dem Präfix der Tabelle). Also ist die Kundennummer die 'KndNummer', die 'Buchungsnummer' die 'BchNummer', die Mandantennummer (wenn es eine Tabelle 'Mandanten' gibt) 'MndNummer' etc.
4.Die Primary-Keys heissen immer '<Präfix>ID', also z.B. 'KndID', 'BchID' etc.
5.Fremdschlüssel bilden die Außnahme: Sie heißen genauso, wie der Primary Key der referenzierten Tabelle.

Es gibt, denke ich, mindestens so viele Benennungssysteme wie Programmierer, insofern kannst Du dir etwas eigenes Ausdenken. Ich bin mit dem o.g. Schema aber immer sehr gut gefahren, denn man lernt die Präfixe schnell auswändig und muss bei den Standardfeldern nicht mehr nachschauen, wie die denn nun heißen.

[mkinzler]

Zitat:

Zitat:
Dann würde ich das mit dem Mandant verknüpfen und nicht mit der Buchung.

Wie meinst du das genau?

Wie Phoenix schon geschrieben hat, zu jdem mandant den Kontoplan ablegen und dort die Kontoart hinterlegen.

Zitat:

Ein weiteres Problem ist mir noch aufgefallen. Es gibt ja auch Debitoren und Kreditorenbuchungen. Eigentlich wollte ich allen Debitoren ein eigenens Konto vom Typ 5 (Hilfskonto) geben.

Nebenbücher gibt man am Besten Nummern in einem anderen Nummernbereich ( 10000/70000).

Zitat:

Ich muss berücksichtigen, dass ich in einem neuen Geschäftsjahr auch die Debitorenposten der vergangenen Jahren haben sollte.

Normalerweise macht man eine OPOS-Abgrenzung, so daß alle SB-Werte abgeschloßen werden und in neuen GJ wieder eingebucht werden. Wenn man Nebenbücher führt sollte man die auch Kontogeanu wieder einbuchen und nicht nur als Summe im Hauptbuch.

[marabu]

Hallo Janosh,

auch wenn dir das vielleicht nicht gefällt, aber kein einziger Beitrag in diesem thread - auch dein erster nicht - beschäftigt sich mit der Datenmodellierung nach dem Entity-Relationship-Model. Das ERM kennt z.B. keine Schlüsselfelder. Diese werden erst in einem späteren Schritt aus den relationships abgeleitet. Es empfiehlt sich übrigens die ER-Modellierung sauber durchzuhalten, da das physische Datenmodell dann fast mechanisch daraus abgeleitet werden kann. Und nicht zuletzt ist das ERM auch eine wertvolle Dokumentation.

Als Ausgangsbasis für deinen Anwendungsfall solltest du unbedingt ein Referenzmodell verwenden. Du hast dann noch genügend Arbeit damit zu begründen, warum du was weglassen oder hinzufügen willst. Eventuell soll dein Programm ja später einmal einer formalen Prüfung standhalten.

Freundliche Grüße vom marabu


Nachtrag:

Absolute Aussagen sind in der Regel angreifbar. Deshalb möchte ich meine eingangs gemachte kommentieren. Bevor ich bei der Modellierung Schlüssel einführe oder auch nur über sogenannte identifizierende Attribute nachdenke, steht eine konzeptuelle Modellierung an und die enthält lediglich die beschreibenden Attribute einer Entität. Dieser wichtige Schritt wird oft übersprungen. Die Schlüssel könnten später sogar automatisiert beigefügt werden. Also ERM ist schon richtig.

[DGL-luke]

[OT]

Wo bekomme ich denn saubere Dokumentation/Spezifikation oder sogar Programme für Entity-Relationship-Sachen?

[mkinzler]

http://www.fabforce.net/dbdesigner4/

[Janosh]

Danke für eure Antworten.

@alzaimar und marabu:
ich werde eure Hinweise und Tips bei der Modellierung berücksichtigen. Das sind wirklich gute Ideen.

@mkinzler:

Zitat:

Normalerweise macht man eine OPOS-Abgrenzung, so daß alle SB-Werte abgeschloßen werden und in neuen GJ wieder eingebucht werden. Wenn man Nebenbücher führt sollte man die auch Kontogeanu wieder einbuchen und nicht nur als Summe im Hauptbuch.

Was bedeutet OPOS?
Werden dann nur die noch offenen Debitoren und Kreditoren im neuen Geschäftsjahr wieder auf die einzelnen Debi/Kredi-Konten eingebucht?

Es ist so, dass mehrere Rechnungen unter einer Vertragsnummer zusammengefasst werden. Das heisst also, dass unter dem Vertrag ABC beispielsweise 5 Kundenrechnungen und entsprechend auch 5 Lieferantenrechnungen gebucht werden. Diese Rechnungen liegen aber zeitlich auseinander, möglicherweise auch in unterschiedlichen Geschäftsjahren. Es sollte nun möglich sein, dass ich nach Vertragsnummer alle Bewegungen zu diesem Vertrag abrufen kann.

Eigentlich wollte ich aus Performancegründen (ich rechne mit 150'000 Buchungen pro Geschäftsjahr) für jedes Geschäftsjahr eine neue Tabelle tbl_buchungen_2006 erstellen. Aber irgendwie geht das ja gar nicht, wenn ich nach einer Vertragsnummer suchen können möchte, welche sich über mehrere Geschäftsjahre verteilt. Wie könnte ich das am besten machen?

Grüsse,
Janosh

[mkinzler]

Zitat:

Was bedeutet OPOS?

Offene Posten

Zitat:

Werden dann nur die noch offenen Debitoren und Kreditoren im neuen Geschäftsjahr wieder auf die einzelnen Debi/Kredi-Konten eingebucht?

Ja.

Zitat:

Eigentlich wollte ich aus Performancegründen (ich rechne mit 150'000 Buchungen pro Geschäftsjahr) für jedes Geschäftsjahr eine neue Tabelle tbl_buchungen_2006 erstellen. Aber irgendwie geht das ja gar nicht, wenn ich nach einer Vertragsnummer suchen können möchte, welche sich über mehrere Geschäftsjahre verteilt. Wie könnte ich das am besten machen?

Die Größe einer Datenbank sollte kein Einfluß auf die Performance haben.

[Janosh]

Zitat:

Die Größe einer Datenbank sollte kein Einfluß auf die Performance haben.

Das heisst, du würdest alle Buchungen in der selben Tabelle speichern?
Nach 10 Jahren würde diese Tabelle dann ca. 1.5 Mio Datensätze umfassen. Ich denke, dass dies schon auch Einfluss darauf hat, wie lange eine Abfrgae auf diese Tabelle dauert (trotz optimalem Index).

Denkst du nicht? Oder kannst du das noch ein bisschen mehr ausführen?

Danke und Gruss,
Janosh

[mkinzler]

1,5Mio Datensätze dürften eigentlich kein Problem darstellen. Sonst mußt du halt die betreffenden Datensätze doppelt halten oder im Folgejahr nur auf das Vorjahr verweisen.

[marabu]

Hallo Janosh,

10 Jahre? Vollständig abgeschlossene Buchungsvorgänge wirst du am Ende jedes Geschäftsjahres archivieren - oder?

Freundliche Grüße

[Janosh]

@mkinzler:
Doppelt führen birgt natürlich die Gefahr von Inkonsistenz. Der Verweis aufs Vorjahr würde dieses Problem zwar lösen, aber es wären ja dann genau wieder so viele Datensätze vorhanden, als wenn man alles in der gleichen Tabelle hätte, nicht? Oder wie würdest du diesen Verweis datenbanktechnisch lösen?
Hast du schon mit MySQL Tabellen (myISAM) gearbeitet, welche 1.5 Mio. Datensätze umfassten? Ging das problemlos?

@marabu:
Das wäre natürlich eine gute Möglichkeit, Datensätze zu reduzieren. Wie wird jedoch ein abgeschlossener Buchungsvorgang definiert? Und was passiert, wenn man dann ein Jahr später nach allen Bewegungen eines bestimmten Vertrages suche möchte?

Grüsse,
Janosh

[Meniskusschaden]

Ich würde dem Anwender eine Funktion "Auslagern Geschäftsjahr" anbieten. Diese Funktion dürfte nur für abgeschlossene Buchungsjahre aufrufbar sein, für die auch sämtliche Offenen Posten ausgeglichen sind. Außerdem müsste es eine entsprechende Re-Importfunktion geben. Dann kann der Anwender selbst entscheiden, wie lange er die Daten für eine komfortable Recherche im Produktivsystem halten will.

[marabu]

Hallo Janosh,

Zitat:

Zitat von Janosh

Wie wird jedoch ein abgeschlossener Buchungsvorgang definiert? Und was passiert, wenn man dann ein Jahr später nach allen Bewegungen eines bestimmten Vertrages suche möchte?

zu den aktiven Buchungsdaten gehören allenfalls Buchungen, bei denen die Verjährungsfristen noch nicht abgelaufen sind.

Außerdem bedeutet die "Archivierung" von Buchungen ja nicht zwangsläufig, dass auf diese nicht mehr zugriffen werden kann. Sie sind halt kein Teil der Transaktionsdaten mehr und in der Regel nur noch per Lesezugriff für Auswertungen oder Recherchen erreichbar.

Etwas anderes ist die "Langzeitarchivierung", die regelmäßig eine Migration auf andere Datenträger mit sich bringt. Dann stellen selbst Lesezugriffe erhöhten Aufwand dar. Das sollte in deinem Anwendungsfall (Buchungsdaten) aber keine Rolle spielen.

Archivierung ist halt ein mehrstufiger Prozess und beinhaltet oft auch eine Informationsverdichtung - je älter die Daten sind, desto weniger interessieren Details.

Freundliche Grüße


Nachtrag: "Abschluß" ist auch ein terminus technicus der Buchhalter. Du wirst dich darum kümmern müssen, wie du Manipulationen an Daten verhinderst, welche gegenüber dem Finanzamt "abgeschlossen" wurden.