Samenvattingen · InformaticaNL · VWO

Keuze H: Databases

Databases bewaren grote hoeveelheden gegevens gestructureerd en betrouwbaar. Dit keuzethema behandelt het relationele model (tabellen met rijen en kolommen, primaire en refererende sleutels), het ontwerpen met ER-modellen, het bevragen en muteren met SQL, en het normaliseren van een schema om redundantie en anomalieën te voorkomen. Het is verdieping binnen het schoolexamen. Databases verbinden domein C (representatie) met domein F (client-server): vrijwel elke webtoepassing steunt op een database achter de server.

4 Onderdelen~13 min leestijd4 VaardighedenNiveau Basis 1 · Standaard 2 · Verdieping 1

T·0999 / 18

Examenprofiel

H · Het relationele model gebruiken: tabellen, rijen, kolommen, primaire en refererende sleutelsH · Een ER-model opstellen met entiteiten, attributen en relaties (cardinaliteit)H · SQL schrijven en lezen: SELECT, WHERE, JOIN, GROUP BY en mutatiesH · Een schema normaliseren tot 3NF om redundantie en anomalieën te voorkomen

Operatoren:schrijfleesontwerpnormaliseerleg uit

basisniveau

Het relationele model, sleutels en eenvoudige SELECT-query’s vormen de kern.

verhoogd niveau

JOIN over meerdere tabellen, aggregaties met GROUP BY en normalisatie tot 3NF horen bij de verdieping.

Diepte

Tekst

Inhoud · 4 onderdelen

Keuze H: Databases

Het relationele model en sleutels#

Basisexamenblad-informatica-H

Een relationele database bewaart gegevens in tabellen (relaties). Elke rij (record, tupel) is één ding — één leerling, één bestelling — en elke kolom (attribuut, veld) een eigenschap daarvan, met een vast datatype. Afb. 1 toont een leerlingentabel. Dit tabelmodel, bedacht door Edgar Codd, is zo succesvol omdat het eenvoudig én wiskundig gefundeerd is: je kunt er precies en voorspelbaar op bevragen. De tabel is de database-tegenhanger van het record uit domein D, maar dan voor grote, blijvend opgeslagen verzamelingen.

Een tabel met primaire en refererende sleutel

Afb. 1Afb. 1 — leerlingID is de primaire sleutel (uniek); klasID is een refererende sleutel naar de klassentabel.

Om elke rij ondubbelzinnig te kunnen aanwijzen, heeft elke tabel een primaire sleutel (primary key): een kolom (of combinatie) waarvan de waarde voor elke rij uniek is en nooit leeg. In de leerlingentabel is dat het leerlingnummer, niet de naam — want twee leerlingen kunnen dezelfde naam hebben. De primaire sleutel is het adres van de rij: elke verwijzing naar die leerling gebruikt dit nummer. Zonder gegarandeerd unieke sleutel kun je rijen niet betrouwbaar onderscheiden, verwijzen of bijwerken.

Tabellen verwijzen naar elkaar met een refererende sleutel (foreign key): een kolom die de primaire sleutel van een ándere tabel bevat. In Afb. 1 is `klasID` een refererende sleutel naar de klassentabel: elke leerling verwijst zo naar zijn klas, zonder de klasgegevens te herhalen. Deze verwijzingen leggen de relaties tussen tabellen. De database bewaakt de referentiële integriteit: je kunt geen leerling koppelen aan een niet-bestaande klas, en (afhankelijk van de instelling) geen klas verwijderen waar nog leerlingen naar verwijzen. Zo blijven de verbanden altijd kloppen.

Het splitsen van gegevens over meerdere gekoppelde tabellen — in plaats van alles in één grote tabel — is het hart van het relationele ontwerp. Elk feit staat op precies één plek: de naam van de klasmentor staat in de klassentabel, niet bij elke leerling opnieuw. Dat voorkomt tegenstrijdigheden en spaart ruimte, en is precies waar normalisatie (sectie 4) systematisch op stuurt. De prijs is dat je de gegevens bij het opvragen weer moet samenvoegen met een JOIN (sectie 3) — een kleine moeite tegenover de winst aan betrouwbaarheid.

Uitgewerkt voorbeeld

Sleutels aanwijzen

In de tabel Leerling(leerlingID, naam, klasID) wil iemand ‘naam’ als primaire sleutel gebruiken. Leg uit waarom dat fout is en wijs de juiste sleutels aan.

Toets op uniciteit
Twee leerlingen kunnen dezelfde naam hebben; ‘naam’ is dus niet gegarandeerd uniek en ongeschikt als primaire sleutel.
Kies de primaire sleutel
leerlingID is per definitie uniek en niet leeg → de juiste primaire sleutel.
Herken de refererende sleutel
klasID verwijst naar de primaire sleutel van de klassentabel → refererende sleutel.

Resultaat: leerlingID is de primaire sleutel, klasID de refererende sleutel; ‘naam’ voldoet niet aan de uniciteitseis.

Veelgemaakte fouten

Een niet-unieke kolom (zoals een naam) als primaire sleutel kiezen; twee rijen kunnen dan dezelfde sleutel krijgen, waardoor ze niet meer te onderscheiden zijn.
Gegevens die bij één ding horen (zoals de klasmentor) bij elke leerling herhalen in plaats van er via een refererende sleutel naar te verwijzen.

Actieve herhaling

Gegeven een tabel `Boek(ISBN, titel, auteur, uitgeverID)` en een tabel `Uitgever(uitgeverID, naam, plaats)`. Benoem de primaire sleutel van elke tabel en de refererende sleutel, en leg uit welke relatie ze samen leggen.

Actief ophalen

Haal de kernpunten op — onthul ze daarna.

Bronnen: Examenprogramma informatica vwo — keuze H (relationeel model) (CvTE / Examenblad)

ER-modellen en relaties#

Standaardexamenblad-informatica-H

ER-model van een school

Afb. 2Afb. 1 — Entiteiten en hun relaties met cardinaliteit; de N:M-relatie ‘volgt’ wordt in tabellen een koppeltabel.

Voordat je tabellen bouwt, ontwerp je de structuur met een entiteit-relatiemodel (ER-model): een schematische weergave van de dingen in je probleemdomein en hun onderlinge verbanden. Een entiteit is een soort ding waarover je gegevens bewaart (Leerling, Klas, Vak); een attribuut is een eigenschap ervan (naam, cijfer); een relatie is een verband tussen entiteiten (een leerling ‘zit in’ een klas). Afb. 1 toont zo’n model. Het ER-model is de database-vertaling van het modelleren uit domein A: je legt eerst de structuur van de werkelijkheid vast, los van de technische uitwerking in tabellen.

De kern van een relatie is haar cardinaliteit: hoeveel exemplaren van de ene entiteit met hoeveel van de andere verbonden zijn. Bij één-op-veel (1:N) hoort bij één klas veel leerlingen, maar bij één leerling precies één klas. Bij veel-op-veel (N:M) volgt een leerling meerdere vakken én wordt elk vak door meerdere leerlingen gevolgd. Bij één-op-één (1:1) hoort bij elk exemplaar precies één van het andere. De cardinaliteit bepaalt hóe je de relatie in tabellen omzet — een verkeerde inschatting leidt tot een schema dat de werkelijkheid niet kan weergeven.

Een ER-model vertaal je volgens vaste regels naar tabellen. Elke entiteit wordt een tabel met haar attributen en een primaire sleutel. Een 1:N-relatie leg je met een refererende sleutel aan de ‘veel’-kant: elke leerling krijgt een `klasID`. Een N:M-relatie kán níet met een enkele refererende sleutel; die vereist een aparte koppeltabel met de sleutels van beide kanten (bijvoorbeeld een tabel `Volgt(leerlingID, vakID)`), waarin elke rij één leerling-vak-combinatie is. Dit is een veelgetoetst en veelgemaakt-verkeerd punt.

Goed ER-ontwerp voorkomt problemen die later duur zijn. Door eerst het model te tekenen zie je of alle benodigde gegevens en verbanden erin passen vóór je iets bouwt — precies de vroeg-testen-gedachte uit de ontwerpcyclus (domein A). Je controleert of elke vraag die de gebruiker wil stellen, uit het model te beantwoorden is, en of geen enkel feit dubbel opgeslagen hoeft te worden. Het ER-model is zo de brug tussen de wensen van de opdrachtgever en een correct, genormaliseerd databaseschema.

Uitgewerkt voorbeeld

Een N:M-relatie omzetten

Een leerling volgt meerdere vakken en een vak wordt door meerdere leerlingen gevolgd. Zet deze relatie om naar tabellen.

Bepaal de cardinaliteit
Meerdere aan beide kanten → veel-op-veel (N:M).
Maak entiteittabellen
Leerling(leerlingID, …) en Vak(vakID, …), elk met eigen primaire sleutel.
Voeg een koppeltabel toe
Volgt(leerlingID, vakID): elke rij is één leerling-vak-combinatie; samen vormen de twee kolommen de primaire sleutel en verwijzen ze als refererende sleutels naar beide tabellen.

Resultaat: De N:M-relatie is opgelost met een koppeltabel Volgt; elke inschrijving is precies één rij daarin.

Veelgemaakte fouten

Een veel-op-veel-relatie proberen te leggen met één refererende sleutel; N:M vereist altijd een aparte koppeltabel met de sleutels van beide entiteiten.
De cardinaliteit verkeerd om lezen; bij 1:N staat de refererende sleutel aan de ‘veel’-kant (bij de leerling, niet bij de klas).

Actieve herhaling

Ontwerp een ER-model voor een bibliotheek met de entiteiten Lid, Boek en Uitlening. Geef de attributen, bepaal de cardinaliteit van de relaties en vertaal het model naar tabellen met de juiste sleutels.

Actief ophalen

Haal de kernpunten op — onthul ze daarna.

Bronnen: Examenprogramma informatica vwo — keuze H (ER-modellen) (CvTE / Examenblad)

SQL: bevragen en muteren#

Standaardexamenblad-informatica-H

Resultaat van een JOIN

Afb. 3Afb. 1 — Een JOIN voegt de gegevens uit twee tabellen samen via de gemeenschappelijke sleutel klasID.

SQL (Structured Query Language) is de standaardtaal om relationele databases te bevragen en te wijzigen. Ze is declaratief (keuze J): je beschrijft wélke gegevens je wilt, niet hóe de database ze moet ophalen — dat optimaliseert het systeem zelf. De kern is de SELECT-opdracht met drie delen: SELECT (welke kolommen), FROM (uit welke tabel) en WHERE (aan welke voorwaarde de rijen moeten voldoen). Zo geeft ‘SELECT naam FROM Leerling WHERE klasID = 4A’ de namen van alle leerlingen in klas 4A. De voorwaarde in WHERE is precies een propositie uit de logica (keuze G), met AND, OR en NOT.

Omdat gegevens over meerdere tabellen verdeeld zijn (sectie 1), moet je ze bij het opvragen weer samenvoegen met een JOIN. Een JOIN combineert rijen uit twee tabellen op grond van een gemeenschappelijke sleutel: koppel elke leerling aan zijn klas door `Leerling.klasID` te matchen met `Klas.klasID`. Afb. 1 toont het resultaat van zo’n koppeling — namen mét de bijbehorende klasgegevens, zonder dat die gegevens in de leerlingentabel herhaald hoefden te staan. De JOIN is het gereedschap dat het normaliseren (sectie 4) weer terugbetaalt: de gegevens staan efficiënt opgeslagen én zijn samen op te vragen.

SQL kan gegevens ook samenvatten met aggregatiefuncties: COUNT (tellen), SUM (optellen), AVG (gemiddelde), MIN en MAX. Met GROUP BY bereken je die per groep: ‘tel het aantal leerlingen per klas’ groepeert de rijen op klas en telt binnen elke groep. Zo beantwoord je in één query vragen als ‘wat is het gemiddelde cijfer per vak?’. Dit maakt van een database niet alleen een opslag maar een analyse-instrument — de brug naar data science (keuze R).

Naast bevragen kun je met SQL de gegevens muteren: INSERT voegt een rij toe, UPDATE wijzigt bestaande rijen (altijd met een WHERE, anders wijzig je de héle tabel!) en DELETE verwijdert rijen. Bij mutaties bewaakt de database de integriteit: een INSERT die een niet-bestaande refererende sleutel gebruikt, wordt geweigerd. Voor betrouwbaarheid groepeert men samenhangende mutaties in een transactie die geheel slaagt of geheel wordt teruggedraaid (bijvoorbeeld: afschrijven én bijschrijven bij een overboeking) — zo blijft de database ook bij een fout of stroomuitval in een consistente toestand.

Uitgewerkt voorbeeld

Een JOIN-query schrijven

Schrijf een SQL-query die van elke leerling de naam en de mentor van zijn klas oplevert (het resultaat van Afb. 1).

Kies kolommen en tabellen
SELECT naam, mentor uit de tabellen Leerling en Klas.
Formuleer de koppeling
Koppel op de gemeenschappelijke sleutel: Leerling.klasID = Klas.klasID.
Volledige query
SELECT Leerling.naam, Klas.mentor FROM Leerling JOIN Klas ON Leerling.klasID = Klas.klasID;

Resultaat: De JOIN op klasID levert per leerling zijn naam met de mentor van de bijbehorende klas — precies de tabel van Afb. 1.

Veelgemaakte fouten

Een UPDATE of DELETE zonder WHERE uitvoeren, waardoor álle rijen worden gewijzigd of verwijderd in plaats van de bedoelde.
Bij een JOIN de koppelvoorwaarde vergeten, waardoor elke rij met élke rij wordt gecombineerd (een enorm, betekenisloos product).

Actieve herhaling

Gegeven Leerling(leerlingID, naam, klasID) en Klas(klasID, mentor). Schrijf een SQL-query die van elke leerling de naam en de mentor van zijn klas toont. Schrijf daarnaast een query die het aantal leerlingen per klas telt.

Actief ophalen

Haal de kernpunten op — onthul ze daarna.

Bronnen: Examenprogramma informatica vwo — keuze H (SQL) (CvTE / Examenblad)

Normalisatie#

Verdiepingexamenblad-informatica-H

Een ongenormaliseerde besteltabel

Afb. 4Afb. 1 — Redundantie: ‘Sanne’ en de prijs van ‘Muis’ (15) worden herhaald — een bron van anomalieën.

Normalisatie is het stapsgewijs herstructureren van tabellen zodat elk feit precies één keer wordt opgeslagen. Het bestrijdt redundantie (dezelfde gegevens meermaals) en de anomalieën die daaruit voortkomen. Afb. 1 toont een slecht ontworpen (‘ongenormaliseerde’) besteltabel waarin klant- en productgegevens telkens herhaald worden. Zulke herhaling is niet alleen verspilling; ze is een bron van fouten, want dezelfde informatie op meerdere plekken kan tegenstrijdig raken.

Redundantie veroorzaakt drie soorten anomalieën. Een wijzigingsanomalie: verandert de prijs van een product, dan moet je hem in álle rijen aanpassen; vergeet je er één, dan is de database tegenstrijdig. Een invoeganomalie: een nieuw product zonder bestelling krijg je er niet in als productgegevens alleen bij bestellingen staan. Een verwijderanomalie: verwijder je de laatste bestelling van een klant, dan verdwijnen ongewild ook diens gegevens. Deze drie anomalieën zijn de concrete schade van een slecht schema en precies wat normalisatie wegneemt.

Normalisatie verloopt in normaalvormen. De eerste normaalvorm (1NF) eist dat elke cel één ondeelbare waarde bevat (geen lijstjes in één veld) en dat er een primaire sleutel is. De tweede normaalvorm (2NF) eist bovendien dat elk niet-sleutelattribuut van de hele primaire sleutel afhangt, niet van een deel ervan (relevant bij samengestelde sleutels). De derde normaalvorm (3NF) eist ten slotte dat niet-sleutelattributen alleen van de sleutel afhangen en niet van elkaar (geen ‘transitieve’ afhankelijkheid). Elke stap splitst de tabel verder op in kleinere, samenhangende tabellen die je met refererende sleutels koppelt.

In de praktijk normaliseer je door herhaalde en afhankelijke gegevens naar eigen tabellen te verplaatsen. De besteltabel uit Afb. 1 splits je in een klanttabel, een producttabel en een besteltabel die via sleutels naar beide verwijst — nu staat elke klant en elk product nog maar één keer. Normalisatie tot 3NF volstaat vrijwel altijd; het is de tegenhanger van efficiënt en betrouwbaar ontwerp. Wel is er een afweging: een sterk genormaliseerd schema vereist meer JOIN’s bij het opvragen, dus soms denormaliseert men bewust een stukje voor snelheid — een ontwerpkeuze die je, zoals altijd in domein A, moet kunnen verantwoorden.

Uitgewerkt voorbeeld

Normaliseren tot 3NF

Normaliseer de besteltabel uit Afb. 1 zodat klant en product elk nog maar één keer worden opgeslagen.

Herken de redundantie
‘Sanne’ herhaalt bij elke bestelregel; de prijs van ‘Muis’ (een producteigenschap) staat bij elke bestelling opnieuw.
Splits in entiteittabellen
Klant(klantID, naam) en Product(productID, naam, prijs): elke klant en elk product één keer.
Maak een besteltabel met sleutels
Bestelregel(bestelID, klantID, productID): verwijst via refererende sleutels naar beide tabellen; de prijs staat nu alleen nog bij het product.

Resultaat: Na normalisatie staat elk feit één keer; een prijswijziging hoeft nog maar op één plek en de anomalieën verdwijnen.

Veelgemaakte fouten

Denken dat normalisatie alleen ruimte bespaart; het belangrijkste doel is het voorkomen van tegenstrijdigheden (anomalieën) door elk feit maar één keer op te slaan.
Bij het opsplitsen vergeten de tabellen met refererende sleutels te koppelen, waardoor je de gegevens naderhand niet meer met een JOIN kunt samenvoegen.

Actieve herhaling

Gegeven een ongenormaliseerde tabel Cursus(cursusID, cursusnaam, docent, docentEmail) waarin de docent bij meerdere cursussen voorkomt en zijn e-mail steeds herhaald wordt. Wijs de redundantie en een anomalie aan en normaliseer de tabel tot 3NF.

Actief ophalen

Haal de kernpunten op — onthul ze daarna.

Bronnen: Examenprogramma informatica vwo — keuze H (normalisatie) (CvTE / Examenblad)

Referenties en bronnen

Bronnen

CvTE / Examenblad

Examenprogramma informatica vwo — keuze H (relationeel model)

Keuze H: Databases

Kernpunten

Sleutels aanwijzen

Kernpunten

Een N:M-relatie omzetten

Kernpunten

Een JOIN-query schrijven

Kernpunten

Normaliseren tot 3NF

Bronnen

Keuze H: Databases

Kernpunten

Sleutels aanwijzen

Kernpunten

Een N:M-relatie omzetten

Kernpunten

Een JOIN-query schrijven

Kernpunten

Normaliseren tot 3NF

Bronnen