Dimensjonsmodellering i Microsoft Fabric Warehouse: Dimensjonstabeller

Gjelder for:✅ SQL Analytics-endepunkt og Warehouse i Microsoft Fabric

Merk

Denne artikkelen er en del av dimensjonalmodelleringsserien med artikler. Denne serien fokuserer på anbefalte fremgangsmåter for veiledning og utforming knyttet til dimensjonal modellering i Microsoft Fabric Warehouse.

Denne artikkelen gir deg veiledning og anbefalte fremgangsmåter for utforming av dimensjonstabeller i en dimensjonsmodell. Det gir praktisk veiledning for Warehouse i Microsoft Fabric, som er en opplevelse som støtter mange T-SQL-funksjoner, som å opprette tabeller og administrere data i tabeller. Så du har full kontroll over å opprette dimensjonale modelltabeller og laste dem inn med data.

Merk

I denne artikkelen refererer termdatalageret til et virksomhetsdatalager, som leverer omfattende integrering av kritiske data på tvers av organisasjonen. Derimot refererer det frittstående termlageret til et Fabric Warehouse, som er en programvare som en tjeneste (SaaS) relasjonsdatabase som du kan bruke til å implementere et datalager. For klarhet, i denne artikkelen sistnevnte er nevnt som Fabric Warehouse.

Tips

Hvis du er uerfaren med dimensjonal modellering, bør du vurdere denne serien med artikler ditt første trinn. Det er ikke ment å gi en fullstendig diskusjon om dimensjonal modelleringsutforming. Hvis du vil ha mer informasjon, kan du se allment publisert innhold, for eksempel Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3. utgave, 2013) av Ralph Kimball og andre.

I en dimensjonsmodell beskriver en dimensjonstabell en enhet som er relevant for forretnings- og analysekravene dine. Dimensjonstabeller representerer generelt de tingene du modellerer. Ting kan være produkter, personer, steder eller andre konsepter, inkludert dato og klokkeslett. Du kan enkelt identifisere dimensjonstabeller ved å prefikse navnene med d_ eller Dim_.

Dimensjonstabellstruktur

Hvis du vil beskrive strukturen i en dimensjonstabell, kan du vurdere følgende eksempel på en selgerdimensjonstabell med navnet d_Salesperson. Dette eksemplet bruker gode utformingspraksiser. Hver av gruppene med kolonner er beskrevet i avsnittene nedenfor.

CREATE TABLE d_Salesperson
(
    --Surrogate key
    Salesperson_SK INT NOT NULL,
    
    --Natural key(s)
    EmployeeID VARCHAR(20) NOT NULL,
    
    --Dimension attributes
    FirstName VARCHAR(20) NOT NULL,
    <…>
    
    --Foreign key(s) to other dimensions
    SalesRegion_FK INT NOT NULL,
    <…>
    
    --Historical tracking attributes (SCD type 2)
    RecChangeDate_FK INT NOT NULL,
    RecValidFromKey INT NOT NULL,
    RecValidToKey INT NOT NULL,
    RecReason VARCHAR(15) NOT NULL,
    RecIsCurrent BIT NOT NULL,
    
    --Audit attributes
    AuditMissing BIT NOT NULL,
    AuditIsInferred BIT NOT NULL,
    AuditCreatedDate DATE NOT NULL,
    AuditCreatedBy VARCHAR(15) NOT NULL,
    AuditLastModifiedDate DATE NOT NULL,
    AuditLastModifiedBy VARCHAR(15) NOT NULL
);

Surrogatnøkkel

Eksempeldimensjonstabellen har en surrogatnøkkel som heter Salesperson_SK. En surrogatnøkkel er en unik identifikator med én kolonne som er generert og lagret i dimensjonstabellen. Det er en primærnøkkelkolonne som brukes til å relatere seg til andre tabeller i den dimensjonale modellen.

Surrogatnøkler forsøker å isolere datalageret fra endringer i kildedata. De leverer også mange andre fordeler, slik at du kan:

• Konsolidere flere datakilder (unngå sammenstøt mellom dupliserte identifikatorer).
• Konsolidere naturlige nøkler med flere kolonner til en mer effektiv enkeltkolonnenøkkel.
• Spor dimensjonslogg med en scd-type (slowly changing dimension) 2.
• Begrens faktatabellbredden for lagringsoptimalisering (ved å velge den minste mulige heltallsdatatypen).

En surrogatnøkkelkolonne er en anbefalt praksis, selv når en naturlig nøkkel (beskrevet neste) virker som en akseptabel kandidat. Du bør også unngå å gi mening til nøkkelverdiene (bortsett fra dato- og klokkeslettdimensjonsnøkler, som beskrevet senere).

Naturlige nøkler

Eksempeldimensjonstabellen har også en naturlig nøkkel, som heter EmployeeID. En naturlig nøkkel er nøkkelen som er lagret i kildesystemet. Det gjør det mulig å relatere dimensjonsdataene til kildesystemet, som vanligvis gjøres av en uttrekkings-, belastnings- og transformeringsprosess (ETL) for å laste inn dimensjonstabellen. Noen ganger kalles en naturlig nøkkel en forretningsnøkkel, og verdiene kan være meningsfulle for forretningsbrukere.

Noen ganger har ikke dimensjoner en naturlig nøkkel. Dette kan være tilfellet for datodimensjonen eller oppslagsdimensjonene, eller når du genererer dimensjonsdata ved å normalisere en flat fil.

Dimensjonsattributter

En eksempeldimensjonstabell har også dimensjonsattributter, for eksempel FirstName kolonnen. Dimensjonsattributter gir kontekst til de numeriske dataene som er lagret i relaterte faktatabeller. De er vanligvis tekstkolonner som brukes i analytiske spørringer for å filtrere og gruppere (slice og terninger), men ikke for å aggregeres selv. Noen dimensjonstabeller inneholder få attributter, mens andre inneholder mange attributter (så mange som det tar for å støtte spørringskravene til den dimensjonale modellen).

Tips

En god måte å finne ut hvilke dimensjoner og attributter du trenger på, er å finne de riktige personene og stille de riktige spørsmålene. Vær spesielt oppmerksom på omtalen av ordet. Når noen for eksempel sier at de må analysere salg etter selger, etter måned og etter produktkategori, forteller de deg at de trenger dimensjoner som har disse attributtene.

Hvis du planlegger å opprette en semantisk direct lake-modell, bør du inkludere alle mulige kolonner som kreves for filtrering og gruppering som dimensjonsattributter. Det er fordi semantiske modeller i Direct Lake ikke støtter beregnede kolonner.

Sekundærnøkler

Eksempeldimensjonstabellen har også en sekundærnøkkel som heter SalesRegion_FK. Andre dimensjonstabeller kan referere til en sekundærnøkkel, og deres tilstedeværelse i en dimensjonstabell er et spesielt tilfelle. Den angir at tabellen er relatert til en annen dimensjonstabell, noe som betyr at den kan være en del av en snøfnuggdimensjon , eller den er relatert til en utriggerdimensjon.

Fabric Warehouse støtter sekundærnøkkelbegrensninger , men de kan ikke håndheves. Derfor er det viktig at ETL-prosessen tester for integritet mellom relaterte tabeller når data lastes inn.

Det er fortsatt lurt å opprette sekundærnøkler. En god grunn til å opprette uhåndhevede sekundærnøkler er å la modelleringsverktøy, for eksempel Power BI Desktop, automatisk oppdage og opprette relasjoner mellom tabeller i den semantiske modellen.

Historiske sporingsattributter

Eksempeldimensjonstabellen har også ulike historiske sporingsattributter. Historiske sporingsattributter er valgfrie basert på behovet for å spore bestemte endringer etter hvert som de forekommer i kildesystemet. De tillater lagring av verdier for å støtte den primære rollen til et datalager, som er å beskrive fortiden nøyaktig. Disse attributtene lagrer spesielt historisk kontekst når ETL-prosessen laster inn nye eller endrede data i dimensjonen.

Hvis du vil ha mer informasjon, kan du se Behandle historiske endringer senere i denne artikkelen.

Overvåkingsattributter

Eksempeldimensjonstabellen har også ulike revisjonsattributter. Overvåkingsattributter er valgfrie, men anbefales. De lar deg spore når og hvordan dimensjonsposter ble opprettet eller endret, og de kan inkludere diagnosedata eller feilsøkingsinformasjon som er opphøyd under ETL-prosesser. Du vil for eksempel spore hvem (eller hvilken prosess) som har oppdatert en rad, og når. Overvåkingsattributter kan også bidra til å diagnostisere et utfordrende problem, for eksempel når en ETL-prosess stopper uventet. De kan også flagge dimensjonsmedlemmer som feil eller utsatte medlemmer.

Størrelse på dimensjonstabell

Ofte er de mest nyttige og allsidige dimensjonene i en dimensjonsmodell store, brede dimensjoner. De er store når det gjelder rader (i overkant av millioner) og bredt når det gjelder antall dimensjonsattributter (potensielt hundrevis). Størrelse er ikke så viktig (selv om du bør utforme og optimalisere for den minste mulige størrelsen). Det som betyr noe er at dimensjonen støtter nødvendig filtrering, gruppering og nøyaktig historisk analyse av faktadata.

Store dimensjoner kan hentes fra flere kildesystemer. I dette tilfellet må dimensjonsbehandling kombinere, slå sammen, deduplicate og standardisere dataene. og tilordne surrogatnøkler.

Til sammenligning er noen dimensjoner små. De kan representere oppslagstabeller som bare inneholder flere poster og attributter. Ofte lagrer disse små dimensjonene kategoriverdier relatert til transaksjoner i faktatabeller, og de implementeres som dimensjoner med surrogatnøkler for å relatere til faktapostene.

Tips

Når du har mange små dimensjoner, bør du vurdere å konsolidere dem til en søppelpostdimensjon.

Konsepter for dimensjonsutforming

Denne delen beskriver ulike dimensjonsutformingskonsepter.

Denormalisering kontra normalisering

Det er nesten alltid slik at dimensjonstabeller skal denormaliseres. Selv om normalisering er begrepet som brukes til å beskrive data som er lagret på en måte som reduserer repeterende data, er denormalisering begrepet som brukes til å definere hvor forhåndskomponerte overflødige data finnes. Overflødige data finnes vanligvis på grunn av lagring av hierarkier (diskutert senere), noe som betyr at hierarkier flates ut. En produktdimensjon kan for eksempel lagre underkategori (og tilhørende attributter) og kategori (og tilhørende attributter).

Fordi dimensjonene generelt er små (sammenlignet med faktatabeller), blir kostnadene ved lagring av overflødige data nesten alltid oppveid av forbedret spørringsytelse og brukervennlighet.

Snøfnuggdimensjoner

Et unntak fra denormalisering er å utforme en snøfnuggdimensjon. En snøfnuggdimensjon normaliseres, og den lagrer dimensjonsdataene på tvers av flere relaterte tabeller.

Diagrammet nedenfor viser en snøfnuggdimensjon som består av tre relaterte dimensjonstabeller: Product, Subcategoryog Category.

Vurder å implementere en snøfnuggdimensjon når:

• Dimensjonen er svært stor, og lagringskostnader oppveier behovet for høy spørringsytelse. (Men regelmessig revurdere at dette fortsatt er tilfelle.)
• Du trenger nøkler for å relatere dimensjonen til fakta med høyere korn. Salgsfaktatabellen lagrer for eksempel rader på produktnivå, men faktatabellen for salgsmål lagrer rader på underkategorinivå.
• Du må spore historiske endringer på høyere nivåer av detaljnivå.

Merk

Husk at et hierarki i en semantisk Power BI-modell bare kan baseres på kolonner fra én enkelt semantisk modelltabell. Derfor bør en snøfnuggdimensjon gi et denormalisert resultat ved hjelp av en visning som føyer snøfnuggbordene sammen.

Hierarkier

Vanligvis produserer dimensjonskolonner hierarkier. Hierarkier gjør det mulig å utforske data på distinkte nivåer av oppsummering. Den første visningen av et matrisevisualobjekt kan for eksempel vise årlig salg, og rapportforbrukeren kan velge å drille ned for å vise kvartalsvise og månedlige salg.

Det finnes tre måter å lagre et hierarki på i en dimensjon. Du kan bruke:

• Kolonner fra én enkelt, denormalisert dimensjon.
• En snøfnuggdimensjon, som består av flere relaterte tabeller.
• En overordnet-underordnet (selvrefererende) relasjon i en dimensjon.

Hierarkier kan balanseres eller ubalanserte. Det er også viktig å forstå at noen hierarkier er fillete.

Balanserte hierarkier

Balanserte hierarkier er den vanligste typen hierarki. Et balansert hierarki har samme antall nivåer. Et vanlig eksempel på et balansert hierarki er et kalenderhierarki i en datodimensjon som består av nivåer for år, kvartal, måned og dato.

Diagrammet nedenfor viser et balansert hierarki av salgsområder. Den består av to nivåer, som er salgsområdegruppe og salgsområde.

Nivåene i et balansert hierarki er enten basert på kolonner fra én enkelt, denormalisert dimensjon eller fra tabeller som danner en snøfnuggdimensjon. Når kolonnene som representerer de høyere nivåene, er basert på én enkelt, denormalisert dimensjon, inneholder de overflødige dataene.

For balanserte hierarkier er fakta alltid relatert til ett enkelt nivå i hierarkiet, som vanligvis er det laveste nivået. På den måten kan fakta aggregeres (fremheves) til det høyeste nivået i hierarkiet. Fakta kan relateres til et hvilket som helst nivå, som bestemmes av faktatabellens korn. Salgsfaktatabellen kan for eksempel lagres på datonivå, mens faktatabellen for salgsmål kan lagres på kvartalsnivå.

Ubalanserte hierarkier

Ubalanserte hierarkier er en mindre vanlig type hierarki. Et ubalansert hierarki har nivåer basert på en overordnet-underordnet relasjon. Av denne grunn bestemmes antall nivåer i et ubalansert hierarki av dimensjonsradene, og ikke bestemte dimensjonstabellkolonner.

Et vanlig eksempel på et ubalansert hierarki er et ansatthierarki der hver rad i en ansattdimensjon er knyttet til en rapportlederrad i samme tabell. I dette tilfellet kan alle ansatte være en leder med rapportering av ansatte. Naturligvis vil noen grener av hierarkiet ha flere nivåer enn andre.

Diagrammet nedenfor viser et ubalansert hierarki. Den består av fire nivåer, og hvert medlem i hierarkiet er en selger. Legg merke til at selgere har et annet antall overordnede i hierarkiet i henhold til hvem de rapporterer til.

Andre vanlige eksempler på ubalanserte hierarkier inkluderer stykkliste, firmaeierskapsmodeller og økonomimodul.

Fakta gjelder alltid dimensjonskornet for ubalanserte hierarkier. Salgsfakta er for eksempel relatert til ulike selgere, som har ulike rapporteringsstrukturer. Dimensjonstabellen har en surrogatnøkkel (kalt Salesperson_SK) og en ReportsTo_Salesperson_FK sekundærnøkkelkolonne, som refererer til primærnøkkelkolonnen. Hver selger uten noen å administrere er ikke nødvendigvis på det laveste nivået i noen gren av hierarkiet. Når de ikke er på det laveste nivået, kan en selger selge produkter og ha rapporteringsselgere som også selger produkter. Så, den beregnede faktadata må vurdere den individuelle selgeren og alle deres etterkommere.

Spørring av overordnede underordnede hierarkier kan være komplisert og tregt, spesielt for store dimensjoner. Selv om kildesystemet kan lagre relasjoner som overordnet underordnet, anbefaler vi at du naturaliserer hierarkiet. I dette tilfellet betyr naturalize å transformere og lagre hierarkinivåene i dimensjonen som kolonner.

Tips

Hvis du velger å ikke naturalisere hierarkiet, kan du likevel opprette et hierarki basert på en overordnet-underordnet relasjon i en semantisk Power BI-modell. Denne fremgangsmåten anbefales imidlertid ikke for store dimensjoner. Hvis du vil ha mer informasjon, kan du se Forstå funksjoner for overordnede-underordnede hierarkier i DAX.

Fillete hierarkier

Noen ganger er et hierarki fillete fordi forelderen til et medlem i hierarkiet finnes på et nivå som ikke er rett over det. I disse tilfellene gjentar manglende nivåverdier verdien for den overordnede verdien.

Vurder et eksempel på et balansert geografihierarki. Det finnes et fillete hierarki når et land/område ikke har noen delstater eller provinser. New Zealand har for eksempel verken delstater eller provinser. Så når du setter inn New Zealand-raden, bør du også lagre land-/områdeverdien i StateProvince kolonnen.

Diagrammet nedenfor viser et fillete hierarki av geografiske områder.

Administrer historisk endring

Når det er nødvendig, kan historisk endring administreres ved å implementere en sakte skiftende dimensjon (SCD). En SCD opprettholder historisk kontekst etter hvert som nye, eller endrede data, lastes inn i den.

Her er de vanligste SCD-typene.

• Type 1: Overskriv det eksisterende dimensjonsmedlemmet.
• Type 2: Sett inn et nytt tidsbasert versjonsdimensjonsmedlem .
• Type 3: Spor begrenset logg med attributter.

Det er mulig at en dimensjon kan støtte både SCD type 1 og SCD type 2 endringer.

SCD type 3 brukes vanligvis ikke, delvis på grunn av at det er vanskelig å bruke i en semantisk modell. Vurder nøye om en SCD type 2 tilnærming ville være en bedre passform.

Tips

Hvis du forventer en dimensjon i rask endring, som er en dimensjon som har et attributt som endres ofte, bør du vurdere å legge til attributtet i faktatabellen i stedet. Hvis attributtet er numerisk, for eksempel produktprisen, kan du legge det til som et mål i faktatabellen. Hvis attributtet er en tekstverdi, kan du opprette en dimensjon basert på alle tekstverdier og legge til dimensjonsnøkkelen i faktatabellen.

SCD-type 1

SCD-type 1-endringer overskriver den eksisterende dimensjonsraden fordi det ikke er nødvendig å holde oversikt over endringer. Denne SCD-typen kan også brukes til å rette opp feil. Det er en vanlig type SCD, og den bør brukes til de fleste endrede attributter, for eksempel kundenavn, e-postadresse og andre.

Diagrammet nedenfor viser tilstanden før og etter for et selgerdimensjonsmedlem der telefonnummeret er endret.

Denne SCD-typen bevarer ikke historisk perspektiv fordi den eksisterende raden oppdateres. Det betyr at ENDRINGER av SCD-type 1 kan resultere i ulike aggregasjoner på høyere nivå. Hvis en selger for eksempel er tilordnet til et annet salgsområde, vil en SCD-type 1-endring overskrive dimensjonsraden. Beregnet verdi av historiske salgsresultater for selgere til område vil da gi et annet resultat fordi det nå bruker det nye gjeldende salgsområdet. Det er som om selgeren alltid ble tilordnet til det nye salgsområdet.

SCD-type 2

SCD-type 2-endringer resulterer i nye rader som representerer en tidsbasert versjon av et dimensjonsmedlem. Det finnes alltid en gjeldende versjonsrad, og den gjenspeiler tilstanden til dimensjonsmedlemmet i kildesystemet. Historiske sporingsattributter i dimensjonstabelllagerverdiene som tillater identifisering av gjeldende versjon (gjeldende flagg er TRUE) og gyldighetsperioden. Det kreves en surrogatnøkkel fordi det vil være dupliserte naturlige nøkler når flere versjoner lagres.

Det er en vanlig type SCD, men den bør reserveres for attributter som må bevare historisk perspektiv.

Hvis for eksempel en selger er tilordnet til et annet salgsområde, innebærer en SCD type 2-endring en oppdateringsoperasjon og en innsettingsoperasjon.

1. Oppdateringsoperasjonen overskriver gjeldende versjon for å angi de historiske sporingsattributter. Kolonnen for slutt gyldighet er angitt til ETL-behandlingsdatoen (eller et passende tidsstempel i kildesystemet), og gjeldende flagg er satt til FALSE.
2. Innsettingsoperasjonen legger til en ny, gjeldende versjon, og angir start-gyldighetskolonnen til sluttverdi for gyldighet (brukes til å oppdatere den forrige versjonen) og gjeldende flagg til TRUE.

Det er viktig å forstå at detaljnivået til relaterte faktatabeller ikke er på selgernivå, men heller selgerens versjonsnivå . Sammendraget av de historiske salgsresultatene til området vil gi riktige resultater, men det vil være to (eller flere) selgermedlemsversjoner å analysere.

Diagrammet nedenfor viser tilstanden før og etter for et selgerdimensjonsmedlem der salgsområdet er endret. Siden organisasjonen ønsker å analysere selgerinnsats etter området de er tilordnet til, utløser den en SCD type 2-endring.

Tips

Når en dimensjonstabell støtter SCD-type 2-endringer, bør du inkludere et etikettattributt som beskriver medlemmet og versjonen. Vurder et eksempel når selgeren Lynn Tsoflias fra Adventure Works endrer tildeling fra den australske salgsregionen til salgsområdet i Storbritannia. Etikettattributtet for den første versjonen kunne lese "Lynn Tsoflias (Australia)" og etikettattributtet for den nye, nåværende versjonen kunne lese "Lynn Tsoflias (Storbritannia)." Hvis nyttig, kan du inkludere gyldighetsdatoene i etiketten også.

Du bør balansere behovet for historisk nøyaktighet kontra brukervennlighet og effektivitet. Prøv å unngå for mange SCD-type 2-endringer i en dimensjonstabell fordi det kan resultere i et overveldende antall versjoner som kan gjøre det vanskelig for analytikere å forstå.

For mange versjoner kan også indikere at et endringsattributt kan lagres bedre i faktatabellen. Hvis salgsområdet endres ofte, kan salgsområdet lagres som en dimensjonsnøkkel i faktatabellen i stedet for å implementere en SCD-type 2.

Vurder følgende SCD type 2 historiske sporingsattributter.

CREATE TABLE d_Salesperson
(
    <…>

    --Historical tracking attributes (SCD type 2)
    RecChangeDate_FK INT NOT NULL,
    RecValidFromKey INT NOT NULL,
    RecValidToKey INT NOT NULL,
    RecReason VARCHAR(15) NOT NULL,
    RecIsCurrent BIT NOT NULL,

    <…>
);

Her er formålet med de historiske sporingsattributter.

• Kolonnen RecChangeDate_FK lagrer datoen da endringen trådte i kraft. Den lar deg spørre når endringene fant sted.
• Kolonnene RecValidFromKey og RecValidToKey lagrer gyldighetsdatoene for raden. Vurder å lagre den tidligste datoen i datodimensjonen for RecValidFromKey å representere den opprinnelige versjonen, og lagre 01/01/9999 for RecValidToKey gjeldende versjoner.
• Kolonnen RecReason er valgfri. Den gjør det mulig å dokumentere årsaken til at versjonen ble satt inn. Det kan kode hvilke attributter som er endret, eller det kan være en kode fra kildesystemet som sier en bestemt forretningsårsak.
• Kolonnen RecIsCurrent gjør det mulig å hente bare gjeldende versjoner. Den brukes når ETL-prosessen slår opp dimensjonsnøkler når du laster inn faktatabeller.

Merk

Enkelte kildesystemer lagrer ikke historiske endringer, så det er viktig at dimensjonen behandles regelmessig for å oppdage endringer og implementere nye versjoner. På den måten kan du oppdage endringer kort tid etter at de forekommer, og gyldighetsdatoene vil være nøyaktige.

SCD-type 3

SCD-type 3-endringer sporer begrenset logg med attributter. Denne fremgangsmåten kan være nyttig når det er behov for å registrere den siste endringen, eller en rekke av de siste endringene.

Denne SCD-typen bevarer begrenset historisk perspektiv. Det kan være nyttig når bare de opprinnelige og gjeldende verdiene skal lagres. I dette tilfellet er det ikke nødvendig med midlertidige endringer.

Hvis en selger for eksempel er tilordnet til et annet salgsområde, overskriver en SCD-type 3-endring dimensjonsraden. En kolonne som spesifikt lagrer det forrige salgsområdet, er angitt som forrige salgsområde, og det nye salgsområdet er angitt som gjeldende salgsområde.

Diagrammet nedenfor viser tilstanden før og etter for et selgerdimensjonsmedlem der salgsområdet er endret. Siden organisasjonen ønsker å bestemme eventuelle tidligere tildelinger i salgsområdet, utløses en SCD-type 3-endring.

Spesielle dimensjonsmedlemmer

Du kan sette inn rader i en dimensjon som representerer manglende, ukjente, I/T- eller feiltilstander. Du kan for eksempel bruke følgende surrogatnøkkelverdier.

Nøkkelverdi	Formål
0	Mangler (ikke tilgjengelig i kildesystemet)
-1	Ukjent (oppslagsfeil under en faktatabellinnlasting)
-2	I/T (ikke aktuelt)
-3	Feil

Kalender og klokkeslett

Nesten uten unntak lagrer faktatabeller mål på bestemte tidspunkter. Hvis du vil støtte analyse etter dato (og muligens klokkeslett), må det være kalenderdimensjoner (dato og klokkeslett).

Det er uvanlig at et kildesystem har kalenderdimensjonsdata, så det må genereres i datalageret. Vanligvis genereres den én gang, og hvis det er en kalenderdimensjon, utvides den med fremtidige datoer ved behov.

Datodimensjon

Datodimensjonen (eller kalenderen) er den vanligste dimensjonen som brukes til analyse. Den lagrer én rad per dato, og den støtter det vanlige kravet om å filtrere eller gruppere etter bestemte perioder med datoer, for eksempel år, kvartaler eller måneder.

Viktig

En datodimensjon bør ikke inneholde et korn som strekker seg til klokkeslettet. Hvis det kreves en tidsanalyse, bør du ha både en datodimensjon og en tidsdimensjon (beskrevet neste). Faktatabeller som lagrer klokkeslettfakta, bør ha to sekundærnøkler, én til hver av disse dimensjonene.

Den naturlige nøkkelen for datodimensjonen bør bruke datatypen dato . Surrogatnøkkelen bør lagre datoen ved hjelp YYYYMMDD av format og int-datatypen . Denne aksepterte praksisen bør være det eneste unntaket (sammen med tidsdimensjonen) når surrogatnøkkelverdien har mening og er lesbar for mennesker. YYYYMMDD Lagring som en int-datatype er ikke bare effektivt og sortert numerisk, men det samsvarer også med det entydige datoformatet International Standards Organization (ISO) 8601.

Her er noen vanlige attributter som skal inkluderes i en datodimensjon.

• Year, , Quarter, MonthDay
• QuarterNumberInYear, MonthNumberInYear som kan være nødvendig for å sortere tekstetiketter.
• FiscalYear, FiscalQuarter – noen regnskapsplaner for bedriften starter midt i året, slik at starten/slutten av kalenderåret og regnskapsåret er annerledes.
• FiscalQuarterNumberInYear, FiscalMonthNumberInYear som kan være nødvendig for å sortere tekstetiketter.
• WeekOfYear – det finnes flere måter å merke uken i året på, inkludert en ISO-standard som har enten 52 eller 53 uker.
• IsHoliday, HolidayText – hvis organisasjonen din opererer i flere geografiske områder, bør du opprettholde flere sett med ferielister som hver geografi ser på som en egen dimensjon eller naturalisert i flere attributter i datodimensjonen. Hvis du legger til et HolidayText attributt, kan det bidra til å identifisere helligdager for rapportering.
• IsWeekday – i enkelte geografiske områder er ikke standard arbeidsuke mandag til fredag. Arbeidsuken er for eksempel søndag til torsdag i mange områder i Midtøsten, mens andre regioner bruker en fire-dagers eller seks-dagers arbeidsuke.
• LastDayOfMonth
• RelativeYearOffset, RelativeQuarterOffset, RelativeMonthOffset, RelativeDayOffset som kan være nødvendig for å støtte relativ datofiltrering (for eksempel forrige måned). Gjeldende perioder bruker en forskyvning på null (0), tidligere perioder lagrer forskyvninger av -1, -2, -3...; fremtidige perioder lagrer forskyvninger på 1, 2, 3....

Som med alle dimensjoner, er det viktig at den inneholder attributter som støtter kjente krav til filtrering, gruppering og hierarki. Det kan også være attributter som lagrer oversettelser av etiketter til andre språk.

Når dimensjonen brukes til å relatere til fakta med høyere korn, kan faktatabellen bruke den første datoen i datoperioden. En faktatabell for salgsmål som lagrer kvartalsvise selgermål, lagrer for eksempel den første datoen i kvartalet i datodimensjonen. En alternativ tilnærming er å opprette nøkkelkolonner i datotabellen. En kvartnøkkel kan for eksempel lagre kvartalsnøkkelen ved hjelp YYYYQ av format og datatypen smallint .

Dimensjonen skal fylles ut med det kjente datointervallet som brukes av alle faktatabeller. Det bør også inneholde fremtidige datoer når datalageret lagrer fakta om mål, budsjetter eller prognoser. Som med andre dimensjoner kan du inkludere rader som representerer manglende, ukjente, I/T eller feilsituasjoner.

Tips

Søk på Internett etter «datodimensjonsgenerator» for å finne skript og regneark som genererer datodata.

Vanligvis bør ETL-prosessen utvide datodimensjonsradene til et bestemt antall år fremover i begynnelsen av neste år. Når dimensjonen inneholder relative forskyvningsattributter, må ETL-prosessen kjøres daglig for å oppdatere attributtverdier for forskyvning basert på gjeldende dato (i dag).

Tidsdimensjon

Noen ganger må fakta lagres på et tidspunkt (som på tidspunktet på dagen). I dette tilfellet kan du opprette en tidsdimensjon (eller klokke). Det kan ha et korn av minutter (24 x 60 = 1440 rader) eller sekunder (24 x 60 x 60 = 86 400 rader). Andre mulige korn inkluderer halvtime eller time.

Den naturlige nøkkelen til en tidsdimensjon bør bruke tidsdatatypen . Surrogatnøkkelen kan bruke et passende format og lagre verdier som har mening og som kan leses av mennesker, for eksempel ved hjelp HHMM av eller HHMMSS formatet.

Her er noen vanlige attributter som skal inkluderes i en tidsdimensjon.

• Hour, , HalfHour, QuarterHourMinute
• Tidsperiodeetiketter (morgen, ettermiddag, kveld, natt)
• Navn på arbeidsskift
• Topp- eller toppflagg

Samsvarende dimensjoner

Noen dimensjoner kan være samsvarende dimensjoner. Samsvarende dimensjoner er knyttet til mange faktatabeller, og de deles derfor av flere stjerner i en dimensjonal modell. De leverer konsistens og kan hjelpe deg med å redusere kontinuerlig utvikling og vedlikehold.

Det er for eksempel typisk at faktatabeller lagrer minst én datodimensjonsnøkkel (fordi aktiviteten nesten alltid registreres etter dato og/eller klokkeslett). Av den grunn er en datodimensjon en felles konform dimensjon. Du bør derfor sørge for at datodimensjonen inneholder attributter som er relevante for analysen av alle faktatabeller.

Diagrammet nedenfor viser faktatabellen Sales og faktatabellen Inventory . Hver faktatabell er knyttet til dimensjonen og Product dimensjonenDate, som er samsvarende dimensjoner.

Som et annet eksempel kan ansatte og brukere være det samme settet med personer. I dette tilfellet kan det være fornuftig å kombinere attributtene for hver enhet for å produsere én samsvarende dimensjon.

Rollespilldimensjoner

Når det refereres til en dimensjon flere ganger i en faktatabell, kalles den en rollespilldimensjon.

Når en salgsfaktatabell for eksempel har ordredato, forsendelsesdato og leveringsdatodimensjonsnøkler, relateres datodimensjonen på tre måter. Hver vei representerer en distinkt rolle, men det finnes bare én fysisk datodimensjon.

Diagrammet nedenfor viser en Flight faktatabell. Dimensjonen Airport er en rollespilldimensjon fordi den er relatert to ganger til faktatabellen som dimensjon og Departure Airport Arrival Airport dimensjon.

Søppeldimensjoner

En søppelpostdimensjon er nyttig når det finnes mange uavhengige dimensjoner, spesielt når de består av noen få attributter (kanskje én), og når disse attributtene har lav kardinalitet (få verdier). Målet med en søppelpostdimensjon er å konsolidere mange små dimensjoner til én enkelt dimensjon. Denne utformingstilnærmingen kan redusere antall dimensjoner, og redusere antall faktatabellnøkler og dermed faktisk tabelllagringsstørrelse. De bidrar også til å redusere rot i dataruten fordi de presenterer færre tabeller for brukere.

En søppeldimensjonstabell lagrer vanligvis det kartesiske produktet av alle dimensjonsattributteverdier, med et surrogatnøkkelattributt.

Gode kandidater inkluderer flagg og indikatorer, ordrestatus og demografiske kundestater (kjønn, aldersgruppe og andre).

Diagrammet nedenfor viser en søppelpostdimensjon med navnet Sales Status som kombinerer ordrestatusverdier og leveringsstatusverdier.

Degenerer dimensjoner

En degenerert dimensjon kan oppstå når dimensjonen er på samme korn som de relaterte fakta. Et vanlig eksempel på en degenerert dimensjon er en salgsordrenummerdimensjon som er knyttet til en salgsfaktatabell. Fakturanummeret er vanligvis et enkelt, ikke-hierarkisk attributt i faktatabellen. Det er derfor en godtatt praksis å ikke kopiere disse dataene for å opprette en egen dimensjonstabell.

Diagrammet nedenfor viser en Sales Order dimensjon som er en degenerert dimensjon basert på SalesOrderNumber kolonnen i en faktatabell for salg. Denne dimensjonen implementeres som en visning som henter de distinkte salgsordrenummerverdiene.

Tips

Det er mulig å opprette en visning i et Fabric Warehouse som presenterer degenerert dimensjon som en dimensjon for spørringsformål.

Fra et semantisk modelleringsperspektiv i Power BI kan en degenerert dimensjon opprettes som en egen tabell ved hjelp av Power Query. På den måten samsvarer den semantiske modellen med den beste fremgangsmåten som felt som brukes til å filtrere eller gruppere, hentes fra dimensjonstabeller, og felt som brukes til å oppsummere fakta, hentes fra faktatabeller.

Utriggerdimensjoner

Når en dimensjonstabell er knyttet til andre dimensjonstabeller, kalles den en utriggerdimensjon. En utriggerdimensjon kan bidra til å tilpasse og gjenbruke definisjoner i den dimensjonale modellen.

Du kan for eksempel opprette en geografidimensjon som lagrer geografiske plasseringer for hvert postnummer. Denne dimensjonen kan deretter refereres til av kundedimensjonen og selgerdimensjonen, som vil lagre surrogatnøkkelen for geografidimensjonen. På denne måten kan kunder og selgere deretter analyseres ved hjelp av konsekvente geografiske plasseringer.

Diagrammet nedenfor viser en Geography dimensjon som er en utriggerdimensjon. Den relaterer seg ikke direkte til faktatabellen Sales . I stedet er det indirekte relatert via dimensjonen Customer og dimensjonen Salesperson .

Vurder at datodimensjonen kan brukes som en utriggerdimensjon når andre dimensjonstabellattributter lagrer datoer. Fødselsdatoen i en kundedimensjon kan for eksempel lagres ved hjelp av surrogatnøkkelen i datodimensjonstabellen.

Flerverdidimensjoner

Når et dimensjonsattributt må lagre flere verdier, må du utforme en dimensjon med flere verdier. Du implementerer en flerverdidimensjon ved å opprette en brotabell (noen ganger kalt en sammenføyningstabell). En brotabell lagrer en mange-til-mange-relasjon mellom enheter.

Tenk deg for eksempel at det finnes en selgerdimensjon, og at hver selger er tilordnet til én eller muligens flere salgsområder. I dette tilfellet er det fornuftig å opprette en salgsområdedimensjon. Denne dimensjonen lagrer hvert salgsområde bare én gang. En separat tabell, kjent som brotabellen, lagrer en rad for hver selger- og salgsområderelasjon. Fysisk er det en én-til-mange-relasjon fra selgerdimensjonen til brotabellen, og en annen én-til-mange-relasjon fra salgsområdedimensjonen til brotabellen. Logisk er det en mange-til-mange-relasjon mellom selgere og salgsområder.

I diagrammet nedenfor er dimensjonstabellen Account knyttet til faktatabellen Transaction . Siden kunder kan ha flere kontoer og kontoer kan ha flere kunder, er dimensjonstabellen Customer relatert via brotabellen Customer Account .

Relatert innhold

I den neste artikkelen i denne serien kan du lære mer om veiledning og utforme anbefalte fremgangsmåter for faktatabeller.