Hoe ga je om met brondata die niet één-op-één aansluit op het Gemeentelijk Gegevensmodel?

Ed Kisman · 05 okt 2026

Brondata die niet één-op-één aansluit op het Gemeentelijk Gegevensmodel (GGM) is eerder regel dan uitzondering. De meeste gemeenten werken met tientallen bronapplicaties die elk hun eigen datastructuur, terminologie en granulariteit hanteren. De sleutel is om systematisch te analyseren waar de afwijkingen zitten, een passende transformatiestrategie te kiezen en beheersmaatregelen in te richten die de kwaliteit op de lange termijn borgen. Dit artikel beantwoordt de meest gestelde praktijkvragen over het omgaan met deze mismatch.

Wat zijn de meest voorkomende oorzaken van een mismatch met het GGM?

De meest voorkomende oorzaken van een mismatch tussen brondata en het Gemeentelijk Gegevensmodel zijn verschillen in naamgeving en definitie van objecttypen, een afwijkende granulariteit, ontbrekende verplichte velden en het gebruik van lokale of verouderde standaarden die niet aansluiten op de landelijke informatiemodellen waarop het GGM is gebaseerd.

Het GGM is opgebouwd rondom landelijke standaarden zoals RSGB, RGBZ, iWmo en iJw. Bronapplicaties zijn echter vaak jaren eerder ingericht op basis van eigen keuzes van een leverancier of een specifieke gemeentelijke werkwijze. Dat leidt tot een aantal terugkerende knelpunten:

Naamgevingsverschillen: Een object dat in het GGM “Natuurlijk Persoon” heet, kan in een bronapplicatie als “Klant”, “Inwoner” of “Burger” zijn opgeslagen.
Granulariteitsverschillen: Waar het GGM een adres opsplitst in afzonderlijke objecttypen (straatnaam, huisnummer, postcode), slaat een bronapplicatie dit soms op als één tekstveld.
Ontbrekende relaties: Koppelingen tussen objecttypen die het GGM als vanzelfsprekend beschouwt, zijn in de brondata simpelweg niet aanwezig of worden via een andere sleutel gelegd.
Verouderde standaarden: Applicaties die zijn gebouwd op oudere versies van RSGB of RGBZ wijken op detailniveau af van de versies die het GGM als uitgangspunt neemt.
Domeinspecifieke uitbreidingen: Applicaties voegen velden toe die buiten elke landelijke standaard vallen en daarmee geen directe plek hebben in het GGM.

Inzicht in de oorzaak bepaalt de aanpak. Een naamgevingsverschil is relatief eenvoudig op te lossen met een mapping-tabel, terwijl een fundamenteel granulariteitsverschil een transformatiestap vereist die meer inspanning vraagt.

Hoe breng je in kaart waar brondata afwijkt van het GGM?

Je brengt afwijkingen tussen brondata en het GGM in kaart door per beleidsdomein interviews te houden met domeinexperts, de authentieke bronnen van gegevens te identificeren en vervolgens de gevonden datastructuren te vergelijken met de objecttypen en attributen in het GGM. Dit levert een gedetailleerde gap-analyse op die als basis dient voor de transformatiestrategie.

De aanpak die bij de ontwikkeling van het GGM zelf is gehanteerd, biedt een bruikbaar stappenplan voor iedere gemeente die deze analyse wil uitvoeren:

Interviews per beleidsdomein: Ga in gesprek met experts over welke applicaties zij gebruiken, welke gegevens daarin leven en hoe gegevensstromen tussen systemen verlopen.
Identificeer authentieke bronnen: Maak onderscheid tussen de gezaghebbende bron van een gegeven en applicaties die dat gegeven alleen doorgeven of kopiëren. Alleen de authentieke bron is relevant voor de mapping.
Vergelijk met GGM-objecttypen: Leg de gevonden datastructuren naast het GGM en noteer per attribuut of het een directe match is, een hernoemde match, een samenvoeging of splitsing vereist, of volledig ontbreekt.
Documenteer de afwijkingen: Leg vast in welke categorie elke afwijking valt. Een gestructureerde mapping-tabel per domein maakt de gap-analyse overdraagbaar en herbruikbaar.

Voor data-integratie bij gemeenten is het essentieel dat deze analyse niet eenmalig wordt uitgevoerd. Applicaties veranderen, en daarmee verandert ook de brondata. Plan de gap-analyse als een terugkerend onderdeel van het databeheerproces.

Welke transformatiestrategie past het beste bij jouw situatie?

De beste transformatiestrategie hangt af van de aard en omvang van de mismatch. Eenvoudige naamgevingsverschillen los je op met een mapping-tabel in de ETL-laag. Structurele afwijkingen, zoals granulariteitsverschillen of ontbrekende relaties, vragen om een expliciete transformatiestap in de datapipeline. Bij grote volumes of complexe transformaties is een geautomatiseerde aanpak met een codegenerator de meest schaalbare keuze.

Mapping-tabellen voor naamgevings- en definitieverschillen

Wanneer de brondata inhoudelijk klopt maar anders is benoemd, is een mapping-tabel de minst invasieve oplossing. Je legt vast welk bronveld overeenkomt met welk GGM-attribuut, inclusief eventuele waardetransformaties (bijvoorbeeld het omzetten van een statuscode naar een GGM-conforme omschrijving). Deze tabel vormt de spil van je ETL-proces en maakt de transformatielogica transparant en onderhoudbaar.

Transformatiestappen voor structurele afwijkingen

Bij granulariteitsverschillen is een expliciete transformatiestap nodig. Een adres dat als één tekstveld is opgeslagen, moet worden geparseerd naar de afzonderlijke GGM-attributen. Omgekeerd kunnen meerdere bronvelden worden samengevoegd tot één GGM-object. Zulke transformaties documenteer je apart van de mapping-tabel, zodat de logica navolgbaar blijft voor beheerders en auditors.

Het GGM biedt bovendien codegeneratietemplates waarmee het model automatisch kan worden vertaald naar fysieke databasetabellen (DDL) voor systemen als Oracle. Dit versnelt de inrichting van het datawarehouse aanzienlijk en verkleint de kans op handmatige fouten.

Hoe ga je om met ontbrekende of niet-gedefinieerde velden in het GGM?

Wanneer brondata velden bevat die geen directe tegenhanger hebben in het GGM, zijn er drie opties: het veld weglaten als het niet relevant is voor analyse of beleid, het veld opnemen als uitbreiding op het GGM via een lokale extensie, of het veld aanmelden bij de GGM-gebruikersgroep als mogelijke toevoeging aan het model zelf.

Het GGM is een logisch model, geen gesloten standaard. De gemeente Delft heeft het model open source gepubliceerd via GitHub en beheer en doorontwikkeling vinden plaats in samenwerking met een gebruikersgroep van gemeenten en andere overheden. Velden die in meerdere gemeenten voorkomen maar nog niet in het model zijn opgenomen, zijn een waardevolle input voor die gebruikersgroep.

Voor lokale uitbreidingen geldt als vuistregel: documenteer ze expliciet als extensie, zodat duidelijk is wat GGM-standaard is en wat lokaal is toegevoegd. Zo blijft de compatibiliteit met andere gemeenten en landelijke initiatieven zoals Common Ground en het Digitaal Stelsel Omgevingswet (DSO) gewaarborgd. Goed datagovernancebeleid helpt om dit onderscheid structureel bij te houden.

Wanneer is het beter om de brondata aan te passen dan het model?

Het aanpassen van de brondata verdient de voorkeur wanneer de afwijking het gevolg is van een historische fout of inconsistentie in de bronapplicatie, wanneer de aanpassing de datakwaliteit structureel verbetert, of wanneer het GGM-objecttype aantoonbaar beter aansluit op de werkelijke betekenis van het gegeven dan de huidige bronstructuur.

Pas het model aan wanneer de brondata een legitieme lokale werkelijkheid vertegenwoordigt die het GGM nog niet dekt. Het aanpassen van de brondata is echter ingrijpender dan een transformatie in de ETL-laag, omdat het de operationele applicatie raakt. Weeg daarom altijd af:

Heeft de aanpassing impact op andere processen die van dezelfde brondata afhankelijk zijn?
Is de leverancier van de bronapplicatie bereid en in staat om de structuur aan te passen?
Levert de aanpassing een structurele kwaliteitsverbetering op, of verschuif je het probleem alleen?

In de meeste gevallen is een combinatie de meest pragmatische keuze: herstel aantoonbare fouten in de bron, en vang legitieme afwijkingen op in de transformatielaag van je data-engineeringproces.

Hoe houd je niet-aansluitende brondata beheersbaar op de lange termijn?

Niet-aansluitende brondata houd je beheersbaar op de lange termijn door de mapping-documentatie actueel te houden, datakwaliteitscontroles in te bouwen in de datapipeline, wijzigingen in bronapplicaties proactief te signaleren en de GGM-aansluiting periodiek te toetsen als onderdeel van het reguliere databeheer.

Concrete maatregelen die gemeenten hiervoor inzetten:

Versiebeheer op mapping-tabellen: Behandel mapping-documentatie als code. Sla wijzigingen op met een versienummer en een beschrijving van wat er is veranderd en waarom.
Geautomatiseerde validatieregels: Bouw controles in die afwijkingen van het GGM signaleren zodra nieuwe data wordt geladen. Zo ontdek je problemen vroeg in het proces in plaats van achteraf in de rapportage.
Wijzigingsbeheer voor bronapplicaties: Spreek met applicatiebeheerders af dat geplande wijzigingen in de bronstructuur tijdig worden gemeld, zodat de mapping kan worden bijgewerkt voordat de wijziging live gaat.
Periodieke review: Plan minimaal jaarlijks een review van de GGM-aansluiting per beleidsdomein. Het GGM zelf wordt ook doorontwikkeld, en nieuwe versies kunnen aanleiding geven om de mapping te herzien.

Het GGM is ook bruikbaar als basis voor AVG-classificatie en gemeentelijk datamanagementbeleid. Door het model centraal te stellen in je databeheeraanpak, profiteer je niet alleen van betere data-integratie, maar ook van een steviger fundament voor gemeentelijke business intelligence en verantwoording.

Hoe DBA helpt bij het aansluiten van brondata op het GGM

Wij begrijpen dat het vertalen van brondata naar een gestandaardiseerd model zoals het GGM technisch complex en tijdrovend kan zijn. Als database-experts met ruime ervaring bij overheidsorganisaties helpen wij gemeenten om dit proces gestructureerd en duurzaam in te richten. Wat wij concreet bieden:

Gap-analyse: We brengen per beleidsdomein in kaart waar brondata afwijkt van het GGM en categoriseren de afwijkingen naar type en impact.
Transformatie-architectuur: We ontwerpen een ETL- of ELT-aanpak die de mapping en transformatielogica transparant, onderhoudbaar en herhaalbaar maakt.
Database-inrichting: We richten de fysieke databasestructuur in op basis van het GGM, inclusief ondersteuning voor Oracle, Microsoft SQL Server en PostgreSQL.
Datagovernance en documentatie: We helpen bij het opzetten van versiebeheer op mapping-tabellen en het inbouwen van datakwaliteitscontroles in de datapipeline.
Langetermijnbeheer: We bieden professioneel databasebeheer zodat de GGM-aansluiting ook na de initiële implementatie actueel en betrouwbaar blijft.

Wil je weten hoe wij jouw gemeente kunnen helpen bij het werken met het Gemeentelijk Gegevensmodel? Neem contact met ons op voor een vrijblijvend gesprek.