EuraStudy
Samenvattingen/Informatica/Keuze H: Databases
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.

4 Onderdelen·~21 min leestijd·4 Vaardigheden·Niveau Basis 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

Leesdiepte: Verdieping

Tekst

Tekstgrootte: Standaard

Inhoud · 4 onderdelen▾
  1. Keuze H: Databases
    • 01Het relationele model○
    • 02Datamodellering met een ERD◐
    • 03Normalisatie●
    • 04Query's met SQL◐
§ 01

Het relationele model#

●○○BasisLPexamenblad-nl

Kernpunten

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

Tabel LeerlingTabel met 4 kolommen en 4 rijen, Gegevens: LeerlingID (PK) · Naam · Woonplaats · KlasID (FK); 1 · Sara de Vries · Utrecht · H4A; 2 · Tom Jansen · Zeist · H4B; 3 · Iris Bakker · Utrecht · H4A; 4 · Noah Smit · Bunnik · H5A, gemarkeerde cel: 1LEERLINGID (PK)NAAMWOONPLAATSKLASID (FK)1Sara de VriesUtrechtH4A2Tom JansenZeistH4B3Iris BakkerUtrechtH4A4Noah SmitBunnikH5A
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?

  1. 01Zoek 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.

  2. 02Toets 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.

  3. 03Herken 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).

  4. 04Beschrijf 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.

Eindexamen-focus

  • In een gegeven tabel de primaire sleutel aanwijzen en uitleggen waarom die kolom uniek en niet-leeg moet zijn.
  • De refererende sleutel (foreign key) herkennen en aangeven naar welke tabel en welke kolom die verwijst.
  • Het verschil tussen een database (met DBMS) en een los bestand benoemen, inclusief de begrippen relatie, tupel en attribuut.

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)

§ 02

Datamodellering met een ERD#

●●○StandaardLPexamenblad-nl

Kernpunten

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

ERD (vereenvoudigd)Graaf, Leerling → Klas, Leerling → Vak, Klas → DocentLeerlingKlasVakDocentN : 1 zit inN : M volgt1 : 1 mentor
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.

  1. 01Entiteiten bepalen

    De zelfstandige naamwoorden leveren drie entiteiten: Leerling, Klas en Vak. Elk wordt straks een tabel met een eigen primaire sleutel (LeerlingID, KlasID, VakCode).

  2. 02Cardinaliteit 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.

  3. 03Cardinaliteit 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.

  4. 041: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.

  5. 05N: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).

Eindexamen-focus

  • Uit een gegeven casus de entiteiten, attributen en relaties halen en er een correct ERD van tekenen.
  • Bij elke relatie de juiste cardinaliteit (1:1, 1:N of N:M) bepalen en onderbouwen met de twee tel-vragen.
  • Uitleggen hoe je een N:M-relatie met een koppeltabel oplost en welke refererende sleutels die tabel bevat.

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)

§ 03

Normalisatie#

●●●VerdiepingLPexamenblad-nl

Kernpunten

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

Inschrijving (plat)Tabel met 5 kolommen en 4 rijen, Gegevens: LeerlingID · Naam · VakCode · Vaknaam · Docent; 1 · Sara · IN · Informatica · Dijk; 1 · Sara · WI · Wiskunde · Vos; 2 · Tom · IN · Informatica · Dijk; 3 · Iris · EC · Economie · Berg, gemarkeerde cel: InformaticaLEERLINGIDNAAMVAKCODEVAKNAAMDOCENT1SaraINInformaticaDijk1SaraWIWiskundeVos2TomINInformaticaDijk3IrisECEconomieBerg
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→BA \to BA→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 VakCode→Vaknaam\text{VakCode} \to \text{Vaknaam}VakCode→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 (VakCode→Docent→DocentKamer\text{VakCode} \to \text{Docent} \to \text{DocentKamer}VakCode→Docent→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.

  1. 01Anomalie 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).

  2. 021NF 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).

  3. 03Naar 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).

  4. 04Naar 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.

  5. 05Resultaat 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.

Eindexamen-focus

  • In een gegeven platte tabel de redundantie en de drie anomalieen (update, insert, delete) aanwijzen.
  • Een tabel stap voor stap normaliseren naar 1NF, 2NF en 3NF en per stap zeggen welke afhankelijkheid je oplost.
  • Een functionele afhankelijkheid herkennen en het begrip transitieve afhankelijkheid toepassen.

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)

§ 04

Query's met SQL#

●●○StandaardLPexamenblad-nl

Resultaat van een SELECT-query

Resultaat (2 rijen)Tabel met 2 kolommen en 2 rijen, Gegevens: Naam · Woonplaats; Iris Bakker · Utrecht; Sara de Vries · UtrechtNAAMWOONPLAATSIris BakkerUtrechtSara de VriesUtrecht
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.

Kernpunten

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.

  1. 01Kies de kolommen (SELECT)

    Gevraagd zijn naam en woonplaats, dus: SELECT Naam, Woonplaats. Uit welke tabel? FROM Leerling.

  2. 02Filter 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.

  3. 03Sorteer (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.

  4. 04Stel 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.

Eindexamen-focus

  • Een SELECT-query lezen en zelf schrijven met FROM, een WHERE-voorwaarde en ORDER BY.
  • Uitleggen wat een JOIN doet en twee tabellen op hun gemeenschappelijke sleutel combineren.
  • Aggregatie met COUNT, SUM of AVG in combinatie met GROUP BY toepassen en het resultaat voorspellen.
  • Het verschil tussen opvragen (SELECT) en wijzigen (INSERT/UPDATE/DELETE) benoemen.

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)

Inhoud

Sectie -- / 04

    • 01Het relationele model○
    • 02Datamodellering met een ERD◐
    • 03Normalisatie●
    • 04Query's met SQL◐

0/4 Gelezen

Van samenvatting naar oefening

Keuze H: Databases

Verstevig dit onderwerp met vragen uit de vragenbank.

~21
min
4
Vaardigheden
Oefenen

Referenties en bronnen

Bronnen

CvTE / Examenblad

  • Examenprogramma informatica (HAVO)

Vorig onderwerp

Domein F: Interactie

Volgend onderwerp

Keuze L: Netwerken

EuraStudy·Samenvattingen T·07·MMXXVI

Ga verder met het volgende onderwerp — je leerpad blijft bewaard.