VOORWOORD INLEIDING...5

Transcriptie

1

2 Inhoudsopgave VOORWOORD INLEIDING PROBLEEMSTELLING DATA WAREHOUSES TYPE INFORMATIE IN EEN DATA WAREHOUSE ONTWERPEN VAN EEN DATA WAREHOUSE Waarom redundantie in een data warehouse? Ontwerp van feitentabel en dimensietabel(len) DATA WAREHOUSE (OLAP) VERSUS TRADITIONELE DBMS (OLTP) DATA WAREHOUSE ARCHITECTUUR De rol van OLTP systemen binnen een data warehouse Extractie uit OLTP systeem OLAP view op extractie van OLTP systeem NAVIGATIE BINNEN EEN DATA WAREHOUSE GERELATEERD WERK Dimensionaal modelleren middels sterschema s Modelleren middels sneeuwvlokschema s Dimensionaal modelleren middels data cubes HISTORIE IN DATA WAREHOUSES Langzaam veranderende dimensies Updaten data warehouse middels overschrijven van gegevens Updaten data warehouse middels stapelen van velden Updaten data warehouse middels toevoegen nieuw veld Inflexibiliteit van sterschema s DEFINITIE VAN EEN DATA WAREHOUSE REPRESENTATIE EN ONTTREKKING VAN DATA UIT EEN DATA WAREHOUSE DRILL-MODELLEN DE VERSCHILLENDE VORMEN VAN DRILLING HET OASI MANIFEST AGGREGATEN IN EEN DATA WAREHOUSE CONCLUSIE DIMENSIONALE DATA WAREHOUSE MODELLEN EN OPERATIES DRILL-MODELLEN BOUWSTENEN VAN EEN DRILL-MODEL DATA WAREHOUSE MET BIJBEHOREND DRILL-MODEL Drill-up, drill-down model Drill across model Drill around model Views bij een drill-model Kortste pad en totaliseerbare kolommen DRILL-MODEL VERSUS ONDERLIGGENDE ARCHITECTUUR CONCLUSIE...50

3 4 QUERIES BEHORENDEN BIJ HET DRILL-MODEL NON-INCREMENTELE QUERIES Non-incrementele queries bij drill-up en drill-down Non-incrementele queries bij drill across Non-incrementele queries bij drill around INCREMENTELE QUERIES Incrementele queries bij drill-up en drill-down Incrementele queries bij drill across en drill around CONCLUSIE CONCLUSIES...65 BIBLIOGRAFIE...68

4 Voorwoord Voor u ligt de afstudeerscriptie van Tim Nieuwenhuis. Na het behalen van mijn diploma Bedrijfsgerichte Informatica in juli 1999 aan de HIO Arnhem, ben ik gaan studeren aan de Katholieke Universiteit Nijmegen (KUN). Daar heb ik de afgelopen twee jaar gestudeerd, eveneens in de richting Bedrijfsgerichte Informatica. Mijn stage en afstudeeropdracht aan de HIO Arnhem heb ik volbracht in het bedrijfsleven. Voor het uitvoeren van mijn afstudeeropdracht aan de KUN heb ik bewust gekozen voor een opdracht binnen de Universiteit, dit omdat de manier van werken naar mijn idee veel zelfstandiger is en minder toegespitst op een specifiek bedrijf. De afstudeerperiode liep van februari 2001 tot en met augustus In deze periode heb ik een onderzoeksopdracht uitgevoerd. De resultaten hiervan heb ik beschreven in deze scriptie. Ik wil hierbij graag een woord van dank richten aan een aantal mensen die me begeleid hebben bij het uitvoeren en beschrijven van mijn onderzoek. Allereerst is dit mijn afstudeerbegeleider, dr. Patrick van Bommel. Hij heeft mij in de aanloop, bij het schrijven van mijn plan van aanpak, en tijdens mijn onderzoek intensief begeleid. Hierbij hebben we meerdere malen inhoudelijk gesproken over de beschreven aspecten. Aan deze gesprekken heb ik erg veel gehad, het heeft me zeker geholpen om op een duidelijke manier een weergave te geven van verschillende onderdelen van mijn onderzoek. Daarnaast wil ik een woord van dank richten aan mijn collega afstudeerders, waarmee ik zeer regelmatig overleg heb gehad en ervaringen heb uitgewisseld. Ik hoop dat deze scriptie een helder beeld vormt van het onderzoek dat ik uitgevoerd heb. Tim Nieuwenhuis, augustus 2001 Faculteit Natuurwetenschappen, Wiskunde en Informatica, door: Tim Nieuwenhuis - 4 -

5 1 Inleiding Alvorens onderzoek te doen naar technieken die binnen data warehouses gebruikt worden, is het allereerst van belang te weten wat data warehouses nu eigenlijk zijn en welke technieken daarbinnen gebruikt worden. In dit eerste hoofdstuk zal daarom een beschrijving worden gegeven van data warehouses in het algemeen. De beschreven onderwerpen zullen in de volgende hoofdstukken nader geformaliseerd worden. 1.1 Probleemstelling Data warehouses zijn er in allerlei vormen en maten. Zoals in de volgende paragraaf zal blijken, zijn er geen eenduidige definities over wat er onder een data warehouse wordt verstaan. Aan het eind van dit hoofdstuk zal daarom, na bespreking van verschillende eigenschappen van belang voor deze scriptie, een definitie worden gegeven van het begrip data warehouse zoals in deze scriptie gehanteerd zal worden. De dimensionaal gemodelleerde data warehouses (zie paragraaf 1.8) zijn de meest toegepaste vandaag de dag. Er wordt in de verschillende literatuur hoog opgegeven over data warehouses, alsof data warehouses een hele nieuwe vorm van opslag- en modelleringtechniek zijn. Op het eerste gezicht zou inderdaad gezegd kunnen worden, dat dit het geval is. Het interessante is natuurlijke of de technieken die in een data warehouse worden toegepast ook inderdaad zo vernieuwend zijn. Met deze gegevens in het achterhoofd kan er een centrale vraag geformuleerd worden die in deze scriptie centraal zal staan en waar onderzoek naar zal worden gedaan. Deze centrale vraag luidt: Zijn data warehouses, in specifiek dimensionaal gemodelleerde, een innovatie m.b.t. gegevensopslag en gegevensmodellering? Om een antwoord op bovenstaande vraag te vinden zal er in speciaal gekeken moeten worden naar bestaande technieken op het gebied van gegevensopslag en gegevensmodellering. Om hier een antwoord op te geven zullen een aantal bestaande technieken bekeken worden en gekeken zal worden of met behulp van deze technieken de data warehouse technieken gerealiseerd kunnen worden. Dat brengt ons bij de subvraag die van belang is. Deze subvraag luidt: Zijn de technieken voor gegevensopslag en gegevensmodellering, die binnen data warehouses gebruikt worden, te realiseren m.b.v. bestaande/traditionele technieken voor gegevensopslag en gegevensmodellering? Met de beschreven probleemstelling zal getracht worden in deze scriptie een beeld te geven van data warehouses. Faculteit Natuurwetenschappen, Wiskunde en Informatica, door: Tim Nieuwenhuis - 5 -

6 1.2 Data warehouses De term data warehouse wordt te pas en te onpas gebruikt. In veel verschillende literatuur wordt deze term gebruikt. Wat opvalt is dat de term data warehouse in veel verschillende contexten wordt gebruikt. De definities die daardoor over data warehouses worden gegeven zijn vaak zo verschillend dat het moeilijk is om één algemene definitie te vinden. Wel kan er gekeken worden naar de eigenschappen die een data warehouse bezit. Eén van deze eigenschappen is de opbouw. De opbouw van een data warehouse is steeds volgens eenzelfde principe, enerzijds een feitentabel[1] anderzijds één of meerdere dimensietabellen[1]. Deze structuur is weergegeven in figuur 1 dimensietabel feitentabel dimensietabel dimensietabel Figuur 1, data warehouse sterschema De feitentabel is het belangrijkste onderdeel van een data warehouse. In deze feitentabel is het centrale feit opgeslagen dat middels het data warehouse gerepresenteerd moet worden. De dimensietabellen vormen een aanvulling op deze feitentabel. Zoals in figuur 1 ook is aangegeven bestaan er vanuit de centrale feitentabel verwijzingen naar de dimensietabellen. Deze verwijzingen worden middels verwijzende sleutels gerealiseerd. Om het geheel wat duidelijker te maken een concreet voorbeeld. Stel er moet een data warehouse opgesteld worden waarin verkoopfeiten van een supermarkt worden opgeslagen. De feitentabel zou dan bestaan uit verkoopfeiten, met andere woorden welke producten zijn er verkocht. De dimensietabellen vormen een aanvulling op de feitentabel. Mogelijke dimensietabellen in dit voorbeeld zouden kunnen zijn, tijd en geografie. Deze dimensietabellen geven extra informatie over respectievelijk wanneer bepaalde producten verkocht zijn en waar deze producten verkocht zijn (er kunnen immers meerdere vestigingen van een winkel zijn). Een eerste aspect, de opbouw van een data warehouse, is dus bekend. Deze opbouw roept ook vragen op, waarom is er voor deze manier van opbouw gekozen en wat zijn de voordelen van hiervan? Om hier een antwoord op te geven zal er gekeken worden naar een ander aspect, namelijk type informatie dat gerepresenteerd moet worden. Faculteit Natuurwetenschappen, Wiskunde en Informatica, door: Tim Nieuwenhuis - 6 -

7 1.3 Type informatie in een data warehouse In eerste instantie kan het lijken alsof data warehouses niets anders zijn dan de traditionele databasesystemen zoals b.v. het relationele database management systeem (RDBMS). Toch is dit niet waar. Het belangrijkste verschil schuilt in het type systeem. De traditionele systemen als RDBMS en zijn gericht op het verwerken van informatie, ook wel OLTP (On- Line Transaction Processing) terwijl data warehouses zogeheten OLAP (On-Line Analytical Processing) systemen zijn, gericht op het analyseren van informatie. Data warehouses worden daarom veel gebruikt door managers van bedrijven om analyses uit te voeren op de gegevens van hun organisatie, en aan de hand van deze analyse mogelijke strategische beslissingen te nemen. Voorbeelden van analyses kunnen zijn de omzetcijfers, hoeveel producten zijn er verkocht, welke producten worden veel verkocht, welke vestiging maakt de grootste omzet. Data warehouses zijn dus in tegenstelling tot de meeste traditionele database management systemen gericht op het analyseren van informatie (OLAP). Met dit aspect in het achterhoofd kan er ook iets gezegd worden over het ontwerp van een data warehouse in het algemeen. 1.4 Ontwerpen van een data warehouse Bij het ontwerp van een data warehouse wordt uitgegaan van een feitentabel en één of meerdere dimensietabellen. Deze architectuur wordt ook wel een sterschema genoemd, vanwege zijn vorm. De feitentabel als middelpunt en de dimensietabellen daar omheen. In traditionele database management systemen is redundantie, het dubbel opslaan van zekere informatie, een aspect dat vermeden dient te worden. In een data warehouse is het toegestaan, of beter gezegd wenselijk, om redundantie van informatie te hebben. De reden hiervoor is gelegen in het feit dat in een data warehouse snelle responstijden gewenst zijn. Redundantie heeft een grote invloed op deze responstijden, door redundantie toe te staan hoeven er veel minder joins uitgevoerd te worden om het gewenste resultaat te berekenen. Het is duidelijk dat redundantie van groot belang is bij het ontwerp van een data warehouse Waarom redundantie in een data warehouse? Het sterschema, feitentabel en dimensietabel(len), hoeft niet genormaliseerd te worden, immers normalisatie wordt toegepast om redundantie te vermijden. Het argument van snelle responstijden is reeds genoemd, toch zijn er belangrijkere aspecten te noemen waardoor in een data warehouse redundantie is toegestaan. Deze aspecten zijn: In een data warehouse kan een gebruiker geen update operaties (insert, delete, update) uitvoeren, de informatie wordt periodiek uit een operationeel OLTP systeem geladen in het data warehouse, waarnaar er geen update operaties meer gebruikt worden. Update analomiën, die het klassieke argument voor normalisatie vormen, zijn hier dus niet aan de orde. De performance van een sterschema is vele malen beter dan de performance van een genormaliseerd schema, doordat in een genormaliseerd schema veel meer joins worden toegepast. De ruimtebesparing door normalisatie is beperkt. De eerste twee argumenten klinken logisch, maar het derde argument klinkt een beetje onrealistisch. Daarom een voorbeeld waarin aangegeven wordt dat de ruimtebesparing in een data warehouse door normalisatie beperkt is. Faculteit Natuurwetenschappen, Wiskunde en Informatica, door: Tim Nieuwenhuis - 7 -

8 Stel er is een dimensietabel van 500 bytes (50 records van 10 bytes). Zeg dat deze dimensietabel records heeft, wat voor een gemiddeld systeem niet veel is. De totale ruimte die voor deze dimensietabel nodig is 20 Mb (500 bytes * records). Stel door normalisatie toe te passen kan een ruimtebesparing van maar liefst 50% bewerkstelligd worden, wat overeenkomt met 10Mb (50% van 20Mb). De ruimte die in een data warehouse nodig is voor een feitentabel is per definitie vele malen groter dan de ruimte die nodig is voor een dimensietabel. Stel in de feitentabel moet informatie worden opgeslagen betreffende verkopen van een bepaalde winkelketen voor een periode van 1000 dagen, producten en 500 verschillende filialen. Natuurlijk worden er niet iedere dag producten verkocht, zeg er worden 2000 verschillende producten per dag verkocht, de zogeheten dichtheid is dan (2000 / 40000) * 100% = 5%. De grootte van de feitentabel verkopen wordt dan 32 Gb (1000 dagen * producten * 500 filialen * 5/100 dichtheid * 32 bytes recordlengte). De besparing van 10 Mb op een feitentabel van 32 Gb is slechts (10Mb / 32Gb) * 100% = 0,03125%. Met deze besparing, die eigenlijk te verwaarlozen is, kan gesteld worden dat normalisatie niet nodig is in een data warehouse Ontwerp van feitentabel en dimensietabel(len) De vraag welke dimensietabel(len) een rol spelen in een data warehouse kan eigenlijk vrij eenvoudig worden bepaald. Hierbij is het allereerst van belang te weten welk feit vastgelegd dient te worden. Al eerder is het voorbeeld aangehaald van een winkel die meerdere producten verkoopt. Het centrale feit is hier de verkoop van deze producten. Om nu mogelijke dimensietabellen te bepalen is het van belang de volgende vragen te stellen[2, 3]: Wat gebeurt er? Waar gebeurt het? Wanneer gebeurt het? Voor wie gebeurt het? Onder welke omstandigheden gebeurt het? Wat is het detailniveau van de informatie? De antwoorden op deze vragen geven al snel een indruk welke dimensietabellen een rol spelen, nog niet direct de invulling van deze dimensietabellen. Zo geeft de vraag waar een dimensietabel geografie, de vraag wanneer een dimensietabel tijd en de vraag voor wie een dimensietabel demografie. De exacte invullingen van deze tabellen, hun opbouw, wordt bepaald door de informatie uit het operationele systeem, middels een zogeheten snapshot, hierover in de volgende paragraaf meer. De feitentabel bestaat voor het grootste deel uit sleutelattributen die de verwijzing vormen naar de primaire sleutels in de verschillende dimensietabellen. Als extra kunnen er in een feitentabel zogeheten totaliseerbare kolommen gebruikt worden. Dit zijn onderdelen uit het operationele systeem, waarvan een zogeheten extractie is gemaakt middels een snapshot, die niet binnen 1 van de dimensietabellen geplaatst kan worden en waarmee gerekend kan worden in de zin dat het getalwaarden zijn. Voorbeelden hiervan zijn aantal en kosten. Een nadere uitleg betreffende deze extractie en snapshots zal verderop in dit hoofdstuk aan bod komen. Het ontwerpen van een data warehouse middels een sterschema is een belangrijke overweging die gemaakt dient te worden. Een voordeel is de eenvoud van het concept van een sterschema. Een nadeel is dat de dimensietabellen erg plat zijn, meta-informatie betreffende functionele afhankelijkheden en hiërarchieën zullen op een andere manier opgeslagen moeten worden. Hoe dit in zijn werk gaat valt buiten de context van deze scriptie. Faculteit Natuurwetenschappen, Wiskunde en Informatica, door: Tim Nieuwenhuis - 8 -

9 1.5 Data warehouse (OLAP) versus traditionele DBMS (OLTP) Nadat het ontwerp van het data warehouse gemaakt is, kan deze gevuld worden met informatie. Deze informatie wordt middels een zogeheten snapshot uit een operationeel systeem geëxtraheerd en in het data warehouse geladen. Voordeel is dat de analyse van deze gegevens uit het data warehouse geen negatieve invloed hebben op de performance van het operationele systeem. Het extraheren van de gegevens gebeurt bij voorkeur op rustige momenten, b.v. s nachts, wanneer er weinig mensen van het systeem gebruik maken. De vraag die hierbij op kan komen is dat de informatie uit het operationele systeem niet up to date meer is, op het moment dat deze in het data warehouse wordt geanalyseerd. In principe klopt deze stelling, echter in data warehouses speelt dit een ondergeschikte rol. Dit komt doordat in een data warehouse informatie over een grote periode gewenst is, b.v. de verkochte producten het laatste jaar, de verkochte producten van de laatste dag zullen op deze algemene informatie weinig invloed hebben. Er zijn nu reeds enkele aspecten van data warehouses besproken. In tabel 1 is een vergelijking gegeven van de belangrijkste verschillen tussen traditionele on-line systemen en data warehouses (OLAP). Eigenschap On-line systeem Data warehouse Soort systeem OLTP OLAP Update operaties Veel kleine transacties Eén groot data laadproces Query operaties Veel kleine operaties Grote queries met veel joins Detailniveau Veel detail Weinig detail Aantal gebruikers >> 1000 << 100 Soort gebruikers Productiewerkers Managers Robuustheid Kritiek voor bedrijfsproces Mag tijdelijk uit de lucht zijn Aanpasbaarheid Vaak moeilijk Flexibel Ontwerpproces Waterval Incrementeel Tabel 1, on-line systeem versus data warehouse 1.6 Data warehouse architectuur Om het verschil tussen een traditionele DBMS (OLTP) en een data warehouse (OLAP) duidelijk te maken zal in deze paragraaf een architectuur van een data warehouse worden weergegeven. Het doel hierbij is om duidelijk te maken welke, verschillende, rollen de OLTP en OLAP systemen spelen De rol van OLTP systemen binnen een data warehouse In figuur 2 is een architectuur getekend die duidelijk aangeeft welke rol een OLTP systeem binnen een data warehouse speelt. Deze OLTP systemen zijn de on-line systemen waar als het ware een data warehouse op gedefinieerd moet gaan worden. Dit zijn vaak grote systemen die informatie bevatten over een zeker onderwerp, bijvoorbeeld verkopen binnen een supermarktketen. Nu werkt het data warehouse niet direct op deze systemen, hoofdreden hiervoor is om het on-line systeem niet te extra te belasten. De oplossing hiervoor is extractie van gegevens uit het on-line systeem naar een nieuwe structuur. Een andere reden waarom er een extractie gemaakt wordt is het feit dat in deze nieuwe data warehouse architectuur een andere manier van gegevensopslag kan worden toegepast, het is dus geen simpele kopie uit het on-line systeem. Redundantie is één van de aspecten die binnen een data warehouse wordt geïntroduceerd om snellere responstijden te krijgen van de queries die op deze structuur worden uitgevoerd. In de on-line systemen is redundantie Faculteit Natuurwetenschappen, Wiskunde en Informatica, door: Tim Nieuwenhuis - 9 -

10 taboe, de responstijden van de data warehouse queries zouden aanzienlijk toenemen aangezien er veel meer joins moeten worden uitgevoerd. Extractie is dus noodzakelijk Extractie uit OLTP systeem Eén van de belangrijkste redenen die aangegeven werd voor extractie is ontlasting van het on-line systeem[2, 3]. Bij de extractie van informatie zal het on-line systeem toch ook flink belast worden. Er moet al het ware een hele conversie plaatsvinden naar de data warehouse structuur waar de gegevens opnieuw moeten worden opgeslagen. Derhalve vindt extractie plaats op tijdstippen dat het on-line systeem niet erg belast is door andere gebruikers. Dit hele proces wordt veelal s nachts uitgevoerd. Een andere naam die hiervoor veel gebruikt wordt is een zogeheten snapshot. Deze naam geeft eigenlijk heel goed aan wat er nu daadwerkelijk gebeurt. Er wordt een extractie gemaakt van de inhoud van het on-line systeem op een zeker moment. Veel mensen zullen zeggen dat dit misschien een vreemde benadering is aangezien de inhoud van een on-line systeem continu wijzigt en derhalve het data warehouse ook. Dit is echter een misverstand. Data warehouses worden gebruikt om grote overzichten te genereren over langere periodes. Hierbij moet gedacht worden aan overzichten als: Omzet in boekingsjaar 1998 Het aantal verkochte producten de afgelopen 6 maanden De totale opbrengst van product X Het aantal manuren besteedt de afgelopen 10 maanden op project Y Duidelijk mag zijn dat hier de informatie over het laatste paar uur niet echt van belang is op de overzichten. Daarom worden deze snapshots slechts een beperkt aantal keer gemaakt. Nadat de snapshots gemaakt zijn en opgeslagen in een nieuwe data warehouse structuur, komt een tweede onderdeel ter sprake de data warehouse view (OLAP) op dit snapshot. Faculteit Natuurwetenschappen, Wiskunde en Informatica, door: Tim Nieuwenhuis

11 Data warehouse OLAP View Data warehouse Db1 Data warehouse Db2 Data warehouse Dbn Extractie On-line DBMS Db1 On-line DBMS Db2 On-line DBMS Dbn OLTP Figuur 2, architectuur data warehouse Faculteit Natuurwetenschappen, Wiskunde en Informatica, door: Tim Nieuwenhuis

12 1.6.3 OLAP view op extractie van OLTP systeem Nadat de extractie gemaakt is kan het data warehouse met deze gegevens aan de slag. Vanuit het data warehouse wordt als het ware een view gedefinieerd op de geëxtraheerde gegevens. Hierin kunnen overzichten gegenereerd worden van de gewenste informatie. Benadrukt moet worden dat het data warehouse zelf geen update operaties uitvoert. Er wordt uitsluitend informatie geselecteerd en weergegeven in een overzicht. Een belangrijk aspect dat hierbij om de hoek komt kijken zijn zogeheten aggregaten. Aggregaten zijn niets anders dan tellingen die vooraf zijn uitgevoerd en opgeslagen om de gewenste resultaten nog sneller aan de gebruiker te kunnen tonen. Deze aggregaten werken, net als de hele data warehouse, op de extractie die in het data warehouse is opgeslagen. In het volgende hoofdstuk zal hier nader op ingegaan worden. In figuur 2 zijn meerdere data warehouse databases weergegeven, alsmede on-line DBMS en. Hiermee wordt aangegeven dat het mogelijk is om binnen één data warehouse extracties te maken van meerdere on-line systemen. Dit hoeft echter niet per definitie het mag ook één systeem zijn waar een extractie van gemaakt wordt. De gebruiker heeft de mogelijkheid om in het resultaat van deze extractie te navigeren. Op deze manier is het mogelijk om, indien gewenst, meer of minder detail te zien. Verderop in deze scriptie zal hier nader op ingegaan worden. Doordat een view werkt op de geëxtraheerde informatie, is het mogelijk om informatie uit verschillende typen on-line systemen te benaderen. Aangezien de data warehouse databases van een uniform type zijn. 1.7 Navigatie binnen een data warehouse Navigatie is een belangrijk aspect van een data warehouse. Met navigatie wordt bedoeld het tonen van minder of meer detail in een view op de informatie uit het data warehouse. Dit navigeren wordt ook wel drilling genoemd. Drilling is eigenlijk niets anders dan het focussen op een stuk informatie (meer detail) of het uitfocussen (minder detail). In figuur 3 is een voorbeeld van een data warehouses gegeven. Dimensie TIJD VERKOOP feiten Dimensie PLAATS dag maand jaar dag stad aantal stad provincie land Figuur 3, data warehouse Het data warehouse bestaat uit een tweetal dimensietabellen en een feitentabel. De feitentabel bevat twee verwijzende sleutels naar respectievelijk de dimensietabel tijd en plaats. De kolom aantal is een totaliseerbare kolom. Duidelijk is te zien dat er in de dimensietabellen een hiërarchie aanwezig is. Faculteit Natuurwetenschappen, Wiskunde en Informatica, door: Tim Nieuwenhuis

13 De entiteiten uit de dimensietabellen geven respectievelijk meer en minder detail over een zeker feit, in dit geval een verkoopfeit. Uit deze dimensietabellen en feitentabel kan een zogeheten drill-model worden afgeleid. In dit model wordt een grafische weergave gegeven van de verschillende detailniveaus binnen het data warehouse. Een zekere view bevat steeds één entiteit uit elke dimensietabel en dit voor alle dimensietabellen. Voor figuur 3 zouden mogelijke views steeds twee entiteiten bevatten, aangezien er twee dimensietabellen zijn. Een drill-model is opgebouwd uit knopen, waarin elke knoop een representatie is van een verzameling van entiteiten, uit elke dimensietabel één entiteit. Een aantal knopen uit het data warehouse van figuur 3 zouden zijn: [dag, stad], [dag, provincie], [jaar, stad], [jaar, land]. Zo n drill-model bestaat dan uit de complete verzameling van knopen die alle mogelijke combinaties van entiteiten uit de aanwezige dimensietabellen weergeeft. In dit voorbeeld met twee dimensietabellen met ieder drie entiteiten zijn er 3 * 3 = 9 knopen in het drill-model aanwezig. Hoe deze knopen in het drill-model met elkaar verbonden zijn zal verderop in deze scriptie nader worden uitgelegd. De mate van gedetailleerdheid wordt bepaald door de knoop waarin men zich bevindt. De meest gedetailleerde knoop, dus met de meest specifieke informatie, wordt gevormd door de meest elementaire entiteiten. Dit zijn de entiteiten uit de dimensietabellen die helemaal bovenin de dimensietabel staan, in dit voorbeeld is dat de knoop [dag, stad]. Het navigeren naar een andere knoop gebeurt middel zogeheten drill-operaties. Er zijn er vier: drill-up, drilldown, drill across en drill around. Hun exacte werking wordt verderop in deze scriptie uitgelegd. 1.8 Gerelateerd werk Over data warehouses zijn reeds vele artikelen geschreven. Deze artikelen behandelen verschillende vormen van informatiemodellering. In tabel 2 is een overzicht gegeven van de verschillend vormen van informatiemodellering binnen data warehouses. Auteur Onderwerp Relatie / koppeling Ralph Kimball Dimensionaal modelleren middels sterschema s Dimensionaal model dient als basis van ieder data warehouse Thomas J. Kelly Sneeuwvlokschema s Uitbreiding op het dimensionale model Bill Inmon, Ralp Kimball Data cubes Speciale vorm van dimensionale modellering. Tabel 2, vormen van informatiemodellering binnen een data warehouse In tabel 2 staan de drie belangrijkste hoofdgroepen waarin de modellering van data warehouses in onder te verdelen is. In deze scriptie zal de dimensionale vorm van modelleren middels sterschema s de uitgangspositie vormen. De reden hiervoor is dat deze vorm van modellering het meest toegepast wordt bij het modelleren van een data warehouse. Om de andere vormen van modellering ook te belichten zullen deze kort besproken worden. Ook hun onderlinge relatie met de daarbij behorende voor en nadelen zullen aan de orde komen. Faculteit Natuurwetenschappen, Wiskunde en Informatica, door: Tim Nieuwenhuis

14 1.8.1 Dimensionaal modelleren middels sterschema s Deze vorm van modellering wordt vandaag de dag het meest toegepast bij het modelleren van data warehouses. Uitgangspunt is hierbij een centrale feitentabel met daaromheen meerdere dimensietabellen, zoals in figuur 1 reeds weergegeven is. De vraag kan natuurlijk gesteld worden waarom deze vorm van modelleren zo n voorkeur heeft. De belangrijkste reden hiervoor is dat sterschema s niet genormaliseerd hoeven te worden. Een andere reden is dat het dimensionale denken erg aansluit bij de belevingswereld van de gebruiker. Deze vorm van modelleren wordt erg aangehangen door Ralph Kimball, een van de goeroes op het gebied van data warehouses. In figuur 4 is een voorbeeld gegeven van een sterschema. dimensie 1 feiten dimensie 2 primaire sleutel entiteit entiteit verwijzende sleutel verwijzende sleutel entiteit entiteit entiteit primaire sleutel entiteit entiteit Figuur 4, sterschema met zijn bouwstenen Wat opvalt is dat een sterschema veel overeenkomsten heeft met een Entity Relationship diagram[10]. De overeenkomsten zijn: Gebruikmaking van entiteiten Gebruikmaking van attributen Relaties tussen tabellen Cardinaliteit, het is ook mogelijk om bij relaties aan te geven wat voor een relatie het betreft een één op één relatie een één op veel relatie of een veel op veel relatie Gebruik van primaire en verwijzende sleutels Een sterschema is dus een bijzondere vorm van een Entity Relationship diagram. Toch bezit een sterschema één essentieel verschil: Een sterschema hoeft niet genormaliseerd te zijn Daarnaast voegt Ralph Kimball in zijn visie de eis eraan toe dat een sterschema, of zoals hij zelf zegt[1, 2, 3]: een sterschema is Kimbaliaans of puur als de primaire sleutels van de dimensietabellen (en dus de verwijzende sleutels in de feitentabel) betekenisloze nummers zijn, die niet in het bronsysteem (waar het data warehouse van is afgeleid) voorkomen, maar puur de functie van pointers van de feitentabel naar de dimensietabellen vervullen. Faculteit Natuurwetenschappen, Wiskunde en Informatica, door: Tim Nieuwenhuis

15 1.8.2 Modelleren middels sneeuwvlokschema s Sneeuwvlokschema s zijn eigenlijk een uitbreiding op het sterschema. Het belangrijkste verschil met het sterschema: Een sneeuwvlokschema is genormaliseerd De aandachtige lezer zal zich afvragen waarom sneeuwvlokschema s dan niet de voorkeur genieten boven een sterschema, aangezien normalisatie een eigenschap is die graag gezien wordt. In paragraaf is al uitgelegd waarom een data warehouse liever niet genormaliseerd wordt. Toch wordt deze vorm van modellering wel toegepast. In [10] wordt een data warehouse besproken waarin er wel sneeuwvlokschema s gebruikt worden en dus genormaliseerd wordt. Een voorbeeld van zo n genormaliseerd sneeuwvlokschema is in figuur 5 weergegeven. jaar maand dag verkoop winkel stad Figuur 5, genormaliseerd sneeuwvlokschema Hier komt vooral het aspect performance om de hoek kijken. Ten opzichte van een niet genormaliseerd sterschema moet er veel meer gejoined worden om een gewenste overzicht uit het data warehouse te genereren. Duidelijk is te zien dat de dimensietabellen uit het sterschema hier ontrafeld zijn in meerdere losse tabellen. De garantie die bij een sterschema gegeven kan worden is dat de queries daar maximaal 1 tabel diep gaan, aangezien dimensietabellen zelf geen verdere verwijzingen hebben naar andere dimensietabellen. Dit in tegenstelling tot de sneeuwvlokschema s. Het gebruik van een sneeuwvlokschema om een data warehouse te modelleren is niet per definitie een slecht alternatief. Er zijn voorbeelden waar binnen data warehouses wel degelijk updates uitgevoerd moeten worden. Dit speelt met name een rol bij het bijhouden van de historie van gegevens in een data warehouse. In deze gevallen werkt een genormaliseerd schema beter, immers in een genormaliseerd schema hoeft slechts op 1 plaats een feit aangepast te worden terwijl in een niet-genormaliseerd schema op veel plaatsen hetzelfde feit aangepast moet worden, door meervoudige opslag van gegevens. Over de historie in data warehouses later meer. Faculteit Natuurwetenschappen, Wiskunde en Informatica, door: Tim Nieuwenhuis

16 1.8.3 Dimensionaal modelleren middels data cubes Data cubes[5, 13] zijn als het ware een speciale vorm van dimensionaal modelleren. Hierbij worden de verscheidene dimensies uit het data warehouse samengenomen. Een voorbeeld hiervan is weergegeven in figuur 6. Plaatsdimensie plaats Nijmegen product wasmiddel Productdimensie Tijdsdimensie tijd 25 mei 1998 verkoopfeit wasmiddel verkocht in Nijmegen op 25 mei 1998 Figu ur 6, dimensies visueel gemaakt in een data cube Hier zijn 3 dimensies, plaats, tijd en product, in een data cube. De cube metafoor levert een nieuwe methode om de wijze waarop de data in een data warehouse is georganiseerd visueel te maken. Een data cube kan opgebouwd zijn uit 2 of meer dimensies. Iedere dimensie representeert een identificerend attribuut. De vorm van de cube geeft aan dat: Verschillende dimensies tegelijkertijd gebruikt kunnen worden om een feit weer te geven Hoe meer dimensies gebruikt worden des te hoger het detailniveau van de feiten Dimensies kunnen tevens gebruikt worden als constraint, dit kan door alleen de rijen terug te geven die voldoen aan een waarde of een set van waarden die in de dimensie zijn opgeslagen. Een voorbeeld zou kunnen zijn een dimensie tijd. Hierbij zou in de data cube binnen deze dimensie een constraint geplaatst kunnen worden die forceert dat alleen feiten met een datum voor 25 maart 2000 getoond worden. Data cubes worden in veel OLAP-tools vandaag de dag gebruikt. De gebruiker kan hierbij zelf in een grafische omgeving een feit uit de cube selecteren en automatisch wordt een querie samengesteld die voor de gebruiker het gewenste resultaat berekent. In sommige OLAP -tools kan de gebruiker zelf een combinatie van dimensies kiezen waaruit een data cube wordt opgebouwd en waaruit vervolgens gewenste feiten worden berekend. Stel een manager van een bedrijf is geïnteresseerd in de verkochte producten per winkel. De dimensies product en plaats zijn hierbij van belang. Een dimensie als tijd, die in het data warehouse aanwezig kan zijn kan hierbij buiten de data cube gelaten worden. Faculteit Natuurwetenschappen, Wiskunde en Informatica, door: Tim Nieuwenhuis

17 1.9 Historie in data warehouses Op het eerste gezicht lijkt dit een onderwerp dat niet zo heel erg belangrijk is. Toch schuilt hier een belangrijk aspect c.q. probleem dat het ontwikkelen c.q. beheren van een data warehouse moeilijk kan maken. Eerder is al aangegeven dat de verwijzende sleutels in een data warehouse bij voorkeur bestaan uit betekenisloze nummers. De eerste reden die daarvoor reeds gegeven is, is ruimtebesparing in de feitentabel. De andere reden komt in deze paragraaf aan de orde en heeft te maken met het omgaan met langzaam veranderende dimensieobjecten. Een zekere vorm van historie is al opgenomen in het data warehouse, n.l. de dimensie tijd. Iedere keer worden nieuwe feiten aan het data warehouse toegevoegd en is er op deze manier een vorm van historie gecreëerd Langzaam veranderende dimensies In eerste instantie lijkt het dat dimensies die eenmaal in een data warehouse zijn opgenomen nooit meer wijzigen. Dit is echter een groot misverstand. Sommige dimensies veranderen in de loop der tijd wel degelijk, het gaat dan concreet om de opbouw van een bepaalde dimensie. In figuur 7 is een voorbeeld gegeven van de dimensie plaats. dimensie plaats winkel_key naam plaats provincie indeling PK FK winkel_key naam plaats provincie indeling 1 Waterstraat Nijmegen Gelderland Standaard 2 Kanaalstraat Eindhoven Brabant Ruim 3 Leegmolen Groningen Groningen Standaard Legenda: PK = primaire sleutel FK = verwijzende sleutel Figuur 7, dimensie plaats en bijbehorende tabel De dimensie plaats geeft een naam van een winkel de plaats waar de winkel zich bevindt en de bijbehorende provincie en als laatste een indeling. Winkels worden aangeduid met een standaard of ruime indeling. Tot zover geen probleem, stel de winkel uit de Waterstraat wordt verbouwd en de indeling wijzigt van standaard naar ruim. Deze wijziging moet echter wel in het data warehouse meegenomen worden. Tot dusver is als uitgangspunt gekozen dat in een data warehouse geen update operaties plaatsvinden. Voor dit soort situaties, veranderende dimensies, moet dit echter wel gebeuren. De vraag is nu alleen hoe dit moet gebeuren. Faculteit Natuurwetenschappen, Wiskunde en Informatica, door: Tim Nieuwenhuis

18 Updaten data warehouse middels overschrijven van gegevens De meest voor de hand liggende oplossing lijkt inderdaad te zijn; het overschrijven van de gegevens. In dit geval zou de kolom indeling voor het filiaal Waterstraat overschreven worden met de indeling Ruim. Echter is dit geen goede oplossing. Data warehouses worden gebruikt om analyses te maken over een zekere periode. En bij deze analyse moet het filiaal Waterstraat voor de verbouwingsdatum onder de categorie Standaard worden gezien en niet onder Ruim. Echter is dit na overschrijving niet meer te traceren. Toch is deze oplossing niet in alle gevallen taboe. Er zijn situaties denkbaar waarbij het overschrijven geen problemen oplevert. Hierbij moet dan wel goed gelet worden op de volgende twee punten[4]: De historie van gegevens moet niet belangrijk zijn, dus het is niet essentieel van belang dat informatie van voor de wijziging als zodanig weergegeven wordt De modellering van de onderdelen die gewijzigd worden wel genormaliseerd is Een voorbeeld van zo n situatie kan zijn b.v. NAW-gegevens die van een klant opgenomen zijn uitsluitend ten behoeve van mailingdoeleinden. In deze situatie is het overschrijven geen enkel bezwaar Updaten data warehouse middels stapelen van velden Een geheel andere oplossing voor het omgaan met veranderende dimensies is het stapelen van velden. Deze oplossing is weergegeven in figuur 8. PK FK winkel_key naam geldig vanaf stad Provincie indeling 1 Waterstraat Nijmegen Gelderland Standaard 2 Kanaalstraat Eindhoven Brabant Ruim 3 Leegmolen Groningen Groningen Standaard 5 Waterstraat Nijmegen Gelderland Ruim Legenda: PK = primaire sleutel FK = verwijzende sleutel Figuur 8, gewijzigde tabel bij dimensie plaats Als oplossing is er een nieuwe rij toegevoegd aan de tabel. Dit is geen bezwaar aangezien in een data warehouse gegevens rustig toegevoegd mogen worden. Hier valt ook meteen het nut op van het gebruik van de nummers als primaire sleutel, eerder is al opgemerkt dat een reden was om ruimte te besparen, de tweede reden wordt hier weergegeven, voor het toevoegen van een nieuwe rij kan eenvoudig een nog niet gebruikt nummer ingevoegd worden om de nieuwe rij uniek te identificeren. Een andere verandering die zich voordoet is de verwijzende sleutel. Eerst lag deze verwijzende sleutel over het veld naam. Echter wordt bij deze oplossing de naam dubbel ingevoerd, Waterstraat komt nu tweemaal voor, vandaar dat de verwijzende sleutel nu komt te liggen over de kolommen naam en geldig vanaf. In veel data warehouses worden deze velden standaard opgenomen. Op deze manier is bijvoorbeeld uit te zoeken hoeveel omzetverhoging de uitbreiding van een winkel met zich meebrengt. Een nadeel van deze oplossing is dat het data warehouse inconsistent raakt. Met andere woorden; doordat een data warehouse veelal niet genormaliseerd is moeten wijzigingen vaak op meerdere plaatsen doorgevoerd worden, het gevaar is dat dit niet altijd Faculteit Natuurwetenschappen, Wiskunde en Informatica, door: Tim Nieuwenhuis

19 gebeurt op alle plaatsen (zekere bij zeer grote data warehouses). Inconsistentie doet dan al snel zijn intrede Updaten data warehouse middels toevoegen nieuw veld Een geheel andere situatie kan zich voordoen op het moment dat er besloten wordt te reorganiseren en de indeling van winkels niet meer weer te geven met standaard en ruim maar met klein, middel of groot. Wanneer hier de stapeloplossing uit de vorige paragraaf gehanteerd zou worden, zou dit leiden tot een enorme explosie van de dimensie plaats. Immers voor iedere vestiging moet een nieuwe rij ingevoegd worden in de tabel. Om dit te voorkomen wordt een nieuw veld toegevoegd. Een voorbeeld is weergegeven in figuur 9. PK FK winkel_key naam plaats provincie indeling indeling_oud 1 Waterstraat Nijmegen Gelderland Groot Ruim 2 Kanaalstraat Eindhoven Brabant Middel Standaard 3 Leegmolen Groningen Groningen Groot Standaard Legenda: PK = primaire sleutel FK = verwijzende sleutel Figuur 9, gewijzigde dimensie plaats door toevoeging kolom Als oplossing is er hier gekozen om de nieuwe indeling te plaatsen in de oude kolom indeling. De waarden die eerst in de kolom indeling stonden (zie figuur 7), zijn nu geplaatst in de nieuwe kolom indeling_oud. Voordeel van deze oplossing is: De dimensie explodeert niet, m.a.w. er wordt niet voor ieder item een nieuwe rij ingevoegd Oude reeds gedefinieerde queries blijven werken, kolomnaam is ongewijzigd, echter hoeft alleen gezocht te worden op de nieuwe naam die gebruikt wordt voor de indeling Historie is gewaarborgd, oude indeling kan opgevraagd worden indien gewenst. Mocht de oude indeling op een zeker moment niet meer van belang zijn, dan kan de kolom indeling_oud simpelweg verwijderd worden Deze oplossing kan dus het beste toegepast worden wanneer er plotseling grote veranderingen worden doorgevoerd. Met grote veranderingen wordt bedoeld veranderingen die invloed hebben op bijna alle rijen uit een zekere dimensie. Betreft het wijzigingen van een kleinere vorm, bijvoorbeeld één winkelindeling die gewijzigd moet worden, zoals in de vorige paragraaf is beschreven, dan volstaat de oplossing met het stapelen van velden. Tot zover lijken de problemen met veranderende dimensies mee te vallen. Aan het begin is al aangegeven dat deze vorm van wijzigingen wel degelijk een probleem kan vormen, waar de meeste leveranciers van data warehousetools (nog) geen oplossing voor gevonden hebben. Faculteit Natuurwetenschappen, Wiskunde en Informatica, door: Tim Nieuwenhuis

20 1.9.2 Inflexibiliteit van sterschema s De oplossingen die beschreven zijn voor het omgaan met dimensies die wijzigen lijken een redelijk goede oplossing te bieden. Toch schuilt hier een probleem. PK FK product_key naam code groep leverancier 1 tandpaste tp05 toiletartikel Derksen b.v. 2 pindakaas pk06 etenswaren Janssen b.v. 3 wasmiddel wm07 schoonmaak Kaartman b.v. Legenda: PK = primaire sleutel FK = verwijzende sleutel Figuur 10, dimensie product In figuur 10 is een voorbeeld gegeven van een deel van een data warehouse, het betreft hier de dimensie product. Van grote supermarktketens verandert de leverancier van een zeker product nog wel eens. Graag wil men ook hier in het data warehouse historie inbouwen. De oplossing lijkt simpel, voeg een kolom toe waarin de oude leveranciers staan, maak uit het operationele OLTP systeem middels extractie een lijst met de nieuwe leveranciers die bij een zeker product horen en voeg deze toe aan het data warehouse. Er lijkt niets aan de hand, echter zijn hier de huidige leveranciers gekoppeld aan de verkopen uit het verleden en het is onduidelijk of tijdens de verkopen uit het verleden dit wel de juiste leverancier was. Middels metagegevens zou eigenlijk bekend moeten zijn vanaf welke datum een kolom geldig is, op zich is dit nog wel te doen. Het is echter ook gewenst dat een eindgebruikerstool (OLAP) de gebruiker waarschuwt als een query mogelijk foutieve resultaten teruggeeft. Stel er is een leverancierskolom geïntroduceerd op 25 juni De vraag geef mij de verkopen per leverancier vanaf 25 augustus 1998 kan correct beantwoord worden. De vraag geef mij de verkopen per leverancier vanaf 25 mei 1998 kan niet correct beantwoord worden. Toch geven de query-hulpmiddelen hier vrolijk een incorrect antwoord op. Naast het hierboven beschreven metaprobleem is er nog een andere complicatie die kan optreden. PK FK demogr_key Leeftijdcat Inkomen geslacht 1 0 tot 25 0 tot M 2 0 tot 25 > M 3 25 tot 50 0 tot M 4 25 tot 50 > M 5 >50 0 tot M 6 >50 > M Legenda: PK = primaire sleutel FK = verwijzende sleutel Figuur 11, deel van de dimensie demografie Faculteit Natuurwetenschappen, Wiskunde en Informatica, door: Tim Nieuwenhuis

21 In figuur 11 is een deel van de dimensie demografie weergegeven. Stel dat in deze dimensie een kolom regio toegevoegd wordt. De dimensie zal dan flink groter worden, maar dat is niet het grootste probleem. Het vervelende hier is dat, zelfs als alleen de huidige waarde correct aangegeven moet worden, sommige klanten die tot voor de wijziging dezelfde demografische sleutel hadden, nu met een ander moeten worden aangeduid. En deze wijziging moet ook in de feitentabel worden doorgevoerd. Voor deze beschreven problemen zijn mogelijk wel oplossingen te vinden, alleen worden ze in de literatuur niet beschreven. De goeroes op het gebied van data warehouses, zoals Bill Inmon en Ralph Kimball zwijgen over dit soort problemen in alle toon aarden. Dit is een van de grootste problemen op dit moment binnen data warehouses. In de meeste data warehouse omgevingen zijn deze problemen (nog) niet opgelost Definitie van een data warehouse Een aantal belangrijke eigenschappen van een data warehouse zijn inmiddels behandeld. Om een duidelijk en helder beeld te geven zal er nu, gegeven de besproken eigenschappen, een definitie worden gegeven van het begrip data warehouse van waaruit de rest van deze scriptie is geschreven. Def1: Data warehouse = verzameling van feitentabel(len) en dimensietabel(len) opgeslagen in een structuur waarin geen update operaties plaatsvinden en die gebruikt wordt om analytische informatie te verschaffen. Deze analytische informatie, ofwel managementinformatie, geeft een overzicht van een zekere periode (b.v. de omzet over het laatste halfjaar). Data warehouses worden daarom ook veel gebruikt door managers, ze bieden namelijk snel een overzicht van globale gegevens, detailinformatie speelt meestal geen rol. Desgewenst kan deze detailinformatie middels de beschreven navigatie (drilling) verkregen worden. In het volgende hoofdstuk zal er in detail worden ingegaan op de onderdelen beschreven in dit eerste hoofdstuk. Faculteit Natuurwetenschappen, Wiskunde en Informatica, door: Tim Nieuwenhuis

22 2 Representatie en onttrekking van data uit een data warehouse Sterschema s met dimensietabellen vormen de basis van de meeste data warehouses vandaag de dag. In dit hoofdstuk zal in meer detail worden ingegaan op deze dimensionale sterschema s en de daarbij behorende drill-modellen. Een drill-model is een afgeleid model dat gemaakt kan worden van een sterschema. Een drill-model beschrijft als het ware alle mogelijke toestanden waarin een data warehouse zich kan bevinden. Daarnaast zal er aandacht besteed worden aan het onttrekken van informatie uit een data warehouse middels queries. 2.1 Drill-modellen Een drill-model is een navigatiemodel dat behoort bij een zeker data warehouse sterschema en beschrijft in welke verschillende toestanden een data warehouse zich kan bevinden. Een drill-model kan afgeleid worden uit een sterschema. Aan de hand van een eenvoudig voorbeeldje zal dit worden toegelicht. dimensie tijd feit verkoop dimensie plaats dag maand jaar dag stad aantal stad provincie land Figuur 12, data warehouse sterschema In figuur 12 is een data warehouse sterschema getekend. Het betreft hier een eenvoudig sterschema met slechts twee dimensietabellen. In een view op dit sterschema zullen altijd twee dimensies aanwezig moeten zijn, aangezien er twee dimensietabellen zijn. Het aantal vertices in het drill-model wordt daarom gevormd door het aantal mogelijke combinaties van entiteiten uit de betreffende dimensietabellen. In dit geval is dit de volgende verzameling van knopen; {(dag, stad), (dag, provincie), (dag, land), (maand, stad), (maand, provincie), (maand, land), (jaar, stad), (jaar, provincie), (jaar, land)}. Het concrete drill-model dat bij deze verzameling hoort is weergegeven in figuur 13. Faculteit Natuurwetenschappen, Wiskunde en Informatica, door: Tim Nieuwenhuis

23 dag stad maand stad jaar stad dag provincie maand provincie jaar provincie dag land maand land jaar land Figuur 13, concreet drill-model Wat opvalt is dat er geen directe verbindingen zijn tussen alle knopen. Het is dus onmogelijk om rechtstreeks van de knoop [dag, land] naar de knoop [jaar, land] te gaan. De overgang van de ene naar de andere knoop wordt dan drilling genoemd. Hierdoor is het mogelijk om als eindgebruiker op verschillende detailniveaus naar informatie uit het data warehouse te kijken. De term drilling is wat algemeen, er zijn namelijk verschillende vormen van drilling mogelijk, afhankelijk van de opbouw van het data warehouse. 2.2 De verschillende vormen van drilling Een drill-model kan onderverdeeld worden in een viertal submodellen. Er zijn 4 soorten van drilling[1, 14], derhalve zijn er ook 4 submodellen te abstraheren, te weten: Drill-down model Drill-up model Drill across model Drill around model De vraag die hierbij gesteld kan worden is: kan uit elk model van een data warehouse (b.v. sterschema) het viertal submodellen gegenereerd worden? Om deze vraag te beantwoorden zal er gekeken moeten worden naar de eigenschappen van deze vier vormen van drilling. Drill-up en Drill-down: deze vorm van drilling kan binnen elk data warehouse model worden toegepast. Er wordt respectievelijk minder of meer detail getoond in de data warehouse view. Een voorbeeld van een drill-up en drill-down is gegeven in figuur 14. maand provincie drill-up jaar provincie dag land drill-down maand land Figuur 14, drill-up/drill-down voorbeeld Faculteit Natuurwetenschappen, Wiskunde en Informatica, door: Tim Nieuwenhuis

24 De drill-up operatie gaat van de knoop [maand, provincie] naar [jaar, provincie]. In woorden zou dit betekenen dat er van een view waarin de verkopen per maand per provincie wordt overgegaan naar een view met de verkopen per jaar per provincie. Dit levert een kleinere minder gedetailleerde view. Aangezien er nu niet meer per maand een overzicht wordt gegeven maar slechts per jaar. De andere kant op, drill-down, heeft het omgekeerde effect. Deze operatie gaat van de knoop [maand, land] naar [dag, land]. In woorden zou dit betekenen dat er van een view waarin de verkopen per maand per land worden weergegeven wordt overgegaan naar een view met de verkopen per dag per land. Dit levert juist een grotere meer gedetailleerde view. Immers worden nu de verkopen per dag weergegeven i.p.v. gegroepeerd per jaar. Een geheel andere vorm van drilling is drill across en drill around. In het volgende hoofdstuk zal hier in meer detail op worden ingegaan, evenals drill-up en drill-down operaties. Toch hier alvast een klein voorproefje. Drill across is als het ware het combineren van feiten uit verschillende dimensietabellen. In concreet zou dit betekenen dat een data warehouse dat feiten representeert over verkopen in een supermarkt per plaats in een zekere periode, weergegeven door de dimensies plaats en tijd en een data warehouse betreffende personele kosten per plaats in een zekere periode, gecombineerd kunnen worden in één view. Schematisch is dit weergegeven in figuur 15. Faculteit Natuurwetenschappen, Wiskunde en Informatica, door: Tim Nieuwenhuis