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?

[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 von fwsp:

Entity Relationship

Danke

[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.

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.