nicht angemeldet
Hallo,
Mir würde dazu folgendes einfallen:
-
Wie Stefan schon meinte, könnte man Workstaions, Server und Sonstiges durchaus zu einer Tabelle zusammen ziehen.
-
Es wäre durchaus auch möglich, daß Rechner mehrere IP-Adressen haben, bzw. in mehreren Netzwerken vorhanden sind. Auch hier wäre eine Auslagerung der IP-Adressen sinnvoll
-
Es kann durchaus auch sein, daß ein Kunde in seinen Netzwerken für verwschienden Anwender verschieden POP3- und SMTP-Server verwendet. Das ist in Deinem Modell nicht abdeckbar. Abgesehen davon, müßten ja Dienste wie DNS, Gateway, Proxy usw. von Rechnern erledigt werden, die auch in dieser Datenbank stehen müßten. So gesehen könnte hier eine Referenz auf die entsprechenden Rechner erfolgen, auch auf die Gefahr hin, Zirkelbezüge zu erstellen
-
die Software würde ich auch eigene Tabellen lösen. Es könnte auch durchaus sinnvoll sien, zwei Tabellen für die Software ansich und deren Versionen zu verwenden, also eine in der beispielswiese Word, Acrobat Reader, Delphi, Windows NT usw. abgebildet sind und in einer zweiten, in der dann die möglcihen Versionen (Word 95, 97, 2000 usw) verwaltet werden. Für jeden Rechner wird dann aufgenommen, welche Version der Software nun wirklich daruaf läuft. BTW. Du siehst, eigentlich habe ich das OS zu nebenbei auch zur Software gemacht.
-
Für die Hardwareausstattung könnte es durchaus auch sinnvoll sein, daß man diese über zusätzlcihe Tabellen verwaltet.
-
Was bedeutet Ws_WID bzw. Ser_SID?
-
Das reduntante Abbilden von Foreign-Keys (Dunden_ID) halte ich auch für ungeschickt. Constraints mit eingeschaltetem CASADE DELETE sollten auch ohne dieser Maßnahme in der Lage sein, alle Daten zu löschen, die beispielsweise dem zu löschenden Kunden zugeordnet sind.
-
Die Namensgebung halte ich z.T. auch mißlungen. imho wäre es besser die Foreign-Key-Spalten gelcih wie die zugehörige Primary-Keyspalte zu benennen. Nach dem Motto "Einmal Kund_ID, dann immer Kund_ID".
Grüße
Klaus