Normaliseren van tabellen - Frank Van Oost - IT-services …Microsoft Access 2007 – Een eigen...
Transcript of Normaliseren van tabellen - Frank Van Oost - IT-services …Microsoft Access 2007 – Een eigen...
[Microsoft Access 2007 – Een eigen database maken] 4 november 2009
1 Frank Van Oost
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,
…)
[Microsoft Access 2007 – Een eigen database maken] 4 november 2009
2 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.
[Microsoft Access 2007 – Een eigen database maken] 4 november 2009
3 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, Btw-
tariefwijzigingen, …) 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.
[Microsoft Access 2007 – Een eigen database maken] 4 november 2009
4 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.
[Microsoft Access 2007 – Een eigen database maken] 4 november 2009
5 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 :
[Microsoft Access 2007 – Een eigen database maken] 4 november 2009
6 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
[Microsoft Access 2007 – Een eigen database maken] 4 november 2009
7 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
[Microsoft Access 2007 – Een eigen database maken] 4 november 2009
8 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
[Microsoft Access 2007 – Een eigen database maken] 4 november 2009
9 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 :
[Microsoft Access 2007 – Een eigen database maken] 4 november 2009
10 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.
[Microsoft Access 2007 – Een eigen database maken] 4 november 2009
11 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>.
[Microsoft Access 2007 – Een eigen database maken] 4 november 2009
12 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.
[Microsoft Access 2007 – Een eigen database maken] 4 november 2009
13 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.
[Microsoft Access 2007 – Een eigen database maken] 4 november 2009
14 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.
[Microsoft Access 2007 – Een eigen database maken] 4 november 2009
15 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.
[Microsoft Access 2007 – Een eigen database maken] 4 november 2009
16 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.
[Microsoft Access 2007 – Een eigen database maken] 4 november 2009
17 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.
[Microsoft Access 2007 – Een eigen database maken] 4 november 2009
18 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.
[Microsoft Access 2007 – Een eigen database maken] 4 november 2009
19 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.