1. 1
Ontwerp van data warehouses:
opslag van data en integratie van constraints
Ferry Kemperman
Huissen / Nijmegen
Februari – December 2000
Afstudeerscriptie nr. 475
Bedrijfsgerichte Informatica
Faculteit der Natuurwetenschappen, Wiskunde en Informatica
Katholieke Universiteit Nijmegen
3. 3
VOORWOORD.............................................................................................................................................. 5
1 CONTEXTBEPALING ............................................................................................................................... 6
1.1 WAT IS EEN DATA WAREHOUSE EN WAT KUN JE ER MEE DOEN? .................................................................. 6
1.2 DE DATA WAREHOUSE ARCHITECTUUR ..................................................................................................... 8
1.2.1 De operationele systemen ................................................................................................................. 9
1.2.2 De extractietools: Wrapper en Monitor............................................................................................. 9
1.2.3 De Integrator.................................................................................................................................. 10
1.2.4 De data warehouse gezien als database .......................................................................................... 10
1.2.5 De metadata................................................................................................................................... 10
1.2.6 De data mart .................................................................................................................................. 10
1.2.7 De multidimensionale database....................................................................................................... 11
1.2.8 De Molap/Rolap server................................................................................................................... 11
1.2.9 De front end tools of OLAP tools .................................................................................................... 11
1.3 PROBLEMATIEK OMTRENT DE OPSLAG VAN DATA EN INTEGRATIE VAN CONSTRAINTS ............................... 11
1.3.1 Iets over data opslag in data warehouses ........................................................................................ 12
2 CONSTRAINTS IN EEN DATA WAREHOUSE, EEN VERKENNING VIA PSM ............................... 14
2.1 KORTE INTRODUCTIE VAN HET DIMENSIONALE MODEL ............................................................................ 14
2.1.1 Een case uitwerking........................................................................................................................ 14
2.1.1.1 Introductie van de case ..............................................................................................................................14
2.1.1.2 De case wordt in het dimensionale model gegoten.....................................................................................15
2.1.1.3 Case invulling van het geschetste model van Down Under..........................................................................17
2.2 CONSTRAINTS IN HET DIMENSIONALE MODEL, EEN BENADERING VIA HET RELATIONELE MODEL................ 19
2.2.1 Introductie van PSM....................................................................................................................... 20
2.2.2 Populaties in PSM.......................................................................................................................... 23
2.2.2.1 Universe of instances gedefinieerd.............................................................................................................23
2.2.2.2 Populaties gedefinieerd..............................................................................................................................24
2.2.3 Constraints in PSM......................................................................................................................... 27
2.2.3.1 Relationele algebra....................................................................................................................................27
2.2.3.1.1 Schema gedefinieerd ..........................................................................................................................28
2.2.3.1.2 Val gedefinieerd.................................................................................................................................28
2.2.3.1.3 Meer relationele operaties...................................................................................................................30
2.2.3.2 Constraints onder de loep ..........................................................................................................................33
2.2.3.2.1 Total role constraint ...........................................................................................................................33
2.2.3.2.2 Uniqueness constraint.........................................................................................................................36
2.2.3.2.2.1 Uniqueness constraint applied to one facttype ..............................................................................37
2.2.3.2.2.2 Uniqueness constraint applied to more facttypes...........................................................................39
2.2.3.2.2.3 Uniqueness constraint applied to objectification ...........................................................................42
2.2.3.2.3 Occurrence frequency constraint.........................................................................................................49
2.2.3.2.4 Set constraints....................................................................................................................................50
2.2.3.2.5 Enumeration constraint.......................................................................................................................50
2.2.3.2.6 Power type constraints........................................................................................................................50
2.2.3.2.7 Specialisation constraints....................................................................................................................51
2.2.3.2.8 Subtype defining rules........................................................................................................................51
2.2.3.2.9 Schema type constraints .....................................................................................................................52
2.2.3.2.10 Constraint definities .........................................................................................................................52
3 HET DIMENSIONALE MODEL UITGEDIEPT..................................................................................... 53
3.1 EEN VERDERE VERKENNING VAN CONSTRAINTS IN HET DIMENSIONALE MODEL......................................... 53
3.2 FUNCTIES VAN DE CONSTRAINTS IN HET DIMENSIONALE MODEL............................................................... 54
3.3 EEN VERKENNING VAN DE CONSTRAINTS IN DE DATA CUBE VIA EEN VOORBEELD...................................... 54
3.3.1 De data cube geanalyseerd ............................................................................................................. 54
3.3.1.1 Perspectieven van dimensies: de rotate-functie...........................................................................................56
3.3.1.2 Aggregatie van data: Drill Up/Down en Roll Up ........................................................................................56
3.3.1.3 Begrippenkader.........................................................................................................................................57
3.3.2 De presentatie van gegevens in data cube jargon ............................................................................ 58
3.3.2.1 Enkelvoudige cel.......................................................................................................................................58
3.3.2.2 Tweedimensionale slice.............................................................................................................................58
3.3.2.3 Multidimensionale sub cube ......................................................................................................................59
3.4 DE CASE DOWN UNDER IN HET DATA CUB E CONCEPT .............................................................................. 60
3.4.1 De intra-cube constraints................................................................................................................ 62
3.4.2 De inter-cube constraints............................................................................................................... 63
4. 4
3.5 CONSTRAINTS BENADERD VANUIT HET DIMENSIONALE MODEL VIA STAR JOIN SCHEMA............................. 64
3.6 VOORBEELD VAN HET GEBRUIK VAN DE JOIN EN APPLICATION CONSTRAINT ............................................. 64
3.6.1 De dimensie geografische ligging en de application constraint........................................................ 66
3.6.2 SQL en de join constraint................................................................................................................ 67
4 RELATIONEEL EN DIMENSIONAAL: EEN VERGELIJKEND ONDERZOEK MET BETREKKING
TOT CONSTRAINTS EN MEER................................................................................................................ 69
4.1 INTRODUCTIE VAN NESTED DATA CUBES ............................................................................................... 69
4.2 NESTED DATA CUBES OPGEBOUWD ........................................................................................................ 69
4.3 NESTED DATA CUBES: EEN EERSTE VERKENNING VIA DOWN UNDER ....................................................... 71
4.4 KLASSIEKE DATASTRUCTUREN IN NDC .................................................................................................. 72
4.5 NDC ALGEBRA...................................................................................................................................... 73
4.5.1 De bagify operator ......................................................................................................................... 73
4.5.2 De extend operator ......................................................................................................................... 74
4.5.3 De nest operator............................................................................................................................. 75
4.5.4 De unnest operator......................................................................................................................... 77
4.5.5 De duplicate operator..................................................................................................................... 77
4.5.6 De select operator .......................................................................................................................... 78
4.5.7 De rename operator........................................................................................................................ 79
4.5.8 De aggregate operator.................................................................................................................... 79
4.6 MODELLERING VAN RELATIONELE OPERATOREN IN HET NDC MODEL...................................................... 80
4.7 NDC ALGEBRA TOEPASBAAR OP ELKE DIEPTE IN EEN NDC ..................................................................... 84
4.8 EEN INFORMELE MAPPING VAN RELATIONEEL OP DIMENSIONAAL EN VICE VERSA...................................... 84
4.9 DOWN UNDER IN PSM: EEN VERGELIJKING MET HET NDC MODEL .......................................................... 86
4.10 OPSLAG VAN AGGREGATIES IN EEN DATA WAREHOUSE .......................................................................... 93
4.11 MULTIDIMENSIONALE BENADERING VAN AGGREGATIES IN PSM GEMODELLEERD .................................. 93
4.12 EEN AANZET TOT DE BESCHRIJVING VAN DE SEMANTIEK VAN CONSTRAINTS IN HET DIMENSIONALE MODEL
................................................................................................................................................................... 97
4.13 EEN INTERMEZZO OVER VIEW MAINTENANCE ...................................................................................... 100
5 CONCLUSIES EN VERDER ONDERZOEK ........................................................................................ 102
5.1 SAMENVATTING................................................................................................................................... 102
5.2 ALGEMENE CONCLUSIES ...................................................................................................................... 103
5.3 VERDER ONDERZOEK ........................................................................................................................... 104
5.4 TERUGBLIK ......................................................................................................................................... 105
BIBLIOGRAFIE ........................................................................................................................................ 106
BRONVERMELDING FIGUREN EN TABELLEN................................................................................. 108
INDEX ........................................................................................................................................................ 109
FIGURENINDEX....................................................................................................................................... 111
TABELLENINDEX.................................................................................................................................... 111
5. 5
Voorwoord
Voor u ligt mijn afstudeerscriptie “Ontwerp van data warehouses: opslag van data en integratie van
constraints”, de kroon op mijn studie Bedrijfsgerichte Informatica. Deze scriptie heeft mij veel tijd en
moeite gekost, evenals mijn studie. Moeizame periodes wisselden zich tijdens mijn studietijd af met
momenten van goede motivatie. Sommige vakken vond ik zeer interessant (vooral die uit de
specialisatierichting en de leerzame GiP-reeks) en gingen me dan ook redelijk goed af, maar andere
bezorgden me hoofdbrekens. Met name P4, W4 en W6 vielen me erg zwaar en hebben me de nodige
moeite gekost te halen.
Na 8 jaar middelbare school en 6½ jaar universiteit vind ik het mooi geweest. Ik wil iedereen
bedanken die mij gedurende mijn gehele studietijd en scriptie heeft geholpen, op welke wijze dan ook.
Mensen die ik in dit verband bij name wil noemen zijn: mijn ouders en mijn broer Mark, mijn goede
vrienden Ernest Neijenhuis en Jaap Penders met wie ik zeer veel heb samengewerkt in het verleden,
mijn goede vriend en studiegenoot Dennis Noy voor een perfecte samenwerking gedurende de gehele
studie aan de KUN. We vulden elkaar perfect aan. Verder mijn afstudeerbegeleider Patrick van
Bommel voor de goede begeleiding en de (bijna) wekelijkse nuttige bijeenkomsten. Verder heb ik
gedurende mijn studie prettig samengewerkt met mijn goede vriend Sander van Woerkom en Richard
Arts. Zij hebben mij geholpen bij vakken die me moeilijk vielen.
Zonder hen was ik hier nooit gekomen!
Bedankt allemaal!
Ferry Kemperman
22 december 2000
Een tweetal opmerkingen vooraf: Dit werk is in de wij-vorm geschreven. Ik heb hier bewust voor
gekozen. De definitie van Val wordt in de literatuur beschreven met een ruimtelijk haakje. Door
printerproblemen is in dit werk het een gewoon haakje ( [ en ] ) geworden.
Informatie over de auteur:
Ferry Remon Kemperman werd op 16 januari 1974 geboren in Huissen. Na de HAVO (1986 -1991)
aan het Nederrijn College in Arnhem vervolgde hij op dezelfde school met het VWO (1991-1994). In
september 1994 begon hij met de opleiding Informatica aan de Katholieke Universiteit Nijmegen. In
de periode december 2000 rondde hij in de specialisatierichting Bedrijfsgerichte Informatica deze
studie af met het voor u liggende werk. Het afstudeerpraatje werd gehouden op 12 januari 2001 om
14.00 uur in colloquiumkamer A2041.
6. 6
They say it's always the same, two steps forward one step back
Whatever he arranges, we must do the best we can
Your pain is mine, my blood is yours, can you hear me, I'm calling you
You have the power over me, I'm rendered helpless, you've got me on my knees
You have the power over me, nothing is certain, I wait for recovery
Power Over Me, Mr.Mister
1 Contextbepaling
In dit eerste hoofdstuk zal een kader worden geschept voor de probleemstelling die wordt behandeld in
deze scriptie. Als eerste zal worden ingegaan op de vraag wat een data warehouse nu precies inhoudt
en wat je ermee kan doen. Vervolgens zal een introductie worden gegeven over hoe een data
warehouse technisch gezien eruit ziet en wat voor specifieke problemen er kunnen optreden bij het
opzetten van zo’n data warehouse. Als laatste zal dit hoofdstuk worden afgesloten met een
uiteenzetting naar de specifieke probleemstelling van deze scriptie, namelijk de opslag van data in data
warehouses voor OLAP-toepassingen en de integratie van constraints. Hier zullen ook de
verschillende problemen aan bod komen.
1.1 Wat is een data warehouse en wat kun je er mee doen?
De term data warehouse komt al geruime tijd voor in wetenschappelijke en technische vakbladen,
maar ook in magazines en tijdschriften van specifieke maatschappelijke en commerciële sectoren. Een
voorbeeld van zo’n sector is het bankwezen. Hieronder zien we een artikel dat door NCR banken uit
Noorwegen op het WWW is gezet als persbericht [WWW03]. In dit persbericht wordt een mooie
toepassing geschetst van een data warehouse, in het Nederlands ook wel gegevenspakhuis genoemd.
De toekomst volgens NCR en Sparebanken NOR
Amsterdam, 7 augustus 1998 - Volgens NCR Corporation en Sparebanken NOR
(Noorwegen) wordt bankieren gemakkelijker, sneller en leuker voor de consument,
leidt het tot minder kosten voor de banken en tot minder papierwerk voor iedereen.
De twee bedrijven hebben tezamen het bankfiliaal van morgen bedacht, ontworpen
en ingevoerd.
Zodra een klant een filiaal van Sparebanken NOR binnenloopt, voert hij zijn
bankcard in. Met een speciaal genummerd kaartje wordt hij geïdentificeerd door het
gegevenspakhuis, dat een bericht terugstuurt met de klantgegevens. Een
videoscherm boven de baliemedewerker toont op de klant gerichte advertenties en
de baliemedewerker zelf heeft alle relevante gegevens onmiddellijk bij de hand,
zoals welke folders naar deze klant zijn gestuurd en welke diensten verder kunnen
worden aangeboden. Klanten bekrachtigen hun opdrachten elektronisch, zodat
geen papier nodig is. Dit concept maakt ook de omvangrijke procedureboeken en
de dagelijkse papieren administratie van het bankkantoor overbodig.
Iedere week worden vijf filialen van Sparebanken NOR herbouwd en uitgerust, en
worden de medewerkers omgeschoold. Inmiddels zijn meer dan 140 nieuwe filialen
omgevormd. Volgens plan zullen medio 1999 alle 350 kantoren in het netwerk van
Sparebanken NOR en zijn partners volgens dit concept zijn aangepast.
In dit artikel wordt de indruk gewekt dat de data warehouse een soort grote database is met een grote
mate van flexibiliteit m.b.t. tot het vinden van informatie en verbanden in die informatie. Dit laatste is
onder meer te halen uit de zin “Een videoscherm boven de baliemedewerker toont op de klant gerichte
7. 7
advertenties en de baliemedewerker zelf heeft alle relevante gegevens onmiddellijk bij de hand”. Nu er
een gedachte is gecreëerd omtrent het begrip data warehouse kunnen we een definitie aangeven op een
hoog abstractieniveau.
“Een data warehouse is een concept dat is opgebouwd uit hard- en software elementen dat het
mogelijk maakt om zeer grote hoeveelheden gegevens te analyseren om zodoende managers in
staat te stellen om betere bedrijfsbeslissingen te nemen op strategisch en tactisch niveau”
Een kanttekening die hier geplaatst dient te worden is het volgende. Een data warehouse is op vele
abstractieniveaus te definiëren, van zeer abstracte naar technisch zeer gedetailleerde definities. Tevens
is er een groot aantal definities in omloop, waarbij een ieder zijn eigen interpretatie aan dit begrip
geeft. In dit document zullen we de bovenstaande definitie aanhouden wanneer we praten op het
niveau van het gebruik van data warehouses (dus de meer algemene definitie) en de definitie die wordt
gegeven in de volgende paragraaf in het geval er op technisch niveau over data warehouses wordt
gesproken. Dan is er ook nog een derde interpretatie die in dit document voorkomt, namelijk de data
warehouse beschouwende als een database. Deze interpretatie zal uitsluitend voorkomen bij het
gebruik in figuren en bespreking van deze figuren.
Wanneer we de definitie onder de loep nemen, vallen gelijk aan aantal zaken op. Een data warehouse
is een concept en geen nieuwe technologie. Een data warehouse moet men dus beschouwen als een
vernieuwd inzicht opgebouwd uit al reeds bekende zaken. Een van die zaken zijn de zogenaamde
legacy-systemen, bestaande uit een informatiesysteem en een database die er zijn voor operationele
doeleinden.
Een intuïtieve definitie die men van een data warehouse zou kunnen geven is een grote verzameling
gegevens (een soort super database) die geanalyseerd kan worden om bepaalde verbanden en trends te
vinden om zo een betere bedrijfsvoering er op na te kunnen houden.
Vragen die hierbij rijzen zijn natuurlijk:
Hoe kom je aan zo’n grote verzameling gegevens?
Welke gegevens komen er in die super database en op welke wijze?
Welke eisen dienen er gesteld te worden aan die gegevens?
Welke analyses moeten er met de gegevens gemaakt kunnen worden?
Hoe pak je die analyses aan?
Etcetera
Een antwoord op enkele van deze vragen zal in de loop van deze scriptie worden gegeven. Een andere
vraag die gesteld kan worden is de vraag naar de noodzaak van zo’n data warehouse. Zijn operationele
systemen (ook wel OLTP of legacy-systeem genoemd) niet in staat de gevraagde analyses te plegen?
Een ontkennend antwoord moet hier worden gegeven. Een dergelijke analyse vereist een aantal
belangrijke aspecten van het systeem en de gegevens.
Operationele systemen konden dit niet aan vanwege [Hobo97]:
• Gebrek aan historische data
• Inconsistentie en verandering van gegevens
• Gegevens die nodig zijn voor een analyse zitten vaak in verschillende operationele systemen
• Query uitvoeringen duren extreem lang (zeer complexe query’s, slechte retrievaltijd)
De belangrijke verschillen tussen een operationeel systeem en een data warehouse kunnen hieruit
direct worden afgeleid (gedeeltelijk afgeleid uit [Hobo97]).
• Tijdsfactor
In een data warehouse is het van groot belang dat de historie van gegevens wordt vastgehouden.
Er wordt dus een historie opgeslagen van de gegevens. Er worden geen updates van de gegevens
gemaakt en de gegevens zijn in principe read-only in een data warehouse. In een operationeel
systeem is een historie niet aanwezig. De tijdsdimensie van gegevens is een zeer belangrijk aspect
bij een data warehouse.
8. 8
• Onderwerp georiënteerde kijk
In een data warehouse gaat het erom de eindgebruiker als referentiepunt te zien in het presenteren
van de gegevens. In een operationeel systeem zijn de gegevens vaak georganiseerd naar het
perspectief van een applicatie.
• Grote hoeveelheid gegevens
Bij een data warehouse gaat het om beheer van zeer grote aantallen gegevens. Dit komt mede door
het feit dat er historische gegevens dienen te worden opgeslagen (in principe wordt er in een data
warehouse niets verwijderd vanuit historisch perspectief). In tegenstelling tot een operationeel
systeem, waarbij vaak historische gegevens worden geüpdate, is het hier dus van essentieel belang
deze juist te bewaren.
• Samenvattingen en geaggregeerde gegevens
In operationele databases is er vaak een zeer grote mate van detail aanwezig in de gegevens. Een
data warehouse zal samenvattingen en aggregatie van gegevens moeten toepassen om tot goed
gebruik te komen van de data warehouse. Dit is een noodzaak om informatie te kunnen extraheren
die voor beslissingsondersteunde doeleinden worden gebruikt.
• Integratie en associatie van gegevens uit verschillende bronnen
De data warehouse “voedt” zichzelf via vaak al bestaande (operationele) systemen en
verschillende applicaties. Deze verschillende bronnen gebruiken vaak verschillende manieren
waarop hun gegevens worden opgeslagen en worden beheerd. Voor opname in de data warehouse
dienen de gegevens consistent te zijn en moeten bepaalde zaken geconverteerd worden. Dit alles
om een bruikbare data warehouse te verkrijgen.
• Multidimensionaliteit van gegevens
Gegevens die in een data warehouse worden opgeslagen kunnen vanuit meerdere dimensies
worden opgeslagen. Dit om er voor te zorgen dat de gegevens vanuit elk gewenst perspectief
bekeken en geraadpleegd kunnen worden. Een toepassing hiervan is de presentatie van gegevens
in een kubus i.p.v. de traditionele 2-dimensionale tabellen.
Nu we een beeld hebben gevormd van een data warehouse en zijn doelen kunnen we in de volgende
paragraaf doorgaan met het conceptidee achter een data warehouse. We doen dit door aan de hand van
een meer technisch perspectief naar een data warehouse te kijken.
1.2 De data warehouse architectuur
Het begrip data warehouses passeert vaak de revue in de vakliteratuur over databases. In deze
literatuur worden allerlei verschillende technische definities gebruikt voor een data warehouse.
Om een goed kader te geven aan het begrip data warehouse in technische zin is het noodzakelijk in te
zien dat we een data warehouse moeten beschouwen als een architectuur van deels al reeds bestaande
systemen en technieken. Een data warehouse is eigenlijk een architectuur voor het genereren van
informatie die kan ondersteunen bij bedrijfsbeslissingen op het tactisch en strategisch
managementniveau.
Nu zullen we een bespreking geven van de algemene architectuur van een data warehouse. Wanneer
het technische kader rond een data warehouse is geschept, kunnen we ons toespitsen op de
problematiek omtrent gegevensopslag in de volgende paragraaf.
In onderstaande figuur (figuur 1) zien we een algemene structuur van een data warehouse. Het figuur
is ontleend aan [SMKK98].
9. 9
Figuur 1: De data warehouse architectuur
We zullen de verschillende onderdelen van de architectuur afzonderlijk bespreken in de nu volgende
paragrafen. Dit draagt bij aan het creëren van een goed inzicht in de architectuur van een data
warehouse, hetgeen weer belangrijk is als fundament voor het inzicht in de opslag van data in een data
warehouse.
1.2.1 De operationele systemen
Onder operationele systemen worden die systemen verstaan die in een bedrijf als dagelijks gebruik
dienen. Deze systemen zorgen voor de dagelijkse informatievoorziening van het bedrijf en bevatten
gegevens van alledag. Een operationeel systeem is vaak een eenvoudige database met relatief weinig
(complexe) informatie en een onderliggend informatiesysteem. We hebben reeds gezien wat de
kenmerken van dergelijke systemen zijn (paragraaf 1.1). Een belangrijk kenmerk van operationele
systemen is het ontbreken van een historie. De gegevens in een operationeel systeem zijn bedoeld voor
dag tot dag beslissingen. [Hobo97] spreekt over gegevens voor het draaiende houden van de
onderneming. Een belangrijk inzicht bij operationele systemen is dat ze van heel verschillende aard
kunnen zijn. De systemen kunnen zeer uiteenlopend zijn qua gegevensopslag, soort database, soort
informatie, manier van beheer, manier van retrieval van informatie (en daarmee samenhangend de
responsietijden). Voorbeelden zijn een Relational Database Management Systemen (RDBMS) of
andere, bijvoorbeeld, heterogene informatiesystemen. De bedoeling is nu om gegevens uit deze
operationele systemen als bron te gebruiken voor de data warehouse data. Om deze gegevens in een
data warehouse te kunnen opnemen is het noodzakelijk de gegevens te bewerken. Dit wordt gedaan
door de zogenaamde extractietools als de wrapper en de monitor. Deze worden in de volgende
paragraaf besproken.
1.2.2 De extractietools: Wrapper en Monitor
De wrapper is een stuk software dat er voor zorgt dat de informatie afkomstig uit de operationele
gegevenbronnen wordt geanalyseerd voor opname in de data warehouse. De gegevens dienen te
worden geselecteerd, getransformeerd en te worden opgeschoond alvorens ze worden doorgegeven
10. 10
aan de zogenaamde integrator. De integrator zal in de volgende paragraaf worden besproken. De
wrapper gaat bijvoorbeeld kijken of de gegevensmodellen van de operationele gegevensbronnen
aansluiten bij het gegevensmodel van de data warehouse. Wanneer dit niet het geval is, zal de wrapper
een transformatie moeten maken van de presentatie van deze gegevens. Een voorbeeld van zo’n
transformatie is de presentatie van flat files in de vorm van een relationeel gegevensmodel (wanneer
de data warehouse gebruikt maakt van het relationele gegevensmodel).
De monitor heeft hetzelfde doel als de wrapper, maar focust op een ander punt. De monitor, zoals de
naam als suggereert, “monitort” op veranderingen in de operationele gegevensbronnen. Wanneer er
zich een wijziging voordoet in de operationele systemen, zal er een update moeten plaatsvinden van de
data warehouse. De monitor spaart veranderingen in de bronnen op en zal deze op gezette tijden
doorgeven aan de integrator. Dit is uiterst belangrijk, daar de data warehouse up-to-date dient te
blijven in vrijwel alle gevallen. De monitor bekijkt bijvoorbeeld veranderingen van bepaalde waarden
en formaten van de operationele systemen. Wanneer de data warehouse continu online moet zijn, zal
de monitor de veranderingen direct moeten doorgeven aan de integrator. Wanneer de data warehouse
af en toe offline kan zijn (denk aan ’s nachts of in het w eekend) is het mogelijk om op gezette tijden de
data warehouse te updaten (in deze offline tijd). Echter, in deze tijd, waar handel over de hele wereld
en dus in verschillende tijdzones plaatsvindt, is het zeer wenselijk de data warehouse continu online te
laten. Dit brengt met zich mee dat het maken van een update in de data warehouse niet zo gemakkelijk
meer is. Een probleem dat optreedt is het geval dat er concurrent gebruikt wordt gemaakt van bepaalde
updates en query-vragen. Dit probleem zal later nog aan de orde komen.
1.2.3 De Integrator
De integrator is een tool dat de data, na aanlevering door de wrapper /monitor, opmaakt voor opslag in
de data warehouse. Denk hierbij aan data die inconsistent is uit verschillende bronnen en data die
conflicten kunnen opleveren. Het uiteindelijke doel is het creëren van een data warehouse dat direct
kan inspelen op de vraag naar managementinformatie die nodig wordt geacht. De integrator is
voornamelijk bedoeld om de data klaar te zetten voor tools die het vervolgens in de data warehouse
laden.
1.2.4 De data warehouse gezien als database
De feitelijke database die als data warehouse wordt beschouwd kan op meerdere manieren worden
uitgelegd. In de data warehouse worden gegevens opgeslagen uit de externe bronnen. Dit kunnen
gegevens zijn die een afbeelding zijn van de externe bron (lees een view) of de feitelijke data. Deze
gegevens kunnen ook geaggregeerd zijn, d.w.z. dat ze zijn voorbewerkt door een eerdere aanvraag. Op
deze wijze ontstaat redundantie in de database. De wijze waarop de data warehouse is opgebouwd
hangt af van de gebruikte architectuur, relationeel of multidimensionaal.
1.2.5 De metadata
De metadata is een speciaal soort data in de data warehouse. Metadata laat zich het best uitleggen als
data over data. Hiermee wordt bedoeld data die wordt opgeslagen over de feitelijke data in de data
warehouse. Denk aan gegevens die iets vertellen over wanneer bepaalde data in de warehouse is
opgeslagen, wanneer er voor het laatst geüpdate is vanuit een bepaalde externe bron, etc.
Ook gegevens die iets zeggen over de creatie van gegevens in een data warehouse en het gebruik van
deze gegevens in een data warehouse vallen onder metadata.
1.2.6 De data mart
Een data mart is een verkleind data warehouse. Een data mart richt zich op speciale afdelingen van een
bedrijf en is dus ook bedoeld voor analyses t.b.v. 1 soort divisie. Aangezien de data mart niet binnen
de scope van deze scriptie valt, zal ik hier volstaan met een verwijzing naar een recent artikel over data
marts. Zie hiervoor het artikel van Rob Arntz voor de NSCCS 2000 [Arntz00].
11. 11
1.2.7 De multidimensionale database
De multidimensionale database bevat, naast de gewone data warehouse, gegevens die worden
gepresenteerd in multidimensionale vorm. Dit zijn vaak geaggregeerde gegevens, die reeds zijn
voorbewerkt door de OLAP-server (uit eerdere query’s) en voor een snelle retrievaltijd van een
nieuwe query stand-by blijven. Wanneer nu een query wordt gelanceerd die de geaggregeerde
gegevens direct kan gebruiken, zonder ze eerst te hoeven berekenen uit de gewone data, kan deze
binnen een veel snellere retrievaltijd worden beantwoord. De data warehouse hoeft echter niet een
aparte database voor dit soort query’s te hebben. Het is goed mogelijk dat de data warehouse zelf een
multidimensionale gegevensopslag gebruikt. De multidimensionale database vormt een belangrijk
onderdeel van deze scriptie.
1.2.8 De Molap/Rolap server
De MOLAP-architectuur en ROLAP-architectuur zijn de twee verschillende architecturen die gebruikt
worden voor het uitvoeren van de analyses door de OLAP tools. De MOLAP architectuur is een
architectuur die zich baseert op het multidimensionale model. De geaggregeerde gegevens worden bij
deze architectuur in een aparte database opgeslagen naast de data warehouse. Deze database slaat de
gegevens multidimensionaal op. In dit geval is het niet nodig geaggregeerde gegevens op te slaan in de
feitelijke data warehouse. De server heeft voornamelijk tot doel de gebruikersvragen om te zetten in
complexe query’s (extended SQL ) die geschikt zijn om informatie te halen uit de data warehouse en
deze vervolgens in de vorm van een multidimensionale presentatie aan te bieden aan de OLAP tools.
De ROLAP architectuur is een architectuur waarbij de data warehouse wordt opgebouwd volgens het
relationele model. Hierbij dienen de OLAP tools de relationele structuur van de data warehouse te
benaderen. Multidimensionale aspecten van de gegevens dienen in een relationeel model te worden
opgeslagen. Dit is zeer wel mogelijk. [Hobo97] spreekt over een mythe die ontkracht wordt door
Sjoerd Hobo: “gegevens dienen multidimensionaal te worden opgeslagen indien men ze
multidimensionaal wilt benaderen.” Dit is pertinent onwaar.
1.2.9 De front end tools of OLAP tools
De front end tools zijn de gebruikersprogramma’s waarmee de eindgebruikers van de data warehouse ,
bijv. de manager die een analyse maakt, de data warehouse aanspreekt voor het uitvoeren van een
analyse. De front end tool lanceert de query, bijvoorbeeld geformuleerd in de vorm van een extended
SQL-query (hier komen we later op terug), en presenteert na acceptabele retrievaltijd het antwoord in
een duidelijke en overzichtelijke tabel of tabellen. Zo’n front end tool kan zijn een spreadsheet, een
data mining tool of andersoortige analyseprogramma’s zijn. [Hobo97] omschrijft OLAP tools als
“gereedschappen die gebruikt worden om gegevens te analyseren, de resultaten te visualiseren en die
mogelijkheden bieden informatie samen te stellen als resultaat van die analyse.” Deze definitie dekt de
drie belangrijke functies van deze tools. Analyse, presentatie en samenstelling van informatie vormen
de hoofdtaken van een OLAP tool.
1.3 Problematiek omtrent de opslag van data en integratie van constraints
In deze scriptie zullen we verschillende kanten van de data warehouse belichten. Het uitgangspunt
hierbij is de verschillende problemen die spelen bij de opslag en benadering van data in een data
warehouse in kaart te brengen. We zullen hiervoor het gebruik van constraints in een data warehouse
als rode draad nemen. Het gebruik van constraints in data warehouses is namelijk een ondergeschoven
kindje in het huidige onderzoek naar data warehouses. We laten de importantie van een goede
constraint set aan het licht komen. We benaderen het gebruik van constraints in een data warehouse op
twee verschillende manieren: vanuit het concept van de data cube en het star join schema.
Het dimensionale model, waarop data warehouses worden gemodelleerd, wordt krachtig
geïntroduceerd en diep geanalyseerd. Aan de hand van een case zullen we de werking van de
verschillende concepten in dit model demonstreren. Een link met het relationele model is
onontbeerlijk: veel inzichten van dit model kunnen we doortrekken naar het dimensionale model.
12. 12
We bekijken hiertoe de manier waarop constraints worden gedefinieerd in het relationele model. Dit
doen we uitgebreid aan de hand van de modelleringstechniek PSM. Na introductie van een
modelleringstechniek voor het dimensionale model, het zogenaamde Nested Data Cube model (NDC),
proberen we de lijn van deze constraints door te trekken naar dit model.
Ons uiteindelijke doel is het aanreiken van mogelijkheden en inzichten om constraints in het
dimensionale model te beschrijven in de NDC algebra of soortgelijke algebra’s. Dit doen we
ondermeer door de verschillende problemen uit de beide modellen te vergelijken (o.a. het modelleren
van de belangrijke aggregatiemogelijkheden uit het dimensionale model in het relationele model).
Het belang van een goede en formele beschrijving van constraints in een data warehouse is zeer groot.
Dit wordt duidelijk gemaakt aan de hand van verschillende invalshoeken.
We zullen ter verduidelijking de inhoud van deze scriptie even kort bespreken. Hoofdstuk 1 geeft de
contextbepaling weer. We bespreken het concept data warehouse op verschillende manieren en geven
de problemen weer van het huidige onderzoek naar data warehouses. Tevens bakenen we het
probleemgebied van deze scriptie af. Hoofdstuk 2 introduceert het dimensionale model aan de hand
van een casebeschrijving. Tevens kijken we naar PSM en de benadering van constraints in dit model.
Hoofdstuk 3 diept het dimensionale model helemaal uit met een beschrijving van de data cube en de
problematiek omtrent constraints in een data warehouse wordt hierin uitgemeten. Hoofdstuk 4
introduceert het NDC model en diens algebra en maakt een vergelijking tussen het dimensionale
model en het relationele model. Verschillende problemen binnen data warehouses komen hier aanbod,
zoals view maintenance, de uitdrukkingskracht van de NDC algebra, de modellering van relationele
operatoren in de NDC algebra, de benadering van aggregaties en de modellering hiervan in het
relationele model. Tenslotte geven we een handreiking naar de mogelijkheid om de constraints in het
dimensionale model te beschrijven op een manier waarop dit binnen PSM is gedaan. De “taal”
hiervoor zou de NDC algebra kunnen zijn.
Als laatste in deze paragraaf een kleine technische sectie ter verduidelijking van de manier waarop
data wordt opgeslagen in een data warehouse.
1.3.1 Iets over data opslag in data warehouses
Het uiteindelijke doel van een data warehouse is het direct kunnen inspelen op de vraag naar
managementinformatie die nodig wordt geacht. Hierdoor dient de data warehouse een zeer flexibele
“houding”aan te nemen. Deze “houding”moet het mogelijk maken om bepaalde complexe en zeer
uiteenlopende vragen (lees: zeer complexe query’s, gesteld via bijvoorbeeld een spreadsheet -achtige
applicatie) zeer snel te kunnen verwerken. Het format van een data warehouse kan zeer uiteenlopen.
Er zijn drie manieren om de warehouse data op te bouwen: top-down, bottom-up en een hybride
manier, die de twee eerste combineert. Bij de top-down manier gaat het erom dat de bronnen direct
worden aangesproken om de warehouse data te creëren. Dit gaat op basis van de bestaande data
warehouse applicaties. Eenvoudige, vaak gebruikte en bekende query’s zijn reeds uitgevoerd en
opgeslagen in de data warehouse. Al het voorwerk is dus reeds gedaan. Bij bottom-up worden de
acties pas uitgevoerd, zodra er een vraag wordt gesteld aan de data warehouse. De gecombineerde,
hybride versie maakt gebruikt van sommige reeds bewerkte data uit de data warehouse en sommige
onbewerkte data rechtstreeks uit de bronnen.
Een manier om de data warehouse met deze grote mate van flexibiliteit te laten werken kan gedaan
worden door de data warehouse op te laten bouwen volgens het multidimensionale datamodel.
Het idee hierachter is dat data op zo een manier wordt opgeslagen dat alle mogelijkheden van
interpretatie van de data nog mogelijk zijn. De noodzaak van deze benadering is dat data warehouses
niet kunnen worden ontworpen met traditionele methoden. In legacy systemen (operationele systemen)
worden vaak eenvoudige query’s uitgevoerd. Bij data warehouses moeten zeer ingewikkelde query’s
kunnen worden uitgevoerd. Dit vraagt om een zeer flexibele opslag van gegevens (zoals we al zeiden:
alle mogelijke interpretaties moeten nog open liggen). Een voorbeeld hiervan is het gebruik van vele
join-operaties op de opgeslagen gegevens (dit blijkt vaak voor te komen bij data warehouses).
13. 13
Het multidimensionale datamodel maakt gebruik van zogenaamde feiten en dimensies. Feiten bevatten
de eigenlijke data en dimensies geven een interpretatie van deze gegevens. Hierdoor ontstaan
redundantie, maar dit is juist de bedoeling. Een voorbeeld van een multidimensionaal datamodel is de
zogenaamde data cube.
14. 14
2 Constraints in een data warehouse, een verkenning via PSM
In dit tweede hoofdstuk zullen we beginnen met een korte introductie van het dimensionale model,
waarbij we dit model demonstreren aan de hand van een case. Vervolgens verleggen we het accent
naar de modelleringstechniek PSM. PSM zal worden geformaliseerd en als basis dienen voor de
beschrijving van constraints in het dimensionale model. De semantiek van PSM die in deze exercitie
wordt beschreven zal als eerste in een reeks van twee formalisaties (waarbij de NDC’s uit hoofdstuk 4
de tweede vormen) dienen als uitgangspositie voor een beschrijving van constraints in een data
warehouse.
2.1 Korte introductie van het dimensionale model
Ten grondslag aan een data warehouse ligt het dimensionale model. [Kim96] spreekt over het
dimensionale model en [SMKK98] heeft het over het multidimensionale model. De heren Kimball en
Samtani c.s. spreken naar mijn mening over hetzelfde model. Op exact dezelfde wijze wordt het model
opgebouwd en met precies dezelfde vocabulaire. Het conceptuele idee wordt echter op een iets andere
manier benaderd. Waar Kimball het heeft over het Star-join schema spreekt Samtani c.s. over de data
cube. Beide benaderingen zullen worden gebruikt om zo een verschillende toenadering te maken naar
het gebruik van constraints in dit model.
Aangezien een bespreking van dit model later uitgebreid wordt beschreven, is een korte introductie
hier noodzakelijk voor een goed begrip van de problematiek rond constraints.
In dit model hebben we te maken met een feitentabel en dimensietabellen. De feitentabel bevat alle,
veelal numerieke en optelbare gegevens (bijvoorbeeld totale verkopen, totaal aantal verkochte
eenheden) over elke mogelijke combinatie van de dimensies. Deze tabel is dus vergeleken met de
dimensietabellen zeer groot. De dimensietabellen hebben een dimensie als uitgangspunt. Een dimensie
moet opgevat worden in dit verband als een variabel gegeven waarin informatie uit de feitentabel
worden opgeslagen. Voorbeelden van zulke dimensies zijn tijd (denk aan jaren, kwartalen, maanden,
weken, etc.) soort product (soort product, beschrijving, merk, etc.) en geografische ligging (Europa,
Azië, Australië, USA, etc.). De dimensietabellen bevatten naast een dimensie-key (de unieke sleutel
voor elk record in de dimensietabel) een reeks attributen die de dimensie verder beschrijven. Deze
attributen zijn dan ook vaak van tekstuele aard. De attributen van de dimensietabel worden
voornamelijk gebruikt om bij query-aanvragen (lees extended SQL, want daar hebben we het over bij
data warehouses) te dienen als bron voor het kunnen gebruiken van constraints en “row headers”. Dit
laatste geeft aan dat dit het hoofdattribuut wordt in het antwoord op de gestelde query-vraag van het
systeem naar de eindgebruiker (de SQL gebruiker). Ter verduidelijking van dit model volgt in de
volgende paragraaf een uitwerking van een voorbeeld.
2.1.1 Een case uitwerking
In deze paragraaf zal een case worden beschreven die verder als voorbeeld zal dienen bij de
verduidelijking van zo’n dimensionaal model. Als eerste zal er een korte introductie plaatsvinden
waarin de case beschreven wordt. Vervolgens zullen de gegevens uit deze case worden geplaatst in het
dimensionale model. Aan de hand van de invulling in dit model zal het model verder worden
uitgediept.
2.1.1.1 Introductie van de case
Een E-commerce bedrijf, genaamd Down Under, gevestigd in Sydney, Australië verkoopt CD’s aan de
consument via het Internet. Het bedrijf biedt deze CD’s aan via een interactieve website waarop de
consument zijn bestelling kan plaatsen. We spreken hier dus over een B2C (Business 2 Consumer)
bedrijf en laten de B2B-tak (Business 2 Business) hier dus helemaal weg. Op deze website bevinden
zich allerlei opties om het voor de consument makkelijk te maken om kiezen. Men kan zoeken in de
online database op auteur, titel, jaar van verschijnen, genre etc. Van de in de database aanwezige en
15. 15
dus leverbare CD’s is het mogelijk om een track listing op te vrage n. Wanneer een bestelling is
geplaatst kan de wijze van betaling worden opgegeven. Dit kan op drie manieren. Allereerst kan online
de creditcard gedebiteerd worden, ten tweede kan een factuur in de vorm van een acceptgiro worden
meegestuurd met de bestelling (waarmee men achteraf kan betalen) en als laatste is er nog de
mogelijkheid om de bestelling zelf af te halen en contant te betalen. Voor de distributie van de CD’s
gebruikt men regionale centra om de vervoers- en transactiekosten zo laag mogelijk te houden. Het
bedrijf zorgt zelf voor de levering van de goederen, zodat men vanuit deze regionale centra
distribueert naar de consument. Deze centra houden er dus zelf een magazijn op na. De centra zijn
gevestigd in Darwin voor verspreiding in Northern Territory, Perth voor verspreiding in West
Australia, Brisbane voor verspreiding in Queensland en Sydney voor verspreiding in New South
Wales, South Australia, Victoria en Tasmanië.
Er zijn dus vier van deze regionale centra, waarbij het hoofdkantoor in Sydney een groot deel voor
haar rekening neemt. Down Under levert dus alleen aan consumenten binnen Australië.
Sinds kort heeft Down Under het plan opgevat om ook te gaan leveren in Nieuw Zeeland. De levering
gebeurt vanuit het kantoor in Sydney, maar door de hoge transportkosten en lange levertijd is het
bedrijf een distributiepunt gestart in Auckland, Nieuw Zeeland. Het loopt goed, dus het distributiepunt
blijft bestaan. De levering gebeurt eens per maand met kleine vans vanuit de distributiepunten die de
bestellingen gaan afleveren. Een voordeel van deze manier is dat wanneer een CD niet op voorraad is,
men deze tijdig kan bestellen en als nog binnen het gestelde termijn kan leveren.
Voor de case gaan we er even vanuit dat het bedrijf dus geen gebruik maakt van de bestaande
postdiensten (in Australië is dit in de dunbevolkte delen toch een lastig vraagstuk, daar hier zeer
zelden de posterijen de consument aandoen en dan nog per vliegtuig).
Omdat het bedrijf zich inzicht wil verschaffen in de verschillende verkopen en een nauwkeurige
analyse wil maken van de historische cijfers m.b.t. de invloed van seizoenen, levertijd, genreverkopen,
etc. etc. is het noodzakelijk dat er een data warehouse wordt aangelegd om deze analyses mogelijk te
maken. Met dit hulpmiddel (de data warehouse) en de daaraan gekoppelde analyses kan men de
strategie voor de toekomst bepalen en zo ook beter inspelen op de commerciële problematiek.
Beslissingen op tactisch en strategisch niveau kunnen beter worden onderbouwd.
Een opmerking die op deze plaats gemaakt dient te worden is, dat vanwege de eenvoud van het
voorbeeld slechts 1 feitentabel wordt gedefinieerd. In een data warehouse heeft men altijd te maken
met zeer veel feitentabellen met allen, soms verschillende dimensies.
2.1.1.2 De case wordt in het dimensionale model gegoten
Als eerste moeten we bepalen wat de belangrijke structuur vormt voor de data warehouse. Hiermee
wordt bedoeld welke gegevens interessant zijn om opgenomen te worden in de data warehouse.
Dit is een eerste stap in het bepalen van de dimensies. In onze case is het product, de CD, een aparte
dimensie. Men wil precies weten welke CD wat waar doet. Ten tweede is er natuurlijk de bijna
standaard aanwezige tijddimensie en als derde is er de geografische dimensie. Deze dimensies zijn
bijna zo goed als standaard in een productiebedrijf en een handelsbedrijf. In ons geval moet de vraag
worden gesteld of er nog een extra dimensie dient te worden toegevoegd. Gemakshalve doen we dat
hier niet, om de eenvoud van het voorbeeld te behouden. Een dimensie die [Kim96] aanhaalt is ook
een vaak voorkomende, namelijk de promotiedimensie. Hierbij gaat het erom of de verkoop van
bepaalde producten afhangt van bepaalde promotionele activiteiten, zoals bonnen, aanbiedingen of
reclamedrukwerk.
Nu we de dimensies Tijd, Geografie en Product hebben afgeleid dient de opmerking te worden
gemaakt dat in de feitentabel het betalingsverkeer wordt opgenomen. De wijze van betaling,
creditcard, acceptgiro of cash, wordt aangegeven in de vorm van omzet per soort betaling in de
feitentabel. Nu we de basisconstructie voor het dimensionale model hebben afgeleid, kunnen we dit in
een eerste schema zetten. Zie hiervoor figuur 2. We zien de feitentabel in het midden van de figuur.
Deze bevat de specifieke gegevens over de verkoop en afzet van de CD’s. Aangezien dit een in
principe onuitputtelijke lijst is, geven we een aantal voorbeelden van zulke cijfers. Het aantal
verkochte eenheden is een voorbeeld van zo’n cijfer. Als men nadenkt over de betekenis van dit veld
zie je vanzelf dat het een combinatie is van de reeds gedefinieerde dimensies. Ook de wijze waarop de
16. 16
betaling plaatsvindt kan men definiëren in de feitentabel. Denk hierbij aan het feit dat de
betalingswijze nergens is opgenomen binnen de gedefinieerde dimensies!
Figuur 2: Het dimensionale model voor Down Under, de Verkoop feitentabel
De sleutels die genoemd staan in de feitentabel komen altijd voort uit de reeds gedefinieerde
dimensies. Een unieke combinatie van Tijd, Plaats en Product leveren de records op voor de
feitentabel. De echte analytische gegevens staan dus in de feitentabel, terwijl de beschrijvende
gegevens in de dimensietabellen staan!
Nu we het basisidee te pakken hebben, is de volgende stap in onze casebeschrijving de invulling van
de dimensieattributen die de dimensies moeten beschrijven. Zoals we zullen zien spelen deze
dimensieattributen een belangrijke rol in het gebruik van constraints. Hierover later meer in dit
hoofdstuk en hoofdstuk 3.
De dimensie Tijd heeft een verdeling in jaren, maanden, dagen etc. Dit zijn sowieso attributen die
moeten worden opgenomen, maar ook vakanties, weekends, uitverkoopdagen dienen te worden
opgenomen in de dimensie Tijd. In de productdimensie worden zaken opgenomen titel, artiest, genre,
jaar van verschijnen, een attribuut dan aangeeft of het een single of cd betreft, platenmaatschappij etc.
etc. Let erop dat dit niet altijd zaken zijn die hiërarchisch of causaal een relatie met elkaar
onderhouden. We zullen later zien dat dit geen problemen oplevert met SQL-aanvragen. In de
geografische dimensie worden zaken opgenomen als verkocht in Australië of Nieuw Zeeland, geleverd
uit welke stad, verkocht in welke regio of stad (uit welke gedeelten van het land of welke steden
worden de CD’s gekocht) etc. Wanneer we dit in een schema pl aatsen komen we uit bij figuur 3.
De attributen die de dimensies bevat geven aan de SQL-vragensteller de mogelijkheid om binnen de
dimensies afbakeningen te regelen. Dit gebeurt in de vorm van beperken van velden binnen deze
dimensies. Binnen de dimensie “Tijd”kan bijvoorbeeld worden beperkt op een bepaald jaar of
bepaalde maand. Om nu een concrete uitwerking van zo’n vraagstelling te geven, volgt nu een
invulling van het dimensionale model van Down Under m.b.t. tot de verkooptabel. In de vorm van vier
invullingen van de feitentabel en de drie dimensietabellen zal worden geprobeerd het principe van een
aanvraag te verduidelijken.
17. 17
Figuur 3: De dimensies met de dimensieattributen van de Down Under verkooptabel
We zullen dit doen in de volgende paragraaf.
2.1.1.3 Case invulling van het geschetste model van Down Under
Allereerst maken we een invulling van de drie dimensietabellen met daarin alle in figuur 3 genoemde
dimensieattributen. We moeten wel realiseren dat dit een zeer klein fragment is van de werkelijke
grootte van de tabel. In het echt zijn dit vele malen grotere tabellen. Voor de doeleinden die we hier
echter willen demonstreren, is een tabel van deze grootte uitermate geschikt.
Plaatssleutel Distributiecentrum State/Department Plaats Land
1 Darwin Northern Territory Katherine Aus
2 Darwin Northern Territory Darwin Aus
3 Perth Western Australia Perth Aus
4 Perth Western Australia Broome Aus
5 Perth Western Australia Hyden Aus
6 Auckland n/a Wellington NZ
7 Sydney New South Wales Tamworth Aus
Tabel 1: Invulling van de geografische dimensietabel
Productsleutel Artiest Titel Platenmy jaar Genre Single
1 Springsteen, Bruce Greatest Hits Columbia 1995 Rock nee
2 Springsteen, Bruce Nebraska Columbia 1982 Rock nee
3 Police, The Outlandos d'Amour A&M 1978 Pop nee
4 Lauper, Cyndi Hat Full Of Stars Epic 1993 Pop nee
5 Foreigner 4 Atlantic 1981 Rock nee
Tabel 2: Invulling van de productdimensietabel
18. 18
Tijdsleutel Maand Maandnr Weekend Schoolvak. Dagnummer Opruimingsdag Kwartaal Jaar
1 Jan 1 Nee Nee 18 nee 1 2000
2 Jan 1 Nee Nee 19 ja 1 2000
3 Mrt 3 Nee Nee 55 nee 1 2000
4 Mrt 3 Nee Nee 56 nee 1 2000
5 Mei 5 Nee Nee 131 nee 2 2000
6 Mei 5 Nee Nee 133 nee 2 2000
7 Dec 12 Nee Ja 350 nee 4 2000
Tabel 3: Invulling van de tijddimensietabel
Tabel 1, 2 en 3 geven een fragment van de invulling van de dimensietabellen weer. Alle
dimensierecords hebben een unieke sleutel in de vorm van, in dit geval, een nummer. Voor de
dimensieattributen is een invulling gemaakt. In de volgende tabel 4 zien we een fragment van de
invulling van de feitentabel Verkoop van Down Under. Zoals hier duidelijk zichtbaar is, vormt de
samengestelde sleutel een combinatie van sleutels uit de dimensietabellen (visueel gezien kun je dit
voorstellen als de data cube met zijn hokjes waarin elke waarde betrekking heeft op een combinatie
van de dimensies!)
Plaatssleutel Tijdsleutel Productsleutel Aantal
verkocht
Omzet #
Creditcard
#
Acceptgiro
#
Cash
#
Terug
1 1 1 4 400 3 1 0 0
1 1 2 5 520 1 4 0 0
2 2 2 6 650 6 0 0 0
2 1 2 4 400 0 4 0 0
1 1 3 7 850 5 2 0 0
1 1 4 3 400 3 0 0 1
2 1 1 2 170 0 2 0 0
Tabel 4: Invulling van de feitentabel Verkoop
Per record is in de feitentabel aangegeven welke cijfers zijn bepaald voor de verschillende producten,
tijden en plaatsen. Voor een goed inzicht zullen we het eerste record even tekstueel uitschrijven.
In het eerste record hebben we te maken met de unieke plaats-, tijd- en productsleutel 1. In een zin
beschreven betekent dit dat dit record in de feitentabel iets zegt over het aantal verkochte albums van
Bruce Springsteen met Greatest Hits op 18 januari 2000 in Katherine verspreidt via het
distributiekantoor in Darwin. Van de vier personen die deze CD in huis hebben gehaald op die dag
hebben er drie met creditcard online betaald en eentje via een acceptgiro. Nu zegt die zeer specifieke
informatie natuurlijk erg weinig en lijkt deze informatie van weinig waarde. De kracht zit hem echter
in het feit dat je selecties kunt maken in de attributen en joins kunt maken met de verschillende
dimensietabellen.
Omdat dit concept uitgebreid aan de orde komt bij de bespreking van de verschillende constraints in
de volgende paragrafen wil ik het hier laten bij een SQL voorbeeld die de werking zal verduidelijken.
SELECT p.artiest, sum(f.aantal_verkocht)
FROM feitentabel f, product p, tijd t, geografie g
WHERE f.productsleutel = p.productsleutel AND f.tijdsleutel = t.tijdsleutel AND
f.plaatssleutel = g.plaatssleutel AND g.state/department = “Northern Territory”
AND p.genre =”Rock”
GROUP BY p.artiest
ORDER BY p.artiest
19. 19
Bovenstaand stukje SQL is een eenvoudig voorbeeld over een mogelijke query die gesteld kan worden
aan ons systeem, beschreven in de case. Door middel van de joins tussen de dimensietabellen en de
feitentabel (de sleutel matching) is het mogelijk om attributen uit de verschillende dimensies op te
nemen in het antwoord. De matching van de attributen uit de dimensietabellen zorgt ervoor dat het
antwoord wordt afgebakend op precies die informatie die je wilt hebben. Hier gaat het dus om
artiesten uit het rockgenre en CD’s die verspreidt zijn in het Northern Territory. Wanneer deze query
wordt losgelaten zal het volgende antwoord worden gegenereerd. Zie tabel 5.
Artiest SUM(aantal_verkocht)
Foreigner 0
Springsteen, Bruce 21
Tabel 5: Gegenereerd antwoord
Tot zover de uitwerking van deze case. Het dimensionale model heeft hiermee een duidelijk voorbeeld
gekregen in de vorm van een reële uitwerking. Nu is de basis gelegd voor een verdere analyse naar het
gebruik van constraints toe in dit model.
2.2 Constraints in het dimensionale model, een benadering via het relationele model
Nu dit model is geschetst is de basis gelegd voor een introductie van de constraints die een rol spelen
in dit model. Als eerste kijken we naar de benadering die gemaakt wordt door [SMKK98]. Vanuit het
perspectief van relationele databases wordt geprobeerd de lijn door te trekken naar het dimensionale
model als basis voor een data warehouse. Bij het ontwerpen van relationele databases wordt in de
conceptuele gegevensmodelleringsfase al rekening gehouden met het gebruik van constraints.
Constraints worden gebruikt om bepaalde zaken te verplichten dan wel te verbieden bij het maken van
bijvoorbeeld een voorbeeldpopulatie van het gegevensmodel (wat natuurlijk een afbeelding van de
werkelijkheid is! Denk hierbij aan het Universe of Discourse). Dit komt reeds tot uiting in de
conceptuele fase. Constraints die hierbij optreden zijn als volgt te categoriseren.
• Key constraints
• Referential integrity constraints
• Not Null constraints
• Relation-based check constraints
• Attribute-based constraints
• General assertions
Voordat we verderop ingaan op de wijze waarop de tweedeling van constraints van [SMKK98] tot
stand komt vanuit dit relationele perspectief, is het op zijn plaats hier een link te leggen naar de
gegevensmodellering met behulp van PSM (Predicator Set Model, zie voor een uitgebreide
beschrijving van PSM [Hof94]). In [Hof94] wordt namelijk een goede en uitgebreide beschrijving
gegeven van de constraints zoals die hierboven door [SMKK98] zijn gecategoriseerd. We zullen nu
een korte informele beschrijving geven van één van deze constraints. Een key constraint is in de
wereld van PSM een zogenaamde uniqueness constraint. Deze constraint zorgt ervoor dat een
populatie in een gedeelte van het feittype (een tabel in het relationele model) maar 1 keer mag
voorkomen. Dit gedeelte kan slaan op slechts 1 veld, maar ook op meerdere velden. Het gedeelte van
het feittype dat hieraan moet voldoen wordt de sleutel genoemd, vandaar ook de term key constraint.
Ook kan een uniqueness constraint over meerdere feittypes gaan en zelfs over nog meer
gecompliceerde structuren. Dit zullen we hier buiten beschouwing laten. In PSM wordt gebruikt
gemaakt van een relationele algebra om de semantiek van verschillende constraints te kunnen
beschrijven. Sommige constraints, waaronder ook de uniqueness constraint, hebben ook een grafische
notatie in PSM-schema’s.
We zullen nu aan de hand van de formele definities van de verschillende soorten constraints een basis
creëren voor de constraints die later in het dimensionale mode kunnen worden beschreven. We zullen
voortborduren op het reeds aangehaalde PSM. In de volgende subparagraaf wordt als eerste een
20. 20
introductie gegeven van PSM en vervolgens zullen, verderop, de verschillende constraints worden
besproken. Deze uitstap naar PSM vormt een belangrijke basis voor de latere formalisering van
constraints in het dimensionale model. We kiezen PSM als uitgangspunt voor zo’n formalisering.
2.2.1 Introductie van PSM
Aangezien er vele informatiemodelleringmethoden zijn (Bijv. ER-diagrammen), is het weinig zinvol
hier een algemeen betoog te houden over deze verschillende methoden. Voor het doel, het construeren
van constraints in het dimensionale model, beperken we ons hier tot NIAM en PSM. NIAM is een
informatiemodelleringstechniek die gebruikt wordt als basis voor de constructen van PSM. Je kunt
NIAM als een soort voorloper beschouwen. In [Hof94] wordt op basis van een introductie van NIAM
verder gebouwd aan de constructies die mogelijk zijn in PSM.
De manier waarop we de constructies en constraints in PSM introduceren en bespreken zal gaan aan
de hand van een aantal figuren uit [Hof93] en [Hof94]. [Hof93] is het proefschrift waarop het
collegedictaat [Hof94] is gebaseerd. Het eerste figuur (figuur 4) staat echter alleen in [Hof93], met
daarbij een interessante sectie over constraints, waar later nog kort gebruik van wordt gemaakt.
Aan de hand van dit figuur maken we een analyse van de voorkomende constructen. We bekijken
figuur 4.
Figuur 4: PSM schema inzake Amerikaanse presidenten
In dit figuur zien we de verschillende (niet alle) constructen in de modelleringtechniek PSM. De
belangrijkste en opvallende grafische notaties zijn de bollen, blokjes en de relaties hiertussen.
We zullen eerst een korte informele bespreking geven van de verschillende onderdelen uit het figuur.
De bollen stellen de objecttypes voor, die weer onderverdeeld kunnen worden in labeltypes en
entiteittypes. Labeltypes worden in dit schema aangegeven met de haakjes ( ). De rest van de bollen
zijn entiteittypes. Tussen de bollen, de entiteiten, geven de blokjes relaties aan tussen deze entiteiten.
Zo’n relatie (1,2 of meer blokjes) wordt een feittype genoemd. De namen bij de blokjes worden
21. 21
predicatoren genoemd. De pijltjes in het schema hebben betrekking op constraints. Hier gaan we later
op in.
We zullen nu een consistente en formele notatie invoeren voor zo’n PSM schema als figuur 4. Figuur
4 wordt, zonder de constraints te beschrijven, een informatiestructuur genoemd. Een
informatiestructuur bestaat uit een vijftiental onderdelen. De verzameling van deze onderdelen vormen
samen een informatiestructuur, aangeduid met het symbool I.
De vijftiental onderdelen worden hieronder beschreven.
1. Een eindige verzameling van predicatoren, genoteerd met P
2. Een niet lege, eindige verzameling van objecttypes, genoteerd met O
3. Een verzameling labeltypes, genoteerd met L, waarbij geldt L⊆O
4. Een verzameling entiteiten (of entiteittypes), genoteerd met
, waarbij geldt
⊆O
5. Een partitie F van de verzameling van predicatoren P. F is een verzameling van feittypes. Een
predicator speelt een rol in een feittype. De functie Fact: P ¡ F geeft bij elke predicator het
feittype waarin deze voorkomt. De definitie van deze functie is Fact(p) = f ¢ p £ f. Er geldt
tevens F ⊆O
6. Een verzameling G van powertypes. Er geldt G⊆O
7. Een verzameling S van sequentietypes. Er geldt S⊆O
8. Een verzameling C van schematypes. Er geldt C⊆O
9. Een functie die een predicator verbindt aan zijn basis uit de verzameling objecttypes. De definitie
is Base: P ¡ O
10. Een functie die het elementtype van een powertype of sequentietype oplevert. De definitie is Elt:
G ¤ S ¡ O
11. Een relatie die de elementen van een schematype verbindt met het schematype. De definitie is ¥ ⊆
C ¦ O
12. Een binaire relatie Spec op objecttypes, die specialisatie vastlegt
13. Een binaire relatie Gen op objecttypes, die generalisatie vastlegt
14. Een algebra D die opgebouwd wordt uit de verzameling D van concrete domeinen (bijv. strings,
int, natno, long int, etc) en de verzameling F van operatoren (bijv. +, -, *, etc). Definitie D =
<D,F>
15. Een functie Dom: L ¡ D. Deze functie verbindt alle labeltypes aan een concreet domein uit D. De
instanties van labeltypes (denk bijv. aan een naam) komen uit een dezer domeinen.
Deze 15 onderdelen vormen samen dus I. De notatie voor zo’n informatiestructuur ziet er als volgt uit:
I = <P, O, L,
, F, G, S, C, Base, Elt, ¥¨§ Spec, Gen, D, Dom>
Een informatiestructuur I moet voldoen aan een reeks voorwaarden die in [Hof94] uitgebreid wordt
besproken. Het is niet erg zinvol om deze hier te beschrijven. Vandaar een verwijzing op deze plek
naar [Hof94], de voorwaarden PSM1 t/m PSM11 over de regels m.b.t. de constructie van PSM-
schema’s, de type-gerelateerdheid van objecten zijn vastgelegd in de regels T1 t/m T8. Deze zijn te
vinden op blz.46 t/m 52 van [Hof94]. Een derde soort voorwaarden, voor ons de interessantste, gaat
over de toegestane populaties in de informatiestructuren. Toegestane populaties leggen de semantiek
van een data model vast, in dit geval een PSM schema. Hieruit is direct de link te leggen met
constraints, die immers bepaalde populaties toestaan dan wel uitsluiten.
Voor we echter verder gaan met populaties in PSM schema’s, schrijven we eerst het genoemde
voorbeeld uit in de zojuist geïntroduceerde notatie. Hiertoe zullen we de verzamelingen definiëren.
P = {headed-by, being-president-of, having-as-vice-president, being-vice-president-of, inaugurated-in,
being-inauguration-year-of, resulting-from, resulting-in, being-spouse-of, having-spouse-as, p1, p2,
p3, won-by, winning, having-as, of, being-member-of, having-as-member, born-in, being-birthstate-of,
serving, being-served-by, dying-at, being-age-at-death-of}
22. 22
O = {Administration, Adm-nr, Person, Person-name, Nr-of-votes, Nr, Election, Elec-Id, Nr-of-
children, Politician, President, Year, Year-nr, Age, Nr-of-years, State, State-name, Party, Party-name,
Hobby, Hobby-name, Marriage, Admin-pres, {having-as-vice-president, being-vice-president-of},
Election-results, {won-by, winning}, {inaugurated-in, being-inauguration-year-of}, Family-size,
Birthyear, {having-as, of}, {being-member-of, having-as-member}, Birthstate, {serving, being-served-
by}, {dying-at, being-age-at-death-of}}
L = {Adm-nr, Person-name, Nr, Elec-Id, Year-nr, Hobby-name, Party-name, State-name}
= {Administration, Person, Nr-of-votes, Election, Year, Age, Nr-of-years, State, Party, Hobby,
President, Politician, Nr-of-children}
F = {Admin-pres, {having-as-vice-president, being-vice-president-of}, {won-by, winning},
{inaugurated-in, being-inauguration-year-of}, {having-as, of}, {being-member-of, having-as-
member}, Birthstate, {serving, being-served-by}, {dying-at, being-age-at-death-of}, Election-results,
Family-size, Marriage, Birthyear}
G = ¡
S = ¡
C = ¡
Verder geven de gedefinieerde functies en relaties de volgende (gedeeltelijke) invulling:
President Spec Politician
Politician Spec Person
Fact(headed-by) = Admin-pres
Fact(won-by) = {won-by, winning}
etcetera
Base(being-served-by) = Nr-of-years
Base(of) = Hobby
etcetera
Dom(Hobby-name) = string
Dom(Year-nr) = integer
etcetera
De overige functies en relaties zijn hier niet gedefinieerd, omdat sommige constructies (zoals
powertypes) ontbreken in het voorbeeld PSM schema.
Een eerste opmerking die hier dient te worden gemaakt m.b.t figuur 4 betreft het feit dat feittypes op
twee manieren kunnen worden weergegeven. Ten eerste is een naamgeving aan het construct feittype
mogelijk, zoals we zien bij Admin-pres. Een andere mogelijkheid is het feittype aan te duiden als een
verzameling van zijn rollen (of predicatoren). Het feittype {having-as, of} is zo’n voorbeeld.
Een tweede opmerking betreft het construct Marriage uit figuur 4. Het gaat hier om een zogenaamd
geobjectificeerd feittype. Dit is een feittype dat door middel van objectificatie (grafisch gezien als een
bol over het feittype) wordt getransformeerd tot een entiteit die zelf weer rollen kan spelen in feittypes.
Hoe zo’n geobjectificeerd feittype dient te worden behandeld, zal worden besproken bij de
beschrijving van populaties in PSM.
27. 27
Met de in deze paragraaf vastgelegde regels met betrekking tot populaties, is het mogelijk om nu in te
gaan op de verschillende constraints binnen PSM.
2.2.3 Constraints in PSM
Alvorens we in gaan op de wijze waarop in PSM met constraints wordt omgegaan, is het eerst
noodzakelijk een categorisatie te maken van de constraints zoals deze in PSM voorkomen.
In [Hof94] wordt als eerste gesproken over een tweedeling in constraints, namelijk als eerste
constraints die grafisch worden aangeduid in PSM-schema’s. Voorbeelden daarvan zijn we al
tegengekomen, zoals de pijltjes boven feittypes en de bollen aan de objecttypes. De tweede soort
constraints zijn degene die beschreven worden aan de hand van een relationele algebra.
Naast deze tweedeling spreekt men ook over het verschil tussen statische en dynamische constraints.
Een statische constraint is een constraint die populaties uitsluit die niet geldig zijn. Niet geldig zijn is
het niet overeenkomen met een toestand in het Universe of Discourse. Het Universe of Discourse is
het model van een gedeelte van de werkelijkheid dat gemodelleerd dient te worden. Dynamische
constraints verbieden bepaalde transities/verschuivingen tussen populaties.
Statische constraints zijn de constraints waar wij voorlopig op zullen focussen.
PSM gebruikt voor de beschrijving van de semantiek van statische constraints een relationele
algebra. Een relationele algebra is geïntroduceerd in het relationele gegevensmodel met als doel het
maken van een retrieval mogelijkheid. Dit hoofddoel zal later ook nog aan bod komen, maar als eerste
gaan we kijken naar de beschrijving van constraints met behulp van deze relationele algebra.
Als eerste definiëren we een PSM schema als een combinatie van een informatiestructuur I en een
verzameling van constraints R. Een populatie van een PSM schema wordt gedefinieerd als een
populatie van zijn informatiestructuur en de geldigheid van de gedefinieerde constraints in deze
structuur. Formeel:
IsPop( ,Pop) = IsPop(I,Pop) ¡£¢ r¤ R [Pop ¥ r]
De “voor alle”expressie geeft aan dat de populatie alle constraints in het schema waar moet maken.
Nu we weten wat een PSM schema precies inhoudt, rijst de vraag hoe we de verzameling constraints R
kunnen beschrijven en definiëren. We zullen hiertoe de relationele algebra introduceren.
2.2.3.1 Relationele algebra
Een relationele algebra voor PSM gebruikt als bouwstenen zogenaamde relationele expressies.
Relationele expressies worden als volgt geconstrueerd. Ze zijn of een feittype of een relationele
operatie toegepast op één of meer relationele expressies. Relationele operaties zullen we hier niet
uitgebreid bespreken. Voor een uitgebreide beschrijving van relationele operaties verwijzen we naar
[Weide]. In [Weide] wordt het relationele gegevensmodel vanaf scratch opgebouwd. Voor een goede
opbouw van de theorie die hierna volgt, is het noodzakelijk dat we hier de relationele operatoren kort
noemen. In [Weide] worden de volgende 4 voor ons interessante relationele operaties genoemd.
1. De projectie operatie, genoteerd met ¦ . De projectie operatie wordt gebruikt om een beperking
mogelijk te maken in de kolommen (attributen, predicatoren) van een tabel in het relationele
gegevensmodel.
2. De selectie operatie, genoteerd met § . De selectie operatie maakt het mogelijk beperkingen uit te
voeren in de tupels van een tabel. Alleen de gewenste tupels worden zo geselecteerd.
3. De join operatie, genoteerd met ¨ . Deze operatie maakt het mogelijk twee tabellen te koppelen
tot een nieuwe tabel, waarbij de attributen uit de afzonderlijke tabellen worden gekoppeld met
gemengde tupels in het resultaat van een join operatie.
28. 28
4. De hernoem operatie, genoteerd met . Deze operator hernoemt een attribuut in een relationele
expressie.
Deze vier operaties spelen een grote rol in de opbouw en werking van de relationele algebra van PSM.
Uiteraard bestaan naast deze wat meer geavanceerde operaties, de standaardoperaties zoals vereniging
en verschil. Deze komen, waar nodig, aan bod.
We zullen nu verder gaan met de opbouw van relationele expressies.
Een relationele expressie is eigenlijk een beschrijving van een afgeleid feittype. Zo’n afgeleid feittype
(afgeleid, omdat er dus via relationele operatoren kan worden gerekend met feittypes) heeft twee
kenmerken, namelijk een type en een populatie. Dit geheel in overstemming met PSM-schema’s.
Twee operaties op relationele expressies geven de mogelijkheid om deze twee kenmerken te
genereren. Het zijn de operaties Schema voor de generatie van het type en Val voor de generatie van
de bijbehorende populatie. Deze zijn als volgt gedefinieerd.
2.2.3.1.1 Schema gedefinieerd
Als relationele expressie een enkel feittype f is dan:
Schema (f) = f (= de verzameling van predicatoren uit f)
Anders is Schema gedefinieerd naar de opbouw van de relationele expressies. Schema is altijd te
schrijven als een verzameling van predicatoren.
Dit gaat als volgt.
Laat r en s relationele expressies zijn. Dan geldt:
Schema (r ¡ s) = Schema (r) ¢ Schema (s)
Laat r een relationele expressie zijn, q1,…q n (allen verschillend) en p1,…pn (uit Schema (r))
predicatoren, dan is de projectie £
q1:p1,…,qn:pn (r) een relationele expressie met de volgende definitie:
Schema (£
q1:p1,…,qn:pn (r)) = {q1,…q n}
Wanneer we kijken naar de selectie operatie, dan kunnen voor wat betreft de schemadefinitie kort zijn.
Een relationele expressie r, waarbij een selectie operatie op wordt toegepast heeft geen directe invloed
op het resultaat van het type van het afgeleide feittype. We noemen F een willekeurige selectie. Dan
geldt voor de selectie ¤
F(r) (ook een relationele expressie):
Schema (¤
F(r)) = Schema (r)
2.2.3.1.2 Val gedefinieerd
De operatie Val geeft bij elke relationele expressie een populatie op basis van een informatiestructuur
en een voorbeeldpopulatie. We zullen Val ook definiëren aan de hand van de opbouw van relationele
expressies via relationele operaties. Als eerste hebben we de basisdefinitie van de populatie van een
feittype f. Dit is eigenlijk triviaal, maar dient als basis voor de opbouw van de operatie Val.
Val [ f ] (Pop) = Pop(f)
Voor de definitie van Val is het interessant om als eerste te kijken naar de standaardoperaties
vereniging en verschil. Wanneer we 2 relationele expressies r en s bekijken, met bijvoorbeeld Schema
30. 30
Nu we de betekenis van “t f”hebben vastgelegd, kunnen we de definitie van Val voor de selectie
operatie vastleggen.
Wanneer r een relationele expressie is, f een selectieformule, dan is de selectie ¡
f (r) een ook een
relationele expressie met de volgende populatie.
Val [ ¡
f (r) ] (Pop) = { t ¢ Val [ r ] (Pop)
£
t
f }
Nu het voorwerk van deze definitie is gedaan, is de uitleg van deze Val niet meer moeilijk. Alle tupels
uit de populatie van relationele expressie r worden overgenomen, indien ze voldoen aan de
selectieformule f.
Nu voor de definities voor Schema en Val zijn opgebouwd aan de hand van de opbouw van de
relationele expressies, is het fundament gelegd voor een verdere uitbreiding van de relationele algebra
voor PSM-schema’s. In de volgende subparagraaf introduceren we nog meer relationele operaties,
waarmee de relationele algebra wordt uitgebreid. Hierbij worden voor iedere operatie de definities van
Schema en Val bijgewerkt.
2.2.3.1.3 Meer relationele operaties
In deze paragraaf breiden we het aantal relationele operaties op relationele expressies uit.
Als eerste introduceren we de extensie operatie ¤ . Deze operatie breidt een relationele expressie r uit
met een nieuwe predicator a. Deze predicator telt het aantal tupels met een gelijke waarde voor een
verzameling van predicatoren uit Schema (r). Deze verzameling wordt gedefinieerd als ¥ .
We definiëren:
Schema (¤ (r, ¥ , a)) = Schema (r) ¦ {a}
Val [ ¤
(r, ¥
, a) ] (Pop) =
{ t
£
t[Schema (r)] ¢ Val [ r ] (Pop) § t(a) = |{s ¢ Val [ r ] (Pop)
£
t(¥ ) = s(¥ ) } | }
Deze definities zijn verder duidelijk. Als tweede introduceren we de “unnest ”operatie. Deze operatie
wordt gebruikt om geneste feittypes te “unnesten”. Dit “unnesten”is feitelijk het elimineren van een
extra laag in een hiërarchische geneste structuur. We zullen dit nu formaliseren.
Laat g een relationele expressie zijn, p een predicator uit Schema (g), f een feittype zodat geldt Base
(p) is type-gerelateerd met f.. We definiëren vervolgens S = Schema (g) {p}. We kunnen dan ¨
p
f (g)
als relationele expressie definiëren. We zullen nu het bijbehorende figuur uit [Hof94] ter
verduidelijking opnemen. Zie figuur 6.
Het feittype f wordt als het ware geëlimineerd en diens predicatoren komen bij het feittype g te zitten.
De bijbehorende definitie voor Schema en Val zijn als volgt.
Schema (¨
p
f (g)) = f ¦
S
Val [ ¨
p
f (g) ] (Pop) = { t ¦ s[S]
£
t ¢ Val [ f ] (Pop) § s ¢ Val [ g ] (Pop) § s(p) = t }
De definitie van Schema spreekt voor zich, daar de verzameling S de predicatoren uit het feittype f er
bij krijgt. De definitie van Val relateert hier duidelijk aan. De populatie uit het feittype f wordt
gekoppeld aan die uit g, met dien verstande dat de populatie toegewezen aan predicator p vervangen
wordt door de reeks uit f.
33. 33
Schema (
p (r) ) = {p}
Val [
p (r) ] (Pop) = { t ¡ t(p) ¢ Val [ r ] (Pop) }
Een klein nuanceverschil in de definitie met de range operatie, maar de populatieverzameling van de
lift operatie is totaal verschillend. Bij de range operator worden alleen de elementen uit de universe of
instances m.b.t. de geselecteerde predicator gegenereerd, terwijl de lift operatie tot gevolg heeft dat de
volledige tupels (dus predicator met toewijzing uit de universe of instances) worden gegenereerd. De
predicator hoeft dus niet per se een onderdeel te zijn van een relationele expressie. Bij een objecttype
als invoer van de lift operatie worden de elementen van dit objecttype toegevoegd aan de predicator
die door de lift operatie wordt gebruikt. Het is natuurlijk wel noodzakelijk dat dit objecttype de basis is
van zo’n predicator.
Hierbij eindigt de beschrijving van de relationele algebra voor PSM. Vanuit deze relationele algebra
zullen we een beschrijving gaan geven van de verschillende soorten constraints in PSM.
2.2.3.2 Constraints onder de loep
We zullen als eerste een categorisatie maken van de voorkomende constraints in PSM. Na deze
categorisatie zal een bespreking plaatsvinden van de total role constraint en de uniqueness constraints
samengaand met een voorbeeld, bestaande uit een PSM schema en een voorbeeldpopulatie. Deze
constraints vormen de basis van alle constraints. Ook het doel van deze constraints wordt uitgelegd.
Vervolgens zal de formalisering van de constraints plaatsvinden. Deze formalisering wordt, zoals
reeds gezegd, opgeschreven in de besproken theorie m.b.t. PSM en diens relationele algebra. De
formalisering van de overige constraints zal in vogelvlucht gaan, daar de basis wordt gelegd bij de
twee genoemde soorten constraints.
We hebben in PSM de volgende (soorten) constraints (gebaseerd op [Hof94]). Gezien de naamgeving
van de constraints in het Engels is, zullen we deze niet trachten te vertalen naar een krom Nederlands
construct.
• Total role constraint
• Uniqueness constraint applied to one facttype
• Uniqueness constraint applied to more facttypes
• Uniqueness constraint applied to objectification
• Occurrence frequency constraint
• Set constraints
• Enumeration constraint
• Power exclusion constraint
• Cover constraint
• Set cardinality constraint
• Membership constraint
• Specialisation constraints
• Subtype constraints (subtype defining rules)
• Schema type constraints
De belangrijkste constraints, dat wil zeggen vaak voorkomend, hebben een grafische notatie binnen
PSM. Onder deze vallen o.a. de total tole constraint, de verschillende uniqueness constraints (met
verreweg de moeilijkste semantiek), occurence frequency constraints en set constraints. We zullen
beginnen met deze grafische constraints.
2.2.3.2.1 Total role constraint
