De probleemgebieden bij datawarehousing

'Datawarehouse volwassen als het de terabyte overschrijdt'

De behoefte aan informatie houdt gelijke tred met de ontwikkeling van informatiesystemen. De vraag daarbij is wat wat aanstuurt: is het 'customer need' of 'technology push'? Data-informatiesystemen worden steeds belang-rijker en daarmee ook steeds omvangrijker. Het voordeel van het vergaren van al die data komt pas goed tot zijn recht wanneer er relaties gelegd kunnen worden tussen de data uit verschillende informatiesystemen; iets dat pas goed mogelijk wordt als wordt overgegaan op 'dataware-housing'. Net als bij een 'normaal' logistiek systeem, moet ook bij datawarehousing van tevoren goed worden nage-dacht over wat wordt opgeslagen, hoe het wordt opge-slagen en met welk doel we het gaan opslaan. Eénmaal gemaakte keuzes voor een bepaalde systematiek hebben immers een weerslag op toekomstige modificaties.

In iedere organisatie wordt informatie verzameld: productinformatie, klantinformatie, verkoopinformatie, marketing-informatie enzovoort. Vaak leidt dit tot een grote diversiteit aan informatiesystematieken en -systemen: iedere afdeling bouwt zijn eigen data-eilandje en het bedrijf raakt op een grandioze manier het overzicht kwijt: productie weet niet wat de behoeften van sales en marketing zijn, marketing heeft geen idee hoe de logistiek draait, de facturatie krijgt gegevens van sales, maar weet niet hoeveel producten daadwerkelijk zijn uitgeleverd en hoeveel orders nog wachten op uitlevering... De oplossing ligt natuurlijk voor de hand: koppel al die systemen. Mocht dat niet haalbaar zijn, maak dan een groot nieuw systeem waar al die afzonderlijke systemen in worden ondergebracht of kies ervoor de data uit al die afzonderlijke systemen in een grote, nieuwe database, een 'datawarehouse', onder te brengen.

Het klinkt logisch en ook wel gemakkelijk, maar de praktijk is weerbarstig. Rien Matthijsse, directeur van Marobi, Oracle-specialist en iemand met veel ervaring op het vlak van dataware-housing, gaf er voor Centor's Oracle-specialisten een presentatie over. Het Orakel beperkt zich in dit artikel echter tot een inventarisatie van de meest voorkomende problemen.

Probleemgebied 1: De eindgebruiker
Wanneer je met eindgebruikers praat, blijkt vaak dat ze niet weten wat ze willen. Ze hebben geen idee wat de potentie van de reeds bestaande operationele systemen is, want het probleem is juist dat ze dat overzicht verloren hebben. Met andere woorden de 'initial requirements' zijn vaak uiterst vaag.

Een bijkomend probleem is dat, als eindgebruikers al weten wat ze willen, ze gaandeweg de formulering van hun informatiebe-hoefte en het bouwen van het systeem, steeds meer willen.
De ervaring is dat wanneer een datawarehouse on-line wordt gebracht er al een hele stapel wijzigingsverzoeken ligt te wachten, want 'we wisten niet dat dát ook kon, maar dan willen we dat natuurlijk ook'. Een tweede val waar ontwikkelaars in kunnen trappen is dat het systeem al begint te groeien voordat het goed en wel geïmplementeerd is: 'Als je toch bezig bent, zou je dan...'
De ervaring leert dat je, wanneer je éénmaal begint met bouwen, blijft bouwen.

De beheerders en gebruikers van de operationele systemen, die data leveren aan het datawarehouse, hebben vaak niet in de gaten dat een wijziging in hun systeem gevolgen heeft voor het centrale systeem. Er komt bijvoorbeeld een nieuwe versie van de database-software uit en zonder zich te realiseren dat een gewijzigde manier van opslag van de records grote gevolgen kan hebben voor het centrale systeem wordt de nieuwe versie geïmplementeerd. Wat ook gebeurt, is dat plotseling een extra veldje in de records verschijnt ('dat is toch wel handig') of verdwijnt ('gebruikten we toch niet'). Dat soort wijzigingen en aanpassingen resulteert in grote problemen in het dataware-house: informatie is niet meer volledig, de volgorde van de velden wordt omgedraaid enzovoort. Zo kun je bezig blijven...
De consequentie van één en ander is – en daar zijn nog te weinig bedrijven zich van bewust –- dat het onderhoud van bestaande datawarehousing-systemen vaak duurder is dan het initiële bouwtraject.
Vaak ook is er sprake van een 'muur' tussen de IT-mensen en de rest van de business; dat hoeft geen opzet te zijn, maar is meestal het gevolg van elkaar niet begrijpen. Het grote probleem is dat je elkaar bij het opzetten van een datawarehouse nu juist wél moet begrijpen.

Probleemgebied 2: Definities van terminologie
Wat is wat? Het lijkt een obligate vraag, maar het antwoord op deze vraag levert in de praktijk vaak problemen op. Wat is bijvoorbeeld een 'klant'? De afdeling Verkoop denkt bijvoorbeeld aan iets totaal anders wanneer zij het woord 'klant' bezigen, dan iemand van de logistieke afdeling. Voor een verkoper is het adres de plaats waar hij met de auto naartoe rijdt om een verkoopge-sprek te voeren. Voor de logistieke medewerker is het adres het afleveradres waar het pakketje naar toe moet en voor de facturatie is het adres de postbus waar de factuur naartoe moet worden gestuurd.

Probleemgebied 3: Key-management
Ieder record dat wordt geproduceerd heeft een sleutel, waaraan het te herkennen is. De keuze voor een sleutel-systematiek is structureel. Want dat is iets wat je niet zomaar na drie maanden nog even wijzigt. Over het antwoord op de vragen 'Welke sleutel of sleutelsystematiek gaan we toepassen, een productie-key of een artificiële key? En hoe gaan we het doen, sequentieel, at random?' moet heel goed worden nagedacht, want iedere keuze heeft zijn consequenties. Wanneer bijvoorbeeld wordt gekozen voor een productie-key en op termijn wil men de ontwikkelingen in de tijd van een bepaald product gaan volgen en in kaart brengen, stuit men op grote problemen.

Probleemgebied 4: Datamanagement
Bestaande informatie wordt regelmatig gewijzigd: een klant verhuist en krijgt een nieuw adres of gaat trouwen en krijgt niet alleen een nieuw adres maar ook een andere naam. Nu zijn dit nog voor de hand liggende voorbeelden, maar het kan natuurlijk veel geniepiger: er wordt een andere schrijfwijze gehanteerd, iets wat voorheen met een 'c' werd geschreven wordt nu met een 'k' vermeld…
Wanneer de consequenties van dergelijke modificaties en wijzigingen niet goed worden overdacht, is er sprake van een enorme vervuiling van je systeem. En dat niet alleen; wanneer gegevens slechts in één van de operationele systemen worden gewijzigd is het leed niet te overzien. De beheerder van het datawarehouse moet dan gaan zoeken wanneer en op welke manier de wijzigingen zijn opgetreden. Daarbij kan het nodig zijn één en ander tot op recordniveau uit te zoeken. Vaak hebben records bijvoorbeeld een tijdsaanduiding – zodat je kunt nagaan wanneer de wijzigingen voor het eerst optraden – maar soms ook niet en moet worden teruggegaan tot de transactielogs van de operationele systemen. Ga er maar aan staan.

Een ander probleem in dit kader staat bekend als de 'slow moving dimensions'. Stel dat één of een aantal klanten overgaat van de ene verkoper naar de andere. Op zich geen probleem, want in de data van de klant wordt de naam van de account-manager gewijzigd. Maar nu vindt die wijziging plaats op 15 oktober en de stand op 31 december is bepalend voor de hoogte van de bonus van de verkopers. De eerste tien maanden omzet die de betreffende klant heeft opgeleverd moet ten gunste komen van de verkoper die van 1 januari tot en met 14 oktober verant-woordelijk was voor de klant en de periode van 15 oktober tot en met 31 december van de andere verkoper. Dergelijke wisselingen moeten natuurlijk wel traceerbaar blijven.

Probleemgebied 5: Integratie
Het zijn natuurlijk met name de grote bedrijven die behoefte hebben aan datawarehouses. Vaak gaat het daarbij om moedermaatschappijen die diverse dochters 'onder zich hebben hangen'. Dan praat je niet meer over een logistiek systeem, een verkoopsysteem en een facturatiesysteem waarvan de data moet worden verzameld en gekoppeld, maar over vijf of tien logistieke systemen en evenzoveel verkoop- en facturatiesystemen. Wanneer datamanagement voor systemen binnen één bedrijf al een issue is, zal duidelijk zijn dat bij implementatie van een gezamenlijk datawarehouse voor een aantal werkmaatschappijen datamanagement een Issue met een hoofdletter is. Vaak hebben de werkmaatschappijen een eigen uniek klantenbestand en is er weinig overlap met klanten van andere werkmaatschappijen, maar je kunt wachten op de vraag om een totaaloverzicht van alle klanten, waarbij – aan de hand van bijvoorbeeld een RFM-analyse (Recency, Frequency, Monetairy) – een klantanalyse moet worden gemaakt. Dan moet je alle data met elkaar in verband brengen en weet je zeker dat klant P.G. Jansen van de ene werkmaatschappij dezelfde is als klant P.G. Jansen van de andere werkmaatschappij?

Probleemgebied 6: Datamodelling
De vraag bij datamodelling is 'Moeten we normaliseren of niet?' Welke afwegingen moeten hiervoor worden gemaakt? Het belang daarbij is 'consistentie'. Die consistentie kan vele malen beter worden gewaarborgd in een genormaliseerde database dan in een niet-genormaliseerde database. Maar aan de andere kant kan met een niet-genormaliseerde database enorme perfor-mance-winst worden geboekt. Bij datamodelling geldt de formule 'tijd x ruimte = constant'. Als je te maken hebt met een tijd-kritisch systeem, zul je kiezen voor een niet-genormaliseerde database, maar dat kost wel meer geheugenruimte. Is geheugen-ruimte echter een probleem en tijd minder, kies dan voor een genormaliseerde manier van inrichten van je database.

Wanneer een goede analyse van de business wordt gemaakt, ligt het datamodel natuurlijk redelijk voor de hand, maar er is geen éénduidige keuze.

Probleemgebied 7: De operatie
In een datawarehouse kunnen met gemak tien miljard records voorkomen. Wanneer je op dat soort enorme tabellen bijvoor-beeld tien indexen moet onderhouden, heb je een probleem. Die tien indexen zijn niet te onderhouden en de update-inserts wor-den veel te duur. Een oplossing die daarbij wel gebruikt wordt is eerst alle indexen 'droppen', dan het werk op de betreffende entiteit uitvoeren en vervolgens alle indexen weer 'rebuilden'. Zeker bij het indexbeeld van Oracle is daarbij winst te behalen.

Een ander probleem is de back-up. Wanneer een datawarehouse-systeem 1,2 terabyte aan data heeft, is het maken van een back-up natuurlijk een onuitvoerbare opgaaf. Maar als je niets doet aan opschoning van de bestanden blijft het bestand continu groeien. Dit is een probleem dat over het algemeen vergeten wordt. Er mag data uit, sterker nog er móet data uit. Maar er zijn zelfs databases waarin wel een 'insert'- en 'modify'- maar geen 'delete'-voorziening is opgenomen. Wanneer als eis wordt gesteld dat alle data tien jaar bewaard en toe-gankelijk moet blijven, kan met een gerust hart elf jaar oude data worden verwijderd. Hóe de data wordt weggegooid is een probleem op zich. Zeker wanneer aggregaten worden bijge-houden. Wat moet er uit de aggregaten worden weggegooid? Of moeten aggregaten helemaal opnieuw gebouwd worden?

Hetgeen in dit artikel behandeld is, is verre van volledig. De dagelijkse praktijk stelt ons telkens weer voor verrassingen. En eigenlijk moeten we bekennen dat dát misschien wel de charme van het vak is: problemen oplossen, die in de begintijd van het programmeren wel eens zijn omschreven als 'een olifant achteruit door het oog van een naald sturen', geeft de Oracle-specialist natuurlijk meer bevrediging dan wanneer deze simpel op een knop moet drukken en het programma wordt geïnstalleerd. Gezien de behoefte aan informatiesystemen en de complexiteit van de problematiek, zullen we - ondanks alle goede instrumen-ten die ons ten dienste staan - voorlopig nog wel olifanten achteruit door zo'n heel klein, miniem oogje moeten sturen.