Design datamodell – stjernediagram som støtter dashboardet
Med utgångspunkt i dashboard skissens som deltagaren fra kunden tegnet under Design Workshop skal vi nå bidra till å skape et antall forslag til design som kunden til slutt skal velge fra som sitt eget. Konsulenten vil komme med 3 ulike forslag til design:
- En polert utgave av designet som kunden tegnet
- Et standard dashboard som følger beste praksis
- Et kreativt forslag som konsulenten utformer, også basert på beste praksis
Bidra med kunnskap og erfaring i visualisering av fakta
I neste omgang vil kunden velge visualiseringene som faller mest i smak. Dette vil ofte være en kombinasjon av visualiseringer fra alle de 3 forslagene. Det er derfor viktig å foreslå visualiseringer som lar seg kombinere.
DATAMODELLEN ER HJERTET TIL ANALYSELØSNINGEN
Dataene til en analysemodell består strengt tatt av fakta med tilknytning til dimensjoner. Faktaene er målinger, tallverdier som beregnes på under analysen. Dimensjoner gir disse faktaene en kontekst, for å kunne filtreres, grupperes og agrigeres faktaene.
Datamodellen til en analyseløsning kalles gjerne et stjernediagram fordi når faktatabeller inneholder fremmednøkler til dimensjonstabellene som den har tilknytning til så danner diagrammet av databasen stjerne med faktatabellen i midten.
Når vi skal designe en datamodell starter vi alltid med å identifisere faktaverdiene. Tenk da på hvilke verdier som faktisk vises i visualiseringene i dashboard skisse som tidligere ble skissert opp og godkjent av kunden. Hvilke verdier representerer søylene i et søylediagram eller de enkelte kurvene i en graf, eller paistykkene i en pai? Er det temperaturmålinger, salgsverdier, produksjonskostnader, budsjeterte inntekter eller antall ansatte? Det er viktig å skille fakta fra dimensjoner, skille klinten fra hveten så og si. Uten fakta, disse tallverdiene, så har vi ingen analyseløsning. En analyseløsning er kun en matematisk modell bestående av formler som kalkulerer verdier basert på tallverdier, faktaene.Den må ha tallverdier, altså fakta, for å ha noe å regne på.
Når vi har identifisert faktaverdiene våre så grupperer vi dem i faktatabeller. For eksempel dersom vi skal analysere salg så kan vi relaterte faktaverdier være Antall, Stykkpris og Rabatt. Det viktigste å ta stilling til når det gjelder faktatabeller er hvilken detaljgrad faktaene skal ha. Dette vil ha en direkte konsekvens på begrensning i hvor mye man kan dykke ned i dataene under analysen. Hvis vi ser på et salg så kan vi ha en faktatabell for Salgsordre men da må vi beregne en totalpris for ordren. Det vil da ikke være mulig å se hvor mye av hvilke vare som var solgt fordi denne lifomasjonen ligger på de enkelte ordrelinjene. Alternativt kunne vi ha en faktatabell for OrdreLinjer som inneholdt en rad for hver ordrelinje. Folgende datamodell skisse illustrerer de to alternativene.
SKISSE AV "Salgsordre Fakta" og "Salgsordrelinje Fakta" TABELLENE
Det er beste praksis å navngi en faktatabell etter hva en enkelt rad representerer, og inkludere Fakta i tabellnavnet. I dette tilfelle "Salgsordre Fakta" og "Salgsordrelinje Fakta". Grunnen til at vi angir at dette er en faktatabell i navnet er for at det skal være lettere for brukerne av datamodellen å differensiere faktatabeller og dimensjonstabeller siden de har helt ulike funksjoner i analyseløsningen. Det er også en beste praksis å angi måleenheten på kolonnene som representerer selve faktaverdiene slik at det ikke kan missforstås hva tallet representerer. For eksempel "Stykkpris (NOK)" dersom beløpet alltid er i norske kroner eller "Temperatur (C)" for temperaturmålinger i grader celsius. Dette er ikke nødvendig dersom måleenheten er entydig som for eksempel "Antall personer". "Antall timer" er entydig mens "Leveringstid (timer)" bør ha måleenheten angitt. Legg også merke til at skissen ikke inneholder Fakta/Dimensjon fordi dette indikeres med firkant eller ovale figurer, men husk å ta det med når du implementerer datamodellen. Detaljgraden er så viktig at vi noterer denne inne i firkanten for at det ikke skal være noe tvil.
Som hovedregel vil man velge det laveste netaljnivået som kildesysteme lagrer, men i noen tilfeller vil dette ikke være hensiktsmessig. Et eksempel på dette er sensormålinger. Har man for eksempel en sensor som kontinuerlig måler temperatur så vil man måtte bestemme seg for hvor ofte man trenger å ha temperaturmålinger for å gjennomføre analysen. Dersom dette er værdata vil man kanskje trenge målinger hvert minutt være tilstrekkelig. Da vil vi foreta en agregering av temperaturene ved å beregne en snittverdi innenfor dette minuttet, og muligens fjerne odde målinger som feilmålinger.
For hver faktatabell spør vi oss om hvilke dimensjoner som er aktuelle for faktaene. For faktatabellen "Salgsordrelinje Fakta" vil Salgsordren som linjen er den del av være en dimensjonstabell. Andre aktuelle dimensjoner vil være Ordredato, Kunde, Produkt, Valuta. Hvis vi tenker litt nærmere på det så vil ordre datoen og kunde være lik for alle ordrelinjene innen samme ordre. Disse kan dermed flyttes opp til Salgsorder dimensjonen. Vi får da følgende datamodell.
SKISSE AV "Salgsordrelinje Fakta", "Salgsordre Dimensjon", "Dato Dimensjon", "Kunde Dimensjon", "Vare Dimensjon" og "Valuta Dimensjon".
Det viktigste med dimensjonstabeller er å identifisere hierarkier. Disse er viktige i analysen fordi de lar oss agregere faktaene opp på høyere nivå. Du kan visualisere et hierarki i form av en trestruktur. Hierarkier kan være et enkelt tre eller en skog av trær. Men hierarkier kan ikke være en grafstruktur fordi den da ikke entydig vil kunne definere hierarkiet. Det må altså være entydig definert hvilke rader i tabellen som hører innunder i hierarkiet. Med andre ord så må det være en og bare en sti fra noden som raden representerer og helt opp til rotnoden i treet.
LAG SKISSER SOM ILLUSTRERER KONSEPTENE MED TRESTRUKTURER
Et hierarki kan implementeres enten som en mornode kolonne som peker på hvilken rad som den inneværende raden hører direkte under eller som en gruppe med kolonner som representerer nodene i ulike nivåer oppover treet. Den første metoden er både enkel å implementere i databsen og er helt fleksibel i forhold til hvor mange nivåer det er i treet, og er derfor den mest foretrukne i databaser til applikasjoner. Ulempen er at den er mer komplisert når vi skal lage formler i analyseløsninger og det er ikke mulig å implementere ferdige hierarkier på datamodell nivå. Alternativer må vi har en kolonne for hvert nivå i treet. Da vil vi sette begrensninger med hensyn til høyden på trestrukturen. Alternativt kan vi ta med de første nivåene (høys oppe i treet) og de laveste nivåene (lengst nede i treet), men da vil ikke analysen kunne benytte de resterednde nivåene i treet.
Hierarki = Trestruktur
Dersom strukturen ikke er et tre så har vi ikke et hierarki!
Datamodellen til en analyseløsning kalles gjerne et stjernediagram fordi når faktatabeller inneholder fremmednøkler til dimensjonstabellene som den har tilknytning til så danner diagrammet av databasen stjerne med faktatabellen i midten.
Når vi skal designe en datamodell starter vi alltid med å identifisere faktaverdiene. Tenk da på hvilke verdier som faktisk vises i visualiseringene i dashboard skisse som tidligere ble skissert opp og godkjent av kunden. Hvilke verdier representerer søylene i et søylediagram eller de enkelte kurvene i en graf, eller paistykkene i en pai? Er det temperaturmålinger, salgsverdier, produksjonskostnader, budsjeterte inntekter eller antall ansatte? Det er viktig å skille fakta fra dimensjoner, skille klinten fra hveten så og si. Uten fakta, disse tallverdiene, så har vi ingen analyseløsning. En analyseløsning er kun en matematisk modell bestående av formler som kalkulerer verdier basert på tallverdier, faktaene.Den må ha tallverdier, altså fakta, for å ha noe å regne på.
Når vi har identifisert faktaverdiene våre så grupperer vi dem i faktatabeller. For eksempel dersom vi skal analysere salg så kan vi relaterte faktaverdier være Antall, Stykkpris og Rabatt. Det viktigste å ta stilling til når det gjelder faktatabeller er hvilken detaljgrad faktaene skal ha. Dette vil ha en direkte konsekvens på begrensning i hvor mye man kan dykke ned i dataene under analysen. Hvis vi ser på et salg så kan vi ha en faktatabell for Salgsordre men da må vi beregne en totalpris for ordren. Det vil da ikke være mulig å se hvor mye av hvilke vare som var solgt fordi denne lifomasjonen ligger på de enkelte ordrelinjene. Alternativt kunne vi ha en faktatabell for OrdreLinjer som inneholdt en rad for hver ordrelinje. Folgende datamodell skisse illustrerer de to alternativene.
SKISSE AV "Salgsordre Fakta" og "Salgsordrelinje Fakta" TABELLENE
Det er beste praksis å navngi en faktatabell etter hva en enkelt rad representerer, og inkludere Fakta i tabellnavnet. I dette tilfelle "Salgsordre Fakta" og "Salgsordrelinje Fakta". Grunnen til at vi angir at dette er en faktatabell i navnet er for at det skal være lettere for brukerne av datamodellen å differensiere faktatabeller og dimensjonstabeller siden de har helt ulike funksjoner i analyseløsningen. Det er også en beste praksis å angi måleenheten på kolonnene som representerer selve faktaverdiene slik at det ikke kan missforstås hva tallet representerer. For eksempel "Stykkpris (NOK)" dersom beløpet alltid er i norske kroner eller "Temperatur (C)" for temperaturmålinger i grader celsius. Dette er ikke nødvendig dersom måleenheten er entydig som for eksempel "Antall personer". "Antall timer" er entydig mens "Leveringstid (timer)" bør ha måleenheten angitt. Legg også merke til at skissen ikke inneholder Fakta/Dimensjon fordi dette indikeres med firkant eller ovale figurer, men husk å ta det med når du implementerer datamodellen. Detaljgraden er så viktig at vi noterer denne inne i firkanten for at det ikke skal være noe tvil.
Som hovedregel vil man velge det laveste netaljnivået som kildesysteme lagrer, men i noen tilfeller vil dette ikke være hensiktsmessig. Et eksempel på dette er sensormålinger. Har man for eksempel en sensor som kontinuerlig måler temperatur så vil man måtte bestemme seg for hvor ofte man trenger å ha temperaturmålinger for å gjennomføre analysen. Dersom dette er værdata vil man kanskje trenge målinger hvert minutt være tilstrekkelig. Da vil vi foreta en agregering av temperaturene ved å beregne en snittverdi innenfor dette minuttet, og muligens fjerne odde målinger som feilmålinger.
For hver faktatabell spør vi oss om hvilke dimensjoner som er aktuelle for faktaene. For faktatabellen "Salgsordrelinje Fakta" vil Salgsordren som linjen er den del av være en dimensjonstabell. Andre aktuelle dimensjoner vil være Ordredato, Kunde, Produkt, Valuta. Hvis vi tenker litt nærmere på det så vil ordre datoen og kunde være lik for alle ordrelinjene innen samme ordre. Disse kan dermed flyttes opp til Salgsorder dimensjonen. Vi får da følgende datamodell.
SKISSE AV "Salgsordrelinje Fakta", "Salgsordre Dimensjon", "Dato Dimensjon", "Kunde Dimensjon", "Vare Dimensjon" og "Valuta Dimensjon".
Det viktigste med dimensjonstabeller er å identifisere hierarkier. Disse er viktige i analysen fordi de lar oss agregere faktaene opp på høyere nivå. Du kan visualisere et hierarki i form av en trestruktur. Hierarkier kan være et enkelt tre eller en skog av trær. Men hierarkier kan ikke være en grafstruktur fordi den da ikke entydig vil kunne definere hierarkiet. Det må altså være entydig definert hvilke rader i tabellen som hører innunder i hierarkiet. Med andre ord så må det være en og bare en sti fra noden som raden representerer og helt opp til rotnoden i treet.
LAG SKISSER SOM ILLUSTRERER KONSEPTENE MED TRESTRUKTURER
Et hierarki kan implementeres enten som en mornode kolonne som peker på hvilken rad som den inneværende raden hører direkte under eller som en gruppe med kolonner som representerer nodene i ulike nivåer oppover treet. Den første metoden er både enkel å implementere i databsen og er helt fleksibel i forhold til hvor mange nivåer det er i treet, og er derfor den mest foretrukne i databaser til applikasjoner. Ulempen er at den er mer komplisert når vi skal lage formler i analyseløsninger og det er ikke mulig å implementere ferdige hierarkier på datamodell nivå. Alternativer må vi har en kolonne for hvert nivå i treet. Da vil vi sette begrensninger med hensyn til høyden på trestrukturen. Alternativt kan vi ta med de første nivåene (høys oppe i treet) og de laveste nivåene (lengst nede i treet), men da vil ikke analysen kunne benytte de resterednde nivåene i treet.
Hierarki = Trestruktur
Dersom strukturen ikke er et tre så har vi ikke et hierarki!