... wat betreft is er werk aan de winkel. De persoon die er mee werkt vind het niet zo belangrijk, ... Dat de 'de dag' , 'maand' , jaartal wordt opgegeven heeft de maken met bijvoorbeeld een rapport ouderen boven de 80 jaar die een presentje krijgen of de maanden die worden per maand een lijst gemaakt voor verjaardagen/verjaardagfonds. Wellicht kan dit anders, maar de meesten hebben wel hun doel.
Dit soort opmerkingen verraadt een gebrek aan database kennis. Daar kan ik jou uiteraard niet op afrekenen, want dat heb je of dat heb je niet. Kwestie van leren en/of lezen. Degene die de database gemaakt heeft, had het in ieder geval niet. Databases maak je op basis van een aantal regels, die we 'normaliseren' noemen. Dat proces bestaat uit een aantal lagen, waarbij elke normaalnorm staat voor alles wat aan de lagere normaalnormen voldoet, + nieuwe eisen. Zo is de 1e Normaalvorm de laagste norm, de 2e Normaalnorm is 1e Normaal + nieuwe regels, de 3e normaal is de 2e Normaal + nieuwe regels. Het is usance om in ieder geval te zorgen dat je database voldoet aan de 1e normaal, maar liever ook aan de tweede. En als je de derde haalt: helemaal perfect
. De vierde en vijfde worden meestal al niet gedaan in kleine databases.
Wat ik hiermee bedoel te zeggen, is dat deze database dus aan geen enkele normaalvorm voldoet, en dat levert gewoon problemen op. Dat de
gebruiker dat niet ziet, snap ik nog wel (gebrek aan kennis), maar het is aan de
ontwerper om er voor te zorgen dat die gebruiker sowieso geen fouten kan maken! En daar komt het normaliseren dus om de hoek kijken. Hoe dan ook: de regels zijn ontworpen om de gegevens van de database structureel foutloos te maken, zodat een gebruiker geen fouten meer
kan maken. En dat wil toch iedereen?
Eén aspect van goed database ontwerp is dat je gegevens
die af te leiden zijn van een ander gegeven niet opslaat in de tabel. En dat geldt dus volledig voor Dag, Maand en Jaar: die gegevens haal je uit de Geboortedatum (in dit geval). Als je een verjaardag wilt bereken, dan gebruik je dus een formule in een query die gebruik maakt van het veld Geboortedatum. En dat is een vrij makkelijke formule.
Maar je slaat die gegevens dus niet op in de database! Gooi die velden dus weg, en haal de gegevens uit de velden die je daarvoor hebt. Conclusie: de opmerking "de meesten hebben wel een doel" is onjuist.
Op een iets dieper niveau heb je hetzelfde probleem met Gezinnen en Personen. Gezinsleden zijn namelijk óók personen, en daarvoor volstaat dus één tabel. Wél zou ik de adressen in een aparte tabel opslaan, maar dus
zonder persoonsgegevens. Wél met een ingangsdatum en einddatum, want hoe je het ook wendt of keert: mensen verhuizen. En hebben dan een ander adres. En kinderen verlaten het gezin, en gaan op zichzelf wonen. Daarbij kan je de situatie krijgen dat ze naar een andere stad verhuizen, en dan nog wél onderdeel zijn van de 'familie', maar niet meer van 'het gezin'. Want een
gezin is gebonden aan een locatie, een familie niet.
Daarnaast kunnen familieleden zélf weer een gezin stichten, al dan niet met behoud van lidmaatschap omdat ze in dezelfde plaats blijven wonen. En dat wil je toch allemaal willen kunnen vastleggen? Wat ík dus zou doen, is een adressentabel met een AdresID, en dat adres in de tabel Kadat koppelen aan de personen. En de familiestructuur van die tabel kan dus ook wat anders: sowieso een veld PartnerID erbij, en twee velden OuderID (voor elke ouder één). Dan begin je met het invoeren van twee getrouwde personen (waarvan de ouders niet bekend zijn in de database) dus die velden blijven bij hun leeg). Vervolgens voer je de kinderen in, waarbij je de OuderID's invoert. Op die manier heb je een koppeling gelegd tussen de ouders en de kinderen.
Gaan de kinderen het huis uit, dan krijgen ze een eigen adres, en dan voer je dat nieuwe adres in in de adres tabel, en in de Persoontabel vul je dan bij die persoon een AdresID in. Daarmee heb je dan het kind 'verwijderd' uit het gezin (eigen adres) maar níet uit de familie (de ouders zijn nog gekoppeld). En met deze werkwijze kun je alle gevallen perfect registreren. En het mooie is: op deze manier kun je werkelijk
alles opvragen uit de database. Je kunt de vraag zo gek niet stellen, of je kunt hem uit de database halen. En dát is dus de reden om een database
goed te normaliseren
.
In de Access cursus die je in de Handleiding sectie kan vinden, heb ik e.e.a. uitgelegd aan de hand van een voorbeeld database. Deze cursus is overigens geschreven voor de versie die jij nu in de prullenmand hebt gegooid; hij is zo'n 10 jaar oud. Maar de theorie staat nog recht overeind!
