De laatste tijd valt het mij op dat er verschillend gedacht wordt over het detailniveau in een datawarehouse. Detailgegevens zouden horen in een transactieverwerkend systeem. En in een datawarehouse vind je alleen geaggregeerde gegevens. Ik ben het daar niet mee eens. Ook de detailgegevens horen in een datawarehouse.
Waarom? Ten eerste omdat op basis van het detail niveau er verschillende dwarsdoorsnedes gemaakt kunnen worden. Wellicht zijn de wensen van de gebruikers in de eerste fase alleen een dwarsdoorsnede per productgroep en klantgroep. Maar het is zeer goed mogelijk dat na een half jaar, na gebruik van de gegevens er vragen opkomen die gebaseerd zijn op transactie muntsoort, of transactiedatum in plaats van boekingsdatum. Dan heb je de detail gegevens nodig om dit te kunnen aggregeren.
Ten tweede heb je detail gegevens nodig om afwijkingen van het geaggregeerde niveau te kunnen verklaren. Bijvoorbeeld waarom is de omzet de afgelopen maand zoveel gestegen of gedaald. Hiervoor heb je de detail gegevens nodig uit het datawarehouse. Dit ook omdat ze in het transactieverwerkend systeem kunnen wijzigen.
Wat bedoel ik daar precies mee. In een transactiesysteem veranderen de gegevens in de tijd. De status van een transactie kan gedurende de tijd veranderen.
In een datawarehouse veranderen de gegevens niet. Als ik nu een rapport draai over de stand van gisteren. En ik draai dit rapport volgende maand weer over de zelfde dag, dan zijn de uitkomsten gelijk. Eenmaal opgeslagen in het datawarehouse blijft zo. Een datawarehouse heeft geen updates, alleen inserts.
Hierdoor blijft een rapport, die laat zien wat de verkopen zijn van het afgelopen jaar, constant. Het bedrag van januari is nog hetzelfde, ook als je het rapport in november draait.
In een transactie systeem kan dit veranderen.
Een voorbeeld:
Een rapport geeft weer wat de status is van de bestellingen per maand. We draaien het rapport over januari, op de eerste dag van februari.
Het transactie systeem geeft aan: 80 procent afgehandeld, 15 procent in behandeling, 5 procent afgebroken
Het datawarehouse geeft hetzelfde aan: 80 procent afgehandeld, 15 procent in behandeling, 5 procent afgebroken
Draaien we in december hetzelfde rapport over januari dan kan het volgende gebeuren:
Het transactiesysteem geeft aan: 93 procent afgehandeld, 7 procent afgebroken.
Het datawarehouse zal blijven aangeven: 80 procent afgehandeld, 15 procent in behandeling, 5 procent afgebroken.
Natuurlijk kun je ervoor kiezen om niet het laagste detail niveau in je datawarehouse op te slaan. Dit kan te maken hebben met de hoeveelheid van data. Je moet het ook allemaal kwijt kunnen en willen. Het kan zijn dat het aantal transacties zo'n enorme hoeveelheid is, dat het opslaan en verwerken daarvan op gedetailleerd niveau een grote kostenpost zal leveren. Qua opslagkosten en CPU kosten. Dan kun je overwegen of de kosten opwegen tegen het detailniveau.
Maar aggregeren in een datawarehouse is eenvoudig, meer detail opvragen dan erin zit is onmogelijk.
Wat is jullie mening?
Het is denk ik grotendeels een kwestie van definitie. Wat versta je onder een datawarehouse? Is dat het gehele systeem (van datasource tot end user layer) of is dat alleen die grote ton in het midden? Ik zou zelf wel alle details beschikbaar willen hebben maar niet per se in het DWH. Dat mag wat mij betreft ook best in een transaction repository of iets dergelijks. In het transactiesysteem laten lijkt mij (zie ook jouw argumenten) zeker geen optie.
Ik ben het met Eva, maar ook met Jorgen eens. Het is noodzakelijk om de gerapporteerde gegevens op elk moment te kunnen verantwoorden. Hiervoor is het noodzakelijk de historie van detailgegevens ergens beschikbaar te hebben. Echter, wanneer het transactiesysteem zo is ontworpen dat deze alle mutaties (dus bij statusverandering oude en nieuwe status met moment van wijziging) zelf bijhoudt dan kan dit volstaan. Of we dit “transaction repository” of “DWH functionality (within system X)” noemen is natuurlijk van ondergeschikt belang.
Wat je wilt is simpelweg historie… hoe en welke technieken je daarvoor gebruikt zijn irrelevant (vanuit de businessbehoefte).
Afhankelijk van de “nauwkeurigheid” waarmee gerapporteerd dient te worden is de detailopslag relevant (trend/forecasting). Voor de historie is het de wijze waarop je de detailgegevens opslaat.
Ik zie het als twee verschillende zaken.
@Vorige post… want ik zeg twee keer hetzelfde…
Nauwkeurigheid zit hem in welk detailniveau je opslaat.. per seconde minuten enz enz
Historie zit hem in HOE je het opslaat om veranderingen in de tijd te kunnen volgen…
Interessante discussie. Ik denk dat de vraag van Jorgen inderdaad relevant is. Wat is de definitie van data warehouse die Eva hanteert?
Vanuit mijn perspectief zie ik het data warehouse inderdaad als het totaal van alle lagen tussen de OLTP systemen en MIS dashboards.
Ik ben van mening dat er inderdaad een laag moet zijn waarin de totale historie zich bevind (afhankelijk inderdaad van het detail niveau van deze historie; minuten, uren, dagen, weken, maanden, etc.) Deze historie is overigens voornamelijk van invloed op de gezichtspunten / brillen waarmee naar de gegevens wordt gekeken. Een feit (zoals Eva terecht aanhaalt) zal NIET wijzigen in de tijd, maar een afdeling binnen een organisatie wel. Wat eerste bij afdeling A moet worden meegeteld moet aan het eind van het jaar wellicht worden meegeteld bij afdeling B, maar het feit blijft dat er 100 artikelen zijn verkocht. Daar wijzigt niets meer aan.
Ik ben het dus roerend eens met Eva dat een Data Warehouse detail niveau moet bevatten, aangezien minder detaillering altijd mogelijk is, maar details erbij ‘verzinnen’ alleen met statische modellen en giswerk kan worden gedaan, wat NOOIT de totale waarheid is. Het argument van CPU en opslag hoeft m.i. geen issue te zijn aangezien de processen geoptimaliseerd kunnen worden en schijfruimte nu niet meer de grootste investering is voor een bedrijf. Kortom er is geen reden m.i. om details te ‘bewaren’ in een laag zo dicht mogelijk bij de bron (zowel in de zin van proces als ook qua structuur).
Ik bedoel natuurlijk;
“Er is GEEN reden m.i. om details te ‘bewaren’ in een laag zo dicht mogelijk bij de bron (zowel in de zin van proces als ook qua structuur).”
Ik ben het met Eva eens. Maar dan met name omdat het onderscheid management informatie (=geen detailgegevens) en operationele informatie (=wel details) aan het vervagen is.
Veel valide argumenten om detail niveau op te slaan in een ‘centrale bak/transactions repo/EDW/etc’. Een mis ik er nog – of ik lees er over heen.
Auditability….We moeten de data die gerapporteerd of gecommuniceerd wordt ten alle tijden kunnen verantwoorden. Hiervoor hebben we gewoon alle data in historisch perspectief nodig.