Data warehousing. Hogeschool voor Economische Studies Rotterdam

Transcriptie

1 Data warehousing Hogeschool voor Economische Studies Rotterdam

2 Data warehousing Een onderzoek naar de valkuilen bij het opzetten van een data warehouse B. Dukker Student Bedrijfskundige Informatica Hogeschool voor Economische Studies Rotterdam, 23 mei 1997

3 Voorwoord Iedereen die afstudeert aan de HES Rotterdam, moet in het laatste jaar van zijn of haar studie een scriptie schrijven. Voor de richting Bedrijfskundige Informatica geldt bovendien, dat het laatste jaar stage gelopen moet worden. Dit biedt een uitstekende mogelijkheid om de stage te combineren met de scriptie. Ook ik heb tijdens mijn stage bij het Duyverman Computer Centrum (DCC) opdrachten uitgevoerd die nauw verband hielden met mijn scriptie. Deze situatie bood twee grote voordelen. Enerzijds was ik in staat om voor het DCC een concrete bijdrage te leveren aan de kennis op het gebied van data warehousing, aangezien ik al volledig op het onderwerp was ingelezen. Anderzijds was ik door mijn stage in staat concreet met mijn kennis om te gaan en dat heeft gezorgd voor een stuk toegevoegde waarde aan mijn scriptie. Ik kan dan ook met zekerheid stellen, dat dit laatste jaar veruit het meest leerzame jaar is geweest uit mijn gehele schoolcarrière. De afgelopen jaren heb ik zeer veel theoretische kennis opgedaan. Nu ik deze kennis tijdens mijn stage in de praktijk heb kunnen brengen, is de theorie pas echt tot leven gekomen en heb ik geleerd veel concreter en kritischer met mijn kennis om te gaan. Ik wil de heer Schiereck bedanken voor zijn begeleiding bij het schrijven van mijn scriptie. Bovendien wil ik mijn collega s bedanken voor de tijd die ze vrij hebben gemaakt om mijn werk kritisch te beoordelen, voor de leerzame discussies die we hebben gevoerd en ook zeker voor de gezellige tijd die ik het afgelopen jaar heb gehad.

4 Inhoudsopgave pag. Inleiding 5 1 De behoefte aan een data warehouse Informatiesystemen Informatiebehoefte Aanleiding tot een data warehouse 9 2 Het data warehouse Algemene omschrijving Specifieke kenmerken 11 3 De schakels van het data warehouse Ontsluiting bronsystemen Copy management Gegevensopslag De gegevensstructuur Het DBMS Metagegevens Beveiliging Front end 30 4 Conclusie en aanbeveling 31 Begrippenlijst 33 Literatuurlijst 36

5 Inleiding Deze scriptie zal handelen over het fenomeen data warehousing. Data warehousing mag zich verheugen in een enorme populariteit. Ieder zichzelf respecterend IT-blad gaat minimaal eens per twee edities uitgebreid op het onderwerp in en in het Database Magazine is er zelfs sprake van een data warehausse. Door deze aanhoudende aandacht in de media ben ik geïnteresseerd geraakt in de mogelijkheden en de onmogelijkheden van het data warehouse. Om het begrip data warehousing hangt een grote grijze wolk van nieuwe termen, begrippen en technologieën die te pas en te onpas worden gebruikt. Bovendien zijn de begrippen niet eenduidig gedefinieerd. De definities van de verschillende begrippen waarover onduidelijkheid kan ontstaan, zijn opgenomen in de begrippenlijst achterin deze scriptie. De eerste keer dat een begrip uit de begrippenlijst wordt gebruikt, zal dit met *) worden aangegeven. Het begrip data warehouse zelf is ook niet eenduidig gedefinieerd. Schrijvers van boeken, *) artikelen en whitepapers op het gebied van data warehousing, hanteren elk een eigen definitie. De definitie die ik in deze scriptie hanteer, komt zoveel mogelijk met deze verschillende definities overeen. Het data warehouse is: een gegevensverzameling die bestemd is voor het leveren van managementinformatie, waarvan de inhoud is ontleend aan bestaande operationele informatiesystemen, waarbij geldt dat de gegevens geïntegreerd, onderwerpgeoriënteerd, historisch *) vluchtig zijn. *) *) *) en niet Het doel van deze scriptie is, dat de lezer zich realiseert dat er bij het opzetten van een data warehouse rekening gehouden moet worden met een aantal aandachtspunten. Er is een aantal valkuilen, die het succes van het data warehouse kunnen bedreigen, waar in de literatuur niet bij wordt stilgestaan. De lezer moet na het lezen van deze scriptie bekend zijn met deze valkuilen. Om dit doel te bereiken, zal ik ingaan op de verschillende schakels in het proces van operationele gegevens naar (management-)informatie die het data warehouse maken tot wat het is. De informatie in deze scriptie is gebaseerd op ontwikkelingen die ik tijdens mijn stage bij het Duyverman Computer Centrum heb gesignaleerd, op gesprekken met leveranciers van de producten die benodigd zijn voor een data warehouse en op verschillende boeken, whitepapers en artikelen, die op het gebied van data warehousing zijn gepubliceerd. Door - 5 -

6 het lezen van deze hoeveelheid aan gegevens heb ik een duidelijk beeld gekregen van wat het data warehouse behelst. Tijdens mijn stage heb ik discussies gevoerd, presentaties bijgewoond en opdrachten uitgevoerd. Hierbij bleek de literatuur op een aantal aspecten tekort te schieten. In deze scriptie ga ik kritisch in op de literatuur en de valkuilen die ik tijdens mijn stage heb blootgelegd. Hoewel de kosten en baten van het data warehouse significante aspecten zijn, zal ik daar in deze scriptie niet bij stilstaan. De kosten zullen per toepassing sterk verschillen en het is vrijwel ondoenlijk de baten in geld uit te drukken, aangezien er dan een causaal verband aangetoond moet worden tussen stijgende winst, de verbeterde beleidsvoering én de mate waarin deze verbetering is veroorzaakt door de managementinformatie uit het data warehouse. Het is echter wel zo, dat de baten van het data warehouse afhankelijk zijn van de kwaliteit van het data warehouse. Een goed data warehouse zal door de gebruiker geaccepteerd én gebruikt worden. Het is dan ook belangrijk om bij het bouwen van een data warehouse rekening te houden met de aandachtspunten waar ik in deze scriptie bij stilsta. In het eerste hoofdstuk geef ik kort aan hoe de behoefte aan een data warehouse is ontstaan. In het hoofdstuk daarna zullen de eigenschappen van het data warehouse nader worden beschreven. De kern van deze scriptie zal handelen over de aandachtspunten waar in de literatuur op wordt gewezen én de problemen hierbij, die tijdens mijn stage aan het licht zijn gekomen. Daarbij zullen dié zaken aan bod komen die hetzij worden onderschat, hetzij volledig over het hoofd worden gezien, maar die wel van groot belang zijn voor de kwaliteit en de acceptatie van het data warehouse. Aansluitend zullen in hoofdstuk 4 enkele conclusies worden getrokken en zal er een aanbeveling worden gedaan

7 1 De behoefte aan een data warehouse Globaal zijn er twee factoren te onderscheiden die leiden tot de behoefte aan een data warehouse. Ten eerste zijn de bestaande informatiesystemen niet ontwikkeld (en als gevolg daarvan niet geschikt) voor het leveren van managementinformatie. Daarnaast wordt de behoefte aan managementinformatie steeds groter. In de volgende paragraaf wordt behandeld vanuit welk oogpunt de bestaande informatiesystemen in de loop der tijd zijn ontwikkeld. In tweede de paragraaf wordt de behoefte aan managementinformatie beschreven en in de laatste paragraaf staat aangegeven hoe deze twee factoren leiden tot de behoefte aan een data warehouse. 1.1 Informatiesystemen De vele informatiesystemen, die in de loop der tijd zijn ontwikkeld, zijn functiegeoriënteerd: ze zijn ontwikkeld voor de ondersteuning van een bepaalde operationele functie. Zo ontwikkelde ieder filiaal en iedere afdeling een eigen *) transactiegericht systeem (OLTP -systeem) dat er functioneel op was gericht, de activiteiten van die specifieke afdeling of van dat filiaal zo efficiënt mogelijk te ondersteunen. Dit had tot gevolg dat er binnen een bedrijf verschillende klanten-, producten-, en financiële registraties ontstonden. Veel gegevens worden dus meerdere malen vastgelegd, maar wel telkens op een andere manier: die manier, die het beste past bij de te ondersteunen functie. Zo ontstonden er dus verschillende definities en naamgevingsconventies voor dezelfde gegevens. Op operationeel niveau hoeft van veel gegevens geen historie bijgehouden te worden. Veelal kan worden volstaan met een weergave van de huidige situatie. Als gegevens wijzigen, gaan de oude waarden bij de wijziging verloren. Het is niet mogelijk trendanalyses uit te voeren met gegevens waarvan geen historie wordt bewaard. Daar komt nog eens bij dat de systemen veelal slecht (of niet) werden gedocumenteerd en *) er geen metagegevens van werden beheerd. Door de groei van het aantal systemen en door de groei van de (relationele) databases, werd het steeds moeilijker het overzicht te behouden. Er begon zich een ondoorgrondelijk spinnenweb te vormen van hardware, software en gegevens. Dergelijke systemen worden in de literatuur aangeduid met de term *) legacy-systemen (Inmon, 1996 a, p. 8)

8 1.2 Informatiebehoefte Bedrijven krijgen steeds meer en steeds vaker te maken met internationalisering van de handel en wereldwijde concurrentie. Om de concurrentie voor te kunnen blijven, moeten deze bedrijven tijdig kunnen inspelen op veranderingen in de markt. Inzicht in trends, klantengedrag en een goed beeld van het bedrijfsproces zijn vereisten als een bedrijf tijdig de juiste strategische beslissingen wil nemen. Niet alleen de stijgende concurrentie zorgt voor deze toenemende informatiebehoefte van het management: ook de klant wordt mondiger en het wordt steeds belangrijker om in te spelen op individuele behoeften. Ook hiervoor is het van groot belang dat de juiste gegevens tijdig beschikbaar zijn. Als er een beter profiel van de klanten beschikbaar is, *) kan er een direct marketing strategie worden toegepast. Hiermee kunnen de verkoopcijfers enorm stijgen (Heuvel e.a., 1991, p ). Er bestaat bovendien een fundamenteel verschil tussen de informatiebehoefte van een manager en die van de gebruikers van de OLTP-systemen. Bij het bouwen van het operationele systeem wordt die functionaliteit ingebouwd, die moet voldoen aan de behoefte van de gebruiker. Vraag en antwoord zijn bij de bouw gedefinieerd. Afbeelding 1: Globaal organisatieschema in drie niveaus In de bovenstaande afbeelding wordt het onderscheid aangegeven tussen de niveaus die kunnen worden onderkend. Bij een vraag die wordt gesteld op operationeel niveau zijn relatief weinig gegevens uit slechts één of misschien enkele informatiesystemen betrokken. Het antwoord op een vraag op operationeel niveau is vaak één getal of een kleine tabel. Voorbeelden van dergelijke vragen zijn: Hoeveel kosten deze schoenen? of Hoeveel jassen hebben we nu op voorraad? - 8 -

9 De informatiebehoefte van een manager is niet op operationeel niveau, maar op strategisch of tactisch niveau. Vraag en antwoord zijn niet van tevoren gedefinieerd. De gedachtengang van een manager kan als volgt worden getypeerd: Geef mij antwoord op mijn vraag en dan kan ik pas zeggen wat ik werkelijk wil weten (Wijnen, 1995). De manager weet pas wat zijn tweede vraag zal zijn, als er een antwoord is gekomen op zijn eerste. Bij een vraag van een manager zijn relatief veel (operationele) gegevens betrokken uit diverse informatiesystemen op verschillende locaties. Het antwoord op dergelijke vragen is vaak geen getal, maar een overzicht van kengetallen, waarbij gegevens met elkaar vergeleken moeten kunnen worden. Voorbeelden van vragen op strategisch of tactisch niveau zijn: Wat zijn mijn omzetten per filiaal per productgroep per kwartaal? of Hoe verhouden mijn omzetten per productgroep zich ten opzichte van vorige jaren? Als dan blijkt dat hier een bepaald filiaal of bepaalde productgroep uitspringt, zal de manager op dat getal in willen zoomen. Dit betekent dat het beantwoorden van een vraag niet te lang mag duren. 1.3 Aanleiding tot een data warehouse Bedrijfsbreed ligt op operationeel niveau een schat aan informatie opgeslagen, maar het zoeken van de juiste antwoorden in deze veelheid aan gegevens, levert niet het gewenste resultaat. Bij het voorzien in de managementinformatiebehoefte gaan de volgende problemen een steeds grotere rol spelen (Achterstraat, 1995): het duurt veel te lang voor het antwoord op een strategische vraag gevonden is vanwege het feit dat de verschillende legacy-systemen slecht op elkaar zijn afgestemd en onvoldoende zijn gedocumenteerd; trends zijn niet te achterhalen, omdat er geen historie wordt bewaard: de OLTPsystemen worden continu bijgewerkt en vormen een weerspiegeling van de huidige situatie; de performance van de operationele systemen wordt sterk negatief beïnvloed als er ad hoc queries op worden gedaan ten behoeve van de managementinformatie. Een data warehouse kan een oplossing bieden voor bovenstaande problemen. De beperkingen die de operationele systemen hebben bij het leveren van managementinformatie zullen leiden tot steeds grotere ontevredenheid bij het management aangezien de behoefte aan tijdige managementinformatie almaar toeneemt. In het volgende hoofdstuk zal het data warehouse beschreven worden en tevens hoe het data warehouse van toepassing kan zijn bij het leveren van managementinformatie

10 2 Het data warehouse Uit het voorgaande hoofdstuk blijkt dat de belangrijkste reden om een data warehouse te bouwen, de behoefte aan managementinformatie is waarin niet (tijdig) wordt voorzien, terwijl de benodigde gegevens wel aanwezig, maar niet toegankelijk zijn (Whitepaper DCC). Het doel van een data warehouse is dan ook het creëren van een geoptimaliseerde omgeving voor het leveren van managementinformatie. De manier waarop een data warehouse een oplossing kan bieden voor het tekortschieten van de operationele systemen bij het verstrekken van managementinformatie zal in de volgende paragrafen worden beschreven. 2.1 Algemene omschrijving Het data warehouse vormt een schakel tussen het aanbod van gegevens in de operationele systemen en vraag naar informatie vanuit het management. De opzet van het data warehouse wordt hieronder zichtbaar gemaakt: Afbeelding 2: De opzet van het data warehouse Deze extra schakel in de informatiestroom vervult de functie van groothandel in het logistieke proces tussen producent en afnemer. De operationele systemen zijn de producenten van de informatie, die met de komst van de tussenschakel niet meer belast worden door de behoeften van individuele afnemers. De tussenschakel voorziet in de behoeften van de afnemers, zodat deze niet langs alle producenten moeten om zelf de informatie te vergaren

11 Binnen dit kader geldt dat de gegevens die uit de operationele systemen worden overgeheveld, niet zonder meer worden gekopieerd. Een van de redenen dat de gegevens uit de operationele systemen niet voldoen bij het beantwoorden van managementvragen, is juist het feit dat deze systemen zijn gebouwd met het oog op de ondersteuning van een bedrijfsproces. De gegevens daarbinnen zijn dan ook overeenkomstig gemodelleerd. De gegevens in het data warehouse worden weliswaar onttrokken aan de operationele systemen, maar kunnen worden geoptimaliseerd voor het verschaffen van managementinformatie. In tegenstelling tot de gegevens in de operationele systemen zijn de gegevens in het data warehouse: geïntegreerd, onderwerpgeoriënteerd, historisch en niet vluchtig. In de volgende paragraaf wordt nadere invulling gegeven aan deze termen. 2.2 Specifieke kenmerken Er bestaan verschillen tussen definities en naamgevingsconventies binnen de verschillende operationele systemen. Dezelfde gegevens kunnen verschillend zijn gedefinieerd. Verschillende gegevens kunnen daarentegen juist dezelfde naam hebben gekregen. Een datum kan in het ene systeem bijvoorbeeld het formaat DD-MM-JJ hebben en in het andere MM-DD-JJJJ. Bovendien kan de handelsrelatie Koning en Hartman binnen één en hetzelfde bedrijf geregistreerd staan als: Firma Koning en Hartman, Koning & Hartman, Koning en Hartmann, K&H, K en H (Whitepaper DCC). Dit gebrek aan integratie van de gegevens kan worden opgelost bij ingebruikname van een data warehouse. Bij het opbouwen van data warehouse moeten de gegevens eenduidig gedefinieerd worden, waarbij alle gegevens in het data warehouse beschreven worden met behulp van metagegevens. Door stil te staan bij definiëring van de gegevens in de operationele systemen ontstaat meteen meer inzicht in deze (legacy-)systemen en in de operationele processen. Als de gegevens geïntegreerd in het data warehouse opgeslagen liggen, hoeft de analist zich niet meer bezig te houden met het schonen en koppelen van de informatie. Hij kan de managementinformatie op een effectieve en efficiënte manier uit één geïntegreerde bron betrekken. Bij het transformatieproces van de gegevens tussen de operationele systemen en het data warehouse worden de gegevens niet alleen geïntegreerd, maar tevens anders gemodelleerd. De modellering van de gegevens in het data warehouse kan volledig worden toegesneden op het verschaffen van managementinformatie. Er kunnen verschillende niveaus van detaillering aangebracht worden en bepaalde gegevens kunnen geclusterd worden. De

12 gegevens worden onderwerpgeoriënteerd gemodelleerd en hoeven niet volledig genormaliseerd, relationeel opgeslagen te worden zoals bij de OLTP-systemen het geval is. De metagegevens spelen hierbij een grote rol als wegwijzer voor de analist op zijn zoektocht naar managementinformatie. De metagegevens geven antwoord op vragen als: wat betekent een gegeven?, waar vind ik bepaalde gegevens?, waar komt het gegeven vandaan? en welk transformatieproces heeft het gegeven ondergaan. Naast de structuur en de definitie van de gegevens is het belangrijk, dat de gegevens in het data warehouse historische gegevens zijn. De gegevens in het data warehouse zijn dan ook *) niet aan verandering onderhevig (read-only ). Ze worden alleen aangevuld met de huidige waarden van de operationele systemen, waarbij alle gegevens van een tijdsaanduiding worden voorzien. De gegevens in het data warehouse zijn dus een reeks momentopnamen van de operationele systemen. Doordat de historische gegevens binnen een data warehouse op verschillende detailleringsniveaus opgeslagen kunnen worden, wordt het mogelijk eenvoudig trendanalyses uit te voeren. Samengevat laat het data warehouse zich dus kenmerken door de volgende eigenschappen: geïntegreerde gegevens, onderwerpgeoriënteerde gegevens, meerdere niveaus van detaillering, metagegevens, historische gegevens, read-only, mogelijkheid tot trendanalyse, ontlasting van operationele systemen. Deze eigenschappen maken het data warehouse tot een ideale bron voor het verkrijgen van de benodigde managementinformatie (Fadlalla, 1996) (Inmon, 1996 b)

13 3 De schakels van het data warehouse Een data warehouse kán een ideale bron zijn voor het verkrijgen van managementinformatie. Voor het echter zover is dat een bedrijf deze ideale informatiebron heeft opgebouwd, zijn er verschillende zaken waarmee terdege rekening gehouden moet worden. Er wordt veel aandacht besteedt aan het fenomeen data warehousing. De leveranciers van *) de diverse front ends op het data warehouse weten hun product bovendien zó flitsend te presenteren, dat het lijkt alsof de mogelijkheden ongelimiteerd zijn. Hierdoor besluiten managers dat er een data warehouse moet komen, zonder te beseffen wat er allemaal moet gebeuren, voordat een goed data warehouse is gerealiseerd én geaccepteerd. Het front end is dan ook een krachtig wapen bij het verkrijgen van gebruikers- en managementacceptatie (zie ook paragraaf 3.6). Het wezenlijke gevaar dat hier echter in schuilt, is dat alle aandacht uitgaat naar het front end en dat het proces dat daaraan vooraf gaat een ondergeschoven kindje wordt. De volgende afbeelding geeft aan welke aandachtsgebieden kunnen worden onderscheiden. Afbeelding 3: Aandachtsgebieden bij het opzetten van een data warehouse De pijlen stellen hierin de volgende aandachtsgebieden voor: 1 ontsluiting bronsystemen, *) 2 copy management, 3 gegevensopslag, 4 metagegevens, 5 beveiliging, 6 front end

14 De zes stappen in afbeelding 3 zijn de schakels in de keten van operationele data naar managementinformatie. Ze zullen in de volgende paragrafen één voor één behandeld worden. Per stap zal worden gelet op problemen die zich bij realisatie voor kunnen doen en op de invloed op de uiteindelijke acceptatie van het data warehouse aangezien de acceptatie van de gebruikers het succes van het data warehouse bepaalt. 3.1 Ontsluiting bronsystemen De eerste stap in de keten van operationele data naar managementinformatie is het ontsluiten van de operationele systemen die de gegevens voor het data warehouse aanleveren. In hoofdstuk 1 wordt al aangegeven dat het tekortschieten van de transactiegerichte operationele systemen bij het leveren van managementinformatie een van de redenen is om tot het bouwen van een data warehouse over te gaan. De legacy-systemen kennen verschillende problemen die opgelost moeten worden, om de kwaliteit van de gegevens in het data warehouse te kunnen waarborgen. Het vinden van een goede oplossing om de bronsystemen te ontsluiten wordt vaak onderschat en er wordt een te klein deel van het budget voor gereserveerd (Koorneef e.a., 1997). Problemen die hierbij kunnen spelen zijn: de documentatie van het bronsysteem ontbreekt of is sterk verouderd waardoor de precieze betekenis van de gegevens niet of moeilijk achterhaald kan worden; de gebruikte technologie wordt niet meer ondersteund of kan moeilijk worden ontsloten, omdat er geen interface voor bestaat; de gegevens in het bronsysteem zijn niet betrouwbaar. Het laatste probleem kan zich op verschillende manieren manifesteren. Ten eerste kunnen de gegevens inhoudelijk incorrect zijn, doordat ze niet consequent worden bijgewerkt of doordat er invoerfouten zijn gemaakt. Het kan ook zo zijn dat er oneigenlijk gebruikt wordt gemaakt van het informatiesysteem. Een veld kan bijvoorbeeld op een andere manier worden gebruikt dan waar het oorspronkelijk voor werd ontworpen. In veel boeken en artikelen wordt wel gewaarschuwd voor de bovenstaande problemen bij het ontsluiten van de bronsystemen en gewezen op de dreiging die een gebrekkige analyse van de brongegevens vormt voor de kwaliteit en flexibiliteit van het data warehouse. Geen enkel boek of artikel gaat echter in op de invloed die het data warehouse heeft op de bronsystemen. Er wordt gesteld, dat de komst van het data warehouse de operationele systemen juist ontlast, aangezien deze worden gevrijwaard van de queries ten behoeve van de gewenste managementinformatie

15 Als een bepaald informatiesysteem gegevens moet aanleveren voor het data warehouse, heeft dat tot gevolg, dat het informatiesysteem een extra interface heeft waarmee rekening moet worden gehouden bij het plegen van onderhoud. Voor elke wijziging op het systeem moet worden nagegaan of de wijziging ook gevolgen heeft voor het data warehouse, wat dus meer werk betekent voor de automatiseerder. Bovendien zal er periodiek moeten worden nagegaan of de gegevens in het bronsysteem door de eindgebruikers goed worden onderhouden. Het data warehouse betekent dus wel degelijk een extra last voor de bronsystemen waar de literatuur, die op dit moment voorhanden is, ten onrechte geen aandacht aan schenkt. 3.2 Copy management Het copy management is het proces bij het opzetten van het data warehouse waarbij de grootste technische complicaties kunnen voorkomen. Tijdens het laden van de gegevens in het data warehouse worden de gegevens overgezet van de (legacy-)systemen. Hierbij worden de gegevens dus onttrokken uit bronnen die sterk verouderd kunnen zijn en geschikt gemaakt voor het data warehouse, dat wordt opgezet met behulp van de nieuwste technologieën. In de literatuur wordt voor deze dreiging wel gewaarschuwd, maar desondanks wordt er in de praktijk veelal te licht over gedacht. Zeker als het management besluit, dat er een data warehouse moet komen vanwege de manier waarop de informatie gepresenteerd kan worden, bestaat er een grote kans dat het voortraject en dús het copy management te weinig aandacht krijgt. Hieronder volgt een opsomming van de belangrijkste problemen die kunnen spelen bij het laden van de gegevens in het data warehouse: de gegevens binnen de bronsystemen kunnen exotische bestandsformaten hebben die niet door extractie-hulpmiddelen worden ondersteund; om een record uit een tabel te kunnen kopiëren, kan het nodig zijn dat er meerdere records uit verschillende andere tabellen geraadpleegd moeten worden in verband met eventuele sleutelverwijzingen; aangezien de gegevens worden geoptimaliseerd voor het leveren van managementinformatie, ondergaan de gegevens uit de bronsystemen een transformatieproces waarbij wijzigingen op het data-type, de lengte en de inhoud van een veld nodig zullen zijn;

16 als verschillende OLTP-systemen (bijvoorbeeld van diverse filialen) gelijksoortige gegevens aanleveren, zullen afwijkende bestandsstructuren, sleutelattributen en definities het samenvoegen van deze gegevens bemoeilijken; tijdens het laden van de (geschoonde en geïntegreerde) gegevens in het data warehouse *) *) kan het zijn dat aggregatieniveaus en afgeleide gegevens meteen moeten worden voorberekend en opgeslagen, wat een extra gevaar kan opleveren voor de consistentie binnen het data warehouse; het gehele transformatieproces van operationele gegevens tot gegevens in het data warehouse moet bekend en onderhoudbaar zijn om flexibiliteit te waarborgen (zie paragraaf 3.4). Het vinden van goede oplossingen voor deze complicaties is van uitermate groot belang voor de kwaliteit van de informatie in het data warehouse. De gegevens ondergaan een transformatieproces waarbij ze worden geschoond en geïntegreerd. Als dit niet goed wordt gerealiseerd, dan geldt voor het data warehouse GIGO *) en zal het management geen betrouwbare informatie uit het data warehouse kunnen verkrijgen. De kwaliteit van de gegevens en daarmee dus de kwaliteit van het copy management-proces is een zeer belangrijke succesfactor van het data warehouse. Naast de kwaliteit van de gegevens wordt met het copy management bovendien de actualiteit van de gegevens bepaald. Veranderingen in de gegevens binnen de bronsystemen kunnen dagelijks, wekelijks of maandelijks worden doorgevoerd. De keuze die hieromtrent moet worden gemaakt, is afhankelijk van de eisen die het management aan de tijdigheid van de informatie stelt en van de snelheid waarmee de gegevens in de bronsystemen worden bijgewerkt. De beslissing heeft eveneens invloed op de netwerkbelasting en op de performance van de bronsystemen. Het is zelfs mogelijk wijzigingen op gegevens in de bronsystemen meteen door te voeren in het data warehouse. Het gaat te ver om in te gaan op de technische mogelijkheden waarop dit kan geschieden, maar het is wel belangrijk om te beseffen dat actualiteit van het data warehouse zijn tol eist voor wat betreft netwerkbelasting en verwerkingskosten. De voor- en nadelen moeten tegen elkaar worden afgewogen, waarbij de extra belasting van de bronsystemen niet uit het oog verloren mag worden

17 3.3 Gegevensopslag Een zeer belangrijke stap tijdens het bouwen van het data warehouse is het vaststellen van de manier waarop de gegevens in het data warehouse worden opgeslagen. Hiermee wordt voor een heel groot deel de performance van het data warehouse bepaald, wat van zeer groot belang is voor de tevredenheid van de eindgebruiker. Bovendien bepaalt het de flexibiliteit, wat belangrijk is in het geval de informatiebehoefte wijzigt. Omdat het karakter van de gegevens in het data warehouse fundamenteel anders is dan dat van de gegevens in operationele systemen, kan de opslag van de gegevens worden geoptimaliseerd voor het leveren van managementinformatie (zie paragraaf 1.2). Omdat de gegevens in het data warehouse niet aan verandering onderhevig zijn, kan consistentie met behulp van het copy management optimaal worden gegarandeerd zonder dat de gegevensstructuur volledig is genormaliseerd zoals dat bij de OLTP-systemen het geval is. De manier waarop gegevens voor een data warehouse gemodelleerd kunnen worden, staat beschreven in paragraaf Het model dat zal worden opgesteld, wordt geïmplementeerd in een database. Hierbij hoeft niet noodzakelijk te worden gekozen voor een Relationeel DataBase Management Systeem (RDBMS). Als er een multidimensionele gegevensstructuur wordt opgesteld, dan kan een MultiDimensioneel DataBase Management Systeem (MDDBMS) als alternatief dienen. Een beschrijving en vergelijking van deze twee alternatieven staat in paragraaf De gegevensstructuur Iedereen die bekend is met het modelleren van gegevens voor het ontwikkelen van systemen is bekend met de normalisatieregels van Codd. Traditiegetrouw wordt er aangevangen met het onderkennen van entiteiten en vervolgens worden deze genormaliseerd, opdat er geen redundantie meer is en de consistentie optimaal kan worden gewaarborgd. De informatiesystemen die doorgaans worden ontwikkeld, zijn bedoeld ter ondersteuning van een operationeel proces en hiervoor is deze manier van gegevensmodelleren bij uitstek geschikt. Een data warehouse is echter niet bedoeld voor ondersteuning van operationele processen, maar voor het leveren van managementinformatie op strategisch danwel tactisch niveau. Bovendien is het data warehouse een statische omgeving (zonder online update) waardoor het makkelijker is de consistentie te waarborgen. Redundantie is dus niet langer een vloek

18 Deze twee factoren maken het data warehouse geschikt voor een andere benadering bij het opstellen van de gegevenstructuur. Er wordt gesteld dat gegevens op strategisch niveau het beste multidimensioneel gedenormaliseerd kunnen worden gemodelleerd. In dat geval kunnen de gegevens worden gepresenteerd als kubus (zie paragraaf 3.3.2), wat voor de eindgebruiker veel makkelijker te begrijpen is dan de onderliggende gegevensstructuur. In elk boek en artikel dat ingaat op gegevensmodellering voor een data warehouse wordt dan ook gesteld dat gegevens in het data warehouse moeten worden gemodelleerd volgens *) een ster-schema, wat de volgende voordelen op zou moeten leveren: de structuur kan multidimensioneel worden gepresenteerd wat voor de eindgebruiker makkelijk te begrijpen is en waar de eindgebruiker makkelijker mee kan werken dan met een volledig genormaliseerde structuur; hiërarchieën kunnen gemakkelijk worden gedefinieerd, waardoor eenvoudig op gegevens kan worden ingezoomd naar een lager niveau; de hoogst mogelijke performance kan worden geboden bij het beantwoorden van vragen van het management, doordat afgeleide gegevens en aggregatieniveaus vooraf kunnen worden berekend en opgeslagen en het feit dat er zo weinig mogelijk tabellen samengevoegd hoeven te worden; de flexibiliteit van het te kiezen front end wordt vergroot, aangezien een aantal front end tools alleen kan worden gebruikt als de gegevens zijn gemodelleerd volgens een ster-schema. Hieronder zal eerst worden beschreven wat een ster-schema behelst en hoe het wordt opgesteld. Vervolgens zullen hier enkele kritische kanttekeningen bij worden geplaatst. Bij het opstellen van een gegevensstructuur ter ondersteuning van het management wordt uitgegaan van een andere informatiebehoefte dan die op operationeel niveau. Bij een vraag die wordt gesteld op operationeel niveau zijn relatief weinig gegevens uit slechts één of misschien enkele informatiesystemen betrokken. Het antwoord op een vraag op operationeel niveau is vaak een getal of een kleine tabel. Bij een vraag op strategisch niveau zijn relatief veel (operationele) gegevens betrokken uit (zo mogelijk) alle informatiesystemen. Een antwoord op strategisch niveau is vaak geen getal, maar een overzicht van een aantal getallen, waarbij gegevens met elkaar vergeleken moeten kunnen worden. Een voorbeeld van een vraag op strategisch of tactisch niveau is: Wat zijn mijn omzetten per filiaal per productgroep per kwartaal? Als blijkt dat hier een bepaald filiaal of bepaalde productgroep uitspringt, zal de manager op die omzet in willen zoomen. Het antwoord op een vraag van een manager zou dan ook zo snel mogelijk gegeven moeten kunnen worden

19 Als deze informatiebehoefte multidimensioneel moet worden gemodelleerd, zal er allereerst onderscheid gemaakt moeten worden tussen feiten en dimensies. De feiten zijn die gegevens waar de manager in is geïnteresseerd (omzet, winst). Deze - veelal numerieke - gegevens worden opgeslagen in de fact-table. De dimensies zijn die elementen in de vraag waarvoor per staat (per product, per regio, per tijdseenheid). Als de informatie in tabelvorm wordt gepresenteerd, dan komen de getallen in de tabel dus uit de fact-table en komen de tabelkoppen uit de dimensietabellen. In de definitie van het data warehouse staat dat de gegevens in een data warehouse onderwerpgeöriënteerd gemodelleerd moeten worden. Onderwerp is in die context de verzamelnaam voor feiten en dimensies. Als deze feiten en dimensies rechtstreeks in een gegevensstructuur worden gezet, onstaat een zogenaamd ster-schema: Afbeelding 4: Voorbeeld van een eenvoudige ster-structuur In het midden staat de fact-table: de tabel met de gewenste feiten, de kengetallen waarop het management wil sturen. Daarop zijn drie dimensies gezet. Deze dimensies zijn aan de fact-table gekoppeld met een automatisch gegenereerde, numerieke sleutel. Op die manier kan de omzet bijvoorbeeld worden herleid naar een bepaalde plaats, een bepaald merk en een bepaald kwartaal. Binnen de dimensies zijn hiërarchieën te definiëren: Locatiedimensie: Winkel Ψ Plaats Ψ Provincie Ψ Land, Productdimensie: Artikel Ψ ProductType Ψ Merk Ψ Leverancier, Tijdsdimensie: Dag Ψ Week Ψ Maand Ψ Kwartaal Ψ Jaar. De dimensie Tijd is in principe altijd aanwezig. Dit maakt het mogelijk trendanalyses uit te voeren

20 Niet alleen iedere Winkel heeft een eigen sleutel, maar ook iedere Plaats en iedere Provincie op zich. Op die manier kan de totale omzet voor een Provincie in de fact-tabel worden opgeslagen, zodat op het moment dat de omzet van een bepaalde Provincie wordt gevraagd, niet de omzetten van alle Winkels in die Provincie opgeteld hoeven te worden. Voor alle niveaus die in een hiërarchie worden onderkend, worden de totale omzetten berekend en opgeslagen in de fact-table. Op die manier ontstaan aggregatieniveaus waarop gemakkelijk en vooral snel kan worden ingezoomd. Hieronder staat een voorbeeld van een aantal records uit de locatie-dimensie: Locatie# Adres Plaats Provincie Land Niveau 1001 Westerstraat 8 Rotterdam Z-Holland Nederland Adres 1002 Goudsesingel 9 Rotterdam Z-Holland Nederland Adres 1003 Leidseplein 4 Amsterdam N-Holland Nederland Adres 1004 NULL Rotterdam Z-Holland Nederland Plaats 1005 NULL Amsterdam N-Holland Nederland Plaats 1006 NULL NULL Z-Holland Nederland Provincie 1007 NULL NULL N-Holland Nederland Provincie 1008 NULL NULL NULL Nederland Land Deze manier van werken heeft twee nadelen: bij elke query zal voor elk van de dimensies het niveau-attribuut gebruikt moeten worden, om dubbeltellingen te voorkomen (in ieder record op Adres-niveau staat de Provincie, maar het Provincie-totaal heeft ook een eigen record in de dimensie-tabel); bij het toenemen van het aantal dimensies en het aantal aggregatieniveaus groeit de fact-table snel, waardoor deze zeer groot kan worden. Een dimensie-tabel kan ook attributen bevatten die niet binnen de hiërarchie passen maar waarop wel kan worden geaggregeerd. Voorbeelden hiervan zijn Kleur, of TypeDag. Met het attribuut TypeDag kan bijvoorbeeld worden gekeken hoe de omzetten van de maandagen zich verhouden tot de dinsdagen in een bepaalde periode en met het attribuut Kleur kan bijvoorbeeld een stijgende trend worden ontdekt in de verkopen van het aantal bruine schoenen en een dalende trend in de verkopen van het aantal zwarte schoenen. Dit concept verschilt helemaal niet zoveel van de bekende modellen. Het blijft een relationeel model met verschillende tabellen die middels een verwijzende sleutel gekoppeld zijn. Het grootste verschil zit hem in het feit, dat er expliciet onderscheid wordt gemaakt tussen feiten en dimensies, waardoor het mogelijk is de gegevens multidimensioneel te presenteren