Veröffentlicht 14. Juni 201015 j 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
14. Juni 201015 j 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.
14. Juni 201015 j Danke für deine Antwort. Technisch gar nicht erst umsetzbar, ok. Mir fehlt jetzt nur noch die Begründung dazu Grüßle Haro
15. Juni 201015 j 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
15. Juni 201015 j 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.
16. Juni 201015 j 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
25. Juni 201015 j 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
Erstelle ein Konto oder melde dich an, um einen Kommentar zu schreiben.