E/R Modell M-M Beziehungen?

[harodos]

Hallo,

mir wurde irgendwann eingetrichtert, dass m zu m Beziehungen vermieden werden sollen. Sollte so eine Beziehung auftauchen, soll man diese möglichst durch eine weitere Tabelle aushebeln.

Mir stellt sich die Frage: warum sollen solche many to many Beziehungen vermieden werden?

Bin mir sicher hier kennt Jemand die Antwort.

Beste Grüße

Haro

[lupo49]

Meines Wissens nach kannst du keine m:n-Beziehung in einer relationalen Datenbank ohne eine Zwischentabelle technisch umsetzen (dadurch entstehen dann zwei 1:n-Beziehungen). In der Modellierungsphase kannst du die Zwischentabelle der Einfachheit halber weglassen.

[harodos]

Danke für deine Antwort.

Technisch gar nicht erst umsetzbar, ok.

Mir fehlt jetzt nur noch die Begründung dazu

Grüßle

Haro

[kingofbrain]

Weil Du irgendwo einen Ort brauchst, an dem Du mehrere X mit mehreren Y verknüpfen kannst. Du könntest jetzt - analog zur 1:n-Relation - in einem Attribut von X eine kommaseparierte Liste der Schlüssel zu Y halten (oder umgekehrt), aber das ist nicht normalisiert. Dann bleibt nur noch eine eigene Tabelle, die nur die PKs von X und Y als FKs enthält.

Schöne Grüße,

Peter

[Xzell]

Technisch ist das ganze natürlich umsetzbar. Es geht vielmehr um die Übersichtlichkeit und Datenintegrität.

Nehmen wir mal die Tabellen "Wohnung" und "Mieter", welche n:m verknüpft sind. Die Wohungstabelle müsste also für jede Wohnung einen Datensatz beherbergen. Da eine Wohnung aber mehrere Mieter haben kann, kommt es vor, dass eine Wohnung in der Tabelle mehrmals auftaucht: nämlich für jeden Mieter einmal:

ID, Straße, Nebenkosten, Mieter

1, blastr., 200, Tom

2, moep, 335, Jeff

3, moep, 335, Jim

Sollten sich die Nebenkosten der Wohnung moep jetzt allerdings ändern, muss ich in mehreren moeps-Datensätzen eine Anpassung vornehmen. Das kann zu Unstimmigkeiten führen.

Außerdem widerspricht dieses Beispiel der 2ten (?) Normalform, da Jeff ja nichts mit den Nebenkosten zu tun hat, bzw nicht abhängig von der Straße ist. Bei einer n:m Beziehung würde natürlich statt des Namens die Mieter-ID stehen - läuft aber aufs selbe hinaus.

[harodos]

Ich danke Euch beiden!

Thema ist somit durch

Gruß

haro

[kylt]

Man sollte jedoch auch erwähnen, dass es Gründe geben kann, für eine n zu m Beziehung.

Beispiel:

Tabelle Autos

Id, Name

1, Golf

2, Passat

Tabelle Autoteile

Id, Teilnahme, AutoId

1, Auspuff, 1

2, Motor, 1

3, Auspuff, 2

4, Motor, 2

Jetzt hast du also für jedes Auto für jedes Teil einen Eintrag in der Tabelle Autoteile und dabei kann es sein, dass es das exakt gleiche Teil ist, nur eben technisch Doppelt erfasst wurde.

Besser wäre also

Tabelle Autos

Id, Name

1, Golf

2, Passat

Tabelle Teile

Id Teilnahme

1, Auspuff A

2, Motor

3, Auspuff B

Tabelle Autoteile

TeilId, AutoId

1, 1

2, 1

1, 2

3, 2

[streffin]

ich würd aber IMMER auch in der Zuordnungstabelle eine Identity Spalte mit reinnehmen. Also deinen Primary Key.

Weil, sagen mer du hast aus welchem Bug auch immer, eine nicht gewollte Dublette in der Zuordnung,

Fabrikat_id	Teil_id

1		1

1		2

1		3

1		1

1		1

1		1

1		1

in der Art. Wie löschst du jetzt die Dublette ? Das einzige was du hier machen kannst ist

DELETE

FROM tabelle 

WHERE Fabrikat_id = 1

  AND Teil_id = 1

Womit du alle einträge löschst. Also auch den den du eventuell behalten willst. Wenn du noch ne Identity mit reinnimmst, also

ID	Fabrikat_id	Teil_id

1	1		1

2	1		2

3	1		3

4	1		1

5	1		1

6	1		1

7	1		1

kannst du geziehlt die dubletten löschen.

Das wär zwar nicht direkt nen einfacher 3 Zeiler in sql, aber immer noch recht einfach (schreibs au gern runter auf Anfrage).

Gruß

Sven