Business Intelligence / Opinie
Detail niveau in een datawarehouse
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?
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.
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...
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).
"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)."
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.
- 13:55 Controles bij de poort
- 11:18 De sponsor: ‘Bij volleybal gaat het om teamspirit'
- 10:14 Imtech koopt Duitse BI-leverancier Stas
- 10:39 Business intelligence op de iPhone populair
- 09:40 Business case bij BI blijft problematisch
- 22:43 Information Access wordt BI
- 11:10 Managementinformatie helpt het Albeda College...
- 09:40 Van Business Intelligence naar Intelligent...
- 09:36 Business Objects kiest voor overleven
- 11:31 Adidas: betere performance en beter sturen
Structureel betere BI door Data Integratie
Informatie combineren leidt tot beter inzicht en analyse. Dat gebeurt echter nog veel te vaak met de losse hand. Door informatiestromen structureel te combineren stijgt het niveau van BI enorm, met als resultaat beter inzicht en gerichtere acties. In deze whitepaper wordt helder...... Download nu
Kosten besparen door slimme opslag data
De hoeveelheid data neemt steeds meer toe, maar wordt deze wel effectief opgeslagen? In deze whitepaper leest u aan de hand van praktijkvoorbeelden hoe databasesoftware de hoeveelheid data in uw datacenter flink kan reduceren zonder dat het impact heeft op prestaties.... Download nu
Meer Business Intelligence whitepapersComputable Events - BI
Computable organiseert in 2008 weer verschillende events met praktijkgerichte informatie over actuele onderwerpen in de ICT:
Oracle Enterprise Performance Management System
18-07 14:45 Oracle komt met Oracle Enterprise Performance Management (epm) System. Deze geïntegreerde suite van epm-oplossingen ondersteunt strategische, financiële en operationele...
Meer business intelligence productenManagementinformatie helpt het Albeda College verder
11-08 11:10 Om het opleidingsinstituut beter te kunnen sturen zocht het Albeda College in Rotterdam een oplossing waarmee doelstelling en doelrealisatie op transparante wijze in meerdere...
Meer business intelligence casesBusiness case bij BI blijft problematisch
15-08 09:40 Op het Topic Business Intelligence is een discussie ontstaan over het opstellen van een business case bij bi-projecten. Er wordt gesteld dat regels voor de algemene...
Meer business intelligence achtergrondControles bij de poort
28-08 13:55 Laatst ben ik weer tegen een data warehouse aangelopen, waar zeer veel issues spelen met betrekking tot de kwaliteit van de brondata. Verkeerde bestanden aangeleverd of...
Meer business intelligence opinie
