Einfaches Datenbankmodell

[Delbor]

Hi zusammen

Da ich nicht wirklich Datenbankentwickler bin, sondern solches zur Speicherung meiner Anwendungsdaten einsetze, entwickle ich zur Zeit erst mein 2. DB-Modell:
Anhang 49386
Ziel ist es, Haushaltskosten zu verwalten und die zugehörigen Dokumente als PDF in einer DB vorzuhalten. Und da es sich erst um mein 2. DB-Modell handelt, dachte ich mir, ich frage hier mal nach, ob und welche Fehler ich da eingebaut habe.

• Zentral ist/sind mal vorerst der oder die User.
• Der hat eines oder mehrere Einkommen. (Desshalb hier eine 1:n-Beziehung, n auf Seite Salärtabelle)
• Auch eine Adresse hat er in der Regel nur eine. Wenn mehrere Adressen vorhanden wären, gibt es davon nur eine Erreichbarkeits-Adresse. (Desshalb hier eine 1:1-Beziehung).
• Gleichzeitig hat er mehrere Verträge mit verschiedenen Firmen, (1:n-Beziehung, n auf Seite Firmen)
• wovon einer oder mehrere Verträge mit der selben Firma abgeschlossen sein können. (1:n-Beziehung, n auf Seite Verträge)
• Eine oder mehrere Rechnungen können von ein- und derselben Firma stammen (1:n-Beziehung, n auf Seite Vertrag.) Hier bin ich mir aber nicht ganz im klaren. Zum einen gibt es unbefristete Vertäge (Wohnungsmiete), die periodisch fällig werden (Monatsmiete) und zum andern gibt es Verträge, die jeweils eine Periode gültig sind (zB. ein Jahr) und sich ohne erfolgte Kündigung automatisch teils zu neuen Bedingungen (Krankenkassenprämien) verlängern. Ich denke schon, dass dies eine 1:n-Beziehung ist ( n auf Seite Rechungen)
• Und zu guter letzt gibt es die Kontotabelle. hier werden alle Bewegungen sämtlicher Konti festgehalten, bzw. zum Teil auch vorausberechnet. Dabei gilt: eine Rechnung wird immer einem einzigen Konto belastet. Trotzdem ergibt sich hier wohl eine 1:n-Beziehung, da mehrere, sich wiederholende Rechnungen (Monatsmiete zB) immer dem selben Konto belastet werden.

Kann dieses Modell stimmen?

Gruss
Delbor

[Delphi.Narium]

Klingt von der Beschreibung her logisch und schlüssig.

Kurze und knappe Beschreibung. Wenn man ein Modell in der Art beschreiben kann, dann passt das meist auch ;-)

Der Anhang lässt sich leider nicht anzeigen, gibt (momentan) 'ne Fehlermeldung. Könntest Du das bitte mal prüfen?

[p80286]

Ich würde eine Vertragstabelle und eine Kündigungstabelle nutzen. Sollte sich aus irgendwelchen Gründen die Kündigungsmodalität ändern könnte man das u.u. nachvollziehen.

Gruß
K-H

[Delbor]

Hi zusammen

Ich habe den Anhang nun nochmal angehängt, diesmal so wie ich es sonst immer mache, also in der Fusszeile.

Zitat:

Zitat von Delphi.Narium (Beitrag 1405772)

Klingt von der Beschreibung her logisch und schlüssig.
Kurze und knappe Beschreibung. Wenn man ein Modell in der Art beschreiben kann, dann passt das meist auch ;-)
Der Anhang lässt sich leider nicht anzeigen, gibt (momentan) 'ne Fehlermeldung. Könntest Du das bitte mal prüfen?

Anhang 49391

Gleichzeitig hab ichs jeetzt nochmal inn den Text eingebettet, zum Unterschied zu vorhin setzte ich den Cursor jedoch ans Ende der letzten Zeile.
Ein 2. Anhang zeigt das Werkzeug, das ich benutzt habe, nachdem ich das Jpeg hochgeladen hatteAnhang 49392

In der Vorschau sind beide Bilder sichtbarr - das war auch vorhin so.

Gruss
Delbor

[jobo]

Mir ist nicht genau klar, was Du mit "Dokumente" meinst. Die Verträge/Scans?
Ich würde an der Stelle mal einwerfen, dass es neben den Laufzeiten auch folgende "Phänomene" gibt:
- automatische Verlängerung
- Abschlagszahlung (plus Nachzahlung/Erstattung)
- Konditionsänderung
- Beitragsänderung (KFZ, Schadensklasse, Unfall, .. usw)

Ggf. macht es Sinn, die Verträge zu historisieren oder (wechselnde) Optionen anhängen zu können oder die Beiträge separat mit jeweiligem Gültigkeitsdatum (auch voraus) abzulegen.
Ob man, wie in Salär, die Referenzen alle redundant ablegt, ist m.E. Geschmacks- eher aber Performancefrage. Eine Rechnung wird immer eindeutig zu einer Firma und einem Vertrag gehören, das muss in Salär nicht mitgeführt werden.
Es wird dann "schwieriger" innerhalb von Salär zu filtern, aber man spart umgekehrt bei der Befüllung einigen Aufwand. Aus der Rechnungs_id kann man die weiteren Referenzen ermitteln.
Bei Millionen von Einträgen spart man sich bei gewissen Abfragen und Reports mit der reduntanten Variante einige Joins und wird schneller, aber darum geht es hier vermutlich nicht.

[hstreicher]

Hallo

erst mal würde ich auf Umlaute bei Tabellen- und Feldnamen verzichten.

ich würde noch eine Tabelle KontoKopf einführen als 1:N auf Tbl_Konto (Bewegungen)
KontoKopf
ID, Beschreibung ,Adress_ID

Im Tbl_Konto würde ich Bank Varchar durch eine Konto_ID als Foreign Key auf Tabelle KontoKopf ersetzen

Bei Konto würde ich keine Gutschrift/Belastungsfelder führen sondern einfach Betrag Positiv ist eine Gutschrift , negativer Wert eine Belastung ,
macht das aufaddieren einfacher

mfg Hannes

[Delphi.Narium]

Warum gibt es in der TBL_Firma Adresse, Strasse, Nr. und Postleitzahl, wenn die Tabelle doch auch noch 'nen Verweis auf TBL_Adressen hat?

Da scheint mir was redundant zu sein.

Adressen gehören in TBL_Adressen. TBL_Firma bekommt nur 'ne Fremdschlüssel auf TBL_Adressen. Aber die Adressdaten werden dort nicht abgelegt.

Nr. ist vom Typ Int. Was soll das sein? Die Hausnummer? Was wäre dann mit der Hausummer 1a?

Die Tabellen TBL_Firma und TBL_Konto scheinen in dem Bild nicht vollständig enthalten zu sein, könntest Du das noch nachbessern?

[Schokohase]

So eine Firma kann ja auch mal umziehen dann ändert sich eben die Adresse oder wird gekauft und benennt sich um (z.B. von CodeGear nach Embarcadero).

Bei diesem Datenmodell würde so eine Änderungen auch die historischen Rechnungen betreffen, obwohl die Dokumente da etwas anderes sagen werden, denn die sind statisch.

FYI: Grundsätzlich ist es ein sehr schlechter Ansatz eine Anwendung mit dem Datenbank-Modell zu beginnen. Uncle Bob sagt dazu: "The database is a detail and not the center of our application." und weiterhin, dass die Auswahl der konkreten Datenbank erst ganz zum Schluss fällt.

[Delphi.Narium]

Echt jetzt?

Bei Datenbankanwendungen halte ich das Datenmodell für wesentlich. Wenn das stimmt, wird die entsprechende Software geschrieben. Hat die letzten Jahrzehnte immer gut geklappt.

Allerdings sind die meisten Kolleginnen und Kollegen, die es andersherum versucht haben, mehr oder weniger kläglich gescheitert oder haben sowohl Software, als auch Datenmodell permanent anpassen müssen.

Aber vielleicht hab' ich ja auch Pech gehabt und nur die Ausnahmefälle kennen gelernt ;-)

Jedenfalls halte ich es hier konkret für durchaus sinnvoll, sich erstmal Gedanken über die benötigten Daten und die Datenhaltung zu machen und dann die entsprechende Software zu schreiben.

[Schokohase]

Ja.

Hmmm, Datenbankanwendung - daher wird das wohl kommen, denn eine Datenbankanwendung muss eine Datenbank haben, sonst ist es ja nur eine Anwendung.

Oder ist es tatsächlich einfach nur eine Anwendung und egal, wo und wie diese die Daten speichert, solage es passiert?

Noch wahrscheinlicher ist es wohl, dass diese Datenbankanwendung ihren Ursprung in den Datenmodulen und den sich darauf tummelnden RADz-Fatz-Connection-Query-Komponenten. Die laufen tatsächlich nur mit Datenbanken, was es aber nicht besser macht.

Das wird auch der Grund für die Aversion gegen Unit-Tests sein, denn diese sind bei so einem Ansatz gar nicht möglich. (Bitte nicht mit Integration-Tests verwechseln)

Wenn man an dem RAD-Ansatz mit Connection-Query-Komponente auf Form/DateModul festhalten will, dann rüclt man tatsächlich die Datenbank in das Zentrum der Anwendung.

Will man das nicht, dann muss man hier einen gänzlich anderen Weg gehen, sonst passiert genau das, was du beschrieben hast.