Announcement

Collapse
No announcement yet.

ERD - Aufbau so richtig?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • ERD - Aufbau so richtig?

    Hallo,
    ich bin gerade an einem neuen Projekt (Ticketsystem):

    Ein Admin soll die Möglichkeit haben ein Webformular auszufüllen.
    Folgende Angaben benötigt er:
    - Person (Vorname, Nachname, Firma...)
    - Einrichtung (Schreibtisch, Tischlampe...)
    - Arbeitsplatz (Laptop, Desktop PC, Telefon...)

    Die Angaben zu Einrichtung, Arbeitsplatz sollen zu den zuständigen Personen (Haustechnik etc) per Mail geschickt werden. Diese sollen die Tickets bearbeiten können (nur ihr Bereicht aber!!! Sprich angeben, ob zB das Telefon eingerichtet wurde etc.)
    Der Admin hat die Kontrolle über das ganze Ticket (sprich wenn die Haustechnik ihre Arbeit geleistet hat, soll beim Admin der Status: Haustechnik "erledigt" erscheinen)

    Nun weiß ich leider nicht genau wie ich dies aufbauen soll, bzw. wie die Beziehungen sind. Hier mal mein Vorschlag:
    Nur: Ein Vorgang hat doch genau nur ein Arbeitsplatz und ein Arbeitsplatz hat genau ein Ticket?? Das ist mir noch unklar.... Bitte erleuchtet mich Oder würdet ihr es komplett anders aufbauen? Wenn ja, wie?
    Zuletzt editiert von rider; 02.09.2009, 11:35.

  • #2
    Also ich würde:

    1 Person kann einen oder mehrere Arbeitsplätze haben
    1 Arbeitsplatz hat einen oder mehrere Gegenstände (PC, Tischlampe...)

    1 Ticket referenziert einen (eventuell auch mehrere - je nachdem was getrackt werden soll) Gegenstände, eine Beschreibung der Mängel und hat einen Zustand (neu, in bearbeitung, fertig). Über den Arbeitsplatz des Gegenstandes weisst du dann auch zu welcher Person das gehört.
    Eventuell kann ein Arbeitsplatz auch mehreren Personen zugeordnet werden (z.B. Laborplätze) je nachdem ob das nötig ist oder nicht.

    Comment


    • #3
      Ich glaub das mit den Gegenständen ist nich so gut gelöst:
      Hier habe ich mal die das ganze als Excelliste! Das soll nun jedoch webbasiert gelöst werden:

      Zuletzt editiert von rider; 08.09.2009, 13:12.

      Comment


      • #4
        Na Du kannst eine Mängelbeschreibung auch einfach auf einen Arbeitsplatz beziehen. Dann kann ein Arbeitsplatz mehrere Mängelbeschreibungen mit unterschiedlichem Status haben.

        Kommt halt drauf an ob die Gegenstände vom System erfasst werden sollen oder nicht.

        Comment


        • #5
          Nein, die Gegenstände sollen nicht vom System erfasst werden.
          Es soll einfach nur in der Bemerkung drin stehen, was benötigt wird.

          Was genau meinst du mit "Mängelbeschreibung"?

          Comment


          • #6
            Naja... ich hab das so verstanden, dass jemand dort die Mängel zu seinem Arbeitsplatz reintippt. Sprich ob was fehlt an dem Arbeitsplatz oder was kaputt ist usw. Die Excelliste ist leider nicht im Forum gelandet.

            Dann ist das ERD doch eigentlich ganz einfach

            Bereich 1 <-> n Person 1 <-> n Arbeitsplatz 1 <-> n Mängelbeschreibung

            Wenn Du nun eine neuen Mängelbeschreibung bekommst, dann weisst du zu welchem Arbeitsplatz diese gehört. Weiterhin weisst Du welcher Mitarbeiter für diesen Arbeitsplatz verantwortlich ist und von dieser Person weisst du den Bereich. Nun kannst Du in den Personen wieder nachschauen wer für diesen Bereich zuständig ist.

            Tabellen in etwa so:

            Bereich:
            ============
            IdBereich
            Name

            Person
            ============
            IdPerson
            Name
            IdBereich (foreign key auf Bereich - IdBereich - not null)
            VerantwortlichFuerBereich (foreign key auf Bereich - unique - darf null sein)

            Arbeitsplatz
            =================
            IdArbeitsplatz
            Beschreibung
            IdPersion

            Mangel
            ===============
            IdMangel
            Beschreibung (hier kommt der Text rein was gemacht werden soll - neue Sachen bestellt o.ä.)
            IdArbeitsplatz
            IdStatus (foreign key auf Status - not null)

            Status
            ==============
            IdStatus
            Beschreibung

            Comment


            • #7
              Hmm, so wirklich kann ich mich damit nicht anfreunden

              Ich habe es so aufgebaut:

              ====== Person =======
              - person_id
              - nachname
              - vorname
              - firma
              - eintrittsdatum
              - kostenstelle
              - personalnummer
              - racf
              - gruppe
              - email
              - passwort


              ====== Vorgang=======
              - vorgangs_id
              - erstelldatum
              - status
              - person_fk



              ====== Einrichtung=======
              - einrichtungs_id
              - arbeitsplatzausstattung (Einfach "JA" oder "NEIN" wegen SelectBox)
              - apa_erledigt
              - apa_veranlasst_am
              - apa_bemerkung
              - bürobezeichnung
              - büro_erledigt
              - büro_veranlasst_am
              - büro_bemerkung
              - metallschlüssel
              - ms_erledigt
              - ms_veranlasst_am
              - ms_bemerkung
              - erstelldatum
              - status
              - vorgang_fk


              Dann eben für "Zugrifssrechte", "PC-Ausstattung" etc. ähnliche Tabelle, nur andere Attribute wie "Einrichtung"

              Comment


              • #8
                Na wie auch immer schließlich und endlich musst doch Du entscheiden was Dir am Liebsten ist

                Comment


                • #9
                  Nunja, ich denke ich hab mich da schon so "reingebissen"!
                  Aber könnte man das so lassen, oder ist das falsch? Verbesserungswürdig?

                  Soll jetzt nicht heißen, dass deine Lösung schlecht wäre, nur mir gefällt sie so nicht *g*

                  Comment


                  • #10
                    Naja Du erfasst halt nur Vorgänge. Das ist ein etwas anderes Modell als das was ich im Kopf hatte.
                    Ich glaub man kann hier nicht sagen "falsch". Es kommt eben immer auf das Problem an. Und wenn Du "nur" eine Erfassungsmöglichkeit für bestimmte Aufgaben suchst, dann ist das ganz gut.

                    Was ich nicht machen würde wäre das "JA" und "NEIN" so direkt in die Datenbank abzuspeichern. Das ist wohl Geschmackssache, ich mags einfach nicht

                    Beim Erstelldatum solltest Du Dich noch entscheiden wo das hin soll. Sinn machts wohl mehr beim Vorgang, weil jeder Vorgang ein Erstelldatum hat. Eventuell kann man auch den Status in die Vorgangstabelle packen, wenn die Zustände über alle anderen Tabellen gleich sind.

                    Comment


                    • #11
                      genau, es soll nur ein Erfassungmöglichkeit sein.
                      Admin gibt die Eingaben ein und die Abteilungen müssen die Vorgänge (für ihre Abteilung) abhaken!

                      Ja, Erstelldatum macht wirklich nur beim Vorgang sinn.
                      Ja, gebe ich dir recht! Auch die Stadien kann man in den "Vorgang" packen!

                      Was mich nun aber stutzig macht ist die Beziehung zwischen "Vorgang" und "Einrichtung"!
                      So wirklich weiß ich nicht, ob das stimmt.

                      1 Vorgang hat 1 Einrichtung ( ich denke das passt?) Da ja zu einem Vorgang genau eine Einrichtung/ Zimmer gehört! (Klar jetzt könnte man noch streiten, ob jmd zwei Büros haben kann - ich lass es aber so, dass ein Mitarbeiter genau ein Büro erhält)

                      1 Einrichtung hat 1 Vorgang
                      Auch hier: zu einer Einrichtung gehört wiederum nur ein Vorgang

                      Habe ich irgendwie einen Denkfehler?
                      Weil eine 1:1 Beziehung macht ja normalerweiße keinen Sinn.
                      Besonders: so kann ich ja dann gar nicht auf die Objekte der andere Entität zugreifen!

                      :-/

                      Comment


                      • #12
                        Also wenn Du in Deine Einrichtungstabelle ALLE Fälle reinbekommst, dann kannst die auch gleich mit der Vorgangstabelle zusammenfassen. Eine eigene Tabelle macht nur Sinn wenn es auch andere Varianten der "Einrichtungstabelle" gibt.
                        z.B die Tabelle mit Zugriffsrechten oder die Tabelle mit PC-Ausstattung.

                        Allerdings würde ich wenns nur irgendwie möglich ist nicht auf 3 Tabellen gehen, sondern etwa sowas sowas machen:

                        ====== Vorgang=======
                        - vorgangs_id
                        - erstelldatum
                        - status
                        - person_fk
                        - kategorie_fk //Einrichtung, Zugriffsrecht, PC-Ausstattung
                        - beschreibung //Beschreibung was zu tun ist
                        - apa_erledigt
                        - apa_veranlasst_am
                        - apa_bemerkung
                        - bürobezeichnung
                        - büro_erledigt
                        - büro_veranlasst_am
                        - büro_bemerkung
                        - metallschlüssel
                        - ms_erledigt
                        - ms_veranlasst_am
                        - ms_bemerkung

                        ===== Kategorie =======
                        - IdKategorie
                        - Beschreibung


                        Das ganze ist eben flexibler und lässt sich z.B. einfach mal um eine Kategorie erweitern. Es kommt halt drauf an ob sich der Ablauf über alle Kategorien gleich gestaltet.

                        Comment

                        Working...
                        X