Høring af Modelregler for Grunddata version 1.1.0


En opdatering af Modelregler for Grunddata er i høring:

Version 1.1.0 indeholder opdateringer, som bringer reglerne i bedre overensstemmelse med UML specifikationen - dette sikrer bedre værktøjsunderstøttelse - og der er ændringer i måden, hvorpå modellerne dokumenteres. Disse sikrer en mere veldokumenteret og dermed brugbar Grunddatamodel.
Endelig er der ændringer i måderne hvorpå identitet og dobbelthistorik modelleres.

For fuld forståelse af høringens sammenhæng anbefales det, at man orienterer sig i Det fulde regeldokument, version 1.0.0  samt eventuelt i en forudgående diskussion af reglerne

 

Af reglerne nedenfor, er det dem som er markeret med 1.1.0, som er i høring. Release Candidate betegner de endelige udkast til godkendelse. Regler i version 1.0.0 er medtaget til sammenligning.

 

Kommentering:

Høringssvar kan afgives til place@digst.dk indtil 18. september 2014

Det er muligt at kommentere de enkelte regler. Dette forudsætter login med Digitaliér.dk brugernavn

Regler:

FORSIDE

Nummer:
0.0
Version:
1.1.0
Release Candidate
Regel

Modelregler v. 1.1.0

Modeller skal udarbejdes som UML-klassediagrammer

Nummer:
5.1
Version:
1.0.0
Gældende
Regel godkendt den:
3. February 2014
Regel

Datamodeller for grunddata skal beskrives i UML (Unified Modeling Language) version 2.4.1 som UML-klassediagrammer.

Rationale

En samlet og sammenhængende model forudsætter anvendelsen af et fælles modelleringssprog. UML er valgt, fordi det er et internationalt anerkendt modelleringssprog, hvor den overordnede forståelse af måden at relatere elementer til hinanden er fastlagt.

Implikationer

Der skal for alle grunddata udarbejdes UML-klassediagrammer med klasser, attributter, relationer og kardinaliteter samt tilhørende dokumentation. Der er krav om attributkomplethed, således at al den information, der udstilles som grunddata, skal kunne findes i grunddatamodellen.

Der henvises til uml.org for yderligere information. Almene UML symboler og notationer forklares ikke yderligere i dette dokument.

Referencer til klassifikationer, forretningsmodeller og organisationsmodeller bør anvendes

Nummer:
5.10
Version:
1.0.0
Gældende
Regel godkendt den:
3. February 2014
Regel

Referencer til ekstern information bør så vidt muligt være referencer til publicerede klassifikationer, forretningsmodeller og organisationsmodeller.

Rationale

De fleste data-objekter skal relateres til klassifikationer og andre typer af strukturer, for derved at give objektet kontekst og sammenhæng. For at styrke genbrugelighed og fremfinding, bør disse referencer pege på eksisterende, publicerede og strukturerede datasæt, som fx FORM. Tilsvarende kan det være relevant, at pege på specifikke organisatoriske enheder - disse kan med fordel genbruges fra publicerede organisationsmodeller. Se endvidere afsnit 3.3.

Der eksisterer ikke på nuværende tidspunkt en infrastruktur, som understøtter sådanne strukturerede data. Derfor kan det være nødvendigt - eventuelt som en migrationsstrategi - at give data sammenhæng på simplere måder - fx med reference til en liste over organisatoriske enheder. På et senere tidspunkt kan sådanne lister så importeres i infrastruktur-komponenter, og referencerne tilpasses.

Implikationer

Området er under udvikling, så derfor kan der ikke opstilles en udtømmende implikation.

På samme måde kan denne regel ikke entydigt specificere konkret modellering eller danne grundlag for udvikling af konkret infrastruktur.

 

Anbefalinger:

Ved angivelse af: Brug:
Forretningsområde: FORM: Anbefales generelt anvendt ved angivelse af fællesoffentligt forretningsområde. Anbefales specifikt anvendt som udfaldsrum for attributten ‘forretningsområde’ i regel 6.4.
Organisatorisk enhed: ORGANISATION: Anbefales generelt anvendt ved referencer til organisatoriske enheder. Anbefales specifikt anvendt som udfaldsrum for attributterne registreringsaktør og virkningsaktør i regel 6.3.
Strukturerede data: KLASSIFIKATION: Anbefales generelt anvendt ved referencer som kræver en mere kompleks struktur, end enumeration eller kodeListe kan understøtte. Anbefales specifikt anvendt som udfaldsrum for attributterne status i regel 6.2 og forretningsproces i regel 6.4.

 

UML-modellen skal organiseres i pakker

Nummer:
5.2
Version:
1.0.0
Gældende
Regel godkendt den:
3. February 2014
Regel

UML-modellen skal organiseres i pakker, med en pakke for hvert forretningsdomæne.

Rationale

En logisk organisering af modellens elementer i pakker gør det mere overskueligt at navngive og referere til elementer.

Implikationer

Hver domænemodel placeres i en UML-pakke. En pakke kan have underpakker. Hvor det er relevant, gøres elementer offentlige (‘public’), således at elementer i andre pakker kan referere til dem. Grunddatasekretariatet sørger desuden for, at der kan refereres til UML-pakker med elementer, som indgår i generelle egenskaber (se kapitel 6), samt til pakker udviklet af ISO, fx standardiserede datatyper (se regel 5.5). Se endvidere fodnote til afsnit 2.1

Modelentiteter skal genbruges

Nummer:
5.3
Version:
1.0.0
Udgået
Regel godkendt den:
3. February 2014
Regel udfaset den
20. January 2015
Regel

Modelentiteter skal genbruges på tværs af grunddatamodellen.

Rationale

Det er en forudsætning for grunddataprogrammet, at modelentiteter genbruges på tværs af grunddata for at sikre sammenhæng og undgå redundant vedligehold af data.

Implikationer

Som modelansvarlig skal man modellere modelentiteterne for sit eget forretningsdomæne samt sørge for at relatere til modelentiteter i andre forretningsdomæners UML-pakker. Se endvidere fodnote til afsnit 2.1

Eksempler

Hvis fx person-domænet har behov for at modellere “Adresse”, skal modelleringen referere/genbruge den korrekte modelentitet inden for Adresse-domænet

Endnu et UML-diagramFigur 5 - Pakken “Person” importerer pakkerne “Adresse” og “Date and Time” (fra ISO/TC 211 Harmonized Model) for at anvende klasserne Postadresse og DateTime.

Modelentiteter skal genbruges

Nummer:
5.3
Version:
1.1.0
Release Candidate
Regel

Modelentiteter skal genbruges på tværs af grunddatamodellen.

Rationale

Det er en forudsætning for grunddataprogrammet, at modelentiteter genbruges på tværs af grunddata for at sikre sammenhæng og undgå redundant vedligehold af data.

Implikationer

Som modelansvarlig skal man modellere modelentiteterne for sit eget forretningsdomæne samt sørge for at relatere til modelentiteter i andre forretningsdomæners UML-pakker. Se endvidere fodnote til afsnit 2.1

Eksempler

Hvis fx person-domænet har behov for at modellere “Adresse”, skal modelleringen referere/genbruge («use») den korrekte modelentitet inden for Adresse-domænet

 

 

Figur 5 - Pakken “Person” anvender («use») pakkerne “Adresse” og “Date and Time” (fra ISO/TC 211 Harmonized Model) for at anvende klasserne Postadresse og DateTime.

 

Modelentiteter skal genbruges

Nummer:
5.3
Version:
1.1.0
Høringsversion
Ændring

Relationen til pakker, som anvendes af andre pakker skal være «use» i stedet for «Import». Rettet i figur.

Ændringsargumentation

«Import» afleverer det importerede element i pakken, så det kan refereres uden kvalificeret navn. Dette er ikke hensigten; elementer skal konceptuelt blive i deres egne application schemas.«use» ændrer ikke på elementets tilhørsforhold.

Regel

Modelentiteter skal genbruges på tværs af grunddatamodellen.

Rationale

Det er en forudsætning for grunddataprogrammet, at modelentiteter genbruges på tværs af grunddata for at sikre sammenhæng og undgå redundant vedligehold af data.

Implikationer

Som modelansvarlig skal man modellere modelentiteterne for sit eget forretningsdomæne samt sørge for at relatere til modelentiteter i andre forretningsdomæners UML-pakker. Se endvidere fodnote til afsnit 2.1

Eksempler

Hvis fx person-domænet har behov for at modellere “Adresse”, skal modelleringen referere/genbruge («use») den korrekte modelentitet inden for Adresse-domænet

 

 

Figur 5 - Pakken “Person” anvender («use») pakkerne “Adresse” og “Date and Time” (fra ISO/TC 211 Harmonized Model) for at anvende klasserne Postadresse og DateTime.

 

Modelentiteter skal genbruges

Nummer:
5.3
Version:
1.1.0
Gældende
Regel godkendt den:
20. January 2015
Regel

Modelentiteter skal genbruges på tværs af grunddatamodellen.

Rationale

Det er en forudsætning for grunddataprogrammet, at modelentiteter genbruges på tværs af grunddata for at sikre sammenhæng og undgå redundant vedligehold af data.

Implikationer

Som modelansvarlig skal man modellere modelentiteterne for sit eget forretningsdomæne samt sørge for at relatere til modelentiteter i andre forretningsdomæners UML-pakker. Se endvidere fodnote til afsnit 2.1

Eksempler

Hvis fx person-domænet har behov for at modellere “Adresse”, skal modelleringen referere/genbruge («use») den korrekte modelentitet inden for Adresse-domænet

 

 

Figur 5 - Pakken “Person” anvender («use») pakkerne “Adresse” og “Date and Time” (fra ISO/TC 211 Harmonized Model) for at anvende klasserne Postadresse og DateTime.

 

Attributter og relationer skal modelleres fyldestgørende

Nummer:
5.4
Version:
1.1.0
Gældende
Regel godkendt den:
20. January 2015
Regel

Attributter og relationer mellem UML-elementer skal modelleres fyldestgørende - dvs. at attributter modelleres med multiplicitet og datatype, relationer modelleres med multiplicitet, retning og roller.

Rationale

For at modellen skal være entydig samt danne basis for semantisk forståelse af data, er det nødvendigt, at attributterne og relationerne er beskrevet grundigt.

Implikationer

Attributter skal modelleres med en eksplicit type - se regel 5.5 Standardiserede datatyper skal genbruges - samt med multiplicitet dvs. antalsregler for, hvor mange værdier attributten kan rumme på en enkelt instans af klassen. Relationer (andre end generalisering/specialisering) mellem UML-elementer (associationer, kompositioner, aggregeringer) skal modelleres med navn, læseretning, navigabilitet, navngiven rolle/relations-ende samt multiplicitet (multiplicitet skal ikke angives for generalisering/specialisering). Se endvidere fodnote til afsnit 2.3

 

Eksempler

På figuren ses hvordan roller, læseretning, navigabilitet og multiplicitet udtrykker en kompleks association mellem to dataobjekter, som ellers ikke vil kunne kommunikeres i regi af modellen.

 

 

Figur 6 - Virksomhed i rollen som Ejer anvender Bygning som Lager. En virksomhed kan være alt fra lagerløs til lagermonopol (multilagered) - en Bygning kan kun have én ejer.

 

Attributter og relationer skal modelleres fyldestgørende

Nummer:
5.4
Version:
1.1.0
Release Candidate
Regel

Attributter og relationer mellem UML-elementer skal modelleres fyldestgørende - dvs. med attributter modelleres med multiplicitet og datatype, relationer modelleres med multiblicitet, retning og roller.

Rationale

For at modellen skal være entydig samt danne basis for semantisk forståelse af data, er det nødvendigt, at attributterne og relationerne er beskrevet grundigt.

Implikationer

Attributter skal modelleres med en eksplicit type - se regel 5.5 Standardiserede datatyper skal genbruges - samt med multiplicitet dvs. antalsregler for, hvor mange værdier attributten kan rumme på en enkelt instans af klassen. Relationer (andre end generalisering/specialisering) mellem UML-elementer (associationer, kompositioner, aggregeringer) skal modelleres med navn, læseretning, navigabilitet, navngiven rolle/relations-ende samt multiplicitet (multiplicitet skal ikke angives for generalisering/specialisering). Se endvidere fodnote til afsnit 2.3

 

Attributter skal modelleres med en eksplicit type - se regel 5.5 Standardiserede datatyper skal genbruges - samt med multiplicitet dvs. antalsregler for, hvor mange værdier attributten kan rumme på en enkelt instans af klassen. Relationer (andre end generalisering/specialisering) mellem UML-elementer (dvs. associationer, kompositioner, aggregeringer) skal modelleres med navn, læseretning, navigabilitet, navngiven rolle/relations-ende samt multiplicitet. Se endvidere fodnote til afsnit 2.3

Eksempler

På figuren ses hvordan roller, læseretning, navigabilitet og multiplicitet udtrykker en kompleks association mellem to dataobjekter, som ellers ikke vil kunne kommunikeres i regi af modellen.

 

 

Figur 6 - Virksomhed i rollen som Ejer anvender Bygning som Lager. En virksomhed kan være alt fra lagerløs til lagermonopol (multilagered) - en Bygning kan kun have én ejer.

 

UML-relationer skal modelleres fyldestgørende

Nummer:
5.4
Version:
1.0.0
Udgået
Regel godkendt den:
3. February 2014
Regel udfaset den
20. January 2015
Regel

Relationer mellem UML-elementer skal modelleres fyldestgørende - dvs. med retning, roller og multiplicitet.

Rationale

For at modellen skal være entydig samt danne basis for semantisk forståelse af data, er det nødvendigt, at relationerne mellem UML-elementer er beskrevet grundigt.

Implikationer

Relationer mellem UML-elementer (associationer, kompositioner, aggregeringer, generalisering/specialisering) skal modelleres med retning, navngiven rolle/relations-ende samt multiplicitet (multiplicitet skal ikke angives for generalisering/specialisering). Se endvidere fodnote til afsnit 2.3

Eksempler

På figuren ses hvordan roller, retning og multiplicitet udtrykker en kompleks association mellem to dataobjekter, som ellers ikke vil kunne kommunikeres i regi af modellen.

Figur, som viser fuldt specificeret associationFigur 6 - Virksomhed i rollen som Ejer anvender Bygning som Lager. En virksomhed kan være alt fra lagerløs til lagermonopol (multilagered) - en Bygning kan kun have én ejer.

Attributter og relationer skal modelleres fyldestgørende

Nummer:
5.4
Version:
1.1.0
Høringsversion
Ændring

Reglen ændres til også at omhandle attributter - disse regler hentes fra Bilag 3 og er altså ikke ny Δ-tekst Sætninger vedr attributter tilføjet i Regel, Rationale og Implikationer; fjernet fra Bilag 3

Ændringsargumentation

Konsekvens af ændringer i regel 5.9 Datamodellen skal dokumenteres, Bilag 3 Det giver mere mening at kræve fuld modellering af attributter i selve reglerne end at gøre det i et bilag, som handler om dokumentation Ingen konsekvens - reglerne er ikke ny, bare flyttet.

Regel

Attributter og relationer mellem UML-elementer skal modelleres fyldestgørende - dvs. med multiplicitet samt henholdsvis datatype og retning og roller.

Rationale

For at modellen skal være entydig samt danne basis for semantisk forståelse af data, er det nødvendigt, at attributterne og relationerne er beskrevet grundigt.

Implikationer

Attributter skal modelleres med en eksplicit type - se regel 5.5 Standardiserede datatyper skal genbruges - samt med multiplicitet dvs. antalsregler for, hvor mange værdier attributten kan rumme på en enkelt instans af klassen. Relationer (andre end generalisering/specialisering) mellem UML-elementer (associationer, kompositioner, aggregeringer) skal modelleres med navn, læseretning, navigabilitet, navngiven rolle/relations-ende samt multiplicitet (multiplicitet skal ikke angives for generalisering/specialisering). Se endvidere fodnote til afsnit 2.3

Eksempler

På figuren ses hvordan roller, læseretning, navigabilitet og multiplicitet udtrykker en kompleks association mellem to dataobjekter, som ellers ikke vil kunne kommunikeres i regi af modellen.

 

 

Figur 6 - Virksomhed i rollen som Ejer anvender Bygning som Lager. En virksomhed kan være alt fra lagerløs til lagermonopol (multilagered) - en Bygning kan kun have én ejer.

 

Standardiserede datatyper skal genbruges

Nummer:
5.5
Version:
1.0.0
Gældende
Regel godkendt den:
3. February 2014
Regel

Alle attributter skal enten tildeles en standardiseret datatype eller en datatype, der er modelleret som et UML-element i samme eller en anden pakke.

Ved brug af en standardiseret datatype skal der henvises til ISO 19103, hvor en række standardiserede datatyper er samlet og modelleret i UML. ISO 19107 anvendes til geografi. 

Rationale

ISO giver en anerkendt ramme for standardiserede datatyper. Anvendelse af en standard for datatyper gør det nemmere at bygge snitflader, der udstiller grunddata som nemt anvendelige services.

 

Implikationer

Standardiserede datatyper i modellen skal hentes fra ISO/TC 211 Harmonized Model.

Denne er en samling af datatyper, som primært anvendes af geografi-relaterede modelleringsprojekter - fx INSPIRE. Ikke desto mindre indeholder ISO/TC 211 Harmonized Model også generelt anvendelige datatyper (CharacterString, Integer, DateTime mv.) modelleret som UML.

Hvis domænet ikke finder typerne i ISO/TC 211 Harmonized Model anvendelige, kan det opbygge sit eget typebibliotek, som skal publiceres sammen med domænemodellen.

 ISO/TC 211 Harmonized Model findes frit tilgængelig på adressen https://inspire-twg.jrc.it/svn/iso/, hvorfra den kan importeres i et modelleringsværktøj. Dokumentet “Modelleringsværktøj”, som Grunddatasekretariatet forventes at publicere, vil beskrive anvendelsen af ISO/TC 211 Harmonized Model i detaljer. 

UML-stereotyper skal anvendes

Nummer:
5.6
Version:
1.1.0
Gældende
Regel godkendt den:
20. January 2015
Regel

Alle UML-elementer tildeles en UML-stereotype.

Rationale

På sigt skal det være muligt, at fortolke modellen til andre modeltyper samt fx datasnitflader. UML kan ikke i sig selv udpege elementernes rolle (modelentitet, datatype, enumeration) i modellen, hvorfor det er nødvendigt, at udvide modellen med disse roller. UML-stereotyper er udvidelser af modelleringssproget, som gør det muligt at specificere yderligere egenskaber, samt at kategorisere model-elementerne. Med stereotyper kan man udpege specifikke klasser som havende bestemte roller i datamodellen, hvilket igen gør det muligt for et eksternt værktøj, at fortolke modellen til fx datasnitflader og ontologier. Stereotyperne tilføjer roller til elementerne og strukturerer de tagged values, som indeholder dokumentationen af modelelementerne (se Note om tagged values).

Implikationer

Følgende stereotyper anvendes i Grunddatamodellen*:

 

  • «DKObjekttype»: Alle forvaltningsobjekter skal modelleres som UML-klasser med stereotypen «DKObjekttype».

  • «DKEnumeration», «DKKodeliste»,«DKKlassifikation»: Attributter med kodede værdier skal modelleres med UML-elementer med stereotyperne «DKEnumeration», «DKKodeliste» eller «DKKlassifikation», som værdisæt - se Note om kodede værdier.

  • «DKDatatype»: Attributter, som ikke er kodede værdier og som ikke tildeles en standardiseret datatype fra ISO (se regel 5.5) skal modelleres med en datatype i samme eller en anden pakke, med stereotypen «DKDatatype», som værdisæt. Se endvidere fodnote til afsnit 2.3

  • «DKEgenskab»: Attributter og associationsender i Grunddatamodellen har stereotypen «DKEgenskab».

  • «DKDomænemodel»: “Rod”-pakken i en afleveret domænemodel markeres med «DKDomænemodel»

Grunddatasekretariatet sørger for, at en UML-profil indeholdende stereotyperne er specificeret. Se http://digitaliser.dk/group/2494445

NOTE om tagged values

UML-elementer kan indeholde ekstra attributter, kaldet tagged values. Ved at anvende tagged values på stereotyperne, kan de på en gang tilføjes alle klasser, der har stereotypen. Disse tagged values kan indeholde specifikke instrukser til det software, som skal fortolke modellen til for eksempel XML schema - se fx INSPIRE GCM afsnit 9.6.3. På nuværende tidspunkt er der ikke overblik over, hvilke instrukser, der er behov for. Disse vil eventuelt kunne tilføjes senere med minimale ændringer af de godkendte modeller. Stereotyperne indeholder tagged values til dokumentation af modellens elementer. Disse dokumentations-tagged values (Definition, Note, Alternativt navn, Lovgrundlag, Eksempel) beskrives i Regel 5.9

 

NOTE om kodede værdier

Kodede værdier kan modelleres på tre måder:

«DKEnumeration», hvor værdierne findes eksplicit som en liste i modellen. Bruges typisk, hvor udfaldsrummet er velforstået, og hvor der ikke forventes ændringer hurtigere end modellens overordnede versioneringscyklus gør muligt. Eksempelvis ugedag: {mandag, tirsdag, onsdag, torsdag, fredag, lørdag, søndag}

«DKKodeliste», hvor værdierne opbevares eksternt, men tilgængeligt på internettet. Se INSPIRE GCM afsnit 9.4.9, 9.5.2 samt Annex G. Dette giver mulighed for dynamisk tilpasning og udvidelse af kodelisten efter behov, samtidig med, at der er et vist mål af styring af historik og proveniens for værdierne.

«DKKlassifikation», hvor værdierne opbevares i en taksonomi - for eksempel i en klassifikationskomponent, som følger OIO-standarden for Klassifikation. Klassifikationskomponenten kan udstyre værdierne med metadata, opdaterings-metadata og dobbelthistorik. En klassifikationskomponent indgår i en fremtidig KL/KOMBIT rammearkitektur. Se afsnit 3.3.2.

For enkelte domæner gælder der regler for, hvordan eksterne data styres og håndteres - eksempelvis INSPIRE reglerne, som gælder for nogle af de geodata, som også er grunddata. Sådanne regler kan overholdes samtidig med, at modelreglerne overholdes.

Domænet skal varetage, at de eksterne data, som domænedata refererer til, er tilgængelige og af den fornødne kvalitet. Ligeledes skal domænet overholde de regler, som gælder for arkivering, og som kan tilsige at eksterne data skal kunne afleveres til arkiv sammen med domænedata.

* Modellen kan udvides med domæne-specifikke stereotyper ligesom Grunddata-stereotyperne kan extendes i domænet fx geodatas DKFeaturetype, som extender DKObjekttype

UML-stereotyper skal anvendes

Nummer:
5.6
Version:
1.1.0
Release Candidate
Regel

Alle UML-elementer tildeles en UML-stereotype.

Rationale

På sigt skal det være muligt, at fortolke modellen til andre modeltyper samt fx datasnitflader. UML kan ikke i sig selv udpege elementernes rolle (modelentitet, datatype, enumeration) i modellen, hvorfor det er nødvendigt, at udvide modellen med disse roller. UML-stereotyper er udvidelser af modelleringssproget, som gør det muligt at specificere yderligere egenskaber, samt at kategorisere model-elementerne. Med stereotyper kan man udpege specifikke klasser som havende bestemte roller i datamodellen, hvilket igen gør det muligt for et eksternt værktøj, at fortolke modellen til fx datasnitflader og ontologier. Stereotyperne tilføjer roller til elementerne og strukturerer de tagged values, som indeholder dokumentationen af modelelementerne (se Note om tagged values).

Implikationer

Følgende stereotyper anvendes i Grunddatamodellen*:

 

  • «DKObjekttype»: Alle forvaltningsobjekter skal modelleres som UML-klasser med stereotypen «DKObjekttype».

  • «DKEnumeration», «DKKodeliste»,«DKKlassifikation»: Attributter med kodede værdier skal modelleres med UML-elementer med stereotyperne «DKEnumeration», «DKKodeliste» eller «DKKlassifikation», som værdisæt - se Note om kodede værdier.

  • «DKDatatype»: Attributter, som ikke er kodede værdier og som ikke tildeles en standardiseret datatype fra ISO (se regel 5.5) skal modelleres med en datatype i samme eller en anden pakke, med stereotypen «DKDatatype», som værdisæt. Se endvidere fodnote til afsnit 2.3

  • «DKEgenskab»: Attributter og associationsender i Grunddatamodellen har stereotypen «DKEgenskab».

  • «DKDomænemodel»: “Rod”-pakken i en afleveret domænemodel markeres med «DKDomænemodel»

Grunddatasekretariatet sørger for, at en UML-profil indeholdende stereotyperne er specificeret.

NOTE om tagged values

UML-elementer kan indeholde ekstra attributter, kaldet tagged values. Ved at anvende tagged values på stereotyperne, kan de på en gang tilføjes alle klasser, der har stereotypen. Disse tagged values kan indeholde specifikke instrukser til det software, som skal fortolke modellen til for eksempel XML schema - se [INSPIRE GCM] afsnit 9.6.3. På nuværende tidspunkt er der ikke overblik over, hvilke instrukser, der er behov for. Disse vil eventuelt kunne tilføjes senere med minimale ændringer af de godkendte modeller. Stereotyperne indeholder tagged values til dokumentation af modellens elementer. Disse dokumentations-tagged values (Definition, Note, Alternativt navn, Lovgrundlag, Eksempel) beskrives i Bilag 3

 

NOTE om kodede værdier

Kodede værdier kan modelleres på tre måder:

«DKEnumeration», hvor værdierne findes eksplicit som en liste i modellen. Bruges typisk, hvor udfaldsrummet er velforstået, og hvor der ikke forventes ændringer hurtigere end modellens overordnede versioneringscyklus gør muligt. Eksempelvis ugedag: {mandag, tirsdag, onsdag, torsdag, fredag, lørdag, søndag}

«DKKodeliste», hvor værdierne opbevares eksternt, men tilgængeligt på internettet. Se [INSPIRE GCM] afsnit 9.4.9, 9.5.2 samt Annex G. Dette giver mulighed for dynamisk tilpasning og udvidelse af kodelisten efter behov, samtidig med, at der er et vist mål af styring af historik og proveniens for værdierne.

«DKKlassifikation», hvor værdierne opbevares i en taksonomi - for eksempel i en klassifikationskomponent, som følger [Klassifikation]. Klassifikationskomponenten kan udstyre værdierne med metadata, opdaterings-metadata og dobbelthistorik. En klassifikationskomponent indgår i en fremtidig KL/KOMBIT rammearkitektur. Se afsnit 3.3.2.

For enkelte domæner gælder der regler for, hvordan eksterne data styres og håndteres - eksempelvis INSPIRE reglerne, som gælder for nogle af de geodata, som også er grunddata. Sådanne regler kan overholdes samtidig med, at modelreglerne overholdes.

Domænet skal varetage, at de eksterne data, som domænedata refererer til, er tilgængelige og af den fornødne kvalitet. Ligeledes skal domænet overholde de regler, som gælder for arkivering, og som kan tilsige at eksterne data skal kunne afleveres til arkiv sammen med domænedata.

* Modellen kan udvides med domæne-specifikke stereotyper ligesom Grunddata-stereotyperne kan extendes i domænet fx geodatas DKFeaturetype, som extender DKObjekttype

UML-stereotyper skal anvendes

Nummer:
5.6
Version:
1.0.0
Udgået
Regel godkendt den:
3. February 2014
Regel udfaset den
20. January 2015
Regel

Alle UML-elementer tildeles en UML-stereotype.

Rationale

På sigt skal det være muligt, at fortolke modellen til andre modeltyper samt fx datasnitflader. UML kan ikke i sig selv udpege elementernes rolle (modelentitet, datatype, enumeration) i modellen, hvorfor det er nødvendigt, at udvide modellen med disse roller. UML-stereotyper er udvidelser af modelleringssproget, som gør det muligt at specificere yderligere egenskaber, samt at kategorisere model-elementerne. Med stereotyper kan man udpege specifikke klasser som havende bestemte roller i datamodellen, hvilket igen gør det muligt for et eksternt værktøj, at fortolke modellen til fx datasnitflader og ontologier. Stereotyperne tilføjer i første omgang bare roller til elementerne (se Note om tagged values).

Implikationer

Følgende stereotyper anvendes i grunddatamodellen:

  • «Objekttype»: Alle forvaltningsobjekter skal modelleres som UML-klasser med stereotypen «Objekttype».
  • «Enumeration», «Kodeliste»,«Klassifikation»: Attributter med kodede værdier skal modelleres med UML-klasser med stereotypen «Enumeration», «Kodeliste» eller «Klassifikation», som værdisæt - se Note om kodede værdier.
  • «Datatype»: Attributter, som ikke er kodede værdier og som ikke tildeles en standardiseret datatype fra ISO (se regel 5.5) skal modelleres med en klasse i samme eller en anden pakke, med stereotypen «Datatype», som værdisæt. Se endvidere fodnote til afsnit 2.3

 

Grunddatasekretariatet sørger for, at en UML-profil indeholdende stereotyperne er specificeret.

NOTE om tagged values

UML-elementer kan indeholde ekstra attributter, kaldet tagged values. Ved at anvende tagged values på stereotyperne, kan de på en gang tilføjes alle klasser, der har stereotypen. Disse tagged values kan indeholde specifikke instrukser til det software, som skal fortolke modellen til for eksempel XML schema - se [INSPIRE GCM] afsnit 9.6.3. På nuværende tidspunkt er der ikke overblik over, hvilke instrukser, der er behov for. Derfor er det indtil videre fyldestgørende, at ordne elementerne med stereotyper, som så på et senere tidspunkt, relativt nemt, eventuelt kan opdateres med relevante tagged values.

 

NOTE om kodede værdier

Kodede værdier kan modelleres på tre måder:

«Enumeration», hvor værdierne findes eksplicit som en liste i modellen. Bruges typisk, hvor udfaldsrummet er velforstået, og hvor der ikke forventes ændringer hurtigere end modellens overordnede versioneringscyklus gør muligt. Eksempelvis ugedag: {mandag, tirsdag, onsdag, torsdag, fredag, lørdag, søndag}

«Kodeliste», hvor værdierne opbevares eksternt, men tilgængeligt på internettet. Se [INSPIRE GCM] afsnit 9.4.9, 9.5.2 samt Annex G. Dette giver mulighed for dynamisk tilpasning og udvidelse af kodelisten efter behov, samtidig med, at der er et vist mål af styring af historik og proveniens for værdierne.

«Klassifikation», hvor værdierne opbevares i en klassifikationskomponent, som følger [Klassifikation]. Klassifikationskomponenten skal udstyre værdierne med metadata, opdaterings-metadata og dobbelthistorik. Klassifikationskomponenten indgår i en fremtidig KL/KOMBIT rammearkitektur. Se afsnit 3.3.2. Når en sådan er på plads, kan udformningen af stereotypen «Klassifikation» færdiggøres.

For enkelte domæner gælder der regler for, hvordan eksterne data styres og håndteres - eksempelvis INSPIRE reglerne, som gælder for nogle af de geodata, som også er grunddata. Sådanne regler kan overholdes samtidig med, at modelreglerne overholdes.

Domænet skal varetage, at de eksterne data, som domænedata refererer til, er tilgængelige og af den fornødne kvalitet. Ligeledes skal domænet overholde de regler, som gælder for arkivering, og som kan tilsige at eksterne data skal kunne afleveres til arkiv sammen med domænedata.

 

 

Eksempler

Figur 8 - Grunddata-stereotyperne i en UML-profil

UML-stereotyper skal anvendes

Nummer:
5.6
Version:
1.1.0
Høringsversion
Ændring

Stereotypnavne ændres med tilføjelsen af præfixet "DK" Nye stereotyper for attributter og relationsender - disse skal indeholde dokumentation qua Bilag 3 note om tagged values til dokumentation tilføjet i “Note om om tagged values”. Stereotypen DKDomænemodel er tilføjet. Den udpeger (ækvivalent med INSPIRE:ApplicationScheme) en pakke som indeholdende rodniveauet af et domænes model. Dertil er grupperingen af Stereotyper ændret. Fodnote om, at domænet kan tilføje egne stereotyper evt via extension af grunddatastereotyperne

Ændringsargumentation

De anvendte navne er reserverede keywords i UML - derfor skulle de ændres - tilføjelse af præfix "DK" giver branding og genkendelighed

Regel

Alle UML-elementer tildeles en UML-stereotype.

Rationale

På sigt skal det være muligt, at fortolke modellen til andre modeltyper samt fx datasnitflader. UML kan ikke i sig selv udpege elementernes rolle (modelentitet, datatype, enumeration) i modellen, hvorfor det er nødvendigt, at udvide modellen med disse roller. UML-stereotyper er udvidelser af modelleringssproget, som gør det muligt at specificere yderligere egenskaber, samt at kategorisere model-elementerne. Med stereotyper kan man udpege specifikke klasser som havende bestemte roller i datamodellen, hvilket igen gør det muligt for et eksternt værktøj, at fortolke modellen til fx datasnitflader og ontologier. Stereotyperne tilføjer roller til elementerne og strukturerer de tagged values, som indeholder dokumentationen af modelelementerne (se Note om tagged values).

Implikationer

Følgende stereotyper anvendes i Grunddatamodellen*:

 

  • «DKObjekttype»: Alle forvaltningsobjekter skal modelleres som UML-klasser med stereotypen «DKObjekttype».

  • «DKEnumeration», «DKKodeliste»,«DKKlassifikation»: Attributter med kodede værdier skal modelleres med UML-elementer med stereotyprne «DKEnumeration», «DKKodeliste» eller «DKKlassifikation», som værdisæt - se Note om kodede værdier.

  • «DKDatatype»: Attributter, som ikke er kodede værdier og som ikke tildeles en standardiseret datatype fra ISO (se regel 5.5) skal modelleres med en datatype i samme eller en anden pakke, med stereotypen «DKDatatype», som værdisæt. Se endvidere fodnote til afsnit 2.3

På egenskaber

  • «DKEgenskab»: Attributter og associationsender i Grunddatamodellen har stereotypen «DKAttribut».

På pakker

  • «DKDomænemodel»: “Rod”-pakken i en afleveret domænemodel markeres med «DKDomænemodel»

Grunddatasekretariatet sørger for, at en UML-profil indeholdende stereotyperne er specificeret.

NOTE om tagged values

UML-elementer kan indeholde ekstra attributter, kaldet tagged values. Ved at anvende tagged values på stereotyperne, kan de på en gang tilføjes alle klasser, der har stereotypen. Disse tagged values kan indeholde specifikke instrukser til det software, som skal fortolke modellen til for eksempel XML schema - se [INSPIRE GCM] afsnit 9.6.3. På nuværende tidspunkt er der ikke overblik over, hvilke instrukser, der er behov for. Disse vil eventuelt kunne tilføjes senere med minimale ændringer af de godkendte modeller. Stereotyperne indeholder tagged values til dokumentation af modellens elementer. Disse dokumentations-tagged values (Definition, Note, Alternativt navn, Lovgrundlag, Eksempel) beskrives i Bilag 3

 

NOTE om kodede værdier

Kodede værdier kan modelleres på tre måder:

«DKEnumeration», hvor værdierne findes eksplicit som en liste i modellen. Bruges typisk, hvor udfaldsrummet er velforstået, og hvor der ikke forventes ændringer hurtigere end modellens overordnede versioneringscyklus gør muligt. Eksempelvis ugedag: {mandag, tirsdag, onsdag, torsdag, fredag, lørdag, søndag}

«DKKodeliste», hvor værdierne opbevares eksternt, men tilgængeligt på internettet. Se [INSPIRE GCM] afsnit 9.4.9, 9.5.2 samt Annex G. Dette giver mulighed for dynamisk tilpasning og udvidelse af kodelisten efter behov, samtidig med, at der er et vist mål af styring af historik og proveniens for værdierne.

«DKKlassifikation», hvor værdierne opbevares i en taksonomi - for eksempel i en klassifikationskomponent, som følger [Klassifikation]. Klassifikationskomponenten kan udstyre værdierne med metadata, opdaterings-metadata og dobbelthistorik. En klassifikationskomponent indgår i en fremtidig KL/KOMBIT rammearkitektur. Se afsnit 3.3.2.

For enkelte domæner gælder der regler for, hvordan eksterne data styres og håndteres - eksempelvis INSPIRE reglerne, som gælder for nogle af de geodata, som også er grunddata. Sådanne regler kan overholdes samtidig med, at modelreglerne overholdes.

Domænet skal varetage, at de eksterne data, som domænedata refererer til, er tilgængelige og af den fornødne kvalitet. Ligeledes skal domænet overholde de regler, som gælder for arkivering, og som kan tilsige at eksterne data skal kunne afleveres til arkiv sammen med domænedata.

* Modellen kan udvides med domæne-specifikke stereotyper ligesom Grunddata-stereotyperne kan extendes i domænet fx geodatas GDFeaturetype, som extender GDObjekttype

Eksempler

Figur 8 - Grunddata-stereotyperne i en UML-profil

Navngivningsregler skal følges

Nummer:
5.7
Version:
1.1.0
Høringsversion
Ændring

Specifikation af at navne på klasser og associationer skal være unikke inden for pakken Reglerne om, at datatyper skal ende på “Type” og at elementer med kodede værdier skal ende på “Værdi” frafaldes

Ændringsargumentation

Ønske om specifikation af unikke associationsnavne, hvilket er nødvendigt hvis modellen skal konverteres til andre modelsprog Minimal konsekvens - eneste operationelle ændring er, at associationer - hvis de ikke allered er det - skal navngives unikt

Regel

Elementer i UML-modellen skal navngives på ensartet vis i hele grunddatamodellen. Navngivning skal være entydig inden for domænet - i praksis inden for UML-pakken.

Rationale

En ensartet navnekonvention giver datamodellen et ensartet udtryk og gør det nemmere at identificere og skelne de forskellige klasser af modelelementer fra hinanden.

Implikationer

Klasser og associationer skal navngives entydigt inden for deres pakke.

 

Klasser, attributter og associationer navngives efter følgende skema:

  • Klasser som repræsenterer forvaltningsobjekter (med stereotypen «DKObjekttype»), som er datatyper («DKDatatype»), klassifikationer («DKKlassifikation»), enumerationer («DKEnumeration») eller kodelister («DKKodeliste») navngives med “UpperCamelCase” - dvs. med stort begyndelsesbogstav i både første ord og alle efterfølgende ord i navnet og uden anvendelse af mellemrum i navnet.

  • Attributter, associationer  og relationsender navngives med “lowerCamelCase” - dvs. med lille begyndelsesbogstav i første ord samt stort begyndelsesbogstav i alle efterfølgende ord i navnet og uden anvendelse af mellemrum i navnet *.

 

*Hvor navnene består af akronymer kan man fravige denne regel; fx. “NUTS1værdi”, “CPRnummer”

 

NOTE: Af hensyn til modellens anvendelse og transformation i software, som ikke kan håndtere de danske tegn Æ, æ, Ø, ø, og Å, å, kan disse eventuelt translittereres til hhv "Ae, "ae", "Oe", "oe", "Aa" og "aa".

 

Navngivningsregler skal følges

Nummer:
5.7
Version:
1.1.0
Gældende
Regel godkendt den:
20. January 2015
Regel

Elementer i UML-modellen skal navngives på ensartet vis i hele grunddatamodellen. Navngivning skal være entydig inden for domænet - i praksis inden for UML-pakken.

Rationale

En ensartet navnekonvention giver datamodellen et ensartet udtryk og gør det nemmere at identificere og skelne de forskellige klasser af modelelementer fra hinanden.

Implikationer

Klasser og associationer skal navngives entydigt inden for deres pakke.

 

Klasser, attributter og associationer navngives efter følgende skema:

  • Elementer som repræsenterer forvaltningsobjekter (med stereotypen «DKObjekttype»), som er datatyper («DKDatatype»), klassifikationer («DKKlassifikation»), enumerationer («DKEnumeration») eller kodelister («DKKodeliste») navngives med “UpperCamelCase” - dvs. med stort begyndelsesbogstav i både første ord og alle efterfølgende ord i navnet og uden anvendelse af mellemrum i navnet.

  • Attributter, associationer  og relationsender navngives med “lowerCamelCase” - dvs. med lille begyndelsesbogstav i første ord samt stort begyndelsesbogstav i alle efterfølgende ord i navnet og uden anvendelse af mellemrum i navnet *.

 

*Hvor navnene består af akronymer kan man fravige denne regel; fx. “NUTS1værdi”, “CPRnummer”

 

NOTE: Af hensyn til modellens anvendelse og transformation i software, som ikke kan håndtere de danske tegn Æ, æ, Ø, ø, og Å, å, kan disse eventuelt translittereres til hhv "Ae, "ae", "Oe", "oe", "Aa" og "aa".

 

Navngivningsregler skal følges

Nummer:
5.7
Version:
1.1.0
Release Candidate
Regel

Elementer i UML-modellen skal navngives på ensartet vis i hele grunddatamodellen. Navngivning skal være entydig inden for domænet - i praksis inden for UML-pakken.

Rationale

En ensartet navnekonvention giver datamodellen et ensartet udtryk og gør det nemmere at identificere og skelne de forskellige klasser af modelelementer fra hinanden.

Implikationer

Klasser og associationer skal navngives entydigt inden for deres pakke.

 

Klasser, attributter og associationer navngives efter følgende skema:

  • Elementer som repræsenterer forvaltningsobjekter (med stereotypen «DKObjekttype»), som er datatyper («DKDatatype»), klassifikationer («DKKlassifikation»), enumerationer («DKEnumeration») eller kodelister («DKKodeliste») navngives med “UpperCamelCase” - dvs. med stort begyndelsesbogstav i både første ord og alle efterfølgende ord i navnet og uden anvendelse af mellemrum i navnet.

  • Attributter, associationer  og relationsender navngives med “lowerCamelCase” - dvs. med lille begyndelsesbogstav i første ord samt stort begyndelsesbogstav i alle efterfølgende ord i navnet og uden anvendelse af mellemrum i navnet *.

 

*Hvor navnene består af akronymer kan man fravige denne regel; fx. “NUTS1værdi”, “CPRnummer”

 

NOTE: Af hensyn til modellens anvendelse og transformation i software, som ikke kan håndtere de danske tegn Æ, æ, Ø, ø, og Å, å, kan disse eventuelt translittereres til hhv "Ae, "ae", "Oe", "oe", "Aa" og "aa".

 

Navngivningsregler skal følges

Nummer:
5.7
Version:
1.0.0
Udgået
Regel godkendt den:
3. February 2014
Regel udfaset den
20. January 2015
Regel

Elementer i UML-modellen skal navngives på ensartet vis i hele grunddatamodellen. Navngivning skal være entydig inden for domænet - i praksis inden for UML-pakken.

Rationale

En ensartet navnekonvention giver datamodellen et ensartet udtryk og gør det nemmere at identificere og skelne de forskellige klasser af modelelementer fra hinanden.

Implikationer
  • Elementer som repræsenterer forvaltningsobjekter (med stereotypen «Objekttype») navngives med “UpperCamelCase” - dvs. med stort begyndelsesbogstav i både første ord og alle efterfølgende ord i navnet og uden anvendelse af mellemrum i navnet.

  • Attributter og relationsender navngives med “lowerCamelCase” - dvs. med lille begyndelsesbogstav i første ord samt stort begyndelsesbogstav i alle efterfølgende ord i navnet og uden anvendelse af mellemrum i navnet.

  • Navne på elementer som er datatyper skal ende på “Type”.

  • Navne på elementer som er klassifikationer, enumerationer eller kodelister skal ende på “Vaerdi”.

NOTE: Af hensyn til modellens anvendelse og transformation i software, som ikke kan håndtere de danske tegn Æ, æ, Ø, ø, og Å, å, anbefales det, at disse translittereres til hhv "Ae, "ae", "Oe", "oe", "Aa" og "aa".

Eksempler

I domænemodellerne for DAGI - Danmarks Administrative Geografiske Inddelinger - og Danske Stednavne findes navne for:

Forvaltningsobjekt-elementer:

  • AdministrativInddeling
  • Menighedsraadsafstemningsomraade
  • SupplerendeBynavn

Datatype-elementer

  • StednavnType

Kodelister

  • BegravelsespladsVaerdi
  • FortidsmindeVaerdi

Attributter

  • valglandsdel
  • afstemningsstedNavn
  • NUTSVærdi
     

Sprogregler skal anvendes

Nummer:
5.8
Version:
1.0.0
Gældende
Regel godkendt den:
3. February 2014
Regel

Dansk skal anvendes ved navngivning af elementer, som indgår i generelle egenskaber.

Den modelansvarlige fastsætter det sprog, som anvendes ved navngivning af domænets elementer.

ISO-standarder følger deres engelske betegnelser (fx “Integer” og “codeList”).

Datamodellen dokumenteres på dansk, se regel 5.9.

Rationale

Idet grunddata er det offentliges forvaltningsgrundlag, beskrives de som udgangspunkt på dansk, som er forvaltningssproget. Nogle grunddata kan imidlertid være underlagt internationale forpligtelser, som forudsætter brug af andre sprog. Fx er en række grunddata omfattet af EU-direktivet INSPIRE og skal som følge heraf genbruge UML-elementer, hvor sproget er engelsk. Det er derfor op til den modelansvarlige for domænet at træffe beslutning om sprog for domænespecifikke elementer.

Implikationer

Det er op til den modelansvarlige at vælge sprog for domænets elementer af modellen. Der kan derfor forekomme modeller, hvor der er en blanding af dansk og andre sprog.

Datamodellen skal dokumenteres

Nummer:
5.9
Version:
1.0.0
Udgået
Regel godkendt den:
3. February 2014
Regel udfaset den
20. January 2015
Regel

Datamodellen skal dokumenteres gennem beskrivelser af elementerne i UML-modellen. Beskrivelserne etableres og vedligeholdes sammen med modellen som beskrevet i bilag 3.

Rationale

Dokumentationen gør det muligt for modellens brugere at forstå modellens elementer. Både når man udvikler og anvender modellen, er det essentielt at kommunikere og forstå betydningsindholdet af de enkelte dele af modellen. Det at dokumentationen er indlejret i datamodellen muliggør automatisk dannelse af et katalog over klasser, attributter og relationer. Yderligere kan dokumentationen indgå i datasnitfladerne, hvis der er ønske herom. Skabelonen for dokumentation i bilag 3 stammer fra INSPIRE, som har et gennemprøvet setup for dokumentation af UML-modeller.

Implikationer

Datamodellens klasser, attributter og relationer skal dokumenteres som beskrevet i bilag 3.

 

 

 

Bilag 3: Dokumentation af datamodellen

Datamodellen skal dokumenteres gennem beskrivelser af elementerne i UML-modellen. Datamodellens klasser, attributter og relationer skal dokumenteres som beskrevet i skabelonen herunder. Skabelonen for dokumentation stammer fra INSPIRE, som har et gennemprøvet setup for dokumentation af UML-modeller [INSPIRE dokumentation].

Dokumentation i UML

Klasser, attributter og relationsender dokumenteres ved brug af Notes-tekstfeltet, som er en del af UML-standarden. Dokumentationen skal følge skabelonerne herunder, således at det er muligt at autogenerere et katalog med dokumentation af datamodellen. Nogle af felterne i skabelonen vil i et modelleringsværktøj kunne autoudfyldes ud fra diagrammet.

Dokumentation af klasser

Klasser i datamodellen beskrives ud fra følgende skabelon:

 

Navn

Navn på klassen i UpperCamelCase. Navnet skal som minimum være entydigt inden for UML-pakken.

Stereotype

Klassens stereotype

Definition

Kort og præcis definition. Kan også indeholde et afsnit med en længere beskrivelse, fx med eksempler og henvisning til definitioner.

Dokumentation af attributter

Klassens attributter beskrives hver især ud fra følgende skabelon:

Navn

Navn på attributten i lowerCamelCase. Navnet skal som minimum være entydigt inden for klassen.

Evt. stereotype

Hvis der er anvendt en stereotype til attributten

Datatype

Standardiseret datatype fra ISO eller et klassenavn for en DataType eller en KodeListe

Multiplicitet

Her angives antalsregler for, hvor mange værdier, attributten kan rumme på en enkelt instans af klassen.

Fx: 0..1, 1..1, 0..*, 0..4, 1..*, 2-4, ...

Definition

Kort og præcis definition. Kan også indeholde et afsnit med en længere beskrivelse, fx formål, referencer, eksempler og kilde.

Dokumentation af relationsender

Relationer, der ender på klassen beskrives hver især ud fra følgende skabelon:

Navn

Entydigt navn på relationsenden i lowerCamelCase. Navnet er som minimum entydigt inden for UML-pakken.

Evt. stereotype

Hvis der er anvendt en stereotype til relationsenden

Kardinalitet

Her angives antalsregler for begrebets deltagelse i relationen.

Fx: 0..1, 1..1, 0..*, 1..*

Definition

Kort og præcis definition. Kan også indeholde et afsnit med en længere beskrivelse, fx formål, referencer og eksempler.

 

Datamodellen skal dokumenteres

Nummer:
5.9
Version:
1.1.0
Høringsversion
Ændring

Reglen ændres til, at dokumentationen skal angives som specificerede tagged values på de enkelte elementer. Der vil blandt andet være felter til beskrivelse af: Definition, Note, Alternativt navn, Lovgrundlag og Eksempel

Ændringsargumentation

Anvendelse af tagged values i stedet for Notes-feltet øger den semantiske struktur af metadata og gør transformationen til tjeneste-data værktøjsneutral. Den øgede strukturering gør det mere tilgængeligt at diversificere udstillingen af metadata.

Regel

Datamodellen skal dokumenteres gennem beskrivelser af elementerne i UML-modellen. Beskrivelserne etableres og vedligeholdes sammen med modellen som beskrevet i bilag 3.

Rationale

Dokumentationen gør det muligt for modellens brugere at forstå modellens elementer. Både når man udvikler og anvender modellen, er det essentielt at kommunikere og forstå betydningsindholdet af de enkelte dele af modellen. Det at dokumentationen er indlejret i datamodellen muliggør automatisk dannelse af et katalog over klasser, attributter og relationer. Yderligere kan dokumentationen indgå i datasnitfladerne, hvis der er ønske herom.

Implikationer

Datamodellens klasser, attributter og relationer skal dokumenteres som beskrevet i bilag 3.

 

NOTE: Nogle domæner anvender store mængder metadata, som har til formål at indgå i brugervendt information om data (forklaringer til rapporter, hjælpetekst på web-sider etc.) Det vil ikke være formålstjenligt, at indlejre disse metadata i selve modellen, men de kan modelleres og distribueres som alle andre data og fordeles gennem den generelle data-arkitektur.

 

 

Bilag 3: Dokumentation af datamodellen

Datamodellen skal dokumenteres ved hjælp af elementerne i UML-modellen.

Modellens klasser og deres attributter beskriver forretningsobjekter og deres egenskaber, ligesom de roller, objekterne har i forhold til hinanden beskrives som roller/relationsender i hver ende af af en association. Disse forretningsobjekter, egenskaber og roller skal beskrives i overensstemmelse med den begrebsmodellering, der er i domænet.

Dokumentation i UML med tagged values

Klasser, attributter og roller/relationsender dokumenteres ved brug af tagged values (se Note om tagged values), som specificeret i tabellen nedenfor. De enkelte tags i dokumentationen modsvarer i videst muligt omfang vidensmodelleringsvokabulariet [SKOS].

Denne strukturerede måde at dokumentere på, muliggør fleksibel generering af tekstdokumentation på baggrund af modellen, ligesom dokumentationen med stor præcision kan transformeres ind i datasnitflader og afledte modeller.

Tagged values som bruges til dokumentation i datamodellen:

 

 

 

 

 

Tag definition

SKOS-ækvivalent

Krav

Indhold

definition

SKOS:definition

Krævet

Objektets/egenskabens/rollens definition. Kort tekst, som entydigt beskriver objektet/egenskaben/rollen -  kan også indeholde et afsnit med en længere beskrivelse, fx formål, referencer og kilde.

note

SKOS:note

Valgfri

Uddybende beskrivelse af objektet/egenskaben/rollen

alternativtNavn

SKOS:altLabel

Valgfri

Andre navne, som objektet/egenskaben/rollen kan have

lovgrundlag

--

Valgfri

Angivelse af det lovgrundlag, som hjemler indsamlingen af data for objektet/egenskaben/rollen

eksempel

SKOS:example

Valgfri

Eksempler på anvendelse af objektet/egenskaben/rollen

Værdierne angives i ren tekst

 

De tagged values, som nævnes i skemaet, er indeholdt i Grunddatamodellens stereotyper, som defineres i regel 5.6 UML-stereotyper skal anvendes.

 

Værktøjsunderstøttelse

I den MDG og base project, som distribueres af modelsekretariatet, er de relevante tagged values indføjet i stereotyperne i en separat gruppe - Grunddata:dokumentation

 

[Figur som viser Class properties med tagged values]
 
Eksempler

[Eksempler på udfyldte tagged values - enten grafisk i EA eller som tabeller for klasse, attribut og relation end]
 

Datamodellen skal dokumenteres

Nummer:
5.9
Version:
1.1.0
Gældende
Regel godkendt den:
20. January 2015
Regel

Datamodellen skal dokumenteres gennem beskrivelser af elementerne i UML-modellen. 

Rationale

Dokumentationen gør det muligt for modellens brugere at forstå modellens elementer. Både når man udvikler og anvender modellen, er det essentielt at kommunikere og forstå betydningsindholdet af de enkelte dele af modellen. Det at dokumentationen er indlejret i datamodellen muliggør automatisk dannelse af et katalog over klasser, attributter og relationer. Yderligere kan dokumentationen indgå i datasnitfladerne, hvis der er ønske herom.

Implikationer

Modellens klasser og deres attributter beskriver forretningsobjekter og deres egenskaber, ligesom de roller, objekterne har i forhold til hinanden beskrives som roller/relationsender i hver ende af af en association. Disse forretningsobjekter, egenskaber og roller skal beskrives i overensstemmelse med den begrebsmodellering, der er i domænet.

Dokumentation i UML med tagged values

Klasser, attributter og roller/relationsender dokumenteres ved brug af tagged values (se Note om tagged values), som specificeret i tabellen nedenfor. De enkelte tags i dokumentationen modsvarer i videst muligt omfang vidensmodelleringsvokabulariet SKOS. Denne strukturerede måde at dokumentere på, muliggør fleksibel generering af tekstdokumentation på baggrund af modellen, ligesom dokumentationen med stor præcision kan transformeres ind i datasnitflader og afledte modeller.

Tagged values som bruges til dokumentation i datamodellen:
Tag definition SKOS-ækvivalent Krav Indhold
definition skos:definition Krævet Objektets/egenskabens/rollens definition. Kort tekst, som entydigt beskriver objektet/egenskaben/rollen -kan også indeholde et afsnit med en længere beskrivelse, fx formål, referencer og kilde.
note skos:note Valgfri Uddybende beskrivelse af objektet/egenskaben/rollen
alternativtNavn skos:altLabel Valgfri Andre navne, som objektet/egenskaben/rollen kan have
lovgrundlag -- Valgfri Angivelse af det lovgrundlag, som hjemler indsamlingen af data for objektet/egenskaben/rollen
eksempel skos:example Valgfri Eksempler på anvendelse af objektet/egenskaben/rollen

Værdierne angives i ren tekst

De tagged values, som nævnes i skemaet, er indeholdt i Grunddatamodellens stereotyper, som defineres i regel 5.6 UML-stereotyper skal anvendes.

Værktøjsunderstøttelse: I den MDG og base project, som distribueres af modelsekretariatet (http://digitaliser.dk/resource/2742281), er de relevante tagged values indføjet i stereotyperne i en separat gruppe - Grunddata:dokumentation 

[Figur som viser Class properties med tagged values] - kommer senere

NOTE: Nogle domæner anvender store mængder metadata, som har til formål at indgå i brugervendt information om data (forklaringer til rapporter, hjælpetekst på web-sider etc.) Det vil ikke være formålstjenligt, at indlejre disse metadata i selve modellen, men de kan modelleres og distribueres som alle andre data og fordeles gennem den generelle data-arkitektur.

Eksempler

[Eksempler på udfyldte tagged values - enten grafisk i EA eller som tabeller for klasse, attribut og relation end]
 

Datamodellen skal dokumenteres

Nummer:
5.9
Version:
1.1.0
Release Candidate
Regel

Datamodellen skal dokumenteres gennem beskrivelser af elementerne i UML-modellen. Beskrivelserne etableres og vedligeholdes sammen med modellen som beskrevet i bilag 3.

Rationale

Dokumentationen gør det muligt for modellens brugere at forstå modellens elementer. Både når man udvikler og anvender modellen, er det essentielt at kommunikere og forstå betydningsindholdet af de enkelte dele af modellen. Det at dokumentationen er indlejret i datamodellen muliggør automatisk dannelse af et katalog over klasser, attributter og relationer. Yderligere kan dokumentationen indgå i datasnitfladerne, hvis der er ønske herom.

Implikationer

Implikationer

Datamodellens klasser, attributter og relationer skal dokumenteres som beskrevet i bilag 3.

NOTE: Nogle domæner anvender store mængder metadata, som har til formål at indgå i brugervendt information om data (forklaringer til rapporter, hjælpetekst på web-sider etc.) Det vil ikke være formålstjenligt, at indlejre disse metadata i selve modellen, men de kan modelleres og distribueres som alle andre data og fordeles gennem den generelle data-arkitektur.

Bilag 3: Dokumentation af datamodellen Datamodellen skal dokumenteres ved hjælp af elementerne i UML-modellen.

Modellens klasser og deres attributter beskriver forretningsobjekter og deres egenskaber, ligesom de roller, objekterne har i forhold til hinanden beskrives som roller/relationsender i hver ende af af en association. Disse forretningsobjekter, egenskaber og roller skal beskrives i overensstemmelse med den begrebsmodellering, der er i domænet.

Dokumentation i UML med tagged values

Klasser, attributter og roller/relationsender dokumenteres ved brug af tagged values (se Note om tagged values), som specificeret i tabellen nedenfor. De enkelte tags i dokumentationen modsvarer i videst muligt omfang vidensmodelleringsvokabulariet [SKOS]. Denne strukturerede måde at dokumentere på, muliggør fleksibel generering af tekstdokumentation på baggrund af modellen, ligesom dokumentationen med stor præcision kan transformeres ind i datasnitflader og afledte modeller.

Tagged values som bruges til dokumentation i datamodellen:
Tag definition SKOS-ækvivalent Krav Indhold
definition skos:definition Krævet Objektets/egenskabens/rollens definition. Kort tekst, som entydigt beskriver objektet/egenskaben/rollen -kan også indeholde et afsnit med en længere beskrivelse, fx formål, referencer og kilde.
note skos:note Valgfri Uddybende beskrivelse af objektet/egenskaben/rollen
alternativtNavn skos:altLabel Valgfri Andre navne, som objektet/egenskaben/rollen kan have
lovgrundlag -- Valgfri Angivelse af det lovgrundlag, som hjemler indsamlingen af data for objektet/egenskaben/rollen
eksempel skos:example Valgfri Eksempler på anvendelse af objektet/egenskaben/rollen

Værdierne angives i ren tekst

De tagged values, som nævnes i skemaet, er indeholdt i Grunddatamodellens stereotyper, som defineres i regel 5.6 UML-stereotyper skal anvendes.

VærktøjsunderstøttelseI den MDG og base project, som distribueres af modelsekretariatet (http://digitaliser.dk/resource/2742281) , er de relevante tagged values indføjet i stereotyperne i en separat gruppe - Grunddata:dokumentation 

[Figur som viser Class properties med tagged values] - kommer senere

Eksempler

[Eksempler på udfyldte tagged values - enten grafisk i EA eller som tabeller for klasse, attribut og relation end]
 

Regler om generelle egenskaber

Nummer:
6
Version:
1.1.0
Gældende
Regel godkendt den:
20. January 2015
Regel

De generelle egenskaber skal understøtte, at grunddata kan anvendes i sammenhæng i et distribueret forvaltningsmiljø. Egenskaberne skal ligeledes sørge for, at brugerne oplever en øget datakvalitet i og med, at data udstilles på en ensartet måde, således at ofte benyttede egenskaber har den samme form bredt ud over grunddata. Yderligere skal reglerne muliggøre en stærk, intelligent beskeddrevet arkitektur. I dette kapitel formuleres reglerne først på forretningsniveau, og efterfølges så af specifikke angivelser af generelle egenskaber, som alle modelentiteter skal have.

 

De generelle egenskaber afføder en række attributter og en datatype, som indgår i grundmønsteret for en modelentitet. Disse vil blive stillet til rådighed af Grunddatasekretariatet 
 
 
 
 
 En skabelon for modellering af en modelentitet, indeholdende de generelle egenskaber, som regelsættes i kapitlet. Modelentiteter i domænernes modeller vil naturligvis indeholde yderligere attributter.

 

 

De generelle egenskaber og deres attributter forklares i de følgende regler.

I reglens implikation angives for hver generel egenskab, om den er obligatorisk eller valgfri:

  • Obligatorisk egenskab: Skal være til stede i domænemodellen og skal modelleres som angivet i dette kapitel.

  • Valgfri egenskab: Skal kun være til stede i domænemodellen, hvis det giver mening inden for domænet. Hvis egenskaben er til stede, skal den modelleres, som angivet i dette kapitel.

I nogle tilfælde kan der ikke stilles krav om, at attributværdien er udfyldt. For hver attribut angives om attributværdien må være tom.

Regler om generelle egenskaber

Nummer:
6
Version:
1.0.0
Udgået
Regel godkendt den:
3. February 2014
Regel udfaset den
20. February 2015
Regel

De generelle egenskaber skal understøtte, at grunddata kan anvendes i sammenhæng i et distribueret forvaltningsmiljø. Egenskaberne skal ligeledes sørge for, at brugerne oplever en øget datakvalitet i og med, at data udstilles på en ensartet måde, således at ofte benyttede egenskaber har den samme form bredt ud over grunddata. Yderligere skal reglerne muliggøre en stærk, intelligent beskeddrevet arkitektur. I dette kapitel formuleres reglerne først på forretningsniveau, og efterfølges så af specifikke angivelser af generelle egenskaber, som alle modelentiteter skal have.

 

De generelle egenskaber afføder tre generelt anvendelige datatyper, som vil blive stillet til rådighed af Grunddatasekretariatet

 

 

 

Figur 10 udgør en skabelon for modellering af en modelentitet, indeholdende de generelle egenskaber, som regelsættes i kapitlet. Modelentiteter i domænernes modeller vil naturligvis indeholde yderligere attributter; i figuren indikeret med “<..>”.

Et eksempel på en modelentitet, der overholder skabelonen i findes i Figur 11.

 

De generelle egenskaber og deres attributter forklares i de følgende regler.

I reglens implikation angives for hver generel egenskab, om den er obligatorisk eller valgfri:

  • Obligatorisk egenskab: Skal være til stede i domænemodellen og skal modelleres som angivet i dette kapitel.

  • Valgfri egenskab: Skal kun være til stede i domænemodellen, hvis det giver mening inden for domænet. Hvis egenskaben er til stede, skal den modelleres, som angivet i dette kapitel.

I nogle tilfælde kan der ikke stilles krav om, at attributværdien er udfyldt. For hver attribut angives om attributværdien må være tom.

Regler om generelle egenskaber

Nummer:
6
Version:
1.1.0
Høringsversion
Ændring

En del omflytninger af elementer pga nymodellering af bitemporalitet påvirker den basale modellering og derved diagrammerne i dette afsnit

Regel

De generelle egenskaber skal understøtte, at grunddata kan anvendes i sammenhæng i et distribueret forvaltningsmiljø. Egenskaberne skal ligeledes sørge for, at brugerne oplever en øget datakvalitet i og med, at data udstilles på en ensartet måde, således at ofte benyttede egenskaber har den samme form bredt ud over grunddata. Yderligere skal reglerne muliggøre en stærk, intelligent beskeddrevet arkitektur. I dette kapitel formuleres reglerne først på forretningsniveau, og efterfølges så af specifikke angivelser af generelle egenskaber, som alle modelentiteter skal have.

 

De generelle egenskaber afføder en række klasser, som indgår i grundmønsteret for en modelentitet. Disse vil blive stillet til rådighed af Grunddatasekretariatet 
 
[Figur, som viser Registreringskonceptet samt GlobalID klasserne i et pakkediagram]
 
Figur 9 - Klasserne med de generelle egenskaber
 
Figur 10 udgør en skabelon for modellering af en modelentitet, indeholdende de generelle egenskaber, som regelsættes i kapitlet. Modelentiteter i domænernes modeller vil naturligvis indeholde yderligere attributter.

 

 

De generelle egenskaber og deres attributter forklares i de følgende regler.

I reglens implikation angives for hver generel egenskab, om den er obligatorisk eller valgfri:

  • Obligatorisk egenskab: Skal være til stede i domænemodellen og skal modelleres som angivet i dette kapitel.

  • Valgfri egenskab: Skal kun være til stede i domænemodellen, hvis det giver mening inden for domænet. Hvis egenskaben er til stede, skal den modelleres, som angivet i dette kapitel.

I nogle tilfælde kan der ikke stilles krav om, at attributværdien er udfyldt. For hver attribut angives om attributværdien må være tom.

Eksempler

Et eksempel på en modelentitet, der overholder skabelonen i findes i Figur 11. [nyt eksempel skal laves]
 Figur 11 - Modellering af forvaltningsobjektet “Køretøj”

Alle modelentiteter skal modelleres med persistent, unik identifikation

Nummer:
6.1
Version:
1.0.0
Gældende
Regel godkendt den:
3. February 2014
Regel

Alle entiteter skal modelleres med persistent, unik identifikation.

 

Rationale

Alle data-objekter, skal have et globalt unikt id, som ikke ændres i data-objektets levetid. Det er nødvendigt at have en unik identifikation af et data-objekt på tværs af grunddatamodellen, for at sikre en fælles høj datakvalitet.

 

Ofte vil data-objektet, ud over den unikke identifikation, have en eller flere forretningsnøgler, fx har en matrikel et matrikelnummer. Men forretningsnøglerne kan ikke stå alene, da grunddatamodellen generelt skal understøtte historik, hvilket betyder, at data-objektet kan have forskellige forretningsnøgler over tid, ligesom den samme forretningsnøgle løbende kan indgå i flere forvaltningsobjekter.

 

Derfor er det essentielt, at objektets identifikation er persistent i hele data-objektets levetid.

 

Ved at lade ID være en HTTP-URI (se Implikation) bliver URI’en “opløsbar”, se

http://en.wikipedia.org/wiki/Dereferenceable_Uniform_Resource_Identifier

 

Dette giver ID’en to funktioner:

  • Global entydig identifikation af en entitet på tværs af Grunddatamodellen og på tværs af øvrige modeller.

  • Reference direkte til data-objektet, således at et givet data-objekt potentielt kan adresseres direkte - også vha. en generisk web-applikation.

Implikationer

Alle entiteter skal modelleres med attributten ‘id’

id
Betydning Unik identifikation af objektet
Værdi Objektets unikke id
Datatype Identifikation
Krav Obligatorisk

 

Datatypen Identifikation.

Datatypen er en del af Grunddatatyperne, som publiceres og vedligeholdes af Grunddatasekretaiatet; se http://digitaliser.dk/group/2494445

Attributterne i Identifikation kan kombineres til en HTTP-URI, som specificeret i IETF RFC 3986 (http-scheme). Denne vil være universelt unik, og vil være opløsbar.

En HTTP-URI kan sammensættes på følgende måde - baseret på IETF RFC 3986, afsnit 3, Syntax Components:

 

Skemaangivelse + “://” + Autoritet + “/” + Sti + “#” + Objektidentifikator

 

 

 

Indhold

Komponent

Værdi

Skemaangivelse “http”
Autoritet “data.gov.dk”
Sti Valgfri, men se nedenfor
Objektidentifikator Valgfri, men se nedenfor

 

HTTP-URI’en skal i sin helhed være universelt unik.

Dette kan opnås på en række måder:

 

 

Det er domænets ansvar, at sikre, at den samlede, identificerende HTTP-URI er universelt unik.

Det anbefales, at Objektidentifikatoren er af typen UUID (Universally Unique Identifier - IETF RFC 4122) - på den måde bliver identifikationen universelt unik uanset hvilket namespace, der anvendes - dette vil være relevant i et fremtidigt, løst koblet data-scenarie, hvorfor der også på sigt vil være behov for, at alle datakilder udstyrer data med UUID.

 

Komponenterne Skemaangivelse, Autoritet og Sti kan sammensættes til et Namespace, som lagres i den ene attribut - namespace i datatypen. Objektidentifikatoren lagres i den anden attribut, som lokalId

 

Attributter

namespace
Betydning Identifikation af et namespace inden for hvilket lokalId er unik
Værdi En HTTP-URI uden Objektidentifikator (Skemaangivelse + “://” + Autoritet + “/” + Sti)
Datatype CharacterString
Krav Obligatorisk
localID
Betydning Identifikation af objektet
Værdi Objektets id
Datatype CharacterString
Krav Obligatorisk

 

Alle modelentiteter skal modelleres med persistent, unik identifikation

Nummer:
6.1
Version:
1.1.0
Høringsversion
Ændring

Ny struktur til datatypen for identifikation

Attributnavn ændret til “globalID”

Anbefaling af UUID fjernet - det er stadig en god og anvendelig løsning til brug for en lokalidentifikator.

Ændringsargumentation

Konsekvensvurdering

For eksisterende modeller vil der være en lille ommodellering - anvendelsen i ny modeller anses for værende svarende til tidligere regel

Regel

Alle entiteter skal modelleres med persistent, unik identifikation.

 

Rationale

Alle dataobjekter og dataobjekters attributter samt relationer, skal kunne identificeres entydigt på tværs af den samlede grunddatamodellen og de mange delmodeller der anvendes som input til den samlede model.

 

Ofte vil data-objektet, ud over den unikke identifikation, have en eller flere forretningsnøgler, fx har en matrikel et matrikelnummer. Men forretningsnøglerne kan ikke stå alene, da grunddatamodellen generelt skal understøtte historik, hvilket betyder, at data-objektet kan have forskellige forretningsnøgler over tid, ligesom den samme forretningsnøgle løbende kan indgå i flere forvaltningsobjekter.

Derfor er det essentielt, at objektets identifikation er persistent i hele data-objektets levetid.

 

Til brug for entydig og uforanderlig identifikation har anvendelse af HTTP-URI vist sin værdi gennem mange års praktisk anvendelse, blandt andet i XML Schema.

En HTTP-URI har yderligere den fordel at den kan anvendes som URL, Uniform Resource Locator. Når HTTP-URIen anvendes som URL, og dermed som et link, gøres det muligt at tilgå yderligere oplysninger om det HTTP-URIen identificerer. URI’en er blevet “opløsbar” ( http://en.wikipedia.org/wiki/Dereferenceable_Uniform_Resource_Identifier )

 

Dette giver det globale id to funktioner:

  • Global entydig identifikation af en entitet på tværs af Grunddatamodellen og på tværs af øvrige modeller.

  • Mulighed for at referere direkte til data-objektet, således at et givet data-objekt potentielt kan adresseres direkte - også vha. en generisk web-applikation.

Implikationer

Alle entiteter skal modelleres med attributten ‘globalID’, med typen GlobalID

 

globalID

 

Betydning

Unik identifikation af objektet

Værdi

Objektets unikke id

Datatype

GlobalID

Krav

Obligatorisk

Eksempel:

Datatypen GlobalID.

 

En instans af GlobalID er sammensat af en instans af datatypen Namespace og en instans af datatypen LokalID. Begge disse er specialiseringer af den standardiserede type CharacterString. Yderligere gælder det, at Namespace og LokalID skal kunne kombineres til en HTTP-URI, som specificeret i IETF RFC 3986 (http-scheme). Denne skal være universelt unik, og vil være opløsbar.

 

En HTTP-URI kan sammensættes på følgende måde - baseret på IETF RFC 3986, afsnit 3, Syntax Components:

 

Skemaangivelse + “://” + Autoritet + “/” + Sti + “#” + Objektidentifikator

 

Indhold:

Komponent

Værdi

Skemaangivelse

“http”

Autoritet

“data.gov.dk”

Sti

Valgfri, men se nedenfor

Objektidentifikator

Værdi som i det mindste er unik inden for domænet

 

HTTP-URI’en skal i sin helhed være universelt unik.

Dette kan opnås på en række måder:

 

 

Det er domænets ansvar, at sikre, at den samlede, identificerende HTTP-URI er universelt unik.

 

Komponenterne Skemaangivelse, Autoritet og Sti kan sammensættes til et Namespace, som modelleres med datatypen Namespace. Objektidentifikatoren modelleres med datatypen lokalID

 

namespace

 

Betydning

Identifikation af et namespace inden for hvilket lokalId er unik

Værdi

En HTTP-URI uden Objektidentifikator (Skemaangivelse + “://” + Autoritet + “/” + Sti)

Datatype

CharacterString

Krav

Obligatorisk

 

lokalId

 

Betydning

Identifikation af objektet

Værdi

Objektets id

Datatype

CharacterString

Krav

Obligatorisk

 

Alle modelentiteter skal modelleres med persistent, unik identifikation

Nummer:
6.1
Version:
1.1.0
Release Candidate
Regel

Alle entiteter skal modelleres med persistent, unik identifikation.

 

Rationale

Alle dataobjekter og dataobjekters attributter samt relationer, skal kunne identificeres entydigt på tværs af den samlede grunddatamodel og de mange delmodeller der anvendes som input til den samlede model.

 

Ofte vil data-objektet, ud over den unikke identifikation, have en eller flere forretningsnøgler, fx har en matrikel et matrikelnummer. Men forretningsnøglerne kan ikke stå alene, da grunddatamodellen generelt skal understøtte historik, hvilket betyder, at data-objektet kan have forskellige forretningsnøgler over tid, ligesom den samme forretningsnøgle løbende kan indgå i flere forvaltningsobjekter.

Derfor er det essentielt, at objektets identifikation er persistent i hele data-objektets levetid.

 

Til brug for entydig og uforanderlig identifikation har anvendelse af HTTP-URI vist sin værdi gennem mange års praktisk anvendelse, blandt andet i XML Schema.

En HTTP-URI har yderligere den fordel at den kan anvendes som URL, Uniform Resource Locator. Når HTTP-URIen anvendes som URL, og dermed som et link, gøres det muligt at tilgå yderligere oplysninger om det HTTP-URIen identificerer. URI’en er blevet “opløsbar” ( http://en.wikipedia.org/wiki/Dereferenceable_Uniform_Resource_Identifier )

 

Dette giver det globale id to funktioner:

  • Global entydig identifikation af en entitet på tværs af Grunddatamodellen og på tværs af øvrige modeller.

  • Mulighed for at referere direkte til data-objektet, således at et givet data-objekt potentielt kan adresseres direkte - også vha. en generisk web-applikation.

Implikationer

Alle entiteter skal modelleres med attributten ‘globalID’, med typen GlobalID - Datatypen stilles til rådighed af modelsekretariatet - se http://digitaliser.dk/resource/2742281

 
globalID
Betydning Unik identifikation af objektet
Værdi Objektets unikke id
Datatype GlobalID
Krav Obligatorisk

Eksempel:

Datatypen GlobalID.

 

En instans af GlobalID er sammensat af en instans af attributten namespace og en instans af attributten lokalID. Begge disse er specialiseringer af den standardiserede type CharacterString. Yderligere gælder det, at namespace og lokalID skal kunne kombineres til en HTTP-URI, som specificeret i IETF RFC 3986 (http-scheme). Denne skal være universelt unik, og vil være opløsbar.

 

En HTTP-URI kan sammensættes på følgende måde - baseret på IETF RFC 3986, afsnit 3, Syntax Components:

 

Skemaangivelse + “://” + Autoritet + “/” + Sti + “#” + Objektidentifikator

 

Indhold:

Komponenter i GlobalID
Komponent Værdi
Skemaangivelse "http"
Autoritet "data.gov.dk"
Sti Valgfri, men se nedenfor
Objektidentifikator Værdi, som i det mindste er unik inden for domænet

 

HTTP-URI’en skal i sin helhed være universelt unik.

Dette kan opnås på en række måder:

 

 

Det er domænets ansvar, at sikre, at den samlede, identificerende HTTP-URI er universelt unik.

Det er væsentligt, at den samlede identifikator er stabil over tid. Derfor kan elementerne Autoritet og Sti ikke opfattes som afspejlende en gældende administrativ kontekst for dataobjektet, som eventuelt ville skulle ændres hvis datas ejerskab eller indhold ændredes. Elementerne udstiller udelukkende semantiske informationer om data, dvs deres logiske struktur og betydning.

Komponenterne Skemaangivelse, Autoritet og Sti kan sammensættes til et Namespace, som modelleres med attributten namespace. Objektidentifikatoren modelleres med attributten lokalID

 

namespace
Betydning Identifikation af et namespace inden for hvilket lokalId er unik
Værdi En HTTP-URI uden Objektidentifikator (Skemaangivelse + “://” + Autoritet + “/” + Sti)
Datatype CharacterString
Krav Obligatorisk
lokalID
Betydning Identifikation af objektet
Værdi Objektets id
Datatype CharacterString
Krav Obligatorisk

 

Alle modelentiteter skal modelleres med status

Nummer:
6.2
Version:
1.0.0
Gældende
Regel godkendt den:
3. February 2014
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
Betydning Forvaltningsobjektets status
Værdi En status
Datatype enumeration, kodeliste, klassifikation
Udfaldsrum Domænespecifik liste, værdien må ikke være tom
Krav Obligatorisk

Der skal i domænemodellerne defineres statustilstande for alle forvaltningsobjekter. Disse statustilstande defineres af den modelansvarlige, og publiceres i den fælles model. Tilstandene kan modelleres som enumeration, kodeliste eller klassifikation (se Note om kodede værdier i afsnit 5.6).

NOTE: Ideelt bør statusser betegnes med de reelle tilstande, ikke senest overståede milepæl. Fx "i brug" frem for "ibrugtaget" - ibrugtaget vil objektet jo vedblive at være.

 

 

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.

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

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

Nummer:
6.3
Version:
1.2.0
Høringsversion
Ændring
1. Afsnittet Registreringstid i Rationale tilføjes en sætning

 fra

"Registreringstid:

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

til

"Registreringstid:

Tidsrummet fra versionen registreres i databasen, indtil den enten erstattes af en nyere version eller afregistreres. Det skal dokumenteres både hvornår data er ændret i kilderegisteret og hvornår data er opdateret på Datafordeleren."

2. Før afsnit to i Implikationer indsættes to afsnit:

"Det skal dokumenterer hvornår hvor grunddataregisteret registrerer ændringen i data. Dette regelsættes af modelreglerne. Hvis der har været en eller flere forudgående processer hos dataleverandører eller andre kildedatabaser, er disse processers tidspunkter ikke registreret  med de generelle egenskabers registreringstidspunkter.

Distribution af data via Datafordeleren tilføjer naturligvis en række yderligere temporale metadata: for eksempel det tidspunkt, hvor Datafordeleren har modtaget data fra grunddataregisteret samt det tidspunkt, hvor data er blevet hentet via en tjeneste på Datafordeleren. Specifikationen af disse tidspunkter regelsættes ikke i modelreglerne, men de indgår som metadata til en tjenestes dataleverance ."

3. Afsnit 2 i Implikationer ændres

 fra

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

til

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

4. Afsnit 3 i Implikationer ændres

 fra

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

til

"Enhver version af et stamdataobjekt identificeres entydigt af objektets unikke identifikation kombineret med attributten registrertidFra og objektets status"

5. Tabel-headers i afsnittet Registrering ændres
fra
'registreringFra', 'registreringTil'
til
'registertidFra', 'registertidTil'
6. Undtagelsen, som findes tilsidst i Implikationer, udgår:
"CVR's modeller er undtaget fra regel 6.3 fsva. attributterne registreringFra og registreringTil, da CVR ikke indeholder de pågældende data"
7. Der indføjes et afsnit: "Eksempler"

Et barn, "Philippa", fødes på Rigshospitalets barselafdeling den 14. december 2022 henimod midnat. Den involverede jordemoder er travlt optaget af en usædvanlig stor mængde komplicerede barnefødsler på dette tidspunkt, og kan ikke afsætte tid til at registrere fødslen i det Centrale Person Register, og alle sekretærer er på tvungen, forceret juleferie. Næste eftermiddag kan en studentermedhjælp kl 12:42  opdatere CPR vha CPRWEB.

Rigshospitalet - registreret i et organisationsregister - er registreringsaktør for opdateringen. Fødselsdatoen (der er tale om en dag) er verificeret af CPR-kontoret, som er virkningsaktør.

Et nyt personobjekt oprettes i CPR: : { registertidFra : 2022-12-15T12:42:00+01:00, registertidTil : Null, virkningFra : 2022-12-14, virkningTil : Null , registreringsaktør : http://data.gov.dk/id/organisation#Rigshospitalet, virkningsaktør : http://data.gov.dk/id/organisation#cprkontoret}

Se yderligere. tilsvarende eksempler i ovennævnte dokument

 

Ændringsargumentation

Det har været nødvendigt, at præcisere anvendelsen af registreringstidspunktet.

Nedenfor følger reglen, med de nævnte ændringer indføjet

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. Det skal dokumenteres både hvornår data er ændret i kilderegisteret og hvornår data er opdateret på Datafordeleren.

 

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.

Det skal dokumenterer hvornår hvor grunddataregisteret registrerer ændringen i data. Dette regelsættes af modelreglerne. Hvis der har været en eller flere forudgående processer hos dataleverandører eller andre kildedatabaser, er disse processers tidspunkter ikke registreret  med de generelle egenskabers registreringstidspunkter.

Distribution af data via Datafordeleren tilføjer naturligvis en række yderligere temporale metadata: for eksempel det tidspunkt, hvor Datafordeleren har modtaget data fra grunddataregisteret samt det tidspunkt, hvor data er blevet hentet via en tjeneste på Datafordeleren. Specifikationen af disse tidspunkter regelsættes ikke i modelreglerne, men de indgår som metadata til en tjenestes dataleverance.

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

Enhver version af et stamdataobjekt identificeres entydigt af objektets unikke identifikation kombineret med attributten registertidFra og objektets status.

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

 

 

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:

registertidFra

BETYDNING

Tidspunktet hvor registreringen er foretaget

VÆRDI

Tidspunkt

DATATYPE

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

KRAV

Obligatorisk

registertidTil

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

Eksempler

Et barn, "Philippa", fødes på Rigshospitalets barselafdeling den 14. december 2022 henimod midnat. Den involverede jordemoder er travlt optaget af en usædvanlig stor mængde komplicerede barnefødsler på dette tidspunkt, og kan ikke afsætte tid til at registrere fødslen i det Centrale Person Register, og alle sekretærer er på tvungen, forceret juleferie. Næste eftermiddag kan en studentermedhjælp kl 12:42 opdatere CPR vha CPRWEB.

Rigshospitalet - registreret i et organisationsregister - er registreringsaktør for opdateringen. Fødselsdatoen (der er tale om en dag) er verificeret af CPR-kontoret, som er virkningsaktør.

Et nyt personobjekt oprettes i CPR: : {  registertidFra : 2022-12-15T12:42:00+01:00, registertidTil : Null, virkningFra : 2022-12-14, virkningTil : Null , registreringsaktør : http://data.gov.dk/id/organisation#Rigshospitalet, virkningsaktør : http://data.gov.dk/id/organisation#cprkontoret}

Se yderligere. tilsvarende eksempler i ovennævnte dokument

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

Nummer:
6.3
Version:
1.0.0
Udgået
Regel godkendt den:
3. February 2014
Regel udfaset den
20. January 2015
Regel

Der udestår en uddybende analyse af, hvordan bitemporale egenskaber og disses samspil med Status modelleres bedst muligt, så der gives den bedste ramme for rekonstruktion af data-objektets historik. Det vurderes at reglerne, som affattet i nærværende dokument, er rudimentære, men tilstrækkelige til at modellering efter dem kan påbegyndes. I en senere version af dokumentet vil reglerne blive præciseret bagudkompatibelt.

Regel

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

 

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 fremfindes i en versioneret form, hvor der er styr på, hvilken status en given version af dataobjektet havde på det 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ør:

Oplysning om hvilken aktør, 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. Begge tidsaspekter modelleres ved anvendelse af attributterne registrering og virkning, som samler information om de forhold, der gør sig gældende i forbindelse med opdatering.

 

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.

 

Alle modelentiteter skal have attributten ‘registrering’

registrering

 

Betydning

dataobjektets registrering

Værdi

Datatypen “RegistreringType”

 

Datatypen RegistreringType har følgende attributter:

 

registreringFra

 

Betydning

Tidspunktet hvor registreringen er foretaget

Værdi

Tidspunkt

Type

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

Udfaldsrum

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

Krav

Obligatorisk

 

registreringsaktør

 

Betydning

Den aktør der har foretaget registreringen

Værdi

Navnet på en aktør eller en reference til en organisationsmodel (se regel 5.10)

Udfaldsrum

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

Krav

Obligatorisk

 

Alle modelentiteter skal have attributten ‘virkning’

registrering

 

Betydning

Forvaltningsobjektets virkning

Værdi

Datatypen “VirkningType”

 

Datatypen VirkningType har følgende attributter:

 

virkningFra

 

Betydning

Tidspunktet hvorfra forvaltningsobjektet har virkning

Værdi

Tidspunkt

Type

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

Krav

Obligatorisk

 

virkningTil

 

Betydning

Tidspunktet hvor forvaltningsobjektets 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

Navnet på en aktør eller en reference til en organisationsmodel (se regel 5.10).

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.

 
 

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

Nummer:
6.3
Version:
1.1.0
Gældende
Regel godkendt den:
20. January 2015
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

Alle modelentiteter bør understøtte beskedfordeling

Nummer:
6.4
Version:
1.0.0
Udgået
Regel godkendt den:
3. February 2014
Regel udfaset den
20. January 2015
Regel

Modelentiteterne i grunddata bør modelleres således, at dataobjektet kommer til at indeholde informationer, som kan forbedre kvaliteten af hændelsesbeskeder, der udsendes i forbindelse med opdatering af dataobjektet. Disse informationer omfatter den forretningsmæssige kontekst, hvori dataobjektet opdateredes, samt den bagvedliggende forretningsmæssige årsag til opdateringen. 

Rationale
Automatiseret beskedfordeling beskrives i kapitel 3.3.3. Der findes på nuværende tidspunkt ikke et samlet billede af, hvordan beskedfordelig skal foregå, hvorfor denne regel er formuleret med det formål, at beskrive rammerne for de data der er nødvendige for beskedfordeling. Yderligere arbejde med fællesoffentlig beskedfordeling kan meget vel resultere i justering af denne regel 
 
Automatiseret beskedfordeling forudsætter, at det for hver ændring af data registreres hvilken forretningssammenhæng, der ligger til grund for ændringen. 
Forretningssammenhængen beskrives med tre parametre: 
  • forretningshændelse, som betegner den begivenhed i virkeligheden (se afsnit 1.3.2), som udløste ændringen i data 
  • forretningsområde - den del af den offentlige forretning, som håndterer hændelsen og derved udvirker ændringen i data 
  • forretningsproces - den manuelle eller it-understøttede proces, hvori forretningsområdet håndterer hændelsen
 
Hændelse, område og proces er udfaldsrum, som typisk vil skulle modelleres af domænet 
  • Forretningshændelser vil typisk (ligesom status - se regel 6.2) være specifikke for det enkelte forvaltningsobjekt - der skal opbygges en datastruktur, der afspejler forretningens viden om hvilke hændelser, der kan påvirke et forvaltningsobjekt 
  • Forretningsområdet kan specificeres ud fra FORM 
  • Forretningsproceser forudsætter en kortlægning af domænets processer
 
De tre udfaldsrum kan modelleres mere eller mindre komplekst - som simple lister, indlejret i modellen eller som reference til eksterne data, enten i form af kodelister eller klassifikationskomponenter - se NOTE om kodede værdier i afsnit 5.6 samt afsnit 3.3.2. 
Den modelansvarlige må afgøre på hvilket niveau modelleringen bedst muligt modsvarer forretningskravene. 
Implikationer

Datatypen RegistreringType tilknyttes attributterne ‘forretningsområde’ og ‘forretningsproces’:

forretningsområde
BETYDNING Det forretningsområde som har opdateret dataobjektet 
VÆRDI Specifikation af et forretningsområde. Domænespecifik liste, værdien kan være tom
DATATYPE enumeration, codeList,klassifikation
KRAV Valgfri
 
forretningsproces
BETYDNING Den forretningsproces, som har opdateret dataobjektet 
VÆRDI Specifikation af en forretningsproces. Domænespecifik liste, værdien kan være tom
DATATYPE enumeration, codeList,klassifikation
KRAV Valgfri

 

Datatypen VirkningType tilknyttes attributten ‘forretningshændelse’:

forretningshændelse
BETYDNING Den forretningshændelse, som afstedkom opdateringen
VÆRDI Specifikation af en forretningshændelse. Domænespecifik liste, værdien kan være tom
DATATYPE enumeration, codeList, klassifikation
KRAV  
 

Alle modelentiteter bør understøtte beskedfordeling

Nummer:
6.4
Version:
1.1.0
Release Candidate
Ændring

Placering af attributterne er justeret ift ny modellering af modelobjektet

Regel

Modelentiteterne i grunddata bør modelleres således, at dataobjektet kommer til at indeholde informationer, som kan forbedre kvaliteten af hændelsesbeskeder, der udsendes i forbindelse med opdatering af dataobjektet. Disse informationer omfatter den forretningsmæssige kontekst, hvori dataobjektet opdateredes, samt den bagvedliggende forretningsmæssige årsag til opdateringen. 

Rationale
Automatiseret beskedfordeling beskrives i kapitel 3.3.3. Der findes på nuværende tidspunkt ikke et samlet billede af, hvordan beskedfordelig skal foregå, hvorfor denne regel er formuleret med det formål, at beskrive rammerne for de data der er nødvendige for beskedfordeling. Yderligere arbejde med fællesoffentlig beskedfordeling kan meget vel resultere i justering af denne regel 
 
Automatiseret beskedfordeling forudsætter, at det for hver ændring af data registreres hvilken forretningssammenhæng, der ligger til grund for ændringen. 
Forretningssammenhængen beskrives med tre parametre: 
  • forretningshændelse, som betegner den begivenhed i virkeligheden (se afsnit 1.3.2), som udløste ændringen i data 
  • forretningsområde - den del af den offentlige forretning, som håndterer hændelsen og derved udvirker ændringen i data 
  • forretningsproces - den manuelle eller it-understøttede proces, hvori forretningsområdet håndterer hændelsen
 
Hændelse, område og proces er udfaldsrum, som typisk vil skulle modelleres af domænet 
  • Forretningshændelser vil typisk (ligesom status - se regel 6.2) være specifikke for det enkelte forvaltningsobjekt - der skal opbygges en datastruktur, der afspejler forretningens viden om hvilke hændelser, der kan påvirke et forvaltningsobjekt 
  • Forretningsområdet kan specificeres ud fra FORM 
  • Forretningsproceser forudsætter en kortlægning af domænets processer
 
De tre udfaldsrum kan modelleres mere eller mindre komplekst - som simple lister, indlejret i modellen eller som reference til eksterne data, enten i form af kodelister eller klassifikationskomponenter - se NOTE om kodede værdier i afsnit 5.6 samt afsnit 3.3.2. 
Den modelansvarlige må afgøre på hvilket niveau modelleringen bedst muligt modsvarer forretningskravene. 
Implikationer

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

forretningsområde
BETYDNING Det forretningsområde som har opdateret dataobjektet 
VÆRDI Specifikation af et forretningsområde. Domænespecifik liste, værdien kan være tom
DATATYPE enumeration, codeList,klassifikation
KRAV Valgfri
 
forretningsproces
BETYDNING Den forretningsproces, som har opdateret dataobjektet 
VÆRDI Specifikation af en forretningsproces. Domænespecifik liste, værdien kan være tom
DATATYPE enumeration, codeList,klassifikation
KRAV Valgfri
forretningshændelse
BETYDNING Den forretningshændelse, som afstedkom opdateringen
VÆRDI Specifikation af en forretningshændelse. Domænespecifik liste, værdien kan være tom
DATATYPE enumeration, codeList, klassifikation
KRAV  
 

Alle modelentiteter bør understøtte beskedfordeling

Nummer:
6.4
Version:
1.1.0
Gældende
Regel godkendt den:
20. January 2015
Regel

Modelentiteterne i grunddata bør modelleres således, at dataobjektet kommer til at indeholde informationer, som kan forbedre kvaliteten af hændelsesbeskeder, der udsendes i forbindelse med opdatering af dataobjektet. Disse informationer omfatter den forretningsmæssige kontekst, hvori dataobjektet opdateredes, samt den bagvedliggende forretningsmæssige årsag til opdateringen. 

Rationale
Automatiseret beskedfordeling beskrives i kapitel 3.3.3. Der findes på nuværende tidspunkt ikke et samlet billede af, hvordan beskedfordelig skal foregå, hvorfor denne regel er formuleret med det formål, at beskrive rammerne for de data der er nødvendige for beskedfordeling. Yderligere arbejde med fællesoffentlig beskedfordeling kan meget vel resultere i justering af denne regel 
 
Automatiseret beskedfordeling forudsætter, at det for hver ændring af data registreres hvilken forretningssammenhæng, der ligger til grund for ændringen. 
Forretningssammenhængen beskrives med tre parametre: 
  • forretningshændelse, som betegner den begivenhed i virkeligheden (se afsnit 1.3.2), som udløste ændringen i data 
  • forretningsområde - den del af den offentlige forretning, som håndterer hændelsen og derved udvirker ændringen i data 
  • forretningsproces - den manuelle eller it-understøttede proces, hvori forretningsområdet håndterer hændelsen
 
Hændelse, område og proces er udfaldsrum, som typisk vil skulle modelleres af domænet 
  • Forretningshændelser vil typisk (ligesom status - se regel 6.2) være specifikke for det enkelte forvaltningsobjekt - der skal opbygges en datastruktur, der afspejler forretningens viden om hvilke hændelser, der kan påvirke et forvaltningsobjekt 
  • Forretningsområdet kan specificeres ud fra FORM 
  • Forretningsproceser forudsætter en kortlægning af domænets processer
 
De tre udfaldsrum kan modelleres mere eller mindre komplekst - som simple lister, indlejret i modellen eller som reference til eksterne data, enten i form af kodelister eller klassifikationskomponenter - se NOTE om kodede værdier i afsnit 5.6 samt afsnit 3.3.2. 
Den modelansvarlige må afgøre på hvilket niveau modelleringen bedst muligt modsvarer forretningskravene. 
Implikationer

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

forretningsområde
BETYDNING Det forretningsområde som har opdateret dataobjektet 
VÆRDI Specifikation af et forretningsområde. Domænespecifik liste, værdien kan være tom
DATATYPE enumeration, codeList,klassifikation
KRAV Valgfri
forretningsproces
BETYDNING Den forretningsproces, som har opdateret dataobjektet 
VÆRDI Specifikation af en forretningsproces. Domænespecifik liste, værdien kan være tom
DATATYPE enumeration, codeList,klassifikation
KRAV Valgfri
forretningshændelse
BETYDNING Den forretningshændelse, som afstedkom opdateringen
VÆRDI Specifikation af en forretningshændelse. Domænespecifik liste, værdien kan være tom
DATATYPE enumeration, codeList, klassifikation
KRAV Valgfri
 

Integrationsregler

Nummer:
IR 0
Version:
1.1.0
Ændring

Nyt regelsæt:

Et sæt af regler, som omhandler grunddataregistrenes aflevering af data til Datafordeleren for videre distribution tænkes publiceret under arbejdstitlen Integrationsregler for Grunddata

Regel

I grunddata data-arkitekturen leveres data fra kilderegistrene til Datafordeleren på måder, som aftales individuelt mellem registrene og Datafordeleren.

De følgende regler gælder for disse data og deres modellering. Reglerne er indtil videre udformet uden Implikations-afsnit. I senere versioner af integrationsreglerne vil reglerne være mere uddybende beskrevet. De er medtaget her, for at skabe opmærksomhed om, at der vil være modelleringsforpligtelser forbundet med dataafleveringen.

Figur xyz Grunddata data-arkitekturen (let forsimplet). En række tjenester leverer data: - Àjourføringstjenester: Kilderegistrene àjourfører data i forbindelse med ejernes myndighedsudøvelse - data kan komme fra andre kilderegister (grønne pile på figuren) eller andetsteds fra (gule) - Opdaterings- og synkroniseringstjenester: Kilderegistrene leverer data til Datafordelern (blå) - Udstillingstjenester: Datafordeleren leverer data til databrugerne (cerise) - som også kan være kilderegistrene

Data som afleveres til Dataforedeleren skal dokumenteres

Nummer:
IR 1
Version:
1.1.0
Ændring

Reglen er ny

Regel

Data som afleveres til Dataforedeleren skal dokumenteres, så det er muligt at anvende de afleverede data. Dokumentationen skal specificere de afleverede datas model og relatere data-elementer til model-elementer

Rationale

For at det er muligt at anvende de afleverede data i datafordeleren må der forefindes dokumentation som udgangspunkt for forståelse og konvertering af data til udstillings- og tjeneste-formål.

Afleverede datas modeller skal relateres til Grunddatamodellen

Nummer:
IR 2
Version:
1.1.0
Ændring

Reglen er ny

Regel

Relationen (mappingen) mellem de afleverede datas model og Grunddatamodellen skal dokumenteres.

Rationale

For at data skal kunne konverteres fra det indleverede format til udstillingsformater (tjenester) er det nødvendigt, at forretningsobjekter, attributter og relationer i de afleverede datas model relateres til Grunddatamodellen - det vil sige til den udstillingsmodel som domænet har indleveret for de samme data og som vil danne udgangspunkt for udstilling på Datafordeleren