Het ideale datawarehouse ofwel gegevenspakhuis bevat alle gedetailleerde historische gegevens over de gehele organisatie. Deze gegevens worden regelmatig gedestilleerd uit produktiedata, die in eerste instantie zijn gecreëerd door de diverse applicaties. Daarnaast kan het pakhuis relevante gegevens uit externe bronnen bevatten.
Een volwassen pakhuis wordt gevoed met een continue stroom gegevens. In de beginfase is het echter moeilijk om alle bruikbare oude transactiegegevens te verkrijgen. Men moet eerst inzicht in de gegevens krijgen, een meta-database ontwikkelen en eigendomskwesties oplossen. Daardoor kan het ideale bedrijfsbrede gegevenspakhuis pas na lange tijd produktief zijn. Een compleet centraal pakhuis moet worden gezien als een essentieel bedrijfs-activum. De organisatie zou het daarom moeten financieren uit strategische fondsen. De kans is echter klein om op hoog niveau ondersteuning en budget voor zo’n systeem te krijgen, omdat het rendement ervan nooit makkelijk te meten zal zijn.
De meest voor de hand liggende financieringsbronnen zijn specifieke projecten, eenvoudigweg omdat dan de schaal kleiner is en de potentiële opbrengsten beter te analyseren zijn. Een pakhuis voor specifieke doeleinden zal nooit alle bedrijfsgegevens bevatten, maar slechts een deelverzameling. Voor zo’n deelpakhuis bestaat nog geen vaste term; ik stel het begrip ‘datamarkt’ voor. In de praktijk begint een compleet gegevenspakhuis altijd als een datamarkt.
De kans is groot dat er meerdere datamarkten ontstaan voordat een organisatie middelen voor een strategisch bedrijfspakhuis beschikbaar stelt. Bovendien zullen datamarkten beter presteren dan volledige pakhuizen, al zijn ze niet geschikt voor complexe queries die diverse disciplines betreffen. Overigens zullen sommige datamarkten ondanks hun beperkte scope zeer groot zijn.
In verband met de prestaties ontstaat nog een niveau. Individuele medewerkers selecteren met behulp van query-tools significante deelverzamelingen van gegevens en laden deze op de PC voor lokale verwerking. Ze kunnen die gegevens naar believen veranderen (‘wat als’-simulatie). Doorgaans worden zulke data regelmatig weggegooid en ververst. Ze kunnen direct aan produktie-databases onttrokken worden, maar het is praktischer om ze uit een pakhuis-achtig systeem te halen, omdat de ruwe gegevens daar al geschoond en gestructureerd zijn.
De meeste pakhuizen en datamarkten gebruiken speciaal ontworpen relationele database-technologie. Er bestaan echter ook gespecialiseerde produkten voor meerdimensionale analyse, zoals SAS en Essbase. Deze systemen halen hun gegevens eveneens uit diverse produktiebronnen. Het zou echter makkelijker zijn als de data uit een centraal pakhuis kunnen komen. In veel gevallen is een meerdimensionaal Olap-systeem geschikter voor een datamarkt dan een relationele database.
Het ideale pakhuismodel kan dus veel complexer zijn dan één centraal pakhuis. Het kan bestaan uit vier in plaats van drie lagen. Aan de top voeden produktiesystemen gegevens aan een grootschalig rdbms, het centrale pakhuis. Op dat niveau worden de gegevens geschoond en gestructureerd. Op het derde niveau krijgen de diverse datamarkten hun gegevens, niet van produktiesystemen, maar vanuit het centrale pakhuis. Er is één centraal rdbms-pakhuis met diverse datamarkten, die afgestemd zijn op de behoeften van specifieke bedrijfsonderdelen. Om ze te laten aansluiten op veranderende omstandigheden kan de organisatie datamarkten verwijderen en toevoegen.
Op het onderste niveau bevinden zich de gebruikers met, vooralsnog, PC’s. Doorgaans gebruiken ze query-tools die vanuit de datamarkten gevoed worden, maar sommigen zullen directe toegang tot de centrale systemen nodig hebben. Anderen zullen gegevens extraheren en downloaden, en zo in feite een single-user datamarkt vormen.
Als zo’n prachtige architectuur te financieren is, ontstaat een krachtig en flexibel maar tegelijkertijd kostbaar systeem. Als de structuur er eenmaal is, kan men denken over een toekomst waarin de centrale database direct wordt geactualiseerd met transactiegegevens en veel bestaande applicaties te vervangen zijn. Dit is een evolutionaire benadering die in schril contrast staat met zijn onpraktische tegenhanger, het direct modelleren van de produktie-databases. Het kan zelfs nog praktischer zijn om een andere stap in de evolutie te volgen: het verbouwen van sommige produktiesystemen, om ze geschikt te maken voor het gebruik van een gemeenschappelijke ‘opslagplaats voor operationele gegevens’. Hierin worden gedetailleerde lees/schrijf-gegevens voor de middellange termijn opgeslagen voordat het pakhuis gevuld wordt. Doel is de produktiesystemen, de operationele systemen en het pakhuis op den duur tot één systeem te laten samensmelten.
We worden daarbij geconfronteerd met een frustrerend probleem: hoe realiseren we deze utopie als we met bestaande produktiesystemen moeten werken en aanvankelijk alleen budget voor kleine datamarkten krijgen?
