B3238 - Alleen identificatoren en geen achterliggende waarden

Besluit

• In de verwerkingenlogging-API worden waar mogelijk alleen de identificatoren (identifiers of sleutelwaarden) doorgegeven en niet de achterliggende waarden.

Toelichting

Het semantisch informatiemodel dient genormaliseerd te zijn zodat de logische relaties tussen objecttypen en attributen duidelijk worden. Voor verwerkingenlogs gelden er vaak bijzondere niet functionele requirements (NFR’s) inzake performance, opslag etc. Dergelijke requirements leiden regelmatig tot praktische datamodellen die sterk afwijken van het semantische informatiemodel.

Enkele verschillende patronen voor het fysieke datamodel (niet uitputtend):

• Een zo compact mogelijk verwerkingenlog met zoveel mogelijk ID’s en Codes. De nadruk ligt op minimale storage en minimale data transfer zodat het loggen zo snel mogelijk gaat.
• Een zo compleet mogelijk log dat op zichzelf leesbaar is en niet afhankelijk is van het (nog) beschikbaar zijn van allerlei systemen (en hun vorige versies) om ID’s en Codes om te zetten naar leesbare informatie.
• Een combinatie waarbij bijvoorbeeld namen en beschrijvingen achter gestandaardiseerde code lijsten in aparte tabellen als onderdeel van of bij het verwerkingenlogsysteem worden opgeslagen. Dit om een compacte opslag te bereiken, maar niet afhankelijk te zijn van operationele systemen.

Als het verwerkingenlog naast de identificatoren ook de achterliggende waarden opslaat, dan kan het nodig zijn dat die achterliggende waarden meegegeven moeten worden bij het aanroepen van de verwerkingenlogging-API.

Er is daarom gekeken welke velden hiervoor op dit moment in aanmerking komen:

• Uitvoerende organisatie: Hier zou ook de naam opgenomen kunnen worden. Aanname is echter dat OIN’s nog vele jaren herleid kunnen worden naar de achterliggende gegevens. Zie ook B0516 (Identificatie van organisaties).
• Gebruiker: Hier zou ook de naam van de gebruiker opgenomen kunnen worden. Dit is echter ongewenst vanuit Privacy. Beter is gemeenten bewust maken dat gegevens over gebruikers en autorisaties bij ingebruikname van nieuwe (autorisatie) systemen niet verloren mogen gaan en bijvoorbeeld in leesbare vorm beschikbaar moeten blijven.

Conclusie

Er is een beperkt aantal velden waarbij dit issue zou kunnen spelen. Er zijn maatregelen te treffen om ervoor te zorgen dat de informatie ‘achter’ deze velden nog vele jaren beschikbaar is. Daarmee komt de noodzaak om gedenormaliseerde informatie op te nemen in de API te vervallen.