[DB] Normaliseren met veel velden en tabellen

[J_Davelaar]

Ik ben mijn oude database aan het herontwerpen. Hij was nog echt aan elkaar geplakt en niet flexibel enzo. Maar nu moeten er ook veel functies bijkomen.
Ik ben al aan het zoeken geweest naar normalisatie e.d. en dat volg ik aardig. Maar nu loop ik tegen het probleem aan dat door de hoeveelheid verschillende data niet meer uit de normalisatie kom. Zie gewoon door de bomen het bos niet meer.

In de meeste dingen die ik gelezen heb zetten ze alle velden naast elkaar en gaan dan dus verder met het normaliseren. Als ik dit doe past het niet meer op mijn bureau...
Mag ik ook werken in delen bij een normalisatie? Dus eerst het leden deel en dan weer het diploma deel? Of verlies ik dan het overzicht in de functionaliteit?

Ik vraag dus niet om een compleet ontwerp (of zelfs een deel) maar om wat tips om toch verder te komen met het normaliseren.


Even een korte inleiding in wat er in moet komen (het gaat om een database voor zeildiploma's voor verschillende scouting groepen)
Gebruikers
-Groep
-Speltak
-Subgroep

Zeil/Roei diploma's --> moet ook uitgebreid kunnen worden naar meerdere diploma's (zijn er nu 5)
-Uitslagen gesplitst naar praktijk en theorie
-Inhoud examens

Examens
-Wanneer
-Wie meegedaan
-Wat behaald

Dit zijn even de hoofdgegevens die ik kwijt moet. Zo hebben jullie ook even een indicatie.


Oh ja, als ik het dus goed begrepen heb is een key de waarde die een rij uniek maakt. Maar een key mag ook bestaan uit een combi van meerdere kolommen? Zeg ik dat goed zo?

[NMe]

Mijn gevoel zegt dat je de volgende tabellen nodig hebt:
Gebruikers, Groepen, Speltakken, Subgroepen, Diplomas en Examens.
Bovendien heb je koppeltabellen nodig:
GebruikerDiplomas en GebruikerExamens.

Gebruikers heeft foreign keys nodig naar de tabellen Groep, Speltak en Subgroep. Diplomas heeft een foreign key naar Examens. De beide koppeltabellen hebben foreign keys naar zowel gebruikers als respectievelijk Diplomas en Examens. De koppeltabellen bevatten niet meer dan een samengestelde key naar een gebruiker en naar een examen of diploma, en de GebruikerExamens-tabel bevat ook die uitslag van dat examen per gebruiker.

Ik denk dat je, als je uitgaat van bovenstaande tabellen en beknopte uitleg, wel vooruit moet komen. Zoek maar even op foreign keys en compound (samengestelde) keys als je niet helemaal weet wat dat is. Overigens zou ik voor elke tabel waarnaar je moet linken een ID-veld maken, ook als bijvoorbeeld een naam al uniek is. Dit omdat bij het linken een ID (integer) kleiner is dan een naam (string).

[Jaspertje]

Ik kom op de volgende tabellen:
- Gebruiker (PK = gebruikerid, FK = groepid, FK = SpeltakID)
- Groep (PK = groepid)
- Speltak (PK = SpeltakID)
- Diploma (PK DiplomaID)
- Examen (PK ExamenID)

Examen_Gebruiker (FK = ExamenID, FK = GebruikerID)
Diploma_Gebuiker (FK = DiplomaID, FK = GebruikerID)

Nog een aantal opmerkingen:
-Een praktijk en theorie examen zijn 2 verschillende zaken!
-Wat is een subgroep?

(Ik kom geloof ik op hetzelfde ls -NMe-)

[NMe]

Jaspertje schreef op dinsdag 31 mei 2005 @ 11:54:
Nog een aantal opmerkingen:
-Een praktijk en theorie examen zijn 2 verschillende zaken!

Hangt ervanaf. Als elk examen bestaat uit een theoriedeel en een praktijkdeel, dan kun je in principe aparte velden daarvoor opnemen in één tabel. Als niet alle examens een theorie- en een praktijkdeel hebben, of als de velden voor theorie- en praktijkexamens exact hetzelfde zijn, dan kun je beter twee records maken in je examen-tabel; een voor elk subexamen.

(Ik kom geloof ik op hetzelfde ls -NMe-)

Weet ik wel zeker. Nou ja, globaal dan.

Overigens:

Examen_Gebruiker (FK = ExamenID, FK = GebruikerID)
Diploma_Gebuiker (FK = DiplomaID, FK = GebruikerID)

De beide foreign keys hier zijn samen een compound primary key. Verder zou Examen_Gebruiker nog een veld "resultaat" kunnen gebruiken, aangezien dat niet thuishoort in de examentabel. (Meerdere mensen kunnen hetzelfde examen doen, maar een persoon kan ook meerdere examens doen.)

Verder missen er natuurlijk meer veldnamen, maar als je bekend bent met de normalisatieregels dan moet dat geen probleem zijn om in te vullen.

[J_Davelaar]

Het is iig leuk om te zien dat jullie op dezelfde tabellen komen als ik/mij.

Dan zit ik iig in de juiste richting. Alleen hoe weet ik nu zeker dat het dan allemaal netjes genormaliseerd is. Ik kwam namelijk op hetzelfde door gezond verstand en er goed over nadenken.

Ik zal voor de examens te denken aan de volgende structuur:

code:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
| DiplomaID | Vraagnummer | Praktijk/Theorie | GebruikerID | Behaald  |
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

En dan als compoundkey de eerste 3 kolommen. Kan dat?

offtopic:
Praktijk en Theorie zijn idd aparte examens, maar worden wel samen weergegeven in de overzichten. Maar dit is prima te koppelen en dus geen probleem.

Ik heb het even een subgroep genoemd omdat geen betere naam wist. Het gaat om verschillende scoutinggroepen en iedereen noemt het anders. Mensen die er ervaring mee hebben zullen de volgende namen misschien herkennen:
nest = golf = bak = vaandel = enz enz enz.
Hier zijn heel veel namen voor en iedereen gebruikt een andere (afhankelijk van land, zee, lucht scouting enz)

[ Voor 18% gewijzigd door J_Davelaar op 31-05-2005 12:12 ]

[T-MOB]

J_Davelaar schreef op dinsdag 31 mei 2005 @ 12:06:
Het is iig leuk om te zien dat jullie op dezelfde tabellen komen als ik.

Dan zit ik iig in de juiste richting. Alleen hoe weet ik nu zeker dat het dan allemaal netjes genormaliseerd is. Ik kwam namelijk op hetzelfde door gezond verstand en er goed over nadenken.

Grofweg als je 1) geen dubbele data in je database hebt staan en 2) geen (/nauwelijks) lege velden hebt zit het meestal wel goed.

[NMe]

J_Davelaar schreef op dinsdag 31 mei 2005 @ 12:06:
Het is iig leuk om te zien dat jullie op dezelfde tabellen komen als ik/mij.

Dan zit ik iig in de juiste richting. Alleen hoe weet ik nu zeker dat het dan allemaal netjes genormaliseerd is. Ik kwam namelijk op hetzelfde door gezond verstand en er goed over nadenken.

Ik zal voor de examens te denken aan de volgende structuur:

code:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
| DiplomaID | Vraagnummer | Praktijk/Theorie | GebruikerID | Behaald  |
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

En dan als compoundkey de eerste 3 kolommen. Kan dat?

Dat komt op mij een beetje vreemd over. Waarom heeft een examen een diplomaID? Als je een examen niet haalt, dan heb je er geen diploma voor. Andersom zou het wel werken: een diploma kan een examenID hebben.

Verder: wat is vraagnummer? Wil je alle vragen apart opslaan in de database? Dan heb je waarschijnlijk een extra vragen-tabel nodig, die weer gelinkt is aan de examen-tabel. Eventueel heb je dan zelfs een extra koppeltabel nodig voor de antwoorden van elke gebruiker op elke vraag.

Voor de examentabel heb je volgens mij maar een enkelvoudige key nodig, namelijk een examenID.

[J_Davelaar]

Ik zit voornamelijk met de uitslagen van de examens. Je kan meerdere keren over een examen doen en dus steeds een aantal punten halen.
Nu heb ik nog 1 grote tabel waar voor elke gebruiker alle punten instaan (in 1 rij). Alleen is dat heel lastig omdat niet elk examen evenveel punten heeft. Nu dacht ik met deze tabel te kunnen zoeken op soort diploma en gebruiker. Dan weet ik welke punten van hem zijn en bij welke vraag die horen en of dat praktijk of theorie is.

[Jaspertje]

Dan komt er een koppeltabel tussen Examen en Gebruiker.. met een extra flag gehaald (true/false)

[NMe]

Jaspertje schreef op dinsdag 31 mei 2005 @ 13:51:
Dan komt er een koppeltabel tussen Examen en Gebruiker.. met een extra flag gehaald (true/false)

Je kan het ook meerdere keren proberen en steeds niet halen. Als dat opgeslagen moet worden is er een extra veld nodig als ID, en vervalt die compound key in die tabel. Uiteraard laat je de afzonderlijke foreign keys wel staan. Op die manier kun je alle historische gegevens op blijven vragen waar nodig.

[J_Davelaar]

-NMe- schreef op dinsdag 31 mei 2005 @ 13:57:
[...]

Je kan het ook meerdere keren proberen en steeds niet halen. Als dat opgeslagen moet worden is er een extra veld nodig als ID, en vervalt die compound key in die tabel. Uiteraard laat je de afzonderlijke foreign keys wel staan. Op die manier kun je alle historische gegevens op blijven vragen waar nodig.

Als een punt eenmaal behaald is wordt het aangetekend en dan is het klaar.

Alleen voor de examen is het van belang om te weten omdat ze een maximaal aantal herkansingen hebben. Hierna vervallen alle punten voor dat diploma. Dus daar heb ik idd een koppel tabel voor een many to many relatie.