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 Power BI-datamodeller som er optimalisert for ytelse og brukervennlighet.

Denne artikkelen er ikke ment å gi en fullstendig diskusjon om utforming av stjerneskjema. Hvis du vil ha mer informasjon, kan du se publisert innhold direkte, 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 beskrivende kolonner.

Faktatabeller lagrer observasjoner eller hendelser, og kan være salgsordrer, børssaldoer, valutakurser, temperaturer osv. 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 Dato 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 Dato-kolonnen , er den første dagen i 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 svært stort antall rader og fortsette å vokse over tid.

Bildet 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 flere kolonner som beskriver produktegenskaper, inkludert 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 illustrasjonen nedenfor.

Bildet 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.

Bildet viser en tabell med data som inkluderer 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 Power BI-datamodeller med tabeller som representerer normaliserte fakta- og dimensjonsdata. Det er imidlertid ett unntak der en snøfnuggdimensjon bør denormaliseres for å produsere en enkelt modelltabell.

Stjerneskjemarelevans for Power BI-modeller

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 for Power BI-rapporter genererer en spørring som sendes til Power BI-modellen (som Power Bi-tjeneste kaller en semantisk modell – tidligere kjent som et datasett). Disse spørringene brukes til å filtrere, gruppere og oppsummere 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 støtter filtrering og gruppering
  • Faktatabeller støtter oppsummering

Det finnes ingen tabellegenskap som modellerere angir for å konfigurere 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 dimensjonstypetabell, mens «mange»-siden alltid er en faktatypetabell. Hvis du vil ha mer informasjon om relasjoner, kan du se Modellrelasjoner i Power BI Desktop.

Bildet viser en begrepsmessig illustrasjon av et stjerneskjema.

En godt strukturert modellutforming bør inneholde tabeller som enten er dimensjonstypetabeller eller faktatypetabeller. Unngå å blande de to typene sammen for én enkelt tabell. Vi anbefaler også at du bør strebe etter å levere riktig antall tabeller med de riktige relasjonene på plass. Det er også viktig at faktatypetabeller alltid laster inn data på et konsekvent nivå.

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 flere konsepter relatert til utforming av stjerneskjema som kan brukes på en 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 Power BI-modell har et mål en annen, men lignende definisjon. Det er en formel skrevet i DAX (Data Analysis Expressions) som oppnår oppsummering. Måluttrykk bruker ofte DAX-aggregasjonsfunksjoner som SUMMER, MIN, MAKS, GJENNOMSNITT osv. for å 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 artikkelen om GRUNNLEGGENDE OM DAX i Power BI Desktop .

Det er viktig å forstå at Power BI-modeller støtter en annen metode for å oppnå oppsummering. Alle kolonner – og vanligvis numeriske kolonner – kan oppsummeres av et visualobjekt i en rapport eller Q&A. Disse kolonnene kalles implisitte mål. De tilbyr en enkelhet for deg som modellutvikler, som i mange tilfeller trenger du ikke å opprette mål. Kolonnen Adventure Works-forhandlersalgsbeløp kan for eksempel oppsummeres på mange måter (sum, antall, gjennomsnitt, median, min, maks, osv.), uten å måtte opprette et mål for hver mulige aggregasjonstype.

Bildet viser ikoner som finnes i Felter-ruten.

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

  • Når du vet at rapportforfatterne vil spørre modellen ved hjelp av MDX (Multidimensional Expressions), må modellen inneholde eksplisitte mål. Eksplisitte mål defineres ved hjelp av DAX. Denne utformingstilnærmingen er svært relevant når et Power BI-datasett spørres ved hjelp av MDX, 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å 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 trenger å sikre at rapportforfatterne bare kan oppsummere kolonner på bestemte måter. For eksempel kan enhetspriskolonnen for forhandlersalg (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, gjennomsnitt osv. I dette tilfellet kan modelløren skjule Enhetspris-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. Live-tilkoblinger i Power BI Desktop gjør det imidlertid mulig for rapportforfattere å vise skjulte felt i Felter-ruten , 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.

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 dimensjonstypetabell i 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 enkelt oppnå dette kravet ved å opprette en indekskolonne i Power Query.

Bilde 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 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, DimProductSubcategory og DimProduct.

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

Bildet viser et 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 integrere (denormalisere) kildetabellene i én enkelt 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 sannsynligvis vil være mindre effektivt enn filtre som brukes i én enkelt tabell.
  • Feltruten presenterer flere modelltabeller for rapportforfattere, noe som kan resultere i en mindre intuitiv opplevelse, spesielt når snøfnuggdimensjonstabeller inneholder bare én eller to kolonner.
  • Det er ikke mulig å opprette et hierarki som strekker seg over tabellene.

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 svært store dimensjonstabeller.

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

Endre dimensjoner sakte

En sakte skiftende dimensjon (SCD) er en som på riktig måte administrerer endring av dimensjonsmedlemmer over tid. Det gjelder når verdier for forretningsenhet endres over tid, og på en ad hoc-måte. Et godt eksempel på en sakte skiftende dimensjon er en kundedimensjon, spesielt kontaktdetaljkolonnene, for eksempel e-postadresse og telefonnummer. I motsetning anses noen dimensjoner å være raskt i endring når et dimensjonsattributt endres ofte, som en børspris. 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 dimensjonstypetabell kan være Type 1 eller Type 2, eller støtte begge typene samtidig for ulike kolonner.

Type 1 SCD

En TYPE 1SCD 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.

En ikke-trinnvis oppdatering av en dimensjonstypetabell 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 2SCD 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 StartDato og Sluttdato) og muligens en flaggkolonne (for eksempel IsCurrent) for enkelt å filtrere etter gjeldende dimensjonsmedlemmer.

Adventure Works tilordner for eksempel 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å definere en surrogatnøkkel fordi forretningsnøkkelen (i dette tilfellet ansatt-ID) ikke vil være unik.

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 StartDato-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 Power BI-modell som bruker Power Query, kan ikke produsere dette resultatet. Det kan imidlertid laste inn data fra en forhåndslastet SCD Type 2-dimensjonstabell.

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 status 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å dimensjonstypetabellen for Power BI-modellen 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 «Michael Blythe (15.12.2008-06.26.2019)» eller «Michael Blythe (gjeldende)». 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 også en god utformingspraksis å inkludere et hierarki som gjør det mulig for visualobjekter å drille ned til versjonsnivået.

Bildet viser Felter-ruten med kolonner for selger og selgerversjon.

Bildet viser det resulterende hierarkiet, inkludert nivåer 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.

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 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. Selv om denne utformingen er mulig, er det viktig å forstå at det bare kan være én aktiv relasjon mellom to 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.

Bildet viser et eksempel på en dimensjon og relasjoner for én rollespilling. Datotabellen har tre relasjoner til faktatabellen.

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å feltruterot , med en overflod av mål. Det finnes også andre begrensninger:

  • Når rapportforfattere er avhengige av summering av 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.

Hvis du vil overvinne disse begrensningene, er en vanlig Teknikk for Power BI-modellering å opprette en dimensjonstypetabell for hver rollespillforekomst. Du oppretter vanligvis de ekstra dimensjonstabellene som beregnede tabeller ved hjelp av DAX. Ved hjelp av beregnede tabeller kan modellen inneholde en datotabell , en forsendelsesdatotabell og en leveringsdatotabell , hver med én enkelt og aktiv relasjon til sine respektive tabellkolonner for forhandlersalg.

Bildet 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, men med denne utformingstilnærmingen er at det vil være duplisering av datodimensjonstabellen som resulterer i en økt modelllagringsstørrelse. Siden dimensjonstypetabeller vanligvis lagrer færre rader i forhold til faktatypetabeller, er det sjelden et problem.

Se følgende gode utformingspraksiser når du oppretter modelldimensjonstypetabeller for hver rolle:

  • Kontroller at kolonnenavnene er selvbeskrivende. Selv om det er mulig å ha en År-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 Forsendelsesdato-tabellen har en årkolonne kalt Forsendelsesår osv.
  • Når det er relevant, må du sørge for at tabellbeskrivelser gir tilbakemelding til rapportforfattere (gjennom feltrutens verktøytips) om hvordan filteroverføring er konfigurert. Denne klarheten er viktig når modellen inneholder en generisk navngitt tabell, for eksempel Dato, som brukes til å filtrere mange faktatypetabeller. I tilfelle denne tabellen for eksempel har en aktiv relasjon til kolonnen for salgsordredato for forhandler, bør du vurdere å gi en tabellbeskrivelse som «Filtrer forhandlersalg etter ordredato».

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 (kjønn, aldersgruppe osv.).

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

En søppeldimensjonstabell er vanligvis det kartesiske produktet av alle dimensjonsattributtemedlemmer, med en surrogatnøkkelkolonne. Surrogatnøkkelen gir en unik referanse til hver rad i tabellen. 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).

Bildet viser et eksempel på en søppeldimensjonstabell. Ordrestatus har tre statuser, mens leveringsstatusen har to delstater. Søppeldimensjonstabellen lagrer alle seks kombinasjoner av de to statusene.

Du laster inn denne spørringen til modellen som en dimensjonstypetabell. 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 gir det ikke god modellutforming mening å opprette en uavhengig tabell som består av bare denne ene kolonnen, fordi den vil øke størrelsen på modelllagringen og føre til rot i feltruten .

I Power BI-modellen kan det være aktuelt å legge til kolonnen salgsordrenummer i faktatypetabellen 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 dimensjonstype eller faktatype).

Bildet viser Felter-ruten og salgsfaktatabellen, som inkluderer Ordrenummer-feltet.

Hvis salgstabellen Adventure Works-forhandlere har ordrenummer og ordrelinjenummerkolonner, og de er nødvendige for filtrering, vil en degenerert dimensjonstabell være en god utforming. 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. På en bestemt dato og et bestemt tidspunkt logget for eksempel en bestemt kunde inn på webområdet. 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 har logget på.

En mer overbevisende bruk av en faktaløs faktatabell er å lagre relasjoner mellom dimensjoner, og det er utformingstilnærmingen for Power BI-modellen vi anbefaler å 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.

Bildet 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 utforming av Power BI-modeller, kan du se følgende artikler: