[DB] N-M relatie van tabel met zichzelf

[Kwistnix]

Ik heb een probleem, waar ik geen geschikte oplossing voor kan vinden.
Stel, ik heb een tabel waar verschillende soorten hardware in opgenomen zijn.
Een hardware item kan een relatie hebben met verschillende andere hardware items. Een standaard N-M relatie tussen twee verschillende tabellen los je op met een koppeltabel. Dat kan in dit geval ook wel, MAAR dan heb je een probleem met redundantie, immers de relatie item1 - item2 is dezelfde als de relatie item2 - item1.
De id combinaties opzich zijn echter wel uniek, waardoor je een zelfde relatie twee keer kan vastlegeen. Dat is dus niet de bedoeling.

Een andere manier zou zijn om een exacte kloon van de tabel hardware te maken en die een andere naam te geven. Op die manier kan je ook met een koppeltabel werken en heb je het bovenstaande probleem niet. Toch is deze situatie verre van ideaal, omdat je met een gigantische berg redundante gegevens zit.

Hoe kan ik dit probleem het beste/netste oplossen?

[Verwijderd]

Je hoeft geen extra tabel te maken, alleen je (standaard) koppel tabel. In je SQL-statement gebruik je dan twee keer dezelfde tabel door middel van een tabel alias.

code:

Select
  Artikel_A.id,
  Artikel_A.naam,
  Artikel_B.id,
  Artikel_B.naam
from
  Artikel Artikel_A,
  Artikel Artikel_B,
  Koppel
where
  Koppel.ID_A = Artikel_A.id and
  Koppel.ID_B = Artikel_B.id

[Kwistnix]

Verwijderd schreef op 29 mei 2004 @ 15:16:
Je hoeft geen extra tabel te maken, alleen je (standaard) koppel tabel. In je SQL-statement gebruik je dan twee keer dezelfde tabel door middel van een tabel alias.

code:

Select
  Artikel_A.id,
  Artikel_A.naam,
  Artikel_B.id,
  Artikel_B.naam
from
  Artikel Artikel_A,
  Artikel Artikel_B,
  Koppel
where
  Koppel.ID_A = Artikel_A.id and
  Koppel.ID_B = Artikel_B.id

Ik wil informatie over de relaties kunnen vastleggen in de database.

[jochemd]

FallenAngel666 schreef op 29 mei 2004 @ 13:38:
Ik heb een probleem, waar ik geen geschikte oplossing voor kan vinden.
Stel, ik heb een tabel waar verschillende soorten hardware in opgenomen zijn.
Een hardware item kan een relatie hebben met verschillende andere hardware items. Een standaard N-M relatie tussen twee verschillende tabellen los je op met een koppeltabel. Dat kan in dit geval ook wel, MAAR dan heb je een probleem met redundantie, immers de relatie item1 - item2 is dezelfde als de relatie item2 - item1.
De id combinaties opzich zijn echter wel uniek, waardoor je een zelfde relatie twee keer kan vastlegeen. Dat is dus niet de bedoeling.

CHECK constraint over de koppeltabel leggen: item1 <= item2

Een andere manier zou zijn om een exacte kloon van de tabel hardware te maken en die een andere naam te geven. Op die manier kan je ook met een koppeltabel werken en heb je het bovenstaande probleem niet.

Ik zou hier toch maar even goed over nadenken, want je hebt het zelfde probleem dus wel.

[Kwistnix]

jochemd schreef op 29 mei 2004 @ 15:48:

[...]
Ik zou hier toch maar even goed over nadenken, want je hebt het zelfde probleem dus wel.

Ja, inderdaad. Nouja, dat was sowieso toch geen oplossing

[.oisyn]

Verwijderd schreef op 29 mei 2004 @ 15:16:
Je hoeft geen extra tabel te maken, alleen je (standaard) koppel tabel. In je SQL-statement gebruik je dan twee keer dezelfde tabel door middel van een tabel alias.

Zijn probleem is niet zozeer de koppeltabel, maar juist dat er dubbele relaties mogelijk zijn. Als je een tabel1 en een tabel2 aan elkaar koppelt, dan heb je dus een koppeltabel met foreign key naar tabel1 en een foreign key naar tabel2. De key van tabel1 gaat altijd in de eerste kolom, en de key van tabel2 in de 2e.

Als je echter relaties hebt tussen rijen in dezelfde tabel, dan heb je dus een koppeltabel met 2 foreign keys naar de tabel. Een relatie tussen rijen met ID's 1 en 2 kun je dus op 2 manieren opslaan:

code:

a_id   b_id
1      2
2      1

FallenAngel666: Als je gewoon ervoor zorgt dat de foreign key in de eerste kolom altijd kleiner of gelijk is aan de foreign key in de 2e kolom heb je het probleem niet. Wat jochemd zegt dus

[Kwistnix]

.oisyn schreef op 29 mei 2004 @ 16:00:
[...]

FallenAngel666: Als je gewoon ervoor zorgt dat de foreign key in de eerste kolom altijd kleiner of gelijk is aan de foreign key in de 2e kolom heb je het probleem niet. Wat jochemd zegt dus

Ok. Er is dus geen andere manier dan het werken met constraints?
Niet dat ik dat een probleem vind hoor

[EfBe]

FallenAngel666 schreef op 29 mei 2004 @ 13:38:
Ik heb een probleem, waar ik geen geschikte oplossing voor kan vinden.
Stel, ik heb een tabel waar verschillende soorten hardware in opgenomen zijn.
Een hardware item kan een relatie hebben met verschillende andere hardware items. Een standaard N-M relatie tussen twee verschillende tabellen los je op met een koppeltabel. Dat kan in dit geval ook wel, MAAR dan heb je een probleem met redundantie, immers de relatie item1 - item2 is dezelfde als de relatie item2 - item1.

Nee. Een m:n relatie is een vereenvoudiging van een 1:n en een m:1 relatie. item1 - item2 is dus niet gelijk aan item2-item1 (wanneer beide m:n relaties zijn).

Een relatie is ook altijd enkelvoudig. Als je de relatie item1 - item2 neemt, dan praat je alleen over die relatie, niet over de opposite relatie item2 - item1, want die is anders. Heb je dus de relatie item1 - item2, dan is item1 de start van de relatie en heb je mbt die start van die relatie geen redundantie, want er zijn geen 2 item1 - item2 relaties over exact dezelfde velden.

De id combinaties opzich zijn echter wel uniek, waardoor je een zelfde relatie twee keer kan vastlegeen. Dat is dus niet de bedoeling.

Dan is je pk keuze fout.

Een andere manier zou zijn om een exacte kloon van de tabel hardware te maken en die een andere naam te geven. Op die manier kan je ook met een koppeltabel werken en heb je het bovenstaande probleem niet. Toch is deze situatie verre van ideaal, omdat je met een gigantische berg redundante gegevens zit.

Er is geen oplossing mogelijk zolang je niet de semantische waarde omschrijft van de 1:n relatie EN de m:1 relatie die BEIDE aanwezig zijn!. Is 1 van beide niet aanwezig dan heb je geen m:n relatie.

Ik wil informatie over de relaties kunnen vastleggen in de database.

Mja, dan praat je dus over een objectified relation en die hebben ALTIJD een aparte tabel. (Voorbeeld objectfied relation: OrderDetail die als koppeltabel optreed tussen Order - Product.)

[ Voor 8% gewijzigd door EfBe op 29-05-2004 17:37 ]