Hoe voorkom je dubbele gegevens bij implementatie van het Gemeentelijk Gegevensmodel?

Ed Kisman · 18 okt 2026

Dubbele gegevens bij de implementatie van het Gemeentelijk Gegevensmodel (GGM) voorkom je door een combinatie van duidelijke modellaagafspraken, technische databaseconstraints en consequent gebruik van landelijke standaarden als gemeenschappelijke basis. Het GGM is ontworpen met een gelaagde structuur die hergebruik van objecttypen stuurt, maar in de praktijk vereist een succesvolle implementatie ook bewuste keuzes op databaseniveau. Dit artikel beantwoordt de meest gestelde vragen over oorzaken, detectie, preventie en professioneel beheer rondom datakwaliteit in een GGM-omgeving.

Wat zijn de meest voorkomende oorzaken van dubbele gegevens in het GGM?

De meest voorkomende oorzaken van dubbele gegevens in een GGM-implementatie zijn het ontbreken van eenduidige sleuteldefinities, het samenvoegen van gegevens uit meerdere bronsystemen zonder deduplicatielogica en het negeren van de gelaagde modelstructuur van het GGM zelf. Wanneer objecttypen uit verschillende beleidsdomeinen niet via de juiste horizontale kernlaag worden hergebruikt, ontstaan er onbedoeld parallelle registraties van dezelfde entiteiten.

Het GGM kent een bewuste gelaagde opbouw: objecttypen in de onderste lagen, zoals die uit de Kern (RSGB en RGBZ), worden hergebruikt door de bovenliggende domeinen. Wordt deze hiërarchie niet gerespecteerd, dan definiëren afzonderlijke beleidsdomeinen hun eigen versies van bijvoorbeeld een persoon, adres of zaak. Het resultaat is dat dezelfde inwoner meerdere keren in de database voorkomt, maar dan onder verschillende sleutels en in verschillende tabellen.

Een tweede structurele oorzaak is de integratie van bronapplicaties. Het GGM fungeert in de praktijk als centraal datamodel voor een gemeentelijk datawarehouse (DWH), waarbij gegevens uit tientallen bronsystemen worden geladen. Elke applicatie hanteert eigen identificatoren. Zonder een expliciete mapping naar de authentieke bronnen, die tijdens de GGM-ontwikkeling al in kaart worden gebracht via interviews met domeinexperts, worden dezelfde gegevens meerdere keren opgeslagen onder verschillende sleutels.

Tot slot spelen organisatorische silo’s een rol. Gemeenten werken met afdelingen die elk hun eigen applicaties en werkwijzen hebben. Zonder een gedeelde “taal”, precies de rol die het GGM wil vervullen, worden gegevens over domeinen heen opnieuw ingevoerd in plaats van hergebruikt. Dit is ook de reden waarom het GGM aansluit bij de principes van data governance en Common Ground: het loskoppelen van gegevens en applicaties voorkomt dat elke applicatie zijn eigen kopie van de werkelijkheid bijhoudt.

Hoe detecteer je dubbele gegevens in een GGM-database?

Dubbele gegevens in een GGM-database detecteer je door gerichte SQL-queries te draaien op de sleutelvelden van de kernobjecttypen, aangevuld met profilering van de geladen brongegevens op uniekheid, volledigheid en consistentie. De combinatie van technische controles en inhoudelijke dataprofilering geeft het meest complete beeld van de datakwaliteit.

Technische detectie via SQL

De meest directe methode is het zoeken naar dubbele waarden op velden die uniek zouden moeten zijn, zoals BSN, adresidentificatie of zaakidentificatie. Een eenvoudige GROUP BY, gecombineerd met HAVING COUNT(*) > 1 op de betreffende kolommen, laat snel zien waar duplicaten zitten. Voer deze controles uit op zowel de staging-tabellen als de definitieve GGM-tabellen om te zien of duplicaten al bij het laden ontstaan of later door transformatiefouten.

Dataprofilering en monitoring

Naast eenmalige controles is continue monitoring van belang, zeker omdat het GGM als DWH-fundament regelmatig nieuwe gegevens ontvangt uit bronsystemen. Dataprofileringstools analyseren automatisch de distributie van waarden, signaleren afwijkingen en vergelijken sleutels tussen bronnen. Koppel deze monitoring aan de authentieke bronnen die in het GGM-ontwikkelproces zijn geïdentificeerd: als een gegeven uit twee bronnen binnenkomt met verschillende sleutels maar dezelfde inhoud, is dat een signaal voor een duplicaat. Een regelmatige healthcheck van de database-omgeving helpt dit soort problemen vroegtijdig aan het licht te brengen.

Welke databasetechnieken voorkomen duplicaten bij GGM-implementatie?

De meest effectieve databasetechnieken om duplicaten bij een GGM-implementatie te voorkomen zijn het afdwingen van UNIQUE constraints en PRIMARY KEY-definities op de kernobjecttypen, het toepassen van MERGE-statements (upsert-logica) bij het laden van brongegevens en het inrichten van een expliciete sleutelmapping tussen bronsystemen en het GGM-datamodel.

Het GGM biedt de mogelijkheid om via de meegeleverde codegeneratietemplates automatisch fysieke databaseschema’s (DDL) te genereren. Dit is getest voor Oracle en er zijn ook templates beschikbaar voor MySQL. Deze gegenereerde schema’s vormen een goede basis, maar de constraints voor uniekheid moeten bewust worden ingesteld op basis van de semantiek van het model. Een PRIMARY KEY op een technische surrogate key is niet voldoende; voeg ook UNIQUE constraints toe op de natuurlijke sleutels zoals die in de landelijke standaarden zijn gedefinieerd (bijvoorbeeld het BSN uit RSGB of de zaakidentificatie uit RGBZ).

Bij het laden van gegevens uit meerdere bronsystemen is upsert-logica onmisbaar. In plaats van simpelweg rijen in te voegen, controleert een MERGE-statement of een record al bestaat op basis van de natuurlijke sleutel. Bestaat het record, dan wordt het bijgewerkt; bestaat het niet, dan wordt het ingevoegd. Dit voorkomt dat hetzelfde gegeven meerdere keren wordt ingevoegd wanneer een laadproces opnieuw wordt uitgevoerd of wanneer twee bronnen hetzelfde object aanleveren.

Daarnaast is een golden record-aanpak waardevol: definieer per objecttype welke bron de authentieke waarde levert. Het GGM-ontwikkelproces identificeert deze authentieke bronnen al expliciet via domeininterviews. Leg deze keuzes vast in de ETL-logica zodat bij conflicterende waarden altijd de juiste bron wint, in plaats van dat de volgorde van laden bepaalt welke waarde overblijft. Voor complexere omgevingen biedt data-integratie aanvullende mogelijkheden om bronnen gestructureerd samen te voegen.

Wanneer is professioneel databasebeheer noodzakelijk bij een GGM-implementatie?

Professioneel databasebeheer is noodzakelijk bij een GGM-implementatie zodra de complexiteit van de integratie, de schaal van de data of de criticaliteit van de informatie de interne capaciteit overstijgt. Dat is bij de meeste gemeenten het geval: het GGM omvat alle beleidsdomeinen, integreert tientallen bronsystemen en vormt de basis voor AVG-classificatie, beleidsrapportages en API’s.

Concreet zijn er drie situaties waarin professionele ondersteuning onmisbaar is:

Bij de initiële implementatie: het genereren van de fysieke databaseschema’s via de GGM-codegeneratietemplates en het correct inrichten van constraints, indexen en partitionering vereist diepgaande kennis van het gekozen databaseplatform, of dat nu Oracle, SQL Server of PostgreSQL is.
Bij het inrichten van de ETL-laag: de koppeling van tientallen bronsystemen aan het GGM, inclusief sleutelmapping, upsert-logica en foutafhandeling, is technisch complex en foutgevoelig. Een fout in de laadlogica is vaak de directe oorzaak van duplicaten.
Bij doorlopend beheer: het GGM wordt actief doorontwikkeld in samenwerking met gemeenten via een gebruikersgroep. Modelwijzigingen moeten worden vertaald naar de fysieke database zonder dataverlies of nieuwe inconsistenties. Dat vereist gestructureerd wijzigingsbeheer en regelmatige controles op datakwaliteit.

Gemeenten die het GGM inzetten voor kritische processen zoals AVG-verantwoording, dashboards voor het sociaal domein of de basis voor het Digitaal Stelsel Omgevingswet, kunnen zich geen datakwaliteitsproblemen veroorloven. In die context is professioneel databasebeheer geen luxe maar een randvoorwaarde voor betrouwbare informatievoorziening.

Hoe DBA helpt bij een betrouwbare GGM-implementatie

Wij ondersteunen gemeenten en overheidsinstellingen bij het technisch fundament onder het Gemeentelijk Gegevensmodel. Onze senior database administrators kennen de complexiteit van gemeentelijke dataomgevingen en weten hoe je een GGM-implementatie technisch solide inricht, zodat datakwaliteit geborgd blijft en dubbele gegevens structureel worden voorkomen.

Wat wij concreet bieden:

Inrichten van fysieke databaseschema’s op basis van de GGM-codegeneratietemplates, getest voor Oracle en beschikbaar voor andere platforms
Opzetten van UNIQUE constraints, PRIMARY KEY-definities en upsert-logica die duplicaten aan de bron voorkomen
Begeleiding bij de integratie van bronsystemen, inclusief sleutelmapping en ETL-inrichting
Proactief databasebeheer met dagelijkse back-upcontroles, monitoring en periodiek onderhoud
Ondersteuning bij modelwijzigingen wanneer het GGM wordt doorontwikkeld, zonder dataverlies of nieuwe inconsistenties
24/7 ondersteuning op afstand of op locatie, al vanaf €177,00 per maand

Wil je weten hoe wij jouw gemeente kunnen ondersteunen bij een technisch betrouwbare GGM-implementatie? Neem contact met ons op en we denken graag vrijblijvend met je mee.