Redundatie is niet meer dan het voorkomen van dubbele gegevens. In jouw geval is het duidelijk waar dat gaat plaatsvinden als je aparte tabellen maakt voor Klanten en Leveranciers: zodra een klant ook leverancier is, heb je dubbele records. En dat betekent bij mutaties dat je die ook 2 keer moet uitvoeren. Dat is uiteraard geen gewenste situatie.
Bij het opzetten van een database moet je in eerste instantie uitgaan van de gegevens die je gaat opslaan. Daarbij verdeel je die gegevens in bij elkaar horende objecten die we dan
entiteiten noemen. Een persoon is daarbij een entiteit, en een artikel ook. Een persoon heeft andere eigenschappen (noemen we:
attributen) dan een artikel. Een persoon die een
klant is, heeft in principe dezelfde attributen als een persoon die
leverancier is. Of een werknemer. Hij heeft een naam, een email adres, een woonadres en ga zo maar door. Regel één van normaliseren is dat je entiteiten die dezelfde attributen hebben bij elkaar zet in een tabel. Dat leidt er dus toe dat je
personen bij elkaar zet in één tabel.
Dat levert een probleem op als het gaat om het onderscheid dat je tussen die personen wilt maken, want een persoon kan dus klant zijn of leverancier. Dat is simpel op te lossen met een extra veld waarin je de status aangeeft. Eventueel een extra tabel, of een veld met meerdere waarden. Dat laatste is database technisch minder handig als je wilt kunnen upgraden naar een hogere database zoals een SQL server, omdat dat soort databases alleen velden erkent waarin unieke waarden zijn opgeslagen. Het (redelijk nieuwe) veld met meervoudige waarden dat je tegenwoordig in Access hebt, slaat dat principe volledig omver, en daarmee ben je dus veroordeeld tot het gebruik van Access. Iets om in het achterhoofd te houden!
Zo'n personen tabel levert wel weer andere problemen op, want je hebt ook te maken met
bedrijven. Een bedrijf is weer een eigen entiteit, en dient dus een eigen tabel te krijgen. Voor bedrijven geldt dan weer dat een bedrijf een adres heeft etc, gegevens dus die je ook in de personen tabel hebt opgeslagen. Dat zou er toe kunnen leiden dat je voor de adresgegevens een aparte tabel maakt. Of je volstaat met het invullen van postcode en huisnummer, waarna je op basis van een postcodetabel de adresgegevens ophaalt. Dat principe gebruik je dan natuurlijk ook in de personen tabel.
Daarnaast heeft een bedrijf kenmerken die niet voor een persoon opgaan, zoals: meerdere filialen en meerdere werknemers. Dat los je dan ook weer op met aparte tabellen waarin je de gegevens koppelt. Een filiaal is in beginsel niet veel anders dan een bedrijf, dus je kunt ook (mijn voorkeur) een filiaal ook als een bedrijf invoeren in de Bedrijven tabel met een verwijzing naar het bovenliggende filiaal. Daartoe volstaat een extra veld in de Bedrijven tabel waarin je dus onderscheid ziet tussen hoofdfilialen (die hebben géén waarde in het veld ParentID) en filialen, waarin je in het veld ParentID de waarde invult van het hoofdfiliaal. Met deze constructie kun je een filiaal óók nog eens dochterfilialen laten hebben, want die krijgen dan een verwijzing naar wat voor hun de ParentID is.
Werknemers van een bedrijf zet je in een koppeltabel waarin je dus een verwijzing opneemt naar het BedrijfID, en (werknemers zijn net mensen) een verwijzing naar het PersoonID uit de personentabel. Want we hebben al vastgesteld dat entiteiten die dezelfde atrributen hebben in één tabel komen te staan. Van een werknemer van een bedrijf heb je waarschijnlijk geen adresgegevens, maar die hoef je dan uiteraard niet in te vullen. Je kunt er ook voor kiezen (heb ik hierboven ook al aangehaald) om de adresgegevens los te koppelen van de tabellen waarin ze voorkomen. Dan maak je dus een aparte tabel voor adressen, en bij entiteiten waar dat nodig is (klanten, bedrijven) vul je de adreskaart in. Op die manier hou je de tabellen klein en overzichtelijk.
Voor ZZP-ers heb je een iets andere constructie nodig, want dat zijn eigenlijk ook bedrijven, maar dan éénmansbedrijven. Met dus dan 2 adressen, één als persoon en één als bedrijf. Ook hier geldt het voordeel van een aparte adrestabel; je kunt in beide tabellen (persoon en bedrijf) verwijzen naar hetzelfde adresID en bij adresmutaties hoef je dan maar één adres te muteren.
Om op je laatste vraag terug te komen: aparte tabellen voor klanten en leveranciers is dus niet altijd aan te raden. Zijn het absoluut (altijd één van de twee en ook toekomstig nooit overlappend) verschillende entiteiten, dan kan het handig zijn om de 2 te scheiden. In jouw geval dus niet
.
