Het is niet duidelijk welke waarde(n) teruggeven moeten worden bij een vraag op peiltijdstip materieel en formeel bij een niet nauwkeurige tijdvakGeldigheid of tijdstipRegistratie in de database of bij een niet nauwkeurige specificatie van het peiltijdstip.
(Deze post komt voort uit post 'eindGeldigheid' moet groter zijn dan 'beginGeldigheid' van 'tijdvakGeldigheid').
Ik heb de aanpassingen in het concept document StUF 03.01 voor patch 14 eens bekeken en er viel mij iets op waar mogelijk rekening mee moet worden gehouden.
Bij het bepalen van de grootste waarde voor een tijdstip binnen de onnauwkeurigheid wordt een tijdstip genomen met 999 milliseconden. Nu is het zo dat er binnen het stelsel van basisregistraties in ieder geval bij de BAG wordt gewerkt met een domein DatumTijd van 16 tekens (het tijdstip gaat dus niet verder dan honderdsten van seconden).
Wanneer in dergelijke gevallen het tijdstip met 999 milliseconden (17 tekens) voor gebruik wordt afgerond krijg je een waarde die net iets hoger is dan bedoeld.
Ik heb me hier verder niet helemaal in verdiept, maar moet met dit soort zaken geen rekening worden gehouden? Als het van belang is voor de werking, is het wellicht goed om dit te documenteren.
Wat is het toch leuk als je de tekst in paragraaf 6.4.5 leest met een wiskundige blik. Hoe moet je de uitspraak duiden “het kleinere element in een kleiner dan relatie”? Of wat wordt er bedoeld met “tijdstipregistratie overlapt met peiltijdstipFormeel”?
Als ik de theoriën over relationele expressies, Boolean algebra en bitemporal databases toepas op StUF, dan kom ik tot de volgende vijf opmerkingen:
Bij het zoeken in de materiële historie moet het voorkomen (of de voorkomens) van een object van een fundamentele entiteit voldoen aan: beginGeldigheid <= peiltijdstipMaterieel EN peiltijdstipMaterieel < eindGeldigheid.
Idem dito voor een relatie entiteit: beginRelatie <= peiltijdstipMaterieel EN peiltijdstipMaterieel < eindRelatie EN beginGeldigheid <= peiltijdstipMaterieel EN peiltijdstipMaterieel < eindGeldigheid.
Bij een relationele expressie wordt gesproken over twee expressies die met elkaar worden vergeleken met een operator, bijvoorbeeld beginGeldigheid <= peiltijdstipMaterieel, met als uitkomst waar of niet-waar (true/false). Het gebruik van “het kleinere element” en “het grotere element” is voorbarig, want dat is pas bekend nadat de expressies met elkaar vergeleken zijn (was beginGeldigheid inderdaad kleiner of gelijk aan peiltijdstipMaterieel?). Gebruikelijk is om te spreken van een linker expressie en een rechter expressie.
Het zoeken naar het juiste voorkomen in de formele historie op een peiltijdstipFormeel levert een lastigere beschrijving op, omdat in het berichtenverkeer uitsluitend sprake is van tijdstipRegistratie, en niet van een combinaties startTijdstipRegistratie en stopTijdstipRegistratie: het voorkomen met de hoogste waarde voor tijdstipRegistratie waarvoor geldt dat tijdstipRegistratie <= peiltijdstipFormeel.
Stel de database bevat twee voorkomens:
nr beginGeldigheid eindGeldigheid
1 15-07-2012 00:00 15-07-2012 00:01
2 15-07-2012 00:01 leeg
en de peiltijdstipMaterieel is 15-07-2012
Volgens voorstel, waarbij ik aanneem dat beginGeldigheid de onnauwkeurigheid bevat en dus aangepast moet worden:
beginGeldigheid <= peiltijdstipMaterieel EN peiltijdstipMaterieel < eindGeldigheid
1: 15-07-2012 23:59 <= 15-07-2012 EN 15-07-2012 < 15-07-2012 23:59
-> niet-waar
2: 15-07-2012 23:59 <= 15-07-2012 EN 15-07-2012 < leeg
-> niet-waar
Andere interpretatie: peiltijdstipMaterieel bevat de onnauwkeurigheid en dus aanpassen:
beginGeldigheid <= peiltijdstipMaterieel EN peiltijdstipMaterieel < eindGeldigheid
1: 15-07-2012 00:00 <= 15-07-2012 23:59 EN 15-07-2012 23:59 < 15-07-2012 00:01
-> niet-waar
2: 15-07-2012 00:01 <= 15-07-2012 23:59 EN 15-07-2012 23:59 < leeg
-> waar
Alternatief: vergelijken op basis van nauwkeurigheid. Bijvoorbeeld door de datum/tijd om te zetten in een string en die af te breken op de minimale lengte (de grootste onnauwkeurigheid)
nr beginGeldigheid eindGeldigheid peiltijdstipMaterieel
1 15-07-2012 00:00 15-07-2012 00:01 15-07-2012
2 15-07-2012 00:01 leeg 15-07-2012
Omgezet naar strings:
nr beginGeldigheid eindGeldigheid peiltijdstipMaterieel
1 20120715 20120705 20120705
1 20120715 leeg 20120705
Vergelijken:
1: 20120705 <= 20120705 EN 20120705 < 20120705 -> niet waar
2: 20120705 <= 20120705 EN 20120705 < leeg -> waar
Volgens mij heeft dit ook veel te maken met de post over het al dan niet kleiner moeten zijn van datumGeldigheid oud en nieuw:
'eindGeldigheid' moet groter zijn dan 'beginGeldigheid' van 'tijdvakGeldigheid'
Sid, dat klopt.
Het probleem bij die andere post is niet de inhoud van de berichten of het verwerken van de berichten.
Maar het probleem is wat er daarna met de opgeslagen data gedaan moet worden als er een vraag wordt gesteld of als er een bestaand voorkomen gewijzigd moet worden (kortom: kun je het juiste voorkomen terugvinden in de database).
In patch 14 is in paragraag 6.4.5. de volgende tekst opgenomen: "In geval van niet tot op de milliseconde nauwkeurig gespecificeerde tijdstippen geldt dat in een kleiner dan relatie als waarde voor het kleinere element de grootst mogelijke waarde binnen de onnauwkeurigheids range genomen moet worden en als waarde voor het grotere element de kleinst mogelijke waarde binnen de onnauwkeurigheids range. Bij een groter dan relatie is het precies andersom. Voor het grotere element wordt dan als waarde de grootst mogelijke waarde in de onnauwkeurigheids range genomen en voor het kleinere element de kleinst mogelijke waarde in de onnauwkeurigheids range."
Ik mis in het document en deze post de reden waarom soms de "grootst mogelijke waarde" en soms de "kleinst mogelijke waarde" moet worden opgenomen. Zoals Han terecht opmerkt, leidt dit soms tot het onterecht (niet) selecteren van gegevens.
?Het is mij niet duidelijk waarom niet altijd de eenduidige regel wordt toegepast om "de kleinst mogelijke waarde (00..0) binnen de onnauwkeurigheids range" te gebruiken. In dit geval zullen gegevens eenduidig worden geselecteerd en is altijd een peiltijdstip te definiëren die een bepaalde selectie oplevert.
Bovenstaand fragment waaraan wordt gerefereerd komt uit een nooit gepubliceerde concept versie van de StUF standaard.
Dit Erratum is opgevoerd in de onderhoudsverzoeken als ERR254.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Tijdens de StUF Expertgroep van 18 juni 2014 is besloten dit erratum voorlopig weer als een onderhoudsverzoek te definieren (ONV0341).