KOMBIT FLIS. D0130 Logisk Datamodel - Rapporteringsgrundlag. Version: 3.1 Status: Godkendt Godkender: Christian Gjerulff

Transkript

1 KOMBIT FLIS Version: 3.1 Status: Godkendt Godkender: Christian Gjerulff

2 Dokumenthistorik Version Dato Navn Status Bemærkninger Udkast Udkast Indholdsfortegnelse oprettet Indholdsfortegnelse tilrettet Endelig Udkast Endelig Endelig Design af nøgletalsdatamart tilføjet Opdateret med KOMBITkommentarer. Opdateret efter personaleafklaringsmøde Endelig Tilføjet design af ældre Endelig ÆØ 43. Afsnit Endelig ÆØ 46. Afsnit Endelig Dataholds Mødereferat indført Endelig Opdateret med udvidede kontoplanskomponenter. Afsnit Endelig Endelig Endelig Opdateret med design for skoleområdet. Opdateret som følge af #66. Klargjort ældreområdet til review (afsnit 11) Endelig Opdateret hele dokumentet til release 2.0 godkendelse incl. VH Godkendt Dokument godkendt Godkendt Nøgletalsvurdering D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 2 af 102

3 Distributionsliste Navn Organisation Bemærkninger Kenneth Jacobsen Thomas Mørk Glintborg KOMBIT KOMBIT Referencer Reference Titel Forfatter Version [D0150] D0150 Softwarearkitektur Christian Kirkegaard 1.0 Budget og regnskabssystem for kommuner [IMKONTOPLAN] Primært kapitel 2. Indenrigsministeriet [KIMBALL] The Data Warehouse Lifecycle Toolkit Ralph Kimball m.fl [EXPERT] Expert Cube Development with Microsoft SQL Server 2008 Analysis Services Chris Webb m.fl D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 3 af 102

4 Indholdsfortegnelse 1 INDLEDNING Formål Omfang 8 2 FLIS DATAMARTER OG KUBER Relationelle datamarter Kubeattributter, felter og datatyper SQL Views som forbindelsesled 10 3 FÆLLES DIMENSIONER Tid Attributter og hierarkier Relationelt datagrundlag 13 4 ØKONOMI Rapporteringsbehov Dimensioner Autoriseret kontoplan Udvidet kontoplan Opus [X] dimensioner Facts Relationelt datagrundlag 21 5 PERSONALE Dimensioner Anciennitet Attributter og hierarkier Ansættelsesvilkår Attributter og hierarkier Fravær Attributter og hierarkier Medarbejder Attributter og hierarkier Facts Fravær Fraværsperiode Medarbejder Aktivitet Relationelt datagrundlag 35 6 BORGER Dimensioner Alder Attributter og hierarkier Borger Attributter og hierarkier Borgerstatus Attributter og hierarkier Geografi (Adresse) Attributter og hierarkier Facts 41 D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 4 af 102

5 6.2.1 Borger Relationelt datagrundlag 44 7 NØGLETAL Dimensioner Nøgletal Attributter og hierarkier Sammenligningsgruppe Attributter og hierarkier Facts Nøgletal Relationelt datagrundlag 51 8 SKOLE Dimensioner DimElev Attributter og hierarkier DimSkole Attributter og hierarkier DimKlasse Attributter og hierarkier DimPrøveKarakter Attributter og hierarkier Facts Elev FactKarakter FactKlasse FactSkole Relationelt datagrundlag 63 9 UDSATTE BØRN OG UNGE Dimensioner DimForanstaltning Attributter og hierarkier DimAnbringelsessted Attributter og hierarkier DimForanstaltningsmodtager Attributter og hierarkier Facts FactForanstaltning FactDisponeretForbrug Relationelt datagrundlag VOKSNE HANDICAPPEDE Dimensioner Ydelse Målgruppe Funktionsvurdering Opholdssted Facts Visiteret borger Ydelse Relationelt datagrundlag 81 D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 5 af 102

6 11 ÆLDRE Dimensioner Besøg Ydelse Ydelseslængde Leverandør Tidspunkt Facts Visiteret ydelsesdetalje Visiteret ydelse Leveret ydelsesdetalje Leveret ydelse Leveret besøgsdetalje Leveret besøg Boligtilbud Relationel datamart 100 (Brug style body text til alm. brødtekst. Så bliver indrykningen pæn under headerteksterne). D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 6 af 102

7 1 Indledning Nærværende dokument indeholder en beskrivelse af datagrundlaget for rapporteringen i FLIS Portalen. Slutproduktet udgør dermed dokumentationen for, hvorledes forespørgsler kan udformes, når dashboards, standardrapporter og kommunale rapporter udvikles. Dokumentet er struktureret ved følgende dele: Introduktion til datamarter og kuber i FLIS indeholdende en overordnet beskrivelse af rapporteringsgrundlaget, som kan opdeles i en række relationelle datamarter og nogle OLAPbaserede kuber. Beskrivelse af fælles dimensioner benyttet på tværs af kuber. Beskrivelser af de enkelte kuber. Hver af kuberne beskrives ved: o o o Et overblik over facts og relaterede dimensioner. Dernæst beskrives de enkelte dimensioner og facts i lidt flere detaljer omkring hierarkier, attributter og s herunder aggregeringstyper. Sidst beskrives i hvert afsnit det underliggende relationelle datamartgrundlag. Denne sektion indeholder detaljerede beskrivelser af tabeller herunder de felter, som dimensionsattributter og s baseres på. Attributter og delfelter For at højne læsbarheden er der for kuber (specifikt dimensioner) kun beskrevet attributter og ikke attributternes tilknyttede delfelter. Eksempelvis findes der i kubebeskrivelsen for økonomiområdet (kontoplansdimensionen) attributten Dranst. Denne attribut har tilknyttet delfelterne: Dranst nøgle: heltalsrepræsentation af attributtens kode eller nummer. Eksempelvis 1. Dranst nummer: attributtens kode eller nummer. Eksempelvis 01. Dranst navn: attributtens navn. Eksempelvis Drift. Dranst nummer og navn: eksempelvis 01 Drift. Delfelter for attributter er udeladt i kubedokumentationen, som er fokuseret på forretningsmæssig afklaring og i stedet specificeret i det mere tekniske, underliggende relationelle datagrundlag. Relevante delfelter (numre og navne) vil være til rådighed i kuberne enten som selvstændige attributter, relationer eller attributegenskaber. Historik Ved gennemgang af dimensioner beskrives typen af historik for dimensionen. Historik på dimensioner baseres på forretningsnøgler, som identificerer en række i en dimension unikt. Forretningsnøglen kan være en kombination af flere felter (eksempelvis kontonummer og regnskabsår). Der skelnes mellem følgende typer af historik: Type1historik: der opsamles nye rækker for nye kombinationer af forretningsnøgleværdier. Ændringer i andre felter i dimensionen giver ikke ophav til nye rækker; disse felters værdier opdateres blot. Type2historik: der oprettes nye rækker ved ændring i felter inklusive andre end forretningsnøglefelter. D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 7 af 102

8 Type3historik: ændringer til et felt registreres i et eller flere dedikerede historikfelter (ekstra kolonner). 1.1 Formål Det er formålet med dokumentet at give et overblik over rapporteringsgrundlaget i FLIS ud fra et logisk perspektiv i form af: Beskrivelser af kuber ved deres af facts og dimensioner. Beskrivelser af de underliggende relationelle datamarter. 1.2 Omfang Det bør bemærkes, at nærværende slutprodukt opdateres i to omgange: I designfasen op til implementering af delleverance 1. Her kortlægges de overordnede datamodeller for alle dataområder. De tværfaglige områder, der skal implementeres og benyttes i delleverance 1 beskrives desuden i detaljer. Ved forberedelse til implementering af delleverance 2 detaljeres beskrivelsen af datamodellen for de fagspecifikke områder. Kontrolfelter til bl.a. sporing af data er ikke beskrevet i nærværende slutprodukt, da det er en arkitekturmæssig del, der indgår på tværs af forretningsmæssige områder. Der henvises til [D0150] for en beskrivelse af disse felter. Det bør bemærkes, at visse specifikationer af det underliggende relationelle datagrundlag udestår på grund af forsinket testdata. D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 8 af 102

9 2 FLIS datamarter og kuber FLIS rapporteringsgrundlag er baseret på OLAPkuber. Brugerne har dermed adgang til FLIS data udelukkende igennem FLISkuber. Kuber er et oplagt valg som rapporteringsgrundlag til FLIS, idet behovet er rapportering og rapportering på relativt aggregerede niveauer. OLAPkuber baseres på et relationelt databasegrundlag. Den underliggende relationelle datamodel ligner som udgangspunkt datamodellen for kuberne. Det er valgt at opdele kuberne og deres underliggende relationelle datamodeller i såkaldte datamarter, der vedrører et givent rapporteringsområde: Økonomi Personale Borger Skole Voksne handicappede Udsatte børn og unge Ældreomsorg Nedenstående figur viser det konceptuelle forhold imellem relationelle datamarter og kuber. Figur 1 Relationelle datamarter og kuber Både de relationelle og kubedatamarterne er struktureret efter såkaldte stjerneskemamodeller, der benytter sig af begreberne facts og dimensioner. Facts indeholder udelukkende tal og er koblet til dimensioner igennem surrogatnøgler ved integration fra EDWdatalaget til datamartdatalaget. Der henvises til [KIMBALL] for yderligere information om modellering af datamarter. 2.1 Relationelle datamarter Navngivningsprincipper for relationelle datamarter (og kuber) følger Pascal casestandard, der er baseret på undersøgelser i effektiv læsbarhed. Dette gælder både skemaer, tabeller og felter. Desuden benyttes nedenstående retningslinjer: Benyt sigende navneord eller navneordsvending (Kunde, KunderPerHusstand) D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 9 af 102

10 Undgå så vidt muligt forkortelser (Knd, KndPrHus) Undgå underscore _ (Kunder_Per_Husstand) For de tilhørende kuber gælder det, at man bør anvende mellemrum, hvis (calculated) s, dimensioner eller attributter indeholder flere ord. (Kunder Per Husstand) De relationelle datamarttabeller inddeles i skemaer navngivet efter identificerede datamarter Kubeattributter, felter og datatyper Herunder gennemgås de generelle principper for felter tilhørende hver kubeattribut og valg af felternes datatyper i de relationelle datamarter. Datatyperne i kuberne følger datatyperne i de relationelle datamarter. Som eksempel benyttes kubeattributten Hovedkonto (en del af kontoplanen) med eksempelværdien 04 Sundhedsområdet. Attributten er (som mange andre kubeattributter) bygget op af en række felter: Nøgle (eksempelvis 4 ) datatype: heltal Nummer (eksempelvis 04 ) datatype: tekst Navn (eksempelvis Sundhedsområdet ) datatype: tekst NummerOgNavn (eksempelvis 04 Sundhedsområdet ) datatype: tekst Almindeligvis anbefales det, at nøgler for de enkelte kubeattributter baseres på heltal i datamarter til effektiv videre brug. Denne praksis benyttes, hvor heltalsudgaver (nøgler) forefindes. Dette afhænger af attributtens nummerlængde. I dybe hierarkier kan det være nødvendigt at nøjes med at benytte numre som attributnøgler i kuben. Bemærk, at nummerfelter i tekst kan være nødvendig, selvom der forefindes en nøgle, da numre kan være præfikset med 0, og numrene bør præsenteres til brugerne således. Såfremt numre ikke er præfikset benyttes Nummerfeltet udelukkende i sin heltalsudgave. Følgende retningslinjer er benyttet ved valg af datatyper for de enkelte felter: Størrelsen på heltalsnøgler er baseret på nummerstørrelsen i tekst og et valg ud fra tilhørende heltalstyper: tinyint (0 til 255), smallint (32,768 til 32,767) 4 cifre, int ( 2,147,483,648 til 2,147,483,647) 8 cifre, bigint (9,223,372,036,854,775,808 til 9,223,372,036,854,775,807) 17 cifre. Størrelsen på numre er baseret på grænsesnitspecifikationer og en dataanalyse inklusive 1 tegn pr. niveau til separatorer. Størrelsen på navne er baseret på dataanalyse af data fra UKM. Størrelsen er ofte 100 tegn. Størrelsen på sammensatte felter (nummer og navn) er størrelsen for nummeret og navnet inklusive 5 tegn til eventuelle separatorer. 2.2 SQL Views som forbindelsesled SQL views benyttes som bindeled imellem relationelle datamarter og kuber i den udstrækning det giver mening i stedet for de såkaldte Data Source Views i kubedefinitioner, hvilket følger anbefalingen i bl.a. [EXPERT]. Som udgangspunkt bør alt, hvad der kan beregnes på et relationelt grundlag foretages i ETLprocessen fra EDW til DMlaget. Denne retningslinje giver bedre ydelse i kuberne og stiller samtidig data til rådighed i relationel tilstand til brug i bl.a. datapakker. Enkelte s bør D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 10 af 102

11 imidlertid ligge i kuberne som eksempelvis procents, for at understøtte effektiv multidimensional analyse. SQL views benyttes oftest ved simple opdelinger eller samlinger af tabeller, simple uddrag af tabeller eller til simple afledte felter. Et afledt felt kunne eksempelvis være sammensætning af nummer og navn for hovedfunktionsattributten. Ved dokumentation af de relationelle tabeller i de følgende afsnit er afledte felter identificeret i en kolonne Afledt. Disse felter er kandidater til at indgå i views, selvom de som udgangspunkt bør udledes/beregnes i ETLprocesser. D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 11 af 102

12 3 Fælles dimensioner Figur 2 Datamodel for fælles dimensioner viser et overblik over de fælles dimensioner i løsningen. class Fælles Dimension::Tid «column» Dato Ugedag Dag Dag og måned i år Måned Kvartal Halvår Uge Uge i måned År Skoleår Figur 2 Datamodel for fælles dimensioner Tid Tidsdimensionen er en central dimension, der benyttes i alle områder Attributter og hierarkier Dimensionen indeholder følgende hierarkier: Navn Niveauer Beskrivelse År Halvår Kvartal Måned Dato Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Skolekalender Skoleår Måned Dato Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Ugekalender År Uge Dato Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Det bemærkes, at halvår ikke indgår i noget hierarki. Udover hierarkier er der også en række attributter til rådighed til analyse af data: D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 12 af 102

13 Navn Beskrivelse Ugedag Ugedag. Eksempelvis Tirsdag. Dag Dag i år. Eksempelvis 255. Dag i måned Understøtter analyse på tværs af år og måneder. Eksempelvis 20 for dag nummer 20 i måneden. Dag og måned i år Understøtter dagsanalyse på tværs af år. Eksempelvis 2. marts.. Uge Understøtter ugeanalyse på tværs af år Eksempelvis 43. Ifølge ISOstandard. Uge i måned Understøtter ugeanalyse på tværs af måneder og år. 15. Eksempelvis 2. Ifølge ISOstandard. Måned Understøtter månedsanalyse på tværs af år. Eksempelvis februar. Kvartal Understøtter kvartalsanalyse på tværs af år. Eksempelvis K2. Halvår Understøtter halvårsanalyse på tværs af år. Eksempelvis H Relationelt datagrundlag Det relationelle datagrundlag er beskrevet i D0180 Den fysiske datamodel. D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 13 af 102

14 4 Økonomi Økonomikuben moduleres efter stjerneskemaet i nedenstående figur. Figur 3 Økonomikube Som det ses af figuren indeholder økonomikuben en fact, beløb, som basalt set indeholder forbrugs og budgetbeløb. Beløbene kan analyseres ud fra dimensionerne: Tid er en standarddimension som langt de fleste facts er koblet til inklusive økonomibeløb. Autoriseret kontoplan hvis struktur følger Indenrigsministeriets retningslinjer. FLIS standard dashboards og rapporter vil være baseret på denne dimension. Alle kommuner og deres tilhørende økonomisystemer vil med sikkerhed kunne analyseres ud fra denne dimension, og datakvaliteten forventes at være høj. Udvidet kontoplan understøtter kommunespecifik analyse af nøgletal. Strukturen går på tværs af alle kommuner og økonomisystemer. Opus [X] understøtter kommunespecifik analyse af nøgletal. Dimensionerne kan kun benyttes af kommuner, der benytter Opus som økonomisystem. Det bemærkes, at dimensionerne vil fremgå for alle kommuner uafhængigt af, om kommunen benytter Opus som økonomisystem. D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 14 af 102

15 Dimensionerne autoriseret kontoplan, udvidet kontoplan og Opus [X] er alle baseret på kontoplansattributter (kontoplansdimensioner i økonomitermer). Opdelingen af disse attributter i flere dimensioner er valgt pga.: En overskuelig og brugervenlig navigation i et højt antal kontoplansattributter. En overskuelig opdeling af autoriserede og ikkeautoriserede attributter. Ved ovenstående opdeling sikres en gennemskuelighed for brugere ved rapportering, om en analyse er baseret på autoriserede kontoplansdele eller ikkeautoriserede dele. En fleksibilitet og robusthed i forhold til underliggende økonomisystemer. Strukturen i den autoriserede kontoplansdimension forventes at være stabil og uafhængig af underliggende økonomisystemer, eftersom systemerne pr. lovkrav skal leve op til strukturen. Da systemerne desuden skal levere data i den struktur, er der en sikkerhed for at økonomidata vil kunne rekvireres i et format, der følger strukturen. Dashboards og rapporter baseret på denne dimension vil derfor være robuste og stabile. Strukturerne for den udvidede kontoplansdimension og Opus [X]dimensionerne vil sandsynligvis være mindre stabile og kunne være kandidater til ændringer ved ændringer i underliggende økonomisystemer. Da fælleskommunal analyse kan foretages via den autoriserede kontoplansdimension, vil der desuden være mulighed for at oprette varianter af eksempelvis den udvidede kontoplansdimension, der er relevante for de enkelte typer af økonomisystemer; uden at påvirke tværkommunal analyse og rapportering. Opus [X]dimensionerne er organiseret i selvstændige dimensioner grundet attributternes parentchildhierarkier fra kildesystemet Opus. Fordelen ved at benytte Opusdimensioner med parentchildhierarkier er, at modellen ligger tæt op af kildesystemets model og dermed også, hvad brugerne er vant til. Ulempen er den dårligere ydelse som parentchildhierarkier medfører. Det forventes ikke, at ydelse vil blive et problem grundet granularitet af facttabel på månedsniveau (og ikke posteringsniveau). 4.1 Rapporteringsbehov Ved modulering af kuber er det vigtigt at holde sig de forventede rapporteringsbehov for øje. Disse behov er primært standard dashboards til benchmarking og nøgletalsdokumentation og standardrapporter til analyse af nøgletalsgrundlag. I mindre grad bør FLIS også understøtte kommunespecifik analyse af datagrundlaget for nøgletal. Disse analyser understøttes af organisationsdimensionen og udvidede kontoplansdimensioner. Alle økonomiske nøgletalstællere er baseret på realiserede beløb og den autoriserede kontoplansdimension. Standard nøgletalsdokumentation baseres ligeledes på den autoriserede kontoplansdimension. 4.2 Dimensioner I det følgende gennemgås dimensionerne specifikke for økonomiområdet Autoriseret kontoplan Dimensionen Autoriseret kontoplan giver en brugervenlig indgang til fuldt og delvist autoriserede attributter fra Indenrigsministeriets (IM s) kontoplan. Dataindholdet i hierarkier og attributter vil udelukkende bestå af autoriserede værdier. Dimensionen indeholder følgende hierarkier: D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 15 af 102

16 Navn Niveauer Beskrivelse Funktioner Hovedkonto Hovedfunktion Funktion Funktionshierarkiet indeholder de tre autoriserede funktionsniveauer også benævnt funktion niveau 13. Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Arter Hovedart Art Artshierarkiet indeholder de to autoriserede artsniveauer også benævnt art niveau 1 og 2. Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Det bemærkes, at analyse af underniveauer på tværs af øvre niveauer ikke understøttes på grund af hierarkierne er naturlige. Eksempelvis er analyse af hovedfunktion 99 på tværs af teoretiske hovedkonti 20 og 30 ikke mulig, da der vil findes to hovedfunktioner med de unikke numre: og Udover hierarkier er der også en række attributter til rådighed til analyse af data: Navn Beskrivelse Dranst Autoriseret kontoplansattribut Dranst. Ejerforhold Autoriseret kontoplansattribut Ejerforhold. Omkostningssted Autoriseret kontoplansattribut Omkostningssted. Også benævnt omkostningssted niveau 1 eller sted 1. Gruppering Autoriseret kontoplansattribut Gruppering. Også benævnt gruppering niveau 1 eller gruppe 1. Inkomplet Binding Angiver at en postering afviger fra FLIS IM kontoplanen på et eller flere punkter Udvidet kontoplan Dimensionen Udvidet kontoplan giver en brugervenlig indgang til autoriserede og ikke autoriserede attributter. Dataindholdet i hierarkier og attributter vil både bestå af autoriserede værdier og kommunespecifikke værdier. Dimensionen indeholder følgende hierarkier: D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 16 af 102

17 Navn Niveauer Beskrivelse Funktioner Funktion 1 Funktion 2 Funktion 3 Funktion niveau 4 Funktion niveau 5 Funktion niveau 6 Funktion niveau 7 Funktionshierarkiet indeholder de tre autoriserede funktionsniveauer også benævnt hovedkonto, hovedfunktion og funktion. Derudover indeholder hierarkiet de kommunespecifikke niveauer 46. Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Omkostningssteder Omkostningssted niveau 1 Omkostningssted niveau 2 Omkostningssted niveau 3 Omkostningssted niveau 4 Omkostningssted niveau 5 Omkostningssted niveau 6 Omkostningssted niveau 7 Omkostningsstedhierarkiet indeholder det autoriserede omkostningssted og derudover en række kommunespecifikke underniveauer 27. Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Grupperinger Gruppering niveau 1 Gruppering niveau 2 Gruppering niveau 3 Gruppering niveau 4 Gruppering niveau 5 Gruppering niveau 6 Gruppering niveau 7 Grupperingshierarkiet indeholder den autoriserede gruppering og derudover en række kommunespecifikke underniveauer 27. Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Arter Art niveau 1 Art niveau 2 Art niveau 3 Art niveau 4 Art niveau 5 Art niveau 6 Art niveau 7 Artshierarkiet indeholder de to autoriserede artsniveauer også benævnt art og hovedart. Derudover indeholder hierarkiet art niveau 34. Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 17 af 102

18 Navn Niveauer Beskrivelse Administrativ organisation niveau 1 Administrativ organisation niveau 2 Administrativ organisation Administrativ organisation niveau 3 Administrativ organisation niveau 4 Administrativ organisation niveau 5 Administrativ organisation niveau 6 Administrativ organisation niveau 7 Det administrative organisationshierarki indeholder 7 niveauer også benævnt administrativ 17. Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Politisk organisation Politisk organisation niveau 1 Politisk organisation niveau 2 Politisk organisation niveau 3 Politisk organisation niveau 4 Politisk organisation niveau 5 Politisk organisation niveau 6 Politisk organisation niveau 7 Det politiske organisationshierarki indeholder 7 niveauer også benævnt politisk 17. Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Fri 1 Fri 1 niveau 1 Fri 1 niveau 2 Fri 1 niveau 3 Fri 1 niveau 4 Fri 1 niveau 5 Fri 1 niveau 6 Fri 1 niveau 7 Det første frie hierarki indeholder 7 niveauer. Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 18 af 102

19 Navn Niveauer Beskrivelse Fri 2 niveau 1 Fri 2 niveau 2 Fri 2 Fri 2 niveau 3 Fri 2 niveau 4 Fri 2 niveau 5 Fri 2 niveau 6 Fri 2 niveau 7 Det andet frie hierarki indeholder 7 niveauer. Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Fri 3 Fri 3 niveau 1 Fri 3 niveau 2 Fri 3 niveau 3 Fri 3 niveau 4 Fri 3 niveau 5 Fri 3 niveau 6 Fri 3 niveau 7 Det tredje frie hierarki indeholder 7 niveauer. Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Det bemærkes, at analyse af underniveauer på tværs af øvre niveauer ikke understøttes på grund af hierarkierne er naturlige. Af listen over hierarkier ses det, at dimensionen har et vist overlap med enkelte niveauer i den autoriserede kontoplansdimension. Overlappet er valgt af hensyn til mulighed for sammenhængende kommunal analyse på eksempelvis funktioner. Det bemærkes, at der for ovenstående attributter både er et nummer og navn. Dog er det afklaret, at navnet for samme nummer kan ændre sig pr. regnskabsår. Det er desuden besluttet, at FLIS skal indeholde denne navnehistorik. Det gøres ved at inkludere et regnskabsår i dimensionen. Ovenstående hierarkier er baseret udelukkende på nummer uden hensynstagen til regnskabsåret. Dermed understøttes analyse på tværs af år. Til analyse med navne inden for et givent år defineres der tillige for hvert af ovenstående hierarkier, nye hierarkier hvor regnskabsåret indgår som øverste niveau eksempelvis: Funktioner år med niveauerne: År Funktion 1 Funktion 2 Funktion 7 Udover hierarkier er der også en række attributter til rådighed til analyse af data: D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 19 af 102

20 Navn Beskrivelse OPUS data Angiver om postering er foretaget i et OPUS økonomisystem. Registreringskonto Angiver det kontonummer en postering er foretaget på Opus [X] dimensioner Dimensionerne Opus PSPelement, profitcenter, omkostningssted, artskonto, bevillingsansvarssted og kapitalmiddel benyttes til analyse af økonomidata fra Opus økonomisystemer. Som for den udvidede kontoplansdimension kan navne ændre sig henover regnskabsår. Hierarkiet er derfor baseret udelukkende på numre. Dimensionerne indeholde følgende hierarkier. Navn Niveauer Beskrivelse [X] Niveau 1 [X] Niveau 2 [X] Niveau 3 [X] Niveau 4 [X] Niveau 5 [X] Niveau 6 [X] Niveau 7 [X] [X] Niveau 8 [X] Niveau 9 [X] Niveau 10 [X] Niveau 11 [X] Niveau 12 [X] Niveau 13 [X] Niveau 14 [X] Niveau 15 [X] Niveau 16 [X] Niveau 17 [X] Niveau 18 Hvert OPUShierarkier indeholder 18 niveauer. Hierarkierne er naturlige, hvormed der er en entilmangerelation imellem niveauerne. 4.3 Facts Der er til økonomiområdet kun en enkelt facttabel. s (målinger eller værdier) og Members (beregnede s) baseret på denne tabel er beskrevet i tabellen herunder. D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 20 af 102

21 Navn Type Beskrivelse Aggregering Forbrug Se relationelt datagrundlag. Sum Oprindeligt budget Se relationelt datagrundlag. Sum Korrigeret budget Se relationelt datagrundlag. Sum Rest oprindeligt budget Se relationelt datagrundlag. Sum Rest korrigeret budget Se relationelt datagrundlag. Sum Omplacering Se relationelt datagrundlag. Sum Tillægsbevilling Se relationelt datagrundlag. Sum Forbrugsprocent oprindeligt budget Forbrug / Oprindeligt budget Forbrugsprocent korrigeret budget Forbrug / Korrigeret budget Følgende s har afhængigheder til kalenderhierarkierne. D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 21 af 102

22 Afhængighed Forbrug ÅTD Forbrug ÅTD tus. Forbrug ÅTD mio. Oprindeligt budget ÅTD Oprindeligt budget ÅTD tus. Oprindeligt budget ÅTD mio. Korrigeret budget ÅTD Korrigeret budget ÅTD tus. Korrigeret budget ÅTD mio. Rest korrigeret budget ÅTD Rest korrigeret budget ÅTD tus. Rest korrigeret budget ÅTD mio. Rest oprindeligt budget ÅTD Rest oprindeligt budget ÅTD tus. Rest oprindeligt budget ÅTD mio. Forbrugsprocent korrigeret budget ÅTD Forbrugsprocent oprindeligt budget ÅTD 4.4 Relationelt datagrundlag Det relationelle datagrundlag er beskrevet i D0180 Den fysiske datamodel. D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 22 af 102

23 5 Personale Personaleområdet inkluderer analyser inden for: Fraværsdage Fraværsperioder Medarbejdere Den logiske datamodel for personalekuben følger disse analysebehov. Som det fremgår af det følgende, benytter de enkelte analyseområder sig af samme kubedimensioner. Derudover benyttes konforme dimensioner fra andre områder: Alder fra borgerområdet Kontoplan fra økonomiområdet Der henvises til afsnit for de respektive områder for beskrivelser af disse dimensioner. Fravær Figur 4 Datamodel for fravær viser et overblik over datamodellen for fraværsdage: D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 23 af 102

24 Figur 4 Datamodel for fravær Facttabellen og de enkelte dimensioner gennemgås i detaljer i de følgende afsnit. Der er foretaget følgende designvalg: Alder og anciennitet er trukket ud i selvstændige dimensioner på trods af, de er tæt knyttet til medarbejderdimensionen. Dette valg er foretaget af hensyn til historisk analyse uden at forøge størrelsen og kompleksiteten af medarbejderdimensionen. Alder og anciennitet er splittet i to dimensioner, da aldersdimensionen er en konform dimension, der også benyttes i andre kuber (borger eksempelvis). Anciennitet er en personalespecifik dimension. Ansættelsesvilkår er trukket ud i en selvstændig dimension, selvom dimensionen er tæt koblet til medarbejderdimensionen. Valget skyldes håndtering af historik på ansættelsesvilkårene, som skifter med tiden. Med ovenstående model undgås forøget kompleksitet af medarbejderdimensionen. Fraværsperiode Figur 5 Datamodel for fraværsperiode giver et overblik over datamodellen for fraværsperiode. D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 24 af 102

25 Figur 5 Datamodel for fraværsperiode Fraværsperiodeanalyse er valgt understøttet med selvstændig datamodel af følgende årsager: Analyse på fravær kan være tung, da datamodellen er på et lavt granularitetsniveau (dage) med rækker for hver dag. Analyse af fraværsperioder optimeres ved at skille analysen ud i en selvstændig model med færre rækker (en pr. periode). Analyse af fraværsperioder adskiller sig fra analyse af fravær på et konceptuelt niveau i forhold til tid. Perioder analyseres i højere grad ud fra en start og slutdato end analyse på fraværsdage gør. Medarbejdere Analyse inden for medarbejdere beskæftiger sig med antallet af medarbejdere med forskellige fordelinger. Figur 6 Datamodel for medarbejder viser et overblik over datamodellen. D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 25 af 102

26 Figur 6 Datamodel for medarbejder Facttabellen er en snapshottabel på månedsniveau, hvor følgende designvalg er blevet taget: Medarbejderdimensionen er ikke gjort konform med CPRregisterets borgerdimension, da de to dimensioner benytter forskellige forretningsnøgler (henholdsvis personalenummer/institution og personnummer). Medarbejdere Analyse inden for aktivitet beskæftiger sig med antallet af aktive arbejdsdage Figur 7 Datamodel for aktivitet viser et overblik over datamodellen. D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 26 af 102

27 Figur 7 Datamodel for aktivitet 5.1 Dimensioner Dimensioner for personaleområdet beskrives i de følgende afsnit Anciennitet Anciennitet understøtter analyse af fravær og medarbejdere ud fra medarbejderes ansættelseslængde. Ansættelseslængde er defineret som indlæsningsdato første ansættelsesdato. Dimensionen benytter type1historik Attributter og hierarkier Dimensionen indeholder følgende hierarkier: D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 27 af 102

28 Navn Niveauer Beskrivelse Hierarkiet indeholder et grupperingsniveau af ancienniteter med følgende intervaller: Anciennitetsgruppering Anciennitet Måneder 06 mdr., 712 mdr., 1336 mdr., 37+ mdr. Det nederste anciennitetsniveau er på måneder. Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Femårsgruppering Femårsgruppering År Måneder Hierarkier indeholder på øverste niveau en gruppering på femårsintervaller, på midterste en gruppering på år og på nederste niveau på måneder. Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Tiårsgruppering Tiårsgruppering År Måneder Hierarkier indeholder på øverste niveau en gruppering på tiårsintervaller, på midterste en gruppering på år og på nederste niveau på måneder. Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Dimensionen indeholder desuden følgende attributter. Navn Beskrivelse Måneder Anciennitet i måneder År Anciennitet i år Ansættelsesvilkår Ansættelsesvilkår benyttes ved analyse af medarbejderes ansættelsesforhold. Dimensionen er en samling af attributter vedrørende medarbejderes ansættelsesforhold og har derfor en såkaldt sammensat forretningsnøgle. Dimensionen benytter type2historik, da inddelingen af lønklasser fra kildesystemer i FLD stillinger kan skifte over tid, og det er nødvendigt at bibeholde historik Attributter og hierarkier Dimensionen indeholder følgende hierarkier: D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 28 af 102

29 Navn Niveauer Beskrivelse Aflønningsform Aflønningskategori Aflønningsform Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Stillingshierarki Overenskomstområde FLD Stilling FLD Lønklasse Stillingshierarki benyttet i FLDsammenhæng. Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Udover hierarkier er der også en række attributter til rådighed til analyse af data: Navn Beskrivelse Ansættelsesstatus Eksempelvis Overenskomst, Tjenestemand, Funktionær etc. Ca. 54 værdier. Lønklasse Eksempelvis Lærer, Plejeassistent, Bogholder, Sygehjælper etc. Flere end 1000 værdier. Lønklasse nummer og navn Eksempelvis Lærer ( ), Plejeassistent ( ) etc. Flere end 1000 værdier Overenskomst Eksempelvis Dagplejere, Kontorpersonale, Kokke, Pædagogmedhjælper. Flere end 100 værdier. Stilling FLD Stillingsbetegnelse fra FLD. Stilling FLD nummer og navn Stillingsbetegnelse fra FLD, inklusiv det tilhørende nummer Overenskomstområde FLD Overenskomstområde (kategorisering af stillinger) fra FLD. Stillingskategori FLIS FLIS kategorisering af stillinger baseret på FLD s stillinger. Nøgletalsrelevant Angiver hvorvidt ansættelsesvilkåret er relevant ifm. nøgletal Fravær Fravær er en samling af informationer omkring hver enkelt registrering af fravær. Dimensionen benytter type1historik Attributter og hierarkier Dimensionen indeholder følgende hierarkier: D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 29 af 102

30 Navn Niveauer Beskrivelse Fraværsårsagskategori Fraværsårsag Fraværsårsag Fraværsårsag kildesystem Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Fraværslængde Periodegruppering Periodelængde Grupperingsniveauet indeholder følgende intervaller: 1 dag, 2 dage, 37 dage, 814 dage, 1521 dage, 2256 dage, over 56 dage Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne Medarbejder Medarbejderdimensionen sikrer, at analyser kan foretages helt ned på personniveau. Indhold hentes som udgangspunkt fra CPRregisteret, således at der opnås ensartet og renset data. Dimensionen benytter type1historik, således at den reflekterer opdaterede informationer omkring medarbejdere Attributter og hierarkier Dimensionen indeholder ingen hierarkier, da den primært er tænkt til dokumentation. Der er følgende attributter til rådighed til analyse af data: D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 30 af 102

31 Navn Beskrivelse Personalenummer Eksempelvis Institutionsnummer Eksempelvis Personnummer Eksempelvis Efternavn Eksempelvis Boje. Fornavn Eksempelvis Mikkel. Navn Sammensat: [Fornavn] [Efternavn], eksempelvis Mikkel Boje. Fødselsdato Eksempelvis Køn Eksempelvis K eller M. Nuværende civilstand Eksempelvis Gift. Ansættelsesdato Eksempelvis Ansættelsesstopdato Eksempelvis Facts I de følgende afsnit beskrives de facts, der benyttes til analyse inden for personaleområdet Fravær Fraværsfacten er koblet til tidsdimensionen på dagsniveau. Der eksisterer en række pr. dag. Fact ens unikke nøgle er: Medarbejder Tid Nedenstående tabel beskriver metrikker og beregnede metrikker: D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 31 af 102

32 Navn Type Beskrivelse Aggregering Antal fraværsdage Optælling af fraværsdage Sum Antal fraværsdagsværk Optælling af fraværsdagsværk Sum Kvote for fravær Antal aktive dage x Kvote Average over time Antal fraværsdage pr. fuldtidsstilling Opgørelse af antal fraværsdage pr. fuldtidsstilling Antal fraværsdagsværk pr. fuldtidsstilling Opgørelse af antal fraværsdagsværk pr. fuldtidsstilling Fraværsprocent Opgørelse af den overordnede fraværsprocent Fraværsprocent for dagsværk Opgørelse af fraværsprocenten for dagsværk Fraværsprocent for dagsværk total Opgørelse af den totale fraværsprocent for dagsværk Fraværsprocent total Fraværsprocent total Fraværsperiode Fraværsperiodefacten er koblet til tidsdimensionen på dagsniveau. Der eksisterer en række pr. fraværsperiode. Fact ens unikke nøgle er: Medarbejder Tid (dato for fraværsperiodens start) Nedenstående tabel beskriver metrikker og beregnede metrikker: Navn Type Beskrivelse Aggregering Antal fraværsperioder Optælling af antallet af fraværsperioder Sum Antal aktive fraværsperioder Beregning af antal aktive fraværsperioder Gennemsnitlig periodelængde Beregning af den gennemsnitlige fraværsperiodelængde D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 32 af 102

33 5.2.3 Medarbejder Medarbejderfacten er koblet til tidsdimensionen på månedsniveau (og dagsniveau for ansættelsesdatoer). Der eksisterer en række pr. medarbejder pr. måned. Fact ens unikke nøgle er: Medarbejder Tid Nedenstående tabel beskriver metrikker og beregnede metrikker: Navn Type Beskrivelse Aggregering Antal fuldtidsstillinger Optælling af antallet af fuldtidsstillinger Last nonempty Antal medarbejdere Optælling af antallet af medarbejdere Sum Gennemsnitligt antal medarbejdere Beregning af det gennemsnitlige antal medarbejdere over tid Average of children Summeret alder i måneder Opsummeret alder for medarbejderne i måneder Sum Summeret anciennitet i måneder Opsummeret anciennitet for medarbejderne i måneder Sum Antal medarbejdere uden fraværsdage i 6 måneder Optælling af medarbejdere der ikke har fraværsdage de seneste 6 måneder Average over time Antal langtidsfriske medarbejdere Optælling af antal langtidsfriske medarbejdere Sum Gennemsnitlig antal langtidsfriske medarbejdere Beregning af det gennemsnitlige antal langtidsfriske medarbejdere over tid Average over time Antal medarbejdere seneste 6 måneder Løbende optællingen af antallet af medarbejdere de foregående 6 måneder Gennemsnitlig anciennitet Beregning af den gennemsnitlige anciennitet Gennemsnitligt personale afgang Beregning af andelen af personalet som er afgået Gennemsnitligt personale tilgang Beregning af andelen af personalet som er fragået D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 33 af 102

34 5.2.4 Aktivitet Aktivitetsfacten er koblet til tidsdimensionen på månedsniveau (og dagsniveau for ansættelsesdatoer). Der eksisterer en række pr. medarbejder pr. måned. Fact ens unikke nøgle er: Medarbejder Tid Nedenstående tabel beskriver metrikker og beregnede metrikker: Navn Type Beskrivelse Aggregering Antal aktive dage Optælling af antal aktive dage Sum Antal aktive dagsværk Optælling af antal aktive dagsværk Sum Kvote for aktivetet Antal fraværsdage x Kvote Average of children 5.3 Afhængigheder til kalenderhierarkierne Følgende s har afhængigheder til kalenderhierarkierne. D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 34 af 102

35 Afhængighed Gennemsnitligt antal unikke medarbejdere over måneder Gennemsnitligt antal unikke medarbejdere over måneder personnummer opgjort Personale tilgang Personale afgang Gennemsnitligt personale tilgang Antal medarbejdere Gennemsnitligt personale afgang Antal aktive fraværsperioder Gennemsnitligt antal medarbejdere seneste 6 måneder Antal medarbejdere uden fraværsdage i 6 måneder Antal medarbejdere med fraværsdage Antal aktive dage ÅTD Antal fraværsdage ÅTD Fraværsprocent total ÅTD Antal aktive dagsværk ÅTD Antal fraværsdagsværk ÅTD Fraværsprocent for dagsværk ÅTD Fraværsprocent for dagsværk total ÅTD 5.4 Relationelt datagrundlag Det relationelle datagrundlag er beskrevet i D0180 Den fysiske datamodel. D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 35 af 102

36 6 Borger Borgerområdet understøtter følgende analyser: Befolkningsudvikling fordelt på bl.a. aldersgrupper og civilstande Geografisk fordeling af borgere Figur 8 Datamodel for borger illustrerer sammenhængen imellem borgerfacten og de relaterede dimensioner. 6.1 Dimensioner Figur 8 Datamodel for borger Dimensioner for borgerområdet beskrives i de følgende afsnit Alder Aldersdimensionen tillader analyse af aldre ud fra en række definerede grupperinger Attributter og hierarkier Dimensionen indeholder følgende hierarkier: D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 36 af 102

37 Navn Niveauer Beskrivelse Femårsgruppering Gruppering År Måneder Grupperingsniveauet indeholder følgende intervaller: 04 år, 59 år, 1014 år, osv. indtil 100+ Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Tiårsgruppering Gruppering År Måneder Grupperingsniveauet indeholder følgende intervaller: 09 år, 1019 år, 2029 år, osv. indtil 100+ Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Skolegruppering Gruppering År Måneder Grupperingsniveauet indeholder følgende intervaller: 02 år, 35 år, 6 år, 716 år, 1719 år, 2266 år og 67+ år Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Gruppering udsatte børn og unge Gruppering År Måneder Grupperingsniveauet indeholder følgende intervaller: 017 år, 1823 år, 2466 år og 67+ år Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Standardgruppering Gruppering År Måneder Grupperingsniveauet indeholder følgende intervaller: 017 år, 1829 år, 3039 år, 4049 år, 5059 år og 67+ år Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Ældregruppering Gruppering overordnet Gruppering detaljeret År Måneder Grupperingsniveauet indeholder på det overordnede niveau følgende intervaller: 0 til 64 år og 65+ år På det detaljerede niveau er der følgende intervaller: 017 år, 1864 år, 6569 år, 7074 år, 7579 år, 8084 år, 8589 år og 90+ år Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Udover hierarkier er der følgende attributter til rådighed til analyse af data: D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 37 af 102

38 Navn Beskrivelse Måneder Borgerens alder i måneder År Borgerens alder i år Borger Borgerdimensionen understøtter dokumentation af borgeranalyser helt ned på personniveau. Desuden indeholder dimensionen kun borgere for den enkelte kommune, maksimalt (se eventuelt [D0150]). Borgerdimensionen vil dog opsamle historik i form af eksempelvis døde borgere. Definitionen af borgere tilhørende en given kommune kan vise sig ved detaljeret design at være mere kompleks, end hvad man måske skulle forvente. Der er eksempelvis identificeret følgende tilfælde: Attributter og hierarkier Dimensionen indeholder ingen hierarkier, da den primært er tænkt til dokumentation. Der er følgende attributter til rådighed til analyse af data: Navn Beskrivelse Personnummer Eksempelvis Efternavn Eksempelvis Boje. Fornavn Eksempelvis Mikkel. Navn Sammensat: [Fornavn] [Efternavn], eksempelvis Mikkel Boje. Fødselsdato Eksempelvis Køn Eksempelvis M eller K Borgerstatus Borgerstatus indeholder en række relaterede forhold omkring borgere, der kan ændre sig over en borgers levetid Attributter og hierarkier Dimensionen indeholder følgende hierarkier: D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 38 af 102

39 Navn Niveauer Beskrivelse Niveauet Aktiv indeholder følgende: Status Aktiv Status Ja og Nej Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Udover hierarkier er der følgende attributter til rådighed til analyse af data: Navn Beskrivelse Civilstand Eksempelvis Gift Geografi (Adresse) Geografidimensionen benyttes som konform dimension på tværs af dataområder. Dimensionen baseres på CPRdata, hvormed der opnås en høj og ensartet datakvalitet for adresser på tværs af dataområder Attributter og hierarkier Dimensionen indeholder følgende hierarkier: D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 39 af 102

40 Navn Niveauer Beskrivelse By Kommune By Adresse Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Postnummer Kommune Postnummer Adresse Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Befolkningsdistrikt Kommune Befolkningsdistrikt Adresse Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Byfornyelsesdistrikt Kommune Byfornyelsesdistrikt Adresse Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Skoledistrikt Kommune Skoledistrikt Adresse Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Socialdistrikt Kommune Socialdistrikt Adresse Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Valgdistrikt Kommune Valgdistrikt Adresse Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Postdistrikt Kommune Postdistrikt Adresse Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Land Land Region Kommune Vej Adresse Hierarkiet er naturligt, hvormed der er en entilmangerelation imellem niveauerne. Det bemærkes, at eksempelvis by og postnummer ikke kan kombineres i naturlige hierarkier. Dette gælder generelt for hierarkier på tværs af såkaldte distrikter (både by og postnummer er selvstændige distrikter). Unaturlige hierarkier er undladt af ydelseshensyn. Såfremt der D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 40 af 102

41 viser sig et behov, kan det analyseres, hvorvidt det vil kunne lade sig gøre at oprette unaturlige hierarkier som f.eks. By Postnummer uden at forringe ydelse for meget. Udover hierarkier er der følgende attributter til rådighed til analyse af data: Navn Beskrivelse Bygningsnummer Eksempelvis Æblevej. Vej Eksempelvis Æblevej. Vejnummer Eksempelvis Facts I de følgende afsnit beskrives de facts, der benyttes til analyse inden for personaleområdet Borger Borgerfacten er koblet til tidsdimensionen på månedsniveau. Der eksisterer en række pr. måned. Fact ens unikke nøgle er: Borger (personnummer) Tid (måned) Nedenstående tabel beskriver metrikker og beregnede metrikker: D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 41 af 102

42 Navn Type Beskrivelse Aggregering Første antal borgere Antal borgere den første i måneden med fuld tilbageregulering. Over tid tages første registrering; eksempelvis januarsmåling ved analyse på år og april ved analyse på 2. kvartal. First nonempty value Første antal borgere vægtet Antal borgere hvor hver borger indgår vægtet efter antal dage, borgeren har været tilknyttet kommunen. Over tid tages første registrering; eksempelvis januarsmåling ved analyse på år og april ved analyse på 2. kvartal. First nonempty value Gennemsnitligt antal borgere Antal borgere den første i måneden med fuld tilbageregulering. Over tid tages et gennemsnit af registreringer; eksempelvis summen af januar, februar og marts divideret med 3 ved analyse på 2. kvartal. Average of children Gennemsnitligt antal borgere vægtet Antal borgere hvor hver borger indgår vægtet efter antal dage, borgeren har været tilknyttet kommunen. Over tid tages et gennemsnit af registreringer; eksempelvis summen af januar, februar og marts divideret med 3 ved analyse på 2. kvartal. Average of children Seneste antal borgere Antal borgere den første i måneden med fuld tilbageregulering. Over tid tages seneste registrering; eksempelvis decembermåling ved analyse på år og juni ved analyse på 2. kvartal. Last nonempty value Seneste antal borgere vægtet Antal borgere hvor hver borger indgår vægtet efter antal dage, borgeren har været tilknyttet kommunen. Over tid tages seneste registrering; eksempelvis decembermåling ved analyse på år og juni ved analyse på 2. kvartal. Last nonempty value Akkumuleret antal borgere Antal borgere hvor værdien summeres over tid. Er der borgere i januar, februar og marts, vil metrikken returnerer for første kvartal. Sum D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 42 af 102

43 Navn Type Beskrivelse Aggregering Akkumuleret antal borgere vægtet Vægtet antal borgere hvor værdien summeres over tid. Er der borgere i januar, februar og marts, vil metrikken returnerer for første kvartal Sum Fraflyttet borgere Antal indbyggere der er flyttet fra kommunen til en anden kommune pr indbyggere i kommunen Average of children Tilflyttet borgere Antal indbyggere der er flyttet til kommunen fra en anden kommune pr indbyggere i kommunen Average of children Indrejste borgere Antal personer er registreret som indrejst til den pågældende kommunen pr indbyggere i kommunen Average of children Udrejste borgere Antal personer er registreret som udrejst fra den pågældende kommunen pr indbyggere i kommunen Average of children Fødte borgere Antal personer der er født ud af alle indbyggere i kommunen i den pågældende måned Average of children Døde borgere Antal personer der er døde ud af alle indbyggere i kommunen i den pågældende måned Average of children Første antal borgere per 1000 Antal borgere per 1000 den første i måneden med fuld tilbageregulering. Over tid tages første registrering; eksempelvis januarsmåling ved analyse på år og april ved analyse på 2. kvartal. Gennemsnitsalder for første antal borgere Summeret alder i måneder for valgte borgere divideret med 12 og antallet af valgte borgere. Alderen (i måneder) opgøres den første i den aktuelle måned. Gennemsnitsalder for gennemsnitligt antal borgere Summeret alder i måneder for valgte borgere divideret med 12 og antallet af valgte borgere. Alderen (i måneder) opgøres den første i den aktuelle måned. D0130 Logisk Datamodel Version 2.2 Udskrevet: :57:00 Side 43 af 102