Databaserelaties

[Verwijderd]

Beste mensen,

ik volg een opleiding BI en hierbij krijgen we veel te maken met databases, later wil ik hier zeer waarschijnlijk ook iets mee gaan doen. Alleen heb ik ooit nog wat moeite met het analyseren van relaties,m.n. in welke tabellen er foreiyn keys voor moeten komen. Mijn vraag is nu eigenlijk hoe kijken jullie hier tegen aan en dus hoe analyseren jullie deze relaties. Doen jullie dat bijvoorbeeld met de kennis van SQL in je achterhoofd om zo te controleren of de relaties kloppen, of hebben jullie er andere methodes voor? Er zijn natuurlijk wel een aantal standaard regeltjes voor dat bijvoorbeeld de child de primary key van de parent als foreiyn key mee krijgt en een koppeltabel de primary keys van de twee verbonden tabellen, maar dit zal niet altijd in praktijk werken.

[P_de_B]

Dit zal wellicht niet altijd in de praktijk werken, maar dan zul je wel met praktijkvoorbeelden moeten komen.
Zie voor meer informatie over de algemene theorie: Wikipedia: Databasenormalisatie

[RobIII]

Als je eens begint met gewoon leren normaliseren? Toegegeven, als je het voor de honderdduizendste keer doet sla je wel wat stapjes over en schud je een "simpel DB'tje" zo wel uit je mouw maar voor complexe zaken blijft het net zo goed een must dan.

* RobIII mept P_de_B

[ Voor 16% gewijzigd door RobIII op 11-03-2010 15:04 ]

[Standeman]

Meestal begin je met het tekenen van een ERD en van daaruit ga je normaliseren en kijken naar de technische (DDL) implementatie.

[ Voor 6% gewijzigd door Standeman op 11-03-2010 15:07 ]

[gvdh]

Persoonlijk benader ik dit vanuit een objectgeoriënteerd standpunt. Wat hoort bij wat... Om dit te vertalen naar relaties tussen databasetabellen moet je meestal bij de child-tabel een verwijzing (foreign key) zetten naar de parent-tabel. Bij een veel-op-veelrelatie werk je inderdaad met een tussentabel die naar beide children verwijst.

[lier]

gvdh schreef op donderdag 11 maart 2010 @ 15:05:
Persoonlijk benader ik dit vanuit een objectgeoriënteerd standpunt. Wat hoort bij wat... Om dit te vertalen naar relaties tussen databasetabellen moet je meestal bij de child-tabel een verwijzing (foreign key) zetten naar de parent-tabel. Bij een veel-op-veelrelatie werk je inderdaad met een tussentabel die naar beide children verwijst.

Oei...nu schop je toch wel heel hard tegen twee compleet verschillende werelden...

Met alle respect, Object Orientatie en relationele databases hebben NIETS met elkaar te maken !

[Standeman]

Nou, niets... Als je je regelmatig bezighoud met ORM, hebben ze heel veel met elkaar te maken

Wat gvdh bedoeld is dat hij het relationele model uit zijn object model haalt. Iets wat ik zelf ook wel vaak doe, maar lang niet altijd (SQL-wise) de meest efficiente oplossing is. Zaken als multipliciteit kan je vaak wel direct uit je OO model halen.

[ Voor 65% gewijzigd door Standeman op 11-03-2010 15:19 ]

[gvdh]

lier schreef op donderdag 11 maart 2010 @ 15:10:
[...]

Oei...nu schop je toch wel heel hard tegen twee compleet verschillende werelden...

Met alle respect, Object Orientatie en relationele databases hebben NIETS met elkaar te maken !

Natuurlijk weet ik dat het twee verschillende werelden zijn, maar ze zijn wel gerelateerd aan elkaar. Ze zijn allebei aanwezig in een project waarin OO gebruikt wordt. (En zoals Standeman zegt, bij ORM worden ze op elkaar gemapt)
Persoonlijk vind ik het het aangenaamst om te vertrekken vanuit een objectgeoriënteerd domeinmodel. Dit geeft mij een goed beeld van de context. Van hieruit kan ik, met normalisatie in het achterhoofd, een degelijk databaseschema tekenen, van waaruit ik verder nadenk over performantie en dergelijke.

[Verwijderd]

Dit bedoel ik met ERD's maken en normaliseren maar ooit moet je dan nog ooit logisch tegen het datamodel aan kijken om de relaties goed te leggen, dit vind ik ooit wat lastig. Je moet in de praktijk ook een logisch beeld hebben van het datamodel, dit vind ik ooit wat lastig. Normaliseren is aanvankelijk ook standaard stappen volgen, dit zal ik praktijk toch ook niet altijd werken? (dit zal ook deels ervaring zijn denk ik)

[Janoz]

Normaliseren werkt in de praktijk uitstekend. Het is een stappenplan die je automatisch naar een goede oplossing leidt. Meer ervaren analisten zullen veel stappen overslaan en automatisch al bij een 3e normaalvorm uitkomen.

Relaties is het probleem niet. Daar zijn er maar 3 van. 1:1, 1:n en n:m. Voor elk van die drie is er de standaard oplossing (respectievelijk 1 tabel, een FK en een koppeltabel). Juist het identificeren van je entiteiten is belangrijk. Relaties volgen daar eigenlijk zo goed als automatisch uit.

De enige lastigheid die ik in de praktijk tegen kom is dat de gebruikers zelf eigenlijk geen idee hebben van hun eigen gegevens. De grootste valkuil blijft dat gebruikers vinden dat 'nooit' hetzelfde is als 'komt zo goed als bijna nooit voor', maar daar prik je over het algemeen met de juiste vragen ook wel doorheen.

Tot slot. Volgens mij ben je nogal wat gortig met 'ooit' aan het rondstrooien geweest in je reactie. Dat maakt het er niet echt veel duidelijker op.

[ Voor 17% gewijzigd door Janoz op 11-03-2010 15:56 ]

[Grijze Vos]

Ik zie niet in waarom die standaard regeltjes "in de praktijk" niet zullen werken. Sterker nog, ik laat tegenwoordig mijn keys genereren als ik een datamodel heb opgezet.

[Verwijderd]

Janoz schreef op donderdag 11 maart 2010 @ 15:53:
Normaliseren werkt in de praktijk uitstekend. Het is een stappenplan die je automatisch naar een goede oplossing leidt. Meer ervaren analisten zullen veel stappen overslaan en automatisch al bij een 3e normaalvorm uitkomen.

Relaties is het probleem niet. Daar zijn er maar 3 van. 1:1, 1:n en n:m. Voor elk van die drie is er de standaard oplossing (respectievelijk 1 tabel, een FK en een koppeltabel). Juist het identificeren van je entiteiten is belangrijk. Relaties volgen daar eigenlijk zo goed als automatisch uit.

De enige lastigheid die ik in de praktijk tegen kom is dat de gebruikers zelf eigenlijk geen idee hebben van hun eigen gegevens. De grootste valkuil blijft dat gebruikers vinden dat 'nooit' hetzelfde is als 'komt zo goed als bijna nooit voor', maar daar prik je over het algemeen met de juiste vragen ook wel doorheen.

Tot slot. Volgens mij ben je nogal wat gortig met 'ooit' aan het rondstrooien geweest in je reactie. Dat maakt het er niet echt veel duidelijker op.

Bedankt voor je antwoord, nu ik mijn laatste bericht na lees komt het inderdaad wat onduidelijk over.

[cariolive23]

Standeman schreef op donderdag 11 maart 2010 @ 15:15:
Nou, niets... Als je je regelmatig bezighoud met ORM, hebben ze heel veel met elkaar te maken

ORM staat dan ook voor Object Relationele Mismatch... Databases die voor iedere poep of scheet van de applicatie worden overspoeld met overbodige queries, performance killers en nog meer van dit soort onzin. Wat een database normaal gesproken in één keer doet, mag 'ie nu ineens in 25000 keer gaan doen. En dan zijn er nog mensen die het raar vinden dat de boel langzaam wordt

Wanneer performance niet noodzakelijk/gewenst is, dan is ORM prachtig, maar anders is het een blok aan je been.

[Standeman]

Je moet natuurlijk wel weten waar, hoe en wanneer je het toepast. Als je zomaar lukraak gaat zitten mappen en niet nadenkt over de consequenties en impact die het heeft, gaat het hartstikke fout natuurlijk.

Mijn inziens ligt dat meer aan de ontwikkelaar dan aan ORM. Een kwestie van de juiste methodieken en tooling kiezen.

Overigens, nu wordt met ORM tools zoals hibernate bedoeld. Maar in principe doet elk OO gebaseerde applicatie wat tegen een DBMS praat aan ORM

[ Voor 20% gewijzigd door Standeman op 12-03-2010 08:47 ]

[321X]

Mocht je moeite hebben met het maken van bijvoorbeeld een ERD of het bepalen van de relaties dan kan je eens kijken naar FCO-IM. Dit is een FOM (Fact Oriented Modeling) methodiek.

FCO-IM helpt je bij het normaliseren van je database, gebasseerd op feiten.

Bijvoorbeeld:
Garage AutoVandaag verkoopt auto's van het merk Volvo
Garage Total Cars verkoopt auto's van het merk BMW en Mini
Garage Kat in je bak verkoopt auto's van het merk Volvo en Volkswagen

FCO-IM helpt je dan stap voor stap om tot het model te komen waarbij je een tabel krijgt met garages, auto merken en een koppeltabbel voor de koppeling tussen die twee.

Hoe meer uitspraken / feiten je voorhanden hebt hoe nauwkeuriger jouw model kan worden.

URL: Wikipedia: FCO-IM, http://www.google.nl/search?q=fco-im

Ik vind het een leuke manier om een database op te zetten en het werkt ook echter gebruik ik het zelf niet, ERD is meer mijn ding omdat ik redelijk eenvoudig de vertaling van wensen/eisen naar datastructuur kan maken.

[ Voor 15% gewijzigd door 321X op 12-03-2010 08:49 ]

[Janoz]

cariolive23 schreef op donderdag 11 maart 2010 @ 23:11:
[...]

ORM staat dan ook voor Object Relationele Mismatch... Databases die voor iedere poep of scheet van de applicatie worden overspoeld met overbodige queries, performance killers en nog meer van dit soort onzin. Wat een database normaal gesproken in één keer doet, mag 'ie nu ineens in 25000 keer gaan doen. En dan zijn er nog mensen die het raar vinden dat de boel langzaam wordt

Wanneer performance niet noodzakelijk/gewenst is, dan is ORM prachtig, maar anders is het een blok aan je been.

Afaik staat de M niet voor mismatch, maar voor mapping. En als je die mapping niet goed doet heb je inderdaad een performance killende mismatch. Maar het is nu eenmaal niet vreemd dat je brakke software krijgt wanneer je je werk slecht doet.

[RobIII]

Janoz schreef op vrijdag 12 maart 2010 @ 08:59:
[...]

Afaik staat de M niet voor mismatch, maar voor mapping.

Sarcasm detectortje kopen?

[Janoz]

Ik wilde gewoon even het statement 'ORM is bad' ontkrachten. Dat is namelijk onzin.

[EfBe]

Janoz schreef op vrijdag 12 maart 2010 @ 08:59:
[...]

Afaik staat de M niet voor mismatch, maar voor mapping. En als je die mapping niet goed doet heb je inderdaad een performance killende mismatch. Maar het is nu eenmaal niet vreemd dat je brakke software krijgt wanneer je je werk slecht doet.

De genoemde 'performance problemen' heb je met iedere data-access code, het is nl. niet gerelateerd aan de mapping, maar aan het gebruik van lazy loading (SELECT N+1 problem), diepe inheritance hierarchien (joins met alle subtype tables) etc. die voor problemen KUNNEN zorgen. Verder zijn er met andere methoden zoals stored procedures weer andere problemen op het gebied van performance (bv op het gebied van update DML)

Een DBA zou niet TEGEN het team moeten werken maar MET het team (ze werken tenslotte bij hetzelfde bedrijf) en het team moeten adviseren met profiles/advies en ook bv welke queries gebruikt gaan worden zodat de dba daar op in kan springen met de-normalisaties/indexed views, indexes etc.

Pruttelen dat het allemaal zo slecht en traag is, tja. De concurrentie die het wel op orde heeft lacht er om, echt.

[Janoz]

De genoemde 'performance problemen' heb je met iedere data-access code,

Klopt

het is nl. niet gerelateerd aan de mapping, maar aan het gebruik van lazy loading (SELECT N+1 problem), diepe inheritance hierarchien (joins met alle subtype tables) etc. die voor problemen KUNNEN zorgen.

Begrijp me niet verkeerd. Ik ben het volledig met je eens. Maar vaak steken de lazy loading en de N+1 selects de kop op wanneer je niet goed oplet bij de implementatie van de datalaag die er voor zorgt dat de gegevens uit je relationele database in je object georienteerde domein model terecht komen. Dat stuk noem ik (misschien ten onrechte) de 'mapping'.

[Wolfboy]

Bij elke fatsoenlijke ORM laag kan je gewoon opgeven wat je wel/niet wil inladen en of je wel/niet de diepere hierarchieen wil preloaden. Daar hoeft de performance overhead niet vandaan te komen.

Wat wel een probleem is... bij wat complexere queries met diepe hierarchieen kan het goed voorkomen dat je outerjoin op outerjoin op outerjoin doet wat al snel duizenden rijen als resultaten gaat geven. Het verwerken daarvan is natuurlijk zwaar voor je ORM systeempje. Maar nog steeds is het allemaal prima te regelen en te optimaliseren.

[roy-t]

Janoz schreef op vrijdag 12 maart 2010 @ 08:59:
[...]

Afaik staat de M niet voor mismatch, maar voor mapping. En als je die mapping niet goed doet heb je inderdaad een performance killende mismatch. Maar het is nu eenmaal niet vreemd dat je brakke software krijgt wanneer je je werk slecht doet.

Een goed ORM model mapt altijd naar een volledige genormaliseerde database, wat meestal juist inhoud dat je minder queries moet doen.

* roy-t haalt Object Role Modelling en Object Relational Mapping weer door elkaar. Hoewel Object Role Modelling wel een tip is voor de TS trouwens .

[ Voor 14% gewijzigd door roy-t op 12-03-2010 11:07 ]

[Janoz]

--Edit-- Ja, als je doorstreept dan is mijn reactie ook niet meer relevant

Zoals Wolfboy ook al aangeeft zul je altijd nog wel wat tweaking willen gebruiken. In sommige gevallen weet je dat je altijd alles terug vraagt waardoor lazy loading duur wordt. Bij grote sets wil je in je datalaag code waarschijnlijk al code opnemen voor het pagineren ipv eerst de hele lijst op te halen en daar vervolgens een subset van nemen.

[ Voor 10% gewijzigd door Janoz op 12-03-2010 11:09 ]

[cariolive23]

EfBe schreef op vrijdag 12 maart 2010 @ 09:34:
[...]

De genoemde 'performance problemen' heb je met iedere data-access code, het is nl. niet gerelateerd aan de mapping, maar aan het gebruik van lazy loading (SELECT N+1 problem), diepe inheritance hierarchien (joins met alle subtype tables) etc. die voor problemen KUNNEN zorgen. Verder zijn er met andere methoden zoals stored procedures weer andere problemen op het gebied van performance (bv op het gebied van update DML)

Een DBA zou niet TEGEN het team moeten werken maar MET het team (ze werken tenslotte bij hetzelfde bedrijf) en het team moeten adviseren met profiles/advies en ook bv welke queries gebruikt gaan worden zodat de dba daar op in kan springen met de-normalisaties/indexed views, indexes etc.

Pruttelen dat het allemaal zo slecht en traag is, tja. De concurrentie die het wel op orde heeft lacht er om, echt.

Wie zegt dat de DBA tegen het team werkt? En sterker nog, de DBA wordt met problemen/foute keuzes in de data access code opgezadeld die hij/zij helemaal niet heeft veroorzaakt, laat staan kan oplossen.

En waarom er direct weer iets geroepen wordt over de-normalisatie, is mij ook een raadsel. Dat is niet meer dan symptoombestrijding, geen oplossing. Het kan juist weer voor nieuwe problemen zorgen.

Hét team, dus programmeurs en dba's, zullen samen moeten kijken welke data ze nodig hebben, hoe ze deze data opvragen en hoe ze dat zo snel mogelijk kunnen doen. Probleem blijft de ORM, met SQL kun je redelijk inschatten hoe een query door de database wordt uitgevoerd, met ORM is het altijd maar afwachten welke SQL wordt opgesteld, je hebt er minder controle over. En omdat je ook niet 100% zeker weet hoe een query wordt uitgevoerd, wordt de voorspelbaarheid van de performance er dus niet beter op. Verbeteren van code wordt dan ook lastiger, je hebt geen garantie dat een aanpassing daadwerkelijk een verbetering is.

Database optimizers zitten dicht op de data en hebben kennis van deze data, hier kan het queryplan op worden afgestemd. De ORM laag heeft deze kennis niet en kan dus heel eenvoudig verkeerde keuzes maken, het maken van de juiste keuze is zonder deze informatie vrijwel onmogelijk. Het is aan het ontwikkelteam om een patroon te bedenken dat voor álle situaties redelijk werkt. Het kan onmogelijk goed werken, daarvoor ontbreekt gedetailleerde informatie over de data.

Maar wijzen naar een DBA-er die geen enkel probleem heeft veroorzaakt? Beetje vreemde zaak. Ook geen situatie die ik ken uit de praktijk, ik word eerder gezien als redder in nood dan als tegenwerkende partij.

[Standeman]

cariolive23 schreef op vrijdag 12 maart 2010 @ 11:58:
[...]

Maar wijzen naar een DBA-er die geen enkel probleem heeft veroorzaakt? Beetje vreemde zaak. Ook geen situatie die ik ken uit de praktijk, ik word eerder gezien als redder in nood dan als tegenwerkende partij.

Het ligt er maar net aan welke DBA-er je hebt. De één denkt inderdaad mee met het ontwikkelteam om een zo goed mogelijk product voor de klant op een kosten-effectieve wijze neer te zetten. De ander ziet zijn database als een heilig huisje waar alles tot in de perfectie is getuned en waar helemaal niemand aan mag zitten. Die bij wijze van spreken al over de rooie gaat wanneer er 1 overbodige query wordt uitgevoerd. Zulke DBA-ers zien de database als doel en niet als middel.

Ik heb beide mogen meemaken, misschien dat EfBe alleen met de laatste te maken heeft gehad.

In mijn ogen is de bedoeling bij de ontwikkeling van een systeem om op een kosteffectieve wijze een zo goed mogelijk resultaat te behalen. Als dat betekend dat x% van de queries overbodig zijn of er aantal zijn die 200ms langer duren, so be it.

Het grote voordeel van een ORM laag is dat het een stuk beter te onderhouden is dan handgetypte SQL.

Maar we gaan nu wel way off-topic

[ Voor 5% gewijzigd door Standeman op 12-03-2010 12:23 ]

[EfBe]

cariolive23 schreef op vrijdag 12 maart 2010 @ 11:58:
[...]
Wie zegt dat de DBA tegen het team werkt? En sterker nog, de DBA wordt met problemen/foute keuzes in de data access code opgezadeld die hij/zij helemaal niet heeft veroorzaakt, laat staan kan oplossen.

De DBA werkt soms tegen het team, vooral wanneer de DBA denkt dat de 'D' in DBA voor developer staat en hij/zij even is vergeten dat de primaire taak van de DBA een administrator is, niet een developer.

Als jij als DBA loopt te miepen dat je met foute queries wordt opgezadeld dan moet je het developmentteam consulteren dat ze het wellicht anders moeten doen, m.a.w. helpen. En met iedere O/R mapper die een beetje goed in elkaar steekt is er altijd wel een mogelijkheid te vinden waardoor EN de queries supersnel gaan EN er ook nog minder queries worden uitgevoerd.

Hét team, dus programmeurs en dba's, zullen samen moeten kijken welke data ze nodig hebben, hoe ze deze data opvragen en hoe ze dat zo snel mogelijk kunnen doen. Probleem blijft de ORM, met SQL kun je redelijk inschatten hoe een query door de database wordt uitgevoerd, met ORM is het altijd maar afwachten welke SQL wordt opgesteld, je hebt er minder controle over. En omdat je ook niet 100% zeker weet hoe een query wordt uitgevoerd, wordt de voorspelbaarheid van de performance er dus niet beter op. Verbeteren van code wordt dan ook lastiger, je hebt geen garantie dat een aanpassing daadwerkelijk een verbetering is.

Als doorgewinterde O/R mapper bouwer kan ik zeggen dat je bewering onzin is. Je weet nl. altijd welke queries uitgevoerd worden, dat is niet iets van 'laten we hopen dat', het is een deterministisch proces.

Database optimizers zitten dicht op de data en hebben kennis van deze data, hier kan het queryplan op worden afgestemd. De ORM laag heeft deze kennis niet en kan dus heel eenvoudig verkeerde keuzes maken, het maken van de juiste keuze is zonder deze informatie vrijwel onmogelijk. Het is aan het ontwikkelteam om een patroon te bedenken dat voor álle situaties redelijk werkt. Het kan onmogelijk goed werken, daarvoor ontbreekt gedetailleerde informatie over de data.

Ook hier geldt: onzin. Tuurlijk, de O/R mapper core heeft geen statistics bij de hand, maar dat is ook niet nodig. Immers: de DBA die de stored procedure schrijft als alternatief (want alleen zeuren zonder alternatief te benoemen is gewoon zeuren) heeft die statistics ook niet wanneer de proc wordt geschreven. Aangezien o/r mapper queries deterministic naar dezelfde SQL leiden (op dyn. tweaking na, maar dat is altijd in je voordeel!), en de DBA met dezelfde kennis queries schrijft, is de optimizer alleen van nut at runtime, met statistics over de data, en die optimizet dan zowel de parameterized queries uit de o/r mapper als de proc sql. Exact hetzelfde.

Verder kan ik zo voorbeelden verzinnen waarbij de O/R mapper wel queries kan optimizen en de DBA met zn procs niet. Ergo: geloof me, je moet je echt wat meer verdiepen in de materie.

Maar wijzen naar een DBA-er die geen enkel probleem heeft veroorzaakt? Beetje vreemde zaak. Ook geen situatie die ik ken uit de praktijk, ik word eerder gezien als redder in nood dan als tegenwerkende partij.

Ik ken talloze gevallen waarbij DBAs alle mogelijke onzinnige myths en kolder uit de kast halen om maar gelijk te krijgen. Immers, het interesseert ze vaak geen reet of developers hun applicatie niet kunnen maken omdat de DBA tegenwerkt, ze zitten immers vaak niet bij het team.

[cariolive23]

Aangeven dat je het ergens niet mee eens bent kan wel op een iets volwassener manier

[ Voor 71% gewijzigd door Janoz op 12-03-2010 22:44 ]

[EfBe]

Cariolive23: neem het niet persoonlijk op, joh, niemand beschuldigt jou van nalatigheid of wat voor ellende dan ook. Databases en hoe je er mee werkt is een mijnenveld van heilige huisjes en iedereen heeft wel een mening en die is in andermans ogen vaak onzinnig/irrealistisch.

Op deze aardbol is het groepje mensen dat een succesvol O/R mapping systeem heeft ontworpen en gebouwd niet erg groot. Ik verwacht dan ook niet dat massa's mensen precies begrijpen hoe deze systemen werken, omdat ze niet betrokken zijn bij de bouw ervan en dus de specialistische kennis missen. Dat is helemaal niet erg, immers, we kunnen niet alles weten en als je tijd besteedt om X te leren kun je niet tegelijkertijd Y leren.

Als je het ergens niet mee eens bent mbt o/r mapping en ik leg het uit, zie dat dan niet als een persoonlijke aanval maar als een opmerking van iemand die al jaren full time werkt aan dit soort systemen en de specialistische kennis wel heeft. Zie het ook niet als 'hoe jij werkt is ruk, je moet het zo doen', dat is nl. niet mijn bedoeling noch mijn intentie. Ik voer al jaren deze discussie en ik snap waar deze vandaan komt: ontwikkelaar ontbeert iedere kennis omtrent databases en denkt dat die er niet toe doen vs. DBA die aan de ene kant zn werk beknot zit worden (SQL wordt gegenereerd) en aan de andere kant de onmogelijke taak heeft de troep op te ruimen van de ontwikkelaar die maar raak queriet.

Als beide kanten nou eens aan elkaar uitleggen wat ze willen en wat de ander nodig heeft, is het veelal binnen no-time opgelost. Ja, met O/R mapping.

[EfBe]

Laat ik ook eens antwoord geven op het topic van deze thread, tenslotte het topic

Verwijderd schreef op donderdag 11 maart 2010 @ 14:57:
Beste mensen,
ik volg een opleiding BI en hierbij krijgen we veel te maken met databases, later wil ik hier zeer waarschijnlijk ook iets mee gaan doen. Alleen heb ik ooit nog wat moeite met het analyseren van relaties,m.n. in welke tabellen er foreiyn keys voor moeten komen. Mijn vraag is nu eigenlijk hoe kijken jullie hier tegen aan en dus hoe analyseren jullie deze relaties. Doen jullie dat bijvoorbeeld met de kennis van SQL in je achterhoofd om zo te controleren of de relaties kloppen, of hebben jullie er andere methodes voor? Er zijn natuurlijk wel een aantal standaard regeltjes voor dat bijvoorbeeld de child de primary key van de parent als foreiyn key mee krijgt en een koppeltabel de primary keys van de twee verbonden tabellen, maar dit zal niet altijd in praktijk werken.

Het moet wel zo werken iedere andere benadering is niet een juiste projectie.

Je moet wel 'parent' en 'child' loslaten, want er is geen hierarchie, maar alleen een aantal entities met relaties. Het concept 'FK constraint' is puur uit referential integrity oogpunt geimplementeerd: Op table niveau (== projectie resultaat van abstract entity model op relational schema): Order heeft een relatie met Customer, en dat geef je aan door de identifying attribute(s) van Customer (de 'pk') op te nemen in Order. Om te voorkomen dat de data inconsistent wordt, en dus dat je bv een waarde voor de customer 'pk' velden in Order kunt plaatsen waar geen bestaande customer mee wordt geidentificeerd, zijn er referential integrity constraints bedacht, een constraint dus die voorschrijft dat een waarde in een FK field een gerelateerde row (== entity instance) identificeert.

Op het niveau van het abstract entity model (bv op het niveau van NIAM/ORM (object role modeling), zie www.orm.net) heeft de 'fk' side van een relatie geen 'fk fields', oftewel de identifying attributes van de pk side zijn niet gecopieerd in de fk side entity. Dit is louter een relational model constructie en zijn het gevolg van de projectie van een abstract entity model op het relational model, dus dat je van abstract entity definitions naar table definitions gaat met FK constraints, PK constraints, Unique constraints en als je wilt, check constraints.

Een 'm:n' relatie kun je op 2 manieren maken op relational model niveau: via een 'intermediate entity' of koppeltabel die 2 m:1 relaties met elkaar verbindt, of middels een join van twee sets over een join clause waarbij niet een unique (pk/uc) constraint wordt gebruikt. Dit geeft meteen aan dat een m:n relatie feitelijk een interpretatie is van of 2 m:1 relaties, of een interpretatie is van een set verkregen door het joinen over non-gerelateerde attributes en feitelijk dus readonly is.

Het abstract entity model kun je ook projecteren op code, bv classes in een OO taal. Hierbij kun je bv dicht bij het abstract entity model blijven en bv geen kopieen van de identifying attributes in de FK side entity representerende class op te nemen, of je kunt dat juist wel doen waardoor je dichter bij de sibling projectie blijft, nl. die op de relational model (de table structure). Je kunt ook extreem de OO kant opgaan en bv een relatie als fysiek object gaan zien, ipv een associatie tussen twee objects beschouwen als een relatie instantie.

O/R mapping is dan het mechanisme waarbij beide projecties gekoppeld worden zodat de instances aan beide kanten (class instance == object en table def instance == table) dezelfde betekenis geven aan de data die ze in zich dragen (de entity 'instance'). Het hangt dus van de gebruikte O/R mapper af of je bv aan de code-kant foreign key fields hebt of dat je bv myOrder.Customer.ID moet uitlezen om de Fk field 'CustomerId' voor een Order instance te weten te komen. Aan de relational model kant wordt het wat lastiger om FK fields te negeren, of FK constraints (wat soms gedaan wordt, om performance redenen, die IMHO ondergeschikt moeten zijn tov data integrity regels, immers als je data inconsistent is dan heb je er niets meer aan) niet toe te passen: immers ergens moet je opslaan bij welke customer een zekere order row behoort.

In extreme gevallen wordt dit in een 3de tabel geplaatst, bv wanneer het systeem de tabellen dynamisch moet kunnen aanpassen aan de wensen van de gebruiker, waardoor men vaak relationele informatie opslaat buiten de tabellen met de entity data. Niet aan te bevelen, want je bouwt feitelijk een database in een database, maar voor extreme gevallen (en een beperkte set tabellen) is het soms feitelijk de enige keuze.

Wellicht handig om je docent te vragen iets meer uit te leggen over Codd's systeem en de paper van Peter Chen omtrent entity models?
Peter Chen: The Entity-Relationship Model-Toward a Unified View of Data: http://www.csc.lsu.edu/news/erd.pdf
Edgar Codd: A Relational Model of Data for Large Shared Data Banks:
http://www.cs.nott.ac.uk/~nza/G51DBS/codd.pdf
Ik ben zelf erg gecharmeerd van T.A. Halpin's werk: http://www.orm.net