[datamodel] generaliseren relatie(s)

Pagina: 1
Acties:
  • 168 views sinds 30-01-2008
  • Reageer

  • THIJZEL
  • Registratie: Januari 2001
  • Niet online
Hallo,

Ik zit met een vraagstuk mbt tot de generalisatie van relaties tussen entiteiten. Ik heb een datamodel gemaakt met(in het kort) een member, organisation, project en department enteit.
Nu kan een member lid zijn van een organisatie, project en department de drie relaties tussen member en organisatie, project en department zijn tus allen veel op veel relaties wat effectief inhoud dat er een tussentabel komt. Deze drie tussentabellen zien er vrijwel gelijk uit, alleen is één key steeds verschillend ( project_id, organisation_id of department_id).
Nu vraag ik me af of het goed(netjes) is om deze relatie te generaliseren, wat er op neer komt dat deze drie tussentabellen "mergen" naar één tabel met een key die bestaat uit member_id, container_ID, en container_type.
Container_id en container_type staan dan samen voor de relatie met een project, organisatie of department tabel.
Voor het overzicht even de twee (verkorte)datamodellen:


Afbeeldingslocatie: http://thijsdejong.homelinux.com/model_een.jpg
De oude, originele versie:
Afbeeldingslocatie: http://thijsdejong.homelinux.com/model_twee.jpg


Als ik dit doortrek naar mijn klassediagram dan kan het gehele membermanagement in de superklasse(een MemberContainer) van Project, Organisatie en Department regelen.
IMHOis het zo erg flexibel maar misschien vanuit een database perspectief niet helemaal netjes, wat denken jullie?

  • whoami
  • Registratie: December 2000
  • Laatst online: 23:33
Wat is het voordeel om deze tussen-tabel te mergen ?

Als je dat doet, ga je dan niet meer OUTER joins nodig hebben, dan als je het niet doet ? (Dat hangt een beetje van je requirements af)

https://fgheysels.github.io/


Verwijderd

Volgens mij gaat dit ook tot smerige queries leiden wanneer je van een member zowel zijn project als zijn departement wil hebben. Je moet dan de tabel memberContainer dubbel definieren in je FROM.

  • THIJZEL
  • Registratie: Januari 2001
  • Niet online
Door dit te mergen kan ik het gehele member management van een Department, Organisation, Project of een eventuele andere toekomstige "groep"met membermanagement in één superklasse samenvatten. Deze klasse hoeft zich niet druk te maken over het feit of hij een relatie met een project, department of organisation maakt.
Ik heb overigens ff een nieuw model waarbij ik ff een generalisatie van project, organisation en department heb gemaakt
Afbeeldingslocatie: http://thijsdejong.homelinux.com/model_drie.jpg

edit:
Een member hoeft overigens niet altijd lid te zijn van een Organisation en/of department.

[ Voor 11% gewijzigd door THIJZEL op 03-05-2006 11:33 ]


  • whoami
  • Registratie: December 2000
  • Laatst online: 23:33
THIJZEL schreef op woensdag 03 mei 2006 @ 11:31:
Door dit te mergen kan ik het gehele member management van een Department, Organisation, Project of een eventuele andere toekomstige "groep"met membermanagement in één superklasse samenvatten.
En dat kan je niet misschien als je dit niet merged ? Je class hierarchy hoeft geen 1 op 1 relatie te zijn met je DB.
Ik bedoel maar, je kan een mapping maken om dit ook te bewerkstelligen, ook al zijn die tables niet gemerged (of je kan een O/R mapper gebruiken).
Er zijn verschillende manieren om inheritance in een DB voor te stellen:
- Table per concrete class
- Table per subtype
- Table per class hierarchy

https://fgheysels.github.io/


  • THIJZEL
  • Registratie: Januari 2001
  • Niet online
Wat moet ik me precies voorstellen bij een O/R (object/relatie?) mapper?

  • whoami
  • Registratie: December 2000
  • Laatst online: 23:33
THIJZEL schreef op woensdag 03 mei 2006 @ 11:42:
Wat moet ik me precies voorstellen bij een O/R (object/relatie?) mapper?
Zoek ff mbhv Google naar de term O/R mapper. Voorbeelden zijn bv Hibernate.
Een O/R mapper maakt de mapping van je DB model naar je class - model.

https://fgheysels.github.io/

Pagina: 1