Denken Over Data

Mijn naam is Richard Steijn en ik ben dol op data dingen. In deze blog deel ik mijn ideeën, ervaringen, hersenspinsels en wat al niet meer over dit onderwerp.

Bezoek ook eens de website van Vaiper, mijn bedrijf.

Jaar: 2015

  • Data Vault als basis voor je datawarehouse

    Data Vault als basis voor je datawarehouse

    In vorige posts gaf ik al aan dat ik een liefhebber ben van de Data Vault methodiek voor data modellering van het data warehouse. Waarom dit zo is zal ik hieronder uitleggen. Het gaat te ver om de Data Vault methode in deze post uit helemaal uit te leggen, dit is al gedaan in dit artikel, geschreven door godfather Dan Linstedt. In deze post volsta ik met een beknopte schets van de drie bouwstenen van Data Vault.

    Bouwstenen van Data Vault

    Hub tabellen

    Een Hub record representeert het bestaan van een entiteit vanaf een bepaald moment. Hub records zijn uniek identificeerbaar met hun business key.Bijvoorbeeld:

    Klant met klantnummer K1234567 is sinds 12-02-2009 bekend in het data warehouse.

    De business key is hier: K1234567

    Link tabellen

    Een Link record representeert een relatie tussen twee of meer Hub records. Link tabellen worden doorgaans gebruikt om bepaalde structurele samenhangen tussen entiteiten weer te geven zoals hiërarchische verhoudingen. Bijvoorbeeld:

    Sinds 25-03-2009 is in het data warehouse bekend dat de medewerker met personeelsnummer AB321 valt onder de afdeling Verkoop

    Dit Link record refereert naar de volgende Hub records:

    • Medewerker (business key = AB321)
    • Afdeling (business key = Verkoop)

    Daarnaast is de Link tabel de aangewezen plek om transactiegegevens in op te slaan. Bijvoorbeeld:

    Sinds 25-03-2009 is in het data warehouse bekend dat klant K1234567 op 22-03-2009 order 8887.23 geplaatst heeft voor product met code X342P.

    Dit Link record refereert naar de volgende Hub records:

    • Klant (business key = K1234567)
    • Product (business key = X342P)
    • Order (business key=8887.23)

    Satellite tabellen

    Een Satellite record representeert een of meerdere attributen die behoren bij een Hub of Link record. Bijvoorbeeld:

    Van 25-03-2009 tot 01-01-2010 is in het data warehouse bekend dat klant K1234567 de rechtsvorm ‘BV’ heeft.

    Met data warehouse gemodelleerd volgens de Data Vault zijn we in staat om:

    – data uit operationele systemen op bepaalde momenten in de tijd vast te leggen, zodanig dat we ten allen tijde de data van dat moment exact terug kunnen halen, ook al zijn er na dat bewuste moment wijzigingen aangebracht in de data. Het zogenaamde non volatility principe. Lees voor meer uitleg een van mijn vorige posts over tijd in een datawarehouse.

    -data uit verschillende operationele systemen te integreren. Dat wil zeggen: Het inlezen van soortgelijke informatie uit verschillende bronnen in dezelfde Data Vault tabellen en het maken van koppelingen tussen data items uit verschillende gegevensbronnen.

    Merkwaardigerwijs verbiedt de officiële Data Vault leer ons Link tabellen (waarin we relaties tussen Hub records opslaan) te voorzien van een einddatum. Hierover is veel discussie in het “wereldje”. Eerlijk gezegd begrijp ik niet waarom. Ook relaties tussen Hubs kunnen een beperkte houdbaarheid hebben. Daarvoor heb je nou eenmaal een einddatum nodig. Kortom: ik voorzie ook Link tabellen gewoon van een einddatum.

    Wat is er nu zo handig aan?

    Stabiliteit door de tijd

    Een belangrijke spelregel van Data Vault is: Wat eenmaal in de Data Vault staat, wijzigt nooit meer. Als we nu de Data Vault methode uitbreiden met Links met einddatum (zoals hierboven genoemd) zijn we in staat een data warehouse te creëren dat volledig stabiel is in de tijd. We kunnen ten allen tijde oude kengetallen en overzichten exact reproduceren.

    Kleine wijzigingen in brondata -> kleine impact op het data warehouse

    Door de fysieke scheiding tussen business keys en attributen van entiteiten en onderlinge relaties tussen entiteiten ontstaat een zeer flexibel datamodel. Een wijziging in een attribuut van een entiteit heeft hier alleen maar gevolgen voor het betreffende Satellite record waarin dit attribuut staat. We geven het “verouderde” satellite record een einddatum en maken daarnaast een nieuwe aan met de nieuwe attribuut waarde. We hoeven in tegenstelling tot bijvoorbeeld een star scheme of een 3NF gemodelleerd data model geen nieuwe versie van de volledige entiteit te maken en daar achteraan een nieuwe versie van alle entiteiten die op dat moment een relatie hebben met de bewuste entiteit. Hetzelfde geldt bij wijzigingen in relaties tussen entiteiten. In de Data Vault hoeven we enkel het betreffende Link record dat de “verouderde” relatie representeert van een einddatum te voorzien en een nieuwe Link record aan te maken die de nieuwe relatie representeert.

    Flexibiliteit

    Als in de loop der tijd er meer attributen van een entiteit moeten worden bewaard in het data warehouse dan aanvankelijk het geval was, dan hoeven we alleen maar een extra satellite tabel toe te voegen die we vanaf dat moment ook gaan vullen. We hoeven niet aan de bestaande tabelstructuur te zitten om dit te faciliteren. Hetzelfde gaat op voor het geval dat er tijdens het leven van het data warehouse nieuwe relaties willen gaan bewaren tussen reeds langer bestaande Hub tabellen.

    Mogelijkheid tot parallel laden van data

    De opsplitsing in Hubs, Links en Satellites en de manier waarop deze met elkaar samenhangen heeft als groot voordeel dat we veel data parallel kunnen laden. In wezen kan dit in 3 stappen gebeuren: Stap1: Het parallel laden van de Hub tabellen

    Stap 2: Het parallel laden van de Satellite tabellen behorend bij de Hub tabellen en alle Link tabellen.

    Stap 3: Het parallel laden van de Satellite tabellen behorend bij de Link tabellen.

    Compacte wijze van historie bewaren

    Data Vault bewaart alleen de verschillen in de brondata ten opzichte van het vorige laadmoment. Dit in combinatie met het uiteenrafelen van entiteiten in Hubs, Links en Satellites zorgt voor een zeer compacte wijze van opslag van het de historie van data items.

    Er wordt (bijna) niets weggegooid

    In Data Vault lezen we de bron data ongewijzigd in. We doen niet aan data cleansing. Pas als we de data in het data warehouse vrijgeven eindgebruikers bijvoorbeeld d.m.v. een data mart, passen we allerhande business logic toe om foute data achter te houden of te “verbeteren”. Het mooie van deze werkwijze is dat wanneer we bijvoorbeeld door voortschrijdend inzicht in de loop der tijd betere logica ontwikkelen voor het schonen van data deze kan worden toegepast op de oorspronkelijke, niet reeds opgeschoonde en gefilterde brondata.

    In combinatie met Change Data Capture op bronsystemen zouden we zelfs een Data Vault kunnen creëren die real time meebeweegt met de operationele systemen die de bron data leveren.

    Auditability

    Een andere Data Vault regel is dat ieder record moet worden voorzien van een bron verwijzing. We kunnen op basis hiervan een mechanisme maken waarmee we zeer gedetailleerd ieder item in ons data warehouse kunnen terug traceren naar de bron. Problemen opsporen in de brondata wordt hiermee vergemakkelijkt.

    Zeer geschikt voor code generatie

    Door de beperkte hoeveelheid bouwstenen en duidelijke regels waaraan een Data Vault moet voldoen is deze bij uitstek geschikt voor het genereren van allerhande programma code. Denk hierbij aan het vanuit een genormaliseerd datamodel van een bronsysteem een Data Vault database genereren die alle informatie kan bevatten die zich in het betreffende bronsysteem bevindt. Denk hierbij ook aan het genereren van ETL om data vanuit het bronsysteem in te lezen in de Data Vault database.

    Dit is zo een greep uit alle voordelen van de Data Vault die bij mij op komt. Als u er meer weet, reageer vooral. Ziet u nadelen, vooral ook reageren.

  • De BI as a service black box

    De BI as a service black box

    Uitbesteden is in.

    Tegenwoordig kunnen we op ICT gebied ongeveer alles uitbesteden waarvan we vinden dat we er zelf niet goed in zijn of geen energie in willen stoppen. In plaats van dure licenties en hardware aan te schaffen en te investeren in kennis om bepaalde software te kunnen beheren en ontwikkelen, kunnen we nu voor een maandbedrag gebruik maken van diensten en software van derden. Software-as-a-service (SAAS) dus. Door de keuze voor een SAAS oplossing worden we ontzorgt en kunnen we ons volledig richten op die dingen we wèl goed in zijn.

    Een speciaal geval van een SAAS oplossing is BI-as-a-service (BIAAS). De gebruiker hoeft zelf geen BI tools te installeren maar benadert deze doorgaans via de web browser. De BI tool bevindt zich vaak ergens in ‘the cloud’ en haalt haar data uit een data warehouse waarvan de ontwikkeling en het beheer ook is uitbesteed. Het data warehouse en de rompslomp eromheen, bevindt zich buiten het zicht van de afnemer van BIAAS. Het enige dat hij er eventueel merkt is dat er op gezette tijden data aan de operationele systemen die hij in gebruik heeft, wordt onttrokken om in het data warehouse te laden.

    Dat BIAAS de nodige voordelen biedt moge duidelijk zijn. Toch zou een afnemer van BIAAS er goed aan doen om er voor waken dat de BI omgeving te veel een black box wordt. Voor zover het zuiver technische aangelegenheden betreft is het prima dat de afnemer hier niets van mee krijgt. Business intelligence is echter niet alleen een technische aangelegenheid. Het onderliggende data warehouse is niet los te koppelen van degene die het gebruikt. Het is niet inwisselbaar zoals software voor tekstverwerking, spreadsheets, projectplanning of e-mail. Managementinformatie is per definitie gebaseerd op data die heel bedrijfseigen is.

    Het is belangrijk dat een bedrijf dat BIAAS afneemt in grote lijnen op de hoogte is van het data acquisitieproces die de BI toepassing van informatie voorziet. Men moet weten hoe deze data wordt schoongemaakt, getransformeerd en geïntegreerd tijdens het laden van het data warehouse. Welke data wordt beschouwd als ’onbruikbaar’ en wordt niet geladen. Hoe wordt data ‘verrijkt’ en ‘verbeterd’ en waarom? In dit soort zaken moet men inzicht hebben, om in staat te zijn de managementinformatie die aan het data warehouse wordt onttrokken op waarde te schatten.

    En stel je voor dat je als BIAAS klant in de toekomst toch weer je BI omgeving zelf in beheer wilt nemen of je wilt overstappen naar een andere aanbieder van BIAAS. Hoe ga je te werk als je helemaal niets weet van wat er zich achter de rookgordijnen van the cloud afspeelt?

    Laatst was ik op het Data Vault Automation Seminar waar een van de sprekers het had over ‘knowledge partnership’. Het bedrijf waarvoor de spreker werkte, een ICT dienstverlener, bouwde in opdracht BI oplossingen voor haar klanten. Deze BI oplossingen werden uiteindelijk door de klant zelf in beheer genomen. In de eerste fase nam de dienstverlener 100% het voortouw, in daaropvolgende fasen werd onder begeleiding de klant steeds meer betrokken bij het ontwikkelproces. Net zolang totdat de klant al het werk zelf kon doen. Al doende werd op deze manier de klant voorzien van de kennis hij nodig om op eigen benen te staan aangaande het beheer, het onderhoud en de doorontwikkeling van de BI oplossing. De dienstverlener en haar klant gingen een knowledge partnership aan. Nu ging het hier niet om een BIAAS oplossing, maar de gedachte sprak mij erg aan. Openheid versus geslotenheid. Deze klanten kloppen in de toekomst heus wel weer aan bij deze dienstverlener, juist door deze openheid.

    Een bedrijf dat op zoek is naar een BIAAS oplossing zou er goed aan doen een aanbieder te zoeken die met hen een knowledge partnership wil aangaan. De focus moet hier dan niet liggen op de techniek, want die moet op de achtergrond blijven. De focus zou juist moeten liggen op dat deel van de oplossing die specifiek is voor de afnemer van de service: de data. Zo kan voorkomen worden dat de BIAAS oplossing een black box wordt.