Normaliseren van tabellen - Frank Van Oost - IT-services …Microsoft Access 2007 – Een eigen database maken] 4 november 2009 2 Frank Van Oost Enkele bezwaren voor dergelijke rangschikking

[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,

…)


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.


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.


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.


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 :


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


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


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


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 :


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 :


1 1 3 2 2 7

Voor Van de Velde Stefaan met categorie ‘ collega’ wordt dat :


10 Frank Van Oost


1 1 3 2 2 7 3 3 2

Voor Dobbel Mien met de categorie ‘vriend’ en ‘collega’ wordt dat :


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 :


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.


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.


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 :


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>.


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.


13 Frank Van Oost

De nieuwe tabel zal er dan als volgt uitzien :


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.


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 :


1 1644 1 2 1645 4

Voor Bral Carlo komt de volgende record erbij :


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.


15 Frank Van Oost


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.


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.


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.


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.


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.

Documents

Normaliseren van tabellen - Frank Van Oost - IT-services …Microsoft Access 2007 – Een eigen database maken] 4 november 2009 2 Frank Van Oost Enkele bezwaren voor dergelijke rangschikking