Ticketsystem / Helpdesk / ... - ER-Modell

[mrhappiness]

Hi

Gebt mir doch bitte mal Feedback, ob euch das angehängte ER-Modell sinnvoll erscheint oder wo da eurer Meinung nach Potential ist

Erklärung:
Der prinzipiell geplante Ablauf ist:
Benutzer (reporting user) ruft verzweifelt bim Support Center an, die erfassen (recording user) sein Problem bzw. das Problem eines Kollegen (affected user) und weisen es einem Sachgebiet (assignee_group) und - falls möglich - auch gleich einem Mitglied dieser Gruppe (assigned_user).

Es ist möglich, dass während der Abarbeitung dieses Problems (oder der Bestellung von Hard-/Software) (kurz: Ticket) weitere User zusätzlich involviert werden (supplementary affeceted user)

Das Ticket kann in jedem Abarbeitungsschritt (ticket process) einen von mehreren Status (ticket_status) annehmen, währned des gesamten Prozesses ist es möglich, Dateien an das Ticket anzuhängen (attachment)

Die Benutzertabelle muss übrigens noch erweitert werden um Abteilungscode, Zimmer- und Telefonnummer, Kostenstelle, ...
Aber das tut ja für das Modell als solches nichts zur Sache

Modell:

[matz0r]

OffTopic:

---

Sry für den Missbrauch...
Aber wie hast du das Bild/Modell erstellt? Ich kenne kein Programm, dass das so gutaussehend macht

---

[admin]

Wir haben vor einigen Wochen ebenfalls mit einem Ticketsystem angefangen. Dein Modell entspricht in großen Teilen unserem - sieht so aus als wäre alles wichtige berücksichtigt. (bis auf nice to have)

[mrhappiness]

@matz0r
Hängt auch vom Aussehen des Autors ab *g*
Der Großteil kommt aber fom DBDesigner von fabforce

@Berni
Na das ist ja schonmal was.
Was genau verstehe ich unter nice to have?

[TBT]

Ein paar kleine Desginfehler mit den Primärschlüsseln, aber sonst brauchbar.

Wenn du zu anderen Tabellen verbindest, solltest du nicht identifizierende Schlüssel nehmen,
zB bei attachments, a_id ist der Primarschlüssel, bestimmt auto_increment,
was macht also die t_id auch im Primärschlüssel ?
Die t_id ist doch ein Fremdschlüssel, eventuell mit Index auf der Spalte.
Selbiges bei user_online und ticket_process

Falls du später mal zu anderen Datenbanksystem zB Informix wechselst, oder
gleich kompatibel sein willst, verwende als Tabellen- bzw Spaltennamen max 8 buchstabige Bezeichner

[mrhappiness]

Original geschrieben von TBT
was macht also die t_id auch im Primärschlüssel ?
Die t_id ist doch ein Fremdschlüssel, eventuell mit Index auf der Spalte.
Selbiges bei user_online und ticket_process

hab das falsche symbol erwischt (Identifying statt Non-Identifying) ;-)


Danke für den Tipp mit der Länge der bezeichner


Ich denke, nachdem ich hier nichts gegenteiliges gehört hab, werd ich mich so lansgam mal an die eigentliche umsetzung machen

[TBT]

was mir da noch aufgefallen ist, die Benutzer sollten einem Ticket später weiter Nachrichten hinzufügen können, und weitere Dateien dazupacken

[mrhappiness]

können sie doch

jeder neue schritt bei der abarbeitung des tickets ist ein weiterer eintrag in der tabelle ticket_process, dort gibt's ja die spalte tp_description

attachments können ja im modell beliebig viele zu einem ticket hinzugefügt werden, oder überseh ich was?

[TBT]

dann würde ich es anders machen ...

- eine Tabelle "ticket" welche die Hauptdaten enthält wie User, Zeit, Porblemkategorie ...

- eine Tabelle "tdetail" welche die Dateileinträge zum Ticket enthält, zb:
User schreibt: blablabla
Service schreibt: jfhjghgfhg
....

- die Dateianhänge gehören dann aber an die tdetails

- der Ticketstatus gehört zum ticket


ich mals mal auf die schnelle auf ( please hold the line ... )

[TBT]

so in etwa

http://tbt.dyndns.org/happy.png

[mrhappiness]

danke

werde die anhänge wahrscheinlich umhängen an ticket_process, den rest hab ich ja aber schon

und der status gehört für mich auch dazu, da sonst nicht mehr nachvolziehbar ist, wer wann welches ticket von welchem status in welchen status versetzt hat


die aufteilung in normale benutzer und servicemitarbeiter gefällt mir persönlich nicht so, da ich einen servicemitarbeiter, der für z. b. novell-berechtigungen zuständig ist, zusätzlich ja auch in der normalen benutzertabelle führen müsste, wenn er mal keine mails verschicken kann. wären doch redundante daten oder?

also hab ich mir gedacht, alle mitarbieter stehen in einer tabelle, mitarbeiter, die potentiell probleme bearbeiten können, kriegen ein anderes benutzerlevel als die, die nur probleme haben, aber nichts können
beispiel:
level 1: benutzer, die per telefon oder mail von problemen berichten
level 2: mitarbeiter, die die tickets erstellen können um die servicemitarbeiter zu entlasten
level 3: servicemitarbieter

[TBT]

Ich dachte, die Nutzer sind Nutzer von außen, wie zB der Service bei vielen Providern.
Sonst ist natürlich eine Tabelle besser, mit Kennung ob Service oder nicht.

Ich würde keine Level einführen, da dies bei mir oft zu Problemen führte,
wenn ich später neue Rechte erfunden habe, also die Level komplett neu
aufteilen müßte. Ich benutze auschliesslich eine "user", eine "rechte" und eine
m:n Tabelle zwischen den beiden.

Für das loggen wer, wann, was geändert hat, würde ich extra Tabellen machen.
Diese Daten haben ja mit den Arbeitsdaten nichts zu tun.

PS: mein Modell hat nur ein Grundgerüst, keine Ausarbeitung aller Entitäten

[mrhappiness]

Original geschrieben von TBT
Ich würde keine Level einführen, da dies bei mir oft zu Problemen führte,
wenn ich später neue Rechte erfunden habe, also die Level komplett neu
aufteilen müßte. Ich benutze auschliesslich eine "user", eine "rechte" und eine
m:n Tabelle zwischen den beiden.

klingt gut

Für das loggen wer, wann, was geändert hat, würde ich extra Tabellen machen.
Diese Daten haben ja mit den Arbeitsdaten nichts zu tun.

Naja, eine Änderung des Tickets ist ja eigentlich schon ein Bearbeiten der Arbeitsdaten

PS

ich weiß