[Databases] Een ERD & LGS maken

[Verwijderd]

Ik heb de opdracht om uit volgende tekst een ERD (Entity Relationshop Diagram) en LGS (Logische Gegevens Structuur) te maken (voor studie). Heb het geprobeerd maar ik ben niet zeker of dit wel correct is. Zou fijn zijn als iemand eens ernaar kan kijken.

De tekst:

In een district bevindt zich een aantal bibliotheken. Deze maken gebruik van een centrale gegevensbank voor het rubriceren van titels van hun boeken en om uitlenen van boeken aan leden te administreren. De titels worden gerubriceerd per onderwerp, waarbij een titel onder meer dan een onderwerp kan worden opgenomen. Een bibliotheek kan van een titel meerdere exemplaren bezitten, deze worden afzonderlijk geadministreerd. Een lezer kan van verschillende titels een exemplaar lenen bij een of meer bibliotheken. Indien geen exemplaar aanwezig is, kan een boek gereserveerd worden. Een persoon kan pas een boek lenen als hij als lid is ingeschreven bij een van de bibliotheken.

Hierbij heb ik volgend LGS gemaakt:

District(districtID, naam, bibliotheekID)
Foreign Keys: Bibliotheek(bibliotheekID)
Bibliotheek(bibliotheekID, naam, adres, telefoonnummer, titelID)
Foreign Keys: Titel(titelID)
Titel(titelID, naam, schrijver, onderwerpID, exemplaarID)
Foreign Keys: Onderwerp(onderwerpID), Exemplaar(exemplaarID)
Onderwerp(onderwerpID, naam)
Foreign Keys: -
Exemplaar(exemplaarID, uitleningID)
Foreign Keys: Uitlening(uitleningID)
Uitlening(uitleningID, uitleendatum, retourdatum, lezerID)
Foreign keys: Lezer(lezerID)
Lezer(lezerID, naam, adres, telefoonnummer)
Foreign Keys: -

En dit ERD:

Ik weet bijvoorbeeld niet of "District" er wel bij moet, en of de relaties in het algemeen wel kloppen.

Alvast bedankt

[kasper_vk]

Verwijderd schreef op vrijdag 10 augustus 2007 @ 01:52:
... Heb het geprobeerd maar ik ben niet zeker of dit wel correct is. ...

Welke vragen/twijfels heb je zelf dan?


Als ik jouw diagram zo zie, komen er bij mij een paar vragen op:
- Van Bib. naar Titel heb je een 1-op-N relatie gemaakt; dit betekent dat een Titel maar in 1 bib aangeboden kan worden --> staat dat ook zo in je opdracht?
- Tussen Titel en Onderwerp hetzelfde: jij hebt een 1-op-N relatie gemodelleerd, maar zo kan er onder een Onderwerp maar 1 Boek geplaatst worden... niet erg handig voor een rubricering
- Ik zie deze eis niet terug in het model: "Indien geen exemplaar aanwezig is, kan een boek gereserveerd worden", toch?

Kortom: probeer jouw eigen diagram eens terug te vertalen naar de tekst: welke beperkingen heeft jouw model en kloppen die ook met de opdracht?
En andersom: ondersteunt jouw model wellicht situaties die niet gevraagd worden? (ik heb ze niet gezien, maar ik heb slechts heel kort gekeken)

[ Voor 20% gewijzigd door kasper_vk op 10-08-2007 08:43 ]

[EfBe]

Exemplaar - uitlening is volgens mij ook 1:1 en niet 1:n. (Uitlening is eigenlijk de objectified relation tussen exemplaar en uitlening.

En die attribute sets kloppen echt niet. Exemplaar heeft bv geen uitleningID, uitlening heeft een exemplaarid. Je hebt alle FK's bij de PK side staan, dat klopt niet. Bibliotheek heeft bv een districtid, maar districtid heeft geen bibliotheekid, immers dan zou de relatie district - bibliotheek m:1 moeten zijn

Makkelijke regel is om gewoon zinnen te maken eerst:
District heeft een of meerdere bibliotheken
Bibliotheek heeft een of meerdere boeken
boek heeft een titel
boek heeft een of meerdere onderwerpen
onderwerp kan verwoord zijn in een of meerdere boeken
boek heeft een of meerdere schrijvers
boek is 0 of 1 keer uitgeleend
lezer leent 1 of meerdere boeken

etc.

[ Voor 29% gewijzigd door EfBe op 10-08-2007 09:25 ]

[bat266]

Ik weet niet zeker of ik t goed lees maar uit:

District(districtID, naam, bibliotheekID)
Foreign Keys: Bibliotheek(bibliotheekID)
Bibliotheek(bibliotheekID, naam, adres, telefoonnummer, titelID)

maak ik op dat je per district een bibid bijhoudt. Hierdoor krijg je heel veel verschillende districten met 1 biblio. Volgens mij is het namelijk de bedoeling om bij een biblio een district te hebben.
kijk nog eens goed hoe je een 1 op n relatie moet modeleren

[ Voor 6% gewijzigd door bat266 op 10-08-2007 12:42 ]

[Verwijderd]

Bedankt voor de antwoorden! Heeft me al best veel geholpen
Ik heb het ERD & LGS wat aangepast. Het LGS klopte inderdaad niet, ik had de relaties "van de verkeerde kant" bekeken. Nu zou het dus wel moeten kloppen (heel voorzichtige uitspraak hier ). Dat met de reserveringen was ik vergeten, maar het staat er nu wel in.

LGS:

District(districtID, naam)
Foreign Keys: -
Bibliotheek(bibliotheekID, naam, adres, telefoonnummer, districtID)
Foreign Keys: District(districtID)
Titel(titelID, naam, schrijver, onderwerpID)
Foreign Keys: Onderwerp(onderwerpID)
Onderwerp(onderwerpID, onderwerpnaam)
Foreign Keys: -
Exemplaar(exemplaarID, titelID)
Foreign Keys: Titel(titelID)
Uitlening(uitleningID, uitleendatum, retourdatum, lezerID, exemplaarID)
Foreign keys: Lezer(lezerID), Exemplaar(exemplaarID)
Lezer(lezerID, naam, adres, telefoonnummer)
Foreign Keys: -
Reservering(reserveringID, datum, exemplaarID, lezerID)
Foreign Keys: Exemplaar(exemplaarID) Lezer(lezerID)

De relaties van het ERD zijn ook aangepast (naar aanleiding van wat jullie (terecht) opgemerkt hebben).

ERD:


Even voor de duidelijkheid, hoe ik de relaties beredeneerd heb en waarom:
Een district heeft meerdere bibliotheken -> Dus, district heeft een 1:n relatie met bibliotheek. Wat dus betekent dat er in de bibliotheek-tabel in de kolom “districtID”, in verschillende rijen dezelfde districtID kan voorkomen.
Als het een 1:1 relatie zou zijn, zou één districtID ook alleen maar één keer kunnen voorkomen in de kolom districtID van bibliotheek. Klopt dit?

Bibliotheek heeft een of meer titels, en een titel is te verkrijgen in een of meer bibliotheken. Dus dit zou betekenen, dat deze twee entiteitstypen een n:m relatie zouden hebben. Maar nu heb ik gelezen, dat n:m relaties vermeden moeten worden. Zou ik dan hier niet een tussentabel moeten maken, met twee 1:n relaties? Hoe zou deze er dan uitzien; Verdeling(bibliotheekID, titelID)?
Hetzelfde dan dus voor titel en onderwerp. Of niet?

Moet/kan je eigenlijk wel alle n:m relaties uitelkaar halen? Je kunt ze toch ook gewoon laten staan, ik zie hier geen probleem in eigenlijk.

Exemplaar - uitlening is volgens mij ook 1:1 en niet 1:n. (Uitlening is eigenlijk de objectified relation tussen exemplaar en uitlening.

Wat is een objectified relation?

[dusty]

Stel : Een geschiedenis boek over hitler in de tweede wereld oorlog?

welke categorie prop jij dat boek? Geschiedenis? Tweede wereld oorlog? Biografie?

In je huide opzet kan je dus een boek maar in slechts een onderwerp gooien, terwijl een boek vaak juist in meerdere onderwerpen thuishoort.

Daarnaast, stel een boek is populair en de bibliotheek heeft 2 exemplaren. Beiden zijn uitgeleend, nu wilt iemand het boek reserveren, Welk examplaar wordt gereserveerd?

Ik neem ook aan dat als iemand zichzelf heeft uitgeschreven deze geen boek meer mag lenen.

In je ERD zijn de titels gekoppeld aan de bibliotheken, Dus exemplaar X heeft titelid: 1 , bibliotheken A en B hebben een boek met de titelid:1 dus wie is eigenaar van exemplaar X? Los dit probleem op en je zult ook geen n:m relatie daarbij hebben.

toevoeging: Ik zie in jouw ERD diagram de reservering alleen gelinkt is aan het lid? Dus als ik jou vertel dat persoon A drie boeken heeft gereserveerd, en er een van de drie boeken binnen is kan jij mij vertellen welke boek dat is als ik je alleen zijn lezerID geeft? of mis je toch wat "RELATIES" binnen je diagram?

[ Voor 16% gewijzigd door dusty op 10-08-2007 19:22 ]

[Verwijderd]

dusty schreef op vrijdag 10 augustus 2007 @ 19:19:
Stel : Een geschiedenis boek over hitler in de tweede wereld oorlog?

welke categorie prop jij dat boek? Geschiedenis? Tweede wereld oorlog? Biografie?

In je huide opzet kan je dus een boek maar in slechts een onderwerp gooien, terwijl een boek vaak juist in meerdere onderwerpen thuishoort.

Titel heeft toch nu een n:m relatie met Onderwerp? Dus kan ik een boek toch in meerdere onderwerpen zetten?

Daarnaast, stel een boek is populair en de bibliotheek heeft 2 exemplaren. Beiden zijn uitgeleend, nu wilt iemand het boek reserveren, Welk examplaar wordt gereserveerd?

Het exemplaar dat als eerste weer terugkomt. Maar dat wordt toch dan bij het reserveren gedaan? Een sql-command dat het betreffende exemplaar eruithaald (dichtsbijzijnde retourdatum).

Ik neem ook aan dat als iemand zichzelf heeft uitgeschreven deze geen boek meer mag lenen.

Ja, dat is toch weer gewoon een sql-command om de lezer uit de database te deleten? Wat heeft dit dan met het ERD te maken?

In je ERD zijn de titels gekoppeld aan de bibliotheken, Dus exemplaar X heeft titelid: 1 , bibliotheken A en B hebben een boek met de titelid:1 dus wie is eigenaar van exemplaar X? Los dit probleem op en je zult ook geen n:m relatie daarbij hebben.

toevoeging: Ik zie in jouw ERD diagram de reservering alleen gelinkt is aan het lid? Dus als ik jou vertel dat persoon A drie boeken heeft gereserveerd, en er een van de drie boeken binnen is kan jij mij vertellen welke boek dat is als ik je alleen zijn lezerID geeft? of mis je toch wat "RELATIES" binnen je diagram?

Hm.. da's een idee

[dusty]

Verwijderd schreef op vrijdag 10 augustus 2007 @ 19:37:
[...]

Titel heeft toch nu een n:m relatie met Onderwerp? Dus kan ik een boek toch in meerdere onderwerpen zetten?

JIj zei:

Titel(titelID, naam, schrijver, onderwerpID)
Foreign Keys: Onderwerp(onderwerpID)

Dus volgens je LGS is er per titelID maar EEN onderwerp.

[...]
Het exemplaar dat als eerste weer terugkomt. Maar dat wordt toch dan bij het reserveren gedaan? Een sql-command dat het betreffende exemplaar eruithaald (dichtsbijzijnde retourdatum).
[...]

Exemplaar A en B hebben dezelfde titels ed,

Exemplaar A wordt uitgeleend op dag 1,
Exemplaar B wordt uitgeleend op dag 2,
Boek wordt gereserveerd op dag 3 ( volgens jouw systeem wordt dus Exemplaar A gereserveerd)
Exemplaar B wordt teruggebracht op dag 4, de lezer vond het een slecht boek en wilde het niet meer lezen.

Betekent dus dat Exemplaar B beschikbaar is maar de de persoon die het heeft gereserveerd moet wachten tot Exemplaar A wordt teruggebracht?

Ja, dat is toch weer gewoon een sql-command om de lezer uit de database te deleten? Wat heeft dit dan met het ERD te maken?
[...]

historische data?

[Verwijderd]

dusty schreef op vrijdag 10 augustus 2007 @ 19:44:
[...]

JIj zei:

[...]

Dus volgens je LGS is er per titelID maar EEN onderwerp.

[...]

hmm, Ik neem dus aan dat je de ID niet meerdere keren mag gebruiken? Dus zou je het attribuut "naam" van Onderwerp kunnen gebruiken als foreign key?

Exemplaar A en B hebben dezelfde titels ed,

Exemplaar A wordt uitgeleend op dag 1,
Exemplaar B wordt uitgeleend op dag 2,
Boek wordt gereserveerd op dag 3 ( volgens jouw systeem wordt dus Exemplaar A gereserveerd)
Exemplaar B wordt teruggebracht op dag 4, de lezer vond het een slecht boek en wilde het niet meer lezen.

Betekent dus dat Exemplaar B beschikbaar is maar de de persoon die het heeft gereserveerd moet wachten tot Exemplaar A wordt teruggebracht?

Ja klopt, maar dat staat niet in de tekst. Telt dit niet bij "eisen erbij verzinnen"?
Het kan bijvoorbeeld ook zijn dat het complete boekenasortiment van een bibliotheek afbrand, dat zou betekenen dat je een optionaliteit moet adden tussen Bibliotheek en Titel.

[...]

historische data?

Dat zou betekenen dat je in het LGS van Lezer een attribuut moet adden; bijvoorbeeld "ingeschreven". met als mogelijke waarden true of false. Of niet?

[Depress]

Verwijderd schreef op zaterdag 11 augustus 2007 @ 00:32:
[...]

hmm, Ik neem dus aan dat je de ID niet meerdere keren mag gebruiken? Dus zou je het attribuut "naam" van Onderwerp kunnen gebruiken als foreign key?

Wanneer het een primary key is niet. Die zijn meestal auto increment(sequenses). Dit is dan ook meestal het volg nummer van de row en hoort dus uniek te blijven.

Verwijderd schreef op zaterdag 11 augustus 2007 @ 00:32:
Dat zou betekenen dat je in het LGS van Lezer een attribuut moet adden; bijvoorbeeld "ingeschreven". met als mogelijke waarden true of false. Of niet?

Nee, dat wil niet perse zeggen dat je een extra atribuut moet maken. Wanneer je een datum veld hebt is het ook al historische data wanneer er een veld met een nieuwere datum inkomt te staan. Dit gewoon aan de hand van hoe jij je sql opbouwd en heeft verder niet echt veel te maken met de ERD, wel met de LSG overigens(meer atributen etc)

[ Voor 26% gewijzigd door Depress op 11-08-2007 00:39 ]

[dusty]

Verwijderd schreef op zaterdag 11 augustus 2007 @ 00:32:
[...]
hmm, Ik neem dus aan dat je de ID niet meerdere keren mag gebruiken? Dus zou je het attribuut "naam" van Onderwerp kunnen gebruiken als foreign key?
[...]

Naam als foreign key? Zou'k niet doen. Je kunt dit geheel oplossen met alleen de ID's. In dit geval dus een koppeltabel tussen de twee.

Ja klopt, maar dat staat niet in de tekst. Telt dit niet bij "eisen erbij verzinnen"?
Het kan bijvoorbeeld ook zijn dat het complete boekenasortiment van een bibliotheek afbrand, dat zou betekenen dat je een optionaliteit moet adden tussen Bibliotheek en Titel.
[...]

Misschien moet je niet een relatie zetten naar een specifiek exemplaar maar naar iets anders..

Dat zou betekenen dat je in het LGS van Lezer een attribuut moet adden; bijvoorbeeld "ingeschreven". met als mogelijke waarden true of false. Of niet?

Juist.

[kasper_vk]

Met betrekking tot de reserveringen discussie: stel jezelf eens de vraag: reserveer je een bepaald exemplaar, of een bepaalde titel?

En wat betreft de koppeling tussen Titel & Bibliotheek: je schreef zelf al dat je niet zo blij bent (/mag zijn) met een n-m relatie, maar ik vraag me af of een titel aan een bib is gekoppeld, of een exemplaar van een bepaalde titel?
Als je deze vraag (naar mijn idee) goed beantwoordt, ben je direct van je n-m relatie in je model af.

[Verwijderd]

Bedankt voor de reacties Ik heb het ERD (LGS later) naar aanleiding daarvan nog eens wat aangepast, en ik ben op het volgende gekomen:

Er zit een n:m relatie tussen, en mij is nog niet helemaal duidelijk hoezo die er eigenlijk uit moet, en of dat ook echt moet. Misschien kan iemand dat even in het kort uitleggen?

Edit: de entiteit District is eruit genomen omdat het hier maar om één district gaat, dus is District overbodig.

[ Voor 13% gewijzigd door Verwijderd op 17-08-2007 00:21 ]

[Alain]

Ik zou het anders bekijken. Je hebt in de basis 3 objecten: een lid, een bibliotheek en een boek.

Het lid doet een request naar de bibliotheek en de bibliotheek kijkt of het boek bestaat en beschikbaar is. In mijn ogen is het enige lastige dus: de bibliotheek. In de bibliotheek kun je dan een soort interface maken naar het lid.

Just my 2 cents.

[dusty]

Verwijderd schreef op vrijdag 17 augustus 2007 @ 00:20:
Bedankt voor de reacties Ik heb het ERD (LGS later) naar aanleiding daarvan nog eens wat aangepast, en ik ben op het volgende gekomen:
[afbeelding]
Er zit een n:m relatie tussen, en mij is nog niet helemaal duidelijk hoezo die er eigenlijk uit moet, en of dat ook echt moet. Misschien kan iemand dat even in het kort uitleggen?
[..]

Een titel kan meerdere onderwerpen hebben.
Een onderwerp kan meerdere titels bevatten.

Dus is je ERD inderdaad correct, het gaat dus hoe je de n:m relatie oplost in je LGS, wat je dus kan doen via een simpel koppeltabel.

[Verwijderd]

dusty schreef op vrijdag 17 augustus 2007 @ 03:06:
[...]

Een titel kan meerdere onderwerpen hebben.
Een onderwerp kan meerdere titels bevatten.

Dus is je ERD inderdaad correct, het gaat dus hoe je de n:m relatie oplost in je LGS, wat je dus kan doen via een simpel koppeltabel.

Moeten Uitlening-Exemplaar en Reservatie-Exemplaar niet 1:1 relaties zijn? Je hebt dan één exemplaar per uitlening, en dan meerdere uitleningen per lid
Als het een 1:n relatie is dan zou bij elke row van Exemplaar een uitleningID en reservatieID moeten zetten (die soms null zijn) wat niet echt zuiver is, lijkt me

[dusty]

Dat ligt aan je systeem, of je binnen een reservatie meerdere exemplaren kunt reserveren. Immers kan een bibliotheek meerdere exemplaren hebben van een titel. (Zie de reactie eerder van mij daarover, maar jij wilt perse een exemplaar reserveren met alle complicaties daarbij, in plaats van een specifieke titel)

Daarnaast moet je toch besluiten welke tabellen welke informatie linken naar de andere columns het lijkt mij sterk dat je een uitlening aanmaakt die aangeeft welke exemplaar je reserveert, en dan bij het exemplaar opslaat welke reservatie die book heeft gereserveerd.

[EfBe]

Verwijderd schreef op vrijdag 17 augustus 2007 @ 03:53:
[...]

Moeten Uitlening-Exemplaar en Reservatie-Exemplaar niet 1:1 relaties zijn? Je hebt dan één exemplaar per uitlening, en dan meerdere uitleningen per lid
Als het een 1:n relatie is dan zou bij elke row van Exemplaar een uitleningID en reservatieID moeten zetten (die soms null zijn) wat niet echt zuiver is, lijkt me

Je moet niet op tabel niveau gaan lopen knoeien, EERST boven water krijgen hoe X relateert aan Y. Als jij je afvraagt of Uitlening - Exemplaar een 1:1 relatie zou moeten zijn, dan moet je je afvragen waarom je niet de zinnen hebt opgeschreven:
uitlening kan meerdere exemplaren bevatten
exemplaar kan meerdere keren worden uitgeleend.

Die lijken me onzin, dus is de relatie 1:1 (ik schrijf niet de rest van de zinnen op maar het lijkt me duidelijk). Ook is de relatie uitlening - lid 1:1, want UITLENING is een entity die een relatie bevat, nl. de relatie lid-exemplaar: Uitlening is een objectified relation Dit houdt in dat je eigenlijk de relatie hebt: Exemplaar - Lid, maar AAN die relatie wil je attributes hangen, bv uitleendatum. Je maakt dan een nieuwe entity aan en hangt daar de attributes aan voor die relatie, dus uitleendatum. Zie: http://www.orm.net voor meer details hierover.

[Verwijderd]

EfBe schreef op vrijdag 17 augustus 2007 @ 09:32:
[...]

Je moet niet op tabel niveau gaan lopen knoeien, EERST boven water krijgen hoe X relateert aan Y. Als jij je afvraagt of Uitlening - Exemplaar een 1:1 relatie zou moeten zijn, dan moet je je afvragen waarom je niet de zinnen hebt opgeschreven:
uitlening kan meerdere exemplaren bevatten
exemplaar kan meerdere keren worden uitgeleend.

Die lijken me onzin, dus is de relatie 1:1 (ik schrijf niet de rest van de zinnen op maar het lijkt me duidelijk). Ook is de relatie uitlening - lid 1:1, want UITLENING is een entity die een relatie bevat, nl. de relatie lid-exemplaar: Uitlening is een objectified relation Dit houdt in dat je eigenlijk de relatie hebt: Exemplaar - Lid, maar AAN die relatie wil je attributes hangen, bv uitleendatum. Je maakt dan een nieuwe entity aan en hangt daar de attributes aan voor die relatie, dus uitleendatum. Zie: http://www.orm.net voor meer details hierover.

Ik snap wel dat je in het begin wat abstracter moet denken, maar als het LGS gemaakt moet worden MOET je wel op tabellenniveau gaan denken.

Heb overigens nog een opdracht gemaakt;

Binnen een bedrijf worden projecten uitgevoerd. Een project omvat een aantal standaard activiteiten zoals analyse, ontwerp, bouw, testen enz.. Voor iedere standaard activiteit is de prijs per uur vastgesteld. Werknemers kunnen worden ingezet voor een of meerdere activiteiten. Van elke activiteit wordt van iedere werknemer het aantal uren bepaald dat hij kan worden ingezet. Op het moment dat een activiteit gepland wordt, behoeft nog niet vast te staan welke werknemer de leiding krijgt.

LGS:

Project(projectID, naam)
Activiteit(activiteitID, soort, prijsperuur)
Planning(planningID, projectID, activiteitID)
FK: Project(projectID), Activiteit(activiteitID)
Medewerker(medewerkerID, naam, adres, telefoonnummer)
Rooster(roosterID, datum, tijd, urenwerknemer, planningID, medewerkerID, medewerkerID_leiding)
FK: Medewerker(medewerkerID), Planning(planningID)
medewerkerID_leiding -> Medewerker(medewerkerID)

ERD:


Bij het dikgedrukte in het LGS ben ik niet zeker of dit zo wel kan (de notatie). Voor de rest weet ik niet of "Op het moment dat een activiteit gepland wordt, behoeft nog niet vast te staan welke werknemer de leiding krijgt." gewoon een nullable attribuut (medewerkerID_leiding) is, of dat er iets in het ERD voor moet worden veranderd.
Of het geheel eigenlijk klopt weet ik trouwens ook niet zeker

Bedankt alvast

[dusty]

Dus per datum, tijd, werknemer en planning kan de leidinggevende verschillen. Dat betekent in principe dus dat iedereen een leider kan zijn over de andere medewerkers Op zich een Interessante stelling in je LGS/ERD

[Verwijderd]

dusty schreef op zaterdag 18 augustus 2007 @ 19:33:
Dus per datum, tijd, werknemer en planning kan de leidinggevende verschillen. Dat betekent in principe dus dat iedereen een leider kan zijn over de andere medewerkers Op zich een Interessante stelling in je LGS/ERD

Denk je dan dat dit een "fout" is? Hoe zou je het dan oplossen?

[dusty]

Laat ik het met een vraag oplossen; Hoeveel leiders zijn er per project?

[Verwijderd]

dusty schreef op zondag 19 augustus 2007 @ 02:57:
Laat ik het met een vraag oplossen; Hoeveel leiders zijn er per project?

Volgens de opdracht één. Maar dit kun je toch ook als constraint vastleggen?

[Verwijderd]

update: tentamen gemaakt, cijfer 8.5. bedankt voor de hulp

[EfBe]

Verwijderd schreef op dinsdag 21 augustus 2007 @ 19:05:
update: tentamen gemaakt, cijfer 8.5. bedankt voor de hulp

Maar... elementaire kennis ontbreekt, je komt nl. met vragen die iemand die een 8.5 scoort op dit vak toch wel moet kunnen beantwoorden lijkt me. "Op het moment dat een activiteit gepland wordt, behoeft nog niet vast te staan welke werknemer de leiding krijgt." zegt dat de relatie niet mandatory is. Jij komt met de leiding FK in een rooster entity. Dat is IMHO behoorlijk fout, immers, wat heeft het rooster voor relatie met leiding? Het PROJECT heeft een leider, niet het rooster!