Van ORM naar relationeel model naar domeinmodel (JPA)

[GSteven]

Voor een schoolproject zijn we druk bezig om een stuk software te ontwikkelen om aan beheer van leden in een vereniging te doen.

In ons domein is het volgende mogelijk:
- Lid kan individueel een afspraak individueel
- Lid kan een afspraak hebben in groepsverband (een training, een match bv), maar wanneer iemand van groep veranderd blijven de vorige afspraken geldig en de volgende afspraken worden gewist.

Als datamodelleringstechniek hebben we ORM gebruikt met dit als resultaat:


Omgezet naar een relationeel model betekent dit:
GroepAfspraak(GroepID, AfspraakID) - Bijhouden welke afspraken bij welke groep horen
LidAfspraak(LidID, AfspraakID) - Bijhouden welke leden bij een afspraak horen (i.f.v. groep
AfspraakLid(AfspraakID, LidID) - Individuele afspraken per lid


In de niet functionele-vereisten wordt van ons verwacht dat we gebruik maken van een ORM mapping tool zoals Hibernate. De keuze is gevallen op JPA met Hibernate als implementatie.

Om hiervoor een goede mapping naar een domeinmodel te voorzien dachten wij aan een klasse Lid met een Map<Groep, List<Afspraak>> voor de groepsafspraken en een List<Afspraak> voor de individuele afspraken.

Iemand van jullie die ons een duw kan geven in de goede richting om dit te gaan mappen?

[RobIII]

Iemand van jullie die ons een duw kan geven in de goede richting om dit te gaan mappen?

Waar strand je dan? Je hebt toch al een idee? En zou je anders de vraag wat concreter kunnen stellen?

En waarom zie ik in dat schema een Lid->heeft...->naam Hoe moet ik dat lezen? Je hebt naam in een andere tabel dan lid? En voornaam ook weer? En idem met sexe/adres/stamnummer/etc..

[ Voor 13% gewijzigd door RobIII op 04-11-2009 19:13 ]

[GSteven]

Een stippellijn betekent een value type. Betekent een een relationeel model een kolom/attribuut.

Vergeten te vermelden:
Voor de lijst dachten we aan ElementCollection. Voor Map is het eigenlijk een map-key toewijzen. Maar dan als value een lijst gebruiken. Daar hangen we eigenlijk vast.

[whoami]

GSteven schreef op woensdag 04 november 2009 @ 19:02:

In ons domein is het volgende mogelijk:
- Lid kan individueel een afspraak individueel
- Lid kan een afspraak hebben in groepsverband (een training, een match bv), maar wanneer iemand van groep veranderd blijven de vorige afspraken geldig en de volgende afspraken worden gewist.

Kan een lid dan niet tot meerdere groepen behoren ?

In de niet functionele-vereisten wordt van ons verwacht dat we gebruik maken van een ORM mapping tool zoals Hibernate. De keuze is gevallen op JPA met Hibernate als implementatie.

Om hiervoor een goede mapping naar een domeinmodel te voorzien ...

Moet je eerst je relationeel model ontwerpen, of, mag je ook eerst je domeinmodel ontwerpen, en dan van daaruit een relationeel model gaan maken ?

dachten wij aan een klasse Lid met een Map<Groep, List<Afspraak>> voor de groepsafspraken en een List<Afspraak> voor de individuele afspraken.

Brrrr .... Dit lijkt me toch maar raar ...
Een Afspraak is een Afspraak voor mij; ongeacht of deze 'individueel' is, of tot een groep behoort.
Daarom zou ik eerder een (abstracte) class Afspraak maken, waarvan je dan een IndividueleAfspraak & een GroepsAfspraak van afleidt.
Een lid heeft dan een collectie van afspraken, waarbij een afspraak een individuele afspraak, of een groep-afspraak kan zijn.

[GSteven]

We zijn moeten starten van een conceptueel schema (ORM) die we hebben moeten mappen naar een relationeel model. Nu moeten we beginnen aan onze implementatie... Vandaar. Ons relationeelmodel is er al.

De mogelijkheid om met een abstracte klasse te werken zal ik eens onder de loep nemen.

[whoami]

GSteven schreef op donderdag 05 november 2009 @ 19:30:
We zijn moeten starten van een conceptueel schema (ORM) die we hebben moeten mappen naar een relationeel model. Nu moeten we beginnen aan onze implementatie... Vandaar. Ons relationeelmodel is er al.

Er is een tendens / beweging, die stelt dat de manier waarop je je gegevens opslaat, slechts een 'implementatie detail' is. Dat je 'model' die je probleem voorstelt, het belangrijkste is, en dat dus eerst het OO model ontworpen wordt, en je op basis daarvan je ERD gaat maken (met desnoods een paar 'opofferingen' aan de puurheid van je relationeel model).
Nu, wat mijn mening daarover is laat ik in het midden, anders wordt er hier weer een 'holy war' gestart.

De mogelijkheid om met een abstracte klasse te werken zal ik eens onder de loep nemen.

Het is niet zozeer 'de mogelijkheid om met een abstracte class' te werken. Het gaat 'm eerder over het zo goed mogelijk modelleren van je class-hierarchie.
Volgens mij moet je het in dit probleem zo zien, dat je een 'afspraak' hebt, die individueel kan zijn, of een groepsafspraak kan zijn. Dit is een 'is a' structuur die je mbhv inheritance voorstelt. Of je daar dan een abstracte class of een interface voor gebruikt doet er op dit moment niet echt toe.
Ik doelde meer op het feit dat je model -zoals het nu is- volgens mij beter kan.

[pedorus]

whoami schreef op donderdag 05 november 2009 @ 21:00:
[...]

Er is een tendens / beweging, die stelt dat de manier waarop je je gegevens opslaat, slechts een 'implementatie detail' is. Dat je 'model' die je probleem voorstelt, het belangrijkste is, en dat dus eerst het OO model ontworpen wordt, en je op basis daarvan je ERD gaat maken (met desnoods een paar 'opofferingen' aan de puurheid van je relationeel model).
Nu, wat mijn mening daarover is laat ik in het midden, anders wordt er hier weer een 'holy war' gestart.

Nu heb ik er ook een mening over, namelijk dat Object-Role Modeling, net als ERD, vooral handig is als je teveel ruimte hebt die je op wilt vullen. In de praktijk kun je dus veel beter gewoon UML gebruiken (class diagram). Dit draadje bewijst het maar weer, met UML was het duidelijker geweest en had het diagram gewoon binnen het plaatje gepast. Daarnaast heb je niet 2x de afkorting ORM, met verschillende betekenissen.

GSteven schreef op woensdag 04 november 2009 @ 19:02:
Omgezet naar een relationeel model betekent dit:
GroepAfspraak(GroepID, AfspraakID) - Bijhouden welke afspraken bij welke groep horen
LidAfspraak(LidID, AfspraakID) - Bijhouden welke leden bij een afspraak horen (i.f.v. groep
AfspraakLid(AfspraakID, LidID) - Individuele afspraken per lid

Ik neem aan dat een van de laatste 2 een VIEW is ofzo? Anders heb je dubbele data... Bevat die VIEW alle afspraken ofzo? Daarnaast is het wat onduidelijk wat het verschil is tussen de laatste 2. Je hebt dus leden, afspraken en groepen, en daartussen steeds many-to-many relaties als ik het goed snap, en geen verschillende soorten afspraken zoals ik het snap.

[EfBe]

pedorus schreef op donderdag 05 november 2009 @ 22:33:
[...]

Nu heb ik er ook een mening over, namelijk dat Object-Role Modeling, net als ERD, vooral handig is als je teveel ruimte hebt die je op wilt vullen. In de praktijk kun je dus veel beter gewoon UML gebruiken (class diagram). Dit draadje bewijst het maar weer, met UML was het duidelijker geweest en had het diagram gewoon binnen het plaatje gepast.

Echt nonsense.

ORM / NIAM geeft een abstractieniveau boven ERD, UML niet, die geeft een 1:1 projectie van je classes. Een ERD en classes uit een ORM/NIAM model maken is niet 1:1 straightforward, maar een echte projectie. Dit hele probleem gaat niet over code, en denken in code is falikant fout en ook het probleem van topicstarter (naast het feit dat zn ORM/NIAM model rammelt). Om tot je code te komen moet je eerst een projectie maken, en waarvan maak jij die projectie? je UML model van je classes is immers een 1:1 representatie ervan.

GSteven schreef op woensdag 04 november 2009 @ 19:02:
Voor een schoolproject zijn we druk bezig om een stuk software te ontwikkelen om aan beheer van leden in een vereniging te doen.

In ons domein is het volgende mogelijk:
- Lid kan individueel een afspraak individueel
- Lid kan een afspraak hebben in groepsverband (een training, een match bv), maar wanneer iemand van groep veranderd blijven de vorige afspraken geldig en de volgende afspraken worden gewist.

Dit laatste is behavior. ORM/NIAM modelleert 'facts', niet behavior.

Als datamodelleringstechniek hebben we ORM gebruikt met dit als resultaat:
[afbeelding]

aantal opmerkingen:
- 'Adres' is geen entity. Een veelvoorkomende fout die gemaakt wordt is dat 'adres' gezien wordt als een los te modelleren entity maar dat is slechts schijn: adressen worden nl. niet hergebruikt en je kunt deze gewoon als attributes modelleren op je entity Lid. Dit levert niet een lagere normaalvorm op wanneer je het model projecteert op ERD.
- je hebt 2 objectified relationships tussen afspraak en lid. Echter zijn ze niet als entities in gebruik, dus hoef je ze niet te objectifien. Dit is op zich wel makkelijker want je benoemt nu al de tables die je in je ERD krijgt, maar op het niveau van ORM/NIAM hoef je dit niet te doen.
- Wanneer een groep en afspraak heeft, dan impliceert dat dat ieder lid van die groep die afspraak heeft. Wisselt iemand van groep, dan heeft dat geen effect op lid, immers, de groep heeft de afspraak en ieder lid, via de groep, heeft dus die afspraak.
- de relatie (M:N) Lid - Afspraak is dan een normale m:n relatie.

Dit resulteert dus in de tables:
- Lid (MET adresvelden!)
- Afspraak
- Groep
- GroepAfspraak (intermediate entity tussen groep en afspraak)
- LidAfspraak (intermediate entity tussen lid en afspraak).
- GroepLid (intermediate entity tussen lid en groep)

Voor een lid, om te kijken welke afspraken daarbij horen, zul je dus via de set van groepen waar lid in zit ook de groepafspraken moeten ophalen, maar dat is an sig geen probleem.

Omgezet naar een relationeel model betekent dit:
GroepAfspraak(GroepID, AfspraakID) - Bijhouden welke afspraken bij welke groep horen
LidAfspraak(LidID, AfspraakID) - Bijhouden welke leden bij een afspraak horen (i.f.v. groep
AfspraakLid(AfspraakID, LidID) - Individuele afspraken per lid

Welke dus niet kloppen, lid heeft maar 1 m:n relationship met afspraak.

[pedorus]

EfBe schreef op vrijdag 06 november 2009 @ 09:58:
[...]

Echt nonsense.

ORM / NIAM geeft een abstractieniveau boven ERD, UML niet, die geeft een 1:1 projectie van je classes. Een ERD en classes uit een ORM/NIAM model maken is niet 1:1 straightforward, maar een echte projectie. Dit hele probleem gaat niet over code, en denken in code is falikant fout en ook het probleem van topicstarter (naast het feit dat zn ORM/NIAM model rammelt). Om tot je code te komen moet je eerst een projectie maken, en waarvan maak jij die projectie? je UML model van je classes is immers een 1:1 representatie ervan.

NIAM is iets Nederlands dat bijna niemand gebruikt volgens mij (over de wereld gezien). Ik denk dat je ERD verward met relationeel model. Zowel ORM, NIAM, ERD als UML zullen allemaal gemapt moeten worden naar een relationeel model. In de praktijk vermoed ik dat er eigenlijk alleen UML-class-diagram-achtige diagrammen worden gemaakt, maar dan niet altijd met de functies erbij, bijvoorbeeld met tools als Visio (al dan niet als echte UML), Rational, StarUML, Dia, MySQL Workbench of desnoods Access. De reden is simpel: die zijn tenminste overzichtelijk. Het plaatje dat ik hier zie is, met alle respect, gewoon een puinzooi.

Ik zie trouwens dat je verder op hetzelfde model als ik kom. Ik had er enkel strak overheen gekeken dat adres geen stippellijn had, en dus blijkbaar een aparte Entity was. Dat was met UML nooit gebeurd.

De volgorde die hier ontstaat is ook wat typisch. Nu krijg je ORM-model-->relationeel model-->OO model. Waar dient dat ORM-model dan eigenlijk voor? Kun je dan niet veel beter gewoon OO-model-->relationeel model doen, en dat ORM-gebeuren achterwege laten? Ik zie geen enkele reden om UML niet direct voor het ontwerpen te gebruiken, daar is het ten slotte mede voor bedoelt...

[whoami]

pedorus schreef op vrijdag 06 november 2009 @ 12:52:
[...]

Zowel ORM, NIAM, ERD als UML zullen allemaal gemapt moeten worden naar een relationeel model.

Waarom ? Waarom zou je een model dat je voorstelt dmv UML moeten gaan mappen naar een relationeel model ? Dat is niet altijd zo.

In de praktijk vermoed ik dat er eigenlijk alleen UML-class-diagram-achtige diagrammen worden gemaakt, maar dan niet altijd met de functies erbij, bijvoorbeeld met tools als Visio (al dan niet als echte UML), Rational, StarUML, Dia, MySQL Workbench of desnoods Access.

Een database gebruiken om een UML diagram voor te stellen ?

Ik zie trouwens dat je verder op hetzelfde model als ik kom. Ik had er enkel strak overheen gekeken dat adres geen stippellijn had, en dus blijkbaar een aparte Entity was. Dat was met UML nooit gebeurd.

Waarom was dat met UML nooit gebeurd ?
Als iemand *denkt* dat Address een entity moet zijn, dan zal hij dat in zijn UML diagram ook als een entity gaan voorstellen.

[pedorus]

whoami schreef op vrijdag 06 november 2009 @ 12:59:
[...]
Waarom ? Waarom zou je een model dat je voorstelt dmv UML moeten gaan mappen naar een relationeel model ? Dat is niet altijd zo.

Klopt. Ik ga even uit van databasedesign.

Een database gebruiken om een UML diagram voor te stellen ?

Dit was een beetje grof gesteld natuurlijk, ik heb het meer over de visuele gelijkenis tussen de diagrammen. Dus een box met daarin de entitynaam en de bijbehorende attributen, en geen aparte bolletjes per attribuut. Ik zou persoonlijk pleiten voor gewoon echt UML gebruiken.

Waarom was dat met UML nooit gebeurd ?
Als iemand *denkt* dat Address een entity moet zijn, dan zal hij dat in zijn UML diagram ook als een entity gaan voorstellen.

Ik had het over het over het hoofd zien van dat iets een entity is in plaats van een attribuut. In UML is het verschil tussen attributen en entities veel duidelijker.

[EfBe]

pedorus schreef op vrijdag 06 november 2009 @ 12:52:
[...]
NIAM is iets Nederlands dat bijna niemand gebruikt volgens mij (over de wereld gezien). Ik denk dat je ERD verward met relationeel model. Zowel ORM, NIAM, ERD als UML zullen allemaal gemapt moeten worden naar een relationeel model.

NIAM is een voorloper van ORM, beide bedacht door o.a. Halpin, en NIAM is mede ontwikkeld door Nijssen (samen met Halpin). ERD is een abstractieniveau lager dan NIAM/ORM, want ERD kan geen inheritance modelleren op een abstract niveau, ORM/NIAM wel. UML is een 1:1 representatie, en dus win je er niets mee, los van het feit dat het geen moer met relational databases te maken heeft natuurlijk (immers, inheritance projections naar relational models is niet 1:1, en dat is omvat in NIAM/ORM.

Ik verwar overigens helemaal niks, dit is nl. mijn vakgebied

In de praktijk vermoed ik dat er eigenlijk alleen UML-class-diagram-achtige diagrammen worden gemaakt, maar dan niet altijd met de functies erbij, bijvoorbeeld met tools als Visio (al dan niet als echte UML), Rational, StarUML, Dia, MySQL Workbench of desnoods Access. De reden is simpel: die zijn tenminste overzichtelijk. Het plaatje dat ik hier zie is, met alle respect, gewoon een puinzooi.

mja, wat is je punt nou eigenlijk? Beetje zeiken op niam/ORM en het pushen van UML terwijl dat totaal irrelevant is? Want meer is het niet wat je ter tafel brengt.

Hoe gaat UML bv de projectie doen van een inheritance hierarchie naar een ERD / relational model? NIAM/ORM omschrijft dat tot in detail. Net als alle andere zaken mbt wat je kunt modelleren in NIAM/ORM.

Ik zie trouwens dat je verder op hetzelfde model als ik kom. Ik had er enkel strak overheen gekeken dat adres geen stippellijn had, en dus blijkbaar een aparte Entity was. Dat was met UML nooit gebeurd.

Dat betwijfel ik, want als je Adres als class modelleert, was dat wel degelijk gewoon een associatie geworden, terwijl het bv in de db als een set attributes van de entity is gemodelleerd.

De volgorde die hier ontstaat is ook wat typisch. Nu krijg je ORM-model-->relationeel model-->OO model. Waar dient dat ORM-model dan eigenlijk voor? Kun je dan niet veel beter gewoon OO-model-->relationeel model doen, en dat ORM-gebeuren achterwege laten? Ik zie geen enkele reden om UML niet direct voor het ontwerpen te gebruiken, daar is het ten slotte mede voor bedoelt...

Wellicht eerst even kijken op www.orm.net, en lezen wat halpin etc. allemaal meldt zodat je wat beter kunt begrijpen waarom NIAM/ORM belangrijk is of beter: het abstractieniveau waar het op opereert.

(hint, de volgorde is:
ORM -> relational model
&
ORM -> class model
immers, dan en alleen dan kun je classes op tables mappen, want ze betekenen hetzelfde)
Terry heeft zelfs de moeite genomen iets te melden over UML, je kunt je hart ophalen dus

[pedorus]

EfBe schreef op vrijdag 06 november 2009 @ 14:25:
[...]
ERD is een abstractieniveau lager dan NIAM/ORM, want ERD kan geen inheritance modelleren op een abstract niveau, ORM/NIAM wel.

Er zijn extenties die dit wel kunnen, maar ik heb dus ook niks met ERD.

UML is een 1:1 representatie, en dus win je er niets mee,

Dit lijkt mij een beetje onzin. Als dit bij ORM niet zo is, en er in een ORM-model meer staat dan dat je in de code/database kan vinden, dan gaat het dus om informatie die niet eens in de uiteindelijke applicatie komt. Dat lijkt mij al snel geen relevante informatie voor het ontwikkelen en analyseren van een applicatie, oftewel data, die dus zsm weggegooid kan worden.

los van het feit dat het geen moer met relational databases te maken heeft natuurlijk

Ik zie hele boeken erover verschijnen, maar ze hebben vast niks met elkaar te maken.

mja, wat is je punt nou eigenlijk? Beetje zeiken op niam/ORM en het pushen van UML terwijl dat totaal irrelevant is? Want meer is het niet wat je ter tafel brengt.

Ik zie mensen moeite steken in het (leren) maken van onoverzichtelijke diagrammen. De relevantie van UML-achtige diagrammen lijkt mij dat je ze zeer vaak tegenkom in de industrie..

Hoe gaat UML bv de projectie doen van een inheritance hierarchie naar een ERD / relational model?

Zie de resultaten van die google-link. Lijkt me in de praktijk geen enkel probleem.

Dat betwijfel ik, want als je Adres als class modelleert, was dat wel degelijk gewoon een associatie geworden, terwijl het bv in de db als een set attributes van de entity is gemodelleerd.

Ik had adres gewoon genegeerd, omdat dat niet duidelijk werd uit het model dat het een aparte entity zou zijn:

pedorus schreef op donderdag 05 november 2009 @ 22:33:
Je hebt dus leden, afspraken en groepen, en daartussen steeds many-to-many relaties als ik het goed snap, en geen verschillende soorten afspraken zoals ik het snap.

Maar in zijn algemeenheid hoef je 1-1 relaties niet perse om te zetten naar 2 aparte tabellen. Dus als je in UML adres apart zet, dan hoef je dat niet naar 2 tabellen in het relationele model te mappen. Daarnaast zijn er situaties mogelijk waarin je wel degelijk tabel met adressen wil hebben (denk aan een gemeente). Andersom, is de mapping van ORM naar een class model ook tot in de details vastgelegd? Waarom is het erg als er bij de mapping naar een relationeel model ook bepaalde keuzes worden gemaakt?

Wellicht eerst even kijken op www.orm.net, en lezen wat halpin etc. allemaal meldt zodat je wat beter kunt begrijpen waarom NIAM/ORM belangrijk is of beter: het abstractieniveau waar het op opereert.

Mm, ondanks dat het door de ORM-mensen zelf is geschreven, zie ik daar de belangrijkste argumenten ook staan:

quote: http://www.orm.net/pdf/JDM99.pdf

UML class diagrams are often more compact, and can be
adorned with a vast array of implementation detail for engineering to and from objectoriented
programming code. Moreover, UML includes mechanisms for modeling
behavior, and its acceptance as an OMG standard is helping it gain wide support in
industry, especially for the design of object-oriented software.
[...]
Research is currently under
way to add transformations between ORM and UML. Once this support is widely
available, empirical studies are planned to study why and how practitioners choose
and/or integrate modeling methods in practice.

Typisch dat het laatste resultaat er nooit is gekomen. Ik heb wel een vermoeden, ik ken namelijk geen niet-wetenschappelijke practitioners die ORM gebruiken...

hint, de volgorde is:
ORM -> relational model
&
ORM -> class model
immers, dan en alleen dan kun je classes op tables mappen, want ze betekenen hetzelfde)

Ah, de titel van dit draadje is dus niet helemaal correct. Maar goed, ik blijf persoonlijk gewoon bij class model->relationeel model, en we skippen de moeite die ORM kost. Of zie ik iets over het hoofd dat ik blijkbaar altijd heb gemist?