Datenbankmodell bewerten

[hyperion]

Hallo,

für eine private Anwendung habe ich ein Datenbankmodell entworfen. Das Datenbankmodell umfasst im Moment zwei Bereiche.

Bereich 1: Fahrzeug

Hier sollen Daten zu Fahrzeugen gespeichert werden, sodass später mehrere Auswertungen erstellt werden können. Zum Beispiel welches Fahrzeug wann wohin bewegt wurde oder welche Kosten ein Fahrzeug verusacht hat. Natürlich sollen mehr Auswertungen möglich sein.

Bereich 2: Geld

Hier sollen Daten zu Geldbewegungen gespeichert werden, sodass später mehrere Auswertungen erstellt werden können. Zum Beispiel wer wann wieviel Geld zu welchem Zweck ausgegeben hat oder wer wieviel Geld in einem bestimmten Zeitraum ausgegeben hat. Natürlich sollen mehr Auswertungen möglich sein.

Da es mein erstes Datenbankmodell ist wollte ich mir von Euch Rat holen, was ich noch verändern sollte.

Mein Ziel ist es eine Datebank zu schaffen die...

...später noch einfach zu erweitern ist

...performant ist

...international ist

...möglichst alle Fehler ausschließt

Zusammengefasst möchte ich ein Datenbankmodell, das so gut ist, dass dieses auch von einer großen Firma hergenommen werden könnte.

Ich habe zwei Bilder angehängt, die das Datenbankmodell zeigen. Kurz zur Erklärung:

>| bedeutet n

|| bedeutet 1

Eine rote Raute bedeutet FK

Eine blaue Raute bedeutet NN

! bedeutet PK

Freue mich über jeden entdeckten Anfänger- oder auch Nichtanfängerfehler.

Gruß hyperion

[flashpixx]

Ich habe nur mal schnell drüber geschaut und z.B. ist mir nicht klar warum Du Person und Login als 1:n modellierst. Man bindet ja normalerweise ein Login an eine Person, so dass man daraus eine Enitity machen könnte.

Ähnliches würde ich bei den Sprachen sagen, denn eine Sprache (Amtssprache) ist dem Land zugeordnet, d.h. innerhalb Deiner Countyentitity würde man den Verweis auf die Sprache speichern.

Als generelles Fragezeichen ist, warum Institution an der Adresse hängt, vom Designaspekt würde ich die Person einer Institution zuordnen, wobei sich dann ja die Adresse automatisch für die Person ergibt.

Wofür die Owner brauchst ist nicht klar, denn ich würde es als überflüssig sehen und direkt die PersonenID verwenden usw.

An vielen Punkten fehlt mir einerseits das Verständnis, da Du die Problemstellung nicht im Detail genannt hast, denn meine Punkte können durchaus falsch sein. Ich finde so auf den ersten Blick das ganze etwas zu sehr auseinander gerissen.

[hyperion]

Ich habe nur mal schnell drüber geschaut und z.B. ist mir nicht klar warum Du Person und Login als 1:n modellierst. Man bindet ja normalerweise ein Login an eine Person, so dass man daraus eine Enitity machen könnte.

Ich denke mit Login meinst du User. Also ich habe mir das so vorgestellt, dass eine Person mehrere User haben kann mit denen er sich anmelden kann. Zum Beispiel hat hier vermutlich der Forenadmin einen Adminaccount und einen normalen Account.

Ähnliches würde ich bei den Sprachen sagen, denn eine Sprache (Amtssprache) ist dem Land zugeordnet, d.h. innerhalb Deiner Countyentitity würde man den Verweis auf die Sprache speichern.

Ja stimmt, da werde ich bei County noch eine LanguageID einbauen.

Als generelles Fragezeichen ist, warum Institution an der Adresse hängt, vom Designaspekt würde ich die Person einer Institution zuordnen, wobei sich dann ja die Adresse automatisch für die Person ergibt.

Ich glaube Du versteht unter Institution jetzt etwas anderes wie ich. Ich habe dafür vielleicht auch nicht den richtigen englischen Begriff gefunden. Mit Institution meinte ich so etwas wie eine Bank. Und eine Bank ist für mich unabhängigi von einer Person. Allerdings ist da noch ein Fehler. Ich würde sagen, dass zwischen Institution und Address eine 1:n Beziehung gehört und nicht n:1. Eine Institution kann mehrere Adressen habe und eine Adresse gehört nur zu einer Institution.

Wofür die Owner brauchst ist nicht klar, denn ich würde es als überflüssig sehen und direkt die PersonenID verwenden usw.

Ja beim Modellieren hatte ich auch zuerst in der Tabelle Vehicle PersonID anstatt OwnerID stehen. Allerdings fande ich dass PersonID nicht so selbsterklären sei wie OwnerID. Bei OwnerID weiß man finde ich automatisch, dass es sich da um den Besitzer des Fahrzeugs handeln muss. Und da ich es auch ungünstig fand ein Feld OwnerID mit einem Feld ID aus der Tabelle Persons zu verknüpfen, habe ich eine neue Tabelle Owner erstellt.

An vielen Punkten fehlt mir einerseits das Verständnis, da Du die Problemstellung nicht im Detail genannt hast, denn meine Punkte können durchaus falsch sein. Ich finde so auf den ersten Blick das ganze etwas zu sehr auseinander gerissen.

Hmm ja die Problemstellung. Also das Projekt mache ich privat und nur für mich. Ich wollte mal ein Portal aufziehen, mit mehreren Anwendungen, zur Pflege privater Daten, wo ich bestimtme Auswertungen machen kann. Eigentlich brauche ich sowas nicht, aber da ich mich sowieso für Java EE interessiere, habe ich mir etwas rausgesucht, wo ich zumindest ein wenig Verwendung für habe. Applikationsserver und Datenbankserver sind aktuell schon mehr oder weniger eingerichtet und nun wollte ich das Datenbankmodell erstellen. Danach kommt die Programmierung. Als erste Anwendungen habe ich eben nun Geld- und Autoverwaltung vorgesehen. Wichtig für mich ist es eigentlich, mal ein Projekt so umzusetzen wie es in einer Firma geschieht. Aus dem Bauch raus würde ich aber sagen, dass man eine Datenbank so aufbauen sollte, dass später die Datenbank auch an neue Problemstellungen angepasst werden kann.

Meinst Du mit auseinander gerissen, dass ich zuviele Tabellen habe? Was würdest Du denn zusammenfassen?

Vielen Dank für deine Zeit die Du dir genommen hast.

Gruß hyperion

[MartinSt]

Hallo

Mit Institution meinte ich so etwas wie eine Bank. Und eine Bank ist für mich unabhängigi von einer Person.

Im Sinne deines Modells hast du damit recht, denn deine Personen sind immer natürliche Personen, wobei es rechtlich (in Dtschland) auch jurist. Personen, Personengesellschaften u.a. gibt, die Geld verwalten oder Autos besitzen und mieten können.

Wenn so etwas für deine Problemstellung relevant ist, würde ich überlegen, die Person abstrakt zu machen und mit entsprechenden Ableitungen der natürlichen, juristischen Person etc. zu arbeiten.

Gruß Martin

[flashpixx]

Also wenn Du so etwas freiwillig zur Übung machst, finde ich das wirklich gut.

Als erste Anwendungen habe ich eben nun Geld- und Autoverwaltung vorgesehen.

Also ich würde da dann eher eins von beiden machen. Du wirst dann mit der Zeit sehen, dass Du an manchen Stellen eh noch einmal nachbessern musst.

Wichtig für mich ist es eigentlich, mal ein Projekt so umzusetzen wie es in einer Firma geschieht. Aus dem Bauch raus würde ich aber sagen, dass man eine Datenbank so aufbauen sollte, dass später die Datenbank auch an neue Problemstellungen angepasst werden kann.

Meinst Du mit auseinander gerissen, dass ich zuviele Tabellen habe? Was würdest Du denn zusammenfassen?

An einigen Stellen schon, z.B. mit dem Owner. Denn Du hast im Grunde nur einen Feldnamen geändert und das über eine neue Entity modelliert. Ziel der Datenbank sollte sein annähernd redundanzfrei die Daten mit minimalsten Beziehungen zu speichern.

Ansonsten aber schon wirklich gut gemacht, ich hätte wohl eher was aus dem täglichen Umfeld genommen, als so ein eher abstrakteres Beispiel. Aber mach mal so weiter

[Carnie]

Eine Institution kann mehrere Adressen habe und eine Adresse gehört nur zu einer Institution.

Das muss nicht immer so sein. Das eine Institution mehrere Adressen haben kann ist klar aber ich denke zu einer Adresse können auch mehrere Institutionen gehören. In grossen Bürogebäuden sind oftmals mehrere Firmen ansässig.

[hyperion]

Wenn so etwas für deine Problemstellung relevant ist, würde ich überlegen, die Person abstrakt zu machen und mit entsprechenden Ableitungen der natürlichen, juristischen Person etc. zu arbeiten.

Die Begriffe die Du hier verwendest kenn ich nur im Zusammenhang mit Objektorientierung. Es ist mir nicht bekannt, dass ich bei Datenbanken etwas ableiten könnte.

An einigen Stellen schon, z.B. mit dem Owner. Denn Du hast im Grunde nur einen Feldnamen geändert und das über eine neue Entity modelliert.

Dann würdest du mir empfehlen, die Tabelle Owner zu entfernen und das Feld OwnerID zu PersonID zu ändern?

Gruß hyperion

[flashpixx]

Es ist mir nicht bekannt, dass ich bei Datenbanken etwas ableiten könnte.

Das ist durchaus üblich, nennst sich dann EERD und wird auch häufig verwendet