Normaliseren van tabellen Inleiding Uit het voorgaande blijkt duidelijk dat de grote hoeveelheid informatie die verzameld worden in een database verspreid zitten over verschillenden tabellen. Dit is een duidelijk onderscheid met een Excel-werkblad dat gebruikt wordt om gegevens bij te houden. In een Excel-werkblad wordt alle informatie in één blad weergegeven en wordt zeer veel informatie meerdere keren opgeslagen. Een voorbeeld : een klant komt in een doe-het-zelf-zaak wat gereedschap kopen om een herstelling uit te voeren in zijn huis. De verkoper moet hiervan een factuur maken. Dit betekent dat hij de gegevens eerst moet opslaan om daarna te kunnen afdrukken. In een Excelblad zouden de gegevens als volgt worden bijgehouden : Mochten we bij deze tabel nog de leverancier van het artikel willen opslaan om later het artikel te kunnen bestellen wordt deze tabel totaal onbeheersbaar. Wat valt je op in deze tabel : - er is heel wat informatie die verschillende keren ingevoerd en bewaard worden (klantnummer, klantnaam, klantadres, klantpostnummer.). Dergelijk manier van werken gebruikt veel schijfruimte, geeft veel netwerkverkeer en vraagt veel rekencapaciteit voor de processor van je computer. Al deze gegevens moeten namelijk ingelezen en verwerkt worden. - er kunnen tikfouten ontstaan door steeds dezelfde informatie manueel te moeten intikken (telefoonnummer, prijs hamer, ) - het wordt moeilijk om iets terug te vinden in dergelijke lijst er is geen duidelijk overzicht door de veelheid aan informatie - wanneer klantgegevens verandert (bvb. Adres) moet dit meerdere malen worden ingevoerd met de kans hier en daar een adres te vergeten. Hetzelfde geldt voor artikelgegevens (prijzen, Btw-tarieven, ) 1 Frank Van Oost
Enkele bezwaren voor dergelijke rangschikking zijn : 1. De tabel wordt onbeheersbaar groot : Telkens een bestelling wordt toegevoegd moeten al de gegevens herhaald worden wat een enorme tabel oplevert. 2. Gegevens zijn moeilijk te onderhouden en te actualiseren Bij een adreswijziging van een klant of een prijswijziging van een artikel moet de volledige tabel overlopen worden om de aanpassing uit te voeren. Dit geeft veel werk en kans op fouten. 3. Dergelijk tabelontwerp verspilt veel schijfruimte, werkgeheugen en processortijd Omdat veel informatie tegelijk moet worden verwerkt wordt het geheugen en de processor van de pc nodeloos belast. Als de gegevens dan nog over een netwerk moeten worden getransporteerd wordt ook het netwerk overdadig belast waardoor het netwerk trager wordt en andere gebruikers, die zelfs deze toepassing niet benutten, ook de kwalijke gevolgen van een slecht databaseontwerp onder vinden. Om deze nadelen zoveel mogelijk te vermijden wordt in een database de informatie verspreid over verschillende tabellen die onderling aan elkaar gekoppeld zijn. We spreken hier van een relationele database. De tabellen hebben onderling een relatie, waardoor de samenhorende informatie ook gemakkelijk terug kan samengesteld worden. De verdeling van de gegevens over verschillende tabellen verloopt volgens bepaalde eenvoudige regels : normalisatieregels. Eerste normaalvorm : elke cel van een tabel mag uitsluitend één waarde bevatten en de tabel mag geen herhalende groepen gegevens bevatten. Tweede normaalvorm : Gegevens die niet rechtstreeks afhankelijk zijn van de primaire sleutel van de tabel worden naar een andere tabel overgebracht. Derde normaalvorm : Alle velden die kunnen afgeleid worden van gegevens die zich in andere tabellen bevinden moeten worden verwijderd. 2 Frank Van Oost
Het enige doel van normalisatie is het maximaliseren van de prestatie van de database met een minimale inspanning om de tabellen te onderhouden. Bij een niet-genormaliseerde database kunnen drie soorten fouten optreden : - Invoegfout : wanneer een bestelling afgewerkt is en de manuele berekeningen opgeslagen zijn en de klant belt terug om nog extra exemplaar van een artikel te bestellen mag je alle berekeningen opnieuw gaan maken en opslaan. Het risico is groot dat dit vergeten wordt of dat er fouten worden gemaakt. Vandaar dat het belangrijk is om berekende waarden automatisch te laten berekenen door de database zelf zonder ze op te slaan. Wanneer de totalen nodig zijn kunnen ze steeds door het systeem foutloos herrekend worden. - Verwijderingfouten : wanneer een bestelling wordt geschrapt gaan misschien ongewild gegevens verloren. In voorbeeld zouden bij het schrappen van een volledige bestelling van een klant naast de gegevens van de artikels ook zijn adresgegevens verdwijnen en dit is niet wenselijk mocht je later deze klant willen contacteren. - Updatefouten : wanneer een gegeven wijzigt (adreswijzigingen, prijswijzigingen, Btwtariefwijzigingen, ) is er zeer veel kans dat je in de ellenlange lijst wel hier en daar een gegeven vergeet aan te passen. Wanneer bijvoorbeeld de artikels in één tabel zijn opgenomen moet je slechts op één plaats de wijziging doorvoeren en automatisch wordt deze overal aangepast. Normaliseren van onze eigen database De verschillende normaliseervormen gaan we toepassen op onze eigen database Contactpersonen. In de onderstaande tabel gaan we uit van een tabelstructuur die we zouden hebben gemaakt en gaan we deze stap voor stap normaliseren. We gebruiken hiervoor de gegevens uit het Excelwerkblad : Normalisatie van tabellen.xlsx. De tabel in Situatie A toont een aantal problemen/fouten die kunnen sluipen in niet genormaliseerde tabellen : - Intikfouten : in record 3 werd Antwerpen verkeerd ingevoerd. Dit heeft als gevolg dat bij het opzoeken van alle inwoners van Antwerpen dat record 3 niet in de lijst zal zijn opgenomen. Dit zou kunnen opgelost worden door te zorgen de gemeente uit een lijst kan gekozen worden. - Meerdere waarden staan in één veld (cel) opgenomen : in dergelijke tabel is het zeer moeilijk om bijvoorbeeld te sorteren volgens een bepaalde waarde. Het is ook moeilijk alle personen uit de lijst te halen die collega zijn, want bij de ene persoon is dat de eerste waarde die vermeld is, bij een andere is dat een tweede waarde die vermeld wordt. Het is altijd mogelijk om die gegevens uit de lijst te halen maar in sommige situaties zal dit zeer moeilijk en traag verlopen. Op die manier is de indexering van de tabellen moeilijk en tijdrovend. 3 Frank Van Oost
- Gegevens die kunnen achterhaald worden door een gegeven uit een ander veld zijn overbodig. De leeftijdsaanduiding is eigenlijk van geen waarde want deze informatie is het volgende jaar achterhaald en alle leeftijden moeten aangepast worden. Beter is om een vast gegeven op te slaan (de geboortedatum) en telkens als het nodig is de leeftijd te berekenen. Dit vereenvoudigt duidelijk het onderhoud van deze tabel. - In deze tabel wordt verschillende keren dezelfde informatie herhaald. Het postnummer van Antwerpen is 2000. In deze beperkte tabel staat dit slechts 2 maal vermeld maar eigenlijk is de naam van de gemeente (in de meeste gevallen) overbodig. De gemeente met het postnummer 2000 is steeds Antwerpen. Dus eigenlijk is de informatie van de gemeente overbodig. We gaan stap voor stap deze tabel normaliseren. Stap 1 : Eerste normaalvorm : tabel mag geen herhalende groepen gegevens bevatten Deze tabel bevat een groep van gegevens die telkens worden herhaald. We hebben het hier over het postnummer en de gemeente. Deze gegevens moeten uit de tabel gehaald worden en in een afzonderlijke tabel worden ondergebracht. We kunnen een tabel maken met alle postnummer en gemeenten. Hieronder een uittreksel uit deze lijst Postnummer Gemeente 1000 Brussel 2000 Antwerpen 3000 Leuven 8000 Brugge 8200 Oostende 9000 Gent 9940 Evergem 9940 Kluizen 9940 Ertvelde Uit dit overzicht blijkt dat, wat op het eerste zicht evident lijkt, dat het postnummer geen uniek gegeven is. Bepaalde gemeentes hebben hetzelfde postnummer. Dit houdt database-technisch in dat de postnummer niet als uniek gegeven kan beschouwd worden het kan geen PRIMAIRE sleutel zijn. Om dat het aan te raden is om voor elke tabel een primaire sleutel te hebben zullen we een extra veld toevoegen met de eigenschap Autonummering zodanig dat elke record in deze tabel een veld heeft met een unieke waarde die als primaire sleutel kan worden gebruikt. 4 Frank Van Oost
De tabel zal er dan uiteindelijk als volgt uitzien : Gemeentenummer Postnummer Gemeente 1 1000 Brussel 2 2000 Antwerpen 3 3000 Leuven 2856 8000 Brugge 2857 8200 Oostende 2858 9000 Gent 2859 9940 Evergem 2860 9940 Kluizen 2861 9940 Ertvelde Dergelijke tabel noemen we een OPZOEKTABEL. De eerste tabel gaat zijn gegevens gaan opzoeken in de tweede tabel via de relatie tussen de primaire sleutel van de tweede tabel (gemeentenummer in de tabel Gemeenten ) en de secundaire sleutel (gemeentenummer in de tabel Contactpersonen ). Normalisatie : Op deze manier kunnen we in de eerste tabel met onze contactpersonen de groep gegevens postnummer en gemeente vervangen door het gemeentenummer. Op die manier wordt op een onbetwistbare manier gedefinieerd in welke gemeente elke persoon woont. Beginsituatie : 5 Frank Van Oost
Normalisatiestap : De stappen die ondernomen zijn om van de begin- naar de eindsituatie te komen vind je in het document : normalisatie van tabellen.xlsx eerste werkblad : herhalende groep van gegevens. Eindsituatie : Om nu een volledig beeld te krijgen van het adres van een bepaalde persoon, om dit bijvoorbeeld af te drukken op een etiket, zullen we later een selectiequery maken die we gebruiken om het etiket af te drukken. Stap 2 : Derde normaalvorm : Alle velden die kunnen afgeleid worden van gegevens die zich in andere tabellen of in dezelfde tabel bevinden moeten worden verwijderd. In onze tabel zien we dat in het veld Leeftijd een berekende waarde wordt opgeslagen. Dit gegeven is eigenlijk niet echt betrouwbaar omdat in verloop van tijd de leeftijd wijzigt. Je zou elke dag een aantal records moeten aanpassen want in een grote tabel is er wel altijd iemand die verjaart met als gevolg dat de leeftijd die vermeld wordt in de tabel niet meer klopt. Beter is een betrouwbaar en vast gegeven op te slaan. We gebruiken hiervoor beter de geboortedatum en berekenen indien 6 Frank Van Oost
nodig de leeftijd van de persoon op het moment dat we deze nodig hebben. Dit heeft als gevolg dat we niet elke dag onze tabel moeten updaten met nieuwe leeftijden. Stap 3 : tweede normaalvorm : Gegevens die niet rechtstreeks afhankelijk zijn van de primaire sleutel van de tabel worden naar een andere tabel overgebracht Een gegeven dat onlosmakend bij de primaire sleutel hoort mag in de tabel blijven staan. De andere velden moeten in een andere tabel worden opgenomen. Als we dit gaan toepasssen in de tabel Contactpersonen dan kunnen we volgende velden als onlosmakend beschouwen t.o.v. de primaire sleutel : Veld Verklaring ID Primaire sleutel dit is de unieke code van elke record Naam de record kan slechts één naam bevatten de persoon in kwestie heeft slechts één familienaam Voornaam hier geldt hetzelfde als hierboven. Mochten we nog een tweede, derde naam of de beginletters van de volgende namen willen opnemen moeten we hiervoor een of meerdere extra velden voorzien. Maar ook hier geldt dat deze gegevens onlosmakend verbonden zijn met de ContactID (de record waarin ze worden opgenomen) Adres Elke persoon woont op één adres. Heb je nu personen die meerdere adressen hebben dan moet je dit anders oplossen en zal blijken dat de adressen niet meer mogen opgenomen worden in deze tabel van Contactpersonen. Op dat moment zullen we een aparte tabel maken waarin de verschillende adressen van onze contactpersonen zijn opgenomen. Dit zal later nog zeker aan bod komen. Een voorbeeld kan zijn : leveringsadressen van firma s waarbij het niet ondenkbaar is dat één firma verschillende filialen heeft met uiteraard verschillende adressen. Postnummer Voor dat we de wijziging hebben aangebracht van gemeentenummer was het postnummer opgenomen. Dit gegeven is ook onlosmakend verbonden met de persoon. Een persoon kan (in normale omstandigheden) geen twee postnummers hebben. Gemeente Hoger hebben we gezien dat deze informatie verwijderd mag worden omdat deze eigenlijk een herhaling is van een gegeven die we al hebben via het postnummer. Er is ook gebleken dat er verschillende gemeentes hetzelfde postnummer hebben vandaar dat we een unieke code gegeven hebben aan elke gemeente, nl. het gemeentenummer. Dank zij het gemeentenummer kunnen we nu éénduidig de gemeente van een persoon achterhalen. Dit gemeentenummer hebben we in het veld postnummer geplaatst en het veld hernoemd naar gemeentenummer. Samengevat : het veld gemeente mag na de nodige wijzigingen aan de tabel (zie hoger) verwijderd worden uit de tabel. Telefoon Het telefoonnummer van een persoon is eigen voor deze persoon. Categorie De categorie van type contactpersoon is eigenlijk een aparte informatie die op zich niets te maken heeft met de contactpersoon. Het is een informatie die wij toevoegen om onze contactpersonen te kunnen 7 Frank Van Oost
catalogeren. Dergelijk informatie moet in een aparte tabel worden opgenomen. Een extra argument om dit gegeven apart te plaatsen is het feit dat iemand meerdere categorieën kan krijgen. Hij is bvb. een collega, en is tevens een tennispartner. Er zijn verschillende categorieën mogelijk vandaar dat we een nieuwe tabel maken met categorieën. Een tabel laat ons toe om later categorieën zonder veel problemen toe te voegen of te verwijderen. Alhoewel dit laatste soms gevaarlijk is maar daar zeker later nog meer. We maken een nieuwe tabel met de naam : Categorie. We nemen de volgende velden op : Veldnaam Gegevenstype Beschrijving CategorieID Autonummering Unieke code voor elke categorie C_Omschrijving Tekst Naam van de categorie CategorieID C_Omschrijving 1 Vriend 2 Collega 3 Tennisclub 4 Gezin 5 Barbecue 6 Familie 7 Werk Mochten we deze tabel als OPZOEKTABEL voor de tabel Contactpersonen beschouwen kan per record slechts één waarde worden toegekend (zoals bij het gemeentenummer). Omdat we gezien hebben dat bepaalde personen (records) meerdere categorieën kunnen hebben (een familielid kan ook een collega op het werk zijn, of een tennispartner) zullen we een ander type van tabel moeten maken. We noemen dergelijke tabel een RELATIETABEL. Deze tabel bevat de informatie die nodig is om de relatie tussen records van verschillende tabellen bij te houden. Concreet betekent dit dat we naast de tabel Contactpersonen en de Categorie een derde tabel gaan maken, nl. PersoonEnCategorie. Hierin gaan we bijhouden welke persoon welke categorieën heeft. Als we onze tabel Contactpersonen er bij nemen (zie hoger) dan kunnen we stellen dat de eerste record Smet Kathleen de categorie tennisclub heeft. Omdat we volgens de derde normaalvorm geen gegevens mogen opnemen in een tabel die uit een andere tabel kunnen 8 Frank Van Oost
afgeleid worden mogen we niet de naam en voornaam van Smet Kathleen opnemen in de nieuwe tabel. We moeten echter weten dat het hierover Smet Kathleen gaat. Hoe gaan we dit oplosssen? In de tabel tblcontactpersonen is er een veld dat een unieke waarde heeft voor Kahtleen Smet nl. de primaire sleutel ID. Voor Kathleen is dat de waarde 1. In de nieuwe tabel nemen we dan ook deze waarde op om aan te duiden dat we hier spreken over K.S. We moeten ook meegeven dat zij een kennis is uit de tennisclub. Dit is een bepaalde categorie, maar we mogen niet tennisclub mee geven omdat deze waarde af te leiden is uit de informatie uit de tabel tblcategorie. We nemen in de nieuwe tabel de unieke waarde voor de categorie tennisclub op de primaire sleutel C_Categorie -, nl. 3. De nieuwe tabel zal er dan als volgt uitzien : Veldnaam Gegevenstype Beschrijving PC_ID Autonummering Unieke code voor elke record in deze tabel C_ID Numeriek ContactID van de persoon aan wie we een categorie toekenen C_CategorieID Numeriek CategorieID van de categorie die we aan deze persoon willen toekennen. We maken deze tabel nu aan zoals we daar net de tabel Categorie hebben aangemaakt. We noemen deze tabel PersonenEnCategorie. Als we nu de gegevens van de tabel Contactpersonen verder willen normaliseren vullen we de nieuwe tabel als volgt op. Voor Smet Kathleen met categorie tennisclub wordt dat : PC_ID C_ID C_CategorieID 1 1 3 Voor Proot Jos met categorie werk wordt dat : PC_ID C_ID C_CategorieID 1 1 3 2 2 7 Voor Van de Velde Stefaan met categorie collega wordt dat : 9 Frank Van Oost
PC_ID C_ID C_CategorieID 1 1 3 2 2 7 3 3 2 Voor Dobbel Mien met de categorie vriend en collega wordt dat : PC_ID C_ID C_CategorieID 1 1 3 2 2 7 3 3 2 4 4 1 Maar omdat geen enkel veld twee waarden mag bevat (normalisatienorm 2) wordt een extra record toegevoegd voor Dobbel Mien : PC_ID C_ID C_CategorieID 1 1 3 2 2 7 3 3 2 4 4 1 5 4 2 Zo zal voor Bekaert Dirk 3 records worden toegevoegd want hij heeft 3 categorieën. PC_ID C_ID C_CategorieID 1 1 3 2 2 7 3 3 2 4 4 1 5 4 2 6 5 3 7 5 2 8 5 4 Deze tabel is uiteraard onleesbaar voor een gebruiker. Vandaar dat de gebruiker ook nooit in de tabellen mag kunnen kijken maar dat jij als programmeur een interface moet maken waardoor de gebruiker de gegevens via formulieren en rapporten kan gebruiken. Om nu deze tabel leesbaar te maken zodanig dat we zien wie welke categorieën heeft is het nodig van een selectiequery te maken die de drie tabellen Contactpersonen, Categorie en PersoonEnCategorie samen brengt. 10 Frank Van Oost
We maken deze oefening in onze eigen toepassing Eigen contactpersonen. We maken een nieuwe tabel met de naam : tblcategorie. We nemen de volgende velden op : Veldnaam Gegevenstype Beschrijving CategorieID Autonummering Unieke code voor elke categorie C_Omschrijving Tekst Naam van de categorie Op het lint kiezen we [Maken] - <TabelOntwerp>. Hier vullen we bovenstaande gegevens in. We houden geen rekening met de Veldeigenschappen die onderaan in het scherm kunnen toegevoegd worden. We bewaren de tabel door op het disketje te drukken onder de naam tblcategorie en drukken op <OK> We aanvaarden de primaire sleutel dat Access zal aanmaken en we drukken op <Ja>. We drukken nu linksboven in het lint op de knop <Weergave>. 11 Frank Van Oost
In het volgende scherm vullen we dan de verschillende categorieën in die we willen gebruiken. Later zullen we daar nog een invoerscherm voor moeten maken zodanig dat een gebruiker niet in de tabellen moet beginnen prutsen maar door een mooi invoerscherm de gegevens kan aanpassen (toevoegen, wijzigen, schrappen, ) Omdat we gezien hebben dat bepaalde personen (records) meerdere categorieën kan hebben (een familielid kan ook een collega op het werk zijn, of een tennispartner) zullen we een RELATIETABEL maken. Deze tabel bevat de informatie die nodig is om de relatie tussen records van verschillende tabellen bij te houden. Concreet betekent dit dat we naast de tabel tblpersonen en de tblcategorie een derde tabel gaan maken, nl. tblpersoonencategorie. Hierin gaan we bijhouden welke persoon welke categorieën heeft. 12 Frank Van Oost
De nieuwe tabel zal er dan als volgt uitzien : Veldnaam Gegevenstype Beschrijving PC_ID Autonummering Unieke code voor elke record in deze tabel P_IDPersoon Numeriek PersoonsID van de persoon aan wie we een categorie toekenen C_CategorieID Numeriek CategorieID van de categorie die we aan deze persoon willen toekennen. We maken deze tabel nu aan in Access zoals we daar net de tabel tblcategorie hebben aangemaakt. We bewaren de nieuwe tabel als tblpersonenencategorie. Primaire sleutel in deze tabel wordt : PC_ID (autonummering). Als we nu voor elk van deze personen een categorie willen toekennen gaan we de nieuwe tabel opvullen. Als we onze tabel tblpersonen er bij nemen en willen aan een aantal personen een categorie toekennen dan gaan we als volgt te werk. 13 Frank Van Oost
Boelaert Niels : vriend Bral Sander : gezin Bral Carlo : familie Cornelis Jean-Pierre : tennisclub, barbecue In de tabel tblpersonen is er een veld dat een unieke waarde heeft voor elk van deze personen, nl. de primaire sleutel P_IDPersoon. Voor Niels is dat de waarde 1644. In de nieuwe tabel nemen we dan ook deze waarde op om aan te duiden dat we hier spreken over Boelaert Niels. We moeten ook meegeven dat hij een vriend is. Dit is een bepaalde categorie, maar we mogen niet vriend opnemen in de nieuwe tabel omdat deze waarde af te leiden is uit de informatie uit de tabel tblcategorie. We nemen in de nieuwe tabel de unieke waarde voor de categorie vriend op de primaire sleutel C_Categorie -, nl. 1. PC_ID P_IDPersoon C_CategorieID 1 1644 1 Voor Bral Sander komt de volgende record erbij : PC_ID P_IDPersoon C_CategorieID 1 1644 1 2 1645 4 Voor Bral Carlo komt de volgende record erbij : PC_ID P_IDPersoon C_CategorieID 1 1644 1 2 1645 4 3 1646 6 Voor Cornelis Jean-Pierre moeten we twee categorieën toekennen. Dit betekent dat we in de nieuwe tabel tblpersoonencategorie 2 records zullen maken. 14 Frank Van Oost
PC_ID P_IDPersoon C_CategorieID 1 1644 1 2 1645 4 3 1646 6 4 1648 3 5 1648 5 En zo zal deze tabel verder aangevuld worden zodanig dat voor alle personen waarvoor we een categorie toegekend hebben er een record bestaat in de tabel tblpersoonencategorie. Deze werkwijze laat ook toe om voor bepaalde personen helemaal geen categorie toe te kennen. Er zal dan voor deze personen geen record terug te vinden zijn in de tblpersoonencategorie. We gaan de bovenstaande gegevens nu in de tabel in onze eigen oefening. Om de gegevens te kunnen invullen moet je de tabel tblpersoonencategorie openen door er tweemaal in te klikken. Je kan dan één voor één de records van hierboven invullen. Dit is het resultaat. 15 Frank Van Oost
Visualiseren van de gegevens uit de RELATIETABEL Om nu of later de gegevens van de relatietabel te visualiseren moeten we een eenvoudige selectiequery maken. En dat doen we als volgt : Klik op [Maken] in het lint Kies in de groep <Overige> (uiterst rechts) voor <QueryOntwerp> Selecteer de drie tabellen die we nodig hebben in deze query nl. tblpersonen, tblcategorie en tblpersoonencategorie en klik op <Toevoegen> en op <Sluiten>. We hebben de tabel tblpersonen nodig om de gegevens van de Personen (naam, voornaam, ) te kunnen weergeven. De tblcategorie hebben we nodig om de naam van de categorieën te kunnen tonen. In het queryontwerprooster zie je dat Access zelf al de onderlinge relaties aanduidt doordat de veldnamen die we gekozen zijn overeenkomen. Dit is een goed principe bij de naamgeving van velden in RELATIETABELLEN. Daardoor wordt de tabelstructuur ook wat leesbaarder. Verschuif de voorstelling van de tabel tblcategorie wat naar onder door de rand van de figuur vast te nemen en naar beneden te slepen. Op die manier zijn de relaties duidelijker. 16 Frank Van Oost
Neem nu van de verschillende tabellen de informatie die wenst en sleep deze onderaan in queryrooster of dubbelklik op deze velden waardoor deze ook in het rooster worden opgenomen. We nemen het veld tblpersonen.p_naam, tblpersonen.p_voornaam en tblcategorie.c_omschrijving. Op deze manier zullen we zien welke categorie bij welke persoon hoort en zien we tevens naam en voornaam van deze persoon. 17 Frank Van Oost
Druk op <Uitvoeren> (rood uitroepteken) en je ziet de volgende tabel (view) als resultaat. Daar zien we dat voor elke categorie voor elke persoon een record is opgenomen. We zien ook dat De Causemaeker Simon niet opgenomen is in de lijst (alhoewel hij tussen Bral Carlo en Cornelis Jean-Pierre in de tblpersonen staat) omdat hij niet met zijn PersoonsID in de relatietabel tblpersoonencategorie staat. Voegen we deze echter toe aan de relatietabel nl. met 1647 en 1 (vriend) dan is dat het resultaat. We sluiten alles en bewaren de query1 niet dit was een tijdelijke weergave die we nu nog niet nodig hebben. 18 Frank Van Oost
Samenvattend kunnen we stellen : Voor gegevens die in een tabel herhaald worden moet een nieuwe tabel gemaakt worden. Dit is een opzoektabel. De gegevens in deze tabel zullen in vele gevallen in een lijst kunnen worden opgezocht. De link tussen de hoofdtabel en de nieuwe tabel wordt gemaakt tussen de primaire sleutel van de nieuwe tabel en de secundaire sleutel in de oude tabel (dit is het veld waar eerst de gegevens van de nieuwe tabel stonden). In een veld van een tabel mag slechts één waarde opgenomen worden. Wanneer er meerdere waarden mogelijk zijn voor een bepaald veld moeten de waarden die in dit veld kunnen ingevuld worden in een nieuwe opzoektabel gestoken worden. Deze nieuwe tabel en de oude tabel zijn beiden opzoektabellen voor een nieuwe tabel waarbij een koppeling wordt gemaakt tussen de record van de oude tabel en de verschillende mogelijke waarden die voor een veld uit deze tabel kunnen worden ingevoerd. Dergelijke tabel wordt een relatietabel genoemd. Op deze manier kan aan één bepaalde record uit de oude tabel meerdere waarden kunnen worden toegekend. Waarden die berekend kunnnen worden door andere gegevens in de tabel moeten niet opgeslagen worden. In het verdere betoog zullen we enkele praktische voorbeelden uitwerken van deze regels. 19 Frank Van Oost