Modelregler for grunddata, version 2.0.3

Reglerne i dette dokument er i høj grad opstillet i lighed med de Fællesoffentlige regler for begrebs- og datamodellering (FDA-reglerne) version 2.1. Dette er gjort for at skabe en større genkendelighed mellem reglerne for dem, der arbejder med datamodellering.

Hver regel i disse grunddatamodelregler har et tilhørende unikt nummer angivet før hvert regelnavn. Under den specifikke regel følger et afsnit med rationale og implikationer af den pågældende regel. Derefter ses konkrete eksempler, der illustrerer opfyldelsen af reglen.

Slutteligt vil det være angivet, hvis den pågældende regel kommer fra FDA-reglerne og i så tilfælde, hvilken FDA-regel grunddatamodelreglen baserer sig på.

Reglerne følger en standardiseret notation for at skabe en entydig forståelse af hvilke krav, der er til regelopfyldelsen.

Hver regel følger nedenstående notation:

Grunddatamodelreglerne er opdelt i tre sektioner med hvert deres kapitel. Denne opdeling er lavet for at skabe overskuelighed i læsningen og skelnen mellem reglerne. Det drejer sig om nedenstående:

Dokumentet har følgende indhold:

Kapitel 1 - Introduktion

Her beskrives baggrunden for revisionen og formålet med reglerne.

Kapitel 2 - Læsevejledning

Her beskrives indholdet af reglerne, og hvordan de læses.

Kapitel 3 - Anvendelse af de Fællesoffentlige regler for begrebs- og datamodellering

Her forklares anvendelsen af FDA reglerne i tilblivelsen af denne version af grunddatamodelreglerne.

Kapitel 4 - Regler for modeller

I dette kapitel opstilles alle modelreglerne, som har fokus på datamodellens udformning, dokumentation og læsbarhed. Her opstilles regler for bl.a. modelleringssprog, ejerskab, sprog og anden dokumentation mv.

Kapitel 5 - Regler for modelelementer

I dette kapitel opstilles alle modelelementreglerne, som har fokus på de enkelte elementers udformning og dokumentation.

Kapitel 6 - Regler for grunddataegenskaber

I dette kapitel opstilles regler, som har fokus på indhold i domænemodellen, og som sætter rammer for dataindhold i forretningsobjekterne. Her opstilles regler med betydning for bl.a. grunddataobjekters identifikation og historik. Reglerne udmøntes i specificering af generelle egenskaber for alle modelentiteter.

Rationale:

UML’s klassediagrammer er en standardiseret, tilgængelig og tilstrækkeligt entydig måde at visualisere modeller på, som samtidig er åben for udvidelse og yderligere specificering. Det visuelt enkle udtryk i et UML-diagram kan fungere både som letforståelig repræsentation af forretningens begreber og som kommunikationsmiddel mellem modellører og mellem modellør og programmør. Potentielt vil klassediagrammer kunne anvendes til effektiv kommunikation mellem forretningen og it-leverancen i hele udviklingsprocessen fra idé til løsningsimplementering.

Implikationer:

UML-klassediagrammer skal anvendes til visuelle repræsentationer (diagrammer) af logiske modeller.

Rationale:

For at modeller entydigt skal kunne beskrive de fælles grunddata, og for at de skal være ensartet tilgængelige for anvendere, er det nødvendigt at begrænse hvilke UML-elementtyper, der anvendes. Samtidig skal modellernes dele kunne genanvendes frigjort fra deres oprindelige kontekst – således skabes sammenhængende modeller.

Implikationer: 

Modeller skal bestå af modelementer indeholdt i UML-pakker. UML-klassediagrammer skal anvendes til at udtrykke logiske datamodeller. Følgende UML-elementer kan anvendes:

Rationale:

Ved at anvende stereotyper bliver det muligt at registrere de nødvendige forretnings- og modelleringsmetadata for modeller og modelelementer. Via stereotyper kan elementerne udstyres med tagged values, som indeholder de metadata, der gør dem selvforklarende udenfor den model, de er defineret i. En stereotype er en udvidelse af specifikationen af et UML-element som specificerer dets anvendelse til en bestemt betydning og kontekst. Stereotypen specificerer et sæt af tagdefinitioner. Disse tagdefinitioner udvider de elementer, som har stereotypen med et tilsvarende sæt af tags, som kan bruges til at beskrive elementets forretnings- og modelleringsmetadata. Disse tags kan, for hvert enkelt element, udfyldes med tagged values, der er netop dette elements metadata for den kategori, som tagget repræsenterer.

Implikationer:

Både modeller og modelelementer skal udstyres med stereotyper og tags.

Modellens type indikeres ved hjælp af pakkens stereotype.

Bemærk at Generalisering/specialisering samt primitive datatyper ikke udstyres med stereotype.

Eksempler:

Domænemodeller for grunddata er logiske datamodeller som har til formål at beskrive indhold og struktur af grunddata som bl.a. er tilgængelig på Datafordeleren. Bagved de enkelte grunddataregistre er der ofte en grundlæggende begrebs- og/eller informationsmodel, der beskriver de forretningsmæssige informationer. Ofte vil der være en en-til-en relation mellem forretnings- og dataobjekttyperne i hhv. informationsmodellen og den logiske datamodel. Dog er det ikke et krav, at der skal være en en-til-en sammenhæng. Tilfældet kan også være, at en egenskab i en informationsmodel bliver et selvstændigt dataobjekt i den logiske datamodel og omvendt kan et forretningsobjekt modelleres som en egenskab på et dataobjekt.

Eksempelvis kan en persons efternavn være modelleret som en forretningegenskab til et forretningsobjekt mens det i den logiske datamodel vil være repræsenteret ved sin egen objekttype med tilhørende grunddataegenskaber.

Rationale: 

Det er hensigtsmæssigt, at modellen gives et meningsfyldt og anvendelsesneutralt navn samt en kort beskrivelse, da det er intentionen, at modellen skal kunne læses, anvendes og genbruges af andre. Det vil ligeledes lette formidling, fremsøgning og anvendelse. Derudover angives modellens primære sprog, hvilket giver mulighed for at automatisere videre behandling af termer og definitioner.

Implikationer:

Modeller skal forsynes med meningsfyldte navne, der refererer til det pågældende emneområde og/eller det centrale forretningsbegreb. Derudover skal modellen forsynes med en kort beskrivelse af modellens formål og indhold.

Der kan også, som en kommentar, tilføjes en tekstuel beskrivelse om, hvilke bekendtgørelser og love der er relevante for modellen, mens selve henvisningen til disse skal ske ved præcis angivelse af en juridisk kilde i form af en HTTP-URI, jf. 'Angiv modellens lovgrundlag og kilde'. Til et meningsfyldt navn, anbefales at tage udgangspunkt i det element, der er i fokus for modellen.

Reglen opfyldes ved at angive modellens navn, beskrivelse, modelsprog og modelomfang ved hjælp af ‘modelnavn’, ’kommentar’, ’modelsprog’ og ’modelScope’ (skal angives til ApplicationModel (anvendelsesmodel)).

Eksempel:

title (da) = Elproduktionsanlæg

description (da) = Model for elproducerende kraftværk

language = da

modelScope = application model

Rationale:

Ved at anvende en unik HTTP-URI som identifikator for en model kan HTTP-URIen samtidigt fungere både som entydig identifikator (~entydigt navn) og potentielt som entydig URL (~entydig adresse), hvilket gør den egnet både til entydig identifikation af elementer og til efterfølgende at kunne finde yderligere oplysninger om elementet.

Implikationer: 

Reglen overholdes dels ved at angive den valgte HTTP-URI i tagget 'namespace' og dels ved at angive et prefix (kort betegnelse for modellen) i tagget 'namespacePrefix'. Den valgte HTTP-URI fungerer både som entydig identifikator for selve pakken og som det namespace, pakkens egendefinerede elementer er tilknyttet.

Logiske datamodeller for grunddata skal tilhøre domænet https://data.gov.dk/model/profile. Domænets opbygning overholder 'Retningslinjer for stabile http-URIer' 4.

For UML-modeller: Udfyld tags ‘namespace’ og ‘namespacePrefix’ på modelpakken

Eksempler: 

namespace = https://data.gov.dk/model/profile/energysupplyfacility/

namespacePrefix = ensupplfac

Rationale:

For at en bruger kan se, om en model er relevant og kan anvendes, skal det fremgå hvilken organisation, der er ansvarlig for modellen. Det vil sige er ansvarlig for, at den er blevet udarbejdet, og står inde for at modellens indhold og struktur er retvisende på udgivelsestidspunktet.

Ejeren af data er ikke nødvendigvis ansvarlig for den anvendte model. Der kan for nogle emneområder være adskillelse mellem ejerskab til data og ‘specifikationsansvar’ for de modeller, som beskriver data. For eksempel inden for emneområderne personregistrering og adresseregistrering. Her er ansvaret for specifikation af data fastsat til ansvarlige ministerier (Indenrigs- og Boligministeriet og Klima-, Energi- og Forsyningsministeriet) jf. bekendtgørelser. Data er imidlertid sammenstillet og kvalitetssikret af kommunerne. Information om modelansvar er således meget relevant, når modelløren skal vurdere, om et givet modelelement er det korrekte/gældende udtryk for et forretningsbegreb, som ønskes modelleret.

Implikationer: 

Reglen opfyldes ved at angive den modelansvarlige organisation med modelegenskaben ‘modelansvarlig’.

Eksempler:

 I UML-model:  responsibleEntity (modelansvarlig) = Energistyrelsen

Rationale: 

Ved at klassificere modellerne efter emneområde, i henhold til en fællesoffentlig referencemodel, lettes fremsøgning, genbrug og anvendelse af udstillede modeller. Det giver brugeren mulighed for at bruge emneområderne som indgang til at finde den ønskede model eller det ønskede modelelement uden nødvendigvis at kende et specifikt søgeord.

Implikationer: 

Reglen opfyldes ved at angive modellens emneområde som modelegenskaben ‘emne’.

Eksempel: 

Rationale: 

Ved at modellen forsynes med oplysninger om versionering og seneste opdateringsdato, bliver det lettere for brugeren at vurdere, om en given model eller elementer herfra kan anvendes til et bestemt formål. Brugeren kan blandt andet let afgøre, hvilken version af en specifik model, der er den nyeste, og hvornår der sidst er sket ændringer i modellen. Ændringshistorik skal angives, når der er sket en ændring ift. seneste godkendte version. Ændringshistorikken er en kort beskrivelse af versionen og evetuelle ændringer, der er sket siden sidste version.

Implikationer: 

Reglen opfyldes ved at angive modellens versionsnummer, seneste opdateringsdato og ændringshistorik.

Eksempler: 

modified = 2021-06-03

versionInfo = 2.3.0

versionNotes = Egenskaben "fabrikat" tilføjet klassen "Nacelle".

Rationale: 

Et vigtigt element for domænemodellerne er, at de kan sammenholdes på tværs af domæneområder. For at en sammensætning kan ske med succes, er det vigtigt, at modellerne er ensartede og kombinerbare. Grunddatamodelregler skal sikre dette. Det er Grunddata Arkitekturforums opgave at kontrollere om reglerne er overholdt. At en offentliggjort domænemodel er kvalitetssikret af Grunddata Arkitekturforum er en væsentlig oplysning for brugeren af domænemodellerne. Derfor denne regel om, at oplysning om Grunddata Arkitekturforums godkendelse skal fremgå af modellen.

En godkendelse omfatter dels den modeltekniske godkendelse ift. modelreglerne samt den forretningsmæssige godkendelse. Forretningsgodkendelsen skal sikre at domænemodellen repræsenterer den forretning, som modellens grunddata indgår i. En godkendelse er derfor betinget af, at registerejer kan dokumentere over Grunddata Arkitekturforum, at der i forbindelse med modellens tilblivelse eller ændring, er inddraget relevante forretningsmæssige overvejelser bl.a. hensyn til aktører såsom anvenderne.

Implikationer: 

Nedenstående informationer skal angives til modellen.

Eksempler: 

approvalStatus = approved

approvedBy = Grunddata Arkitekturforum

approvedBy = Grunddata Modelsekretariatet

¹ Opdatering af tjenester er nødvendig

² Opdatering af tjenester er mulig men ikke nødvendig

³ Tjenester uændrede

Rationale: 

For at brugerne af en given model skal kunne forvisse sig om en models potentielle anvendelse og relevans, skal det være muligt at kunne tilgå udsagn om modellens status.

Implikationer: 

Godkendte og udstillede domænemodeller kan kun have modelstatus stabil ("stable"). Forslag til domænemodeller, som sendes til Modelsekretariatet til konformanstjek, skal have angivet modelstatus som 'under udvikling' ("development"). Når modellen er godkendt ændrer Modelsekretariatet modelstatus til 'stabil' ("stable").

Reglen opfyldes ved at angive modellens status ved hjælp af modelegenskaben ‘modelstatus’:

Eksempler: 

modelStatus = stable

Rationale: 

Ved at synliggøre og dokumentere sammenhængen mellem lovgrundlag og forretningsmæssige modeller fremmes juridisk og organisatorisk interoperabilitet.

Ved at synliggøre kilder, som modellen tager udgangspunkt i, fremmes ensartethed mellem modeller, der bygger på samme kilder.

Implikationer: 

Man skal undersøge, om der findes lovmæssige rammer omkring modellen, og i så fald skal disse beskrives.

Reglen opfyldes ved at specificere henvisninger til love og bekendtgørelser med egenskaben 'juridisk kilde' på modelniveau ved angivelse af ELI-URI-referencer (European Legislation Identifier), som præsenteres på Retsinformation.dk. Skal der angives flere henvisninger skal disse adskilles af |||

Andre henvisninger til nationale og internationale standarder samt øvrige kilder kan beskrives med egenskaben 'kilde'.

Eksempler:

legalSource = https://www.retsinformation.dk/eli/lta/2020/125 ||| https://www.retsinformation.dk/eli/lta/2018/864

source = https://publications.europa.eu/resource/authority/bkc/008.11.01.1600

Rationale: 

Klassifikation er i denne sammenhæng anvendelse af en kontrolleret mængde af veldefinerede klassifikationsemner. Det er vigtigt, at det bliver muligt entydigt at referere til et klassifikationsemne (en instans) i en klassifikation, ligesom man bør kunne få tilstrækkelig information om klassifikationsemnet og skabe relationer mellem emner på tværs af modeller og systemer.

Klassifikationer skal modelleres til genbrug, og derfor bør disse kontrollerede udfaldsrum også løftes ud af modellerne og fremstå som selvstændige modeller. Det vil betyde at flere modeller kan referere til samme klassifikation, og at klassifikationen kan udvides eller indsnævres uden behov for revision af de refererende modeller.    

Implikationer: 

Når klassifikationer modelleres med UML optræder klassifikationsemnerne som værdier i en enumeration med stereotypen «DKEnumeration», og disse skal placeres i en selvstændig pakke med stereotypen «DKKlassifikationsmodel».

Hvis klassifikationen findes i et klassifikationsregister, skal en kodeliste med stereotypen «DKKodeliste» anvendes. Der skal henvises til den eksterne kodeliste.

¹ f.eks. CSV, SKOS, XML

² f.eks. PDF, html

Rationale:

Domænemodellerne (UML datamodeller) tjener to formål:

For at en domænemodel via dens diagrammer kan skabe en god kommunikation mellem registerejer og anvender er det vigtigt, at UML diagrammerne er læsbare og forståelige. Derfor oplistes i denne regel nogle basale konventioner for, hvordan diagrammer bør opstilles, så god kommunikation understøttes.

Ensartet navngivning af diagrammer på tværs af grunddatamodellerne er forudsætningen for, at grunddata objekttypekataloget automatisk kan dannes, og at grunddataregistrene fremstår ensartet heri. Det gør det nemmere for anvenderne at sammenligne og vurdere grunddataregistrenes indhold og karakteristika.

Implikationer:

Lav diagrammer til domænemodeller efter disse konventioner:

Teksterne skal være frie fra klasser etc.

Del op i flere diagrammer hvis indholdet ikke kan være i et diagram

Ofte er det muligt at omrokere klasser, så man undgår krysende relationer

Ofte er det muligt at omrokere klasser, så relationer er vand- eller lodrette

Rationale: 

Det er hensigtsmæssigt, at modellens elementer får meningsfyldte betegnelser, da det er intentionen, at modellen skal kunne læses, anvendes og genbruges af andre. Det vil sige, at selvom man principielt kan betegne et element med et navn, som ikke i sig selv er meningsgivende, fx KA00045, så bør man vælge en betegnelse, der afspejler den i emneområdet anvendte term, og udpeger det begreb, som elementet faktisk skal repræsentere, fx ‘Vindkraftanlæg’ [Allemang 2008:310].

Implikationer:

Modelelementer, herunder klasser, associationer, associationsender og egenskaber skal forsynes med UML-navne, der afspejler anvendt terminologi inden for emneområdet.

Eksempler: 

Rationale: 

Sporbarhed af modelelementers udvikling, fra begrebsmodel frem til teknisk implementering, kræver entydig identifikation af elementerne. Et middel til sammenhæng mellem modeller og mellem data opnås ved brug af unikke, entydige identifikatorer. W3C anbefaler brug af HTTP-URI, jf. W3C 2017 36.

HTTP-URI har både funktion som entydig identifikator (~ entydigt navn) og potentielt som entydig URL (~ entydig adresse), hvilket gør den egnet både til entydig identifikation af elementer og til efterfølgende at kunne finde yderligere oplysninger om elementet.

Implikationer: 

Identifikatorer dannes som en fuldt kvalificeret HTTP-URI ved en sammensætning af:

Notér at UML-elementet Generalisering (Generalization), som eneste UML-element, ikke forsynes med dette tag.

Eksempler: 

Modelpakken for modellen over energiforsyningsanlæg har URI: https://data.gov.dk/model/profile/energysupplyfacility/

Fragmentnavnet for et element (en klasse) er: EnergySupplyFacility

Som en kombination af disse to dannes den fulde HTTP-URI for elementet: https://data.gov.dk/model/profile/energysupplyfacility/EnergySupplyFacility

Rationale: 

Ved at forsyne modelelementer med termer i et naturligt sprog, afspejles terminologien i emneområdet og dermed understøttes fremsøgning og genbrug af modelelementer. Med naturligt sprog skal forstås skriftsprog, der følger det pågældende sprogs retskrivning og ikke programmeringskonventioner såsom CamelCase og sammensætningen af ord med understregning eller bindestreg. Termerne skal dermed ikke yderligere behandles for at kunne indgå og forstås som termer i en traditionel ordliste.

Implikationer: 

Det er de termer, som naturligt anvendes i emneområdet, der skal registreres. Term skal i denne sammenhæng forstås som et udtryk eller en betegnelse, der sprogligt udpeger et begreb, og som dermed har en specifik betydning i et fagsprog.

Som minimum registreres den foretrukne term, men såfremt et begreb kan udtrykkes ved flere synonyme accepterede eller frarådede termer, så anbefales det at disse også registreres, selvom det ikke er et krav. Termer registreres ved hjælp af elementegenskaberne ‘foretrukken term’, accepteret term’ og ‘frarådet term’.

UML-modeller: Udfyld tagget ‘prefLabel’ og evt. ‘altLabel’ og ‘deprecatedLabel' på modelelementet med termer som de naturligt anvendes i emneområdet.

Eksempler: 

prefLabel (da): vindkraftanlæg

altLabel (da): vindturbine

deprecatedLabel (da): vindmølle

Rationale: 

Modelelementers betegnelser skal understøtte genbrug. En ensartet navnekonvention giver modellen et ensartet udtryk, og gør det nemmere at identificere og skelne de forskellige elementer fra hinanden.

Implikationer:

Logiske datamodeller:

Vedrørende termer som angives som tagværdier gælder det jf. 'Angiv termer i et naturligt sprog'

Eksempler:

Rationale:

For at sikre at elementer anvendt i en model forstås på samme måde ved alle anvendelser, er det nødvendigt at gøre rede for betydningen ved fyldestgørende beskrivelse. Dette er grundlaget for en bred anvendelse og for minimering af fejltolkninger.

Implikationer:

Reglen opfyldes ved at tilknytte en beskrivelse eller definition på dansk til alle navngivne modelelementer. Supplerende bemærkninger eller oplysninger kan eventuelt tilføjes som en kommentar, og ligeledes kan eksempler eventuelt angives.

Bemærk at denne regel sætter krav om tilstedeværelsen af en definition, og at reglen 'Udarbejd strukturerede definitioner på en standardiseret måde' og 'Udarbejd anvendelsesneutrale definitioner' supplerer denne regel ved at sætte krav til selve udformningen af definitionen.

Elementegenskaberne 'definition', 'kommentar' og 'eksempel' anvendes som vist herunder. Man kan, hvis der er behov for det, supplere med en 'anvendelsesnote' om, hvordan elementet skal forstås netop i et pågældende datasæt eller i det it-system, hvor det skal anvendes.

Eksempler: 

definition (da) = kraftværk som omdanner vindenergi til elektricitet

comment (da) = vindkraftanlæg er typisk opført efter 1970

example (da) = vindmøllen i Tvind

applicationNote (da) = kun vindkraftanlæg på land indgår

Rationale: 

Ved at udarbejde indholdsdefinitioner får man korte, klare og korrekte definitioner, som på entydig og robust vis formidler betydningen af et begreb, ligeledes undgås en række uhensigtsmæssigheder, som andre definitionstyper har (se eksempler på andre definitionstyper under afsnittet ‘eksempler’ herunder).

Implikationer: 

Kort fortalt skal man tilstræbe at definere et begreb ved at angive nærmeste overbegreb samt karakteristiske træk. dvs. man skal anføre, hvad begrebet er for “en slags” og hvad det, der er karakteristisk ved netop denne slags i forhold til andre begreber med samme direkte overbegreb.

Ved definition af elementer skal man udtrykke sig så kort, klart og korrekt som muligt.

I henhold til reglen om sammenhæng mellem lovgrundlag og modeller, bør det undersøges om gældende lovgivning på området definerer det relevante begreb, og hvis dette umiddelbart kan anvendes, er det ikke nødvendigt at opfylde dette krav om en struktureret form.

Eksempler: 

Rationale:

Hvis man lader anvendelseskonteksten indsnævre definitionen af elementet risikerer man, at udelukke genbrug eller man risikerer uhensigtsmæssig brug af elementet i andre modeller.

Implikationer:

Definitionen må ikke indeholde elementer, som udtrykker en uhensigtsmæssig indsnævring af begrebet ved for eksempel at beskrive tekniske, organisatoriske eller politiske afhængigheder. Supplerende kontekstafhængige kommentarer eller eksempler skal ikke indgå i definitionen, da disse oplysninger eventuelt ikke er relevante for definitionen og kan være begrænsende for bred anvendelse af begrebet.

Eksempler:

Rationale: 

Ved at synliggøre og dokumentere sammenhængen mellem lovgrundlag og modelelementer fremmes juridisk og organisatorisk interoperabilitet. I modelleringsarbejdet bør begreber fra lovgrundlag anvendes så vidt muligt.

Implikationer: 

Termer og definitioner af begreber skal, i det omfang det er muligt, hentes fra gældende lovgivning på området, og kildehenvisninger bør angives for begrebet.

Det bør undersøges om gældende lovgivning på området definerer det relevante begreb, og hvis dette umiddelbart kan anvendes, er det ikke nødvendigt at opfylde reglen om en struktureret form jf. 'Udarbejd strukturerede definitioner på en standardiseret måde'. Hvis lovgivningens definition af et givet begreb derimod vurderes at være uanvendelig, udarbejdes en ny definition samtidigt med at lovgivningens definition medtages i kommentar (rdfs:comment) med en forklaring på, hvorfor den er uanvendelig.

Reglen opfyldes ved at specificere henvisninger (med HTTP-URIer) til love og bekendtgørelser med egenskaben 'juridisk kilde' og henvisninger til nationale og internationale standarder samt øvrige kilder med egenskaben 'kilde'.

Eksempler: 

legalSource = https://www.retsinformation.dk/eli/lta/2015/1736

source = Finscreening af havarealer til etablering af nye havmølleparker med direkte forbindelse til land, https://ens.dk/sites/ens.dk/files/Vindenergi/1-0_finscreening_af_havarealer_til_etablering_af_nye_havmoelleparker_med_direkte_forbindelse_til_landf2137918451137918144.pdf, 2022 (set den 31/8-2022)

Rationale: 

Logiske modeller bliver først udtømmende beskrivelser af data, når de angiver datatyper for egenskaber. Datatyperne udtrykker på en konsistent måde det udfaldsrum, som egenskaben har. Datatyper skal dog være platforms- og systemneutrale for at kunne anvendes i definition af fælles logiske modeller.

Først og fremmest er det væsentligt, at de anvendte datatyper kan forstås og fortolkes, hvorfor deres definition skal være entydig og publiceret. Yderligere gælder det, at genkendelighed og genbrugelighed øges, hvis de anvendte datatyper tages fra et så lille udvalg af publicerede typer som muligt.

Implikationer: 

Standardiserede primitive datatyper i modellen skal hentes fra ISO/Dansk Standard (DS)

En ikke-udtømmende liste over ISO og danske standarder, som kan anvendes til grunddata:

Rationale: 

Til grunddataregistre er der brug for differentiering af håndtering af historik. Der skelnes mellem tre typer:

Nogle forretninger er opbygget sådan, at de indsamler og registrerer data med bestemte mellemrum, f.eks. indsamling af geodata vha. flyfotos. Det gør, at det ikke er muligt at fastslå, hvornår en ændring i virkeligheden har fundet sted. I sådanne registre har man heller ikke mulighed for at registrere data om fortiden. Man kan f.eks. ikke registrere i dag, at et hus så sådan og sådan ud fra 1980 til 1995. Andre typer forretninger er opbygget sådan, at noget først eksisterer, når det er registreret. Man er f.eks. først forsikret, når ens oplysninger står i it-systemet. I nogle forretninger er der m.a.o. ikke et forretningsbehov for virkningshistorik, eller muligheden for virkningshistorik er bevidst valgt fra. I disse tilfælde angives objekttypens historikmodel til "registreringshistorik".

I andre forretninger er det nødvendigt at kunne håndtere virkningshistorik for forretningsobjekterne, dvs. at forretningen skal kunne holde styr på både, hvordan deres forretningsobjekter var i fortiden, og på hvordan de er lige nu (og evt. også på hvordan de vil være i fremtiden, hvis relevant). I disse tilfælde angives objekttypens historikmodel til "bitemporalitet".

Der kan være tilfælde, hvor et register ikke håndterer historik. En objekttype med ingen historik er dog ikke en option for grunddata. Her vil som minimum registreringstiden forventes at være angivet.

Implikationer: 

Reglen opfyldes ved at angive historikmodel som modelelement egenskab. Opfyldelse af regel 'Grunddataobjekttyper bør understøtte virkningstid' skal ske i overensstemmelse med den angivne historikmodel.

Eksempler: 

historikmodel: bitemporalitet

Rationale: 

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

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

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

Implikationer:

Hver UML-klasse med stereotypen DKObjekttype skal modelleres med følgende attribut:

Modeleksempler:

Dataeksempler:

id = http://data.gov.dk/geodanmark/1032949295

id = 811cd589-7d11-43e9-86a8-6c1e9c03e2ec

id = http://data.gov.dk/Matriklen/Jordstykke/339085

Rationale: 

Det er vigtigt, at bevare datagrundlaget for (rets)reglers forvaltning, så man til enhver tid kan fremfinde de data, der var aktuelle engang, og man kan dokumentere trufne beslutninger over for borgere og virksomheder. Ved at håndtere registrering og afregistrering af dataobjektversioner ved hjælp af tidsstempling, gennemgår grunddataobjekterne en registreringshistorik, og man kan hermed leve op til forventningen om sporbarhed.

Derfor skal grunddataobjekter modelleres med et registreringstidsinterval - det vil sige tidsintervallet, hvor en version anses for at være ajour i informationssystemet.

En dataobjektversionregistrering foretages af en aktør (som kan være et it-system) og resulterer i en registreret dataobjektversion. Aktøren betegnes registreringsaktør.

Implikationer:

Hver UML-klasse med stereotypen DKObjekttype skal modelleres med følgende egenskaber:

Modeleksempler:

Dataeksempler:

registreringFra = 2021-06-21T10:45

registreringTil = Null

registreringTil = 2021-08-21T11:57

registreringaktør = Geodatastyrelsen

registreringaktør = Matriklens informationssystem

Rationale: 

Bestemte forretninger kan have behov for at kunne holde styr på både hvordan deres forretningsobjekter var i fortiden, hvordan de er lige nu, og evt. også hvordan de vil være i fremtiden. Man skal m.a.o. kunne holde styr på alle tilstande som et forretningsobjekt har befundet sig i, befinder sig i lige nu, og (evt.) vil befinde sig i ude i fremtiden; og ikke kun på forretningsobjektets nuværende tilstand. Et informationssystem der understøtter sådan en forretning giver mulighed for at registrere, hvornår i virkeligheden et forretningsobjekt har ændret sig.

Sådan en forretning er eksempelvis Danmarks Administrative Geografiske Inddeling (DAGI), hvis informationssystem giver mulighed for i dag at registrere, at to kommuner vil sammenlægges om f.eks. et år. Man kan både se, hvordan kommunernes grænser ser ud i dag, hvordan de så ud for et år siden, og hvordan de vil se ud om et år.

Et virkningstidsinterval er afgrænset af tidspunktet hvor tilstanden i virkeligheden begynder at eksistere, og tidspunktet hvor tilstanden stopper med at eksistere. virkningstidsintervallet angives med egenskaberne virkningFra og virkningTil.

Hvis et informationssystem understøtter virkningshistorik, skal der for grunddata, også registreres hvem der er virkningsaktøren, dvs. hvilken aktør som afstedkommer fødslen eller ændringen af forretningsobjektet.

En aktør kan være navnet på den organisation eller det informationssystem, som har afstedkommet ændringen. Registerejeren bør tage højde for eksterne kendskab til relevante aktører, når virkningsaktører angives. Eksempelvis kan registreringsaktøren for en kommuneændring i DAGI være Styrelsen for Dataforsyning og Effektivisering, mens virkningsaktøren, som har forårsaget ændringen, kan være Indenrigs- & Boligministeriet.

Implikationer:

Som hovedregel bør alle grunddataobjekttyper indeholde virkningstid, men jf. ovenstående er det ikke meningsfuldt for alle grunddataregistre at operere med denne information. Krav om virkningstid kan dispenseres for, hvis registerejer kan godtgøre, at bitemporalitet hverken er relevant fra et forvaltningsmæssigt perspektiv eller et anvenderperspektiv. I forbindelse med afklaringen kan det være relevant, at gennemføre en særskilt høring om emnet blandt anvendere og andre registre. En dispensation kan gøres betinget og f.eks. kan det være et krav, at spørgsmålet genbesøges ved større ændringer af det bagvedliggende forvaltningssystem. Dispensation kan gives af Grunddata Arkitekturforum.

Er bitemporalitet angivet som historikmodel skal følgende egenskaber angives:

Modeleksempler:

Dataeksempler:

virkningFra = 2021-06-21T10:45

virkningFra = 1938-12-24

virkningFra = 1844-01-01 (til angivelse af kun årstal)

virkningTil = Null

virkningTil = 1945-05-05

virkningsaktør = Tinglysningsretten

virkningsaktør = Matriklens informationssystem

Rationale: 

forretningsobjekter gennemløber typisk en livscyklus. Forretningsdomænet kan opstille regler for hvilke statusser, der er gyldige for et givet objekt, og for, hvordan forretningsobjektet 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.

Et grunddataobjekts livscyklus må ikke være i strid med angivelsen af virkningstid.

Implikationer:

Hver UML-klasse med stereotypen DKObjekttype bør modelleres med status. Angivelse af status er vel at mærke kun relevant såfrem forretningsobjektet gennemløber en livscyklus. Den klassifikation som bruges til at angive status skal have mere end én værdi i sit udfaldsrum.:

Modeleksempler:

Dataeksempler:

Status = i høring

Status = godkendt

Status = afvist

Rationale: 

For at give brugeren af grunddata viden om, hvorfor og hvordan data er blevet ændret, bør grunddataobjekter indeholde information om

Implikationer:

Hver UML-klasse med stereotypen DKObjekttype bør modelleres med følgende attributter:

Modeleksempler:

Dataeksempler:

forretningshændelse = Arealændring på Jordstykke

forretningsproces = Fotogrammetrisk ajourføring