ER-Diagramm für Abschlussprügung - zirkulärer Verweis?

[nmike]

Hallo zusammen,

ich sitze aktuell an meiner Dokumentation zum Abschlussprojekt für meine Ausbildung als FIAE. Hierbei entwickle ich eine Projektverwaltung, die intern genutzt werden soll. Ich bin jetzt dabei, einige Diagramme zu erstellen, unter anderem das ER-Diagramm. Dieses sieht momentan folgendermaßen aus:

Nun habe ich meiner Ansicht nach einen zirkulären Verweis. Hier bin ich mir aber der Ausnahmefälle, in denen das in Ordnung ist, leider nicht bewusst und habe auf die Schnelle auch keine vergleichbare Situation gefunden.

Kurze Erläuterung:

1. Jedes Projekt kann mehrere Mitarbeiter (User) haben, jeder Mitarbeiter kann an mehreren Projekten teilnehmen -> n zu m -> Zwischentabelle
2. Jede Aufgabe (Task) hat keinen oder einen Bearbeiter (User), jeder Bearbeiter kann 0 bis n Aufgaben haben -> 0..1 zu n
3. Jedes Projekt kann n Aufgaben haben, jede Aufgabe gehört zu genau einem Projekt

Meine Frage ist konkret: habe ich hierdurch den UML-Standard verletzt und wenn ja, wie könnte ich das Problem beheben? Ich komme leider selber gerade auf keine Lösung.

 

Vielen Dank und viele Grüße

Niklas

 

Bearbeitet 19. Oktober 2017 von nmike

[consul56]

Ich habe zunächst das Problem, dass eine n:m Beziehung beschrieben wird, aber es nicht zwangsläufig im Projekt einen User geben muss. Die Task-Relation muss die PK von Projekt und User als FK mitführen, aber die referentielle Integrität darf nicht eingeschalten werden, da es ja Tasks geben kann, die keinem Projekt und keine User zugeordnet sein müssen. So lese ich das bisher. Und da ergibt sich m.M. ein Widerspruch.

[consul56]

Genau, die Task-Relation sollte so modelliert werden, dass Project_ID und Task_ID zusammengesetzter PK sind und user_id nullable ist, jedoch keine FK. Project_ID ist gleichzeitig auch FK in der Task-Relation.

[Rienne]

vor 16 Stunden schrieb nmike:

Meine Frage ist konkret: habe ich hierdurch den UML-Standard verletzt

Korrigiert mich bitte, wenn ich falsch liegen sollte, aber ein ERD gehört doch eigentlich gar nicht zu den UML-Diagrammen, oder?

Also ich habe jedenfalls bezüglich UML damals nur folgende Einteilung gelernt:

Zitat

Structural UML diagrams

• Class diagram
• Package diagram
• Object diagram
• Component diagram
• Composite structure diagram
• Deployment diagram

Behavioral UML diagrams

• Activity diagram
• Sequence diagram
• Use case diagram
• State diagram
• Communication diagram
• Interaction overview diagram
• Timing diagram

Ansonsten sehe ich nicht, warum es keine "zirkulären Verweise" in einer Datenbankstruktur geben sollte.

Was mir allerdings auffällt:

Du hast bei der Relation Project-Task angegeben, dass ein Projekt aus 0 bis n Tasks bestehen kann. Sollte aber nicht jedes Projekt aus mind. einer Aufgabe bestehen?

Aber hätte die Tabelle "Task" nicht im Grunde die gleiche Aufgabe wie die Tabelle "ProjectUserRelation"? Denn im Grunde ist ja, sobald ein User eine Aufgabe annimmt, dieser User dann Teil des Projektes, zu dem die Aufgabe gehört.

Somit hättest du das Problem aus deiner Fragestellung auch nicht mehr. Aber das ist vermutlich etwas, was man auf beiden Wegen lösen kann oder eben noch von anderen Faktoren, die uns hier jetzt nicht bekannt sind, abhängt.

[Whiz-zarD]

vor 28 Minuten schrieb Rienne:

Du hast bei der Relation Project-Task angegeben, dass ein Projekt aus 0 bis n Tasks bestehen kann. Sollte aber nicht jedes Projekt aus mind. einer Aufgabe bestehen?

Nicht unbedingt. Man könnte doch auch ein Projekt anlegen, wo man noch nicht weiß, was die Tasks sind.

vor 29 Minuten schrieb Rienne:

Aber hätte die Tabelle "Task" nicht im Grunde die gleiche Aufgabe wie die Tabelle "ProjectUserRelation"? Denn im Grunde ist ja, sobald ein User eine Aufgabe annimmt, dieser User dann Teil des Projektes, zu dem die Aufgabe gehört.

Auch das kann man mit "nicht unbedingt" beantworten.
Möchte man im Vorwege Personen einem Projekt zuteilen, ohne dass sie explizit schon Tasks im Projekt übernommen haben, so braucht man diese Tabelle. 

Es ist also eine Frage des späteren Workflows der Projektverwaltung.

[Rienne]

vor 8 Minuten schrieb Whiz-zarD:

Man könnte doch auch ein Projekt anlegen, wo man noch nicht weiß, was die Tasks sind.

Es gibt ja auch nicht ohne Grund mehrere Lösungen zu einem Problem. Daher habe ich ja auch in meinem letzten Satz geschrieben, dass es noch auf andere Faktoren ankommen kann. Aber im "Endzustand" eines Projektes hat es auf jeden Fall mind. eine Aufgabe.

Das ist ja genauso, wie die Frage, ob man die Task Tabelle nicht eigentlich noch weiter auflösen könnte, da es ja auch immer wieder Redundanzen in den einzelnen Tasks zu Projekten gibt. Stichwort Normalisierung und 3. NF! Und ja ich weiß, dass ERD und Normalisierung 2 Paar Schuhe sind. Und ja ich weiß auch, dass es in der täglichen Anwendung von Datenbanken genug Gründe gibt, warum man diese eben nicht bis in die xte Normalform bringt.

Sowas bietet auf jeden Fall viel Raum zum Philosophieren und Diskutieren. Letzten Endes weiß nur der TO bzw. der Auftraggeber seines Abschlussprojektes, wie die einzelnen Bedingungen sein sollten.

[nmike]

Hallo ihr zwei,

vielen Dank schon mal für die Antworten!

Ein Projekt soll existieren können, ohne Aufgaben zu haben, damit diese nach und nach eingefügt werden können. Ebenso soll eine Aufgabe ohne Bearbeiter existieren können, damit diese später gepusht/gepullt werden können. Die Betrachtung ist aber definitiv wichtig!

Ich habe zwischenzeitlich einmal mit einem Lehrer von mir gesprochen, der bestätigte mir, dass das Diagramm so in Ordnung ist, da ich keine zirkulären, "harten" Referenzen habe.

 

Vielen Dank!

[nmike]

vor 14 Stunden schrieb consul56:

Ich habe zunächst das Problem, dass eine n:m Beziehung beschrieben wird, aber es nicht zwangsläufig im Projekt einen User geben muss. Die Task-Relation muss die PK von Projekt und User als FK mitführen, aber die referentielle Integrität darf nicht eingeschalten werden, da es ja Tasks geben kann, die keinem Projekt und keine User zugeordnet sein müssen. So lese ich das bisher. Und da ergibt sich m.M. ein Widerspruch.

Bei der Relation Project <-> Task muss ich dir widersprechen - die Kardinalität auf Seite des Projekts ist fest 1, ein Task muss also ein Projekt haben, ohne kann er nicht existieren.

Bei Task <-> User stimme ich dir zu - es gibt ein FK-Nullable-Feld, das auf den Benutzer referenziert, die Kardinalität zeigt aber 0 oder 1. Die Kardinalität ist absichtlich so gesetzt, damit Aufgaben am Projekt angelegt werden können, die später vom Projektleiter gepusht oder von Mitarbeitern gepullt werden - sprich einem Bearbeiter zugeordnet werden. Hierbei müsste ich nun meiner Ansicht nach das Feld "user_id" so modellieren, dass es zwar nullable, aber kein Foreign Key ist - sehe ich das richtig?

Vielen Dank schon mal für den Hinweis!

LG Niklas