Hoe pas je het Gemeentelijk Gegevensmodel toe als verschillende afdelingen andere databronnen gebruiken?

Ed Kisman · 09 okt 2026

Wanneer verschillende gemeentelijke afdelingen elk hun eigen databronnen gebruiken, pas je het Gemeentelijk Gegevensmodel toe door eerst alle afwijkende bronnen in kaart te brengen, vervolgens een expliciete mapping te maken tussen die bronnen en de GGM-entiteiten, en daarna conflicten op definitieniveau op te lossen voordat je begint met implementeren. Het GGM biedt juist de gelaagde structuur die dit mogelijk maakt: horizontale basisdomeinen zoals Kern, Financiën, ICT en Dienstverlening vormen de gemeenschappelijke basis waarop verticale beleidsdomeinen worden gebouwd. De vragen hieronder lopen stap voor stap door het hele proces.

Waarom botsen afdelingsdatabronnen met het GGM?

Afdelingsdatabronnen botsen met het Gemeentelijk Gegevensmodel omdat elke afdeling haar eigen applicaties, definities en registratiepraktijken heeft ontwikkeld, terwijl het GGM één logisch gegevensmodel hanteert dat alle beleidsterreinen van een gemeente beschrijft, ongeacht de organisatorische inrichting. Die spanning is structureel, niet toevallig.

Een sociale dienst registreert een inwoner anders dan de afdeling Burgerzaken dat doet. Vergunningverlening hanteert andere adresformaten dan de afdeling Openbare Ruimte. En het financiële systeem kent objecten die in geen enkel ander domeinmodel voorkomen. Nederland kende tot de introductie van het GGM een lappendeken aan standaarden met beperkte onderlinge samenhang, en die lappendeken leeft nog steeds voort in de applicatielandschappen van gemeenten.

Het GGM lost dit structureel op door beleidsterreinen af te leiden van de landelijke IV3-taakvelden en door bestaande standaarden zoals RSGB en RGBZ te bundelen in het Kern-domein. Maar dat betekent niet dat bestaande databronnen automatisch aansluiten. De botsing is dus geen fout in het model, maar een onvermijdelijk gevolg van historisch gegroeide systemen die nu geharmoniseerd moeten worden.

Wat is het verschil tussen een logisch en fysiek gegevensmodel binnen het GGM?

Het GGM is een logisch gegevensmodel: het beschrijft welke informatie bestaat, hoe objecttypen zich tot elkaar verhouden en welke betekenis gegevens hebben, los van hoe ze technisch worden opgeslagen. Een fysiek gegevensmodel vertaalt dat logische model naar concrete databasetabellen, kolomtypen en indexen die daadwerkelijk in een databasesysteem draaien.

Dit onderscheid is cruciaal voor gemeenten die met meerdere databronnen werken. Het logische GGM-model geldt als de gemeenschappelijke taal: alle afdelingen spreken over dezelfde objecttypen, relaties en definities. Het fysieke model is wat er uiteindelijk in het datawarehouse of de bronsystemen staat, en dat kan per systeem sterk verschillen.

Voor de gemeente Delft is het GGM concreet ingezet als het centrale datamodel in het datawarehouse. Daarvoor is een codegenerator ontwikkeld waarmee het logische GGM automatisch wordt vertaald naar fysieke databasetabellen via DDL-scripts. Dit is getest voor Oracle, en er zijn ook templates beschikbaar voor MySQL. Die generator overbrugt precies de kloof tussen het logische model en de fysieke implementatie. Meer over de technische kant van data-integratie bij gemeenten lees je op onze dienstenpagina.

Hoe breng je afwijkende databronnen in kaart vóór de implementatie?

Breng afwijkende databronnen in kaart door per beleidsdomein een gegevensinventarisatie uit te voeren: welke applicaties bestaan er, welke objecttypen registreren ze, welke definities hanteren ze, en hoe verhouden die definities zich tot de GGM-entiteiten in het corresponderende domein? Doe dit vóór de technische implementatie, niet erna.

Een praktische aanpak werkt in drie stappen:

Applicatiekaart per domein: Zet per verticaal beleidsdomein (zoals Sociaal Domein, Vergunningen of Openbare Ruimte) alle gebruikte applicaties op een rij. Noteer per applicatie welke gegevensobjecten worden bijgehouden.
Definitievergelijking: Vergelijk de lokale definitie van elk object met de GGM-definitie. Let op naamgeving, granulariteit, verplichte velden en relaties met andere objecttypen.
Afwijkingenregister: Documenteer alle gevonden afwijkingen in een gestructureerd register. Categoriseer ze als naamverschil, definitieverschil, ontbrekend object of structuurverschil.

Het GGM is ontworpen op basis van interviews met domeinexperts en de in Delft gebruikte applicaties, aangevuld met landelijke informatiestandaarden. Diezelfde interviewaanpak werkt ook voor andere gemeenten: praat met de mensen die dagelijks met de data werken, want zij kennen de afwijkingen tussen het systeem en de werkelijkheid beter dan welk document ook.

Welke mapping-strategieën bestaan er voor het koppelen van brondata aan GGM-entiteiten?

Er zijn drie hoofdstrategieën om brondata te koppelen aan GGM-entiteiten: directe mapping (één-op-éénvertaling van een bronveld naar een GGM-attribuut), transformatiemapping (waarbij brondata wordt omgezet of gecombineerd om aan een GGM-definitie te voldoen) en uitbreidingsmapping (waarbij het GGM lokaal wordt uitgebreid met extra attributen die niet in het standaardmodel voorkomen).

Directe mapping

Directe mapping is de eenvoudigste vorm en werkt goed wanneer een bronsysteem al aansluit bij een landelijke standaard die in het GGM is verwerkt, zoals RSGB voor basisregistraties of iWmo voor het sociaal domein. Een BSN in een bronsysteem is een BSN in het GGM. Hier is weinig transformatielogica nodig.

Transformatiemapping

Transformatiemapping is nodig wanneer een bronsysteem dezelfde informatie anders structureert. Een adres dat in het bronsysteem als één tekstveld is opgeslagen, moet worden gesplitst naar straatnaam, huisnummer en postcode conform de RSGB-structuur in het GGM-Kern. Hier is ETL-logica vereist, en het is verstandig die transformaties expliciet te documenteren zodat ze beheersbaar blijven.

Uitbreidingsmapping

Uitbreidingsmapping is van toepassing wanneer een afdeling gegevens bijhoudt die buiten de scope van het GGM vallen. Het GGM laat dit toe: de gelaagde opbouw maakt het mogelijk om domeinspecifieke objecttypen toe te voegen zonder de horizontale basisdomeinen te verstoren. Documenteer uitbreidingen zorgvuldig, zodat ze bij een volgende versie van het GGM eenvoudig kunnen worden vergeleken met eventuele nieuwe standaardobjecttypen. Bekijk ook hoe data engineering hierbij een rol speelt.

Hoe los je conflicten op tussen definities van verschillende afdelingen?

Definitieconflicten tussen afdelingen los je op door het GGM als neutrale scheidsrechter te gebruiken: niet de definitie van de sterkste afdeling wint, maar de definitie die het beste aansluit bij de GGM-standaard en de onderliggende landelijke informatiestandaarden. Dat vereist een formeel besluitvormingsproces, geen technische oplossing.

In de praktijk zijn er drie veelvoorkomende conflicttypen:

Naamconflicten: Twee afdelingen gebruiken verschillende termen voor hetzelfde concept. Oplossing: adopteer de GGM-terminologie als standaard en leg aliassen vast in een gemeentelijk begrippenkader.
Definitieconflicten: Twee afdelingen definiëren hetzelfde begrip anders (bijvoorbeeld: wat telt als een “melding”?). Oplossing: raadpleeg de GGM-definitie en de onderliggende standaard (zoals RGBZ voor zaakgericht werken) en laat een domeinexpert de definitieve interpretatie vaststellen.
Granulariteitsconflicten: De ene afdeling registreert op een gedetailleerder niveau dan de andere. Oplossing: kies het meest gedetailleerde niveau als brondefinitie en aggregeer waar nodig voor rapportage.

Het GGM is ook ingezet als basis voor de classificatie van gegevens in het kader van de AVG. Dat maakt het model geschikt als gemeenschappelijk referentiepunt: als twee afdelingen het niet eens zijn over een definitie, biedt de AVG-classificatie soms een objectieve tiebreaker. Beveiliging en governance spelen hierbij een ondersteunende rol.

Wanneer is een gefaseerde GGM-implementatie verstandiger dan een big bang-aanpak?

Een gefaseerde GGM-implementatie is verstandiger dan een big bang-aanpak wanneer een gemeente meer dan drie of vier beleidsdomeinen tegelijk moet harmoniseren, wanneer de kwaliteit van bestaande databronnen sterk verschilt per domein, of wanneer de organisatie nog geen volwassen datamanagementbeleid heeft. In die situaties vergroot een big bang de kans op mislukking aanzienlijk.

De gelaagde opbouw van het GGM ondersteunt een gefaseerde aanpak van nature. Begin met de horizontale basisdomeinen: Kern (RSGB en RGBZ), Financiën, ICT en Dienstverlening. Deze vormen de fundering waarop alle verticale beleidsdomeinen bouwen. Als de basis stabiel is, kunnen verticale domeinen één voor één worden toegevoegd zonder de rest te destabiliseren.

Een big bang-aanpak is alleen realistisch wanneer een gemeente een greenfield-situatie heeft (bijvoorbeeld bij een nieuw datawarehouse zonder legacy-data), wanneer alle betrokken afdelingen al werken met gestandaardiseerde systemen die aansluiten bij landelijke standaarden, en wanneer er voldoende capaciteit is om alle domeinen parallel te begeleiden. Dat zijn zeldzame omstandigheden.

Praktisch gezien levert een gefaseerde aanpak ook sneller zichtbare resultaten op. Elk succesvol geïmplementeerd domein bouwt draagvlak op voor de volgende fase, wat bij een politiek gevoelig traject als gemeentelijke data-harmonisatie geen onbelangrijke factor is. Meer over de aanpak van Microsoft Fabric voor de overheid laat zien hoe gefaseerde implementaties in de praktijk werken.

Hoe DBA helpt bij GGM-implementatie met meerdere databronnen

Wij begrijpen dat de implementatie van het Gemeentelijk Gegevensmodel in een omgeving met versnipperde afdelingsdatabronnen een complexe technische én organisatorische uitdaging is. Onze database-experts ondersteunen gemeenten op meerdere niveaus:

Databronanalyse: We brengen bestaande databronnen per beleidsdomein in kaart en vergelijken ze systematisch met de GGM-entiteiten.
Mapping en transformatie: We ontwerpen en implementeren de ETL-logica die brondata correct vertaalt naar GGM-conforme structuren, inclusief documentatie van alle transformatieregels.
Databasebeheer voor Oracle, SQL Server en PostgreSQL: We zorgen dat de fysieke databaseomgeving waarin het GGM wordt geïmplementeerd optimaal presteert en beheerd wordt.
Gefaseerde implementatiebegeleiding: We helpen gemeenten bij het prioriteren van domeinen en het bewaken van de voortgang per fase, zodat het project beheersbaar blijft.
Governance en definitiebeheer: We ondersteunen bij het opstellen van een gemeentelijk begrippenkader en het inrichten van een datamanagementproces dat conflicten tussen afdelingen structureel oplost.

Wil je weten hoe we dit concreet aanpakken voor jouw gemeente? Neem contact op met DBA voor een vrijblijvend gesprek.