MySQL ER-Diagramm

[Mig]

Hi,

ich versuche mich gerade an einem ER-Diagramm und bastel es in Access 2007 (nur aus gründen der Ansicht).
Ich versuche mein Problem mal zu schildern (Inhalt und Thema fiktiv):

Tabellen:
T_Immos
T_ObjektArt

(zu betrachten im angehangenden Bild (ER-1.png) )

Wie man in der Tabelle "T_Immos" sieht, sind dort nur rudimentäre Eigenschaften enthalten, die jede Art von Immobilie betreffen.

Mein Problem liegt nun darin, dass ich zu jeder Immobilien/Objektart verschiedene Eigenschaft brauch.

Habe ich nun einen "Laden", brauche ich die Eigenschaft "Länge Fensterfront" z.B. ...
Habe ich eine Mehrfamilienhaus, brauche ich z.B. die Eigenschaft "Zugang zum Garten möglich?" ...


Diese verschiedenen Eigenschaften zu einer Immobilie resultieren also aus der ausgewählten ObjektArt.


Mein Problem ist nun der Aufbau/Beziehung des ER-Diagramms zu meinem Problem.

Mein Ansatz ist, eine Tabelle in folgder Form zu erstellen:

T_Eigenschaften
--------------------------------------
ObejktArt_ID | Eigenschaften
--------------------------------------

T_Immos -> auffüllen mit alles Eigenschaften (standardwert = 0)


Bei der späteren Eingabe müssten sich aber die Eingabefelder anhand der ObjektArt ändern und in die entsprechenden Felder der Tabelle T_Immos einschreiben.

Und da harperts bei mir mit dem Verständniss.


Ich hab da glaube grad auch zu lange drüber nachgedacht, komme immer aufs selbe.

 

[theHacker]

Bei der späteren Eingabe müssten sich aber die Eingabefelder anhand der ObjektArt ändern und in die entsprechenden Felder der Tabelle T_Immos einschreiben.

Das hat aber nix mit ER zu tun.

Bei einem ordentlichen Mapping hast du pro Typ eine Entity (sehr wahrscheinlich mit Vererbung). Bei deinem Ansatz hat jede Immobilie eben ein gewisse Anzahl von Eigenschaften. Du kannst aber mit einem RDMS nicht ein "Wenn Typ = 'A', existiere Feld 'X', sonst existiere das Feld 'X' nicht" abbilden.

@Access: Nimm Dia, wenns dir nur um das Zeichnen der ER-Diagramme geht Bei Linux isses meistens schon dabei. Unter Windows kannst du es aber auch betreiben.

 

[tobomator]

wenn er über die Menge der Eigenschaften X die Permutationen {0,1} in Beziehung setzt, was ne Menge Einträge in der Tabelle bedeuten würde, könnte er es machen. Der Overhead der dabei entsteht, beinhaltet sicher Fälle die nie auftreten werden.

Aber sag niemals nie oder unmöglich !

 

[Mig]

das bedeutet, ich soll zB die tabelle T_Immos mit allen möglichen Eigenschaften befüllen, standardwert "0".

die auswahl, was befüllt wird, geschieht im frontend ?

 

[tobomator]

Nun ich versuchs mal bildlich

--------------------------------------
ObejktArt_ID | Eigenschaften_ID's
--------------------------------------
1 | 1|0|0|1|0....
...


--------------------------------------
Eigenschaften_ID | Eigenschaft
--------------------------------------
1 | Tor
2 | Einfahrt
3 | Hintertür
4 | Hof
....

Du musst nur eine Sache bedenken, das oben zerlegst in ein Array ( ID's mit | getrennt )
und selektierst anhand des Array Indizes den Namen der Eigenschaft

So hat halt ein Grundstück mit ObjektArt_ID immer ein Tor und ein Hof standardmäßig mit der ID 1.
So kannst Du Dir halt ObjektArt_ID's generieren, die alles mögliche enthalten können.

Wenn Du hierbei effizient sein möchtest, dann entwickle einen Algorithmus der die 0 in den
Eigenschaften_ID's wegnimmt und den Array Index der 1 davor oder danach hinschreibt.
So könntest Du eben für das BSP. oben folgendes Array zum Schluss haben:

ObjecktArt_ID[1] = { Array->{ [1] = "Hof", [4] = "Tor" }

Dazu müsstest Du nur noch entsprechend Templates basteln, die dann an bestimmten Stellen
eine $variable stehen haben, die dann mit dem Arrayeintrag ersetzt wird und schon hast du
einen vollständigen Text nur für diese Immobilie.

Hoffe Du konntest folgen.

Wenn Du jede Permutation einzeln reinschreibst, wird es zu viel, dazu die Unterteilung, wo eine 1:1 Beziehung für jedes "Merkmal" der Immobilie steht und dann koppelst Du Sie einfach miteinander.

Kommt einem Wenn Dann vll nahe aber nur vll, da ja selektiv gearbeitet wird....

Also der Ansatz ist ja noch zu vereinfachen:
Schreib einfach nur die Eigenschaften_ID rein quasi:
--------------------------------------
ObejktArt_ID | Eigenschaften_ID's
--------------------------------------
1 | 1|4|...
...

so kommt man beim lesen auch noch auf einfacheres
und so kann man getrost neue Eigenschaften (Panormafenster, Flachdach, ... ) einfach einfügen, ohne andere Datensätze zu beinträchtigen. Es wird halt einfach ein neuer Eintrag in ObjektArt_ID eingefügt, eben immer nur mit dem was diese Immobilie eben alles hat.

 

[theHacker]

Du musst nur eine Sache bedenken, das oben zerlegst in ein Array ( ID's mit | getrennt )
[...]
--------------------------------------
ObejktArt_ID | Eigenschaften_ID's
--------------------------------------
1 | 1|4|...

Für gewöhnlich klink ich mich ja aus Threads aus, in denen du gepostet hast, aber hier muss ich nun doch noch eine Warnung posten, dass andere, v.a. Unwissende, deinem Beitrag nicht zu viel Bedeutung zumessen.

Der gepostete Lösungsvorschlag von tobomator ist der gröbste Verstoß bereits gegen die 1NF und somit weder empfehlenswert, noch überhaupt mit einem ER-Diagramm abbildbar.

 

[tobomator]

Gut, dann wird es gar nicht gehen.
Da immer eine Datenredundanz in der Datenbank an irgend einer Stelle existiert.
Schon allein weil ein Objekt gleiche Eigenschaften wie ein anderes besitzt.

Tja Pustekuchen und zum Teufel mit den ganzen NF.
schau mal in der Realität nach, welche Datenbanken denn mindestens die 3NF Prüfung bestehen, geschweigeden noch höhere !

...

 

[tleilax]

Tja Pustekuchen und zum Teufel mit den ganzen NF.

Welche qualifizierte Aussage.

Die 1. NF anzuwenden, ist nun wirklich ein Klacks. Statt alles token-separiert in einer Spalte zu speichern, speicherst Du es halt in einer zusätzlichen Tabelle. Und mit einem Mal sind Updates der Eigenschaften oder die Suche danach problemlos möglich. Solche Werte nicht atomar abzuspeichern, spricht in 99% aller Fälle von einem schlechten Softwaredesign.

 

[Darklord]

[...]schau mal in der Realität nach, welche Datenbanken denn mindestens die 3NF Prüfung bestehen, geschweigeden noch höhere !
...

Hier hast du ganz offensichtlich nicht denn Sinn verstanden der in der Normalisierung steckt. Man Normalisiert soweit wie es den Anforderungen gerrecht wird. Dabei kann es durchaus von Vorteil sein eben nicht komplett zu normalisieren. Als Beispiel wäre hier das Speichern von Adressen zu nennen (PLZ, Ort, Name, Strasse, ...) wo es gerade Sinn macht nicht alles aufzubröseln.

Also siehst du hoffentlich ein das es nicht erstrebenswert ist die höchste Normalform zu haben. Sondern das von den Anforderungen abhängig zu machen.

Wikipedia hat sogar einen guten Eintrag zu Normalisierung der eigentlich auch genau auf die Probleme hinweist, die bei Missachtung der Normalisierung auftreten.