Inleiding
Wanneer een organisatie begint met business intelligence (BI), komt vroeg of laat dezelfde vraag naar voren: Is een data warehouse noodzakelijk voor onze BI-oplossingen, of kunnen we zonder?
Of u nu aan het begin staat van een BI-traject of al meerdere oplossingen hebt geïmplementeerd – soms is het nodig om eerdere keuzes opnieuw te evalueren.
Zoals in elk vakgebied, zijn er binnen BI en datawarehousing continue ontwikkelingen. Enkele actuele trends die invloed hebben op deze discussie:
- Snellere time-to-market: De wens om sneller BI-oplossingen op te leveren.
- Data-virtualisatie: Is fysieke verplaatsing van data nog wel nodig?
- In-memory oplossingen: Kunnen we met in-memory technologie sneller toegang tot data krijgen?
De keuze: wel of geen data warehouse?
Om te beoordelen of een data warehouse nog relevant is, is het goed om terug te gaan naar de oorspronkelijke gedachte erachter. We nemen hierbij de definitie van Bill Inmon als uitgangspunt:
A data warehouse is a subject-oriented, integrated, non-volatile, and time-variant collection of data in support of management’s decision-making process.
Twee sleutelbegrippen uit deze definitie zijn voor ons van belang: non-volatile en integrated.
- Non-volatile verwijst naar de mogelijkheid om naar data te kijken vanuit een historisch perspectief – met de bril van toen of die van nu. Dit is niet vanzelfsprekend beschikbaar in elke operationele applicatie.
- Integrated benadrukt dat organisaties vrijwel nooit met één bron (zoals alleen een ERP-systeem) werken. Het combineren van data uit meerdere bronnen, inclusief het afstemmen van masterdata, blijft essentieel.
De conclusie? Ondanks technologische vooruitgang kunnen we vandaag de dag nog steeds niet zonder een data warehouse.
Het is cruciaal voor het betrouwbaar integreren van data én voor het historisch analyseren ervan. En hoewel populariteit geen doorslaggevend argument is, blijft het feit dat vrijwel alle grote BI-leveranciers een centrale rol toekennen aan het data warehouse in hun architecturen, veelzeggend.
De vier fasen van de architectuur
Als we kiezen voor een data warehouse, dan is de volgende vraag: In welke vorm nemen we het op in onze architectuur? En hoe spelen we in op de actuele ontwikkelingen en trends?
Daarvoor gebruiken we een gelaagde architectuur, opgebouwd in vier fasen – zoals weergegeven in onderstaande figuur.
Vier lagen binnen de datawarehouse-architectuur
Laag 1: Staging area
In deze eerste laag worden relevante gegevens tijdelijk opgeslagen voordat ze verder verwerkt worden. Hier vindt optioneel een eerste kwaliteitscontrole plaats om de bruikbaarheid van de data te beoordelen.
Belangrijk uitgangspunt: álle data die binnenkomt, moet volledig verwerkt kunnen worden in de volgende stappen.
Laag 2: Historical data area (source data warehouse)
In deze laag worden ruwe gegevens uit de bronsystemen vastgelegd. Belangrijke kenmerken zijn de registratie van wijzigingen met geldigheid van en tot datum. Deze laag fungeert als het historisch geheugen van de organisatie – onmisbaar voor terugkijken in de tijd.
Laag 3: Business data warehouse
Hier wordt de data getransformeerd volgens een generiek, bronsysteemonafhankelijk model. Dit model kan gebaseerd zijn op bijvoorbeeld derde normaalvorm (3NF) of een data vault-structuur.
Terminologie wordt geharmoniseerd en vertaald naar businessdefinities. Dit is de laag waarin bronspecifieke data wordt omgevormd naar eenduidige informatie.
Laag 4: Data marts (dimensionele laag)
De laatste laag is geoptimaliseerd voor eindgebruikers. Gegevens worden aangeboden in een dimensioneel model (zoals ooit bedacht door Ralph Kimball), gericht op eenvoudige en snelle analyses door de business.
ELT-aanpak
Deze vierlaagse architectuur impliceert een ELT-aanpak:
Extract – Load – Transform. Ruwe data wordt eerst geladen en daarna pas getransformeerd in het data warehouse zelf. De transformatie vindt voornamelijk plaats tussen laag 2 en 3.
Snelle time-to-market & automatisering
Een gelaagde datawarehouse-architectuur lijkt op het eerste gezicht haaks te staan op de wens om snel BI-oplossingen op te leveren. Toch hoeft dat geen belemmering te zijn.
Door strikt eenmalig een stappenplan te volgen en daarin te standaardiseren, wordt hergebruik mogelijk.
Standaardisatie maakt automatisering mogelijk, zoals het genereren van ETL-code. Dit versnelt niet alleen de ontwikkeling, maar verhoogt ook de kwaliteit en voorspelbaarheid van BI-oplossingen.
Data virtualisatie: slim omgaan met beweging van data
Data virtualisatie voorkomt het fysiek verplaatsen van data tussen lagen. Binnen deze architectuur zijn er vooral kansen voor virtualisatie in laag 4 – de data mart-laag.
Daar zijn gegevens al beschikbaar in de juiste terminologie en businesslogica. Virtualisatie biedt hier snelheid én minder ontwikkelwerk.
In laag 3 zijn er beperkt mogelijkheden. Hoewel technisch haalbaar, maakt de complexiteit van dataintegratie (zoals metadata, transformaties en masterdata) het in de praktijk lastig.
Voor laag 1 en 2 wordt virtualisatie sterk afgeraden. Deze lagen bevatten ruwe, onbewerkte data. Afhankelijk zijn van bronsystemen die direct benaderd worden zonder tussenopslag brengt risico’s met zich mee voor de beschikbaarheid en betrouwbaarheid van BI-oplossingen.
In-memory oplossingen: snelheid waar mogelijk
In-memory technologie biedt hoge verwerkingssnelheid doordat data direct in het geheugen beschikbaar is. Gecombineerd met virtualisatie vormt dit een krachtig duo voor snelle BI.
Maar ook hier geldt: er moet altijd een plek zijn waar gegevens fysiek beschikbaar blijven – als vaste basis voor analyses, historische vergelijking en herhaalbaarheid.
Conclusie
Een data warehouse blijft anno nu onmisbaar.
Het biedt de robuustheid die nodig is voor betrouwbare analyses, integratie van bronnen en historisch inzicht.
Tegelijkertijd kunnen moderne technieken als data virtualisatie, in-memory oplossingen en automatische ETL-generatie bijdragen aan kortere doorlooptijden en snellere analyses.
Door slim te combineren ontstaat een toekomstbestendige BI-architectuur die zowel krachtig als wendbaar is.