In een aantal entiteittypen zijn elementen opgenomen uit andere object- of entiteittypen (de zogenoemde platgeslagen relaties). Denk aan bijvoorbeeld de straat- of woonplaatsnaam in een AOA-entititeit.
Een belangrijke vraag die hierbij speelt is hoe in deze gevallen de definitie van het tijdvakGeldigheid moet zijn.
Een voorbeeld:
Openbare ruimte kerkstraat bevat een nummeraanduiding kerkstraat 10. Op 1-1-2010 wordt kerkstraat hernoemd in kapelstraat, resulterend in kennisgevingsberichten voor de OPR/GOR en voor de AOA (kerkstraat 10 wordt kapelstraat 10).
Wat is nu de tijdvakGeldigheid.beginGeldigheid in het AOA-bericht? De tijdvakgeldigheid van de nummeraanduiding wijzigt immers niet in de registratie, omdat deze zelf niet wijzigt. De begindatum zou dan dus een datum ver in het verleden kunnen zijn (de laatste mutatiedatum van het NAA-object zelf).
Zeker als op 1-1-2011 de nummeraanduiding wordt gewijzigd (naar kapelstraat 10 a), dan moet je je als zender afvragen wat de beginGeldigheid in de oude situatie in het AOA-bericht zou moeten zijn.
Zou de tijdvakgeldigheid van het (RSGB-) object zelf worden genomen, dan krijg je voor de AOA mogelijk meerdere berichten met dezelfde ingangsdatum (waarbij je de ingangsdatum van de feitelijke mutatie van de (StUF-) entiteit kwijt zou raken). Zou je ervoor kiezen om de ingangsdatum van de platgeslagen entiteit te nemen (in het voorbeeld dus de OPR), dan betekent dat dat je bij elk bericht na moet gaan welke periode moet worden genomen. Dit kan best wel eens meerdere niveau's diep gaan als het gaat om bijvoorbeeld de woonplaats(-naam) bij een openbare ruimte bij een nummeraanduiding. Moeten we het verzendende systeem hiermee opzadelen?
Hoe zouden we hier mee om moeten gaan? Ofwel: wat is nu eigenlijk de definitie van de tijdvakGeldigheid bij entiteittypen waarin eigenschappen van andere entiteit-/objecttypen zijn ondergebracht?
Met vriendelijke groet,
Sid Brouwer
Hallo Sid,
StUF weet niet dat attributen afkomstig zijn uit een platgeslagen relatie. Attributen uit een platgeslagen relatie moeten daarom op precies dezelfde wijze behandeld worden als eigen attributen.
Je maakt bij een vernaming van de openbare ruimte dus een AOA-bericht aan met de wijziging van de straatnaam en als ingangsdatum de ingangsdatum van de wijziging.
De consequentie van deze benadering is natuurlijk wel dat in de database de tijdvakken geldigheid niet overeenkomen met de tijdvakken geldigheid in de basisregistratie adressen. Je kunt de tijdvakken geldigheid in de BRA overigens altijd reconstrueren door alleen die tijdvakken te pakken waarbij een attribuut in de BRA wijzigt. Hier heb je dan weer domeinkennis voor nodig.
Maarten van den Broek
Hallo Maarten,
Dat betekent dus dat de definitie van het tijdvakGeldigheid niet meer kan verwijzen naar een RSGB-gegeven, maar een gegeven is dat specifiek geldt voor de StUF-enteiten. Met andere woorden: in dergelijke gevallen verwijst het tijdvakGeldigheid niet meer naar één in het RSGB gedefinieerd gegeven, maar naar een berekening waarin meerdere gegevens moeten worden meegenomen.
Is het wel duidelijk dat deze keuze voor een aanleverend systeem de bepaling van het tijdvak best complex maakt? Om de datum te bepalen moeten voor een AOA-bericht de bijbehorende openbare ruimte en woonplaats worden bekeken, voor TGO moet worden gekeken naar BRT en AOA of OPR. En bij NPS zie ik zo al 5 platgeslagen relaties staan.
Voor al die relaties moet dus bij elke mutatie op het boveliggende object worden gekeken of er een mutatie is geweest met een latere ingangsdatum dan de ingangsdatum van de vorige situatie van het object en zo ja, of dit wijzigingen betrof die attributen betrof die zijn opgenomen in het object zelf.
Voor de datum in het wordt-gedeelte is het allemaal niet zo'n probleem, maar voor de WAS-situatie in een volgend bericht moet je dus deze 'berekening' gaan maken.
Volgens mij maak je het hiermee onnodig complex voor de verzendende systemen om de gegevens in de WAS-situatie te bepalen. Of je zou dergelijke datums ook weer op moeten slaan als attribuut van het bovenliggende object.
Het aantal te administreren tijdvakken wordt zo langzaamaan wel erg groot: authentiek, niet authentiek, StUF...
Mijn voorstel is om de tijdvakken dan toch direct aan te laten sluiten op het RSGB en dan (voor de platgeslagen relaties) een ingangsdatum op te nemen die niet nog eens hoeft te worden herhaald in de was-situatie van een volgend bericht.
Met vriendelijke groet,
Sid Brouwer
Hallo Sid,
Mogelijk is het probleem een gevolg van het feit dat in jullie implementatie van AOA de platgeslagen gegevens in de database niet zijn opgenomen bij AOA, maar worden opgehaald vanuit OPR. Bij een dergelijke implementatie kan ik me voorstellen dat een en ander niet triviaal is. Wanneer je de platgeslagen gegevens gewoon vastlegt bij AOA is er mijns inziens geen probleem met de StUF-voorschriften, want dan weet je simpelweg wat de ingangsdatum van het laaste te wijzigen voorkomen is.
De StUF-standaard wil zich verre houden van dit soort implementatievraagstukken en probeert op een niveau dat hiervan abstraheert voorschriften te geven. De ene implementatie kan vanuit StUF inderdaad natuurlijker zijn dan de andere, maar dat is de vrijheid van de ontwerper van een systeem.
Maarten
Hallo Maarten,
Daar ben ik het niet helemaal mee eens:
In het RSGB zijn deze gegevens netjes uitgenormaliseerd. StUF-BG 03.10 zou toch gebaseerd zijn op het RSGB?! Volgens mij zou je dan het liefst de gegevens in StUF liefst een op een laten overeen komen met de gegevens in het RSGB. Hierbij kun je redundantie introduceren en objecten plat slaan, maar liefst zou je de attributen (lijkt mij) zoveel mogelijk laten 'mappen' op attributen die ook daadwerkelijk in het RSGB zijn opgenomen.
De tijdvakGeldigheid is nu zodanig gedefinieerd dat zij (voor sommige entiteittypes) niet meer één op één overeen komen met attributen in het RSGB, maar dat hiervoor een complexe berekening nodig is. De tijdvakgeldigheid van een nummeraanduiding of overig adresseerbaar objectaanduiding zou namelijk in het RSGB niet hoeven wijzigen op het moment dat een straatnaam wijzigt. Dat stemt volgens mij niet overeen met het RSGB.
Ik ben het met je eens dat StUF geen uitspraken moet doen over implementatie. Nu wij k je echter zoveel af van het RSGB dat je min of meer een redundante implementatie oplegt (om het allemaal werkbaar te maken), die helemaal niet nodig is voor het RSGB.
Ik bestrijd dus dat het alleen maar een implementatiekwestie is: het is een afwijking ten opzichte van de in het RSGB opgestelde structuur.
Met vriendelijke groet,
Sid Brouwer
Hallo Sid,
In de verStUFfing is er op een aantal plaatsen heel bewust voor gekozen om te denormaliseren. Een systeem dat bijvoorbeeld geen tabel met openbare ruimten bevat (de meeste systemen) vind het wel gemakkelijk dat AOA ook de openbareruimtenaam en woonplaatsnaam bevat. Daarnaast vergemakkelijkt dit het stellen van vragen. Je kunt nu zonder al te ingewikkelde constructies selecteren en sorteren op straat en woonplaats.
Ik stel voor dat de StUF expertgroep zich buigt over jouw issue in haar vergadering van a.s. woensdag. Via het forum zal het resultaat worden teruggekoppeld.
Groet,
Maarten
Hallo Maarten,
Voor alle duidelijkheid: de denormalisering in StUF kan ik mij heel goed voorstellen. Het gaat mij om de complexiteit van de bepaling van de gegevens en het feit dat er in StUF nu attributen zijn (anders dan stuurgegevens) die niet één op één overeen komen met attributen uit het RSGB.
In ieder geval dank voor je reactie(s). Ik wacht de uitslag af.
Met vriendelijke groet,
Sid
Hallo Sid en anderen,
Deze post hangt nauw samen met andere posts (die van Sid over het platslaan van gemeente, wijk en buurt in elkaar en in pand en die van Ruud Kathmann over de grote aantallen berichten die een gevolg zijn van het platslaan).
In deze reactie wil ik wat uitvoeriger ingaan op de achterliggende problematiek en de gemaakte keuzen.
De berichtstructuren in StUF zijn hiërarchische boomstructuren en geen netwerkstructuren. In het volgend nummer van DB/M verschijnt een artikel van Henri en mij dat dieper hierop ingaat. Het is ook als attachment bij deze post gevoegd. Kern van de zaak is dat StUF in de vorm van een boomstructuur een samenhangende hoeveelheid informatie modelleert relevant vanuit de business, zogenaamde business objecten. Om het werken met StUF te vereenvoudigen wordt daarbij ook nog eens regelmatig gedenormaliseerd, dat wil zeggen gegevens die in het genormaliseerde model zijn opgenomen in een gerelateerd entiteittype worden platgeslagen in het entiteittype vanwaaruit de relatie ligt.
Dit heeft een aantal consequenties waar we ons nu bij de implementatie van bewust worden:
Het gaat enerzijds over de vraag in hoeverre een StUF sectormodel normatief definieert welke transacties voor een entiteittype ondersteund worden en anderzijds over de vraag of alle gemaakte keuzen in bg0310 wel gelukkig zijn.
Voor wat betreft het normatief zijn van StUF zou ik graag vasthouden aan de lijn dat een systeem dat de berichten voor een bepaald entiteittype zegt te ondersteunen, dit dan ook doet met de functionaliteit zoals die gedefinieerd voor de berichten, dus inclusief consequenties als het dan misschien vanuit een BAG-systeem wel moeten versturen van honderdduizenden berichten op het moment dat bijvoorbeeld een woonplaatsnaam wijzigt. De standaard verliest een belangrijk deel van zijn waarde, als dit weer wordt overgelaten aan bilaterale afspraken tussen implementaties. De lasten worden dus neergelegd bij het systeem dat berichten verstuurt en niet bij het systeem dat berichten ontvangt. Dit uitgangspunt is ook gekozen bij de definitie van het koppelvlak van de BAG met GBA en WOZ. Het lijkt me ook een logisch uitgangspunt, omdat er vaak maar één verzendende partij is en meerdere ontvangende partijen. Overall minimaliseert dit uitgangspunt de kosten en geeft het ontvangende systemen de vrijheid om zelf een implementatie van hun database te kiezen. Het is bijvoorbeeld niet noodzakelijk om in alle systemen een woonplaats, openbare ruimte en zelfs nummeraanduiding tabel bij te houden. Alle mutaties op deze objecten komen nu ook binnen via TGO.
Nu inhoudelijk nog iets over de drie hierboven genoemde punten.
Platslaan en historie
Er lijkt veel voor te zeggen om te zeggen dat platgeslagen gegevens nooit historie hebben in het entiteittype waarin ze zijn platgeslagen, omdat dit het genereren van antwoordberichten voor het entiteittype waarin de gegevens zijn platgeslagen vereenvoudigd bij een implementatie, waarin de platgeslagen gegevens in de database niet zijn opgenomen bij het entiteittype, maar alleen de verwijzing.
Zo is het nu niet gedefinieerd in bg0310. Daar hebben platgeslagen gegevens ook gewoon historie. Een interessant geval in dit verband is het platslaan van de adresgegevens bij een natuurlijk persoon. Wanneer hier geen historie wordt gedefinieerd voor de platgeslagen gegevens, dan zal een antwoordbericht niet op een natuurlijke manier de adreshistorie bevatten. In geval van een nevenadres is het niet eens mogelijk om in één bericht de complete adreshistorie op te vragen, als de platgeslagen gegevens geen historie hebben.
Verschillende modellen voor kennisgevingen en vraag/antwoord
De nu in bg0310 gemaakte keuze wijst heel erg in de richting van een genormaliseerde implementatie in de database van de gemeente, wijk, buurt en pand tabellen. In vraag- antwoordberichten is het natuurlijk wel handig om niet alleen de codes te hebben, maar ook de omschrijvingen en andere gegevens.
Ik denk dat we hier per geval moeten beoordelen of de keuze die bg0310 maakt zinnig is. Zo niet, dan zal het sectormodel bg herzien moeten worden. Deze discussie kan natuurlijk ook gevoerd worden voor de platgeslagen adres gegevens. Voor de goede orde: Deze discussie is onafhankelijk van de discussie of voor platgeslagen gegevens al dan niet historie gedefinieerd mag worden.
Wijzigingen in platgeslagen gegevens in kennisgevingen worden ook doorgegeven in het entiteittype waarin is platgeslagen
Ik heb hierboven al beargumenteerd dat dit me het correcte uitgangspunt lijkt. Een andere vraag is natuurlijk of we dan niet op teveel plaatsen platgeslagen hebben gegeven de consequentie dat dit soms kan leiden tot honderdduizenden berichten.
Ik schrik niet zo van deze aantallen berichten. In een dag zitten 80.000 seconden en er worden meerdere berichten per seconde verwerkt. In een weekeinde hebben de systemen dit probleem dus gemakkelijk weggewerkt zonder dat er veel menselijk ingrijpen nodig is, afgezien van het inplannen van deze verwerking.
Voor systemen die zich primair richten op bevragingen lijkt denormaliseren van de database verstandig om het werken met historie intuïtief voor de eindgebruiker te maken. Het lijkt ook verstandig om de last die dit met zich meebrengt bij de bron te leggen.
Ik ben benieuwd naar de reacties van anderen op het bovenstaande en zie uit naar de discussie hierover in de expertgroep.
Maarten