Het aspect tijd speelt een belangrijke rol in ieder datawarehouse. In deze blog zal ik uiteenzetten welke tijdsaspecten we zoal hebben en wat hun nut is.
Allereerst gebruiken we een datawarehouse om historische data te bewaren. Dit stelt ons in staat om de situatie in het verleden te bekijken en trends te analyseren. Zo kunnen we bijvoorbeeld in een datawarehouse het aantal aan een project bestede uren van jaren terug bekijken terwijl gegevens uit die tijd in het bronsysteem mogelijk niet eens meer beschikbaar zijn. Dit wordt ook wel het time-variant principe genoemd.
Verder is er ook nog zoiets als het non-volatility principe. Dit zorgt ervoor dat je op ieder moment in de tijd een in het verleden geproduceerd rapport exact kunt reproduceren. Stelt u zich een universiteit voor met verschillende faculteiten. Aan deze faculteiten zijn onderzoekers verbonden (middels een aanstelling). Onderzoekers verbonden aan verschillende faculteiten werken gezamenlijk aan het project genaamd IMPACT. Stel we draaiden op 15 januari 2009 een rapport uit met het aantal in het jaar 2008 besteedde uren aan project IMPACT, dan moeten we anno nu dit rapport nog exact zo kunnen uitdraaien. Dit alles moet mogelijk zijn ongeacht het feit dat er inmiddels wijzigingen zijn opgetreden in de organisatiestructuur (twee faculteiten zijn inmiddels gefuseerd) en ongeacht het verlaat invoeren van gewerkte uren door diverse medewerkers die na 15 januari 2009 met terugwerkende kracht zijn doorgevoerd.
Tegelijkertijd wil je ook in staat zijn over besteedde uren in het jaar 2008 te rapporteren inclusief de achteraf doorgevoerde wijzigingen. Als het datawarehouse moet voldoen aan het non-volatility principe betekent dit dat we van ieder item de historie moeten gaan bijhouden.
Deze twee principes worden doorgaans niet ondersteund door transactiesystemen waarover een BI laag is gelegd. Immers transactiesystemen zijn met een heel ander doel gebouwd, namelijk het ondersteunen van het businessproces, zoals het vastleggen van orders, zodat er geleverd kan worden. Managementinformatie is voor dit systemen aanvankelijk van secundair belang. Dit zijn volgens mijn mening dan ook geen echte datawarehouses, ongeacht het feit dat een BI laag overheen ligt.
Ook zijn er systemen dat toch wel degelijk het leveren van managementinformatie als primair doel heeft maar dat niet aan het non-volatility principe voldoet. Vaak wordt dit principe niet op zijn waarde geschat of gewoon als teveel rompslomp ervaren. Het draagt echter bij aan de geloofwaardigheid van de managementinformatie die het systeem produceert.
Stel je voor dat je (teruggrijpend op het eerdergenoemde voorbeeld) op 15 januari 2009 aan de faculteitsdirecteur een overzicht moet leveren van het aantal onderzoeksuren dat binnen zijn faculteit aan verschillende projecten is besteed in het jaar 2008. Hij presenteert deze cijfers vervolgens tijdens het een overleg met de het college van bestuur. Voorafgaand aan de volgende vergadering, een maand later, krijg je het verzoek om deze cijfers nogmaals te leveren, maar nu verfijnd op maandniveau en per type activiteit. In het urenregistratiesysteem is wat achterstallige administratie over het jaar 2008 bijgewerkt. Deze data is inmiddels ook ingelezen in het datawarehouse. Je hebt dus de beschikking over “verbeterde” informatie maar… helaas, je cijfers die je op 15 januari 2009 hebt geleverd, zijn niet meer exact te reproduceren. Voor de meeste projecten wijken de besteedde uren nu iets af van de cijfers op het vorige publicatiemoment. De faculteitsdirecteur is nu in verlegenheid gebracht omdat hij aan het college van bestuur mag gaan uitleggen waarom zijn managementinformatie over het jaar 2008 zomaar is veranderd. Hij hoort de schampere opmerkingen al over tafel gaan: “Volgende maand is het zeker weer anders!”. Uiteraard krijg jij deze opmerkingen keurig doorgeserveerd.
Je kunt er natuurlijk altijd voor kiezen om na ieder moment dat een datawarehouse wordt bijgewerkt een back-up te maken en deze naar behoefte weer online te plaatsen, mocht men terugwillen grijpen op de situatie in het verleden. Dit is een tamelijk onpraktische benadering omdat deze steeds een beheershandeling vereist. Veel mooier zou zijn als het non-volatility principe is ingebakken in de architectuur van het datawarehouse.
Een datawarehouse die is opgezet volgens de Datavault benadering voldoet hier aan. Dit is een van de redenen waarom ik zo’n liefhebber ben van deze benadering. Zonder er diep op in te gaan komt de het er op neer dat alle in het datawarehouse ingelezen brondata op efficiënte wijze met een bepaalde geldigheidsduur wordt opgeslagen. Van iedere entiteit wordt bij ieder attribuut een “geldig vanaf-“ en een “geldig tot-” datum vastgelegd. Hetzelfde geldt voor relaties tussen de opgeslagen entiteiten. Door ieder deeltje informatie een geldigheidsduur mee te geven, kan aan het non-volatility principe worden voldaan. Ik besef dat deze laatste alinea vele vragen bij u oproept en hopelijk uw nieuwsgierigheid gewekt heeft. Daarom zal in een volgende blog zal ik hierover wat gedetailleerder in gaan.
