Zum Inhalt springen
  • 0

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


nmike

Frage

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:

image.png.b9a925a2742606610e4ca7ba1efbbbca.png

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 von nmike
Link zu diesem Kommentar
Auf anderen Seiten teilen

7 Antworten auf diese Frage

Empfohlene Beiträge

  • 1

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 0
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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 0
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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 0
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. :)

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 0

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!

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 0
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

Link zu diesem Kommentar
Auf anderen Seiten teilen

Dein Kommentar

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.

Gast
Diese Frage beantworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...