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

Datenbank Normalisierung Ticketsystem

Dieses Thema im Forum "Datenmodellierung, Datenbank-Design" wurde erstellt von Jonas09, 2 Juli 2015.

  1. Jonas09

    Jonas09 Benutzer

    Hallo zusammen,

    wir sind in unserem Unternehmen dabei ein eigenes Ticketsystem zu entwerfen.
    Nun habe ich die Aufgabe bekommen die MySQL Datenbank zu entwerfen.
    Also habe ich mir die für uns wichtigen Attribute rausgesucht, aufgestellt und diese versucht zu Normaliseren (bis zur dritten NF).
    Nun wäre es toll wenn jemand von euch mal kurz darüber schauen könnte um zu gucken ob so noch Redundanzen entstehen können.

    Rot sind PKs
    Blau sind FKs
    Grün sind die Beziehungen


    Vielen Dank schonmal & Gruß
    Jonas


    Datenbank Normalisierung.png
     
  2. Distrilec

    Distrilec Datenbank-Guru

    Deine "Relation Problem" ist falsch.
    (Davon abgesehen das "User ID" sowohl für ein Ticket als auch für ein Problem hinterlegt ist...)
    1. Wenn man nur einen User und eine Kategorie pro Problem hinterlegen kann, kann man sowohl Kategorie als auch User bei "Anhang" hinterlegen.
    2. Wenn man mehrere User und eine Kategorie pro Problem hinterlegen kann, gibt es eine Redundanz bei der "Kategorie ID"
    3. Wenn man mehrere Kategorien anlegen kann aber nur einen User gibt es eine Redundanz bei der "User ID"
    4. Wenn man sowohl mehrere User als auch mehrere Kategorien anlegen kann, gibt das ganze sowieso nur völligen Schwachsinn :)
     
  3. ukulele

    ukulele Datenbank-Guru

    Zusätzliche Ideen (Distrilec hat ja schon die Fehler beschrieben):
    1) Kann ein User mehreren Abteilungen angehören kannst du immer nur eine Abteilung abbilden.
    2) Kann ein User die Abteilung wechseln kannst du immer nur den aktuellen Zustand abbilden, die Tickets ändern sich also ggf. im Nachhinein.
    3) Notiz und Anhang ist zwar nett, aber vieleicht wären Felder wie Fehler/Problem und Lösung gut.
    4) Sind User immer Sachbearbeiter oder die Leute mit dem Problem? Das jeweils andere würde ich auch mit abbilden wollen.
    5) In einem Ticketsystem sollte man eventuell neben Kategorie auch noch nach Geräten / Servern / Software oder dergleichen unterscheiden können, wo der Fehler aufgetreten ist.
     
  4. Jonas09

    Jonas09 Benutzer

    Hallo,
    erst einmal vielen Dank für die Antworten.
    Ich bin die Normalisierung gerade nochmal in Ruhe durchgegangen und Distrilec hat recht, die Relation Problem ist völliger Schwachsinn.
    Es ist leider schon eine Weile her als ich das letzte mal so eine Normalisierung vorgenommen habe.

    Wir gehen erst einmal davon aus, dass der User nur einer Abteilung angehören kann.
    Ich hab vergessen dazu zu schreiben, dass dies erst einmal die Datenbank von den Leuten mit dem Problem ist (User).
    Die Idee mit den Geräte-Typen finde ich gut. Die werde ich mit Absprache des Leiters warscheinlich einbauen.

    Das Problem mit dem Abteilung wechseln fällt mir auch gerade auf. Nur wie bekomme ich das hin, dass wenn ein User die Abteilung wechselt die alte Abteilung bei alten Tickets beibehalten wird?

    Vielen Dank & Gruß!
     
  5. akretschmer

    akretschmer Datenbank-Guru

    Indem man vielleicht eine Gültigkeitszeitraum mitführt? In PG böten sich da Dateranges an.
     
  6. Distrilec

    Distrilec Datenbank-Guru

    Eine Tabelle Beschäftigungszeitraum.
    Dann gibst du sowohl deinem Ticket als auch der Abteilung eine Zeitstempel
    Code:
    Create Table emp_employed_time As
    (
    emp_no Varchar2(12)
    ,valid_from Date Not Null
    ,valid_to Date
    ,department_id Varchar2(12)
    );
     
  7. akretschmer

    akretschmer Datenbank-Guru

    Dazu noch Constraints, daß valid_to > valid_from ist und sich die Ranges nicht überschneiden. Ach neee, soll ja mit MySQL laufen ...
     
  8. ukulele

    ukulele Datenbank-Guru

    Die Beziehung wird dann zunächst mal von 1.n zu n:m und die Zwischentabelle nimmt dann den Zeitraum auf. Das Ticket sollte eigentlich sowieso ein Datum haben.

    Theoretisch ist es dann auch nicht mehr schwer eine zweite Abteilungszugehörigkeit parallel zu haben, aber in dem Fall muss das auch das Front-End darstellen können.
     
  9. Jonas09

    Jonas09 Benutzer

    Hallo zusammen,
    Vielen Dank für die ganzen Antworten.
    ich habe mein Modell nochmal überarbeitet und bin auf folgendes gekommen:

    Datenbank_Normalisierung_2.png


    Hier mal das ERM Modell, welches ich mir vorgestellt habe:

    User 1 [hat] n Ticket(s)

    Abteilung 1 [hat] n User

    Erst einmal abgesehen von den Datentypen und Attributen möchte ich nur wissen ob dies in der dritten Normalform vorliegt, damit ich ein grobes Modell habe mit dem ich arbeiten kann.

    Vielen Dank!
    Jonas
     
  10. ukulele

    ukulele Datenbank-Guru

    Ich würde sagen 3. NF ist gegeben außer das du für Fertiggestellt einen BOOLEAN und ein DATETIME hasst, ist nicht der BOOLEAN überflüssig wenn ein Datum gesetzt ist?
     
  11. akretschmer

    akretschmer Datenbank-Guru

    Da ist nicht beachtet, daß ein User die Abteilung wechseln kann.

    Code:
    test=# create table t_user(id int primary key, name text);
    CREATE TABLE
    Time: 6,120 ms
    test=*# create table t_abteilung(id int primary key, name text);
    CREATE TABLE
    Time: 2,952 ms
    test=*# create table t_user_abteilung(id_user int references t_user, id_abteilung int references t_abteilung, valid daterange, exclude using gist (id_user with =, valid with &&));
    CREATE TABLE
    Time: 4,345 ms
    
    Mal so als grobe Idee, wie man abbilden kann, in welcher Abteilung ein User zu Zeitpunkt X war.
     
  12. Jonas09

    Jonas09 Benutzer

    Vielen Dank!

    Das Attribut "Fertiggestellt" ist unnötig das stimmt.
    Das mit dem Abteilungswechsel habe ich momentan noch nicht beachtet, das kommt jetzt! :)
     
  13. Distrilec

    Distrilec Datenbank-Guru

    Was mir da noch so ein bisschen Fehlt:
    1. Wer hat das Ticket bearbeitet
    2. Wer hat was, wann und wo gemacht... (Bsp. "Support-Mitarbeiter x hat am 06.07.2015 um 10 Uhr angerufen, es war aber niemand erreichbar")
     
  14. Jonas09

    Jonas09 Benutzer

    Hallo zusammen,

    entschuldigt meine späte Rückantwort, aber ich hatte derweil etwas anderes zu tun.
    Ich habe meine Relationen erst einmal weiter an die EDV gegeben, die werden sich das nochmal angucken.
    Vielen Dank für die vielen Antworten, ihr habt mir echt weiter geholfen! :)
    Super Sache mit so einem Forum!
     
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