Embed Size (px)
Citation preview
Database Concepts
Arne Vandenbussche, Marc Desplenter, Luc De TollenaereAcademiejaar 2019-2020
Handelswetenschappen en bedrijfskunde
Legende van de gebruikte iconen
Database Concepts 1
Legende van de gebruikte iconen
Denkvraag
Leerdoelen
Extra informatie
Niet vergeten
Opdracht/Oefening
Presentatie (PowerPoint)
Samenwerking
Studeeraanwijzingen
Beeld-/geluidsfragment
Voorbeeld
Tools/Apps
Website
Zelfstudie
(Zelf)toets
Inhoudsopgave
Database Concepts 2
Inhoudsopgave
Legende van de gebruikte iconen .................................................................................................. 1
Inhoudsopgave ............................................................................................................................. 2
Hoofdstuk 1: Inleiding ................................................................................................................... 6
1.1 Data versus informatie ............................................................................................................. 6
1.2 Gegevensdragers door de eeuwen heen .................................................................................. 7
1.3 Databasemanagementsystemen .............................................................................................. 8
1.4 Het toenemend belang van gegevens en informatie ............................................................. 12
1.5 Datawarehouses ..................................................................................................................... 13
1.6 Business Intelligence ............................................................................................................... 14
1.7 Artificial Intelligence – Machine Learning .............................................................................. 15
1.8 Big Data ................................................................................................................................... 17
1.9 Internet of Things - IoT ........................................................................................................... 19
Hoofdstuk 2: Het relationele model ............................................................................................ 21
2.1 Inleiding .................................................................................................................................. 21
2.2 Bouwstenen van relationele gegevensbanken ....................................................................... 22
2.2.1 Relaties.................................................................................................................................... 22
2.2.2 Attributen ................................................................................................................................ 23
2.2.3 Domeinen ................................................................................................................................ 25
2.2.4 Tupels ...................................................................................................................................... 25
2.2.5 Nulwaarden (nulls) .................................................................................................................. 26
2.3 Sleutels .................................................................................................................................... 26
2.3.1 Kandidaatsleutels.................................................................................................................... 26
2.3.2 Primaire sleutel (Primary Key) ................................................................................................ 27
2.3.3 Verwijssleutel (Foreign Key) .................................................................................................... 27
2.3.4 Datastructuurdiagram/ERD .................................................................................................... 28
2.4 Integriteit ................................................................................................................................ 31
2.4.1 Entiteit-integriteit (Entity integrity) ........................................................................................ 31
2.4.2 Referentiële integriteit (Referential integrity) ........................................................................ 32
Inhoudsopgave
Database Concepts 3
2.4.3 Domeinrestricties (Domain constraints) ................................................................................. 32
2.5 Relationele algebra ................................................................................................................. 32
2.5.1 Selectie .................................................................................................................................... 33
2.5.2 Projectie .................................................................................................................................. 35
2.5.3 Join .......................................................................................................................................... 35
2.5.4 Vereniging (Union) .................................................................................................................. 38
2.5.5 Doorsnede (Intersect) ............................................................................................................. 38
2.5.6 Verschil (minus) ....................................................................................................................... 39
2.5.7 Views ....................................................................................................................................... 39
2.6 Oefeningen ............................................................................................................................. 41
2.6.1 Begrippen ................................................................................................................................ 41
2.6.2 IQ – lengte - leeftijd ................................................................................................................ 41
2.6.3 Studenten en hun vakken ........................................................................................................ 42
2.6.4 Bestellingen in de bistro .......................................................................................................... 43
2.6.5 Handbalcompetitie ................................................................................................................. 43
2.6.6 Relationele algebra en de VIVES-database. ............................................................................ 44
2.6.7 Studiecontracten ..................................................................................................................... 45
2.6.8 CAR-PASS................................................................................................................................. 46
2.6.9 Hotelreservaties ...................................................................................................................... 47
2.6.10 De eenvoudige bibliotheek ...................................................................................................... 48
Hoofdstuk 3: Een relationele database ontwerpen door normalisatie. ......................................... 50
3.1 Inleiding .................................................................................................................................. 50
3.2 Normaliseren .......................................................................................................................... 51
3.3 Repeterende groepen ............................................................................................................. 52
3.4 Functionele afhankelijkheden in relatieschema’s. ................................................................. 53
3.4.1 Functionele afhankelijkheid. ................................................................................................... 53
3.4.2 Volledige functionele afhankelijkheid. .................................................................................... 53
3.4.3 Transitief functionele afhankelijkheid. .................................................................................... 54
3.5 Stappen bij het normaliseren. ................................................................................................ 56
3.5.1 Van nulde naar eerste normaalvorm. ..................................................................................... 56
3.5.2 Tweede normaalvorm. ............................................................................................................ 57
Inhoudsopgave
Database Concepts 4
3.5.3 Derde normaalvorm. ............................................................................................................... 57
3.5.4 Voorbeeld ................................................................................................................................ 57
3.6 Domein-sleutelnormaalvorm .................................................................................................. 59
3.7 Oefeningen op normaliseren .................................................................................................. 61
3.7.1 Inleidende oefeningen............................................................................................................. 61
3.7.2 Studentenhuizen ..................................................................................................................... 65
3.7.3 Monitoraat .............................................................................................................................. 65
3.7.4 Studentenhuizen (2) ................................................................................................................ 65
3.7.5 Archeologische vondsten ........................................................................................................ 66
3.7.6 Lijst uitleningen ....................................................................................................................... 66
3.7.7 Inkooporders. .......................................................................................................................... 67
3.7.8 Vrachtwagenverhuur .............................................................................................................. 69
3.7.9 Vakken in een hogeschool....................................................................................................... 69
3.7.10 Informatica-afdeling. .............................................................................................................. 70
3.7.11 Voorraadbeheer ...................................................................................................................... 70
3.7.12 Bibliotheek .............................................................................................................................. 71
3.7.13 Garagebedrijf. ......................................................................................................................... 72
3.8 Denormalisatie en optimalisatie. ............................................................................................ 73
Hoofdstuk 4: Evaluatiecriteria voor volwaardige Relationele Database Management Systemen. .. 75
4.1 Criterium 1: 3-lagenstructuur ................................................................................................. 76
4.2 Criterium 2: Standaard SQL .................................................................................................... 79
4.2.1 Wat is SQL? ............................................................................................................................. 79
4.2.2 SQL: declaratieve taal met procedurele extensies. ................................................................. 79
4.2.3 SQL: interactief versus embedded .......................................................................................... 81
4.2.4 SQL: impedance mismatch en ORM-frameworks ................................................................... 83
4.2.5 SQL: soorten instructies .......................................................................................................... 84
4.3 Criterium 3: Query Optimizer ................................................................................................. 84
4.3.1 De taak en werking van de query optimizer ........................................................................... 84
4.3.2 Indexen .................................................................................................................................... 86
4.4 Criterium 4: Data Dictionary ................................................................................................... 88
4.5 Criterium 5: Integriteitscontrole ............................................................................................. 90
Inhoudsopgave
Database Concepts 5
4.6 Criterium 6: Transactiegeoriënteerd ...................................................................................... 92
4.7 Criterium 7: concurrency control en read consistency........................................................... 93
4.8 Criterium 8: Selective access control ...................................................................................... 97
4.9 Criterium 9: Backup en Recovery faciliteiten ......................................................................... 99
4.10 Criterium 10: Auditing ............................................................................................................ 99
4.11 Criterium 11: Import/Export utilities .................................................................................... 100
4.12 Opgaven ................................................................................................................................ 100
Hoofdstuk 5: NoSQL-databases ..................................................................................................103
5.1 Wat zijn NoSQL-databases? .................................................................................................. 103
5.2 Waarom NoSQL-databases? ................................................................................................. 105
5.3 Soorten NoSQL-databases? .................................................................................................. 106
5.4 Een voorbeeld: MongoDB ..................................................................................................... 107
5.5 Embedden of verwijzen ........................................................................................................ 109
5.6 Replication and sharding ...................................................................................................... 110
Bijlagen 112
Inleiding
Database Concepts 6
Hoofdstuk 1: Inleiding
De student(e) kan een aantal basisbegrippen in verband met gegevens, informatie
en databanken, databasemanagementsystemen uitleggen en in een context correct
gebruiken.
Hij/zij kan de rol van een databasemanagementsysteem toelichten.
Hij/zij kent het onderscheid tussen een operationele database en een
datawarehouse en kan de rol van een datawarehouse en verwante begrippen
uitleggen.
Hij/zij kan het belang van kennis van databanken aantonen en de invloed dan data
science op ons leven situeren.
In dit eerste hoofdstuk van de cursus Database Concepts wordt een heel brede inleiding gegeven:
gaande van de historiek van gegevensdragers over de evolutie van data tot de evolutie van systemen
om data te beheren en te analyseren. Daarenboven worden ook een aantal gerelateerde
functieprofielen uit het werkveld vermeld waarvoor de vraag veelal het aanbod van mensen met
gepaste competenties ruimschoots overtreft.
In de afgelopen jaren is steeds meer duidelijk geworden dat het belang van data spectaculair stijgt.
Gegevens zijn immers de primaire grondstof geworden voor het functioneren van bedrijven en van
onze samenleving.
Terecht wordt dan ook dikwijls de stelling geponeerd: ‘data is the new oil’.
1.1 Data versus informatie
Computersystemen worden tegenwoordig gebruikt voor de automatisering van allerlei aspecten van
menselijke activiteit. Een belangrijke activiteit, die niet meer weg te denken is uit de huidige
informatiemaatschappij, is het automatisch beheren van informatie met het oog op latere
verwerking en hergebruik. In eenvoudige gevallen komt dit louter neer op het bijhouden van
gegevens voor later onderzoek. In meer geavanceerde toepassingen mondt dit uit in complexe taken
voor de ondersteuning van diverse activiteiten binnen een onderneming. Naast het doorzoeken, zijn
het toevoegen, verwijderen, aanpassen en consistent houden van gegevens typische basistaken die
voorkomen bij gegevensbeheer.
Doorheen deze cursus maken we een duidelijk onderscheid tussen de termen data (of gegevens) en
informatie. Met data bedoelen we ‘gegeven feiten’. Zo vormen getallen, symbolen, woorden,
berichten, foto’s, video’s,.. op zich data. Voorbeelden van gegevens of data zijn dan: 45; ‘Piet’; 12,5;
…
Pas wanneer een gebruiker of een groep gebruikers betekenis aan deze data kan toekennen spreken
we van informatie. 45 wordt dan de leeftijd van een sollicitant. ‘Piet’ wordt de voornaam van een
Inleiding
Database Concepts 7
werknemer. 12,5 wordt de gemiddelde temperatuur op 11 janauari 2019. Een foto is een
verzameling pixels. Dat is pure data. Wanneer een persoon op een foto in facebook getagd wordt
ontstaat er extra ‘informatie’.
In de context van informatiebeheer is het verschil tussen de concepten data en informatie
belangrijk. De meeste computersystemen zijn vrijwel enkel in staat om op een efficiënte manier data
te beheren, betekenis wordt toegevoegd door de gebruikers. Dit heeft rechtstreeks geleid tot de
term database die we als volgt kunnen omschrijven: een database is een collectie van persistente
data. Het woord ‘persistent’ geeft hierbij aan dat de data gedurende een zekere tijd worden
opgeslagen in het permanent geheugen van een computersysteem.
De huidige databasetechnologie, die ingezet wordt voor bedrijfsdatabases, is overwegend gericht op
het beheer van data (gegevens), eerder dan op het beheer van de betekenis van de data. Op het
wereldwijd web zien we dat er steeds meer betekenis in de data herkend wordt, denk maar aan
intelligente zoekmachines zoals Google. Men spreekt in dit verband over semantische databases. De
data worden vergezeld van betekenis en context en die informatie kan zowel door mensen als
machines geïnterpreteerd worden.
Een computersysteem voor het beheer van databases wordt een databasemanagementsysteem
genoemd.
1.2 Gegevensdragers door de eeuwen heen
Gegevensbeheer is een zeer oude activiteit. Vrijwel alle moderne beschavingen danken hun bestaan
grotendeels aan hun vermogen om gegevens en kennis fysiek te registreren met het oog op bewaring
en kennisoverdracht. Sinds de codex van Hammoerabi (een van de oudste schriftelijke wetten,
ongeveer 4000 jaar geleden) waren steen, hout, perkament en papier achtereenvolgens de
dominante informatiedragers. Aanvankelijk deed men weinig moeite om de geregistreerde
informatie te structureren, later begon de mens het nut te erkennen van het groeperen van data
volgens een vaste structuur: men kan gestructureerde data veel efficiënter doorzoeken en bewaren.
Eén van de eerste voorbeelden van een gestructureerde informatiedrager: in het begin van de
negentiende eeuw werden de besturingsinstructies van het automatisch Jacquard-weefgetouw
voorgesteld door gestructureerde perforaties in kartonnen kaarten. Herman Hollerith gebruikte ook
soortgelijke kaarten bij de machine die hij ontwierp voor de statische verwerking van de
Amerikaanse volkstellingsgegevens van 1890. Een nieuwe gegevensdrager, de ponskaart, was
geboren.
Het duurde tot de jaren 1970-1980 voordat ponskaarten geleidelijk aan werden verdrongen door
sneller toegankelijke en gemakkelijker te hanteren magnetische gegevensdragers met veel grotere
opslagcapaciteit. Aanvankelijk waren dat vooral magneetbanden. Die hadden het nadeel dat de
gegevens sequentieel (de een na de ander) benaderd moesten worden. Dat was niet erg efficiënt .
Inleiding
Database Concepts 8
Daarna kwamen de magneetschijven. Zij hadden het voordeel dat de leeskop sneller naar een
bepaald blok op de schrijf kon bewegen. Dit kennen we nog van de meeste harde schrijven op onze
PC’s en servers.
Later volgden de optische gegevensdragers (CD, DVD, Blu-ray). Deze werden en worden gebruikt
voor de archivering van gegevens en voor het afspelen van multimediaal materiaal.
Deze laatste categorie is stilaan aan het verdwijnen ten voordele van flashgeheugen (SSD, USB, SD-
kaart). Deze zijn veel sneller dan de klassieke magneetschijven omdat er geen mechanische
bewegingen (draaiende schijven, leeskoppen) nodig zijn, maar alles elektronisch gebeurt. De prijs per
MB van flashgeheugen is veel duurder dan dat van een klassieke magneetschijf, maar die prijs is snel
aan het dalen. De invoering van deze snelle gegevensdragers maakt onze PC’s en servers vele malen
sneller dan voorheen.
We kennen intussen ook al de zogenaamde “in memory databases”. Hier worden de gegevens in
eerste instantie in het heel snelle, maar vluchtige werkgeheugen gehouden en gebeurt de stockering
op een permanente gegevensdrager slechts in tweede instantie.
Een niet te stuiten evolutie is dat data steeds meer en meer in de cloud opgeslagen wordt. De cloud
staat voor een netwerk dat met alle computer die erop aangesloten zijn een soort ‘wolk van
computers’ vormt, waarbij de eindgebruiker niet weet op hoeveel of welke computers de software
draait, de data staat en waar die computers precies staan.
De gebruiker hoeft op deze manier geen eigenaar meer te zijn van de gebruikte hard- en software en
is dus ook niet verantwoordelijk voor het onderhoud.
Cloud computing is het via een netwerk – vaak het internet – op aanvraag beschikbaar stellen van
hardware, software en gegevens, ongeveer zoals elektriciteit uit het lichtnet.
1.3 Databasemanagementsystemen
Oorspronkelijk werden data bijgehouden in aparte bestanden. We hadden databasetoepassingen die
toegang kregen tot die gegevens, daar betekenis aan gaven en die gegevens beheerden. Met een
databasetoepassing bedoelen we hier een webapplicatie, een mobiele app, een desktoptoepassing
of back-endsoftware die toegang heeft tot de gegevens in de database. Enkele decennia geleden
zaten die gegeven in geïsoleerde bestanden. Geîsoleerde toepassingen hadden toegang tot die
bestanden.
Inleiding
Database Concepts 9
Die softwaretoepassingen (client-toepassingen) moesten exact weten waar de bestanden waren
opgeslagen en welke interne structuur ze hadden. Op die manier konden zij die gegevens inlezen en
wegschrijven en daar betekenis aan geven. De betekens van de gegevens was beschreven in de
toepassingen, niet in de bestanden zelf. Dit had duidelijke nadelen:
• Gegevens worden gescheiden opgeslagen. Klantgegevens zitten in andere bestanden dan
factuurgegevens.
• Er ontstaat duplicatie. Bepaalde gegevens over klanten zullen zowel in het klantenbestand als
in het facturenbestand voorkomen.
• De applicaties moeten de interne structuur van de bestanden kennen.
o Dat maakt de applicaties complexer.
o Als de interne structuur van een bestand wijzigt of het bestand wordt verplaatst ,
moet ook de applicatie herschreven worden
• De gegevens zijn niet goed geïntegreerd. Het vraagt soms toegang tot diverse bestanden om
alle gegevens over een verkoop of een klant te verzamelen.
• Buiten de applicaties om, is het nagenoeg onmogelijk om een betekenisvolle toegang tot de
gegevens te krijgen.
In de jaren 1970 ontstaan er geïntegreerde databases. Dit betekent dat we de diverse gegevens in
één database stoppen
Een databasemanagementsysteem (DBMS) is de softwarecomponent van een databasesysteem die
instaat voor het beheer van de databases. Het DBMS heeft als doel het beheren en bewaren van data
in de database en gebruikers toe te laten om, via een databasetoepassing, deze data te manipuleren
en te doorzoeken.
Gebruikers
DBMS Database
Database
toepassing
Inleiding
Database Concepts 10
Het DBMS neemt dus alle beheerstaken omtrent de opgeslagen data op zich:
• het regelt de fysieke opslag van de gegevens,
• controleert de juistheid en de volledigheid van de gegevens,
• zorgt voor het zo snel mogelijk doorzoeken van de data (performantie)
• en beschermt de gegevens tegen ongeautoriseerd gebruik.
Deze taken worden dus bijgevolg uit de applicaties gelicht waardoor deze minder complex worden.
Het DBMS houdt in de database ook een beschrijving van de structuur van alle opgeslagen data bij:
• welke soort data wordt er opgeslagen,
• welke verbanden zijn er tussen de data,
• welke waarden kunnen er opgeslagen worden,
• welke gebruikers zijn er geregistreerd,
• wie is de eigenaar van bepaalde data,
• welke rechten hebben ander gebruikers t.o.v. bepaalde data (lezen/wijzigen/schrappen).
Deze beschrijving wordt meta-data genoemd (data omtrent de data) en wordt in de database
opgeslagen in een onderdeel dat de data dictionary genoemd wordt.
De voordelen van een geïntegreerde database beheerd door een DBMS zijn duidelijk:
• De informatie wordt in één database bewaard waardoor het evidenter is om relaties tussen
gegevens te leggen (bijv. een verkoop en een factuur).
• Wanneer de database goed ontwerpen is (cf. normalisatie uit hoofdstuk 3), dan worden
gegevens niet gedupliceerd, maar slechts één keer bijgehouden. Er kan immers vanuit een
factuurgegeven een verwijzing gemaakt worden naar de klantengegevens. Dat verlaagt de
kans op fouten.
• De betekenis van de gegevens zit vervat in de database (in de data dictionary). Dat maakt het
gemakkelijker om nieuwe applicaties te bouwen die deze data gebruiken.
• De applicaties moeten zich geen (of minder) zorgen maken over de interne structuur van de
gegevens, de performantie van de databasebevragingen, de controle op bepaalde facturen
die de gegevens correct houden, gebruikerstoegang en beveiliging. Dit wordt door de DBMS
afgehandeld op een eenduidige manier.
• De DBMS voorziet ook een gestructureerde, afgeschermde toegang tot de gegevens buiten
de applicaties om, bijv. via SQL.
Momenteel zijn de meest gebruikte databasesystemen voor de dagdagelijkse verwerking van
operationele taken binnen bedrijven en organisaties de zogenaamde relationele
databasemanagementsystemen (RDBMS).
Inleiding
Database Concepts 11
Volgens het relationeel databasemodel worden databases logisch gezien als verzamelingen van
samenhangende tabellen. Alle relationele databasesystemen werken met een standaard
datadefinitie- en datamanipulatietaal, namelijk SQL (Structured Query Language).
De meest bekende RDBMS-systemen zijn het open-source systeem MySQL en de commerciële
systemen Oracle RDBMS, Microsoft SQL Server, IBM DB2 en MS Access.
Belangrijke functies in verband met databases en DBMS’en zijn:
Data modeler
Een data modeler is in staat om een bedrijfsproces te analyseren en hieruit af te leiden
welke data en in welke structuur deze data dient opgeslagen te worden. Hieronder ziet u
bijvoorbeeld een visueel model van de structuur van een database, een zogenaamd entiteit-
relatiediagram of ERD.
Vermits data voorkomt is in vrijwel elke IT-toepassing en app vormt het datamodelleren een
essentiële basiscompetentie voor elke informaticus.
Datamodellering vormt het hoofdthema van deze cursus Database Concepts.
Database administrator (DBA)
Een database administrator is iemand binnen een onderneming die technisch
verantwoordelijk is voor de implementatie en het onderhoud van de databases. Enkele
belangrijke taken van een DBA zijn:
Inleiding
Database Concepts 12
• het plannen van initiële benodigde opslagruimte voor nu en in de toekomst, ten bate van zowel het databasemanagementsysteem als de van data zelf;
• het modificeren van de databasestructuur naar de eisen en wensen van de applicatieontwikkelaar(s);
• het instaan voor de kwaliteit van de data;
• het beheren van toegangsrechten van de verschillende gebruikers;
• het herstellen na falen (backup & restore);
• het observeren en het controleren van de performantie en het goed functioneren van het hele databasesysteem en het optimaliseren van die performantie.
1.4 Het toenemend belang van gegevens en informatie
Steeds meer gegevens worden op een digitale manier gecreëerd, beheerd en gebruikt. In het begin
van het informatie hadden we grote mainframecomputer die hun eigen bestanden en databases
hadden en die gegevens gebruikten binnen het kader van één bedrijf.
Met de spectaculaire groei van het internet vanaf de jaren ’90 van de vorige eeuw worden gegevens
toegankelijk van overal ter wereld. Verkopen kunnen op afstand worden gedaan, gegevens worden
beschikbaar gemaakt en gemanipuleerd via toepassingen die van overal ter wereld toegankelijk zijn
en databanken gebruiken die zich waar ook ter wereld kunnen bevinden.
Gordon Moore heeft in de jaren 1960 al voorspeld dat computers elke twee jaar zouden verdubbelen
in snelheid. Dit en de beschikbaarheid van het wereldwijde web zorgt voor een explosieve toename
van het computergebruik en van het gebruik van gegevens.
De connectiviteit van gebruikers neemt nog toe met de komst van de smartphone. In de 21ste eeuw
heeft iedereen een computer op zak. We zijn permanent verbonden met het internet, niet alleen op
kantoor, maar ook thuis, op de trein, op vakantie, tijdens een muziekfestival, enzovoort. Overal
gebruiken we gegevens en sturen we via sociale media zelf gegevens de wereld in. We laten een
permanent spoort van gegevens achter.
Dit heeft gezorgd voor een disruptie. Met disruptie bedoelen we dat bestaande economische en
maatschappelijke modellen op hun kop gezet worden. De voortdurende connectiviteit, de steeds
grotere beschikbaarheid van gegevens van allerlei aard en het steeds intelligentere gebruik van deze
gegevens maakt dat hele bedrijfstakken verdwijnen of op hun kop gezet worden.
We kunnen hier tal van voorbeelden geven:
• De klassieke brievenpost is marginaal geworden in vergelijking met het gebruik van e-mail,
whatsappberichten, sms, enzovoort.
• Zeldzame producten zijn nu voor iedereen van overal beschikbaar (cf. The long Tail).
• Marketing en reclame is niet enkel meer een zaak van televisie en folders, maaar is meer en
meer digitale marketing, waarbij elke individu zijn eigen persoonlijke reclame krijgt.
Inleiding
Database Concepts 13
• De klassieken platenindustrie werd bijna van de kaart geveegd door het streamen van
muziek, waarbij wij die muziek voorgeschoteld krijgen die het best aansluit bij onze
persoonlijke smaak.
• Klassieken reisagentschappen verdwijnen of vervulllen een totaal andere rol. Wij plannen en
boeken onze reis via diverse webtoepassingen en mobiele apps.
• ….
Het aantal voorbeelden is legio. De gemeenschappelijke factor is dat al die nieuwe industrieën en
diensten steunen op de beschikbaarheid van grote hoeveelheden gegevens en het steeds
intelligenter gebruik van deze gegevens. Naast de klassieke operationele database zien we nieuwe
fenomenen zoals data warehouses, business intelligence, data analytics, big data, the internet of
things, enzovoort.
1.5 Datawarehouses
Een klassieke RDBMS is een ideaal platform voor zogenaamde operationele of transactionele
databases. Dit zijn de databases die de dagelijkse transacties bevatten. We denken hier aan het
beheren van verkopen, het factureren van verkopen, het registreren van nieuwe personeelsleden,
enzovoort. In een dergelijke database komen er voortdurend toevoegingen, wijzigingen en
schrappingen voor. Deze databases zijn ideaal voor de dagelijke transacties, maar maken
rapportering over het verleden niet altijd eenvoudig. Daarom hebben we een datawarehouse nodig.
Het datawarehouse (DWH) is een database waar de data zo gestructureerd is dat deze rapportering
en analyse vlot toelaat, het vormt de centrale opslagplaats voor verder te analyseren data. Het
datamodel in een datawarehouse is zo opgebouwd dat de database ideaal is dat om gegevens te
raadplegen en te analyseren, maar niet geschikt is voor dagelijkse wijzigingen. Dat vraagt andere
gegevensstructuren. Een datawarehouse is gebouwd in functie van raadpleging en niet van wijziging.
Een datawarehouse zal ook gegevens groeperen uit verschillende bronnen: de operationele
databases uit verschillende systemen, bestanden hier en daar, externe gegevens, enzovoort.
Een datawarehouse moet ook gevuld worden met die gegevens uit verschillende bronnen en die
gegevens moeten gefilterd en omgezet worden naar de nieuwe structuur. Dit is een proces dat
geregeld herhaald moet worden aangezien de operationele databases voortdurend met nieuwe
gegevens gevuld worden. Dat proces van het overzetten van de gegevens uit diverse
gegevensbronnen naar een datawarehouse nomen we ETL (Extract, Transform, Load). Er bestaan
diverse ETL-tools die dat proces van het extraheren, het transformeren en het laden van data vanuit
de operationele systemen zo automatisch mogelijk laten gebeuren.
Het belang van een goed doordacht DWH mag niet onderschat worden, via het DWH moet immers
één versie van de waarheid (single version of the truth) gegarandeerd worden. In een operationeel
systeem zitten gegevens vaak verspreid over verschillende systemen: diverse RDBMS’en,
excelbestanden, enzovoort, waarbij dubbels of tegenstrijdige waarden niet uitgesloten zijn. Met een
DWH moet een eind gemaakt worden aan het bestaan van verschillende informatiesilo’s in de
Inleiding
Database Concepts 14
organisatie en de daarbij horende tijdrovende gegevensconsolidaties en controles op datakwaliteit
en integriteit. Gegroepeerde gegevens over een klant bevinden zich op één plaats en bevatten de
volledige en gezuiverde gegevens over die klant.
Voordelen van het gebruik van datawarehouses:
• Een “single version of the truth” wordt gegarandeerd
• Operationele systemen worden niet extra belast tijdens het uitvoeren van data-analysetaken.
• Historie (vb. wijzigingen woonplaats klant) worden bijgehouden.
• De opslagstructuur is gemodelleerd in functie van uiterst performante analyses.
Datawarehouse developer
Aangezien het doel van het opzetten van een datawarehouse erin bestaan om rapportering en
analyse te ondersteunen, worden de inhoud en het ontwerp ervan bepaald door de eisen van de
organisatie. In de praktijk betekent dit dat businessmedewerkers definiëren welke informatie hen
helpt betere beslissingen te nemen, waarna Datawarehouse-experten een datawarehouse en het
ETL-proces kunnen opzetten zodat de businessmedewerkers de juiste rapporten kunnen krijgen.
1.6 Business Intelligence
Business intelligence (BI) start met het verzamelen van gegevens binnen de eigen handelsactiviteit.
Het kan omschreven worden als het proces van gegevens omzetten in informatie, dat vervolgens zou
moeten leiden tot kennis en aanzetten tot adequate actie.
Business intelligence heeft als doel competitief voordeel te creëren en organisaties slimmer te
kunnen laten werken. Het wordt als een waardevolle kerncompetentie beschouwd.
Business intelligence is gericht op het verzamelen en analyseren van informatie over klanten,
beslissingsprocessen, concurrentie, markttoestand en algemene economische, technologische en
culturele trends, teneinde beslissingsondersteunende informatie (intelligence) te verkrijgen.
Op diverse niveaus in een organisatie hebben managers behoefte aan verschillende soorten
informatie, dit veelal op een zeer geaggregeerde wijze. Met geaggregreerde gegevens bedoelen we
gegevens die uit verschillende bronnen werden samengevoegd en vaak ook gefilterd zijn. Een
voorbeeld van geaggregeerde gegevens is het gemiddelde inkomen van mannelijke Belgen tussen 35
en 45.
Typisch voorbeeld van een methode die hiervoor ingezet kan worden is de “Balanced Scorecard”
waarin KPI’s (Key Performance Indicators) gevisualiseerd worden en het topmanagement op de
hoogte houden van de mate waarin de vooropgestelde targets al dan niet bereikt worden. Een KPI is
een precieze maatstaf die aangeeft hoe goed een onderneming presteert op een bepaald terrein.
Wanneer een manager bijvoorbeeld het percentage teruggestuurde producten uit de categorie
Inleiding
Database Concepts 15
kleding voor de regio Vlaanderen kent, kan hij nagaan of dit overeenkomt met de vooraf gestelde
doelen.
Op het tactisch en operationele niveau worden veelal “Dashboards” gebruikt. Een dashboard is één
pagina waarop data op een overzichtelijke manier visueel voorgesteld worden en waarop je vaak zelf
kunt filteren op diverse parameters. Via deze interface worden eveneens KPI’s voorgesteld. De focus
ligt hier eerder op de ondersteuning van dagdagelijkse operationele acties.
Bij het analyseren van gegevens, met oog op het verkrijgen van belangrijke bedrijfsinzichten die het
nemen van efficiënte beslissingen kunnen ondersteunen, wordt vaak gebruik gemaakt van OLAP-
tools (Online Analytical Processing) waarmee gegevens op een interactieve wijze gevisualiseerd
worden.
BI Analyst
Een BI Analyst analyseert data en creëert rapporten en analyses met nieuwe inzichten die door de
business gebruikt kunnen worden. Dit profiel vormt bij uitstek een brugfunctie tussen Business en
IT.
Data steward
Is een ondersteunende ICT’er, verantwoordelijk voor de kwaliteit en de consistentie van de data.
1.7 Artificial Intelligence – Machine Learning
De focus bij het analyseren van data verschuift ook steeds meer naar het kunnen voorspellen van
wat er in de toekomst zal gebeuren (predictive analytics), daar waar bij Business Intelligence de
nadruk veelal ligt op de analyse van wat voorbij is.
Inleiding
Database Concepts 16
Datamining is het gericht zoeken naar (statistische) verbanden in gegevensverzamelingen met als
doel profielen op te stellen voor wetenschappelijk, journalistiek of commercieel gebruik.
De naam komt voort uit de overeenkomsten tussen het zoeken naar statistische verbanden en het
graven (mining) naar iets waardevols in een grote berg. Datamining helpt bedrijven en
wetenschappers om de essentiële informatie te selecteren. Er kan een model mee gecreëerd worden
dat het gedrag van mensen of systemen kan voorspellen.
Het basisrecept van datamining is als volgt:
1) Je neemt data uit het verleden waarvoor je de uitkomst kent
2) Deze set splits je in een zogenaamde trainingsset en een testset
3) Je bouwt een wiskundig model met de trainingsset.
4) Je checkt hoe goed het model de uitkomsten van de testset voorspelt.
Werkt dit naar behoren dan kun je met een redelijke mate van zekerheid nauwkeurige
toekomstvoorspellingen doen.
Enkele dataminingtoepassingen:
• Opmaak klantprofielen en winstgevendheid.
• Voorspellen beste tijdstip om een onderdeel te vervangen (predictive maintenance).
• Voorspellen afhakers (churn prediction).
• Winkelwagen-analyse: optimaliseren indeling (web)winkel.
• Zoekmachines, sociale netwerksites.
Dataminingalgoritmen horen tot het domein van wat men artificiële intelligentie noemt, dikwijls
wordt ook de term Machine Learning gebruikt: door het leren uit gemaakte fouten worden
dergelijke systemen immers ook steeds beter.
De supercomputer Watson van IBM heeft de onderzoekslaboratoria verlaten en wordt reeds ingezet
in verscheidene Amerikaanse ziekenhuizen. Door symptomen en medische dossiers van patiënten te
toetsen aan de enorme hoeveelheden literatuur die hij in zijn geheugen heeft opgeslagen, kan hij
een diagnose stellen. Met een hoge efficiëntie: analyse van de resultaten toonde aan dat diagnoses
van Watson voor 90 procent betrouwbaar waren, tegenover 50 procent voor menselijke artsen.
Een ander mooi voorbeeld waar Machine Learning een noodzaak vormt is dat van de zelfrijdende
auto. De grote uitdaging is hier niet het rijden op zich maar wel het extreem snel kunnen analyseren
van alle beeldmateriaal van de camera’s en hiermee telkens de juiste beslissing te kunnen nemen.
Vermits zelfrijdende wagens ook zullen geconnecteerd zijn, zullen deze ook van elkaar leren.
De mens staat machteloos tegenover de wildgroei aan data, terwijl de kracht van kunstmatige
intelligentie er precies in bestaat dat ze in fracties van seconden miljarden gegevens kan analyseren.
Inleiding
Database Concepts 17
Artificiële intelligentie zal wellicht uitgroeien tot een van de belangrijkste sectoren van deze eeuw!
1.8 Big Data
Men spreekt van Big Data wanneer men werkt met meerdere datasets die te groot zijn om met
reguliere databasemanagementsystemen verwerkt te worden. Hierbij zijn drie factoren belangrijk: de
hoeveelheid data, de snelheid waarmee de data binnenkomt en opgevraagd wordt en de diversiteit
van de data. In het Engels spreekt men van de drie V’s: Volume (hoeveelheid data), Velocity
(snelheid van verwerking) en Variety (diversiteit van gegevens). Soms wordt Value hieraan
toegevoegd om het objectief, de (meer)waarde die dit kan opleveren, te benadrukken.
Zo wordt er gebruik gemaakt van zowel gestructureerde data (uit databanken) als van
ongestructureerde data van bijvoorbeeld sociale netwerken (tweets, blogs, forums, audio, video,
webpagina’s, geografische info,…). In tweets bijvoorbeeld zit er weinig structuur : er is de zender en
de datum en verder 140 willekeurige tekens met veel verschillende hashtags.
De beschikbaarheid van grote hoeveelheden big data wordt veroorzaakt door een aantal elementen:
• Het intensief gebruik van mediatoepassingen zoals streamingdiensten, sociale media, …. Dat
veroorzaakt een stroom aan berichten, foto’s, filmpjes, … Dit is een gigantische stroom
ongestructureerde gegevens.
• De gigantische hoeveelheid gegevens die via het web verspreid worden, dragen ook bij tot de
steeds grotere beschikbaarheid van big data: webshops, wikipedia, blogs, discussiefora,
enzovoort.
• IoT, the internet of things. Dat begrip leggen we wat verder in detail uit. Hier krijgen we
gestructureerde gegevens die in een hoog tempo door allerlei apparaten gegenereerd
worden.
Inleiding
Database Concepts 18
• De steeds grotere beschikbaarheid van grote databanken die de bedrijfsprocessen
ondersteunen. We spreken hier dan over gestructureerde data in allerlei systemen. Veel van
die data worden ook via de cloud ter beschikking gesteld.
De informatie en potentie van ongestructureerde data is enorm. Bioscopen kunnen al op basis van
tweets in de week voorafgaand aan een première inschatten hoe druk het in de eerste week gaat
worden. Hoe meer positieve tweets over de film, hoe beter hij zal lopen. Goed om te weten als je
planner bent: welke film krijgt volgende week de grootste zaal?
Voor dit soort van Big Data is de laatste tijd een heel scala aan nieuwe soorten databases ontstaan.
Vaak worden die allemaal samengevat onder de noemer NoSQL. Dit is echter een slechte naam die
voornamelijk refereert aan het feit dat het niet om relationele databases gaat.
Een populair open-source softwareframework voor gedistribueerde opslag en verwerking voor grote
hoeveelheden data is Hadoop. Het draait op een cluster van computers en er wordt rekening
gehouden met een mogelijke uitval van een computer door replicatie van de data over verschillende
computers.
De hoeveelheid data neemt exponentieel toe, zo is negentig procent van alle wereldwijd beschikbare
data de afgelopen twee jaar geproduceerd.
Pas nu wordt duidelijk wat de invloed is van deze overvloed aan data. Nieuwe diensten en analyses
rond Big Data zullen onze samenleving veranderen. Alleen organisaties die slim gebruik maken van
de bergen aan gegevens over het gebruik van producten en diensten zullen overleven. Helaas ligt de
nadruk bij Big Data-initiatieven vaak nog op het genereren en opslaan van enorme hoeveelheden
data in plaats van op de analyse ervan.
Chief Data Officer
Deze persoon is binnen het managementteam verantwoordelijk voor visie en beleid ten aanzien
van data. Voorbeeld van een vraag waar een CDO zich mee bezighoudt: gaan we externe data van
Inleiding
Database Concepts 19
de consument die onze producten gebruikt verzamelen en daarmee nieuwe diensten
ontwikkelen?
Data Scientist
Is de centrale spil voor een data-gedreven innovatie, deze nieuwe rol wordt ook wel omschreven
als het beroep van de toekomst “the sexiest job of the 21st century”. Dit sterk profiel
combineert heel wat skills: kennis algoritmen, statistiek, business-kennis,
programmeervaardigheden en communicatieve skills. Hij is de specialist in het analyseren van
grote hoeveelheden data en het toepassen van machine learning.
Big Data Practitioner
Heeft de juiste competenties om slimme Big Data oplossingen in praktijk te brengen. De data
practitioner past bestaande algoritmes toe op data maar ontwikkelt zelf geen nieuwe algoritmes.
1.9 Internet of Things - IoT
Internet of Things (IoT) verwijst naar een concept waarbij fysieke objecten (things) verbonden
worden met het internet en waarbij deze fysieke objecten zichzelf kunnen identificeren naar andere
objecten toe. IoT verwijst dus niet op de eerste plaats naar een nieuwe technologie. Het combineert
hoofdzakelijk bestaande technologieën zoals sensortechnologie, elektronica en netwerktechnologie.
De vernieuwing zit in de toegenomen verbondenheid via het internet. Internet of Things biedt vooral
kansen voor een sterkere integratie tussen de fysieke wereld en verschillende computersystemen.
Voorspellingen gaan er van uit dat er tegen 2020 meer dan 20 miljard IoT-apparaten in gebruik zijn,
van smart tv’s, koelkasten en auto’s tot slimme elektrische meters, grasmaairobots, vochtsensoren
en beveiligingscamera’s. Allemaal uitgerust met sensoren die gebeurtenissen capteren en alle
gegevens netjes doorsturen naar het internet.
Iedereen is het erover eens dat het Internet of Things aan een ontstuitbare opmars is begonnen. Het
genereert een tsunami aan data waaruit een massa informatie kan worden gepuurd. Op voorwaarde
dan wel dat er analytics op losgelaten worden en dit bij voorkeur real-time. IoT is één van de triggers
die heel veel big data genereren en data analytics mogelijk maken.
Dit opent meteen de weg naar een heleboel nieuwe scenario’s – denk maar aan de detailhandel waar
je in real-time boodschappen en promoties naar de klanten kan sturen op basis van ondermeer de
locatie van die klanten in de winkel.
Real-time analytics wordt mainstream, de kern van de onderneming.
Inleiding
Database Concepts 20
IoT architect
Een IoT Architect is in staat om innovatieve oplossingen uit te werken die IoT / Mobile-
apparaten en data samenvoegen.
De Powerpointpresentatie voor dit hoofdstuk vind je op Toledo.
Op Toledo vind je nog een aantal aanvullende artikels over Big Data.
Het relationele model
Database Concepts 21
Hoofdstuk 2: Het relationele model
Leerdoelen
De student kan de bouwstenen van relationele gegevensbanken benoemen en bij
een concreet voorbeeld aanduiden. Het gaat hier om begrippen als relatie/tabel,
tupel/record, cartesisch product, attribuut, kenmerken van attributen in een
relationele gegevensbank, domein van een attribuut, de betekenis van de null-
waarde.
De student kan de kandidaat-sleutels, de primaire sleutel en de verwijssleutel in een
relationele databank bepalen. Hij kan voor een eenvoudige casus de relaties
(tabellen), attributen en sleutels bepalen en het datastructuurdiagram tekenen.
De student kan de begrippen redundantie, entiteit-integriteit, referentiële integriteit
en domeinrestrictie uitleggen en toepassen op een concreet voorbeeld.
De student kent de operatie van de relationele algebra (selectie, projectie, join
(natuurlijke join, equi-join, auto-join, outer-join (left-right), unie, doorsnede, verschil
en kan dit toepassen om concrete casussen. Hij weet wat een view is en wat de
bedoeling is van een view.
Het is wel belangrijk de theorie te begrijpen, maar probeer vooral de oefeningen
vaak te doen tot je ze nagenoeg perfect kent. Kijk ook naar voorbeelden van
databanken die je in je omgeving ziet.
2.1 Inleiding
Het relationele model werd in 1970 geïntroduceerd door de Amerikaanse wiskundige E. F. Codd.
Dit model komt zo eenvoudig over dat het lange tijd is verguisd als zijnde niet-volwassen. Het
eenvoudig concept, waarbij gegevens weergegeven worden in een verzameling gelijksoortige
tabellen, is nochtans één van de belangrijkste voordelen van het relationele model t.o.v. het
hiërarchische- en het netwerkmodel (vooral vroeger vormden deze laatste modellen de basis voor
databanken .)
Bovendien heeft het relationele model een degelijke wiskundige basis en dat heeft een aantal
voordelen bij het ontwerpen en onderhouden van relationele gegevensbanken.
Sedert de introductie in 1970 is het model regelmatig herzien en aangepast.
Het relationele model vormt momenteel dan ook de grondslag van de grootste groep DBMS-
producten.
Het relationele model
Database Concepts 22
2.2 Bouwstenen van relationele gegevensbanken
2.2.1 Relaties
Het relationele model is gebaseerd op een tak van de wiskunde, met name de verzamelingenleer en
in het bijzonder de leer van de relaties.
Een verzameling is een ongeordende serie gelijksoortige elementen.
Een relatie op 2 of meer verzamelingen is een deelverzameling van de productverzameling van de
betreffende verzamelingen.
Stel de volgende twee verzamelingen met de opgesomde elementen.
KLEUR = {rood, geel, groen}
MAAT = {small, medium, large}
De productverzameling KLEUR x MAAT bestaat uit 9 elementen: {(rood,small),
(rood, medium), (rood, large), (geel, small), (geel, medium), (geel, large), (groen,
small), (groen, medium), (groen, large)}
Het aantal elementen v/d productverzameling is steeds het product van het aantal
elementen van de vermenigvuldigde verzamelingen, hier 3 x 3 = 9.
Men noemt een dergelijk product van verzamelingen ook een cartesisch product, het is natuurlijk
totaal verschillend van een rekenkundig product van getallen.
KLEUR MAAT
Productverzameling KLEUR x MAAT (cartesisch product)
rood geel
groen
small medium
large
(geel, large) RELATIE: ASSORTIMENT
(groen, small)
(geel, medium)
(rood, small)
{rood, small} {groen, medium}
{rood, medium} {groen, large}
{geel, small} {rood, large}
Het relationele model
Database Concepts 23
Een voorbeeld van een relatie op de twee verzamelingen zou kunnen zijn:
{(rood, medium), (rood,large), (geel, small), (geel, medium), (geel, large)}
Als mogelijke betekenis zou deze relatie het assortiment jassen kunnen voorstellen
welke een winkel verkoopt.
In een relationele databank wordt een relatie weergegeven d.m.v. een tabel.
De vijf elementen of tupels van de relatie ASSORTIMENT worden als volgt in
tabelvorm voorgesteld:
ASSORTIMENT
KLEUR MAAT
rood medium
rood large
geel small
geel medium
geel large
Elke rij uit de tabel representeert een tupel van de relatie en correspondeert bijgevolg met een
object uit de werkelijkheid.
2.2.2 Attributen
In de theorie van relationele gegevensbanken draait dus alles om relaties, en in een relationele
gegevensbank correspondeert met elke relatie een tabel, daardoor ziet een relationele
gegevensbank er voor een gebruiker uit als een verzameling tabellen.
Voorbeeld: een vereenvoudigde gegevensbank betreffende de
personeelsadministratie van de Vives-hogeschool zou kunnen bestaan uit volgende
2 tabellen.
Het relationele model
Database Concepts 24
PERSONEEL
Naam Voornaam Persnr Gebdat Gesl Salaris Manager Studgebnr
Acx Johan 6541 15-jan-1963 M 5222,62 7365 2
Desplenter Marc 4379 19-feb-1962 M 5202,88 7365 2
Ketels Bavo 8167 12-apr-1988 M 4602,88 7365 2
Vandenbussche Arne 7365 29-feb-1968 M 5478,94 9876 2
Haegeman Wim 1234 31-dec-1970 M 6718,40 7582 5
Hindryckx Joris 7582 01-jan-1960 M 8197,34 Null 1
Beyls Katrien 6741 Null V 4478,94 7365 2
De Langhe Johan 9876 15-apr-1969 M 6214,19 7582 2
Selis Noel 3456 20-aug-1968 M 6214,19 7582 9
Dekocker Veerle 6543 15-nov-1974 V 5966,30 7582 4
STUDIEGEBIED
Studgebnr Studgebnaam Studgebmanager Managerstartdate
5 IW&T 1234 01-sept-2013
1 VIVES 7582 01-sept-2012
9 ONDERWIJS 3456 01-jan-2015
2 HW&B 9876 01-sept-2012
4 SOCIAAL AGO 6543 01-sept-2014
Een kolom in een tabel herbergt gelijksoortige waarden welke attribuutwaarden (attributen)
genoemd worden, de kop van een kolom bevat een attribuutnaam.
In een relationele databank moeten alle attribuutwaarden atomair zijn. Elke cel bevat één waarde.
De waarden binnen een cel worden niet opgesplitst. Een cel kan geen lijst gegevens bevatten. Als een
cel bijvoorbeeld [01-02-03] bevat, dan heeft dat één betekenis.
Attributen zijn ook globaal in het relationele model, d.w.z. als een attribuutnaam voorkomt in twee
verschillende tabellen v/e relationele database, dan is de betekenis ervan in beide tabellen dezelfde.
Vb. attribuutnaam Studgebnr in de tabel Personeel en in de tabel Studiegebied.
Bovendien moeten attributen invariant zijn in de tijd, de waarden moeten in mindere of meerdere
mate tijdsonafhankelijk zijn. Vb. Sla niet de leeftijd van een persoon op in een databank, maar wel
Het relationele model
Database Concepts 25
zijn geboortedatum, de waarde van het attribuut geboortedatum is tijdsonafhankelijk en de leeftijd
kan altijd afgeleid worden.
Het aantal attributen in een tabel wordt de graad v/d tabel genoemd, het aantal tupels de
cardinaliteit. De cardinaliteit van een tabel kan in de loop van de tijd veranderen, de graad (meestal)
niet.
Samengevat heeft elke tabel in een relationele databank volgende eigenschappen:
• Elke kolom heeft een onderscheiden naam (attribuutnaam)
• De volgorde van de kolommen is niet van belang
• Een tabel bevat niet twee dezelfde rijen (een tabel is een verzameling van tupels en een verzameling kent per definitie geen duplicaten)
• De volgorde van de rijen is niet van belang (verzamelingen zijn immers niet geordend)
• Alle attribuutwaarden in de tabel zijn atomair
2.2.3 Domeinen
Met de term domein van een attribuut wordt de verzameling waarden bedoeld die een attribuut
mag aannemen.
In de databank van Vives is het domein van het attribuut Geslacht gelijk aan de verzameling {M, V}.
Het domein van het attribuut Studgebnr is een geheel getal van 1 tot 9 (grenzen incl.)
Voor het attribuut Naam gaan we uit van een domein dat bestaat uit alle alfanumerieke waarden van
maximaal 25 karakters. Dit betekent dat een naam een combinatie kan zijn van hoofdletters, kleine
letters, leestekens, cijfers, enz. met een maximum van 25 tekens. Vb. D’haese.
Het domein van een attribuut is een enkelvoudig domein als alle elementen van het betreffende
domein atomair zijn. In een relationele databank moet elk atribuut een enkelvoudig domein hebben.
Bijgevolg kan een attribuutwaarde nooit een samenstelling van waarden zijn; repeterende groepen
zijn niet toegestaan. In elke positie van een tabel van een relationele gegevensbank staat precies één
waarde.
Het registreren van het feit dat een personeelslid van Vives verbonden is aan twee
studiegebieden van de hogeschool kan onmogelijk door in het attribuut Studgebnr
van de tabel Personeel twee studiegebiednummers op te nemen
.
2.2.4 Tupels
De gegevens in een rij van een tabel vormen samen het beeld van een object uit de werkelijkheid.
Een rij is dus een verzameling bij elkaar horende attribuutwaarden, een dergelijke verzameling
noemt men een tupel (of rij).
Een voorbeeld van een tupel uit de tabel Studiegebied is: (2,HW&B,9876,01-sept-2012).
Het relationele model
Database Concepts 26
Gezien de attribuutwaarden geen betekenis hebben zonder kennis van de bijpassende attributen
vermelden we ook de verzameling attribuutnamen: (Studgebnr, Studgebnaam, Studgebmanager,
Managerstartdate), dit wordt het tupelschema (relatieschema) genoemd.
2.2.5 Nulwaarden (nulls)
Nulwaarden vormen een belangrijke en in bepaalde situaties vrij moeilijke problematiek in de
gegevensbanktheorie.
We geven een attribuut een NULL-waarde als:
• Een attribuutwaarde niet van toepassing is
• Een attribuutwaarde voor het moment nog onbekend is.
Een voorbeeld van de eerste situatie is de nulwaarde bij het attribuut manager van
de algemeen directeur van Vives dhr. Hindryckx. Een illustratie van het tweede geval
is het ontbreken van de geboortedatum van mevr. Beyls.
Belangrijk is dat een NULL-waarde niet verward wordt met het getal 0, dat is namelijk wel degelijk
een waarde. Ook bij alfanumerieke attributen is een NULL-waarde formeel totaal verschillend t.o.v.
leeg stuk tekst.
2.3 Sleutels
2.3.1 Kandidaatsleutels
De tupels van een tabel kunnen op een unieke manier van elkaar onderscheiden worden. Dit
betekent dat ze op één of andere manier van elkaar moeten verschillen, via één attribuut of een
groep attribuut die voor elk tupel een andere waarde heeft. De attributenverzameling die voor elk
tupel verschillend is, noemen we de kandidaatsleutel of sleutel.
De attributenverzameling bestaat uit één of meer attributen waarin geen NULL-waarden voorkomen,
bovendien mag de attributenverzameling geen overtollige attributen bevatten.
Een kandidaatsleutel heeft de eigenschap van minimaliteit.
Voor de tabel Personeel is het attribuut Naam geen kandidaatsleutel gezien meerdere
personeelsleden dezelfde naam kunnen hebben. De combinatie Naam + Persnr is geen
kandidaatsleutel omdat Naam een overtollig attribuut blijkt. De enige kandidaatsleutel die hier
overblijft is Persnr.
In de veronderstelling dat in de tabel Personeel ook het attribuut Rijksregisternummer zou bestaan
zijn er twee kandidaatsleutels: Persnr en Rijksregisternummer.
Vermits elke tupel uniek is, bestaat er altijd minstens één kandidaatsleutel.
Het relationele model
Database Concepts 27
Als een sleutel uit één attribuut bestaat noemt men die sleutel een enkelvoudige sleutel. Een sleutel
die uit een combinatie van attributen bestaat, heet een samengestelde sleutel.
2.3.2 Primaire sleutel (Primary Key)
De sleutel die door de gegevensbankontwerper daadwerkelijk gekozen wordt (uit de
kandidaatsleutels) voor tupelidentificatie wordt de primaire sleutel genoemd.
Elke waardencombinatie van een primaire sleutel voor een tabel verwijst naar precies één tupel van
die tabel. Gezien we een tupel in een tabel alleen kunnen herkennen als alle attribuutwaarden van
de sleutel bekend zijn mag een waardencombinatie van een primaire sleutel in een tabel geen
nulwaarden bevatten.
Een kandidaatsleutel die niet verkozen is tot primaire sleutel wordt een alternatieve sleutel
(alternate key) genoemd.
Opdracht/Oefening: bepaal de primaire sleutel van de tabellen PERSONEEL en
STUDIEGEBIED. Bepaal ook eventuele alternatieve sleutels.
2.3.3 Verwijssleutel (Foreign Key)
Meestal houden de tabellen in een relationele gegevensbank verband met elkaar. Het komt bvb.
voor dat een attributenverzameling voorkomt in twee relaties en dat de attributenverzameling de
primaire sleutel is voor één van de relaties, maar niet voor beide.
Dan is er sprake van een verwijssleutel (foreign key).
Het attribuut Studgebnr is de primaire sleutel in de tabel Studiegebied, Studgebnr komt echter ook
voor in de tabel Personeel en is geen primaire sleutel in deze tabel. In de tabel Personeel vormt het
attribuut Studgebnr een verwijssleutel, dit omdat het de sleutel is van een andere tabel en naar die
tabel verwijst.
Verwijssleutels verwijzen van één tabel naar één of meerdere andere tabellen (soms naar dezelfde
tabel). Op die manier zorgen ze voor samenhang tussen de verschillende tabellen van een
gegevensbank
De attribuutwaardencombinatie van een verwijssleutel mag niet voor een gedeelte nulwaarden
bevatten, de attribuutwaardencombinatie van een verwijssleutel mag wel volledig uit nulwaarden
bestaan. Als dit laatste het geval is, verwijst de attribuutwaardencombinatie van de verwijssleutel
niet naar een andere tupel.
Zo zou in de tabel Studiegebied een studiegebied kunnen toegevoegd worden zonder aanduiding van
de manager van dat studiegebied.
Het relationele model
Database Concepts 28
Opdracht/Oefening: bepaal alle foreign keys van de tabellen PERSONEEL en
STUDIEGEBIED. Hou ook rekening met recursieve relaties.
2.3.4 Datastructuurdiagram/ERD
De tabellen en de relaties tussen de verschillende tabellen worden visueel weergegeven in een
datastructuurdiagram of ERD (entiteit-relatiediagram). Een ERD toont de entiteiten of objecten en
hun relaties. Een voorbeeld van een entiteit is de entiteit KLANT. KLANT heeft dan een relatie met
een andere entiteit, een BESTELLING. Een klant heeft nul, een of meer bestellingen en een bestelling
werd geplaatst door één klant. Op technisch databaseniveau spreken we dan over verbanden tussen
tabellen via de foreign key.
Er zijn diverse mogelijke voorstellingswijzen van een ERD. Een bekende notatieswijze is de Chen-
notaties. Wij gebruiken echter de kraaiepootnotaties of Crow’s foot notation. Deze naam heeft te
maken met de notatieswijze van relaties zoals hieronder zal blijken.
We kunnen een ERD ontwerpen op diverse niveaus:
• Op het conceptuele niveau ontwerpen we de gegevensstructuur nog op een vrij abstract
niveau waarbij we de informatiebehoeften van onze klant en de relaties tussen entiteiten in
klaart brengen zonder rekening te houden met de beperkingen van een relationele database.
Op dat niveau zullen we bijvoorbeeld veel-op-veel-relaties toelaten en zullen we de foreign
keys en primary keys nog niet definiëren.
• Op het logische niveau zullen we wel elke entiteit/tabel en elke relatie in kaart brengen en de
attributen duidelijk definiëren met hun respectievelijke logische datatypes (tekst, geheel
getal, kommagetal, booleaanse waarde, media-object) zonder er specifiek rekening mee te
houden in welke technologie we onze relationele database zullen definiëren. We zullen dus
wel de primaire sleutels, alternatieve sleutels, verwijssleutels aanduiden, maar we zullen er
ons nog niet om bekommeren of het systeem een kommagetal definieert als numeric, float
of een ander datatype specifiek voor deze technologie.
• Op het fysieke niveau houden we rekening met de RDBMS die we zullen hanteren. Het model
bevat alle details opdat de database automatisch gegenereerd kan worden.
Wij zullen in deze cursus op ERD’s op het logische niveau tekenen.
De relatie tussen twee entiteiten wordt soms aangeduid met de term ‘ouder/kind-associatie’. De
tabel met de verwijssleutel heet dan de kindtabel, de tabel waarnaar verwezen wordt heet de
oudertabel.
Datastructuurdiagram van de Vives-databank:
Het relationele model
Database Concepts 29
Personeel Studiegebiedheeft als hoofdis verbonden aan
heeft als chef
PERSONEEL(Persnr, Naam,Voornaam, Gebdat, Gesl, Salaris, Manager(FK), Studgebnr(FK))
STUDIEGEBIED(Studgebnr, Studgebnaam, Studgebmanager(FK), Managerstartdate)
Het datastructuurdiagram geeft, samen met een opsomming van de attributen per tabel, een
duidelijk beeld van de structuur van een database.
De naam van de relatie tussen tabellen komt tot stand door, vanuit het standpunt van de tabel met
de foreign key, de betekenis te verwoorden van de foreign key. De tabel die de foreign key bevat,
vormt dus het onderwerp van de te maken zinsconstructie.
• een Personeelslid ‘is verbonden aan’ een Studiegebied (FK: Studgebnr)
• een Studiegebied ‘heeft als hoofd’ een Personeelslid (FK: Studgebmanager)
• een Personeelslid ‘heeft als chef’ een (ander) Personeelslid (FK: Manager)
Als alternatief van het datastructuurdiagram en de opsomming van de attributen per tabel kunnen de attributen ook opgenomen worden in het datastructuurdiagram.
Voor wat de relatie ‘verbonden aan’ betreft, vormt Studiegebied de oudertabel en
Personeel de kindtabel (bevat de foreign key).
Er wordt expliciet aangegeven dat er:
• bij één rij van Studiegebied, nul of meer Personeelrijen horen.
• bij één rij van Personeel, precies één Studiegebiedrij hoort.
Deze zogenaamde cardinaliteiten moet men in het schema steeds aflezen ‘aan de andere kant’ van
de verbindingslijn, lezend van de ene tabel naar de andere.
PERSONEEL
Naam
Voornaam
Persnr
Gesl
Salaris
Manager (FK)
StudgebnrFK)
STUDIEGEBIED
Studgebnr
Studgebnaam
Studgebmanager (FK)
Managerstardateheeft als hoofd
is verbonden aan
heeft als chef
Het relationele model
Database Concepts 30
Personeel Studiegebiedis verbonden aan
Bij één Personeel-rij hoort precies één Studiegebied-rij.
Bij één Studiegebied-rij horen nul of meer Personeel-rijen.
Dit betekent dat een personeelslid steeds moet verbonden zijn aan een
studiegebied, m.a.w. de foreign key Studgebnr in Personeel moet verplicht ingevuld
worden!
De realisatie hiervan gebeurt met een extra beperkende voorwaarde op de foreign
key (not null constraint, zie later).
Bij de relatie ‘heeft als hoofd’ vormt Personeel de oudertabel en Studiegebied de
kindtabel (bevat de foreign key).
• Bij één rij van Personeel horen nul of meer Studiegebied-rijen
• Bij één rij van Studiegebied hoort nul of één Personeel-rij
Personeel Studiegebiedheeft als hoofd
Dit betekent dat een studiegebied kan toegevoegd worden zonder aanduiding van de
studiegebiedmanager, m.a.w. de foreign key Studgebmanager mag null zijn. Gezien, volgens de
relationele theorie, een foreign key steeds (volledig) null mag zijn (zie paragraaf 2.3.3) impliceert dit
geen extra voorwaarde op deze foreign key.
Men spreekt in dit verband ook van een optionele (niet-verplichte) relatie.
De relatie ‘heeft als chef’ is in die zin speciaal dat de verwijzing naar de tabel zelf gebeurt, men
noemt dit een recursieve relatie.
• Bij één rij van Personeel hoort geen of 1 rij van Personeel die de chef aanduidt
• Bij één rij van Personeel horen 0 of meer rijen van Personeel die de ondergeschikten aanduiden.
Samenvattend worden volgende cardinaliteitsnotaties in een datastructuurdiagram gebruikt:
Het relationele model
Database Concepts 31
0 of 1
precies 1
0 of meer
1 of meer
Merken we nog op dat een ‘één-of-meer’-relatie zelden voorkomt en bovendien niet direct
afdwingbaar is in een relationele database. Vermits dit ook zou aanleiding geven tot weinig
flexibiliteit zullen we verder ‘éé-of-meer’ niet gebruiken.
2.4 Integriteit
De gegevens van een gegevensbank moeten steeds consistent (met elkaar in overeenstemming) zijn.
Het mag bvb. niet zo zijn dat een gegevensbank twee tupels bevat, waarvan de ene aangeeft dat een
persoon gedomicilieerd is in Kortrijk en de andere dat dezelfde persoon gedomicilieerd is in Knokke.
De grootste bedreiging voor de consistentie van een informatiesysteem vormt de redundantie
(overtolligheid). Er moet ten allen tijde naar gestreefd worden dat een bepaald gegeven (vb. adres
v/e persoon) maar éénmalig gestockeerd wordt. Om dat te bereiken zullen we ernaar streven een
genormaliseerde database te ontwerpen. Dat wordt in het volgende hoofdstuk behandeld.
Ook het opslaan van zogenaamde afleidbare gegevens is een vorm van redundantie en dient
vermeden te worden. Indien een bedrag (excl. BTW) en het BTW-percentage opgeslagen worden is
het overbodig het bedrag inclusief BTW op te slaan. Soms wordt echter selectief besloten tot het
opslaan van redundante gegevens; vooral in gevallen waar snelheid (performance) cruciaal is, en
waarbij het steeds opnieuw berekenen of afleiden van de gewenste gegevens teveel tijd zou kosten.
Bovendien moeten de gegevens correct zijn. We willen dus dat de gegevens in een gegevensbank
volledig en correct zijn, ofwel: dat de integriteit van een gegevensbank gegarandeerd is.
Teneinde de integriteit van een gegevensbank zo goed als mogelijk te garanderen worden
integriteitsregels (constraints) opgesteld.
2.4.1 Entiteit-integriteit (Entity integrity)
In een primaire sleutel van een tabel mogen geen attributen met nulwaarden voorkomen.
Elke tupel moet uniek worden gëidentificeerd door een waardencombinatie van de primaire sleutel.
Het toestaan van een null-waarde in de primaire sleutel zou bijgevolg een contradictie betekenen
gezien een null-waarde de afwezigheid van een waarde voorstelt.
Per definitie is een primaire sleutel ook uniek.
