Wat is een datawarehouse?
"A (data) warehouse is a subject-oriented, integrated, time-variant and non-volatile collection of data in support of management's decision making process."
De bovenstaande definitie van een data warehouse is afkomstig van Bill Inmon, één van de grondleggers van datawarehousing. In de praktijk komt het neer op een database, waarin data wordt opgeslagen voor rapportage en analyse doeleinden. Over hoe zo'n datawarehouse eruit moet zien, bestaan verschillende meningen. De twee bekendste hiervan zijn: de klassieke benadering van Bill Inmon (CIF) en een wat meer modernere aanpak van Ralph Kimball. De term Data Warehouse is voor het eerst gebruikt in 1988.
De kenmerken van een datawarehouse zijn volgens Bill Inmon:
Subject-oriented
Een datawarehouse is subject-oriented. Dit wil zeggen dat data gegroepeerd is per onderwerp en niet per activiteit, zoals dit bij operationele systemen het geval is.
integrated
Data in de verschillende bronsystemen, wijkt vaak af voor wat betreft gebruikte coderingen, dataformaten en data types. Voordat deze data in het datawarehouse geladen wordt, moet ze eerst op elkaar worden afgestemd.
time-variant
Een datawarehouse bevat historische data. Dit betekent dat alle data gelinkt moet zijn aan een bepaalde periode in de tijd. Bovendien moet deze data precies de situatie weergeven zoals deze was op dat moment. In operationele systemen vindt men vaak alleen de situatie van het moment terug, omdat in het geval van wijzigingen bestaande data wordt overschreven.
non-volatile
Data in een datawarehouse is statisch. Men gaat er vanuit dat data, nadat deze in het datawarehouse geladen is, niet meer veranderd.
Verschillende visies
Zoals reeds benoemd, zijn er verschillende visies op hoe een datawarehouse er precies uit hoort te zien. Naast de twee genoemde hoofdstromingen van Ralph Kimball enerzijds en Bill Inmon anderzijds, worden er in de praktijk verschillende varianten geïmplementeerd met combinaties van aspecten uit beide methodieken, aangevuld met allerlei eigen inzichten. Een redelijk bekend voorbeeld is de Data Vault architectuur van Dan Linsted. De Data Vault methodiek is een modelleringswijze voor het ontwerpen voor de centrale datawarehouse, wat zijn oorsprong vindt in het CIF model (Corporate Information Factory) van Bill Inmon. Tegelijkertijd wordt vanuit de Data Vault methodiek geadviseerd om de data marts te modelleren volgens de principes van Ralph Kimball (Dimensioneel Modelleren). Er zijn ook andere methoden beschikbaar voor het modelleren van het centrale datawarehouse binnen het CIF model. Anchor Modelling van Lars Rönnbäck is een voorbeeld hiervan. Bill Inmon heeft enige jaren geleden zijn CIF model herzien en aangepast aan de moderne tijd. Het resultaat hiervan is het z.g. DW 2.0 model. Zoals gezegd, zal men in de praktijk vele verschillende varianten van architecturen vinden, waaronder de genoemde bekende voorbeelden, maar ook vele eigen varianten hierop. Alvorens hier nader op in te gaan, worden hieronder kort de verschillen beschreven tussen de hoofdstromingen.
De Kimball stroming
Ralph Kimball ziet het datawarehouse als een dimensionaal gemodelleerde database voor het ondersteunen van query en analysedoeleinden. Binnen een dimensionaal model wordt in hoofdlijnen onderscheid gemaakt tussen twee soorten data (wat resulteerd in twee soorten tabellen binnen het datawarehouse): dimensies en feiten. Feiten zijn kengetallen over business processen (aantallen, bedragen, berekende waarden, zoals percentages). In plaats van feiten spreekt met ook wel van meetwaarden. Feiten kunnen geaggregeerd worden: het totaal, of de laagste, hoogste, gemiddelde waarde kunnen bepaald worden van de genoemde getallen over een bepaalde selectie (bijvoorbeeld: per klant per week). Dimensies verzorgen de context bij feiten. Zij bevatten kenmerken met betrekking tot de feiten, of met betrekking tot de business entiteiten die gerelateerd zijn aan de feiten, zoals: klanten, producten, locaties, medewerkers.
Het dimensionaal model wordt in het algemeen gezien als een intuïtief model, wat begrepen kan worden door business analisten en gebruikers van rapportages. Door een slimme structuur op te zetten van feiten en dimensies kan een model gemaakt worden waarmee kengetallen die betrekking hebben op verschillende processen gecombineerd kunnen worden op een geaggregeerd niveau, waardoor inzicht ontstaat in de verbanden tussen deze business processen. Kortom het maken van proces overschrijdende rapportages wordt hierdoor mogelijk.
Binnen de Kimball Methodiek, wordt de verzameling van alle feitentabellen en dimensietabellen gezien als het Enterprise Datawarehouse.
Hierbij zijn de volgende voorwaarden van belang:
Binnen de Imon Methodiek wordt het gebruik van dimensies en feiten gezien als een middel (niet het enige middel) om data beschikbaar te stellen aan de business (bij voorkeur geaggregeerd en met een beperkte scope). Binnen deze methodiek worden deze dimensies en feitentabellen niet als datawarehouse gezien, maar als data marts. Deze data marts worden geladen vanuit een centrale datawarehouse laag, welke volledig genormaliseerd is (dus niet uit gedenormaliseerde feitentabellen bestaat).
De Inmon stroming
Volgens Bill Inmon bestaat het datawarehouse niet uit gedenormaliseerde feitentabellen en dimensietabellen, maar uit een centraal genormaliseerd datamodel. Vanuit dit datamodel kunnen datamarts gevoed worden voor verschillende typen business users. Deze datamarts kunnen bestaan uit sterschema's (dimensies en feiten), welke een subset bevat van de totale data geaggregeerd op een bepaald niveau voor die gebruikers groep. Datamarts kunnen ook anders gemodelleerd zijn, en bijvoorbeeld uit platte zelfstandige exports bestaan. De datamarts worden als het ware per gebruikersgroep vervaardigd en afgestemd op de gebruikersgroep. De Inmon architectuur wordt ook wel omschreven als het hub and spoke model.
Welke keuze: Inmon of Kimball?
Er bestaan verschillende meningen over welke van de twee architecturen het beste werkt voor welke situatie. Vaak zijn deze meningen gebaseerd op een persoonlijke voorkeur voor één van beide opties.
Generaliserend kan gesteld worden dat het binnen een hub and spoke architectuur vaak langer duurt om een oplossing op te leveren, omdat er een sterke focus ligt op de backend. Data zal eerst moeten worden geladen vanuit bronnen naar een centraal datawarehouse. Hierbij zal al nagedacht moeten worden over bepaalde integratieregels. Pas als dat klaar is kan begonnen worden met het maken van data marts. Doordat verschillende data marts gebruik maken van dezelfde tabellen in het datawarehouse, ontstaan er weer gemakkelijk allerlei afhankelijkheden. Bij een Kimball architectuur kan vaak sneller een datamart gebouwd worden (lees: feitentabel + dimensies), omdat deze rechtstreeks vanuit de brondata geladen kan worden. Echter het in sneltreinvaart creëren van allerlei data marts kan weer gemakkelijk leiden tot een wirwar van ongedocumenteerde tabellen.
Uiteindelijk is er één grote uitdaging bij het bouwen van datawarehouses en dat is verandering:
- bedrijven moeten zich constant aanpassen om te overleven
- de markt kan veranderen, waardoor producten en diensten moeten veranderen.
- het gevolg is dat business processen veranderen, waardoor systemen mee veranderen
- veranderingen in systemen, betekent verandering in de inhoud of structuur van data in deze systemen
- veranderende omstandigheden, leidt ook tot een andere informatiebehoefte van managers
Een datawarehouse architectuur moet dus snel aangepast kunnen worden bij veranderende omstandigheden. Dit gaat helaas nog niet op voor alle bestaande datawarehouses binnen bedrijven, waardoor managers vaak lang moeten wachten op geschikte rapportages.