Office: Neues Datenmodell bewerten

Mahlzeit an die MOF User!

Ich habe mich sehr intensiv mit dem Thema Datenmodellierung beschäftigt. Ob nun hier, bei DBWiki, AEK s oder ähnliches. Trotzdem Maße ich mich ganz sicher nicht an, jetzt ein perfektes Datenmodell (gibt es sowas?) für mein Projekt gefunden zu haben. Vielmehr möchte ich jetzt offene Kritik von den Profi s hier im MOF entgegen nehmen und gffs Änderungen vornehmen, so daß ich zumindest sagen kann... "Besser geht s nicht".

Folgende Anforderungen sind gestellt und jetzt schon im Modell (Bild anbei):

1. Eine Person soll mehrere Personenarten haben können (z.B. Eine Rechtsanwalt kann auch Kunde sein) => tbl_Personendetails
2. Die Personen sollen zueinander in Beziehung gestellt werden können. (z.B. Müller ist der Rechtsanwalt von Meier) => tbl_PersonenBeziehungen (reflixive m:n Beziehung?)
3. Personen sollen Zentral in einer Tabelle und später Maske verwaltet werden.

Die Anforderungen müßen noch realisiert werden:

A. Eine Person soll mehrere Unterpersonen haben können. Unterpersonen sind z.B. bei einer Vesicherungsgesellschaft, die Vermittler oder Filialdirektionen.

Idee: Tabelle "tbl_Unterpersonen" m:n Beziehung zu tbl_Personen und tbl_Personen_1 (reflixive m:n Beziehung). Vielleicht noch eine Extra Tabelle, die die Art der Unterperson beschreibt.

B: Ansprechpartner zu einer Person. Hier bin ich mir nicht ganz sicher, ob ich auch die Tabelle Personen dafür verwende und mit reflexiven Beziehungen arbeiten soll.

Daten wie Telefonnummer, EMail etc kommen in eine Extratabelle und werden 1:n mit tbl_Personen verknüpft.

Ich würde mich echt freuen, wenn Ihr die eine oder andere Anregung hättet. Was kann ich man besser machen? Insbesondere tbl_Personendetails (m:n Beziehung?!?) ist mir selbst so in den Sinn gekommen und ich habe keine richtige "Bezeichnung" dafür finden können.

Bis vielleicht gleich... ich freu mich.*Smilie

:)

 

Auch wenn ich gewiß kein Profi bin weiß ich doch sicher, daß ein perfektes Datenmodell nur möglich ist, wenn ich den Ausschnitt der realen Welt, den ich beschreiben möchte, ganz genau beschrieben habe.
Ein Immobilienmakler sieht ein Haus anders als ein Architekt und ein Brandstifter hat auch eigene Vorstellungen von einem perfekten Haus.

 

Hi achtelpetit,

mein Glück das ich keine Brandstifter in meiner DB verwalte....*biggrin.gif*

 

Zum Glück, ja. Was verwaltest Du denn?

 

Ich habe schon seit 7 Jahren für einen Feund eine Datenbank am Wickel, die Versicherungsverträge, Immobilien und die dazu gehörigen Finanzierungen verwaltet.

Das alte Datenmodell ist SCHROTT, weil ich mich nicht so eingängig mit dem Thema der Datenmodellierung beschäftigt habe. Was sich jetzt rächt.

Jetzt erstelle ich das ganze NEU und möchte natürlich nicht gleich wieder enstcheidende Fehler einbauen, die sich nachher nur schwer aufheben lassen.

 

Die Perspektive ist also die eines Finanz- und Versicherungsmaklers?

 

Genau.

Und derzeit habe ich aber nur die "Personen" im Blickwinkel. Weiteres wie Finanzierungen und Objekte, Dokumentation und Dokumentenverwaltung kommt in den nächsten Schritten.

 

zu tbl_PersonenDetails:
Im Prinzip könntest du in gezeigten Fall auch ganz auf die Tabelle verzichten und eine 1:0/1-Beziehung direkt von tbl_Personen zu den Tabellen tbl_PersonenBanken usw. einrichten. Die Art ergibt sich bereits aus der Verwendung in den Tabellen *Banken, *Finanzaemter, ...

In deinem aktuellen Datenmodell könnte es eine Verknüpfungsungenauigkeit geben.
Beispiel: In tbl_PersonenDetail exisitiert ein Eintrag mit der PersonenArtId für Banken. Und nun nehmen wir an, diese PersonenDetailID auch in der Tabelle tbl_PersonenFinazaemter verwendet.

 

Was spricht dagegen die Struktur zu vereinfachen ? Ich denke in die Richtung (verkürzt ausgedrückt)
Tabelle Adressen
Tabelle Ansprechpartner der Adresse
Tabelle Adressfunktion (Bank, Finanzamt, Versicherung . . .)
Tabelle Beziehungen (Adresse 7 ist Versicherung von Adresse 22)

 

Hallo Josef,

wie willst Du dann sicherstellen, dass ein Bänker nicht gleichzeitig Finanzbeamter wird?
(In der heutigen Zeit ein nicht ganz unwichtiges Detail. *wink.gif* )

Im bisherigen Datenmodell könnte man dies durch einen eindeutigen Index auf die Spalte "PersonID" in der Tabelle "tbl_PersonenDetails" erreichen.

CU

 

Hallo Sascha,

was mich ein bischen stutzig macht ist das Feld "Nominalzins" in der Tbaelle "tbl_PersonenBanken".

Ist der Nominalzins tatsächlich von der Person des Bankmitarbeiters abhängig?
Oder hängt der Zinssatz eher von anderen Faktoren ab?
Kann sich der Zinssatz im Zeitverlauf ändern?

CU

 

Ich ging davon aus, dass genau das möglich sein soll und somit die 1:n-Beziehung zw. tbl_Personen und tbl_PersonenDetails Absicht ist.

Und wie verhindere dann, dass PersonenDetailID nicht mehrfach verwendet wird? *Smilie
... klar aus FE-Sicht wird das schon möglich sein, aber rein aus Datensicht, wird das schwierig bei Access.
Eine Lösung die mir dazu einfällt: in den Tabellen tbl_PersonenBanken usw. auch das Feld PersonenArtID im FK mitziehen und dort nur den passenden Wert per Einschränkung zulassen.

/edit: wenn ich über diese Variante genauer nachdenke, könnte das sogar ein "sauberes" Modell werden. *wink.gif*

Prinzip:
tbl_Personen: PK = PersonenID
tbl_PersonenDetail: PK = PersonenID + PersonenArtID
tbl_PersonenBanken: PK = BankID ; FK = PersonenID + PersonenArtID; PersonenArtID mit Wert-Einschänkung auf PersonenArtID = ID für Bank
... wobei imo PersonenID auch PK sein könnte falls BankID sonst nirgends als FK benötigt wird.

Über tbl_PersonenDetail werden die erlaubten "Personen-Arten" eingestellt. Später für Abfragen kann man aber den Umweg über tbl_PersonenDetail weglassen und von tbl_PersonenBanken direkt auf tbl_Personen zugreifen, wenn Daten beider Tabellen dargestellt werden sollen.

 

\@Thomas Möller: Da ist der Tabellennamen vielleicht ein bißchen verwirrend. In der tabelle tbl_PersonenBanken befinden sich die bankspezifischen Daten zu einer Person. Person ist in diesem Fall eine Bank (juristische Person).

Der Nominalzinsatz hängt von der Bank ab und kann sich auch ändern.

@Joseph: wie oben geschrieben, soll genau das möglich sein, eine Person kann mehrere Personenarten annehmen.

Das Prob kann doch nur auftauchen, wenn ich den bestehenden Datensatz in tbl_PersonenDetails ändere? Oder verstehe ich Dich da falsch? Mit dieser Variante wollte ich sicherstellen, das wenn ich die Personart ändere (bzw Datensatz aus tbl_Personendetails lösche) auch gleich den passenden Datensatz in der entsprechenden tbl_PersonenBanken...etc lösche.


Danke schon einmal vorab an Euch Dreien.

===> @Joseph: lese gerade Deinen nachtrag und versuche das in mein Spatzenhirn zu realisieren?*grins

 

\@Josef:

Also einen zusammengesetzten PK?

Du meinst aber hier keinen zusammengesetzten FK? (Gibts sowas?):

FK = PersonenID + PersonenArtID

Sonst habe ich Dich - so glaube ich - wohl richtig Verstanden. Soll ich mal umsetzten?

 

\@Sascha: ich meinte einen zusammengesetzten FK - so einer ist für die Verwendung eines zusammengesetzten PK erforderlich. *wink.gif*

Du könntest es zumindest mit einer Kopie deiner aktuellen DB ausprobieren.
Ob es sinnvoll ist, musst du entscheiden. *Smilie