Als je nog een leek bent in Access, zou ik je in eerste instantie aanraden om je eerst eens goed in te lezen in hoe je een database opzet. Daarvoor kun je de Access cursus gebruiken in de handleidingen sectie bijvoorbeeld; de eerste hoofdstukken gaan over het opzetten van een goede structuur en het normaliseren van een database. Jouw tabel zou wellicht in Excel prima werken, maar dus niet in een database. Je moet daarbij (het inrichten) dus eerst goed op papier hebben welke informatiestromen je hebt, en hoe je werkprocessen lopen. Op basis daarvan ga je de gegevens groeperen in tabellen.
Simpel voorbeeldje op basis van jouw db: je hebt dus blijkbaar klanten die reparaties laten doen. Een klant is een 'entiteit' zoals we dat noemen; een specifiek object, maar een klant is geen horloge. Een horloge is óók een entiteit, maar is weer géén klant. Zet alle klanten bij elkaar met hun spullen die ze bij jou laten repareren, en het is niet zo moeilijk om de verschillen te zien. Een reparatieobject heeft een merk en een eigenaar, een klant is doorgaans een mens met een naam en een adres, en is merkloos. Voor mensen (klanten) heb je dus een aparte tabel nodig waarin je de klanteigenschappen opslaat. Een naam is een 'attribuut' van een klant, en een adres ook. Weet je het Klantnummer, dan weet je dus waar die klant woont en hoe hij heet. Een horloge daarentegen is géén attribuut van een klant: kijk naar jezelf: vandaag heb je de Rolex om, en morgen de Breitner. En overmorgen het goedkope prul uit China. Elk horloge an sich is een eigen object, maar een horloge kan dus de ene dag bij Jan om de pols zitten, en de volgende dag bij Piet. Kortom: (het is een simpel voorbeeld, maar daarom wel duidelijk hoop ik) een horloge
kan nooit een eigenschap van een klant zijn. En daarom mag een horloge (of welk ander reparatieobject dan ook) nooit in een klantentabel worden opgeslagen.
Een reparatie is een
gebeurtenis. Gebeurtenissen leg je vast in een aparte tabel, en per gebeurtenis leg je bijvoorbeeld de datum(s) vast. Bij reparatie bijvoorbeeld de datum van binnenkomst en de datum waarop het gerepareerde artikel wordt opgehaald. Tevens leg je vast welk object je repareert, en de eigenaar (=klant). Omdat een klant meerdere reparaties moet kunnen doen, leg je een één-op-veel relatie tussen Klantentabel en Reparatietabel. Dat houdt dan in: één klant mag veel reparaties doen.
Wat jij in bericht #8 een historie tabel noemt, is dus eigenlijk een hele normale procesgang. Een historietabel is in mijn ogen ook iets heel anders; dat is een tabel waarin je
mutaties vastlegt voor het nageslacht. Stel dat een klant verhuist. Simpel: je verandert het adres van de klant en je tabel is weer helemaal bij. Maar nu ben je dus het vorige adres van de klant kwijt! Wil je die informatie bewaren, dan moet je die dus ergens opslaan. Welnu, daar gebruik je historietabellen voor. Maar in jouw structuur speelt dat dus nog niet; je moet eerst de gewenste datastromen voor jezelf goed in kaart brengen.
