Managementinformatie wordt gemaakt op basis van data afkomstig uit een of meer bronsystemen. Tussen het moment van het onttrekken aan het bronsysteem en het moment van afleveren van managementinformatie bij de eindgebruiker kan de ruwe brondata aan verschillende transformaties worden onderworpen. Niet zelden wordt er in dit proces gebruik gemaakt van een of andere vorm van historische data opslag. Een belangrijke reden om datahistorie te bewaren is dat dit ons in staat stelt om op ieder gewenst moment eerder geproduceerde managementinformatie exact te kunnen reproduceren. Zo kan de gebruiker, op een later tijdstip verdere analyse uitvoeren op dezelfde cijfers als destijds. Dit wordt ook wel het non-volatility principe genoemd.

Binnen verschillende BI architecturen wordt op verschillende manieren omgegaan met brondata, het bewaren van historie en de transformaties die nodig zijn om van ruwe brondata managementinformatie te maken. De ene architectuur is er primair op gericht informatievragen die hier en nu spelen te kunnen beantwoorden en bevatten geen voorzieningen voor non-volatility.  Andere architecturen zijn ambitieuzer van opzet en garanderen wel non-volatility en houden tegelijkertijd rekening met het gegeven dat bronsystemen kunnen wijzigen evenals de informatiebehoefte van de gebruikers van managementinformatie. Alles daar tussenin is uiteraard ook mogelijk.

Verlies van historie

Bij de meeste BI architecturen kan informatie verloren gaan over de historie en herkomst van de brondata. Dit is altijd het gevolg van het transformeren van data waarbij de uitkomst van de transformatie wordt bewaard maar de data die als input voor de transformatie diende niet. Voor de meeste BI specialisten is dit gesneden koek (mag ik hopen), echter voor de business, de eindgebruiker van de BI architectuur, is dit lang niet altijd het geval (We hebben een datawarehouse dus we bewaren de historie van al onze data…). Daarom is het goed om eens te benoemen wat er allemaal gebeurt met de data uit de operationele systemen voordat het uiteindelijk is getransformeerd naar bruikbare management informatie.

Manieren om data historie te verliezen

Hieronder beschrijf ik aan welke transformaties data binnen een BI architectuur onderworpen kan worden en hoe dit tot verlies van data historie kan leiden.

Data cleansing

Dit is het opschonen van data door het toepassen van kwaliteitsregels alvorens deze data in het datawarehouse worden geladen. Er zijn verschillende situaties die er toe kunnen leiden dat een data item niet in het datawarehouse terecht komt:

• Er treden problemen op bij het converteren van velden van het ene gegevenstype naar het andere. Bijvoorbeeld: Een orderregel in het bronsysteem heeft een veld ‘Orderdatum’ van het gegevenstype ‘Tekst’ met de waarde ‘1 januari Z012’. Deze waarde kan niet geconverteerd worden naar het gegevenstype ‘Datum’ hetgeen noodzakelijk is om het op te kunnen slaan in het daarvoor bestemde datumveld de historische data opslag.
• Door het niet laden van onbestaanbare informatie. Bijvoorbeeld een orderregel met een negatief te factureren bedrag.
• Door het niet laden van informatie met ontbrekende sleutelwaarden. Bijvoorbeeld een record met persoonsinformatie waarvan het burgerservicenummer ontbreekt kan niet worden geladen omdat binnen het datawarehouse de entiteit persoon uniek identificeerbaar moet zijn met het burgerservicenummer.
• Door codes die niet bekend zijn in het datawarehouse, te vervangen door een standaardwaarde. Bijvoorbeeld een orderregel met een onbekende productcode die vervangen wordt door de waarde ‘UNKNOWN’ alvorens hij wordt opgeslagen in het datawarehouse.

Data integratie

Dit is het samensmeden van gefragmenteerde data tot een geheel. Ik onderscheid twee vormen van data integratie:

• Intra bronsysteem integratie. Dit is integratie van data die op verschillende momenten wordt onttrokken aan hetzelfde bronsysteem.  Als bij dit type data integratie historische informatie verloren gaat, is dit doorgaans een bewuste keuze. Soms wordt er bewust gekozen voor het niet of slechts deels opbouwen van een tijdslijn van een entiteit, bijvoorbeeld omdat dit geen business belang dient. Echter soms gaat het hier ook onvoorzien mis doordat sleutelvelden niet stabiel in de tijd zijn. Bijvoorbeeld: Stel we hebben een productregistratiesysteem waarin de producten uit het assortiment, zijn gedefinieerd. Het systeem dwingt af dat ieder product een unieke productcode toegewezen krijgt. Bij eerste invoer krijgt het product de unieke code ‘PRODUCTA’ toegewezen. Vervolgens wordt deze informatie geladen in het datawarehouse waarbij de productcode als unieke sleutel wordt gebruikt. Weer wat later komt men erachter dat de code foutief was en daarom wordt deze vervangen door een andere, eveneens unieke code ‘PRODUCTB’. Als vervolgens ook deze informatie wordt geladen in het datawarehouse, dan wordt de tijdslijn van het product met code ‘PRODUCTA’ niet voortgezet. In plaats daarvan wordt een nieuwe tijdslijn gestart voor het product met code ‘PRODUCTB’. Het feit dat product met code ‘PRODUCTA’ hetzelfde product betreft als het product met code ‘PRODUCTB’ gaat hier verloren.
• Bronsysteem overstijgende integratie. Dit is integratie van data die wordt onttrokken aan verschillende bronsystemen om zo een compleet beeld te creëren van een entiteit waarvan data gedistribueerd is opgeslagen. Bij dit type data-integratie kan historie verloren gaan als het integratie algoritme niet gegarandeerd 100% zonder fouten verloopt. Bijvoorbeeld persoonsgegevens die geïntegreerd moet worden op naam, geslacht en geboortedatum. Dit kan fout gaan als het integratiealgoritme geen rekening houdt met verschil in gebruik van diacrieten, hoofdletters, koppeltekens etc. in de naam. Als de architectuur van het datawarehouse  vereist dat direct tijdens het laadproces ook de data geïntegreerd wordt dan is er vaak geen weg meer terug. Als achteraf blijkt dat er iets is fout gegaan tijdens de data-integratie dan kunnen binnen het datawarehouse al zoveel afhankelijkheden zijn ontstaan met het foutief geïntegreerde data-item dat de kluwen niet meer zonder informatieverlies te ontwarren is. Daarnaast kan bij bronsysteem overstijgende integratie natuurlijk hetzelfde type probleem optreden als beschreven is bij intra bronsysteem integratie.

Calculatie

Dit is het berekenen van numerieke waarden op basis van verschillende getallen in een of meer records uit het bronsysteem.  Denk hierbij bijvoorbeeld aan het berekenen van een omzet voor een orderregel door het verkochte aantal te nemen en dit te vermenigvuldigen met de stuksprijs van het bestelde product en hiervan een eventueel verleende korting af te trekken. De berekende omzet wordt opgeslagen in het datawarehouse, maar de onderliggende getallen (aantal verkocht, stuksprijs en kortingsbedrag) niet.

Aggregatie

Dit is het berekenen van numerieke waarden door het samenvatten van data uit meerdere records uit het bronsysteem voor een of meer dimensies en dit opslaan in het datawarehouse. Tegelijkertijd worden de onderliggende detailgegevens niet bewaard in het datawarehouse. Een voorbeeld van aggregatie is het berekenen van het verkochte aantal van een product per week door de som van het verkochte aantal van alle orderregels voor het betreffende product die binnen dezelfde week vallen, op te tellen.

Wat is nou eigenlijk het probleem?

In de bovengenoemde voorbeelden onder het kopje data integratie is het probleem evident. Door voortschrijdend inzicht in de wijze waarop de data geïntegreerd moet worden of door er te laat achter te komen dat er iets mis is gegaan met de data integratie is het onmogelijk de oorspronkelijke brondata te reconstrueren en opnieuw te integreren volgens de nieuwe inzichten.

Ook rondom data cleansing strategieën kunnen we voorschrijdende inzichten krijgen. Bijvoorbeeld we komen tot het inzicht dat, geheel tegen de afspraken in, de order desk orderregels ‘misbruikt’ door een negatief te factureren bedrag in te voeren om zo geld terug te storten op rekening van klanten die te veel betaald hebben. Nu we dit weten, blijkt dat we, achteraf gezien, de orderregels met een negatief factuurbedrag wel degelijk hadden moeten meenemen in de berekening van de weekomzet. Echter deze orderregels zijn buiten het datawarehouse gehouden en zijn in de tussentijd mogelijk gewijzigd in het bronsysteem. Met terugwerkende kracht zijn we nu niet meer in staat de weekomzet te herberekenen volgens de nieuwe methode.

Organisaties zijn continue onderhevig aan veranderingen. Hetzelfde geldt voor de markt waarin zij opereren. Het kan dan ook niet anders dan dat de informatiebehoefte van de gebruikers van de BI oplossing verandert in de tijd. Om tegemoet te kunnen komen aan deze veranderende informatiebehoefte, moeten soms wijzigingen worden aangebracht in het datawarehouse. Stel dat de eindgebruiker aanvankelijk geïnteresseerd was in de omzet per product, per verkoper, per week. Om aan deze informatiebehoefte te voldoen, zijn de orderregels afkomstig uit het ordersteem geaggregeerd per product, verkoper en week. Het resultaat van deze aggregatie is opgeslagen. De onderliggende orderregels niet. Op een later moment geeft de eindgebruiker aan dat hij de omzet ook nog per verkoopregio wil kunnen bekijken. We hebben nu geen andere keus dan de omzet opnieuw te berekenen door de orderregels zoals ze nu in het ordersysteeem staan, opnieuw te aggregeren, ditmaal met de extra dimensie verkoopregio. Er is een gerede kans er inmiddels iets is veranderd in het orderregels in het ordersysteem. Als we het non-volatility principe belangrijk vinden, moeten we in dat geval de oorspronkelijke omzetcijfers (per product, per verkoper, per week) bewaren in het datawarehouse en daarnaast de omzetcijfers volgens de nieuwe berekening (per product, per verkoper, per week, per verkoopregio) gaan opslaan. De oorspronkelijke omzetcijfers uitsplitsen volgens een extra dimensie kan in dit geval dus niet.

Business beslist mee 

Nu we weten waar we historie kunnen verliezen, kunnen we, indien gewenst, hierop anticiperen. Dit kan door de juiste BI architectuur te kiezen, in combinatie met de juiste wijze van het modelleren van data. Voordat een organisatie een keuze maakt, is het belangrijk om helder te hebben welke consequenties deze keuze heeft in termen van mogelijk verlies van data-historie en hoe dit de flexibiliteit en onderhoudbaarheid van de oplossing beïnvloedt.  Architectuurkeuze is dus niet enkel een technische aangelegenheid. De business moet hier ook bij betrokken worden.