normaliseren van tabel

[ikselle]

Ik ben nieuw in Access (2007) en zit met volgende vraag.
Er dient een database aangelegd om gegevens van bezoekers aan een openbare instelling bij te houden. Deze bezoekers moeten een geldig authentiek document (identiteitskaart, verblijfsvergunning, rijbewijs,...) afgeven bij hun binnenkomst en krijgen dit terug bij het buitengaan.
Er wordt bijgehouden :
1) de datum van het bezoek
2) de deur waarlangs de bezoeker binnen komt (er zijn verschillende toegangen)
3) het nummer van de identiteitskaart of
4) het nummer van het andere in bewaring gegeven document
5) de naam van de bezoeker
6) de voornaam van de bezoeker
7) de naam van de bestemmeling
8) het aankomstuur van de bezoeker
9) het vertrekuur van de bezoeker
Wetende dat een bezoeker 's morgens kan komen en diezelfde dag nog eens kan terugkeren, dat hij daarom niet per se naar dezelfde bestemmeling gaat...
Query's en formulieren maken lijkt mij maar een fluitje van en cent; het is het normaliseren waar ik problemen mee heb. Vandaar mijn vraag:
Hoe kan ik deze tabel best normaliseren? Welke relaties moet ik vervolgens leggen ? Kan iemand mij daarbij helpen?
Bedankt in ieder geval!

 

[OctaFish]

Deze tabel is, zoals je hem nu beschrijft, prima. Daar valt eigenlijk weinig aan te normaliseren... Hooguit kun je een extra tabel maken voor de verschillende ingangen, waar je een keuzelijst van kan maken op je formulier. Deze tabel mag je koppelen aan je datatabel, maar dat hoeft niet eens, omdat je alles via een formuier invult, en de keuzelijst laat dan alleen de aanwezige ingangen zien. Dat geldt dan ook voor de Bestemmingen. Je kunt dus al geen verkeerde keuze maken voor deze velden. De rest van de gegevens is puur eenmalig (wat betreft de database) en hoef je dus niet apart vast te leggen. Tenzij je met een vast ledenbestand werkt, en alle bezoekers dus bekend zijn. Maar dat zal hier niet zo wezen, neem ik aan...

 

[ikselle]

Bedankt voor je snelle reactie Michel. Misschien zoek ik het te moeilijk maar ik dacht dat je alle gegevens die zich herhalen zo veel mogelijk moet vermijden. Een bezoeker kan zich dus dagelijks meerdere keren aanbieden nu eens met zijn identiteitskaart, dan met zijn rijbewijs, ...Ik vind heel die normalisering niet zo makkelijk. Toch bedankt!

 

[OctaFish]

Normaliseren is inderdaad wel dat je herhalende gegevens in aparte tabellen zet, dat heb je goed gezien. Maar je moet daarbij aan het geheel van de herhalende gegevens denken. En die zijn er eigenlijk niet in jouw geval. Want het zijn feitenlijk allemaal unieke records. Je geeft zelf al aan, dat één persoon verschillende identiteits documenten mag afgeven. Dat houdt automtisch al in, dat je een bezoeker dus niet kunt identificeren in je db aan zijn identiteitsbewijs (wat uteraard op zich wel afdoende zou moeten zijn.... een paspoort zul je maar bij één persoon aantreffen als het goed is).
Wil je toch gaan splitsen, dan moet je dus een aparte tabel maken voor de bezoekers, waar je een eigen sleutelveld voor moet gebruiken, en een aparte tabel voor de ruimtes die betreden worden met een nieuwe entreeregistratie. Dan krijg je zoiets:

1) BezoekerID
2) de datum van het bezoek
3) het nummer van de identiteitsbewijs
4) het soort identiteitsbewijs
5) de naam van de bezoeker
6) de voornaam van de bezoeker
7) vertrekdatum

1) BezoekerID
2) Entreepoort
3) Naam van de bestemming
4) het aankomstuur

Daarbij zit je (denk ik) met het probleem dat je op verschillende lokaties moet bijhouden wat de beweging van de bezoeker is. Als hij ruimte B betreede en ruimte B dus verlaat, moet je dat op die plek kunnen vastleggen.
Uiteindelijk moet een bezoeker ook weer vertrekken, dus je hebt ook een vertrektijd nodig, die dan automatisch inhoudt dat het ingenomen identiteitsbewijs ook weer is teruggegeven.

 

[ikselle]

Een bezoeker gaat ook weer buiten langs waar hij binnenkwam. Dus dat is niet echt een probleem. Maar ik was geneigd de tabel als volgt te splitsen :
1) BezoekerID
2) het nummer van de identiteitsbewijs
3) het soort identiteitsbewijs
4) de naam van de bezoeker
5) de voornaam van de bezoeker

1) BezoekerID
2) Entreepoort

1) BezoekerID
2) Naam van de bestemming

1) BezoekerID
2) Datum van bezoek
3) Aankomstuur
4) Vertrekuur

Is dit moeilijk, is dit niet nodig of ....

 

[OctaFish]

Is er een reden waarom je de Entreepoort zou scheiden van de Bestemming? Mij lijkt bestemming fysiek verbonden te zijn met de entreepoort. Maar ik ken uiteraard jouw situatie niet. Een vertrekuur registreren kan uiteraard wel, maar zelf zie ik daar het nut niet zo van in. Ik dacht zelf dat het betreden van ruimte B automatisch inhoudt dat je ruimte A hebt verlaten. Dat idee vind je dus ook terug in mijn opvatting dat de Entreepoort is gekoppeld aan de bestemming. Een vertrekuur registreren heeft alleen zin als er een significante tijdsspann zit tussen het verlaten van Ruimte A en het betreden van Poort B. Als je per poort verschillende bestemmingen kunt hebben, en voor elke bestemming en voor elke poort heb je weer een identificatie nodig (we hebben het hier toch niet over het Pentagon?) dan zijn gescheiden tabellen wel te overwegen. Anders (één poort, één bestemming) zou ik het toch in één tabel houden. Maar dan zouden we toch iets meer moeten weten over de opzet van de instelling...

 

[ikselle]

Sorry dat ik zo laat antwoord maar ter verduidelijking :
Het gaat hier over één gebouw met verschillende bezoekerstoegangen. Buiten het feit dat ik zou willen registreren wie (naam, voornaam), waar(ingang), wanneer (datum, in_uur) en naar welke bestemm(el)ing ging, wil ik ook weten of de persoon in kwestie het gebouw verlaten heeft (brandveiligheid) en hoelang dat hij in hte gebouw verbleef.
Ziezo dat is een beetje de schets van de situatie.
Dus een persoon kan zich 's morgens aanbieden om mr. X te bezoeken, het gebouw verlaten en 's namiddags via een andere poort zich opnieuw aanbieden om deel te nemen aan één of andere activiteit.
Meer is dit allemaal niet. En als beginnend gebruiker van access vraag ik me dan ook af hoe ik de kaap van de normalisering (die volgens meerdere auteurs toch zo belangrijk is) moet nemen. Ik vraag me inderdaad ook af of ik door het splitsen van deze tabel wel zoveel winst maak ... en is schijfruimte tegenwoordig niet van minder belang??

 

[OctaFish]

Schijfruimte is in die zin van belang, dat een Access database nog steeds aan een maximum grootte is gebonden, afhankelijk van de versie. Maar die zul je, met een eenvoudige database, niet zo snel benaderen. Wat belangrjker is, is het aantal personen dat je met de database wilt laten werken. Als er op verschillende locaties moet worden geregistreerd, heb je vermoed ik meerdere werkplekken die tegelijk in de db werken. En dat aantal is dus wel interessant om mee te nemen in het verhaal.
Wat betreft je normalisering: Je moet jezelf de vraag stellen hoe belangrijk het is om de persoonsgegevens genormaliseerd op te slaan. Doorgaans zullen 'enkelvoudige' bezoekers geen relatie hebben met de overige gegevens, en heeft het niet zoveel zin om die op te slaan. Denk bijvoorbeeld aan een museum, die de gasten een kaartje geeft waarmee ze het museum in kunnen. Die hoeven niet te weten hoe iemand heeft, zolang het toegangsbewijs maar geldig is. Praat je over 'regelmatige' bezoekers, bijvoorbeeld van contactpersonen van bedrijven waar je een relatie mee hebt, dan heeft het wel weer zin om die contactgegevens op te slaan.
Normaal gesproken zeg je: als een persoon een handeling herhaaldelijk uitvoert, dan wil je de gegevens genormaliseerd hebben. Bij een bezoeker houdt dat dan in: persoonsgegevens apart opslaan, en de bewegingen in het pand apart opslaan. Gaat het echter maar om hooguit twee of drie bewegingen per persoon, en komt die persoon daarna niet meer terug, dan ben je eigenlijk bezig om je gegevensbestand te verdubbelen (twee tabellen i.p.v. een) met als enige 'winst' dat je bij het vastleggen van de bewegingen van de persoon de beschikking hebt over diens naamgegevens. Je kunt jezelf afvragen, of die winst zinvol is of niet. Want je kunt ook elke keer opnieuw het identiteitsbewijs vastleggen, en alleen de eerste keerd de naamsgegevens vragen. Dan heb je eigenlijk ook de naamsgegevens genormaliseerd.

 

[ikselle]

Bedankt Octafish voor je reacties. Ik zal zelf proberen het normailseren te beperken en dan wel zien of er achteraf nog iets moet gewijzigd worden. :thumb: