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.

Categorie: Datamodel

  • Kijk eens wat vaker in je glazen bol!

    Kijk eens wat vaker in je glazen bol!

    Vermijd het Hier-en-nu denken als het om data gaat!

    In een tijd waarin steeds meer organisaties datagedreven (willen gaan) werken wordt het data-engineering vak steeds belangrijker. Bij data-engineering denk ik aan het maken van een doordacht ontwerp en het vervolgens bouwen van een dataproduct, zoals een BI-oplossing. Dit ontwerp moet niet alleen voldoen aan de huidige eisen, maar ook voorbereid zijn op toekomstige veranderingen. Hier ligt dus een spanningsveld. Maar al te vaak constateer ik dat binnen dataprojecten de voorkeur gaat naar korte termijn winst. Ik noem dit vaak (licht smalend, ik geef het toe) het Hier-en-nu denken.

    Verder lijkt het wel, met de opkomst van AI, machine learning en steeds toegankelijker rapportage en analyse tools, of data architectuur en data modelling aan belang hebben ingeboet. Echter een goed doordacht datamodel staat nog altijd aan de basis van goede datakwaliteit, wat op zijn beurt essentieel is voor betrouwbare informatieproducten. Het is niet zo dat een informatieproduct automatisch van goede kwaliteit wordt zodra er maar genoeg complexe bewerkingen op inconsistente onderliggende data worden losgelaten. Bovendien zijn deze complexe bewerkingen meestal afkomstig uit een of andere bouwdoos en zodat diep begrip ervan niet noodzakelijk is. Als de data waarmee gewerkt wordt van matige kwaliteit is, zal deze matige kwaliteit slechts worden uitvergroot door er een hoop bewerkingen op los te laten.

    Enkele voorbeelden van het Hier-en-nu denken:

    Voorbeeld 1

    Als een BI oplossing nog in de kinderschoenen staat, niet investeren in een robuuste architectuur van je datawarehouse maar het “lekker simpel houden” wat vaak neerkomt op een enkele datamart met daarin een starscheme dat rechtstreeks uit een bronsysteem gevuld wordt. Misschien voldoet deze eenvoudige oplossing nu, maar er wordt vergeten dat in de toekomst eisen en omstandigheden kunnen veranderen Misschien komen er wel meer datamarts voor verschillende gebruikersgroepen die deels gebaseerd zijn op dezelfde data. Misschien komt er wel een nieuw bronsysteem bij of verandert het huidige bronsysteem. Alle laadlogica (historie bewaren, data integreren, business rules toepassen, etc.) lekker compact bundelen en verweven op een punt is dan meestal geen goed idee.

    Voorbeeld 2

    Op dit moment bekende datakwaliteitsproblemen hardcoded in de ETL van het datawarehouse op lossen. Bijvoorbeeld: Klant met klantnummer 123456 staat ook in het bronsysteem geregistreerd onder nummer 444444. In de ETL is daarom een regel opgenomen dat alle orders die in de bron gekoppeld zijn klant 123456 in het datawarehouse moeten worden gekoppeld aan klant 444444. Dat er morgen weer andere klanten dubbel geregistreerd blijken te zijn, zijn dan zorgen voor morgen.

    Voorbeeld 3

    ETL code slordig opzetten. Geen aandacht schenken aan leesbaarheid van je code. Bijvoorbeeld slechte layout van programmacode, SQL statements met subqueries in subqueries in subqueries, het gebruik van SELECT * en natuurlijk nergens commentaar.

    Zeg nu zelf: Welke code debug je het liefst?

    Dit…

    Image

    ..of dit?

    Image

    Als je voor voor de lekkere compacte optie 1 gaat ben je dus zelf onderdeel van het probleem. 😉

    Maar alle gekheid op een stokje, dit soort rommel komt echt tergend vaak voor.

    Voorbeeld 4

    Ook het meerdere malen definiëren van eenzelfde bewerking is vaak uiting van het Hier-en-nu denken. Zie onderstaand eenvoudige voorbeeld waarin de berekening voor gemiddelde omzet (GemOmzet) op twee plaatsen is gedefinieerd in de ETL voor een datawarehouse.

    Enkele tips ter bestrijding van het Hier-en-nu denken

    Kijk in je glazen bol

    De eerste tip ligt voor de hand: Kijk niet alleen naar de nu geldende requirements maar in te schatten welke eisen er in de toekomst gesteld gaan worden aan je dataoplossing. Zeker als een organisatie net begint met de transitie naar datagedrevenheid is de BI omgeving vaak nog lekker overzichtelijk. Maak het jezelf in het begin niet onnodig te moeilijk maar probeer in ieder geval voor te sorteren voor het moment dat er complexere eisen gesteld gaan worden. Dit geldt voor alle betrokkenen, van data-architect tot ontwikkelaar.

    Smeed één wapen voor alle gevechten

    Denk generiek. Vervang hardcoded regels waarin id’s letterlijk genoemd worden door een generieke aanpak. Het bovenstaande voorbeeld 2 van de klant die dubbel geregistreerd staat in de bron zou je bijvoorbeeld kunnen oplossen door een van-naar mapping tabel aan te leggen en deze vervolgens gebruiken in de ETL gebruiken om de vertaalslag te definieren. Toekomstige dubbele registraties kan je dan inregelen door een extra record aan de mapping tabel toe te voegen. Geen onderhoud aan je code nodig!

    Wees dodelijk consequent

    Pak soortgelijke zaken op soortgelijke wijze aan. Wees consistent. Dit komt de onderhoudbaarheid overdraagbaarheid van je oplossing ten goede. Neem nooit shortcuts, hoe verleidelijk dat ook is. Een shortcut is namelijk een uitzondering, en die zul je dus moeten gaan onthouden, overdragen en een speciale afwijkende behandeling geven. Dat willen we dus niet!

    Verdeel en heers

    Bouw een dataarchitectuur met meerdere lagen, ieder met hun eigen functie (segregation of concerns). In ieder geval moet daar inzitten: een staging laag, een dataintegratielaag en een informatielaag (je datamarts en andere voorbewerkte datamodellen toegespitst op wat je informatieproducten vereissen) een informatieproductlaag (zoals dashboards, BI rapportages, data exports tbv dataanalyse etc).

    Voorzie je architectuur, zover mogelijk stroomopwaards altijd van een genormaliseerde datalaag ter vermijding van redundantie.

    Houd het droog

    Hang het DRY principe aan. Dit staat voor Don’t Repeat Yourself. Dit is een fundamenteel principe binnen softwareontwikkeling dat stelt dat elk stukje kennis (zoals een berekening, functie of business rule) slechts op één plek in de codebase mag bestaan. Voordeel is dat als in de toekomst wijzigingen noodzakelijk blijken in de bestaande logica, je deze maar op een plek hoeft door te voeren. Kortom: Herhaling in code is de vijand van schaalbaarheid en onderhoudbaarheid. Bekijk ter illustratie eens hoe de code uit voorbeeld 4 kan worden herschreven volgens het DRY principe:

    Image

    Regeer met ijzeren hand

    Plaats een spin in het web. Zorg ervoor dat een klein slagvaardig team van minstens twee personen (ivm continuiteit) in de organisatie het overzicht houden over de dataarchitectuur en de implementatie met een mandaat om in te grijpen waar nodig. Klinkt dit dictatoriaal? Absoluut. Maar laten we eerlijk zijn: systeemontwikkeling is geen democratie. Je wilt geen architectuur waarin iedere ontwikkelaar zijn creatieve ei kwijt kan. Consistentie en een strakke visie zijn geen luxe, maar pure noodzaak. Een strak geleid data-ecosysteem voorkomt dat je over een paar jaar een digitale ruïne moet proberen te renoveren. De spin heft zijn scepter, zwaait met je ER-diagrammen en regeert met rechtvaardige, maar ijzeren hand.

    😉

  • Datamigratie?: Bezint eer ge begint

    Datamigratie?: Bezint eer ge begint

    U denkt misschien: Waarschuwt hij nou voor datamigraties? Nou nee, dat is niet de bedoeling. Ik wou de lezer er slechts op wijzen dat, wanneer een systeemmigratie, met bijbehorende data, op stapel staat, dit een goed moment is om starten met het leggen van een stevige basis voor toekomstig databeheer. Aangezien iedere organisatie hier vroeg of laat wel mee te maken krijgt, bijvoorbeeld vanwege de gang naar de cloud, leek het mij goed om eens wat zaken op op een rijtje te zetten.

    Want waarom zou u simpelweg bestaande data overzetten, inclusief fouten, inconsistenties en verouderde structuren? Een datamigratie biedt het momentum om de datafundamenten van uw organisatie nog eens kritisch na te lopen en te verbeteren. Alle data uit het oude systeem moet immers toch onder de loep worden genomen.

    Enterprise Data Model

    Maak bijvoorbeeld, om te beginnen eens een start met Enterprise Data Model (EDM). Een EDM helpt u in een (of twee) oogopslag(en) inzicht te krijgen over welke entiteiten (klanten, producten, facturen, medewerkers, …) er informatie in omloop is binnen uw organisatie. Bovendien zijn hier de definities van alle entiteiten en hun attributen vastgelegd. Gebruik hier wel een degelijk CASE-tool voor zoals Powerdesigner of DataArchitect zodat u wordt geholpen met het bewaken van de integriteit van het datamodel. Bovendien heeft u dan een mooie basis van waaruit allerhande code generereerd kan worden ten behoeve van het creeeren van tabellen, ETL scripts en (delen van) applicaties die iets doen met de data die in het EDM is gemodelleerd.

    Een goed bijgehouden en compleet EDM betaalt zichzelf op termijn terug, omdat het veel dingen makkelijker maakt. Zo laat het duidelijk zien welke gegevens (entiteiten) in welke systemen worden gebruikt en hoe ze herkend kunnen worden (de zogenaamde business keys). Dit helpt bij het samenvoegen van data, bijvoorbeeld in een datawarehouse. Bijvoorbeeld: Stel, we hebben een Klant als entiteit die in zowel een CRM-systeem als een factureringssysteem voorkomt onder de naam Customer. In het CRM systeem wordt het veld Customernumber gebruikt als unieke identificator van een Klant. In het factureringssysteem wordt o.a. het veld CustomerId hiervoor gebruikt. In het EDM is vastgelegd dat de velden Customernumber in het CRM-systeem en CustomerId in het factureersysteem mappen met het het attribuut Klantnummer van entiteit Klant, dat is aangemerkt als business key. Hieruit volgt dat de velden CustomerId en CustomerNumber gebruikt kunnen worden om klantinfo uit beide bronsystemen te koppelen.

    Bij organisaties die kampen met zogenaamde datasilo’s kan een EDM helpen de overlap en verschillen tussen deze datasilo’s zowel qua structuur als definities in beeld te brengen hetgeen communicatie tussen de gebruikers van de silo’s vereenvoudigd.

    Master Data Management

    In samenhang met bovenstaande is dit ook een mooie aanleiding om Master Data Management (MDM) op te zetten. Dit komt erop neer dat er een centrale plek wordt gecreëerd waar alle kerngegevens (klanten, producten, leveranciers, medewerkers, …) beheerd worden. Informatie die dus in MDM beheerd worden, worden alleen gewijzigd in het MDM systeem en nergens anders. De overige informatiesystemen in de organisatie verwijzen er slechts naar. Hiermee wordt voorkomen dat er binnen de organisatie inconsistente kerngegevens rondgaan.

    Grote schoonmaak

    Verder zou ik de over te zetten data onderwerpen aan een kwalitteitsonderzoek. Identificeer dubbelingen en tegenstrijdigheden in de data. Spoor foutieve data op. Standaardiseer naamgevingen, formaten en structuren. Zorg voor eenduidige datadefinities en coderingen en breng ze zonodig onder in het EDM en MDM. Corrigeer datakwaliteitsissues zoveel mogelijk alvorens de data door te zetten naar zijn nieuwe habitat.

    Data Governance

    En nu u toch bezig bent met uw datalandschap: Spreek meteen even af wie welke afdeling in de organisatie eindverantwoordelijk is voor welke data. Definieer en implementeer datakwaliteitsregelsen zorg voor duidelijke richtlijnen over data-opslag, beveiliging en toegang. Oftewel: Data Governance.

    Tot slot

    Daarom zeg ik: Bezint eer ge begint als u aan een datamigratie begint en neem uw kans waar om uw databeheer en datakwaliteit in de toekomst op een hoger niveau te brengen.

  • 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.

  • Managementinformatie: Wat is waar? (II)

    Managementinformatie: Wat is waar? (II)

    In deze post ga ik dieper in op het produceren van managementinformatie in een business intelligence (BI) omgeving, er vanuit gaand dat we alle benodigde broninformatie reeds bij elkaar hebben gezocht. Deze eerste stap heb ik reeds eerder beschreven.

    Als ik het heb over managementinformatie dan denk ik aan beknopte overzichten met gemiddelden en kengetallen op dashboards en dergelijke. Kortom informatie waarop een organisatie gestuurd kan worden. In data warehouse land wordt in dit verband vaak gesproken over de “single version of the truth”. Vaak wordt dit uitgelegd als: Organisatiebreed moet er consensus zijn over de definitie van alle begrippen (kengetallen, categorieën, ..) binnen de managementinformatie. Dit is makkelijker gezegd dan gedaan. Zeker als we te maken hebben met een grote schare aan eindgebruikers afkomstig uit verschillende delen van de organisatie, zal er een hoop overleg nodig zijn om deze heilige graal te vinden. En zoals een goede heilige graal betaamd, blijft hij waarschijnlijk onvindbaar.

    Laten we het probleem eens illustreren aan de hand van een voorbeeld waarin het begrip Medewerker een rol speelt.

    Een universiteit heeft een financiële afdeling. Op deze afdeling heerst de overtuiging dat iedereen die op de loonlijst staat, een Medewerker is. Mensen die niet op de loonlijst staan, zijn geen Medewerker.

    Faculteit A ziet dit anders. Zij beschouwt alle niet-studenten die daadwerkelijk werk verrichten voor de faculteit als Medewerkers. Immers, deze mensen schrijven uren, worden ingepland en leggen beslag op bepaalde ruimtes en hulpmiddelen. Zo komt het voor dat onderzoekers afkomstig van andere onderzoeksinstituten werkzaam zijn binnen de faculteit. Verder zijn er soms gastdocenten die een college verzorgen. Deze mensen staan niet op de loonlijst maar verrichten wel degelijk werkzaamheden.

    Faculteit B hanteert een iets andere definitie. Zij beschouwd in aanvulling op de definitie van Faculteit A ook studenten met een student-assistentschap als Medewerker.

    We hebben hier drie verschillende definities van het begrip Medewerker binnen een organisatie. Net als in mijn vorige blogpost rijst ook hier weer de vraag: Wat is waar?

    Het antwoord is simpel: Alle drie zijn natuurlijk waar. Het hangt er maar vanaf welk gezichtspunt je kiest. Als je wilt uitrekenen wat de student/docent ratio is op een bepaald moment, moet je eerst weten welke vraag je hiermee wilt beantwoorden. Wil je de gemiddelde loonkosten in beeld brengen die gemoeid zijn met het opleiden van een student, dan kun je uit de voeten met de definitie van het begrip Medewerker van de financiële afdeling. Ben je geïnteresseerd in het gemiddeld aantal uren inspanning dat het opleiden van een student kost, dan is de definitie van faculteit A of B wellicht nuttiger.

    De faculteiten zullen mogelijk niet snel bereid zijn de definitie van het begrip Medewerker over te nemen van de financiële afdeling en vice versa. Alle drie de definities hebben echter bestaansrecht. Immers zowel het werkprocessen op de financiële afdeling als de werkprocessen op de faculteiten werken (hopelijk) naar behoren. Je zou kunnen zeggen dat ieder organisatieonderdeel/bedrijfsproces in principe zijn eigen definitie kan hebben van een bepaald begrip en een BI omgeving moet al deze definities faciliteren. Dit hoeft helemaal geen probleem te zijn zolang het voor de eindgebruiker van managementinformatie maar steeds duidelijk is welke definitie gehanteerd wordt.

    Een bijzonder geval vormt die managementinformatie die organisatiebreed en dus afdeling overstijgend is. Dit is typisch het gezichtspunt van het hoger management. Om er hier zeker van te zijn dat we geen appels met peren gaan vergelijken is afstemming nodig met de verschillende organisatieonderdelen waarover we management informatie willen produceren.

    Stel, voortbouwend op het bovengenoemde voorbeeld, dat het College van Bestuur van iedere faculteit een beeld wil hebben van de gemiddelde kosten die worden gespendeerd aan het opleiden van een student per collegejaar. Hiervoor moeten onder anderen de volgende vragen beantwoorden:

    1. In hoeverre kunnen gewerkte uren van Medewerkers worden toegeschreven aan een bepaalde faculteit? Er zijn namelijk Medewerkers met meerdere deeltijdaanstellingen.
    2. Welke kosten kunnen gekoppeld worden aan gewerkte uren van Medewerkers? Denk aan loonkosten en allerhande geldstromen.
    3. Voor welk deel moeten we kosten voor het opleiden van een student toeschrijven aan een bepaalde faculteit? Denk hier aan studenten die cursussen volgen bij verschillende faculteiten.

    Op zich zijn dit stuk voor stuk lastige vragen die ik hier niet ga proberen te beantwoorden. Waar het om gaat is de definitie van het begrip Medewerker in dit verband. Het is duidelijk dat we met de definitie van het begrip Medewerker van de financiële afdeling hier niet uit de voeten kunnen. We kiezen hier de definitie van Faculteit B (dus ook student-assistenten worden als Medewerker beschouwd).

    Vervolgens is het zaak dat dit wordt afgestemd met alle faculteiten. De faculteiten hoeven de definitie van de begrippen die het College van Bestuur hanteert in principe niet over te nemen. Het gaat er hier alleen om dat we voor alle faculteiten inzicht krijgen in de ons ter beschikking staande brondata met betrekking tot Medewerkers. Hiervoor is input van de faculteiten nodig. Het zo verworven inzicht stelt ons technisch in staat om hieruit de management informatie zodanig te construeren dat deze voldoet aan de definities die het College van Bestuur hanteert. De faculteiten kunnen met de brondata op hun managementniveau nog altijd hun eigen ding mee doen, natuurlijk wel met het besef dat er op een hoger gelegen niveau op een (iets) andere manier naar gekeken wordt.

    Ik realiseer mij dat deze zienswijze niet door iedereen wordt aangehangen. In mijn optiek moet een BI omgeving gewoon aansluiten bij de bestaande werkprocessen. De BI omgeving moet nooit dicteren hoe de betrokken organisatieonderdelen moeten werken of communiceren. Er moet ruimte zijn voor verschillende zienswijzen. Hooguit kan de BI omgeving doordat zij inzicht geeft in de verschillen in interpretatie van bepaalde begrippen de aanzet zijn voor een “verbeterproces” om de definitie van begrippen meer op een lijn te krijgen door de organisatie heen.

    Ik ben dan ook een tegenstander van het nastreven van een organisatiebrede “single version of the truth” want: “The truth is in the eye of the beholder.”

  • Managementinformatie: Wat is waar?

    Managementinformatie: Wat is waar?

    In iedere organisatie van enige omvang speelt het uitwisselen van informatie een belangrijke rol.  Het komt dan ook geregeld voor dat er van bepaalde informatie verschillende versies circuleren. Stel je voor: Een hogeschool slaat van alle ingeschreven studenten informatie op in een centraal inschrijfsysteem. Daarnaast gebruikt iedere faculteit haar eigen op zichzelf staande studievolgsysteem (voor de niet ingewijden: een systeem waarin studieresultaten worden bijgehouden).  Ook hierin is informatie over studenten opgeslagen die oorspronkelijk bij instroom is overgenomen van het centrale inschrijfsysteem. Zowel in het inschrijfsysteem, als in het studievolgsysteem kunnen vanaf dat moment onafhankelijk van elkaar wijzigingen worden aangebracht op de studentgegevens. Het is dientengevolge heel goed mogelijk dat in beide systemen tegenstrijdige informatie rondom een bepaalde student is opgeslagen. Dit voorbeeld is slechts het topje van de ijsberg. Soortgelijke problemen doen zich voor bij medewerkers die zowel in het HRM systeem, het financiële systeem en soms ook in het studievolgsysteem (docenten) staan opgeslagen. En nog een (uit eigen ervaring): Als studenten die ingeschreven staan bij faculteit A een cursus volgen bij faculteit B dan wordt de betreffende cursus in het studievolgsysteem van beide faculteiten opgenomen.

    En dan rijst nu de vraag: Wat is waar? Je zou kunnen zeggen dat dit op zich geen interessante vraag is. De student kan immers netjes zijn studie doorlopen en daar is het ons toch allemaal om te doen. Dit is op zich waar. Het punt is alleen dat wanneer we managementinformatie willen gaan afleiden, we voor een dilemma staan. Deze managementinformatie is geen doel op zich maar speelt een belangrijke rol in de kwaliteitscyclus (en uiteindelijk ook in het accreditatieproces). Als de juiste mensen op het juiste moment kunnen beschikken over de juiste managementinformatie, kunnen er beter gestuurd worden.  Misschien doorloopt de student zijn studie dan wel wat sneller, of sluit zijn kennis beter aan op de arbeidsmarkt, om maar eens wat te noemen.

    Hoe voorkomen we dat er onduidelijkheid bestaat over welke informatie we moeten gebruiken voor het afleiden van managementinformatie?

    Een antwoord hierop is Master Data Management (MDM). Het komt er dan op neer dat van alle niet transactionele informatie er een centrale administratie wordt aangewezen die als leidend beschouwd wordt binnen alle werkprocessen in de organisatie. Het decentraal wijzigen van gegevens die onder het MDM regime vallen is dan dus vloeken in de kerk. Dit betekent uiteraard wel dat alle werkprocessen en geautomatiseerde systemen hierop geënt moeten zijn. Dit is geen sinecure. Teruggrijpend naar de bovenstaande voorbeelden moet er dan MDM worden toegepast op de entiteiten Student, Medewerker en Cursus. Als er gekozen is voor een data warehouse als middel voor het verkrijgen van managementinformatie is het laden ervan door MDM een stuk eenvoudiger geworden. Transactionele data uit de verschillende bronsystemen kan dan relatief eenvoudig aan de entiteiten gekoppeld worden die onder MDM vallen.

    Veel organisaties “kiezen” noodgedwongen voor een alternatief voor MDM. Namelijk door voor het verzamelen van brondata voor managementinformatie te kiezen voor een bronsysteem dat als leidend gezien moet worden. Deze leidende data wordt dan eventueel nog aangevuld met data uit niet leidende bronnen. Dit levert in de praktijk bijna per definitie problemen op met betrekking tot het aan elkaar koppelen van data uit verschillende bronsystemen. Het kan in dat geval haast niet anders dan dat de trukendoos open moet om toch maar zoveel mogelijk data wel te kunnen koppelen. Tijdens dit koppelproces zal naar alle waarschijnlijkheid bepaalde data afkomstig uit niet leidende systemen, genegeerd worden. In het beste geval zijn alle betrokkenen (van eigenaren van de bronsystemen tot aan eindgebruikers van de managementinformatie) het eens over de gekozen aanpak. Maar uiteindelijk zullen slechts weinigen kunnen overzien wat de gevolgen zijn van de toegepaste trucs voor de kwaliteit van de managementinformatie die hieruit voortkomt. Waarschijnlijk zijn dit alleen die personen die verantwoordelijk zijn voor de technische realisatie ervan. De verantwoordelijkheid voor datakwaliteit wordt op deze manier bij de verkeerde personen gelegd. Hoe dan ook: deze praktijk komt zeer veel voor.

    Bij het ontbreken van MDM pleit ik ervoor om in ieder geval alle brondata ‘as is’ te bewaren met een tijdsstempel. Namelijk het is best mogelijk dat we bijvoorbeeld door voortschrijdend inzicht bedenken dat het koppelen van data uit verschillende bronnen toch anders moet verlopen. Als we data historisch hebben bewaard, kunnen we met terugwerkende kracht deze nieuwe manier van koppelen alsnog gaan uitvoeren. Een data warehouse ingericht volgens principes als Data Vault  en Anchor Modelling is hier heel geschikt voor.

    We zijn nu op de helft. Als we eenmaal zover zijn dat de we brondata bij elkaar hebben gezocht, moet er nog managementinformatie van gemaakt worden.  In de volgende blogpost ga ik hier wat dieper op in.

  • When does the coding stop?

    When does the coding stop?

    Pas sprak ik met een collega over de vraag waarom we nog steeds met zijn allen zitten te programmeren voor het realiseren van een informatiesysteem. Dit terwijl, als je er door je oogharen naar kijkt, er bij de meeste systemen steeds weer sprake van is dezelfde functionaliteit: het vast leggen van attributen van een entiteiten, het aan elkaar koppelen van entiteiten, of het opvragen van attributen van entiteiten in een of ander vorm. Toch zitten we steeds weer opnieuw en opnieuw te programmeren. Waarom genereren we het gros van de informatiesystemen niet gewoon in hun geheel? Een van de oorzaken is ongetwijfeld het feit dat informatiesystemen naast de grote gemene deler die ze hebben, ook hele specifieke eigenschappen hebben die precies op maat zijn voor een bepaald type gebruiker, situatie of platform. Deze specifieke functionaliteit is vaak lastig op generieke wijze te modeleren (bijvoorbeeld met een Model Driven Design tool) en vervolgens te genereren. Eenmalig genereren en daarna handmatig uitbreiden lukt nog wel meer onderhoud plegen vanuit een functioneel model is al snel lastig. Kort gezegd: hoe meer je genereert, hoe meer flexibiliteit je inlevert.

    De laatste jaren houd ik me voornamelijk bezig met data warehousing. Reuze interessante materie maar in het bouwproces zie ik wel veel herhaling van hetzelfde. Onwillekeurig dringt zich dan de weer vraag bij mij op: Waarom zit ik nog steeds te coderen? Gelukkig ben ik niet de enige met dit soort gedachten. Zo zijn de jongens (en meisjes?) van Qosqo al druk doende met de ontwikkeling van het product Quipu waarmee op basis van de structuur van bronbestanden Data Vaults gegenereerd kunnen worden met bijbehorende ETL. Ik denk echter dat codegeneratie binnen de data warehousing context nog veel breder kan worden toegepast. Ik zou een data warehouse architectuur willen kunnen ontwikkelen zonder perse toe te moeten werken naar een specifieke architectuur, en zonder me vast te pinnen op een bepaalde wijze van datamodellering. Ik zou graag op enkel op basis van een specifatie van de brondata en de requirements die gelden voor het data warehouse een volledig functionerende data warehouse architectuur willen kunnen genereren. Het maakt mij dan niet uit of het resultaat een Data Vault, Anchor Model, Historical Staging Area, Dimensional Model of een of andere mengvorm is. De te gebruiken modelleringstechniek is typisch iets dat ik buiten de requirements zou willen houden op basis waarvan de data warehouse architectuur gegenereerd gaat worden.

    Ik zie het als volgt voor me: In een data warehouse architectuur zijn, functioneel gezien, een aantal lagen te onderscheiden:

    • De inputlaag, oftewel de databronnen. Deze zijn een gegeven en moeten dus enkel goed beschreven worden bijvoorbeeld in de vorm van een logisch datamodel per bron en bepaalde eigenschappen van de bron (verderop geef enkele voorbeelden).
    • De opslaglaag. Het hart van het data warehouse. Deze moet na analyse van de wensen van de gebruikers en de beschikbare databronnen worden vormgegeven. Modelleren kan in de vorm van logisch datamodel, uitgebreid met wat specifieke eigenschappen (zie verderop).
    • De outputlaag. Hiermee interacteert de gebruiker. De outputlaag is typisch het product van een transformatieproces met als input de opslaglaag en een verzameling business rules. Doorgaans wordt data in deze laag ontsloten door bijvoorbeeld BI tools zoals een cube, een dashboard met KPI’s, standaardrapporten of een voor gebruikers begrijpelijke informatielaag (zoals de Universe van BO en de Catalog van Cognos). Maar alles is hier in principe mogelijk. Er kan gebruik worden gemaakt van logische datamodellen om de basisdata te beschrijven die beschikbaar moeten zijn om de gewenste output mogelijk te maken.

    Tussen de input- en de opslaglaag en de opslag- en de outputlaag kunnen mappings gedefinieerd worden. Deze vormen dan de basis voor het genereren van de benodigde ETL code.

    De input- en opslaglagen zijn mijns inziens volledig functioneel te modelleren op een min of meer declaratieve wijze. De outputlaag is de lastigste en kan mogelijk niet volledig gemodelleerd worden zonder te vervallen in een verkapt soort programmeren (waar we juist vanaf willen). Dit is vooral het geval als er zeer exotische (en die komen vaker voor dan ons lief is) business rules het spel zijn.

    Toch is er ook iets te zeggen voor een eenvoudige basistaal waarin procedurele beschrijvingen van business rules kunnen worden vastgelegd. Een dergelijke taal biedt namelijk een platformonafhankelijke wijze waarop allerhande transformaties kunnen worden vastgelegd. Als we het vervolgens voor elkaar krijgen alle business rules met deze beperkte taal volledig te modelleren, kunnen we ook het onderhoud op de resulterende data warehouse architectuur via dit model blijven doen. Anders blijft altijd de noodzaak bestaan om na het genereren van een nieuwe versie van de data warehouse architectuur handmatige correcties op de niet gegenereerde code uit te voeren.

    Wat winnen we met een dergelijke benadering:

    1. We kunnen alle benodige datastructuren genereren op basis van het model.
    2. We kunnen alle benodigde ETL genereren op basis van het model.
    3. Na wijzigingen in het model kunnen we ook de migratie van de oplossing gebaseerd op het oude model naar de oplossing gebaseerd op het nieuwe model automatiseren.
    4. We zijn niet afhankelijk van de onderliggende techniek omdat we het systeem volledig functioneel hebben beschreven. Komt er nieuwe technologie in beeld, dan kan m.b.v. de bijbehorende code generator het nieuwe systeem gegenereerd worden.

    Hieronder noem enkele zaken die zoal moeten worden vastgelegd in het functionele model van de BI oplossing. Het is uiteraard slechts een schot voor de boeg.

    Informatie rondom de inputlaag

    • Welk type databron betreft het?(csv, Excel sheets, xml, tabellen in een Oracle database, Webservice, …)
    • Moet de brondata continue of per interval worden bijgeladen?
    • Hebben we per laadbatch de beschikking over een volledige of onvolledige foto van het bronsysteem of alleen de delta’s
    • Mag de databron live worden benaderd voor BI doeleinden of niet?
    • Per bronbestand: Welke entiteiten,relaties en attributen zijn er?
    • Per entiteit: Hoe kan deze uniek te geïdentificeerd worden (of is er misschien een foutkans, zie ook een vorige blogpost)?

    Informatie rondom de data in de opslaglaag

    • Welke entiteiten,relaties en attributen hebben we?
    • Wat willen we wel en wat willen we niet historisch bewaren?
    • Vanuit welk attribuut in de inputlaag, correspondeert met welk attribuut in de opslaglaag?

    Informatie rondom de data in de outputlaag

    • Per outputvorm (cube, dashboard etc): Welke KPI’s, meetwaarden en dimensies onderscheiden we?
    • Welke entiteiten in de opslagstructuur hebben we nodig om een KPI, meetwaarde of dimensie te creeeren?
    • Per outputvorm: Hoe vaak moet data ververst worden?

    Ik realiseer me dat dit een wel zeer globale schets is, en dat er nog het nodige denkwerk verzet moet worden om tot een werkende oplossing te komen. Het is echter de moeite waard om dit verder uit te werken. Alleen zo kunnen we uiteindelijk zeggen: “The coding finally stops!” Ik wil iedere lezer dan ook aanmoedigen om hierop te schieten en zijn/haar ideeën met mij te delen. Wellicht zijn er al vergaande ontwikkelingen in deze richting waarvan ik geen weet heb. Ik verneem ze graag!

  • Kimball versus Inmon

    Kimball versus Inmon

    ©Richard Steijn http://www.vaiper.nl

    Bill Inmon over Ralph Kimball’s bottom-up aanpak.

    “You can catch all the minnows in the ocean and stack them together and they still do not make a whale,”
    Bill Inmon, January 8, 1998.

  • De charme van Anchor Modeling

    De charme van Anchor Modeling

    Anchor Modeling intrigeert mij al een tijdje. Zo’n anderhalf jaar geleden kreeg ik hiervan voor het eerst een artikel in DB/M, geschreven door Ronald Kunenborg, onder ogen. Wat mij meteen aansprak was de elegantie van de modelleringmethode. Verder viel op dat het in een bepaald opzicht nogal extreem was. Ik zal niet ontkennen dat juist dat extreme ook wel stiekem een zekere aantrekkingskracht op mij uitoefende. Anchor Modeling is namelijk extreem in die zin dat een data warehouse vormgegeven volgens deze methodiek een enorme hoeveelheid tabellen kent. Juist op dat moment had ik net de keuze gemaakt voor de Data Vault aanpak voor het Boven-wijs project dat toen net van start was gegaan.

    Ook bij een Data Vault model was het al even wennen gezien de grote hoeveelheid tabellen die er bij komen kijken. Gegeven een logisch datamodel met twee entiteiten met ieder vijf attributen en tussen de entiteiten een één op veel relatie, dan resulteert dit in een fysiek datamodel in de derde normaalvorm van slechts twee tabellen, waarvan er een middels een foreign key refereert naar de ander.

    Volgens de Data Vault methode komen we al snel op vijf tabellen: voor iedere entiteit een Hub, tussen de twee Hubs een Link en voor iedere Hub minimaal één Satellite om de attributen in onder te brengen. Voor een beknopte uitleg van DV zie een van mijn eerdere posts.

    Modelleren we echter volgens de Anchor Modeling methodiek, dan komen we op een fysiek datamodel van maarliefst 13 tabellen!: voor iedere entiteit een Anchor, tussen de twee Anchors een Tie en voor ieder attribuut een Attribute tabel. In onderstaande afbeelding is deze situatie gevisualiseerd: de rode blokken zijn Anchors, de cirkels zijn Attributes, de grijze ruit is een Tie.

    Anchor Modeling kent vier typen objecten:

    Anchor

    Deze representeert het bestaan van een entiteit. Het bestaat enkel uit een surrogaatsleutel. Het Anchor is vergelijkbaar met de Hub in Data Vault. Echter in een Anchor tabel wordt geen unieke business key opgeslagen zoals dit wel in de Hub gebeurt.

    Knot

    Deze representeert een eindige set vaste waarden. Het bestaat uit een surrogaatsleutel en een veld waarin de ermee geassocieerde waarde wordt opgeslagen. Bijvoorbeeld een knot voor de eigenschap geslacht {(1, Man), (2, Vrouw)} is goed denkbaar. De Knot is de tegenhanger van van de Reference table in Data Vault.

    Attribute

    Deze representeert een eigenschap van een Anchor. Deze bevat een veld met daarin de waarde van de eigenschap OF een referentie naar een specifiek record in een Knot tabel.

    Tie

    Deze representeert een relatie tussen twee of meer Anchors en eventueel een Knot. Een Tie kan geen Attributes hebben. Het is dus de tegenhanger van een Link zonder Satellites in Data Vault. Als van een relatie eigenschappen moeten worden bewaard, moet de relatie worden gemodelleerd als een Anchor, waar dan Attributes aan gekoppeld kunnen worden.

    Voor alle objecttypen geldt dat er een veld in opgenomen mag worden met een verwijzing naar metadata.

    De objecttypen Attribute en Tie kunnen static of historized zijn. In het eerste geval wordt er geen historie bewaard van het bewuste object, in het tweede geval wel. Dit gaat met behulp van een extra datum veld (ValidFrom).

    Dit is de methode in een notendop.

    Het apart onderbrengen van een attribuut in zijn eigen tabel zoals de Anchor Modeling methode predikt, kan zorgen voor onoverzichtelijkheid. Een beetje serieus data warehouse gaat al snel over tientallen entiteiten met in totaal honderden attributen. Wanneer we een dergelijk model handmatig moeten onderhouden zien we al snel door de bomen het bos niet meer. Bovendien rijst de vraag, of een dergelijk data warehouse fatsoenlijk te bevragen is, als er een substantiële hoeveelheid data in zit. Om informatie over een bepaalde entiteit op te halen, moeten vele joins gelegd worden tussen het corresponderende Anchor en alle ermee verbonden Attributes. Kortom we hebben standaard te maken met complexe queries en mogelijk trage queries. Dit alles in overweging nemend, heb ik destijds, ondanks dat ik de modeleerwijze heel elegant vind, besloten het maar op Data Vault te houden.

    Echter, recentelijk heb ik een open gast college bijgewoond bij de HAN waar mede-bedenker Lars Rönnbäck een lezing hield over Anchor Modeling. Een aantal van mijn twijfels heeft hij hier (deels) weggenomen:

    • Hij gaf aan dat Anchor Modeling nog klein is. Maar hoe dan ook zijn er enkele toepassingen van deze methodiek in gebruik in Zweden, o.a. in de financiële sector (niet de minst kritische sector). Het werkt dus echt in de praktijk, naar het schijnt naar tevredenheid. Prettig om te weten.
    • Er werd een artikel aan de toehoorders uitgereikt waarin onder andere een experiment stond beschreven waaruit grofweg afgeleid kan worden dat naarmate het data warehouse meer data bevat, de query performance onder diverse condities, relatief beter wordt, vergeleken met de situatie waarin alle data in enkele tabel is opgeslagen. Dit geldt met name naarmate er meer attributen in het spel zijn. Dit experiment is reproduceerbaar en kan hier worden gedownload. Wat meer experimenten zijn wel gewenst. Zo zou het bijvoorbeeld heel interessant zijn, te zien hoe snel het laden van een Anchor database verloopt, vergeleken met bijvoorbeeld het laden van een enkele tabel of een Data Vault.
    • Op www.anchormodeling.com is een mooi vormgegeven en prettig werkend online Anchor Modeling tool ontwikkeld waarmee op grafische wijze een Anchor Model kan worden gemaakt. Er is goed nagedacht over het hanteerbaar maken van de grote hoeveelheid symbolen die je met elkaar moet verbinden bij een datamodel van enige omvang. De DDL om het gemaakte model vervolgens om te zetten in een database wordt automatisch gegenereerd. Jammer genoeg wordt momenteel alleen SQL Server ondersteund, maar er wordt gewerkt aan het ondersteunen van andere databases zoals Oracle. Op deze site staan overigens diverse korte instructiefilmpjes waarin je snel wegwijs met de modeling tool. Het tool is overigens Open Source.
    • Naast DDL voor het definiëren van tabellen worden er ook diverse hulpobjecten (views, functions) gegenereerd die het uitvragen van het data warehouse aanzienlijk makkelijker maken. Voor ieder Anchor in het model is er bijvoorbeeld een zogenaamde ‘latest’ view waarmee je een Anchor en alle bijbehorende Attributes kunt opvragen zoals deze momenteel gelden. Ook is er een point-in-time functie waarmee je een Anchor met zijn Attributes kunt opvragen zoals deze golden op een bepaald moment in de tijd.
    • Verschillende databases maken gebruik van het zogenaamde ‘table elimination’ principe. Dit principe zorgt ervoor dat als een view bestaat uit meerdere aan elkaar gejoinde tabellen en er wordt informatie opgevraagd uit slechts enkele van deze tabellen, dan worden de voor de betreffende vraag irrelevante tabellen geëlimineerd uit het queryplan. Als bijvoorbeeld op de bovengenoemde ‘latest’ view behorend bij een Anchor met vijf Attributes een query wordt uitgevoerd waarbij slechts een Attribute wordt opgevraagd, worden de vier overige Attributes en de Anchor table buiten het query plan gehouden. Dit is voor een Anchor database zeer belangrijk mechanisme, gezien de performance winst die dit oplevert.
    • Er is een naming convention die helpt orde te scheppen in de vele objecten die voorkomen in een Anchor Model.

    Kortweg kunnen we concluderen dat er veel mogelijk is (wat deels al gedaan is) om een Anchor Modeling tot een werkbare modelleringtechniek te maken. Verder wordt er gewerkt door de bedenkers van de techniek aan verdere onderbouwing door middel van experimenten. Ik denk dat dit alles ook hard nodig is, om de drempel om deze techniek toe te passen, te verlagen. Anchor Modeling is een techniek die niet zomaar afgeserveerd kan worden als een extreme rariteit. Daarvoor is er te goed over nagedacht. Het is het dan ook waard om er eens in te duiken.