Alle modelentiteter skal understøtte dobbelthistorik og angivelse af aktører

Nummer:
6.3
Version:
1.1.0
Release Candidate
Regel

Alle modelentiteter skal modelleres med angivelse af registrering, virkning og aktører

 
Rationale

Dobbelthistorik:

På tværs af grunddata er der behov for at implementere dobbelthistorik, for at kunne understøtte et samlet krav om revisionsspor. Dataobjekter skal med andre ord kunne rekonstrueres på en måde, hvor der er styr på objektets sammensætning eller tilstand til et givet tidspunkt. Formålet hermed er bl.a. at dokumentere det konkrete historiske beslutningsgrundlag i forbindelse med fx sagsbehandling.

Dobbelthistorik modelleres ved hjælp af bitemporale egenskaber. Det dobbelte består i, at to tidsaspekter “virkningstid” og “registreringstid” håndteres i sammenhæng.

 

Registreringstid:

Tidsrummet fra versionen registreres i databasen, indtil den enten erstattes af en nyere version eller afregistreres

 

Virkningstid:
Tidsrummet, hvor en given version af data svarer til de forhold i virkeligheden, som versionen afbilder.

 

Aktører:

Oplysning om hvilke aktører, der er ansvarlig for datas indhold, tilfører sporbarhed i forbindelse med revision og anvendelse af data. Aktøren kan være en af en række forskellige typer, fx en organisation, et it-system, en arbejdsfunktion eller en konkret bruger.

 
Implikationer

Et data-objekt kan bestå af en række (1-*) versioner (ændres en enkelt attributværdi, betragtes dataobjektet som ændret og dermed versioneret). Alle versioner betragtes som dele af et “stamdataobjekt”, og har den samme Identifikation.

 

Alle versioner skal være karakteriseret ved hjælp af deres registreringstid og deres virkningstid. Disse tidsaspekter modelleres ved anvendelse af attributterne registreringFra, registreringTil, virkningFra og virkningTil. 

Enhver version af et stamdataobjekt identificeres entydigt af objektets unikke identifikation kombineret med attributten registreringFra.

Når en bruger til et bestemt formål skal fremfinde den eller de relevante versioner af et objekt, anvendes objektets identifikation samt en kombination af registreringstid, virkningstid og/eller objektets status.

 

Virkningstidsrummet skal fortolkes sådan at virkningsintervallet er inklusiv starttidspunktet men eksklusiv sluttidspunktet.

Hvorvidt der kan være "huller" i Virkningstiden - perioder hvori virkeligheden ikke er afspejlet i data - er op til det enkelte datdomæne at beslutte og dokumentere.

 

 

Til hver version af et dataobjekt skal der knyttes aktører i betydningen:

  • Reference til den aktør, der afstedkommer iværksættelse af virkningsperioden
  • Reference til den aktør, der har foretaget registreringen

Værdien kan være en reference til fx en organisation, et system eller en sagsbehandler se afsnit afsnit 3.3.1 og regel 5.10

 

Fuld temporal rekonstruktion af dataobjekter forudsætter, at alle ændringer i dataojektet gemmes med de nødvendige tidsmarkeringer. Derfor indeholder denne regel et krav om, at data opbevares i registre, som er implementeret på en måde som gør dette muligt. En sådan implementering indbefatter dels en fysisk datamodel som tilføjer en ny række til datatabellen for hver ny version a data, på en måde så alle ændringer kan genfindes dels forretningsregler for, hvordan tidsmærkerne tilknyttes. Et dokument, som uddyber hvordan dette kan gøres i et RDB/SQL miljø  kan downloades her

 

Attributter:

Hver modelentitet med stereotypen DKObjekttype - modsvarende et forretningsobjekt - modelleres med følgende attributter:

 

Registrering:

registreringFra

BETYDNING

Tidspunktet hvor registreringen er foretaget

VÆRDI

Tidspunkt

DATATYPE

DateTime (ISO 8601), værdien må ikke være tom

KRAV

Obligatorisk

registreringTil

BETYDNING

Tidspunktet hvor en ny registrering er foretaget på dataobjektet, og hvor denne version således ikke længere er den seneste.

VÆRDI

Tidspunkt

DATATYPE

DateTime (ISO 8601), værdien kan være tom

KRAV

Obligatorisk

registreringsaktør

BETYDNING

Den aktør der har foretaget registreringen

VÆRDI

Angivelse af en aktør fx som en reference til en organisationsmodel (se regel 5.10)

DATATYPE

Domænespecifik aktør, værdien må ikke være tom

KRAV

Obligatorisk

 

Virkning:

virkningFra

BETYDNING

Tidspunktet hvorfra forvaltningsobjektet har virkning

VÆRDI

Tidspunkt - virkningsperioden inkluderer dette tidspunkt

DATATYPE

dateTime (ISO 8601), værdien må ikke være tom

KRAV

Obligatorisk

virkningTil

BETYDNING

Tidspunktet hvor forvaltningsobjektets virkning ophører

VÆRDI

Tidspunkt - virkningsperioden stopper umiddelbart før dette tidspunkt 

DATATYPE

dateTime (ISO 8601), værdien kan være tom

KRAV

Obligatorisk

virkningsaktør

BETYDNING

Den aktør der har afstedkommet forvaltningsobjektets virkning

VÆRDI

Angivelse af en aktør fx som en reference til en organisationsmodel (se regel 5.10)

DATATYPE

Domænespecifik aktør, værdien må ikke være tom

KRAV

Obligatorisk

 

Undtagelse

CVR's modeller er undtaget fra regel 6.3 fsva. attributterne registreringFra og registreringTil, da CVR ikke indeholder de pågældende data

Permanent URL til denne artikel: http://arkitekturguiden.digitaliser.dk/node/859

Kommentarer

Indlæg fra KL:

Registreringsid: Der er ikke et kommunalt behov for denne egenskab – hvem efterspørger og hvad er formålet med denne egenskab ?
 
Registreringsaktør: Denne aktør er altid en ”Bruger”, virkningsaktøren kan være af anden type. 
 
Registreringsaktør/virkningsaktør: Vil være en reference, ikke et navn – det kan være en brugervendt nøgle eller systemnøgle.
 
Dataansvarligmyndighed: Uklart hvad dette er og hvilket behov det dækker. Der vil være en ejer af specifikationen, hvilket vil være en reference på objekttypen. Der står ansvar for datasamling hvilket indikerer at det er specifikationen/objekttypeniveau, men det er jo ikke relevant på registreringsnivneau.
 

Svar på: Indlæg fra KL:

  • Registreringsid: Der er ikke et kommunalt behov for denne egenskab – hvem efterspørger og hvad er formålet med denne egenskab ?
    - Medgivet: denne kræver nok uddybende kommentarer: Der har været efterspørgsel - bland andet fra Adresseprogrammet - efter versionering af data så man direkte kan specificere en bestemt version af et dataobjekt. Hvis data opbevares i en tabel, med tilføjelse af en ny række/post for hver ændring af dataobjektet - og der er meget der tyder på, at det vil være den fremherskende måde at sikre bitemporalitet på  - vil denne række modsvare en version af data/en registrering. Ved at tilføje en identifikator (jeg har indtil videre gjort det valgfrit) til denne post/række opnås, at man kan specificere denne version direkte. Man kan naturligvis altid fremsøge en given registrering med en temporal søgning, men der er også anvendelse for en direkte adressering:
    I den forståelse, som vi i digst deler med KL og KOMBIT om beskeddreven arkitektur, er det en registrering på dataobjektet, som afføder en hændelsesbesked - derfor også nogen gange kaldet en registreringsbesked. I det fælles beskedformat, som er ved at være afklaret mellem KL, KOMBIT og digst indgår registreringsid som specifikation af dnne begivenhed.
    INSPIRE GCM 9.8.2.3.1 specificerer en versionId for temporale versioner af et dataobjekt

     
  • Registreringsaktør: Denne aktør er altid en ”Bruger”, virkningsaktøren kan være af anden type. 
    - Skal vi tilføje til "Værdi": "Skal altid være en bruger eller en systembruger" - Er det en terminologi, som forstås fjernt fra Weidkampsgade?
     
  • Registreringsaktør/virkningsaktør: Vil være en reference, ikke et navn – det kan være en brugervendt nøgle eller systemnøgle.
    - Kan vi antage, at det altid vil være en reference? Måske kunne "Værdi" udtrykkes sådan: "Angivelse af en aktør fx som en reference til en organisationsmodel (se regel 5.10)"
     
  • Dataansvarligmyndighed: Uklart hvad dette er og hvilket behov det dækker. Der vil være en ejer af specifikationen, hvilket vil være en reference på objekttypen. Der står ansvar for datasamling hvilket indikerer at det er specifikationen/objekttypeniveau, men det er jo ikke relevant på registreringsnivneau.
    - Behovet er igen dukket op i forbindelse med implementering af beskedfordeling, men det er nok også reelt mere generelt: I en række registre (fx CPR, Matriklen) ejes dataspecifikationen af en myndighed (fremgår af objekttypen/domænemodellen) og registeret drives af en myndighed - ofte, men ikke nødvendigvis samme myndighed. Data skrives af en række forskellige registreringsaktører - kommuner, landmålere, ministerialbogførere. Hvis man som beskedmodtager har behov for at opsætte et abonnement på CPR-ændringer uanset hvem der er registreringsaktør, skal man kunne specificere CPR som dataansvarligMyndighed (svarende til angivelse af et register). Dette er rationalet. Jeg hører ferne yderligere kommentarer - ellers fjerner jeg attributten.
 

CVR undtagelse

Da CVR ikke opsamler oplysninger om registreringstid fra deres føde-systemer kan denne ikke udstilles som grunddata.

Derfor undtages CVR fra kravet om at modellere udstillingsmodeller med registreringstids-attributterne