Bitemporalitet

Hvorfor to tidsakser

Registre bliver rettet. En tilbygning fra 2015 bliver måske først registreret i 2018, og en fejl i et areal bliver rettet bagud. Med én tidsakse ville man enten miste, hvornår ændringen skete, eller hvornår registret vidste det. Med to kan man svare på begge spørgsmål: hvordan så bygningen ud i 2016, og hvad stod der i registret i 2016? De to svar kan være forskellige, og forskellen er ofte det interessante.

Hver version har derfor et virkningsvindue og et registreringsvindue. En ændring lukker den gamle version og åbner en ny; intet overskrives.

Hvornår du har brug for det

• Due diligence: hvordan stod ejendommen registreret på handelsdagen?
• Revision og sagsbehandling: hvad vidste man, da beslutningen blev truffet?
• Forandringsanalyse: hvornår blev en bygning ombygget, eller en adresse omdøbt?
• Fejlfinding: hvorfor ændrede et tal sig i jeres egne data, og var det virkeligheden eller registret, der flyttede sig?
• Dokumentation: at kunne vise, hvilken registrering en rapport eller en pris byggede på, også efter at registret er rettet.

Bitemporale data kræver lidt omtanke i en egen database. Gemmer du kun den seneste version, mister du historikken; gemmer du alle versioner, skal hver forespørgsel vide, hvilken akse og hvilket tidspunkt den spørger til. Ofte er det enkleste at hente den aktuelle version løbende og slå historikken op, når et konkret spørgsmål kræver den.

Bitemporal historik i Grundfast

De almindelige opslag giver den aktuelle version, uden bitemporal støj. Med ?asOf= på /v1/bbr/ejendom/:bfe, /v1/matrikel/ejendom/:bfe og /v1/adresse/:uuid får du posten på et tidspunkt; Grundfast sætter registreringstid og virkningstid til samme øjeblik, og tidspunktet gentages i meta.as_of. Datoen skal ligge fra 1990-01-01 og må ikke være i fremtiden.

/v1/bbr/ejendom/:bfe/historik, /v1/matrikel/ejendom/:bfe/historik og /v1/adresse/:uuid/historik giver hele rækken af versioner, nyeste først, hver med registrering_fra, registrering_til, virkning_fra og virkning_til. Begge dele kræver Scale. Se Historik-API’et.