Redigerer Dimensjon (datavarehus)

[[Fil:Dimension_estrella.png|miniatyr|En dimensjonstabell i en [[OLAP-kube]] med [[stjernemodell]]]]
En '''dimensjon''' er en struktur som kategoriserer [[Datavarehus|fakta]] og [[Måling (datavarehus)|målinger]] slik at brukere kan få svar på forretningsmessige spørsmål. Eksempler på ofte brukte dimensjoner kan være personer, produkter, sted og tid,<ref>"[http://docs.oracle.com/cd/B10501_01/server.920/a96520/dimensio.htm#11840 Oracle Data Warehousing Guide]", Oracle Corporation, retrieved 9 June 2014</ref><ref>[http://searchdatamanagement.techtarget.com/definition/dimension Definition: Dimension]" Search Data Management, TechTarget, retrieved 9 June 2014</ref> men personer og tid er ikke nødvendigvis alltid modellert som dimensjoner.

I et [[datavarehus]] gjør dimensjoner at man kan få en strukturert merking av ellers uordnede numeriske målinger. Dimensjonen er en [[datamengde]] som består av individuelle, ikke-overlappende [[Dataelement|dataelementer]]. Hovedfunksjonen til dimensjoner består av 3 deler: Muliggjøre filtrering, gruppering og merking. 

De tre hovedfunksjonene til en dimensjon er å muliggjøre filtrering, gruppering og merking. Disse funksjonene er ofte beskrevet som [[wiktionary:slice and dice|''slicing and dicing'']] (oppdeling i mindre skiver eller ved å se på dataene som terninger{{Klargjør}}). Et vanlig eksempel fra datavarehus innebærer et salg som en måling, med kunden og produktet som tilhørende dimensjoner. Ved hvert salg kjøper en kunde et produkt. Dataene kan deles opp i skiver ved å fjerne alle kunder unntatt den gruppen man ønsker å studere nærmere, og deretter formes om til en terning ved å gruppere etter produktene.

Et [[dataelement]] i en dimensjonstabell ligner på en [[kategorisk variabel]] i [[statistikk]].

Dimensjoner i et datavarehus er vanligvis organiserte internt i et eller flere hierarkier. Dato er en vanlig dimensjon, og kan ha flere mulige hierarkier:

* Dager (gruppert i) måneder (som er gruppert i) år, 
* Dager (gruppert i) uker (som er gruppert i) år, 
* Dager (gruppert i) måneder (som er gruppert i) kvartal (som er gruppert i) år, 
* og så videre.

Faktatabeller er ofte [[Smal tabell|smale tabeller]] (få kolonner), mens dimensjonstabeller ofte er [[Bred tabell|brede tabeller]].<ref>{{Kilde www|url=http://www.bedreinnsikt.no/konvertering-av-datatyper.html|tittel=Konvertering av datatyper - BEDREINNSIKT}}</ref>

== Typer ==

=== Endringstrege dimensjoner ===
En [[endringstreg dimensjon]] er en mengde med dataattributter som endres sakte over tid i stedet for å endres regelmessig. Vanlige eksempler på dette kan være adresse eller navn. Det finnes flere tilnærminger for hvordan man skal håndtere endringstrege dimensjoner:<ref>{{Kilde www|url=https://www.edureka.co/blog/types-of-dimension-table/|tittel=Types Of Dimension Table {{!}} Data Warehousing Training|besøksdato=2022-01-12|fornavn=Kalyn|etternavn=Says}}</ref>

* '''Type 0 (Behold originalen)''': Attributter endres aldri. Ingen historikk.
* '''Type 1 (Overskriv)''': Gamle verdier overskrives av nye verdier for attributten. Ingen historikk.
* '''Type 2 (Legg til ny rad)''': For en nye verdi opprettes det en ny rad med enten start- og sluttdato eller versjonsnummer. Dermed tar man vare på historikk.
* '''Type 3 (Legg til ny attributt)''': For en ny verdi opprettes det en ny kolonne. Historikken er begrenset av det antallet kolonner som er tiltenkt lagring av historiske data.
* '''Type 4 (Legg til historikktabell)''': En tabell holder på gjeldende verdi, mens historikken lagres i en annen tabell. Dette gir også historikk.
* '''Type 5 (Kombinert tilnærming 1 + 4)''': Kombinasjon av type 1 og 4. Historikken skapes via en annen historikktabell.
* '''Type 6 (Kombinert tilnærming 1 + 2 + 3)''': Kombinasjon av type 1, 2 og 3. Historikken skapes gjennom separate rader og attributter.
* '''Type 7 (Hybrid tilnærming)''': Både naturlig og surrogatnøkkel brukes.<ref>{{Kilde www|url=https://www.kimballgroup.com/2013/02/design-tip-152-slowly-changing-dimension-types-0-4-5-6-7/|tittel=Design Tip #152 Slowly Changing Dimension Types 0, 4, 5, 6 and 7|besøksdato=2022-01-12|fornavn=Margy|etternavn=Ross}}</ref>

=== Konform dimensjon ===
En konform dimensjon er et mengde av dataattributter som har blitt fysisk referert til i flere databasetabeller med samme nøkkelverdi for å referere til samme struktur, attributter, domeneverdier, definisjoner og begreper. En konform dimensjon spenner over mange fakta.

Dimensjoner er konforme når de enten er nøyaktig like (inkludert nøkler) eller når den ene er en ekte [[delmengde]] av den andre. Det viktigste er at rad-overskrifter fremstilt i to ulike svarmengder fra samme konforme dimensjon(er) skal kunne matche perfekt.

Konforme dimensjoner er enten identiske eller strengt matematiske delmengder av den mest finkornede, detaljerte dimensjonen. Dimensjonstabeller er ikke-konforme dersom attributtene er merket ulikt eller inneholder ulike verdier. Det finnes flere varianter av konforme dimensjoner, men i sin mest grunnleggende betydning innebærer det at de konforme dimensjonene har eksakt samme betydning uansett hvilken faktatabell de skjøtes mes. Dato-dimensjonstabellen koblet med salgsfaktaene er identisk med dato-dimensjonstabellen koblet med lagerfaktaene.<ref>Ralph Kimball, Margy Ross, The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling, Second Edition, Wiley Computer Publishing, 2002. {{ISBN|0471-20024-7}}, Pages 82-87, 394</ref> 

=== Søppeldimensjon ===
En søppeldimensjon er en praktisk gruppering av typiske lav-[[Kardinalitet (datamodellering)|kardinalitets]] flagg og -indikatorer. Ved å opprette en abstrakt dimensjon fjernes disse flaggene og indikatorene fra faktatabellen, mens de plasseres i et nyttig dimensjons-rammeverk.<ref>Ralph Kimball, Margy Ross, The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling, Second Edition, Wiley Computer Publishing, 2002. {{ISBN|0471-20024-7}}, Pages 202, 405</ref> En søppeldimensjon er en dimensjonstabell av attributter som ikke hører hjemme i det faktatabellen eller i noen av de eksisterende dimensjonstabellene. Disse attributtene er vanligvis tekst eller ulike flagg som for eksempel ikke-generiske kommentarer eller bare enkle ja/nei- eller sann/usann-indikatorer. Disse typene attributter er vanligvis gjenværende når alle de åpenbare dimensjonene i forretningsprosessen har blitt identifisert, hvorpå designeren får utfordringne med å finne ut hvor disse attributtene som ikke hører hjemme i andre dimensjoner skal gjøres av.

En løsning kan være å opprette en ny dimensjon for hvert av de gjenværende attributtene, men på grunn av deres karakter kan det være nødvendig å lage et stort antall nye dimensjoner hvilket gir en faktatabell med et meget stort antall fremmednøkler. Et annet alternativ designeren kan vurdere er å legge de gjenværende attributtene i faktatabellen, men dette kan gjøre radlengden til tabellen unødvendig stor hvis for eksempel attributten er en lang tekststreng.

Løsningen på denne utfordringen er å identifisere alle attributter og deretter sette dem inn i en eller flere søppeldimensjoner. En søppeldimensjon kan ha flere sann/usann eller ja/nei indikatorer som har ingen sammenheng med hverandre, og for å beholde informasjon kan det være praktisk å konvertere indikatorene til mer beskrivende attributter. Et eksempel kan være en indikator på om en pakke har kommet: I stedet for å angi denne som "ja" eller "nei" kan indikatoren i søppeldimensjon konverteres til "ankommet" eller "undervegs". Designeren kan velge å bygge dimensjontabellen slik at den ender opp med å holde alle indikatorene slik at alle kombinasjoner er dekket. Dette gir en fast størrelse for selve tabellen som ville bli 2<sup>''x''</sup> rader, hvor ''x'' er antallet indikatorer. Denne løsningen er hensiktsmessig i situasjoner der designeren forventer å kunne støte på en rekke ulike kombinasjoner, og der mulige kombinasjoner er begrenset til et akseptabelt nivå. I en situasjon der antall indikatorer er stort og dermed skaper en svært stor tabell, eller der designeren bare forventer å møte noen få av de mulige kombinasjonene, ville det være mer hensiktsmessig å bygge hver rad i søppeldimensjonen etterhvert som man kommer over nye kombinasjoner. For å begrense størrelsen på tabellene kan være hensiktsmessig med flere søppeldimensjoner i andre situasjoner, avhengig av korrelasjonen mellom ulike indikatorer.

Søppeldimensjoner er også passende for å plassere attributter som ikke-generiske kommentarer fra faktatabellen. Slike attributter kan bestå av data fra et valgfritt kommentarfelt når en kunde bestiller et produkt, og vil som et resultat trolig være tom i mange tilfeller. Derfor bør søppeldimensjoner inneholde en enkelt rad som representerer slike tomme felter med en surrogatnøkkel som skal brukes i faktatabellen for hver rad som returneres med et tomt kommentarfelt.<ref>Kimball, Ralph, ''et al.'' (2008): The Data Warehouse Lifecycle Toolkit, Second Edition, Wiley Publishing Inc., Indianapolis, IN. Pages 263-265</ref>

=== Degenerert dimensjon ===
En [[degenerert dimensjon]] er en nøkkel, som for eksempel kan være et transaksjonsnummer, fakturanummer, saksnummer, eller fraktbrev som ikke har noen attributter og derfor ikke kan skjøtes til en faktisk dimensjonstabell. Degenererte dimensjoner er svært vanlige når finheten av faktatabellen representerer et enkelt transaksjonselement eller en varelinje fordi den degenererte dimensjonen representerer en unik identifikator av forelderen. Degenererte dimensjoner spiller ofte en viktig rolle i faktatabellen sin primærnøkkel.<ref>Ralph Kimball, Margy Ross, The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling, Second Edition, Wiley Computer Publishing, 2002. {{ISBN|0471-20024-7}}, Pages 50, 398</ref>

=== Rollespillende dimensjon ===
En rollespillende dimensjon er en dimensjon som kan bli resirkulert for flere bruksområder innenfor samme database. For eksempel kan en datodimensjon brukes både til "dato for salg", "leveringsdato" og "dato for ansettelse". Dette kan gjennomføres ved hjelp av en visning av den samme dimensjonstabellen.

=== Utriggerdimensjon ===
Vanligvis refererer ikke dimensjonstabeller til andre dimensjoner via fremmenøkler. Når dette skjer kalles de refererte dimensjonene en utriggerdimensjon. Utriggeredimensjoner bør anses som et [[antimønster]] i datavarehus, i stedet er det ansett som bedre praksis å bruke noen faktatabeller som relaterer de to dimensjonene.<ref>
{{Kilde bok|tittel=The Data Wharehouse Toolkit 3rd edition|etternavn=Ralph Kimball|etternavn2=Margy Ross|utgiver=Wiley|isbn=978-1-118-53080-1|side=50}}</ref>

=== Krympet dimensjon ===
En konform dimensjon sies å være en krympet dimensjon når det inneholder en [[delmengde]] av rader og/eller kolonner av den opprinnelige dimensjonen.<ref>
{{Kilde bok|tittel=The Data Wharehouse Toolkit 3rd edition|etternavn=Ralph Kimball|etternavn2=Margy Ross|utgiver=Wiley|isbn=978-1-118-53080-1|side=51}}</ref>

=== Datodimensjon ===
{{se også|ISO 8601}}En spesiell type dimensjon kan brukes til å representere datoer med en finheten til en dag. Datoer vil bli referert i en [[faktatabell]] som fremmednøkler til en datodimensjon. Datodimensjonen sin primærnøkkel kan være en surrogatnøkkel eller et nummer ved hjelp av formatet YYYYMMDD.

Datodimensjonen kan inkludere andre attributter som [[ISO-uke|ISO-uke i året]], eller flagg som representerer [[Virkedag|virkedager]], [[Ferie|feriedager]], og så videre. Det kan også være spesielle rader som representerer: ikke-kjente datoer eller datoer som ikke er definerte ennå. Datodimensjonen bør initialiseres med alle nødvendige datoer som trengs for eksempel de neste 10 årene, eller mer hvis det er nødvendig, samt eventuelt tidligere datoer dersom hendelser i fortiden håndteres.

Tid egner seg derimot vanligvis best til å representeres som et [[tidsstempel]] i en faktatabell.<ref>
{{Kilde bok|tittel=The Data Wharehouse Toolkit 3rd edition|etternavn=Ralph Kimball|etternavn2=Margy Ross|utgiver=Wiley|isbn=978-1-118-53080-1|side=48}}</ref>

== Bruk av ISO-representasjonsbegreper ==
Når man refererer til data fra et [[Metadata|metadata-register]] som for eksempel ISO/IEC 11179 inkluderer [[representationsbegrep|representasjonsbegrep]] vanligvis brukt dimensjoner for eksempel "''Indicator''" (en boolsk sann/usann-verdi) eller "''Code''" (en mengde ikke-overlappende [[Oppregningstype|oppregnede typer]]). For eksempel vil navnet på dataelementet ved hjelp av National Information Exchange-Modell (NIEM) være "PersonGenderCode" og de oppregnede verdiene kan være "mann", "kvinne" eller "ukjent".

== Dimensjonstabell ==
I [[datavarehus]] er en dimensjonstabell en av flere tabeller koblet til en [[faktatabell]].

Faktatabellen inneholder [[Business faktum|forretningsfakta]] (eller målinger) og [[Nøkkel (database)#Fremmednøkkel|fremmednøkler]] som refererer til [[Nøkkel (database)#Kandidatnøkkel|kandidatnøkler]] (vanligvis [[Nøkkel (database)#Primærnøkkel|primærnøkler]]) i dimensjonstabellene.

I motsetning til faktatabeller inneholder dimensjonstabellene typisk beskrivende attributter (eller felter) som er typisk tekstfelter (eller diskrete tall som oppfører seg som tekst). Disse attributtene er utformet for å tjene 2 kritiske hensikter: Avgrense spørringer og/eller filtrere, og merking av [[resultatmengde]]n.

Dimensjonsattributter skal være:

* Ordrike (merket med etiketter som består av hele ord)
* Beskrivende
* Komplette (har ingen manglende verdier)
* Være diskrete verdier (har bare én verdi per dimensjontabell-rad)
* Kvalitetssikret (har ingen feilstavinger eller umulig verdier)

Dimensjonstabell-rader skal være unikt identifiserbare av et enkelt nøkkelfelt. Det anbefales at nøkkelfeltet er et enkelt heltall fordi en nøkkelverdi er ikke trenger å ha noen mening utover å brukes som felt for kobling mellom faktatabellen og dimensjonstabellene. Dimensjontabeller bruker ofte primærnøkler som også er surrogatnøkler. Surrogatnøkler er ofte autogenererte (for eksempel lager Sybase og SQL Server en kolonne kalt "identity column", PostgreSQL og Informix "serial", Oracle "SEQUENCE", og MySQL en kolonne med "AUTO_INCREMENT").

Bruk av surrogat-dimensjonsnøkler gir flere fordeler, inkludert:

* Ytelse: Bli med behandlingen er gjort mye mer effektiv ved hjelp av et enkelt felt (den surrogat-tasten)
* Bufring etter praksis fra operasjonell nøkkelhåndtering: Dette hindrer situasjoner hvor fjernede datarader kan dukke opp igjen når deres naturlige nøkler blir gjenbrukt eller omplasserte etter en lang periode uten bruk
* Avbildninger for å integrere ulike kilder
* Håndtering av ukjente eller ikke-gjeldende koblinger
* Sporing av endringer i dimensjonsattributt-verdier

Selv om surrogatnøkler legger en byrde på [[Uttrekk, transformasjon og lasting|ETL-systemet]] kan det bedre prosesseringen i kommandokøer, og ETL-verktøy har innebygd forbedret surrogatnøkkel-prosessering.

Målet til en dimensjonstabell er å lage standardiserte og konforme dimensjoner som kan deles på tvers av virksomhetens [[datavarehus]]-miljø, og muliggjør skjøting av flere faktatabeller som representerer ulike forretningsprosesser.

Konforme dimensjoner er viktige for virksomheters systemer for datavarehus og virksomhetsetterretning ettersom de fremmer:

* Konsistens: Hver faktatabell filtreres konsekvent slik at svarene på spørringene merkes konsekvent.
* Integrering: Spørringer kan [[Databoring|bores]] separat inn i faktatabeller til ulike prosesser, og deretter skjøtes i resultatene ved hjelp av felles dimensjonsattributter.
* Tiden fra utvikling til marked reduseres: De vanligste dimensjonene er tilgjengelige uten å gjenskape dem.

Over tid vil attributtene for en gitt rad i en dimensjonstabell endres. For eksempel, den leveringsadressen til et selskap endres. [[Ralph Kimball|Kimball]] refererer til dette fenomenet som [[endringstreg dimensjon]]. Strategier for å håndtere denne type endringer deles inn i 3 kategorier:

* Type 1: Overskriv gamle verdier.
* Type 2: Legg til en ny rad som inneholder de nye verdiene, og skill mellom radene med [[Tuppel-versjonskontroll|tuppel-versjonering]] (en mekanisme i noen relasjonsdatabaser for å lagre tidligere tilstander i en relasjon)
* Type 3: Legg til en ny attributt til den eksisterende raden.

== Vanlige mønstre ==

=== Dato og tid<ref>Ralph Kimball, The Data Warehouse Toolkit, Second Edition, Wiley Publishing, Inc., 2008. {{ISBN|978-0-470-14977-5}}, Pages 253-256</ref> ===
Siden mange faktatabeller i et datavarehus er [[Tidsserie|tidsserier]] med observasjoner trengs det ofte en eller flere datodimensjoner. En av grunnene til å ha datodimensjoner er å plassere kalenderkunnskap i datavarehuset i stedet for hardkoding i et program. Et enkelt SQL-[[dato-tidsstempel]] er nyttig for å gi nøyaktig informasjon om hvilket tidspunktet et fakta ble registrert. Det skal imidlertid ikke gi informasjon om feriedager, høytider, og så videre. Et SQL-dato-tidsstempel kan likevel være nyttig å lagre i faktatabellen ettersom det gjør det mulig med nøyaktige beregninger.

Å ha både dato og tid på døgnet i samme dimensjon kan raskt resultere i en stor dimensjon med millioner av rader. Dersom det trengs en høy grad av detaljer er det vanligvis en god idé å dele dato og tid inn i to eller flere separate dimensjoner. En tidsdimensjon med en finhet på sekundnivå for en dag vil ha 86400 rader, ettersom det er 86400 sekunder i et døgn. En mer eller mindre finhet for dato- og klokkeslett-dimensjoner kan velges avhengig av behov. For eksempel kan dato-dimensjoner ha finhet på år, [[Kvartal (tid)|kvartal]], måned og dag, mens tidsdimensjoner ha finhet på timer, minutter eller sekunder.

Som en tommelfingerregel bør klokkeslett-dimensjonen bare opprettes hvis hierarkiske grupperinger trengs, eller dersom det er meningsfulle tekstbeskrivelser for tidsperioder innenfor dagen (for eksempel "kveldsrush" eller "første skift").

Hvis rader i en faktatabell kommer fra flere tidssoner, kan det være nyttig å lagre dato og klokkeslett i både lokal tid ([[Sentraleuropeisk tid|CET]]) og universiell standardtid ([[Koordinert universaltid|UTC]]). Dette kan gjøres ved å ha 2 dimensjoner for dato, og 2 dimensjoner for tid. Dermed kan man analysere enten etter når fakta ble opprettet i loaltid eller global tid.

== Se også ==
* [[Datavarehus]]
* [[Degenerert dimensjon]]
* [[Endringstreg dimensjon]]
* [[Faktatabell]]
* [[ISO/IEC 11179]]
* [[Kategorisk variabel]]
* [[Metadata]]
* [[Måling (datavarehus)]]

== Referanser ==
<references />

{{Datavarehus}}

[[Kategori:Metadata]]
[[Kategori:Datavarehusmetodikk]]