theorie normaliseren

Gegevensbeheer 3
p. 1
1 INLEIDING
Meestal speelt het voor langere tijd bewaren van gegevens, een belangrijke rol in
informatiesystemen.
1.1 Databases
Een database of gegevensbank is een gestructureerde, digitaal bewaarde
verzameling gegevens, opgezet om in een bepaalde informatiebehoefte te voorzien.
Een database is een hulpmiddel voor de informatievoorziening, aan een individuele
gebruiker of aan een organisatie. Niet alle gegevens die in een organisatie nodig zijn
hoeven te worden gestructureerd in een database. De technische of economische
noodzaak voor een database is aanwezig wanneer de informatievoorziening als volgt
gekarakteriseerd kan worden:
 De gegevens worden frequent opgevraagd.
 De zoekinspanning van de gebruiker moet minimaal zijn. In plaats van de
gebruiker te laten bladeren door lange lijsten is het gewenst dat het systeem het
gevraagde zoekt en aanbiedt.
 Er is behoefte aan antwoorden op complexere vragen dan alleen het opvragen
van opgeslagen gegevens. Het moet mogelijk zijn om het systeem te laten zoeken
naar combinaties van gegevens en om filters te gebruiken.
1.2 Analyse van de informatiebehoefte
Als besloten is om een database te gaan opzetten dan zal de eerstvolgende stap zijn
het in kaart brengen van de gewenste functie van die database voor de organisatie.
Dit komt neer op een analyse van de informatiebehoefte. Daarbij komen de volgende
aspecten aan bod:
 Er moet duidelijkheid komen over de omvang en aard van het domein waarover
informatie gevraagd zal worden. Over welke dingen gaat het, welke
eigenschappen van die dingen zijn van belang (of kunnen dat in de toekomst
worden) en welke niet. Een domein is het relevante deel van de werkelijkheid voor
wat betreft de informatiebehoefte. De dingen in het domein worden entiteiten
genoemd. Bijvoorbeeld bij een personeelsadministratie zijn de volgende entiteiten
belangrijk: personeelslid, afdeling, functiebeschrijvingen…
 Er moet ingeschat worden welke (soorten) vragen in welke frequentie gesteld
zullen worden. Als die frequentie hoog is, dan zal dat extra eisen stellen aan de
computerimplementatie van de database. Er moet ingeschat worden of bepaalde
combinaties van gegevens opgevraagd zullen worden, of dat er bepaalde
zoekfilters gebruikt gaan worden.
Ann De Ridder
Gegevensbeheer 3
p. 2
 Het verwachte aantal gebruikers van de database. Dit kan variëren van 1 tot zeer
veel. Vormen ze een homogene groep? Worden de gebruikers getraind in het
werken met de database, of gaat het om incidentele gebruikers? Wat is een
acceptabele wachttijd op een antwoord van het database systeem?
 Het verwachte aantal externe softwarepakketten dat de database aanspreekt. Als
de database rechtstreeks of via internet verbonden is met andere
computerprogramma’s, dan zal het database systeem daardoor belast worden,
mogelijk met nadelige gevolgen voor de ‘gewone’ gebruikers.
 De te verstrekken privileges aan de gebruikers. Het kan de bedoeling zijn dat
verschillende (groepen) gebruikers verschillende rechten van toegang tot de
gegevens krijgen. De gegevens moeten selectief beveiligd of beschermd kunnen
worden.
 Het moet duidelijk zijn welke partijen het recht (of de plicht) hebben gegevens in te
voeren in en/of te verwijderen uit de database. Ook hier spelen kwantitatieve
aspecten zoals de omvang van de ingevoerde gegevensstroom een rol.
 Er moet ingeschat worden hoe duurzaam de gegevens moeten zijn. Soms zijn
alleen actuele gegevens van belang (bijvoorbeeld verkeersinformatie), soms
moeten gegevens na 50 jaar nog beschikbaar zijn (bijvoorbeeld
bevolkingsregister).
 Er moet ingeschat worden hoe duurzaam de structuur van de gegevens is. Let op
het grote verschil van dit punt met het hiervoor genoemde punt. Een DBS
(database systeem) is ontworpen op (snelle) veranderingen van de inhoud, maar
wel binnen steeds dezelfde structuur van de database. Als de informatiebehoefte
zou veranderen dan moet soms de gegevensstructuur van de database herzien
worden. Dit kan zeer duur zijn, vandaar dat dit punt extra aandacht verdient.
Overigens is het gebruikelijk dat een database meegroeit met een organisatie of
met een toepassing. Het moet daarom mogelijk zijn om de gegevensstructuur aan
te passen.
1.3 Datamodel
1.3.1 Betekenis
Een model is een abstracte voorstelling van (een deel van) de reële wereld. Dit wil
zeggen dat de maker van een model bepaalde essentiële kenmerken van de realiteit
isoleert, en alle andere kenmerken als bijkomstig achterwege laat.
Een gegevensmodel of datamodel is een abstracte voorstelling van een
informatiesysteem, waarbij alle dynamische aspecten (generatie, transformatie en
verwerking van gegevens) achterwege blijven, en slechts statische
informatiestructuren, hun beperkingen en hun onderlinge verbanden van belang zijn.
Ann De Ridder
Gegevensbeheer 3
p. 3
Een datamodel gaat over de structuur van gegevens, niet over de inhoudelijke
opvulling. Een gegevensmodel kan specifiëren dat een bedrijf de namen en adressen
van zijn werknemers opslaat. Het zegt niet dat er een werknemer bestaat met de
naam Peeters, en evenmin dat de namen en adressen worden verkregen via de
personeelsdienst. Het kan wel bepalen dat ieder adres een postnummer moet
bevatten.
Een procesmodel brengt de dynamische aspecten in beeld. Een
gegevensstroomdiagram (Data Flow Diagram, DFD) is hiervan een voorbeeld. Het
toont op een visuele manier waar de data gegenereerd en verwerkt worden en
waarheen ze getransporteerd worden.
Een gegevensmodel wordt gebruikt voor het structureren van een database terwijl
een gegevensstroomschema eerder gebruikt wordt voor het programmeren.
1.3.2 Waarom modelleren?
Het doel van het gegevensmodel is een éénduidige voorstelling te krijgen van de
structuren en verbanden die ten grondslag liggen aan de verschillende
informatiestromen en –archieven in een informatiesysteem. Als dusdanig vormt het
gegevensmodel een communicatiemiddel tussen verschillende belanghebbenden
van het informatiesysteem:
 programmeurs (ontwikkeling en onderhoud)
 analisten
 gebruikers
 beheerders
 …
1.3.3 Verschillende modellen
Er worden heel wat verschillende datamodellen gebruikt. Het Entiteit Relatie (EntityRelationship) Diagram is één van de bekendste traditionele modellen. Zie
hoofdstuk 3.
Ann De Ridder
Gegevensbeheer 3
p. 4
1.4 Databasesystemen
De software die het werken met een database mogelijk maakt, is het database
managementsysteem (DBMS). Het geheel van database en DBMS is dan het
database-systeem (DBS).
Als je een datamodel hebt gemaakt, moet je dit omzetten naar een dataschema voor
een bepaald type database-systeem. Er bestaan verschillende types. Het DBS dat in
deze nota’s besproken wordt is MS Access. De structuur waarin de gegevens
worden opgeslagen, wordt bepaald door de databaseontwerper. Het DBMS waarmee
gewerkt wordt, bepaalt het structuurtype. MS Access is een RDBMS. De R staat voor
Relationeel.
Ann De Ridder
Gegevensbeheer 3
p. 5
2 NORMALISEREN, INLEIDING
Voor het bepalen van de indeling van de database bestaan verschillende technieken.
Wij zullen gebruikmaken van de techniek van het normaliseren, zoals die door de
Amerikaan Edgar Codd in de jaren zeventig is opgesteld.
Het doel van normalisatie is het vermijden van redundantie. Redundantie betekent,
dat bepaalde informatie tegelijkertijd op meer dan één plaats wordt voorgesteld. De
voornaamste nadelen van redundantie zijn:
 risico’s van inconsistentie: indien hetzelfde soort informatie op meer dan één
plaats tegelijk aanwezig is, dan kunnen de verschillende plaatsen van
informatieopslag elkaar tegenspreken;
 moeilijker gegevensonderhoud: sommige wijzigingen moeten op verschillende
plaatsen tegelijk worden doorgevoerd.
Normaliseren houdt in dat we in een viertal stappen de gegevens uiteenrafelen en
indelen in een beperkt aantal, overzichtelijke tabellen.
2.1 Stap 1, de nulde normaalvorm
Uitgangspunt van het normaliseren is steeds de informatiebehoefte van de
toekomstige gebruiker van de database. De indeling en inhoud van de tabellen wordt
bepaald door de informatie die de gebruiker wenst te zien.
Stel dat een gebruiker een database wil met daarin de gegevens van zijn
muziekcollectie. Als hij aangeeft geïnteresseerd te zijn in het jaar van uitbrengen van
de cd, dan zullen we dit jaartal uiteraard moeten opnemen in de database. Als hij
aangeeft absoluut niet te willen weten door welke muziekmaatschappij een cd is
uitgegeven, heeft het geen zin om dit gegeven wel in de database op te nemen. Voor
een andere opdrachtgever zou het precies andersom kunnen zijn. Het is dus
noodzakelijk om tijdens het ontwerpen van een database vaak contact te hebben met
de toekomstige gebruiker.
Praktijkvoorbeeld
Paul, DJ bij de lokale radio, verzorgt driemaal per week een twee uur durend
programma waarin hij zijn favoriete muziek laat horen en nieuwe cd’s onder de
aandacht wil brengen. Hij krijgt hiervoor een kleine onkostenvergoeding die hij
gebruikt om zijn cd-collectie langzaam uit te breiden. Aan het einde van iedere
maand moet Paul een overzicht inleveren van alle nummers die hij die maand heeft
Ann De Ridder
Gegevensbeheer 3
p. 6
laten horen. Aan de hand van deze overzichten zorgt de stichting BUMA/STEMRA
ervoor dat de betreffende artiesten een kleine vergoeding krijgen.
Paul weet meestal aan het einde van de maand niet meer precies wat hij aan het
begin van de maand allemaal heeft gedraaid. Daarom maakt hij het betreffende
overzicht (zie figuur 1) direct na afloop van het programma. Daarop staat vermeld
welke nummers hij heeft gedraaid. Ieder nummer heeft een eigen code. Deze code is
bepaald door één van de medewerkers van het lokale radiostation. Natuurlijk is van
ieder nummer ook bekend wat de titel is en wie de uitvoerende artiest(en) is/zijn. Ten
slotte noteert men ook of het nummer van een gewone cd afkomstig is of dat het op
een single cd staat. Aan het einde van de maand levert hij dan de stapel met deze
‘dagelijkse’ overzichten in. Hij is echter al een paar keer zo’n dagoverzicht
kwijtgeraakt, met alle gevolgen van dien. Hij vraagt ons daarom om voor hem een
database te ontwerpen waarmee hij aan het einde van de maand het gewenste
overzicht kan maken.
We nemen aan de hand van figuur 1 de eerste stap om de gegevens uiteen te
rafelen. We krijgen dan de zogenaamde nulde normaalvorm. We bepalen de nulde
normaalvorm door alle elementaire, relevante gegevens te bepalen en op te
schrijven.
Figuur 1
Allereerst zien we een koptekst boven het overzicht. Deze koptekst is op ieder
overzicht van Paul hetzelfde (constant), ongeacht de datum en ongeacht de
gedraaide nummers. Omdat de koptekst onveranderlijk is, nemen we deze niet op in
de database. Constante gegevens nemen we nooit op in de database.
Vervolgens zien we een aantal gegevens die iedere keer zullen verschillen: de datum
en de gegevens van de gedraaide muziek. Deze gegevens moeten we natuurlijk wel
opnemen in de database omdat we ze anders kwijt zijn.
Ann De Ridder
Gegevensbeheer 3
p. 7
Ten slotte zien we onder in het overzicht nog een totaal aantal getoond. Dit totaal is
af te leiden uit het overzicht door simpelweg het aantal afgedrukte en dus gedraaide
nummers te tellen. We noemen het totaal aantal een procesgegeven omdat we het
gegeven zelf kunnen bepalen door een rekenproces te laten uitvoeren.
Procesgegevens nemen we nooit op in de database.
Wat we overhouden aan relevante gegevens bestaat uit: datum, code, titel, artiest en
soort. De aanduiding soort is echter niet elementair. Met de aanduiding soort
bedoelen we twee gegevens, te weten een soortcode (bijvoorbeeld S) en een
soortomschrijving (bijvoorbeeld Single). We moeten de aanduiding soort daarom
splitsen in twee elementaire gegevens, te weten soortcode en soortomschrijving. Dit
splitsen moeten we altijd doen in het geval dat we te maken hebben met
samengestelde gegevens.
We houden nu dus over de elementaire gegevens: datum, code, titel, artiest,
soortcode en soortomschrijving. In plaats van gegevens zullen we meestal de term
attributen gebruiken.
Met de door ons gevonden attributen is iets speciaals aan de hand. Het eerste
gegeven, de datum, komen we maar één keer tegen. De andere gegevens komen
we meerdere keren tegen. Om dit verschil duidelijk te maken, noteren we onze
gegevens daarom op de volgende manier:
datum, RG(code, titel, artiest, soortcode, soortomschrijving)
Daarbij staat RG voor repeterende groep (repeating group). Alle gegevens die
meerdere keren, repeterend, voorkomen, staan vervolgens tussen ronde haken
vermeld.
Het overzicht uit figuur 1 is het overzicht van 17 februari 2001. Paul beschikt echter
voor iedere dag, dat hij een programma heeft gepresenteerd, over een dergelijk
overzicht. Om uit de hele stapel met alle overzichten precies het door ons getoonde
overzicht te pakken, moeten we weten van welke datum we iets willen weten. De
datum wijst in ons geval precies één overzicht aan. De datum geeft ons toegang tot
precies één overzicht. We noemen daarom de datum ook wel het sleutelgegeven
ofwel sleutelattribuut. We geven het sleutelattribuut aan door dit te onderstrepen. We
hebben nu uiteindelijk de nulde normaalvorm gevonden. We noteren dit op de
volgende manier:
0 NV (datum, RG(code, titel, artiest, soortcode, soortomschrijving))
Ann De Ridder
Gegevensbeheer 3
p. 8
OPMERKING
 Een sleutelattribuut moet altijd een waarde hebben.
 Een sleutelattribuut moet altijd uniek zijn.
 Een sleutelattribuut moet altijd zo minimaal mogelijk zijn. Als de datum volstaat als
sleutel, dan zal ook de combinatie dagaanduiding met datum volstaan. We zouden
dan de sleutel datum + dag krijgen (bijvoorbeeld: 23-1-2001 + zaterdag). Omdat
we echter ook met een deel hiervan (datum) als sleutel kunnen werken, zijn we
verplicht het overtollige deel, de dagaanduiding, weg te laten.
 Soms kunnen meerdere attributen als sleutelattribuut fungeren. Dit noemen we
kandidaat-sleutels. In het algemeen kiest men uit de kandidaat-sleutels er één die
als sleutelattribuut zal gaan fungeren.
OEFENING 1
a. In een bibliotheek zal men de afzonderlijke boeken moeten kunnen aanduiden.
Hiertoe zullen zij een sleutelattribuut hebben gedefinieerd. Zou men hiervoor het
ISBN gebruiken? Verklaar het antwoord.
b. Gegeven het overzicht uit figuur 2. Stel hiervan de nulde normaalvorm op.
Figuur 2
Ann De Ridder
Gegevensbeheer 3
p. 9
2.2 Stap 2, de eerste normaalvorm
In de nulde normaalvorm zitten een aantal problemen verborgen o.a. wat als een
nummer meerdere keren door Paul is gedraaid? Iedere keer zal hij steeds alle
gegevens van dat nummer noteren, dus code, titel, artiest, soortcode en
soortomschrijving. Dat betekent dat als Paul het nummer Coming Home van Romeo
in een jaar zestig keer heeft gedraaid, hij ook zestig keer alle gegevens heeft
genoteerd. Waarom kunnen we niet volstaan met het één keer noteren van alle
gegevens? Natuurlijk moeten we dan wel iedere keer even noteren dat we dat
nummer hebben gedraaid, maar dat doen we dan kortweg via het noteren van alleen
maar de code. In de eerste normaalvorm wordt dit probleem gedeeltelijk opgelost.
We bepalen de eerste normaalvorm door de repeterende groep apart te nemen en
uit te breiden met de sleutel van de originele nulde normaalvorm. Hierna bepalen we
in de nu nieuw gevonden reeks weer een sleutel.
De repeterende groep bestaat uit (code, titel, artiest, soortcode, soortomschrijving).
Deze nemen we apart en we voegen de sleutel (datum) eraan toe. We krijgen dan:
(datum, code, titel, artiest, soortcode, soortomschrijving)
Let erop dat we de datum, hoewel die in de eerste normaalvorm sleutel was en dus
onderstreept, nu niet zonder meer opnieuw onderstrepen. We gaan nu een nieuwe
sleutel aanwijzen. Daartoe moeten we ons eerst afvragen hoe we de nu ontstane
groep terugzien op het originele overzicht (zie figuur 1). Dan weten we wat we
proberen en kunnen we bepalen wat een goede sleutelkeuze is.
Onze groep gegevens, met eenmaal een datum, eenmaal een code, eenmaal een
titel, enzovoort vinden we terug als een enkele regel van het overzicht. Om precies
één regel op een bepaald formulier aan te duiden, moeten we eerst aangeven naar
welk formulier, van welke datum, we willen kijken. Daartoe dienen we dus de datum
op te geven. Vervolgens selecteren we één enkele regel van het betreffende
overzicht door de code van het betreffende nummer op te geven. Iedere code komt
hooguit één keer op een overzicht voor omdat Paul nooit twee maal hetzelfde
nummer in dezelfde uitzending draait. De combinatie van datum en code kan dus
fungeren als sleutel. We krijgen dan:
(datum, code, titel, artiest, soortcode, soortomschrijving)
Ann De Ridder
Gegevensbeheer 3
p. 10
Omdat de sleutel nu bestaat uit twee delen en omdat een sleutel altijd minimaal moet
zijn, moeten we wel even controleren of een kleinere sleutel ook voldoet. Dus we
gaan na of alleen de datum als sleutel ook voldoet. Dat is natuurlijk niet zo, want bij
één datum vinden we meerdere nummers die Paul heeft gedraaid, dus meerdere
regels, en we zoeken precies één regel.
Kunnen we misschien volstaan met alleen de code van het nummer als sleutel? Dat
zou kunnen als Paul een nummer nooit meer dan één keer draait, ook niet op
verschillende dagen. Omdat wij weten dat Paul wel degelijk nummers vaker draait,
ontstaat het probleem dat we een bepaalde code op meerdere overzichten, van
verschillende data, kunnen terugvinden. Daardoor wijzen we dus niet slechts één,
maar meerdere regels aan, hoewel die op verschillende overzichten liggen. Dus
alleen de code voldoet ook niet als sleutel. De door ons eerder gekozen,
gecombineerde, sleutel is dus de juiste.
We moeten ons werk nog afmaken. Dat doen we door in de originele nulde
normaalvorm de door ons apart genomen repeterende groep te verwijderen en te
kijken wat er overblijft. Wat er overblijft, voegen we als aparte groep toe aan de
eerste normaalvorm.
We hadden als nulde normaalvorm gevonden:
(datum, RG(code, titel, artiest, soortcode, soortomschrijving))
Door de repeterende groep te verwijderen, houden we alleen over:
(datum)
Deze groep voegen we toe. We krijgen dan uiteindelijk de eerste normaalvorm:
1 NV (datum)
(datum, code, titel, artiest, soortcode, soortomschrijving)
We zien dat we nu geen repeterende groep meer over hebben. We zijn dus
gedeeltelijk geslaagd in onze opzet. Nog steeds zitten we met het probleem dat als
Paul een nummer vaker draait, we steeds opnieuw alle gegevens zitten te noteren.
We zijn dus nog steeds niet klaar.
OPMERKING
In het toegelichte voorbeeld zien we dat de sleutel uit de nulde normaalvorm (datum)
ook in de eerste normaalvorm weer onderdeel van de sleutel is. Vaak is dat zo, maar
lang niet altijd. Let dus goed op bij het kiezen van een nieuwe sleutel!
Ann De Ridder
Gegevensbeheer 3
p. 11
OEFENING 2
a. Gegeven is het overzicht uit figuur 3. Iemand heeft daarbij de volgende nulde
normaalvorm gevonden.
0 NV
(Bestelnummer, naam klant, RG(artikelnr, omschrijving, prijs p/s,
aantal), korting%)
Waarom zijn het bedrag per regel, het subtotaal, het kortingsbedrag en het
eindtotaal niet opengenomen in de nulde normaalvorm?
Bepaal uitgaande van de genoemde nulde normaalvorm de eerste normaalvorm.
Figuur 3
b. Ga uit van de nulde normaalvorm die je eerder bij opdracht 1.b gevonden hebt en
bepaal de daarbij behorende eerste normaalvorm. Controleer goed of de gekozen
sleutel niet korter kan.
Ann De Ridder
Gegevensbeheer 3
p. 12
2.3 Stap 3, de tweede normaalvorm
Om te komen tot de tweede normaalvorm onderzoeken we in de eerste normaalvorm
of er attributen (gegevens) zijn die niet tot de sleutel behoren (niet onderstreept) en
die niet van de gehele sleutel afhangen, maar slechts van een gedeelte van de
sleutel. We zullen deze moeilijk lijkende regel aan de hand van ons voorbeeld
toelichten. We kijken alleen maar naar groepen in de eerste normaalvorm waarbij de
sleutel samengesteld is, dus uit meerdere attributen bestaat. In ons geval de groep:
(datum, code, titel, artiest, soortcode, soortomschrijving)
We moeten nu zoeken naar niet-sleutelattributen die slechts afhankelijk zijn van een
deel van de sleutel, dus in ons voorbeeld van alleen de datum of alleen de code. De
gegevens titel, artiest, soortcode en soortomschrijving hebben niets te maken met de
datum, maar zijn alleen maar afhankelijk van de code van het gedraaide nummer
(‘vertel ons de code en wij vertellen u de artiest, de titel, enzovoort’). Die hebben dus
niets te maken met de datum.
Kortom, de gegevens titel, artiest, soortcode en soortomschrijving zijn niet afhankelijk
van de gehele sleutel maar slechts van een deel van de sleutel. Deze gegevens
nemen we apart, tezamen met het deel van de sleutel waarvan ze afhankelijk blijken
te zijn. We krijgen dan:
(code, titel, artiest, soortcode, soortomschrijving)
In de originele groep laten we de betreffende niet-sleutelvelden achterwege. We
krijgen dus:
(datum, code)
Let erop dat het sleuteldeel waarvan de niet-sleutelvelden afhankelijk waren (code) in
deze groep gewoon blijft bestaan.
De nu gevonden groepen:
(code, titel, artiest, soortcode, soortomschrijving)
(datum, code)
vullen we ten slotte aan met de groepen die we in de eerste normaalvorm al hadden
gevonden maar waar geen samengestelde sleutel in aanwezig was.
Ann De Ridder
Gegevensbeheer 3
p. 13
We krijgen dan uiteindelijk de tweede normaalvorm:
2 NV (code, titel, artiest, soortcode, soortomschrijving)
(datum, code)
(datum)
We hebben nu veel overtolligheid (redundantie) opgeheven. Dat komt doordat in de
eerste groep de code de sleutel is. Ieder nummer wordt hierin hooguit één keer
opgenomen. Wordt een nummer nu vaker gedraaid, dan wordt het zo vaak als nodig
opgenomen in de tweede groep (datum, code). De gegevens van het nummer zelf,
zoals de titel, zijn echter al bekend in de eerste groep en worden daar dus niet nog
eens opgenomen. Het achteraf corrigeren van een typefout in de naam van de artiest
is nu dus eenvoudig want het hoeft slechts één maal te worden uitgevoerd.
OEFENING 3
a. Gegeven is het overzicht uit figuur 3. Iemand heeft daarbij de volgende eerste
normaalvorm gevonden.
1 NV
(Bestelnummer, naam klant, kortings%)
(Bestelnummer, artikelnr, omschrijving, prijs p/s, aantal)
Bepaal uitgaande van de bovenstaande eerste normaalvorm de tweede
normaalvorm.
b. Wat is het wezenlijke verschil tussen de 1 NV zoals die bij opdracht 3.a is gegeven
en zoals die hieronder staat afgedrukt?
1 NV
(Bestelnummer, naam klant)
(Bestelnummer, artikelnr, omschrijving, prijs p/s, aantal, kortings%)
Ann De Ridder
Gegevensbeheer 3
p. 14
2.4 Stap 4, de derde normaalvorm
Er zit in de tweede normaalvorm nog een vorm van overtolligheid (redundantie). Die
heeft te maken met de attributen soortcode en soortomschrijving. Bij ieder nummer
staan beide gegevens opgenomen. Als we de gegevens van 1000 nummers op
single hebben, zal de combinatie S, Single dus 1000 keer zijn opgenomen. Ook hier
zouden we met één keer klaar moeten zijn. Wel bij iedere single noteren dat het een
single is (soortcode = S) maar slechts één maal noteren dat de code S staat voor de
omschrijving Single. Door deze overtolligheid eruit te halen, ontstaat de derde
normaalvorm.
Om de derde normaalvorm te bepalen, vragen we ons af of er niet-sleutelattributen
(niet-onderstreepte gegevens) zijn die niet afhangen van de sleutel maar die eigenlijk
afhangen van andere niet-sleutelattributen. Als dat zo is, nemen we deze gegevens
op in een nieuwe groep, geven daar de sleutel aan en verwijderen uit de originele
groep het afhankelijke attribuut.
Om de titel van een nummer te weten te komen, hebben we niets aan de artiest, die
kan immers meerdere nummers op zijn repertoire hebben staan. Het heeft ook niets
te maken met de soort muziekdrager, single of cd. Nee, de titel is geheel afhankelijk
van de code van het nummer: ‘vertel ons de code en wij vertellen u welke titel daarbij
hoort’. De titel is dus geheel afhankelijk van de sleutel. We laten de titel met rust. Om
dezelfde reden doen we niets met artiest en soortcode.
Met de soortomschrijving is wel iets speciaals aan de hand. Om deze te weten te
komen, hoeven we niet te weten over welk nummer we precies praten (de code)
maar moeten we weten welke soortcode van toepassing is: ‘vertel ons de soortcode
en wij vertellen u de soortomschrijving’. De soortcode heeft dus niets te maken met
de sleutel maar alles met een ander niet-sleutelattribuut. We nemen deze twee
attributen daarom apart op in een afzonderlijke groep:
(soortcode, soortomschrijving)
Daarbij geldt dat de soortcode het sleutelattribuut zal worden: ‘vertel ons de code en
wij vertellen u de omschrijving’. Dus:
(soortcode, soortomschrijving)
In de originele groep laten we het afhankelijke niet-sleutelattribuut (soortomschrijving)
achterwege. We houden dan over:
(code, titel, artiest, soortcode)
Ann De Ridder
Gegevensbeheer 3
p. 15
Let erop dat het attribuut dat sleutel is geworden in de nieuwe groep, in de
oorspronkelijke groep gewoon blijft bestaan!
Door de beide zojuist gevonden groepen aan te vullen met de andere, niet
veranderde groepen uit de tweede normaalvorm, ontstaat de volgende derde
normaalvorm:
3 NV (soortcode, soortomschrijving)
(code, titel, artiest, soortcode)
(datum, code)
(datum)
Deze derde normaalvorm is het uiteindelijke doel geweest van het
normalisatieproces. Deze nu gevonden groepen kunnen we later op eenvoudige
wijze opnemen in een database. Iedere gevonden groep zal daarbij worden vertaald
in een afzonderlijke tabel. Hierdoor kunnen we later op relatief eenvoudige wijze alle
gegevens invoeren en alle gewenste informatie opvragen.
De eerste tabel geven we de naam SOORT omdat daarin de soort muziekdrager
wordt bijgehouden, single of cd. De tweede tabel noemen we TRACK omdat daarin
de gegevens van de tracks worden bijgehouden. In de derde tabel worden de
gegevens bijgehouden van de nummers die gedraaid zijn, we kunnen dit zien als een
DRAAILIJST. Ten slotte hebben we nog de laatste tabel waarin de data liggen
opgeslagen van de dagen waarop Paul een programma heeft verzorgd. Deze tabel
noemen we DATUM.
3 NV SOORT
(soortcode, soortomschrijving)
TRACK
(code, titel, artiest, soortcode)
DRAAILIJST (datum, code)
DATUM
(datum)
OPMERKING
We kunnen ons afvragen of het zin heeft om de tabel DATUM bij te houden. Immers,
een overzicht van alle draaidata kunnen we ook afleiden uit de tabel DRAAILIJST.
Tenslotte komen alle data daar ook in voor. Omdat de tabel DATUM verder geen
speciale betekenis heeft, zullen we deze weglaten. Daardoor gaan er geen gegevens
verloren.
We houden dan over:
3 NV SOORT
(soortcode, soortomschrijving)
TRACK
(code, titel, artiest, soortcode)
DRAAILIJST (datum, code)
Ann De Ridder
Gegevensbeheer 3
p. 16
Het komt vaker voor dat één van de gevonden groepen in de derde normaalvorm
mag worden weggelaten. Dit zijn dan altijd tabellen waarin alleen maar
sleutelattributen voorkomen. De tabellen mogen alleen maar worden weggelaten als
er daardoor verder geen informatie verloren gaat. Niet iedere tabel die bestaat uit
alleen maar sleutelattributen mag dus worden weggelaten! Controleer altijd terdege.
De groep DRAAILIJST mag in ons voorbeeld niet weggelaten worden omdat daar nu
precies in staat welke nummers op welke datum zijn gedraaid. Zonder deze groep
zouden we alleen maar de gegevens van de nummers hebben. En dan kunnen we
dus niet het door Paul gewenste overzicht maken.
Ten slotte nog even opmerken dat het niet altijd zo is dat er bij de stap van de ene
naar de andere normaalvorm altijd iets gedaan kan worden. Regelmatig blijken twee
normaalvormen gelijk aan elkaar te zijn. In dat geval zullen we gebruikmaken van
een verkorte notatiewijze. Als de tweede normaalvorm gelijk blijkt te zijn aan de
eerste normaalvorm, noteren we bij de tweede normaalvorm: 2 NV = 1 NV.
OEFENING 4
a. Iemand heeft de volgende tweede normaalvorm gevonden. Deze hoort bij een
order die door een klant is geplaatst. Daarbij geldt dat de korting, het percentage,
alleen maar afhankelijk is van het aantal dat men van één artikel koopt. Bij één
stuk ontvangt men 2 % korting, bij twee stuks 3 %, bij drie stuks 5 %, enzovoort.
Ten slotte geldt dat iedere klant een eigen uniek klantnummer heeft dat altijd voor
hem gebruikt wordt.
2 NV
(ordernummer, klantnummer, klantnaam)
(ordernummer, artikelnr, aantal, korting%)
(artikelnr, omschrijving, prijs p/s)
Bepaal uitgaande van deze tweede normaalvorm de derde normaalvorm.
b. Een voetbalvereniging maakt gebruik van (onder andere) het overzicht van
figuur 4. Een lid van de vereniging hoeft geen commissiewerk te doen maar mag
het wel. Indien gewenst kan hij (of zij) zelfs deel uitmaken van meerdere
commissies.
Ann De Ridder
Gegevensbeheer 3
p. 17
Normaliseer het overzicht tot en met de derde normaalvorm.
Commisie: BC, Barcommissie
Lidnummer
Naam
Telefoon
34
L. Ketelaar
053 12 34 56
122
V. Borrelaar
02 569 78 32
307
M. Vervat
052 69 75 35
Figuur 4
c. Het overzicht van figuur 5 wordt bij een camping gebruikt om de reserveringen bij
te houden. Op die manier probeert men te voorkomen dat een plaats aan meer
dan één klant tegelijkertijd wordt toegekend. Normaliseer dit overzicht tot en met
de derde normaalvorm.
Camping Zee en Strand, Nieuwpoort
Plaatsnummer
Klant
23
Aankomstdat
Vertrekdatum
um
8448
J. Janssens
Kerkweg 23
BE 9300 Aalst
6 augustus
2003
20 augustus 2003
3662
K. De Smet
Korenstraat 5
NL 2870 AB Schoonhoven
23 juli 2003
30 juli 2003
Figuur 5
Ann De Ridder
Gegevensbeheer 3
p. 18
2.5 Vreemde sleutels
Met een vreemde sleutel (foreign key) bedoelen we een gegeven dat verwijst naar de
sleutel van een tabel. In ons voorbeeld is er sprake van een tweetal vreemde
sleutels. Als eerste het gegeven code in DRAAILIJST. Dit is een vreemde sleutel
omdat het verwijst naar het gegeven code in de tabel TRACK, dus naar een sleutel.
Ook het gegeven soortcode in TRACK is een vreemde sleutel want het verwijst naar
de sleutel van de tabel SOORT (soortcode). We geven vreemde sleutels aan door ze
met een stippellijn te onderstrepen. Dus:
3 NV SOORT
TRACK
(soortcode, soortomschrijving)
(code, titel, artiest, soortcode)
-----------DRAAILIJST (datum, code)
------
Vreemde sleutels verwijzen in het algemeen naar andere tabellen. Dit lukt alleen
maar als iedere waarde die de vreemde sleutel aanneemt ook als sleutelwaarde
voorkomt in de tabel waarnaar verwezen wordt. Met andere woorden: als in
DRAAILIJST de code ‘R7734’ voorkomt, moet deze waarde ook voorkomen als code
in TRACK, met daarbij de naam van de artiest en de titel van het nummer. De eis dat
iedere waarde die een vreemde sleutel aanneemt ook als sleutelwaarde moet
voorkomen in de andere tabel, staat bekend onder de eis van referentiële integriteit
(referential integrity).
Andersom geldt deze eis niet. Er kan in TRACK best een waarde voor code
voorkomen die we nog niet tegenkomen in DRAAILIJST. De track is dan gewoon nog
nooit gedraaid in het programma! Zoals uit de derde normaalvorm blijkt, kan een
vreemde sleutel zelf deel van een sleutel zijn. Kijk naar het gegeven code in de tabel
DRAAILIJST. Een vreemde sleutel kan echter ook een niet-sleutelattribuut zijn. Kijk
maar naar het gegeven soortcode in de tabel TRACK.
Via de vreemde sleutels zijn de tabellen met elkaar verbonden. Deze verbondenheid
geven we weer door middel van een diagram, omdat dat over het algemeen veel
duidelijker is. Dit diagram noemen we Entiteit Relatie Diagram of Entity Relationship
Diagram, kortweg ERD.
Ann De Ridder
Gegevensbeheer 3
p. 19
3 HET ENTITEIT RELATIE DIAGRAM
In dit hoofdstuk maak je kennis met een datamodel dat zeer geschikt is bij het
ontwerpen van een database: het Entiteit Relatie Diagram (Entity Relationship
Diagram).
In het Entiteit Relatie Diagram wordt gebruik gemaakt van:
 entiteiten
 attributen
 relaties (relationships)
3.1 Entiteiten
Een entiteit is simpelweg iets dat je kunt identificeren en waarvan je gegevens wilt
bijhouden: auto, persoon, magazijn, bankrekening, computer…
Een entiteit bestaat uit:
 een unieke naam
 een definitie die objectief en ondubbelzinnig aangeeft welke objecten door de
entiteiten worden gemodelleerd (en soms even belangrijk: welke niet)
 een lijst van attributen (zie verder)
Voorbeeld
Naam
Definitie
Attributen
werknemer
een natuurlijke persoon die in loondienst is van de firma; personen die
slechts occasioneel voor de firma werken en personen die via een
interim-kantoor tewerkgesteld zijn, worden niet als werknemer
beschouwd.
naam, adres, telefoonnummer, geboortedatum, datum in dienstname…
Voorstelling
Een entiteit wordt voorgesteld door een rechthoek.
Werknemer
Ann De Ridder
Gegevensbeheer 3
p. 20
3.2 Relatie
Een relatie is een verband tussen twee of meer entiteiten dat model staat voor een
overeenkomstige band tussen de reële objecten. Een relatie bestaat uit:
 een naam, uniek binnen het beschouwde diagram
 een lijst van betrokken entiteiten
 een definitie die objectief en ondubbelzinnig aangeeft in welke omstandigheden
precies het veronderstelde verband aan- of afwezig is tussen de gespecifieerde
entiteiten
 een lijst van attributen (zie verder)
Voorbeeld
Naam
werkt in
Deelnemende entiteiten
werknemer, afdeling
Definitie
een werknemer werkt in een afdeling als hij
verantwoording verschuldigd is aan het hoofd van die
afdeling
aantal werkuren
Attributen
Voorstelling
Een relatie wordt voorgesteld als een verbindingslijn tussen de betrokken entiteiten.
Werknemer
Afdeling
Werkt in 
De naam van de relatie kan al dan niet vermeld worden. Het pijltje is hier enkel een
hulpmiddel bij het lezen van het diagram van links naar rechts: werknemer werkt in
afdeling.
Ann De Ridder
Gegevensbeheer 3
p. 21
3.3 Attributen
Iedere entiteit en relatie is voorzien van een collectie van nul of meer attributen. Een
attribuut is een eigenschap die met de instanties van de entiteit of de relatie
geassocieerd wordt. Entiteiten hebben bijna altijd attributen. Relaties kunnen
gemakkelijk voorkomen zonder attributen.
Samengestelde gegevens
Je wenst bijvoorbeeld gegevens op te slaan van personen zodat deze telefonisch of
per brief kunnen gecontacteerd worden. Als attributen van de persoon heb je dan
nodig: naam, adres en telefoonnummer. Je zou dus kunnen opteren voor drie
attributen. Dit is echter niet handig. Als je bijvoorbeeld een adresetiket wilt
samenstellen, heb je straat, postcode en gemeente apart nodig.
De gegevens naam, adres en telefoonnummer zijn samengestelde gegevens: naam
bevat zowel voor- als familienaam, adres bevat straat, straatnummer, postnummer
en gemeente en telefoonnummer bevat zonenummer en eigenlijke nummer. Als je de
deelgegevens van een samengesteld gegeven afzonderlijk gebruikt, is het beter ze
te beschouwen als afzonderlijke attributen. Zo splits je naam waarschijnlijk best op in
de attributen voornaam en familienaam. Adres kan gesplitst worden in straat,
postnummer en gemeente. Meestal zal het geen zin hebben om straatnaam en
straatnummer afzonderlijk op te splitsen, gewoon omdat ze niet afzonderlijk gebruikt
worden.
Procesgegevens
Een procesgegeven of berekend gegeven is een gegeven waarvan de waarde
bepaald wordt door de waarde van één of meer andere gegevens.
In een groothandel worden bijvoorbeeld artikelgegevens bijgehouden, o.a. naam,
inkoopprijs en hoeveelheid in voorraad. Bij het inventariseren wil men, per artikel, de
waarde van de voorraad kennen. Je zou hiervoor een attribuut WaardeVoorraad
kunnen voorzien waarbij WaardeVoorraad = Inkoopprijs * HoeveelheidInVoorraad.
Dit betekent echter dat om de integriteit van de database te behouden bij elke
verandering van de voorraad of de inkoopprijs ook de waarde van dit attribuut moet
aangepast worden. Daarom worden procesgegevens meestal niet opgenomen in de
database. Ze worden berekend op het moment dat ze nodig zijn.
Ann De Ridder
Gegevensbeheer 3
p. 22
Een attribuut bestaat uit de volgende elementen:
 een naam, uniek binnen de collectie attributen van dezelfde entiteit of relatie
 een entiteit of relatie waarvan het attribuut een kenmerk is
 een domein, dit is de collectie van alle mogelijke waarden die het kenmerk kan
aannemen
 een definitie, die éénduidig de interpretatie van de gekozen waarden uit het
domein aangeeft
 het al dan niet verplichte karakter van het attribuut: moet elke instantie van de
gegeven entiteit of relatie over deze eigenschap beschikken, of is dit optioneel,
met andere woorden, modelleer je ook instanties waarvoor deze eigenschap
irrelevant of onbekend is.
Voorbeeld
Naam
personen ten laste
Entiteit
werknemer
Domein
de natuurlijke getallen, inclusief 0
Definitie
het aantal personen die fiscaal ten laste van de medewerker zijn
Verplicht
ja
Voorstelling
De attributen worden bij in de rechthoek geschreven. In diagrammen worden ze
meestal weggelaten om de overzichtelijkheid niet te schaden.
Werknemer
naam
adres
telefoonnummer
datum in dienst
…
Ann De Ridder
Gegevensbeheer 3
p. 23
3.4 Cardinaliteit
De cardinaliteit van een relatie geeft aan, hoeveel elementen van een betrokken
entiteittype maximaal in relatie kunnen staan met één instantie van de andere
entiteittypes. Daarbij zijn de toegelaten waarden: één of veel.
Voorbeeld
Als je de relatie ‘persoon is ondergeschikte van manager’ bekijkt, dan gelden
waarschijnlijk de volgende twee beschouwingen betreffende de cardinaliteit:
 iedere werknemer heeft (is ondergeschikt aan) hoogstens één manager
 een manager kan veel ondergeschikten (ondergeschikte werknemers) hebben.
In een gegevensstructuurdiagram geven we de cardinaliteit aan door een markering
van de lijnen (relaties) op de plaats waar ze de rechthoeken (entiteiten) bereiken:
 als de instantie van de desbetreffende entiteit uniek is (d.w.z. hoogstens één),
plaats je een dwarsstreepje op de lijn vlakbij de entiteit
 als de instantie van de desbetreffende entiteit verscheidene malen kan voorkomen
(d.w.z. hoogstens veel), plaats je een kraaiepoot op de lijn tegen de entiteit.
Voor een relatie tussen twee entiteiten zijn er dus, wat de cardinaliteit betreft, vier
mogelijkheden: één-op-één, één-op-veel (twee verschillende mogelijkheden) en
veel-op-veel. Een één-op-één-relatie wordt ook 1:1 genoteerd, een één-op-veelrelatie 1:n (lees: één op n) en een veel-op-veel-relatie m:n (lees: m op n).
Ann De Ridder
Gegevensbeheer 3
p. 24
3.5 Optionaliteit
De optionaliteit van een relatie geeft aan, hoeveel elementen van een betrokken
entiteittype minimaal in relatie moeten staan met één instantie van de andere
entiteittypes. Daarbij zijn toegelaten waarden: nul of één.
Voorbeeld
Als je in een juridische database de entiteiten ‘natuurlijke persoon’ en
‘arbeidscontract’ beschouwt, met daartussen de relatie ‘persoon werkt onder
contract’, dan gelden de volgende beschouwingen omtrent de optionaliteit:
 een natuurlijke persoon heeft niet noodzakelijk een arbeidscontract
 ieder arbeidscontract heeft noodzakelijk betrekking op een persoon.
In een gegevensstructuurdiagram geven we de optionaliteit aan door het aanbrengen
van een symbool op de lijnen (relaties) dichtbij de rechthoeken (entiteiten), naast de
tekens voor de cardinaliteit:
 als de instantie van de desbetreffende entiteit verplicht is (d.w.z. minstens één),
plaatsen we een dwarsstreepje op de lijn
 als de instantie van de desbetreffende entiteit optioneel is (d.w.z. minstens nul),
plaatsen we een cirkeltje op de lijn.
Het verplicht karakter van een relatie is een zeer strenge eis. Als een relatie verplicht
is, wil dat zeggen dat je geen enkele situatie kunt modelleren waarin de relatie niet
voorkomt, zelfs niet tijdelijk.
Ann De Ridder
Gegevensbeheer 3
p. 25
OEFENING 5
a. Teken voor het praktijkvoorbeeld uit hoofdstuk 2 het bijbehorende ERD.
b. Gegeven is de onderstaande genormaliseerde gegevensstructuur. Geef hier de
vreemde sleutels aan door deze gestippeld te onderstrepen.
GAST (gastnummer, naam, adres, postcode, plaats, geboortedatum,
telefoonnummer)
BOEKING (boekingnummer, boekdatum, aankomstdatum, vertrekdatum,
plaatsnummer)
------------------PLAATS
(plaatsnummer, voorzieningen, bedrag per nacht)
REGISTER (gastnummer, boekingnummer)
----------------- --------------------BETALING (boekingnummer, betaaldatum, betaald bedrag)
---------------------Ter informatie: het gaat om een deel van de administratie van een camping. Van
een boeking worden de belangrijke gegevens bijgehouden. Bij iedere boeking
wordt bijgehouden welke personen er zullen verblijven in verband met het
nachtregister. Er kan in twee gedeelten betaald worden. Het eerste deel moet
worden betaald binnen vier weken na de boekdatum, het laatste deel moet betaald
worden uiterlijk zes weken voor de geplande aankomstdatum. Per boeking wordt
er steeds één campingplaats geboekt.
Teken ook het bijbehorende ERD.
c. Gegeven is de volgende genormaliseerde gegevensstructuur. Geef hier de
vreemde sleutels aan door deze gestippeld te onderstrepen. Ga er daarbij van uit
dat meerdere spelers deel uitmaken van een elftal, dat ieder elftal slechts één
leider heeft en dat er ereleden bestaan. Deze ereleden staan wel als speler
genoteerd maar er is geen elftalcode ingevuld.
ELFTAL
LEIDER
LID
(elftalcode, leidercode)
(leidercode, leidernaam, telefoonnummer)
(lidcode, lidnaam, lidadres, lidplaats, elftalcode)
Ann De Ridder
Gegevensbeheer 3
p. 26
Teken ook het bijbehorende ERD.
c. Gegeven is het volgende ERD. Beantwoord op basis van dit ERD de gestelde
vragen.







Kan een chef meerdere afdelingen onder zijn beheer hebben?
Kan een afdeling geleid worden door meerdere chefs?
Kan een werknemer bij meerdere afdelingen zijn ingedeeld?
Kan er een afdeling zijn zonder medewerkers?
Kan er een afdeling zijn zonder chef?
Kan er een werknemer zijn zonder afdeling?
Kan er een chef zijn zonder werknemers?
SAMENVATTING HOOFDSTUK 2 EN 3
We hebben de eerste beginselen van het normaliseren geleerd. Daarbij rafelen we
de ongestructureerde gegevens, zoals die op een overzicht worden getoond, in een
aantal stappen uiteen tot een gestructureerd geheel. Daarbij maken we gebruik van
de techniek van het normaliseren.
Eerst stellen we de nulde normaalvorm op door alle elementaire gegevens te
noteren. Daarbij laten we alle vaste teksten (constanten) en procesgegevens
achterwege. We bepalen de sleutel. Het bepalen van de sleutel doen we ook bij
iedere volgende stap.
Vervolgens bepalen we de eerste normaalvorm door de repeating group te
verwijderen.
Hierna bepalen we de tweede normaalvorm. Daarbij nemen we alle gegevens apart
die slechts van een deel van de sleutel afhangen en niet van de gehele sleutel.
Ten slotte bepalen we de derde normaalvorm. Daarbij nemen we alle gegevens apart
die helemaal niet van de sleutel afhangen maar die van een ander nietsleutelattribuut afhangen.
Nadat we de derde normaalvorm hebben gevonden, gaan we na of er misschien
groepen zijn die weggelaten mogen worden zonder dat we informatie verliezen. We
hoeven hierbij alleen maar de groepen te onderzoeken die uit alleen maar
sleutelattributen bestaan.
De gegevensstructuur die we hebben gevonden, geven we vervolgens grafisch weer
door middel van een Entiteit Relatie Diagram (ERD). We laten daarbij het verband
tussen de diverse tabellen zien. Deze verbanden zijn gebaseerd op vreemde
sleutels. Een vreemde sleutel mag alleen maar waarden aannemen die ook in de
overeenkomstige andere tabel voorkomen (referentiële integriteit).
Ann De Ridder