4 Patronen
Dit hoofdstuk beschrijft een aantal standaard patronen voor datalineage en de omstandigheden waarbij deze het best aansluiten. Een patroon is een standaard soort oplossing voor een bepaald type probleem. De diversiteit aan patronen in dit hoofdstuk laat zien dat datalineage allerlei verschillende vormen aan kan nemen in de praktijk.
4.1 Overzicht
In de volgende paragrafen wordt een uiteenlopende verzameling van patronen beschreven. Om wat meer ordening aan te brengen en de positionering van de patronen beter te begrijpen staan ze in de volgende tabel globaal gepositioneerd in dezelfde thema’s als de standaarden.
| Generieke basis | Transparantie | Data-engineering | Specifieke toepassingen |
|---|---|---|---|
|
|
|
|
Tabel 7: Globale positionering van patronen
Naast bovenstaande positionering geldt dat de patronen in een volgorde van toenemende complexiteit worden beschreven. De patronen 4, 6, 7 en 8 kun je zien als een samenhangende groep, met daarbij een toenemend detailniveau. Deze set van patronen wordt verder uitgewerkt in het voorbeeld in hoofdstuk 5 en het profiel in hoofdstuk 6.
Figuur 5 geeft een visueel overzicht van de patronen door hun essentiële structuren weer te geven. Deze reflecteren de structuur die direct beschikbaar is in de datalineage metagegevens. Het zijn nadrukkelijk vereenvoudigde structuren, die alleen tot doel hebben om de essentie van de patronen weer te geven. Ze geven bijvoorbeeld niet weer welke rol transformaties hebben in de patronen. Daarnaast zijn een deel van de weergegeven relaties in de praktijk niet expliciet vastgelegd, maar kunnen deze afgeleid worden uit andere relaties. Zo kun je de relatie tussen gegevensclusters afleiden uit de relaties die op het niveau van gegevenselementen zijn vastgelegd.
Figuur 5: Visueel overzicht datalineage patronen
4.2 Patroon 1: Enkelvoudige gegevensobjecten
Dit is een triviaal geval waarbij iemand, mogelijk samen met anderen, aan één gegevensobject werkt, dat verder niet gerelateerd is aan andere gegevensobjecten. Dat is typisch een officebestand, webpagina of een multimediaal bestand, zoals een afbeelding of video.
Bij dit patroon is sprake van een hele simpele vorm van datalineage. Daarbij staat het gegevensobject centraal en gaat het vooral over het vastleggen van relatief eenvoudige metagegevens van dit gegevensobject zoals de persoon die het object heeft gecreëerd, de organisatie waarvoor deze persoon werkt, het moment waarop het object is gecreëerd, de personen die het object hebben gewijzigd, de organisaties waarvoor deze personen werken en de datum waarop de laatste wijziging heeft plaatsgevonden.
Een aantal soorten gegevensobjecten hebben standaard mechanismen om dit soort metagegevens vast te leggen, als onderdeel van het object zelf. Denk bijvoorbeeld aan de standaard mogelijkheden in officedocumenten. Voor afbeeldingen kunnen dit soort metagegevens vastgelegd worden in bijvoorbeeld de EXIF metagegevens. Voor webpagina’s kan gebruik worden gemaakt van de Dublin Core standaard, als onderdeel van de pagina zelf. Voor het duurzaam toegankelijk maken van dit soort gegevensobjecten is de MDTO standaard van toepassing.
4.3 Patroon 2: Versionering
Dit is een specifieke vorm van datalineage, waarbij er één gegevensobject wordt gewijzigd in de tijd en waarbij het relevant is om te weten wie, wanneer, wat en om welke reden heeft gewijzigd. Het kan gaan om wijzigingen in gegevensobjecten zoals benoemd in het vorige patroon, maar ook bijvoorbeeld om gegevensobjecten in een database of bestanden zoals programmacode die wordt beheerd in versiebeheersystemen zoals Git.
Bij deze vorm van datalineage staat het gegevensobject centraal en is niet zo relevant wat de activiteit was (omdat dat vooral het aanbrengen van de wijziging is). Er spelen typisch ook geen geautomatiseerde transformaties een rol in de datalineage. Het is vooral relevant om de relatie tussen de versies van de gegevensobjecten vast te leggen, inclusief een beschrijving van wie, wanneer en om welke reden de wijziging heeft plaatsgevonden.
De Dublin Core en PROV standaarden kunnen beiden worden toegepast bij dit patroon. In Dublin Core zijn de replaces en de inverse isReplacedBy eigenschappen geschikt om opvolging van versies van gegevensobjecten te duiden. In de PROV-O standaard is de klasse Revision benoemd om versies van gegevensobjecten te beschrijven en wordt de wasRevisionOf eigenschap gebruikt om de relatie tussen deze versies te leggen. De Provenance, Authoring and Versioning (PAV) vocabulaire maakt het mogelijk om meer gericht rollen van actoren en versies te beschrijven. Dit is echter een standaard die niet formeel door een standaardisatie-instelling is goedgekeurd en beheerd en de toepassing daarvan heeft dus niet de voorkeur.
4.4 Patroon 3: Datalineage op gegevensobjectniveau
Bij dit patroon verwijzen de gegevensobjecten in een dataset naar de gegevensobjecten in de dataset die eraan ten grondslag ligt. Hiervoor worden er identificaties van de originele gegevensobjecten opgeslagen bij de daarvan afgeleide gegevensobjecten. In geval van gestructureerde gegevens is een gegevensobject een instantie van een gegevenscluster. Denk bijvoorbeeld aan een record in een relationele database, die een instantie is van een tabel.
Dit patroon is een basis voor het herleidbaar maken van gegevens. Het kan los van de andere patronen worden toegepast. Als het in de context van gestructureerde gegevens niet wordt gecombineerd met patroon 5 dan veronderstelt het (impliciete) kennis bij de gebruiker van de datalineage om deze goed te kunnen interpreteren.
De Dublin Core en PROV standaarden kunnen beiden worden toegepast bij dit patroon. In Dublin Core is de source eigenschap bedoeld om te verwijzen naar de bron van een gegevensobject. In de PROV-O standaard is hiervoor de used eigenschap beschikbaar. Dit soort informatie wordt in de context van relationele databases vaak in speciaal daarvoor bedoelde kolommen vastgelegd.
4.5 Patroon 4: Datalineage op datasetniveau
In dit geval is er sprake van een dataset (of informatieproduct) die gebaseerd is op andere datasets, maar waarvoor het niet nodig is om precies te weten hoe de individuele gegevenselementen precies tot stand zijn gekomen. Dit detailniveau kan vaak in eerste instantie al voldoende zijn.
Dit past met name op situaties waarbij:
- Er geen afnemers zijn die om gedetailleerd inzicht vragen en/of
- Er geen complexe transformaties plaatsvinden en/of
- De dataset met vaste en gedocumenteerde processen wordt gecreëerd.
Bij dit patroon is het voldoende om naast basismetagegevens zoals beschreven in paragraaf 4.1 (maar zonder namen van personen) een verwijzing op te nemen naar de datasets die zijn gebruikt als bron. Als de dataset is beschreven conform DCAT dan kunnen de daarvoor aanwezige eigenschappen in DCAT worden gebruikt (zie paragraaf 3.4).
Als datasets voor hergebruik beschikbaar zijn dan is er eigenlijk altijd behoefte aan een definitie van de gegevens in de dataset, minimaal in de vorm van een logisch gegevensmodel. Liefst zijn bedrijfsregels en/of afleidingsregels bij een dataset ook beschikbaar omdat van overheidsorganisaties in het algemeen transparantie wordt verwacht.
4.6 Patroon 5: Datalineage op logisch niveau
Een deel van de horizontale datalineage kan al worden vastgelegd op logisch ontwerpniveau (en daarmee op typeniveau). Er zijn dan nog geen gegevens en het technische datamodel is mogelijk ook nog niet bekend. Er is al wel een logisch gegevensmodel.
De datalineage gaat in dit patroon over de wijze waarop gegevens worden getransformeerd in de context van bepaalde activiteiten om een bepaalde dataset te creëren. Het is daarvoor niet voldoende om op basis van de afleidingsregels in de transformatie een mapping te definiëren van de elementen van het gegevensmodel van de brondataset naar die van de afgeleide dataset. Een dergelijke mapping bestaat altijd alleen in de context van een specifieke activiteit. Anders gezegd: er is niet per definitie slechts één mapping tussen beide gegevensmodellen. Er kan bijvoorbeeld een activiteit zijn die invoergegevens van verschillende partijen bij elkaar optelt. Er kan echter ook een activiteit zijn die een correctie uitvoert op de aangeleverde gegevens. Zonder kennis van welke activiteiten echt worden uitgevoerd kun je niets zeggen over welke mapping van toepassing is op de bijbehorende gegevensmodellen.
Dit patroon kan worden gebruikt om tijdens het (logische) ontwerp een vorm van datalineage vast te leggen. De patronen 6, 7, 8 en 9 zijn meer gericht op het achteraf documenteren (op fysiek niveau). De criteria zoals beschreven bij patroon 7 (datalineage op gegevenselementniveau) zijn ook grotendeels van toepassing op dit patroon. Er zit echter overlap in beide patronen, waardoor het belangrijk is een goede afweging te maken of beide patronen worden toegepast of dat structureel één van de twee wordt gekozen. Zo zijn de transformaties zowel op logisch als op fysiek niveau te beschrijven en het vraagt het inspanning en discipline om beide niveaus vast te leggen en actueel en consistent te houden.
4.7 Patroon 6: Datalineage op gegevensclusterniveau
Een gegevenscluster is een groepering van gegevenselementen, zoals een tabel. Bij dit patroon worden gegevens uitgewisseld tussen databases, waarbij tabellen uit brondatabases grotendeels één-op-één terecht komen in een doeldatabase. Dit geldt bijvoorbeeld voor het laden van gegevens in de staging area van een datawarehouse, operational datastore of in een datalake. Daarbij kan gebruik maken van verschillende vormen van uitwisseling zoals bestandsuitwisseling, change data capture, of directe verbindingen tussen databases, eventueel gecombineerd met ETL scripts.
Dit patroon lijkt op patroon 5, maar het dataset niveau is niet afdoende omdat tabellen uit verschillende databases bij elkaar in één database terecht komen. Datalineage op typeniveau is meestal voldoende bij dit patroon. Het is ook meer gericht op gegevenslogistiek binnen een organisatie, met name in de context van datawarehousing en business-intelligence.
4.8 Patroon 7: Datalineage op gegevenselementniveau
In dit geval wordt er een dataset (of informatieproduct) geleverd en is er ook een behoefte om precies te weten hoe de gegevens in de dataset tot stand komen op basis van de brongegevens. Tabel 8 geeft een overzicht van relevante criteria om te bepalen of datalineage op het niveau van gegevenselementen gewenst is, inclusief de rationale waarom dat het geval is. Als meer criteria van toepassing zijn dan wordt de relevantie van datalineage op gegevenselementniveau hoger.
| Criterium | Rationale |
|---|---|
|
Er zijn afnemers die gedetailleerd inzicht vragen |
De behoeften van afnemers zijn sterk bepalend voor het gewenste niveau van datalineage. Zo kunnen bijvoorbeeld bepaalde externe auditors detailinzicht vragen. |
|
Er vinden complexe transformaties (zoals berekeningen) plaats |
Complexe transformaties roepen meer vragen op over hoe uitvoergegevens tot stand komen op basis van de invoergegevens. |
|
De dataset bevat meerdere kritieke gegevenselementen |
De impact van fouten in kritieke gegevenselementen is groot en meer inzicht in de totstandkoming van gegevens creëert meer vertrouwen in hun juistheid. |
|
De dataset of de gebruikte brongegevens en/of transformaties wijzigen vaak |
In geval van frequente wijzigingen kunnen gebruikers niet vertrouwen op hun bestaande kennis om te begrijpen hoe gegevens tot stand komen. |
|
De dataset wordt voor een groot aantal andere datasets of informatieproducten gebruikt |
Een breder gebruik van een dataset maakt het bepalen van de impact van wijzigingen op afnemers belangrijker. Datalineage geeft inzicht in afhankelijkheden. |
|
De dataset wordt gebruikt als input voor AI of geautomatiseerde besluitvorming |
Aan AI en geautomatiseerde besluitvorming worden hogere eisen m.b.t. transparantie gesteld. |
|
Er zijn meerdere organisaties of afdelingen betrokken bij de dataset |
Betrokkenheid van meer partijen verhoogt het belang van afstemming en inzicht. Er kan niet worden vertrouwd op kennis van een beperkt aantal mensen. |
|
Er is sprake van migratie van gegevens naar een nieuwe applicatie |
Bij migratie van applicaties is belangrijk dat wordt aangetoond dat de gegevens in de nieuwe applicatie overeenkomen met de gegevens in de oude applicatie. |
|
Gegevens worden in hoge volumes en/of hoge frequentie geautomatiseerd verwerkt |
De impact van foutieve gegevens is hierbij hoog en het is belangrijk om snel inzicht in problemen en mogelijke oplossing te krijgen. |
|
De dataset heeft een juridische status en kan gebruikt worden in een rechtszaak |
De impact van foutieve gegevens is hierbij hoog omdat er juridische besluiten op worden gebaseerd. Het is ook belangrijk om formeel aan te tonen hoe gegevens tot stand zijn gekomen. |
Tabel 8: Criteria voor datalineage op het niveau van gegevenselementen
Eén van de criteria om te bepalen of datalineage op het niveau van gegevenselementen gewenst is heeft betrekking op of ze kritiek zijn. Voor kritieke gegevenselementen geldt dat het essentieel is dat ze correct zijn voor de succesvolle uitvoering van processen in de organisatie. Ze bieden een vorm van prioritering voor het verbeteren van de kwaliteit van gegevens. Er zijn geen harde criteria die bepalen of een gegevenselement kritiek is, maar de volgende kenmerken geven daarvoor wel een belangrijke indicatie. Het betreft gegevens die:
- zijn vereist vanuit wet- en regelgeving;
- belangrijk zijn voor besluitvorming;
- worden gebruikt in key performance indicatoren;
- impact hebben op het operationele proces en de kwaliteit van producten/diensten;
- gevoelig zijn;
- worden gebruikt voor externe rapportages;
- verwijzen naar mastergegevens.
Bij dit patroon wordt de datalineage in ieder geval op typeniveau vastgelegd. Daarbij is het nodig om van elk gegevenselement te weten op welke andere gegevenselementen deze is gebaseerd en welke transformaties daarbij worden gebruikt. Er is dus ook een beschrijving van deze transformaties gewenst, bij voorkeur op verschillende abstractieniveaus (conceptueel, logisch, implementatie) zodat verschillende afnemers kunnen worden bediend. Het verschil met het beschikbaar stellen van afleidingsregels zoals benoemd in paragraaf 4.4 (als optie) is dat er in dit patroon een meer gestructureerd en ketenbreed inzicht ontstaat in de gegevensstromen en transformaties. In plaats van losse bestanden met beschrijvingen is er een centrale, gestructureerde metagegevensrepository die op allerlei manieren kan worden doorzocht en gevisualiseerd.
4.9 Patroon 8: Datalineage van instanties van gegevenselementen
Dit patroon is een specialisatie van het vorige patroon, waarbij datalineage van de instanties van gegevenselementen wordt vastgelegd. Het gaat daarbij dus over de waarden die deze gegevenselementen hadden. Deze kunnen alleen door het uitvoeren van bewerkingen en transformaties worden bepaald. Datalineage op instantieniveau kost veel meer inspanning en kan eventueel ook op verzoek worden gegenereerd (lazy datalineage).
Het vastleggen van datalineage op instantieniveau is vooral relevant als specifieke afnemers hierom vragen, bij migratie van gegevens naar een nieuwe applicatie of als een dataset een juridische status heeft. Daarnaast biedt het meer ondersteuning bij analyse van fouten.
Datalineage van instanties van gegevenselementen is alleen waardevol voor gebruikers die toegang hebben tot de brongegevens.
Als de dataset zelf een juridische status heeft en dus gebruikt kan worden in een rechtszaak dan is aanvullend erg belangrijk dat exact duidelijk is van welk moment bepaalde gegevens en brongegevens zijn gebruikt en dat de bijbehorende versies van deze gegevens nog beschikbaar zijn. Dat geldt ook voor de versies van de transformaties die zijn gebruikt. In meer algemene zin is het bijhouden van de historie van gegevens belangrijk en moet ook rekening worden gehouden met archivering.
4.10 Patroon 9: Verantwoording over verwerkingen
Dit patroon is de basis voor verantwoording van overheden over hun gegevensverwerkingen. Het kan worden ingezet ter ondersteuning van recht op inzage, correctie en verwijdering zoals bedoeld in de AVG, maar is ook relevant voor allerlei andere wet- en regelgeving die vraagt om een vorm van verantwoording van verwerkingen van gegevens.
Voor deze situaties is het Logboek Dataverwerkingen ontwikkeld, waarbij alle individuele verwerkingsactiviteiten of onderdelen ervan worden vastgelegd. Deze standaard wordt bij voorkeur ondersteund door de applicatie zelf, maar er zou ook een (zelf te ontwikkelen) adapter tussen kunnen zitten.
De Logboek Dataverwerkingen standaard legt primair gegevens vast gerelateerd aan de verwerking zelf. Het kan verwijzen naar bijvoorbeeld het algoritmeregister, waarin het algoritme dat is gebruikt voor de verwerking is gedocumenteerd. De standaard zelf biedt beperkte mogelijkheden om aan te geven welke gegevens precies worden verwerkt. Door gebruik te maken van een extensie kunnen hier nog wel meer details over worden vastgelegd. Dit patroon kan ook in aanvulling op andere patronen worden gebruikt, omdat het doel en de doelgroep ook anders is. Daar waar dit patroon is gericht op verantwoording naar externe belanghebbenden, zijn bijvoorbeeld patronen 6 en 7 veel meer gericht op de ondersteuning van impactanalyse door data-engineers. In dit patroon staan daarom de verwerkingen centraal, terwijl bij patronen 6 en 7 de gegevens centraal staan.
4.11 Patroon 10: Trainen van kunstmatige intelligentie
Er is veel aandacht voor kunstmatige intelligentie en de mate waarin deze uitlegbaar is, ook in de AI act. Een kernonderdeel daarbij is het inzichtelijk maken van het proces van het trainen van de bijbehorende modellen, inclusief het cureren van de invoergegevens, het voorbereiden van deze gegevens en het gebruik van deze gegevens bij het trainen van de modellen.
Er zijn specifieke metamodellen voor dit soort contexten, zoals het PROV-ML metamodel dat is gebaseerd op de PROV standaard. Dit is geen formele standaard, maar het resultaat van een onderzoeksproject waarin is onderzocht hoe het trainen van machine learning modellen meer inzichtelijk kan worden gemaakt met behulp van datalineage (Souza et al., 2019).
4.12 Patroon 11: Volledige reproduceerbaarheid
Bij dit patroon is het nodig om de gegevens op exact dezelfde wijze te kunnen reproduceren op een later moment in tijd. Dit past bijvoorbeeld op situaties waarbij gegevens zijn gebaseerd op wetenschappelijk onderzoek of formeel beleidsonderzoek.
In veel gevallen volstaat het voor volledige reproduceerbaarheid niet om alleen de brongegevens en transformaties vast te leggen, maar is het ook nodig om vast te leggen hoe bepaalde activiteiten precies zijn uitgevoerd. Dat betekent dat het niveau van activiteiten ook moet worden gedefinieerd in de datalineage.
Datalineage is een kernfunctie van wetenschappelijke workflowmanagementsystemen. Er zijn ook specifieke metamodellen voor de bijbehorende datalineage metagegevens, zoals bijvoorbeeld ProvONE, CWLProv en RO-Crate.
Volgende hoofdstuk: Hoofdstuk 5 - Uitwerking
13 november 2025 11:50:19
13 november 2025 09:38:45
13 november 2025 11:50:19
7
Informatief
