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 von 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?

12_55_08-PèDFOfficerData.jpg

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 hatte20_09_39-Werkzeugleiste.jpg

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.

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

[Delbor]

Hi jobo

Zitat:

Ziel ist es, Haushaltskosten zu verwalten und die zugehörigen Dokumente als PDF in einer DB vorzuhalten.

Tatsächlich sind hier im wesentlichen die Verträge und Rechnungen gemeint. Mir fällt aber auf, dass ich bislang eine "Dokumententabelle" vergessen habe für Korrespondenzen aller Art.

Zitat:

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)

Die automatische Verlängerung betrifft zB. die Krankenkasse, wobei jedesmal jährlich eine neue Police mit einem neuen Betrag, aber den ursprünglichen Konditionen(Grundversicherung + diverse allfällige Zusatzversicherungen). Gültig ist hier der ursprüngliche Vertrag, nur eben, dass die fällige Prämie jedes Jahr neu berechnet wird. Das bedeutet: In diesem Fall gibt es jährlich eine neue Police, die aber keine Rechnung ist - die müsste dann in der von mir bislang vergessenen "Dokumententabelle" abgelegt werden.
Dagegen gibt es andere Verträge, die ohne vorliegende rechtzeitige Kündigung auch automatisch verlängert werden, aber ohne dass sich der Betrag ändert.

Grundsätzlich denke ich, sollte es in einem Privathaushalt ausreichen, solche unterschiedlichen Rechnungen nicht in verschiedenen Tabellen zu führen. Ausnahme könnte ein Haushalt sein, der in Wertpapiere diverser Art investiert. Das würde wohl zu einigen zusätzlichen Tabellen führen.

Gruss
Delbor

[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

[Delbor]

Hi hstreicher

Zitat von hstreicher:

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

Stimmt. Pascal akzeptiert keine Bezeichner mit Umlauten.

Zitat von hstreicher:

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

Das erinnert mich an die Webseite meiner Bank. Da werden neuerdings auch alle Buchungen untereinander aufgeführt. Sowas nennt sich dann 'modernes Webdesign' - ich finde es nur wesentlich unübersichtlicher.
Andere Webseiten wurden auch 'modernisiert' und präsentieren sich nun auf einem Desktop genau so, wie auf einem Mobile - man darf auch genauso oft Scrollen. Nur scrollt eine Mausradumdrehung nicht so weit wie ein Fingerwisch - ich empfinde diesen 'Modernisierungswahn' schlicht und einfach fürchterlich.
Im Code ist das auch nicht gerade Zielführend: du musst (d.h. das SQL) jede Zeile lesen und auf Vorzeichen prüfen. Im Falle einer Anwendung wie die von mir geplante fällt dies wohl weniger ins Gewicht, aber bei bei Millionen von Datensätzen sieht das anders aus.
Ich bin mir nicht sicher, ob eine weitere Normalisierung im Bereich der Kontotabelle Sinn macht, nichtzuletzt eben auch wegen der zu erwartenden Datenmenge.
Andrerseits müssten in der eigentlichen Kontotabelle nur die Datensätze mit dem richtigen Index (Integer) gelesen werden.

Gruss
Dellbor

[Delbor]

Hi p80286

Zitat von 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.

Sowas nachvollziehen zu können, ist sicher wichtig. Ob eine spezielle Kündigungstabelle allerdings Sinn macht, bin ich mir nicht ganz sicher. Ich hab andernorts erwähnt, dass ich vergessen habe, eine Dokumententabelle mit ins Modell einzubeziehen. Andrerseits - eine Dokumententabelle wäre für Dokumente inklusive jeglicher Korrespondenz zuständig. Eine Kündigungstabelle könnte so eine Dokumententabelle entlasten.

Gruss
Delbor