KOMBIT FLIS Version: 3.1 Status: Godkendt Godkender: Christian Gjerulff
Dokumenthistorik Version Dato Navn Status Bemærkninger 0.1 26012012 Udkast 0.2 30012012 Udkast Indholdsfortegnelse oprettet Indholdsfortegnelse tilrettet 1.0 05032012 Endelig 1.1 15032012 Udkast 1.2 03052012 Endelig 1.3 23052012 Endelig Design af nøgletalsdatamart tilføjet Opdateret med KOMBITkommentarer. Opdateret efter personaleafklaringsmøde. 1.4 19062012 Endelig Tilføjet design af ældre. 1.5 28092012 Endelig ÆØ 43. Afsnit 5.1.2. 1.6 18102012 Endelig ÆØ 46. Afsnit 0. 1.7 21112012 Endelig Dataholds Mødereferat 04062012 indført. 1.8 04122012 Endelig Opdateret med udvidede kontoplanskomponenter. Afsnit 4. 1.9 01022013 Endelig 2.0 04022013 Endelig 2.1 08022013 Endelig Opdateret med design for skoleområdet. Opdateret som følge af #66. Klargjort ældreområdet til review (afsnit 11). 2.2 12122013 Endelig Opdateret hele dokumentet til release 2.0 godkendelse incl. VH. 3.0 04022014 Godkendt Dokument godkendt 3.1 18122014 Godkendt Nøgletalsvurdering D0130 Logisk Datamodel Version 2.2 Udskrevet: 10022016 08:57:00 Side 2 af 102
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] http://www.budregn.im.dk/im/site.aspx?p=2895 Primært kapitel 2. Indenrigsministeriet 20060614 [KIMBALL] The Data Warehouse Lifecycle Toolkit Ralph Kimball m.fl. 2008 [EXPERT] Expert Cube Development with Microsoft SQL Server 2008 Analysis Services Chris Webb m.fl. 2009 D0130 Logisk Datamodel Version 2.2 Udskrevet: 10022016 08:57:00 Side 3 af 102
Indholdsfortegnelse 1 INDLEDNING 7 1.1 Formål 8 1.2 Omfang 8 2 FLIS DATAMARTER OG KUBER 9 2.1 Relationelle datamarter 9 2.1.1 Kubeattributter, felter og datatyper 10 2.2 SQL Views som forbindelsesled 10 3 FÆLLES DIMENSIONER 12 3.1.1 Tid 12 3.1.1.1 Attributter og hierarkier 12 3.2 Relationelt datagrundlag 13 4 ØKONOMI 14 4.1 Rapporteringsbehov 15 4.2 Dimensioner 15 4.2.1 Autoriseret kontoplan 15 4.2.2 Udvidet kontoplan 16 4.2.3 Opus [X] dimensioner 20 4.3 Facts 20 4.4 Relationelt datagrundlag 21 5 PERSONALE 23 5.1 Dimensioner 27 5.1.1 Anciennitet 27 5.1.1.1 Attributter og hierarkier 27 5.1.2 Ansættelsesvilkår 28 5.1.2.1 Attributter og hierarkier 28 5.1.3 Fravær 29 5.1.3.1 Attributter og hierarkier 29 5.1.4 Medarbejder 30 5.1.4.1 Attributter og hierarkier 30 5.2 Facts 31 5.2.1 Fravær 31 5.2.2 Fraværsperiode 32 5.2.3 Medarbejder 33 5.2.4 Aktivitet 34 5.3 Relationelt datagrundlag 35 6 BORGER 36 6.1 Dimensioner 36 6.1.1 Alder 36 6.1.1.1 Attributter og hierarkier 36 6.1.2 Borger 38 6.1.2.1 Attributter og hierarkier 38 6.1.3 Borgerstatus 38 6.1.3.1 Attributter og hierarkier 38 6.1.4 Geografi (Adresse) 39 6.1.4.1 Attributter og hierarkier 39 6.2 Facts 41 D0130 Logisk Datamodel Version 2.2 Udskrevet: 10022016 08:57:00 Side 4 af 102
6.2.1 Borger 41 6.3 Relationelt datagrundlag 44 7 NØGLETAL 45 7.1 Dimensioner 45 7.1.1 Nøgletal 46 7.1.1.1 Attributter og hierarkier 46 7.1.2 Sammenligningsgruppe 47 7.1.2.1 Attributter og hierarkier 48 7.2 Facts 50 7.2.1 Nøgletal 50 7.3 Relationelt datagrundlag 51 8 SKOLE 52 8.1 Dimensioner 52 8.1.1 DimElev 52 8.1.1.1 Attributter og hierarkier 52 8.1.2 DimSkole 52 8.1.2.1 Attributter og hierarkier 53 8.1.3 DimKlasse 53 8.1.3.1 Attributter og hierarkier 54 8.1.4 DimPrøveKarakter 55 8.1.4.1 Attributter og hierarkier 55 8.2 Facts 56 8.2.1 Elev 56 8.2.2 FactKarakter 59 8.2.3 FactKlasse 60 8.2.4 FactSkole 61 8.3 Relationelt datagrundlag 63 9 UDSATTE BØRN OG UNGE 64 9.1 Dimensioner 64 9.1.1 DimForanstaltning 64 9.1.1.1 Attributter og hierarkier 64 9.1.2 DimAnbringelsessted 66 9.1.2.1 Attributter og hierarkier 66 9.1.3 DimForanstaltningsmodtager 66 9.1.3.1 Attributter og hierarkier 66 9.2 Facts 67 9.2.1 FactForanstaltning 67 9.2.2 FactDisponeretForbrug 72 9.3 Relationelt datagrundlag 73 10 VOKSNE HANDICAPPEDE 74 10.1 Dimensioner 74 10.1.1 Ydelse 74 10.1.2 Målgruppe 75 10.1.3 Funktionsvurdering 76 10.1.4 Opholdssted 77 10.2 Facts 77 10.2.1 Visiteret borger 77 10.2.2 Ydelse 79 10.3 Relationelt datagrundlag 81 D0130 Logisk Datamodel Version 2.2 Udskrevet: 10022016 08:57:00 Side 5 af 102
11 ÆLDRE 82 11.1 Dimensioner 87 11.1.1 Besøg 87 11.1.2 Ydelse 88 11.1.3 Ydelseslængde 89 11.1.4 Leverandør 89 11.1.5 Tidspunkt 90 11.2 Facts 90 11.2.1 Visiteret ydelsesdetalje 91 11.2.2 Visiteret ydelse 93 11.2.3 Leveret ydelsesdetalje 96 11.2.4 Leveret ydelse 97 11.2.5 Leveret besøgsdetalje 98 11.2.6 Leveret besøg 99 11.2.7 Boligtilbud 100 11.3 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: 10022016 08:57:00 Side 6 af 102
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: 10022016 08:57:00 Side 7 af 102
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: 10022016 08:57:00 Side 8 af 102
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: 10022016 08:57:00 Side 9 af 102
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. 2.1.1 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: 10022016 08:57:00 Side 10 af 102
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: 10022016 08:57:00 Side 11 af 102
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 3.1.1 Tid Tidsdimensionen er en central dimension, der benyttes i alle områder. 3.1.1.1 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: 10022016 08:57:00 Side 12 af 102
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. 153. 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 H1. 3.2 Relationelt datagrundlag Det relationelle datagrundlag er beskrevet i D0180 Den fysiske datamodel. D0130 Logisk Datamodel Version 2.2 Udskrevet: 10022016 08:57:00 Side 13 af 102
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: 10022016 08:57:00 Side 14 af 102
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. 4.2.1 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: 10022016 08:57:00 Side 15 af 102
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: 20.99 og 30.99. 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. 4.2.2 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: 10022016 08:57:00 Side 16 af 102
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: 10022016 08:57:00 Side 17 af 102
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: 10022016 08:57:00 Side 18 af 102
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: 10022016 08:57:00 Side 19 af 102
Navn Beskrivelse OPUS data Angiver om postering er foretaget i et OPUS økonomisystem. Registreringskonto Angiver det kontonummer en postering er foretaget på. 4.2.3 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: 10022016 08:57:00 Side 20 af 102
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: 10022016 08:57:00 Side 21 af 102
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: 10022016 08:57:00 Side 22 af 102
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: 10022016 08:57:00 Side 23 af 102
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: 10022016 08:57:00 Side 24 af 102
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: 10022016 08:57:00 Side 25 af 102
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: 10022016 08:57:00 Side 26 af 102
Figur 7 Datamodel for aktivitet 5.1 Dimensioner Dimensioner for personaleområdet beskrives i de følgende afsnit. 5.1.1 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. 5.1.1.1 Attributter og hierarkier Dimensionen indeholder følgende hierarkier: D0130 Logisk Datamodel Version 2.2 Udskrevet: 10022016 08:57:00 Side 27 af 102
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 5.1.2 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. 5.1.2.1 Attributter og hierarkier Dimensionen indeholder følgende hierarkier: D0130 Logisk Datamodel Version 2.2 Udskrevet: 10022016 08:57:00 Side 28 af 102
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 (3204123), Plejeassistent (23041923) 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. 5.1.3 Fravær Fravær er en samling af informationer omkring hver enkelt registrering af fravær. Dimensionen benytter type1historik. 5.1.3.1 Attributter og hierarkier Dimensionen indeholder følgende hierarkier: D0130 Logisk Datamodel Version 2.2 Udskrevet: 10022016 08:57:00 Side 29 af 102
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. 5.1.4 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. 5.1.4.1 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: 10022016 08:57:00 Side 30 af 102
Navn Beskrivelse Personalenummer Eksempelvis 3453335. Institutionsnummer Eksempelvis 2552. Personnummer Eksempelvis 0303778844. Efternavn Eksempelvis Boje. Fornavn Eksempelvis Mikkel. Navn Sammensat: [Fornavn] [Efternavn], eksempelvis Mikkel Boje. Fødselsdato Eksempelvis 19770303 Køn Eksempelvis K eller M. Nuværende civilstand Eksempelvis Gift. Ansættelsesdato Eksempelvis 19770303. Ansættelsesstopdato Eksempelvis 19770303. 5.2 Facts I de følgende afsnit beskrives de facts, der benyttes til analyse inden for personaleområdet. 5.2.1 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: 10022016 08:57:00 Side 31 af 102
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 5.2.2 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: 10022016 08:57:00 Side 32 af 102
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: 10022016 08:57:00 Side 33 af 102
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: 10022016 08:57:00 Side 34 af 102
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: 10022016 08:57:00 Side 35 af 102
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. 6.1.1 Alder Aldersdimensionen tillader analyse af aldre ud fra en række definerede grupperinger. 6.1.1.1 Attributter og hierarkier Dimensionen indeholder følgende hierarkier: D0130 Logisk Datamodel Version 2.2 Udskrevet: 10022016 08:57:00 Side 36 af 102
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: 10022016 08:57:00 Side 37 af 102
Navn Beskrivelse Måneder Borgerens alder i måneder År Borgerens alder i år 6.1.2 Borger Borgerdimensionen understøtter dokumentation af borgeranalyser helt ned på personniveau. Desuden indeholder dimensionen kun borgere for den enkelte kommune, maksimalt 500.000 (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: 6.1.2.1 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 0303778844. Efternavn Eksempelvis Boje. Fornavn Eksempelvis Mikkel. Navn Sammensat: [Fornavn] [Efternavn], eksempelvis Mikkel Boje. Fødselsdato Eksempelvis 19770303 Køn Eksempelvis M eller K. 6.1.3 Borgerstatus Borgerstatus indeholder en række relaterede forhold omkring borgere, der kan ændre sig over en borgers levetid. 6.1.3.1 Attributter og hierarkier Dimensionen indeholder følgende hierarkier: D0130 Logisk Datamodel Version 2.2 Udskrevet: 10022016 08:57:00 Side 38 af 102
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. 6.1.4 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. 6.1.4.1 Attributter og hierarkier Dimensionen indeholder følgende hierarkier: D0130 Logisk Datamodel Version 2.2 Udskrevet: 10022016 08:57:00 Side 39 af 102
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: 10022016 08:57:00 Side 40 af 102
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 1. 6.2 Facts I de følgende afsnit beskrives de facts, der benyttes til analyse inden for personaleområdet. 6.2.1 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: 10022016 08:57:00 Side 41 af 102
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 10.000 borgere i januar, februar og marts, vil metrikken returnerer 30.000 for første kvartal. Sum D0130 Logisk Datamodel Version 2.2 Udskrevet: 10022016 08:57:00 Side 42 af 102
Navn Type Beskrivelse Aggregering Akkumuleret antal borgere vægtet Vægtet antal borgere hvor værdien summeres over tid. Er der 10.000 borgere i januar, februar og marts, vil metrikken returnerer 30.000 for første kvartal Sum Fraflyttet borgere Antal indbyggere der er flyttet fra kommunen til en anden kommune pr. 1000 indbyggere i kommunen Average of children Tilflyttet borgere Antal indbyggere der er flyttet til kommunen fra en anden kommune pr. 1000 indbyggere i kommunen Average of children Indrejste borgere Antal personer er registreret som indrejst til den pågældende kommunen pr. 1000 indbyggere i kommunen Average of children Udrejste borgere Antal personer er registreret som udrejst fra den pågældende kommunen pr. 1000 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: 10022016 08:57:00 Side 43 af 102