Bitemporele toestandsprojecties bijwerken
Dit hoofdstuk is een verdere uitwerking van het onderwerp in de handreiking. We gaan in dit hoofdstuk in op het bijwerken van bitemporele toestand-projecties. Bitemporaliteit is complex, en zoals ook in een eerder hoofdstuk uitgelegd is daar best wat voor nodig in projecties. Zeker in grotere projecten met veel verschillende typen gevolgen en veel data kan zowel het bijwerken van een bitemporele projectiestore als het bevragen van een dergelijke store erg moeilijk worden. Om de complexiteit van bitemporaliteit beheersbaar te houden introduceren we hier standaarden voor het type operaties die uitgevoerd worden bij het bijwerken van een bitemporele toestandsprojectie.
In de handreiking zijn de uitdagingen van het bouwen van projecties reeds uitgebreid beschreven. Ook komt daar onderstaande plaat terug:
In dit hoofdstuk focussen we ons op de linkerkant: de standaardoperaties. Eerder hebben we al gevolg-archetypen beschreven. Deze archetypen hebben elk een eigen operatie bij het bijwerken van een projectie. Bij het bijwerken van een projectie wordt de aard van een gevolg gecombineerd met het doel van de projectie.
Het toevoegen van een nieuwe toestand aan de projectiestore kan op verschillende manieren, en is afhankelijk van de situatie:
- Bestaat de entiteit al of is deze nieuw in de store?
- Wordt er een nieuw geldigheidsmoment toegevoegd aan de store, of wordt een bestaand geldigheidsmoment bovenschreven?
- Wordt er bij de bovenschrijving foute informatie hersteld of niet?
Mutaties in detail
In de basis kent de projectiestore drie typen operaties:
Deze worden hieronder in detail uitgelegd.
Openen: Create
Het initiële, identiteitgevende projectie-element:
Deze flow wordt gebruikt bij de create operatie.
Bijwerken: Append & Amend
Een nieuwe projectie op basis van een gevolg dat werkt op het voorgaande projectie:
Deze flow wordt gebruikt bij de append en amend operaties.
De append betreft een 'reguliere' mutatie: bij de append wordt een nieuw moment op een nieuw geldigheidstijdstip toegevoegd aan de projectiestore:
Het bestaande projectie-element waar de het nieuwe element op gebaseerd is wordt weergegeven in lichtgroen.
Bij amend was de reeds bestaande projectie op zich niet fout, maar wordt er (achteraf) informatie toegevoegd (of verwijderd). Bij deze operatie dient de reeds bestaande toestand als uitgangspunt genomen te worden. Hiermee bovenschrijven we de eerdere toestand op hetzelfde geldigheidstijdstip.
Bijstellen: Correctie
Als we moeten bijstellen is gebleken dat eerder vastgelegde informatie fout is, en gecorrigeerd moet worden. Op de eerste plaats dient deze correctie in de gevolgen gecorrigeerd te worden, zodat we in de projectie de beschikking hebben over de onderschreven gevolgen.
In een toestandsprojectie kunnen fouten doorwerken: Als een persoon op een foutief adres ingeschreven is, waarbij vervolgens deze persoon trouwt, ouder wordt en scheidt, zal, als het woonadres getoond wordt, op elk van de projectie-elementen het adres foutief getoond worden. Bij het corrigeren van toestandsprojecties is het dus niet voldoende om enkel het projectie-element dat als directe consequentie van het foutieve gevolg geproduceerd is te herstellen.
Bij correctie zullen alle projectie-elementen opnieuw aangemaakt moeten worden vanaf het moment dat de onderschreven gevolgen afwijken van de oorspronkelijke gevolgen, waarbij we erop moeten letten dat we ons bij het produceren van een nieuw element niet baseren op een eerder element dat niet meer onderschreven is. Hierbij moeten we nieuwe projectie-elementen baseren op Hiermee bovenschrijven we foutieve projectie-elementen.
Overzicht
| Operatie | Functie | Betekenis |
|---|---|---|
| Open | create | Eerste punt van een nieuwe entiteit — altijd linksonder in de grafiek |
| Bijwerken | append | Nieuw tijdvak aan het einde van de geldigheidstijdlijn — altijd rechtsboven |
| amend | Bovenschrijft een projectie met als bron de oorspronkelijke toestand | |
| Bijstellen | correct | Bovenschrijft een projectie met als bron de voorgaande toestand |
De operaties als contract
We hebben gezien in het hoofdstuk over gevolg archetypen dat gevolgen bepaalde archetypen invullen, die beschrijft wat hun rol is op op tijdlijnen. We hebben nu ook gezien dat deze rol invullen in een projectie neerkomt op (in ieder geval) vier standaardoperaties: create, append, amend en correct. Deze operaties kan je zien als een contract, of interface. Bij (bitemporele) toestandsprojecties over tijd dien je aan dit contract te voldoen. Hoe die
toestanden worden opgeslagen, is de zaak van de specifieke projectie-implementatie, zoals bitemporele tabellen of het snapshot-mechanisme.
Wat de vier operaties doen
Als we in meer detail kijken naar de vier verschillende operaties wordt het verschil tussen de operaties duidelijk. T staat voor het geldigheidstijdstip (projectiespecifiek bepaald, zoals beschreven in het relevante hoofdstuk over tijdstippen, G voor gevolg, en V voor de voorgaande state.
| Operatie | Waar T vandaan komt | Waar V vandaan komt |
|---|---|---|
create(G, T) | Het gevolg levert het geldigheidstijdstip: de projectie-implementatie bepaalt welk tijdstip in het gevolg dat is | - |
append(G, T, V) | Het gevolg levert het geldigheidstijdstip: de projectie-implementatie bepaalt welk tijdstip in het gevolg dat is | De voorgaande state |
amend(G, V) | Geen argument: De nieuwe state krijgt hetzelfde geldigheidstijdstip als zijn voorganger | De voorgaande state |
correct(G, T, V) | het eerste moment waarop de onderschreven gevolgen afwijken van wat vastgelegd was | De laatste nog steeds onderschreven state. |
append en amend nemen een voorgaande state en passen er hetzelfde soort gevolg op toe. Ze verschillen op 1 punt:
appendproduceert een nieuwe toestand met een nieuw tijdstip: het eigenTvan het gevolg.amendproduceert een nieuwe toestand met hetzelfde tijdstip als zijn voorganger.
Amend heeft als operatie geen geldigheidstijdstip als argument, en dat maakt een amend een amend: Het nieuwe tijdstip T is geen ontbrekende parameter – er bestaat geen geldigheidstijdstip voor een amend.