ER Modellierung

[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