Over mij

Ik ben Richard Steijn en datawarehousing/BI specialist. Bij vele organisaties in diverse branches heb ik een kijkje in de keuken mogen nemen. Verscheidene technologieën hebben mijn pad gekruist. Data en alle vraagstukken daaromheen vormen een rode draad in mijn werkzame leven. In deze blog schrijf ik over de dingen die mij zoal bezighouden.

door Richard Steijn

Archief voor 'Analyse'

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

Delen van de data warehouse architectuur die declaratief te modeleren 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.

Voor ieder platform een codegenerator

Hieronder noem ik 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?
  • 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!

Een datawarehouse bouwen op drijfzand

Het uniek kunnen identificeren van entiteiten is van groot belang voor een datawarehouse. Binnen transactiesystemen die de bron vormen voor een datawarehouse wordt dit doorgaans netjes geregeld door een unieke index te definiëren op de velden die een entiteit identificeren. Op deze manier kan worden afgedwongen dat op ieder moment in de tijd het betreffende veld of combinatie van velden de unieke sleutel vormen van een entiteit binnen het betreffende systeem. Wanneer we vervolgens data uit het betreffende transactiesysteem willen inlezen in een datawarehouse, kunnen we op basis van deze unieke sleutel bepalen bij welke entiteit een bepaald data item hoort.

In deze post wil ik wat dieper ingaan op het concept unieke sleutel. De ene sleutel is de andere niet. Sleutels hebben aspecten die soms over het hoofd worden gezien maar die van wezenlijk belang zijn voor het kunnen ‘volgen’ van een entiteit binnen een bepaald bronsysteem door de tijd heen.

Eeuwig versus Tijdelijk

Vaak wordt er vanuit gegaan dat een unieke sleutel binnen een bronsysteem voor altijd gekoppeld blijft aan een en dezelfde entiteit. Dit is echter een aanname die door de werkelijkheid kan worden ingehaald. In systemen waar gebruikers de mogelijkheid hebben om unieke sleutels te wijzigen, kan het al dan niet bedoeld, gebeuren dat de sleutel die voorheen aan entiteit A was gekoppeld nu verbonden is met entiteit B. Zelfs de veelgebruikte technische sleutel (ook wel surrogaatsleutel genoemd) is wat dat betreft niet veilig. Het kan namelijk voorkomen dat een bestaand transactiesysteem wordt overgezet naar een andere database, waarbij de technische sleutels opnieuw gegenereerd en aan entiteiten gekoppeld worden. In een dergelijk geval is het heel waarschijnlijk dat de technische sleutels gerecycled worden. Kort gezegd: Er zijn unieke sleutels die Eeuwig zijn en er zijn unieke sleutels die Tijdelijk zijn. Wat betreft tijdelijke sleutels is het nog nuttig om te weten of ze alleen Gecontroleerd, of ook Ongecontroleerd, kunnen wijzigen. Van een sleutel die gecontroleerd wijzigt, krijgen we bij ieder geval van wijziging een signaal. Naar aanleiding van dit signaal kunnen we maatregelen nemen zodat we de betreffende entiteit in het bronsysteem kunnen blijven volgen in het datawarehouse. Bij sleutels die ongecontroleerd kunnen wijzigen, kan dat niet en hebben we te maken met een zekere foutkans. Bij een transactiesysteem dat we middels een Changed Data Capture mechanisme volgen, wijzigen tijdelijke sleutels altijd gecontroleerd. Een ander voorbeeld van een gecontroleerd wijzigende tijdelijke sleutel is een surrogaatsleutel binnen een transactiesysteem waarvan we op de hoogte gehouden worden, als er bijvoorbeeld een datamigratie plaatsvindt.

Universeel versus Optioneel

In de loop der tijd kan er voor een bepaald entiteittype een nieuwe unieke sleutel ontstaan. Bijvoorbeeld binnen het basisonderwijs is het sinds een aantal jaren verplicht om in correspondentie over een leerling met overheidsinstanties het centraal uitgegeven onderwijsnummer te gebruiken. Leerlingvolgsystemen zijn dientengevolge uitgebreid met een extra uniek veld ‘Onderwijsnummer’. Voor reeds uitgestroomde leerlingen was echter geen onderwijsnummer beschikbaar. Daarom is in veel systemen het veld ‘Onderwijsnummer’ naast uniek (voor zover ingevuld) ook Optioneel: het mag de waarde NULL bevatten. Omgekeerd kunnen reeds bestaande sleutels in onbruik raken en zo Optioneel worden. De tegenhanger van het kenmerk Optioneel noem ik Universeel.

Sterk versus Zwak

Tot slot kan het voorkomen dat een veld of een combinatie van velden logischer wijze gebruikt kan worden als sleutel maar dat binnen het bronsysteem geen uniciteit wordt afgedwongen. Dit type sleutel noem ik Zwak vanwege de verhoogde foutkans. Dit is een type sleutel dat bij voorkeur vermeden moet worden als identificatiemiddel maar helaas zijn we hier soms, bij gebrek aan beter, op aangewezen. Wanneer we zwakke sleutels gebruiken voor identificatie, doen we er goed aan de mogelijkheid in te bouwen om op zo simpel mogelijke wijze de gevolgen van een achteraf fout gebleken identificatie terug te draaien. Het alternatief is: accepteren dat er een zekere foutmarge is. De tegenhanger van het kenmerk Zwak noem ik Sterk: uniciteit wordt afgedwongen in het bronsysteem.

Een taxonomie van sleutels

Alle sleutels zijn te karakteriseren met een combinatie van bovenstaande kenmerken. In de onderstaande tabel zijn alle mogelijke combinaties weergegeven. Iedere combinatie in de tabel staat dus voor een type sleutel. Per type sleutel is aangegeven of deze een 100% betrouwbare (+) mogelijkheid biedt om een entiteit in een bepaald bronsysteem door de tijd heen te volgen in het datawarehouse of niet (-).

Let wel dat ook de classificatie van een sleutel een momentopname is. Door omstandigheden kunnen hierin wijzigingen optreden. Een sleutel die bijvoorbeeld op een bepaald moment Universeel is, kan in de loop der tijd in onbruik raken en worden vervangen door een andere sleutel. Vanaf dat moment is hij Optioneel.

Ieder datawarehouse dat gevoed wordt met data die op discrete momenten in de tijd (dus niet continue) aan een bronsysteem wordt onttrokken, loopt het gevaar, het spoor van bepaalde entiteiten kwijt te raken als er niet 100% veilige sleutels in het spel zijn. In wezen is het datawarehouse dan gebouwd op drijfzand. Mijn inschatting is dat dit vaker wel dan niet aan hand is. Ga maar na: de meeste bronsystemen leven in het hier en nu. Ze houden vaak geen rekening met wijzigingen van unieke sleutels door de tijd heen. Enige relativering is hier wel op zijn plaats. Unieke sleutels die op de werkvloer een rol spelen (de niet-technische sleutels dus), hebben doorgaans niet de neiging om om de haverklap van waarde te veranderen. Dit zou op de werkvloer namelijk resulteren in een voortdurende zoektocht naar de juiste informatie binnen een bronsysteem. Het dagelijks werk zou hierdoor sterk belemmerd worden. Aan de andere kant geldt ook hier de wet van Murphy: ’Anything that can go wrong will go wrong’.

Daarom is het goed je te realiseren waar dit probleem kan optreden. Nog beter is het om dit probleem op een of andere manier te kwantificeren. Het is onmogelijk om de situaties te identificeren waar dit optreedt, immers dan zou het probleem niet bestaan. Wat we wel kunnen doen is bijvoorbeeld iedere keer dat het datawarehouse wordt geladen, tellen hoeveel sleutelwaarden er in het verleden wel in het bronsysteem stonden  maar nu niet meer. Een andere interessante meting is, daar waar een entiteit met meerdere sleutels identificeerbaar is, te tellen hoe vaak een bepaalde sleutelwaarde door de tijd heen is gecombineerd met verschillende waarden van de alternatieve sleutel. Zo zijn er nog meer metingen te verzinnen (Suggesties zijn zeer welkom!). Een oplossing is dit niet maar het geeft wel enigszins grip op de situatie en helpt ons om iets te zeggen over foutmarge.

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 Data Vault, zie deze blog post.

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 rode cirkels zijn Attributes, de grijze ruit, geflankeerd door twee grijze bolletjes 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 werkelijk prachtig 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 wordt gemaakt 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.

Het modelleren van werkprocessen

In het voortraject van een data warehouse project gaan we op zoek naar potentiële informatiebronnen die in het te ontwikkelen data warehouse kunnen worden ingelezen. We willen de onderlinge samenhang tussen alle in gebruik zijnde gegevensbronnen in kaart brengen. We willen hier weten welke gegevens in welke informatiebronnen zitten, wat is de overlap tussen deze bronnen, welke bronnen zijn leidend, etc.  Dit noem ik het in kaart brengen van het datalandschap.

Zo gauw we weten hoe het datalandschap eruit ziet, kunnen we ons een beeld vormen van hoe de verschillende gegevensbronnen zijn ingebed in de organisatie. De volgende elementen zijn hier van belang:

  • Gegevensbronnen
  • Activiteiten in relatie tot de gegevensbronnen
  • Actoren binnen deze activiteiten
  • De volgorde van deze activiteiten
  • De gevolgen van deze activiteiten voor de data in de gegevensbronnen

Kortom we gaan werkprocessen binnen de organisatie in beeld brengen met een sterke nadruk op de data die hierin een rol speelt.

Waarom moeten we dit allemaal weten? Heel eenvoudig omdat dit ons helpt de gegevens op hun waarde te schatten. We krijgen inzicht in het moment waarop gegevens voor het data warehouse nuttig zijn. Bovendien brengen we zo nauwkeurig alle belanghebbenden (stake holders voor liefhebbers van Engelse termen) in beeld. Dit zijn de mensen waarmee rekening gehouden moet worden tijdens en na het project. Sommigen bevinden zich aan de invoerkant van de bronsystemen en hebben dus invloed op de kwaliteit van de gegevens. Anderen bevinden zich juist aan de vragende kant van deze systemen en kunnen een rol spelen bij het bepalen van de informatie die in het data warehouse moet worden opgeslagen. Al deze mensen zullen (moeten) op een of andere manier te maken krijgen met het data warehouse. Als zij er op de juiste manier bij betrokken worden, zal dit positief bijdragen aan het vormen van voldoende draagvlak voor het data warehouse binnen de organisatie.

In deze blog wil ik een schematechniek aanreiken waarmee we werkprocessen in beeld kunnen brengen. Er zijn verschillende technieken in gebruik voor dit soort doeleinden. Ik heb echter nooit een gangbare schematechniek kunnen ontdekken waarin we alle elementen zoals ik deze hierboven heb opgesomd, ineens kan visualiseren. Daarom heb ik mijn eigen schematechniek samengesteld door elementen uit verschillende bestaande technieken bij elkaar te brengen. Deze diagramstijl presenteer ik ook in de data warehouse cursussen die ik soms geef. Daar leg ik hem uit aan de hand van het volgende voorbeeld:

Stel we willen voor een onderwijsinstelling het proces in beeld brengen genaamd: “Afname Tentamen”. In dit proces wordt beschreven hoe een tentamencijfer van een student wordt bepaald, geadministreerd en vrijgegeven vanaf het moment dat het tentamen wordt afgenomen. In dit proces spelen 3 actoren een rol te weten:

  • De cursusleider
  • De tweede beoordelaar
  • De Student

Het proces start op het moment dat de cursusleider (die ook het tentamen afneemt) het blad met tentamenvragen aanbiedt aan de student. De student vult de antwoorden in het blad met tentamenvragen. Na afloop van het tentamen beoordeelt de cursusleider de ingeleverde tentamens, waaronder het tentamen van “onze” student. Het cijfer schrijft hij op een lijst met tentamenscores. Als hij een tentamen beoordeelt met een cijfer tussen de 5 en de 7 dan wordt het betreffende tentamen voorgelegd aan een tweede beoordelaar. Ook deze kent een cijfer toe en schrijft dit op een tweede lijst met tentamenscores. Vervolgens bepaalt de cursusleider aan de hand van de door hemzelf ingevulde lijst met scores en die van de tweede beoordelaar wat het eindcijfer zal zijn: Hij neemt het gemiddelde. De uiteindelijke score voert hij in in het studievolgsysteem waarop de studenten ook een account hebben. Als de student inlogt in het studievolgsysteem, kan hij zijn uiteindelijke score bekijken.

Dit proces is als volgt gevisualiseerd:

Processchema Afname Tentamen

De actoren in het proces hebben in dit diagram ieder hun eigen functiebaan (swim lane). Een actor kan een natuurlijk persoon of eventueel een groep personen zijn. Het kan ook een geautomatiseerd systeem zijn, dat bepaalde acties uitvoert binnen het werkproces. Deze laatste variant komt in het voorbeeld niet voor.

De legenda van bovenstaand diagram ziet er als volgt uit:


  • Het icoon met de tekst “Begin/Eind Proces” wordt gebruikt om de start en het einde van het proces te markeren. Het maakt niet uit in welke functiebaan deze geplaatst wordt. Er is altijd een Begin Proces icoon en minimaal een Eind Proces icoon.
  • Het rode icoon dient om een actie weer te geven. De functiebaan waarin de actie geplaatst is, geeft aan wie/wat de actie uitvoert. Een actie heeft altijd een of meer inkomende gesloten pijlen: deze geven de richting van de processtroom weer. Een actie kan een willekeurig aantal in- of uitgaande gestippelde pijlen hebben: de informatiestromen. Een actie heeft altijd exact een uitgaande gesloten pijl.
  • Het grijze icoon met de tekst “Informatie drager” representeert een gegevensbron. Dit alles zijn wat informatie bevat, variërend van een database systeem tot een kladblaadje. Als in het diagram vaker dan eenmaal een informatiedrager icoon voorkomt met daarin dezelfde tekst, dan betreft dit dezelfde informatiedrager. In het voorbeeld representeren de twee iconen met de tekst “Tentamen” een en hetzelfde tentamenblad. Twee verschillende informatiedragers van hetzelfde soort, moeten dus ieder voorzien worden van een uniek label. Het maakt niet uit in welke functieband een informatiedrager geplaatst wordt. Dit zegt niets over het eigenaarschap van de informatiedrager.
  • Een groene ruit representeert een beslissing. In de ruit is de vraag weergegeven waarvan het antwoord erop bepaalt, in welke richting het proces verder zal worden voortgezet. Een beslissing heeft minimaal een inkomende gesloten pijl en minimaal 2 uitgaande gesloten pijlen. Iedere uitgaande gesloten pijl is voorzien van een label die aangeeft bij welk antwoord op de vraag in de ruit het hoort.
  • Een gesloten pijl geeft de processtroom weer. Normaal gesproken staat er in een processtroom geen tekst, behalve als deze stroom vertrekt vanuit een beslissing. Gesloten pijlen kunnen alleen vertrekken of binnenkomen in Begin/Einde Proces iconen, Actie iconen en Beslissing iconen. Het moet mogelijk zijn om vanuit het Begin Proces Icoon alle Eind Proces iconen te bereiken als de gesloten pijlen gevolgd worden.
  • Een gestippelde pijl geeft een informatiestroom weer die van een Informatiedrager naar een Actie loopt of andersom. In de gestippelde pijl staat altijd d.m.v. een korte tekst aangegeven, welke informatie het precies betreft.

Dit is de basis van de schema techniek. Simpel en doeltreffend. Eventueel zouden alle iconen nog kunnen worden voorzien van een uniek nummer om er in een begeleidende tekst makkelijker naar te kunnen verwijzen. Welliswaar oogt het resulterende diagram wat vol en mogelijk gecompliceerd. Het geeft echter wel in een (of twee) oogopslag(en) een mooi overzicht van verschillende aspecten weer van werkprocessen. Het is niet alleen handig in de context van een data warehouse project. Het kan ook handig zijn om bijvoorbeeld inefficiënties in een werkproces duidelijk te maken.