1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen
  2. Willkommen im Forum für alle Datenbanken! Registriere Dich kostenlos und diskutiere über DBs wie Mysql, Oracle, Sql-Server, Postgres, Access uvm
    Information ausblenden

Einschätzung zu meinem ER Modell (Tickettool)

Dieses Thema im Forum "Datenmodellierung, Datenbank-Design" wurde erstellt von manerer, 12 November 2017.

  1. manerer

    manerer Benutzer

    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:

  2. akretschmer

    akretschmer Datenbank-Guru

    Von viel Bla bla abgesehen sehe ich keine Definition einer Tabelle oder sowas. Ich für mich mich kann da bis jetzt exakt gar kein Konzept erkennen. Tut mir Leid.
     
  3. manerer

    manerer Benutzer

    Was genau soll Ich denn dir schicken? Sämtliche Attribute?
     
  4. akretschmer

    akretschmer Datenbank-Guru

    Etwas nachvollziehbares. CREATE TABLE ist nachvollziehbar.
     
  5. manerer

    manerer Benutzer

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

    akretschmer Datenbank-Guru

    Nützt mir nix, kann ich nicht lesen.
     
  7. manerer

    manerer Benutzer

    Hier ein screenshot
     

    Anhänge:

  8. akretschmer

    akretschmer Datenbank-Guru

    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
     
    manerer gefällt das.
  9. manerer

    manerer Benutzer

    "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 :)
     
  10. akretschmer

    akretschmer Datenbank-Guru

  11. manerer

    manerer Benutzer

    Nein unser Superadmin kommt schon selbst in der Applikation vor.
     
  12. akretschmer

    akretschmer Datenbank-Guru

    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.
     
  13. manerer

    manerer Benutzer

    Ah ok. Danke für die Erklärung. Leider wurden wir vom Dozenten auf MySQL beschränkt.
     

Diese Seite empfehlen