Dimensionel modellering i Microsoft Fabric Warehouse: Dimensionstabeller

Gælder for:✅ SQL Analytics-slutpunkt og warehouse i Microsoft Fabric

Bemærk

Denne artikel er en del af den dimensionelle modelleringsserie af artikler. I denne serie fokuseres der på vejledning og design af bedste praksis for dimensionel modellering i Microsoft Fabric Warehouse.

Denne artikel indeholder vejledning og bedste praksis for design af dimensionstabeller i en dimensionsmodel. Den indeholder praktisk vejledning til Warehouse i Microsoft Fabric, som er en oplevelse, der understøtter mange T-SQL-funktioner, f.eks. oprettelse af tabeller og administration af data i tabeller. Så du har fuld kontrol over, hvordan du opretter tabeller med din dimensionelle model og indlæser dem med data.

Bemærk

I denne artikel henviser begrebet data warehouse til et virksomhedsdata warehouse, som leverer omfattende integration af vigtige data på tværs af organisationen. I modsætning hertil refererer det separate begreb warehouse til et Fabric Warehouse, som er en SaaS-relationsdatabase (software as a service), som du kan bruge til at implementere et data warehouse. For klarheds skyld nævnes sidstnævnte i denne artikel som Fabric Warehouse.

Tip

Hvis du er uerfaren med dimensionel modellering, kan du overveje denne serie artikler som dit første trin. Det er ikke hensigten at give en komplet diskussion om dimensionel udformning design. Du kan finde flere oplysninger i det publicerede indhold, der er vedtaget i vid udstrækning, f.eks . The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3. udgave, 2013) af Ralph Kimball og andre.

I en dimensionel model beskriver en dimensionstabel en enhed, der er relevant for din virksomhed og dine analysekrav. Dimensionstabeller repræsenterer stort set de ting , du modellerer. Ting kan være produkter, personer, steder eller andre koncepter, herunder dato og klokkeslæt. Hvis du nemt vil identificere dimensionstabeller, skal du typisk angive deres navne som præfiks med d_ eller Dim_.

Struktur af dimensionstabel

Hvis du vil beskrive strukturen i en dimensionstabel, skal du overveje følgende eksempel på en sælgerdimensionstabel med navnet d_Salesperson. I dette eksempel anvendes gode designpraksisser. Hver af grupperne af kolonner er beskrevet i følgende afsnit.

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
);

Erstatningsnøgle

Eksempeldimensionstabellen har en surrogatnøgle med navnet Salesperson_SK. En surrogatnøgle er et entydigt id med en enkelt kolonne, der genereres og gemmes i dimensionstabellen. Det er en primær nøglekolonne , der bruges til at relatere til andre tabeller i den dimensionelle model.

Surrogatnøgler bestræber sig på at isolere data warehouse'et fra ændringer i kildedata. De giver også mange andre fordele, så du kan:

• Sammenflette flere datakilder (undgå sammenstød mellem dublet-id'er).
• Sammenfletter naturlige nøgler med flere kolonner til en mere effektiv nøgle med én kolonne.
• Spor dimensionshistorikken med en dimension, der langsomt ændres (SCD) type 2.
• Begræns bredden af faktatabellen til lageroptimering (ved at vælge den mindst mulige heltalsdatatype).

En surrogatnøglekolonne er en anbefalet praksis, også selvom en naturlig nøgle (beskrevet næste) synes at være en acceptabel kandidat. Du bør også undgå at give nøgleværdierne betydning (undtagen dato- og klokkeslætsdimensionsnøgler, som beskrevet senere).

Naturlige nøgler

Eksempeldimensionstabellen har også en naturlig nøgle, der hedder EmployeeID. En naturlig nøgle er den nøgle, der er gemt i kildesystemet. Det gør det muligt at relaterer dimensionsdataene til kildesystemet, hvilket typisk udføres af en ETL-proces (Extract, Load og Transform) for at indlæse dimensionstabellen. Nogle gange kaldes en naturlig nøgle for en forretningsnøgle, og dens værdier kan være meningsfulde for virksomhedsbrugere.

Nogle gange har dimensioner ikke en naturlig nøgle. Det kan være tilfældet for datodimensionen eller opslagsdimensionerne, eller når du genererer dimensionsdata ved at normalisere en flad fil.

Dimensionsattributter

En eksempeldimensionstabel har også dimensionsattributter, f.eks. kolonnen FirstName . Dimensionsattributter giver kontekst til de numeriske data, der er gemt i relaterede faktatabeller. De er typisk tekstkolonner, der bruges i analyseforespørgsler til at filtrere og gruppere (udsnit og terninger), men som ikke skal aggregeres selv. Nogle dimensionstabeller indeholder få attributter, mens andre indeholder mange attributter (så mange som det tager at understøtte forespørgselskravene i den dimensionelle model).

Tip

En god måde at finde ud af, hvilke dimensioner og attributter du har brug for, er at finde de rigtige personer og stille de rigtige spørgsmål. Du skal især være opmærksom på, at ordet er blevet nævnt ved. Når nogen f.eks. siger, at de har brug for at analysere salg efter sælger, efter måned og efter produktkategori, fortæller de dig, at de har brug for dimensioner, der har disse attributter.

Hvis du planlægger at oprette en semantisk Direct Lake-model, skal du medtage alle de mulige kolonner, der kræves til filtrering og gruppering som dimensionsattributter. Det skyldes, at semantiske Direct Lake-modeller ikke understøtter beregnede kolonner.

Fremmede nøgler

Eksempeldimensionstabellen har også en fremmed nøgle, der hedder SalesRegion_FK. Andre dimensionstabeller kan referere til en fremmed nøgle, og deres tilstedeværelse i en dimensionstabel er et særligt tilfælde. Den angiver, at tabellen er relateret til en anden dimensionstabel, hvilket betyder, at den kan være en del af en snowflake-dimension , eller at den er relateret til en udriggerdimension.

Fabric Warehouse understøtter begrænsninger for fremmede nøgler, men de kan ikke gennemtvinges. Det er derfor vigtigt, at dit ETL-procestests for integritet mellem relaterede tabeller, når data indlæses.

Det er stadig en god idé at oprette fremmede nøgler. En god grund til at oprette fremmede nøgler, der ikke er håndhævet, er at tillade modelleringsværktøjer, f.eks. Power BI Desktop, automatisk at registrere og oprette relationer mellem tabeller i den semantiske model.

Historiske sporingsattributter

Eksempeldimensionstabellen har også forskellige historiske sporingsattributter. Historiske sporingsattributter er valgfrie baseret på dit behov for at spore specifikke ændringer, som de forekommer i kildesystemet. De gør det muligt at gemme værdier for at understøtte den primære rolle for et data warehouse, som er at beskrive fortiden præcist. Disse attributter gemmer især historisk kontekst, da ETL-processen indlæser nye eller ændrede data i dimensionen.

Du kan få flere oplysninger under Administrer historiske ændringer senere i denne artikel.

Overvågningsattributter

Eksempeldimensionstabellen har også forskellige overvågningsattributter. Overvågningsattributter er valgfrie, men anbefales. De giver dig mulighed for at spore, hvornår og hvordan dimensionsposter blev oprettet eller ændret, og de kan omfatte diagnosticerings- eller fejlfindingsoplysninger, der opstår under ETL-processer. Du vil f.eks. spore, hvem (eller hvilken proces) der har opdateret en række, og hvornår. Overvågningsattributter kan også hjælpe med at diagnosticere et udfordrende problem, f.eks. når en ETL-proces stopper uventet. De kan også markere dimensionsmedlemmer som fejl eller udledte medlemmer.

Størrelse på dimensionstabel

Ofte er de mest nyttige og alsidige dimensioner i en dimensionel model store, brede dimensioner. De er store med hensyn til rækker (over millioner) og brede med hensyn til antallet af dimensionsattributter (muligvis hundredvis). Størrelse er ikke så vigtig (selvom du skal designe og optimere til den mindst mulige størrelse). Det vigtige er, at dimensionen understøtter den påkrævede filtrering, gruppering og nøjagtige historiske analyse af faktadata.

Store dimensioner kan hentes fra flere kildesystemer. I dette tilfælde skal dimensionsbehandling kombinere, flette, deduplicere og standardisere dataene. og tildele surrogatnøgler.

Til sammenligning er nogle dimensioner små. De repræsenterer muligvis opslagstabeller, der kun indeholder flere poster og attributter. Disse små dimensioner gemmer ofte kategoriværdier, der er relateret til transaktioner i faktatabeller, og de implementeres som dimensioner med surrogatnøgler for at relatere til faktaposterne.

Tip

Når du har mange små dimensioner, kan du overveje at konsolidere dem i en dimension for uønsket post.

Koncepter for dimensionsdesign

I dette afsnit beskrives forskellige koncepter for dimensionsdesign.

Denormalisering vs. normalisering

Det er næsten altid tilfældet, at dimensionstabeller skal denormaliseres. Selvom normalisering er det ord, der bruges til at beskrive data, der er gemt på en måde, der reducerer tilbagevendende data, er denormalisering det ord, der bruges til at definere, hvor der findes forudkomputerede redundante data. Redundante data findes typisk på grund af lagringen af hierarkier (beskrevet senere), hvilket betyder, at hierarkier er fladgjort. En produktdimension kan f.eks. gemme underkategori (og dens relaterede attributter) og kategori (og dens relaterede attributter).

Da dimensioner generelt er små (sammenlignet med faktatabeller), opvejes omkostningerne ved lagring af redundante data næsten altid af den forbedrede forespørgselsydeevne og anvendelighed.

Snowflake-dimensioner

En undtagelse til denormalisering er at designe en snowflake-dimension. En snowflake-dimension normaliseres, og dimensionsdataene gemmes på tværs af flere relaterede tabeller.

I følgende diagram vises en snowflake-dimension, der består af tre relaterede dimensionstabeller: Product, Subcategoryog Category.

Overvej at implementere en snowflake-dimension, når:

• Dimensionen er ekstremt stor, og lageromkostninger opvejer behovet for høj forespørgselsydeevne. (Men jævnligt revurderer, at dette stadig er tilfældet.)
• Du skal bruge nøgler for at relatere dimensionen til fakta med højere detaljering. Faktatabellen salg gemmer f.eks. rækker på produktniveau, men faktatabellen for salgsmål gemmer rækker på underkategoriniveau.
• Du skal spore historiske ændringer på højere granularitetsniveauer.

Bemærk

Vær opmærksom på, at et hierarki i en semantisk Power BI-model kun kan være baseret på kolonner fra en enkelt semantisk modeltabel. Derfor skal en snowflake-dimension levere et denormaliseret resultat ved hjælp af en visning, der forbinder snowflake-tabellerne.

Hierarkier

Dimensionskolonner producerer ofte hierarkier. Hierarkier gør det muligt at udforske data på forskellige opsummeringsniveauer. Den indledende visning af en matrixvisualisering kan f.eks. vise årligt salg, og rapportens forbruger kan vælge at foretage detailudledning for at få vist kvartalsvis og månedligt salg.

Der er tre måder at gemme et hierarki på i en dimension. Du kan bruge:

• Kolonner fra en enkelt, denormaliseret dimension.
• En snowflake-dimension, der består af flere relaterede tabeller.
• En overordnet/underordnet-relation (selvrefererende) i en dimension.

Hierarkier kan balanceres eller ubalanceres. Det er også vigtigt at forstå, at nogle hierarkier er ujævne.

Balancerede hierarkier

Balancerede hierarkier er den mest almindelige type hierarki. Et balanceret hierarki har det samme antal niveauer. Et almindeligt eksempel på et balanceret hierarki er et kalenderhierarki i en datodimension, der omfatter niveauer for år, kvartal, måned og dato.

I følgende diagram vises et balanceret hierarki af salgsområder. Det består af to niveauer, som er salgsområdegruppe og salgsområde.

Niveauer i et balanceret hierarki er enten baseret på kolonner fra en enkelt, denormaliseret dimension eller fra tabeller, der udgør en snowflake-dimension. Når de kolonner, der repræsenterer de højere niveauer, er baseret på en enkelt, denormaliseret dimension, indeholder de redundante data.

I forbindelse med balancerede hierarkier er fakta altid relateret til et enkelt niveau i hierarkiet, hvilket typisk er det laveste niveau. På den måde kan fakta aggregeres (opløftes) til det højeste niveau i hierarkiet. Fakta kan relatere til et hvilket som helst niveau, som bestemmes af faktatabellens detaljeringsgrad. Faktatabellen for salg kan f.eks. gemmes på datoniveau, mens faktatabellen for salgsmålet kan gemmes på kvartalsniveau.

Ubalancerede hierarkier

Ubalancerede hierarkier er en mindre almindelig type hierarki. Et hierarki, der ikke er balanceret, har niveauer, der er baseret på en overordnet/underordnet-relation. Derfor bestemmes antallet af niveauer i et ubalanceret hierarki af dimensionsrækkerne og ikke bestemte kolonner i dimensionstabellen.

Et almindeligt eksempel på et ubalanceret hierarki er et medarbejderhierarki, hvor hver række i en medarbejderdimension er relateret til en rapportstyringsrække i den samme tabel. I dette tilfælde kan enhver medarbejder være leder med rapporteringsmedarbejdere. Nogle grene af hierarkiet har naturligvis flere niveauer end andre.

I følgende diagram vises et ubalanceret hierarki. Det består af fire niveauer, og hvert medlem i hierarkiet er en sælger. Bemærk, at sælgere har et andet antal overordnede i hierarkiet, afhængigt af hvem de rapporterer til.

Andre almindelige eksempler på ubalancerede hierarkier omfatter styklister, virksomhedsejerskabsmodeller og finans.

For ubalancerede hierarkier er fakta altid relateret til dimensionskornet. Salgsfakta er f.eks. relateret til forskellige sælgere, der har forskellige rapporteringsstrukturer. Dimensionstabellen har en surrogatnøgle (med navnet Salesperson_SK) og en ReportsTo_Salesperson_FK fremmed nøglekolonne, som refererer til kolonnen med den primære nøgle. Hver sælger uden nogen at administrere er ikke nødvendigvis på det laveste niveau i en gren af hierarkiet. Når de ikke er på det laveste niveau, kan en sælger sælge produkter og have rapporterende sælgere, der også sælger produkter. Så akkumulering af faktadata skal tage højde for den enkelte sælger og alle deres underordnede.

Forespørgsler om overordnede/underordnede hierarkier kan være komplekse og langsomme, især for store dimensioner. Selvom kildesystemet kan gemme relationer som overordnet/underordnet, anbefaler vi, at du naturaliserer hierarkiet. I denne forekomst betyder naturaliser at transformere og gemme hierarkiniveauerne i dimensionen som kolonner.

Tip

Hvis du vælger ikke at naturalisere hierarkiet, kan du stadig oprette et hierarki baseret på en overordnet/underordnet-relation i en semantisk Power BI-model. Denne fremgangsmåde anbefales dog ikke for store dimensioner. Du kan få flere oplysninger under Om funktioner for overordnede/underordnede hierarkier i DAX.

Ujævne hierarkier

Nogle gange er et hierarki ujævnt , fordi det overordnede element for et medlem i hierarkiet findes på et niveau, der ikke er umiddelbart over det. I disse tilfælde gentager manglende niveauværdier værdien for det overordnede element.

Overvej et eksempel på et balanceret geografihierarki. Der findes et ujævnt hierarki, når et land/område ikke har nogen stater eller provinser. New Zealand har f.eks. hverken stater eller provinser. Når du indsætter rækken New Zealand, skal du derfor også gemme værdien land/område i kolonnen StateProvince .

Følgende diagram viser et ujævnt hierarki af geografiske områder.

Administrer historiske ændringer

Når det er nødvendigt, kan historiske ændringer styres ved at implementere en dimension , der langsomt ændrer sig. En SCD bevarer historisk kontekst, da nye eller ændrede data indlæses i den.

Her er de mest almindelige scd-typer.

• Type 1: Overskriv det eksisterende dimensionsmedlem.
• Type 2: Indsæt et nyt tidsbaseret versionsbaseret dimensionsmedlem.
• Type 3: Spor begrænset historik med attributter.

Det er muligt, at en dimension understøtter både ændringer af SCD type 1 og SCD type 2.

SCD type 3 bruges ikke ofte, til dels fordi det er svært at bruge i en semantisk model. Overvej nøje, om en scd type 2-tilgang ville være bedre egnet.

Tip

Hvis du forventer en dimension, der ændrer sig hurtigt, hvilket er en dimension, der har en attribut, der ofte ændres, kan du overveje at føje attributten til faktatabellen i stedet for. Hvis attributten er numerisk, f.eks. produktprisen, kan du tilføje den som en måling i faktatabellen. Hvis attributten er en tekstværdi, kan du oprette en dimension baseret på alle tekstværdier og føje dens dimensionsnøgle til faktatabellen.

SCD-type 1

Ændringer af SCD type 1 overskriver den eksisterende dimensionsrække, fordi det ikke er nødvendigt at holde styr på ændringerne. Denne scd-type kan også bruges til at rette fejl. Det er en almindelig type scd, og den skal bruges til de fleste ændrede attributter, f.eks. kundenavn, mailadresse og andre.

I følgende diagram vises tilstanden før og efter for et sælgerdimensionsmedlem, hvor deres telefonnummer er blevet ændret.

Denne scd-type bevarer ikke det historiske perspektiv, fordi den eksisterende række opdateres. Det betyder, at ændringer af SCD type 1 kan resultere i forskellige sammenlægninger på højere niveau. Hvis en sælger f.eks. er tildelt et andet salgsområde, overskriver en ændring af SCD type 1 dimensionsrækken. Akkumulering af sælgeres historiske salgsresultater til området vil derefter give et andet resultat, fordi det nu bruger det nye aktuelle salgsområde. Det er, som om denne sælger altid er blevet tildelt det nye salgsområde.

SCD-type 2

Ændringer af SCD type 2 resulterer i nye rækker, der repræsenterer en tidsbaseret version af et dimensionsmedlem. Der er altid en aktuel versionsrække, og den afspejler tilstanden for dimensionsmedlemmet i kildesystemet. Historiske sporingsattributter i dimensionstabellen gemmer værdier, der gør det muligt at identificere den aktuelle version (aktuelt flag er TRUE) og dens gyldighedsperiode. Der kræves en surrogatnøgle, fordi der vil være identiske naturlige nøgler, når der gemmes flere versioner.

Det er en almindelig type scd, men den skal være reserveret til attributter, der skal bevare det historiske perspektiv.

Hvis en sælger f.eks. er tildelt et andet salgsområde, omfatter en ændring af SCD type 2 en opdateringshandling og en indsættelseshandling.

1. Opdateringshandlingen overskriver den aktuelle version for at angive de historiske sporingsattributter. Kolonnen for slut gyldighed er specifikt angivet til ETL-behandlingsdatoen (eller et passende tidsstempel i kildesystemet), og det aktuelle flag er angivet til FALSE.
2. Indsæt-handlingen tilføjer en ny, aktuel version, hvor kolonnen for startafgyldighed indstilles til kolonneværdien for slut gyldighed (bruges til at opdatere den tidligere version) og det aktuelle flag til TRUE.

Det er vigtigt at forstå, at granulariteten af relaterede faktatabeller ikke er på sælgerniveau, men snarere på niveauet for sælgerversionen. Akkumulering af deres historiske salgsresultater til området giver korrekte resultater, men der vil være to (eller flere) versioner af sælgere, der kan analyseres.

I følgende diagram vises tilstanden før og efter for et medlem af en sælgerdimension, hvor deres salgsområde er blevet ændret. Da organisationen ønsker at analysere sælgeres indsats efter det område, de er tildelt, udløser den en ændring af SCD-type 2.

Tip

Når en dimensionstabel understøtter ændringer af scd type 2, skal du inkludere en mærkattribut, der beskriver medlemmet og versionen. Overvej et eksempel, når sælgeren Lynn Tsoflias fra Adventure Works ændrer tildelingen fra det australske salgsområde til salgsområdet i Storbritannien. Mærkattributten for den første version kunne læse "Lynn Tsoflias (Australien)", og mærkattributten for den nye aktuelle version kunne læse "Lynn Tsoflias (Storbritannien)." Hvis det er nyttigt, kan du også inkludere gyldighedsdatoerne i etiketten.

Du bør afbalancere behovet for historisk nøjagtighed i forhold til anvendelighed og effektivitet. Prøv at undgå at have for mange ændringer af scd type 2 i en dimensionstabel, da det kan resultere i et overvældende antal versioner, der kan gøre det svært for analytikere at forstå.

For mange versioner kan også indikere, at en ændringsattribut er bedre gemt i faktatabellen. Hvis det tidligere eksempel udvides, kan salgsområdet gemmes som en dimensionsnøgle i faktatabellen i stedet for at implementere en SCD-type 2, hvis der ofte sker ændringer i salgsområdet.

Overvej følgende historiske sporingsattributter af typen SCD type 2.

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 gemmer den dato, hvor ændringen trådte i kraft. Det giver dig mulighed for at forespørge, hvornår ændringerne fandt sted.
• Kolonnerne RecValidFromKey og RecValidToKey gemmer ikrafttrædelsesdatoerne for gyldigheden for rækken. Overvej at gemme den tidligste dato, der blev fundet i datodimensionen, for for RecValidFromKey at repræsentere den oprindelige version og gemme 01/01/9999 for de RecValidToKey aktuelle versioner.
• Kolonnen RecReason er valgfri. Det gør det muligt at dokumentere årsagen til, at versionen blev indsat. Det kan kode, hvilke attributter der er ændret, eller det kan være en kode fra kildesystemet, der angiver en bestemt forretningsårsag.
• Kolonnen RecIsCurrent gør det kun muligt at hente aktuelle versioner. Den bruges, når ETL-processen slår dimensionsnøgler op, når faktatabeller indlæses.

Bemærk

Nogle kildesystemer gemmer ikke historiske ændringer, så det er vigtigt, at dimensionen behandles regelmæssigt for at registrere ændringer og implementere nye versioner. På den måde kan du registrere ændringer kort efter, at de forekommer, og deres gyldighedsdatoer vil være nøjagtige.

SCD-type 3

Ændringer af SCD type 3 sporer begrænset historik med attributter. Denne fremgangsmåde kan være nyttig, når der er behov for at registrere den seneste ændring eller en række af de seneste ændringer.

Denne scd-type bevarer et begrænset historisk perspektiv. Det kan være nyttigt, når det kun er de indledende og aktuelle værdier, der skal gemmes. I dette tilfælde er midlertidige ændringer ikke påkrævet.

Hvis en sælger f.eks. er tildelt et andet salgsområde, overskriver en ændring af SCD type 3 dimensionsrækken. En kolonne, der specifikt gemmer det forrige salgsområde, angives som det forrige salgsområde, og det nye salgsområde angives som det aktuelle salgsområde.

I følgende diagram vises tilstanden før og efter for et medlem af en sælgerdimension, hvor deres salgsområde er blevet ændret. Da organisationen ønsker at bestemme en tidligere tildeling af salgsområde, udløser den en ændring af SCD-type 3.

Særlige dimensionsmedlemmer

Du kan indsætte rækker i en dimension, der repræsenterer manglende, ukendte, I/T eller fejltilstande. Du kan f.eks. bruge følgende surrogatnøgleværdier.

Nøgleværdi	Formål
0	Mangler (ikke tilgængelig i kildesystemet)
-1	Ukendt (opslagsfejl under indlæsning af en faktatabel)
-2	I/T (ikke relevant)
-3	Error

Kalender og klokkeslæt

Næsten uden undtagelse gemmer faktatabeller målinger på bestemte tidspunkter. Hvis du vil understøtte analyse efter dato (og muligvis klokkeslæt), skal der være kalenderdimensioner (dato og klokkeslæt).

Det er ualmindeligt, at et kildesystem har kalenderdimensionsdata, så de skal genereres i data warehouse'et. Den genereres typisk én gang, og hvis det er en kalenderdimension, forlænges den med fremtidige datoer, når det er nødvendigt.

Datodimension

Datodimensionen (eller kalenderdimensionen) er den mest almindelige dimension, der bruges til analyse. Den gemmer én række pr. dato og understøtter det almindelige krav om at filtrere eller gruppere efter bestemte datoer, f.eks. år, kvartaler eller måneder.

Vigtigt

En datodimension må ikke indeholde et detaljeringsformat, der strækker sig til et tidspunkt på dagen. Hvis analyse af klokkeslæt på dagen er påkrævet, skal du både have en datodimension og en tidsdimension (beskrevet næste). Faktatabeller, der gemmer fakta om tidspunktet på dagen, skal have to fremmede nøgler, én til hver af disse dimensioner.

Den naturlige nøgle for datodimensionen skal bruge datatypen Dato . Surrogatnøglen skal gemme datoen ved hjælp YYYYMMDD af formatet og datatypen int . Denne accepterede praksis bør være den eneste undtagelse (sammen med tidsdimensionen), når surrogatnøglens værdi har betydning og er læsbar for mennesker. YYYYMMDD Lagring som en int-datatype er ikke kun effektiv og sorteret numerisk, men er også i overensstemmelse med det entydige datoformat for International Standards Organization (ISO) 8601.

Her er nogle almindelige attributter, der skal medtages i en datodimension.

• Year, , QuarterMonth,Day
• QuarterNumberInYear, MonthNumberInYear – som kan være påkrævet for at sortere tekstnavne.
• FiscalYear, FiscalQuarter – nogle virksomhedsregnskabsplaner starter midt på året, så starten/slutningen af kalenderåret og regnskabsåret er forskellige.
• FiscalQuarterNumberInYear, FiscalMonthNumberInYear – som kan være påkrævet for at sortere tekstnavne.
• WeekOfYear – der er flere måder at mærke ugen i året på, herunder en ISO-standard, der har enten 52 eller 53 uger.
• IsHoliday, HolidayText – hvis din organisation opererer i flere geografiske områder, skal du vedligeholde flere sæt helligdagslister, som hvert geografi betragter som en separat dimension eller naturaliseret i flere attributter i datodimensionen. Hvis du tilføjer en HolidayText attribut, kan det hjælpe med at identificere helligdage til rapportering.
• IsWeekday – på samme måde er standardarbejdsugen i nogle geografiske områder ikke mandag til fredag. Arbejdsugen er f.eks. søndag til torsdag i mange mellemøstlige områder, mens andre områder har en fire-dages eller seks-dages arbejdsuge.
• LastDayOfMonth
• RelativeYearOffset, RelativeQuarterOffset, RelativeMonthOffsetRelativeDayOffset – som kan være påkrævet for at understøtte relativ datofiltrering (f.eks. forrige måned). Aktuelle perioder bruger en forskydning på nul (0); tidligere perioder lagrer forskydninger på -1, -2, -3...; fremtidige perioder lagrer forskydninger på 1, 2, 3....

Som med enhver dimension er det vigtigt, at den indeholder attributter, der understøtter kendte krav til filtrering, gruppering og hierarki. Der kan også være attributter, der gemmer oversættelser af mærkater til andre sprog.

Når dimensionen bruges til at relatere til fakta med højere detaljering, kan faktatabellen bruge den første dato i datoperioden. En faktatabel for salgsmål, der gemmer kvartalsvise sælgeres mål, gemmer f.eks. den første dato i kvartalet i datodimensionen. En alternativ metode er at oprette nøglekolonner i datotabellen. En fjerdedelsnøgle kan f.eks. gemme kvartalsnøglen ved hjælp YYYYQ af formatet og datatypen smallint .

Dimensionen skal udfyldes med det kendte datointerval, der bruges af alle faktatabeller. Den bør også indeholde fremtidige datoer, når data warehouse gemmer fakta om mål, budgetter eller prognoser. Som med andre dimensioner kan du inkludere rækker, der repræsenterer manglende, ukendte, I/T- eller fejlsituationer.

Tip

Søg på internettet efter "datodimensionsgenerator" for at finde scripts og regneark, der genererer datodata.

I begyndelsen af det næste år bør ETL-processen typisk udvide datodimensionsrækkerne til et bestemt antal år forude. Når dimensionen indeholder relative forskydningsattributter, skal ETL-processen køres dagligt for at opdatere forskydningsattributværdier baseret på den aktuelle dato (i dag).

Tidsdimension

Nogle gange skal fakta gemmes på et tidspunkt (som på tidspunktet på dagen). I dette tilfælde skal du oprette en tidsdimension (eller et ur). Det kan have et gran af minutter (24 x 60 = 1.440 rækker) eller endda sekunder (24 x 60 x 60 = 86.400 rækker). Andre mulige korn omfatter en halv time eller time.

Den naturlige nøgle for en tidsdimension skal bruge datatypen Tid . Erstatningsnøglen kan bruge et passende format og gemme værdier, der har betydning og er læsbare for mennesker, f.eks. ved hjælp HHMM af formatet eller HHMMSS .

Her er nogle almindelige attributter, der skal medtages i en tidsdimension.

• Hour, , HalfHourQuarterHour,Minute
• Tidsmærkater (morgen, eftermiddag, aften, nat)
• Navne på arbejdsskift
• Flag for spidsbelastning eller ikke-spidsbelastning

Dimensioner, der er i overensstemmelse

Nogle dimensioner kan være i overensstemmelse med målene. Overensstemmende dimensioner er relateret til mange faktatabeller, og de deles derfor af flere stjerner i en dimensionel model. De leverer ensartethed og kan hjælpe dig med at reducere den løbende udvikling og vedligeholdelse.

Det er f.eks. typisk, at faktatabeller gemmer mindst én datodimensionsnøgle (fordi aktivitet næsten altid registreres efter dato og/eller klokkeslæt). Derfor er en datodimension en fælles overensstemmende dimension. Du skal derfor sikre, at datodimensionen indeholder attributter, der er relevante for analysen af alle faktatabeller.

I følgende diagram vises Sales faktatabellen og Inventory faktatabellen. Hver faktatabel er relateret til dimensionen Date og Product dimensionen, som er i overensstemmelse med dimensionerne.

Som et andet eksempel kan din medarbejder og dine brugere være det samme sæt personer. I dette tilfælde kan det give mening at kombinere attributterne for hver enhed for at oprette én dimension, der er i overensstemmelse med hinanden.

Dimensioner med forskellige roller

Når der refereres til en dimension flere gange i en faktatabel, kaldes den en dimension med forskellige roller.

Når en salgs faktatabel f.eks. har dimensionsnøgler for ordredato, afsendelsesdato og leveringsdato, relaterer datodimensionen på tre måder. Hver måde repræsenterer en særskilt rolle, men der er kun én fysisk datodimension.

I følgende diagram vises en Flight faktatabel. Dimensionen Airport er en dimension med forskellige roller, fordi den er relateret to gange til faktatabellen som dimensionen Departure Airport og dimensionen Arrival Airport .

Dimensionerne for uønsket post

En dimension for uønsket post er nyttig, når der er mange uafhængige dimensioner, især når de indeholder nogle få attributter (måske en), og når disse attributter har lav kardinalitet (få værdier). Formålet med en dimension for uønsket mail er at konsolidere mange små dimensioner i en enkelt dimension. Denne designtilgang kan reducere antallet af dimensioner og reducere antallet af faktatabelnøgler og dermed lagringsstørrelsen for faktatabellen. De hjælper også med at reducere rodet i dataruden , fordi de præsenterer færre tabeller for brugerne.

En tabel over uønskede dimensioner gemmer typisk det kartesiske produkt af alle dimensionsattributværdier med en surrogatnøgleattribut.

Gode kandidater omfatter flag og indikatorer, ordrestatus og kundedemografiske stater (køn, aldersgruppe og andre).

I følgende diagram vises en dimension for uønsket post med navnet Sales Status , der kombinerer værdier for ordrestatus og leveringsstatusværdier.

Degenerere dimensioner

Der kan opstå en degenereret dimension , når dimensionen er på samme detaljeringsgrænse som de relaterede fakta. Et almindeligt eksempel på en forringet dimension er en dimension for salgsordrenummer, der er relateret til en salgs faktatabel. Fakturanummeret er typisk en enkelt, ikke-hierarkisk attribut i faktatabellen. Det er derfor en accepteret praksis ikke at kopiere disse data for at oprette en separat dimensionstabel.

I følgende diagram vises en Sales Order dimension, der er en forringet dimension baseret på kolonnen SalesOrderNumber i en salgs faktatabel. Denne dimension implementeres som en visning, der henter de entydige værdier for salgsordrenummer.

Tip

Det er muligt at oprette en visning i et Fabric Warehouse, der præsenterer den forringede dimension som en dimension til forespørgselsformål.

Fra et semantisk modelleringsperspektiv i Power BI kan der oprettes en forringet dimension som en separat tabel ved hjælp af Power Query. På den måde er den semantiske model i overensstemmelse med den bedste praksis, som felter, der bruges til at filtrere eller gruppere, hentes fra dimensionstabeller, og felter, der bruges til at opsummere fakta, hentes fra faktatabeller.

Outrigger-dimensioner

Når en dimensionstabel er relateret til andre dimensionstabeller, kaldes den en udriggerdimension. En outrigger-dimension kan hjælpe med at overholde og genbruge definitioner i den dimensionelle model.

Du kan f.eks. oprette en geografidimension, der gemmer geografiske placeringer for hvert postnummer. Denne dimension kan derefter refereres til af din kundedimension og sælgerdimension, som gemmer surrogatnøglen for geografidimensionen. På den måde kan kunder og sælgere derefter analyseres ved hjælp af ensartede geografiske placeringer.

I følgende diagram vises en Geography dimension, der er en udriggerdimension. Det er ikke direkte relateret til Sales faktatabellen. I stedet er den relateret indirekte via dimensionen Customer og dimensionen Salesperson .

Overvej, at datodimensionen kan bruges som en udriggerdimension, når andre dimensionstabelattributter gemmer datoer. Fødselsdatoen i en kundedimension kan f.eks. gemmes ved hjælp af surrogatnøglen i datodimensionstabellen.

Dimensioner med flere værdier

Når en dimensionsattribut skal gemme flere værdier, skal du designe en dimension med flere værdier. Du implementerer en dimension med flere værdier ved at oprette en brotabel (også kaldet en jointabel). En brotabel gemmer en mange til mange-relation mellem objekter.

Overvej f.eks., at der er en sælgerdimension, og at hver sælger er tildelt et eller muligvis flere salgsområder. I dette tilfælde giver det mening at oprette en dimension for salgsområde. Denne dimension gemmer kun hvert salgsområde én gang. En separat tabel, der kaldes brotabellen, gemmer en række for hver sælger- og salgsområderelation. Fysisk er der en en til mange-relation fra sælgerdimensionen til brotabellen og en anden en til mange-relation fra salgsområdedimensionen til brotabellen. Logisk set er der en mange til mange-relation mellem sælgere og salgsområder.

I følgende diagram Account er dimensionstabellen relateret til Transaction faktatabellen. Da kunder kan have flere konti, og konti kan have flere kunder, Customer er dimensionstabellen relateret via Customer Account brotabellen.

Relateret indhold

I den næste artikel i denne serie kan du få mere at vide om vejledning og design af bedste praksis for faktatabeller.