Home » Cursus Microsoft Access » Database weetjes: sleutel, record, tabel etc. (2/10)

Laatste update:

Database weetjes: sleutel, record, tabel etc. (2/10)

Wat is een relationele database? Waarvoor gebruik je databases, tabellen, records en velden? Wat is de primaire sleutel? Wat is een één op één of één op veel relatie? Wat is normaliseren?

Access is gebruiksvriendelijk, maar een paar dingen moet je weten. Je moet een klein stukje spreken in de taal van het programma. Op deze pagina leg ik in grote lijnen uit hoe een database werkt, hoe ze gestructureerd is. Belangrijk allemaal vooraleer je zelf aan de slag gaat!

Database, tabellen, records en velden

Laat ons beginnen met wat ik in het vorige deel ook al eens heb uitgelegd, over de opbouw van een database.

Ten eerste moet je weten dat je altijd in één database werkt. Er zijn niet twee databases tegelijk open wanneer je met Microsoft Access werkt.

In die database zitten de gegevens in een of meerdere tabellen. Een tabel is een collectie van gegevens over een bepaald onderwerp. In het voorbeeld dat we op deze pagina uitwerken, maken we een tabel van klanten, eentje van producten, een van bestellingen en een van leveranciers.

In het navigatiedeelvenster links zie je de 4 tabellen staan. Ze zijn ook alle 4 geopend, en op dit moment kijk je naar de tabel met de klanten.

Een tabel zelf is onderverdeeld in rijen en kolommen, eigenlijk net zoals in een Microsoft Excel bestand.

1 item uit zo’n tabel, 1 rij dus, noemen we een record. Dat is dan de data voor 1 klant, 1 product of 1 leverancier. In het screenshot hierboven gaat het record met ID 2 bijvoorbeeld over een zekere Margot.

Naar een kolom in de tabel verwijzen we met de term veld. In de klantentabel heb je dus de velden voornaam, achternaam, huisnummer, straat etc.

Relationele database

Meestal staan de tabellen niet op zich, maar zijn ze met elkaar verbonden. Dat heeft als voordeel dat je de data kan combineren, gegevens kan opzoeken etc.

We spreken in dat geval van een relationele database. Er zijn verbanden tussen de tabellen.

Voorbeeld van een relationele database

Een voorbeeld. Stel dat je wil bijhouden welke klanten welke producten kopen. Je wil van elke klant adresgegevens bijhouden en wat zij of hij bestelt. Van de producten die je verkoopt wil je ook de leveranciers registreren.

Als je nu géén relationele database zou gebruiken, dan moet je in elk record steeds opnieuw het adres opgeven, ook al heb je dat adres al duizenden keren ingegeven.

Je moet ook elke keer opnieuw alle productgegevens ingeven, hoewel dat product misschien al 200 x eerder verkocht werd. Als je dat in Excel zou weergeven, ziet het er bijvoorbeeld zo uit.

NaamAdresWoonpaatsPostcodeBest. nr.DatumArtikelPrijs
Jan JannsensAdreslaan 1Zonnebloemgem1000123415/2/2023Kartonnen beker€ 5,74
Jan JannsensAdreslaan 1Zonnebloemgem1000123515/2/2023Balpen€ 2,54
Jan JannsensAdreslaan 1Zonnebloemgem1000157815/5/2023Kaft€ 8,98
Pieter PieterssenAdreslaan 3Madeliefdorp2000079815/1/2023Balpen€ 2,54
Pieter PieterssenAdreslaan 3Madeliefdorp2000098718/1/2023Schaar€ 6,56
Pieter PieterssenAdreslaan 3Madeliefdorp2000198716/6/2023Kartonnen beker€ 5,74
Dit is een voorbeeld van een weinig efficiënte gegevensopslag.

Ik weet niet hoe jij je daar bij voelt, maar ik vind dat niet efficiënt.

Het altijd maar kopiëren van dezelfde data (bijv. het adres van Jan Jannsens) kost niet alleen veel tijd, het vergroot ook de kans op fouten. En dat kan je in je mooie database missen als kiespijn.

En wat als een van je klanten verhuist? Dan moet je alle bestellingen van die klant manueel aanpassen om de besteldata zuiver en bruikbaar te houden.

Zou het niet handiger zijn om eerst alle klantgegevens in te voegen, dan productgegevens, en dan een lijst bij te houden van de bestellingen waarbij je een product kiest en een klant, waarbij dan alle andere productgegevens en klantgegevens worden opgezocht? Je maakt dus aparte lijsten die naar elkaar verwijzen.

Dat is precies waarvoor de relationele database ontwikkeld werd.

Dat is veel minder werk en je zorgt ervoor dat dezelfde gegevens niet op veel verschillende plaatsen zitten. Hieronder zie je welke tabellen zo’n database zou bevatten.

We bewaren onze data hier in 4 tabellen.

Hieronder leg ik uit hoe je die 4 tabellen met elkaar kan verbinden.

Primaire sleutel: het identificatieveld in een tabel

Nu we de tabellen hebben, moeten we natuurlijk in de ene tabel verwijzen naar de andere. Anders staan de tabellen los van elkaar.

In de besteltabel moeten we bijvoorbeeld verwijzen naar de klanttabel. De vraag van 1 miljoen is nu natuurlijk hoé we dat precies gaan doen.

Wel, we gaan een brug bouwen tussen de 2 tabellen.

Je moet in je besteltabel minstens 1 waarde uit de klanttabel opnemen om de verbinding te leggen tussen de 2 tabellen. Je moet met andere woorden bij de bestellingen iets zeggen over de klant, om later nog te weten welke klant wat besteld heeft.

Zullen we in de besteltabel dan gewoon de voornaam van de klant vermelden? Nee, want er zijn misschien meerdere klanten met dezelfde voornaam. Zullen we dan de achternaam vermelden? Nee, want er zijn misschien klanten met dezelfde achternaam. Zo kan ik nog wel een tijdje doorgaan.

We moeten op zoek gaan naar een veld in de klantentabel dat ondubbelzinnig duidelijk maakt welke klant precies we bedoelen.

De gemakkelijkste manier om zo’n unieke identificatie mogelijk te maken is elke klant een uniek volgnummer mee te geven. Hier is dat Klant_Id. Zo is er geen verwarring meer mogelijk. In de klantentabel noemen we Klant_Id de primaire sleutel, een waarde die elk record uniek identificeert.

Bekijk opnieuw het screenshot hieronder: in elke tabel zie je bij een veld een sleutelicoontje staan. Dat zijn de primaire sleutels per tabel.

Zie je de sleutelicoontjes staan? Die geven de primaire sleutels aan per tabel.

De primaire sleutel van de ene tabel nemen we ook op als veld in de andere tabel. Pas dan is de brug compleet.

In de besteltabel moet ik bijvoorbeeld ook het veld Klant_Id (dat is de primaire sleutel in de klantentabel) opnemen zodat ik per bestelling kan bijhouden om welke klant het gaat. Dat zal later toelaten om ook de andere data (voornaam, achternaam etc.) per bestelling op te zoeken.

Ik voeg in de besteltabel ook Product_Id in zodat we bijhouden welke producten besteld werden. In de productentabel herhaal ik tot slot het leverancier_Id zodat we van elk product de leverancier kunnen registreren.

Bekijk hieronder op het screenshot hoe de velden werden toegevoegd.

Ik voegde in de besteltabel Klant_Id en Product_Id toe en in de producttabel Leverancier_Id

Relaties tussen de tabellen: één-op-veel, veel-op-veel & één-op-één relaties

We hebben nu al een brug tussen tabellen, maar we moeten duidelijk maken hoe de data over die brug mogen stromen. Hoe precies moeten de tabellen verbonden worden?

Er bestaan namelijk verschillende types relaties, hieronder ontdek je wat er mogelijk is.

Relatietype 1: de één-op-veel relatie

Het meest voorkomende type relatie is de zogenaamde één-op-veel relatie. Dat betekent dat een record uit de ene tabel verschillende keren aan bod kan komen in de andere tabel, maar dat dan in de omgekeerde richting niét geldt.

Klinkt moeilijk? Kijk eens naar de klantentabel en de bestellingtabel. Een record in de klantentabel (een bepaalde klant, dus) kan verwijzen naar meerdere records in de bestellingentabel (eenzelfde klant kan meerdere bestellingen doen).

Omgekeerd geldt dat echter niet: een record in de bestellingentabel (een bepaalde bestelling, dus) kan maar verwijzen naar 1 bepaalde klant (elke bestelling heeft maar 1 klant), niet naar meerdere klanten.

In Microsoft Access wordt zo’n 1 op veel relatie weergegeven met 1 en ∞.

Hieronder geef ik de relaties zo weer:

  • een klant kan meerdere bestellingen doen, maar een bestelling kan maar 1 klant hebben
  • een leverancier kan meerdere producten aanbieden, maar een product heeft maar 1 leverancier
  • een product kan in meerdere bestellingen voorkomen, maar een bestelling bestaat maar uit 1 product (al is dat niet helemaal correct, zoals je hieronder zal ontdekken)
Drie 1-op-veel relaties tussen de tabellen (al is 1 relatie niet helemaal correct, dat ontdek je hieronder)

Relatietype 2: de veel-op-veel relatie met een verbindingstabel.

Die laatste uitspraak hierboven, die lijkt niet correct: een product kan in meerdere bestellingen voorkomen, maar een bestelling kan toch ook meerdere producten hebben?

In dat geval hebben we geen 1-op-veel relatie, maar wel een veel-op-veel relatie.

In Microsoft Access maken we zo’n relatie met een zogenaamde verbindingstabel. We voegen een extra tabel toe waarin elk record deelinfo geeft over een bestelling. De verbindingstabel zou er zo kunnen uitzien:

bestellingproduct
1a
1b
2c
3a
3b
Voor elke bestelling lijsten we de bestelde producten op.

Een weetje: in zo’n verbindingstabel vormen de 2 primaire sleutels van de tabellen die er deel van uitmaken sámen de primaire sleutel. BestellingenProducten heeft dus 2 primaire sleutels, Bestelling_Id & Product_Id.

Hieronder zie je de sleutelicoontjes in de afbeelding.

Er werd een verbindingstabel BestellingenProducten toegevoegd die toelaat om per bestelling meerdere producten te registreren en per product ook meerdere bestellingen.

Om nog beter te snappen hoe dat werkt, toon ik eens de records in de verbindingstabel in Microsoft Access zelf.

De verbindingstabel laat toe bestellingen en producten met elkaar te verbinden, in 2 richtingen. We voegen ook het aantal bestelde producten toe.

Relatietype 3: de één-op-één-relatie

Het laatste type relatie komt minder vaak voor. Een record in de ene tabel verwijst dan naar slechts 1 record in de andere tabel, en in omgekeerde richting geldt dat ook.

Stel dat we bijvoorbeeld het BTW-nummer uit de leveranciertabel halen en onderbrengen in een aparte BTW-nummertabel. Elke leverancier komt overeen met slechts 1 BTW-nummer, en elk BTW-nummer komt slechts overeen met 1 leverancier. Dat is een 1 op 1 relatie.

Je gebruikt dit type relatie om grote tabellen op te splitsen, of omdat de data uit verschillende bronnen komen.

In deze cursus Microsoft Access laat ik dit type relatie echter niet aan bod komen.

Wat is een database normaliseren?

Het zal op dit moment al wel duidelijk zijn: vooraleer we een database maken, moeten we eerst nadenken over de structuur.

We moeten ontdekken welke velden we samen in 1 tabel plaatsen, welke verschillende tabellen we onderscheiden en welke relaties we instellen tussen de tabellen.

Stel dat ik bijvoorbeeld een een eenvoudige database wil maken om mijn non-fictie boekencollectie bij te houden. Welk boeken heb ik, wie is de auter, waar bewaar ik ze, etc? Die data wil ik bijhouden.

Als je alleen Microsoft Excel of Google Sheets kent (spreadsheets ipv. databases), dus géén Microsoft Access, dan geef je je gegevens waarschijnlijk weer als meerdere kolommen op 1 werkblad:

BoekAuteurAuteurlandLocatieVerdiepingOnderwerp
Een digitaal marketingplan in 100 dagenVan Wassenhove, BertBelgiëzolder3digitale marketing
Marketing – de nieuwe principesVan Belleghem, StevenBelgiëzolder3digitale marketing
Handboek Facebook marketingKolb, KarelNederlandbureau2social marketing
Advanced Web Metrics with Google AnalyticsClifton, BrianVerenigde Statenbureau2analytics
Basisboek digital analyticsOosterveer, DannyNederlandzolder2analytics
Advanced Google AdWordsGeddes, BradVerenigde Statenzolder2ads
Dit is een voorbeeld van een weinig efficiënte gegevensopslag.

Alles in 1 tabel stoppen is echter niet de goede manier om je data te bewaren en te gebruiken, dat heb ik hierboven al ergens vermeld. Voor elke auteur moet je bijvoorbeeld telkens de naam én de het land intypen. En voor elke locatie moet je ook de verdieping herhalen. Dat alles vergroot de kans op fouten en het maakt je bestand nodeloos complex.

Wat we gaan doen om van je database een efficiëntere relationele database te maken is normaliseren.

Normaliseren betekent dat je stap voor stap de database gaat opsplitsen om herhaling en afhankelijkheid te voorkomen. In plaats van 1 groot werkblad, maken we dus meerdere tabellen. Zo kunnen we veel overbodige items schrappen. Je duidt bij het normaliseren meteen ook de primaire sleutels aan.

In ons voorbeeld voorkomen we herhaling door boeken, auteurs, locaties en onderwerpen van elkaar te scheiden: als we van elk boek de auteur weten, dan weten we automatisch ook het land van de auteur. Als we van een boek de locatie weten, dan weten we automatisch ook de verdieping.

Het is overbodig om die gegevens telkens weer te herhalen. Binnen elke tabel duiden we een primaire sleutel aan die de records in de tabel uniek kan identificeren.

BOEKAUTEURLOCATIEONDERWERP
*boek_id*auteur_id*locatie_id*onderwerp_id
titelnaamlocatieonderwerp
landverdieping
4 tabellen en een primaire sleutel per tabel (*)

Tijd nu om de bruggen tussen de tabellen te maken: welke relaties moeten we instellen?

  • onderwerp <-> boek: 1 op veel, want een onderwerp kan toegewezen worden aan meerdere boeken, terwijl een boek maar 1 onderwerp kan hebben
  • locatie <-> boek: 1 op veel, want een locatie kan toegewezen worden aan meerdere boeken, terwijl een boek maar 1 locatie kan hebben

De relatie tussen de auteurstabel en de boektabel is eigenlijk een veel-op-relatie. Een boek kan meerdere auteurs hebben en een auteur kan meerdere boeken hebben.

Zoals hierboven al uitgelegd, hebben we dan een verbindingstabel nodig waar we elke auteur koppelen aan de boeken die zij of hij schreef.

Het schema ziet er nu zo uit

BOEKBoekAuteurAUTEURLOCATIEONDERWERP
*boek_id*boek_id*auteur_id*locatie_id*onderwerp_id
titel*auteur_idnaamlocatieonderwerp
landverdieping
5 tabellen en minimaal één primaire sleutel per tabel (*)

Dat s al beter, hé?

Nu hebben wij dat normaliseren hier op een redelijk informele manier aangepakt. Als je ambities hebt om programmeur te worden, dan moet je vaak met grote, complexe databases werken.

Een niet-gestandaardiseerde normalisering gebaseerd op louter gezond verstand, zoals die van ons hierboven, loopt dan waarschijnlijk ergens spaak.

Om normaliseren gestructureerd aan te pakken, bestaan er een reeks regeltjes en specifieke notaties.

Als je echt wil weten hoe het moet volgens de regels van de kunst, verwijs ik je graag door naar tutorials over normaliseren die je overal op het internet kan vinden. Zeker YouTube is een onuitputtelijke bron van hapklare kennis over dit onderwerp.

In het volgende deel schakelen we terug over naar Microsoft Access waar we deze database nu eens echt gaan maken. Vond je alles wat je hier las wat abstract? Ga dan naar het volgende deel en ga aan de slag.

Office-toepassingen

Cursus MS Excel

Cursus MS Word

Cursus MS PowerPoint

Cursus MS Outlook

Cursus MS Access

Grafische programma's

Basiscursus Adobe Photoshop

Basiscursus GIMP

Basiscursus Adobe Lightroom

Mobiel

Cursus Android smartphones

Bedrijfstoepassingen

Cursus Google Analytics

Cursus Google Ads

Cursus SEO

Cursus Wordpress