[database] Normaliseren wil niet lukken

[the_scientist]

Ik ben bezig met het bouwen van een database. Een project van school, wat begint met het interviewen van de "klant" tot het presenteren van het uiteindelijke product. Inmiddels is mijn ontwerp goedgekeurd door de klant, en heb ik groen licht gekregen voor het bouwen van de database.

Het probleem zit hem nu in het normaliseren. Na een aantal lessen proberen wilde dit nog steeds niet lukken. Op internet heb ik een handige tutorial gevonden, op deze site.

http://www.phphulp.nl/php/tutorials/3/150/

Helaas kwam ik hiermee ook niet tot het gewenste resultaat, maar verdere Google-searches leverden mij enkel 3 flamewars op tussen gebruikers van verschillende fora. Ik hoop dat iemand mij hiermee kan helpen.

De bedoeling is dat we een applicatie ontwikkelen, waarmee de gebruiker met een paar muisklikken een cijferkaart kan uitprinten van een leerling. Deze gegevens worden door de gebruiker ingevoerd in Access 2000, waar we uiteindelijk de database in moeten bouwen.

Een schematisch ontwerp van mijn rapport in Excel:

http://www.frozen-land.com/ioi/schets.xls

De informatie die in de database zal moeten komen:

Leerlinginformatie:
Voornaam (VN_leerling)
Achternaam (AN_leerling)
OV-nummer (NR_leerling)

Klasinformatie:
Klascode (Code_klas)
Klasnaam (Naam_klas)

Mentorinformatie:
Voornaam (VN_mentor)
Achternaam (AN-mentor)
Naamcode (NC_mentor)

Toetsinformatie:
Toetscode (Code_toets)
Behaald cijfer (Cijfer1)
Herkansing (Herkansing)
Gemiddeld cijfer (Procesgegeven)

Vakinformatie:
Vakcode (Code_vak)
Vaknaam (Naam_vak)

De schuine tekst tussen haakjes zijn de namen van de velden.

Hieronder wat ik van de normalisering heb gemaakt:

Nulde normaalvorm:

VN_leerling, AN_leerling, NR_leerling, [Naam_klas, Code_klas, VN_mentor, AN-mentor, NC_mentor, Code_toets, Cijfer1, Herkansing, Code_vak, Naam_vak]

Eerste normaalvorm:

NR_leerling, VN_leerling, AN_leerling

NR_leerling, Code_klas, Naam_klas

Code_klas, NC_mentor, VN_mentor, AN-mentor,

NC_mentor Code_toets, Cijfer1, Herkansing

Code_toets, Code_vak, Naam_vak

Tweede normaalvorm:


Derde normaalvorm:

Voor deze database gaan we niet verder dan de derde normaalvorm. Voor de sleutel maak ik voor het gemak gebruik van onderstreepte tekst, voor de vreemde sleutels maak ik gebruik van doorgehaalde tekst.

Zelf denk ik dat de fout in de repeterende groep zit in de nulde normaalvorm. Kan iemand mij hiermee enigszins op weg helpen? Mocht er nog iets aan informatie missen, dan hoor ik dat graag.

[ Voor 33% gewijzigd door the_scientist op 25-03-2005 12:35 ]

[Mischa_NL]

tblUsers
User_ID	VN_leerling	AN_leerling	OV-nummer	Class_ID	Mentor_ID (=Naamcode)
1	Peter	L.	2134	1	1

tblMentor
Mentor_ID (=Naamcode)	Voornaam	Achternaam
1	Jan	P.

tblToetsen
Toets_ID	User_ID	Behaald cijfer	Herkansing	Gemiddeld cijfer
1	1	8		6

tblKlassen
Class_ID	Klasnaam
1	Groep3

Enige wat ik apart vind is dat je een gemiddeld cijfer gaat opslaan. Ik weet niet waar dat cijfer vandaag komt.

EDIT/ Ik weet niet hoe het met die normaal vormen zit maar volgens mij is mijn model redelijk genormaliseerd

EDIT2/ Zo beter dan . Je snapte best wat ik ermee bedoel

[ Voor 6% gewijzigd door Mischa_NL op 25-03-2005 12:43 ]

[Verwijderd]

3x tblMentor klinkt niet echt als genormaliseerd...

[the_scientist]

Dat gemiddelde cijfer is een procesgegeven, dat wordt dus niet opgeslagen, maar uitgerekend tijdens het uitdraaien van een rapport.

[4VAlien]

De normalisatie van Mischa lijkt me een standaard vorm om mee te werken, tevens moet het gemiddelde inderdaad liever niet opgeslagen maar uitgerekend worden.

[ Voor 82% gewijzigd door 4VAlien op 25-03-2005 12:47 ]

[the_scientist]

Mischa_nl:

Die tabel ziet er op zich goed uit. Alleen is mijn probleem dat ik ook een compleet projectverslag heb doorlopen, met de uitdraai van de doorlopen stappen om tot een genormaliseerde database te komen. Ik blijf dus nog steeds hangen op de repeterende groepen. Als iemand daar een oplossing voor heeft is die uiteraard zeer welkom.

[Mischa_NL]

Kan wel. Voor mij is iets genormaliseerd als je zoveel mogelijk logische/nuttige verwijzingen naar ID's gebruikt. Verander je de naam van een mentor in de mentor tabel dan moet hij bij elke user aangepast zijn. Ik kijk niet naar die vage normaal vorm. Gewoon ff logisch nadenken .

[the_scientist]

4VAlien schreef op vrijdag 25 maart 2005 @ 12:46:
De normalisatie van Mischa lijkt me een standaard vorm om mee te werken, tevens moet het gemiddelde inderdaad liever niet opgeslagen maar uitgerekend worden.

Dat is ook inderdaad een vereiste van ons eindproduct. Aangezien ik zo hoog mogelijk moet scoren voor dit project om mijn jaar te halen ga ik ook proberen om dit voor elkaar te boxen. Informatie-analyse is mijn zwakste punt, daarom hoop ik wat extra hulp te krijgen.

[the_scientist]

Mischa_NL schreef op vrijdag 25 maart 2005 @ 12:49:
Kan wel. Voor mij is iets genormaliseerd als je zoveel mogelijk logische/nuttige verwijzingen naar ID's gebruikt. Verander je de naam van een mentor in de mentor tabel dan moet hij bij elke user aangepast zijn. Ik kijk niet naar die vage normaal vorm. Gewoon ff logisch nadenken .

Ik begrijp je punt. Alleen, leg dat mijn eigenwijze leraar maar eens uit

Op het moment dat ik m'n diploma in handen heb, mag ik werken hoe ik wil. Alleen is dat nu nog niet het geval, dus zal het nu nog volledig moeten doen hoe het me voorgekauwd wordt.

[Lustucru]

edit:
eerder verwarrend dan verhelderend

[ Voor 86% gewijzigd door Lustucru op 25-03-2005 17:17 ]

[the_scientist]

Ik snap het volgens mij. Op die manier zou een leerling maar 1 X een toets kunnen maken, daarna niet meer. Alleen, toen ik dit aan m'n leraar liet zien hoorde ik hem alleen over de repeterende groepen. En ik heb eerlijk gezegd nog nooit meegemaakt dat je een 2e sleutel hebt in de nulde normaalvorm.

Niet lullig bedoeld hoor, alleen volgens mij ben ik er nog niet helemaal.

[Lustucru]

Nee, er is maar één sleutel, en die sleutel is een unieke identificatie van je rij. De theorie van het normaliseren zegt niets over het maximaal aantal velden waaruit de sleutel wordt opgebouwd. Wel is er een b(l)oeiende discussie mogelijk of die sleutel betekenisvol mag of moet zijn. Ik vind zelf van niet, maar ja.

ALs een leerling elke toets maar één keer mag maken (inclusief een veld voor herkansing) dan is de sleutel lrlID+ToetsID. Mag hij/zij een toets diverse keren maken dan is zelfs dat onvoldoende. Wil je één veld voor je sleutel dan genereer je een ToetsLeerlingMomentID.
[toetsleerlingmomentid]
lrlgegevens
klasgegevens
mentorgegevens
toetsgegevens
resultaatgegevens

[the_scientist]

Niesje schreef op vrijdag 25 maart 2005 @ 14:12:
Nee, er is maar één sleutel, en die sleutel is een unieke identificatie van je rij. De theorie van het normaliseren zegt niets over het maximaal aantal velden waaruit de sleutel wordt opgebouwd. Wel is er een b(l)oeiende discussie mogelijk of die sleutel betekenisvol mag of moet zijn. Ik vind zelf van niet, maar ja.

ALs een leerling elke toets maar één keer mag maken (inclusief een veld voor herkansing) dan is de sleutel lrlID+ToetsID. Mag hij/zij een toets diverse keren maken dan is zelfs dat onvoldoende. Wil je één veld voor je sleutel dan genereer je een ToetsLeerlingMomentID.
[toetsleerlingmomentid]
lrlgegevens
klasgegevens
mentorgegevens
toetsgegevens
resultaatgegevens

Nu ben ik al wat verder. Maarja, ben ik weer, hoe kom ik er nu achter wat de repeterende groepen zijn? Ik weet dat GoT geen huiswerkforum is, maar ik wil voorbij die @#* nulde normaalvorm. Het tweede stuk over het ToetsLeerlingMomentID. Dat kan ik op zich nog wel volgen, alleen ligt dat wat hoger dan de stof die we hebben gehad. De lessen waren eigenlijk puur basisprincipes van MySQL, Access, en normaliseren.

[Verwijderd]

Op die manier zou een leerling maar 1 X een toets kunnen maken, daarna niet meer.

Nee, hij/zij kan maar 1x een toets met die ID maken. De herkansingstoetsen geef je dan weer gewoon een eigen ID, met een verwijzing naar die toets-definitie (dat wordt dan dus een extra tabelletje: Toets_ID, Omschrijving, en misschien nog wat extra velden).

Overigens moet je je niet doodstaren op normalisatie. Vaak is gewoon nuchter nadenken en dingen in de praktijk testen een stuk handiger.
Ik heb vaak genoeg redundante gegevens gebruikt (de naam van een klant bijvoorbeeld, terwijl een foreign key naar 't record in de klantentabel ook zou volstaan). Niet netjes genormaliseerd dus, maar als 't dan opeens 100% sneller werkt, is de klant blij, en ik ook.
En zo vaak wijzigt de naam van een klant niet, dus dan zijn ook die redundant fields simpel bij te werken (via een trigger of client side).

[the_scientist]

Verwijderd schreef op vrijdag 25 maart 2005 @ 14:26:
[...]

Nee, hij/zij kan maar 1x een toets met die ID maken. De herkansingstoetsen geef je dan weer gewoon een eigen ID, met een verwijzing naar die toets-definitie (dat wordt dan dus een extra tabelletje: Toets_ID, Omschrijving, en misschien nog wat extra velden).

Overigens moet je je niet doodstaren op normalisatie. Vaak is gewoon nuchter nadenken en dingen in de praktijk testen een stuk handiger.
Ik heb vaak genoeg redundante gegevens gebruikt (de naam van een klant bijvoorbeeld, terwijl een foreign key naar 't record in de klantentabel ook zou volstaan). Niet netjes genormaliseerd dus, maar als 't dan opeens 100% sneller werkt, is de klant blij, en ik ook.
En zo vaak wijzigt de naam van een klant niet, dus dan zijn ook die redundant fields simpel bij te werken (via een trigger of client side).

In het eerste stukje doelde ik op mijn eigen fout, die ik nu dus begrijp. Als leerling_ID als enig veld als sleutel zou dienen, zou een leerling maar 1 toets kunnen maken, inclusief herkansing. Stel je echter een sleutel samen van leerling_ID en toets_ID zou een leerling dus 1 X dezelfde toets kunnen maken, wat ook de bedoeling is. Dit is nu duidelijk.

In het tweede stukje snap ik je punt. Alleen, wat er vergeten wordt is dat jij (waarschijnlijk?) voor een bedrijf bezig bent, terwijl ik nu een opdracht voor school uitvoer. Alles is voor mij voorgekauwd, en verbonden aan een zwik regels. Als ik daarvan afwijk is de leraar heel makkelijk: bam, punten eraf. Niet bepaald de bedoeling dus. Of het nou sneller werkt of niet doet er in dit project niet toe, als het maar werkt volgens de regels van het project.

Een nette normalisering is in dit geval dus wel belangrijk, hoe graag ik het ook anders zou zien.

[ Voor 4% gewijzigd door the_scientist op 25-03-2005 14:52 ]

[Lustucru]

Foutje . Wat je als nulde vorm presenteert is al een halve eerste normaalvorm.

Repeterende groepen zijn die gegevens die bij een gelijkblijvende sleutel herhaald worden. Dus in jouw geval kan dat zijn uitslag1, uitslag2, uitslag3 etc. etc. Haal die eruit tezamen met de procesgegevens en je hebt de eerste normaalvorm. Als je eerste punt en herkansing als twee niet te vergelijken waarden wilt zien dan ben je nog sneller klaar.

Anders gezegd: als leerlingid je sleutel is dan had je een nulde-vorm gehad als:
leerling - toets1-toets2-toets3-toets4-toets5-toets6....toetsN, zeg maar de gemiddelde exceltabel

Benoem dat als nulde vorm en dan wordt de eerste normaal dus wat je nu al bijna hebt.

[ Voor 53% gewijzigd door Lustucru op 25-03-2005 15:02 ]

[the_scientist]

Ik ga nog een gooi doen:

Nulde normaalvorm:

VN_leerling, AN_leerling, NR_leerling, [Naam_klas, Code_klas, VN_mentor, AN-mentor, NC_mentor, Code_toets, Cijfer1, Herkansing, Code_vak, Naam_vak]

Eerste normaalvorm:

VN_leerling, AN_leerling, NR_leerling

NR_leerling, Naam_klas, Code_klas, VN_mentor, AN-mentor, NC_mentor, Code_toets, Cijfer1, Herkansing, Code_vak, Naam_vak

Is dit het, of zit ik er weer compleet naast?

[Lustucru]

Helaas
Nulde normaalvorm:

VN_leerling, AN_leerling, NR_leerling, Naam_klas, Code_klas, VN_mentor, AN-mentor, NC_mentor, [Code_toets, Cijfer1, Herkansing, Code_vak, Naam_vak]
_{mentor weet ik niet, is dat vakgebonden, dan repeterend}

edit:
als klassen variabel zijn trouwens idem dito, en dan is wat je schrijft wel OK

Eerste normaalvorm:
VN_leerling, AN_leerling, NR_leerling, Naam_klas, Code_klas, VN_mentor, AN-mentor, NC_mentor,
m.a.w. alle dingen die alleen afhankelijk zijn van lrl blijven voorlopig in de tabel.

resultaten:
nrleerling,Code_toets, Code_vak, Naam_vak,cijfer

[ Voor 22% gewijzigd door Lustucru op 25-03-2005 15:39 ]

[Voutloos]

Waarom teken je niet een relationeel diagram als je niet op je beginnetje komt? Diagram mappen naar 1e normaal is simpel. En het hebben van zo'n diagram heeft vast een positieve uitwerking op je cijfer, omdat je de verschillende ontwerpstappen dan netjes doorlopen hebt.

Tevens vind ik een diagram helderder om te lezen dan de lijstjes die je nu hebt. Zien wij ook meteen alles mbt kardinaliteit, wat niesje eigenlijk ook vraagt hierboven ("mentor weet ik niet, is dat vakgebonden, dan repeterend")

[ Voor 18% gewijzigd door Voutloos op 25-03-2005 15:40 ]

[the_scientist]

Voutloos schreef op vrijdag 25 maart 2005 @ 15:38:
Waarom teken je niet een relationeel diagram als je niet op je beginnetje komt? Diagram mappen naar 1e normaal is simpel. En het hebben van zo'n diagram heeft vast een positieve uitwerking op je cijfer, omdat je de verschillende ontwerpstappen dan netjes doorlopen hebt.

Tevens vind ik een diagram helderder om te lezen dan de lijstjes die je nu hebt. Zien wij ook meteen alles mbt kardinaliteit, wat niesje eigenlijk ook vraagt hierboven ("mentor weet ik niet, is dat vakgebonden, dan repeterend")

Het relationele diagram wil ik best tekenen, enkel volgens het project behoort dit pas na afloop te gebeuren. Over mentor: deze is klasgebonden. Informatie over de leraar, welke vakgebonden is, hoeft dus niet in de database te komen.

Ik denk dat ik nu een heel eind kan komen. Moet helaas nu wat klanten gaan rijden voor m'n ma d'r bedrijf (stomerij, godzijdank geen ict ) maar zodra ik terug ben gaan we weer aan de slag.

[ Voor 12% gewijzigd door the_scientist op 25-03-2005 15:52 ]

[Voutloos]

Na afloop zo'n diagram tekenen is net als na afloop van een voetbalwedstrijd de opstelling vrijgeven.

[curry684]

4VAlien schreef op vrijdag 25 maart 2005 @ 12:46:
De normalisatie van Mischa lijkt me een standaard vorm om mee te werken, tevens moet het gemiddelde inderdaad liever niet opgeslagen maar uitgerekend worden.

Depends. De reguliere procedure van databasedesign is dat je eerst normaliseert tot BCNV of 3NV (of hoger als je echt wilt) en vervolgens gaat denormaliseren om capaciteitsproblemen te herkennen. Lichtend voorbeeld is je postcount hier op GoT, welke als integer in de usertabel staat. Je zou die natuurlijk ook met een count op 15284641 berichten in de messagestabel kunnen doen iedere keer als ie nodig is maaruhm....

[NMe]

the_scientist schreef op vrijdag 25 maart 2005 @ 15:49:
Het relationele diagram wil ik best tekenen, enkel volgens het project behoort dit pas na afloop te gebeuren.

Euh... Het uiteindelijke model maak je inderdaad achteraf. Maar tussendoor kun je toch zeker wel wat modelletjes maken om je op gang te helpen? Ik heb nog nooit een database gemaakt zonder ERD.

[curry684]

-NMe- schreef op vrijdag 25 maart 2005 @ 16:03:
[...]

Ik heb nog nooit een database gemaakt zonder ERD.

Ik nog nooit met

[NMe]

curry684 schreef op vrijdag 25 maart 2005 @ 16:04:
Ik nog nooit met

Dan neem ik aan dat je met een LGS, Data Dictionary of strokendiagram werkt, of een vergelijkbare methode. Hoe dan ook lijkt het me nogal lastig om relaties goed duidelijk te krijgen zonder een of andere diagramvorm.

[Voutloos]

Kan best dat je uit ervaring de relaties goed weet in te schatten en al op de automatische piloot id's hangt aan bepaalde entities (bv: een tabel voor personen of adressen komt bijna in elke DB voor, dus die ken je zo uit je hoofd uitschrijven als je een nieuwe DB maakt), maar dat er zo slorig wordt begonnen aan een DB-ontwerp op een opleiding verbaasde me gewoon.

Uiteraard mag iedereen op zijn eigen manier zijn DB ontwerpen, maar dit hoort imo gewoon bij het leerproces. Als je na het halen van het vak liever de methode laat varen omdat het je niet aanstaat heb je groot gelijk (zolang je maar fatsoenlijke DB's blijft maken ).

edit:
Precies, wat NMe zegt: het gaat hier ook om het leren en begrijpen van relaties.

[ Voor 8% gewijzigd door Voutloos op 25-03-2005 16:15 ]

[curry684]

-NMe- schreef op vrijdag 25 maart 2005 @ 16:13:
[...]

Dan neem ik aan dat je met een LGS, Data Dictionary of strokendiagram werkt, of een vergelijkbare methode. Hoe dan ook lijkt het me nogal lastig om relaties goed duidelijk te krijgen zonder een of andere diagramvorm.

Sorry, gewoon tig jaar ervaring en inzicht Werk op z'n tijd met de diagram editor van SQL Server Enterprise Manager, maar da's ook puur en alleen omdat je dan lekker snel werkt met relaties leggen itt de popupwindowtje met handmatig primary en foreign keys selecteren, maar zelfs dan nog gaat het allemaal direct uit het blote hoofd, en kan me verder niet herinneren dat ik ooit iets naderhand heb hoeven wijzigen aan een DB

Vanzelfsprekend is het voor topicstarter aan te raden wel iets gestructureerder te werken als je die tig jaar ervaring nog niet hebt

[ Voor 9% gewijzigd door curry684 op 25-03-2005 16:47 ]

[Wokker]

Toevallig ik heb ik pas ook les gehad in normaliseren. Hiervoor hebben we in andere thema's ook gebruik gemaakt van erd en Structuurdiagrammen (minder bekent).
Onze leraar heeft ons gelijk verteld dat normaliseren verouderd is maar het toch handig is om te weten. Ik heb de presentatie die de leraar gebruikt online gezet over normaliseren mischien dat je er wat aan hebt

http://allesopwieletjes.nl.nu/vandenbulckeLes3.ppt

[Lustucru]

Voutloos schreef op vrijdag 25 maart 2005 @ 16:14:
Kan best dat je uit ervaring de relaties goed weet in te schatten en al op de automatische piloot id's hangt aan bepaalde entities (bv: een tabel voor personen of adressen komt bijna in elke DB voor, dus die ken je zo uit je hoofd uitschrijven als je een nieuwe DB maakt), maar dat er zo slorig wordt begonnen aan een DB-ontwerp op een opleiding verbaasde me gewoon.

Uiteraard mag iedereen op zijn eigen manier zijn DB ontwerpen, maar dit hoort imo gewoon bij het leerproces. Als je na het halen van het vak liever de methode laat varen omdat het je niet aanstaat heb je groot gelijk (zolang je maar fatsoenlijke DB's blijft maken ).

edit:
Precies, wat NMe zegt: het gaat hier ook om het leren en begrijpen van relaties.

Zo slordig vind ik het niet. Het strokendiagram / relatiediagram whatever is imho het resultaat van het normalisatieproces. De prestatie van Boyce-Codd is dat ze in een drietal stappen de weg naar een erd konden formaliseren en tegelijk inzichtelijk maken wat er nu eigenlijk gebeurd. Ik zou het juist slordig vinden als er niet eerst 0,1,2,3 genormaliseerd moest worden. Wat curry684 al zegt, dus.

[NMe]

Ook met tig jaar ervaring zijn tekeningen handig, zeker als je in een team werkt. Niet iedereen heeft dezelfde denkwijze, en zeker bij normaalvormen die na de 3e komen wil je nog wel eens discussiepunten hebben. Zeker als je iemand in je team hebt die nog niet zoveel ervaring heeft.

Wokker schreef op vrijdag 25 maart 2005 @ 16:57:
Onze leraar heeft ons gelijk verteld dat normaliseren verouderd is maar het toch handig is om te weten.

Verouderd? Sorry? Welk alternatief biedt hij dan, voor een relationele database?

[ Voor 34% gewijzigd door NMe op 25-03-2005 17:02 ]

[Voutloos]

Wokker schreef op vrijdag 25 maart 2005 @ 16:57:
Onze leraar heeft ons gelijk verteld dat normaliseren verouderd is maar het toch handig is om te weten.

De redenen voor normaliseren staan toch duidelijk in die ppt. Redundantie en inconsistentie vermijden is en blijft nodig, tenzij je het bewust anders wil doen ivm prestatiereden (zie Curry's voorbeeld over postcount).

Jammer dat het niet je eigen stelling is, hadden we een leuke discussie kunnen voeren.

[the_scientist]

Goed, na een flinke pizza en wat klantjes rijden konden we weer aan het normaliseren. En volgens mij is het nu redelijk gelukt. Maar ja, dat dacht ik vanmiddag ook...

Anyway, hieronder is het eindproduct van mijn genormaliseerde database. Zit ik op de goede weg, of zitten er nog steeds fouten in?

Nulde normaalvorm:

VN_leerling, AN_leerling, NR_leerling, Naam_klas, Code_klas, VN_mentor, AN_mentor, NC_mentor, [Code_toets, Cijfer1, Herkansing, Code_vak, Naam_vak]

Eerste normaalvorm:

VN_leerling AN_leerling NR_leerling Naam_klas Code_klas VN_mentor AN_mentor NC_mentor

VN_leerling Code_toets Cijfer1 Herkansing Code_vak Naam_vak

Tweede normaalvorm:

VN_leerling AN_leerling NR_leerling Naam_klas Code_klas VN_mentor AN_mentor NC_mentor

VN_leerling Code_toets

Code_toets Cijfer1 Herkansing Code_vak Naam_vak

Derde normaalvorm:

Leerling VN_leerling AN_leerling NR_leerling Code_klas

Klas Code_klas Naam_klas NC_mentor

Mentor NC_mentor VN_mentor AN_mentor

Toets VN_leerling Code_toets[/u]

Resultaat Code_toets Cijfer1 Herkansing Code_vak

Vak Code_vak Naam_vak

In ieder geval allemaal bedankt voor de reacties tot zover!

[Lustucru]

VN_Leerling als sleutelveld? Grapje zeker?

1e normaalvorm: kan zo wel (imho)
2e normaalvorm: splits alle velden af die afhankelijk zijn van een deel van de sleutel, dwz naamvak hangt af van code toets; die splits je af. Verder niets
3e normaalvorm: splits velden af die afhankelijk zijn van een niet sleutelveld
dwz naam_klas, mentordata.

In jouw 3e normaal is toets en resultaat ietwat onzinnig.
beter: toets=vak + toetsnaam
resultaat=lrl+toets+cijfer

En nu hou ik er mee op.

[ Voor 6% gewijzigd door Lustucru op 26-03-2005 11:29 ]

[the_scientist]

M'n normalisering is goedgekeurd na de tips hier, wat zoekwerk op internet, en een klein beetje hulp van de leraar. Bedankt, alleen nu zit ik weer vast bij het ERD. Op internet en in m'n boek heb ik al wat tekens gevonden voor het toepassen van de cardinaliteit, alleen lukt het mij nog niet om deze te kunnen verwerken. Ik heb een probeersel gemaakt, maar heb geen idee of dat goed is. De relaties tussen de tabellen heb ik al wel kunnen leggen. Nogmaals een noodkreet.

De documenten die ik tot nu toe heb:

Een schematisch ontwerp van mijn rapport in Excel:

http://www.frozen-land.com/ioi/schets.xls

De op te nemen informatie:

http://www.frozen-land.com/ioi/informatie.doc

De genormaliseerde uitwerking van de tabellen:

http://www.frozen-land.com/ioi/normalisering.doc

Mijn ERD-probeersel

http://www.frozen-land.com/ioi/ERD.doc

[Freakertje]

Mentor heeft altijd precies één klas? Ga dit even na. Weet je het niet vraag het dan aan de klant.

Als je het wilt controleren schrijf het dan uit in normaal Nederlands en leg die stellingen voor aan de gebruiker. Klopt er iets niet dan zul je dat heel snel te weten komen
==edit=
Zinnen als "Een leerling zit in PRECIES één klas" en "In een klas zit MINIMAAL 1 leerling"
==/edit=
Laat nooit het ERD aan de klant zien, aangezien die dan iets heeft van: "WTF is dit? Nuja, niet laten merken dat ik het niet ken, dat komt stom over, laat ik maar ja en amen zeggen".

Mosterd na de maaltijd, maar: Ik vind het altijd makkelijk om eerst een schets te maken van de formulieren die er moeten komen, en aan de hand daarvan te gaan normaliseren. Bij de eerste berg entiteiten had ik ook zoiets van "wtf moet ik beginnen" maar toen ik je voorbeeldformulier zag had ik iets van "oh dat doe je zo en zo en zo en klaar :)"
Ieder zijn eigen voorkeur, maar dit is mijn manier
(In dit (mijn) geval zou eindcijfer dus ook bij de 1e normaalvorm afvallen als procesgegeven.)

Voor de rest kan ik weinig zeggen, jaar geleden voor het laatst gedaan dus kennis is tikkie weggezakt

[ Voor 7% gewijzigd door Freakertje op 23-04-2005 16:11 ]

[the_scientist]

Freakertje schreef op zaterdag 23 april 2005 @ 16:08:
Mentor heeft altijd precies één klas? Ga dit even na. Weet je het niet vraag het dan aan de klant.

Als je het wilt controleren schrijf het dan uit in normaal Nederlands en leg die stellingen voor aan de gebruiker. Klopt er iets niet dan zul je dat heel snel te weten komen
==edit=
Zinnen als "Een leerling zit in PRECIES één klas" en "In een klas zit MINIMAAL 1 leerling"
==/edit=
Laat nooit het ERD aan de klant zien, aangezien die dan iets heeft van: "WTF is dit? Nuja, niet laten merken dat ik het niet ken, dat komt stom over, laat ik maar ja en amen zeggen".

Mosterd na de maaltijd, maar: Ik vind het altijd makkelijk om eerst een schets te maken van de formulieren die er moeten komen, en aan de hand daarvan te gaan normaliseren. Bij de eerste berg entiteiten had ik ook zoiets van "wtf moet ik beginnen" maar toen ik je voorbeeldformulier zag had ik iets van "oh dat doe je zo en zo en zo en klaar :)"
Ieder zijn eigen voorkeur, maar dit is mijn manier
(In dit (mijn) geval zou eindcijfer dus ook bij de 1e normaalvorm afvallen als procesgegeven.)

Voor de rest kan ik weinig zeggen, jaar geleden voor het laatst gedaan dus kennis is tikkie weggezakt

Damn, heel verhaal getikt, valt de stroom uit

Volgens mij had ik het niet goed uitgelegd in mijn vorige posts:

Aan het begin hebben we een rollenspel gehouden in de klas. De leraar speelde voor klant, ik was database-ontwerper. Na dit rollenspel is er geen klant meer, het ERD kan ik gewoon laten zien aan m'n leraar. Moet zelfs, anders wordt dit niet afgetekend, en kan ik niet door naar de volgende stap.

De zinnen die je bedoelde kende ik al. Ik heb er een paar op papier gezet, waardoor ik de bovenste tabellen volgens mij wel juist heb voorzien van cardinaliteit. Wat betreft de mentorklas, dat klopt wel. Een mentor is slechts van 1 klas mentor, klassen zonder mentor komen niet voor. Een klas kan ook maar 1 mentor hebben. Alleen met de onderste tabellen in het ERD heb ik wat moeite, ik kan daar niet echt goede zinnen bij maken. Als iemand mij daarmee op weg zou kunnen helpen, zou ik daar zeer blij mee zijn.

[Lustucru]

Het klopt ook niet . Elke toets heeft 0,1 of meer resultaten. Zoals het er nu staat heeft elke toets maar één resultaat, m.a.w. dat elke toets maar door één leerling gemaakt wordt. Verder suggereert [...] informatie.doc dat de relatie vak <-> toets verborgen zit in de toetscode, en dat lijkt me niet zo handig.

[the_scientist]

Niesje schreef op zaterdag 23 april 2005 @ 19:26:
Het klopt ook niet . Elke toets heeft 0,1 of meer resultaten. Zoals het er nu staat heeft elke toets maar één resultaat, m.a.w. dat elke toets maar door één leerling gemaakt wordt. Verder suggereert [...] informatie.doc dat de relatie vak <-> toets verborgen zit in de toetscode, en dat lijkt me niet zo handig.

Ik vergeet weer een stukje informatie. Bij mij op de opleiding is er een regel van kracht, dat we een toets slechts 2 X mogen maken. 1 centrale afname, 1 herkansing. Daarna moet er een brief naar de examencommissie, in het project zal die er niet aan te pas komen. Daarom heeft een toets slechts 1 resultaat. Pas op het moment dat de cijfers bekend zijn, zal de toets tezamen met de resultaten worden ingevuld.

Edit:

Informatie.doc is slechts een bestand met aantekeningen voor de informatie wat er in de database opgenomen moet worden. Je moet daar verder niet naar kijken, er zijn daar geen relaties. Het ERD heb ik aangepast na nog eens doorlopen, en inderdaad, je hebt gelijk. Ook heb ik een entiteitenbeschrijving gemaakt, en na wat puzzelen is dit aardig gelukt. Ik ga ze nu uploaden, verder commentaar is uiteraard welkom!

De aangepaste documenten staan online.

De documenten die ik tot nu toe heb:

Een schematisch ontwerp van mijn rapport in Excel:
http://www.frozen-land.com/ioi/schets.xls

De op te nemen informatie:
http://www.frozen-land.com/ioi/informatie.doc

De genormaliseerde uitwerking van de tabellen:
http://www.frozen-land.com/ioi/normalisering.doc

Mijn ERD:
http://www.frozen-land.com/ioi/ERD.doc

De entiteitsbeschrijvingen:
http://www.frozen-land.com/ioi/enti.doc

De database:
http://www.frozen-land.com/ioi/database.mdb

[ Voor 49% gewijzigd door the_scientist op 23-04-2005 19:56 ]

[the_scientist]

*kick*

[Voutloos]

Leuk die kick, maar wat is nu je vraag? Ik heb net je mdb-tje bekeken en dat ziet er allemaal logisch uit (een echt spannende/ingewikkelde DB is dit trouwens niet).

Als dit alles is wat je moet opslaan, doe je het wel goed zo hoor. Het echte nakijken laat ik aan je docent over.

[the_scientist]

M'n enige vraag is: Klopt het ERD, en klopt de entiteitsbeschrijving?

Ik vraag het liever hier, omdat ik van de leraar totaal geen uitleg krijg, en dan m'n tijd verdoe met het zoeken naar de fout. Hier krijg ik tenminste tips ter verbetering waar ik wat mee kan, zodat ik meteen door kan naar de volgende stap .

[Voutloos]

Je zet steeds de naam van de FK/PK bij de relaties. Dit legt wel leuk uit hoe je de tabellen gekoppeld hebt, maar dat is iets wat imo niet boeit op dat niveau. Het gaat immers om relaties. Dus waarom is er een relatie? Meestal zijn de labels bij de lijntjes dus werkwoorden oid. Bij: [Leerling]>---behoort tot---[Klas]

Dit is tenminste de manier waarop ik mijn ERD's moest maken. Dat het resultaat van je ontwerp is dat er uiteindelijk een FK ontstaat is triviaal.

[the_scientist]

Voutloos schreef op maandag 25 april 2005 @ 16:30:
Je zet steeds de naam van de FK/PK bij de relaties. Dit legt wel leuk uit hoe je de tabellen gekoppeld hebt, maar dat is iets wat imo niet boeit op dat niveau. Het gaat immers om relaties. Dus waarom is er een relatie? Meestal zijn de labels bij de lijntjes dus werkwoorden oid. Bij: [Leerling]>---behoort tot---[Klas]

Dit is tenminste de manier waarop ik mijn ERD's moest maken. Dat het resultaat van je ontwerp is dat er uiteindelijk een FK ontstaat is triviaal.

Klopt, dit is de manier hoe het in het voorbeeldbestand stond. Ik probeer me daar zoveel mogelijk aan te houden, dat is hoe ze het willen zien, en wat het meeste punten oplevert.

[Lustucru]

the_scientist schreef op maandag 25 april 2005 @ 16:21:
M'n enige vraag is: Klopt het ERD, en klopt de entiteitsbeschrijving?

Ik vraag het liever hier, omdat ik van de leraar totaal geen uitleg krijg, en dan m'n tijd verdoe met het zoeken naar de fout. Hier krijg ik tenminste tips ter verbetering waar ik wat mee kan, zodat ik meteen door kan naar de volgende stap .

Maar dan wel volgend jaar je lesgeld overmaken naar tweakers, hé?
[mierenneuken]
toets is afsluiting van vakmoduul. /me zoekt vakmoduul op in entiteitsbeschrijving

[the_scientist]

Niesje schreef op maandag 25 april 2005 @ 17:51:
[...]


Maar dan wel volgend jaar je lesgeld overmaken naar tweakers, hé?
[mierenneuken]
toets is afsluiting van vakmoduul. /me zoekt vakmoduul op in entiteitsbeschrijving

Volgend jaar hoop ik van school af te zijn

Wat betreft het stukje over vakmoduul: het gaat daarmee om de praktijk, dus de termen hoeven niet per se terug te komen in de database volgens mij. ERD wel goed in elkaar nu?

[Verwijderd]

Dit lijkt mij een standaard database ontwerp. Ik denk dat er via Google wel voorbeelden te vinden zijn voor het ontwerp van z'on database. Jij hebt nu docent, leraar als entiteiten. Ik kan me nog herinneren dat we dit voorbeeld hebben besproken tijdens mijn college over Database design. Je zou ook kunnen denken aan werkgever en werknemer, of winkel en klant. Gewoon de tabellen overnemen, variabelen wat veranderen, beetje practisch denken en klaar is kees. Google is your best friend!

Lees bijv dit: http://www-106.ibm.com/de...b/library/wa-dbdsgn2.html