Hoe gebruik je het Gemeentelijk Gegevensmodel in een gemeentelijk datawarehouse?

Ed Kisman ·
Architectonische bouwtekening van een Nederlands gemeentehuis op een eikenhouten bureau, met laptop en miniatuur stadhuis.

Het Gemeentelijk Gegevensmodel (GGM) gebruik je in een gemeentelijk datawarehouse als semantische laag die de betekenis van gemeentelijke gegevens vastlegt en standaardiseert. Door GGM-entiteiten als basis te nemen voor je datawarehouse-ontwerp, zorg je dat gegevens uit verschillende bronsystemen op een eenduidige manier samenkomen. Dit artikel beantwoordt de meest gestelde vragen over het vertalen van het GGM naar een werkende datawarehouse-architectuur.

Wat is het Gemeentelijk Gegevensmodel precies?

Het Gemeentelijk Gegevensmodel (GGM) is een open informatiemodel dat de gegevensobjecten, hun eigenschappen en hun onderlinge relaties beschrijft voor vrijwel alle gemeentelijke domeinen. Het model is oorspronkelijk ontwikkeld door de gemeente Delft op basis van interviews met domeinexperts, bestaande applicaties en landelijke informatiestandaarden, met als doel een generiek herbruikbaar model te bieden dat aansluit bij de lokale praktijk.

Het GGM dekt een breed spectrum aan gemeentelijke domeinen, waaronder:

  • Sociaal domein (Wmo, Jeugd, Inkomen, Werk, Schuldhulpverlening, Inburgering)
  • Volkshuisvesting, Leefomgeving en Stedelijke Vernieuwing (Openbare ruimte, Bouwen en Wonen, Omgevingswet)
  • Onderwijs (Leerplicht, Leerlingenvervoer, funderend onderwijs)
  • Sport, Cultuur en Recreatie (Erfgoed, Musea, Archeologie, Monumenten)
  • Verkeer, Vervoer en Waterstaat (Mobiliteit en Parkeren)
  • Interne organisatie (ICT, Financiën, HR, Inkoop, Subsidies)
  • Dienstverlening (meldingen, aanvragen, baliecontacten, digitale interacties)

Wat het GGM onderscheidt van een intern gegevensmodel is de verankering in landelijke standaarden zoals RSGB, RGBZ, iWmo, iJw, het Suwi Gegevensregister (SGR) en geo-informatiestandaarden als NEN 3610 en IMBAG. Hierdoor sluit het model aan bij bestaande afspraken in de keten in plaats van een nieuwe, losstaande standaard te introduceren.

Hoe verhoudt het GGM zich tot een datawarehouse-architectuur?

Het GGM fungeert in een datawarehouse-architectuur als conceptueel fundament: het beschrijft wat gemeentelijke gegevens betekenen, terwijl het datawarehouse bepaalt hoe die gegevens worden opgeslagen, gecombineerd en beschikbaar gesteld voor analyse. De twee vullen elkaar aan en zijn geen concurrerende modellen.

In de praktijk positioneer je het GGM het best als referentiemodel voor de semantische laag of het kernmodel van je datawarehouse. Bronsystemen leveren ruwe data aan; het GGM biedt de definitie waarmee je die data harmoniseert voordat ze in de analytische laag terechtkomen. Dit maakt het GGM bijzonder geschikt als basis voor een BI-infrastructuur die meerdere bronsystemen integreert.

Concreet betekent dit dat GGM-objectklassen vertaald worden naar dimensies en feitentabellen, waarbij de relaties in het GGM de referentiële integriteit in het datawarehouse onderbouwen. Heb je te maken met een Data Vault-aanpak, dan vormen GGM-entiteiten de hubs en GGM-relaties de links.

Welke GGM-entiteiten zijn het meest relevant voor een datawarehouse?

De meest relevante GGM-entiteiten voor een gemeentelijk datawarehouse zijn die objectklassen die domeinoverstijgend worden hergebruikt en een hoog analysegewicht hebben. Denk aan personen, adressen, zaken en verstrekkingen, omdat deze in vrijwel elk beleidsdomein terugkomen en de kern vormen van gemeentelijke rapportages.

Binnen het Sociaal domein zijn entiteiten rondom Wmo-maatwerkvoorzieningen, jeugdhulptrajecten, uitkeringen en schuldhulpverleningstrajecten het meest gevraagd voor managementinformatie. In het domein Volkshuisvesting en Openbare ruimte zijn objecten uit BGT/IMGeo en IMBOR relevant, met name voor beheerrapportages over de openbare ruimte. Voor de Omgevingswet zijn entiteiten rondom vergunningverlening, toezicht en handhaving (gebaseerd op RiHA) steeds belangrijker geworden.

Prioriteer bij de inrichting van je datawarehouse de entiteiten die:

  1. Domeinoverstijgend worden gedeeld (zoals Persoon, Adres, Zaak)
  2. Direct gekoppeld zijn aan sturingsinformatie en KPI’s
  3. Gevoed worden vanuit meerdere bronsystemen tegelijk
  4. Wettelijke verantwoordingsverplichtingen ondersteunen

Hoe vertaal je GGM-objectklassen naar datawarehouse-tabellen?

Je vertaalt GGM-objectklassen naar datawarehouse-tabellen door elke objectklasse te evalueren op zijn rol in analyses: wordt het een dimensietabel, een feitentabel of een brug? De attributen van de GGM-klasse worden kolommen, en de associaties tussen klassen worden foreign key-relaties of aparte koppeltabellen.

Een praktische aanpak werkt als volgt:

  1. Identificeer kernentiteiten die als dimensie dienen, zoals Persoon, Locatie of Organisatie.
  2. Bepaal meetbare feiten: welke GGM-klassen bevatten kwantificeerbare gegevens zoals aantallen, bedragen of doorlooptijden?
  3. Modelleer tijdsdimensies: veel GGM-entiteiten kennen geldigheidsperioden (begindatum/einddatum) die je als slowly changing dimensions (SCD type 2) implementeert.
  4. Vertaal associaties: een GGM-relatie tussen Zaak en Betrokkene wordt een brug- of feitentabel in het datawarehouse.
  5. Pas naamgeving aan: gebruik GGM-terminologie als basis voor kolomnamen zodat het model begrijpelijk blijft voor domeinexperts.

Let daarbij op dat het GGM nog niet volledig compliant is met het Metamodel voor Informatiemodellen (MIM). Dit betekent dat je bij de vertaalslag soms eigen interpretaties moet vastleggen in een data dictionary om de semantiek te borgen.

Welke databronnen koppel je aan het GGM in een gemeentelijk datawarehouse?

In een gemeentelijk datawarehouse koppel je primair die bronsystemen waarvan de gegevens overeenkomen met GGM-domeinen. De meest voorkomende bronnen zijn zaaksystemen, basisregistraties, sectorale applicaties en landelijke gegevensketens die via standaardkoppelingen ontsloten worden.

Concrete bronkoppelingen per domein zijn onder meer:

  • Sociaal domein: berichtenverkeer via iWmo en iJw (beide versie 2.x) voor zorgaanbieders, iPgb voor persoonsgebonden budgetten en het Suwi Gegevensregister (SGR versie 4.0) voor Werk en Inkomen
  • Geo-informatie en openbare ruimte: BAG (IMBAG), BGT/IMGeo 2.1.1 en IMBOR voor beheertoepassingen
  • Omgevingswet: STTR/IMTR, STAM/IMAM en STOP/TPOD voor vergunningen en officiële publicaties
  • Basisregistraties: RSGB (versie 2.0.2) als basis voor de kernentiteiten rondom personen, adressen en gebouwen

Een goede data-integratiestrategie is essentieel om deze bronnen betrouwbaar en herhaalbaar aan te sluiten. Zorg dat je ETL- of ELT-processen de GGM-semantiek bewaren tijdens de transformatie, zodat het eindresultaat in het datawarehouse nog steeds aansluit bij de domeinbetekenis.

Wat zijn veelvoorkomende valkuilen bij GGM-implementatie in een datawarehouse?

De meest voorkomende valkuilen bij GGM-implementatie in een gemeentelijk datawarehouse zijn het klakkeloos overnemen van het volledige model, het negeren van lokale afwijkingen in bronsystemen en het ontbreken van een duidelijke data-governancestructuur. Elk van deze fouten leidt tot een datawarehouse dat op papier aansluit bij het GGM maar in de praktijk moeilijk te onderhouden of te begrijpen is.

Het model te letterlijk implementeren

Het GGM is een conceptueel model, geen fysiek databaseschema. Wie het model één-op-één vertaalt naar tabellen, krijgt een overgenormaliseerde structuur die slecht presteert voor analytische queries. Vertaal het GGM altijd via een logisch model naar een fysiek model dat is geoptimaliseerd voor rapportage en analyse.

Lokale databronnen niet valideren tegen het GGM

Bronsystemen wijken in de praktijk af van het GGM, soms in naamgeving, soms in structuur. Documenteer deze afwijkingen expliciet in een mapping-document en leg vast hoe je de transformatie uitvoert. Zonder deze documentatie verlies je de traceerbaarheid van gegevens en wordt kwaliteitscontrole vrijwel onmogelijk.

Data governance onderschatten

Een GGM-gebaseerd datawarehouse staat of valt met duidelijke afspraken over gegevenseigenaarschap, definitiebeheer en wijzigingsbeheer. Wie is verantwoordelijk voor de definitie van een entiteit als Cliënt in het Sociaal domein? Wie keurt wijzigingen in het model goed? Zonder antwoorden op deze vragen groeit het datawarehouse uit tot een onbeheersbare verzameling inconsistente tabellen. Een solide aanpak voor beveiliging en governance is daarom geen bijzaak maar een voorwaarde.

Hoe DBA helpt met GGM-implementatie in een gemeentelijk datawarehouse

Wij begrijpen dat de vertaalslag van een conceptueel model als het GGM naar een werkend, goed presterend datawarehouse veel technische en organisatorische kennis vraagt. Als database-experts met ruime ervaring bij overheidsinstellingen helpen wij gemeenten bij elke stap van dit traject.

Wat wij concreet bieden:

  • Architectuuradvies voor het vertalen van GGM-entiteiten naar een logisch en fysiek datawarehouse-model
  • Data-integratie van gemeentelijke bronsystemen, inclusief aansluiting op landelijke standaarden zoals RSGB, iWmo en SGR
  • Databasebeheer en optimalisatie van de onderliggende SQL Server- of PostgreSQL-omgeving waarop het datawarehouse draait
  • Governance-ondersteuning bij het inrichten van een data dictionary, eigenaarschap en wijzigingsbeheer
  • BI-consultancy voor rapportages en dashboards bovenop de GGM-gebaseerde datastructuur, onder meer via Microsoft Fabric voor de overheid

Of je nu start met een nieuw datawarehouse-project of een bestaande omgeving wilt laten aansluiten op het GGM, wij denken graag met je mee. Neem contact op en we bespreken samen de mogelijkheden voor jouw gemeente.

Gerelateerde artikelen