[alg] 'soorten' relaties en or-mapping

[Alarmnummer]

Ik heb een vraag over relaties in de database en bij objecten. Ik begrijp hoe cardinaliteiten werken, maar wat niet helemaal duidelijk is zijn de 'types' relaties tussen objecten.

Tussen een order en een order regel bestaat een bepaalde relatie " order bestaat uit meerdere order regels". Bij mijn Order object zou ik dus ook graag een getOrderRegels methode willen zien.

Tussen een auto en een kleur kan ook een relatie bestaan "auto heeft kleur". Maar je zult nooit direct aan een kleur object getAuto`s opvragen.

Het gekke is dat ik mijn objecten altijd wel goed opzet, dus het is geen kwestie van hoe doe ik het goed.. mijn vraag is.. waarom doe ik het goed.. kan iemand mij misschien een duidelijke uitleg geven van de soorten relaties.

[Michali]

Maar dat geldt volgens mij toch ook voor een order regel? Die zou ook geen method getOrders moeten hebben als een order regel maar aan 1 order gekoppeld mag zijn. Heet het dan niet gewoon compositie, dat een object niet bestaat zonder aan ander object (theoretisch)?

[bille]

Tussen een auto en een kleur kan ook een relatie bestaan "auto heeft kleur". Maar je zult nooit direct aan een kleur object getAuto`s opvragen

dat komt omdat de kleur die je auto heeft een uniek object.. Je zou wel aan het object Color een methode kunnen toevoegen "getItemColoredByThis()' en die retourneerd een instance van een object die de interface 'ColorableObject' implementeert.
Overigens zou het wel kunnen wat jij zegt (dus een methode getAuto() implementeren) maar dat gaat tegen het 'Reverse Dependency priciple' in.. dwz: je mag een simpel object (Color) eigelijk niet implementatie afhankelijk maken. Dat wil je ook niet zoals je zelf aangeeft omdat een Color toegepast kan worden op meer dan alleen een auto, namelijk op alle colorable objects..


Maare.. als ik me niet vergis bedoel je zoiets als: Aggregatie, Generalisatie, Defines etc... misschien is dit wat voor je?: http://www.science.uva.nl...sfh/chapters/node132.html

[ Voor 33% gewijzigd door bille op 04-02-2005 10:02 ]

[Verwijderd]

Alarmnummer schreef op vrijdag 04 februari 2005 @ 09:23:
Tussen een auto en een kleur kan ook een relatie bestaan "auto heeft kleur". Maar je zult nooit direct aan een kleur object getAuto`s opvragen.

Wel... waarom niet?

Waarschijnlijk denk je van niet omdat de term "kleur" voor jou een bredere betekenis heeft, buiten het domein van je applicatie. Omdat jij weet dat niet alleen auto's een kleur hebben, maar ook stoelen, bloemen, appels en toetsenborden ben je van mening dat het niet logisch is om [alleen] een getAutos() methode op een kleur te hebben. Want, waarom dan niet ook een getStoelen(), getBloemen() en getToetsenborden() ?

Maar ik zie niet in waarom het binnen je applicatiedomein niet acceptabel zou zijn om een getAutos() methode op een Kleur object te hebben, om op die manier achter bijvoorbeeld alle rode auto's te komen.

[Alarmnummer]

bille schreef op vrijdag 04 februari 2005 @ 09:56:
[...]
Dat wil je ook niet zoals je zelf aangeeft omdat een Color toegepast kan worden op meer dan alleen een auto, namelijk op alle colorable objects..

Nu ga je een stuk polymorfisme toevoegen dat absoluut geen toegevoegde waarde heeft. Dit is dus geen zinnige opmerking.

Maare.. als ik me niet vergis bedoel je zoiets als: Aggregatie, Generalisatie, Defines etc... misschien is dit wat voor je?: http://www.science.uva.nl...sfh/chapters/node132.html

Ik ben ze idd al een aantal keren in mijn uml editor tegen gekomen, maar de link wel/geen methodes aanmaken nog niet goed en duidelijk gelegt.

[FendtVario]

Alarmnummer schreef op vrijdag 04 februari 2005 @ 09:23:
Tussen een order en een order regel bestaat een bepaalde relatie " order bestaat uit meerdere order regels". Bij mijn Order object zou ik dus ook graag een getOrderRegels methode willen zien.

Tussen een auto en een kleur kan ook een relatie bestaan "auto heeft kleur". Maar je zult nooit direct aan een kleur object getAuto`s opvragen.

De methoden die je gebruikt om eigenschappen op te vragen heeft denk ik te maken met de 'sturende factor'. In je eerste voorbeeld is de sturende factor de order want je hebt nooit een orderregel zonder order. Het is dan ook niet interessant om op te vragen welke order bij een regel hoort omdat je, voorrdat je regel opzoekt, eerst de order opzoekt.

Hetzelfde geldt voor de kleur van een auto, de auto is de sturende factor.

Maar, dat wil nog niet zeggen dat het niet interessant is om de andere kant op gegevens op te vragen. Maar waarschijnlijk wordt je vraagstelling dan anders. het is dan niet getAuto's maar getAutoMetKleur(kleur). Voor orders kan het heel interessant zijn om alle orders op te vragen waarbij een bepaald artikel voorkomt, getAlleOrdersMetArtikel(artikel). Dit kun je ook niet uitvoeren op het object OrderRegel omdat die alleen kennis heeft van een orderregel.

[Alarmnummer]

Verwijderd schreef op vrijdag 04 februari 2005 @ 11:14:
[...]


Wel... waarom niet?

Waarschijnlijk denk je van niet omdat de term "kleur" voor jou een bredere betekenis heeft, buiten het domein van je applicatie. Omdat jij weet dat niet alleen auto's een kleur hebben, maar ook stoelen, bloemen, appels en toetsenborden ben je van mening dat het niet logisch is om [alleen] een getAutos() methode op een kleur te hebben. Want, waarom dan niet ook een getStoelen(), getBloemen() en getToetsenborden() ?

Als je er niet inhoudelijk naar kijkt (dus geen rekening houd met de normale informatie behoefte in een applicatie) dan zul je bij kleur ook al deze methodes aantreffen.

En daar gaat het mij om... ik heb deze behoefte bij kleur niet nodig... maar bij order en order regels wel... Er is dus een verschil tussen de beide relaties... wat is dit verschil? Is dit formeel vastgelegd (vast wel)... dat wil ik weten. Ik wil dus weten welke soorten relaties er zijn...

Maar ik zie niet in waarom het binnen je applicatiedomein niet acceptabel zou zijn om een getAutos() methode op een Kleur object te hebben, om op die manier achter bijvoorbeeld alle rode auto's te komen.

Tja.. die informatiebehoefte is er bij ons nooit. En verder zul je bij een or mapping dan rekening moeten houden met allerlei lazy loads (ander trek je in 1 keer de hele db leeg). Maar aangezien deze informatie behoefte er bij ons niet is.. wil ik niet de (configuratie) rekening betalen van relaties die ik nooit op deze manier opvraag (dus nooit aan het entiteit zelf).

[edit]
een eigenschap van een relatie is dat het bidirectional of unidirectional relation is. In het geval van kleur is het een unidirectional relation. Van een auto wil je wel de kleur weten, maar van een kleur wil je niet de auto`s weten die die kleur hebben (als je het wel wilt weten kun je altijd nog een query uitvoeren).. Maar je vraagt het nooit direct aan de entity.

[ Voor 24% gewijzigd door Alarmnummer op 04-02-2005 11:45 ]

[Michali]

Volgens mij is het verschil gewoon dat een order regel direct in verband staat met een order. Een order regel zul je niet zo snel aatreffen bij een ander object. Kleur is meer een eigenschap van je object en er niet zozeer een onderdeel van (ik weet niet of dat van belang is). Een kleur is ook echt toepasbaar op meerdere objecten, maar bij een order regel is dat niet zo. Hoe deze twee verschillen nou benoemt worden weet ik eigenlijk ook niet.

[ Voor 5% gewijzigd door Michali op 04-02-2005 12:03 ]

[ACM]

In Hibernate is bovenstaande allemaal gewoon mogelijk. Het heet dan one-to-many, many-to-many en one-to-one, met dezelfde betekenis als het bekende 1-tje en *ertje in de diverse diagrammen. Een x-to-many beeld je af op een Container, meestal een Set, maar kan ook een Map of List zijn.

De kleur is overigens weliswaar een one-to-many relatie, maar dan zonder inverse (neem ik maar aan, zou best met kunnen hoor, dat je alle rode objecten kunt opvragen). Lazy loading is bij mijn weten naast standaard in Hibernate ook overgenomen in EJB3.

[whoami]

Michali schreef op vrijdag 04 februari 2005 @ 12:02:
Volgens mij is het verschil gewoon dat een order regel direct in verband staat met een order. Een order regel zul je niet zo snel aatreffen bij een ander object. Kleur is meer een eigenschap van je object en er niet zozeer een onderdeel van (ik weet niet of dat van belang is). Een kleur is ook echt toepasbaar op meerdere objecten, maar bij een order regel is dat niet zo. Hoe deze twee verschillen nou benoemt worden weet ik eigenlijk ook niet.

Inderdaad, een orderregel kan eigenlijk niet opzichzelf bestaan; een orderregel moet gelinked zijn aan een order, anders heeft het geen bestaansrecht.
Bij een kleur is dat anders; een kleur kan wel op zichzelf bestaan en heeft geen exclusieve relatie met een ander object.
(Het één is compositie, het ander is aggregatie dacht ik, maar vraag me nu niet welkeen van de twee wat is. )

[Verwijderd]

Compositie en aggregatie sluiten elkaar niet uit. Beide beschrijven een bidirectionele relatie.
Bij een bidirectionele relatie kan een uiteinde "zwak" of "sterk" zijn. Een object van een zwakke klasse kan niet bestaan zonder objecten van de andere kant. Hier zijn in principe 4 mogelijkheden mogelijk: beide kanten kunnen onafhankelijk van elkaar sterk of zwak zijn.
Bij aggregatie is het container-object zwak. Aggregatie zegt niets over het onderdeel.
Bij compositie delen container en contained een sterke basisklasse. Echter (contained) subklasses kunnen weer zwak zijn, bv een order uit het voorbeeld hierboven.

Een andere fijne relatie is overerving. Stel de relatie CManager --> CWerknemer geven we vorm met een table-split. Dan is voor elke CManager-record een CWerknemer-record aanwezig. De cardinaliteit van de relatie in de database is 1:1.

[drm]

Grappig, ik had het gister met Cheatah over precies hetzelfde probleem binnen ons CMS. Zonder heel erg veel af te weten van O/R-mapping, heb je volgens mij bij n:1 relaties eigenlijk altijd te maken met de vraag of de one-kant een "container" is voor de many-kant. Dus: een order is eigenlijk altijd een container voor Order-regels; je verplaatst een order-regel bijvoorbeeld nooit van de 1 naar de andere order niet erg waarschijnlijk iig, is maar een voorbeeld. Met een auto-kleur heb je dat niet, een "kleur" is niet een container van "vele auto's". Hetzelfde idee kun je hebben met n:m relaties, waarbij de ene many-kant ook de functie kan vervullen van container voor de andere kant. Denk bijvoorbeeld aan producten/product-categorien; 1 product kan in meerdere categorien voorkomen, maar de product-categorie is toch duidelijk de "container" van de producten, en niet andersom. Als je het dan over product-kleuren gaat hebben, (ook mogelijk in een n:m-relatie) krijgt zo'n relatie weer een heel andere betekenis (terwijl het fysiek in de db eigenlijk nog niet eens een heel andere relatie is of hoeft te zijn)

Wij zijn er eigenlijk op uit gekomen dat je bij relaties altijd aan moet kunnen geven welke kanten de relatie op werkt (van de one naar de many, andersom of allebei). Wanneer een relatie van one naar many werkt, zou je dus een getTheMany () (orderregels) moeten hebben, wanneer de many naar de one werkt, moet je een getTheOne () (order, maar ook kleur) hebben.

Ik weet niet of je hier wat aan hebt maar da's een beetje de brainstorm die we hadden.

edit:
halve zinnen afgemaakt

[ Voor 8% gewijzigd door drm op 04-02-2005 12:28 ]

[Alarmnummer]

ACM schreef op vrijdag 04 februari 2005 @ 12:05:
In Hibernate is bovenstaande allemaal gewoon mogelijk. Het heet dan one-to-many, many-to-many en one-to-one, met dezelfde betekenis als het bekende 1-tje en *ertje in de diverse diagrammen. Een x-to-many beeld je af op een Container, meestal een Set, maar kan ook een Map of List zijn.

De kleur is overigens weliswaar een one-to-many relatie, maar dan zonder inverse (neem ik maar aan, zou best met kunnen hoor, dat je alle rode objecten kunt opvragen). Lazy loading is bij mijn weten naast standaard in Hibernate ook overgenomen in EJB3.

Je moet mijn topic even goed doorlezen. Ik heb niet gevraag hoe het in hibernate moet. Ik heb gevraagd hoe dit soort relaties heten en welke soorten relaties er allemaal zijn.

Ik wil dus meer inzicht in het fenomeen: relaties.

[Michali]

whoami schreef op vrijdag 04 februari 2005 @ 12:05:
[...]


Inderdaad, een orderregel kan eigenlijk niet opzichzelf bestaan; een orderregel moet gelinked zijn aan een order, anders heeft het geen bestaansrecht.
Bij een kleur is dat anders; een kleur kan wel op zichzelf bestaan en heeft geen exclusieve relatie met een ander object.
(Het één is compositie, het ander is aggregatie dacht ik, maar vraag me nu niet welkeen van de twee wat is. )

Compositie betekent dat een object ergens onderdeel van is en dat het niet bestaat zonder de container. De contained objecten worden (in normale situaties) aangemaakt tegelijkertijd met de container en ook weer verwijderd tegelijkertijd. Aggregatie betekent inderdaad dat een object wel kan bestaan zonder de ander, het is dus op zich nog een logisch geheel. Ik denk dat je daar ook naar moet kijken. Een order regel geeft al aan dat het iets van een order is. Het heeft order immers al in de naam zitten. Maar toch is dit weer lastig bij een kleur. Een kleur los zul je toch niet zo snel tegenkomen. Ik denk dat je dan ook niet van een echte geaggregeerde relatie mag spreken. Een kleur is echt gewoon een eigenschap van iets dat toevallig geen simpel data type is. Dat is volgens mij toch wat anders dan een relatie met een klant oid. Volgens mij model je zoiets ook niet als een relatie/associatie. Het is dan echt een property van een object.

[ Voor 4% gewijzigd door Michali op 04-02-2005 12:37 ]

[Alarmnummer]

We gaan er in dit geval wel even van uit dat kleur een entiteit is (dus een record in een db). Iedere kleur heeft een rgb waarde en de kostprijs van het spuiten

[ Voor 27% gewijzigd door Alarmnummer op 04-02-2005 12:38 ]

[ACM]

Nou, die namen van hibernate zijn de namen zoals ik ze ooit geleerd heb

one-to-many, een relatie zoals de kleur van een auto. 1 kleur per auto, maar meerdere auto's met dezelfde kleur. Maar ook de order en orderregels. Waarbij je in het laatste geval de order van een orderregel zou kunnen willen weten (wat niet strict noodzakelijk is).

one-to-one, een op een relaties. Bijvoorbeeld een huwelijk (nouja, in Nederland dan).

En dan is er nog many-to-many. De producten die aan meerdere klanten worden verkocht. Vaak zit daar een tussenstap bij (koppeltabel in sql bijv).

Maar hoe je meer over relaties? Ik gebruik het eigenlijk altijd vrij intiutief? Echt meer dan die drie varianten kan ik je niet noemen iig. Uiteraard zijn er wel situaties waarbij het lastig is om te beoordelen welk relatietype er nou precies is, maar over het algemeen is het vrij simpel te zien door de te implementeren zaken gewoon in simpele zinnen te beschrijven.

[drm]

Michali (over kleur) Ik denk dat je dan ook niet van een echte geaggregeerde relatie mag spreken.

Ik kan me voorstellen (ik kende die termen niet, dus slap my if i'm wrong ), dat een geaggregeerde relatie ook betekent dat 't object aan meerdere dingen gerelateerd kan zijn. Bijvoorbeeld: een auto kan paars zijn, maar een pen ook. Of is daar weer een ander mooi naampje voor?

[Michali]

drm schreef op vrijdag 04 februari 2005 @ 12:38:
[...]
Ik kan me voorstellen (ik kende die termen niet, dus slap my if i'm wrong ), dat een geaggregeerde relatie ook betekent dat 't object aan meerdere dingen gerelateerd kan zijn. Bijvoorbeeld: een auto kan paars zijn, maar een pen ook. Of is daar weer een ander mooi naampje voor?

Maar dat is volgens mij eerder gewoon een geheel ander kleur object dat toevallig dezelfde waardes heeft. Een kleur zou dan logischer wijs dan ook een value object zijn en geen reference object (Een value object, volgens de definitie van fowler, is een object zonder een identiteit waarmee je hem kunt vergelijken met andere objecten.) Dit zou eigenlijk ook geheel niet mogen, omdat je anders de kleur van wie weet wat aanpast als je dit voor 1 object veranderd (of je moet natuurlijk een geheel nieuw object toewijzen).

[Michali]

Alarmnummer schreef op vrijdag 04 februari 2005 @ 12:38:
We gaan er in dit geval wel even van uit dat kleur een entiteit is (dus een record in een db). Iedere kleur heeft een rgb waarde en de kostprijs van het spuiten

In dat geval heeft het object dus wel een identiteit en is het wel een relatie van het aggregatie type (many-to-many dan denk ik).

[Alarmnummer]

ACM schreef op vrijdag 04 februari 2005 @ 12:38:
Nou, die namen van hibernate zijn de namen zoals ik ze ooit geleerd heb

one-to-many

one-to-one, een op een relaties.

En dan is er nog many-to-many.

Dit zijn je cardinaliteiten en daar heb ik geen problemen mee

Maar er zijn nog meer subtiele eigenschappen oa die directionaliteit. En of een object bestaansrecht heeft zonder een ander object. Een orderregel heeft geen bestaandrecht zonder een order.. maar een kleur wel zonder auto...

Ik zal nog eens even heel goed gaan kijken naar die aggregatie/compositie eigenschap.

[Verwijderd]

Alarmnummer schreef op vrijdag 04 februari 2005 @ 11:40:
Tja.. die informatiebehoefte is er bij ons nooit. En verder zul je bij een or mapping dan rekening moeten houden met allerlei lazy loads (ander trek je in 1 keer de hele db leeg). Maar aangezien deze informatie behoefte er bij ons niet is.. wil ik niet de (configuratie) rekening betalen van relaties die ik nooit op deze manier opvraag (dus nooit aan het entiteit zelf).

Dan heb je toch je eigen vraag beantwoord? Er zijn (voor jou) twee soorten relaties:

• Relaties die interessant zijn voor je applicatie
• Relaties die niet interessant zijn voor je applicatie

Voor de relaties die wel interessant zijn maak je methoden aan op je objecten, en voor de relaties die niet interessant zijn (lees: waar geen behoefte aan is), doe je dat niet.

Ik denk namelijk niet dat je over het algemeen kan zeggen (om maar een voorbeeld te geven in de terminologie die hier al in de thread is gebruikt), dat compositie relaties wel interessant zijn (beide kanten op), en aggregatie relaties niet (of maar één kant op).

Dan blijft er natuurlijk nog het praktische probleem over wat een makkelijke manier is om aan te geven welke relaties wenselijk en onwenselijk zijn, maar ik neem aan dat je dat wel ergens in de configuratie van je O/R-mapper op kan nemen.

[ Voor 11% gewijzigd door Verwijderd op 04-02-2005 12:57 ]

[Verwijderd]

Een composition is toch een aggregation waarbij de owner de enige is die bepaalt of de parts blijven bestaan.. een heel sterke aggregation zeg maar.

Iets als een color attribute lijkt me eerder gewoon een simpele unidirectional association. Als de auto ophoudt te bestaan kan het Color object nog wel gewoon blijven bestaan (stel dat je een static Color.red oid hebt gebruikt...).

[Infinitive]

Zonder deze hele thread te lezen ( ), heeft dit niet gewoon te maken met:

(1) Of je relatie van het type "verwijzing" of van het type "bevat" is.
(2) Het wel of niet bidirectioneel zijn van de relatie.

[Verwijderd]

Alarmnummer schreef op vrijdag 04 februari 2005 @ 12:38:
We gaan er in dit geval wel even van uit dat kleur een entiteit is (dus een record in een db). Iedere kleur heeft een rgb waarde en de kostprijs van het spuiten

Uit het voorbeeld zou attribuut Prijs evengoed bij Kleur als bij ArtikelKleur kunnen horen. In het laatste geval is dan variatie van spuitprijs mogelijk.

Relaties zijn ook entiteiten. Wanneer een relatie op zichzelf geen attributen meer heeft is het gebruikelijk niet door te gaan met kleinere entiteiten te zoeken. Dan zou je oneindig lang bezig blijven .
Een relationele database is een middel om de status van objecten van de gevonde entiteiten vast te leggen. Een relationele database is een middel, geen doel. De structuur van zo'n ding is geoptimaliseerd voor een gegeven probleem. Afgewogen wordt snelheid tegen redundantie of verschillende vormen van redundantie onderling. Zo leidt bv het gebruik van een aparte tabel voor een 1-op-n relatie tot redundantie van gegevens, hoewel deze aanpak het klasse-model beter zal weerspiegelen.

[Alarmnummer]

Verwijderd schreef op vrijdag 04 februari 2005 @ 13:27:
[...]
Uit het voorbeeld zou attribuut Prijs evengoed bij Kleur als bij ArtikelKleur kunnen horen. In het laatste geval is dan variatie van spuitprijs mogelijk.

Het was alleen even een voorbeeld

Een relationele database is een middel om de status van objecten van de gevonde entiteiten vast te leggen. Een relationele database is een middel, geen doel.

Ik geloof niet dat dat hier ter sprake is gekomen.

De structuur van zo'n ding is geoptimaliseerd voor een gegeven probleem. Afgewogen wordt snelheid tegen redundantie of verschillende vormen van redundantie onderling. Zo leidt bv het gebruik van een aparte tabel voor een 1-op-n relatie tot redundantie van gegevens, hoewel deze aanpak het klasse-model beter zal weerspiegelen.

Het ging mij om het object model van entiteiten die ook in de database voorkomen. Daar heb ik wat 'vragen' over. Het probleem zit hem niet zozeer in het feit of ik het wel of niet goed doe, maar ligt bij de vraag.. waarom ik het goed doe.

[ Voor 3% gewijzigd door Alarmnummer op 04-02-2005 13:55 ]

[jvdmeer]

Je begint het stukje met "order bestaat uit meerdere order regels". Maar volgens mij is dat al onjuist. Een order bestaat namelijk uit artikelregels. En die artikelregels hebben meerdere bestaansvormen. Vaak beginnen ze als een offerteregel, een (hopelijk groot deel) wordt dan een orderregel en eindigen hun leven tenslotte als faktuurregel.

Eigenlijk zijn offertes, orders en fakturen dezelfde objecten in een andere fase van het proces.

Dus eigenlijk bestaat er een n:m relatie tussen artikelregels en [offertes, orders en fakturen]. Of wijk ik met deze gedachte teveel af van het gangbare, en dient de discussie hierover in een apart draadje te worden gevoerd?

[Verwijderd]

Sorry, ik dwaalde af. Terug naar post 1.

Het lijkt erop dat de benodigde functies in je model komen: CAuto->getKleur. U wilde dit, dan bouw ik het. OK
Het lijkt erop dat sommige methoden in je model afwezig zijn: CKleur->getAuto. OK, want niemand vroeg erom. Je hebt doorgevraagd: wilt u van kleur ook het gebruik daarvan zien ? Antwoord: Nee, niemand heeft die informatie nodig. Weg functie. Iedereen blij.

Ik denk dat je goed kan luisteren .

[bille]

@TS: mayb moet je hier es naar kijken: http://www.csci.csusb.edu/dick/samples/ocl.html

waarom doe ik het goed..

Tja.. waarom doe ik het wel eens fout.. waarschijnlijk om dat jij goed bent en ik niet? beetje onbeantwoordbare vraag, maar waarschijnlijk komt het doordat jouw hersenen linksomdraaiend zijn
overigens beetje jammer Alarmnummer: ok ok .. geen modder gooien Bille..

kan iemand mij misschien een duidelijke uitleg geven van de soorten relaties.

Geef ik je een linkie naar een site waar verschillende object relatietypen staan uitgelegd, ga je nog klagen..

Maar je zult nooit direct aan een kleur object getAuto`s opvragen.

Zoals OneOfBorg terecht opmerkt.. het KAN wel. .dat jij het niet ziet zitten is iets heel anders..

Nu ga je een stuk polymorfisme toevoegen dat absoluut geen toegevoegde waarde heeft

. Kijk dat jij niet inziet dat een stukje abstractie aanbrengen in je applicatie ervoor zorgt dat het geheel herbruikbaar, rigide etc etc wordt ligt niet aan mij. Begin je zin dan met: ik VIND het niet zinnig ipv het is niet zinnig of het heeft geen waarde

@Bloog

Je hebt doorgevraagd: wilt u van kleur ook het gebruik daarvan zien ? Antwoord: Nee, niemand heeft die informatie nodig. Weg functie. Iedereen blij.

Praktisch gezien heb je gelijk.. je kán het wel implementeren, maar dat zou imho OO theoretisch niet correct zijn. Persoonlijk zou ik ervoor kiezen om een Collectie ColorableObjects te maken (extends Vector bijv.) en daar een methode op implementeren getObjectsByColor(Color myColor). Uiteraard implementeren alle objecten die gekleurd kunnen worden de interface 'ColorableObject' die op zijn beurt de methode set/getColor(Color myColor) afdwingt. Zo heb je iig een implementatie onafhankelijk object Color en een herbruikbare collectie waarin je kan zoeken op kleur en dus ook bruikbaar is voor andere typen objecten dan alleen auto's.

Maar goed dan zijn we weer abstractie aan het aanbrengen en als ik de TS mag geloven is dat vrij onzinnig

[ Voor 42% gewijzigd door bille op 04-02-2005 14:55 ]

[Michali]

jvdmeer schreef op vrijdag 04 februari 2005 @ 13:51:
Je begint het stukje met "order bestaat uit meerdere order regels". Maar volgens mij is dat al onjuist. Een order bestaat namelijk uit artikelregels. En die artikelregels hebben meerdere bestaansvormen. Vaak beginnen ze als een offerteregel, een (hopelijk groot deel) wordt dan een orderregel en eindigen hun leven tenslotte als faktuurregel.

Eigenlijk zijn offertes, orders en fakturen dezelfde objecten in een andere fase van het proces.

Dus eigenlijk bestaat er een n:m relatie tussen artikelregels en [offertes, orders en fakturen]. Of wijk ik met deze gedachte teveel af van het gangbare, en dient de discussie hierover in een apart draadje te worden gevoerd?

Ja zo kan je blijven generaliseren. Je moet gewoon designen naar de eisen die er nu zijn. Als zo'n extra generalisatie stap gewoon niet nodig is, dan moet je hem ook niet maken. Als je een goed ontwerp hebt kun je dit later alsnog doen.

[EfBe]

Alarmnummer schreef op vrijdag 04 februari 2005 @ 09:23:
Ik heb een vraag over relaties in de database en bij objecten. Ik begrijp hoe cardinaliteiten werken, maar wat niet helemaal duidelijk is zijn de 'types' relaties tussen objecten.

Tussen een order en een order regel bestaat een bepaalde relatie " order bestaat uit meerdere order regels". Bij mijn Order object zou ik dus ook graag een getOrderRegels methode willen zien.

Tussen een auto en een kleur kan ook een relatie bestaan "auto heeft kleur". Maar je zult nooit direct aan een kleur object getAuto`s opvragen.

Dat is maar net hoe je er naar kijkt.

Je hebt attributes, zoals customername, orderdate etc. Die hebben een relatie met elkaar en die noem je een entity. Zoals order, customer etc. Dan heb je relaties tussen attributes van verschillende entities, zoals order.customerid -> customer.customerid

Omdat attributes van verschillende entities die een relatie hebben met elkaar een relatie hebben met de andere attributes in de entity, spreek je van 'entity A heeft relatie met entity B'.

Nu heb je verschillende relatie typen:
1:1 (PK - FK/PK)
1:1 (PK - FK/UC)
1:1 (PK/FK - PK)
1:1 (FK/UC - PK)
1:n (PK - FK)
m:1 (FK - PK)

Verder is het zo dat wanneer je 3 entities hebt, A, B en C en B heeft een m:1 relatie naar A en een m:1 relatie naar C dat A en C een m:n relatie hebben via B.

Je kunt in algemene termen spreken over 'Customer heeft relatie met Order' maar daar heb je niet zoveel aan. Wat interessant is is wat je definieert wat de basis is van de relatie tussen Customer en Order, en dat is een referential constraint: Order.CustomerID == Customer.CustomerID.

Die constraint is de basis voor 2 relaties: Customer->Order (1:n) en Order -> Customer (m:1). Iedere constraint gaat 1 kant op en start altijd vanaf de FK side naar de PK side.

Binnen relational theory heb je hier niet zoveel last van. Bij O/R mappers is dat anders. Heb je in Customers nog een routine die bv GetOrders() heet, in Order heb je niet een routine die GetCustomers() heet, maar GetCustomer.

Fraaier wordt het wanneer we naar de 1:1 relaties gaan kijken. Is het bij een 1:n en m:1 relatie nog makkelijk te bepalen wat je moet nemen: een GetCustomer of een GetOrders, bij 1:1 relaties is dat lastig: hoe fetch je het related object? Via de PK? via een UC? Je moet dan weten aan welke kant van de relatie je zit: de FK side of de PK side.

Het gekke is dat ik mijn objecten altijd wel goed opzet, dus het is geen kwestie van hoe doe ik het goed.. mijn vraag is.. waarom doe ik het goed.. kan iemand mij misschien een duidelijke uitleg geven van de soorten relaties.

Dat komt omdat het relationele model en het E/R model eigenlijk heel natuurlijk werken, ZEKER wanneer je entities fysieke elementen representeren of elementen die je als entiteit ook tegenkomt in het dagelijks leven, bv Cursus, Auto, Customer, Product etc.

Het nare is: je kunt niet echt controlleren of iets 'goed' is, want een niet heel slim in elkaar gezet relational model werkt op zich best nog wel.

Even een oefening:
Department en Employee (istie weer). Stel ik model het zo:
Department: (DepartmentID* | Head | Name | Location)
Employee: (EmployeeID* | WorksAtDepartment | Name | ... )
waarbij Department.Head een FK is naar Employee.EmployeeID en Employee.WorksAtDepartment een FK is naar Department.DepartmentID

Niet gaan lachen, met addresses en customers zie je dit vaak terugkomen. Dit is een zg. loop. Je kunt dit niet saven in SQL zonder een nullable FK. Is dit goed? Geen idee. Er is een betere variant mogelijk met 3 entities ipv 2, zonder loop. Die ziet er niet natuurlijk uit:
Department: (DepartmentID* | Name | Location)
DepartmentEmployee: (DepartmentID* | EmployeeID* | IsHead)
Employee: (EmployeeID* | Name | ... )
Waarbij DepartmentEmployee.EmployeeID een UC heeft.

Dus of je het 'altijd' goed doet is niet altijd te zeggen. Soms denk je het goed gedaan te hebben, maar loop je toevallig NOG niet tegen de flaws aan die er in zitten. Het bovenstaande schemaatje is niet bedacht, maar een echt schema (onderdeel van).

[Alarmnummer]

bille schreef op vrijdag 04 februari 2005 @ 14:32:
@TS: mayb moet je hier es naar kijken: http://www.csci.csusb.edu/dick/samples/ocl.html

overigens beetje jammer Alarmnummer:

[...]
Geef ik je een linkie naar een site waar verschillende object relatietypen staan uitgelegd, ga je nog klagen..

Ik zal daar even naar kijken, my bad.

. Kijk dat jij niet inziet dat een stukje abstractie aanbrengen in je applicatie ervoor zorgt dat het geheel herbruikbaar, rigide etc etc wordt ligt niet aan mij. Begin je zin dan met: ik VIND het niet zinnig ipv het is niet zinnig of het heeft geen waarde

Ik ben mr abstract.. ik hou van goeie structuren en lekker veel abstractie. maar niet op plekken waar het niet nodig is. Ik zie de toegevoegde waarde niet in om een kleurbaar interface te maken voor alle objecten die een kleur kunnen dragen. Dat zou je alleen willen als je generiek over dit type object zou willen praten. Er zal vast wel een scenario te bedenken zijn waar het toepasbaar is, maar bij het voorbeeld met die auto is het vrij zinloos.

en daar een methode op implementeren getObjectsByColor(Color myColor). Uiteraard implementeren alle objecten die gekleurd kunnen worden de interface 'ColorableObject' die op zijn beurt de methode set/getColor(Color myColor) afdwingt. Zo heb je iig een implementatie onafhankelijk object Color en een herbruikbare collectie waarin je kan zoeken op kleur en dus ook bruikbaar is voor andere typen objecten dan alleen auto's.

De vraag is dus of je zo wilt gaan zoeken. In het geval van kleur zal het niet snel voorkomen en daarom is het in dit geval geen praktische oplossing. Een 'coole' oplossing maken omwille van het cool zijn is fout.. je maakt een oplossing uit praktische noodzaak.. en dat je er dan iets goeds van maakt is een 2e.. (daar hou ik namelijk wel van een coole oplossing)

Maar goed dan zijn we weer abstractie aan het aanbrengen en als ik de TS mag geloven is dat vrij onzinnig

Zoals ik al zei... ik ben gek op abstracties.. check mijn enorme collectie met pattern/architectuur opmerkingen. Maar ik kijk nu wel heel streng naar het wel of niet nodig zijn van abstracties. Abstracties zijn namelijk niet gratis.. ze leveren namelijk complexiteit op... De vraag is of jij de prijs wilt betalen voor deze complexiteit. Of de kosten van de complexiteit opwegen tegen de 'meerwaarde' van een abstractie. Als je domweg geen behoefte hebt aan die meerwaarde.... waarom dan een rekening betalen? (rekening krijg je gepresenteerd bij onderhoud en aanpassingen aan het systeem)

KISS... en dan bedoel ik niet zo`n ding dat je moeder of je vriendin je geeft...

[ Voor 5% gewijzigd door Alarmnummer op 04-02-2005 15:07 ]

[Alarmnummer]

EfBe schreef op vrijdag 04 februari 2005 @ 14:58:
[...]

Ik zal straks (als ik vrij ben) jouw opmerking even goed doorlezen.

[bille]

@Alarm.. hmm wellicht dat we elkaar niet goed begrepen ivm de context van de auto/kleur stelling. uiteraard ben ik het met je eens dat abstractie alleen moet worden toegepast daar het noodzakelijk is. MAAR aan de andere kant vind ik 'complexiteit' eigelijk geen argument omdat dat afhankelijk is van je IQ Wat voor mij complex is, is voor jou mayb peanuts.. En tja ik score maar 75 op de nationale IQ test (en neej, ik heet geen Kelly) dus zaken worden al vrij snel té complex voor mij.. betekend dat dat ik geen abstracties meer mag/kan aanbrengen???

ps: OCL is wel uber klote imho... soms wel noodzakelijk, maar kan erg complex worden in grote software programma's.

maar om dan maar even serieus in te gaan op de vraag, waarom je het goed doet:
Waarschijnlijk omdat OO programmeren/modelleren vrij intuitief is. Als je eenmaal door hebt dat alles wat je om je heen ziet feitelijk Objecten zijn, dan zie je ook in dat Objecten properties hebben, zoals een auto een kleur heeft. Kleur is in dat geval een eigenschap van auto, maar op zijn beurt is kleur ook weer een Object met bepaalde properties. Je zal doorgaans topdown redeneren denk ik. Je begint bij het grootste en gaat verticaal decomposeren. net zolang totdat je voor je gevoel de meest elementaire Object bouwsteentjes in je applicatie hebt ontdekt. Die bouwsteentjes hebben dus properties die op hun beurt GEEN Object meer voorstellen, of waarbij het niet meer relevant is om er een Object voor te maken (dat kan een kosten/baten keuze zijn, of een model abstractie beslissing, verder dan dit ga ik niet)
In het voorbeeld van de TS, is kleur een eigenschap van auto en zijn auto's geen eigenschap van kleur. TENZIJ het specifiek binnen je applicatie domein valt (zoals al eerder terecht werd opgemerkt door Bloog). In het geval van een auto en zijn kleur lijkt het me eigelijk wel ietwat onwaarschijnlijk, tenzij je bijv. een spuiterij hebt en Kleur als object je leidend voorwerp is.. maar in dat geval zal je zeggen: ik pas de auto toe op de kleur, en niet ik pas de kleur toe op de auto (ook al klinkt het wat raar)

[ Voor 24% gewijzigd door bille op 04-02-2005 15:16 ]

[Alarmnummer]

bille schreef op vrijdag 04 februari 2005 @ 15:06:
@Alarm.. hmm wellicht dat we elkaar niet goed begrepen ivm de context van de auto/kleur stelling. uiteraard ben ik het met je eens dat abstractie alleen moet worden toegepast daar het noodzakelijk is. MAAR aan de andere kant vind ik 'complexiteit' eigelijk geen argument omdat dat afhankelijk is van je IQ

Die van mij is net zo hoog als die van een kip en ik heb hetzelfde concentratie vermogen. Daarom wil ik ook simpele structuren en alleen complexiteit als het nodig is. Een ander nadeel aan extra complexiteit (naast de eerdere nadelen die ik al heb genoemd) is dat je al die ballast (want dat is alle code die geen praktische functionaliteit heeft) met je mee moet slepen. Even een aanpassing aan het systeem maken kost meer tijd... tijd kost geld...

[ Voor 5% gewijzigd door Alarmnummer op 04-02-2005 15:23 ]

[EfBe]

@Alarmnummâh: Het is gewoon set logica. Je hebt een grote bak met entities van type A, B en C. Je wilt daar een subset uit betrekken. Die subset definieer je dmv een filter.

Die filters maken kan lastig zijn, en het is dan makkelijk om een method te hebben die alle B's ophaalt voor een bepaalde A. Maar achter de schermen gebruikt hij gewoon de filter techniek om een set te definieren.

* EfBe , die ooit ook 75 scoorde op de nationale iq test (maar toen wel veel bier op had )

[drm]

EfBe:
Dat is maar net hoe je er naar kijkt.

Je hebt attributes, zoals customername, orderdate etc. Die hebben een relatie met elkaar en die noem je een entity. Zoals order, customer etc. Dan heb je relaties tussen attributes van verschillende entities, zoals order.customerid -> customer.customerid

Omdat attributes van verschillende entities die een relatie hebben met elkaar een relatie hebben met de andere attributes in de entity, spreek je van 'entity A heeft relatie met entity B'.

Nu heb je verschillende relatie typen:
1:1 (PK - FK/PK)
1:1 (PK - FK/UC)
1:1 (PK/FK - PK)
1:1 (FK/UC - PK)
1:n (PK - FK)
m:1 (FK - PK)

De n:1 en m:1 (en evt. daaruit volgende impliciete n:m relaties) spreken wel tot de verbeelding, maar de verschillen tussen 1:1 relaties ontgaan me een beetje:

1:1 (PK - FK/PK) (1)
1:1 (PK - FK/UC) (2)
1:1 (PK/FK - PK) (3)
1:1 (FK/UC - PK) (4)

Kan je de verschillen tussen deze relaties uitleggen? Misschien aan de hand van wat voorbeeldjes ofzo?

Ik denk dat 't verschil tussen (1) en (3) resp. (2) en (4) 'm zit in de richting waarop de relaties werken; en dat 't voorbeeld wat je geeft me de Departments en Employees een voorbeeld is van (2) (correct my if i'm wrong...), maar ik kan me niet zo veel voorstellen bij de anderen, eigenlijk

[EfBe]

1) en 3) heb je in inheritance models:

Employee 1:1 Manager 1:1 CEO
Manager's PK is ook EmployeeID en een FK naar Employee.EmployeeID. CEO heeft ook als PK EmployeeID en heeft een FK naar Manager.EmployeeID (die dus in deze niet als 'fk' optreedt, want dat is een andere relatie).

Je moet weten hoe de relatie ligt om te bepalen hoe je de related data ophaalt. Stel je hebt in je entity objects een method FetchByPK(...) en als er een UC is een FetchByUC<naam>(...). Dan is een related object via 1:1 aan de FK side met een UC niet te fetchen met <relatedInstance>.FetchByPK() want je moet de FetchByUC... gebruiken.