6
Lagerdatenbank für IT-Lager
Servus miteinander,
nun ist es soweit. Ich möchte mich ein wenig mit Datenbanken auseindersetzen. Meine Erfahrungen mit DBs sind allerdings eher gering einzustufen und jetzt wollt ich mal für ein konkretes Projekt wissen, wie Ihr das so lösen würdet. Leider konnte ich via Google keine Ansätze für dieses spezielle "Problem" finden. Bzw. haben mich diese nicht zufriedengestellt.
Ich möchte die Datenbank im übrigen mit Access 2010 erstellen.
Projekt:
Ich verwalte an meinem Arbeitsplatz das IT-Lager, welches nicht sehr groß ist, würd ich mal behaupten. Wir sprechen hier von ca. 150 Geräten. Bisher habe ich eine Übersicht in Excel geführt, wo ich für jeden Gerätetyp (PC, Laptop, Monitor usw.) eine Spalte hatte und für jedes Gerät eine extra Zeile angelegt habe.
Hier kommt es darauf an, dass einige Geräte im Verhältnis zueinander stehen.
So hat z.B. ein jeder PC einen Monitor, welche diesem festzugebucht ist. Genauso verhält es sich mit Laptops, die über einen Monitor verfügen können, aber nicht zwangsläufig müssen, aber in jedem Fall an eine Dockingstation und einen Smartcard-Reader gebunden sind.
Hier ein kurzer Überblick über die Exceltabelle um es vielleicht zu verdeutlichen:
Mir ist jetzt nach einigem probieren aber nicht ganz klar, wie ich am besten die Tabellenstruktur aufbauen soll und was in welcher Beziehung zueinander stehen sollte, damit das Ganze vernünftig ist.
Soll ich pro Gerät eine Tabelle anlegen?
Ist vermutlich sinnvoll, da ja nur so eine Zuordnung zueinander stattfinden kann. Zumindest meine ich, dass es so wäre.
Gesetz dem Fall, dass es so wäre, wie kann ich dann z.B. den Monitor einem APC zuordnen?
Wäre wirklich sehr nett, wenn ich ein paar Anregungen für die Umsetzung dieses Vorhabens bekommen könnte.
Vielen Dank schonmal
dasepp89
nun ist es soweit. Ich möchte mich ein wenig mit Datenbanken auseindersetzen. Meine Erfahrungen mit DBs sind allerdings eher gering einzustufen und jetzt wollt ich mal für ein konkretes Projekt wissen, wie Ihr das so lösen würdet. Leider konnte ich via Google keine Ansätze für dieses spezielle "Problem" finden. Bzw. haben mich diese nicht zufriedengestellt.
Ich möchte die Datenbank im übrigen mit Access 2010 erstellen.
Projekt:
Ich verwalte an meinem Arbeitsplatz das IT-Lager, welches nicht sehr groß ist, würd ich mal behaupten. Wir sprechen hier von ca. 150 Geräten. Bisher habe ich eine Übersicht in Excel geführt, wo ich für jeden Gerätetyp (PC, Laptop, Monitor usw.) eine Spalte hatte und für jedes Gerät eine extra Zeile angelegt habe.
Hier kommt es darauf an, dass einige Geräte im Verhältnis zueinander stehen.
So hat z.B. ein jeder PC einen Monitor, welche diesem festzugebucht ist. Genauso verhält es sich mit Laptops, die über einen Monitor verfügen können, aber nicht zwangsläufig müssen, aber in jedem Fall an eine Dockingstation und einen Smartcard-Reader gebunden sind.
Hier ein kurzer Überblick über die Exceltabelle um es vielleicht zu verdeutlichen:
Mir ist jetzt nach einigem probieren aber nicht ganz klar, wie ich am besten die Tabellenstruktur aufbauen soll und was in welcher Beziehung zueinander stehen sollte, damit das Ganze vernünftig ist.
Soll ich pro Gerät eine Tabelle anlegen?
Ist vermutlich sinnvoll, da ja nur so eine Zuordnung zueinander stattfinden kann. Zumindest meine ich, dass es so wäre.
Gesetz dem Fall, dass es so wäre, wie kann ich dann z.B. den Monitor einem APC zuordnen?
Wäre wirklich sehr nett, wenn ich ein paar Anregungen für die Umsetzung dieses Vorhabens bekommen könnte.
Vielen Dank schonmal
dasepp89
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 224776
Url: https://administrator.de/contentid/224776
Printed on: April 19, 2024 at 04:04 o'clock
6 Comments
Latest comment
Hallo,
für einen Anfänger schau dir dieses Beispiel mal an.
http://www.office-loesung.de/ftopic626938_0_0_asc.php
have a nice day...
DockM@ster
für einen Anfänger schau dir dieses Beispiel mal an.
http://www.office-loesung.de/ftopic626938_0_0_asc.php
have a nice day...
DockM@ster
Hallo,
Schwierig wird das, wenn du einen PC mit zwei Monitoren hast, in die Montior-Spalte in der PC-Tabelle kannst du nur einen aufnehmen (zumindest nur, wenn du mit automatischen Verknüpfungen arbeiten willst). Um 1:n-Beziehungen abzubilden bräuchtest du eine separate Tabelle, (PC,Monitor), in der du dann für jede PC -> Monitor-Beziehung eine neue Zeile anlegst - aber dann wird das mit Abfragen schon wieder relativ kompliziert.
Die Geschichte mit den Schlüssel erklärt http://v.hdm-stuttgart.de/~riekert/lehre/db-kelz/index.htm ziemlich gut.
Grüße
Filipp
So hat z.B. ein jeder PC einen Monitor, welche diesem festzugebucht ist.
Das verstehe ich nicht. Wieso sind in einem Lager PC und Monitor verknüpft? Was passiert denn, wenn nur eins von beidem kaputt geht?Soll ich pro Gerät eine Tabelle anlegen?
Das macht bestimmt Sinn. So kannst du bei PC noch Spalten "CPU" und "RAM" aufnehmen, die ein Monitor eher nicht benötigt. Wenn du in jeder Tabelle noch einen Primärschlüssel (ID) verwendest, kannst du jede Zeile eindeutig identifizieren. Und beim PC kannst du einen Foreign Key-Spalte aufnehmen, in der du dann die ID des Monitors hinterlegen kannst. Beim PC kannst du erzwingen, dass das Feld "Monitor" nicht leer sein darf (sofern das aus deiner Sicht Sinn ergibt), während du beim Notebook das Feld auch leer erlaubst.Schwierig wird das, wenn du einen PC mit zwei Monitoren hast, in die Montior-Spalte in der PC-Tabelle kannst du nur einen aufnehmen (zumindest nur, wenn du mit automatischen Verknüpfungen arbeiten willst). Um 1:n-Beziehungen abzubilden bräuchtest du eine separate Tabelle, (PC,Monitor), in der du dann für jede PC -> Monitor-Beziehung eine neue Zeile anlegst - aber dann wird das mit Abfragen schon wieder relativ kompliziert.
Die Geschichte mit den Schlüssel erklärt http://v.hdm-stuttgart.de/~riekert/lehre/db-kelz/index.htm ziemlich gut.
Grüße
Filipp
Hallo dasepp89,
ein einfaches Ausgangsmodell für das Projekt:
1. Tabelle "GeraeteTypen", Spalte "IDTyp" (Int, Primärschlüssel) und Spalte "BezTyp" (String)
2. Tabelle "Geraete", Spalte "IDGeraet" (Int, Primärschlüssel), Spalte "IDTyp" (Int, enthält IDs aus Tabelle "GeraeteTypen") und Spalte "BezGeraet" (String), kann/sollte man noch um weitere Spalten ergänzen, z.B. "Ist es ein Hauptgerät?" (dem andere Geräte zugeordnet werden können), Hersteller, Kaufdatum, Pfad zur Datei mit der eingescannten Rechnung u.ä.
3. Tabelle "Zuordnungen", Spalte "IDHauptGeraet" (Int) und Spalte "IDZugGeraet" (Int), beide Spalten zusammen bilden einen zusammengesetzten Primärschlüssel und enthalten beide IDs aus der Tabelle "Geraete"
Die dritte Tabelle ist eine sog. Verknüpfungstabelle, die die Beziehung zwischen den Geräten herstellt. In relationalen Datenbank Management Systemen werden Beziehungen/Zuordnungen in Form von Tabellen dargestellt, die die IDs von Datensätzen aus anderen Tabellen enthalten.
Gruß
Friemler
ein einfaches Ausgangsmodell für das Projekt:
1. Tabelle "GeraeteTypen", Spalte "IDTyp" (Int, Primärschlüssel) und Spalte "BezTyp" (String)
2. Tabelle "Geraete", Spalte "IDGeraet" (Int, Primärschlüssel), Spalte "IDTyp" (Int, enthält IDs aus Tabelle "GeraeteTypen") und Spalte "BezGeraet" (String), kann/sollte man noch um weitere Spalten ergänzen, z.B. "Ist es ein Hauptgerät?" (dem andere Geräte zugeordnet werden können), Hersteller, Kaufdatum, Pfad zur Datei mit der eingescannten Rechnung u.ä.
3. Tabelle "Zuordnungen", Spalte "IDHauptGeraet" (Int) und Spalte "IDZugGeraet" (Int), beide Spalten zusammen bilden einen zusammengesetzten Primärschlüssel und enthalten beide IDs aus der Tabelle "Geraete"
Die dritte Tabelle ist eine sog. Verknüpfungstabelle, die die Beziehung zwischen den Geräten herstellt. In relationalen Datenbank Management Systemen werden Beziehungen/Zuordnungen in Form von Tabellen dargestellt, die die IDs von Datensätzen aus anderen Tabellen enthalten.
Gruß
Friemler
Guten Morgen zusammen,
danke schonmal für die Antworten. Ist alles schon sehr hilfreich
Also es ist so: Wir bekommen unsere IT-Geräte von einem Dienstleister für unsere Firma gestellt. Und dieser gibt vor, dass eben PC und Monitor ein Bundle bilden. Wenn jetzt z.B. der Monitor kaputt geht, dann wird auch nur der Monitor getauscht und eben dieser neue Monitor mit dem "alten" PC gebundelt. Ist ziemlich doof, aber leider nicht zu ändern. Aus diesem Grunde muss das in der DB ersichtlich sein, welche Geräte zusammengehören.
Ok, dann bin ich ja da schonmal auf dem richtigen Weg. Aber das mit dem Foreign-Key ist ein guter Tipp. Das macht sogar in meinen Augen Sinn
Bezüglich dem zweiten Monitor: Das kommt nicht vor. Klar, wäre es schön, wenn man das abbildet, aber das ist gar nicht vorgesehen, dass ein PC zwei Monitore hat. Zumindest im Lager nicht. Nichtsdestotrotz ist auch das ein guter Hinweis und ich werde das versuchen umzusetzen, wenn ich das mit der Abfrage dann auch hinbekomme.
Ich sehe schon, das Ziel ist auf mehreren Wegen zu erreichen. Ich find auch den Ansatz reizvoll. Ich denke, jetzt muss ich wirklich erstmal ausprobieren.
Gibt es den Vor- und Nachteile die aus den beiden Lösungen hervorgehen, die ich jetzt nicht sehe? Gerade was jetzt den weiteren Verlauf mit Abfragen usw. angeht?
Grüße
dasepp
danke schonmal für die Antworten. Ist alles schon sehr hilfreich
> So hat z.B. ein jeder PC einen Monitor, welche diesem festzugebucht ist.
Das verstehe ich nicht. Wieso sind in einem Lager PC und Monitor verknüpft? Was passiert denn, wenn nur eins von beidem
kaputt geht?
Das verstehe ich nicht. Wieso sind in einem Lager PC und Monitor verknüpft? Was passiert denn, wenn nur eins von beidem
kaputt geht?
Also es ist so: Wir bekommen unsere IT-Geräte von einem Dienstleister für unsere Firma gestellt. Und dieser gibt vor, dass eben PC und Monitor ein Bundle bilden. Wenn jetzt z.B. der Monitor kaputt geht, dann wird auch nur der Monitor getauscht und eben dieser neue Monitor mit dem "alten" PC gebundelt. Ist ziemlich doof, aber leider nicht zu ändern. Aus diesem Grunde muss das in der DB ersichtlich sein, welche Geräte zusammengehören.
> Soll ich pro Gerät eine Tabelle anlegen?
Das macht bestimmt Sinn. So kannst du bei PC noch Spalten "CPU" und "RAM" aufnehmen, die ein Monitor eher
nicht benötigt. Wenn du in jeder Tabelle noch einen Primärschlüssel (ID) verwendest, kannst du jede Zeile eindeutig
identifizieren. Und beim PC kannst du einen Foreign Key-Spalte aufnehmen, in der du dann die ID des Monitors hinterlegen kannst.
Beim PC kannst du erzwingen, dass das Feld "Monitor" nicht leer sein darf (sofern das aus deiner Sicht Sinn ergibt),
während du beim Notebook das Feld auch leer erlaubst.
Schwierig wird das, wenn du einen PC mit zwei Monitoren hast, in die Montior-Spalte in der PC-Tabelle kannst du nur einen
aufnehmen (zumindest nur, wenn du mit automatischen Verknüpfungen arbeiten willst). Um 1:n-Beziehungen abzubilden
bräuchtest du eine separate Tabelle, (PC,Monitor), in der du dann für jede PC -> Monitor-Beziehung eine neue Zeile
anlegst - aber dann wird das mit Abfragen schon wieder relativ kompliziert.
Das macht bestimmt Sinn. So kannst du bei PC noch Spalten "CPU" und "RAM" aufnehmen, die ein Monitor eher
nicht benötigt. Wenn du in jeder Tabelle noch einen Primärschlüssel (ID) verwendest, kannst du jede Zeile eindeutig
identifizieren. Und beim PC kannst du einen Foreign Key-Spalte aufnehmen, in der du dann die ID des Monitors hinterlegen kannst.
Beim PC kannst du erzwingen, dass das Feld "Monitor" nicht leer sein darf (sofern das aus deiner Sicht Sinn ergibt),
während du beim Notebook das Feld auch leer erlaubst.
Schwierig wird das, wenn du einen PC mit zwei Monitoren hast, in die Montior-Spalte in der PC-Tabelle kannst du nur einen
aufnehmen (zumindest nur, wenn du mit automatischen Verknüpfungen arbeiten willst). Um 1:n-Beziehungen abzubilden
bräuchtest du eine separate Tabelle, (PC,Monitor), in der du dann für jede PC -> Monitor-Beziehung eine neue Zeile
anlegst - aber dann wird das mit Abfragen schon wieder relativ kompliziert.
Ok, dann bin ich ja da schonmal auf dem richtigen Weg. Aber das mit dem Foreign-Key ist ein guter Tipp. Das macht sogar in meinen Augen Sinn
Bezüglich dem zweiten Monitor: Das kommt nicht vor. Klar, wäre es schön, wenn man das abbildet, aber das ist gar nicht vorgesehen, dass ein PC zwei Monitore hat. Zumindest im Lager nicht. Nichtsdestotrotz ist auch das ein guter Hinweis und ich werde das versuchen umzusetzen, wenn ich das mit der Abfrage dann auch hinbekomme.
Die dritte Tabelle ist eine sog. Verknüpfungstabelle, die die Beziehung zwischen den Geräten herstellt. In relationalen
Datenbank Management Systemen werden Beziehungen/Zuordnungen in Form von Tabellen dargestellt, die die IDs von Datensätzen
aus anderen Tabellen enthalten.
Datenbank Management Systemen werden Beziehungen/Zuordnungen in Form von Tabellen dargestellt, die die IDs von Datensätzen
aus anderen Tabellen enthalten.
Ich sehe schon, das Ziel ist auf mehreren Wegen zu erreichen. Ich find auch den Ansatz reizvoll. Ich denke, jetzt muss ich wirklich erstmal ausprobieren.
Gibt es den Vor- und Nachteile die aus den beiden Lösungen hervorgehen, die ich jetzt nicht sehe? Gerade was jetzt den weiteren Verlauf mit Abfragen usw. angeht?
Grüße
dasepp
Hallo!
Ich nehme für das Ganze die Software GLPI.
Alternativ wäre i-DOIT eine Möglichkeit.
Hier hast Du eine Hardwareübersicht, kannst Assets miteinander verlinken und kannst Supportverträge, etc. hinterlegen.
Dazu ist GLPI noch ein Ticketsystem, bei dem man Tickets an Hardware verlinken kann.
Phil
Ich nehme für das Ganze die Software GLPI.
Alternativ wäre i-DOIT eine Möglichkeit.
Hier hast Du eine Hardwareübersicht, kannst Assets miteinander verlinken und kannst Supportverträge, etc. hinterlegen.
Dazu ist GLPI noch ein Ticketsystem, bei dem man Tickets an Hardware verlinken kann.
Phil
Hallo dasepp89,
also pro Gerät wäre ja wohl ein abolutes No-Go, Du und @filippg meintet wohl eher pro Gerätetyp, das wäre schon sinnvoll.
Wenn Du keine Verknüpfungstabelle verwendest, sondern eine Tabelle, in der Geräte mit ID, Bezeichnung, TypID und den zugeordneten "Zubehörgeräten" gespeichert werden, wird das ganze unflexibel.
In Bezug auf den Schwierigkeitsgrad der SQL-Abfragen: Egal wie Du es löst, mit (INNER/LEFT/RIGHT) JOINs musst Du Dich so oder so beschäftigen. Auch wie Du in Access z.B. den in einem Kombinationsfeld ausgewählten Eintrag in einer SQL-Abfrage in die WHERE-Klausel einbaust, um ein Listenfeld zu füllen, musst Du lernen u.v.a.m.
Goldene Regel ist auf jeden Fall: Wenn man eine schnelle, schlecht durchdachte Lösung für ein langfristiges Problem umsetzt, kommt man aus dem Reparieren und Anpassen an geänderte Anforderungen nicht mehr heraus. Außerdem wird meist auch schnell ein Redesign fällig, also (fast) alles neu machen. Lass Dir lieber Zeit und mach es richtig oder nimm eine fertige Lösung, wie schon @Der-Phil schrieb.
Gruß
Friemler
also pro Gerät wäre ja wohl ein abolutes No-Go, Du und @filippg meintet wohl eher pro Gerätetyp, das wäre schon sinnvoll.
Zitat von @dasepp89:
Gibt es den Vor- und Nachteile die aus den beiden Lösungen hervorgehen, die ich jetzt nicht sehe? Gerade was jetzt den
weiteren Verlauf mit Abfragen usw. angeht?
Gibt es den Vor- und Nachteile die aus den beiden Lösungen hervorgehen, die ich jetzt nicht sehe? Gerade was jetzt den
weiteren Verlauf mit Abfragen usw. angeht?
Wenn Du keine Verknüpfungstabelle verwendest, sondern eine Tabelle, in der Geräte mit ID, Bezeichnung, TypID und den zugeordneten "Zubehörgeräten" gespeichert werden, wird das ganze unflexibel.
- Der schon erwähnte Fall "PC hat zwei Monitore" ist mit einer Verknüpfungstabelle kein Sonderfall mehr, sondern wird einfach "per Design" unterstützt. In der Verknüpfungstabelle stehen zwei Zeilen mit der ID des PCs, die ID des jeweils verknüpften Geräts ist verschieden.
- Was ist, wenn ein neuer Zubehör-Gerätetyp hinzukommt? => Ohne Verknüfungstabelle musst Du die o.g. Tabelle um eine Spalte erweitern, was bei einer Tabelle, die bereits Daten enthält, zu Problemen führen kann und für den neuen Gerätetyp neue SQL-Abfragen schreiben bzw. bestehende ändern. Mit einer Verknüpfungstabelle ergänzt Du die Gerätetyp-Tabelle um eine Zeile und kannst jederzeit in der Verknüpfungstabelle eine neue Zuordnung zu diesem Gerätetyp eintragen. An der Struktur der Datenbank und den SQL-Abfragen der verwendeten Access-Formulare brauchst Du nichts zu ändern.
- Wenn Du die SQL-Abfrage für die Ermittelung der Zuordnung "Haupgerät->Zubehörgeräte" (also z.B. PC->Monitor, Drucker) geschrieben hast, kannst Du sie mit relativ geringem Aufwand umschreiben, um die Zuordnung "Zubehörgerät->Hauptgerät" (also z.B. Monitor->PC) zu ermitteln. Damit kann man in Erfahrung bringen, wo ein bestimmtes "Zubehörgerät" eingesetzt wird.
In Bezug auf den Schwierigkeitsgrad der SQL-Abfragen: Egal wie Du es löst, mit (INNER/LEFT/RIGHT) JOINs musst Du Dich so oder so beschäftigen. Auch wie Du in Access z.B. den in einem Kombinationsfeld ausgewählten Eintrag in einer SQL-Abfrage in die WHERE-Klausel einbaust, um ein Listenfeld zu füllen, musst Du lernen u.v.a.m.
Goldene Regel ist auf jeden Fall: Wenn man eine schnelle, schlecht durchdachte Lösung für ein langfristiges Problem umsetzt, kommt man aus dem Reparieren und Anpassen an geänderte Anforderungen nicht mehr heraus. Außerdem wird meist auch schnell ein Redesign fällig, also (fast) alles neu machen. Lass Dir lieber Zeit und mach es richtig oder nimm eine fertige Lösung, wie schon @Der-Phil schrieb.
Gruß
Friemler
