Einschätzung zu meinem ER Modell (Tickettool)

manerer

Benutzer
Beiträge
7
Hallo miteinander. Ich arbeite aktuell an einem Softwareprojekt von der Uni aus und bin im Bereich Datenbank zu gewiesen.

Wir Programmieren ein Tickettool, dass eigentlich recht Simpel funktioniert.
Wir haben einen Benutzer (Key: BenutzerID) der zu einer Abteilung gehört und ein Ticket eröffnet. Bei der Eröffnung des Tickets muss er die Abteilung (die das Ticket betrifft. Nicht seine eigene) und eine Kategorie (Eine Art vorauswahl von häufigen Problemen. Sieht man ja häufiger bei großen Kundensupports) angeben. Mit hilfe dieser Angaben wird das Ticket einem sogenannten Ticketbearbeiter zugewiesen. Dieser bearbeitet das Ticket und verändert den Ticketstatus (z.B offen etc.). Der Superadministrator legt jeden Benutzer und Ticketbearbeiter an (ein rein Firmen internes System) und verwaltet deren Accounts. Auch kann der Superadmin auf alle Tickets zugreifen und sowohl Kategorien, Statuse als auch die Abteilungen anpassen.

Eventeul können auch die Log_data weggelassen werden, weil sie bisher keine relevanten Funktionen haben. Optionales Feature.

Nun hätte Ich ein paar Fragen:
1.Was denkt ihr von meinem ER Modell. Was könnte man besser machen?

2. Wäre es ratsam statt 2 Tabellen (Benutzer und Ticketbearbeiter) lieber in 1 Tabelle zu speichern (Die Attribute unterscheiden sich maginal)?

3. Lieber den Status und den Anhang in der Tabelle Ticket als Spalte speichern oder als eigene Tabelle?
 

Anhänge

  • ERM - Modell gesammt Beta 2.pdf
    36,5 KB · Aufrufe: 12
Werbung:
Etwas nachvollziehbares. CREATE TABLE ist nachvollziehbar.
Hoffe ein EER Diagramm hilft dir Weiter.

Mir eine nur wichtig ob, dass so funktioniert oder ob Ich irgendwo einen Denkfehler gemacht habe :) Ist das erstemal, dass Ich mit Datenbanken arbeite und hatte in dem Bereich auch noch keine Vorlesungen. Deswegen ist hier viel learning by doing angesagt.

Kann das MySQL Workbench file leider nicht hier uploaden deshalb schick Ich dir den Link als PM
 
Nun hätte Ich ein paar Fragen:
1.Was denkt ihr von meinem ER Modell. Was könnte man besser machen?

2. Wäre es ratsam statt 2 Tabellen (Benutzer und Ticketbearbeiter) lieber in 1 Tabelle zu speichern (Die Attribute unterscheiden sich maginal)?

3. Lieber den Status und den Anhang in der Tabelle Ticket als Spalte speichern oder als eigene Tabelle?

  • Du bist nicht in der Lage, eine Historie zu machen. Üblicherweise ist Ticketbearbeitung ein N-stufiger Prozess.
  • wenn ein Mitarbeiter die Abteilung wechselt ist das nicht mehr nachvollziehbar
  • 2. ja
  • 3. ja, wenn da noch z.B. das Datum dazukommt

Ein Benutzer Modified Date - Feld sagt exakt was aus? Nicht viel, Du siehst nur, wann die letzte Bearbeitung war, nicht die davor, und nicht, was verändert wurde. Ob Du das brauchst, weiß ich aber nicht. Was Dein Superadmin soll ist mir nicht ganz klar. Evtl. ein primitiver Ersatz für Row level Security.

Andreas
 
"Ein Benutzer Modified Date - Feld sagt exakt was aus? Nicht viel, Du siehst nur, wann die letzte Bearbeitung war, nicht die davor, und nicht, was verändert wurde. Ob Du das brauchst, weiß ich aber nicht."

Ein genauer Bearbeitungsverlauf wäre zwar wünschenswert aber steht jetzt erstmal nicht im Vordergrund. Bisher als optionales feature geplant.

Der Superadmin hat die Aufgabe Benutzer und Ticketarbeiter anzulegen und zu pflegen. (Wir sind ja wie gesagt Firmenintern folglich sollte dass manuell Machbar sein.)
Außerdem hat er einsicht in alle Daten, Tickets etc. Deshalb ist auch der Foreignkey in den Beiden Tabellen zu finden.

Sorry der Begriff Row level security sagt mir leider aktuell nichts.

Datum hab ich noch hinzugefügt. Den Ticket_Body hab ich gemacht um zu verhindern, dass jedes mal der BLOB und TEXT mit geöffnet werden. Hoffe dass ist so korrekt

Aber danke schonmal für deine Antwort :)
 
Ja. Aber jeder, der die Tabellen lesen kann, kann ALLES lesen. RLS ermöglicht z.B. in einer Mitarbeiter-Tabelle, daß nur der Mitarbeiter selbst oder die Personalabteilung Mitarbeiter-Datensätze sehen können (also Maier kann seinen Datensatz lesen, Schulze seinen. Maier sieht Schulze nicht, Schulze nicht Maier. Personalabteilung sieht beide Records. Das ist RLS. Kann aber MySQL z.B. nicht.
 
Werbung:
Zurück
Oben