ERM angegeben aber kaum sinnvoll zu realisieren

[Dugong]

Hallo, seid mir gegrüßt.

Ich habe folgendes Problem in meinem Abschlussprojekt.

Ziel ist es einen Netzwerkscanner zu programmieren, der interne und externe Printserver aus dem Netz filtert und deren Informationen in eine Datenbank schreibt.

Jetzt habe ich bei meinem Antrag angegeben ERM zur Datenbank erstellen, aber im Verlauf der Arbeit am Projekt wurde immer deutlicher... naja, dass ich am Ende nur eine Tabelle mit ein paar eindeutigen Informationen habe ^^ also da ist nichts mit normalisieren.

Kennt sich jemand damit aus? Also kann ich jetzt einfach in der Doku dann schreiben "Abweichung vom Antrag... blabla nix mit ERM weil unnötig" oder muss ich auf Biegen und Brechen aus der einen Tabelle jetzt eins erstellen?

Danke euch

[Klotzkopp]

also da ist nichts mit normalisieren.

Unsinn. Die Erkenntnis, dass du nur eine Relation (Tabelle) brauchst, ist doch das Ergebnis der Normalisierung. Wenn man nicht normalisiert, braucht man immer nur eine einzige Relation. Wenn du also zeigen kannst, dass deine Relation die 3. Normalform erfüllt, ist doch alles prima.

[Dugong]

Asche auf mein Haupt, aber ich habe mich mit Datenbanken noch nicht wirklich intensiv befasst.

Ich hoffe, dass die fachliche Frage, die ich jetzt hier stelle, keinen Unmut erregt zwecks falsches Forum:

Die Tabelle hat folgende Spalten mit Beispielen:

IP: xxx.xxx.xxx.xxx(PK)

Hostname: xxxxxx (eindeutig)

Hersteller: Axis (Dopplung möglich)

Typ: 5600+ (Dopplung möglich)

LPT1: HP Deskjet 4100 (Dopplung möglich)

LPT2: Brother MFC 6400 (Dopplung möglich)

COM/USB: Serielles Gerät (Dopplung möglich)

Ansprechpartner: Frau Muster 1234 (Dopplung möglich)

Standort: MustergebäudeMusterraum (Dopplung möglich)

Datum der Erfassung: yyyy-mm-dd hh-mm-ss (eindeutig)

Kann oder sollte ich damit noch irgendwas verändern bzw. auf mehrere Tabellen aufteilen? Ich hab mir da schon ne Weile drüber Gedanken gemacht, aber ich wüsste nicht, wo ich da ansetzen sollte.

Danke

Bearbeitet 18. März 2011 von Dugong

[gimbo]

Es sind nicht alle Felder atomar, also wird eigentlich die erste Normalform bereits verletzt. Nun kann man darüber streiten, ob eine weitere Aufspaltung der Felder wirklich nutzbringend ist, aber wie sähen z.B. die Anfragen für folgende Fälle aus?

1. Ich will alle Drucker wissen die in einem bestimmten Gebäude stehen

2. Ich möchte alle Einträge sehen bei denen HP-Drucker verwendet werden

3. Ich möchte wissen wie viele weibliche Ansprechpartner es gibt

4. Ich möchte alle Drucker wissen die auf USB aufgerüstet werden sollen

Das würde vermutlich zu Abfragen mit LIKE führen, was nicht sonderlich elegant ist und recht schnell zu Anomalien führen kann (häufig durch Variationen der Schreibweise oder schlichtweg Rechtschreibfehler). Sind diese Abfragen nicht notwendig, dann kann man darüber hinweg sehen. Allerdings schränkt die jetzige Realisierung die Erweiterbarkeit ein.

[Klotzkopp]

Ziel ist es einen Netzwerkscanner zu programmieren, der interne und externe Printserver aus dem Netz filtert und deren Informationen in eine Datenbank schreibt.

So eine Datenbank ist ja kein Selbstzweck. Wie sollen diese Daten denn genutzt werden? Was sind typische Abfragen? Was muss erfasst werden? Du sprichst von Printservern, aber du erfasst offenbar auch noch die Drucker, die Anschlüsse, die Standorte und die Ansprechpartner. Im ersten Schritt sind das potenzielle Relationen.

gimbo hat ja ein paar schöne Beispiele geliefert, bei denen dein Datenmodell schon arg ins Schwitzen kommt, hauptsächlich wegen Verletzung der 1. Normalform. Dein Datenmodell kommt beispielsweise auch nicht damit klar, wenn ein Printserver mehr als einen USB-Drucker hat, oder zusätzliche parallele Schnittstellen.

Aber wie gesagt, die Modellierung hängt davon ab, wie die Daten verwendet werden sollen.

[itazubi]

du könntest:

Hersteller

Typ

LPT

COM/USB

Ansprechpartner

Standort

in eigene Tabellen schreiben. Verknüpft werden die dann per Fremdschlüssel.

Am sinnvollsten wäre es bei LPT. Der PA wird das anstreichen bei LPT. Du hast nämlich 2 mal die selben Typen drinen. Das entspricht nicht der 3. Normalform. :mod:

[Dugong]

Okay, dann geh ich mal etwas genauer darauf ein.

Das GUI bietet die Möglichkeit eine Range scannen zu lassen, ist das Prog damit fertig werden die Daten in eine "lokale Tabelle", also ein DataGridView im Programm geschrieben, die nichts mit der Datenbank zu tun hat und genau die Struktur aufweist, wie ich sie oben abgebildet habe.

Weiterhin gibt es noch eine Tabelle bzw DataGridView, das die Datenbank darstellt. Also man kann über zwei Tabs auswählen ob er mir die "lokale Tabelle" oder die Datenbanktabelle zeigen soll.

Jetzt kann man, wenn man die Druckerbestände eingescannt hat und in der "lokalen Tabelle" erfasst, per Button eben diese Tabelle zur Datenbank schicken, so dass sich diese mit den Beständen füllt (Datenbank und lokale Tabelle weisen ja im Moment noch exakt den gleichen Aufbau auf).

Ebenso ist es jederzeit möglich den Auftrag zu geben, dass die Datenbank ausgelesen werden soll und dann im Programm in das Datenbank-DataGridView geschrieben wird. Also zusammengefasst: in die lokale Tabelle kommt immer nur das Ergebnis des Scanvogangs, welches dann in die Datenbank auf dem Server geschickt werden kann, und in die Datenbanktabelle im Programm kommen immer nur die Daten, welche sich in der Datenbank auf dem Server befinden.

Wenn diese Datenbanken bzw. Tabellen immer den selben Aufbau hätten (so wie es im Moment der Fall ist) vereinfacht das die Sache natürlich erheblich, aber ich mache mir Gedanken darüber ob ich das vorm Prüfungsausschuss so zeigen sollte, und da ich angegeben habe ein ERM zu erstellen wäre das mit einer Tabelle und ohne Abhängigkeiten etc. schon mager.

Bei dem wenigen Wissen, das ich im Moment über Normalisierung habe, weiß ich, dass für die Normalformen zB. noch mindestens 2 Tabellen, nämlich für Hersteller und Druckertypen, dazugehören.

Wie gesagt, die Frage, die ich jetzt an euch stelle ist: ist es notwendig, dass ich mir jetzt noch die "Mühe" mache die Datenbank zu normalisieren (wenn ja dann gleich die Frage wie ^^) oder kann ich in die Doku schreiben nachträglich wurde das ERM doch nicht erstellt, weil nur eine Tabelle etc.

Ein weiteres nicht unerhebliches Problem ist, dass wir definitiv nicht alle Druckertypen wissen (wir reden hier über ca. 800 Geräte insgesamt), die wir einsetzen und somit könnte ich nicht alle in eine zusätzliche Tabelle schreiben. Weiterhin soll das Programm auch für die Zukunft gerüstet sein und wir wissen natürlich nicht, welche Drucker wir in Zukunft anschaffen.

Wenn ich immer alle Informationen von allen Geräten einholen könnte, wäre das ja kein Problem, aber da ich die Anfragen über SNMP und Telnet ausführe kommt es bei manchen Geräten durchaus vor, dass zB. nur der Hersteller und nicht der Typ erfasst wird (zB. bei komplexen Ettikettendruckern) oder, dass kein Ansprechpartner oder kein Standort eingetragen ist, weil das Gerät das nicht unterstützt.

Zu den Fragen, die ihr gestellt hattet zwecks suche nur nach HP etc.:

Nein, so etwas ist nicht geplant. Wenn gescannt wird, dann immer nach allen druckfähigen Geräten, die in der angegebenen Range enthalten sind und diese Infos werden dann in die Tabelle geschrieben. Das einzige "Filtern" kann man durch das Sortieren nach zB Hostname, Typ etc. machen, mehr ist auch nicht gefordert.

Das Hauptziel des Programmes ist es, alle Geräte zu erfassen.

Das mit dem LPT1,2 und COM ergibt sich dadurch, dass wir sowohl normal am Netz angeschlossene Drucker haben mit nem internen Printserver, als auch Axis Printserver, wo man mehrere Drucker, die normal nicht Netzfähig sind, anschließen kann.

Ich hoffe die Infos waren hilfreich^^ schonmal vielen Dank, hat mir schon etwas weitergeholfen.

edit: Das mit dem zB "ich will nur Drucker die in einem bestimmten Gebäude sind" lässt sich nicht realisieren. Das Programm ist auch dafür gedacht, weil das Problem besteht, dass sich erst jetzt auf eine uniforme Syntax geeinigt wurde (Betrieb Gebäude Etage Raum). Zur Zeit steht in fast jedem Drucker nicht diese Form und weil wir das ändern wollen habe ich das Programm so geschrieben, dass er dann gleich in die Tabelle schreibt "Falsches Format, bitte ändern". Das selbe ist beim Ansprechpartner der Fall.

Bearbeitet 18. März 2011 von Dugong

[Klotzkopp]

Wie gesagt, die Frage, die ich jetzt an euch stelle ist: ist es notwendig, dass ich mir jetzt noch die "Mühe" mache die Datenbank zu normalisieren (wenn ja dann gleich die Frage wie ^^) oder kann ich in die Doku schreiben nachträglich wurde das ERM doch nicht erstellt, weil nur eine Tabelle etc.

Nein. Ob eine Tabelle ausreicht, weißt du erst nach der Normalisierung. Du kannst dir natürlich die Normalisierung schenken (was keinen guten Eindruck macht), aber du kannst das nicht damit begründen, dass du nur eine Tabelle brauchst. Da vertauschst du Ursache und Wirkung.

Ein weiteres nicht unerhebliches Problem ist, dass wir definitiv nicht alle Druckertypen wissen (wir reden hier über ca. 800 Geräte insgesamt), die wir einsetzen und somit könnte ich nicht alle in eine zusätzliche Tabelle schreiben. Weiterhin soll das Programm auch für die Zukunft gerüstet sein und wir wissen natürlich nicht, welche Drucker wir in Zukunft anschaffen.

Wenn ich immer alle Informationen von allen Geräten einholen könnte, wäre das ja kein Problem, aber da ich die Anfragen über SNMP und Telnet ausführe kommt es bei manchen Geräten durchaus vor, dass zB. nur der Hersteller und nicht der Typ erfasst wird (zB. bei komplexen Ettikettendruckern) oder, dass kein Ansprechpartner oder kein Standort eingetragen ist, weil das Gerät das nicht unterstützt.

Die Verfügbarkeit der Daten hat aber nichts mit dem Datenmodell zu tun. Das Problem hast du so oder so.

Das Hauptziel des Programmes ist es, alle Geräte zu erfassen.

Und welchem Zweck dient dieses Ziel? Ich sehe da bisher nur eine Lösung ohne dazugehöriges Problem. Wenn niemand mit diesen Daten arbeitet, braucht man sie nicht zu erfassen.

edit: Das mit dem zB "ich will nur Drucker die in einem bestimmten Gebäude sind" lässt sich nicht realisieren.

Was heißt, es lässt sich nicht realisieren? Wird das nicht benötigt? Auch in Zukunft nicht?

Das Programm ist auch dafür gedacht, weil das Problem besteht, dass sich erst jetzt auf eine uniforme Syntax geeinigt wurde (Betrieb Gebäude Etage Raum). Zur Zeit steht in fast jedem Drucker nicht diese Form und weil wir das ändern wollen habe ich das Programm so geschrieben, dass er dann gleich in die Tabelle schreibt "Falsches Format, bitte ändern". Das selbe ist beim Ansprechpartner der Fall.

Gut, das ist schon mal ein Zweck. Aber du schreibst "auch dafür". Wofür denn noch?

[gimbo]

Wenn diese Datenbanken bzw. Tabellen immer den selben Aufbau hätten (so wie es im Moment der Fall ist) vereinfacht das die Sache natürlich erheblich (...)

Vereinfacht was? Die Anzeige? Ja, aber die Datenbankstruktur darf sich nicht danach richten wie die Daten später angezeigt werden. Datenhaltung und Anzeige sind zwei verschiedene Schichten und sollten lose gekoppelt sein. Die Datenbankstruktur sollte so flexibel sein, dass alle Ausgabeformen und alle (wahrscheinlichen) Teilmengen möglich sind. Wenn die Softwarearchitektur sauber sein soll, dann darf die Anzeige der Daten hier also nicht von Relevanz sein.

Um dennoch weiterhin ein 1:1-Mapping zwischen Anzeigetabelle und Datenbanktabelle zu ermöglichen, kann man eine View erstellen.

Bei dem wenigen Wissen, das ich im Moment über Normalisierung habe, weiß ich, dass für die Normalformen zB. noch mindestens 2 Tabellen, nämlich für Hersteller und Druckertypen, dazugehören.

Das ist in diesem Fall naheliegend, aber man darf sich die Datenbanknormalisierung nicht als determinischen Vorgang vorstellen. Aus einer nicht normalisierten Datenbank kann man viele verschiedene normalisierte Datenbanken erstellen. Das Ergebnis ist also nicht eindeutig. Auch Begriffe wie "atomar" sind nicht feststehend. Wenn ich beispielsweise definiere, dass eine Telefonnr. inkl. Vorwahl für mich ausreichend atomar ist, dann ist das halt so. Es hängt natürlich von den Einsatzmöglichkeiten der Software ab. Bei eine Software für die Telefonauskunft würde ich Vorwahl und Telefonnr. tendenziell in zwei verschiedene Felder packen und die Vorwahl in eine Orte-Tabelle auslagern, bei einer Software für Sportvereine würde ich vermutlich alles in ein einziges Feld speichern.

Wie gesagt, die Frage, die ich jetzt an euch stelle ist: ist es notwendig, dass ich mir jetzt noch die "Mühe" mache die Datenbank zu normalisieren (wenn ja dann gleich die Frage wie ^^) oder kann ich in die Doku schreiben nachträglich wurde das ERM doch nicht erstellt, weil nur eine Tabelle etc.

Naja, ingenieursmäßig ist es schon besser eine Normalisierung durchzuführen. Es ist halt dein Abschlussprojekt und dort sollte man schon zeigen dass man so etwas kann. Ein Softwareentwickler macht sich über so etwas überhaupt keine Gedanken mehr, weil er es für ihn selbstverständlich ist. Ein Entwickler hätte diese Tabelle in der Zeit, in der ich diese Antwort geschrieben habe, wahrscheinlich schon vollständig normalisiert.

Ein weiteres nicht unerhebliches Problem ist, dass wir definitiv nicht alle Druckertypen wissen (wir reden hier über ca. 800 Geräte insgesamt), die wir einsetzen und somit könnte ich nicht alle in eine zusätzliche Tabelle schreiben. Weiterhin soll das Programm auch für die Zukunft gerüstet sein und wir wissen natürlich nicht, welche Drucker wir in Zukunft anschaffen.

Sofern sich die Druckertypen auslesen lassen, müssen neue Typen natürlich in der Datenbank automatisch hinzugefügt werden.

Wenn ich immer alle Informationen von allen Geräten einholen könnte, wäre das ja kein Problem, aber da ich die Anfragen über SNMP und Telnet ausführe kommt es bei manchen Geräten durchaus vor, dass zB. nur der Hersteller und nicht der Typ erfasst wird (zB. bei komplexen Ettikettendruckern) oder, dass kein Ansprechpartner oder kein Standort eingetragen ist, weil das Gerät das nicht unterstützt.

Dann steht bei diesen Feldern halt NULL statt der Fremdschlüsselverweis. Wenn man die Daten nicht hat, dann lässt sich das halt nicht ändern. Dass die Daten geliefert werden ist eher ein Problem der Netzwerktechniker.

Zu den Fragen, die ihr gestellt hattet zwecks suche nur nach HP etc.:

Nein, so etwas ist nicht geplant. Wenn gescannt wird, dann immer nach allen druckfähigen Geräten, die in der angegebenen Range enthalten sind und diese Infos werden dann in die Tabelle geschrieben. Das einzige "Filtern" kann man durch das Sortieren nach zB Hostname, Typ etc. machen, mehr ist auch nicht gefordert.

Das Hauptziel des Programmes ist es, alle Geräte zu erfassen.

Also ist die Software statisch und nicht erweiterbar? Bzw. wenn man es erweitern möchte, müsste man dort einiges an Zeit investieren weil bei der Erstellung 2 Stunden gespart wurden?

Ich halte es immer noch für fragwürdig. Du scheinst diese Entscheidung danach zu richten, ob du sie mit deiner jetzigen Kompetenz schnell und sicher umsetzen kannst. Das darf aber gerade bei gewöhnlichem Handwerk (und Datenbanken gehören für einen FIAE dazu) nicht der Maßstab sein.

Bearbeitet 18. März 2011 von gimbo

[Dugong]

Nein. Ob eine Tabelle ausreicht, weißt du erst nach der Normalisierung. Du kannst dir natürlich die Normalisierung schenken (was keinen guten Eindruck macht), aber du kannst das nicht damit begründen, dass du nur eine Tabelle brauchst. Da vertauschst du Ursache und Wirkung.

Wenn es danach geht ist eine Normalisierung natürlich notwendig, da es ja noch Redundanz gibt.

Die Verfügbarkeit der Daten hat aber nichts mit dem Datenmodell zu tun. Das Problem hast du so oder so.

Ja, ich verstehe. Ich habe es mir wohl etwas zu einfach gemacht dabei.

Und welchem Zweck dient dieses Ziel? Ich sehe da bisher nur eine Lösung ohne dazugehöriges Problem. Wenn niemand mit diesen Daten arbeitet, braucht man sie nicht zu erfassen.

Das Ziel des gesamten Programmes ist es, im Zuge einer Betriebssystemumstellung des gesamten Werksgeländes, alle druckfähigen Geräte zu erfassen, da wir atm keine vollständige Liste haben, um die Treiberkompatibilität zu prüfen später. Ansprechpartner, Standort und Telefonnummer sind dafür da um mit den Usern einfacher in Kontakt treten zu können.

Was heißt, es lässt sich nicht realisieren? Wird das nicht benötigt? Auch in Zukunft nicht?

Nein, wird es nicht. Das Programm soll nur o.g. Zweck erfüllen. Zum Ändern der Einstellungen und Informationen benutzen wir andere Programme, die aber wie gesagt entweder herstellerspezifisch sind, oder schlicht nicht alle Geräte erfassen können. Da komme ich dann wieder ins Spiel.

[Carnie]

Na dann mal 2 Fragen.

Gibt es immer nur einen Ansprechpartner ?

Ist ein Ansprechpartner für mehrere Geräte zuständig ?

Das alles in eine Tabelle zu packen ist Blödsinn und widerspricht jeglicher Normalisierung. Ich bin kein Prüfer aber wenn du mir das so vorgesetzt hättest würde ich dir dafür massiv Punkte abziehen und mindestens 1-2 Fragen im Gespräch bringen.

[Dugong]

Hey, ich editiere das hier morgen, bin grade nicht auf arbeit, habe es mal normalisiert, wie gesagt das zeige ich euch dann morgen, wenn ich dann auch mit dem ERM anfangen will.

Grüße

[Dugong]

Asche auf mein Haupt, aber ich hab keine Ahnung wo hier der Editbutton ist... btw gefällt mir die neue Ajax Lösung sehr gut

Also hier meine (nach bestem Wissen) normalisierte Datenbank:

Tabelle producer

ID PK

Name

Tabelle type

ID PK

Name

ProducerID FK

Tabelle Owner

ID PK

Name

Number

LocationID FK

Tabelle Location

ID PK

Name

Tabelle Axis

ID PK

LPT1ID FK

LPT2ID FK

COMID FK

Tabelle Axisprinter

ID PK

Name

Tabelle Main

IP PK

Hostname

AxisID(oder NULL)

TypeID

OwnerID

Was sagt ihr dazu? Kann ich das so verwenden oder ist es noch nicht atomar? Eigentlich sind jetzt alle Sachen eindeutig.

[Klotzkopp]

Ohne Beschreibung, worauf sich die jeweiligen Fremschlüssel beziehen, ist das schwer zu beurteilen. Bei einigen kann man es ja am Namen sehen, aber nicht bei allen.

Wie sehen die Beziehungen aus?

Was repräsentieren die einzelnen Tabellen (Main? Axis?)

Ich sehe da jedenfalls ein Problem, wenn ein Printserver mehr als 2 LPT-Ports oder mehr als einen USB-Drucker hat. Warum legst du dich da derart fest?

[Dugong]

Die AxisID in der Main bezieht sich auf die ID in der Axistabelle. Die LPT1ID etc. in dieser beziehen sich auf einen Axisprinter in der Axisprinter Tabelle.

Ich lege mich so fest, weil es vom Auftraggeber gewünscht war, die derzeitige IT-Landschaft zu berücksichtigen. Jetzt und in absehbarer Zukunft wird es hier keine Printserver geben, die andere Anschlüsse haben als die berücksichtigten. Die Funktionen im Code selbst sind so modular gehalten, dass eine Erweiterung mit wenigen Handgriffen möglich wäre. Wenn ein Axis keinen Drucker angeschlossen hat an zB COM gibts ein NULL.

Die Axistabelle repräsentiert einen Axis-Printserver, der als einziger die Möglichkeit in der Landschaft bietet Geräte anzuschließen. Die Main ist die, aus der ich dann per SQL die wichtigsten Informationen auslese, quasi die Haupttabelle in der alles zusammengeführt wird.

[Klotzkopp]

Die Funktionen im Code selbst sind so modular gehalten, dass eine Erweiterung mit wenigen Handgriffen möglich wäre.

Dir ist aber klar, dass du nicht nur den Code, sondern möglicherweise auch die Datenbankstruktur ändern musst? Sobald jemand einen zweiten seriellen Drucker anschließt, passt dein Datenmodell nicht mehr. Und die Lösung ist nicht, dass du in Axis ein weiteres Fremdschlüsselfeld einbaust. Nimm die Fremschlüssel aus Axis raus, und füge in Axisprinter eine AxisID hinzu, sowie Felder, die Anschlussart und -nummer aufnehmen können.

Die Main ist die, aus der ich dann per SQL die wichtigsten Informationen auslese, quasi die Haupttabelle in der alles zusammengeführt wird.

Aber was für ein reales Objekt repräsentiert ein Main-Datensatz? Hostname legt nahe, dass es sich um einen Rechner handelt. TypeID lässt eher auf einen Drucker schließen.