Johan Eikelboom (architect VX Company) over transactieverwerkende systemen

Er is behoefte aan het vastleggen van tijdgebonden gegevens in een database. Spoorboekjes, arbeidshistorie, medische achtergronden… Een waterdicht systeem hiervoor moet nog gebouwd worden. Kennelijk. Want gegevens in de tijd verzamelen leidt tot zoveel complexiteit, dat het ontwikkelen van een dergelijk systeem vooralsnog gedoemd is te mislukken. Niet verwonderlijk, stelt Johan Eikelboom. Johan is werkzaam als software architect bij VX Company en gespecialiseerd in bedrijfskritische transactieverwerkende systemen. In verschillende grootschalige projecten is hij het temporale dataprobleem tegengekomen. In onderstaand artikel vertelt hij waarom databases eigenlijk niet ingericht zijn om historische gegevens vast te leggen.

Het vadertje tijd anti-pattern

Temporale data als risicofactor voor uw project

In Nederland zijn veel systemen die met temporale dataproblemen worstelen. Ik weet niet of het u ook opgevallen is, maar de relationele databases waar we dagelijks mee werken hebben daarvoor geen voorzieningen. Een geboortedatum opslaan is geen probleem, maar werken met tijdlijnen kunnen ze blijkbaar niet. Veel projecten komen hierdoor soms ongemerkt in de problemen doordat er extra complexiteit in sluipt.

Bitemporale data

Een voorbeeld. Jan werkt op de afdeling testen als senior tester sinds 2003. Dat is een gegeven dat in principe makkelijk op te slaan is in een relationele database. Als we echter niet alleen de huidige situatie willen vastleggen maar ook de historie, dan zijn er twee mogelijkheden:

Geldige tijd; van wanneer tot wanneer is dit het geval geweest?
Transactietijd; van wanneer tot wanneer is dit gegeven in de database opgeslagen?

Het is mogelijk om alleen geldige tijd of alleen transactietijd op te nemen, maar doe je het beide dan spreken we van bitemporale data.

Het systeem heeft van 1 januari 2006 tot 10 maart 2006 (de transactietijd) geregistreerd dat Jan op de afdeling expeditie gewerkt heeft als junior tester van 2003 tot en met 2005 (de geldige tijd). Daarna is dit gecorrigeerd, omdat het de afdeling Testen betrof en de functie senior tester. Excuses, Jan. Als we de hele loopbaan van Jan in ogenschouw nemen dan krijgen we een tijdslijn. De volgende tabel is een voorbeeld van tijdslijn met alleen een geldige tijd dimensie. De transactietijden laten we hierbij even buiten beschouwing.

We Love IT uitgave 5 - VX Company - transactieverwerkende systemen figuur-1

Geldige tijd dimensie in het relationele model

Het probleem doet zich nu voor hoe we dit in de tabellen van onze relationele databases kunnen opslaan. We lopen tegen diverse moeilijkheden aan.

Normaliseren van de tijdlijnen.
Aansluitende of overlappende intervallen willen we samengenomen hebben.
Primaire sleutels met intervallen.
Twee overlappende intervallen zijn ongelijk. Een klassieke primaire sleutel zal twee records met overlappende intervallen accepteren en tegenspraak of redundantie toelaten.
Verwijssleutels met intervallen.
Hoe moeten we gegevens combineren in de tijd als de intervallen uit de pas lopen.
Redundantie door verschillend verloop in de tijd.
Er is in bovenstaande tabel twee maal opgeslagen dat het de afdeling Testen betreft, evenzo met de functie senior tester.

Dit laatste kunnen we vermijden door de tabel te splitsen.

We Love IT uitgave 5 - VX Company - transactieverwerkende systemen figuur-2

Chris Date toont in zijn boek [1] aan dat dit alles niet het geval zou zijn geweest als we in plaats van intervallen alles per jaar op zouden slaan. Dit noemt hij ‘unpacked formaat’. Als we voor ieder jaar een rij moeten opslaan, dan wordt de tabel nogal groot. En met datum is het natuurlijk nog veel erger. Maar de primaire sleutel en verwijssleutels ‘doen’ het weer. En met een join kunnen de twee tabelletjes weer gecombineerd worden waardoor we keurig de eerste tabel weer terug krijgen. We kunnen dit zien als een normalisatie van de zesde normaalvorm [1]. Ja, u leest het goed, ik heb ook altijd gedacht dat er maar vijf waren. Zo maakt Date een uitbreiding op het relationele model voor efficiënte verwerking van temporale gegevens.

“Waar blijven al die miljoenen?”

Tja, als ik dat wist dan zat ik hier natuurlijk niet een artikel te schrijven. Werkt u toevallig op de rekenkamer, dan vraagt u zich misschien ook af waar al miljoenen blijven in al die geflopte ICT-projecten. Dan heeft u hier een stuk van de puzzel: het Vadertje Tijd anti-pattern.

We kijken hoe het zit met de functiepunten. We hadden vier kolommen: naam, functie, afdeling en vanaf. Nu hebben we een interval (eigenlijk twee kolommen) , dus we gaan naar vijf. Dat zou misschien anderhalf keer zoveel functiepunten kunnen opleveren. Ik weet het niet precies, maar ik denk dat het veel te ruim genomen is.

In het eerste geval zou een overplaatsing van Jan met een enkel update statement geprogrammeerd kunnen worden door iedere beginnende SQL programmeur. Een mutatie in de tijdlijn is we een ander verhaal. In het boek van Richard SnodGrass [2] kunnen we allerlei voorbeelden vinden van hoe je deze zaken in SQL kunt uitprogrammeren. Een update met terugwerkende kracht waarbij we alle intervallen bijknippen of eventueel aan elkaar plakken kost 12 tot 14 SQL statements. En dat lukt niet in 12 tot 14 keer zoveel tijd door een junior programmeur. Want dit is ingewikkeld. Als deze problematiek niet wordt onderkend, dan wordt deze tijdlogica vermengd met de business logica. Iedere bugfix levert nieuwe bugs op in deze complexiteit. En er was maar één veldje bijgekomen.

Het is makkelijk als we dit fenomeen voortaan expliciet benoemen. De naam Vadertje Tijd anti-pattern lijkt me geschikt hiervoor. Binnen met name watervalprojecten wil men deze problemen meestal liever niet onder ogen zien. Er is weerstand tegen ‘generieke’ oplossingen. En och, die offshoring is zo goedkoop. En men heeft zo’n prachtige ESB architectuur. Voorbeelden genoeg te vinden op het nationale ICT projecten kerkhof.

Oplossingsrichtingen

De standaard temporale logica moet ondergebracht worden in aparte componenten om hier uit te komen. De beste oplossing zou zijn, dat de database vendors voorzieningen inbouwen voor temporale data. In het verleden zijn er al voorstellen geweest voor standaarden. Tot bruikbare resultaten heeft dit nog niet geleid. We zijn ook nog maar 30 jaar bezig met relationele technologie.

Maar goed, tot deze heugelijke dag verschijnt moeten projecten dus zelf maar oplossingen zoeken. Als Java adept heb ik wel eens een paar klassen gebouwd voor terugwerkende kracht mutaties en temporale joins.Een lagenmodel gesplitst in nontemporaal, geldige tijd en transactie tijd kan helpen. SQL kent maar beperkte abstractie mogelijkheden, maar werken met views is een optie. Code generatie met MDA hulpmiddelen is ook iets wat beter binnen bereik komt.

Een probleem in dit veld is dat theorie en praktijk ver uit elkaar liggen, en de pragmatische tussenweg nog ontbreekt. Chris Date heeft met zijn boek [1]mijn interesse gewekt voor dit onderwerp, en geeft een heel goed denkkader hoe je het moet zien in het relationele model, maar staat ver af van huidige producten. Het boek van Snodgrass [2] geeft ook een goede basis en terminologie, en veel praktische voorbeelden.

Conclusie

Hopelijk kan dit artikel bijdragen aan een stukje bewustwording van deze problematiek. Er is al vaker over gepubliceerd. Snodgrass [2] schrijft in de preface dat de ene datum de andere niet is. Een geboortedatum werkt altijd meteen en met andere data komt er geen einde aan de problemen. Een zinnetje waar blijkbaar overheen gelezen wordt. Dus als u in deze problemen zit en het nu herkent, dan is de doelstelling van dit artikel al bereikt. In ieder geval hoop ik dat uw project niet voortijdig te maken krijgt met vadertje tijd.

Reageren op dit artikel?

Mail naar: temporaldata(at)vxcompany.com
Johan Eikelboom, VX Company

Referenties

[1] Chris Date, Hugh Darwen, Nikos Lorenzos
data & the relational model.

[2] Richard T. Snodgrass,
Developping time oriented database applications in SQL.
http://www.cs.arizona.edu/~rts/publications.html

[3] Martin Fowler
http://martinfowler.com/ap2/timeNarrative.html

Lees meer over VX Company

Ga terug naar We Love IT uitgave 5 - 2008

Advertentie