Samenvattingen · InformaticaNL · HAVO

Keuze H: Databases

Databases gaat over het gestructureerd opslaan, ordenen en bevragen van grote hoeveelheden gegevens met een databasemanagementsysteem (DBMS). Je leert het relationele model, hoe je met een ERD een datamodel ontwerpt, hoe je door normaliseren redundantie en fouten voorkomt, en hoe je met SQL gegevens opvraagt en wijzigt. Keuzethema — onderdeel van het schoolexamen als de school dit thema kiest; informatica kent geen landelijk examen en wordt volledig met het schoolexamen (SE) afgesloten.

4Onderdelenca. 21min leestijd4VaardighedenNiveauBasis 1 · Standaard 2 · Verdieping 1

T·0777 / 12

Examenprofiel

Het relationele model uitleggen en in een gegeven tabel de primaire sleutel en de refererende sleutel (foreign key) aanwijzen en hun rol beschrijven.Uit een beschrijving van een situatie een datamodel (ERD) ontwerpen met entiteiten, attributen, relaties en de juiste cardinaliteit (1:1, 1:N, N:M).Een tabel normaliseren tot de derde normaalvorm en beredeneren welke redundantie en welke update-, insert- en delete-anomalieen je daarmee voorkomt.Met SQL gegevens opvragen (SELECT, WHERE, ORDER BY, JOIN, GROUP BY) en wijzigen (INSERT, UPDATE, DELETE).

Operatoren:ontwerpbepaalleg uitnormaliseerstel oppas toeberedeneer

basisniveau

Zorg dat je het relationele model en de sleutels beheerst en een eenvoudige SELECT-query met WHERE en ORDER BY kunt lezen en schrijven.

verhoogd niveau

Kun je een casus zelfstandig modelleren in een ERD, een tabel tot 3NF normaliseren en query's met JOIN en GROUP BY opstellen en het resultaat voorspellen.

Diepte

Schrift

Inhalt · 4 onderdelen

Keuze H: Databases

Het relationele model#

Basisexamenblad-nl

Een database is een gestructureerde, samenhangende verzameling gegevens die zo is opgeslagen dat een computer ze snel kan opzoeken, combineren en bijwerken. Het grote verschil met een los bestand — denk aan een tekstdocument of een enkel werkblad in een spreadsheet — is dat een database bewaakt hoe de gegevens met elkaar samenhangen en dat er regels gelden die de gegevens betrouwbaar houden. Los bestand: heb je de klas van een leerling in tien documenten overgetypt en verandert die leerling van klas, dan moet je tien keer wijzigen en vergeet je er gauw een. Een database bewaart zo'n gegeven op een plek en laat de rest ernaar verwijzen. Het programma dat dit alles beheert heet een databasemanagementsysteem (DBMS), bijvoorbeeld MySQL, PostgreSQL of SQLite.

In het relationele model — verreweg het meest gebruikte model — bewaar je gegevens in tabellen. Een tabel heet formeel een relatie en beschrijft een soort ding uit de werkelijkheid, bijvoorbeeld alle leerlingen. Elke rij (ook wel tupel of record genoemd) is een exemplaar van dat ding: een leerling. Elke kolom (attribuut of veld) is een eigenschap die je van elk exemplaar bijhoudt: naam, woonplaats, geboortedatum. De tabel Leerling heeft dus bijvoorbeeld de kolommen Naam en Woonplaats, en per leerling een rij met concrete waarden. Belangrijk: de volgorde van de rijen heeft geen betekenis — een tabel is een verzameling rijen, geen genummerde lijst — en binnen een kolom zijn alle waarden van dezelfde soort.

Om een bepaalde rij ondubbelzinnig te kunnen aanwijzen heeft elke tabel een primaire sleutel: een kolom (of combinatie van kolommen) waarvan de waarde voor elke rij uniek is en nooit leeg. Namen zijn ongeschikt als sleutel — er kunnen twee leerlingen Sara de Vries heten — dus voegt men vaak een kunstmatig nummer toe, zoals LeerlingID. In de tabel Leerling is LeerlingID = 3 dan een adres waarmee je precies een rij terugvindt. De primaire sleutel garandeert dat er geen twee identieke rijen bestaan en is het aanknopingspunt waarmee andere tabellen naar deze rij kunnen verwijzen. Een sleutel die uit meerdere kolommen bestaat heet een samengestelde sleutel; die kom je vooral tegen in koppeltabellen.

Tabellen worden aan elkaar gekoppeld met een refererende sleutel (Engels: foreign key). Dat is een kolom in de ene tabel die verwijst naar de primaire sleutel van een andere tabel. Stel je hebt naast Leerling ook een tabel Klas met primaire sleutel KlasID (H4A, H4B, ...). Door in Leerling een kolom KlasID op te nemen die dezelfde waarden gebruikt, leg je vast in welke klas elke leerling zit, zonder de klasgegevens over te typen. De foreign key dwingt bovendien samenhang af: het DBMS kan weigeren een leerling in klas H9Z te plaatsen als die klas niet in de tabel Klas bestaat — dat heet referentiele integriteit. Zo verwijst de kolom KlasID (FK) in Afb. 1 naar de sleutel van de klassentabel.

Tabel Leerling met primaire en refererende sleutel

Afb. 1De kolom LeerlingID (PK) identificeert elke leerling uniek; KlasID (FK) verwijst naar de primaire sleutel van de tabel Klas en legt zo vast in welke klas elke leerling zit.

Bij elke kolom hoort een domein oftewel datatype: de verzameling waarden die er zijn toegestaan. LeerlingID is een geheel getal, Naam is tekst, een geboortedatum is een datum en 'is geslaagd' is een booleaanse waarde (waar of onwaar). Door het datatype vast te leggen voorkomt het DBMS dat er onzin in een kolom belandt, zoals de tekst 'gisteren' in een datumkolom. Samen met de sleutels en de referentiele integriteit vormt dit de kracht van een DBMS boven losse bestanden: het bewaakt de structuur, voorkomt dubbele en tegenstrijdige gegevens, laat veel gebruikers tegelijk veilig werken en maakt met SQL snelle, gecombineerde zoekopdrachten mogelijk. Daarom draait vrijwel elke website, app of administratie op een database.

Uitgewerkt voorbeeld

Sleutels aanwijzen in een tabel

Bekijk de tabel Leerling(LeerlingID, Naam, Woonplaats, KlasID) uit Afb. 1. Welke kolom is de primaire sleutel, welke is de refererende sleutel, en waarom zijn de andere kolommen ongeschikt als sleutel?

Zoek de unieke, niet-lege kolom
LeerlingID heeft voor elke rij een andere waarde (1, 2, 3, 4) en is nooit leeg. Daarmee kun je elke rij ondubbelzinnig aanwijzen, dus LeerlingID is de primaire sleutel.
Toets de andere kolommen
Naam is ongeschikt: twee leerlingen zouden dezelfde naam kunnen hebben. Woonplaats komt zelfs meermaals voor (Utrecht bij rij 1 en rij 3). Zulke kolommen kunnen geen rij uniek identificeren.
Herken de verwijzing
KlasID bevat waarden als H4A en H4B. Dat zijn geen eigenschappen van de leerling zelf maar verwijzingen naar rijen in de tabel Klas. KlasID is dus de refererende sleutel (foreign key).
Beschrijf de koppeling
KlasID in Leerling verwijst naar KlasID (de primaire sleutel) in Klas. Zo hoort bij elke leerling precies een klas, terwijl een klas bij veel leerlingen kan horen.

Resultaat: LeerlingID is de primaire sleutel; KlasID is de refererende sleutel die naar de primaire sleutel van de tabel Klas verwijst. Naam en Woonplaats zijn niet gegarandeerd uniek en kunnen dus geen sleutel zijn.

Veelgemaakte fouten

De naam als primaire sleutel kiezen; namen zijn niet gegarandeerd uniek, gebruik daarom een uniek ID.
Primaire en refererende sleutel verwarren: de foreign key is de verwijzende kolom, niet de sleutel waarnaar hij verwijst.
Denken dat de rijvolgorde betekenis heeft; een tabel is een ongeordende verzameling rijen.

Actieve herhaling

Gegeven een tabel Boek(BoekID, Titel, Auteur, UitgeverID) en een tabel Uitgever(UitgeverID, Naam, Plaats): wijs in beide tabellen de primaire sleutel aan, benoem de refererende sleutel en leg uit welke koppeling die legt.

Actief ophalen

Haal de kernpunten op — onthul ze daarna.

Bronnen: Examenprogramma informatica (HAVO) (CvTE / Examenblad)

Datamodellering met een ERD#

Standardexamenblad-nl

Voordat je tabellen aanmaakt, ontwerp je eerst een datamodel: een schematische weergave van welke dingen je wilt bewaren en hoe die samenhangen. Het gangbare gereedschap daarvoor is het entiteit-relatiediagram (ERD). Een entiteit is een soort ding uit de werkelijkheid waarover je gegevens bijhoudt en dat je later een eigen tabel geeft: Leerling, Klas, Vak, Docent. In het ERD teken je elke entiteit als een knoop (vaak een rechthoek). Een handige vuistregel: entiteiten zijn meestal de zelfstandige naamwoorden in de beschrijving van het probleem. Door eerst te modelleren voorkom je dat je halverwege het bouwen ontdekt dat je structuur niet klopt en alles opnieuw moet.

Elke entiteit heeft attributen: de eigenschappen die je per exemplaar wilt vastleggen, en die later de kolommen van de tabel worden. Bij de entiteit Leerling horen bijvoorbeeld de attributen naam, woonplaats en geboortedatum; bij Vak horen vakcode en vaknaam. Een attribuut (of combinatie) wordt aangewezen als identificerend attribuut — de latere primaire sleutel — bijvoorbeeld LeerlingID bij Leerling. Attributen horen bij precies een entiteit: 'vaknaam' hoort bij Vak, niet bij Leerling. Wie dat door elkaar haalt, krijgt later een tabel die dezelfde gegevens op meerdere plekken bewaart — precies wat je met normaliseren weer moet rechttrekken.

Een relatie legt vast hoe twee entiteiten met elkaar te maken hebben; in het ERD is dat een lijn tussen twee knopen, met een werkwoord als label ('zit in', 'volgt'). Bij elke relatie hoort een cardinaliteit die zegt hoeveel exemplaren van de ene entiteit bij hoeveel van de andere kunnen horen. Er zijn drie soorten. Een-op-een (1:1): bij elk exemplaar hoort er hooguit een aan de andere kant, bijvoorbeeld een klas heeft precies een mentor-docent. Een-op-veel (1:N): een klas heeft veel leerlingen, maar een leerling zit in een klas. Veel-op-veel (N:M): een leerling volgt veel vakken en een vak wordt door veel leerlingen gevolgd. De cardinaliteit bepaalt straks hoe je de relatie in tabellen omzet.

Van een informele beschrijving naar een ERD werk je stap voor stap. Lees de casus en onderstreep de zelfstandige naamwoorden: dat worden je kandidaat-entiteiten (Leerling, Klas, Vak). Zoek per entiteit de eigenschappen: dat worden de attributen. Zoek dan de werkwoorden die entiteiten verbinden ('een leerling zit in een klas', 'een leerling volgt een vak'): dat worden de relaties. Bepaal ten slotte voor elke relatie de cardinaliteit door je telkens twee vragen te stellen: 'hoeveel klassen horen bij een leerling?' en 'hoeveel leerlingen bij een klas?'. Uit 'een' en 'veel' volgt een 1:N-relatie. Zo ontstaat het diagram van Afb. 2.

ERD: leerlingen, klassen, vakken en docenten

Afb. 2Vereenvoudigd ERD van een schooladministratie. De drie cardinaliteiten komen alle voor: 1:1 (Klas-Docent), 1:N (Leerling-Klas) en N:M (Leerling-Vak). De N:M-relatie 'volgt' wordt in tabellen opgelost met een koppeltabel Inschrijving.

Een 1:1- of 1:N-relatie kun je rechtstreeks in tabellen leggen: bij 1:N zet je de sleutel van de 'een'-kant als refererende sleutel bij de 'veel'-kant (KlasID komt bij Leerling). Een veel-op-veel-relatie kan echter niet zo — je zou eindeloos veel vakcodes in de leerlingtabel moeten proppen. Daarom los je elke N:M-relatie op met een koppeltabel (ook wel tussentabel of associatieve entiteit): een aparte tabel die de relatie zelf voorstelt. De koppeltabel Inschrijving bevat twee refererende sleutels, LeerlingID en VakCode, en elke rij betekent 'deze leerling volgt dit vak'. Zo wordt een N:M-relatie twee keer een 1:N-relatie, en kun je bovendien extra gegevens over de inschrijving bewaren, zoals het behaalde cijfer.

Uitgewerkt voorbeeld

Van casus naar ERD

Op een school geldt: elke leerling zit in precies een klas, een klas heeft veel leerlingen; een leerling volgt meerdere vakken en een vak wordt door veel leerlingen gevolgd. Ontwerp het ERD met de juiste cardinaliteiten en geef aan hoe je de veel-op-veel-relatie in tabellen omzet.

Entiteiten bepalen
De zelfstandige naamwoorden leveren drie entiteiten: Leerling, Klas en Vak. Elk wordt straks een tabel met een eigen primaire sleutel (LeerlingID, KlasID, VakCode).
Cardinaliteit Leerling-Klas
'Een leerling zit in een klas' en 'een klas heeft veel leerlingen'. Een-veel dus: de relatie 'zit in' is 1:N tussen Klas en Leerling, met de veel-kant bij de leerlingen.
Cardinaliteit Leerling-Vak
'Een leerling volgt veel vakken' en 'een vak wordt door veel leerlingen gevolgd'. Veel aan beide kanten: de relatie 'volgt' is N:M.
1:N in tabellen leggen
Bij de 1:N-relatie zet je de sleutel van de een-kant als foreign key bij de veel-kant: de kolom KlasID komt in de tabel Leerling.
N:M oplossen met koppeltabel
De N:M-relatie kan niet met een enkele foreign key. Maak een koppeltabel Inschrijving(LeerlingID, VakCode) met beide sleutels als foreign key; elke rij is een leerling die een vak volgt, en je kunt er het cijfer aan toevoegen.

Resultaat: Drie entiteiten (Leerling, Klas, Vak); 'zit in' is 1:N met KlasID als foreign key in Leerling; 'volgt' is N:M en wordt opgelost met de koppeltabel Inschrijving(LeerlingID, VakCode).

Veelgemaakte fouten

Een attribuut bij de verkeerde entiteit plaatsen (vaknaam bij Leerling in plaats van bij Vak).
De cardinaliteit omdraaien; controleer altijd met beide vragen ('hoeveel X bij een Y?' en andersom).
Een N:M-relatie proberen te leggen met een enkele foreign key in plaats van met een koppeltabel.

Actieve herhaling

Een bibliotheek leent boeken uit aan leden: een lid kan meerdere boeken lenen en een boek kan in de loop van de tijd door meerdere leden geleend worden. Teken het ERD met de entiteiten Lid en Boek, benoem de cardinaliteit van de uitleen-relatie en geef de koppeltabel met de juiste refererende sleutels.

Actief ophalen

Haal de kernpunten op — onthul ze daarna.

Bronnen: Examenprogramma informatica (HAVO) (CvTE / Examenblad)

Normalisatie#

Vertiefungexamenblad-nl

Normaliseren is het stapsgewijs herstructureren van tabellen zodat elk gegeven maar op een plek staat. Het probleem dat je bestrijdt heet redundantie: dezelfde informatie die meermaals is opgeslagen. Bekijk een platte inschrijvingstabel waarin bij elke inschrijving ook de vaknaam en de docent staan (Afb. 3). Omdat Sara twee vakken volgt, staat haar naam er twee keer; omdat twee leerlingen Informatica volgen, staan 'Informatica' en de docent 'Dijk' er ook dubbel. Redundantie is niet alleen verspilling van ruimte, ze veroorzaakt drie soorten fouten — de anomalieen — die je gegevens langzaam inconsistent maken.

Ongenormaliseerde inschrijvingstabel met redundantie

Afb. 3In deze platte tabel staan Naam, Vaknaam en Docent meermaals (redundantie); de dubbele vaknaam 'Informatica' is gemarkeerd. Stap naar 3NF: splits in Leerling(LeerlingID, Naam), Vak(VakCode, Vaknaam, Docent) en koppeltabel Inschrijving(LeerlingID, VakCode).

De update-anomalie: verandert docent Dijk van naam, dan moet je dat in elke rij met Informatica aanpassen; vergeet je er een, dan spreekt de tabel zichzelf tegen. De insert-anomalie: je wilt een nieuw vak (Filosofie, docent Prins) vastleggen, maar er is nog geen leerling die het volgt — in de platte tabel kun je het vak dan nergens kwijt zonder een halflege rij te verzinnen. De delete-anomalie: verwijder je de enige leerling die Economie volgt, dan verdwijnt met die rij ook per ongeluk het bestaan van het vak Economie en zijn docent. Alle drie komen ze voort uit dezelfde oorzaak: gegevens die eigenlijk over verschillende dingen gaan, staan in een tabel door elkaar.

De sleutel om te normaliseren is de functionele afhankelijkheid. Attribuut B is functioneel afhankelijk van A (genoteerd

A \to B

) als bij elke waarde van A precies een waarde van B hoort. Zo bepaalt VakCode de Vaknaam: bij VakCode 'IN' hoort altijd 'Informatica', dus

\text{VakCode} \to \text{Vaknaam}

. En LeerlingID bepaalt de Naam. Het ideaal is dat in elke tabel alle niet-sleutelattributen volledig en uitsluitend afhangen van de (hele) primaire sleutel — kort gezegd: van de sleutel, de hele sleutel en niets dan de sleutel. Waar een attribuut van iets anders afhangt, hoort het in een eigen tabel thuis. De normaalvormen 1NF, 2NF en 3NF maken die eis stap voor stap concreet.

De eerste normaalvorm (1NF) eist dat elke cel een ondeelbare (atomaire) waarde bevat en dat er geen herhalende groepen zijn. Een kolom Vakken met de inhoud 'Informatica, Wiskunde' is dus verboden; je maakt er aparte rijen van. De tweede normaalvorm (2NF) geldt voor tabellen met een samengestelde sleutel en eist dat er geen deelsleutelafhankelijkheid is: geen enkel niet-sleutelattribuut mag van slechts een deel van de sleutel afhangen. In de tabel Inschrijving met sleutel (LeerlingID, VakCode) hangt Vaknaam alleen van VakCode af — een halve sleutel. Dat haal je eruit: Vaknaam verhuist naar een eigen tabel Vak, met VakCode als sleutel.

De derde normaalvorm (3NF) eist dat er geen transitieve afhankelijkheid is: een niet-sleutelattribuut mag niet via een ander niet-sleutelattribuut van de sleutel afhangen. Voorbeeld: in Vak(VakCode, Vaknaam, Docent, DocentKamer) bepaalt VakCode de Docent en de Docent bepaalt de DocentKamer, dus DocentKamer hangt niet rechtstreeks maar via Docent van de sleutel af (

\text{VakCode} \to \text{Docent} \to \text{DocentKamer}

). Je splitst Docent en DocentKamer af naar een eigen tabel Docent. Na 1NF, 2NF en 3NF staat elk feit precies een keer opgeslagen. Het doel is consistentie: de anomalieen zijn verdwenen, want je hoeft een gegeven nog maar op een plek te wijzigen, toe te voegen of te verwijderen. De prijs is dat je bij het opvragen tabellen weer moet samenvoegen met een JOIN.

Uitgewerkt voorbeeld

Normaliseren naar 3NF

Neem de platte tabel Inschrijving(LeerlingID, Naam, VakCode, Vaknaam, Docent) uit Afb. 3. Wijs een anomalie aan en normaliseer de tabel stap voor stap naar 1NF, 2NF en 3NF.

Anomalie aanwijzen
Docent 'Dijk' staat bij elke rij met Informatica. Wijzigt Dijk van naam, dan moet dat in alle Informatica-rijen (update-anomalie). En een vak zonder ingeschreven leerling past nergens in de tabel (insert-anomalie).
1NF controleren
Elke cel bevat al een atomaire waarde en er zijn geen herhalende groepen (geen cel met 'Informatica, Wiskunde'). De tabel voldoet dus al aan 1NF; de sleutel is de combinatie (LeerlingID, VakCode).
Naar 2NF: deelsleutel weghalen
Naam hangt alleen van LeerlingID af en Vaknaam alleen van VakCode — beide van een deel van de sleutel. Splits af: Leerling(LeerlingID, Naam) en Vak(VakCode, Vaknaam, Docent). Over blijft Inschrijving(LeerlingID, VakCode).
Naar 3NF: transitieve afhankelijkheid weghalen
Stel dat bij elke docent een vaste werkkamer hoort. Dan bepaalt VakCode de Docent en de Docent de DocentKamer: DocentKamer hangt transitief van de sleutel af. Verhuis de docentgegevens naar Docent(DocentID, Naam, Kamer) en zet DocentID als foreign key in Vak.
Resultaat controleren
Elk feit staat nu een keer: een leerlingnaam in Leerling, een vaknaam in Vak, een docentkamer in Docent. Bij het opvragen koppel je de tabellen weer met JOIN via de sleutels.

Resultaat: Een platte tabel wordt Leerling(LeerlingID, Naam), Vak(VakCode, Vaknaam, DocentID), Docent(DocentID, Naam, Kamer) en koppeltabel Inschrijving(LeerlingID, VakCode). Alle drie de anomalieen zijn verdwenen omdat elk gegeven nog maar op een plek staat.

Veelgemaakte fouten

Denken dat normaliseren gegevens weggooit; je verdeelt ze over meer tabellen die je met sleutels weer koppelt.
2NF (deelsleutel) en 3NF (transitief) verwarren; 2NF gaat over een deel van de sleutel, 3NF over een omweg via een ander gewoon attribuut.
Stoppen bij 1NF en de dubbele vaknaam en docent laten staan, waardoor de anomalieen blijven bestaan.

Actieve herhaling

Gegeven de platte tabel Bestelling(BestelID, Klantnaam, Klantadres, ArtikelCode, Artikelnaam, Aantal): wijs de redundantie en een update-anomalie aan en normaliseer de tabel naar 3NF. Geef de resulterende tabellen met hun primaire en refererende sleutels.

Actief ophalen

Haal de kernpunten op — onthul ze daarna.

Bronnen: Examenprogramma informatica (HAVO) (CvTE / Examenblad)

Query's met SQL#

Standardexamenblad-nl

Resultaat van een SELECT-query

Afb. 4De resultaatverzameling van de query SELECT Naam, Woonplaats FROM Leerling WHERE KlasID = 'H4A' ORDER BY Naam: alleen de rijen uit klas H4A (Afb. 1), alfabetisch op naam. Ook het antwoord op een query is weer een tabel.

Een query is een vraag die je in de taal SQL (Structured Query Language) aan de database stelt; het DBMS zoekt het antwoord op en geeft het terug als een tabel. De kernopdracht om gegevens op te vragen is `SELECT`. Je noemt achter `SELECT` welke kolommen je wilt zien, achter `FROM` uit welke tabel, en achter het optionele `WHERE` welke voorwaarde de rijen moeten halen. `SELECT Naam FROM Leerling WHERE Woonplaats = 'Utrecht'` levert de namen van alle Utrechtse leerlingen. Een sterretje (`SELECT *`) geeft alle kolommen. SQL is declaratief: je zegt wat je wilt, niet hoe de computer het moet zoeken — dat regelt het DBMS zelf.

Met `ORDER BY` sorteer je het resultaat op een kolom, standaard oplopend; `ORDER BY Naam` zet de namen alfabetisch, en met `DESC` erachter draai je de volgorde om. In de `WHERE`-voorwaarde gebruik je vergelijkingen (`=`, `<`, `>`, `<=`, `>=`, en `<>` voor 'ongelijk') en je kunt voorwaarden combineren met `AND`, `OR` en `NOT`. Zo geeft `SELECT Naam FROM Leerling WHERE KlasID = 'H4A' AND Woonplaats = 'Utrecht'` de Utrechtse leerlingen uit H4A. Tekstwaarden staan tussen enkele aanhalingstekens, getallen niet. Met een handvol sleutelwoorden bouw je zo precieze, herhaalbare vragen die altijd dezelfde structuur volgen.

Doordat je bij het normaliseren gegevens over meerdere tabellen hebt verdeeld, moet je ze bij het opvragen vaak weer samenvoegen. Dat doet de `JOIN`: die combineert rijen uit twee tabellen op grond van een gemeenschappelijke sleutel. Wil je bij elke leerling de naam van zijn klas tonen, dan koppel je Leerling aan Klas op KlasID: `SELECT Leerling.Naam, Klas.Klasnaam FROM Leerling JOIN Klas ON Leerling.KlasID = Klas.KlasID`. De `ON`-voorwaarde zegt welke foreign key op welke primaire sleutel moet passen. Zo betaalt normaliseren zich terug: je hebt geen dubbele opslag, en met een `JOIN` reconstrueer je bij het lezen precies het overzicht dat je nodig hebt.

Naast losse rijen kun je ook samenvattingen opvragen met aggregatiefuncties: `COUNT` telt rijen, `SUM` telt waarden op, `AVG` berekent het gemiddelde, en `MIN` en `MAX` geven de kleinste en de grootste waarde. `SELECT COUNT() FROM Leerling` geeft het totale aantal leerlingen. Met `GROUP BY` splits je de rijen eerst in groepen en reken je per groep: `SELECT KlasID, COUNT() FROM Leerling GROUP BY KlasID` geeft per klas het aantal leerlingen — een regel per klas. Aggregatie verandert dus veel rijen in een compact overzicht en is de basis voor vrijwel elke statistiek die een informatiesysteem toont, van 'aantal bestellingen per maand' tot 'gemiddeld cijfer per vak'.

Tot nu toe vroegen we gegevens alleen op; de tabel bleef ongewijzigd. SQL kent daarnaast opdrachten die de inhoud veranderen. `INSERT INTO Leerling (LeerlingID, Naam, KlasID) VALUES (5, 'Eva Mol', 'H4A')` voegt een nieuwe rij toe. `UPDATE Leerling SET KlasID = 'H5A' WHERE LeerlingID = 5` wijzigt bestaande rijen die aan de voorwaarde voldoen. `DELETE FROM Leerling WHERE LeerlingID = 5` verwijdert rijen. Let op de `WHERE`: vergeet je die bij `UPDATE` of `DELETE`, dan pas je alle rijen aan of wis je de hele tabel. Het onderscheid tussen opvragen (`SELECT`, verandert niets) en wijzigen (`INSERT`, `UPDATE`, `DELETE`) is wezenlijk, en het DBMS bewaakt daarbij de sleutels en de referentiele integriteit.

Uitgewerkt voorbeeld

Een SELECT-query schrijven

Gebruik de tabel Leerling(LeerlingID, Naam, Woonplaats, KlasID) uit Afb. 1. Schrijf een query die de naam en woonplaats geeft van alle leerlingen in klas H4A, alfabetisch gesorteerd op naam, en bepaal het resultaat.

Kies de kolommen (SELECT)
Gevraagd zijn naam en woonplaats, dus: SELECT Naam, Woonplaats. Uit welke tabel? FROM Leerling.
Filter de rijen (WHERE)
Alleen klas H4A telt mee. KlasID is tekst, dus tussen aanhalingstekens: WHERE KlasID = 'H4A'. Dit selecteert de rijen van Sara (Utrecht) en Iris (Utrecht); Tom (H4B) en Noah (H5A) vallen af.
Sorteer (ORDER BY)
Alfabetisch op naam: ORDER BY Naam. Van 'Iris Bakker' en 'Sara de Vries' komt Iris eerst, want de I komt in het alfabet voor de S.
Stel de volledige query op
Samengevoegd: SELECT Naam, Woonplaats FROM Leerling WHERE KlasID = 'H4A' ORDER BY Naam. Het DBMS voert eerst FROM en WHERE uit (selecteren), dan ORDER BY (sorteren) en toont ten slotte de gekozen kolommen.

Resultaat: De query SELECT Naam, Woonplaats FROM Leerling WHERE KlasID = 'H4A' ORDER BY Naam geeft twee rijen: Iris Bakker (Utrecht) en Sara de Vries (Utrecht) — zie Afb. 4.

Veelgemaakte fouten

Bij UPDATE of DELETE de WHERE-voorwaarde vergeten, waardoor de bewerking op alle rijen wordt uitgevoerd.
Tekstwaarden zonder aanhalingstekens schrijven (WHERE KlasID = H4A in plaats van WHERE KlasID = 'H4A').
Een JOIN vergeten en dan verbaasd zijn dat kolommen uit de tweede tabel niet beschikbaar zijn.

Actieve herhaling

Gegeven Leerling(LeerlingID, Naam, KlasID) en Klas(KlasID, Klasnaam, Mentor): schrijf een query die per klas het aantal leerlingen geeft, gesorteerd van veel naar weinig, en geef aan met welke sleutel je de tabellen eventueel moet koppelen.

Actief ophalen

Haal de kernpunten op — onthul ze daarna.

Bronnen: Examenprogramma informatica (HAVO) (CvTE / Examenblad)

Referenties en bronnen

Bronnen

CvTE / Examenblad

Examenprogramma informatica (HAVO)

Keuze H: Databases

Kernpunten

Sleutels aanwijzen in een tabel

Kernpunten

Van casus naar ERD

Kernpunten

Normaliseren naar 3NF

Kernpunten

Een SELECT-query schrijven

Bronnen

Keuze H: Databases

Kernpunten

Sleutels aanwijzen in een tabel

Kernpunten

Van casus naar ERD

Kernpunten

Normaliseren naar 3NF

Kernpunten

Een SELECT-query schrijven

Bronnen