Hilfe bei erstem Versuch eines ER-Modells für Objekte

[DDL2024]

Hallo,
in meiner Firma fliegen mittlerweile sehr viele Exceltabellen rum mit zum Teil redundanten Daten, die dann alle aktualisiert werden müss(t)en.
Deswegen wollte ich schauen, ob ich nicht eine kleine Datenbank basteln könnte, um dieses Chaos wenigsten teilweise zu ordnen.

Leider starte ich hier mit sehr wenig Vorwissen, aber jeder Menge Lernfreude.
Dank einiger YouTube-Videos habe ich eine Idee bekommen, wie man für den Entwurf ER-Modelle anwendet. Da ich jetzt aber schon Fragen dazu hätte, aber niemanden kenne, der sich damit auskennt, wollte ich es mal hier versuchen.

Wir betreuen als Dienstleister Objekte, die behördlich überwacht werden.

Zu meinem ersten ER-Modell-Entwurf hätte ich folgende 2 Fragen:

1. jedes Objekt wird von je einem Chef, einem direkten Betreuer und einem Berichtersteller betreut. Der Betreuer hat allerdings 1-3 Stellvertreter, wobei direkte Betreuer eines Objekts gleichzeitig Stellvertreter für andere Objekte sind.
Wie bilde ich das am besten ab? Mit einer Spezialisierung der Entitätstyps "Personal" (PDF1) oder über Attribute (PDF2)? Bei PDF1 hätten die Subentitätstypen allerdings keine (sinnvollen) Attribute. In PDF2 würde ich die Subentitätstypen als Ausprägungen des Attributs "Verantwortungsbereich" einsetzen, müsste dann aber irgendwie die Stellvertreter einbringen können.
Beides scheint mir nicht ganz richtig zu sein.

2.Die Fachbehörden beraten je mehrere rechtl. Behörden, haben allerdings je einen Ansprechpartner pro rechtl. Behörde. Ich könnte also wie in PDF2, die Ansprechpartner beider Behörden als Attribute zum Entitätstyp "rechtl. Behörde" packen. Kann ich dann aber noch abfragen, welche Ansprechpartner die einzelne Fachbehörde hat? Oder muss ich es eher wie in PDF1 darstellen?

Ich wäre dankbar für jeden kleinen Hinweis oder Tipp.

Viele Grüße
Thea

 

[ukulele]

Schönes Projekt, kann Spaß machen

zu 1.)

Der Betreuer hat allerdings 1-3 Stellvertreter, wobei direkte Betreuer eines Objekts gleichzeitig Stellvertreter für andere Objekte sind.

Zunächst mal würde ich deine Formulierung hinterfragen. Hat wirklich die Person, die als Betreuer fungiert der mit dem Objekt in Beziehung steht, einen Stellvertreter oder hat die Position "Betreuer" des Objektes einen oder mehrere Stellvertreter, die Konstellation kann aber von Objekt zu Objekt variieren? Ich vermute Letzteres. Also Projekt A hat Betreuer a und stellvertretenden Betreuer b, Projekt B hat ebenfalls Betreuer a aber Stellvertreter für a in Projekt B ist nicht b sondern z.B. c.

Ich bin in der Theorie nicht mehr ganz so fit. Die Umsetzungen in PDF2 sieht nicht ganz richtig aus, PDF1 bin ich bei der Notation nicht sicher. Du nimmst ein Objekt und machst eine n:m Beziehung zu einer Entität Person (Attribute Personalnr, Vorname, Nachname). Eine Person kann mit beliebig vielen Objekten in Verbindung stehen und zwar in beliebiger Funktion, oder nicht? Also Person a kann in Projekt A Betreuer sein und in Projekt B stellvertretender Betreuer. Dann gehört das Attribut "Funktion" auch in die Zwischentabelle, so wie "seit" und auch eventuell "bis".

So wärst du jedenfalls maximal flexibel und kommst nie in die Situation, das du eine Person mehrfach anlegen musst. Die Person kann ja auch irgendwann mal aufsteigen und dann ist sie nicht mehr Betreuer sondern Chef von das Janze.

Was dann schwieriger ist sind Einschränkungen. Z.B. das a und b maximal als Betreuer, nie aber als Chef eingesetzt werden können. Das könnte man über eine Qualifikation als Attribut* in Personal abbilden. Es muss dann entweder in SQL oder auch im Frontend eine Regel gebaut werden die verhindert, das man Tätigkeiten oberhalb seiner Qualifikation wahr nimmt. Das geht aber durchaus, ist nur nicht unbedingt im ERD abbildbar.

* Auch Qualifikationen können erworben werden. Wenn man das mit abbilden möchte, braucht man wieder eine eigene Entität Qualifikation der man die Personen aus Personal n:m zuordnet. It will be wild

zu 2.)
Ich glaube PDF1 ist hier eher richtig. Wenn jetzt eine Fachbehörde mehrere rechtl. Behörden beraten kann, eine rechtl. Behörde aber immer nur von einer Fachbehörde beraten wird und zusätzlich der Ansprechpartner nicht von der Fachbehörde sondern von der Konstellation rechtl. Behörde/Fachbehörde abhängt, dann kannst du den Ansprechpartner für die rechtl. Behörde bei der Fachbehörde (es kann ja nur eine geben) direkt mit der rechtl. Behörde verknüpfen (gerne auch als Beziehung und eigene Entität, nicht als Attribut).

Alternativ kann man für die Abbildung der Beziehung zwischen den Behörden auch eine Zwischentabelle benutzen und die Person mit Ansprechpartnerfunktion der Zwischentabelle zuordnen. Man kann dann über Regeln verhindern, das eine rechtliche Behörde gleichzeitig von mehreren Fachbehörden beraten werden kann.

Muss ich zur Not mal aufmalen. Entscheidend ist aber natürlich, was sein kann und was nicht.

 

[DDL2024]

Vielen Dank!
Nach einer Nacht drüber schlafen kommt hier Version 3:
1. Der Entitätstyp Personal wird schon vorher in die Funktionsgruppen aufgeteilt und diese direkt in Beziehung zum Objekt gebracht. Die zeitlichen Komponenten seit/bis werden Attribute vom Objekt. Würde das dann funktionieren, wenn "hauptverantwortlich/stellvertretend" ein Attribut von der Beziehung "betreut" ist?

2. Bei der Fachbehörde hätte ich Entitätstyp und Attribut umgedreht und "Name der Fachbehörde" als Attribut von Ansprechpartner Fachbehörde gemacht. Könnte ich dann aber noch abfragen, a) welche Ansprechpartner eine Fachbehörde hat, b) welche rechtl. Behörden von ihr beraten werden und c) welche Objekte von diese Fachbehörde betroffen sind?

 

[ukulele]

1. Der Entitätstyp Personal wird schon vorher in die Funktionsgruppen aufgeteilt und diese direkt in Beziehung zum Objekt gebracht.

Das kann man so machen, wie allerdings sieht das dann bei dir genau in der Praxis aus? Gibt es wirklich drei Tabellen Betreuer, Berichtersteller und Chef oder ist das eine Tabelle und die Unterscheidung wird anderweitig definiert? Ich würde letzteres bevorzugen, da alle personenbezogenen Entitäten unabhängig von ihrer Funktion ja identisch sind und auch über eine längere Zeit die Rolle wechseln können. Stichwort müsste Generalisierung sein.

Die zeitlichen Komponenten seit/bis werden Attribute vom Objekt.

Jein. Attribute zu einem Zeitraum kannst du fast überall haben. Ein Objekt existiert von bis. Ein Chef kann vorn Baum fahren und ist tot, dann wird ein neuer Chef eingesetzt. Die Frage ist, wie bildet das Datenmodell das ab? Man kann die alte Information überschrieben und nur den Ist-Zustand abbilden. Eventuell will man aber auch einen Wechsel auf einer Position nachhalten können.

Würde das dann funktionieren, wenn "hauptverantwortlich/stellvertretend" ein Attribut von der Beziehung "betreut" ist?

Ja, das funktioniert.

2. Bei der Fachbehörde hätte ich Entitätstyp und Attribut umgedreht und "Name der Fachbehörde" als Attribut von Ansprechpartner Fachbehörde gemacht. Könnte ich dann aber noch abfragen, a) welche Ansprechpartner eine Fachbehörde hat,

Nicht so gut. Hat eine Fachbehörde mehrere Ansprechpartner steht die Information "Name Fachbehörde" redundant in der Tabelle. Ändert sich der Name tatsächlich mal, muss er mehrfach angepasst werden damit er gleichbleibend ist. Dann kann man das Abfragen, ist aber kein normalisiertes Datenmodell an der Stelle.

b) welche rechtl. Behörden von ihr beraten werden und c) welche Objekte von diese Fachbehörde betroffen sind?

Das Abfragen geht grundsätzlich auch in nicht normalisierten Daten.

Es gibt kein absolut Richtig, du bildest ja nicht absolut alle Informationen der Realität komplett durchnormalisiert ab. Es kommt aber durchaus schnell mal vor das man nicht weit genug voraus gedacht hat was man eventuell mal abbilden will.

 

[DDL2024]

OK, letzter Versuch vor meinem Urlaub:

1. So scheint mir jetzt die Betreuungssituation am besten abgebildet zu werden. das Attribut "Primäre Qualifizierung" bei Personal wäre die Haupttätigkeit der Person (Betreuer, Berichteersteller, irgendwas), das Attribut "Verantwortungsbreich" bei "wird betreut" hingegen die spezifische Tätigkeit bezüglich des Objekts. So wäre es maximal flexibel. Gäbe es hier noch Einwände?

2. Den Ansprechpartner der Fachbehörde als Attribut von der Beziehung "wird beraten" zu setzen fühlt sich nicht ganz richtig an, weil er im reelen Leben der Fachbehörde untergeordnet ist, aber so ist es vielleicht für die Datenbank die beste Lösung?

Könnte ich dann aber noch abfragen, a) welche Ansprechpartner eine Fachbehörde hat, b) welche rechtl. Behörden von ihr beraten werden und c) welche Objekte von diese Fachbehörde betroffen sind?

Würden die o.g. Abfragen so gut funktionieren?

 

[ukulele]

1. So scheint mir jetzt die Betreuungssituation am besten abgebildet zu werden. das Attribut "Primäre Qualifizierung" bei Personal wäre die Haupttätigkeit der Person (Betreuer, Berichteersteller, irgendwas), das Attribut "Verantwortungsbreich" bei "wird betreut" hingegen die spezifische Tätigkeit bezüglich des Objekts. So wäre es maximal flexibel. Gäbe es hier noch Einwände?

Das sieht für mich erstmal ganz gut aus.

2. Den Ansprechpartner der Fachbehörde als Attribut von der Beziehung "wird beraten" zu setzen fühlt sich nicht ganz richtig an, weil er im reelen Leben der Fachbehörde untergeordnet ist, aber so ist es vielleicht für die Datenbank die beste Lösung?

Das kann ich nicht so genau beurteilen, aber ich weiß was du meinst. Da die 1:n Beziehung ja keine eigene Tabelle braucht, müsste das Attribut "Ansprechpartner Fachbehörde" eine Spalte in der Tabelle "recht. Behörde" werden. (Das gleiche gilt aber eigentlich auch für "Ansprechpartner rechtl. Behörde" und Tabelle "Betreiber".) Das wirkt zunächst falsch, kann aber funktionieren.

Es ist auf jeden Fall einfacher, das erstmal so abzubilden und man kann es später erweitern auf ein Modell mit n:m Beziehungen zwischen den Behörden. Auch könnten die Ansprechpartner innerhalb von Behörden in einer eigenen Entität besser aufgehoben sein, ich weiß ja nicht, wie viele Ansprechpartner sich da um mehrere Behörden bzw. Betreiber kümmern. Als jemand, der die Materie nicht so gut kennt, würde ich erstmal einen flachen Ansatz wie hier versuchen.

 

[DDL2024]

Vielen Dank,
das hat mir schon viel geholfen. Jetzt mach ich mich erst mal an die Normalisierungen. Da, glaub ich, wird sich noch mal einiges klären und verschieben.

 

[ukulele]

Es wird sich vermutlich auch nicht vermeiden lassen, das das Modell irgendwann nochmal angepasst wird. Damit sollte man rechnen.