Office: (Office 2007) Netzwerkverwaltung mit Access

Hallo liebe Gemeinde;

ich habe schon ewig nichts mehr mit Access gemacht und habe mir nun ein recht großes Projekt vor die Brust genommen.

Im konkreten Fall geht es um eine Netzwerkverwaltung mit gut 100 Clients.

Verwaltet werden sollen User, Firmen (unsere Firma besteht aus mehreren Firmen), Abteilungen, IP- und MAC- Adressen, Clients und Softwarelizenzen.

Im speziellen sieht das Ganze so aus:

1 User hat einen Client.
1 User ist in genau einer Firma
1 User ist in genau einer Abteilung
1 Client hat eine IP- Adresse (Ausnahme: diverse Server - mit max. 2 IP- Adressen)
1 Client hat 1 MAC- Adresse (Ausnahme: diverse Server - mit max. 2 MAC- Adressen - s. Punkt 2)
Es gibt verschiedene Netzwerke - Es gibt User, die in 2 oder mehr Netzwerken sind.
1 User kann verschiedene Softwareprodukte haben (Office, OS etc), aber immer nur ein gleichartiges (Office 2007 oder Office 2010 oder. . . . . .).

1. Ansatz

1 Tabelle für die User
1 Tabelle für die Lizenzen

Diese Lösung wäre die einfachste, würde aber gegen Normalisierungsregeln verstoßen (2 Spalten MAC- Adresse, 2 Spalten IP- Adresse).

2. Ansatz

1. Tabelle User
2. Tabelle Firmen
3. Tabelle Abteilungen
4. Tabelle IP- Adressen
5. Tabelle MAC- Adressen
6. Tabelle Netzwerke

Dieser Ansatz scheint mir der vernünftigere, langfristig flexiblere, wohl aber auch aufwendigere. Kopfschmerzen bereiten mir zum einen die Beziehungen und die Formulare.

Ich habe keinen blassen Schimmer wie ich ansetzen soll und wie ich es schaffe einen User in einer Maske (Formular) anzulegen.

Ich hoffe, ihr könnt mich auf den richtigen Weg bringen und mir vielleicht den einen oder anderen Lösungsschritt vermitteln. Dafür bedanke ich mich im Vorraus.

:)

 

Ich würde vorsichtshalber davon ausgehen, daß es hier keine sicheren 1:1-Beziehungen gibt, auch wenn das gegenwärtig vielleicht so ist.
(1 User in 1 Abteilung, das muß nicht immer so sein. Irgendwann gehört 1 User vielleicht zu 2 Abteilungen.)
Pointiert ausgedrückt: wenn es kein Naturgesetz gibt, daß etwas einmalig ist, dann geh' auch nicht davon aus, daß es einmalig ist.

Daraus folgt: für jedes Ding zunächst eine separate Tabelle anlegen.
Dann folgen Zuordnungstabellen, mit denen die die Dinge eben in Beziehung gesetzt werden.

Ist die Software dem User oder der Maschine zugeordnet? Vermutlich doch der Maschine und der User hat Zugriff auf die Maschine.
Ob es sinnvoll ist, getrennte Tabellen für Clients und Server anzulegen, kann ich mangels Fachkenntnis nicht entscheiden, ich vermute aber, daß man alle Maschinen in eine Tabelle packen kann.

Nimm auf jeden Fall erst mal ein Blatt Papier und 'nen Bleistift, um das Datenmodell zu entwerfen. Wenn Du das hast, stell's hier mal vor und es wird Dir bestimmt gehelft.

 

Hier mal der Entwurf.

Folgende Überlegungen habe ich dabei zugrunde gelegt:

1. Ein User kann meherer Clients haben (Laptop, Workstation etc.)
2. Ein Client kann mehrere IP- Adressen haben (mehrere Netzwerkkarten)
3. Ein Client kann mehrere MAC- Adressen haben (mehrere Netzwerkkarten)
4. Ein Client kann in verschiedenen Netzwerken sein (z.B. Router)
5. Eine Firma/Abteilung hat mehrere User (ein User ist definitiv nur in einer Abteilung)

 

Nee, so könntest Du eine widersprüchliche Zuordnung "Firma - Abteilung" erhalten. Die Der User muß an der Abteilung hängen und die Abteilung an der Firma; wenn es dann in Erz gegossen ist, daß 1 User immer nur zu 1 Abteilung gehören kann.
Außerdem kann 1 Client gemäß Deiner Konstruktion nur 1 Mac-Adresse und 1 Ip-Adresse haben und nur zu 1 Netzwerk gehören.
Du brauchst Zuordnungstabellen in der Art:
tbl_macadressen (enthält Mac-Adressen-Id)
tbl_clients (enthält Client-Id)
tbl_clients_macadressen (Mac-Adressen-Id | Client-Id)

 

Also eher so?

 

Nee, dem User wird eine Abteilung zugewiesen und die Abteilung hängt an der Firma.
Nochmal die Empfehlung, zunächst mal alles mit Bleistift und Papier zu skizzieren. Du mußt festlegen, welches "Ding" unabhängig von anderen "Dingen" besteht, nach dem Schema "es gibt...".
Es gibt Firmen
Es gibt Abteilungen
Es gibt Mitarbeiter
Es gibt Clients
Es gibt Mac-Adressen

Wenn Du damit durch bist, mußt Du prüfen, wie weit die Dinge voneinander abhängig sind. Ein Mitarbeiter kann nur vorkommen, wenn er zu einer und nur einer Abteilung gehört (sagst Du), eine Abteilung kann nur vorkommen, wenn sie zu einer Firma gehört. Damit ist diese Zuordnungskette klar; vom kleinsten Element zum nächstgrößeren gehen.
Was die Computergeschichte angeht, fehlt es mir an Fachwissen. Mir ist klar, das eine Maschine viele Mac-Adressen haben kann und soweit ich weiß, auch viele IP-Adressen.
"Viele" bedeutet hier mehr als eins, und das ist der Unterschied für die Tabellenstruktur. Entweder kann etwas nur genau einmalig sein oder es kann vielfach vorkommen. Dabei ist es im Prinzip gleichgültig, ob zweifach oder tausendfach.
Kurz und gut, schreib zunächst auf, was es gibt und was "naturgesetzlich" zusammengehört und was mehrfach kombiniert werden kann. Dann sehen wir weiter.
Noch 'ne Warnung: die Aussage, "das könnte zwar theoretisch sein, kommt bei uns aber nicht vor", ist eine ganz schlechte Grundlage für eine Tabellenstruktur. Wenn nämlich die Geschäftsleitung morgen beschließt, das ein Mitarbeiter doch zu mehreren Abteilungen gehören kann, dann hast Du eine elende, fehlerträchtige und unbefriedigende Arbeit vor Dir um die DB anzupassen.

 

Darf man mal offtopic reinhusten?

Abgesehen von der Herausforderung an sich: Macht es Sinn, ein solches Projekt selber per Access zu lösen? Wenn die beschriebene "Netzwerk"-Verwaltung steht, kommen ganz sicher neue Anforderungen dazu, weil man ja eh schon eine "Datenbank für Rechner" im Haus hat. Software-(Lizenz-)-Verwaltung, Update-Kontrollen, Rechte-Management ...

Da steht man schneller als man glaubt an der Schwelle zu "besser kaufen".

nur als spontaner Gedanke beim querlesen ....

 

\@Andre.Heisig
Ob es sinnvoll ist, solch ein DB selber zu bauen, muß jeder für sich beurteilen. Spaß kann es durchaus bereiten.

Aus dieser Erfahrung heraus lege ich auch den größten Wert auf ein Datenmodell das nicht bei der kleinsten Änderung untauglich wird. Motto: Tabellen kosten nix, warum also sparen?

 

Es gibt sicherlich Tools, die eine Menge können, keine Frage.

Aber in einem Unternehmen mit ca. 100 Clients steht der Preis für eine solche Lösung sicherlich nicht im Hintergrund. Hier wird nur darüber gesprochen, dass die IT Geld kostet und keinen Gewinn bringt. Bei derartigen Äußerungen würde ich gerne mal den Netzstecker ziehen. Aber back to topic.

Bisher wurden die beschriebenen Daten in Excel- Tabellen geflegt. Das Ganze ist umständlich und unübersichtlich. Von Fehlern reden wir erst gar nicht.

Eine Access- Datenbank ist da mit Sicherheit die bessere Wahl, zumal Access im Unternehmen eingesetzt wird und meine Arbeitskraft um das Teil zu erstellen vorhanden ist. Das ich Geld koste und dabei für etwaige andere Aufgaben nicht zur Verfügung stehe wird als gegeben hingenommen.

Ich persönliche sehe das Ganze dennoch eher positiv. Ich kann etwas produktives tun, dabei lernen und sicherlich, wenn es denn mal alles fertig ist und läuft, Pluspunkte sammeln.

So, nun aber noch mal zur Konkretisierung:

Jeder User ist genau einer Firma und einer Abteilung dieser Firma zugeordnet.
Jeder User hat mindestens 1 Rechner (ggf. mehrere).
Jeder Rechner hat mindestens eine Netzwerkkarte (ggf. mehrere - z.b. bei Servern).
Jede Netzwerkarte hat genau eine MAC- Adresse.
Einer Netzwerkkarte (und damit der MAC- Adresse) wird eine IP- Adresse zugewiesen. Es ist netzwerktechnisch möglich einer Netzwerkkarte (und damit einer MAC- Adresse) mehrere IP- Adressen zuzuweisen. Ist bei uns nicht der Fall - ob ich diese Evantualität in Betracht ziehen soll, weiß ich noch nicht.
Es gibt verschiedene Netzwerke. In einem Netzwerk sind eindeutige IP- Adressen und MAC- Adressen vorhanden. Ein User kann in verschieden Netzen vorkommen.

Tabellenstruktur:

tblMACAdressen - MACID | MACAdresse
tblNetzwerke - NetzwerkID | Netzwerkadress
tblIPAdressen - IPID| IPAdresse | NetzwerkID | MACID | ClientID
tblClients - ClientID | ClientName | UserID
tblUser - UserID | UserName | UserVorname
tblfirma - FirmaID | FirmaName
tblAbteilung - AbteilungID | AbteilungName

Die Software und Lizenzverwaltung lasse ich erst mal außen vor. Das wird später ergänzend zugefügt.

 

Jau, das klärt doch.

Ich würde das gleich berücksichtigen, wie gesagt: Tabellen kosten nix.
Im nächsten Schritt müssen jetzt die möglichen Zuordnungen abgebildet werden.
tblFirmaAbteilung: FirmenId | AbteilungsId
tblUserAbteilung: UserId | AbteilungsId
usw.
Es ist nach meiner Erfahrung nützlich, auch in den Zuordnungstabellen einen Autowert als Id mitzuführen, der kostet nämlich auch nix und kann später nützlich sein. Unbedingt nötig ist diese Id nicht, weil ja über die Kombination (FirmenId | AbteilungsId) ohnehin ein Index ohne Duplikate geführt werden muß.

Über den Namen tblClients würd' ich nochmal nachsinnen, wenn da nachher auch Server drinstehen, wird's mißverständlich.
Für die Feld- und Tabellennamen solltest Du auf alle Sonderzeichen verzichten, auch "-". Also ausschließlich Buchstaben, Zahlen und den Unterstrich "_" verwenden. Du bist sonst nachher gezwungen, die Namen immer eckig einzuklammern, das ist lästig und eine Fehlerquelle.
Ich bevorzuge, den Fremdschlüsseln in den Zuordnungstabellen denselben Namen wie den Primärschlüsseln in den Haupttabellen zu geben, ich find das klar und einfach. Andere bevorzugen, den Fremdschlüssel mit einem Präfix zu kennzeichnen. Egal wie Du es machst: eine klare Nomenklatur vereinfacht das Leben sehr.

 

Habe mal versucht Deine Vorschläge aufzugreifen und umzusetzen:

http://www.fa-wiki.de/Netwerk.accdb

 

Ich hab' nur Access2003, Du mußt bitte für die alte Version speichern.

 

Auf ein Neues *Smilie .

http://www.fa-wiki.de/Netwerk.mdb

 

Ich wollt eure Gedanken hierzu auch in keiner Weise angreifen. Man vertut sich nur glaub ich schnell, wie fix ein paar Hundert € Lizenzkosten in eigener Entwicklungsarbeit draufgegangen sind. Ich werf mal das Wort DocuSnap in die Runde, das hatte ich mir mal näher ansehen können. Exemplarisch, da gibts sicher Vergleichbares. Wenn ich den Funktionsumfang einer solchen, fertigen Lösung sehe, dann kann man schon auch kaufmännisch argumentieren, denk ich.

So, das solls offtopic gewesen sein, ich verfolg das hier nun weiter, ohne zu nörgeln! ;-)) Schönes Wochenende!

 

Hallo Kai, anbei meine Überarbeitung des Tabellenentwurfs. Ob das sachlich richtig ist, kann ich bei manchen Dingen nicht entscheiden, weil ich nix von Netzwerken versteh'.
Eine kleine Liste mit Anmerkungen ist als Tabelle in die DB eingefügt. Falls Du nochmal was hochlädst, dann doch bitte gleich hier im Forum, das ist bequemer.

Edit:
@Andre
Ich empfinde solch Gedanken, auch wenn sie off topic sind, nicht als Nörgelei. Es ist ja nicht unvernünftig, nach einer Alternative zu suchen.