Data warehousing
Hogeschool voor Economische Studies Rotterdam
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
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.
Inhoudsopgave pag. Inleiding
5
1
De behoefte aan een data warehouse
7
1.1
Informatiesystemen
7
1.2
Informatiebehoefte
8
1.3
Aanleiding tot een data warehouse
9
2
3
4
Het data warehouse
10
2.1
Algemene omschrijving
10
2.2
Specifieke kenmerken
11
De schakels van het data warehouse
13
3.1
Ontsluiting bronsystemen
14
3.2
Copy management
15
3.3
Gegevensopslag
17
3.3.1
De gegevensstructuur
17
3.3.2
Het DBMS
23
3.4
Metagegevens
28
3.5
Beveiliging
29
3.6
Front end
30
Conclusie en aanbeveling
31
Begrippenlijst
33
Literatuurlijst
36
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 *) en niet vluchtig *) zijn. 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-
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.
-6-
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).
-7-
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. 444-445). 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-
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.
-9-
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.
- 10 -
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
- 11 -
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).
- 12 -
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.
- 13 -
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.
- 14 -
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;
- 15 -
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.
- 16 -
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 3.3.1. 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 3.3.2. 3.3.1 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.
- 17 -
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.
- 18 -
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.
- 19 -
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.
- 20 -
Als de informatiebehoefte van de manager vanuit de traditionele benadering wordt gemodelleerd, zal er waarschijnlijk een gegevensstructuur ontstaan die sterk op een sterschema zal gelijken. Het grootste bezwaar hiertegen is echter dat dan het expliciete onderscheid tussen feiten en dimensies ontbreekt. Een tweede verschil zit in het feit dat afgeleide gegevens en aggregatieniveaus binnen een ster-schema voorberekend opgeslagen worden en in het feit dat er een niveau-attribuut is, waarmee wordt aangeven op welk aggregatieniveau de feiten moeten worden bekeken. Op die manier kunnen strategische vragen op de snelst mogelijke manier worden beantwoord, zonder dat er enig rekenwerk wordt verricht. Het betekent echter wel een hoge mate van redundantie, wat in een genormaliseerde structuur uit den boze is. Uit het voorgaande blijkt dat het modelleren volgens een ster-schema een aantal voordelen heeft bij het leveren van managementinformatie uit een data warehouse, waarbij er een performance kan worden geleverd, die met andere methoden niet gerealiseerd kan worden. Hierbij moet echter wel een aantal kanttekeningen worden geplaatst, waar in de literatuur geen of te weinig aandacht aan wordt besteed: Ieder artikel en ieder boek dat stilstaat bij gegevensmodellering voor een data warehouse geeft het standaardvoorbeeld: omzet per product, per regio en per tijdseenheid. Dit voorbeeld ziet er goed uit, is reëel als er sprake is van een warenhuisketen en is voor eenieder gemakkelijk te begrijpen. Het is alleen jammer dat het in werkelijkheid allemaal iets minder makkelijk in een mooi standaardmodel past. De vele varianten en uitzonderingen op varianten maken het opstellen van het (o zo mooie) concept een stuk lastiger. Enkele voorbeelden van problemen en uitzonderingen die kunnen spelen bij het opstellen van een ster-schema, zijn: - minder mooi te definiëren hiërarchieën, - optionele dimensionaliteit (Omzet hoort nu eenmaal altijd bij een bepaald Product, en is altijd gerealiseerd op een bepaalde Plaats en altijd op een bepaald Tijdstip. Feiten kunnen niet altijd allemaal even mooi naar alle dimensies herleid worden), - feiten die slechts naar één dimensie te herleiden zijn (tijd), vanwege het feit dat er op operationeel niveau geen koppeling is te leggen naar andere dimensies. De literatuur die op dit moment voorhanden is, komt aan deze en andere (toch wezenlijke) vraagstukken niet tegemoet. Het kan voorkomen dat de fact-table of één van de dimensie-tabellen zó groot wordt, dat dit weer ten koste gaat van de performance. Hiervoor zijn weer oplossingen - 21 -
verzonnen, welke neerkomen op het opdelen van tabellen die te groot zijn geworden. Hierdoor ontstaan afgeleide vormen van het ster-schema (‘fact-constellation’ of ‘snowflake-schema’). Het gaat echter te ver om hierop in te gaan. Deze afgeleide vormen zullen het opstellen van de gegevensstructuur niet vergemakkelijken en het opsplitsen van de tabellen zal de begrijpelijkheid en onderhoudbaarheid van het model niet ten goede komen. Normaliseren van systemen op operationeel niveau is volledig uitgekristalliseerd en als er op dit gebied vragen of problemen zijn, kan vrijwel iedere informaticus om hulp worden gevraagd. Het multidimensioneel modelleren voor een data warehouse wordt overal genoemd als een ‘must’, maar er is binnen het bedrijf niemand die er ervaring mee heeft. Dit gebrek aan ervaring en het feit dat het concept nog in de kinderschoenen staat, kan de ontwerper opbreken op het moment dat hij tegen de bovengenoemde uitzonderingssituaties aanloopt. Er zou al ervaring aanwezig moeten zijn alvorens er een start wordt gemaakt met het ontwerp van het data warehouse. Een manager op strategisch niveau zal ongetwijfeld een informatiebehoefte uit kunnen spreken, waaruit een aantal feiten en dimensies herleid kan worden. Het blijft echter de vraag of de gegevens en de nodige koppelingen hiertussen op operationeel niveau wel aanwezig zijn. Leveranciers van front end-producten claimen dat hun product een ster-schema ondersteunt en tijdens de presentaties wordt dit ook geïllustreerd. Het is echter niet zeker of het product het ster-schema nog steeds vlekkeloos ondersteunt op het moment dat er geen sprake is van het geijkte voorbeeld, maar van een wat gecompliceerder model. Dit zijn aandachtspunten waarbij moet worden stilgestaan alvorens wordt begonnen met het ontwerp van het data warehouse. Vanwege het feit dat er binnen het eigen bedrijf geen ervaring is met multidimensionele modelleringstechnieken en vanwege het feit dat de literatuur op dit gebied tekort schiet, is het wellicht verstandig eens te rade te gaan bij bedrijven die er al wel ervaring mee hebben opgedaan.
- 22 -
3.3.2 Het DBMS Een opgestelde gegevensstructuur wordt doorgaans geïmplementeerd in een relationele database met een Relationeel DataBase Management Systeem (RDBMS). Hieruit kunnen gegevens worden opgevraagd met behulp van SQL. SQL heeft echter een aantal beperkingen. Zo is het moeilijk om te vragen wat de drie best verkopende producten van de afgelopen periode waren en is het nagenoeg onmogelijk ad hoc complexe analyses uit te voeren (What-If Analysis). Een verzamelnaam voor het online uitvoeren van deze analyses is OnLine Analytical Processing (OLAP *)). Als er een data warehouse wordt gebouwd voor het voorzien in managementinformatie, zijn dit toch wezenlijke informatiebehoeften. Nu kan er als alternatief voor een RDBMS voor een MultiDimensioneel DataBase Management Systeem (MDDBMS) gekozen worden. Met een MDDBMS kunnen deze complexe analyses wél worden uitgevoerd. Leveranciers van MDDBMS’sen claimen dan ook dat het MDDBMS bij uitstek geschikt is voor het data warehouse. Om een keuze te kunnen maken tussen een RDBMS en een MDDBMS zijn er een enkele eigenschappen van het MDDBMS van belang, die door de leverancier van het product niet benadrukt zullen worden. Om de keuze te kunnen maken, moet bovendien het onderscheid bekend zijn tussen de verschillende vormen van OLAP. Alvorens wordt ingegaan op de eigenschappen van het MDDBMS, zal ingegaan worden op deze vormen van OLAP. Als er wordt uitgegaan van de volgende informatiebehoefte: ”omzet per regio per product per tijdseenheid,” kan dat als volgt multidimensioneel (als ‘kubus’) weergegeven worden. Er zijn drie dimensies en op elke kruising van de dimensies (ieder blokje) staat de omzet.
Afbeelding 5: Informatiebehoefte van de manager weergegeven als kubus
- 23 -
Deze kubus kan vervolgens op diverse manieren worden doorgesneden. Een regiomanager zal geïnteresseerd zijn in de omzetten per product per tijdseenheid voor zijn regio en een productmanager zal geïnteresseerd zijn in de omzetten per regio per tijdseenheid voor zijn product. Deze informatiebehoeften leiden tot de volgende doorsneden:
Afbeelding 6: Verschillende doorsneden van de kubus
Het uitvoeren van dergelijke analyses en het in- en uitzoomen op bepaalde gegevens wordt gevat onder de noemer OLAP. Er zijn verschillende verschijningen van OLAP, verschillende manieren waarop het technisch gerealiseerd kan worden. Deze zullen hieronder kort omschreven worden: Relational OLAP:
Techniek waarmee een multidimensionele ‘view’ wordt gelegd op een RDBMS, ongeacht de onderliggende gegevensstructuur (een aantal ROLAP-producten vereist echter wél een ster-structuur).
Hybrid OLAP:
Techniek waarmee gegevens in een RDBMS in verregaande mate worden gekoppeld aan een MDDBMS, waarbij op basis van bevragingen de gegevens dynamisch van het RDBMS in het MDDBMS worden geladen.
Desktop OLAP:
Speciale vorm van OLAP, waarbij het aantal analysemogelijkheden beperkt is, omdat ze lokaal worden uitgevoerd. Hierbij worden de benodigde gegevens uit een DBMS gelezen en fysiek op het desktop in een kubus opgeslagen. Op de data in de lokale kubus kunnen de analyses worden uitgevoerd.
Multidimensioneel OLAP: Wordt ook wel Specialised OLAP genoemd. Techniek waarbij alle gegevens fysiek in een multidimensionele database liggen opgeslagen. De verschillende analyses worden direct op het MDDBMS uitgevoerd, zonder dat er een RDBMS aan te pas komt. (Gartner Group CD-Rom: “The four styles of OLAP: The relational approach”, Gartner Group CD-Rom: “The four styles of OLAP: Multidimensional Databases”)
- 24 -
Bij ROLAP en HOLAP liggen de brongegevens voor de analyse dus fysiek opgeslagen in een RDBMS. In de andere twee gevallen liggen de voor de analyse benodigde gegevens fysiek in een MDDBMS opgeslagen. De te kiezen vorm van OLAP is afhankelijk van de complexiteit van de uit te voeren analyses en de eisen die bij het uitvoeren van de analyses aan de performance worden gesteld. Als er zeer complexe analyses moeten worden uitgevoerd en/of als er hele hoge eisen aan de performance worden gesteld dan zal er voor MOLAP moeten worden gekozen. Als er geen gebruik gemaakt hoeft te worden van de meest complexe analyses, kan worden volstaan met HOLAP en/of ROLAP. Deze afweging wordt in afbeelding 7 zichtbaar gemaakt. Bij deze afbeelding moet vooraf de kanttekening geplaatst worden, dat het de verschillende vormen van OLAP tegen de assen uitzet. Het is echter in eerste instantie de vraag of er wel van OLAP-functionaliteit gebruik moet worden gemaakt. Vaak zal kunnen worden volstaan met query-, of relatief eenvoudige rapportagefaciliteiten. Pas als er behoefte is aan OLAP-functionaliteit, dán geldt (in het onderstaande plaatje) dat in circa 15% van de gevallen (de meest complexe) voor een MDDBMS gekozen moet worden.
Afbeelding 7: Afweging van de te kiezen vorm van OLAP (Gartner Group CD-Rom: “Introducing the four styles of OLAP”) Om gegevens multidimensioneel op te kunnen slaan, moet er een multidimensionele gegevensstructuur aanwezig zijn in termen van feiten en dimensies. De dimensies zijn de assen van de ‘kubus’ en de feiten ‘zitten in de kubus’ op de kruispunten van de dimensies. Als deze structuur er is, kan deze worden opgeslagen in een MDDBMS. Het MDDBMS kent een aantal verschillen ten opzichte van het RDBMS. - 25 -
Een groot verschil tussen een RDBMS en een MDDBMS zit in de manier waarop de gegevens benaderd kunnen worden. Bij een relationele database verwijst de index naar een record, waarbij één record bovendien in meerdere indexen opgenomen kan zijn. Dit leidt tot relatief omvangrijke indexstructuren. Bij een MDDBMS wordt de locatie van de gezochte informatie bepaald op basis van de coördinaten van het snijpunt van de dimensies. De coördinaten van de dimensies bepalen dus rechtstreeks waar de gezochte informatie fysiek ligt opgeslagen, zonder dat er gebruik hoeft te worden gemaakt van een index. Daarnaast liggen de gegevens in een RDBMS anders opgeslagen dan in een MDDBMS. Een RDBMS is record-georiënteerd, waardoor bij het lezen van de omzetten alle records worden geopend (waarin ook vele andere variabelen kunnen staan). Een MDDBMS is daarentegen variabele-georiënteerd wat erop neerkomt dat alle omzetten naast elkaar liggen opgeslagen. Dit scheelt bij het inlezen aanzienlijk in het aantal ‘pages’ dat moet worden binnengehaald. Het MDDBMS biedt de volgende voordelen ten opzichte van een RDBMS. Hogere performance bij het benaderen van de gegevens vanwege het feit dat er geen gebruik hoeft te worden gemaakt van een indextabel en vanwege het feit dat het aantal binnen te halen pages veel kleiner is. Mogelijkheid tot het uitvoeren van complexe multidimensionele analyses die met een RDBMS moeilijk uitvoerbaar zijn (z.g. ‘cross dimensional calculations’). Tegenover deze voordelen staan diverse nadelen van het MDDBMS. Er bestaan alleen producten en geen standaards. Als een bedrijf voor een bepaald product kiest, dan is het wat het front end betreft ook gebonden aan dezelfde leverancier. Relationele databases zijn daarentegen wél uitgekristalliseerd en gestandaardiseerd, waardoor er in principe elk front end op kan worden gezet. Gebruikers en beheerders zijn bekend met het werken met een RDBMS en SQL, maar zijn volledig onbekend met het werken met een MDDBMS. De kruisingen van de dimensies verwijzen fysiek naar de opslagplaats van de informatie. Voor elk kruispunt wordt ruimte gereserveerd, ongeacht het feit of deze wordt gevuld. Zelfs als de database een lage vullingsgraad heeft, is er dus een zeer grote opslagcapaciteit nodig. Om een MDDBMS te gebruiken, moet de informatiebehoefte in multidimensionele structuur worden gegoten. In paragraaf 3.3.1 wordt al aangegeven dat dit niet altijd even gemakkelijk gerealiseerd kan worden.
- 26 -
De structuur is inflexibel: bij het toevoegen van een product moet de gehele database opnieuw worden gegenereerd aangezien de bepaling van de coördinaten verandert en de coördinaten rechtstreeks verwijzen naar de fysieke opslagplaats van de informatie. Een MDDBMS kent vooralsnog een beperkte opslagcapaciteit (tot 100 GB). De voordelen van een MDDBMS worden altijd wel vermeld en hetzelfde geldt voor een deel van de nadelen. Een aantal van de bovenstaande nadelen die aan het licht zijn gekomen, wordt echter nergens genoemd. Bovendien moeten er bij deze voor- en nadelen nog de volgende kanttekeningen worden geplaatst: De ontwikkelingen op het gebied van MDDBMS’sen staan natuurlijk niet stil en het is mogelijk dat bepaalde producten inmiddels een oplossing hebben voor de genoemde nadelen. Bij gesprekken met leveranciers van deze producten zullen deze (en eventueel andere nadelen) boven tafel moeten komen. Er wordt vaak gesteld dat de multidimensionele databases een hogere performance bieden. Er wordt daarentegen ook gezegd dat de vergelijking meestal een vertekend beeld geeft, aangezien de relationele database vaak niet geoptimaliseerd is voor het verschaffen van managementinformatie. Het verschil zal veel minder zijn, wanneer: -
wordt gewerkt met een ster-schema met voorgecalculeerde aggregatieniveaus,
-
gebruik wordt gemaakt van optimale indexeringstechnieken en van integers als automatisch gegenereerde sleutels waarop wordt gejoind.
Bovendien zijn er ontwikkelingen gaande om verbetering te brengen in de tekortkomingen van SQL bij het uitvoeren van analyses. Hierbij kan gedacht worden aan een SQL-extensie als RANK, waarmee de vraag ‘geef de beste tien producten van deze maand’ wel eenvoudig kan worden beantwoord. Behalve de verbeteringen in SQL worden RDBMS’sen ook geoptimaliseerd voor het leveren van managementinformatie. Concluderend kan worden gesteld dat een MDDBMS een groot aantal significante nadelen heeft en slechts in een zeer beperkt aantal situaties toepasbaar is. Het is bij het ontwikkelen van een informatiesysteem dus verstandig om te kiezen voor een RDBMS. Als er sprake is managementinformatiebehoefte met duidelijke feiten en dimensies, kan dat in de vorm van een ster-schema in het RDBMS worden geïmplementeerd, zodat hier toch snel in kan worden voorzien.
- 27 -
3.4
Metagegevens
In de literatuur krijgt het metagegevensbeheer een grote rol toebedeeld. Er wordt gesteld dat het succes van een data warehouse kan vallen of staan met de kwaliteit van de metagegevens. Een goede inrichting van het metagegevensbeheer is bepalend voor de acceptatie en voor de onderhoudbaarheid van een data warehouse. De metagegevens kunnen worden verdeeld in twee categorieën. Ten eerste moet de eindgebruiker van het data warehouse informatie over zijn gegevens uit het data warehouse op kunnen vragen, zodat duidelijk is wat de gegevens betekenen en waar ze vandaan komen. Als de gebruiker van het data warehouse niet in staat is de waarde van de gegevens te achterhalen, dan kan dat de acceptatie van het data warehouse ondermijnen. Ten tweede moeten de beheerders van het data warehouse technische informatie over de gegevens en hun herkomst kunnen achterhalen. Als deze gegevens niet voorhanden zijn, zal dat het beheer en het onderhoud van het data warehouse bemoeilijken. De metagegevens die benodigd zijn, beschrijven de bronsystemen, het transformatieproces, de manier waarop de gegevens liggen opgeslagen en de manier waarop de gegevens door het front end aan de eindgebruiker van het data warehouse worden gepresenteerd. Tijdens elke schakel in de keten van operationele gegevens naar managementinformatie ontstaat dus een deel van de benodigde metagegevens. In veel boeken en artikelen wordt gemeld, dat het ideaal zou zijn als deze verschillende metagegevens geïntegreerd zouden worden opgeslagen, waarbij de eindgebruiker ze online zou moeten kunnen benaderen met het front end. Er is echter nog geen enkel product dat het gehele traject ondersteunt. Voor de verschillende stappen moeten verschillende producten worden gebruikt, die elk op een eigen manier met metagegevens omspringen. Dit gebrek aan integratie wordt onderkend en er is een zogenaamde ‘Metadata Coalition’ opgericht, waarin diverse leveranciers van de benodigde producten zitting hebben. Het valt echter te betwijfelen of deze coalitie hierin zal slagen. Ten eerste bestaan er binnen de coalitie de nodige meningsverschillen en ten tweede maakt een aantal toonaangevende leveranciers geen deel uit van de coalitie. Als er geen goede metagegevens voorhanden zijn zullen kosten van het beheer en onderhoud van het data warehouse hard oplopen, zeker op het moment dat het data warehouse groeit of moet worden afgestemd op een veranderende informatiebehoefte. Zolang de verschillende benodigde producten nog niet met elkaars metagegevens overweg kunnen, blijft het dus noodzakelijk dat alle stappen zorgvuldig worden gedocumenteerd.
- 28 -
3.5
Beveiliging
Beveiliging is belangrijk, aangezien het data warehouse bedrijfskritische gegevens kan bevatten. Desondanks is het een onderwerp waar vaak te weinig aandacht aan wordt geschonken. Zelfs in het whitepaper van het DCC, waar beveiliging toch heel hoog in het vaandel staat, ontbreekt een hoofdstuk beveiliging. Er bestaat een spanningsveld: het data warehouse heeft tot doel de gegevens van het bedrijf te ontsluiten en beveiliging heeft juist tot doel de gegevens af te schermen. Een goede beveiligingsprocedure is essentieel, maar de gebruiker moet er tijdens het grasduinen in het data warehouse zo weinig mogelijk hinder van ondervinden. Beveiliging kan worden gerealiseerd op de traditionele manier: autorisatie voor eindgebruikers die een bepaald gegeven mogen benaderen. Het kan echter ook middels data marts *). Hiermee kan voor bepaalde groepen gebruikers een aparte deelverzameling van het data warehouse worden aangemaakt. Zij kunnen voor het raadplegen van een bepaalde data mart worden geautoriseerd en niet voor het gehele data warehouse. Hierdoor zijn de overige gegevens in het data warehouse automatisch afgeschermd. Een data mart wordt altijd gepresenteerd als een aparte database, die wordt bijgewerkt op het moment dat er veranderingen op de gegevens in het data warehouse zijn. Tijdens een presentatie is echter gebleken, dat met behulp van het front end ‘logische datamarts’ kunnen worden gecreëerd. Hierbij worden er voor verschillende groepen gebruikers verschillende ‘views’ op het data warehouse gecreëerd. Een gebruiker wordt in dat geval geautoriseerd voor een bepaalde ‘view’ en ziet zodoende alleen de gegevens die daarbinnen kunnen worden benaderd. Er moet een afweging worden gemaakt tussen de voor- en nadelen van de verschillende manieren waarop de beveiliging kan worden gerealiseerd. Hierbij zullen met name het karakter van de gegevens in het data warehouse en de gebruikte technologie doorslaggevende factoren zijn. Het is bovendien belangrijk, dat de eindgebruiker zo weinig mogelijk hinder ondervindt van de beveiligingsprocedure en dat de autorisaties efficiënt kunnen worden beheerd.
- 29 -
3.6
Front end
Het front end bepaalt het gebruikersgemak en heeft dus direct invloed op de acceptatie van de gebruiker. De gewenste informatie kan met behulp van een aantal front end-producten zeer mooi worden gepresenteerd. Deze producten zijn daardoor bovendien bij uitstek geschikt om de directie te overtuigen van het nut van een data warehouse. Tijdens presentaties komen de gebreken en de nadelen gewoonweg niet ter sprake. Als een bedrijf de bouw van een data warehouse overweegt, is het belangrijk dat er kennis genomen wordt van de algemene nadelen, alvorens er in zee wordt gegaan met een leverancier. Op die manier kan het gepresenteerde product kritisch worden beoordeeld en kan er meteen worden gevraagd hoe het product omgaat met de nadelen die in de literatuur worden geschetst. In veel gevallen zal de leverancier moeten toegeven dat, ‘die functionaliteit binnen deze versie nog niet wordt ondersteund...’ Het is belangrijk om door de gepresenteerde concepten heen te prikken en alvast te bedenken welke problemen er in de praktijk kunnen spelen. Beweringen dat de manager zélf met het product zou kunnen werken, vallen in de praktijk vaak tegen. Bovendien werken de producten tijdens de presentaties vrijwel altijd met het meest eenvoudige ster-schema (omzet per product per regio per tijdseenheid) en vanzelfsprekend werkt het product daar uiterst soepel en foutloos mee. De vraag is echter wat het product doet op het moment dat de gegevensstructuur niet het meest eenvoudige ster-schema is en er gewerkt moet worden met een data warehouse van enkele Terabytes. Behalve het feit dat er rekening moet worden gehouden met deze aandachtspunten is het belangrijk vooraf te bepalen wie er met het data warehouse moeten gaan werken. Het front end kan een uitgebreid scala aan faciliteiten bieden, maar als de eindgebruiker er geen gebruik van maakt óf kan maken, is er toch een verkeerde afweging gemaakt. De eindgebruiker bepaalt het succes van het data warehouse. Het front end zal de gegevens dan ook moeten presenteren op een manier die aansluit bij de wensen en vaardigheden van de eindgebruiker.
- 30 -
4
Conclusie en aanbeveling
Het kan zo zijn dat een data warehouse een significant voordeel kan leveren voor de managementinformatievoorziening, mits het goed wordt opgezet en geïmplementeerd,. Doordat een data warehouse gegevens geïntegreerd, onderwerpgeöriënteerd aanlevert, waarbij ook nog eens de historie bewaard blijft, kán het een ideale bron zijn om managementinformatie uit te putten zonder dat de operationele systemen daar enige hinder van hoeven te ondervinden. Er is echter een aantal zaken waar zeker rekening mee gehouden moet worden en waar in de praktijk te licht over wordt gedacht. Het gevaar bestaat dat een bedrijf dat zich tot de bouw van een data warehouse laat verleiden, zich alleen laat leiden door de flitsende presentaties van de diverse front end-producten en zodoende het voortraject te weinig aandacht schenkt. Iedere schakel in het traject van transactiegerichte systemen tot managementinformatie verdient evenveel aandacht. Na het zien van de ‘grenzeloze mogelijkheden’ van de front ends mogen de volgende zaken niet uit het oog worden verloren: het ontsluiten van de bestaande operationele systemen, het copy-management van de gegevens uit de bronsystemen naar het data warehouse, het modelleren van de gegevens in het data warehouse, het beheer van de metagegevens, het beveiligen van de gegevens in het data warehouse, het kiezen van het juiste front end waarmee de gegevens worden gepresenteerd. De eindgebruikers van het data warehouse zullen het data warehouse accepteren en gebruiken als er rekening wordt gehouden met hun wensen en met hun werkniveau. Elk van de stappen in de keten van operationele data naar managementinformatie is van invloed op de kwaliteit en de uiteindelijke acceptatie van het data warehouse. Als één van deze schakels niet goed functioneert, kan zelfs het meest geavanceerde front end geen betrouwbare informatie presenteren. Bedenk, een keten is zo sterk als zijn zwakste schakel. Bovendien is het belangrijk te beseffen, dat de literatuur die op dit moment voorhanden is, op een aantal zaken niet diep genoeg ingaat (bijvoorbeeld de manier waarop een sterschema moet worden opgesteld en de problemen die hierbij spelen) en een aantal beperkingen volledig buiten beschouwing laat (bijvoorbeeld de invloed die de komst van een data warehouse heeft op de bronsystemen).
- 31 -
Het feit dat de literatuur tekortschiet bij het aangeven van een aantal valkuilen en het feit dat er in de loop der tijd verschillende succesverhalen zijn gepubliceerd, zorgt voor een te gunstige weerspiegeling van het data warehouse in de literatuur. Door het voeren van discussies en het kritisch aanschouwen van presentaties is mij gebleken dat er diverse belangrijke aandachtspunten een rol spelen. Het is dan ook aan te raden om deze discussie te voeren alvorens er een data warehouse-project wordt gestart. Daarnaast kan er worden gesteld, dat het verstandig is kennis te nemen van de specifieke eigenschappen en technieken van het data warehouse alvorens contact wordt opgenomen met de leveranciers van de benodigde producten. Tijdens de presentaties is mij bovendien gebleken, dat de informatie niet volledig en juist wordt weergegeven. Nadelen en gebreken worden verzwegen, danwel verdraaid, waardoor het lijkt dat het product meer kan dan in werkelijkheid het geval is. Met deze adviezen in het achterhoofd kan een bedrijf zichzelf presenteren als ‘smart buyer’ waardoor de leveranciers minder ruimte hebben de praktijk rooskleuriger voor te stellen dan ze is.
- 32 -
Begrippenlijst Afgeleide gegevens Een gegeven dat kan worden afgeleid van andere gegevens die liggen opgeslagen. Aggregatieniveaus Totalen die worden berekend op verschillende niveaus binnen een hiërarchie. Copy management Het proces waarbij de gegevens uit de bronsystemen in het data warehouse worden geladen. Tijdens dit proces worden de gegevens niet domweg gekopieerd, maar er heeft een transformatieproces plaats, waarmee de gegevens worden geoptimaliseerd voor het data warehouse. Data mart Een voor een specifieke doelgroep aangelegde deelverzameling van het data warehouse. Data warehouse 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 *) en niet vluchtig *) zijn. Direct marketing strategie Marketing strategie op basis van gerichte communicatie, waarmee de doelgroep kan worden benaderd met een aanbod dat al is voorgeselecteerd op hun smaak. Front end het gedeelte tussen het data warehouse en de gebruiker, waarmee de gebruiker de informatie uit het data warehouse kan halen. Geïntegreerd Gegevens uit verschillende bronnen zijn geïntegreerd als gelijksoortige gegevens eenduidig zijn gedefinieerd en zijn afgebeeld op één domein.
GIGO - 33 -
Garbage In Garbage Out: in geval van slechte input, kan er nooit sprake zijn van goede output. Historisch Gegevens zijn historisch als ze zijn voorzien van een tijdsaanduiding van de periode waarin ze geldig waren. Legacy-systeem Een informatiesysteem dat op verouderde wijze is gebouwd, niet flexibel en vaak slecht gedocumenteerd is, waardoor de onderhouds- en exploitatiekosten hoog zijn ten opzichte van de functionaliteit. Metagegevens Gegevens over gegevens. OLTP (OnLine Transactional Processing) Transactionele werking van de operationele productiesystemen met vele, kleine, voorgedefinieerde transacties waarbij relatief weinig gegevens per transactie benodigd zijn (het uitvoeren van een berekening of een controle). OLAP (OnLine Analytical Processing) Geavanceerde techniek waarmee op basis van ad hoc-bevragingen gegevens online uit databases gehaald kunnen worden, waarbij grote hoeveelheden gegevens kunnen worden geanalyseerd. Onderwerpgeoriënteerd Gegevens zijn onderwerpgeoriënteerd als ze zijn opgenomen in een onderwerpgeoriënteerde gegevensstructuur. De gegevens worden per onderwerp (product, regio, merk, winkel, maand, kwartaal) samengevoegd. Read-only ‘Alleen lezen’, niet vluchtig. Ster-schema Een speciale verschijning van een gegevensstructuur, die is gericht op het efficiënt verstrekken van managementinformatie, waarbij er expliciet onderscheid wordt gemaakt tussen feiten en dimensies. Vluchtig - 34 -
Gegevens zijn vluchtig als ze bijgewerkt kunnen worden en dus aan verandering onderhevig zijn. Whitepaper Document waarin een organisatie haar inhoudelijke standpunt met betrekking tot een bepaald onderwerp uiteenzet.
- 35 -
Literatuurlijst Boeken en artikelen 1.
ACHTERSTRAAT, A.N. 1995
“Het gegevensschuurtje dient als pakhuis voor de kleine onderneming” In: Automatisering Gids, 6 oktober 1995, p. 15
2.
FADLALLA, A. 1996
“The advancements of data warehousing” In: Enterprise Systems Journal, oktober 1996, p. 18-24
3.
GILL, H.S. en P.C. RAO 1996
The Official Guide to Data Warehousing Que Corporation, 1996
4.
HAHNKE, J. 1996
“Data model design for business analysis” In: Unix Review, september 1996, p. 35-44
5.
HEUVEL, T VAN DEN, J.H.C. POST en A.L.M. VERBEEK 1991
Basisboek Marketing Wolters-Noordhoff, 1991
6.
INMON, W.H. 1996 a
Building the Data Warehouse Second Edition John Wiley & Sons, 1996
7.
INMON, W.H. 1996 b
“The data warehouse and data mining” In: Communications of the ACM, november 1996, p. 49-50
8.
KIMBALL, R. 1996
The Data Warehouse Toolkit John Wiley & Sons, 1996
9.
KORNEEF, R. en SLOB, D. 1997
“Gegevens veelal kwalitatief onder de maat” In: Automatisering Gids, 7 maart 1997, p. 17
10. KUIJPER, N. en BULSINK, A.J. 1996
“Informatiehuishouding van een data warehouse” In: Database Magazine, mei 1996, p. 25-30
11. POE, V. 1996
Building a Data Warehouse for Decision Support Prentice Hall, 1996
12. WIJNEN, L.W. - 36 -
1995
“Ontwikkeling en invoering van een data warehouse” In: Database Magazine, mei/juni 1995, p. 11-20
Whitepapers 1.
BUSINESS OBJECTS 1996
2.
DUYVERMAN COMPUTER CENTRUM 1996
3.
The IBM Visual Warehouse Solution
ORACLE 1996
5.
Data Warehouse: (on)mogelijkheden voor Defensie
IBM 1996
4.
Data Warehousing: Delivering Decision Support to the many
Oracle Warehouse
QUERCUS 1996
Capturing Dynamic Information Needs of Managers
CD-roms 1.
AUTOMATISERING GIDS 1996
2.
DATAPRO 1996
3.
Your Personal Information Technology Advisor
INFORMATIE 1996
5.
Computer Systems, Hardware & Software
GARTNER GROUP 1997
4.
Electronisch Archief Automatisering Gids 1994 - 1996
Abstracts 1982 - 1990 Artikelen 1991- 1995
ORACLE 1996
Oracle Development and Decision Support Tools
- 37 -
