Hilfe bei Datenbank design

D

Dev0x

Neuer Benutzer
Beiträge
4
Hallo zusammen.

ich bin mir gerade etwas unsicher mit dem Design von 2 Tabellen aus meinem aktuellen Projekt und bräuchte mal kurz eine zweite Meinung.

Es geht darum einen User (userTabelle) als Stellvertreter eines Departments (departmentTabelle) festzulegen.

Regeln:

1 Mitarbeiter kann nur einem Department angehören

(Pro Department gibt es nur einen Stellvertrerer )

In einem Fall Ausnahme Fall sind ALLE Mitarbeiter eines Departments Stellvertreter

Hier ist ein Ausschnitt meines momentanen DB-Designs: http://fs5.directupload.net/images/160809/voyt5qv2.png

Wie sollte ich das am besten machen?
1) Sollte ich das über die userID verknüpfen
2) Verknüpfen über die deputyOfDepartmentID
3) Evtl. sowas wie junction tables einsetzte

Was mein ihr?
 
Werbung:
Ah danke, den kannte ich noch gar nicht...
Ich will ne zweite Meinung und da mir da momentan niemand mehr antwortet, ich aber noch offene Fragen habe und voran kommen muss frag ich hier.
 
Es gibt Forenregeln, hier wie da. Dazu gehört u.a., daß man kein Crossposting machen soll, das gilt allgemein als unhöflich.
 
Kann ich ja auch verstehen, allerdings ist die Frage hier modifiziert (verändertes Design, weiterer Lösungs vorschlag) und es ist ja nicht so das ich zeitgleich in 2 Foren frage. Ich hab um Erklärung gebeten und keine bekommen nach ca 3h. Ich muss voran kommen. Villt. besitzt du ja die Freundlichkeit meine Verwirrung zu beheben, wo ist mir im Endeffekt egal.

Sorry für das Crossposting, aber ich bin gerade verwirrt und will es klären. Wenn auf eine Frage nicht geantwortet wird, suche ich nach weiteren Möglichkeiten.

Lies dir mal beiden Fragen durch. Es sind unterschiedliche. Nur weil das Thema das gleiche ist, ist es trotzdem noch eine andere Frage.
 
pff is gut... der Typ der unerlaubt andauernd Werbung für seine kack PostgreSQL -DB macht, will mir hier einen von Foren-moral erzählen.
 
Ich kann hier in der Firma den Link nicht öffen, aber mit zwei Tabellen hast du mindestens eine zu wenig.
Zwischen Mitarbeiter und Abteilung eine weitere Tabelle einziehen, die die Rolle des Mitarbeiters in der Abteilung festlegt.
Dort auch einen Unqiue Constraint auf die Kombination Userid und Abteilungsid um sicherzeustellen, dass ein Mitarbeiter nur in einer Abteilung sein kann.

Interessant wird es, wenn ein Mitarbeiter mehrere Rollen innerhalb einer Abteilung besitzt, dann braucht man ein etwas anderes Konstrukt mit einer vierten Tabelle (ansonsten funkt uns der Unique Constraint rein).
 
drdimitri schrieb:
Dort auch einen Unqiue Constraint auf die Kombination Userid und Abteilungsid um sicherzeustellen, dass ein Mitarbeiter nur in einer Abteilung sein kann.
Zum Vergrößern anklicken....

dieser kann gleich als PK fungieren.

Interessant wird es, wenn ein Mitarbeiter mehrere Rollen innerhalb einer Abteilung besitzt, dann braucht man ein etwas anderes Konstrukt mit einer vierten Tabelle (ansonsten funkt uns der Unique Constraint rein).
Zum Vergrößern anklicken....

Depends.
 
akretschmer schrieb:
dieser kann gleich als PK fungieren.
Zum Vergrößern anklicken....
Sofern es wirklich technische Werte sind und nicht etwa eine echte "fachliche" Personalnummer widerspiegeln kann man das machen, würd ich aber nicht.
Mit dieser Zuordnungstabelle könnte man z.B. auch offene Stellen abbilden. Die Userid würde dann null bleiben bzw. werden.
Davon abgesehen: Ich würd einer Tabelle immer ein eigenes, technisches PK Feld geben wenn nicht irgendwas ganz seltsames dagegen spricht.

Edit: Hab grad das Tabellendesign gesehen. Da fehlts noch an ein paar anderen Enden...
 
Zuletzt bearbeitet:
Dev0x schrieb:
Es geht darum einen User (userTabelle) als Stellvertreter eines Departments (departmentTabelle) festzulegen.

Regeln:

1 Mitarbeiter kann nur einem Department angehören

(Pro Department gibt es nur einen Stellvertrerer )

In einem Fall Ausnahme Fall sind ALLE Mitarbeiter eines Departments Stellvertreter
Zum Vergrößern anklicken....
Durch die Ausnahme ist das erste keine Regel mehr. Du kannst jetzt entweder ein DB-Schema entwickeln, das 1D = 1 Stellvertreter als Regel beinhaltet und eine extra Lösung für den Spezialfall erstellen oder die Regel aufheben und die Lösung allgemeiner formulieren. In fast allen Fällen ist der erste Weg sehr schlechtes Design. Du wirst dann später z. B. keinen zweiten Stellvertreter hinzufügen können.

Die Lösung sollte also in einer extra Verknüpfungstabelle liegen, die Department und user verbindet. Allerdings würde ich auch die Stellvertreter-Rolle generalisieren: Jeder User sollte zu dem Department auch in mehreren Rollen stehen können, die wiederum in einer gesonderten Tabelle aufgelistet werden. In etwa so:

utd_user_to_department
utd_id | utd_user_id | utd_dep_id | utd_role_udr_fk

udr_user_department_role
udr_id | udr_role

Selbst wenn Du gerade ausschließlich Stellvertreter anlegen sollst, würde ich es so machen. Denn dann kann irgendwann jemand das Design einfach erweitern und den Vorsitzenden oder Pressesprecher etc. einfügen, indem er einfach die Rolle hinzufügt. Reduzierst Du die Tabelle auf eine Stellvertreter-Tabelle, dann wird es später ein großer Aufwand sein, eine neue Rolle hinzuzufügen. Weil dann nicht nur ein DB-Eintrag hinzugefügt werden muss, sondern auch auch im Programm-Code der Zugriff auf eine neue Tabelle implementiert werden muss.

PS. Möchtest Du sicherstellen, dass jeder User auch sicher nur in einem Department zugeordnet wird, dann sind "Regeln" der geeignete Weg. Damit können Anforderungen an neue Einträge formuliert werden, z. B. in der utd-Tabelle, dass nicht zu einer user_id zwei verschiedene dep_id erlaubt sind. Ich warne aber davor, da sehr restriktiv zu sein. In Universitäten gibt es z. B. häufig Fälle, wo ein Wissenschaftlicher Mitarbeiter eine halbe Stelle von einem Lehrstuhl und eine zweite von einem anderen hat. Wenn die dann in unterschiedlichen Departments sind, wird ein Schlaukopf auf die Idee kommen, einfach die Person ein zweites Mal einzutragen, um die Restriktion zu umgehen und damit fangen die Probleme erst richtig an, weil andere Programme sich auf die Einmaligkeit der Personen im System verlassen. Rules also nur so setzen, wo Du mit Sicherheit sagen kannst, dass es nie eine Ausnahme geben wird.
 
Zuletzt bearbeitet:
Ohne jetzt alles gelesen zu haben sei vielleicht noch ein Gedanke eingeworfen: Wechseln deine Stellvertreter auch mal und muss das festgehalten werden? In diesem Fall lohnt sich vielleicht gleich ein n:m Beziehung.
 
Werbung:

Ähnliche Themen

I
Fragen zum Datenbank-Design
Antworten
4
Aufrufe
5K
Injector
I
Zurück
Oben