Bitemporalitet

Bitemporalitet betyder, at én registeroplysning har to tidsforløb: hvornår oplysningen gælder i virkeligheden, og hvornår den er registreret i systemet. Datafordeleren kalder det også dobbelthistorik. [1]

Virkningstiden svarer på, hvad der gjaldt på et bestemt tidspunkt. Registreringstiden svarer på, hvornår registret vidste eller registrerede det. De to tider gør det muligt både at følge ændringer og senere rettelser. [1]

Et eksempel fra DAR før og efter

Tabellen viser de rå versioner af husnummeret på Ørevadsvej 29. Eksemplet er en faktisk DAR-registrering fra det dataudtræk, vi samlede den 16. juli 2026. Tidspunkterne er vist i lokal tid uden sekunder. En tankestreg betyder, at perioden ikke har en registreret slutdato.

Rækkerne er ikke seks forskellige husnumre. De er seks tidsversioner med samme id_lokalId. Når vi danner et aktuelt datasæt den 16. juli 2026, skal datoen ligge i både registreringsperioden og virkningsperioden. Det efterlader version 6:

Hvis flere versioner med samme ID stadig opfylder begge tidsperioder, vælger vi den seneste efter virkningFra og derefter registreringFra. Status håndteres særskilt, fordi værdierne afhænger af registret. [2]

Det samme princip indgår, når vi samler lokationsdata fra DAR, BBR og Matriklen. For de registerobjekter, hvor begge tidsperioder bruges, vælger vi den version, der er aktuel den dag, dataene samles. Vejnavne og BBR's bygningsrelationer følger lidt andre regler, som er beskrevet sammen med resten af forløbet.

Regler for bitemporalitet i Grunddata

Grunddatamodellen beskriver de egenskaber, der gør versionerne sporbare og mulige at anvende på tværs af registre. [3]

Udvælgelsen bygger på følgende felter:

• En persistent, unik identifikation af objektet. I Datafordelerens JSON hedder den typisk id_lokalId, mens den står som ID_LOKALID i rådatabasen.
• Virkningstiden i virkningFra og virkningTil.
• Registreringstiden i registreringFra og registreringTil.
• Objektets tilstand i status.

Et åbent sluttidspunkt behandles som en periode uden registreret slutning. Det er stadig status og den anden tidsdimension, der afgør, om rækken kan bruges.

Objekt-ID, relationsnøgle og forretningsnøgle

Grunddatareglerne skelner mellem objektets persistente ID og dets forretningsnøgler. Et matrikelnummer eller BFE-nummer kan ændre betydning eller indgå i flere objekter over tid og kan derfor ikke uden videre bruges til at samle et objekts historiske versioner. [3]

Som udgangspunkt samler vi derfor versioner på objektets eget ID_LOKALID. Efter behandlingen kan samme værdi have fået et mere læsbart navn. I lokationsdatasættet er house_number_id, address_id, building_id og cadastre_id eksempelvis blot nye navne for ID_LOKALID fra henholdsvis Husnummer, Adresse, Bygning og Jordstykke. De navne findes ikke som selvstændige nøgler i rådatabasen.

Nogle udvælgelser skal dog give én række pr. relation og ikke én række pr. registerobjekt. I lokationsdatasættet gælder det:

• EBR, hvor vi vælger én ejendomsreference pr. adresseLokalId eller husnummerLokalId. EBR-objektet har stadig sit eget persistente ID; de to andre felter er relationer til DAR. [4]
• BBR Grund, hvor vi vælger én supplerende Grund-række pr. husnummer. BBR-modellen viser både Grund som et selvstændigt, bitemporalt objekt og relationen til et husnummer i DAR. [5]

Det er valg af datasættets niveau, ikke en anden definition af bitemporal identitet.

Ejerfortegnelsen

Ejerfortegnelsen er ikke en undtagelse. Ejerfortegnelseselement, som blandt andet er overtype for Ejerskab, Ejerskabsskifte, Ejerskifte og Handelsoplysninger, har et persistent, globalt unikt ID og fuld bitemporalitet. [6] Datafordelerens relationsbeskrivelse siger tilsvarende, at både Ejerskifte og Ejerskab har deres eget ID_LOKALID. [7]

De mange andre felter, der ender på LokalId, er relationsnøgler. Datafordelerens databasemodel beskriver ID_LOKALID som identifikation af objektet og de øvrige felter som udpegninger af relaterede objekter. [9]

Når de bitemporale versioner fjernes i en rå Ejerfortegnelsen-tabel, samles der derfor på tabellens eget ID_LOKALID. Relationsfelterne bruges til at forbinde tabellerne, og BFE-nummeret bruges til at samle oplysninger om samme ejendom. Ejerfortegnelsen kræver desuden både virknings- og registreringstid for at give et entydigt historisk svar. [8]

Kilder

[1]: https://datafordeler.dk/vejledning/grunddata/datamodel/bitemporalitet/ Bitemporalitet

[2]: https://confluence.sdfi.dk/display/DML/Datafordeleren+-+introduktion+til+bitemporalitet Datafordeleren - introduktion til bitemporalitet

[3]: https://grunddatamodel.datafordeler.dk/modelregler/grunddatamodelregler.html#_alle_grunddataobjekttyper_skal_modelleres_med_persistent_unik_identifikation Modelregler for grunddata: persistent, unik identifikation

[4]: https://grunddatamodel.datafordeler.dk/objekttypekatalog/Ejendomsbeliggenhed/Ejendomsbeliggenhed.html EBR: Ejendomsbeliggenhed

[5]: https://grunddatamodel.datafordeler.dk/objekttypekatalog/Bygninger%20og%20boliger/Grund.html BBR: Grund

[6]: https://grunddatamodel.datafordeler.dk/objekttypekatalog/Ejerfortegnelsen/Ejerfortegnelseselement.html Ejerfortegnelsen: Ejerfortegnelseselement

[7]: https://confluence.sdfi.dk/pages/viewpage.action?pageId=91455673 Ejerfortegnelsen: Sammenhæng mellem tabellerne

[8]: https://confluence.sdfi.dk/pages/viewpage.action?pageId=16056447 Ejerfortegnelsen: Bitemporalitet

[9]: https://confluence.sdfi.dk/display/DML/Databasemodeller%2Bfor%2Bregistre Datafordeleren: Databasemodeller for registre