Ontwerp van data warehouses: opslag van data en integratie van constraints

Transcriptie

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 1

2 2

3 VOORWOORD CONTEXTBEPALING WAT IS EEN DATA WAREHOUSE EN WAT KUN JE ER MEE DOEN? DE DATA WAREHOUSE ARCHITECTUUR De operationele systemen De extractietools: Wrapper en Monitor De Integrator De data warehouse gezien als database De metadata De data mart De multidimensionale database De Molap/Rolap server De front end tools of OLAP tools PROBLEMATIEK OMTRENT DE OPSLAG VAN DATA EN INTEGRATIE VAN CONSTRAINTS Iets over data opslag in data warehouses CONSTRAINTS IN EEN DATA WAREHOUSE, EEN VERKENNING VIA PSM KORTE INTRODUCTIE VAN HET DIMENSIONALE MODEL Een case uitwerking Introductie van de case De case wordt in het dimensionale model gegoten Case invulling van het geschetste model van Down Under CONSTRAINTS IN HET DIMENSIONALE MODEL, EEN BENADERING VIA HET RELATIONELE MODEL Introductie van PSM Populaties in PSM Universe of instances gedefinieerd Populaties gedefinieerd Constraints in PSM Relationele algebra Schema gedefinieerd Val gedefinieerd Meer relationele operaties Constraints onder de loep Total role constraint Uniqueness 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 type constraints Specialisation constraints Subtype defining rules Schema type constraints Constraint definities HET DIMENSIONALE MODEL UITGEDIEPT EEN VERDERE VERKENNING VAN CONSTRAINTS IN HET DIMENSIONALE MODEL FUNCTIES VAN DE CONSTRAINTS IN HET DIMENSIONALE MODEL EEN VERKENNING VAN DE CONSTRAINTS IN DE DATA CUBE VIA EEN VOORBEELD De data cube geanalyseerd Perspectieven van dimensies: de rotate-functie Aggregatie van data: Drill Up/Down en Roll Up Begrippenkader De presentatie van gegevens in data cube jargon Enkelvoudige cel Tweedimensionale slice Multidimensionale sub cube DE CASE DOWN UNDER IN HET DATA CUB E CONCEPT De intra-cube constraints De inter-cube constraints

4 3.5 CONSTRAINTS BENADERD VANUIT HET DIMENSIONALE MODEL VIA STAR JOIN SCHEMA VOORBEELD VAN HET GEBRUIK VAN DE JOIN EN APPLICATION CONSTRAINT De dimensie geografische ligging en de application constraint SQL en de join constraint RELATIONEEL EN DIMENSIONAAL: EEN VERGELIJKEND ONDERZOEK MET BETREKKING TOT CONSTRAINTS EN MEER INTRODUCTIE VAN NESTED DATA CUBES NESTED DATA CUBES OPGEBOUWD NESTED DATA CUBES: EEN EERSTE VERKENNING VIA DOWN UNDER KLASSIEKE DATASTRUCTUREN IN NDC NDC ALGEBRA De bagify operator De extend operator De nest operator De unnest operator De duplicate operator De select operator De rename operator De aggregate operator MODELLERING VAN RELATIONELE OPERATOREN IN HET NDC MODEL NDC ALGEBRA TOEPASBAAR OP ELKE DIEPTE IN EEN NDC EEN INFORMELE MAPPING VAN RELATIONEEL OP DIMENSIONAAL EN VICE VERSA DOWN UNDER IN PSM: EEN VERGELIJKING MET HET NDC MODEL OPSLAG VAN AGGREGATIES IN EEN DATA WAREHOUSE MULTIDIMENSIONALE BENADERING VAN AGGREGATIES IN PSM GEMODELLEERD EEN AANZET TOT DE BESCHRIJVING VAN DE SEMANTIEK VAN CONSTRAINTS IN HET DIMENSIONALE MODEL EEN INTERMEZZO OVER VIEW MAINTENANCE CONCLUSIES EN VERDER ONDERZOEK SAMENVATTING ALGEMENE CONCLUSIES VERDER ONDERZOEK TERUGBLIK BIBLIOGRAFIE BRONVERMELDING FIGUREN EN TABELLEN INDEX FIGURENINDEX TABELLENINDEX

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 ( ) aan het Nederrijn College in Arnhem vervolgde hij op dezelfde school met het VWO ( ). 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 uur in colloquiumkamer A

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 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 6

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. 7

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]. 8

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 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 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 9

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 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 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 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 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]. 10

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 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 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. 11

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 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). 12

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. 13

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 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 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 14

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 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 15

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. 16

17 Figuur 3: De dimensies met de dimensieattributen van de Down Under verkooptabel We zullen dit doen in de volgende paragraaf 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 17

18 Tijdsleutel Maand Maandnr Weekend Schoolvak. Dagnummer Opruimingsdag Kwartaal Jaar 1 Jan 1 Nee Nee 18 nee Jan 1 Nee Nee 19 ja Mrt 3 Nee Nee 55 nee Mrt 3 Nee Nee 56 nee Mei 5 Nee Nee 131 nee Mei 5 Nee Nee 133 nee Dec 12 Nee Ja 350 nee 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 Omzet # # # # verkocht Creditcard Acceptgiro Cash Terug 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 18

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 19

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 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 20