[DB] Normalisatie *

[Verwijderd]

Ik heb hier 2x een 0NV

(STUDENTNR, NAAM, RICHTING, RG (ACTIVITEIT, RG ( DATUM, BETAALD)))

(DATUM, RG (ACTIVITEIT, PRIJS, RG (STUDENTNR)))

Deze moest ik normaliseren en integreren.

Is deze uiteindelijke 3 NV goed?

Betaald (STUDENTNR, ACTIVITEIT, DATUM, BETAALD)
Student (STUDENTNR, NAAM, RICHTING)
Activiteit (ACTIVITEIT, PRIJS,OMSCHRIJVING)

[ Voor 5% gewijzigd door Verwijderd op 08-10-2003 11:36 ]

[kasper_vk]

Geef eens iets meer uitleg over de case en over wat de genoemde zaken voorstellen. Eerder kan hier echt geen zinvol oordeel over gegeven worden.

En hoever moet het vervolgens genormaliseerd worden? 1e normaalvorm, 2e, 3e, BCNF?

[Verwijderd]

Een commissie van een studentenvereniging houdt bij voor welke (sport-) activiteiten een student zich heeft ingeschreven. Een student kan zich voor een bepaalde activiteit voor één of meer dagen inschrijven. De genoemde prijs is de prijs van de betreffende activiteit. Deze prijs ligt per activiteit vast en varieert niet. In verband met de grote afstanden tussen de diverse locaties kan een student zich slechts voor één activiteit per dag inschrijven.

[Verwijderd]

code:

Inschrijvingen per student          Overzicht per 30-4-99
Gegevens student:

Nummer          : 0053789
Naam            : J. Jansen 
Richting        : BE ; Bedrijfseconomische
Gegevens ingeschreven activiteiten:

Activiteit                                   Datum           Betaald
HG - Hangglijden    21 mei 1999                                  Ja
                        28 mei 1999      Nee

ZV - Zweefvliegen   03 juni 1999                                 Ja
                        04 juni 1999                                 Ja
                        05 juni 1999                                 Nee    
Figuur 1

[ Voor 13% gewijzigd door Verwijderd op 08-10-2003 11:58 ]

[Verwijderd]

code:

Datum           Activiteit      Prijs   Studentnummer
21 mei 1999 Hangglijden  75,=   0053789
                Zweefvliegen     225,-  0012345
                                        0054321

22 mei 1999 Hangglijden  75,=   0098765
                Zweefvliegen     225,-  0045678
Figuur 2

Excuses voor de 3 posts achter elkaar maar dit is het in iedergeval.

gebruik dan het -knopje rechtsbovenin

[ Voor 33% gewijzigd door curry684 op 08-10-2003 12:39 ]

[kasper_vk]

Volgens mij heb je te maken met 3 entiteiten:
- activiteit
- student
- inschrijving (i.p.v. 'betaald' --> een entiteit is een zelfstandig naamwoord)

Omdat een student zich voor slechts 1 activiteit per dag kan inschrijven, lijkt het me dat in Inschrijving alleen de velden datum en studentnr kandidaadsleutels zijn; de activiteit die wordt uitgevoerd is 'slechts' een attribuut / veld.

Ik denk dat de studierichting van een student na normalisatie ook in een aparte tabel gaat eindigen. (ik zou alleen even moeten opzoeken waarom ookalweer )

[ Voor 9% gewijzigd door kasper_vk op 08-10-2003 12:06 ]

[Verwijderd]

kasper_vk schreef op 08 oktober 2003 @ 12:04:
Volgens mij heb je te maken met 3 entiteiten:
- activiteit
- student
- inschrijving (i.p.v. 'betaald' --> een entiteit is een zelfstandig naamwoord)

Omdat een student zich voor slechts 1 activiteit per dag kan inschrijven, lijkt het me dat in Inschrijving alleen de velden datum en studentnr kandidaadsleutels zijn; de activiteit die wordt uitgevoerd is 'slechts' een attribuut / veld.

Ik denk dat de studierichting van een student na normalisatie ook in een aparte tabel gaat eindigen. (ik zou alleen even moeten opzoeken waarom ookalweer )

Ik had ook al zoiets in gedachte alleen kwam ik er echt niet aan uit.
De normalisatie heb ik 2x gedaan en nu loop ik bij het maken van de vragen vast.

[dusty]

Is het mogelijk dat een student in twee gedeeltes voor een activiteit betaald?

[dusty]

kasper_vk schreef op 08 oktober 2003 @ 12:04:
Omdat een student zich voor slechts 1 activiteit per dag kan inschrijven, lijkt het me dat in Inschrijving alleen de velden datum en studentnr kandidaadsleutels zijn; de activiteit die wordt uitgevoerd is 'slechts' een attribuut / veld.

Als je de database gaat gebruiken om op deze manier af te dwingen dat die student slechts een keer per dag mee mag doen, ben je de database aan het misbruiken. Er zijn in normale databases andere methoden om te zorgen dat er een foutmelding komt. Op deze manier zou je de database model gebruiken om een regel af te dwingen, wat een eventueel toekomstige uitbereiding zeer zeker in de weg zou kunnen zitten.

Dat een student slechts een activiteit per dag mag doen, moet je zeer zeker niet meenemen bij het normaliseren van je database. Juist vanwege de limieten die je genereert om de mogelijkheden van je systeem in de toekomst uit te bereiden. De check dat een student maar een keer met een activiteit mee doet kan beter op een andere manier worden gedaan.

[kasper_vk]

dusty schreef op 08 oktober 2003 @ 13:26:
[...]
Als je de database gaat gebruiken om op deze manier af te dwingen dat die student slechts een keer per dag mee mag doen, ben je de database aan het misbruiken. Er zijn in normale databases andere methoden om te zorgen dat er een foutmelding komt.

Je zou het idd ook met behulp van een constraint oid kunnen afdwingen. Wanneer je van mening bent dat de database nog steeds in een consistente toestand is wanneer er toch 2 inschrijvingen van 1 student op 1 dag bestaan, zou je zelfs de check buiten de database kunnen uitvoeren.
Maar dan ben je dus meer ontwikkelwerk aan het doen met als gevolg een grotere kans op fouten.

dusty schreef op 08 oktober 2003 @ 13:26:
[...]
Op deze manier zou je de database model gebruiken om een regel af te dwingen, wat een eventueel toekomstige uitbereiding zeer zeker in de weg zou kunnen zitten.

Volgens mij is het gewoon mogelijk om een extra kandidaatsleutel te definieren & implementeren; wanneer je een kandidaatsleutel nu toevoegt en later toch wilt verwijderen, zadel je jezelf echter met roblemen op.
Vandaar dat het mijn vookeur zou zijn om het aantal sleutels zo mininaal mogelijk te houden en volgens de case is de combinatie van student + datum uniek.

dusty schreef op 08 oktober 2003 @ 13:26:
[...]

Dat een student slechts een activiteit per dag mag doen, moet je zeer zeker niet meenemen bij het normaliseren van je database. Juist vanwege de limieten die je genereert om de mogelijkheden van je systeem in de toekomst uit te bereiden. De check dat een student maar een keer met een activiteit mee doet kan beter op een andere manier worden gedaan.

Mee eens: ik bedoelde het ook niet als onderdeel van het normaliseren, maar als aanvullende afweging bij het opstellen van zijn model.

[jAnO!]

ah.. algemene informatiekunde voor het HBO?
koop gewoon het antwoordenboek.

<font color=blue>modbreak: hou het ontopic aub</font>

<edit>
<stiekem toch off-topic>
Ik reageerde omdat ik de opdracht herken. Overigens staat in het betreffende boek een uitstekende uitleg van normalisatie. Ik meen h13 of h14. een aanrader...
Prima te gebruiken als basis voor AMBI Hg1 en Hg2 (10 X beter dan de meuk die je bij de LOI krijgt).

AIV van Derksen en Crins ISBN 9039512833
</stiekem toch off-topic>
</edit>

[ Voor 86% gewijzigd door jAnO! op 08-10-2003 16:46 ]

[The Eagle]

Ik d8 dat GoT er niet was voor huiswerkopdrachten.....
Ik zie in de topicstart staan "Is deze uiteindelijke 3 NV goed?" Dat duidt er bij mij al op. En de inhoud van de DB wijst ook al die kant in.....


M'n vorige modbreak ging al over het on-topic houden van dit topic.
Als je dergelijke meldingen wilt doen, doe het dan via TR of SM
Daarnaast moet je eens de P&W FAQ lezen. Moest het niet mogen, dan hadden we al lang ingegrepen.

[ Voor 41% gewijzigd door whoami op 08-10-2003 16:30 ]

[whoami]

kasper_vk schreef op 08 October 2003 @ 13:40:
[...]


Je zou het idd ook met behulp van een constraint oid kunnen afdwingen. Wanneer je van mening bent dat de database nog steeds in een consistente toestand is wanneer er toch 2 inschrijvingen van 1 student op 1 dag bestaan, zou je zelfs de check buiten de database kunnen uitvoeren.
Maar dan ben je dus meer ontwikkelwerk aan het doen met als gevolg een grotere kans op fouten.

Als de bedrijfsregels zo zijn, dat een student slechts 1 inschrijving mag hebben op een bepaalde dag, dan is je DB niet meer consistent als er toch zo'n geval zou voorkomen.
Dergelijke zaken vang je dus op in de DB dmv constraints. (In dit geval dmv een primary key constraint).

[Verwijderd]

Ik heb 'm eens opnieuw bekeken en nu kom ik op een uiteindelijke 3NV
INSCHRIJVING (STUDENTNR, ACTIVITEIT, BETAALD)
STUDENTINFO (STUDENTNR, NAAM, RICHTING)
ROOSTER (DATUM, ACTIVITEIT, STUDENTNR)
ACTIVITEIT (ACTIVITEIT, DATUM, PRIJS)

Dit leek mij ook iets logischer.
Maar in praktijk lukt het niet.

[ Voor 12% gewijzigd door Verwijderd op 08-10-2003 17:35 ]

[whoami]

De entiteit Rooster mag geen studentnr bevatten.
Het rooster staat nl. los van studenten op zich.

Studenten kunnen wel inschrijven op een activeit die in het rooster te vinden is, maar dat doe je al dmv de inschrijving entiteit.

[ Voor 66% gewijzigd door whoami op 08-10-2003 18:30 ]

[Verwijderd]

hmmm da's klote

[Verwijderd]

idd wat whoami zegt... je zet in inschrijving de student nummer...

je moet daar alleen niet ACTIVITEIT gebruiken, maar ROOSTER. Je student schrijft zich nl in op een ROOSTER vermelding (Activiteit op een dag) en niet op een ACTIVITEIT zelf... en bij activitetit moet je datum schrappen:
dit is je nieuwe tabel:

INSCHRIJVING (STUDENTNR, ROOSTER, BETAALD)
STUDENTINFO (STUDENTNR, NAAM, RICHTING)
ROOSTER (DATUM, ACTIVITEIT)
ACTIVITEIT (ACTIVITEIT, PRIJS)

Ook zou je kunnen overwegen om bij inscrhijving, rooster en activiteit een eigen Primary Key op te nemen

[ Voor 1% gewijzigd door Verwijderd op 09-10-2003 08:23 . Reden: PK vergeten aan te geven :) ]