Bitemporalitet. Proof of concept. Versionshistorik. Version Dato Hvem Hvad er ændret. Første udkast. Kommentarer fra KL indarbejdet undervejs.

Transkript

1 Bitemporalitet Proof of concept Versionshistorik Version Dato Hvem Hvad er ændret sept 2014 Heidi Vanparys (GST) Flemming Nissen (GST) sept 2014 Heidi Vanparys (GST) Erik Helweg-Larsen (KL) sept 2014 Flemming Nissen (GST) Heidi Vanparys (GST) Niels Kjær (GST) Første udkast. Kommentarer fra KL indarbejdet undervejs. Indarbejdet kommentarer og rettelser fra DOS-området i GST. Tilføjet afsnit Distribuerede objekter med bitemporale egenskaber og Performance og bitemporale egenskaber. Viderebehandling af kommentarer og revideret afsluttende afsnit sept Flemming Nissen (GST) Opstramning af showcase beskrivelse sept Thorben Brigsted Hansen (GST) Opdatering af showcase beskrivelse. 1

2 Indholdsfortegnelse 1. Resumé Indledning Begreber i bitemporalitets- og forvaltningsdomænet Matriklen Informationsmodeller & fysiske datamodeller Informationsmodel 1: Bitemporale objekter Fysisk datamodel 1a: Bitemporal tabel Fysisk datamodel 1b: Separat tabel for registrerings- og virkningstid Fysisk datamodel 1c: Tabel med aktuelle data + bitemporal tabel Fysisk datamodel 1d: Totallager + historiklager Bitemporalitet og egenskaber Overførsel af data fra produktion til udstilling Informationsmodel 2: Bitemporalitet på et udvalg af egenskaber Distribuerede objekter med bitemporale egenskaber Performance og bitemporale egenskaber Anbefalinger Referencer

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. 3

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. 4

5 Ved at inkludere virkningstid i en model, kan man svare på de følgende spørgsmål 1 : 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. 5

6 Figur 1: Den offentlige sektors grunddata [Grunddata]. Figur 2: Begrebsoverblik over fast ejendom [Ejendom Målarkitektur]. 6

7 En proces som kan berøre et jordstykke er fx en udstykning af dette jordstykke, som er en matrikulær forandring, som er en del af hovedprocessen Ejendomsdannelse [Ejendom Målarkitektur]. For at illustrere brugen af virkningstid og registreringstid bruges det følgende eksempel 2, 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 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 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. 7

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. 8

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 informationsmodel 3, 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 tilstandsbaseret 4 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]. 9

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 ) (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 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. 10

11 I nedestående tabeller beskrives forløbet for matrikeleksemplet. JORDSTYKKEID MATRIKELNR GEOMETRI VIRKNINGFRA VIRKNINGTIL REGISTRERINGFRA REGISTRERINGTIL NULL :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 = :00:00) har vidst, at der findes et jordstykke med jordstykke-id , matrikelnummer 123 og geometri, som er nugældende (VIRKNINGTIL er NULL) og har været gældende siden d. 1. januar 1970 (VIRKNINGFRA = ). JORDSTYKKEID MATRIKELNR GEOMETRI VIRKNINGFRA VIRKNINGTIL REGISTRERINGFRA REGISTRERINGTIL NULL :00: :41: :41:05 NULL NULL :41:05 NULL NULL :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 = :41:05) har vidst, at der engang fandtes et jordstykke med jordstykke-id , 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 , matrikelnummer 123 og geometri som var gældende (VIRKNINGTIL er NULL) og havde været gældende siden d. 1. januar 1970 (VIRKNINGFRA = ). Den tredje og fjerde række i Tabel 2 skal læses på samme måde som rækken i Tabel 1. 11

12 JORDSTYKKEID MATRIKELNR GEOMETRI VIRKNINGFRA VIRKNINGTIL REGISTRERINGFRA REGISTRERINGTIL NULL :00: :41: :41: :07: NULL :41: :07: NULL :41: :07: :07:12 NULL NULL :07:12 NULL NULL :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 , matrikelnummer 123 og geometri 2014., som var gældende fra d. 1. januar 1970 til d. 13. februar 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 , matrikelnummer 123 og geometri som var gældende og havde været gældende siden d. 13. februar 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 , matrikelnummer 123 og geometri 2014., som var gældende fra d. 1. januar 1970 til d. 13. februar 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 , matrikelnummer 123 og geometri, som er og har været gældende siden d. 1. marts 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

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 NULL :00: :41: :41: :07: NULL :41: :07: NULL :41: :07: :07:12 NULL NULL :07:12 NULL NULL :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) 13

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 NULL :00: :41: :41: :07: NULL :41: :07: NULL :41: :07: :07:12 NULL NULL :07:12 NULL NULL :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 <= :00:00 (som kendt d. 20. februar 2014 kl. 14:00:00) 14

15 :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

16 JORDSTYKKEID MATRIKELNR GEOMETRI VIRKNINGFRA VIRKNINGTIL REGISTRERINGFRA REGISTRERINGTIL NULL :00: :41: :41: :07: NULL :41: :07: NULL :41: :07: :07:12 NULL NULL :07:12 NULL NULL :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 <= (som var gældende d. 20. februar 2014) < 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. 16

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 NULL :00: :41: :41: :07: NULL :41: :07: NULL :41: :07: :07:12 NULL NULL :07:12 NULL NULL :07:12 NULL Tabel 7: Resultatet af forespørgslen "Giv tilstandene af jordstykket med matrikelnummer 123 lige før udstykningen og lige nu". 17

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" 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 Fysisk datamodel 1c: Tabel med aktuelle data + bitemporal tabel 7 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] 18

19 4.2.4 Fysisk datamodel 1d: Totallager + historiklager 8 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 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] 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] 19

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 Tabel 8: Tabel JORDSTYKKE, uden bitemporalitet. JORDSTYKKEID GEOMETRI VIRKNINGFRA VIRKNINGTIL REGISTRERINGFRA REGISTRERINGTIL NULL :00: :41: :41: :07: NULL :41: :07: NULL :41: :07: :07:12 NULL NULL :07:12 NULL NULL :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 implementeringer 9. 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 anvender system 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. 20

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 bygninger 10. 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 henvise 11 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. 21

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 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 Link DB [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 Link database concepts February 1998 version. Springer Berlin Heidelberg, [Jensen1] JENSEN, C. S.; SNODGRASS, R. T. Semantics of Time-Varying Link Information. Chapter 2 in: JENSEN, Christian S. Temporal database management PhD Thesis. Department of 22

23 [Jensen2] [Modelregler] [MTRD] [Snodgrass] [SQL2011] Computer Science, Aalborg University, Denmark. JENSEN, C. S.; SOO, M. D.; SNODGRASS, R. T. Unifying Link Temporal Data Models. Chapter 6 in: JENSEN, Christian S. Temporal database management PhD Thesis. Department of Computer Science, Aalborg University, Denmark. Digitaliseringsstyrelsen. Modelregler for grunddata, Version: Link JOHNSON, T.; WEIS, R. Managing Time in Relational Databases. Link SNODGRASS, Richard T.; MELTON, Jim. Developing timeoriented database applications in SQL. San Francisco: Morgan Link Kaufmann Publishers, KULKARNI, Krishna; MICHELS, Jan-Eike. Temporal features in Link SQL: SIGMOD Record, 2012, 41.3: