Dimensioner – nogle aspekter

af Joakim Dalby

 

Indledning

Dimensioner og dimensionsdata identificeres i forretningen og dannes enten via kilde­systemernes data der levererer dimensionsdata eller de udtrækkes fra leveret fact­data, eller dimensionsdata genereres på basis af regelsæt der enten er program­me­ret eller bliver administreret af brugerne via en applikation. Se praktiske eksempler herpå under menupunktet {Kunder/Projekter} {TDC Mobil Sol BI løs­ning} Eksempler på Tid måned dimensioner ses under menu­punk­tet {Tips} {Dato som heltal}.

 

Formål med dimension

·         At den oversætter en kode fra en kilde leverance til en værdi som derved giver en tekst til koden. Teksten kan være tilpasset brugernes behov og vil i så fald være forskellig fra kilden.

·         At den grupperer en kode fra en kilde leverance i en hierarkisk organi­se­rings­struk­tur der enten er opdelt efter Niveau eller MorBarn princippet (dimensions­typer).

·         At den hierarkiske organisering betyder, at factdata’s talværdier såsom be­løb, antal og måling automatisk kan ses på summerede placeringer i hie­rarkiet f.eks. factdata pr. dato ses på summeringsplaceringerne måned, kvartal, halvår eller år.

·         At den håndterer enten ukendte koder fra en kilde leverance eller at kilde le­ve­­ran­cen er uden koder.

 

OnLine Analytical Processing (OLAP for multidimensional data analysis) er en fler­di­men­sio­nel kube, som præ­sen­te­rer data via dimen­sio­ner, der er forretningens ind­gang til analysevariable (measures) gennem en kube, der kan ses som en slags Rubiks terning (Rubik’s cube billede), hvor man kan vende og dreje de enkelte dele efter behov gennem for­skel­lige funk­tio­na­li­te­ter på di­men­sio­ner, som in­de­hol­der en hierarkisk niveau opdeling af data:

·   slice-and-dice hvor dimensionsdata skæres til med filter/zoom/kriterier og di­men­sio­ner placeres i forspalten og danner rækker, og som kolonner og danner en kryds­ta­bu­le­ring eller pivot opstilling

·   drill-down til præsentation af dimensionsdata i gradvis større detaljeringsgrad

·   roll-up ser dimensionsdata på højere aggregeringsniveau og summeret (drill-up)

·   drill-through viser de bagvedliggende data fra kildesystemet

·   drill-across sammenstiller analysevariable fra flere kuber med fælles di­men­sio­ner

·   ranking or sorting præsenterer dimensionsdata efter en analysevariabel f.eks. kundesegmenter i faldende orden efter salget

·   top or bottom til præsentation af f.eks. top 5 produkter eller 10 dårligste kunder salgs­mæs­sigt

·   indtaste cellekommentar på kombinationer af dimensionsdata og analyse­vari­able som for­kla­ring til et nøgletal f.eks. et beløb eller en procent og at kommentarer­ne straks kan ses og læses af andre

·   indtaste værdi i analysevariabel f.eks. måltal eller budget beløb på kombinatio­ner af dimensionsdata så værdien straks kan ses af andre og indgå i deres analyser

Se eksempel med OWC inklusiv en række programmeret funktioner.

 

Dimensionstyper

Der findes to typer af dimensioner som præsenteres her sammen med krav til dimen­sio­ner­nes data.

 

Niveau dimension (Level based dimension på engelsk)

Dimensionsdata er opdelt i et hierarki af niveauer som navngives. En klas­sisk Ni­ve­au dimension er Periode, hvis hierarki går fra År til Måned f.eks.:

År→Halvår→Kvartal→Måned.  År kaldes første niveau og Måned for fjerde ni­veau. Dato kan være placeret under Måned for at summerer datoer sammen og i sær­lige tilfælde se data på dato niveau eller via drill through i en kube d.v.s. få fact­data frem på skærmen med de enkelte datoer, så der ses en forklaring på en må­­neds­sum.

Verdensdel→Land→By→Adresse er et andet eksempel, hvor nogle lande har mange byer og andre lande kun en by f.eks. Monaco og Singapore.

Niveau dimensioner er balanceret, hvilket vil sige, at alle dimensionsdata er re­præ­­sen­teret i alle niveauer f.eks. findes der ikke et kvartal uden en måned eller et land uden en by eller en verdensdel uden et land. Sydpolen er måske en undtagelse, men så må der opfindes et Uden land, Uden by og Uden adresse, så der er dimensionsdata på alle niveauer.

         

MorBarn dimension (Parent Child based dimension på engelsk)

Dimensionsdata er opdelt i et hierarki af ukendte niveauer og kan enten indeholde ensartede data eller forskelligartede data. Antallet af niveauer er ikke kendt i en MorBarn dimension. En klassisk MorBarn ensartet data dimension er et medar­bej­der hierarki, hvor alle dimensionsdata er medarbejder-referencer, der er placeret i et hierarki, hvor den øverste medarbejder kaldes direktør som har en række medarbejdere under sig kaldet underdirektør (en mor har flere børn), og igen har en underdirektør en række medarbejdere under sig kaldet chef. Nogle chefer kan igen have medarbejdere under sig mens andre chefer ingen med­arbej­dere har under sig. En MorBarn forskellig­artet data dimension kunne være et regn­­skab, som indeholder både budget og rea­lise­ret beløbsreferencer, der er place­ret under strukturen med tekster så som »budget« og »rea­lise­ret« d.v.s. en blan­ding af strukturtekster og beløbsreferencer d.v.s. for­skel­lig­artet data. MorBarn dimensioner er uba­lan­ce­ret, d.v.s. dimen­sions­­data er ikke lige meget underopdelt. Et ægte MorBarn hierarki er opdelt, så der findes et og kun et top-datum på øverste niveau, og data under toppen har en reference (fra barn til mor) til top-datum, mens top-datum ingen reference har, d.v.s. den har ingen mor. Et uægte MorBarn hierarki er opdelt, så der findes flere top-data på øverste niveau.

 

Niveau dimension krav til dimensionsdata

1.      Balanceret hierarki af dimensionsdata, der har samme antal niveauer. Leverer en kilde ubalanceret dimensionsdata, må ETL-processen automa­tisk rette data op, så dimensions­data bliver balanceret.

2.      Hvert niveau består af en Kode (heltal/50 tegn) og en Værdi (100 tegn). Måtte kilde eller bruger ikke have en kode, er det ETL eller applikationens opgave automatisk at genere en passende kode, der kan være med til at bestemme sor­terings­orden af dimen­sions­data.

3.      En Kode bestemmer en Værdi pr. niveau (Kode er determinant for en Værdi), derved er Koden entydig/unik inden for hvert niveau af dimensionen.

4.      En Værdi kan godt have flere Koder på samme niveau, fordi en værdi sagtens kan indgå i for­skel­lige delhierarkier f.eks. to verdensdele har samme ukendte land eller to områder begge er opdelt i Nord, Øst, Syd og Vest. Det tillades og­så, at et niveau har flere underniveauer med samme værdi med forskellige koder.

5.      En Kode skal være entydig/unik over alle niveauer i dimensionen, altså en udvi­del­se af punkt 3, hvilket er et alternativ til sikring af komplet entydighed.

 

MorBarn dimension krav til dimensionsdata

1.      Ubalanceret hierarki af enten ensartet eller forskelligartet og enten ægte eller uægte dimensionsdata placeret i forhold til hinanden i en mor-barn struktur, hvor et barn har en og kun en mor, og hvor en mor har nul, en eller flere børn.

2.      Hver placering består af en Kode (heltal/50 tegn), en Værdi (100 tegn) og en Sidste­Kode (Parent reference) (heltal/50 tegn) som er en reference fra barn til mor. Måtte kilde eller bruger ikke have en kode, er det ETL eller applikationens opgave automatisk at genere en passende Kode og udfylde SidsteKode.

3.      En Kode bestemmer en Værdi i hele dimensionen (Kode er determinant for en Værdi), derved er Koden entydig/unik over hele dimensionen.

4.      En Værdi kan godt have flere Koder, fordi samme værdi sagtens kan indgå i for­skel­lige placeringer. Det tillades også, at en mor har flere børn med samme værdi, altså søskende der hedder det samme men med forskellige koder.

5.      Punkt 3 og 4 medfører, at Kode er entydig i hele dimensionen. SidsteKode er blank (null) for top-datum og kan ikke være entydig, idet flere børn kan have samme mor, d.v.s. børnenes SidsteKode er ens.

 

Ukendt og uden dimensionsdata

Det kan forekomme, at der leveres factdata fra kilde leverancen, som:

  • Indeholder en kode der er ukendt d.v.s. ikke findes inden for dimensionens data, enten fordi koden er forkert angivet hos kilden eller fordi di­men­sions­data ikke er up-to-date.
  • Er uden en kode til en dimensionsdata d.v.s. blank (null).

Det er påkrævet, at alle factdata fra kilde leverancen kan placeres i en dimension, så­le­des at ingen factdata går tabt i datawarehouse og tilhørende kube. Derfor er det vigtigt, at oven­stå­ende to situationer bliver håndteret af ETL, hvor der lægges op til, at en dimension på forhånd altid indeholder dimensionsdata for et:

Ukendt→Uden hierarki.

Når factdata indeholder en ukendt kode, placeres koden automatisk af ETL under Ukendt dimensionsdata med følgende:

       Kode = Koden fra kilden,  Værdi = Koden fra kilden + ” Ukendt”.

Når factdata er uden en kode, tildeles factdata en kode automatisk af ETL, som for­årsa­ger, at factdata bliver placeret under Uden dimensionsdata under Ukendt hierar­kiet. Eksempel på Ukendt/Uden vist for en Niveau dimension (koden er vist i parentes):

 

De to »Ukendte« lande bør undersøges nærmere, enten er der tale om forkerte koder fra kilde leverancen eller også er dimensionen ikke up-to-date, hvorved en bruger i sidste tilfælde skal have rettet værdierne til de rigtige landnavne og pla­ce­ret dem ind i den hierarkiske orga­nise­rings­struk­tur via applikationen. Når der op­træ­der fact­data med »Uden«, skal det vurderes af brugeren og kil­den, hvorvidt der er tale om en fejl leverance. Det vur­de­res, at en leverance uden kode er yderst sjældent, da kilden også har et ansvar for at sikre en korrekt leverance, d.v.s. altid udfyldte koder, mens en ukendt kode kan forekomme især i de til­fæl­de, hvor det er en bruger som ajour­fører en dimension, og derved ikke har fået indsat de nyeste koder, som kil­de leverancen refererer til.

 

Ændring af dimensionsdata

Kildesystemer eller brugerens egne dimensioner kan finde på at ændre dimensions­data på forskellig måde, som beskrives nærmere her. Der bør altid gælde, at en dimension har sin egen interne repræsentation (et Id) af laveste kode i Niveau dimen­sio­nen og ko­der­ne i MorBarn dimensionen (surrogate key eller artificial key på engelsk, typisk et fort­lø­bende heltal), så koder kan blive ændret uden at dimen­sions­data re­fe­ren­cen skal ændres for tidligere indlæste factdata, da factdata re­fe­ren­cen også anvender den interne repræsentation, d.v.s. di­men­sions­frem­med­nøg­len i factdata.

 

Kode eller Værdi ændring af dimensionsdata

Ved ændring af dimensionsdata kode eller værdi i kildesystemer eller i bruger di­men­­sio­ner i appli­ka­tionen, gælder tre forhold. Det er sjældent, at en kode ændrer sig, og me­get ofte at værdien til en kode ændrer sig, er de tre forhold beskrevet når værdien æn­drer sig.

 

  • Ændring af værdi med både bagudrettet og fremadrettet kraft

Ændres en dimensionsdata værdi, så slår ændringen igennem på alle de fact­data som refererer til dimensionsdataet. D.v.s. både tidligere indlæste fact­data og kommende factdata.

 

  • Ændring af værdi med kun fremadrettet kraft

Ønskes en ændring af en dimensionsdata værdi kun at virke på kommende factdata, så skal der ikke foretages nogen værdi-ændring men til gengæld indsættes en ny dimen­sions­data med den ændrede værdi sammen med en ny ikke-eksisterende kode, og det er den nye kode, som de kommende fact­data skal referere til. Derved er den oprindelige værdi bevaret i dimen­sions­data og de tidligere indlæste factdata som refererer til dimensionsdataet an­vender fortsat den oprindelige værdi. Det kan også være, at der i stedet blø­des op på kravet om Kode entydighed fordi der anvendes Id (også Id for SidsteKode) og samtidig indføres en Startdato og Slutdato for, hvornår den gamle værdi er gyldig og hvornår den nye Værdi er gyldig fra (slutdato kan sættes til 31-12-2050), og ud fra en dato eller år i factdata kan en kode bestemme den rette værdi ud fra datoerne på dimensionsdata.

 

  • Ændring af værdi med kun bagudrettet kraft

Ønskes en ændring af en dimensionsdata værdi kun at virke på tidligere ind­læste factdata, så skal der både foretages en ændring af værdien på den ek­si­ste­ren­de dimensionsdata og indsættes en ny dimensionsdata med den gamle værdi sammen med en ny ikke-eksisterende kode, og det er den nye kode, som de kommende factdata skal referere til. Derved er den oprin­de­lige værdi bevaret i dimensionsdata for kommende factdata og tidligere indlæste factdata har fået deres værdi ændret.

 

Hierarkisk ændring af dimensionsdata

Der gælder de samme forhold som ved ændring af værdier, d.v.s. den hierarkiske æn­dring kan gøres enten bagud og/eller fremadrettet. For Niveau dimensionen er det vig­tigt, at det laveste niveaus kode forbliver uændret fordi kommende factdata refere­rer dertil, men at de højere liggende koder og værdier ændres som følge af ny placering af dimensionsdata i hierarkiet i dimensionen. For MorBarn dimensionen er det simpelt at ændre i hierarkiet, fordi det blot betyder, at et barn får en anden mor, og har barnet selv børn, så betyder det, at disse børn får en anden bedste­mor.

 

Sletning af dimensionsdata

Sletning af dimensionsdata vil forekomme yderst sjældent, fordi der i så fald skal rettes i tid­lige­re indlæste factdata, så de ikke mere refererer til den slettede di­men­­sions­data. Men factdata bestemmer, hvor længe en dimensionsdata er aktiv, for stop­per kom­­men­de factdata med at referere til dimen­sions­data, så kan man sige, at dimen­sions­data er udgået, men formentlig vil tidligere indlæste factdata referere til di­men­sions­data, så bagud i tid er di­men­­sions­data fortsat aktiv.

 

I forbindelse med rullerende periode i factdata, f.eks. når januar 2006 indlæses, så slet­tes enten hele år 2003 eller januar 2003, vil det betyde, at udgået dimensions­data til sidst ikke mere har en reference blandt factdata, og det må overvejes om en au­to­ma­tisk oprydning skal fjerne disse dimensionsdata. Der kan jo sagtens ek­si­stere di­men­sions­data, som factdata ikke refererer til over en periode, men senere vil kom­men­­de factdata igen referere til dimen­sions­data, så det kan være svært at afgøre, hvornår dimensionsdata er helt dødt. Også overvejes om dimensionsdata ikke slettes, men markeres udgået med en slutdato.

 

Fiksering af dimensionsdata

Ændringer i dimensionsdata har gået på at slå igennem på enten eksi­ste­ren­de eller kommende factdata, men det kan måske også forekomme, at dimen­sions­data skal bevares uændret for hver leverance af factdata. Det vil sige, at di­men­sions­data låses fast pr. factdata leverance, svarende til at man laver data­ware­house ski­ver og skiver af kuber. Derved er ændring af dimensionsdata ikke mere aktuelt, for hver leverance har sit billede af dimen­sions­data. Ulempen ved skivningen af dimen­sions­data og factdata er, at det kan være svært at lave ana­ly­ser på tværs af de skivede perioder, fordi i en periode kan der ligge mange dimen­sions­data på et un­der­niveau, som betyder, at overniveauets sum på en analyseva­ria­bel bliver stor i forhold til en anden periode, hvor samme overniveau kun har få dimensionsdata under sig. Man kan f.eks. implementere en dimension som altid er et øjebliksbillede med de aktuelle værdier og hierarkiske placeringer, og at man sikrer, at factdata som stræk­ker sig over flere år, anvender denne dimension, så der kan udarbejdes tværgående analyser over flere år.

 

Ved ændring af værdi med kun fremadrettet kraft findes forskellige modeller til hånd­tering af ændringen f.eks. foretages ændringen kun ved årsskifte, og man ønsker at bevare de tidligere års vær­dier, kan dimensionen med fordel inddeles i topniveauer for de enkelte år. Det be­tyder imidlertid, at de dimensionsdata der anvendes i alle år findes som dubletter under de enkelte topniveau år, men når brugeren vælger et bestemt år i dimen­sio­nen ses kun dette års gældende dimensionsdata. Koden forbliver ikke mere enty­dig i en årstalsopdelt dimension, men når kod­e du­blet­terne har hver sit Id der anvendes i factdata, giver det ikke problemer med dimensions­frem­med­nøglen i fact­data.  Eksempel på en Regnskab dimension hvis data er årstalsopdelt:

 

Fra 2005 til 2006 er kode 1010’s værdi blevet ændret fra Konsulent til Råd­giv­ning, og Serviceaftale er udgået i 2006 mens ny Analyse/Design er kommet til. Derud­over er Undervisning blevet flyttet fra Indtægter i 2005 til Andre indtægter i 2006, hvorved det forventes at summen af Indtægter i 2006 bliver mindre end i 2005 og summen af Andre indtægter bliver større i 2006. Derved kan Indtægter og Andre indtægter ikke sammenlignes mellem årene, fordi deres definitioner er forskellige. Når Tid dimensionen vælges til f.eks. 2006, vælger man også 2006 i Regnskab dimensionen og får derved vist hierarkiet og teksterne gældende i 2006, og er der ingen beløb på Analyse/Design kan den alligevel vises, mens Serviceaftale ikke vises i 2006 fordi den udgik i 2005.

 

Historik i dimensionsdata for en dimension kræver en nøje analyse og et solidt design og im­ple­men­ta­tion for at virke tilfredsstillende til analyse og rap­por­te­rings­for­mål.

 

Dimension tabelstruktur

Et systems mange dimensioner placeres ofte i selvstændige tabeller, fordi di­men­sio­ner­ne har en række ekstra oplysninger (egenskaber, attributter), der kan anvendes som grundlag for nye dimensioner, eksempelvis en Person dimension med Landsdel som topniveau: Landsdel→Cprnr Navn, hvor Navn udgør Værdi og Cprnr udgør Kode, og hvor DimPersonId findes i factdata. De andre Id’er anvendes til både entydighed via key i dimensionen og til sortering af data. Det giver to ekstra dimensioner kaldet Aldersgruppe og Køn, og de placeres inde under Person dimensionen, hvilket kaldes indlejret dimensioner.

 

DimPer-sonId

Cprnr

Navn

Lands-delId

Landsdel

Alder

Id

Alders-gruppe

KønId

Køn

1

090880-3019

Ib Pihl

100

Sjælland

2

20-50

1

Mand

2

231150-0387

Per Toft

300

Jylland

3

51-75

1

Mand

3

070206-5410

Pia Gro

200

Fyn

1

0-19

2

Kvinde

4

150182-0152

Maj Pihl

100

Sjælland

2

20-50

2

Kvinde

 

Person dimension implementeret i SQL Server Analysis Services

 

Sortering af dimensionsdata sker ofte efter deres kode, men nogle gange er koden ikke anvendelig eller i brugerens egne dimensionersdata ønskes en særlig sorte­rings­orden (ordering på engelsk), så dimensionsdata tabellen har et ekstra sorte­ringsfelt der anvendes i kuben, eksempelvis:

 

DimOverskudsstatusId

Kode

Værdi

Sortering

1

Grøn

Større end 1 mill kr.

3

2

Gul

Mellem 0 og 1 mill kr.

2

3

Rød

Mindre end 0 kr.

1

 

Dimensionsdata kan også placeres i en stor tabel DimensionData, der har en frem­med­nøgle til en Dimension tabel med listen over dimensioner og deres metadata, d.v.s. en en-til-mange relation mellem Dimension og DimensionData tabellerne. Ekstra op­lys­nin­ger­ne placeres i selvstændige tabeller med en en-til-en relation til DimensionData tabellen.

 

Eksempel på en dimension med indbygget flere hierarkier

Nedenfor er dimensionsværdier for boligområder grupperet i tre hierarkier hvor de enkelte Id felter også står for sortering, så Alle øvrige (boligområder) placeres til sidst i hierarkierne for Ghetto, Udvalgt og Urbanplanen, hvor Udvalgt er en del­mæng­de af Ghetto, mens Urbanplanen er helt sin egen. BoligområdeId er referen­cen til fact tabellen fra denne Boligområde dimensionstabel med tre hierarkier:

 

Bolig-områdeId

Bolig-

område-

Navn

Udvalgt-

Boligom-

rådeId

Udvalgt-

Boligom-

rådeNavn

Ghetto-

Boligom-

rådeId

Ghetto-

Boligom-

rådeNavn

Urban-

planen-

Boligom-

rådeId

Urban-

planen-

Boligom-

rådeNavn

0

Alle øvrige

99

Alle øvrige

99

Alle øvrige

99

Alle øvrige

1

Akacieparken

1

Akacieparken

1

Akacieparken

99

Alle øvrige

2

Aldersrogade

2

Aldersrogade

2

Aldersrogade

99

Alle øvrige

3

Bispeparken

99

Alle øvrige

3

Bispeparken

99

Alle øvrige

4

Blågården

99

Alle øvrige

4

Blågården

99

Alle øvrige

5

Gadelandet/

Husumgård

99

Alle øvrige

5

Gadelandet/

Husumgård

99

Alle øvrige

6

Hørgården

99

Alle øvrige

6

Hørgården

99

Alle øvrige

7

Lundtofte-gade

3

Lundtoftegade

7

Lundtofte-gade

99

Alle øvrige

8

Mjølnerparken

4

Mjølnerparken

8

Mjølnerparken

99

Alle øvrige

9

Sjælør Boulevard

99

Alle øvrige

9

Sjælør Boulevard

99

Alle øvrige

10

Tingbjerg

5

Tingbjerg

10

Tingbjerg

99

Alle øvrige

11

Urbanplanen

99

Alle øvrige

99

Alle øvrige

1

Urbanplanen

 

I Targit tager det således ud, når Boligområde dimensionen åbnes, vises de tre hie­rar­kier, og de kan bruges uafhængig af hinanden i tre krydstabuleringer:

 

 

Implementeret på følgende måde i SQL Server 2008 Business Intelligence Develop­ment Studio i et Analysis Services projekt (olap kube):