3 mei 2005
Het archiveren van databases is in de discussies over digitale archivering over het algemeen een redelijk vergeten hoofdstuk. Over het algemeen komen de opvattingen er op neer dat de database in zijn geheel moet worden bewaard ofwel in het oorspronkelijke format, inclusief het databasemanagement programma dat de database heeft gegenereerd ofwel als een ASCII-bestand met veldscheiding en een uitgebreide beschrijving van de organisatorische en technische context van de database. De Uitvoeringsregeling van artikel 12 van het Archiefbesluit 1995 is wat dat betreft zelfs zeer specifiek: ‘Het oorspronkelijke opslagformaat of ASCII (flatfile, met veldscheidingstekens), vergezeld van documentatie bij voorkeur in XML-DTD over de structuur van de database (tenminste omvattende een compleet logisch datamodel met beschrijving van entiteiten); queries dienen in de vraagtaal SQL (SQL2) te worden vastgelegd’. Buiten het feit dat niet is vastgelegd welke ASCII-variant gebruikt moet worden, wordt er hierbij vanuit gegaan dat de gehele database wordt gearchiveerd. De vraag is of dat wel een juiste veronderstelling is.
Geert-Jan van Bussel
De veronderstelling dat de gehele database bewaard wordt is correct daar waar het gaat om databases die voor één specifiek belang worden aangelegd, zoals bijvoorbeeld een klimaat-database van het KNMI, een wetenschappelijke database met tectonische gegevens e.d. én vanwege een selectiebeslissing voor bewaring zijn aangemerkt. Databases die gevuld worden met gegevens die alle lange tijd van belang zijn of benodigd zijn vanwege de historische data die ze bevatten. Zolang ze gebruikt worden is er niets aan de hand; pas op het moment dat de database niet langer meer gebruikt wordt voor de uitvoering van een specifiek proces, maar waarbij de gegevens wel van belang blijven voor onderzoek of verantwoorde voorspellingen, ontstaan de problemen. In dat geval dient een oplossing gevonden te worden voor het bewaren van de gehele database. Een oplossing daarvoor is nog niet beschikbaar, al zijn er binnen de XML-ontwikkelwereld oplossingen in de maak die de archivering van gehele databases mogelijk moeten gaan maken. Het bewaren van een database in ASCII-format is een zeer twijfelachtige oplossing, maar op dit moment nog een van de weinige te operationaliseren mogelijkheden. Bedenk hierbij wel dat de ASCII-variant van groot belang is: niet alle ASCII-varianten zijn in staat bijvoorbeel Slavische, Cyrillische of Arabische tekens weer te geven.
In de meeste gevallen echter is het bewaren van een totale database niet nodig en niet gewenst. De database is immers niets meer dan een container, waarin data zijn opgeslagen die betrekking hebben op de input, throughput en output van bedrijfsprocessen. In iedere organisatie worden databases aangemaakt binnen database management programma’s, zoals Oracle, DB2 en Progress, op basis van wensen vanuit bedrijfsprocessen. Zo heeft een bouwvergunningenproces een specifieke database, bestemd voor de afhandeling van alle gegevens zoals die binnen dat proces voorkomen. Dat geldt vervolgens ook voor een milieuvergunningenproces, een uitkeringsproces, een subsidieproces e.d. In die databases worden gegevens vastgelegd betreffende de transacties die binnen die processen worden uitgevoerd. Iedere bouw- of milieuvergunning, iedere afzonderlijke transactie dus, heeft een eigen set aan bij elkaar horende gegevens. Elk van die sets gegevens worden in de database vastgelegd. Die database bevat dus honderden, meestal duizenden verschillende sets van gegevens, voor iedere afgegeven bouw- en milieuvergunning. Honderden c.q. duizenden transacties dus.
Al die sets van gegevens worden op een bepaalde manier op het scherm getoond, zodanig dat de gebruiker op de meest effectieve wijze de gegevens krijgt gepresenteerd en in staat is zo snel mogelijk de gewenste informatie er aan te onttrekken. Bij al die transacties die via sets van gerelateerde gegevens in de database zijn opgenomen behoren ook nog allerlei andere informatieobjecten, zoals papieren of gedigitaliseerde documenten of tekeningen, foto’s of wellicht zelfs geluids- of video-opnamen. De documenten komen in een dossier, de geluids- en video-opnamen worden in een audio-visueel bestand vastgelegd. Om een beeld van de afgehandelde transactie te verwerven is het nodig om alle gegevens inzake die transactie bij elkaar te krijgen in een case- (zaak-) dossier. Ook om rechtmatigheid te kunnen aantonen is het van belang dat alle gegevens die bij elkaar horen ook als een eenheid kunnen worden geraadpleegd. Op zich hoeven ze niet bij elkaar te worden bewaard: het is voldoende als voor iedere transactie alle benodigde informatie bij elkaar kan worden gebracht. Er dient dus bekend te zijn waar voor iedere transactie de daarbij behorende gegevens vastgelegd of opgeslagen zijn.
In dat laatste zit veelal het grootste probleem; iedere transactie moet reconstrueerbaar zijn. Dat impliceert dat alle informatie van belang voor de betreffende transactie op ieder gewenst moment ter beschikking zal moeten zijn. Voor het papieren dossier, een geluidsband of een videoband is dat over het algemeen geen probleem, mits bekend is bij welke transactie het betreffende materiaal een rol gespeeld heeft. Voor wat betreft de sets van gegevens in de database is het echter een ander verhaal.
Vanouds bestaat binnen de informatica een geduchte weerstand tegen het meer dan eenmaal opslaan van een gegeven. Dat heeft te maken met het feit dat lange tijd opslagcapaciteit heel erg duur was. Die situatie bestaat niet meer, maar de mentaliteit van één keer opslaan is gebleven. Derhalve wordt heel vaak niet zozeer het gegeven zelf opgenomen in een database als wel een verwijzing naar dat gegeven (of die set gegevens) in een andere database. Gegevens worden vaak immers veel meer dan één keer gebruikt.
Blijven we bijvoorbeeld bij de bouwvergunningendatabase. Gegevens die daarin altijd worden opgenomen zijn de NAW-gegevens. Alleen: deze gegevens worden niet ingevoerd, maar de NAW-velden worden gevuld met de meest actuele gegevens vanuit het GBA, de Gemeentelijke Basis Administratie. Daartoe zijn er links, pointers, gelegd tussen de NAW-velden in de bouwvergunningendatabase en die in het GBA. Op zich is er helemaal niet mis met het gebruiken van pointers. Het is de enige manier om uniformiteit binnen gegevens te waarborgen; het is maar al te goed bekend wat er gebeurt als NAW-gegevens in drie- of vier verschillende databases moeten worden veranderd. Dat gebeurt over het algemeen wel, maar toch gaat er daarbij heel veel mis. Pointers maken het mogelijk een gegeven maar één keer op te slaan, maar het veelvuldig te gebruiken. Maar pointers hebben ook nadelen: als de centrale database, in het genoemde voorbeeld het GBA, gewijzigd wordt, zullen die wijzigingen zich ook presenteren in de databases die door middel van pointers aan die centrale database zijn gekoppeld. Immers, in een database die pointers heeft naar de NAW-velden van het GBA, worden de gegevens vertoond zoals die in het GBA zijn vastgelegd. Of dat nu wel of niet gewenst is. Want in alle gegevenssets vertonen zich de nieuwe gegevens, ook in de historische transacties die zich hebben voorgedaan. Een pointer houdt immers geen rekening met de dynamiek van de tijd: overal waar de pointer naar verwijst worden de gegevens getoond in de meest actuele vorm. De reconstructie van transacties wordt dan een moeilijke zaak. Ook als door middel van audit trails wordt vastgelegd dat gegevens worden veranderd, dan gebeurt dat enkel in de database die wordt gemuteerd, het GBA dus in het genoemde voorbeeld. In alle andere databases zien we de meest actuele gegevens. Uiteraard kan bij de reconstructie van iedere transactie wel teruggegrepen worden op de audit trails van de gemuteerde database, maar erg effectief is dat niet. Het komt in ieder geval dan de snelheid van de raadpleging van de juiste gegevens niet ten goede. Deze problematiek wordt door de uitspraken in de Uitvoeringsregeling van het Archiefbesluit 1995 niet opgelost.
Een ander verschijnsel binnen de database-ontwikkeling is de zich zelf actualiserende database. Deze ontwikkeling borduurt voort op de pointer, alleen wordt bij deze databases niet volstaan met een verwijzing, maar worden de opgenomen data via de pointer zelf gewijzigd als de moederdatabase aangepast wordt. Hier zijn dus de gegevens fysiek in iedere database aanwezig en worden ze automatisch gewijzigd als ook de moederdatabase wordt aangepast. Blijven we bij de bouwvergunningendatabase. Bij een zichzelf actualiserende database worden op het moment dat de moederdatabase, in dit geval het GBA, zich wijzigt, de bestaande gegevens vervangen door de meest actuele. Dat betekent dat het bestand van de bouwvergunningendatabase door middel van een automatisch proces wordt vervangen als de gegevens niet meer in overeenstemming zijn met de gegevens zoals die in de moederdatabase zijn opgenomen. Wat in het geval van historische transacties altijd het geval is. Maar ook hier: een zichzelf actualiserende database kent in principe niet de dynamiek van de tijd. Uiteraard: ook hier kunnen audit trails een redmiddel zijn, maar het was beter als gegevens in afgehandelde transacties helemaal niet worden veranderd.
Net zoals bij de pointer zijn de historische transacties hier het slachtoffer van het gedrag van het database managementprogramma. Vaak is het gedrag van een database het argument om de database in zijn totaliteit te bewaren. Maar het is niet de database die ‘gedrag’ vertoont (het is enkel een container van gegevens en gegevenssets), maar het programma waarin de database wordt aangemaakt. De gegevensset zelf, vastgelegd in wat wij het ‘record’ noemen, vertoont geen ‘gedrag’. Als het gedrag een belangrijke reden is voor het bewaren van de gehele database, dan dient dat in het oorspronkelijke opslagformaat te gebeuren met behoud van het oorspronkelijke databaseprogramma. Ook bij omzetting naar ASCII immers gaat het ‘gedrag’ verloren.
Het zal duidelijk zijn dat het volledig bewaren van een database in de geschetste gevallen weinig zin heeft. Zonder GBA is een bouwvergunningendatabase volstrekt betekenisloos, omdat de gekoppelde velden niet gevuld zijn. Een zichzelf actualiserende database is altijd actueel, niet historisch. Het bewaren van de database leidt daar tot het bewaren van de laatst bestaande versie. In bedrijfsprocessen, waarbij rechtmatigheid van handelen een belangrijk aspect is (zoals bij een bouw- of een milieuvergunning), gaat het helemaal niet om die database zelf. Het gaat in dat soort processen over de afhandeling van transacties (zaken, cases, of hoe men ze ook noemen wil). Maar als het niet om de database zelf gaat wordt de vraag hoe de gegevens in procesdatabases te archiveren van essentieel belang. Wat we eigenlijk willen archiveren zijn de gegevenssets zoals die bij de afzonderlijke transacties zijn gegenereerd. Let wel: de gegevens zoals ze waren op het moment dat de transactie werd afgehandeld. Dat impliceert dat op het moment dat de transactie is afgehandeld de gegevens zoals ze zijn bewerkt en gegenereerd moeten blijven zoals ze zich tijdens die transactie hebben gepresenteerd.
Als dat de insteek is, dan blijven er voor de archivering daarvan twee mogelijkheden over:
1. Het vastleggen van de onmuteerbare transactiegegevens in een historische transactiedatabase. De database zal de gegevens als een historische set van gegevens moeten vastleggen, met daarbij een expliciete vermelding van de transactie waarin zij zijn gegenereerd en een aanduiding naar de andere informatieobjecten die in de transactie een rol hebben gespeeld. Op zich hoeft dat niet onmogelijk te zijn, maar het betekent dat iedere procesdatabase een historische variant krijgt, waarin onmuteerbare gegevenssets zijn opgenomen en waarin dezelfde gegevens veelvuldig in verschillende transacties kunnen voorkomen. Deze historische databases worden vervolgens gedurende de bewaartermijn bewaard. Deze oplossing leidt dus tot het bewaren van vele historische transactiedatabases, waarin het in principe slechts handelt om de representatie van de transactiegegevens op de momenten dat transacties moeten worden gereconstrueerd. Deze databases kunnen zelfs in ASCII worden bewaard, mits voorzien van de juiste contextinformatie. De dynamische muteerbare database blijft ongemoeid; ze is niet van belang voor archiveringsdoeleinden, enkel voor het uitvoeren van het bedrijfsproces. Alle data gebruikt in een transactie (dus ook de NAW-gegevens) worden na afhandeling van een transactie telkens vastgelegd in een onmuteerbare gegevensset, die niet langer in de dynamische, maar in de historische database wordt opgenomen.
2. Het verwijderen van de afgehandelde gegevenssets uit de database. Dit klinkt heel radicaal, maar de bedoeling hiervan is dat de gegenereerde gegevenssets in de gespecificeerde presentatievorm van het record uit de database worden gehaald en geplaatst in een XML-formulier. Dat formulier wordt vervolgens in een onmuteerbare vorm opgenomen in een transactiedossier, waarin ook alle andere digitale documenten gegenereerd in de specifieke transactie worden opgenomen. De papieren documenten die in de transactie zijn gegenereerd worden gedigitaliseerd, net als audio- en videobestanden. De procedure op basis waarvan deze digitalisering plaatsvindt dient geborgd te worden en geauthentiseerd. Analoge objecten die authentiseringskenmerken dragen, zoals handtekeningen, dienen te worden bewaard onder hetzelfde identificatiecriterium als het transactiedossier. De database is op dit moment geen object van archivering meer: de gegevenssets zijn uit de database gehaald en als specifieke digitale documenten in XML-format in digitale dossiers opgenomen. Reconstructie van de transactie kan door het transactiedossier, voorzien van voldoende contextinformatie (zoals bijvoorbeeld de gebruikte procesbeschrijving), te raadplegen.
Archivering van databases is een complex onderwerp. Beide oplossingen zijn mogelijk; geen van beide oplossingen wordt op dit moment in de praktijk gebruikt. De auteur heeft geen voorkeur voor wat betreft de gebruikte oplossing. Gezien de omvang van de transacties vastgelegd in databases lijkt het tijd te worden onderzoek te doen naar deze beide mogelijkheden. De reconstructie van de rechtmatigheid van handelen zou anders wel eens zwaar onder druk komen te staan.
