Fehler im DB-Modell?

[Christoph]

Hallihallo,

ich habe da mal eine Frage: Ein DB-Modell von mir soll falsch sein. Jemand meinte es wäre nicht in der 3. Normalform und andere kleine Fehler wären drin, nur ehrlich gesagt weiss ich nicht welche :(

Wenn Ihr mir da etwas weiterhelfen könntet!

[img:http://www.cgdesign.de/download/dbmodell4.gif]

Gruß Christoph

[Christoph]

sorry

<img src="http://www.cgdesign.de/download/dbmodell4.gif" border="0" alt="">

[Stefan Falz]

Hallo,

das was mir jetzt so auf die Schnelle einfällt, wäre die redundante
Speicherung der Kund_Id in einigen Tabellen, in denen Sie nicht
benötigt wird. Durch die Zuweisung der Nw_Id sind bspw. die Server
und die Workstations auch einem Kunden zugeordnet, da die Netzwerke
die Kund_Id innehaben.
Als zweites würde ich sagen, dass Workstations und Server ziemlich
gleich sind. Die beiden Tabellen hätte man als eine einzige mit
einem Attribut "Type" (o.ä.) realisieren können. Dort steht dann
drin, ob es ein Server oder eine WS ist.
Was du mit Actions vorhast, weiß ich jetzt nicht, daher kann ich
nicht sagen, ob das so OK ist (könnte man aber wahrscheinlich
trotzdem anders lösen ;)

Nur so am Rande. Man kann sich auch totnormalisieren. Die dritte
NF gilt als Mittelweg, aber es gibt auch Fälle, da kann und will
man ggfs. gar nicht so weit gehen.
Damit meine ich u.a. dass man wie oben geschrieben, WS und Server
zusammenlegt und die Spalten, die jeweils nur für WS _oder_ Server
benötigt werden, wiederum in eigene Tabellen auslagert, ...

BTW: Dir hat das jemand gesagt, OK. Aber dann hätte er dir auch
gleich sagen können, wo derjenige denn die Probleme sieht.

Tschau, Stefan

[Christoph]

Hi Stefan,

erstmal Danke für deine Mühe, ich versuchs mal zu erklären: Ich habe am Montag mündliche Prüfung und werde in DB geprüft. Nun sagte mir jemand das ich über meine Arbeit in DB geprüft werde, wo ich halt dieses DB-Modell erstellt habe. Und dieser Prüfer meinte halt das da Fehler wären. Natürlich hat er mir nicht gesagt welche.

Ok nun zu DB Beschreibung mal selber: Es gibt einen Kunden (Firma), dieser hat 1 oder mehrere Ansprechpartner in der Firma.

Der Kunde hat auch immer eine Workstation, einen Server, ein Netzwerk oder sonstiges deswegen die Trennung. Ok er muss keinen Server haben und auch kein Netzwerk, manche Kunden haben nur eine Workstation oder nur einen Server oder nur sonstiges. Jedenfalls die Actions bedeuten das dort alles reingeschrieben wird, was man an dem Server geändert hat oder bei der WS oder im Netzwerk usw. Das wird alles protokolliert und in der DB gespeichert.

das was mir jetzt so auf die Schnelle einfällt, wäre die redundante
Speicherung der Kund_Id in einigen Tabellen, in denen Sie nicht
benötigt wird. Durch die Zuweisung der Nw_Id sind bspw. die Server
und die Workstations auch einem Kunden zugeordnet, da die Netzwerke
die Kund_Id innehaben.

Stichwort referentielle Integrität: Wenn ich einen Kunden lösche, dann natürlich alle seine Server + WS + sein Netzwerk + Sonstiges. Ok wenn ich nur einen Server lösche, dann nicht gleich den ganzen Kunden.

Gruß Christoph

[Stefan Falz]

Hallo Christoph,

halt dieses DB-Modell erstellt habe. Und dieser Prüfer meinte halt das da Fehler wären. Natürlich hat er mir nicht gesagt welche.

OK, klingt plausibel ;)

Der Kunde hat auch immer eine Workstation, einen Server, ein Netzwerk oder sonstiges deswegen die Trennung. Ok er muss keinen Server haben und auch kein Netzwerk, manche Kunden haben nur eine Workstation oder nur einen Server oder nur sonstiges.

OK, dann kann man WS und Server zuammenlegen und ein zusätzliches
Attribut zur Unterscheidung einbringen.

Jedenfalls die Actions bedeuten das dort alles reingeschrieben wird, was man an dem Server geändert hat oder bei der WS oder im Netzwerk usw. Das wird alles protokolliert und in der DB gespeichert.

Hätte ich etwa so gemacht (nur so auf die Schnelle, daher bestimmt
auch noch verbesserungsbedürftig)

Ac_Id
Ac_Type (Server, Ws, ... -> ggfs. als numerischen Wert, der in einer
weiteren Tabelle [tblTypes o.ä.] definiert wurde)
Ac_Timestamp
Ac_Beschreibung

Stichwort referentielle Integrität: Wenn ich einen Kunden lösche, dann natürlich alle seine Server + WS + sein Netzwerk + Sonstiges.

OK, wenn der Kunde kein Netzwerk haben muß (sah für mich auf den
ersten Block so aus) hast du Recht. Ansonsten würde das auch so
gehen.

Tschau, Stefan

[Christoph]

Hallo Christoph,

Hi Stefan,

OK, dann kann man WS und Server zuammenlegen und ein zusätzliches
Attribut zur Unterscheidung einbringen.

Hm das wär mir aber zu viel geworden zu unübersichtlich oder nicht?

Hätte ich etwa so gemacht (nur so auf die Schnelle, daher bestimmt
auch noch verbesserungsbedürftig)

Ac_Id
Ac_Type (Server, Ws, ... -> ggfs. als numerischen Wert, der in einer
weiteren Tabelle [tblTypes o.ä.] definiert wurde)
Ac_Timestamp
Ac_Beschreibung

Wäre auch eine Möglichkeit, hmmm...

OK, wenn der Kunde kein Netzwerk haben muß (sah für mich auf den
ersten Block so aus) hast du Recht. Ansonsten würde das auch so
gehen.

Naja eigentlich hat ja jede Firma ein Netzwerk. Auch haben alle Kunden eigentlich mindestens einen PC. Aber so siehts real aus aber nicht bei den Prüfern wohl :/

Gruß Christoph

[Daniela Koller]

Hi Christoph

Mir fallen einige gefährliche Dinge auf. Diese können aber auch völlig ok sein je nachdem was da ganz genau rein soll, deswegen zähl ich einfach mal auf wo und warum ich Bedenken habe.

• Tabelle Workstation und Server: Software, hat ein Server und eine Workstation garantiert nur eine Software? Ansonsten kriegst du Probleme mit der 1. NF.

• Tabelle Action: Die vielen Keyfelder, je nach Anwendungszweck kann es so mühsam werden zuzugreifen, grundsätzlich aber richtig.

• Tabelle Ansprechpartner: Streng genommen sind Tel, Handy und Fax kritisch wegen der 1. NF, praktisch wirds aber wohl reichen.

• Die Passwörter in der Datenbank gefallen mir nicht wirklich, ich hoffe, sie sind wenigstens verschlüsselt.

• Den Zweck der Tabelle Sonstiges verstehe ich nicht.

• Was ist mit der IP des Netzwerkes gemeint? Broadcastip oder die IP mit 0 am Ende zur Identifikation des Netzwerks.

• Die Verknüpfungen sind auf dem Bild sehr unübersichtlich, könntest du das etwas auseinander ziehen das man es besser sieht?

Ich würde dem Datenmodell nach behaupten dass das für eine Firma/Abteilung ist die Support leistet für Netze mit Servern und Workstations sowie einzelne Server und Workstations.

Gruss Daniela

[Christoph]

Hi Daniela,

Habe erstmal etwas auseinander gezogen: http://www.cgdesign.de/download/dbmodell.gif

• Tabelle Workstation und Server: Software, hat ein Server und eine Workstation garantiert nur eine Software? Ansonsten kriegst du Probleme mit der 1. NF.

Ähm naja ist ein Textfeld, wo man mehrere reinschreiben kann. Ich habe auch schon überlegt wegen 1.NF aber wenn dann müsste man ganz schon viele Softwarefelder erstellen!

• Tabelle Action: Die vielen Keyfelder, je nach Anwendungszweck kann es so mühsam werden zuzugreifen, grundsätzlich aber richtig.

hm was würdest du vorschlagen?

• Tabelle Ansprechpartner: Streng genommen sind Tel, Handy und Fax kritisch wegen der 1. NF, praktisch wirds aber wohl reichen.

dachte ich eigentlich auch, das es reichen sollte. Weil meistens hat der Ansprechpartner nur eine Handynummer oder eine Faxnummer usw.

• Die Passwörter in der Datenbank gefallen mir nicht wirklich, ich hoffe, sie sind wenigstens verschlüsselt.

ähm nunja, mit MySQL als PASSWORD habe ich Sie nicht verschlüsselt und leider in den php Scripten auch nicht. Ok gut sollte man überdenken.

• Den Zweck der Tabelle Sonstiges verstehe ich nicht.

Hihi ich ehrlich gesagt auch nicht, hat mir nur mein Chef vorgegeben gehabt. Quasi alles was nicht ins Netzwerk, unter WS oder Server passt, kommt in Sonstiges.

• Was ist mit der IP des Netzwerkes gemeint? Broadcastip oder die IP mit 0 am Ende zur Identifikation des Netzwerks.

Ja die normale IP eines Netzwerkes z.B. 192.123.17.2 usw...

Ich würde dem Datenmodell nach behaupten dass das für eine Firma/Abteilung ist die Support leistet für Netze mit Servern und Workstations sowie einzelne Server und Workstations.

Nicht ganz. Meine Firma wollte nur in einem Intranet System einen Überblick haben von allen unseren Kunde, was die installiert haben, welchen Server usw halt. Damit Sie schneller zugreifen können. Also auch beim Kunden dann, dort eintragen in die Actions was Sie gerade beim Kunden machen, was Sie vielleicht noch brauchen, an neuen PC Teilen usw... Hoffe das es Dir vielleicht ewtwas weiter hilft.

Trotzdem erstmal vielen Dank!

Gruß Christoph

[Andreas Schneider]

Hallo Christoph,

• Tabelle Workstation und Server: Software, hat ein Server und eine Workstation garantiert nur eine Software? Ansonsten kriegst du Probleme mit der 1. NF.
  Ähm naja ist ein Textfeld, wo man mehrere reinschreiben kann. Ich habe auch schon überlegt wegen 1.NF aber wenn dann müsste man ganz schon viele Softwarefelder erstellen!

Nein, sondern zwei zusätzliche Tabellen:

1. Software, mit Id, Programmname
2. ServerSoftware mit ServerId, SoftwareId

Grüße
Andreas

[Daniela Koller]

Hi Christoph

• Tabelle Workstation und Server: Software, hat ein Server und eine Workstation garantiert nur eine Software? Ansonsten kriegst du Probleme mit der 1. NF.
  Ähm naja ist ein Textfeld, wo man mehrere reinschreiben kann. Ich habe auch schon überlegt wegen 1.NF aber wenn dann müsste man ganz schon viele Softwarefelder erstellen!

Nein! Das verletzt die erste Normalform genauso. Das müsstest du in eine weitere Tabelle auslagern (evtl 2 mit Verknüpfungstabelle).

• Tabelle Action: Die vielen Keyfelder, je nach Anwendungszweck kann es so mühsam werden zuzugreifen, grundsätzlich aber richtig.
  hm was würdest du vorschlagen?

Ich würde vorschlagen, du suchst mal nach Bogen- resp Subtypendesign und liest dich etwas ein. Eine Möglichkeit wäre auch was Stefan vorschlägt, ein Feld Typ, ein weiteres Key und die zusammen zeigen an, welche Tabelle verknüpft wird mit welchem Datensatz (Müsste eines der Bogendesigns sein).

• Tabelle Ansprechpartner: Streng genommen sind Tel, Handy und Fax kritisch wegen der 1. NF, praktisch wirds aber wohl reichen.
  dachte ich eigentlich auch, das es reichen sollte. Weil meistens hat der Ansprechpartner nur eine Handynummer oder eine Faxnummer usw.

Wenns dein Prüfer streng nimmt, wird er dir einfach dann sagen, Tel, Handy und Fax und all das sind ein und das selbe und du müsstest es auslagern zusammen mit einem Typ (Festnetz, Handy...). Vorteil wäre, das du nur die Nummer gespeichert hast, die wirklich existieren und auch mehr Nummern haben kannst als jetzt bei dir (zb Geschäftsnummer und Privatnummer Festnetz).

• Den Zweck der Tabelle Sonstiges verstehe ich nicht.
  Hihi ich ehrlich gesagt auch nicht, hat mir nur mein Chef vorgegeben gehabt. Quasi alles was nicht ins Netzwerk, unter WS oder Server passt, kommt in Sonstiges.

Für WS, Server und Sonstiges würde ich mir in dem Fall Subtypendesign resp Bogendesign genau anschauen, es scheint alles ein Spezialfall einer Netzwerkkomponente zu sein.

• Was ist mit der IP des Netzwerkes gemeint? Broadcastip oder die IP mit 0 am Ende zur Identifikation des Netzwerks.
  Ja die normale IP eines Netzwerkes z.B. 192.123.17.2 usw...

Das ist eine KomponentenIP und nicht die eines Netzwerks.

Gruss Daniela *die jetzt zur Vorlesung muss und sich das Bild deswegen erst später ansehen wird*

[Christoph]

Hi Daniela

Was bitte ist Bogen- resp Subtypendesign? Dazu habe ich nichts bei google oder sogar bei Helmut Balzert gefunden :(
Gibts da irgendwo ne gute Seite wo ich mich trotzdem belesen kann?

Vielen Dank

Gruß Christoph

[Daniela Koller]

Hi Christoph

Gibts da irgendwo ne gute Seite wo ich mich trotzdem belesen kann?

Ich habe es aus den Oracle Kursunterlagen, nur leider sind die nicht frei verfügbar. Ich versuchs mal zu erklären:

Subtypdesign: Funktioniert wie Vererbung in der objektorientierten Welt, du hast eine Supertype Netzwerkkomponenten, darin Untertypen Server, Workstation... Der Supertyp beinhaltet alle Datenfelder und Beziehungen die in allen Untertypen drin sind, die Untertypen jeweils das spezielle. Gezeichnet wird das ganze als Vierecke mit runden Ecken wobei die Vierecke der Subtypen im Viereck des Supertypes beinhaltet sind. (Sieht anders aus, ist aber identisch zu Vererbung).

Bogendesign: Du hast eine Fremdschlüsselbeziehung zu mehreren Tabellen, das wäre dann in etwa wie du es gelöst hast, Workstation, Server... sind eigene vollständige Tabellen. Durch die Fremdschlüsselbeziehungen ziehst du einen Bogen um zu zeigen, das nur eine der Beziehungen gleichzeitig existent ist. Nehmen wir als Beispiel deine Action Tabelle, du hast viele Links zu Workstation, Server..., durch die müsste ein Bogen weil ja effektiv eine Action nur eine Komponente betrifft. Der Bogen drückt das explizit aus.

Umgesetzt kann beides auf mehrere Arten werden: Subtypendesign kann mit Vererbung umgesetzt werden falls dein DBMS das beherrscht.

Ansonsten kann beides entweder so umgestzt werden wie du es hast, also mit einzelnen FK-Feldern in Action wovon nur eines besetzt ist, oder aber mit einem FK-Feld und einem Feld was anzeigt, wohin der Link geht.

Gruss Daniela *hoff dass es einigermassen verständlich war*

[Klaus Mock]

Hallo Daniela,

... oder aber mit einem FK-Feld und einem Feld was anzeigt, wohin der Link geht.

Kannst Du mir vielleicht erklären, wie so etwas in Oracle genau umgesetzt werden kann.

Ich habe derzeit nämlich genau dieses Problem.  Ich habe Tabellen, die zwar verschiedene 'Objekte' innerhalb der Anwendung repräsentieren, aber ab einem bestimmten Punkt doch wieder nur einfach als Objekte gesehen werden sollten. Im speziellen geht es dabei um Zugriffsrechte.
Also habe ich eine Tabelle gebaut in der die Rechte eben diese Objekte vergeben werden sollen. Dabei wird der Objekt-Typ und dessen ID in zwei Spalten abgelegt. Allerdings ist mir kein Weg bekannt, einen Constraint so aufzubauen, daß ich hier wirklich eine, sagen wir mal sternförmige, Foreign-Keybeziehung zu den übrigen Tabellen habe.

Derzeit realisiere ich das Befüllen und Löschen in dieser Tabelle über Trigger, die beim INSERT und DELETE in den jeweiligen Tabellen greifen. Das funktioniert zwar, aber irgendwie finde ich  daß das nur eine Notlösung ist.

Ich bin der Meinung, daß so eine Aufgabenstellung doch öfter vorkommen müßte und daß gerade Oracle dafür eine brauchbare Antwort haben sollte, aber vielleicht habe ich ja auch nur falsch gedacht.

Vielleicht hast Du oder sonst jemand eine sinnvollere Idee als mein Herumgetriggere.

Grüße
  Klaus

[Daniela Koller]

Hi Klaus

Kannst Du mir vielleicht erklären, wie so etwas in Oracle genau umgesetzt werden kann.

Derzeit realisiere ich das Befüllen und Löschen in dieser Tabelle über Trigger, die beim INSERT und DELETE in den jeweiligen Tabellen greifen. Das funktioniert zwar, aber irgendwie finde ich  daß das nur eine Notlösung ist.

Laut meinem Dozenten vom letzten Semester ist genau das das Problem bei dieser Lösung, das es eben nicht möglich ist, Constraints aufzubauen für den Fall und die Lösung dann genau so aussieht wie du sie gebaut hast.

Für den anderen Fall sieht es auch nicht besser aus. Da muss man sicherstellen, dass genau eins der Felder gefüllt ist und eine gültige Beziehung aufweist. Das gültige Beziehung ist da kein Problem, aber das genau 1.

Gruss Daniela

[Klaus Mock]

Hallo Daniela,

Danke, eine Bestätigung aus berufenem Munde ist immer eine Wohltat. Obwohl... ich finde es schon eigenartig, daß solch ein Konzept bei praktisch keiner gängigen relationalen Datenbank vernünftig umsetzbar ist. afaik kann man so etwas mit Informix machen, aber die ist ja inzwischen eher in die Versenkung verschwunden. Naja, was soll's. So lange einem noch Wege einfallen, es doch irgendwie zu realisieren, ist ja nicht alles verloren.

Danke nochmals und Grüße aus der (derzeit wirklich sonnigen) Steiermark
  Klaus

[Klaus Mock]

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

[Lude]

Hi,

• 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".

die Praefixe sind doch OK, weil:

• der Programmierer mehr Information hat
• alle Namen DB-weit eindeutig sind (vorteilhaft bei Datenzugriff)

Fremdschluesseldatenfelder kann man auch recht gut mit "<SUFFIX>_<SUFFIX_DER_TABELLE_AUF_DIE_VERWIESEN_WIRD>_<NAME_DES_DATENFELDS_AUF_DAS_VERWIESEN_WIRD>" benennen. Also z.B. 'Ws_Kund_ID'.

Ich bin aber nicht sicher, ob ich die Aussage "Einmal..." richtig verstanden habe.

Gruss,
Lude

[Philipp Hasenfratz]

Halihallo Lude

die Praefixe sind doch OK, weil:

• der Programmierer mehr Information hat

Ich halte das Prefix der referenzierten Tabelle für einen Mehrwert an Information, da
das Prefix der Spalte wo das Attribut steht implizit bekannt ist. Durch das Prefix der
referenzierten Tabelle (FOREIGN KEY-Symbol) kann man die Relationen genau(er) erkennen.

• alle Namen DB-weit eindeutig sind (vorteilhaft bei Datenzugriff)

Ja, aber da die Tabellen normalerweise immer über PRIMARY KEY/FOREIGN KEY gejoined
werden, sind eh beide Spalten gleich; deine Argumentation ist zwar richtig, halte
ich aber in den meisten Fällen für unnötig; vielmehr zählt für mich folgender Vorteil:
...

Fremdschluesseldatenfelder kann man auch recht gut mit "<SUFFIX>_<SUFFIX_DER_TABELLE_AUF_DIE_VERWIESEN_WIRD>_<NAME_DES_DATENFELDS_AUF_DAS_VERWIESEN_WIRD>" benennen. Also z.B. 'Ws_Kund_ID'.

Wäre denkbar, aber...

wenn man Klaus'es Vorschlag folgt wäre es möglich einen NATURAL JOIN auf zwei Tabellen
anzuwenden, ansonsten bräuchte man einen THETA JOIN (da Tippt man dann beim Query einfach
ein paar Bytes mehr ein; Condition: ON (WS.Ws_Kund_ID=K.Kund_ID))... Sonst wäre

WS NATURAL JOIN K

statt

WS JOIN K ON (WS.Ws_Kund_ID=K.Kund_ID)

möglich...

Viele Grüsse

Philipp

[Lude]

Hi,

wenn ich Dich jetzt richtig verstanden habe, hast Du gerade einer bestimmten "Join-Technik" das Wort geredet, die ich leider nicht kenne. (MySQL, wie ich annehmen darf?)

Anmerkungen:
1.) Den NATURAL JOIN (beim Schrieben muss ich immer noch etwas lachen ;-) ueber identische Namen(!) von FK und PK zu implementieren, finde ich schon etwas krass. Aber da habe ich Dich wohl nicht verstanden?
2.) Den NATURAL JOIN wuerde ich als natuerlich empfinden, wenn der JOIN aus der Beziehung der Tabellen entwickelt worden waere.
3.) Entwickler schaetzen eine konsistente Namensvergabe, weil ansonsten die "Erarbeitung" der Semantik ein Prozess werden kann.

Gruss,
Lude

[Philipp Hasenfratz]

Halihallo Lude

wenn ich Dich jetzt richtig verstanden habe, hast Du gerade einer bestimmten "Join-Technik" das Wort geredet, die ich leider nicht kenne. (MySQL, wie ich annehmen darf?)

Bitte? - Meinst du EQUI oder THETA JOIN? - Das sind einfach gewisse JOIN "Kategorien".
Meinst du das?

1.) Den NATURAL JOIN (beim Schrieben muss ich immer noch etwas lachen ;-) ueber identische Namen(!) von FK und PK zu implementieren, finde ich schon etwas krass. Aber da habe ich Dich wohl nicht verstanden?

Ich glaube du hast richtig verstanden. Aber warum krass? - Es ist einfach eine andere
Nomenklatur, die IMHO mindestens genauso eine Daseinsberechtigung hat wie andere...
Oder verstehe ich dich jetzt nicht?

3.) Entwickler schaetzen eine konsistente Namensvergabe, weil ansonsten die "Erarbeitung" der Semantik ein Prozess werden kann.

Ja, das stimmt. Die Namengebung sollte eigentlich keinen Einfluss auf die verwendete
Abfrage haben. Aber wenn ich diese Notation bevorzuge, warum auf den NATURAL JOIN
verzichten?
Hast du das so verstanden?

Viele Grüsse

Philipp

[Lude]

Hi,

Hast du das so verstanden?

eigentlich darf ich ja nicht antworten. Also nur ein ganz kurzes 'ja'.

Viele Gruesse aus Baden-Baden,
Lude

[Philipp Hasenfratz]

Halihallo Lude

Hast du das so verstanden?
eigentlich darf ich ja nicht antworten. Also nur ein ganz kurzes 'ja'.

So, also jetzt musses aber mal raus: *g*
Äm, warum darfst du nicht darauf antworten? - Hängt es an mir, hängt es an dir, hängt
es an deiner Umgebung? - Du scheinst mir irgendwie, hmmm, wie soll ich sagen, zurück-
haltend zu sein. Hm?

Viele Gruesse aus Baden-Baden,

und dieselben zurück aus (jetzt noch nahe Konstanz). Aber ab heute abend, 22:30 bin
ich gradewegs nach Sao Paulo unterwegs, werde euch also für ganze 5 Tag alleine lassen ;)
Tschüss, tschüss also, bis in fünf Tage to [e-mail]...

Viele Grüsse

Philipp

[Christoph]

Hi Klaus,

• 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

Hm, ok.

• 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

das habe ich jetzt nicht ganz verstanden :/

• 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.

Ja weil OS ist ja Software, da hast du auch Recht. Also eine Auslagerung auf 2 Tabellen wäre wirklich sinnvoll in dem Moment. Ok.

• Für die Hardwareausstattung könnte es durchaus auch sinnvoll sein, daß man diese über zusätzlcihe Tabellen verwaltet.

Versteh ich jetzt auch nicht.

• Was bedeutet Ws_WID bzw. Ser_SID?

Die Server usw. haben alle eine eigene Nummer die sich aus der Kundennummer und dem Datum usw. zusammenstellt. Deswegen Ws_WID usw.

• 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.

Ok, kannte ich ehrlich gesagt bis vor kurzem selber noch nicht. also das mit CASADE DELETE. Kannte nur Not Null und UNIQUE usw.

• 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".

Hm dachte es wäre so übersichtlicher. Aber ok.

Vielen Dank!

Gruß Christoph

[Klaus Mock]

Hallo,

• 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

das habe ich jetzt nicht ganz verstanden :/

Du hast in der Tabelle Netzwerk Felder für DNS, Gateway, POP3 bzw. SMTP. Ich gehe jetzt davon aus, daß es sich dabei um IP-Adressen oder Domain-Namen handelt. Eigentlich werden diese Dienste aber ja von physikalischen Geräten abgedeckt, die dann auch in der Datenbank erfasst sein müssten. Dort wiederum ist für den Rechner auch die Adresse eingetragen [....] aber wenn ich so nachdenke wäre es auch nicht so schlau, wenn man anstelle der Adresse die ID des Gerätes eintragen würde, da ja, wie ich anderweitig bemerkt habe, es durchaus Rechner gibt, die mehrere IP-Adressen besitzen. Naja, ein Datenbank-Design ist ja auch nichts, was man so nebenbei machen sollte. also vergiss den Absatz.

ABer was ich auch noch meinte, ist, daß es durchaus vorkommt, daß, gerade in größeren Firmen, die Mails nicht nur über einen zentralen Mailserver verwaltet werden, sondern auch durchaus auf mehrere Rechner aufgeteilt wird. Und da wird dann meist einem Benutzer ein spezieller Mailserver zugeordnet.   Und das wiederum ist durch Dein Modell gar nicht abgedeckt, da Du ja davon ausgehst, daß in einem Netzwerk nur genau ein POP3-Server existieren kann.

• Für die Hardwareausstattung könnte es durchaus auch sinnvoll sein, daß man diese über zusätzlcihe Tabellen verwaltet.

Versteh ich jetzt auch nicht.

Du hast in den Tabellen für die Workstations und Server Felder für CPU, Motherboard, Grafikkarte CD-Rom usw. Eigentlich sind das Teile, die, ähnlich wie bei der Software, in einem Gerät eingebaut sein können aber nicht zwangsläufig eingebaut sein müssen. Deshalb könntest Du analog zur Software auch die Hardware über zusätzliche Tabellen verwalten. Gemeinsam mit einem Hardware-Typ könnten dann auch Auswertungen bezüglich spezieller Hardwareausstattungen gefahren werden.

BTW: Ich habe mir beim Datenbankdesign bisher immer wieder auch die Frage "Was kann ich den alles von der Datenbank wissen wollen?" gestellt. Das kann oft wirklich gut helfen, sinnvolle Kategorien und Tabellenstrukturen zu finden. Speziell wenn man versucht ist, etwas so mal eben in einem Textfeld abzulegen, sollte man stutzig werden. All die Eigenschaften, nach denen ich eventuell suchen will, sollten möglichst klar abfragbar bleiben.

Eine der möglichen Fragen an so eine Datenbank könnte z.B. lauten:  "Ich muß ein Bugfix bei der Software XY Version 17.3 einspielen. Welche Rechner sind den nun betroffen, und wer muss den nun verständigt werden?"

Da hätte ich jetzt schon z.B. den Bedarf eines Rechnerverantwortlichen in Deiner Datenstruktur drin, wobei es auch ganz anders sein kann.

Ok, kannte ich ehrlich gesagt bis vor kurzem selber noch nicht. also das mit CASADE DELETE. Kannte nur Not Null und UNIQUE usw.

Dann hat Dien Lehrer anscheinend gepatzt;-)

Grüße
  Klaus