[MySQL] - Idee für Datenstruktur in 3. Normalform gesucht

[anddie]

Hallo zusammen,

ich habe ein kleineres Problem, eine Datenstruktur brav in die 3. Normalform zu bringen.
Ich habe Objekte, Gruppen von Objekten und Beziehungenstypen zwischen Gruppen und Objekten.
Eine Gruppe besteht immer aus min. 2 Objekten. Ein Objekt kann aber in keiner Gruppe, in einer Gruppe oder in mehreren Gruppen sein.
Um dies darzustellen, hab ich erstmal 3 Tabellen:
groups (groupid, groupname)
1, GruppeA
2, GruppeB
3, GruppeC

objects (objectid, objectname)
1, Objekt1
2, Objekt2
...
9, Objekt9

groupmembers (groupid, objectid)
1, 1
1, 2
2, 1
2, 3
2, 5
2, 8
3, 7
3, 8

Das Objekt1 ist also in GruppeA und GruppeB, Objekt2 nur in GruppeA und die Objekte 6 und 9 in gar keiner.

Jetzt muss ich die ganzen Beziehungen noch in eine Tabelle bekommen. Beziehungen bestehen aus "von wo", "wohin" und "Beziehungstyp". Das Problem ist jetzt aber, dass ich bei "von wo" und "wohin" sowohl Gruppen, als auch Objekte drin stehen habe. Mir fehlt also irgendwie ein Kriterium, um zu erkennen, ob es sich bei der ID um die Gruppe oder das Objekt handelt.

Und jetzt brauch ich von euch mal eine Idee.

anddie

 

[Paladin]

Mal ganz kurz für mich zur Klärung, ob ich das richtig verstanden habe:
Du willst wissen, welches Objekt zu welcher Gruppe in Beziehung steht?

 

[ZeroCCC]

von wo, wohin? hä? kannst du mal erklären was du genau vor hast...

 

[anddie]

Mal ganz kurz für mich zur Klärung, ob ich das richtig verstanden habe:
Du willst wissen, welches Objekt zu welcher Gruppe in Beziehung steht?

Richtiger wäre: Welche Beziehungstypen gibt es zwischen welchen Objekten/Gruppen zu welchen Objekten/Gruppen.

von wo, wohin? hä? kannst du mal erklären was du genau vor hast...

Was der Beziehungtyp genau ist, ist für das Problem erstmal irrelevant (sind spezifische Strings). Wichtig ist nur, dass es die Beziehungen in 2 Richtungen geben kann. Es ist also wichtig, Start und Ziel zu definieren.
Beispiel:
Von Gruppe1 zu Gruppe2 gibt es BeziehungstypA
Von Gruppe2 zu Gruppe1 gibt es BeziehungstypB
Von Gruppe2 zu Objekt20 gibt es BeziehungstypC
Von Objekt18 zu Objekt12 gibt es BeziehungstypC

Zuerst hatte ich ja die Idee, für jedes Objekt ohne Gruppe eine gleichnamige Dummy-Gruppe anzulegen und meine Beziehungstabelle nur noch mit Gruppenids anzulegen. Da hätte ich nur jede Menge überflüssige Daten.
Die andere Idee wäre, in der Beziehungstabelle 2 extra Spalten anzulegen, wo vermerkt ist, ob es sich um ne Gruppe oder ein Objekt handelt. Also in etwa

sourceid	sourcetype	destid	desttype	relation
    1		Gruppe	 	 5	   Gruppe	  TypA
    1 	   Gruppe	 	 5	   Objekt	  TypB
    1		Objekt	  	2	   Gruppe	  TypA
    5		Gruppe		 12	   Objekt	  TypF
...

Da bin ich mir nur gerade arg unsicher, ob das wirklich der 3. Normalform entspricht.

anddie

 

[tleilax]

Muss die bisherige Modellierung unbedingt so bestehen bleiben? Ansonsten könntest Du Gruppen auch als Objekte definieren - mit dem Unterschied, dass diese Objekte als Gruppen erkannt werden, sobald sie einen entsprechenden Eintrag in der Verknüpfungstabelle haben.

Sprich: Ein Objekt wird zu einer Gruppe, sobald es mit anderen Objekten als Inhalt gefüllt wird.

 

[ZeroCCC]

hrm ohne weitere information würde ichs auch in die auflösung der n:m beziehung reinpacken und genauso wie dus jetzt vorgeschlagen hast. ob dir das programmier technisch vorteile bringt musst du wissen... ich weiß das die normalform nicht immer die lösung jedes problems ist.

 

[anddie]

Muss die bisherige Modellierung unbedingt so bestehen bleiben? Ansonsten könntest Du Gruppen auch als Objekte definieren - mit dem Unterschied, dass diese Objekte als Gruppen erkannt werden, sobald sie einen entsprechenden Eintrag in der Verknüpfungstabelle haben.

Dann könnte es mir aber passieren, dass ich in der Verknüpfungstabelle der GruppeD die GruppeH als Objekte zuweise und das Ganze noch umgekehrt und schon habe ich lustige Kreisbeziehungen.

hrm ohne weitere information würde ichs auch in die auflösung der n:m beziehung reinpacken und genauso wie dus jetzt vorgeschlagen hast.

Ne andere Idee war noch, für source und destination jeweils 2 Spalten (Gruppe und Objekte) zu haben und eine immer mit NULL zu belassen.
Das fand ich programmiertechnisch aber noch bekloppter.

ob dir das programmier technisch vorteile bringt musst du wissen... ich weiß das die normalform nicht immer die lösung jedes problems ist.

Ich weiß, vor allem, wenn mal irgendwas gelöscht wird, hab ich jede Menge Tabellen durchzugehen. Kann sich schon pervers entwickeln. Aber durch die Normalform kann man auch sehr einfach die Datenstrukturen und -komplexität erweitern.

anddie