Temporele Database (kort)

Inleiding

Een temporele database in de breedste zin van het woord is een database die een tijdsaspect bevat bij het organiseren van informatie. Ondanks de complexiteit van zulk systeem zijn ze vaak onmisbaar voor bijvoorbeeld verzekeringsmaatschappijen, reservatiesystemen, of in bedrijven.

Het tijdsaspect kan je op drie manieren toevoegen: ‘valid time’, ‘transaction time’ en tenslotte ‘bitemporal data’ .

‘Valid time’ wil zeggen dat de geassocieerde tijdsperiode verwijst naar een tijdsperiode die zich in de echte wereld afspeelt. ‘Transaction time’ verwijst naar de tijd dat de informatie opgeslaan werd in het systeem. De laatste vorm tenslotte ‘bitemporal data’ is een combinatie van de twee voorgaande.

Tijd

Voordat ik dieper op de drie verschillende types inga zal ik eerst wat informatie geven over het gebruik van tijd zelf in databases.

Voor databases is het aspect tijd een opeenvolging van punten met een interval gespecificeerd door de applicatie. Anders gezegd, als het systeem nooit vereist dat de nauwkeurigheid beter is dan ййn uur, dan zal men uur als interval gebruiken. In de realiteit is een uur echter geen punt maar een duur die nog verder onderverdeeld kan worden in minuten en seconden. Daarom gebruikt men in databases een van de fysici geleende term: chronon .

Valid time Relations

Om dit type te gebruiken moeten we twee kolommen aan ons database model toevoegen, namelijk VST (Valid Start Time) en VET (Valid End Time). Hun datatype is vaak ‘Date’ . Ik zal dit verder uitleggen aan de hand van een voorbeeld.

Naam Werknemersnummer Loon VST VET

Janssen 34523 2000 31-01-2003 now

Peeters 43343 1600 01-01-2003 31-12-2004

Peeters 43343 2000 01-01-2005 now

Debruyne 53424 1800 31-01-2003 31-12-2004

Debruyne 53424 2200 01-01-2005 12-11-2005

Wat misschien het meest opvalt is het gebruik van ‘now’. ‘now’ Is een temporele variabele die aanduidt dat het huidige tijdstip bezig is. Een niet-temporele database zou enkel de tuples weergeven waarvan VET ‘now’ is.

Wanneer men in dit type ййn of meerdere attributen wil wijzigen, dan maakt men een nieuwe versie en sluit men de oude versie in plaats van oude data te overschrijven. In dit voorbeeld zijn de lonen van Peeters en Debruyne aangepast. In valid time relations moet men meestal zelf een updatedatum ingeven (in plaats van het tijdstip van aanpassen te gebruiken). Indien men een wijziging doorvoert in een database voor het echt gebeurd dan noemt men dit een ‘proactive update’, indien men de aanpassing pas na de gebeurtenis uitvoert noemt men het ‘retroactive update’. Ten slotte indien men de aanpassing simultaan met de gebeurtenis doorvoert, dan spreekt men van ‘simultaneous update’ .

Wanneer in het voorbeeld een werknemer zijn ontslag zou geven, dan zou men die werknemer in een conventionele database verwijderen. In een ‘valid time’ database sluit men enkel de huidige versie in plaats van deze te verwijderen. Dit is het geval met Debruyne die op 12 november 2005 het bedrijf verlaten heeft.

Indien men een nieuwe werknemer aan zou nemen, dan gebeurd dit identiek als in een niet temporele database, met het verschil dat men bij valid time een VST opgeeft en het VET op ‘now’ zet. In het voorbeeld is dit het geval met Janssen die in dienst genomen is op 31 januari 2003.

Merk ook op dat in dit model het Werknemersnummer niet volstaat als primaire sleutel aangezien deze niet meer uniek is. De combinatie van Werkenmersnummer en VST is daarom een goede oplossing. Hierbij moet men wel opletten dat er geen meerdere wijzigingen per werknemer doorgevoerd worden binnen de chronon (hier dag).

Transaction time relations

Ook bij dit type voegen we twee kolommen toe aan het database model. Namelijk TST (Transaction Start Time) en TET (Transaction End Time). Vaak is hun datatype ‘timestamp’ . Als we het voorgaande voorbeeld hernemen zou dit er zo uit kunnen zien:

Naam Werknemersnummer Loon TST TET

Janssen 34523 2000 31-01-2003, 10:23:56 uc

Peeters 43343 1600 01-01-2003 09:32:34 28-12-2004 15:46:59

Peeters 43343 2000 28-12-2004 15:46:59 uc

Debruyne 53424 1800 31-01-2003 10:27:03 28-12-2004 19:43:33

Debruyne 53424 2200 28-12-2004 19:43:33 12-11-2005 14:33:21

De