Before anything else, preparation is the key to success.
—Alexander Graham Bell

Conceptueel datamodel

In dit hoofdstuk gaan we dieper in op de verschillende bouwblokken van een conceptueel datamodel en het proces om dit datamodel te ontwerpen. Hiervoor lichten we alvast een aantal belangrijke begrippen toe en gaan we ook de eerste stappen zetten om zelf eenvoudige conceptuele modellen te ontwerpen. We bekijken de volgende vragen:

Na dit hoofdstuk te hebben afgewerkt, moet je de volgende termen kunnen uitleggen:

Na dit hoofdstuk te hebben afgewerkt, moet je in staat zijn om de notatie in een ERD (waar relevant) te kennen en toe te lichten aan de hand van een voorbeeld.

Je moet daarnaast ook in staat zijn een ERD uit te tekenen voor een gegeven probleemstelling.

Entity Relationship Diagram

Een conceptueel datamodel beantwoordt de vraag ‘Welke informatie is relevant voor de beoogde IT-toepassing?’. Dit datamodel geeft een beeld van de realiteit van de gebruikers en de informatie die hierin vervat zit, zonder hierbij technische details in rekening te nemen.

Een conceptueel datamodel is een schematische voorstelling van de relevante informatie. We streven naar een voorstelling die gemakkelijk op te stellen is en door een breed publiek gelezen kan worden. Om dat te bereiken, maken we gebruik van een gestandaardiseerde notatie, namelijk Entity Relationship Modelling. De diagrammen die gebruik maken van deze notatie noemen we Entity Relationship Diagrams (afgekort naar ERD).

ERD maakt gebruik van drie belangrijke concepten die de basis vormen van de modellen: entiteiten, relaties en attributen. We gaan elk van deze concepten uitgebreid toelichten en tonen hoe deze passen in het proces om tot een conceptueel datamodel te komen.

ERD-notatie werd ontwikkeld in 1976 door Peter Chen en gaat dus al heel wat jaren mee. Deze computer was toen net ontwikkeld door een klein bedrijfje genaamd ‘Apple Computer’:

ERD werd later ook uitgebreid met enkele bijkomende concepten. We spreken dan over het Extended Entity Relationship Model (EERD). De concepten die toegevoegd zijn, zijn specialisatie en generalisatie, en subklasses en superklasses. Deze concepten zullen we ook kort toelichten.

ERD is zeker niet de enige gestandaardiseerde notatie, zo heb je bijvoorbeeld ook UML. In de context van dit vak gebruiken we ERD notatie om conceptuele en logische datamodellen te beschrijven. Heel wat mensen met een IT-opleiding (en ook daarbuiten) kunnen vlot een ERD lezen, wat het een uitstekende vorm van documenteren maakt.

Entiteiten en entiteittypes

Wat zijn entiteiten en entiteittypes?

De eerste belangrijke concepten binnen een ERD zijn entiteiten en entiteittypes. Een entiteit komt overeen met iets dat bestaat in de reële wereld. Dit kan zowel iets fysieks als iets abstracts zijn zodat we kunnen spreken over objecten, personen, … de persoon met als naam ‘Emma’, de stad met als naam ‘Leuven’, een wagen met nummerplaat ‘1-AAA-001’, … zijn elk voorbeelden van entiteiten. Vanaf het ogenblik dat het bestaat en het relevant is, kunnen we het als een entiteit beschouwen.

Naast entiteiten hebben we ook entiteittypes. We definiëren entiteittypes als een verzameling van gelijkaardige entiteiten. Deze verzameling geven we vervolgens een naam die het type van entiteiten duidelijk omschrijft. Voorbeelden van entiteittypes zijn ‘Persoon’, ‘Stad’, ‘Wagen’, ... Je zal merken dat we deze entiteittypes in het enkelvoud en met een hoofdletter schrijven. Daar bestaat geen wet of regel voor, we doen dit voor duidelijkheid en consistentie.

Even een voorbeeld van bovenstaande: indien je een systeem ontwikkelt waarbij we informatie bijhouden over klanten, zou ‘Sam Peters’ een klant zijn, en zou ‘Klant’ het entiteittype zijn dat de verzameling klanten beschrijft. We zeggen dat Sam een reële invulling is van een bepaald type, in dit geval een klant. In het kader van dit opleidingsonderdeel gaan we een strikt onderscheid maken tussen enerzijds entiteit en anderzijds entiteittype. We moeten echter toegeven dat dit in de beschikbare literatuur niet altijd het geval is. Men gebruikt de termen ‘entiteit’ en ‘entiteittype’ door elkaar. Houd dit in het achterhoofd wanneer je in boeken of online bepaalde dingen opzoekt.

Hoe herken je entiteittypes?

Om een ERD op te stellen, gaan we op zoek naar de relevante entiteittypes. Het herkennen van entiteittypes gebeurt typisch aan de hand van de zelfstandige naamwoorden die je tijdens een interview hoort of bij het doornemen van documenten leest of die gebruikt worden in de beschrijving van de oplossing. Woorden zoals ‘Klant’, ‘Reservatie’, ‘Product’, ‘Winkel’, ‘Aanvraag’, ‘Wagen’, … zijn een goed startpunt. Vaak wil je dan informatie hierover bijhouden (zie attributen) wat van deze concepten goede kandidaten maakt.

Om de kandidaten te evalueren kunnen we de volgende vragen stellen:

In een conceptueel datamodel nemen we enkel entiteittypes op. Het is altijd wel handig om enkele voorbeelden van entiteiten mee op te nemen in jouw documentatie, want dit maakt het voor de personen die jouw ERD lezen makkelijker om zich voor te stellen wat je exact bedoelt.

Notatie entiteittype in ERD

Entiteittypes worden in een ERD weergegeven door een rechthoek met daarin de naam van het entiteittype. We kiezen ervoor om de naam telkens in het enkelvoud te schrijven en te laten beginnen met een hoofdletter. Bijvoorbeeld de entiteittypes ‘Klant’, ‘Product’ en ‘Wagen’ worden als volgt weergegeven:

Voorbeelden van de notatie van een entiteittype: ‘Klant’, ‘Product’ en ‘Wagen’.

Hoe eraan beginnen?

Zoals aangegeven kan je entiteittypes typisch herkennen als zelfstandige naamwoorden die gebruikt worden in een bepaalde tekst. Ons advies is om een bepaalde beschrijving te overlopen en alle zelfstandige naamwoorden aan te duiden of te onderlijnen. Dit zijn de kandidaten voor jouw entiteittypes.

Om de kandidaten te evalueren kunnen we de volgende vragen stellen:

Het evalueren van bovenstaande vragen is soms moeilijk of verwarrend. In bovenstaande voorbeelden gebruiken we het kandidaat-entiteittype ‘Wagen’ om elke vraag af te toetsen, maar wat bijvoorbeeld met het kandidaat-entiteittype ‘Nummerplaat’? Er zijn meerdere nummerplaten, we kunnen nummerplaten ook beschrijven (nummer, datum aanvraag, datum afgifte, ...), en we gebruiken het om wagens te identificeren dus het is ook relevant.

Om te bepalen of het entiteittype ‘Nummerplaat’ relevant is, moeten we naar de IT-oplossing kijken. Voor een fleet-management systeem zal de nummerplaat een beschrijving zijn van een wagen, maar zelf minder relevant zijn. In dit geval is het een eigenschap om een wagen te beschrijven, maar geen entiteittype op zich. Mocht je een systeem ontwikkelen voor de Dienst voor Inschrijvingen van Voertuigen, dan zou ‘Nummerplaat’ dan weer wel een goede kandidaat zijn omdat het verdelen van nummerplaten voor hen van belang is. Het is dus niet altijd voor de hand liggend.

Tekentool: Draw.io (diagrams.net)

Gebruik draw.io als tekentool voor ERD. We maakten een aparte pagina over deze app. Bekijk:

Oefening jeugdvereniging: entiteittypes

Maak Oefening 1: jeugdvereniging: entiteittypes. Houd het resultaat van de oefening bij aangezien we dit in een aantal stappen gaan opbouwen.

Attributen

Wat zijn attributen?

Entiteittypes beschrijven concepten die relevant zijn voor ons datamodel, maar bevatten eigenlijk geen data. Om aan te geven wat we specifiek over de verschillende entiteiten willen bijhouden, gebruiken we attributen. Elk attribuut van een entiteittype beschrijft één eigenschap die we als data bijhouden voor elk van de entiteiten. Indien we meerdere eigenschappen willen bijhouden, dan maken we meerdere attributen aan.

Voorbeelden van deze eigenschappen voor de entiteit ‘Sam Peters’ zijn ‘Sam’, ‘Peters’, ‘04/09/2001’, ‘21’, ‘Vilvoorde’ en ‘Bordspelen, rugby, reizen’ die respectievelijk waarden zijn voor de attributen ‘Voornaam’, ‘Naam’, ‘Geboortedatum’, ‘Leeftijd’, ‘Woonplaats’ en ‘Hobby’s’.

Een attribuut krijgt een algemene naam die de eigenschap beschrijft. De mogelijke waarden die de eigenschap kan aannemen noemen we het domein van een attribuut. Bijvoorbeeld, het attribuut met de naam ‘Woonplaats’ kan als domein ‘Vilvoorde’, ‘Leuven’, ‘Tienen’, ‘Landen’, ‘Heverlee’, ... hebben.

Een attribuut wordt niet gedeeld tussen meerdere entiteittypes. Wil je bijvoorbeeld de woonplaats bijhouden van zowel een klant als een werknemer, moet je het attribuut ‘Woonplaats’ zowel toevoegen aan entiteittype ‘Klant’ als aan het entiteittype ‘Werknemer’.

Er zijn verschillende types van attributen zodat je meer nuance kan leggen over de aard van de eigenschap die je wil bijhouden, maar daar komen we op een later moment op terug.

Hoe herken je een attribuut?

Attributen zijn eigenschappen van entiteittypes. Dus als je een kandidaat-entiteittype hebt, kan je op zoek gaan naar de verschillende elementen die iets zeggen over de entiteittypes en de data die we hierover willen bijhouden. Vaak geven constructies zoals ‘Over de klant willen we de volgende informatie bijhouden …’ een zeer duidelijke hint dat we data willen bijhouden over entiteittype ‘Klant’ met dan de nodige attributen. Helaas is het niet altijd even duidelijk aangegeven. Soms kan het makkelijker zijn om een bepaalde entiteit voor ogen te nemen. Wat willen we weten over onze klant ‘Sam Peters’?

Soms moet je voor bepaalde elementen de keuze maken of het een entiteittype is of een attribuut van een entiteittype. Enkele tips die we hierbij kunnen geven:

Notatie attribuut in ERD

In de context van een ERD wordt een attribuut weergegeven door een ellips met hierin de naam van het attribuut. Deze ellips wordt vervolgens met een lijn verbonden met het entiteittype. Een attribuut kan niet gedeeld worden tussen verschillende entiteittypes!

Voorbeeld van de notatie van attributen: het entiteittype ‘Klant’ met een aantal attributen ‘Voornaam’, ‘Naam’, ‘Geboortedatum’, ‘Leeftijd’, ‘Hobby’s’ en ‘Woonplaats’

Het domein van een attribuut (= de mogelijke waarden die een attribuut kan aannemen) wordt niet weergegeven in een ERD.

Oefening jeugdvereniging: attributen

Maak oefening 2: jeugdvereniging, attributen. Houd het resultaat van de oefening bij aangezien we dit in een aantal stappen gaan opbouwen.

Relaties

Wat zijn relaties?

Een entiteittype met attributen beschrijft concepten die we relevant vinden en de data die we hiervan willen bijhouden. Informatie wordt gecreëerd wanneer data gecombineerd wordt en verbanden gelegd worden. Om deze verbanden te beschrijven die bestaan tussen de verschillende concepten, maken we gebruik van relaties.

Een relatie verbindt een aantal entiteittypes en geeft het verband weer dat er bestaat tussen deze entiteittypes een naam. Daarbovenop laten relaties toe om het verband tussen de entiteittypes verder te nuanceren door het gebruik van een maximum- en minimumkardinaliteit. We bespreken kardinaliteit later.

Een voorbeeld van een relatie ontstaat wanneer Sam Peters in een supermarkt een flesje water koopt. Onze klanten zullen namelijk onze producten kopen. We hebben hierbij twee entiteittypes: ‘Klant’ (met als entiteit ‘Sam Peters’) en ‘Product’ (met als entiteit ‘Flesje water’). Tussen beide entiteittypes creëren we een relatie ‘Koopt’. Ons datamodel laat nu toe om informatie af te leiden van welke klanten welke producten kopen.

Hoe herken je een relatie?

Relaties gaan over verbanden herkennen en benoemen. Vaak worden die verbanden beschreven in de vorm van ‘is de … van’ of een bepaald werkwoord. Je kan voor elke combinatie evalueren of er ergens een verband bestaat, maar opgelet dat je geen redundantie creëert. We bespreken redundantie ook later.

Een entiteittype dat met geen enkele ander entiteittype verbonden is, is meestal een teken dat er een relatie ontbreekt, of dat het geïsoleerde entiteittype niet relevant is.

Notatie relatie in ERD

Een relatie wordt in een ERD getekend als een ruit waarin we met een naam de relatie benoemen. De ruit wordt verbonden met de relevante entiteittypes. Het attribuut ‘SKU’ betekent ‘Stock Keeping Unit’ en is een unieke code die gebruikt wordt om een product te identificeren.

Een voorbeeld van de notatie van een relatie: een relatie ‘Koopt’ tussen twee entiteittypes ‘Klant’ en ‘Product’. Elk entiteittype heeft een aantal attributen.

Redundantie

De bedoeling van een ERD is om een zo eenvoudig mogelijke weergave te hebben van de nodige informatie. Het is echter mogelijk dat we in een datamodel meerdere keren dezelfde informatie toevoegen. Dit noemen we redundantie.

Redundantie ontstaat hoofdzakelijk wanneer we entiteiten, attributen of relaties toevoegen die afgeleid kunnen worden uit andere elementen in onze databank. Bijvoorbeeld, een klant koopt een wagen in één van de garages. We weten welke klant welke wagen koopt. We weten ook in welke garage een wagen verkocht wordt. Indien we willen weten in welke garage een klant een wagen koopt, kunnen we de relatie ‘Koopt wagen in’ tussen de entiteittypes ‘Klant’ en ‘Garage’ toevoegen.

Een voorbeeld van een niet-redundante relatie ‘Bezoekt’ tussen de entiteittypes ‘Klant’ en ‘Garage’ die bijkomende informatie aangeeft.

Maar deze relatie is redundant. We kunnen deze informatie altijd afleiden uit de combinatie van de andere relaties. De relatie ‘Koopt wagen in’ nemen we niet mee op in het ERD.

Zeggen dat we redundantie kunnen afleiden uit elke lus in ons ERD, is kort door de bocht. Het klopt dat redundantie vaak de vorm van een cyclus aanneemt. Maar je moet wel altijd rekening houden met wat je specifiek wil zeggen.

Stel bijvoorbeeld dat we willen bijhouden dat een klant een bepaalde garage bezoekt, dan kunnen we een relatie ‘Bezoekt’ definiëren tussen de entiteittypes ‘Klant’ en ‘Garage’. Het bezoek leidt mogelijk niet tot een aankoop, dus dat willen we wel apart bijhouden.

We komen hier later op terug wanneer we het hebben over het relationele databankmodel.

Graad

In de meeste gevallen zal een relatie twee entiteittypes met elkaar verbinden, maar dat hoeft niet per se het geval te zijn. Het is ook mogelijk dat een entiteittype naar zichzelf verwijst, of dat er een relatie bestaat tussen drie of meer entiteittypes. Het aantal entiteittypes dat een relatie met elkaar verbindt, noemen we de graad van een relatie.

In geval van één entiteittype, spreken we over een unaire relatie of een relatie van de eerste graad. In geval van twee entiteittypes, spreken we over een binaire relatie of een relatie van de tweede graad. In geval van drie entiteittypes, spreken we over een ternaire relatie of een relatie van de derde graad. Enzovoort. De meeste relaties zullen binair zijn, maar unair, ternair, ... komen zeker voor.

Een voorbeeld van een unaire relatie is ‘Is getrouwd met’ waarbij een entiteit van het entiteittype ‘Persoon’ getrouwd is met een entiteit van hetzelfde entiteittype.

Voorbeeld van een unaire relatie ‘Is getrouwd met’ die het entiteittypes ‘Persoon’ met zichzelf verbindt.

We gaan er voor dit voorbeeld vanuit dat de twee entiteiten niet dezelfde zijn. Maar in principe kan het ook gaan om een relatie die een entiteit met zichzelf heeft . Een relatie waarbij we aangeven dat een minister opgevolgd wordt door een andere minister zouden we kunnen beschrijven door de relatie ‘Volgt op’ die twee entiteiten van het entiteittype ‘Minister’ met elkaar verbindt. Het kan gebeuren dat een minister zichzelf opvolgt.

Een voorbeeld van een binaire relatie is ‘Is piloot’ waarbij een entiteit van het entiteittype ‘Piloot’ wordt toegekend aan een entiteit van het entiteittype ‘Geplande vlucht’. Zoals onderstaand voorbeeld ook toont, is het mogelijk om meerdere relaties te hebben tussen twee entiteittypes aangezien we ook een binaire relatie ‘Is copiloot’ hebben gedefinieerd. Voor een geplande vlucht zal een piloot als (hoofd)piloot worden toegekend en een andere piloot als copiloot. Op basis van het model houden we de informatie van beide rollen bij.

Voorbeeld van twee binaire relaties: de relatie ‘Is piloot’ en de relatie ‘Is copiloot’ die het entiteittypes ‘Piloot’ en ‘Geplande vlucht’ verbinden.

Een voorbeeld van een ternaire relatie is ‘Schrijft voor’ waarbij telkens entiteiten van entiteittype ‘Patiënt’, ‘Dokter’ en ‘Medicatie’ met elkaar verbonden worden.

Voorbeeld van een ternaire relatie ‘Schrijft voor’ die de entiteittypes ‘Patiënt’, ‘Dokter’ en ‘Medicatie’ verbindt.

Voor het verband dat er tussen de drie bestaat, is het essentieel dat alle drie de entiteittypes betrokken zijn. Mochten we dit vervangen door binaire relaties, zouden we namelijk informatie verliezen. Onderstaande figuur laat ons wel toe om te achterhalen welke patiënt welke medicatie krijgt, maar niet door welke dokter het voorgeschreven wordt. Het laat ons toe om te achterhalen welke patiënt door welke dokter behandeld wordt, maar niet welke medicatie hierbij voorgeschreven wordt. En ten slotte weten we ook welke dokter welke medicatie voorschrijft, maar niet voor welke patiënt. Willen we telkens het volledige plaatje hebben, dan moeten we bij elk verband de drie entiteittypes betrekken.

Een voorbeeld hoe drie binaire relaties die geen goed alternatief vormen voor de ternaire relatie.

Alternatief kan bovenstaande ternaire relatie gemodelleerd worden als een entiteittype ‘Voorschrift’. Hierbij gaan we de relatie ‘Schrijft voor’ die de entiteittypes ‘Patient’, ‘Dokter’ en ‘Medicatie’ verbindt, vervangen door een entiteittype ‘Voorschrift’ dat dan vervolgens telkens met een binaire relatie verbonden is met de entiteittypes ‘Patient’, ‘Dokter’ en ‘Medicatie’. Voor elk voorschrift weten we dan welke patiënt het voorschrift ontvangt, welke dokter het voorschrift schrijft en welke medicatie voorgeschreven wordt.

Een nieuw entiteittype ‘Voorschrift’ dat de entiteittypes ‘Patient’, ‘Dokter’ en ‘Medicatie’ verbindt als alternatief op de ternaire relatie ‘Schrijft voor’

Het voordeel van deze aanpak is dat we aan dit entiteittype ook nog bijkomende attributen kunnen hangen. Zo kunnen we bijvoorbeeld het attribuut ‘Datum’ toevoegen. Zo weten we ook op welke datum het voorschrift werd geschreven.

Je kan nu de vraag stellen welke oplossing het best is, die met de ternaire relatie ‘Schrijft voor’, of die met het entiteittype ‘Voorschrift’. Het antwoord is dat beide oplossingen correct zijn. Aan het einde van de rit gaat dit in hetzelfde resulteren.

Kardinaliteit van een relatie

Zoals eerder gezegd, verbindt een relatie één of meerdere entiteittypes. Entity Relationship Modeling laat ons toe om de aard van die relatie verder te nuanceren door bijkomende informatie mee te geven. Zo kunnen we aangeven met hoeveel entiteiten van een bepaald entiteittype een entiteit van een ander entiteittype verbonden moet en kan zijn. Dit doen we door de kardinaliteit van een relatie te bepalen. Elke kardinaliteit bestaat uit twee delen, een minimum- en een maximumkardinaliteit. Dit wordt voor elk entiteittype binnen de relatie individueel bepaald.

De kardinaliteit is van belang wanneer we ons datamodel omzetten naar een logisch en fysiek datamodel. Een fout in het bepalen van kardinaliteit leidt tot problemen en fouten in het gebruik van de data.

Binnen een ERD bestaan er verschillende manieren om kardinaliteit te noteren. In het kader van dit vak maken we gebruik van de (min,max)-notatie. Naast de (min,max)-notatie gaan we bij de logische datamodellen gebruik maken van de kraaienpootnotatie, zodat jullie beide kennen.

Minimumkardinaliteit (of participatierestrictie)

De minimumkardinaliteit geeft aan of een relatie optioneel of verplicht is voor alle entiteiten van een specifiek entiteittype. Er zijn twee mogelijke waarden: ‘0’ en ‘1’:

Dit kan mogelijk wat abstract klinken, dus laten we dit even aan de hand van voorbeelden toelichten. Een eerste voorbeeld is de relatie ‘Koopt’ tussen de entiteittypes ‘Klant’ en ‘Product’. Stel nu de volgende vraag: kan een product bestaan zonder dat dit gekocht wordt door een klant? Het antwoord is ‘ja’, want nieuwe producten die we nog niet verkocht hebben, kunnen wel degelijk aanwezig zijn in het systeem zonder dat een klant die al gekocht heeft. De minimumkardinaliteit van het entiteittype ‘Product’ in de relatie ‘Koopt’ is dus ‘0’.

De volgende vraag die we stellen: kan een klant bestaan zonder dat deze een product heeft gekocht? Dat is al moeilijker eenduidig te beantwoorden, want dit gaat erg afhangen van hoe er in de winkel wordt gewerkt. Indien een klant zich vooraf kan registreren zonder dat hij een aankoop doet, kan een klant bestaan zonder dat hij een product heeft gekocht, en is de minimumkardinaliteit ‘0’. Maar mocht een klant pas aangemaakt worden van zodra deze een product koopt, dan is de waarde van de minimumkardinaliteit ‘1’.

We gaan even er van uit dat een klant pas klant wordt van zodra deze iets koopt, dus met een minimumkardinaliteit van ‘1’.

Binnen een ERD gaan we de minimumkardinaliteit aanduiden waar de lijn komende van de ruit die de relatie voorstelt het vierkant dat het entiteittype voorstelt, raakt. We schrijven (0, ...) of (1, ...).

Een voorbeeld van de minimumkardinaliteit in (min,max) notatie voor elk van de entiteittypes in de relatie ‘Koopt’.

In het kader van de minimumkardinaliteit is de waarde ‘1’ de meest beperkende, omdat we eisen dat er minstens één relatie moet zijn. Bij twijfel geven we het advies telkens voor ‘0’ te gaan of beter nog, geen veronderstelling te maken en gericht de vraag te stellen of de relatie al dan niet optioneel is voor het entiteittype.

Maximumkardinaliteit (of kardinaliteitsrestrictie)

De maximumkardinaliteit geeft aan of een entiteit van een entiteittype aan meerdere relaties van hetzelfde type kan deelnemen. We hebben twee mogelijke waarden: 1 of N.

Laten we dit opnieuw toelichten aan de hand van ons eerder voorbeeld waarbij klanten producten kopen. We stellen onszelf de volgende vraag: kan een klant meerdere producten kopen? Het antwoord is ‘ja’, wat betekent dat we een maximumkardinaliteit hebben van ‘N’. Als we dit combineren met de minimumkardinaliteit, dan kunnen we stellen dat een klant minimaal ‘1’ en maximaal ‘N’ producten kan kopen, samengevat als (1, N).

De volgende vraag die we stellen: kan een product door meerdere klanten worden gekocht? Dit is opnieuw moeilijk eenduidig vast te leggen en zal afhangen van het type product we verkopen. Indien we spreken over bijvoorbeeld een supermarkt, dan kunnen we een flesje water beschouwen als een product, en kunnen meerdere personen een flesje water kopen. We houden geen overzicht bij welke klant een specifiek flesje water heeft gekocht. In dat geval is de maximumkardinaliteit ‘N’. Maar indien het gaat om iets exclusiefs (bijvoorbeeld een wagen, uniek kunstwerk, ...) dan kan dat uniek stuk maar aan 1 klant verkocht worden. En dan is de maximumkardinaliteit dus ‘1’.

Voor dit voorbeeld gaan we even er van uit dat een product maar aan 1 klant verkocht kan worden, dus met een maximumkardinaliteit van ‘1’.

Binnen een ERD gaan we de maximumkardinaliteit achter de minimumkardinaliteit toevoegen. We schrijven (>minimumkardinaliteit <,1) of (>minimumkardinaliteit <,N). Wanneer binnen eenzelfde type relatie meerdere keren een maximumkardinaliteit van N voorkomt, gaan we differentiëren door in plaats van N ook M, O, P, ... te gebruiken. Daarbij willen we benadrukken dat deze telkens andere waarden voorstellen, maar telkens wel groter dan ‘1’.

Een voorbeeld van de minimum- en maximumkardinaliteit in (min,max) notatie voor elk van de entiteittypes in de relatie ‘Koopt’.

Hoe moet je bovenstaande figuur lezen? ‘Product’ heeft in de relatie ‘Koopt’ een minimumkardinaliteit van ‘0’, wat betekent dat een product kan bestaan zonder verkocht te zijn geweest. De maximumkardinaliteit van ‘Product’ in de relatie ‘Koopt’ is ‘1’, wat betekent dat een product maar door één klant gekocht kan worden.

‘Klant’ heeft in de relatie ‘Koopt’ een minimumkardinaliteit van ‘1’, wat betekent dat een klant niet kan bestaan zonder dat deze een product heeft gekocht. Er moet een relatie bestaan met minstens 1 product. De maximumkardinaliteit van ‘Klant’ in de relatie ‘Koopt’ is ‘N’, wat betekent dat een klant meerdere producten kan kopen en dus een relatie kan hebben met meerdere producten.

Kardinaliteit: voorbeeld hondenschool

Misschien was het bovenstaande nogal veel tekst. Het volgende filmpje probeert kardinaliteit met een nieuw voorbeeld uit te leggen:

Types relaties

Onder de binaire relaties, onderscheiden we drie verschillende types.

1-1 relatie

Het eerste type is een 1-1 relatie (één-op-één-relatie) waarbij de maximumkardinaliteit van beide entiteittypes binnen de relatie ‘1’ is. Elke entiteit van het ene entiteittype kan dus maximaal 1 relatie hebben met een entiteit van het andere entiteittype. En dit geldt in beide richtingen.

Een voorbeeld van een 1-1 relatie is een relatie ‘Heeft’ waarbij een entiteit (bijvoorbeeld ‘Sam Peters’) van het entiteittype ‘Persoon’ maximaal 1 entiteit van het entiteittype ‘Identiteitskaart’ kan hebben, en elke entiteit van het entiteittype ‘Identiteitskaart’ kan maximaal aan één entiteit van het entiteittype ‘Persoon’ toebehoren. Elke persoon heeft maximaal één identiteitskaart, en elke identiteitskaart behoort aan juist één persoon.

Een voorbeeld van een 1-1 relatie.

In bovenstaande voorbeeld gaan we ervan uit dat historiek niet bijgehouden wordt, maar een persoon kan doorheen de jaren wel meerdere identiteitskaarten hebben. Maar dat kunnen we oplossen door twee verschillende relaties te definiëren: ‘Heeft’ en ‘Had’. Een persoon kan maximaal 1 identiteitskaart hebben, maar doorheen de tijd kan hij er wel meerdere gehad hebben.

Een voorbeeld van een 1-1 relatie.

De minimumkardinaliteit speelt hier geen rol in deze typering. Er wordt enkel naar maximumkardinaliteit gekeken.

1-N relatie

Een tweede type is een 1-N relatie (één-op-meer-relatie of één-op-veel-relatie) waarbij de maximumkardinaliteit van het ene entiteittype ‘N’ is en deze van het andere entiteittype ‘1’ is. Elke entiteit van het entiteittype met maximumkardinaliteit ‘N’ kan een relatie hebben met meerdere entiteiten van het entiteittype met maximumkardinaliteit ‘1’. Omgekeerd kan elke entiteit van het entiteittype met maximumkardinaliteit ‘1’ maximaal met 1 entiteit van het entiteittype met maximumkardinaliteit ‘N’ een relatie hebben.

Een voorbeeld van een 1-N relatie is een relatie ‘Koopt’ waarbij een entiteit (bijvoorbeeld ‘Sam Peters’) van het entiteittype ‘Klant’ meerdere entiteiten van het entiteittype ‘Wagen’ kan kopen, maar elke entiteit van het entiteittype ‘Wagen’ kan maximaal aan één entiteit van het entiteittype ‘Klant’ worden verkocht. Een klant kan meerdere wagens kopen, maar elke wagen kunnen we maximaal één keer verkopen (we houden tweedehandsverkoop even buiten beschouwing). Belangrijk in dit voorbeeld is dat elke wagen individueel identificeerbaar is en dat het relevant is om te weten welke klant welke wagen heeft gekocht.

Een voorbeeld van een 1-N relatie.

Ook bij deze typering speelt minimumkardinaliteit geen rol.

N-M relatie

Een derde type is een N-M relatie (meer-op-meer-relatie of veel-op-veel-relatie) waarbij de maximumkardinaliteit van beide entiteittypes ‘N’ is. Elke entiteit van het ene entiteittype kan dus meerdere relaties hebben met een entiteit van het andere entiteittype. En dit geldt in beide richtingen.

Een voorbeeld van een N-M relatie is een relatie ‘Koopt’ waarbij een entiteit (bijvoorbeeld ‘Sam Peters’) van het entiteittype ‘Klant’ meerdere entiteiten van het entiteittype ‘Product’ kan kopen, en elke entiteit van het entiteittype ‘Product’ kan door meerdere entiteiten van het entiteittype ‘Klant’ worden gekocht. Een klant kan meerdere producten kopen, elk product kan door meerdere klanten worden gekocht. Belangrijk is dit voorbeeld is dat het niet relevant is om elke product individueel te identificeren. We willen wel bijhouden dat een klant ‘Sam Peters’ een flesje water heeft gekocht, maar niet welk exact flesje dat dan is, in tegenstelling tot het voorbeeld met de wagen, waar we dit wel willen bijhouden.

Een voorbeeld van een N-M relatie.

Oefening jeugdvereniging: relaties

Maak Oefening 3: jeugdvereniging: relaties. Houd het resultaat van de oefening bij aangezien we dit in een aantal stappen gaan opbouwen.

Soorten attributen

Sleutelattributen

Om entiteiten uniek te identificeren, maken we gebruik van sleutelattributen. Sleutelattributen van een entiteittype zijn attributen die toelaten om elke entiteit van een entiteittype uniek te benoemen.

Een voorbeeld van een sleutelattribuut voor het entiteittype ‘Student’ is het attribuut ‘Studentnummer’. Elke student is uniek identificeerbaar aan de hand van zijn of haar studentnummer. Voor een wagen heb je de keuze: je kan bijvoorbeeld chassisnummer of nummerplaat gebruiken. Wat onderzoek zou je leren dat chassisnummer een betere keuze is, dus gebruik je dat als sleutelattribuut.

In een ERD gaan we sleutelattributen aanduiden door de naam van de attributen te onderlijnen . Indien we meerdere attributen nodig hebben om een entiteit te identificeren, onderlijnen we elk van de nodige attributen. Als we de keuze hebben tussen verschillende attributen, onderlijnen we slechts één van de opties.

Een voorbeeld van een entiteittype ‘Student’ met een sleutelattribuut ‘Studentennummer’.

Sleutels vormen een belangrijke componenten van het relationeel databankmodel , dus hier komen we nog uitgebreid op terug in het kader van het logisch datamodel.

Afgeleide attributen

Attributen kunnen in sommige gevallen afgeleid worden op basis van andere attributen . We spreken in dat geval over afgeleide attributen.

Een voorbeeld van een afgeleid attribuut is het attribuut ‘Leeftijd’ wanneer we ook het attribuut ‘Geboortedatum’ ter beschikking hebben. Met behulp van een berekening op basis van deze datum kunnen we telkens ook de leeftijd bepalen.

Een afgeleid attribuut wordt in een ERD aangeduid door middel van een ellips die met een stippellijn getekend is waarin de naam van het attribuut wordt geplaatst.

Een voorbeeld van een entiteittype ‘Student’ met een afgeleid attribuut ‘Leeftijd’.

Het attribuut waarvan het afgeleid is, moet ook aanwezig zijn in het datamodel. In het geval van ‘Leeftijd’ moet dus ook ‘Geboortedatum’ aanwezig zijn. Het is niet mogelijk om in een ERD aan te duiden dat ‘Leeftijd’ specifiek van ‘Geboortedatum’ afgeleid wordt, dat moet je in de documentatie of een nota op het model aangeven.

Je kan jezelf de vraag stellen ‘waarom voegen we deze toe?’. Het antwoord is dat we compleet willen zijn als we bepaalde vragen krijgen van de gebruikers. Als we een expliciete vraag hebben ontvangen om leeftijd toe te voegen, kunnen we ook tonen dat dit uit het model af te leiden is en hierbij de gebruikers geruststellen. Tegelijk voorkomen we op deze manier dat er redundantie gecreëerd wordt, en alle problemen die hierbij komen kijken. In het bovenstaande voorbeeld voorkomen we ook dat we continu de leeftijden moeten aanpassen telkens iemand verjaart.

Een afgeleid attribuut kan trouwens ook afgeleid worden op basis van attributen van andere entiteittypes. Het attribuut ‘Aantal opgenomen studiepunten’ van een entiteit van het entiteittype ‘Inschrijving’ kan je afleiden uit het attribuut ‘Aantal studiepunten’ van de entiteiten van het entiteittype ‘Opleidingsonderdeel’ dat opgenomen zijn binnen een inschrijving.

Samengestelde en enkelvoudige attributen

Een attribuut kan samengesteld of enkelvoudig zijn. Samengestelde attributen kunnen nog opgedeeld worden in verschillende attributen. Enkelvoudige attributen kunnen niet meer opgedeeld worden.

Een voorbeeld van een samengesteld attribuut van het entiteittype ‘Persoon’ is ‘Adres’. Een adres bestaat namelijk uit een straat, huisnummer, ... We zouden met andere woorden het attribuut ‘Adres’ ook kunnen vervangen door de attributen ‘Straat’, ‘Huisnummer’, ...

In een ERD gaan we het onderscheid tussen samengesteld en enkelvoudig niet aanduiden. Er is dus geen verschil in notatie.

De keuze tussen samengestelde of enkelvoudige attributen is een afweging tussen eenvoudig en leesbaar enerzijds en correct en volledig anderzijds. Vaak geven we de voorkeur aan correct en volledig.

Enkelwaardige en meerwaardige attributen

Een attribuut zal typisch voor een entiteit maximaal één waarde bevatten. Bijvoorbeeld voor het entiteittype ‘Student’ zal voor de entiteit ‘Sam Peters’ het attribuut ‘Voornaam’ de waarde ‘Sam’ bevatten. Voor elke entiteit hebben we voor een bepaald attribuut dus maximaal één waarde. We spreken in dit geval over een enkelvoudig attribuut.

Het is ook mogelijk meervoudige attributen te definiëren waarbij voor een attribuut van een entiteit meerdere waarden kunnen bestaan. Het is bijvoorbeeld mogelijk dat een student meerdere e-mailadressen heeft. Voor het entiteittype ‘Student’ kan voor de entiteit ‘Sam Peters’ het attribuut ‘E-mailadres’ de waarden ‘sam.peters@gmail.com’ en ‘huppeldepup@gmail.com’ bevatten. ‘E-mailadres’ is in dit geval een meervoudig attribuut.

Een meervoudig attribuut wordt in een ERD aangeduid door middel van een dubbel omlijnde ellips waarin de naam van het attribuut wordt geplaatst.

Een voorbeeld van een entiteittype ‘Student’ met een meerwaardig attribuut ‘E-mail’.

Attribuut van een relatie

In bepaalde N-M relaties merk je dat je bepaalde attributen niet kan plaatsen bij de entiteittypes.

Laten we even het volgende voorbeeld bekijken. In een bedrijf dat tweedehandswagens verkoopt, is het mogelijk voor klanten om een testrit te reserveren met één van de beschikbare wagens. Het is zelfs mogelijk dat een klant die interesse heeft in een wagen, meerdere keren een testrit doet met dezelfde wagen. Daarnaast kunnen voor een wagen verschillende klanten testritten inboeken. Als we dit zouden omzetten naar een ERD komen we op het volgende diagram:

Een voorbeeld van een N-M relatie met een relatie ‘Boekt testrit’ tussen de entiteittypes ‘Klant’ en ‘Wagen’.

Onze opdrachtgever wil ook weten op welke dag en tijdstip de testrit ingepland is, dus we willen de attributen ‘Dag’ en ‘Tijdstip’ toevoegen. Mochten we deze attributen toevoegen bij het entiteittype ‘Auto’, betekent dat we voor elke entiteit van ‘Auto’ één dag en één tijdstip kunnen vastleggen. Maar aangezien meerdere personen een testrit kunnen aanvragen, kunnen voor één wagen verschillende momenten vastgelegd zijn. We zouden van ‘Dag’ en ‘Tijdstip’ meerwaardige attributen van het entiteittype ‘Auto’ kunnen maken. Maar ook dat is geen optie. We zouden dan voor elke entiteit van ‘Auto’ wel meerdere dagen en meerdere tijdstippen kunnen boeken, maar we hebben dan geen idee bij welke klant deze horen.

Mochten we de attributen toevoegen aan het entiteittype ‘Klant’, dan zitten we met een gelijkaardig probleem. Een klant kan met meerdere wagens een dag en tijdstip vastleggen voor een testrit. Mochten we dit dus als een attribuut toevoegen aan het entiteittype ‘Klant’, dan zou voor alle vastgelegde testritten hetzelfde datum en tijdstip gelden. We kunnen de attributen ‘Dag’ en ‘Tijdstip’ dus niet toevoegen bij het entiteittype ‘Klant’.

De oplossing is om deze attributen als eigenschappen van de relatie te beschouwen . Hierdoor gaan we voor elke combinatie van klant en auto aangeven op welke dag en tijdstip de testrit gepland is.

Een voorbeeld van een N-M relatie met een relatie ‘Boekt testrit’ tussen de entiteittypes ‘Klant’ en ‘Wagen’. De relatie is uitgebreid met twee attributen ‘Datum’ en ‘Tijdstip’.

Opgelet! Een attribuut van een relatie kan enkel bestaan indien het gaat om een N-M relatie. Voor alle andere types van relaties is dit niet mogelijk. We kunnen de attributen dan altijd aan één van de entiteittypes verbinden.

Oefening jeugdvereniging: types van attributen

Maak oefening 4: jeugdvereniging, types van attributen.

Oefening autoverhuurbedrijf

Maak oefening 5: autoverhuurbedrijf.

Zwakke en sterke entiteiten

Binnen de entiteittypes kunnen we nog een onderscheid maken tussen zwakke entiteittypes en sterke entiteittypes (ook wel gewone entiteittypes genoemd). Een zwak entiteittype beschrijft een verzameling van entiteiten die niet op zichzelf kunnen bestaan. De entiteiten zijn afhankelijk van het bestaan van andere entiteiten.

Een voorbeeld van een zwak entiteittype is een ‘Inschrijving’ aan de UCLL Hogeschool. Een inschrijving kan niet bestaan als er geen student bestaat. Er moet met andere worden al een entiteit ‘Sam Peters’ van entiteittype ‘Student’ aangemaakt zijn vooraleer we Sam kunnen inschrijven. De entiteit van het entiteittype ‘Inschrijving’ zal een verwijzing bevatten naar de entiteit van het entiteittype ‘Student’. In het ERD moet er dus een relatie bestaan tussen beide entiteittypes.

Voor de identificatie van de zwakke entiteit gaan we gebruik maken van het sleutelattribuut van de sterke entiteit. Op basis van bovenstaand voorbeeld, gaan we dus gebruik maken van het studentnummer van ‘Sam Peters’ om de inschrijving (deels) te identificeren. Aangezien Sam meerdere inschrijvingen kan hebben over verschillende jaren heen, is het studentnummer onvoldoende om de inschrijving te identificeren. We gaan die combineren met een volgnummer, of academiejaar, ...

Een zwak entiteittype wordt in een ERD aangeduid als een vierkant met een dubbele omlijning met hierin de naam van het entiteittype. De relatie tussen het zwak en sterk entiteittype wordt weergegeven als een ruit met dubbele omlijning .

Een voorbeeld van een zwak entiteittype‘Inschrijving’ met relatietype ‘Schrijft in’.

Let op het feit dat we in het ERD het identificerend attribuut van het entiteittype ‘Student’ niet overnemen als identificerend attribuut van ‘Inschrijving’. We kunnen dit wel afleiden uit de notatie met de dubbel omlijnde rechthoeken en ruiten.

In de praktijk kan een zwakke entiteit wel een eigen sleutelattribuut krijgen bij het uittekenen van een logisch of fysiek datamodel omdat dit efficiëntiewinst oplevert.

Oefening studentenadministratie

Maak oefening 6: studentenadministratie.

Extended Entity Relationship Diagram (EERD)

Het ERD werd uitgebreid met een aantal concepten om meer complexe versies van de realiteit te kunnen modelleren.

Subtypes en supertypes

Een entiteittype is een subtype van een ander entiteittype indien het eerste entiteittype alle attributen en relaties overerft van het tweede entiteittype en dit uitbreidt met eigen attributen en relaties. Het tweede entiteittype is een meer generiek entiteittype met een aantal algemene attributen en relaties, en noemen we het supertype.

Een voorbeeld van subtypes en supertypes is bijvoorbeeld een supertype ‘Werknemer’, en twee subtypes ‘Tijdelijke werknemer’ en ‘Permanente werknemer’. Van het entiteittype ‘Werknemer’ houden we de typische eigenschappen bij: naam, voornaam, geboortedatum, werknemersnummer, ... Daarnaast hebben we het entiteittype ‘Tijdelijke werknemer’ dat alle attributen en relaties overerft van het entiteittype ‘Werknemer’, maar dit uitbreidt met de attributen ‘Startdatum contract’ en ‘Einddatum contract’. Het entiteittype ‘Permanente werknemer’ breidt het entiteittype ‘Werknemer’ uit met de attributen ‘Startdatum werknemer’ en ‘Aantal jaren dienst’.

Subtypes kunnen overlappend of disjunct zijn:

Het voorbeeld (zie ook onderstaande figuur) is disjunct, aangezien een werknemer of een tijdelijke werknemer is, of een permanente werknemer maar nooit beide.

De overerving kan totaal of optioneel zijn:

Het voorbeeld is totaal: elke werknemer moet of een tijdelijke medewerker zijn, of een permanente medewerker zijn.

Elke entiteit van een subtype, is ook een entiteit van het supertype. De relatie tussen een subtype en supertype is een 1-1 relatie. Het sleutelattribuut van het supertype, wordt ook het sleutelattribuut van de subtypes. Dit wordt geïmpliceerd door de overerving, en moet dus niet toegevoegd worden.

Notatie ERD

De notatie van sub- en supertypes gebeurt aan de hand van een cirkel met hierin een ‘O’ om overlappende subtypes aan te geven, of ‘D’ om disjuncte subtypes aan te geven. Vanuit de subtypes gaat een lijn naar de cirkel waarop we een boog tekenen. Vanuit de cirkel gaat een lijn naar het supertype. De lijn wordt dubbel of enkel getekend. Een dubbele lijn duidt op een totale overerving, een enkele lijn op een optionele overerving.

Een voorbeeld van een supertype ‘Werknemer’ met twee subtypes ‘Tijdelijke werknemer’ en ‘Permanente werknemer’.

Generalisatie en specialisatie

Het proces om subtypes en supertypes te definiëren, wordt ook wel generalisatie en specialisatie genoemd:

Met andere woorden, het is de richting die bepaalt of je spreekt over generalisatie of specialisatie, maar het resultaat is hetzelfde.

Wanneer toepassen?

Subtypes en supertypes zijn handig wanneer er een grote overlap is tussen een aantal entiteittypes. Het zorgt voor een overzichtelijk schema en reikt ook al oplossingen aan voor de ontwikkeling van de tabellen.

Oefening bibliotheek

Maak oefening 7: bibliotheek.