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

Nummer:
6.3
Version:
1.1.0
Høringsversion
Ændring
  1. Måden hvorpå dobbelthistorik skal modelleres, konsolideres.
  2. En attribut tilføjes, for at kunne registrere den dataansvarlige myndighed – denne er ikke altid sammenfaldende med den registeransvarlige myndighed.
 
Δ-tekst
Disclaimer fjernet
Versionering erstattet med rekonstruktion
Aktører i flertal i Rationale
Dataansvarlig Myndighed tilføjet som attribut på hovedobjektet
Dertil altmulig lavet om...
 
Konsekvensvurdering
Radikal nymodellering af området - vil kræve en del tilpasning af eksisterende modeller men vil på sigt være lettere at anvende.

 

Ændringsargumentation
  1. Det er påpeget i forbindelse med høringen af modelreglerne, at den foreslåede metode til modellering af dobbelthistorik ikke er fyldestgørende i forhold til at kunne rekonstruere et dataobjekts tilstand på et givet tidspunkt.
  2. Behovet er påpeget i forbindelse med metadataanvendelse i DIADEM og i forbindelse med udarbejdningen af referencearkitekturen for beskeddreven arkitektur

 

 

Regel

Alle modelentiteter skal modelleres med angivelse af registrering, virkning, aktør og dataansvarlig myndighed.

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

 

Dataansvarlig Myndighed:

Det er ikke altid tilfældet, at data ejes eller vedligeholdes af den myndighed, som er registeransvarlig - eksempelvis vedligeholder kommunerne deres data om personer i CPR-registeret.

Derfor kan det være nødvendigt, at registrere hvilken aktør, der er ansvarlig for det konkrete dataobjekt.

 
Implikationer

Dataansvarlig myndighed

Alle modelentiteter skal have attributten ‘dataansvarligMyndighed’

dataansvarligMyndighed

 

Betydning

Myndighed, med ansvar for dataobjektet

Værdi

Aktør

 

Dobbelthistorik

Dobbelthistorik registreres som selvstændige dataobjekter med entydig reference til redigerede dataobjekter og de berørte relationer eller værdier

 

 

Registreringsobjekter - det vil sige instanser af klassen Registrering og klassen ÆndredeData - sammenbinder de elementer, der har betydning for rekonstruktion af dataobjektet som det så/ser ud som følge af den givne registrering.

Når et dataobjekt oprettes, ændres eller slettet, registreres dette ved hjælp af instanser af klassen Registrering og klassen ÆndredeData. Dataobjektet i sig selv indeholder dermed altid de aktuelle informationer, mens de historiske data indeholdes i instanser af klassen Registrering i kombination med instanser af klassen ÆndredeData. Rekonstruktion af et dataobjekt kan dermed foretages ud fra det aktuelle dataobjekt og de relevante instanser af klasserne Registrering og ÆndredeData.

 

Til hver registrering knyttes følgende data:

  • Et dataobjekt i rollen som subjekt - det dataobjekt, som registreringen vedrører.

  • Den forretningshændelse og den forretningsproces, som afstedkom og effektuerede registreringen - se regel 6.4

  • Tidspunkter for registreringstidspunktet, registreringstid, samt starten og afslutningen af virkningsperioden for den omhandlede ændring, henholdsvis virkningstidStart og virkningstidSlut.

  • En aktør i rollen virkningsaktør - den aktør, der afstedkommer iværksættelse af virkningsperioden

  • En aktør i rollen registreringsaktør - den aktør, der foretager registreringen

  • Angivelse af den type af handling (navngivet redigering) der er foretaget, i form af en af tre muligheder; oprettelse, nedlæggelse og laesning.

  • En attribut eller en relationsende i rollen som egenskab - den del af dataobjektet, som registreringen vedrører
  • Et dataobjekt i rollen som objekt - et dataobjekt som der er skabt en relation til eller en dataværdi i rollen vaerdi - den ny værdi, som attributten har fået

 

registrering

 

Betydning

dataobjektets registrering

Værdi

Datatypen “RegistreringType”

 

registreringstid

 

Betydning

Tidspunktet hvor registreringen er foretaget

Værdi

Tidspunkt

Type

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

Krav

Obligatorisk

 

 

registreringsaktør

 

Betydning

Den aktør der har foretaget registreringen

Værdi

Unik og entydig identifikator i form af en http-uri.

Udfaldsrum

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

Krav

Obligatorisk

 

 

redigering

 

Betydning

Angivelse af den type af handling der er foretaget. r, i form af en af tre muligheder; oprettelse, nedlæggelse og laesning.

Type

Datatypen “RedigeringstypeVaerdi"

 

 

redigeringstypeVaerdi

 

Betydning

Enumeration af handlingstyper der kan registreres.

Værdi

oprettelse, nedlæggelse eller læsning

 

virkningstidStart

 

Betydning

Tidspunktet hvorfra forvaltningsobjektet eller dets egenskab har virkning

Værdi

Tidspunkt

Type

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

Krav

Obligatorisk

 

virkningstidSlut

 

Betydning

Tidspunktet hvor forvaltningsobjektets eller dets egenskabs virkning ophører

Værdi

Tidspunkt

Udfaldsrum

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

Krav

Obligatorisk

 

virkningsaktør

 

Betydning

Den aktør der har afstedkommet forvaltningsobjektets virkning

Værdi

Unik og entydig identifikator i form af en http-uri.

Udfaldsrum

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

Krav

Obligatorisk

Grunddatasekretariatet sørger for, at der kan refereres til en UML-pakke med de elementer, som indgår i generelle egenskaber.

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

Kommentarer

Høringssvar: MBBL

MBBL kan ikke tilslutte sig denne ændring. 
Høringsmaterialet indeholder efter MBBL’s opfattelse ikke nogen begrundelse eller argu-men¬tation for den foreslåede ændring. Hertil kommer, at ændringen vil have væsentlige negative konsekven¬ser for basisregister¬projek¬terne og dermed for delprogrammerne. 
I givet fald vil der være tale om en fundamental ændring, som vil kræve en egentlig re-model¬¬lering af løsningsarkitekturerne for grunddataregistrene i GD1 og GD2, hvilket efter MBBL’s vurdering vil resultere i forsinkelser og yderligere omkostninger – for kravs¬specifika-tion og udbud. Eksisterende, kørende grunddatasystemer vil skulle ombygges, ligeledes med risiko for tidsplan og økonomi.
MBBL skønner endvidere, at ændringen vil give grunddataprogrammets brugere og gevinst-tagere yderligere byrder, såfremt de ønsker at anvende grunddataregistrenes historik. 
Som begrundelse for ændringen fremhæves to forhold:
 
  • Den foreslåede metode til modellering af dobbelthistorik i version 1.0.0, kan ikke rekonstruere et dataobjekts tilstand på et givet tidspunkt
  • Behovet for ændring er påpeget i DIADEM’s metadataanvendelse og i udarbejdelsen af reference¬arkitekturen for beskeddreven arkitektur
Den første begrundelse er efter MBBL’s opfattelse forkert, idet version 1.0.0 modelleringen af dobbelthistorik er tilstrækkelig til at genskabe et objekts tilstand på et givent tidspunkt. 
Fra DIADEM (Ejendomsdata¬rapporten) har MBBL praktiske og positive erfaringer med implementering af dobbelthistorik efter de principper der er beskrevet i version 1.0.0 af modelreglerne, dvs. hvor alle objekter er angivet med virkningstid og registre¬ringstid (dvs. start- og slut tidspunkt for begge). Med disse 4 tidsstempler kan et objekts tilstand gen¬skabes på et vilkårligt tidspunkt. Princippet anvendes i øvrigt også i EU’s INSPIRE-program.
Vi deler gerne vores erfaringerne med anvendelse dobbelt¬historik i DIADEM-projektet. Omvendt er vi ikke bekendt med praktiske implementeringer af den foreslåede ændring.
At Grunddataprogrammet derudover har behov for ”Status/livscyklus tilstand” (grundet registrering af foreløbige ændringer) for at kunne udpege et unikt dataobjekt på et givent tidspunkt, gør ikke modelleringsmetoden invalid – det betyder blot, at der kan findes flere aktive versioner af et objekt, med forskellig status. 
Den anden begrundelse må skyldes en misforståelse. Hverken MBBL eller de involverede konsulenter fra Strand & Donslund i henholdsvis DIADEM og EDA referencearkitekturen er fremkommet med udtalelser, der kan begrunde ændringen i reglerne for dobbelthistorik. 
Såvel DIADEM som EDA referencearkitekturen har påpeget et behov for den nye attribut ”dataansvarligMyndighed”, men altså ikke et behov for ændringer til dobbelthistorikken. 
MBBL kan således ikke i høringsmaterialet finde egentlige begrundelser for den foreslåede, meget omfattende ændring. 
I en konsekvensvurdering karakteriserer høringsmaterialet ændringen således: 
 
”Radikal nymodellering af området - vil kræve en del tilpasning af eksisterende model¬ler, men vil på sigt være lettere at anvende.”
 
For så vidt angår den første del af sætningen er MBBL som ovenfor anført enig: Der vil være tale om betydelige ændringer for de kørende og specificerede GD1 og GD2 registerprojekter, hvilket kan resultere i forsinkelser og yderligere omkostninger. 
Omvendt kan vi ikke se nogen argumenter for, at grunddataanvendelsen vil blive lettere. Ud fra de givne oplysninger er det vores vurdering at anvendelsen bliver betydelig mere kompleks for brugerne end med version 1.0.0, hvilket som nævnt kan berøre ”gevinst-tagerne” negativt. 
Konkluderende forudsætter MBBL således, at reglerne for så vidt angår modelleringen af dobbelthistorik bevares efter de principper, som er fastlagt i version 1.0.0 af modelreglerne, gerne med præciseringer, eksempler og vejledninger, som kan lette registrenes implemen-tering og brugernes forståelse af reglerne. 
En tilføjelse af attributten ”dataansvarligMyndighed” vil være udmærket, eventuelt som valgfri attribut, således at ændringen ikke har indflydelse på allerede færdiggjorte modeller. 
Når en grundlæggende ændring i modelreglerne (som de hér foreslåede) medfører væsent-lige konsekvenser for grunddataprogrammets delprogrammer og projekter, bør ændringen være understøttet af stærke forretningsmæssige argumenter, der også kan begrunde de eventuelle forsinkelser og øgede omkostninger der vil være tale om. Dette er efter vores vurdering ikke tilfældet her. 
Det bør ligeledes være en forventning, at de ændringer, der foreslås, er afprøvet i praksis og at det er tydeligt for de grunddataansvarlige, hvilke implikationer ændringen vil give anled-ning til. Dette var tilfældet med dobbelthistorikken jf. version 1.0.0, der hen over sommeren 2013 blev prototypetestet og dokumenteret af GST på DAGI. 
 

Høringssvar: ATP

Ingen kommentarer

Høringssvar GST:

 
Kære Per
 
Vores korte svar er:
 
 
GST har kigget på kommentarer og bemærkninger modtaget omkring proof-of-concept for bitemporalitet og har følgende input til modelregler 1.1:
 
 
Vi synes, at den forslåede ændring i modelregler 1.1, regel 6.3 er uhensigtsmæssig, af flere grunde.
 
 
Formålet for historikanvendelsen er klar efter vores mening: sporbarhed i forvaltningen.
Målet er at alle anvendelser af data i Datafordeleren tidsmæssigt kan rekonstrueres. (registreringstid skal defineres i DAF)
 
Midlet er bitemporale tidsstempler, status- og aktør- attributter.
 
 
Informationsmodellen er entydig på den måde, at historikfunktionaliteten er den samme for begge fysiske modeller.
 
Den fysiske model kan være
  1. en ren objektmodel, således at hele objektet kopieres over i en ny instans (række) for hver ændring.
  2. en attributorienteret model, som er modelleret, således at attributter kan tidsstemples for sig uden om resten af objektet.
 
Implementeringen kan foretages med de fysiske strukturer (tabeller) som er nødvendig for den enkeltes forretning (performance og lign.).
 
 

 
 
Vores lange svar er:
 
 
Vi er alle enige i, at vi har et krav om, at en ændring i en egenskab i et forvaltningsobjekt skal kunne spores. Eller med andre ord, der skal være fuld temporal rekonstruktion af forvaltningsobjekter.
 
 
Og så er vi alle enige i, at der skal være ensartet modellering over hele grunddata-datasættet. Men vi er ikke helt enig (endnu) om, hvordan sådan en ensartet modellering kunne se ud.
 
Vi ser 3 mulige måder, at lave informationsmodeller på, som alle 3 overholder kravet om, at en ændring i en egenskab i et forvaltningsobjekt skal kunne spores:
1.       et forvaltningsobjekt modelleres som én UML-klasse, og får tidsstempler og aktører som attributter (modelregler 1.0)
2.       et forvaltningsobjekt modelleres som én UML-klasse, dets egenskaber modelleres som separate UML-klasser, og alle disse UML-klasser får tidsstempler og aktører som attributter (”fuldstændig atomiseret model”)
3.       data udstilles som en lang række enkeltændringer, hvor før-og-efterværdier holdes sammen af et registreringsobjekt, som udpeger data-elementer på baggrund af den øvrige udstillingsmodels som så er uden bitemporale elementer (modelregler 1.1)
 
Så skal disse informationsmodeller implementeres. I praksis, så er det en implementering i en relationel database, da det er det, grunddataregistrene bruger. Og i praksis, så bruger man bitemporale databasetabeller. Både informationsmodel 1 og 2 kan implementeres vha. bitemporale tabeller, som er en veldokumenteret og afprøvet måde, som har eksisteret i årtier, se litteraturlisten i vores rapport:
1.       I det første model, ligger forvaltningsobjektets egenskaber i en eller i hvert fald få tabeller:
a.       fordel: kun få tabeller skal bruges for at rekonstruere en tilstand
b.      ulempe: duplikering af kolonneværdier
2.       I den anden model, ligger forvaltningsobjektets egenskaber spredt over flere tabeller:
a.       fordel: ingen duplikering af kolonneværdier
b.      ulempe: mange tabeller skal bruges for at rekonstruere en tilstand
Men principperne er det samme for begge implementeringen (og varianter på disse implementeringer, se rapport). Og så kan man selvfølgelig også bruge en blanding af model 1 og model 2, afhængig af, hvad forretningens behov er.
 
Informationsmodel 3 er en teoretisk mulighed, som viser sig, ikke at være en mulighed på det fysiske niveau. Eller i hvert fald:
·         vi mangler en forklaring i modelregler 1.1
o   på hvilke basis eller teori, denne model er baseret på
o   hvordan det vil kunne lade sig gøre, rent praktisk
·         vi har ikke fundet litteratur, der beskriver denne måde
 
Vi mener, at modelreglerne skal tillade, at
·         model 1 (som forventeligt vil være den mest brugte model)
·         model 2
·         eller en kombination
bruges af dataejerne. Vi mener ikke, at dette er en forhindring for ensartet modellering. Ensartet betyder for os:
·         samme attributnavne for tidsstempler og aktører
·         samme betydning af disse attributter (åbent, lukket, osv.)

 

Høringssvar: KL

Som afledt af dette emne kan det drøftes hvornår er der tale om et selvstændigt objekt – og hvordan forholder man sig til blå objekter og den historik den indeholder.
Eksempel: Når man skal hente et fremmed objekt (blåt objekt) – hvilken registreringsdato skal man spørge på?
Svaret er, at det er den samme registreringsdato som du brugte for det oprindelige objekt. Den dato er typisk ’nu’ eller et tidspunkt som du har lagret for en tidligere afgørelse (eller lignende).
Hvis man bliver tvunget til at spørge på mange forskellige måder i mange forskellige registre – som ikke har det samme tidsbegreb – så bliver det ikke særlig anvendeligt.