Data Flow & Lineage Model

Gegevensstroom en herkomst zijn niet hetzelfde

Een gegevensstroom beschrijft welke gegevens van een bron naar een verwerking of afnemer gaan. Een herkomstrelatie beschrijft welke specifieke invoer via welke bewerking bijdraagt aan welke uitvoer. Ook een ongewijzigde kopie kan herkomst hebben. Alleen een pijl tussen systemen verklaart nog niet hoe een uitkomst is ontstaan.

Dit EAW-werkmodel combineert een gegevensstroomkaart, een stroomregister en een herkomst-/transformatieregister. Het is een architectuurproduct, geen automatische lineage-scanner of runtime-monitor. Je kiest het detailniveau dat nodig is voor de analysevraag en maakt de grens van de onderzochte keten expliciet.

W3C PROV onderscheidt gegevensobjecten, activiteiten en verantwoordelijke actoren en beschrijft gebruik, voortbrenging en afleiding. Die begrippen ondersteunen de herkomstregistratie. De drie views, veldkeuze en lokale codes zijn EAW-werkafspraken, geen volledige PROV-implementatie. Zie bron B1 onderaan.

De drie onderdelen

Gegevensstroomkaart. Teken brongegevens, referentiegegevens, verwerkingen, uitvoergegevens en afnemers. Benoem iedere gegevenspijl met een unieke stroomcode en betekenis. DS staat in de template voor een gegevensverzameling, TR voor een verwerking en AF voor een afnemer. De F-pijlen lopen in gegevensrichting; LIN verwijst naar een specifieke afleiding in het herkomstregister. Een afnemer is niet hetzelfde als de gegevens die hij gebruikt.

Stroomregister. Leg bron, bestemming, gegevensinhoud, doel, modelreferentie en verantwoordelijkheid vast. Maak bronautoriteit, actualiteit, frequentie en classificatie expliciet wanneer hiervoor onderbouwde afspraken bestaan. Anders blijft het veld onbekend of te valideren. De data-eigenaar is niet automatisch de beheerder van het bronsysteem.

Herkomst-/transformatieregister. Begin bij één relevante uitvoer en benoem de bijdrage van iedere input. Een input kan de waarde leveren, maar ook uitsluitend een selectie, vergelijking of filter beïnvloeden. Een gedeelde verwerking rechtvaardigt niet zonder meer een relatie van iedere input naar iedere output. De Lineage Job Facet van OpenLineage beschrijft specifieke input-outputafhankelijkheden; dit EAW-model gebruikt dat onderscheid als inhoudelijk uitgangspunt, zonder een software-implementatie voor te schrijven. Zie B3.

Ontwerp en waarneming apart vastleggen

Gebruik twee afzonderlijke velden. Modelperspectief: bestaand of beoogd. Bewijsstatus: waargenomen, gedocumenteerd, ontwerpaanname of onbekend. Dit zijn EAW-werkafspraken. Een bestaand ontwerpdocument is nog geen bewijs van wat een concrete uitvoering heeft gedaan.

OpenLineage onderscheidt dataset- en jobmetadata van gebeurtenissen over concrete uitvoeringen. Dat ondersteunt het onderscheid tussen ontwerpregistratie en waarneming. Zie B2. Leg bronreferentie, versie of peildatum en verificatiehouder vast. Een echte uitvoerings-ID, omgeving, meettijd of datasetversie wordt alleen opgenomen wanneer die beschikbaar is.

Een diagram garandeert geen volledige dekking. Ontbrekende herkomstinformatie bewijst niet dat een gegevensstroom ontbreekt. Beperk een impactconclusie tot het aangetoonde bereik; daarbuiten is het een onderzoeksvraag.

Fictief voorbeeld: aanvraagstatus

Alle casusgegevens zijn fictieve ontwerpaannames, geen waargenomen organisatie-inrichting.

DS-01 Aanvraagstatus bevat Aanvraagnummer en Statuscode uit fictieve Aanvraagbehandeling. DS-02 Statusdefinities levert Statuscode en Betekenis. TR-01 Statusinterpretatie gebruikt beide en produceert DS-03 Statusduiding voor AF-01 Statuspresentatie. F-01 tot en met F-04 tonen deze aanlevering, verwerking en het gebruik.

DS-01 verwijst naar de voorbeeldentiteit Aanvraag uit Logical Data Model v1.1 en DD-01 Aanvraagdata. DS-02 en DS-03 zijn uitwerkingsvoorstellen voor deze casus, niet reeds vastgestelde uitbreidingen van het logische model.

LIN-01 verklaart specifiek DS-03.Statusduiding: DS-01.Statuscode bepaalt de selectie, DS-02.Statuscode is de vergelijkingswaarde en DS-02.Betekenis levert de tekst. Aanvraagnummer levert aanvraagcontext, maar wordt niet ten onrechte als tekstbron voorgesteld.

De kandidaatregel is: vergelijk de codes en gebruik de passende, geldige definitie. Geldigheidsversie, bronautoriteit en afhandeling van nul of meerdere matches moeten nog worden gevalideerd. Frequentie, prestatienorm en classificatie zijn niet vastgesteld. De genoemde Data Owner Aanvragen is een fictieve validatierol.

Alle drie templateviews zijn in het voorbeeld behouden. Eén stroom, F-01, en één afleiding, LIN-01, zijn volledig uitgewerkt. De overige stromen zijn context; dat maakt het geen volledig referentiemodel.

Samenhang en afbakening

Het Logical Data Model beschrijft structuur; Data Domain & Ownership levert domeinafbakening en verantwoordelijkheden. Business Information en Information Flow leveren zakelijke betekenis en overdracht. Solution Information Usage beschrijft het gebruik door de oplossing.

Dit product beschrijft beweging, verwerking en herkomst. Het schrijft geen SQL, ETL-code, fysieke tabel, API-endpoint, integratiepatroon of leverancier voor. Het implementeert evenmin automatische cross-domain governance. De primaire bronnen hieronder ondersteunen de begrippen; productindeling, invulvelden en fictieve casus zijn eigen EAW-uitwerking.