Vejledning i begrebs-og datamodellering

Du finder den fulde vejledning til hvordan man udarbejder begrebs- og datamodeller i overensstemmelse med de Fællesoffentlige regler for begrebs- og datamodellering v.2.1 på GitHub. Her kan du også bruge issue-funktionalitet til at stille spørgsmål, samt komme med kommentarer og forbedringsforslag til vejledningen.

Nedenfor på denne side findes rollebaseret hjælp til at finde det mest relevante vejledning.

Til ledelse, fx CIO/CTO og kontorchefer Her er den information om de fællesoffentlige modelregler, som det øvre ledelseslag har fordel af at kende
Til projektleder/Product Owner Når produkter og projekter indeholder data bør disse dokumenters grundigt både af hensyn til produktets/projektets egen kvalitet og af hensyn til intergrationer og fremtidig anvendelse. Derudover kan især projekter der går på tværs af organisatoriske eller faglige skel have glæde at blive enige om forståelsen af centrale begeber for at sikre den gode kommunikation.
Til udviklere
Til modellører, informations- og dataarkitekter
Er du ny modellør? Hvis modellering er en ny disciplin du skal til at udføre, forventer vi som udgangspunkt at du vil have glæde af at læse hele vejledningen. Afhængigt af dine umiddelbare opgaver, kan særligt relevante startsteder måske være:
Er modelreglerne nye for dig? Hvis du har erfaring med modellering, men ikke har arbejdet med de fællesoffentlige regler for begrebs- og datamodellering før, vil disse afsnit måske være af særlig interesse for dig
Hjælp til finde modeller
Find vejledning til en bestemt regel Her finder du hurtigt det i vejledning der er mest relevant i forbindelse med en bestemt regel.
01 - Brug UML som det visuelle modelsprog
02 - Brug kun udvalgte UML-elementer
03 - Brug UML-stereotyper
04 - Udstil modellen online
05 - Gør modellen tilgængelig i maskinlæsbart format
06 - Angiv meningsfyldte navne og beskrivelser for modeller
07 - Angiv identifikation af modeller
08 - Angiv den modelansvarlige organisation
09 - Angiv emne for modellen
  • Anbefalede emnesystematikker
    • FORM- Fællesoffentlig Reference Model klassificerer offentlige opgaver
    • KLE- KL Emnesystematik: Taksonomi over kommunale opgaver
  • Læs regelteksten
  •  
10 - Angiv modellens version
11 - Modellen skal forretningsgodkendes
12 - Angiv modellens modelstatus
13 - Angiv modellens lovgrundlag
14 - Etablér sammenhæng mellem modeller
15 - Modeller klassifikationer til genbrug
16 - Angiv meningsfyldte UML-navne for modelelementer
17 - Giv alle modelelementer en identifikator
18 - Angiv termer i et naturligt sprog
19 - Brug standardiserede konventioner for angivelse af navne
20 - Udarbejd definitioner eller beskrivelser af modellens elementer
21 - Udarbejd strukturerede definitioner på en standardiseret måde
22 - Udarbejd anvendelsesneutrale definitioner
23 - Angiv modelelementers lovgrundlag
24 - Definér kun nye modelelementer når det er nødvendigt
25 - Sammensæt anvendelsesmodeller af elementer fra kernemodeller
26 - Angiv om begrebet tilhører modellens emne
27 - Brug standardiserede primitive datatyper
28 - Modellér klassifikationsemner som instanser
FAQ Her er nogle almindelige spørgsmål med svar og/eller relevante henvisninger, fx til afsnit i vejledningen.
Hvad er forskellen på kerne- og anvendelsesmodeller? En kernemodel modellerer et bestemt emneområde, fx kontaktoplysninger, vandløb eller datasætbeskrivelser, og det vigtige er at opnå enighed om modelleringen med interessenter og eksperter inden for emneområdet. En anvendelsesmodel er rettet mod en specifik anvendelse, ofte et it-system eller et specifikt dataudvekslingsbehov. Fokus er på at modellere alt der reelt indgår i anvendelsen ved at sammensætte elementer fra kernemodeller. Fx kan elementer fra modeller om kontaktoplysninger, vandløb og datasætbeskrivelser sammensættes til udveksling af opsluninger om vandløbsrelatered datasæt. Læs mere om modelomfang.
Skal jeg altid lave en kernemodel? Alle modelelementer skal defineres i en kernemodel. Dog kan man ifølge regel 25 lave implicit kernemodellering som en del af en anvendelsesmodel. Det indebærer at alle elementer skal have HTTP-URIer der afspejler den kernemodel de er en del, dvs. at namespace-delen af URIerne skal komme fra kernemodellen ikke anvendelsesmodellen. Se også udarbejdelse og anvendelse af HTTP-URIer. Ulempen ved denne tilgang er at den eller de implicitte kernemdel(ler) bliver sværere at finde og dermed sværere at genbruge. Det anbefales desuden at lægge elementer fra forskellige implicitte kernemodeller i forskellige underpakker i UML-modellen.
Skal jeg altid lave en begrebsmodel? Det er ikke nødvendigt at lave en eksplicit begrebsmodel. Den gode informations- eller datamodel bygger dog på afklarede og veldefinerede begreber, så det væsentligste af det arbejde der ligger i at lave en begrebsmodel, nemlig selve begrebsafklaringen, hvor der skal findes egnede begreber at genbruge og/eller udformes gode strukturerede definitioner og afklare termer skal udføres. Udarbejdelsen af en konkret begrebsmodel kan være nyttigt i denne proces og gør resultatet af indsatsen delbart så andre kan få glæde af arbejdet.
Hvad er forskellen på logiske og fysiske datamodeller? Logiske og fysiske datamodeller har forskelligt abstraktionsniveau. Logiske modeller den semantik, de relationer mm. der gælder uanset i hvilket system eller skema data forefindes. Fysiske datamodeller beskriver et konkret dataformat, som det er implementeret i et system, skema eller lignende. Der kan fx være betydelig forskel på hvordan en adresse er gemt i en relationel database og hvordan den samme adresse deles via xsd-skema. Den logiske model bekrives hvad betydningen af de forskellige dele af adressen er og hvordan de logisk hænder sammen, fx at husnummer identificerer en sted på en bestemt vej. En logisk datamodel kan implementeres i flere forskellige fysiske datamodeller, der så vil være nemme at mappe imellem. Læs mere om modeltyper. Logiske datamodeller er værdifulde til kommunikation af dataindholdet i et system, mapning mellem forskellige systemer, og i forbindelse med systemskift og videreudvikling, hvorfor de er med til reducere afhængighed af specifikke løsninger eller leverandører.
Hvad er identifikatorer i kontekst af modellering? Identifikatorer identificere hvert modelelement unikt, uanset om elementet er en klasse, en egenskab eller et begreb. Dette muliggør genbrug af elementer i andre modeller på en måde hvor det er tydeligt hvad man genbruger. Flere modeller kan have elementer der hedder det samme, og i teorien kan man få behov for at genbruge flere elementer med samme navn fra forskellige modeller. Til modellering iht. modelreglerne skal anvendes HTTP-URIer.
Hvorfor skal jeg bruge HTTP-URIer som identifikatorer? HTTP-URIer lavet iht. Retningslinjer for stabile HTTP-URIer har udover at være et robust system til oprettelse af unikke identifikatorer, følgende fordele: De anvendes i internationalt arbejde med semantisk interoperabilitet, fx EUs Interoperable Europe og W3C, de gør det nemt at se hvilken model elementet kommer fra, og den højere grad af menneskelæsbarhed gør det nemmere at spotte fejl (sammenlignet med fx UUIDer). Desuden er de forberedt til anvendelse som URLer til opslag af information om elementet/modellen. Derfor er det vedtaget som en del af modelreglerne. Se kapitlet om HTTP-URIer i vejledningen
Er der regler for hvordan et diagram skal se ud? Et læsevenligt og overskueligt diagram, eller flere, er en stor fordel i forhold til forståelse og kommunikation af en model. Der er dog ikke deciderede regler for hvordan disse skal se ud, men kapitlet Det visuelle udtryk samler en række gode råd og anbefalinger.
Hvad er et modelreview, og hvem kan få et? Et modelreview i kontekst af modelregler, er et tjek af i hvor høj grad en model (eller flere sammenhørende modeller) overholder modelreglerne. Det foretages af modelsekretariatet med et reviewboard bestående af ca. 2 repræsentanter for UAS. Det er et modelteknisk review med fokus hvordan modellen er udformet, og gør det dermed ikke ud for den forretningsgodkendelse der også anbefales . Modelreview tilbydes primært til projekter med et tværgående sigte, dvs. hvor flere aktører skal udveksle data eller på anden vis anvende modellen eller modellerne. Kontakt gerne modelsekretariatet for at høre om mulighederne for at få et review af din model. Tag kontakt i god tid inden du ønsker reviewet, da det tager tid at planlægge.
Hvordan forbereder jeg mig på et modelreview?
Hvad når jeg skal modellere grunddata Det er i regi af grunddataprogrammet vedtaget at anvende en specifik profil af modelreglerne med enkelte tilføjelser. Du kan finde profilen her: Grunddatamodelregler
Hvem kan jeg kontakte for yderligere hjælp? Du er til enhver tid velkommen til at kontakte modelsekretariatet via arkitektur@digst.dk . Vi hjælper gerne hvis du ikke kan finde det svar du har brug for, har svært ved at komme i gang eller andet. Du kan også oprette et issue på GitHub.
Hvad hvis jeg har forbedringsforslag til vejledningen? Det er planen at vejledningen løbende skal opdateres på baggrund den viden vi løbende får om brugen af vejledningen, samt de udfordringen man kan løbe ind ved modelleringen i henhold til modelreglerne. Vi modtager derfor gerne feedback og forslag på arkitektur@digst.dk eller via GitHub siden, hvor man også kan inddrage andre anvendere i dialogen om ønsker til vejledningen.