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




Indledning

Grunddatamyndighederne har i samarbejde skabt én samlet og sammenhængende datamodel for alle grunddata.

Datamodellen viser de grunddata, som udstilles på Datafordeleren. Datamodellen følger Grunddata modelregler. 

Denne side beskriver kort hvorfor modelregler er relevante for anvendere af tjenester på Datafordeleren, og hvilke modelregler man som minimum bør kende til, for at kunne anvende tjenester, både i forhold til inputparametre og deres betydning samt i forhold til data der returneres ved kald til tjenester og den forretningsmæssige betydning. 

Siden er en opsummering af modelreglerne for grunddata, med det formål at give et overblik over disse, afgrænset til relevante dele i forhold til bitemporalitet.






Grunddata modelregler - målsætning

Målsætningen med modelreglerne - regel 1.1.2

Det primære mål med modelreglerne er at skabe den fælles tilgang til at modellere grunddata, som er nødvendig for at kunne skabe en samlet og sammenhængende datamodel.

Konkret skal modelreglerne opfylde følgende målsætninger:

  • Modelreglerne skal danne grundlag for ensartet modellering af grunddata.

  • Modelreglerne skal sikre det nødvendige abstraktionsniveau til at imødekomme alle interessenters behov.

  • Modelreglerne skal sikre genbrug af allerede eksisterende standarder, hvor det er muligt.

  • Modelreglerne skal gøre det nemt for databrugere at bygge applikationer, der bruger grunddata, og at stille ensartede forespørgsler på tværs af grunddata.




Grunddata modelregler - struktur

Reglerne er organiseret i kapitler: 

Kapitel 1 - Formål
Her beskrives modelreglernes formål og rationale.

Kapitel 2 - Modelreglernes fokus og afgrænsning
Her beskrives fokus og afgrænsning for grunddatamodellen og modelreglerne.

Kapitel 3 - Arkitekturmæssige forudsætninger
Her beskrives de arkitektur - og infrastrukturmæssige forhold, som har indflydelse på udformningen af modelreglerne.

Kapitel 4 - Anvendelse af modelregler
Her forklares, hvordan modelreglerne er bygget op, og hvordan de skal efterkommes. Selve reglerne følger i kapitel 5 og 6.

Kapitel 5 - Generelle modelregler
I dette kapitel opstilles generelle modelregler, som har fokus på datamodellens udformning og vedrører diagrammering. Her opstilles regler for fx modelleringssprog, navngivning af elementer, sprog og dokumentation mv.

Kapitel 6 - Regler for generelle egenskaber
I dette kapitel opstilles regler, som har fokus på indhold i datamodellen, og som sætter rammer for dataindhold i forvaltningsobjekterne. Her opstilles regler med betydning for fx forvaltningsobjekters identifikation og historik. Reglerne udmøntes i specificering af generelle egenskaber for alle modelentiteter.





Grunddata modelregler - bitemporalitet

Dette er en opsummering af to af modelreglerne for grunddata- regel nr. 6.2 og 6.3,  

Formålet er at give et overblik over disse, afgrænset til relevante dele i forhold til bitemporalitet og kan på ingen måde anvendes som erstatning for modelreglerne.







Regel 6.2 - Alle modelentiteter skal modelleres med status



Regel

Alle modelentiteter skal modelleres med status, der klart angiver, hvor et forvaltningsobjekt er i sin livscyklus.


Rationale

Forvaltningsobjekter gennemløber typisk en livscyklus. Fx kunne en livscyklus for en bygning være: “Forslag > Under projektering > Under opførelse > Ibrug > Under nedrivning > Historisk”. Forretningsdomænet kan opstille regler for hvilke statusser, der er gyldige for et givet objekt, og for, hvordan forvaltningsobjektet kan gennemløbe disse.

Disse tilstande skal placeres og udstilles i et vedtaget udfaldsrum, som modelentiteten skal referere til.

Dataobjektets status udtrykker dataobjektets relevans for databrugeren. Forretningsmæssigt giver det god værdi at udstille et dataobjekts status eksplicit, frem for at lade databrugeren analysere sig frem til informationen. Anvendelsen af status er med til at sikre en høj datakvalitet og potentielt nedbringe udviklingsomkostninger, da der skal implementeres mindre forretningslogik og fejlhåndteringslogik.


Implikationer

Alle modelentiteter skal have attributten ‘status’


Status

BetydningForvaltningsobjektets status
VærdiEn status
Datatypeenumeration, kodeliste, klassifikation
UdfaldsrumDomænespecifik liste, værdien må ikke være tom
KravObligatorisk








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


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 datadomæ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 af 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:




BetydningVærdiDatatypeKrav
Registrering:registreringFra

Tidspunktet hvor registreringen er foretaget


TidspunktDateTime (ISO 8601), værdien må ikke være tomObligatorisk
registreringTil

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

TidspunktDateTime (ISO 8601), værdien kan være tomObligatorisk
registreringsaktørDen aktør der har foretaget registreringenAngivelse af en aktør fx som en reference til en organisationsmodel (se regel 5.10)Domænespecifik aktør, værdien må ikke være tomObligatorisk
Virkning:virkningFraTidspunktet hvorfra forvaltningsobjektet har virkningTidspunkt - virkningsperioden inkluderer dette tidspunktdateTime (ISO 8601), værdien må ikke være tomObligatorisk
virkningTilTidspunktet hvor forvaltningsobjektets virkning ophørerTidspunkt - virkningsperioden stopper umiddelbart før dette tidspunkt dateTime (ISO 8601), værdien kan være tomObligatorisk
virkningsaktørDen aktør der har afstedkommet forvaltningsobjektets virkningAngivelse af en aktør fx som en reference til en organisationsmodel (se regel 5.10)Domænespecifik aktør, værdien må ikke være tomObligatorisk