Designa stjärnschema för semantiska modeller

Du valde hur data flödar in i din semantiska modell. Utforma nu stjärnschemat som organiserar det för tydliga, högpresterande frågor. Ett star-schema ansluter faktatabeller till dimensionstabeller via relationer, vilket skapar de filtersökvägar som rapporter och AI-förbrukning är beroende av. Om du är bekant med att skapa star-schema i Power BI Desktop fokuserar den här lektionen på de beslut om relationsdesign som är viktiga när modeller växer i komplexitet och skala.

Star-schema i en semantisk modell

I ett star-schema lagrar faktatabeller mätbara affärshändelser (till exempel försäljningstransaktioner, orderrader och webbbesök) och dimensionstabeller ger den beskrivande kontexten (till exempel produktinformation, kundinformation och datumattribut). Dimensionstabeller filtrerar faktatabeller via relationer, vilket gör det möjligt för användare att dela upp mått efter alla beskrivande attribut.

I en semantisk modell för Fabric ger detta mönster effektiv vidareföring av filter för både rapporter och AI-användning. När Copilot eller en dataagent genererar en fråga med naturligt språk ger ett välorganiserat stjärnschema AI tydliga sökvägar till rätt data. Tvetydiga eller cirkulära relationer förvirrar både rapportkonsumenter och AI-verktyg.

Så här påverkar lagringsläget relationer

Relationer i en semantisk modell fungerar annorlunda beroende på lagringsläget. Att förstå dessa skillnader är viktigt för att utforma star-scheman som fungerar bra i olika scenarier.

Direkt Lake-relationer

I Direct Lake-läge läser motorn relationer direkt från Delta-tabellmetadata. Relationer presterar bäst när:

• Dimensionsnyckelkolumner har låg kardinalitet i förhållande till faktatabellrader.
• Referensintegritet upprätthålls i källdata. När referensintegriteten gäller använder motorn INRE kopplingar i stället för VÄNSTER YTTRE kopplingar, vilket förbättrar frågeprestandan.
• Kolumner som används i relationer indexeras i de underliggande Delta-tabellerna.

Relationer mellan källor

Fabric semantiska modeller kan ansluta tabeller från olika datalager. En faktatabell från ett lakehouse kan ha en relation till en dimensionstabell från ett lager eller till en tabell som nås via en SQL-analysslutpunkt. Dessa anslutningar mellan källor använder sammansatta modellfunktioner.

När tabeller kommer från olika källor avgör lagringsläget för varje tabell hur relationen fungerar vid frågetillfället. Motorn löser varje sida oberoende av varandra och kopplar ihop resultaten.

Relationstyper

En-till-många-relationer

En-till-många är den vanligaste relationstypen i ett stjärnschema. Ett unikt värde i en dimensionstabell relaterar till många rader i en faktatabell. En produktrad i produktdimensionen matchar till exempel tusentals orderrader i tabellen Sales fact.

Konfigurera en-till-många-relationer med filterriktningen som flödar från dimensionen ("en"-sidan) till faktatabellen ("många"-sidan). Det här är standardmönstret för stjärnschemafilter.

Många-till-många-relationer

Många-till-många-relationer krävs när ingen av tabellerna har unika värden för relationskolumnen. Använd en brotabell för att lösa dessa samband. En brotabell ligger mellan två tabeller och innehåller unika kombinationer av nycklarna från varje sida.

Om en kund till exempel kan ha flera konton och ett konto kan tillhöra flera kunder, löser en Customer-Account bryggtabell relationen. Bryggtabellen har en-till-många-relationer till både kund- och kontotabellerna.

Filterriktning

I de flesta star-schemaimplementeringar använder du enkelriktad filtrering från dimension till fakta. Detta ger förutsägbar filterspridning och undviker tvetydighet i frågeresultat.

Dubbelriktad filtrering är ibland nödvändigt för många-till-många-relationer eller när dimensionstabeller måste filtreras efter värden i faktatabellen. Använd dubbelriktade filter sparsamt eftersom de kan försämra frågeprestanda och skapa oväntat filterbeteende i rapporter.

Referensintegritet

Inställningen Anta referensintegritet instruerar motorn att använda INNER JOIN i stället för LEFT OUTER JOIN när frågor ställs över en relation. I Direct Lake- och DirectQuery-lägen kan den här inställningen avsevärt förbättra prestandan eftersom det minskar antalet rader som motorn bearbetar.

Aktivera den här inställningen när du är säker på att varje sekundärnyckelvärde i faktatabellen har ett matchande värde i dimensionstabellen. Om referensintegriteten kränks försvinner rader med omatchade nycklar tyst från frågeresultatet.

Inaktiva relationer och USERELATIONSHIP

Endast en aktiv relation kan finnas mellan två tabeller i taget. När du behöver flera relationssökvägar (till exempel ett orderdatum och ett leveransdatum som båda relaterar till samma datumdimension) gör du en relation aktiv och de andra inaktiva.

USERELATIONSHIP Använd funktionen i DAX för att aktivera en inaktiv relation i en beräkning:

Shipped Amount =
CALCULATE(
    SUM(Sales[Amount]),
    USERELATIONSHIP(Sales[ShipDate], 'Date'[Date])
)

Det här mönstret håller modellen ren samtidigt som den stöder flera analytiska perspektiv på samma data.

Hantera snowflake-schema i semantiska modeller

Källdata anländer ofta i ett normaliserat snowflake-schema, där dimensionstabeller delas upp i flera relaterade tabeller. En produktdimension kan till exempel delas upp i tabellerna Produkt, Underkategori och Kategori, var och en länkad via sekundärnycklar.

I en semantisk modell har du två alternativ: platta ut snöflinga till ett stjärnschema eller bevara den normaliserade strukturen.

Platta ut till stjärnschema

Utplattande innebär att kombinera de normaliserade dimensionstabellerna i en enda avnormaliserad dimensionstabell. Tabellen Produkt innehåller kolumnerna Underkategori och Kategori direkt, vilket eliminerar de extra tabellerna och relationerna.

Platta ut när:

• Den kombinerade dimensionstabellen är fortfarande liten i förhållande till faktatabellen (vilket nästan alltid är fallet för dimensioner).
• Du vill ha enklare filtersökvägar från dimension till fakta. Varje filter går igenom en relation i stället för en kedja.
• AI-förbrukning är en prioritet. Färre tabeller och enklare relationer ger Copilot och dataagenter tydligare sökvägar till rätt data.

Normalisera dimensionstabeller vid dataförberedelser i lakehouses eller dataflöden innan data når den semantiska modellen. Använd Power Query sammanslagningar, SQL-kopplingar eller notebook-transformeringar för att kombinera de normaliserade tabellerna till en enda dimension.

Bevara snowflake-strukturen

I vissa fall är det vettigt att behålla den normaliserade strukturen:

• Dimensionhierarkin har flera nivåer, och en utplaning skulle skapa dussintals redundanta kolumner.
• Flera faktatabeller delar underdimensionstabeller (till exempel en delad kategoritabell som används av både försäljnings- och lagerfakta) och avnormalisering skulle skapa inkonsekventa kopior.
• Säkerhet på radnivå måste tillämpas på en viss nivå i hierarkin.

När du bevarar en snowflake-struktur konfigurerar du relationerna noggrant. Varje relation i kedjan måste använda enkelriktad filtrering från den yttersta tabellen mot faktatabellen så att filtren sprids korrekt. Ett filter för Kategori måste flöda genom Underkategori, sedan genom Produkt och till faktatabellen.

När du ska använda sammansatta modeller för scenarier mellan källor

Använd sammansatta modeller när ditt stjärnschema sträcker sig över flera Fabric datalager eller innehåller externa källor. Vanliga scenarier är:

• Faktatabeller i ett sjöhus med dimensionstabeller som underhålls i ett lager.
• Realtidsströmning av data från ett eventhouse kombinerat med historiska data i ett sjöhus.
• Referensdata från en extern källa (import) kombinerat med Fabric interna faktatabeller (Direct Lake).

I dessa scenarier konfigurerar du lagringsläget för varje tabell oberoende av varandra och kontrollerar att relationerna mellan källor fungerar acceptabelt på dina förväntade datavolymer.