Datenbank Normalisierung Ticketsystem

J

Jonas09

Benutzer
Beiträge
8
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
 
Werbung:
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 :)
 
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.
 
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ß!
 
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)
);
 
Dazu noch Constraints, daß valid_to > valid_from ist und sich die Ranges nicht überschneiden. Ach neee, soll ja mit MySQL laufen ...
 
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.
 
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
 
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?
 
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.
 
Vielen Dank!

Das Attribut "Fertiggestellt" ist unnötig das stimmt.
Das mit dem Abteilungswechsel habe ich momentan noch nicht beachtet, das kommt jetzt! :)
 
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")
 
Werbung:
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!
 
Zurück
Oben