(Basis)administraties en gegevensuitwisseling

Transcriptie

1 (Basis)administraties en gegevensuitwisseling Door René van Leusen Probleembeschrijving In de praktijk blijkt regelmatig dat het uitwisselen van gegevens tussen systemen zeer ingewikkeld is. Het gaat dan bijvoorbeeld om complexe berichten en ingewikkelde afspraken om deze berichten samen te stellen en te verwerken. Maar ook om het niet kunnen leveren van gegevens omdat bij het ontwerpen van een administratie geen rekening is gehouden met bepaalde informatie behoeftes van afnemende systemen. Bij omvangrijke en grote aantallen berichten is in productie vaak sprake van performance problemen en gebrek aan hardware resources (CPU, geheugen). Voor de korte termijn zijn het toepassen van noodgrepen in de code en het aanschaffen van dure hardware meestal de enige oplossingsalternatieven. Aanpassen van afgestemde berichten en vastgelegde afspraken is een langdurend traject. Het uitwisselen van gegevens tussen systemen wordt steeds belangrijker. Het centraal en eenmalig bewaren van veel gebruikte gegevens is een architectuur principe dat veel wordt toegepast. Een bekend voorbeeld zijn de basisadministraties die de overheid heeft onderkend (nl.wikipedia.org/wiki/basisregistratie). Een ander voorbeeld is masterdata management waarbij organisaties veel gebruikte gegevens zoals bijvoorbeeld referentietabellen en klantgegevens centraal bewaren (en.wikipedia.org/wiki/master_data_management). In dit artikel wordt een aantal onderwerpen beschreven die tijdens het ontwerpen van een (basis)administratie en het uitwisselen van gegevens met andere systemen meegenomen moeten worden. De gemaakte keuzes bepalen in hoge mate de functionaliteit, complexiteit, onderhoudbaarheid, performance en resource gebruik van de systemen. Het gaat om de volgende onderwerpen: 1 Systemen hebben geen kennis van de business logica van andere systemen; 2 Uitwisselen van (gewijzigde) gegevens tussen systemen; 3 Uitwisselen van (gewijzigde) gegevens in een keten van systemen; 4 Uitwisselen van (gewijzigde) gegevens afhankelijk van business rules; 5 Uitwisselen van gegevens (on)afhankelijk van de database structuur; 6 Uitwisselen van gegevens afhankelijk van de gewenste integriteit; 7 Mutatiehistorie van gegevens; 8 Geldigheid van gegevens. De eerste vijf onderwerpen gaan over het uitwisselen van gegevens tussen systemen. De laatste drie onderwerpen gaan over welke eisen er gesteld worden aan de gegevens(structuur) van de lokale database van een systeem, opdat een systeem de juiste gegevens kan uitwisselen met andere systemen.

2 Voorbeeld: deelauto Bovenstaande onderwerpen worden toegelicht aan de hand van een voorbeeld. Als voorbeeld wordt het gezamenlijk gebruik van een deelauto door een aantal huisadressen uitgewerkt. Zogenaamde deelauto projecten worden steeds populairder. Het idee achter een deelauto is dat alleen wordt betaald wanneer de auto wordt gebruikt. In het deelauto project in dit voorbeeld delen meerdere huisadressen twee auto s. Een kleine auto voor bijvoorbeeld korte ritten in de stad, en een grote auto voor een weekendje weg met alle bewoners van een huisadres, of het vervoeren van een heel voetbalteam op zaterdagochtend. Op een huisadres wonen een of meerdere bestuurders. De algehele administratie van het deelauto project wordt vanuit één centraal huisadres gecoördineerd. Per huisadres is 1 persoon verantwoordelijk voor zowel de administratie van dat huisadres, als de communicatie met het centrale huisadres en de communicatie met de andere bestuurders die op hetzelfde huisadres wonen. Elke bestuurder is zelf verantwoordelijk voor zijn of haar administratie. De gegevensstructuur waarin het centrale huisadres al deze gegevens bewaard ziet er als volgt uit: In RIT wordt bijgehouden welke BESTUURDER wanneer hoeveel kilometer heeft gereden in welke AUTO. In BOETE wordt bijgehouden tijdens welke RIT een overtreding is beboet, en in ROOSTERUUR kan een HUISADRES een auto reserveren.

3 In de onderstaande uitwerkingen van bovenstaande onderwerpen wordt er vanuit gegaan dat alle huisadressen en alle bestuurders een eigen softwaresysteem en een eigen database hebben: Het centrale huisadres heeft een softwaresysteem voor het registreren van bovenstaande gegevens in een centrale database, en het versturen van berichten met gegevens uit deze centrale database naar de verschillende huisadressen. Het software systeem van het centrale huisadres biedt een website waarmee een bestuurder een auto kan reserveren of annuleren. De verschillende huisadressen hebben elk een eigen softwaresysteem voor het verwerken van berichten die door het centrale huisadres worden verstuurd, en het registreren van de gegevens in deze berichten in de lokale huisadres database. Het huisadres gebruikt dit softwaresysteem ook voor het samenstellen en versturen van berichten naar de verschillende bestuurders die wonen op dat huisadres. De bestuurders hebben elk een eigen softwaresysteem voor het verwerken van berichten die door het huisadres worden verstuurd, en het registreren van de gegevens in deze berichten in de lokale bestuurder database. 1. Systemen hebben geen kennis van de business logica van andere systemen Aan het einde van elke maand stuurt het centrale huisadres een rekening naar alle deelnemende huisadressen met het verzoek om de rekening te betalen. De huisadressen sturen een rekening naar de bestuurders die wonen op dat huisadres met het verzoek om elk hun deel te betalen. De situatie ziet er als volgt uit: Rekening bestuurder Bestuurder 21 Huisadres 2 Bestuurder 11 Rekening bestuurder Rekening huisadres Bestuurder 12 Rekening bestuurder Centrale huisadres Rekening huisadres Huisadres 1 Rekening bestuurder Rekening huisadres Bestuurder 13 Rekening bestuurder Huisadres 3 Bestuurder 31 Rekening bestuurder Bestuurder 32 In deze figuur is gekozen voor 3 huisadressen met elk een beperkt aantal bestuurders. Dit vanwege ruimte gebrek. Voor de strekking van het verhaal zijn de aantallen niet van belang.

4 De rekening die het centrale huisadres naar de verschillende huisadressen stuurt zou er als volgt uit kunnen zien: Op het eerste gezicht ziet het bericht er goed uit. Het bericht bevat het bedrag dat elke bestuurder moet betalen. Echter wat nu als de verschillende huisadressen het totaalbedrag per huisadres verschillend verdelen over de bestuurders die wonen op dat huisadres? Bij het ene huisadres betalen de bestuurders naar gebruik, en bij het andere huisadres naar draagkracht. Bij het bovenstaande bericht betekent dit dat het centrale huisadres van alle huisadressen de verdeelsleutel moet kennen. In de meeste complexe situatie heeft elk huisadres een andere verdeelsleutel. Een ander nadeel is de sterke afhankelijkheid: als een huisadres besluit om de eigen verdeelsleutel te wijzigen, dan moet de aanpassing bij het centrale huisadres gebeuren.

5 De bovenstaande nadelen zijn opgelost met het volgende bericht: Dit bericht bevat geen totaalbedrag per bestuurder. De verschillende huisadressen moeten dit zelf bedrag nu zelf berekenen. Omdat het bericht alle ritgegevens bevat zijn de huisadressen ook in staat om dit bedrag zelf te berekenen. Bij deze berekening kan een huisadres zijn eigen verdeelsleutel gebruiken. Het centrale huisadres stuurt slechts gegevens en heeft geen kennis van de verdeelsleutels van de verschillende huisadressen. Een ander voorbeeld is het controleren of een rijbewijs geldig is. Voordat een persoon zich in kan schrijven als bestuurder wordt gecontroleerd of de betreffende persoon een geldig rijbewijs heeft. Dit kan op meerdere manieren. Eén manier is opvragen van de rijbewijsgegevens bij de RDW door het centrale huisadres, waarna het centrale huisadres deze gegevens zelf gaat interpreteren. Een andere manier is om RDW te laten bepalen of een persoon een geldig rijbewijs heeft. Nadeel van de eerste manier is dat het centrale huisadres moet weten welke controles uitgevoerd moeten worden, en welke gegevens daarvoor nodig zijn. Een ander nadeel is de sterke afhankelijkheid. Als RDW besluit dat de controles aangepast moeten worden, dan moeten ook de controles die het huisadres gebruikt worden aangepast. Als RDW besluit dat er andere gegevens gebruikt moeten worden, dan moet het bericht dat RDW naar het centrale huisadres stuurt worden aangepast. Bij de tweede manier hoeft het centrale huisadres geen kennis te hebben welke controles en gegevens nodig zijn om de geldigheid van een rijbewijs te bepalen. Deze manier heeft dus ook de voorkeur.

6 2. Uitwisselen van (gewijzigde) gegevens tussen systemen Op de laatste dag van de maand stuurt het software systeem van het centrale huisadres een rooster naar de softwaresystemen van alle deelnemende huisadressen met daarop informatie over welk huisadres welke auto de komende maand tot zijn beschikking heeft. De situatie ziet er als volgt uit: Huisadres 1 Rooster huisadres Rooster huisadres Centrale huisadres Huisadres 2 Rooster huisadres Huisadres 3 Het Rooster ziet er als volgt uit: Het initiële rooster voor een nieuwe maand wordt op de volgende manier gevuld: - Elke bestuurder kan een abonnement nemen op een auto voor een aantal vaste uren per dag, week of maand; - Verder kan een bestuurder vooraf of gedurende de maand een auto eenmalig reserveren voor een aantal uren; - Ook kan een bestuurder een inschrijving (verkregen via abonnement of reservering) annuleren. Dit kan tot een dag van te voren.

7 Om optimaal gebruik te kunnen maken van beide (deel)auto s is afgesproken dat elke bestuurder mutaties door moet geven aan het centrale huisadres. Het centrale huisadres geeft alle mutaties aan het eind van de dag eenmalig door aan alle huisadressen. Het doorgeven van mutaties door het centrale huisadres aan de verschillende huisadressen kan via meerdere methodes. Elke methode vergt zijn eigen specifieke bericht. Hier zijn twee veel voorkomende methodes: 1. Het centrale huisadres stuurt een nieuw rooster waarin de mutaties zijn verwerkt; 2. Het centrale huisadres stuurt alleen mutaties. Tussen het centrale huisadres en de andere huisadressen moet vooraf afgesproken worden op welke manier mutaties worden doorgegeven. Bovenstaande methodes hebben elke hun eigen voor- en nadelen, en afhankelijk van de situatie moet in onderling overleg de juiste methode gekozen worden. Voor het centrale huisadres is het essentieel dat mutaties via één methode en één bericht naar alle andere huisadressen worden verstuurd. Anders moet het centrale huisadres beide methodes en twee berichten ondersteunen. Methode 1: Het centrale huisadres stuurt een nieuw rooster waarin de mutaties zijn verwerkt. De eerste methode is voor het centrale huisadres de makkelijkste methode. Het centrale huisadres hoeft niet bij te houden welke wijzigingen er zijn opgetreden sinds het versturen van het laatste rooster en kan op elke moment opnieuw het rooster samenstellen en versturen. Voor de ontvangende huisadressen is deze methode een stuk lastiger. Het is immers niet direct duidelijk wat er is gewijzigd ten opzichte van het vorige rooster. Vergelijken van het oude en nieuwe rooster kan zeer complex zijn, en het lezen van het oude rooster uit de lokale huisadresdatabase kost tijd en resources. Een alternatief is het oude rooster in zijn geheel verwijderen, en vervangen door het nieuwe rooster. Het verwijderen en toevoegen van veel database records kost echter ook veel tijd en resources. Als er weinig verschillen zijn tussen het oude en nieuwe rooster zijn veel van deze databasemutaties bovendien onnodig. Een variant is om alle huisadressen een seintje te geven dat een nieuw rooster beschikbaar is. Het huisadres kan dan zelf beslissen of en wanneer het nieuwe rooster wordt opgehaald. Een huisadres is in dit geval niet verplicht om alle nieuwe roosters te verwerken. Methode 2: Het centrale huisadres stuurt alleen de mutaties Voor het centrale huisadres is deze methode veel lastiger, het centrale huisadres moet bijhouden welke mutaties er zijn gebeurd sinds het versturen van het laatste rooster. Het succes van deze methode is afhankelijk van het correct verwerken door alle huisadressen van alle mutaties. In theorie zou dit geen problemen mogen opleveren, echter in de praktijk blijkt regelmatig dat administraties na verloop van tijd, ondanks alle goede afspraken, toch uit elkaar gaan lopen. Dit kan komen doordat berichten uitvallen, berichten kwijtraken of niet correct verwerkt worden. Hierdoor kunnen problemen optreden bij het verwerken van bijvoorbeeld een wijziging, als een huisadres een voorgaand roosteruur nooit als toevoeging heeft verwerkt. Voor deze methode is monitoren dat alle verstuurde berichten correct zijn verwerkt essentieel. Voor het ontvangende huisadres is deze methode makkelijker, het is immers direct duidelijk wat de mutaties zijn. Deze methode kent twee varianten: het centrale huisadres geeft per mutatie wel of niet aan of het gaat om een toevoeging, wijziging of verwijdering. In de laatste variant moeten huisadressen zelf bepalen of het gaat om een toevoeging of wijziging. Verder is het doorgeven van fysieke verwijderingen met de laatste variant niet mogelijk, omdat een niet opgenomen roosteruur betekent dat het roosteruur niet is gewijzigd.

8 3. Uitwisselen van (gewijzigde) gegevens in een keten van systemen Dit onderwerp is een uitbreiding van het voorgaande onderwerp. In dit onderwerp wordt het uitwisselen van gegevens in een keten beschreven. De situatie ziet er als volgt uit: Rooster bestuurder Bestuurder 11 Huisadres 1 Bestuurder 21 Reserveren of annuleren Rooster bestuurder Rooster huisadres Rooster bestuurder Bestuurder 22 Rooster huisadres Centrale huisadres Huisadres 2 Rooster bestuurder Reserveren of annuleren Rooster huisadres Bestuurder 23 Rooster bestuurder Huisadres 3 Bestuurder 31 Rooster bestuurder Bestuurder 32 Voor een huisadres is het ongewijzigd doorsturen van alle ontvangen berichten van het centrale systeem naar de bestuurders de makkelijkste oplossing. Dit kan alleen als afspraken over het ontvangen van wijzigingen tussen het centrale huisadres en huisadres enerzijds, en tussen huisadres en bestuurders anderzijds op elkaar zijn afgestemd. Dit is niet het geval in het volgende voorbeeld: het huisadres ontvangt bij een roosterwijziging het complete rooster van het centrale huisadres, terwijl de bestuurders alleen de roosterwijzigingen willen ontvangen. Het huisadres moet in dat geval de roosterwijzigingen bepalen door het vergelijken van het nieuwe rooster met het vorige rooster. Vergelijken is complex, betekent veel database acties, en kost veel tijd en resources. Bij het doorsturen van roosterwijzigingen moet het huisadres in het bovenstaande voorbeeld een keuze maken hoe sterk de koppeling mag zijn tussen het verwerken van het inkomende bericht Rooster huisadres en het samenstellen van het uitgaande bericht Rooster bestuurder. Een veel gebruikt architectuurprincipe zegt dat de database als ontkoppelpunt moet fungeren. Voordeel van dit principe is dat verwerken van inkomende berichten onafhankelijk is van het versturen van uitgaande berichten. Nadeel van dit principe is vaak een slechtere performance en meer resource gebruik. Toelichting: wijzigingen bepaald bij het verwerken van het inkomende bericht Rooster huisadres zouden én gebruikt kunnen worden om de lokale database van het huisadres aan te passen, én gebruikt kunnen worden om het uitgaande bericht Rooster bestuurder samen te stellen. Voordeel van deze oplossing is dat de wijzigingen maar een keer bepaald hoeven te worden. Nadeel is de sterke koppeling tussen verwerken van het inkomende bericht Rooster huisadres en het samenstellen van het uitgaande bericht Rooster bestuurder. Als het (inkomende) Rooster huisadres wijzigt kan dit impact hebben op het samenstellen van het (uitgaande) Rooster bestuurder. Een kleine, op het eerste gezicht snelle en goedkope functionele wijziging, kan door deze sterke koppeling een grote, langdurende en kostbare technische aanpassing betekenen. Dit is onwenselijk. Een andere mogelijkheid (conform het bovenstaande architectuur principe) is om bij het samenstellen van het (uitgaande) Rooster bestuurder de wijzigingen opnieuw te bepalen uitgaande van alleen de database gegevens.

9 4. Uitwisselen van (gewijzigde) gegevens afhankelijk van business rules Niet alle (gewijzigde) gegevens mogen en hoeven verstuurd te worden naar alle afnemende systemen. Een voorbeeld is de rekening die door het centrale huisadres wordt verstuurd naar een huisadres. Deze rekening bevat de boetes van alle bestuurders. Vanuit privacy overwegingen is het niet wenselijk dat de bestuurders van elkaar weten hoeveel boetes de ander moet betalen. Tussen het centrale huisadres, de huisadressen en de bestuurders moet afgesproken worden onder welke condities (gewijzigde) gegevens verstuurd mogen en moeten worden. Voor de rekening van de bestuurder geldt dat deze alleen boetes mag bevatten die de bestuurder zelf moet betalen. Een ander voorbeeld is als een roosterwijziging dezelfde dag door een andere roosterwijziging wordt teruggedraaid. Stel een bestuurder reserveert s ochtends een auto voor de volgende dag, wordt s middags gebeld voor een afspraak voor de volgende dag en besluit daarop de reservering voor de volgende dag te annuleren. Moet in dit geval het centrale huisadres aan het einde van de dag een nieuw rooster versturen? Voor de ontvangende huisadressen is er immers niets gewijzigd. Als afgesproken wordt om in dit geval geen rooster te versturen dan moet het centrale huisadres kijken of wijzigingen elkaar opheffen. Het is niet voldoende om te kijken of er records in de centrale database zijn met een later registratie tijdstip dan het tijdstip van versturen van het laatste rooster naar de verschillende huisadressen. Er zijn verschillende manieren om te bepalen of een wijziging een echte wijziging is. Eén manier is het vergelijken van versies van database records. Echter dit betekent het bijhouden van alle versies van een roosteruur. Bij veel gegevens in een bericht betekent dit het vergelijken van veel database records. Bepalen of een nieuw rooster verstuurd moet worden wordt in dat geval een langdurig proces en vergt veel resources. Een alternatief is om het nieuwe rooster gewoon samen te stellen, en dit nieuwe rooster te vergelijken met het vorige rooster. Alleen als deze roosters verschillen mag het nieuwe rooster verstuurd worden. Het eenmalig vergelijken van twee berichten (tekst strings) is veel eenvoudiger en sneller dan het vergelijken van versies van meerdere database records. Ook hoeft er geen mutatiehistorie van database records bijgehouden te worden. Voorwaarde voor deze oplossing is wel dat het laatst verstuurde rooster bewaard moet worden. Als het opslaan van het laatst verstuurde rooster teveel opslagruimte vergt is het gebruik van een digest (of hash) waarde een alternatief. Een digest waarde is een soort samenvatting. Het idee achter het gebruik van een digest waarde is dat twee verschillende roosters twee verschillende digest waardes hebben en dat het bewaren van een digest waarde weinig ruimte kost. Een veel gebruikt digest algoritme is MD5. Zie nl.wikipedia.org/wiki/hashfunctie voor meer informatie over digest (of hash) waarden. 5. Uitwisselen van gegevens (on)afhankelijk van de database structuur Een veel gebruikt architectuurprincipe is dat de structuur van een bericht onafhankelijk moet zijn van de structuur van de database waarin de gegevens zijn geregistreerd. Dit geldt zowel voor het systeem dat het bericht samenstelt en verstuurd, als het systeem dat het bericht ontvangt en verwerkt. Het idee is dat als de databasestructuur van een systeem wijzigt, dit geen gevolgen heeft voor de structuur van het bericht, en zeker geen gevolgen voor de databasestructuur van het andere systeem. Eventuele structuurwijzigingen moeten opgevangen worden in het samenstellen en verwerken van de berichten. Bij het samenstellen en verwerken van het bericht is de databasestructuur wel belangrijk. Bij het samenstellen en verwerken van een XML bericht moet een vertaling gemaakt worden tussen een relationele databasestructuur en hiërarchische XML structuur. De complexiteit en performance van deze vertaling wordt onder andere bepaald door de mate waarin de hiërarchische XML structuur en de relationele databasestructuur op elkaar aansluiten. Een hiërarchische structuur is een speciale relationele structuur. Namelijk elke entiteit heeft maximaal 1 ouder. Om van een relationele structuur een hiërarchische structuur te maken, moet van elke entiteit in de relationele structuur die onderdeel uit gaat maken van het bericht, het aantal ouder relaties teruggebracht worden tot maximaal 1 ouder relatie. De vraag is dus welke ouder relatie blijft, en wat gebeurt er met de andere ouder relaties.

10 Een voorbeeld is de berichtstructuur van de rekening: In het bovenstaande bericht is bij de vertaling van de relationele gegevensstructuur naar de hiërarchische berichtstructuur gekozen om AUTO onder RIT te hangen. In feite is de relationele structuur met daarin de entiteiten HUISADRES, BESTUURDER, RIT, AUTO en BOETE opgetild door de entiteit HUISADRES op te pakken met als resultaat de bovenstaande hiërarchische structuur met HUISADRES BESTUURDER RIT (AUTO, BOETE). In dit geval sluiten de relationele databasestructuur en de hiërarchische berichtstructuur goed op elkaar aan waardoor de vertaling relatief eenvoudig is.

11 In het volgende bericht sluiten de relationele gegevensstructuur en de hiërarchische berichtstructuur minder goed op elkaar aan, waardoor de vertaling relatief moeilijker zal zijn: De relatie in de hiërarchische berichtstructuur tussen HUISADRES en AUTO bestaat niet in de relationele gegevensstructuur, en de relatie tussen HUISADRES en BESTUURDER in de relationele gegevensstructuur komt niet voor in de hiërarchische berichtstructuur.

12 Een ander voorbeeld waaruit blijkt dat de structuur van de database belangrijk is bij het samenstellen en verwerken van een XML bericht is als volgt. Boetes komen binnen bij de eigenaar van de auto en het is dan niet direct duidelijk wie de bestuurder was van de auto op het moment dat de overtreding werd begaan. Voordat aan het einde van maand de rekeningen verstuurd kunnen worden moet de betreffende bestuurder achterhaald worden. De vraag is niet zo zeer de manier waarop dit gedaan kan worden (vergelijken van de datumovertreding van de boete met de rittijden), maar de vraag is wanneer dit gedaan wordt: bij vastleggen van de ontvangen boete of bij samenstellen van de rekening. In het bovenstaande gegevensstructuur hangt BOETE onder RIT. Bij binnenkomst van de boete wordt direct achterhaald en vastgelegd tijdens welke rit de overtreding is begaan. Bij samenstellen van de rekening is direct duidelijk welke bestuurder de overtreding heeft begaan. Voordeel van deze oplossing is dat achterhalen van de juiste RIT slechts eenmalig hoeft te gebeuren, en bij het samenstellen van de rekening steeds opnieuw gebruikt kan worden. Zeker als de performance bij samenstellen van de rekening belangrijker is dan de performance van het verwerken van de boete is dit een voordeel. Nadeel is dat bij intrekken van de boete door justitie (na beroep door de bestuurder) niet gelijk duidelijk is welke BOETE verwijderd moet worden. Immers BOETE hangt onder RIT en RIT is geen onderdeel van het bericht van justitie.

13 Een andere mogelijkheid is om BOETE onder AUTO te hangen. Bij binnenkomst van de boete wordt de boete geregistreerd, en bij samenstellen van de rekening wordt de juiste rit bepaald. Nadeel is dat bij opnieuw samenstellen van de rekening de bijbehorende RIT opnieuw bepaald moet worden. Voordeel is dat bij intrekken van de boete door justitie direct duidelijk is om welke BOETE het gaat. De gegevensstructuur ziet er als volgt uit: Opbouw artikel De bovenstaande vijf onderwerpen gingen over het uitwisselen van gegevens tussen systemen. De laatste drie onderwerpen gaan over welke eisen er gesteld worden aan de gegevens(structuur) van de lokale database van een systeem, opdat een systeem de juiste gegevens kan uitwisselen met andere systemen.

14 6. Uitwisselen van gegevens afhankelijk van de gewenste integriteit Wat als de ontvanger van een bericht de integriteit van de verstuurde gegevens wil controleren? Met integriteit wordt bedoeld dat de gegevens niet zijn gewijzigd na vastlegging. In het deelauto project wil een bestuurder kunnen controleren dat de ritgegevens die op de rekening staan niet zijn gewijzigd sinds het moment van vastleggen in de administratie van het centrale huisadres. Deze ritgegevens worden immers gebruikt om het te betalen bedrag te berekenen. Achteraf controleren kan door bij het vastleggen van de ritgegevens ook direct een digitale handtekening van de ritgegevens vast te leggen. In de volgende gegevens structuur is de tabel RIT uitgebreid met een digitale handtekening: Wat is een digitale handtekening? Bij vastleggen van de ritgegevens wordt een samenvatting, een digest, berekend van de ritgegevens. Vervolgens wordt deze digest versleuteld met de private (geheime) sleutel van de bestuurder, en het resultaat, een digitale handtekening, wordt samen met de ritgegevens vastgelegd. In het voorbeeld wordt bij elke RIT een bijbehorende digitale handtekening vastgelegd. In dit geval gaat het om de private sleutel van de bestuurder omdat de bestuurder achteraf wil kunnen controleren of de ritgegevens niet zijn gewijzigd. De bestuurder kan de integriteit van de ritgegevens in de rekening controleren door de digitale handtekening te ontcijferen met zijn eigen publieke sleutel. Het resultaat, een ontcijferde digest, kan de bestuurder vergelijken met de digest die de bestuurder zelf moet berekenen van de ontvangen ritgegevens. Als de ontcijferde digest gelijk is aan de zelf berekende digest heeft de bestuurder de garantie dat de ontvangen ritgegevens niet zijn gemanipuleerd na vastleggen van de gegevens in de administratie van het centrale huisadres.

15 Bovenstaande behoefte van de bestuurder om achteraf te kunnen verifiëren dat ritgegevens niet zijn gemanipuleerd, betekent wel dat alle ritgegevens die gebruikt zijn bij het berekenen van de digest waarde opgenomen moeten worden in de rekening. Anders is de bestuurder niet in staat om digest te berekenen, en dus ook niet om de integriteit van de ritgegevens te controleren. De rekening ziet er als volgt uit: 7. Mutatiehistorie van gegevens Als een bestuurder het niet eens is met een boete heeft hij of zij het recht om beroep aan te tekenen. Wat nu als het beroep wordt gehonoreerd, en de boete wordt ingetrokken? Als de boete fysiek verwijderd wordt uit de database van het centrale huisadres dan kan achteraf de vraag van een bestuurder niet beantwoord worden waarom een reeds verstuurde rekening een boete bevat. Als bij logisch verwijderen van de BOETE het tijdstip van verwijderen wordt vastgelegd dan kan voor elk moment in het verleden bepaald worden welke boetes voor welke bestuurder bekend waren in de database van het centrale huisadres. Een ander voorbeeld is als tussen het centrale huisadres en de verschillende huisadressen wordt afgesproken dat aan het einde van de dag alleen de mutaties worden opgestuurd (dus niet een compleet nieuw rooster), en dat voor een mutatie moet gelden dat er ook daadwerkelijk iets is gewijzigd. De situatie dat een bestuurder s ochtends een auto reserveert voor de volgende dag, en deze reservering s middags annuleert is geen mutatie gezien vanuit de verschillende huisadressen. Om te kunnen voldoen aan deze afspraak moet het centrale huisadres alle oude versies van alle ROOSTERUREN bijhouden, en bij het registreren van de gegevens moet het tijdstip van registratie worden vastgelegd. Bij verwijderen van gegevens moet bovendien het tijdstip van verwijderen worden gevuld. Bij samenstellen van het rooster aan het einde van de dag wordt eerst gekeken naar datumtijd registratie welke roosteruren zijn gewijzigd sinds het versturen van het vorige rooster, en daarna wordt gekeken of er sprake is van een echte wijziging door het vergelijken van de actuele versie van de gegevens met de versie op het tijdstip van verzenden van het vorige rooster. Dit hoeft niet de een na laatste versie te zijn, er kunnen immers meerdere mutaties hebben plaatsgevonden voor hetzelfde roosteruur.

16 Bij het ontwerpen van een gegevensstructuur van een (basis)administratie moet bepaald worden of mutatiehistorie noodzakelijk is om te kunnen voldoen aan de informatiebehoefte van de afnemers. Een methode voor het implementeren van mutatiehistorie is door gebruik te maken van aparte schaduwtabellen. De actuele gegevens bevinden zich in de hoofdtabel, en in de schaduwtabel bevinden zich alle versies (inclusief de actuele versie). In de volgende gegevensstructuur is voor BOETE, ROOSTERUUR en HUISADRES een schaduwtabel opgenomen met daarin een aantal extra attributen. De gegevens voor BESTUURDER, AUTO en RIT zullen niet wijzigen. Het idee is dat versies van hetzelfde gegeven hetzelfde ID hebben, dat ID + Datumtijd registratie de unieke sleutel is van de schaduwtabel, en als Datumtijd verwijderd gevuld is dit betekent dat het record is verwijderd op dat tijdstip. Voor een uitgebreide beschrijving en voor andere implementaties zie het artikel van Toon Loonen over mutatie historie in Database Magazine nummer 3 uit 1999, 8. Geldigheid van gegevens Een bestuurder kan via een website een auto reserveren. Binnen het project deelauto worden auto s elke vier jaar vervangen. Stel op 1 januari 2010 wordt een auto vervangen door een andere auto. Dit betekent dat de bestuurder deze auto voor gebruik na 1 januari 2010 niet meer kan reserveren. Afgesproken is dat bestuurders de nieuwe auto vanaf 1 december 2009 kunnen reserveren voor gebruik na 1 januari Om dit mogelijk te maken moet AUTO voorzien worden van een geldigheidsperiode. De tabel AUTO wordt daartoe uitgebreid met de velden Begindatum gebruik en Einddatum gebruik. Tijdens het reserveren van een auto moet dan gecontroleerd worden of het roosteruur binnen de geldigheidsperiode valt. Alleen als Datumtijd begin en Datumtijd eind van een ROOSTER beide vallen binnen Begindatum gebruik en Einddatum gebruik van een AUTO kan het ROOSTERUUR aangemaakt worden. Dezelfde eis geldt voor het maken van een RIT.

17 Nieuwe bestuurders en huisadressen kunnen zich aanmelden voor het project deelauto per direct of vanaf een bepaalde datum. Bestaande bestuurders en huisadressen (als het aantal deelnemende bestuurders nul is geworden) kunnen hun deelneming opzeggen met ingang van een bepaalde datum. Er geldt dat alleen huisadressen en bestuurders die zijn aangemeld een auto mogen reserveren of mogen gebruiken. Om dit mogelijk te maken moeten ook BESTUURDER en HUISADRES beide voorzien worden van een geldigheidsperiode wat betreft deelname. Het gaat om Begindatum deelname en Einddatum deelname. Het project deelauto bevat adresgegevens. Veel administraties hebben een koppeling met de Gemeentelijke basisadministratie voor persoonsgegevens (GBA) voor het leveren van persoons- en adresmutaties. Het GBA bevat het adresgegevens Datum aanvang adreshouding. Dit gegeven geeft aan wanneer een persoon op een bepaald adres is gaan wonen en dit gegeven is meestal niet gelijk aan de datum waarop het bericht van de GBA wordt ontvangen en/of verwerkt. Bij een verhuizing is de nieuwe bewoner verplicht om zich binnen vijf dagen na verhuizing in te laten schrijven bij de gemeente op het nieuwe adres. De gemeente stuurt dit gegeven door naar het GBA, waarna het GBA het weer doorstuurt naar alle afnemers van adresmutaties voor die persoon. Datum aanvang adreshouding kan als Begindatum adreshouding van een HUISADRES worden gebruikt. Bij het ontwerpen van de gegevensstructuur van een (basis)administratie moet bepaald worden of geldigheid van gegevens noodzakelijk is. In de volgende gegevensstructuur zijn de tabel BESTUURDER, AUTO en HUISADRES uitgebreid met een geldigheidsperiode.

18 Conclusie Als tijdens het ontwerpen van een (basis)administratie en het berichtenverkeer ten behoeve van het uitwisselen van gegevens met andere systemen rekening wordt gehouden met de onderwerpen uit dit artikel dan heeft dit grote voordelen voor de functionaliteit, complexiteit, onderhoudbaarheid, performance en resource gebruik van de systemen. Oplossen van performance problemen en gebrek aan hardware resources in productie, door het toepassen van noodgrepen in de code en het aanschaffen van dure hardware, kunnen op deze manier worden voorkomen. Literatuur Toon Loonen, Mutatiehistorie van gegevens, Database Magazine nummer 3 uit René van Leusen is als consultant werkzaam bij Capgemini. rene.van.leusen@capgemini.com Dit artikel verscheen in ingekorte en bewerkte vorm in Database Magazine