Artikel

Data-integratie met een slag om de arm

Data-integratie speelt een belangrijke rol bij datawarehousing en dataconversietrajecten. Eigenlijk heeft data-integratie veel weg van het maken van een grote legpuzzel. Verspreid in de tijd en over verschillende systemen, wordt allerhande informatie opgeslagen over entiteiten die voor een organisatie van belang zijn. Deze verspreide datafragmenten vormen de stukjes van de legpuzzel. De uitdaging voor de datawarehouse architect bestaat hier uit het bij elkaar zoeken van deze puzzelstukjes zodat een zo compleet mogelijk beeld ontstaat van deze entiteiten. Ook moet er vaak een zo goed mogelijke reconstructie gemaakt worden van hoe deze entiteiten zijn veranderd in de tijd. Dat dit lang niet altijd even eenvoudig is zal ik in dit artikel illustreren aan de hand van de data-integratieproblemen die ik bij de ontwikkeling van het product Boven-wijs ben tegengekomen.

Context

Boven-wijs is een management informatiesysteem dat gebruikt kan worden om de prestaties van onderwijsinstellingen te meten, zodat men hierop vervolgens kan acteren. In de huidige fase ligt de focus nog op het meten van leerprestaties. Deze focus zal in de toekomst mogelijk verbreed worden naar andere aspecten (zoals financieel en personeel) van het onderwijsproces.  De doelgroep bestaat momenteel uit beslissers binnen individuele scholen, schoolbesturen en beleidsmakers van gemeenten. Boven-wijs wordt aangeboden als een via het web te benaderen SAAS oplossing.  Deelnemende scholen leveren hiertoe informatie aan rondom hun leerlingen en hun prestaties op diverse landelijke toetsen. Deze gegevens worden ingelezen in een datawarehouse van waaruit vervolgens diverse managementoverzichten en stuurgetallen worden gegenereerd die men via het web kan bekijken. Omix, de eigenaar van Boven-wijs, speelt hiermee in op een groeiende behoefte aan stuurinformatie in en rondom het onderwijs.     

Hieronder beschrijf ik aan de hand van een realistische casus een mogelijke toepassing van Boven-wijs.  Vervolgens zal ik inzoomen op de uitdagingen rondom data-integratie die hier naar voren komen.

Casus

Een grote gemeente wil zicht krijgen op de kwaliteit van het onderwijs (van primair tot voortgezet) zoals dit binnen de gemeentegrenzen wordt gegeven. Voor dit doel moet een datawarehouse worden opgezet. De gemeente wil onder andere onderzoeken hoe de leerprestaties die behaald zijn in het primair onderwijs zich verhouden tot die in het voortgezet onderwijs. Hiervoor is het noodzakelijk dat binnen het datawarehouse de onderwijsloopbaan van individuele leerlingen gevolgd kan worden vanaf groep 1 tot aan het laatste examenjaar in het voortgezet onderwijs. In het datawarehouse moeten de leerprestaties (in de vorm van cijfers op het jaarlijkse eindrapport en uitslagen op landelijk afgenomen toetsen en examens) van alle leerlingen die ooit op een school binnen de gemeente onderwijs volgden, worden ingelezen.  Alle ruim 300 scholen binnen de gemeente moeten voor dit doel periodiek informatie aanleveren over hun leerlingen en de leerresultaten die zij behaald hebben. Deze informatie wordt in de vorm van een of meer exportbestanden onttrokken aan de informatiesystemen die de scholen in gebruik hebben.

Vaak is er per school meer dan een informatiesysteem in het spel. Sommige scholen zijn in het verleden overgestapt op een ander volgsysteem. De persoonsgegevens en toetsresultaten van leerlingen die op het moment van deze overstap op de betreffende school zaten zijn (mogelijk gedeeltelijk) terug te vinden in beide bronsystemen.  Bij sommige scholen wordt registratie rondom leerlingen en registratie rondom schoolprestaties in aparte systemen gedaan. Verder is het een bekend verschijnsel dat basisscholen de uitslag op de Cito Eindtoets niet meer opslaan in hun volgsysteem omdat de betreffende leerlingen toch de school verlaten. In deze gevallen moeten de toetsscores worden gehaald van het Cito Portal waartoe iedere school  toegang heeft. Een nadeel van Cito Portal is dat een leerling hier wordt geïdentificeerd aan de hand van de naam en de geboortedatum. Deze gegevens zijn ook nog eens ingescand vanaf toetsformulieren die handmatig zijn ingevuld door de leerkracht.  Verder komt het voor dat een leerling van school verandert, met als gevolg dat sommige leerlingen voorkomen in de systemen van meerdere scholen.

In de beschreven situatie hebben we te maken hebben met een kleine 600 bronsystemen, waarin potentieel informatie is opgeslagen over een specifieke leerling. In totaal zijn er op de basisscholen acht verschillende typen systemen in gebruik voor het registreren van leerlingen en hun schoolprestaties en in het voortgezet onderwijs nog eens vijf. De verschillende typen systemen hebben ieder hun eigen en soms zeer beperkte exportmogelijkheden. Het gevolg hiervan is dat bij bepaalde systemen meerdere exportbestanden geproduceerd moeten worden om alle voor het datawarehouse benodigde informatie te extraheren. 

Leerlingen identificeren

Om leerlinginformatie te kunnen integreren, moeten we eerst bepalen hoe we leerlingen uniek kunnen identificeren. Leerlingen kunnen in de verschillende exportbestanden niet allemaal op dezelfde wijze geïdentificeerd worden. Soms is er zelfs binnen een exportbestand niet een enkele sleutel aan te wijzen waarmee alle entiteiten uniek te identificeren zijn. Stel: een school heeft de volgsystemen X en Y en Cito Portal in gebruik. Aan deze systemen worden exportbestanden onttrokken met daarin informatie over leerlingen. In Box 1 zijn van enkele records in deze exportbestanden de velden weergegeven die gebruikt kunnen worden om een leerling te identificeren.

Box 1: Voorbeelden van verschillende sleutelvelden per exportbestand behorend bij een bepaalde school

In bovenstaand voorbeeld zijn de volgende sleutels te onderscheiden:


Burgerservicenummer:

Iedere Nederlandse burger krijgt een uniek burgerservicenummer.  Helaas is dit veld, met name bij oudere leerlingen nogal eens leeg in de volgsystemen.

Onderwijsnummer:

Iedere leerling in Nederland krijgt sinds een aantal jaren een uniek onderwijsnummer toegekend.  Normaal gesproken is dit nummer gelijk aan het burgerservicenummer. Echter buitenlandse leerlingen krijgen een voorlopig onderwijsnummer. Als de leerling een Nederlands staatsburger wordt, krijgt hij/zij een burgerservicenummer en het onderwijsnummer wordt hier vervolgens aan gelijk gesteld. We hebben hier dus te maken met een sleutel die, mits ingevuld, weliswaar uniek hoort te zijn, maar kan wijzigen in de tijd. Helaas geldt ook voor dit veld dat deze met name bij oudere leerlingen niet altijd ingevuld is.

Leerlingnummer:

Dit is een technische sleutel (surrogaatsleutel) die  kan worden gebruikt om de leerling uniek te identificeren binnen een bronsysteem. Een dergelijke sleutel kan alleen worden gebruikt om leerlingen in exportbestanden afkomstig van hetzelfde systeem te identificeren. In het voorbeeld bevatten de exportbestanden afkomstig uit volgsysteem X en Cito Portal een surrogaatsleutel.

Naam+Geboortedatum:

Dit type sleutel gebruiken we liever niet omdat unieke identificatie hier niet 100% gegarandeerd is. Maar bij het ontbreken van alternatieven zijn we hier toch op aangewezen. Naaminformatie heeft verschillende verschijningsvormen. Dit resulteert dan ook in een aantal mogelijke combinaties van velden die als sleutel gebruikt kunnen worden:

  • Voornamen, Achternaam, Geboortedatum (volgsysteem X)
  • Roepnaam, Achternaam, Geboortedatum (volgsysteem Y)
  • Initialen, Achternaam, Geboortedatum (volgsysteem Y en Cito Portal)

Het kan voorkomen dat sommige van deze velden leeg zijn of dat de inhoud in de loop der tijd wijzigt.

 

Leerlinginformatie integreren

We kunnen twee vormen van integratie onderscheiden:

  1. Integratie van records, afkomstig uit hetzelfde bronsysteem op verschillende momenten in de tijd.
  2. Integratie van records, afkomstig uit verschillende bronsystemen.

Voor data-integratie van het eerste type zijn zowel technische als niet-technische sleutels bruikbaar. Voor data-integratie van het tweede type zijn we aangewezen op niet-technische sleutels, ook wel business keys genoemd. Daar waar we te maken hebben met zwakke sleutels (sleutels die niet 100% zeker tot een unieke identificatie leiden) is de kans op fouten kleiner naarmate de context waarin we werken, nauwer is. Als we bijvoorbeeld binnen de bronsystemen van een school een leerling op basis van naam en geboortedatum identificeren is de foutkans aanzienlijk kleiner dan wanneer we dit op landelijk niveau zouden doen. Hieruit volgt dat het nuttig is ook contextinformatie mee te nemen in het identificatieproces. Binnen Boven-wijs is dit opgelost door een administratie op te zetten waarin per te laden bronbestand context beschrijvende meta-informatie is  vastgelegd. Het betreft meta-informatie rondom:


Bronbestand:

Informatie over het bronbestand zelf. Bijvoorbeeld: welk type bronbestand is het, op welke datum is het geproduceerd, onder welke bestandsnaam is het opgeslagen op de server. Ieder geladen bronbestand krijgt zijn eigen unieke nummer zodat ernaar verwezen kan worden.

Bronsysteem:

Het concrete bronsysteem dat het bronbestand geproduceerd heeft. Ieder geregistreerd bronsysteem krijgt zijn eigen unieke nummer zodat ernaar verwezen kan worden. 

Bronorganisatie:

Informatie over de school die eigenaar is van het bronsysteem dat het bronbestand geproduceerd heeft.

In Box 1 zijn de verschillende records in de exportbestanden genummerd van 1 t/m 9. De records 1, 4 en 7 hebben allen betrekking op de dezelfde persoon. Hetzelfde geldt voor de records 2, 5 en 8 en de records 3, 6 en 9. Deze records kunnen vaak niet bij elkaar gezocht worden op basis van recht-toe-recht-aan matchen van sleutels. Hier moet “fuzzy matching” worden toegepast.

Data-integratie verloopt bij voorkeur geautomatiseerd. Er zijn diverse geautomatiseerde fuzzy matchingmethoden te bedenken. Bijvoorbeeld record 1 en 4 zijn te matchen door van record 1 de  inhoud van het veld Voornamen nemen en hiervan de initialen “RAE” af te leiden, daarachter de inhoud van velden Achternaam en Geboortedatum en dit te vergelijken met de inhoud van de velden Initialen, Achternaam en Geboortedatum van record 4.

Omdat we gebruik maken van een geautomatiseerd fuzzy matching proces, moeten we rekening houden met de kans dat sommige matches onterecht worden gemaakt. Ook zal het voorkomen dat bepaalde matches niet geautomatiseerd gemaakt kunnen worden. Bijvoorbeeld in record 7 is het veld Achternaam gevuld met een schijnbaar willekeurige tekenreeks: een typisch gevolg van het inscannen van handgeschreven tekst. Het feit dat record 7 betrekking heeft op dezelfde persoon als record 4, kan alleen worden bepaald door navraag te doen. Daarom is het noodzakelijk dat handmatig gecorrigeerd kan worden zonder concessies te doen op de traceerbaarheid van de data naar de bron.

Architectuur

Een belangrijk onderdeel van het Boven-wijs project was het creëren van een datawarehouse dat voldoet aan een aantal algemene basisprincipes:

  • Traceerbaarheid: Het moet mogelijk zijn om van ieder record in het datawarehouse te bepalen van welk record in een bepaald bronsysteem het is afgeleid.
  • Non Volatility:  Historie moet ongewijzigd bewaard blijven. Als van een reeds eerder geladen entiteit nieuwe attribuutwaarden worden geladen in het datawarehouse, moeten de oude waarden ongewijzigd en gedateerd bewaard worden. 
  • Maximale data-integratie: Data afkomstig uit verschillende bronsystemen moet in het datawarehouse zo goed mogelijk geïntegreerd worden opgeslagen.
  •  Toekomstbestendigheid: Het datawarehouse moet zo soepel mogelijk meebewegen met wijzigingen in de bronsystemen (bijvoorbeeld als een school een nieuw type bronsysteem in gebruik neemt) en wijzigingen in wensen van de gebruiker of het aanwenden van het datawarehouse voor geheel nieuwe doeleinden. De reeds bestaande datastructuren in het datawarehouse en de bijbehorende ETL procedures moeten zo weinig mogelijk onderhoud vragen bij wijzigende randvoorwaarden.

Met een datawarehouse opgezet volgens de principes van Data Vault kan tegemoet worden gekomen aan bovenstaande eisen. Echter: de in de casus beschreven situatie brengt een aantal specifieke problemen met zich mee en vragen om doordachte ontwerpkeuzes.

De grote hoeveelheid bronsystemen die informatie leveren met betrekking tot dezelfde entiteittypes stelt speciale eisen aan de systeemarchitectuur. Er is gekozen voor een architectuur waarin allereerst per bronsysteem data-integratie plaats vindt op basis van het exact (dus niet fuzzy) matchen van sleutelvelden. Als er binnen een bronsysteem hiervoor een algemeen toepasbare unieke sleutel  beschikbaar is dan wordt enkel op deze sleutel geïntegreerd. Als dit niet het geval is wordt geïntegreerd op de combinatie van alternatieve sleutels (zie verderop). Voor volgsysteem X en Cito Portal uit het voorbeeld wordt er geïntegreerd op het veld Leerlingnummer. Voor volgsysteem Y wordt geïntegreerd op alle beschikbare alternatieve sleutels tezamen.

Omdat er vele bronsystemen van hetzelfde type zijn die allen exportbestanden leveren met dezelfde structuur die met dezelfde ETL geladen kunnen worden, is er per bronsysteem type een afzonderlijke Data Vault gedefinieerd: de Source Type Data Vault (stDV). De consequentie van deze benadering is dat de business key van iedere Hub binnen de stDV per definitie het veld BronSysteemId bevat. Het begrip business key zoals we dat van Data Vault kennen is hier dus enigszins opgerekt.

Ten behoeve van de bronsysteemoverstijgende  data-integratie is er een zogenaamde Integration Data Vault (iDV) gedefinieerd. In de iDV worden de relaties tussen de records in de verschillende stDV’s opgeslagen. Verderop in dit artikel wordt hierop dieper ingegaan.

De volgende laag is de Business Data Vault (bDV). De bDV is de plek waar de uitkomsten van business rules die op een gegeven moment gelden, historisch worden opgeslagen. Daarnaast bevat het views en zogenaamde point-in-time functions die deze uitkomsten combineren met data uit de verschillende stDV’s en en de iDV. Zo geeft de bDV een blik op alle stDV’s en de iDV alsof het een enkel geïntegreerd datawarehouse betreft.  

Tenslotte worden vanuit de bDV data marts gegenereerd die toegesneden zijn op de informatiebehoefte van de verschillende eindgebruikers.

Metadata zoals de eerder genoemde data over te laden bronbestanden wordt opgeslagen in de Metadatabase. Ook wordt hier een registratie aangelegd van alle mogelijke matchingmethodes die worden toegepast in het automatische matchingproces. In Box 2 is de systeemarchitectuur schematisch weergegeven. De gele pijlen geven aan hoe de informatiestromen lopen

Box 2: Systeemarchitectuur

 

De key combination Hub

Een van de uitgangspunten van Data Vault is dat het feit dat er informatie in een bronsysteem aanwezig is die behoort bij een bepaalde entiteit (zoals een leerling) wordt gerepresenteerd door een rij in een hubtabel en dat het betreffende record uniek identificeerbaar is met behulp van een enkele onveranderlijke business key.  Dit staat op gespannen voet met het feit dat er binnen sommige bronbestanden (zoals het bestand afkomstig uit Volgsysteem Y in Box 1) niet één enkele sleutel is aan te wijzen waarmee en leerling uniek geïdentificeerd kan worden. Soms hebben we de beschikking over de ene sleutel, dan weer over de ander. Veel sleutels zijn niet eens gegarandeerd onveranderlijk in de tijd. Om dit probleem het hoofd te bieden, heb ik een nieuwe variant op het concept hub geïntroduceerd: de Key Combination Hub (KC hub). De KC hub bevat alle kolommen die onderdeel van een alternatieve sleutel zijn voor een bepaald entiteittype. Een KC hub wordt per type bronsysteem gedefinieerd, uiteraard alleen wanneer er sprake is van meerdere alternatieve sleutels voor een entiteittype. Uitgaand van het voorbeeld in Box 1 is het alleen voor volgsysteem Y nodig een KC hub te definieren voor entiteittype Leerling. In Box 3 is deze KC hub schematisch weergegeven.   

Box 3: De key combination hub voor entiteittype Leerling in volgysteem Y

De velden weergegeven in witte letters zijn metadata velden die ook bij een reguliere hub bestaan. In het veld BronId wordt het in de Metadatabase geregistreerde id van het bronbestand waaruit de data afkomstig is, opgeslagen. Het blauw weergegeven Bk_BronSysteemId is noodzakelijk om data-integratie per bronsysteem mogelijk te maken. Kenmerkend voor een KC hub is dat van de sleutelvelden alleen het veld BK_BronSysteemId altijd een waarde heeft. De overige sleutelvelden zijn optioneel. Er is alleen sprake van een match tussen een te laden bronrecord en een record in de KC hub als alle sleutelvelden overeenkomen.

Omgaan met foutkans

Een ander probleem is dat we soms leerlingrecords moeten integreren op basis van naam en geboortedatum. Eerder is al aangegeven dat we hier gebruik moeten maken van fuzzy matching. Het is goed denkbaar dat onze fuzzy matching methoden zich ontwikkelen in de tijd door voortschrijdend inzicht.  Bijvoorbeeld: op een gegeven moment introduceren we een nieuwe matchingmethode op naamgegevens en geboortedatum die niet hoofdlettergevoelig is (“JAN JANSEN 20-06-2001” = “jan jansen 20-06-2001”). Weer wat later introduceren we nog een methode die tevens ongevoelig is voor diacrieten (“Orhan Özinar 19-03-2002” = “ORHAN OZINAR 19-03-2002”). Gevolg hiervan is dat sommige records die aanvankelijk betrekking leken te hebben op twee verschillende leerlingen op een later tijdstip toch over dezelfde leerling blijken te gaan. Omdat we trouw willen blijven aan het non-volatility principe, betekent dit dat we het resultaat van de matchingmethoden historisch moeten bewaren in het datawarehouse.

De iDV bevat de datastructuren die hiervoor nodig zijn. Nadat vanuit de Staging Area records in de stDV’s geladen zijn, kan het matching proces gestart worden en wordt de data in de iDV bijgewerkt. Voor ieder entiteittype waarvoor we fuzzy matching toepassen is er in de iDV een hub gedefinieerd ten behoeve van bronsysteemoverstijgende data-integratie.  Voor het entiteittype Leerling is in Box 4 een dergelijke hub weergegeven (H_Leerling).  Voor ieder record in de leerling hubs in een van de stDV’s wordt in de hub H_Leerling in de iDV een corresponderend record toegevoegd. Als business key wordt in dit geval het id van het bronsysteem (Bk_BronSysteemId) en het id van het betreffende hub record in de stDV (Bk_stDVId) opgeslagen.  Hiermee hebben we een bronsysteemoverstijgende registratie van alle leerling sleutels die er zijn in de stDV’s. 

Records die betrekking hebben op één en dezelfde persoon worden met elkaar in verband met behulp van een linktabel. Deze linktabel (in Box 4 afgebeeld met de naam L_Match) koppelt twee records in H_Leerling aan elkaar, samen met het id van de matchingmethode die geleid heeft tot de koppeling (BK_MatchingMethodeId). Deze linktabel wordt normaal gesproken gevuld met behulp van een geautomatiseerd matchingproces. Als dit het geval is wordt in het veld BronId de waarde 0 opgeslagen.  

Om in staat te zijn een koppeling tussen twee records H_Leerling te activeren of deactiveren is er voor de linktabel L_Match een satellitetabel S_Status gedefinieerd (zie Box 4). Deze tabel heeft naast de voor een satellite gebruikelijke metavelden de attribuutvelden Actief en Geblokkeerd. Het veld Actief wordt gebruikt om aan te geven dat de link al dan niet actief is.  Het veld Geblokkeerd dient om aan te geven of het betreffende statusrecord door een geautomatiseerd matchingproces overruled kan worden. Als tijdens het geautomatiseerde matchingproces er een record aan L_Match wordt toegevoegd, wordt eveneens een bijbehorend record aan S_Match toegevoegd. Het veld BronId  wordt in dat geval met 0 gevuld, het veld Actief met True (=koppeling geactiveerd) en het veld Geblokkeerd met False (=niet geblokkeerd).

Met de beschreven tabellenstructuur zijn we in staat om leerling hubrecords in de verschillende stDV’s aan elkaar te relateren op een wijze die traceerbaar is naar de bron. Omdat  in deze tabellen historie wordt bijgehouden, is het mogelijk om terug te komen op data-integratie beslissingen uit het verleden  en tegelijkertijd te voldoen aan het non-volatility principe. Wat echter nog ontbreekt is een unieke sleutel waarmee een groep hubrecords die allen betrekking hebben op eenzelfde persoon geïdentificeerd kan worden. Voor dit doel is de hubtabel H_Leerling voorzien van een satellittetabel S_Integratie. Deze tabel heeft slechts één attribuutveld: IntegratieId. Ieder record in H_Leerling dat (volgens de huidige inzichten) eenzelfde persoon identificeert, is te herkennen aan dezelfde waarde in het veld IntegratieId. De inhoud van tabel S_Integratie wordt, met behulp van een algoritme, steeds bijgewerkt als er iets verandert in de tabellen H_Leerling, L_Match of S_Status.

Box 4: Tabellen rondom entiteittype Leerling in de Integration Vault

In Box 5 is, voortbouwend op het voorbeeld in Box 1, afgebeeld hoe de tabellen in de iDV samenhangen met de verschillende tabellen in de stDV’s. De witte pijlen geven foreign key relaties weer. De zwarte onderbroken pijlen geven een logische relatie weer, waarvoor geen foreign key relatie bestaat

Box 5: Voorbeeld Integration Data Vault

Handmatig ingrijpen

Omdat we leerling hubrecords in de verschillende stDV’s koppelen door middel van de datastructuren in de iDV, is het mogelijk om deze koppelingen op een later moment, buiten het automatische matching proces om, inactief te maken. Ook kunnen  koppelingen die volgens de huidige inzichten ten onrechte niet gemaakt zijn, alsnog aangemaakt worden. Dit kan door wijzigingen aan te brengen in records in de linktabel L_Match en de bijbehorende records in satellitetabel S_Status. De inhoud van deze tabellen wordt niet rechtstreeks met de hand gewijzigd. Dit gebeurt middels het laden van een correctiebestand dat handmatig wordt aangemaakt. In Box 6 is een voorbeeld van de inhoud van een correctiebestand weergegeven.

Box 6 Voorbeeld correctiebestand voor de integratietabellen rondom Hub H_Leerling in de iDV

De opzet is eenvoudig: De velden Hub1_id en Hub2_id bevatten het id van de leerling hubrecords in de iDV waartussen we een koppeling willen maken (eerste regel) of juist verbreken (tweede regel). Het veld Matchingmethode_id wordt voor alsnog aan te maken koppelingen altijd gevuld met de waarde 1 (=handmatige matching). Het veld Geblokkeerd wordt doorgaans op True gezet (zodat deze wijziging achteraf niet door het automatische matchingproces ongedaan gemaakt wordt). Het veld Actief wordt gevuld met de waarde True als de koppeling vanaf nu geldig moet zijn en False als dit juist niet het geval is.

Het laden van een correctiebestand in de tabellen L_Match en S_Status verloopt op de standaard wijze waarop bronbestanden  in een linktabel en satellitetabel geladen worden binnen een Data Vault. In Box 7 is weergegeven hoe de inhoud van de tabellen wijzigt als gevolg van het laden van het correctiebestand in Box 6. Het correctiebestand wordt voorafgaand aan het laden, geregistreerd in de Metadatabase en krijgt daar een uniek id (234) toegekend. Dit id wordt opgeslagen in het veld Bron_Id van de nieuw aangemaakte records.

Box 7: Data in integratietabellen rondom Hub H_Leerling in de iDV voor en na het laden van hetcorrectiebestand

 

Door op deze manier te werk te gaan, zijn ook handmatige ingrepen eenvoudig terug te traceren naar de bron. 

Workflow

Telkens als we nieuwe bronbestanden met leerlinginformatie gaan laden moet er een aantal terugkerende handelingen worden uitgevoerd. Meteen na het laden moet het geautomatiseerde data-integratie proces worden uitgevoerd, waarin de inhoud van de tabellen in de iDV wordt bijgewerkt. Vervolgens is het verstandig enkele standaard controles uit te voeren zodat in een vroeg stadium verdachte gevallen opgespoord worden. Denk hierbij bijvoorbeeld aan het opvragen van alle nieuw ingelezen Leerling hub records in de stDV’s die sinds de laatste run enkel met een matching methode gematcht zijn die we als ‘zwak’ aanmerken. Na deze controle kan het nodig zijn dat er wordt ingegrepen middels het laden van correctiebestanden. Vervolgens wordt de data in de iDV weer bijgewerkt en wordt er opnieuw gecontroleerd. Deze workflow is nog eens schematisch weergegeven in Box 8

Box 8: Workflow rondom het laden en integreren van data rondom leerlingen

 

Conclusie

In gevallen waar we entiteiten van eenzelfde type in de verschillende bronsystemen niet altijd met dezelfde sleutelvelden kunnen identificeren en waar data-integratie die de grenzen van de bronsystemen overschrijdt enigszins “fuzzy” en dus foutgevoelig is, is het verstandig de betreffende data in twee stappen te integreren.  Als de in dit artikel beschreven werkwijze wordt gevolgd, zijn we in staat om op een later tijdstip nog correcties aan te brengen in de uitkomst van het data-integratieproces. Kortom: data-integratie met een slag om de arm. Dit terwijl we nog steeds de voordelen genieten die Data Vault ons brengt voor wat betreft flexibiliteit, traceerbaarheid en stabiliteit in de tijd.

Dankwoord

Langs deze weg wil ik Roland Bouman bedanken voor de kritische review van dit artikel.

 

Categorie:   
Auteur(s)
afbeelding van richardsteijn
Richard Steijn
Vaiper - Data warehouse/BI Consultant

Richard Steijn is onafhankelijk Data warehouse/BI consultant. Data en alle vraagstukken daaromheen vormen een rode draad in zijn werkzame leven.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.