bitemporalitet -...
TRANSCRIPT
1
Bitemporalitet Proof of concept
Versionshistorik
Version Dato Hvem Hvad er ændret
0.9 3. sept 2014 Heidi Vanparys (GST) Flemming Nissen (GST)
Første udkast. Kommentarer fra KL indarbejdet undervejs.
0.10 9. sept 2014 Heidi Vanparys (GST) Erik Helweg-Larsen (KL)
Indarbejdet kommentarer og rettelser fra DOS-området i GST. Tilføjet afsnit Distribuerede objekter med bitemporale egenskaber og Performance og bitemporale egenskaber.
1.0 15. sept 2014 Flemming Nissen (GST) Heidi Vanparys (GST) Niels Kjær (GST)
Viderebehandling af kommentarer og revideret afsluttende afsnit.
1.1 17. sept. 2014 Flemming Nissen (GST) Opstramning af showcase beskrivelse.
1.2 19. sept. 2014 Thorben Brigsted Hansen (GST)
Opdatering af showcase beskrivelse.
2
Indholdsfortegnelse 1. Resumé ..................................................................................................................................... 3
2. Indledning .................................................................................................................................. 3
3. Begreber i bitemporalitets- og forvaltningsdomænet .................................................................. 3
4. Matriklen .................................................................................................................................... 5
4.1 Informationsmodeller & fysiske datamodeller ...................................................................... 8
4.2 Informationsmodel 1: Bitemporale objekter ......................................................................... 9
4.2.1 Fysisk datamodel 1a: Bitemporal tabel ...................................................................... 10
4.2.2 Fysisk datamodel 1b: Separat tabel for registrerings- og virkningstid ......................... 18
4.2.3 Fysisk datamodel 1c: Tabel med aktuelle data + bitemporal tabel ............................. 18
4.2.4 Fysisk datamodel 1d: Totallager + historiklager ......................................................... 19
4.2.5 Bitemporalitet og egenskaber .................................................................................... 19
4.2.6 Overførsel af data fra produktion til udstilling ............................................................. 19
4.3 Informationsmodel 2: Bitemporalitet på et udvalg af egenskaber ...................................... 19
5. Distribuerede objekter med bitemporale egenskaber ............................................................... 20
6. Performance og bitemporale egenskaber ................................................................................ 21
7. Anbefalinger ............................................................................................................................ 21
8. Referencer ............................................................................................................................... 22
3
1. Resumé
Denne rapport beskriver en række problemstillinger omkring historik og bitemporalitet, som er
relevante i forhold til at distribuere data med høj aktualitet og med en datahistorik der giver
sporbarhed i de foretagne registreringer.
Sporbarhed er den egenskab et offentligt forvaltningsgrundlag skal kunne understøtte. Sporbarhed
indebærer at kunne fremfinde og dokumentere det datamæssige forvaltningsgrundlag som har
været brugt if. med en konkret sagsbehandling.
Der tages udgangspunkt i teorien for implementering af historik i relationsdatabaser ved definitionen
af begreber og valg af termer.
Dokumentet anvender en konstrueret matrikulær udstykning som showcase til at forklare
egenskaber og konsekvenser ved modellering af bitemporale egenskaber.
Arbejdet har resulteret i en videnopbygning omkring brugen af historik, den nødvendige
tidsmærkning og en mere stringent måde at definere registreringstid og virkningstid på. Dette er
vigtigt hvis data skal kunne sammenstilles på tværs af datasæt og dermed danne grundlag for en
bedre og mere effektiv brug af de offentlige grunddata.
Der udsondres en række anbefalinger til grunddataprogrammets Modelregler 1.1, som kan bruges
til at kvalificere bitemporalitet som begreb, implementering af historik som funktionalitet og de
brugsscenarier, hvori historik forekommer.
Konklusionen på analysen viser at GST, KL og grunddataprogrammet indikerer et løsningsrum for
historik, som er nødvendig og tilstrækkelig.
2. Indledning
Dette dokument er opbygget som følgende;
Definition af begreber
Benyttelse af bitemporalitet med et konstrueret eksempel
Eksempler på (database) implementeringer
Anbefalinger
Som senere beskrevet er 2 sæt af tidsstempler nok til datamæssigt at kunne spore en given
datamæssig situation. Men den fornødne funktionalitet og hyppighed der er brug for af historik,
medfører at historikfunktionalitet kan implementeres på forskellige niveauer. Her er driftsafviklingen
styrende for den fysiske implementering af historikanvendelsen.
Men bitemporalitet er kun en tidsmæssig attributtering af et objekt. Det er ofte nødvendigt at have
andre egenskaber til at holde oplysninger om status og aktør, men indholdet vil sædvanligvis være
stærkt forretningsområdeafhængige.
De to ovenstående nævnte egenskaber er ikke behandlet i dette proof of concept.
Som det fremgår af rapporten er bitemporalitet kun enkel side af den historiske anvendelse, der kan
gøres af data. Fremtidens forskere vil utvivlsomt få glæde af den digitale udvikling.
4
3. Begreber i bitemporalitets- og forvaltningsdomænet
Nedenstående begrebsliste omfatter begreber relateret til bitemporalitet (også betegnet
dobbelthistorik) og forvaltningsobjekter.
1. begivenhed
noget der sker eller finder sted, især noget vigtigt eller bemærkelsesværdigt
[DDO]
2. bitemporal
vedrørende både registreringstid og virkningstid
NOTE: tider såsom fx observationstid kan også være relevante, men ”bi” i bitemporal
refererer til registreringstid og virkningstid [Glossary]
3. egenskab
side af et forvaltningsobjekts udseende, væsen eller måde at virke eller fungere på
NOTE: Definitionen er tilpasset fra [DDO].
4. forvaltningsobjekt
forvaltningens repræsentation af det konkrete - fysisk eller konceptuelt - eksisterende objekt,
som der udøves myndighed på og som der derfor opsamles data om
[Modelregler]
5. registreringstid
synonymer: transaction time [Glossary], record time [Fowler]
tiden, hvor et forvaltningsobjekts egenskaber var kendt i et bestemt system
NOTE 1: Når et forvaltningsobjekts egenskaber flyttes til et andet system, så får man to
registreringstider [Jensen1].
NOTE 2: Der kan være tale om såvel et forvaltnings- som et distributionssystem.
6. tilstand
mængden af egenskaber som karakteriserer et forvaltningsobjekt i en afgrænset del af
tiden
NOTE 1: Når man betragter bitemporale forvaltningsobjekter, skal tiden afgrænses både
mht. registreringstid og mht. virkningstid.
NOTE 2: Et forvaltningsobjekt ændrer tilstand pga. begivenheder som berører dette objekt.
NOTE 3: Tilstand som defineret her er ikke det samme som status, som angiver, hvor et
forvaltningsobjekt er i sin livscyklus [Modelregler].
NOTE 4: tilstand er et ”reserveret ord” i KL og har en anden betydning i den sammenhæng
7. version
bestemt tilstand af et forvaltningsobjekt
8. virkningstid
synonymer: juridisk tid, valid time [Glossary], actual time [Fowler]
tiden, hvor et forvaltningsobjekts egenskaber svarer til forholdet i den modellerede
virkelighed
NOTE: Definitionen er tilpasset fra [Glossary].
Registreringstid og virkningstid er to forskellige dimensioner af tid, som kan bruges uafhængigt af
hinanden, eller i kombination.
5
Ved at inkludere virkningstid i en model, kan man svare på de følgende spørgsmål1:
● Hvilken tilstand er gældende (lige nu)?
● Hvilken tilstand var gældende på et givet tidspunkt i fortiden?
● Hvilken tilstand vil være gældende på et givet tidspunkt i fremtiden?
Ved at inkludere registreringstid i en model, kan man svare på de følgende spørgsmål:
● Hvad ved man om et forvaltningsobjekt (lige nu)?
● Hvad vidste/troede man om et forvaltningsobjekt på et givet tidspunkt i fortiden?
Ved at inkludere både virkningstid og registreringstid i en model, kan man svare på spørgsmål som:
● Hvilken tilstand er gældende (lige nu) (som kendt nu)?
● Hvilken tilstand var gældende på et givet tidspunkt i fortiden (som kendt nu)?
● Hvilken tilstand vil være gældende på et givet tidspunkt i fremtiden (som kendt nu)?
● På et givet tidspunkt i fortiden, hvilken tilstand troede man ville være gældende lige nu?
● På et givet tidspunkt i fortiden, hvilken tilstand troede man var gældende på et andet
tidspunkt i fortiden?
● På et givet tidspunkt i fortiden, hvilken tilstand troede man ville være gældende på et
tidspunkt i fremtiden?
4. Matriklen
Fast ejendom er en del af grunddataprogrammet, se Figur 1. Jordstykke er et af begreberne
defineret i dette felt, se Figur 2. Et jordstykke er et opmålt areal på jordoverfladen, som er afgrænset
af matrikelskel. Et jordstykke har bl.a. et jordstykke-ID, som er en entydig forretningsnøgle, og en
matrikelbetegnelse. En matrikelbetegnelse består af matrikelnummer (tal plus litra) og ejerlav
(landsejerlavsnummer) [Ejendom Målarkitektur].
1 Tekst i parentes kan udelades: når der ikke er givet en specifik tid, så betragtes det som ”nu”.
6
Figur 1: Den offentlige sektors grunddata [Grunddata].
Figur 2: Begrebsoverblik over fast ejendom [Ejendom Målarkitektur].
7
En proces som kan berøre et jordstykke er fx en udstykning af dette jordstykke, som er en matriku-
lær forandring, som er en del af hovedprocessen Ejendomsdannelse [Ejendom Målarkitektur].
For at illustrere brugen af virkningstid og registreringstid bruges det følgende eksempel2, illustreret i
Figur 3:
1. En sag, som omfatter en udstykning med jordstykkeajourføringer, godkendes og registreres
d. 18. februar 2014 kl 13:41:05 med virkning fra d. 13. februar 2014.
2. Kort efter sagen er godkendt, konstateres en fejl, der medfører, at de ændringer, der blev
gennemført i første omgang, må annulleres (aldrig har haft virkning) og en tilrettet sag med
ændrede jordstykkeajourføringer godkendes og registreres d. 6. marts 2014 kl. 10:07:12
med virkning fra d. 1. marts 2014.
Figur 3: Illustration af eksemplet.
2 Det valgte eksempel er et tænkt eksempel, der ikke nødvendigvis illustrerer en forretningsmæssig relevant
use case. Eksemplet skal udelukkende illustrere brugen af virkningstid og registreringstid.
8
I denne proces er det vigtigt, at
● vise, at vi i dag ved, at de sagsdata vedr. jordstykkeajourføringer, som ved en fejl blev
godkendt i starten, aldrig har været gældende.
● gemme oplysninger omkring processen beskrevet ovenfor, som dokumentation for det, der
skete.
4.1 Informationsmodeller & fysiske datamodeller
Bitemporalitet kan diskuteres på forskellige niveauer, se Figur 4. Det konceptuelle niveau er
beskrevet i afsnit 0, Som det fremgår af rapporten er bitemporalitet kun enkel side af den historiske
anvendelse, der kan gøres af data. Fremtidens forskere vil utvivlsomt få glæde af den digitale
udvikling.
9
Begreber i bitemporalitets- og forvaltningsdomænet ovenfor, og det antages, at
forretningsobjekterne og deres relationer er kendt.
Figur 4: De forskellige niveauer hvorpå man kan diskutere bitemporalitet (tilpasset fra [Arkitekturreolen]).
Der er forskellige muligheder for at modellere virkningstid og registreringstid i en
informationsmodel3, og for hver informationsmodel eksisterer der forskellige muligheder for en fysisk
datamodel. I dette dokument antages der, at data gemmes i en relationsdatabase.
Figur 5: Fra konceptuel model til informationsmodeller til fysiske datamodeller.
4.2 Informationsmodel 1: Bitemporale objekter
Denne model er tilstandsbaseret4 og bruges, når man er mest interesseret i, hvilken tilstand et
objekt har på et bestemt tidspunkt. I denne model får et objekt både et virkningstidsinterval og et
registreringstidsinterval. Da de fleste databaser ikke har en indbygget datatype, som repræsenterer
et interval, skal intervaller implementeres vha. af to tidspunkter. Dette resulterer i to sæt tidspunkter:
3 Også kaldt logisk datamodel.
4 Engelsk: state-based, se også [MTRD].
10
● registreringFra og registreringTil, hvor registreringTil er ukendt for aktuel viden
● virkningFra og virkningTil, hvor virkningTil kan være ukendt for nugældende data og data
gældende i fremtiden
Figur 6: Informationsmodel for en bitemporal objekt. Et alternativ kunne være, at have en datatype Tidsinterval, og have to attributter, registreringstidsinterval og virkningstidsinterval, som har denne datatype som type.
Denne model kan implementeres på forskellige måder i en database, som beskrevet i de næste
afsnit. Bemærk, at der kan være endnu flere måder end beskrevet her.
Konventionerne i eksemplet:
● fra-datoen er inklusiv og til-datoen er eksklusiv (se [Snodgrass] og [DB2] omkring
argumenter for og imod inklusiv vs. eksklusiv), dvs. at intervallet er lukket-åbent. Dette er
også måden tidsperioder er defineret i SQL:2011 standarden [SQL2011].
● virkningTil for en nugældende række er NULL (og ikke fx 9999-12-31) (se [Snodgrass]
omkring argumenter for og imod NULL vs. en dato langt i fremtiden)
● registreringTil for en række som repræsenterer aktuel viden er NULL, se ovenfor
● granulariteten for registreringstid er 1 sekund
● granulariteten for virkningstid er 1 dag
4.2.1 Fysisk datamodel 1a: Bitemporal tabel
I denne model er der én bitemporal tabel per objekttype.
Modifikationer
[Snodgrass]5 beskriver hvordan man modificerer bitemporale tabeller. Den grundlæggende regel er,
at kun to slags ændringer er tilladt i en bitemporal tabel:
● registrering: oprettelse af en ny række med en registreringFra som er tidspunktet for
oprettelsen og en registreringTil som er NULL
● afregistrering = logisk sletning: opdatering af en eksisterende række hvor registreringTil
ændres fra NULL til tidspunktet af opdateringen
Rapportteamet har ikke undersøgt konsekvenser af fejlagtige registreringstidsstempler og rapporten
tager derfor ikke stilling til den problematik.
5 Snodgrass betragtes som én af de førende kapaciteter på området og citeres ofte. Udgangspunktet for
SQL:2011 standarden er arbejde af blandt andre ham, Jensen og Nicola, der også refereres her. I en hjemlig kontekst har Snodgrass’ bog fx været benyttet af Kombit i forbindelse med et proof-of-concept omkring CPR.
11
I nedestående tabeller beskrives forløbet for matrikeleksemplet.
JORDSTYKKEID MATRIKELNR GEOMETRI VIRKNINGFRA VIRKNINGTIL REGISTRERINGFRA REGISTRERINGTIL
100010001 123
1970-01-01 NULL 1970-01-01 00:00:00 NULL
Tabel 1: Databasetabellen JORDSTYKKE som den ser ud før udstykningen.
Rækken i Tabel 1 betyder, at forvaltningen lige nu ved (REGISTRERINGTIL er null), og siden d. 1.
januar 1970 midnat (REGISTRERINGFRA = 1970-01-01 00:00:00) har vidst, at der findes et jordstykke
med jordstykke-ID 100010001, matrikelnummer 123 og geometri , som er nugældende
(VIRKNINGTIL er NULL) og har været gældende siden d. 1. januar 1970 (VIRKNINGFRA = 1970-01-01).
JORDSTYKKEID MATRIKELNR GEOMETRI VIRKNINGFRA VIRKNINGTIL REGISTRERINGFRA REGISTRERINGTIL
100010001 123
1970-01-01 NULL 1970-01-01 00:00:00 2014-02-18 13:41:05
100010001 123
1970-01-01 2014-02-13 2014-02-18 13:41:05 NULL
100010001 123
2014-02-13 NULL 2014-02-18 13:41:05 NULL
100010002 456
2014-02-13 NULL 2014-02-18 13:41:05 NULL
Tabel 2: Databasetabellen JORDSTYKKE som den ser ud efter første godkendelse i GST, d. 18. februar 2014 kl. 13:41:05.
Den anden række i Tabel 2 betyder, at forvaltningen lige nu (REGISTRERINGTIL er NULL) ved, og
siden d. 18. februar 2014 kl. 13:41:05 (REGISTRERINGFRA = 2014-02-18 13:41:05) har vidst, at der
engang fandtes et jordstykke med jordstykke-ID 100010001, matrikelnummer 123 og geometri
, som var gældende fra d. 1. januar 1970 til d. 13. februar 2014 (eksklusiv, dvs. ikke til og
med d. 13. februar).
Den første række i Tabel 2 betyder, at forvaltningen fra d. 1. januar 1970 kl. 00:00:00 til d. 18.
februar 2014 kl. 13:41:05 vidste, at der fandtes et jordstykke med jordstykke-ID 100010001,
matrikelnummer 123 og geometri som var gældende (VIRKNINGTIL er NULL) og havde
været gældende siden d. 1. januar 1970 (VIRKNINGFRA = 1970-01-01).
Den tredje og fjerde række i Tabel 2 skal læses på samme måde som rækken i Tabel 1.
12
JORDSTYKKEID MATRIKELNR GEOMETRI VIRKNINGFRA VIRKNINGTIL REGISTRERINGFRA REGISTRERINGTIL
100010001 123
1970-01-01 NULL 1970-01-01 00:00:00 2014-02-18 13:41:05
100010001 123
1970-01-01 2014-02-13 2014-02-18 13:41:05 2014-03-06 10:07:12
100010001 123
2014-02-13 NULL 2014-02-18 13:41:05 2014-03-06 10:07:12
100010002 456
2014-02-13 NULL 2014-02-18 13:41:05 2014-03-06 10:07:12
100010001 123
1970-01-01 2014-03-01 2014-03-06 10:07:12 NULL
100010001 123
2014-03-01 NULL 2014-03-06 10:07:12 NULL
100010002 456
2014-03-01 NULL 2014-03-06 10:07:12 NULL
Tabel 3: Databasetabellen JORDSTYKKE som den ser ud efter anden godkendelse i GST, d. 6. marts 2014 kl.10:07:12.
Den anden række i Tabel 3 betyder, at forvaltningen fra d. 18. februar 2014 kl. 13:41:05 til d. 6.
marts 2014 kl. 10:07:12 troede, at der engang fandtes et jordstykke med jordstykke-ID 100010001,
matrikelnummer 123 og geometri , som var gældende fra d. 1. januar 1970 til d. 13. februar
2014.
Den tredje række i Tabel 3 betyder, at forvaltningen fra d. 18. februar 2014 kl. 13:41:05 til d. 6.
marts 2014 kl. 10:07:12 troede, at der fandtes et jordstykke jordstykke-ID 100010001,
matrikelnummer 123 og geometri som var gældende og havde været gældende siden d. 13.
februar 2014. Den fjerde række skal læses på samme måde.
Den femte række i Tabel 3 betyder, at forvaltningen lige nu ved, og siden d. 6. marts 2014 kl.
10:07:12 har vidst, at der engang fandtes et jordstykke med jordstykke-ID 100010001,
matrikelnummer 123 og geometri , som var gældende fra d. 1. januar 1970 til d. 13. februar
2014.
Den sjette række i Tabel 3 betyder, at forvaltningen lige nu ved, og siden d. 6. marts 2014 kl.
10:07:12 har vidst, at der findes et jordstykke med jordstykke-ID 100010001, matrikelnummer 123
og geometri, som er og har været gældende siden d. 1. marts 2014. Den syvende række skal læses
på samme måde.
Oplysningerne i Tabel 3 kan visualiseres i tidsdiagrammer, hvor registreringstid vises på x-aksen og
virkningstid på y-aksen, som gjort i Figur 7 for jordstykket med matrikelnummer 123.
13
Figur 7: Tidsdiagrammet for jordstykket med matrikelnummer 123.
Forespørgsler
Resultatet af forespørgslen “Giv den nugældende tilstand af jordstykket med matrikelnummer 123
(som kendt lige nu)” er vist i Tabel 4 og illustreret i Figur 8.
JORDSTYKKEID MATRIKELNR GEOMETRI VIRKNINGFRA VIRKNINGTIL REGISTRERINGFRA REGISTRERINGTIL
100010001 123
1970-01-01 NULL 1970-01-01 00:00:00 2014-02-18 13:41:05
100010001 123
1970-01-01 2014-02-13 2014-02-18 13:41:05 2014-03-06 10:07:12
100010001 123
2014-02-13 NULL 2014-02-18 13:41:05 2014-03-06 10:07:12
100010002 456
2014-02-13 NULL 2014-02-18 13:41:05 2014-03-06 10:07:12
100010001 123
1970-01-01 2014-03-01 2014-03-06 10:07:12 NULL
100010001 123
2014-03-01 NULL 2014-03-06 10:07:12 NULL
100010002 456
2014-03-01 NULL 2014-03-06 10:07:12 NULL
Tabel 4: Nugældende tilstand af jordstykket med matrikelnummer 123 (vist i grønt).
Alle følgende betingelser skal nemlig være opfyldt:
● REGISTRERINGTIL er NULL (som kendt lige nu)
● VIRKNINGFRA <= dagens dato (nugældende tilstand)
14
● dagens dato < VIRKNINGTIL eller VIRKNINGTIL er NULL (nugældende tilstand)
● matrikelnummeret er 123
Figur 8: Nugældende tilstand af jordstykket med matrikelnummer 123 (vist i grønt), vist på tidsdiagrammet.
Resultatet af forespørgslen “Giv (virknings)historikken af jordstykket med matrikelnummer 123 som
kendt d. 20. februar 2014 kl. 14:00:00” er vist i Tabel 5 og illustreret i Figur 9.
JORDSTYKKEID MATRIKELNR GEOMETRI VIRKNINGFRA VIRKNINGTIL REGISTRERINGFRA REGISTRERINGTIL
100010001 123
1970-01-01 NULL 1970-01-01 00:00:00 2014-02-18 13:41:05
100010001 123
1970-01-01 2014-02-13 2014-02-18 13:41:05 2014-03-06 10:07:12
100010001 123
2014-02-13 NULL 2014-02-18 13:41:05 2014-03-06 10:07:12
100010002 456
2014-02-13 NULL 2014-02-18 13:41:05 2014-03-06 10:07:12
100010001 123
1970-01-01 2014-03-01 2014-03-06 10:07:12 NULL
100010001 123
2014-03-01 NULL 2014-03-06 10:07:12 NULL
100010002 456
2014-03-01 NULL 2014-03-06 10:07:12 NULL
Tabel 5: Virkningshistorikken af jordstykket med matrikelnummer 123 som kendt d. 20. februar 2014 kl. 14:00:00.
Alle følgende betingelser skal nemlig være opfyldt:
● REGISTRERINGFRA <= 2014-02-20 14:00:00 (som kendt d. 20. februar 2014 kl. 14:00:00)
15
● 2014-02-20 14:00:00 < REGISTRERINGTIL eller REGISTRERINGTIL er NULL (som kendt d. 20.
februar 2014 kl. 14:00:00)
● matrikelnummeret er 123
Figur 9: Illustration af virkningshistorikken af jordstykket med matrikelnummer 123 som kendt d. 20. februar 2014 kl. 14:00:00.
Resultatet af forespørgslen “Hvornår blev der registreret oplysninger omkring tilstanden af
jordstykket med matrikelnummer 123 som var gældende d. 20. februar 2014?” er vist i Tabel 6 og
illustreret i Figur 10.
16
JORDSTYKKEID MATRIKELNR GEOMETRI VIRKNINGFRA VIRKNINGTIL REGISTRERINGFRA REGISTRERINGTIL
100010001 123
1970-01-01 NULL 1970-01-01 00:00:00 2014-02-18 13:41:05
100010001 123
1970-01-01 2014-02-13 2014-02-18 13:41:05 2014-03-06 10:07:12
100010001 123
2014-02-13 NULL 2014-02-18 13:41:05 2014-03-06 10:07:12
100010002 456
2014-02-13 NULL 2014-02-18 13:41:05 2014-03-06 10:07:12
100010001 123
1970-01-01 2014-03-01 2014-03-06 10:07:12 NULL
100010001 123
2014-03-01 NULL 2014-03-06 10:07:12 NULL
100010002 456
2014-03-01 NULL 2014-03-06 10:07:12 NULL
Tabel 6: Resultat af forespørgslen "Hvornår blev der registreret oplysninger omkring den tilstand af jordstykket med matrikelnummer 123 som var gældende d. 20. februar 2014?"
Alle følgende betingelser skal nemlig være opfyldt:
● VIRKNINGFRA <= 2014-02-20 (som var gældende d. 20. februar 2014)
● 2014-02-20 < VIRKNINGTIL eller VIRKNINGTIL er NULL
● matrikelnummeret er 123
Så svaret er, at der blev registreret oplysninger, d. 1. januar 1970 kl. 00:00:00, d. 18. februar kl.
13:41:05 og d. 6. marts kl. 10:07:12.
17
Figur 10: Illustration af forespørgslen "Hvornår blev der registreret oplysninger omkring den tilstand af jordstykket med matrikelnummer 123 som var gældende d. 20. februar 2014?"
Med de oplysninger som ligger i Tabel 3, kan man rekonstruere de ændringer objekter har
gennemgået. Man kan fx beregne forskellen mellem geometrien af jordstykket med matrikelnummer
123 før og efter udstykningen som kendt lige nu på basis af resultatet af forespørgslen “Giv
tilstandene af jordstykket med matrikelnummer 123 lige før udstykningen og lige nu (som kendt lige
nu)”, vist i Tabel 7 og illustreret i Figur 11.
JORDSTYKKEID MATRIKELNR GEOMETRI VIRKNINGFRA VIRKNINGTIL REGISTRERINGFRA REGISTRERINGTIL
100010001 123
1970-01-01 NULL 1970-01-01 00:00:00 2014-02-18 13:41:05
100010001 123
1970-01-01 2014-02-13 2014-02-18 13:41:05 2014-03-06 10:07:12
100010001 123
2014-02-13 NULL 2014-02-18 13:41:05 2014-03-06 10:07:12
100010002 456
2014-02-13 NULL 2014-02-18 13:41:05 2014-03-06 10:07:12
100010001 123
1970-01-01 2014-03-01 2014-03-06 10:07:12 NULL
100010001 123
2014-03-01 NULL 2014-03-06 10:07:12 NULL
100010002 456
2014-03-01 NULL 2014-03-06 10:07:12 NULL
Tabel 7: Resultatet af forespørgslen "Giv tilstandene af jordstykket med matrikelnummer 123 lige før udstykningen og lige nu".
18
Ved hjælp af en spatial beregning kan man så aflede, at forskellen er .6
Figur 11: Illustration af forespørgslen "Giv tilstandene af jordstykket med matrikelnummer 123 lige før udstykningen og lige nu".
4.2.2 Fysisk datamodel 1b: Separat tabel for registrerings- og virkningstid
En variant på en bitemporal tabel er, at man lægger VIRKNINGFRA, VIRKNINGTIL, REGISTRERINGFRA og
REGISTRERINGTIL i en separat tabel.
4.2.3 Fysisk datamodel 1c: Tabel med aktuelle data + bitemporal tabel7
En databaseimplementering med én bitemporal tabel kan kræve en fuld gennemgang af denne
tabel når spørgsmålet “Hvad er de nugældende egenskaber af et forvaltningsobjekt som
forvaltningen kender dem lige nu?” skal besvares, og dette nedsætter svartiderne. Hvis denne type
forespørgsel er fremherskende, kan det derfor være en fordel at have to tabeller: en snapshot-tabel
som viser den nuværende tilstand mht. både registrerings- og virkningstid, og en bitemporal tabel.
Data i disse tabeller kan så distribueres via to forskellige tjenester, som GST har tænkt at gøre.
6 I dette eksempel kunne man selvfølgelig bare med det samme tage geometrien fra 456, men når et
jordstykke er blevet udstykket til 3 eller flere jordstykker, skal der alligevel spatiale beregninger til.
7 Beskrevet som VT Current/TT Current + Bitemporal State I [Snodgrass]
19
4.2.4 Fysisk datamodel 1d: Totallager + historiklager8
Totallageret indeholder alle dagældende, nugældende og evt. fremtidig gældende egenskaber af
objekter, som kendt lige nu. Historiklageret er en såkaldt tracking log [Snodgrass] som indeholder
alle tidligere modifikationer. Denne implementering kan med fordel bruges når der forventes
hyppige forespørgsler omkring tidligere gældende egenskaber.
4.2.5 Bitemporalitet og egenskaber
Når man arbejder med bitemporale tabeller, så har man bitemporalitet på alle egenskaber af et
forretningsobjekt, da der laves en ny række i databasen så snart en af egenskaberne ændrer sig.
Det kan introducere en form for redundans i databasen, for egenskaber som ændrer sig på
forskellige tidspunkter gentages i flere rækker. Et alternativ er, at give hver eneste egenskab et
separat tidsinterval (se også afsnit Informationsmodel 2: Bitemporalitet på et udvalg af egenskaber),
men denne metode giver ulemper på andre punkter [Jensen2].
4.2.6 Overførsel af data fra produktion til udstilling
Jo mere datamodellen i en produktionsdatabase ligner datamodellen i den tilhørende
udstillingsdatabase, jo mindre kompleks bliver overførslen af data fra produktionsdatabasen til
udstillingsdatabasen. Det vil sige, at, hvis produktionsdatabasen bruger bitemporale tabeller, så er
det en fordel at bruge bitemporale tabeller også i udstillingsdatabasen, og dermed vælge
“bitemporale objekter” som informationsmodel.
4.3 Informationsmodel 2: Bitemporalitet på et udvalg af egenskaber
Figur 12: Bitemporalitet på et udvalg af egenskaber.
Hvis forretningen vurderer, at kun nogle egenskaber af et forretningsobjekt skal kunne spores i tiden
via bitemporalitet, så kan man anvende bitemporalitet på disse egenskaber i stedet for på selve
forretningsobjektet, se Figur 12. Man kan introducere en UML-klasse for hver egenskab, eller man
kan gruppere egenskaber, så hver gruppe får de samme tidsstempler.
Bemærk, at eksemplet her er fiktivt, da matrikelnummeret faktisk kan ændre sig, og disse ændringer
skal kunne spores.
8 Beskrevet som VT State/TT Current + State/State Archive og VT State/TT Current + State/Event Archive i
[Snodgrass]
20
I Tabel 8 og Tabel 9 vises hvordan en databaseimplementering kunne se ud. Ligesom i afsnit 4.2,
Informationsmodel 1: Bitemporale objekter, så kan man implementere varianter af den viste
implementering, fx en tabel med aktuelle data og en bitemporal tabel for oplysningerne omkring
geometri.
JORDSTYKKEID MATRIKELNR
100010001 123
100010002 456
Tabel 8: Tabel JORDSTYKKE, uden bitemporalitet.
JORDSTYKKEID GEOMETRI VIRKNINGFRA VIRKNINGTIL REGISTRERINGFRA REGISTRERINGTIL
100010001
1970-01-01 NULL 1970-01-01 00:00:00 2014-02-18 13:41:05
100010001
1970-01-01 2014-02-13 2014-02-18 13:41:05 2014-03-06 10:07:12
100010001
2014-02-13 NULL 2014-02-18 13:41:05 2014-03-06 10:07:12
100010002
2014-02-13 NULL 2014-02-18 13:41:05 2014-03-06 10:07:12
100010001
1970-01-01 2014-03-01 2014-03-06 10:07:12 NULL
100010001
2014-03-01 NULL 2014-03-06 10:07:12 NULL
100010002
2014-03-01 NULL 2014-03-06 10:07:12 NULL
Tabel 9: Tabel JORDSTYKKEGEOMETRI, med bitemporalitet.
5. Distribuerede objekter med bitemporale egenskaber
Et objekt der registreres i forskellige services kaldes et distribueret objekt. Objekter vil kunne
oprettes og ændres flere i forskellige services og derfor er der behov for replikering af objekterne på
tværs af implementeringer9. Der vil også være tale om distribuerede objekter, hvis der er aftalt, at en
registrering er ’master’ og andre replika heraf. Fx vil objekter der udstilles i datafordelerens service
være replika fra produktionssystemets registrering, med mindre der er tale om gennemstilling.
Der er afgørende at registrering af objektet foretages hver gang objektet lagres i en service. Man
skal altså bruge servicesystemets timestamp-funktion. Dermed vil det samme objekt altid have
forskellige registreringsperioder i forskellige services. Begrundelsen herfor er enkel: Et
anvendersystem skal spørge den samme service for at få oplysninger om ændringer i registrering,
der jo er et udtryk for hvad services vidste om objektet på et bestemt tidspunkt. Hvis man fejlagtigt
9 Vi anvender begrebet replika og ikke synkronisering – fordi der hverken er tale om kopier af objekter eller at
de har de samme tidsmæssige egenskaber.
21
kopierer registreringstidspunkter fra forretningssystemet, vil der være et tidsrum (forsinkelsen), hvor
servicen svarer forkert.
Når et objekt registreres i forskellige services kan det også opdateres i disse services – det kan
også være, at der i nogle services er flere egenskaber der registreres end i andre. Der er altså tale
om samme objekt, men ofte forskellige egenskaber. Fx vil FOT og BBR have registreret forskellige
egenskaber om samme bygninger10. Derfor er der behov for, at udveksle beskeder om objektets
ændringer mellem de forskellige implementeringer.
Når et objekt importeres er det et udtryk for, at det er et replika af et objekt fra en anden
registrering. Et distribueret objekt kan således kun oprettes én gang – men importeres flere gange.
En import bevarer objektets unikke ident, mens en opret danner den.
Når et objekt afregistreres bruger man registreringTil – uden at der er en efterfølgende
registreringFra med samme tidspunkt. Når et objekt skal afregistreres må det ikke fjernes.
Afregistrering bruges i forskellige situationer:
● Der kan være tale om en logisk sletning af objektet, fordi det aldrig skulle have været
oprettet eller der er tale om en dublet, hvor samme logiske objekt er registret under to
forskellige identer. Det afregistrerede objekt skal henvise11 til det blivende objekt, så
anvendersystemerne bliver opmærksomme på fejlen.
● Der kan være tale om en passivering af objektet, hvor en service ikke ønsker at
vedligeholde oplysning om objektet længere. I dette tilfælde må anvendersystemet finde en
anden service, hvor objektet er vedligeholdt.
Det bør fremgå af objektets livscyklus, hvilken ’situation’ objektet befinder sig i på forskellige
registreringstidspunkter: Importeret, oprettet, rettet, slettet, passiveret.
6. Performance og bitemporale egenskaber
SQL databaser kan i nogle tilfælde have udvidede tidsmæssige faciliteter. Dermed undgår man de
tidsmæssige udtryk, der kan give en dårlig performance. Men hvis man ønsker at anvende
traditionelle databaser, bør man anvende et databasedesign, hvor man arbejder med relation til
intervaltabeller. En objektegenskab får relation til et interval, som er identificeret og indekseret.
Forespørgsel består af forespørgsel på tid i intervaltabellen joinet med egenskabstabellen.
7. Anbefalinger
Det foreslås at skærpe kravene til definition af egenskaber og deres attributter for bitemporalitet;
● Det skal afklares, hvorvidt registreringstid (til/fra) er forvaltningssystemets registreringstid
eller distributionssystemets registreringstid. Relateret til hvilke spørgsmål man vil kunne stille
Datafordeleren.
10 Det vil også være muligt at BBR og FOT ønsker at registrere den samme bygning under forskellige identer.
I så fald bør de henvise til hinanden. 11
Brug relationen fra de generelle egenskaber ’erstattet af’ med reference det blivende objekt.
22
● Det skal afklares, om der er behov for et ekstra sæt tidsstempler for at håndtere de
forskellige registreringstider.
● Virkningstid (fra) skal være lukket (inklusiv) og virkningstid (til) skal være åbent (eksklusiv)
● Virkningstider, hvor der ikke er tænkt et tidsmæssigt ”hul”, men som støder op til hinanden,
skal være forskellige, men således at den fortidige er åbent og den fremtidige er lukket.
● Det skal afklares, om SQL:2011 standarden definerer NULL som værdi for nu og i fremtiden
eller om en dato langt ude i fremtiden benyttes, som fx 31-12-9999.
● Modelreglerne bør afspejle den praktiske anvendelse og modellering af bitemporalitet.
Der tegner sig et billede af forskellige behov for modellering og implementering af en historikmodel
for nogle parter i Grunddataprogrammet.
Det synes klart at nogle forvaltninger, jævnligt har brug for fx at efterregulere offentlige udbetalinger,
som er blevet udbetalt på et foreløbigt grundlag. Det er typisk kommunale myndigheder som må
forvalte på ikke-kendte eller ikke-opdaterede oplysninger.
Andre forvaltninger har kun sjældnere brug for at søge data med tiden som parameter. Der sker fx,
når en afgørelse drages i tvivl eller påvises at være fejlagtig i forbindelse med tvister.
Funktionalitet, der understøtter historikanvendelsen, bør afpasses til det konkrete behov for den
enkelte forvaltning. Det er vel også rimeligt at antage, at det er på objektniveau, der tildeles
bitemporalitet, men på sådan en måde at hver eneste attributændring giver anledning til en ny
historik.
Det påstås i ovenstående forbindelse, at en traversering gennem et datasæt (tabel), hvor objekter
inkl. historik er lagret, tager længere tid sammenlignet med tilgang til objekter via en historiktabel,
hvis det er tiden, der er den afgørende performance faktor.
At kunne spore forløbet omkring forvaltningsafgørelser, synes at være en rimelig anvendelse af
historik, således at bitemporale data skal understøttes af passende funktionalitet og passende
modeller, i forhold til brugen af historiksøgninger.
8. Referencer
Reference Titel Link [Arkitekturreolen] OIO arkitekturreolen Link [DB2] NICOLA, M. Best practices for Temporal Data Management with
DB2. 2012. Link
[DDO] Den Danske Ordbog Link [Grunddata] Grunddata | Digitaliseringsstyrelsen Link [Ejendom Målarkitektur] Ejendomsdataprogrammet - Målarkitektur Link [Fowler] Temporal Patterns Link [Glossary] JENSEN, Christian S., et al. The consensus glossary of temporal
database concepts—February 1998 version. Springer Berlin Heidelberg, 1998.
Link
[Jensen1] JENSEN, C. S.; SNODGRASS, R. T. Semantics of Time-Varying Information. Chapter 2 in: JENSEN, Christian S. Temporal database management. 2000. PhD Thesis. Department of
Link
23
Computer Science, Aalborg University, Denmark. [Jensen2] JENSEN, C. S.; SOO, M. D.; SNODGRASS, R. T. Unifying
Temporal Data Models. Chapter 6 in: JENSEN, Christian S. Temporal database management. 2000. PhD Thesis. Department of Computer Science, Aalborg University, Denmark.
Link
[Modelregler] Digitaliseringsstyrelsen. Modelregler for grunddata, Version: 1.0.0. Link [MTRD] JOHNSON, T.; WEIS, R. Managing Time in Relational Databases.
2010. Link
[Snodgrass] SNODGRASS, Richard T.; MELTON, Jim. Developing time-oriented database applications in SQL. San Francisco: Morgan Kaufmann Publishers, 2000.
Link
[SQL2011] KULKARNI, Krishna; MICHELS, Jan-Eike. Temporal features in SQL: 2011. SIGMOD Record, 2012, 41.3: 35.
Link