Hoe maak je een mapping van bronsystemen naar het Gemeentelijk Gegevensmodel?

Ed Kisman · 01 okt 2026

Een mapping van bronsystemen naar het Gemeentelijk Gegevensmodel maak je door elk veld uit een bronsysteem systematisch te koppelen aan het bijbehorende objecttype en attribuut binnen het GGM. Dit vereist inzicht in zowel de structuur van het GGM als de gegevensstructuur van de bronapplicaties die de gemeente gebruikt. In dit artikel beantwoorden we de meest gestelde vragen over dit proces, van de eerste inventarisatie tot het beheer van de mapping in de tijd.

Wat is het Gemeentelijk Gegevensmodel en welke bronsystemen horen erbij?

Het Gemeentelijk Gegevensmodel (GGM) is een logisch gegevensmodel dat alle beleidsterreinen van een Nederlandse gemeente beschrijft, ongeacht hoe de organisatie is ingericht of welke applicaties worden gebruikt. Het model is ontwikkeld in opdracht van de gemeente Delft en vormt een gemeenschappelijke taal voor het uitwisselen en samenvoegen van gemeentelijke data. Alle Nederlandse gemeenten hebben in principe dezelfde wettelijke taken, waardoor de onderliggende informatiemodellen sterk op elkaar lijken.

Het GGM heeft een gelaagde opbouw. Vier horizontale domeinen vormen de basis: Kern, Financiën, ICT en Dienstverlening. Bovenop deze laag zijn verticale beleidsdomeinen uitgewerkt, zoals het Sociaal Domein, Veiligheid en Vergunningen, Onderwijs, Volkshuisvesting en Openbare Ruimte. Het onderdeel Kern bevat gedeelde objecttypen op basis van RSGB (basisregistraties) en RGBZ (zaakgericht werken), beide onderdelen van GEMMA.

De bronsystemen die bij een GGM-mapping horen, zijn alle applicaties waarmee een gemeente gegevens registreert binnen deze domeinen. Denk aan:

Burgerzakensystemen voor persoonsgegevens (gekoppeld aan RSGB)
Zaaksystemen voor meldingen, aanvragen en vergunningen (gekoppeld aan RGBZ)
Sociaal domein-applicaties voor Wmo, Jeugd en Werk (gekoppeld aan iWmo en iJw)
GIS-systemen voor geo-informatie (gekoppeld aan BGT/IMGeo en IMBOR)
Financiële systemen voor begrotingen en subsidies
HR- en facilitaire systemen voor interne organisatie

Het GGM integreert landelijke standaarden zoals het Suwi Gegevensregister (SGR), STTR/IMTR voor de Omgevingswet en RiHA voor vergunningverlening. Dit maakt het model bij uitstek geschikt als centrale data-integratielaag voor een gemeentelijk datawarehouse.

Hoe begin je met een mapping van bronsystemen naar het GGM?

Begin een GGM-mapping met een gestructureerde inventarisatie van alle bronsystemen die de gemeente in gebruik heeft, gevolgd door een analyse van welke GGM-domeinen deze systemen raken. Zonder een volledig beeld van de bronsystemen en hun gegevensstructuur is een betrouwbare mapping niet mogelijk. Een gefaseerde aanpak per beleidsdomein werkt in de praktijk het beste.

Volg deze stappen als startpunt:

Inventariseer de bronsystemen per beleidsdomein. Maak een overzicht van alle applicaties, wie de eigenaar is, welke gegevens erin zitten en in welk formaat deze beschikbaar zijn.
Koppel elk systeem aan een GGM-domein. Bepaal welk verticaal beleidsdomein (of meerdere) het bronsysteem raakt. Een sociaal domein-applicatie raakt bijvoorbeeld de domeinen Wmo, Jeugd en Werk.
Haal de gegevensstructuur op uit het bronsysteem. Vraag de leverancier om een gegevenswoordenboek of exporteer een schemaoverzicht. Zonder dit kun je geen veldniveau-mapping uitvoeren.
Bestudeer de relevante GGM-objecttypen en attributen voor het betreffende domein. Het GGM is uitgewerkt in Enterprise Architect en bevat per objecttype de bijbehorende attributen, datatypes en relaties.
Stel een mappingtemplate op met kolommen voor: bronsysteemveld, GGM-objecttype, GGM-attribuut, transformatieregel en eventuele opmerkingen over afwijkingen.

Een praktisch hulpmiddel is de codegenerator die bij het GGM wordt meegeleverd. Met de codegeneratietemplates voor het Code Template Framework van Enterprise Architect kun je het GGM automatisch vertalen naar fysieke databasetabellen (DDL). Dit is getest voor Oracle, en er zijn ook templates beschikbaar voor MySQL. Dit versnelt het aanmaken van de doelstructuur aanzienlijk. Meer over data engineering bij gemeenten lees je op onze kennispagina.

Welke methoden worden gebruikt om bronsysteemvelden te koppelen aan GGM-attributen?

De meest gebruikte methoden voor het koppelen van bronsysteemvelden aan GGM-attributen zijn directe mapping (één-op-één-veldkoppeling), transformatiemapping (waarbij waarden worden omgezet of samengevoegd) en afgeleide mapping (waarbij een GGM-attribuut wordt berekend uit meerdere bronvelden). De juiste methode hangt af van hoe goed het bronsysteem aansluit bij de GGM-structuur.

Directe mapping

Bij directe mapping komt een bronsysteemveld rechtstreeks overeen met een GGM-attribuut, zonder dat er een transformatie nodig is. Dit is het eenvoudigste geval en komt voor bij systemen die al zijn gebouwd op basis van landelijke standaarden zoals RSGB of RGBZ. Een BSN-veld in een burgerzakensysteem koppelt bijvoorbeeld direct aan het attribuut burgerservicenummer binnen het objecttype Natuurlijk Persoon in het GGM-Kern-domein.

Transformatiemapping

Transformatiemapping is nodig wanneer waarden in het bronsysteem afwijken van de GGM-definitie. Denk aan datumnotaties die moeten worden omgezet, codelijsten die verschillen van de GGM-waardelijsten, of samengestelde velden die moeten worden gesplitst. Documenteer de transformatieregel expliciet in de mapping, zodat de logica later reproduceerbaar en controleerbaar is.

Afgeleide mapping

Soms bestaat een GGM-attribuut niet als enkelvoudig veld in het bronsysteem, maar moet het worden afgeleid uit meerdere bronvelden of berekend op basis van bedrijfslogica. Dit vereist afstemming met de domeinexpert of proceseigenaar om te borgen dat de afgeleide waarde semantisch correct is. Leg de berekeningsregel vast als onderdeel van de mappingdocumentatie.

Wat zijn veelvoorkomende problemen bij het mappen van bronsystemen?

De meest voorkomende problemen bij het mappen van bronsystemen naar het GGM zijn semantische mismatch (een veld heeft in het bronsysteem een andere betekenis dan in het GGM), ontbrekende gegevens, inconsistente codelijsten en gebrekkige documentatie van het bronsysteem. Deze problemen vertragen het mappingproces en kunnen leiden tot foutieve interpretaties in het datawarehouse.

Andere veelgehoorde knelpunten zijn:

Silo-structuur van bronsystemen: Applicaties zijn historisch per afdeling aangeschaft en bevatten overlappende of tegenstrijdige gegevens over dezelfde objecten, zoals adressen of personen.
Geen of beperkte leveranciersdocumentatie: Veel gemeentelijke applicaties hebben geen volledig gegevenswoordenboek, waardoor reverse engineering van het datamodel nodig is.
Afwijkende versies van standaarden: Het GGM gebruikt RSGB versie 2.0.2 als basis, maar sommige bronsystemen zijn gebouwd op een oudere of nieuwere versie, wat tot attribuutverschillen leidt.
Gegevenskwaliteitsproblemen: Velden die in het bronsysteem optioneel zijn, bevatten in de praktijk vaak lege of inconsistente waarden, wat de bruikbaarheid in het GGM-datawarehouse beperkt.
Domeinoverschrijdende objecten: Een object zoals een adres komt voor in meerdere domeinen. Als elk bronsysteem het adres iets anders registreert, ontstaat er een harmonisatievraagstuk dat buiten de puur technische mapping valt.

Een goede aanpak is om bij elk knelpunt een beslissing vast te leggen: hoe wordt het opgelost, wie heeft dat besloten en wanneer. Dit voorkomt dat dezelfde discussie bij elke nieuwe mapping opnieuw wordt gevoerd. Voor complexe gevallen helpt data governance om eigenaarschap en beslissingsbevoegdheid helder te beleggen.

Hoe documenteer en beheer je een GGM-mapping in de tijd?

Documenteer een GGM-mapping in een centraal mappingregister dat per bronsysteem de veldkoppelingen, transformatieregels en beslissingen vastlegt. Beheer dit register als een levend document: update het bij elke applicatiewijziging, nieuwe release van het GGM of wijziging in een landelijke standaard. Zonder actief beheer veroudert een mapping snel en verliest die zijn waarde als betrouwbare bron.

Praktische richtlijnen voor duurzaam beheer:

Gebruik versiebeheer voor het mappingregister, zodat wijzigingen traceerbaar zijn en teruggedraaid kunnen worden.
Koppel de mapping aan de GGM-versie die op dat moment van toepassing is. Het GGM wordt doorontwikkeld in samenwerking met diverse gemeenten via een gebruikersgroep, waardoor nieuwe versies nieuwe of gewijzigde objecttypen kunnen bevatten.
Beleg eigenaarschap per domein bij een data-eigenaar of informatiemanager die verantwoordelijk is voor het actueel houden van de mapping binnen zijn of haar beleidsdomein.
Automatiseer waar mogelijk. Als het GGM via de codegenerator wordt vertaald naar DDL voor het datawarehouse, kan een geautomatiseerde vergelijking helpen om afwijkingen tussen de mapping en de feitelijke databasestructuur vroegtijdig te signaleren.
Documenteer uitzonderingen expliciet. Niet elk bronsysteemveld past naadloos in het GGM. Leg deze uitzonderingen vast met een motivatie, zodat toekomstige beheerders begrijpen waarom een bepaalde keuze is gemaakt.

Het GGM sluit aan bij het Common Ground-principe van het loskoppelen van gegevens en applicaties. Een goed gedocumenteerde en actief beheerde mapping is daarmee niet alleen technisch nuttig, maar ook een bouwsteen voor een toekomstbestendige BI-infrastructuur die applicatiewisselingen kan opvangen zonder dat de datalaag opnieuw moet worden opgebouwd.

Hoe DBA helpt met het mappen van bronsystemen naar het GGM

Wij begrijpen dat een GGM-mapping technisch complex is en veel kennis vereist van zowel gemeentelijke informatiemodellen als de onderliggende databasestructuren. Bij DBA combineren we onze expertise in databasebeheer en data-integratie om gemeenten te ondersteunen bij elke stap van dit proces. Concreet bieden we:

Inventarisatie en analyse van bestaande bronsystemen en hun gegevensstructuren, inclusief reverse engineering waar documentatie ontbreekt.
Technische mapping van bronsysteemvelden naar GGM-objecttypen en attributen, inclusief het vastleggen van transformatieregels en uitzonderingen.
Implementatie van de doelstructuur in Oracle, Microsoft SQL Server of PostgreSQL, gebruikmakend van de GGM-codegeneratietemplates en onze eigen database-expertise.
Inrichting van een mappingregister met versiebeheer, zodat de mapping actueel en beheersbaar blijft.
Langdurig beheer en onderhoud van de database-omgeving achter het gemeentelijk datawarehouse, met 24/7 monitoring en proactief onderhoud.

Wil je weten hoe we jouw gemeente kunnen helpen met een gestructureerde aanpak van databeheer en GGM-mapping? Neem contact met ons op voor een vrijblijvend gesprek.