Page tree
Skip to end of metadata
Go to start of metadata




Denne side indeholder en anvenderrettet beskrivelse og dokumentation af grunddataprogrammets historikmodel ved anvendelse og implementering af bitemporalitet.

Siden er opdelt i en mere generel forretningsvendt del, hvor der primært er fokus på virkningsdimension for data, og en del der primært henvender sig til en mere teknisk og udviklerorienteret gruppe, som har behov de specifikke datamæssige og implementeringsmæssige detaljer.

Afslutningsvis henvises til registerspecifikke sider omhandlende bitemporalitet, som giver overblik i de registermæssige forskelle, der er i implementeringen af bitemporalitet for de forskellige registre, afledt af forretningsmæssige behov eller leverandørspecifikke teknologivalg.

Bitemporale egenskaber for data oprettes og vedligeholdes altid i det enkelte register, hvor de efterfølgende overføres sammen med øvrige forretningsmæssige data til Datafordeleren. Her udstilles bitemporale egenskaber i de respektive tjenester som forretningsmæssige data. Datafordeleren opdaterer ikke bitemporale egenskaber for dataobjekter, men udstiller alene disse. Datafordeleren anvender de bitemporale egenskaber og de specificerede regler for disse, herunder de registerspecifikke forhold for bitemporalitet, ved udstilling af data, således at en anvender får returneret de korrekte data i forhold til en given forespørgsel.






Indledning

Hvorfor har vi brug for historik, og hvor kommer krav til historikken fra?

  • Det kan være afledt af lovgivningsmæssige forhold, der beskriver at historik skal være tilgængelig eller at en lov f.eks. træder i kraft en bestemt dato, og at sager før denne dato forholder sig til ældre lovgivning
  • Der er historik i forhold til sagsbehandling- hvornår og på hvilket grundlag er sagen behandlet og afgjort
  • Der kan være sammenhæng til arkivering og mulighed for at arkivere et tidsmæssig forløb

Banker har anvendt dobbelthistorik i lang tid, hvor der fx på en kontooversigt både opereres med en Bogføringsdato og Rentedato. Bogføringsdatoen er hvornår banken har registreret transaktionen på din konto, og Rentedato er dato for hvornår transaktionen har effekt/gyldighed på din saldo.

Som eksemplet viser betyder dobbelthistorik at et system registrerer hvornår data er oprettet eller opdateret rent systemmæssig og samtidig holder styr på hvornår data har virkning rent forretningsmæssigt.

Hvad hvis vi ikke har historik i det hele taget?

Det vil betyde at man kun har gældende version. Gældende version betyder, at man kun har en udgave/version af et givent dataobjekt, og dette er altid den der gælder. Hvis man laver ændringer til dette f.eks. opdaterer en attribut, kan man ikke se, hvad den gamle værdi var, eller hvornår data er blevet opdateret og dermed ikke hvilke ændringer, der evt. er gennemført.

Eksempel: Et kundesystem indeholder data om kunder og deres navn

  • En kunde er registreret med følgende data
    • Navn: Kurt Hansen
    • Adresse: Nordhavnsgade 8, 2100 København Ø
    • : +45 21212121
  • Kunde skifter navn til Kurt Nielsen, hvilket registreres i systemet.
    • Navn: Kurt Nielsen
    • Adresse: Nordhavnsgade 8, 2100 København Ø
    • : +45 21212121

Da der ikke er nogen form for historik, træder ændring i kraft med det samme. Det er endvidere ikke muligt at se, hvad kundens navn var tidligere, samt at se hvornår opdatering i systemet blev gennemført.

Bitemporalitet er også uundværligt, hvis det skal være muligt at gennemføre registreringer, som først træder i kraft på et tidspunkt i fremtiden, således at man kan oprette data, når man kender data, og samtidig give anvendere mulighed for ved selvsyn at se, der kommer ændringer eller oprettelser. Et reelt eksempel her er matrikulær udstykning, der kan oprettes, når det er besluttet, men inden selve udstykning er opmålt og matrikuleret. 

Registrering af dobbelthistorik omkring et forretningsobjekt er relevant i forhold til at kunne registrere og distribuere data, som giver mulighed for sporbarhed i de foretagne registreringer. Sporbarhed er de egenskaber, som et offentligt forvaltningsgrundlag skal kunne understøtte, således det til enhver tid er muligt at fremfinde og dokumentere det datamæssige forvaltningsgrundlag (historiske beslutningsgrundlag), som en myndighed har anvendt som grundlag for en konkret beslutning/sagsbehandling.







Bitemporalitet på Datafordeleren

Her beskrives virkningstid og den generelle forretningsmæssige anvendelse med eksempler. Dvs. der beskrives alene den ene tidsdimension af dobbelt-historikken.

De forretningsmæssige behov i forhold til virkningstid kan beskrives som 3 entydige udsagn om data:

  1. Hvad er gældende nu?
  2. Hvad var gældende på et givet tidspunkt i fortiden?
  3. Hvad vil være gældende på et givet tidspunkt i fremtiden?

Et typisk eksempel på virkningstid i fremtiden er love og forordninger, hvor det ofte i selve loven er angivet, hvornår den træder i kraft. Eksempelvis angiver Persondataforordningen at den træder i kraft 25. maj 2018.

Virkningstid kan også ses som den forretningsvendte historik for data, som vil være relevant at kende i forbindelse med anvendelse af data.




Eksemplet er opbygget, ud fra forudsætning af at dags dato er 01. marts 2018.

Adresse:

  1. januar 2000: Per Jensen bor på Gammel Strand 40, 4. th, 1202 København K
  2. februar 2017: Per Jensen flytter til Ny Strandvej 8, 3060 Espergærde
  3. februar 2018: Per Jensen melder flytning til Strandvejen 23, 4600 Køge pr. 1. april 2018

Forløb for virkning-til og virkning-fra

Adresse

Virkning fra

Virkning til

Gammel Strand 40, 4. th, 1202 Kbh K

01-01-2000

01-02-2017

Ny Strandvej 8, 3060 Espergærde

01-02-2017

01-04-2018

Strandvejen 23, 4600 Køge

01-04-2018





I grunddataprogrammet er der tilføjet en ekstra dimension, da man kan tilføje en status på data, hvorved der kan være flere versioner, der er gældende på et givet tidspunkt.

For data i grunddataregistrene er dette gjort ved at dataobjekter inkluderer et statusfelt - læs mere om status i Grunddata modelregel 6.2 



En adresseflytning kan være midlertidig, f.eks. i forbindelse med ophold i sommerhus eller genhusning.

Det er vigtigt at fremhæve, at betydningen af Status-feltets indhold er både forretnings- og register-specifikt, så anvendere skal altid besøge den registerspecifikke dokumentation for at kunne anvende og tolke data korrekt.

Udvides ovenstående eksempel med Status-felt kan data evt. se således ud (dette er et tænkt eksempel og ikke udtryk for hvordan adresser registreres):

Eksemplet viser at i perioden 01-04-2018 til 31-08-2018 har Per Jensen reelt 2 aktive adresser, nemlig den permanente adresse (folkeregisteradressen) og en ”midlertidig adresse”. Så når man vil finde Per Jensens adresse, skal man som anvender af data, fremsøge adressen med den ønskede Status.


Adresse

Virkning fra

Virkning til

Status

Gammel Strand 40, 4. th, 1202 Kbh K

01-01-2000

01-02-2017

Permanent

Ny Strandvej 8, 3060 Espergærde

01-02-2017

01-04-2018

Permanent

Strandvejen 23, 4600 Køge

01-04-2018


Permanent

Stenvej 16, 3250 Gilleleje

01-04-2018

31-08-2018

Midlertidig




I grunddataprogrammet registreres alle forekomster i systemet/registret med en virkningstid bestående af to tidsstempler - et fra-timestamp og et til‐timestamp, hvor fra‐timestamp er inklusiv og til‐timestamp er eksklusiv.

Virkningstid kan oprettes i fortiden, nutiden eller fremtiden, og skal ikke have overlappende perioder. Dette dog med den tilføjelse, at der skal kun være én gældende virkningstid for en given objektstatus på et givet tidspunkt. Så hvis der kigges på virkningstid alene, kan der forekomme overlap. Dette uddybes i næste afsnit.







Regler for bitemporalitet

I Grunddataprogrammet er der i forbindelse med udstilling af data på den fællesoffentlige Datafordeler behov for en stringent måde at definere registreringstid og virkningstid på. Dette er vigtigt, dels fordi data skal kunne sammenstilles på tværs af registre og dels danne grundlag for en bedre og mere effektiv brug af de offentlige grunddata.

Bitemporalitet er et anerkendt begreb, som anvendes i databaser mange forskellige steder i verden og består af:

  • Unik identifikation (UUID)
  • Registreringstid (til og fra timestamp)
  • Virkningstid (til og fra timestamp)

I Grunddataprogrammets modelleringsregler er dobbelthistorik beskrevet til at indeholde de bitemporale egenskaber samt:

  • Registreringsaktør
  • Virkningsaktør

Disse aktørregistreringer kan eksterne anvendere udelade at anvende.

Derudover er der et yderligere krav til at alle objekter indeholder en statusattribut:

  • Objektstatus

Af hensyn til fælles forståelse, implementering og anvendelse, beskrives disse 6 egenskaber under begrebet dobbelthistorik /bitemporalitet.






Begrebsafklaring

Dette afsnit beskriver kort de begreber Grunddataprogrammet anvender i forbindelse med dobbelthistorik.

Beskrivelsen anvender følgende termer:

  • ”Begreb”: Det der fremgår af informationsmodellerne.

  • ”Forretningsobjekt”: En konkret instans af begrebet (har en UUID).

  • ”Forekomst”: De enkelte rækker i tabellen for et forretningsobjekt.




BegrebBeskrivelse

Unik identifikation

Alle begreber modelleres med en persistent, unik nøgle af typen UUID (”Universal Unique IDentifier”), dvs. et globalt unikt id, som ikke ændres i et forretningsobjekts levetid.

Normalt vil forretningsobjektet, ud over denne unikke nøgle, have en eller flere forretningsnøgler. Men forretningsnøglerne kan ikke stå alene, da disse i nogle tilfælde ændres over tid, ligesom den samme forretningsnøgle løbende kan indgå i flere forekomster.

Registreringstid

Alle forekomster registreres i databasen med en registreringstid, bestående af to tidsstempler - et fra-timestamp og et til-timestamp. Fra-timestamp er inklusiv, og til-timestamp er eksklusiv den tidsmæssige periode som angives ved de to timestamp.

Registreringstiden er tidsrummet fra versionen registreres til den enten erstattes af en nyere version eller afregistreres (logisk slettes). Registreringstiden er således fortløbende for et givent forretningsobjekt.

Der kan over tid eksistere flere forekomster med samme identifikation, virkningstid og objektstatus. Her vil registreringstid afgøre, hvilken der er/var gældende på et givet tidspunkt.

Virkningstid

Alle forekomster registreres i databasen med en virkningstid bestående af to tidsstempler - et fra- timestamp og et til-timestamp. Fra-timestamp er inklusiv, og til-timestamp er eksklusiv.

Virkningstid kan oprettes i fortiden, nutiden eller fremtiden.

Der skal kun være én gældende virkningstid for en given objektstatus på et givet tidspunkt.

Virkningstid må ikke være overlappende for samme registreringstid og objektstatus.

Objektstatus

Alle forekomster registreres i registersystemet med en status, der angiver, hvor et forretningsobjekt er i sin livscyklus.

Registrerings‐ og virkningsaktør

De to attributter udfyldes med navn eller id på den person eller det program, der foretager ændringen. Registreringsaktør, er den aktør der opdaterer registersystemet, virkningsaktør er den aktør, der er forretningsmæssig ansvarlig for opdateringen.

Attributterne udfyldes altid og er, af hensyn til overskueligheden, ikke medtaget i resten af dokumentet, da indholdet ikke anvendes aktivt i forbindelse med dobbelthistorikken.






Eksempel på nyt forretningsobjekt med bitemporalitet

Dobbelthistorik registreres pr. forretningsobjekt, dvs. hvert UUID har sin egen dobbelthistorik.

Et ”Null” timestamp betragtes som uendelig, eksempelvis implementeret som 9999-12-31‐ 23.59.59.999999. ”Null” timestamps anvendes kun på registreringTil og virkningTil.

RegistreringFra og virkningFra skal altid udfyldes med et ikke‐fiktivt timestamp. Ligeledes skal objektstatus også altid udfyldes.

Der oprettes altid en ny forekomst i databasen, når en af egenskaberne for et forretningsobjekt ændrer sig. Dvs. at når en forekomst først er oprettet, må den ikke ændres efterfølgende. Eneste undtagelse er opdatering af sluttidspunkt for registreringen (registreringTil), der udfyldes, når en ny forekomst af samme forretningsobjekt oprettes.




Nyt forretningsobjekt

Ved oprettelse af et nyt forretningsobjekt sættes forekomstens virkningstid, registreringstid og objektstatus således:

  • VirkningFra = Timestamp for start på forekomstens gyldighed
  • VirkningTil = ”Null” eller slut på forekomstens gyldighed, hvis denne kendes
  • Objektstatus = Forekomstens livscyklus status, gældende for den angivne virkningstid
  • RegistreringFra = Aktuelt timestamp
  • RegistreringTil = ”Null”







Eksempler på ændringer af forretningsobjekter med bitemporalitet

Ved ændring af et forretningsobjekt, oprettes en forekomst, hvor virkningstid, registreringstid og objektstatus sættes som ved en oprettelse med følgende tilføjelse:

  • RegistreringTil = Aktuelt timestamp (på den eksisterende forekomst der opdateres)

Der må således ikke opstå ”huller” mellem registreringstiden på de to forekomster.



Rettelse af indholdsmæssige fejl til samme virkningstid og objektstatus

Ved rettelse af indholdsfejl til samme virkningstid, foretages følgende:

  • RegistreringTil = Aktuelt timestamp (på den eksisterende forekomst der opdateres)

Der oprettes en ny forekomst med:

  • RegistreringFra = Aktuelt timestamp
  • RegistreringTil = ”Null”
  • Objektstatus = Kopieres fra den forekomst, der rettes
  • VirkningFra = Kopieres fra den forekomst, der rettes
  • VirkningTil = Kopieres fra den forekomst, der rettes
  • Opdatering af oplysninger til ny virkningstid og/eller ny objektstatus


Ved opdatering af oplysninger til ny virkningstid og/eller ny objektstatus

Ved opdatering af oplysninger til ny virkningstid og/eller ny objektstatus foretages følgende:

  • RegistreringTil = Aktuelt timestamp (på den eksisterende forekomst der opdateres)

Der oprettes en ny forekomst som en kopi af den tidligere forekomst hvor:

  • RegistreringFra = Aktuelt timestamp
  • RegistreringTil = ”Null”
  • Objektstatus = Kopieres fra den forekomst, der rettes
  • VirkningFra = Kopieres fra den forekomst, der rettes
  • VirkningTil = VirkningFra på den nye forekomst (nedenfor)

Der oprettes en ny forekomst med:

  • RegistreringFra = Aktuelt timestamp
  • RegistreringTil = ”Null”
  • Objektstatus = Forekomstens livscyklus status, gældende for den angivne virkningstid
  • VirkningFra = Timestamp for start på forekomstens gyldighed
  • VirkningTil = ”Null” eller slut på forekomstens gyldighed, hvis denne kendes

Logisk sletning af et forretningsobjekt

Ved logisk sletning af et forretningsobjekt, foretages følgende:

  • RegistreringTil = Aktuelt timestamp (på den eksisterende forekomst der opdateres)

Der oprettes en ny forekomst som en kopi af den tidligere forekomst hvor:

  • RegistreringFra = Aktuelt timestamp
  • RegistreringTil = ”Null”
  • Objektstatus = Kopieres fra den forekomst, der rettes
  • VirkningFra = Kopieres fra den forekomst, der rettes
  • VirkningTil = Timestamp for slut på forekomstens gyldighed (tid for sletning)

OBS: Registre med objektstatus ’Nedlagt’ o.lign er ikke en sletning, men en opdatering, hvor objektstatus anvendes til at beskrive en logisk sletning. Logisk sletning skal anvendes, hvis registreret arbejder med flere samtidige versioner.


Tilføjelse af historik

Ved tilføjelse af historik, foretages følgende:

  • RegistreringTil = Aktuelt timestamp (på den eksisterende forekomst der opdateres)

Der oprettes nye forekomster, som kopier, af de objekter, hvis virkningstid er berørt af historik-tilføjelsen: (der kan være tale om en eller flere forekomster)

  • RegistreringFra = Aktuelt timestamp
  • RegistreringTil = ”Null”
  • Objektstatus = Kopieres fra den forekomst, der rettes
  • VirkningFra = VirkningFra, fra den tidligere instans, eller en ny virkningFra, hvis historik tilføjelsen ændrer på virkningFra.
  • VirkningTil = VirkningTil, fra den tidligere instans, eller en ny virkningTil, hvis historik tilføjelsen ændrer på virkningTil.

Der oprettes en ny forekomst med den nye historik:

  • RegistreringFra = Aktuelt timestamp
  • RegistreringTil = ”Null”
  • Objektstatus = Forekomstens livscyklus status, gældende for den angivne virkningstid
  • VirkningFra = Timestamp for start på forekomstens gyldighed (start for den nye historik)
  • VirkningTil = Timestamp for slut på forekomstens gyldighed (slut for den nye historik)

Flere samtidige versioner

Ved oprettelse af en ny version af et forretningsobjekt, vil resultatet blive flere forekomster med overlappende registreringstid og virkningstid, men med forskellige objektstatus.

Ved oprettelse af nye versioner, foretages følgende:

Der oprettes en ny forekomst med:

  • RegistreringFra = Aktuelt timestamp
  • RegistreringTil = ”Null”
  • Objektstatus = Forekomstens livscyklus status, gældende for den angivne virkningstid
  • VirkningFra = Timestamp for start på forekomstens gyldighed
  • VirkningTil = ”Null” eller slut på forekomstens gyldighed, hvis denne kendes

Hvis der eksisterer en anden forekomst med samme objektstatus og virkningstid, skal dette objekt først logisk slettes, jf. nedenstående beskrivelse.

Når forekomsten, der beskriver den nye version, skifter objektstatus, til samme status som forekomsten der beskriver den aktive version, skal der foretages følgende:

  • Forekomsten for den aktive version skal udgå efter reglerne for ”Logisk sletning af et forretningsobjekt”, hvorved virkningTil angives med tidspunkt (TID) for skiftet til forekomsten for den nye version
  • Forekomsten for den nye version skal opdateres efter reglerne for ”Opdatering af oplysninger til ny virkningstid og/eller ny objektstatus”, hvor virkningFra sættes til TID








Eksempler på læsning af forretningsobjekter med bitemporalitet

Læsning af forretningsobjekter, er altid med udgangspunkt i en identifikation, i form af en nøgle (UUID, evt. fundet via forretningsnøglen) kombineret med virkningstid og registreringstid. For forretningsobjekter med flere samtidige versioner skal objektstatus også anvendes. De to tidsangivelser kan både angives som tidspunkter og som perioder, hvor sidstnævnte vil kunne resultere i en liste af forekomster.

Beskrivelserne i nedenstående eksempler tager udgangspunkt i, at der forespørges på tidspunkter – ikke perioder.




Gyldige forretningsobjekter på et givent tidspunkt

Et gyldigt forretningsobjekt på et givent tidspunkt (TID) identificeres som den forekomst af forretningsobjektet, med den nyeste registreringstid (registreringTil = ”Null”), hvor VirkningFra <= TID og VirkningTil > TID.

Et gyldigt forretningsobjekt på et givent tidspunkt (TID) med en bestemt objektstatus (STATUS) identificeres som den forekomst af forretningsobjektet med den nyeste registreringstid, hvor VirkningFra <= TID og VirkningTil > TID og Objektstatus = STATUS.




Genskabning af forretningsobjekter på et givent real‐tidspunkt

Et forretningsobjekt kan genskabes på et givent real-­‐tidspunkt (TID), via registreringstid, ved at hente de forekomster hvor RegistreringFra <= TID og RegistreringTil > TID.

Forespørgslen kan naturligvis også kombineres med andre elementer, fx en given objektstatus eller en given virkningstid.







Grunddata - modelregler med bitemporalitet





Grunddata – eks. på anvendelse af bitemporalitet




Registerspecifik dokumentation af bitemporalitet

En række sider beskriver registerspecifikke forhold af implementeringsnær karakter, som anvendere skal være opmærksom på ved anvendelse af tjenester og data for de enkelte registre.

Beskrivelsen er opdelt pr. register. Hvor der er forhold, som gælder for alle tjenester og data for et register, beskrives dette først efterfulgt af tjeneste- eller dataspecifikke detaljer.


Bygnings- og Boligregistret (BBR)

Danmarks Administrative Geografiske Inddelinger (DAGI)

Danmarks Adresseregister (DAR)

Danmarks Fikspunktregister

Danmarks Højdemodel (DHM)

Danmarks Topografiske Kortværk (DTK)

Danske Stednavne

Det Centrale Personregister (CPR)

Det Centrale Virksomhedsregister (CVR)

Ejendomsbeliggenhed (EBR)

Ejendomsvurdering (VUR)

Ejerfortegnelsen (EJF)

GeoDanmark Ortofoto

GeoDanmarkVektor

Historiske kort og data

Matriklen (MAT)

Skærmkortet