Begivenhed
31. mar., 23 - 2. apr., 23
Den ultimative Microsoft Fabric-, Power BI-, SQL- og AI-communityledede begivenhed. 31. marts til 2. april 2025.
Tilmeld dig i dagDenne browser understøttes ikke længere.
Opgrader til Microsoft Edge for at drage fordel af de nyeste funktioner, sikkerhedsopdateringer og teknisk support.
Denne artikel henvender sig til Power BI Desktop-dataudformere. Den beskriver design af stjerneskemaer og dens relevans for udvikling af semantiske Power BI-modeller, der er optimeret til ydeevne og anvendelighed.
Vigtigt
Semantiske Power BI-modeller afhænger af Power Query for at importere eller oprette forbindelse til data. Det betyder, at du skal bruge Power Query til at transformere og forberede kildedataene, hvilket kan være en udfordring, når du har store datamængder, eller du har brug for at implementere avancerede begreber som langsomt skiftende dimensioner (beskrevet senere i denne artikel).
Når du får præsenteret disse udfordringer, anbefaler vi, at du først udvikler et data warehouse og etl-processer (Extract, Transform og Load) for at indlæse data warehouse'et med jævne mellemrum. Din semantiske model kan derefter oprette forbindelse til data warehouse. Du kan få flere oplysninger under Dimensionel modellering i Microsoft Fabric Warehouse.
Tip
Denne artikel er ikke beregnet til at give en komplet diskussion om stjerneskemadesign. 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.
Stjerneskema er en moden modelmetode, der er almindeligt anvendt af relationsdata warehouses. Det kræver, at modeludviklere klassificerer deres modeltabeller som enten dimension eller fakta.
Date
og ProductKey
. Det er nemt at forstå, at tabellen har to dimensioner. Granulariteten kan dog ikke bestemmes uden at tage dimensionsnøgleværdierne i betragtning. I dette eksempel skal du overveje, at de værdier, der er gemt i kolonnen Date
, er den første dag i hver måned. I dette tilfælde er granulariteten på månedsproduktniveau.Dimensionstabeller indeholder generelt et relativt lille antal rækker. Faktatabeller kan derimod indeholde et stort antal rækker og fortsætte med at vokse over tid.
For at forstå nogle stjerneskemabegreber, der er beskrevet i denne artikel, er det vigtigt at kende to begreber: normalisering og denormalisering.
Normalisering er det ord, der bruges til at beskrive data, der er gemt på en måde, der reducerer tilbagevendende data. Overvej en tabel med produkter, der har en entydig nøgleværdikolonne, f.eks. produktnøglen og andre kolonner, der beskriver produktegenskaber, f.eks. produktnavn, kategori, farve og størrelse. En salgstabel anses for at være normaliseret, når den kun gemmer nøgler, f.eks. produktnøglen. På følgende billede kan du se, at det kun er ProductKey
kolonnen, der registrerer produktet.
Men hvis salgstabellen gemmer produktoplysninger ud over nøglen, anses den for at være denormaliseret. På følgende billede kan du se, at de ProductKey
og andre produktrelaterede kolonner registrerer produktet.
Når du henter data fra en eksportfil eller dataudtrækning, er det sandsynligt, at det repræsenterer et deormaliseret datasæt. I dette tilfælde skal du bruge Power Query til at transformere og forme kildedataene til flere normaliserede tabeller.
Som beskrevet i denne artikel skal du bestræbe dig på at udvikle optimerede semantiske Power BI-modeller med tabeller, der repræsenterer normaliserede fakta- og dimensionsdata. Der er dog én undtagelse, hvor en snowflake-dimension kan være denormaliseret for at oprette en enkelt modeltabel.
Design af stjerneskemaer og mange relaterede begreber, der introduceres i denne artikel, er yderst relevante for udvikling af Power BI-modeller, der er optimeret til ydeevne og anvendelighed.
Overvej, at hver power BI-rapportvisualisering genererer en forespørgsel, der sendes til den semantiske Power BI-model. Forespørgsler filtrerer, grupperer og opsummerer generelt modeldata. En veldesignet model er derfor en model, der indeholder tabeller til filtrering og gruppering og tabeller til opsummering. Dette design passer godt sammen med principper for stjerneskemaer:
Der er ingen tabelegenskab, som modeludviklere har angivet til at angive tabeltypen som dimension eller fakta. Det bestemmes faktisk af modelrelationerne. En modelrelation etablerer en filteroverførselssti mellem to tabeller, og det er kardinalitetsegenskaben for relationen, der bestemmer tabeltypen. En almindelig relationskardinalitet er en til mange eller den omvendte mange til en. "en"-siden er altid en dimensionstabel, mens "mange"-siden altid er en faktatabel.
Et velstruktureret modeldesign omfatter tabeller, der enten er dimensionstabeller eller faktatabeller. Undgå at blande de to typer sammen for en enkelt tabel. Vi anbefaler også, at du bestræber dig på at levere det rigtige antal tabeller med de rette relationer på plads. Det er også vigtigt, at faktatabeller altid indlæser data på et ensartet gran.
Endelig er det vigtigt at forstå, at optimalt modeldesign er en del af videnskab og delkunst. Nogle gange kan du bryde med god vejledning, når det giver mening at gøre det.
Der er mange begreber, der er relateret til stjerneskemadesign, som kan anvendes på en semantisk Power BI-model. Disse begreber omfatter:
I design af stjerneskema er en måling en kolonne i faktatabellen, der gemmer værdier, der skal opsummeres. I en semantisk Power BI-model har en måling en anden - men lignende - definition. En model understøtter både eksplicitte og implicitte målinger.
SUM
, MIN
, MAX
, AVERAGE
og andre til at oprette et skalarværdiresultat på forespørgselstidspunktet (værdier gemmes aldrig i modellen). Målingsudtryk kan variere fra simple kolonnesammenlægninger til mere avancerede formler, der tilsidesætter filterkontekst og/eller relationsoverførsel. Du kan få flere oplysninger ved at læse om GRUNDLÆGGENDE DAX i Power BI Desktop.Sales Amount
kan f.eks. opsummeres på mange måder (sum, antal, gennemsnit, median, min. maks. m.m.), uden at det er nødvendigt at oprette en måling for hver mulige sammenlægningstype.I ruden Data repræsenteres eksplicitte målinger af lommeregnerikonet, mens implicitte målinger repræsenteres af sigmasymbolet (∑).
Der er dog tre overbevisende grunde til, at du kan oprette målinger, selv for enkle opsummeringer på kolonneniveau:
Når du ved, at rapportforfatterne forespørger den semantiske model ved hjælp af MDX (Multidimensional Expressions), skal modellen indeholde eksplicitte målinger. Det skyldes, at MDX ikke kan opnå opsummering af kolonneværdier. MDX bruges især, når der udføres Analysér i Excel , fordi pivottabeller udsteder MDX-forespørgsler.
Når du ved, at rapportforfatterne opretter sideinddelte Power BI-rapporter ved hjælp af MDX-forespørgselsdesigneren, skal den semantiske model indeholde eksplicitte målinger. Det er kun MDX-forespørgselsdesigneren, der understøtter serveraggregater. Så hvis rapportforfattere skal have målinger evalueret af Power BI (i stedet for af det sideinddelte rapportprogram), skal de bruge MDX-forespørgselsdesigneren.
Når du vil styre, hvordan rapportforfatterne opsummerer kolonner på bestemte måder. Kolonnen Forhandlersalg Unit Price
(som repræsenterer en enhedssats) kan f.eks. opsummeres, men kun ved hjælp af bestemte sammenlægningsfunktioner. Den bør aldrig lægges sammen, men det er hensigtsmæssigt at opsummere ved hjælp af andre sammenlægningsfunktioner, f.eks. min., maks. eller gennemsnit. I dette tilfælde kan modeludvikleren skjule kolonnen Unit Price
og oprette målinger for alle relevante sammenlægningsfunktioner.
Denne designtilgang fungerer godt for rapporter, der er oprettet i Power BI-tjeneste og for Q&A. Direkte forbindelser i Power BI Desktop gør det dog muligt for rapportforfattere at vise skjulte felter i ruden Data, hvilket kan resultere i omgåelse af denne designtilgang.
En surrogatnøgle er et entydigt id, som du føjer til en tabel for at understøtte modellering af stjerneskemaer. Den er pr. definition ikke defineret eller gemt i kildedataene. Surrogatnøgler føjes ofte til dimensionstabeller for relationsdata warehouse for at angive et entydigt id for hver række i dimensionstabellen.
Power BI-semantiske modelrelationer er baseret på en enkelt entydig kolonne i én tabel, som overfører filtre til en enkelt kolonne i en anden tabel. Når en dimensionstabel i din semantiske model ikke indeholder en enkelt entydig kolonne, skal du tilføje et entydigt id for at blive "en"-siden af en relation. I Power BI Desktop kan du opfylde dette krav ved at tilføje en Power Query-indekskolonne.
Du skal flette denne forespørgsel med forespørgslen "mange", så du også kan føje indekskolonnen til den. Når du indlæser disse forespørgsler i den semantiske model, kan du derefter oprette en en til mange-relation mellem modeltabellerne.
En snowflake-dimension er et sæt normaliserede tabeller for en enkelt forretningsenhed. Adventure Works klassificerer f.eks. produkter efter kategori og underkategori. Produkter tildeles til underkategorier, og underkategorier tildeles igen til kategorier. I det relationelle data warehouse Adventure Works normaliseres produktdimensionen og gemmes i tre relaterede tabeller: DimProductCategory
, DimProductSubcategory
og DimProduct
.
Hvis du bruger din fantasi, kan du forestille dig, at de normaliserede tabeller er placeret udad fra faktatabellen og danner et snefnugdesign.
I Power BI Desktop kan du vælge at efterligne et snowflake-dimensionsdesign (måske fordi dine kildedata gør) eller kombinere kildetabellerne for at danne en enkelt, denormaliseret modeltabel. Generelt opvejer fordelene ved en enkelt modeltabel fordelene ved flere modeltabeller. Den mest optimale beslutning kan afhænge af datamængderne og kravene til anvendelighed for modellen.
Når du vælger at efterligne et snowflake-dimensionsdesign:
Når du vælger at integrere i en enkelt modeltabel, kan du også definere et hierarki, der omfatter dimensionens højeste og laveste detaljering. Lagring af redundante denormaliserede data kan muligvis resultere i en øget modellagerstørrelse, især for store dimensionstabeller.
En dimension, der langsomt ændrer sig (eller SCD), er en dimension , der administrerer ændring af dimensionsmedlemmer korrekt over tid. Den gælder, når værdier for forretningsenheder ændres langsomt over tid på en uplanlagt måde. Et godt eksempel på en scd er en kundedimension, fordi kolonnerne med kontaktdetaljer, f.eks. mailadresse og telefonnummer, ændres sjældent. I modsætning hertil anses nogle dimensioner for at være hurtigt skiftende, når en dimensionsattribut ændres ofte, f.eks. markedsprisen på en aktie. Den almindelige designtilgang i disse tilfælde er at gemme hurtigt skiftende attributværdier i en måling i faktatabellen.
Teorien om design af stjerneskemaer refererer til to almindelige SCD-typer: Type 1 og Type 2. En dimensionstabel kan være Type 1 eller Type 2 eller understøtte begge typer samtidigt for forskellige kolonner.
Et type 1-scd afspejler altid de nyeste værdier, og når der registreres ændringer i kildedataene, overskrives dataene i dimensionstabellen. Denne designtilgang er almindelig for kolonner, der gemmer supplerende værdier, f.eks. en kundes mailadresse eller telefonnummer. Når en kundes mailadresse eller telefonnummer ændres, opdaterer dimensionstabellen kunderækken med de nye værdier. Det er, som om kunden altid har haft disse kontaktoplysninger.
En ikke-trinvis opdatering af en dimensionstabel for en Power BI-model opnår resultatet af en type 1 SCD. Tabeldataene opdateres for at sikre, at de nyeste værdier indlæses.
En type 2 SCD understøtter versionering af dimensionsmedlemmer. Hvis kildesystemet ikke gemmer versioner, er det normalt indlæsningsprocessen for data warehouse, der registrerer ændringer og administrerer ændringen korrekt i en dimensionstabel. I dette tilfælde skal dimensionstabellen bruge en surrogatnøgle til at angive en entydig reference til en version af dimensionsmedlemmet. Den indeholder også kolonner, der definerer gyldigheden af datointervallet for versionen (f.eks StartDate
. og EndDate
) og muligvis en flagkolonne (f.eks. IsCurrent
) for nemt at filtrere efter aktuelle dimensionsmedlemmer.
Adventure Works tildeler f.eks. alle sælgere til et salgsområde. Når en sælger flytter område, skal der oprettes en ny version af sælgeren for at sikre, at historiske fakta forbliver knyttet til det tidligere område. Dimensionstabellen skal indeholde versioner af sælgere og deres tilknyttede områder for at understøtte nøjagtig historisk analyse af salg efter sælger. Tabellen skal også indeholde værdier for start- og slutdato for at definere tids gyldighed. Aktuelle versioner kan definere en tom slutdato (eller 31-12-9999), hvilket angiver, at rækken er den aktuelle version. Tabellen skal også have en surrogatnøgle , fordi forretningsnøglen (i denne forekomst medarbejder-id) ikke er entydig.
Det er vigtigt at forstå, at når kildedataene ikke gemmer versioner, skal du bruge et mellemliggende system (f.eks. et data warehouse) til at registrere og gemme ændringer. Indlæsningsprocessen for tabellen skal bevare eksisterende data og registrere ændringer. Når der registreres en ændring, skal indlæsningsprocessen for tabellen udløbe den aktuelle version. Disse ændringer registreres ved at opdatere værdien EndDate
og indsætte en ny version, hvor StartDate
værdien starter fra den forrige EndDate
værdi. Relaterede fakta skal også bruge et tidsbaseret opslag til at hente den dimensionsnøgleværdi, der er relevant for faktadatoen. En semantisk Power BI-model bruger Power Query og kan derfor ikke give dette resultat. Den kan dog indlæse data fra en forudinstalleret SCD Type 2-dimensionstabel.
Tip
Hvis du vil vide mere om, hvordan du implementerer en Type 2 SCD-dimensionstabel i et Fabric-lager, skal du se Administrer historiske ændringer.
Den semantiske Power BI-model skal understøtte forespørgsler om historiske data for et medlem, uanset ændring, og for en version af medlemmet, som repræsenterer en bestemt tilstand for medlemmet i tide. I forbindelse med Adventure Works giver dette design dig mulighed for at forespørge sælgeren, uanset hvilken salgsregion der er tildelt, eller om en bestemt version af sælgeren.
For at opfylde dette krav skal dimensionstabellen for den semantiske Power BI-model indeholde en kolonne til filtrering af sælgeren og en anden kolonne til filtrering af en bestemt version af sælgeren. Det er vigtigt, at versionskolonnen indeholder en ikke-tvetydig beskrivelse, f.eks David Campbell (12/15/2008-06/26/2019)
. eller David Campbell (06/27/2019-Current)
. Det er også vigtigt at oplære rapportforfattere og forbrugere i de grundlæggende funktioner i SCD Type 2, og hvordan du opnår relevante rapportdesign ved at anvende korrekte filtre.
Det er en god designpraksis at inkludere et hierarki, der gør det muligt for visualiseringer at foretage detailudledning til versionsniveauet.
En dimension med forskellige roller er en dimension, der kan filtrere relaterede fakta forskelligt. I Adventure Works har datodimensionstabellen f.eks. tre relationer til fakta om forhandlersalg. Den samme dimensionstabel kan bruges til at filtrere fakta efter ordredato, afsendelsesdato eller leveringsdato.
I et data warehouse er den accepterede designmetode at definere en enkelt datodimensionstabel. På forespørgselstidspunktet oprettes datodimensionens "rolle" af den faktakolonne, du bruger til at joinforbinde tabellerne. Når du f.eks. analyserer salg efter ordredato, relaterer tabeljoinen til kolonnen med dato for forhandlersalgsordre.
I en semantisk Power BI-model kan dette design efterlignes ved at oprette flere relationer mellem to tabeller. I eksemplet med Adventure Works har tabellerne dato og forhandlersalg tre relationer.
Selvom dette design er muligt, kan der kun være én aktiv relation mellem to semantiske Power BI-modeltabeller. Alle resterende relationer skal angives til inaktive. Hvis du har en enkelt aktiv relation, betyder det, at der er en standardfilteroverførsel fra dato til forhandlersalg. I denne forekomst er den aktive relation indstillet til det mest almindelige filter, der bruges af rapporter, som i Adventure Works er ordredatorelationen.
Den eneste måde at bruge en inaktiv relation på er ved at definere et DAX-udtryk, der bruger funktionen USERELATIONSHIP . I vores eksempel skal modeludvikleren oprette målinger for at muliggøre analyse af forhandlersalg efter afsendelsesdato og leveringsdato. Dette arbejde kan være kedeligt, især når forhandlertabellen definerer mange målinger. Det opretter også en rodet datarude , der indeholder en overmængde af målinger. Der er også andre begrænsninger:
For at overvinde disse begrænsninger er en almindelig Power BI-modelleringsteknik at oprette en dimensionstabel for hver forekomst af rollespil. Du kan oprette hver dimensionstabel som en referenceforespørgsel ved hjælp af Power Query eller en beregnet tabel ved hjælp af DAX. Modellen kan indeholde en Date
tabel, en Ship Date
tabel og en Delivery Date
tabel, der hver især har en enkelt og aktiv relation til deres respektive kolonner med forhandlersalgstabeller.
Denne designtilgang kræver ikke, at du definerer flere målinger for forskellige datoroller, og det giver mulighed for samtidig filtrering efter forskellige datoroller. En mindre pris, der skal betales med denne designtilgang, er dog, at der vil være duplikering af datodimensionstabellen, hvilket resulterer i en øget modellagerstørrelse. Da dimensionstabeller typisk gemmer færre rækker i forhold til faktatabeller, er det sjældent et problem.
Vi anbefaler, at du følger gode designpraksisser, når du opretter modeldimensionstabeller for hver rolle:
Year
kolonne i alle datotabeller (kolonnenavne er entydige i deres tabel), er det ikke selvbeskrivende som standard visualtitler. Overvej at omdøbe kolonner i hver dimensionsrolletabel, så tabellen Ship Date
har en kolonne med navnet Ship Year
år osv.Date
. , som bruges til at filtrere mange faktatabeller. Hvis denne tabel f.eks. har en aktiv relation til kolonnen med dato for forhandlersalgsordrer, kan du overveje at angive en tabelbeskrivelse som f.eks Filters reseller sales by order date
. .Du kan finde flere oplysninger under Vejledning til aktive i forhold til inaktive relationer.
En dimension for uønsket post er nyttig, når der er mange dimensioner, især bestående af få attributter (måske en), og når disse attributter har få værdier. Gode kandidater omfatter kolonner med ordrestatus eller kundedemografiske kolonner, f.eks. køn eller aldersgruppe.
Designmålet for en dimension for uønsket mail er at konsolidere mange små dimensioner i en enkelt dimension for at reducere størrelsen på modellageret og også reducere rodet i dataruden ved at få færre modeltabeller.
En tabel over uønskede dimensioner er typisk det kartesiske produkt for alle medlemmer af dimensionsattributten med en surrogatnøglekolonne , der entydigt identificerer hver række. Du kan oprette dimensionen i et data warehouse eller ved hjælp af Power Query til at oprette en forespørgsel, der udfører komplette ydre forespørgselsjoinforbindelser og derefter tilføjer en surrogatnøgle (indekskolonne).
Du indlæser denne forespørgsel i modellen som en dimensionstabel. Du skal også flette denne forespørgsel med faktaforespørgslen, så indekskolonnen indlæses i modellen for at understøtte oprettelsen af en "en til mange"-modelrelation.
En degenereret dimension refererer til en attribut i faktatabellen, der kræves til filtrering. I Adventure Works er forhandlersalgsordrenummeret et godt eksempel. I dette tilfælde giver det ikke mening at oprette en uafhængig tabel, der kun består af denne ene kolonne, fordi det ville øge størrelsen på modellageret og resultere i rod i ruden Data .
I den semantiske Power BI-model kan det være hensigtsmæssigt at føje kolonnen med salgsordrenummer til faktatabellen for at tillade filtrering eller gruppering efter salgsordrenummer. Det er en undtagelse fra den tidligere introducerede regel, at du ikke skal blande tabeltyper (generelt skal modeltabeller være enten dimension eller fakta).
Men hvis tabellen Adventure Works-forhandleres salg indeholder kolonner med ordrenummer og ordrelinjenummer, og de er påkrævet til filtrering, vil oprettelse af en degenereret dimensionstabel være et godt design. Du kan finde flere oplysninger under En til en-relationsvejledning (Degenererede dimensioner).
En faktaløs faktatabel indeholder ikke nogen målingskolonner. Den indeholder kun dimensionsnøgler.
En faktaløs faktatabel kan indeholde observationer, der er defineret af dimensionsnøgler. På en bestemt dato og et bestemt klokkeslæt er en bestemt kunde f.eks. logget på dit websted. Du kan definere en måling for at tælle rækkerne i den faktaløse faktatabel for at analysere, hvornår og hvor mange kunder der er logget på.
En mere overbevisende brug af en faktafri faktatabel er at gemme relationer mellem dimensioner, og det er en semantisk modeldesigntilgang til Power BI, som vi anbefaler til definition af mange til mange-dimensionsrelationer. I et design af mange til mange-dimensionsrelationer kaldes den faktaløse faktatabel en brotabel.
Overvej f.eks., at sælgere kan tildeles til et eller flere salgsområder. Brotabellen vil være udformet som en faktaløs faktatabel, der består af to kolonner: sælgernøgle og områdenøgle. Dubletværdier kan gemmes i begge kolonner.
Denne mange til mange-designtilgang er veldokumenteret, og den kan opnås uden en brotabel. Brotabeltilgangen betragtes dog som den bedste praksis, når du relaterer to dimensioner. Du kan finde flere oplysninger i Vejledning til mange til mange-relationer (Relater to tabeller af dimensionstypen).
Du kan få flere oplysninger om stjerneskemadesign eller semantisk power BI-modeldesign i følgende artikler:
Begivenhed
31. mar., 23 - 2. apr., 23
Den ultimative Microsoft Fabric-, Power BI-, SQL- og AI-communityledede begivenhed. 31. marts til 2. april 2025.
Tilmeld dig i dagTræning
Modul
Design en semantisk model i Power BI - Training
Processen med at oprette en kompliceret semantisk model i Power BI er ligetil. Hvis dine data kommer fra mere end ét transaktionssystem, kan du, ende med at skulle arbejde med en masse tabeller, før du ved af det. Oprettelse af en stor semantisk model handler om at forenkle uorden. Et stjerneskema er én måde at forenkle en semantisk model på, og du får mere at vide om terminologien og implementeringen af dem i dette modul. Du får også mere at vide om, hvorfor det er vigtigt at vælge den korrekte datagranula
Certificering
Microsoft Certified: Power BI Data Analyst Associate - Certifications
Demonstrate methods and best practices that align with business and technical requirements for modeling, visualizing, and analyzing data with Microsoft Power BI.
Dokumentation
Modelrelationer i Power BI Desktop - Power BI
Præsenter teori om modelrelationer i Power BI Desktop
Teknikker til reduktion af data til importudformning - Power BI
Forstå forskellige teknikker for at hjælpe med at reducere de data, der indlæses i importmodeller.
Vejledning til mange til mange-relationer - Power BI
Vejledning til udvikling af mange til mange-modelrelationer.