Information ausblenden
Willkommen im Forum für alle Datenbanken! Registriere Dich kostenlos und diskutiere über DBs wie Mysql, MariaDB, Oracle, Sql-Server, Postgres, Access uvm

Hilfe bei Datenbank design

Dieses Thema im Forum "Datenmodellierung, Datenbank-Design" wurde erstellt von Dev0x, 9 August 2016.

  1. Dev0x

    Dev0x Neuer Benutzer

    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?
     
  2. akretschmer

    akretschmer Datenbank-Guru

  3. Dev0x

    Dev0x Neuer Benutzer

    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.
     
  4. akretschmer

    akretschmer Datenbank-Guru

    Es gibt Forenregeln, hier wie da. Dazu gehört u.a., daß man kein Crossposting machen soll, das gilt allgemein als unhöflich.
     
  5. Dev0x

    Dev0x Neuer Benutzer

    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.
     
  6. akretschmer

    akretschmer Datenbank-Guru

    Du hast eine ganz schöne Erwartungshaltung an Deine Helfer. Viel Erfolg da noch.
     
  7. Dev0x

    Dev0x Neuer Benutzer

    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.
     
  8. drdimitri

    drdimitri Datenbank-Guru

    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).
     
  9. akretschmer

    akretschmer Datenbank-Guru

    dieser kann gleich als PK fungieren.

    Depends.
     
  10. drdimitri

    drdimitri Datenbank-Guru

    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: 9 August 2016
    akretschmer gefällt das.
  11. akretschmer

    akretschmer Datenbank-Guru

    Auch eine Idee ;-)
     
  12. Tom.S

    Tom.S Fleissiger Benutzer

    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: 12 August 2016
    akretschmer gefällt das.
  13. akretschmer

    akretschmer Datenbank-Guru

    ich denke mal, Du meinst 'Constraints'.
     
  14. ukulele

    ukulele Datenbank-Guru

    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.
     
  15. Tom.S

    Tom.S Fleissiger Benutzer

    Stimmt.
     
    akretschmer gefällt das.
Die Seite wird geladen...

Diese Seite empfehlen

  1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden