Del via

Forstå stjerneskjema og viktigheten for Power BI

  • Artikkel

Denne artikkelen er rettet mot Power BI Desktop-datamodellerere. Den beskriver utforming av stjerneskjema og relevansen for utvikling av semantiske modeller for Power BI som er optimalisert for ytelse og brukervennlighet.

Viktig

Semantiske Power BI-modeller avhenger av Power Query for å importere eller koble til data. Det betyr at du må bruke Power Query til å transformere og klargjøre kildedataene, noe som kan være utfordrende når du har store datavolumer, eller du må implementere avanserte konsepter som sakte endrede dimensjoner (beskrevet senere i denne artikkelen).

Når du får disse utfordringene, anbefaler vi at du først utvikler et datalager og pakke ut, transformere og laste inn prosesser (ETL) for å laste inn datalageret med jevne mellomrom. Semantisk modell kan deretter koble til datalageret. Hvis du vil ha mer informasjon, kan du se Dimensjonal modellering i Microsoft Fabric Warehouse.

Tips

Denne artikkelen er ikke ment å gi en fullstendig diskusjon om utforming av stjerneskjema. 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.

Oversikt over stjerneskjema

Stjerneskjema er en moden modelleringstilnærming som er mye tatt i bruk av relasjonelle datalagre. Det krever at modellerere klassifiserer modelltabellene som enten dimensjon eller fakta.

  • Dimensjonstabeller beskriver forretningsenheter – tingene du modellerer. Enheter kan inkludere produkter, personer, steder og konsepter, inkludert selve tiden. Den mest konsekvente tabellen du finner i et stjerneskjema, er en datodimensjonstabell. En dimensjonstabell inneholder en nøkkelkolonne (eller kolonner) som fungerer som en unik identifikator og andre kolonner. Andre kolonner støtter filtrering og gruppering av dataene.
  • Faktatabeller lagrer observasjoner eller hendelser, og kan være salgsordrer, børssaldoer, valutakurser, temperaturer og mer. En faktatabell inneholder dimensjonsnøkkelkolonner som er relatert til dimensjonstabeller og numeriske målkolonner. Dimensjonsnøkkelkolonnene bestemmer dimensjonaliteten til en faktatabell, mens dimensjonsnøkkelverdiene bestemmer detaljnivået til en faktatabell. Vurder for eksempel en faktatabell som er utformet for å lagre salgsmål som har to dimensjonsnøkkelkolonner Date og ProductKey. Det er lett å forstå at tabellen har to dimensjoner. Detaljnivået kan imidlertid ikke bestemmes uten å vurdere dimensjonsnøkkelverdiene. I dette eksemplet bør du vurdere at verdiene som er lagret i kolonnen, er den første dagen i Date hver måned. I dette tilfellet er detaljnivået på månedsproduktnivå.

Dimensjonstabeller inneholder vanligvis et relativt lite antall rader. Faktatabeller kan derimot inneholde et stort antall rader og fortsette å vokse over tid.

Diagram som viser en illustrasjon av et stjerneskjema.

Normalisering kontra denormalisering

Hvis du vil forstå noen stjerneskjemakonsepter som er beskrevet i denne artikkelen, er det viktig å vite to termer: normalisering og denormalisering.

Normalisering er begrepet som brukes til å beskrive data som er lagret på en måte som reduserer repeterende data. Vurder en tabell med produkter som har en unik nøkkelverdikolonne, for eksempel produktnøkkelen og andre kolonner som beskriver produktegenskaper, for eksempel produktnavn, kategori, farge og størrelse. En salgstabell anses som normalisert når den bare lagrer nøkler, for eksempel produktnøkkelen. Legg merke til at bare ProductKey kolonnen registrerer produktet i bildet nedenfor.

Diagram som viser en tabell med data som inneholder en produktnøkkelkolonne.

Hvis salgstabellen imidlertid lagrer produktdetaljer utover nøkkelen, anses denormalisert. Legg merke til at ProductKey og andre produktrelaterte kolonner registrerer produktet i illustrasjonen nedenfor.

Diagram som viser en tabell med data som inneholder en produktnøkkel og andre produktrelaterte kolonner, inkludert kategori, farge og størrelse.

Når du henter data fra en eksportfil eller datautpakking, er det sannsynlig at det representerer et denormalisert sett med data. I dette tilfellet kan du bruke Power Query til å transformere og forme kildedataene til flere normaliserte tabeller.

Som beskrevet i denne artikkelen bør du arbeide for å utvikle optimaliserte Semantiske Modeller for Power BI med tabeller som representerer normaliserte fakta- og dimensjonsdata. Det er imidlertid ett unntak der en snøfnuggdimensjon kan være denormalisert for å produsere en enkelt modelltabell.

Stjerneskjemarelevans for semantiske modeller i Power BI

Utforming av stjerneskjema og mange relaterte konsepter som er introdusert i denne artikkelen, er svært relevante for utvikling av Power BI-modeller som er optimalisert for ytelse og brukervennlighet.

Tenk på at hvert visualobjekt i Power BI-rapporter genererer en spørring som sendes til semantisk Power BI-modell. Generelt sett filtrerer spørringer, grupperer og oppsummerer modelldata. En godt utformet modell, da, er en som gir tabeller for filtrering og gruppering, og tabeller for oppsummering. Denne utformingen passer godt med stjerneskjemaprinsipper:

  • Dimensjonstabeller aktiverer filtrering og gruppering.
  • Faktatabeller aktiverer sammendrag.

Det finnes ingen tabellegenskap som modellerere har angitt for å angi tabelltypen som dimensjon eller fakta. Det bestemmes faktisk av modellrelasjonene. En modellrelasjon etablerer en filteroverføringsbane mellom to tabeller, og det er kardinalitetsegenskapen for relasjonen som bestemmer tabelltypen. En vanlig relasjonskardinalitet er én-til-mange eller dens inverse mange-til-en. «én»-siden er alltid en dimensjonstabell, mens «mange»-siden alltid er en faktatabell.

Diagram som viser en begrepsmessig illustrasjon av et stjerneskjema.

En godt strukturert modellutforming inneholder tabeller som enten er dimensjonstabeller eller faktatabeller. Unngå å blande de to typene sammen for én enkelt tabell. Vi anbefaler også at du ønsker å levere riktig antall tabeller med de riktige relasjonene på plass. Det er også viktig at faktatabeller alltid laster inn data på et konsekvent korn.

Til slutt er det viktig å forstå at optimal modelldesign er en del vitenskap og delkunst. Noen ganger kan du bryte med god veiledning når det er fornuftig å gjøre det.

Det finnes mange konsepter relatert til utforming av stjerneskjema som kan brukes på en semantisk Power BI-modell. Disse konseptene omfatter:

Measures

I utforming av stjerneskjema er et mål en faktatabellkolonne som lagrer verdier som skal summeres. I en semantisk Power BI-modell har et mål en annen , men lik - definisjon. En modell støtter både eksplisitte og implisitte mål.

  • Eksplisitte mål opprettes uttrykkelig, og de er basert på en formel skrevet i DAX (Data Analysis Expressions) som oppnår oppsummering. Måluttrykk bruker ofte DAX-aggregasjonsfunksjoner som SUM, , MINMAX, AVERAGEog andre til å produsere et skalarverdiresultat ved spørringstidspunktet (verdier lagres aldri i modellen). Måluttrykk kan variere fra enkle kolonneaggregasjoner til mer avanserte formler som overstyrer filterkontekst og/eller relasjonsoverføring. Hvis du vil ha mer informasjon, kan du lese om GRUNNLEGGENDE OM DAX i Power BI Desktop.
  • Implisitte mål er kolonner som kan oppsummeres av et visualobjekt for rapporter eller spørsmål og svar. De tilbyr en enkelhet for deg som modellutvikler, som i mange tilfeller trenger du ikke å opprette (eksplisitte) mål. Salgskolonnen Adventure Works kan for eksempel oppsummeres Sales Amount på mange måter (sum, antall, gjennomsnitt, median, min, maks og andre), uten å måtte opprette et mål for hver mulige aggregasjonstype.

I dataruten representeres eksplisitte mål av kalkulatorikonet, mens implisitte mål representeres av sigma-symbolet (∑).

Diagram som viser ikoner som finnes i dataruten.

Det er imidlertid tre overbevisende grunner til at du kan opprette mål, selv for enkle sammendrag på kolonnenivå:

  • Når du vet at rapportforfatterne vil spørre den semantiske modellen ved hjelp av MDX (Multidimensional Expressions), må modellen inneholde eksplisitte mål. Det er fordi MDX ikke kan oppnå oppsummering av kolonneverdier. MDX brukes spesielt når du utfører Analyser i Excel fordi pivottabeller utsteder MDX-spørringer.

  • Når du vet at rapportforfatterne oppretter Paginerte Power BI-rapporter ved hjelp av MDX-spørringsutformingen, må den semantiske modellen inneholde eksplisitte mål. Bare MDX-spørringsutformingen støtter serveraggregater. Så hvis rapportforfattere må ha mål evaluert av Power BI (i stedet for av den paginerte rapportmotoren), må de bruke MDX-spørringsutformingen.

  • Når du vil kontrollere hvordan rapportforfatterne oppsummerer kolonner på bestemte måter. For eksempel kan forhandlersalgskolonnen Unit Price (som representerer en per enhetssats) oppsummeres, men bare ved hjelp av bestemte aggregasjonsfunksjoner. Det bør aldri summeres, men det er hensiktsmessig å oppsummere ved hjelp av andre aggregasjonsfunksjoner som min, maks eller gjennomsnitt. I dette tilfellet kan modelløren Unit Price skjule kolonnen og opprette mål for alle aggregasjonsfunksjoner.

    Denne utformingstilnærmingen fungerer bra for rapporter som er skrevet i Power Bi-tjeneste og for spørsmål og svar. Power BI Desktop live-tilkoblinger gjør det imidlertid mulig for rapportforfattere å vise skjulte felt i dataruten , noe som kan føre til omgåelse av denne utformingstilnærmingen.

Surrogatnøkler

En surrogatnøkkel er en unik identifikator som du legger til i en tabell for å støtte stjerneskjemamodellering. Per definisjon er den ikke definert eller lagret i kildedataene. Vanligvis legges surrogatnøkler til i dimensjonstabeller for relasjonsdatalager for å gi en unik identifikator for hver dimensjonstabellrad.

Semantiske power BI-modellrelasjoner er basert på én enkelt unik kolonne i én tabell, som overfører filtre til én enkelt kolonne i en annen tabell. Når en dimensjonstabell i den semantiske modellen ikke inneholder én enkelt unik kolonne, må du legge til en unik identifikator for å bli «én»-siden i en relasjon. I Power BI Desktop kan du oppnå dette kravet ved å legge til en power query-indekskolonne.

Diagram som viser kommandoen Opprett indekskolonne i Power Query-redigering.

Du må slå sammen denne spørringen med "mange"-side-spørringen, slik at du kan legge til indekskolonnen i den også. Når du laster inn disse spørringene til den semantiske modellen, kan du deretter opprette en én-til-mange-relasjon mellom modelltabellene.

Snøfnuggdimensjoner

En snøfnuggdimensjon er et sett med normaliserte tabeller for én enkelt forretningsenhet. Adventure Works klassifiserer for eksempel produkter etter kategori og underkategori. Produkter tilordnes underkategorier, og underkategorier tilordnes i sin tur til kategorier. I relasjonsdatalageret Adventure Works normaliseres og lagres produktdimensjonen i tre relaterte tabeller: DimProductCategory, DimProductSubcategoryog DimProduct.

Diagram som viser et eksempel på et snøfnuggdiagram bestående av tre relaterte tabeller.

Hvis du bruker fantasien, kan du se for deg de normaliserte tabellene som er plassert utover fra faktatabellen, og danner en snøfnuggutforming.

Diagram som viser et begrepsmessig eksempel på et snøfnuggdiagram bestående av tre relaterte tabeller.

I Power BI Desktop kan du velge å etterligne en snøfnuggdimensjonsutforming (kanskje fordi kildedataene gjør det) eller kombinere kildetabellene for å danne en enkelt, denormalisert modelltabell. Vanligvis oppveier fordelene med en enkelt modelltabell fordelene med flere modelltabeller. Den mest optimale beslutningen kan avhenge av datavolumene og anvendelighetskravene for modellen.

Når du velger å etterligne en snøfnuggdimensjonsutforming:

  • Power BI laster inn flere tabeller, noe som er mindre effektivt fra lagrings- og ytelsesperspektiver. Disse tabellene må inneholde kolonner for å støtte modellrelasjoner, og det kan resultere i en større modellstørrelse.
  • Lengre relasjonsfilteroverføringskjeder må krysses, noe som kan være mindre effektivt enn filtre som brukes i én enkelt tabell.
  • Dataruten presenterer flere modelltabeller for rapportforfattere, noe som kan resultere i en mindre intuitiv opplevelse, spesielt når snøfnuggdimensjonstabeller bare inneholder én eller to kolonner.
  • Det er ikke mulig å opprette et hierarki som består av kolonner fra mer enn én tabell.

Når du velger å integrere i én enkelt modelltabell, kan du også definere et hierarki som omfatter det høyeste og laveste kornet i dimensjonen. Lagring av overflødige denormaliserte data kan muligens føre til økt størrelse på modelllagring, spesielt for store dimensjonstabeller.

Diagram som viser et eksempel på et hierarki i en dimensjonstabell som har kolonner som Kategori, Underkategori og Produkt.

Endre dimensjoner sakte

En sakte skiftende dimensjon (eller SCD) er en som på riktig måte administrerer endring av dimensjonsmedlemmer over tid. Det gjelder når verdier for forretningsenhet endres sakte over tid på en ikke-planlagt måte. Et godt eksempel på en SCD er en kundedimensjon, fordi kontaktdetaljkolonnene, for eksempel e-postadresse og telefonnummer, endres sjeldent. I motsetning anses noen dimensjoner å være raskt i endring når et dimensjonsattributt endres ofte, som markedsprisen på en aksje. Den vanlige utformingstilnærmingen i disse tilfellene er å lagre raskt endrede attributtverdier i et faktatabellmål.

Utformingsteori for stjerneskjema refererer til to vanlige SCD-typer: Type 1 og Type 2. En dimensjonstabell kan være Type 1 eller Type 2, eller støtte begge typene samtidig for ulike kolonner.

Type 1 SCD

En TYPE 1 SCD gjenspeiler alltid de nyeste verdiene, og når endringer i kildedata oppdages, overskrives dimensjonstabelldataene. Denne utformingstilnærmingen er vanlig for kolonner som lagrer tilleggsverdier, for eksempel e-postadressen eller telefonnummeret til en kunde. Når en kunde-e-postadresse eller et telefonnummer endres, oppdaterer dimensjonstabellen kunderaden med de nye verdiene. Det er som om kunden alltid hadde denne kontaktinformasjonen.

Diagram som viser et eksempel på en sakte skiftende dimensjonstype 1 der et telefonnummer for ansatte oppdateres.

En ikke-trinnvis oppdatering av en dimensjonstabell for Power BI-modellen oppnår resultatet av en TYPE 1 SCD. Den oppdaterer tabelldataene for å sikre at de nyeste verdiene lastes inn.

Type 2 SCD

En TYPE 2 SCD støtter versjonskontroll av dimensjonsmedlemmer. Hvis kildesystemet ikke lagrer versjoner, er det vanligvis innlastingsprosessen for datalageret som oppdager endringer og administrerer endringen i en dimensjonstabell på riktig måte. I dette tilfellet må dimensjonstabellen bruke en surrogatnøkkel for å gi en unik referanse til en versjon av dimensjonsmedlemmet. Den inneholder også kolonner som definerer datointervallets gyldighet for versjonen (for eksempel StartDate og EndDate) og muligens en flaggkolonne (for eksempel IsCurrent) for enkelt å filtrere etter gjeldende dimensjonsmedlemmer.

Adventure Works tilordner for eksempel alle selgere til et salgsområde. Når en selger flytter område, må det opprettes en ny versjon av selgeren for å sikre at historiske fakta forblir knyttet til det tidligere området. Hvis du vil støtte nøyaktig historisk analyse av salg etter selger, må dimensjonstabellen lagre versjoner av selgere og tilknyttede områder. Tabellen bør også inneholde start- og sluttdatoverdier for å definere tidsvaliditeten. Gjeldende versjoner kan definere en tom sluttdato (eller 31.12.9999), som angir at raden er gjeldende versjon. Tabellen må også ha en surrogatnøkkel fordi forretningsnøkkelen (i dette tilfellet ansatt-ID) ikke vil være unik.

Diagram som viser et eksempel på en sakte skiftende dimensjonstype 2 der et salgsområde for ansatte oppdateres ved å opprette en ny versjon.

Det er viktig å forstå at når kildedataene ikke lagrer versjoner, må du bruke et mellomliggende system (for eksempel et datalager) til å oppdage og lagre endringer. Innlastingsprosessen for tabellen må bevare eksisterende data og oppdage endringer. Når en endring oppdages, må innlastingsprosessen for tabellen utløpe gjeldende versjon. Den registrerer disse endringene ved å oppdatere EndDate verdien og sette inn en ny versjon med StartDate verdien som begynner fra den forrige EndDate verdien. Relaterte fakta må også bruke et tidsbasert oppslag for å hente dimensjonsnøkkelverdien som er relevant for faktadatoen. En semantisk Power BI-modell bruker Power Query, og den kan derfor ikke produsere dette resultatet. Det kan imidlertid laste inn data fra en forhåndslastet SCD Type 2-dimensjonstabell.

Tips

Hvis du vil lære hvordan du implementerer en type 2 SCD-dimensjonstabell i et stofflager, kan du se Administrere historiske endringer.

Den semantiske Power BI-modellen bør støtte spørring av historiske data for et medlem, uavhengig av endring, og for en versjon av medlemmet, som representerer en bestemt tilstand for medlemmet i tide. I konteksten til Adventure Works kan du bruke denne utformingen til å spørre selgeren uavhengig av tilordnet salgsområde, eller for en bestemt versjon av selgeren.

For å oppnå dette kravet må den semantiske dimensjonstabellen for Power BI inneholde en kolonne for filtrering av selgeren, og en annen kolonne for filtrering av en bestemt versjon av selgeren. Det er viktig at versjonskolonnen gir en ikke-tvetydig beskrivelse, for eksempel David Campbell (12/15/2008-06/26/2019) eller David Campbell (06/27/2019-Current). Det er også viktig å lære rapportforfattere og forbrukere om det grunnleggende om SCD Type 2, og hvordan du oppnår riktige rapportutforminger ved å bruke riktige filtre.

Det er en god utformingspraksis å inkludere et hierarki som gjør det mulig for visualobjekter å drille ned til versjonsnivået.

Diagram som viser dataruten med kolonner for selger og selgerversjon.

Rollespilldimensjoner

En rollespilldimensjon er en dimensjon som kan filtrere relaterte fakta annerledes. I Adventure Works har for eksempel datodimensjonstabellen tre relasjoner til forhandlersalgsfakta. Den samme dimensjonstabellen kan brukes til å filtrere fakta etter ordredato, forsendelsesdato eller leveringsdato.

Diagram som viser et begrepsmessig eksempel på en enkelt rollespilldimensjon og relasjoner. Datotabellen har to relasjoner til faktatabellen for ordredato og forsendelsesdato.

I et datalager er den godtatte utformingstilnærmingen å definere én enkelt datodimensjonstabell. På spørringstidspunktet opprettes «rollen» for datodimensjonen etter hvilken faktakolonne du bruker til å bli med i tabellene. Når du for eksempel analyserer salg etter ordredato, er tabellkoblingen knyttet til datokolonnen for forhandlersalgsordre.

I en semantisk Power BI-modell kan denne utformingen etterlignes ved å opprette flere relasjoner mellom to tabeller. I eksempelet Adventure Works vil salgstabellene for dato og forhandler ha tre relasjoner.

Diagram som viser et eksempel på en enkelt rollespilldimensjon og relasjoner. Datotabellen har tre relasjoner til faktatabellen.

Selv om denne utformingen er mulig, kan det bare være én aktiv relasjon mellom to semantiske Power BI-modelltabeller. Alle gjenstående relasjoner må være satt til inaktive. Å ha en enkelt aktiv relasjon betyr at det finnes en standard filteroverføring fra dato til forhandlersalg. I dette tilfellet er den aktive relasjonen satt til det vanligste filteret som brukes av rapporter, som i Adventure Works er ordredatorelasjonen.

Den eneste måten å bruke en inaktiv relasjon på, er å definere et DAX-uttrykk som bruker USERELATIONSHIP-funksjonen . I vårt eksempel må modellutvikleren opprette mål for å aktivere analyse av forhandlersalg etter forsendelsesdato og leveringsdato. Dette arbeidet kan være kjedelig, spesielt når forhandlertabellen definerer mange mål. Det oppretter også en rotete datarute som har en overflod av mål. Det finnes også andre begrensninger:

  • Når rapportforfattere er avhengige av å oppsummere kolonner i stedet for å definere mål, kan de ikke oppnå oppsummering for de inaktive relasjonene uten å skrive et mål på rapportnivå. Mål på rapportnivå kan bare defineres når du redigerer rapporter i Power BI Desktop.
  • Med bare én aktiv relasjonsbane mellom dato- og forhandlersalg, er det ikke mulig å filtrere forhandlersalg samtidig etter ulike datotyper. Du kan for eksempel ikke produsere et visualobjekt som tegner inn ordredatosalg ved å sende salg.

For å overvinne disse begrensningene er en vanlig Teknikk for Power BI-modellering å opprette en dimensjonstabell for hver rollespillforekomst. Du kan opprette hver dimensjonstabell som en referansespørring ved hjelp av Power Query, eller en beregnet tabell ved hjelp av DAX. Modellen kan inneholde en Date tabell, en Ship Date tabell og en Delivery Date tabell, hver med én enkelt og aktiv relasjon til sine respektive tabellkolonner for forhandlersalg.

Diagram som viser et eksempel på rollespilldimensjoner og relasjoner. Det finnes tre ulike datodimensjonstabeller relatert til faktatabellen.

Denne utformingstilnærmingen krever ikke at du definerer flere mål for ulike datoroller, og den tillater samtidig filtrering etter ulike datoroller. En mindre pris å betale med denne utformingstilnærmingen er imidlertid at det vil være duplisering av datodimensjonstabellen som resulterer i økt modelllagringsstørrelse. Siden dimensjonstabeller vanligvis lagrer færre rader i forhold til faktatabeller, er det sjelden et problem.

Vi anbefaler at du følger gode utformingspraksiser når du oppretter modelldimensjonstabeller for hver rolle:

  • Kontroller at kolonnenavnene er selvbeskrivende. Selv om det er mulig å ha en Year kolonne i alle datotabeller (kolonnenavn er unike i tabellen), er det ikke selvbeskrivende som standard visuelle titler. Vurder å gi nytt navn til kolonner i hver dimensjonsrolletabell, slik at Ship Date tabellen har en årskolonne med navnet Ship Year, og så videre.
  • Når det er relevant, må du sørge for at tabellbeskrivelser gir tilbakemelding til rapportforfattere (via verktøytips for dataruten ) om hvordan filteroverføring er konfigurert. Denne klarheten er viktig når modellen inneholder en generisk navngitt tabell, for eksempel Date, som brukes til å filtrere mange faktatabeller. I tilfelle denne tabellen for eksempel har en aktiv relasjon til kolonnen for salgsordredato for forhandler, bør du vurdere å gi en tabellbeskrivelse som Filters reseller sales by order date.

Hvis du vil ha mer informasjon, kan du se Aktiv kontra inaktiv relasjonsveiledning.

Søppeldimensjoner

En søppelpostdimensjon er nyttig når det finnes mange dimensjoner, spesielt bestående av få attributter (kanskje én), og når disse attributtene har få verdier. Gode kandidater inkluderer ordrestatuskolonner eller demografiske kolonner for kunder, for eksempel kjønn eller aldersgruppe.

Utformingsmålet med en søppelpostdimensjon er å konsolidere mange små dimensjoner til én enkelt dimensjon for å redusere størrelsen på modelllagringen og også redusere rot i dataruten ved å vise færre modelltabeller.

En søppeldimensjonstabell er vanligvis det kartesiske produktet av alle dimensjonsattributtemedlemmer, med en surrogatnøkkelkolonne som unikt identifiserer hver rad. Du kan bygge dimensjonen i et datalager, eller ved å bruke Power Query til å opprette en spørring som utfører fullstendige ytre spørringskoblinger, og deretter legger du til en surrogatnøkkel (indekskolonne).

Diagram som viser et eksempel på en søppelpostdimensjonstabell. Ordrestatus har tre statuser, mens leveringsstatusen har to delstater. Søppeldimensjonstabellen lagrer alle de seks kombinasjonene av de to statusene.

Du laster inn denne spørringen til modellen som en dimensjonstabell. Du må også slå sammen denne spørringen med faktaspørringen, slik at indekskolonnen lastes inn i modellen for å støtte oppretting av en modellrelasjon mellom én og mange.

Degenerer dimensjoner

En degenerert dimensjon refererer til et attributt for faktatabellen som kreves for filtrering. Hos Adventure Works er salgsordrenummeret for forhandler et godt eksempel. I dette tilfellet er det ikke fornuftig å opprette en uavhengig tabell som består av bare denne ene kolonnen, fordi den vil øke lagringsstørrelsen for modellen og føre til rot i dataruten .

I semantisk Power BI-modell kan det være aktuelt å legge til kolonnen salgsordrenummer i faktatabellen for å tillate filtrering eller gruppering etter salgsordrenummer. Det er et unntak fra den tidligere innførte regelen at du ikke bør blande tabelltyper (vanligvis bør modelltabeller være enten dimensjon eller fakta).

Diagram som viser dataruten og salgsfaktatabellen, som inkluderer Ordrenummer-feltet.

Hvis salgstabellen Adventure Works-forhandlere har ordrenummer og ordrelinjenummerkolonner, og de er nødvendige for filtrering, vil det være en god utforming å opprette en degenerert dimensjonstabell. Hvis du vil ha mer informasjon, kan du se Én-til-én-relasjonsveiledning (degenererte dimensjoner).

Faktaløse faktatabeller

En faktaløs faktatabell inneholder ingen målkolonner. Den inneholder bare dimensjonsnøkler.

En faktaløs faktatabell kan lagre observasjoner definert av dimensjonsnøkler. En bestemt kunde er for eksempel logget på nettstedet på en bestemt dato og klokkeslett. Du kan definere et mål for å telle radene i den faktaløse faktatabellen for å utføre analyse av når og hvor mange kunder som er logget på.

En mer overbevisende bruk av en faktaløs faktatabell er å lagre relasjoner mellom dimensjoner, og det er en power BI semantisk modellutformingstilnærming vi anbefaler for å definere mange-til-mange-dimensjonsrelasjoner. I en mange-til-mange-dimensjonsrelasjonsutforming kalles den faktaløse faktatabellen en brotabell.

Tenk deg for eksempel at selgere kan tilordnes til ett eller flere salgsområder. Brotabellen vil bli utformet som en faktaløs faktatabell bestående av to kolonner: selgernøkkel og områdenøkkel. Dupliserte verdier kan lagres i begge kolonnene.

Diagram som viser en faktaløs faktatabell som bygger mellom selger- og områdedimensjoner. Den faktaløse faktatabellen består av to kolonner, som er dimensjonsnøklene.

Denne mange-til-mange-utformingstilnærmingen er godt dokumentert, og den kan oppnås uten en brotabell. Men tilnærmingen til brotabellen regnes som den beste praksisen når du relaterer to dimensjoner. Hvis du vil ha mer informasjon, kan du se Veiledning for mange-til-mange-relasjoner (relatere to dimensjonstypetabeller).

Relatert innhold

Hvis du vil ha mer informasjon om utforming av stjerneskjema eller power bi semantisk modellutforming, kan du se følgende artikler: