PROFILBARU.COM

En dimensjonstabell i en OLAP-kube med stjernemodell

En dimensjon er en struktur som kategoriserer fakta og 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,^[1]^[2] 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 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 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 smale tabeller (få kolonner), mens dimensjonstabeller ofte er brede tabeller.^[3]

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:^[4]

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.^[5]

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.^[6]

Søppeldimensjon

En søppeldimensjon er en praktisk gruppering av typiske lav-kardinalitets flagg og -indikatorer. Ved å opprette en abstrakt dimensjon fjernes disse flaggene og indikatorene fra faktatabellen, mens de plasseres i et nyttig dimensjons-rammeverk.^[7] 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^x 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.^[8]

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.^[9]

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.^[10]

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.^[11]

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 i året, eller flagg som representerer virkedager, 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.^[12]

Bruk av ISO-representasjonsbegreper

Når man refererer til data fra et metadata-register som for eksempel ISO/IEC 11179 inkluderer representasjonsbegrep vanligvis brukt dimensjoner for eksempel "Indicator" (en boolsk sann/usann-verdi) eller "Code" (en mengde ikke-overlappende 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 forretningsfakta (eller målinger) og fremmednøkler som refererer til kandidatnøkler (vanligvis 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 resultatmengden.

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å 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 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. 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-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^[13]

Siden mange faktatabeller i et datavarehus er 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, 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 (CET) og universiell standardtid (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å

Referanser

^ "Oracle Data Warehousing Guide", Oracle Corporation, retrieved 9 June 2014
^ Definition: Dimension" Search Data Management, TechTarget, retrieved 9 June 2014
^ «Konvertering av datatyper - BEDREINNSIKT».
^ Says, Kalyn. «Types Of Dimension Table | Data Warehousing Training». Besøkt 12. januar 2022.
^ Ross, Margy. «Design Tip #152 Slowly Changing Dimension Types 0, 4, 5, 6 and 7». Besøkt 12. januar 2022.
^ 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
^ 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
^ Kimball, Ralph, et al. (2008): The Data Warehouse Lifecycle Toolkit, Second Edition, Wiley Publishing Inc., Indianapolis, IN. Pages 263-265
^ 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
^ Ralph Kimball; Margy Ross. The Data Wharehouse Toolkit 3rd edition. Wiley. s. 50. ISBN 978-1-118-53080-1.
^ Ralph Kimball; Margy Ross. The Data Wharehouse Toolkit 3rd edition. Wiley. s. 51. ISBN 978-1-118-53080-1.
^ Ralph Kimball; Margy Ross. The Data Wharehouse Toolkit 3rd edition. Wiley. s. 48. ISBN 978-1-118-53080-1.
^ Ralph Kimball, The Data Warehouse Toolkit, Second Edition, Wiley Publishing, Inc., 2008. ISBN 978-0-470-14977-5, Pages 253-256