Designstjerneskjema for semantiske modeller

Du valgte hvordan data flyter inn i din semantiske modell. Nå designer du stjerneskjemaet som organiserer det for klare, performante forespørsler. Et stjerneskjema kobler faktatabeller til dimensjonstabeller gjennom relasjoner, og skaper filterstiene som rapporter og AI-forbruk er avhengige av. Hvis du er kjent med å bygge stjerneskjemaer i Power BI Desktop, fokuserer denne enheten på de forholdsdesignbeslutningene som betyr noe etter hvert som modellene blir mer komplekse og skalerende.

Stjerneskjema i en semantisk modell

I et stjerneskjema lagrer faktatabeller målbare forretningshendelser (som salgstransaksjoner, ordrelinjer og nettbesøk), og dimensjonstabeller gir den beskrivende konteksten (som produktdetaljer, kundeinformasjon og datoattributter). Dimensjonstabeller filtrerer faktatabeller gjennom relasjoner, noe som lar brukere dele opp metrikker etter hvilken som helst beskrivende attributt.

I en Fabric-semantisk modell gir dette mønsteret ren filterpropagasjon for både rapporter og AI-forbruk. Når Copilot eller en dataagent genererer en naturlig språkspørring, gir et godt organisert stjerneskjema AI-en klare veier til riktig data. Tvetydige eller sirkulære relasjoner forvirrer både rapportforbrukere og AI-verktøy.

Hvordan lagringsmodus påvirker relasjoner

Relasjoner i en semantisk modell oppfører seg forskjellig avhengig av lagringsmodus. Å forstå disse forskjellene er avgjørende for å designe stjerneskjemaer som fungerer godt i ulike scenarioer.

Direkte innsjøforhold

I Direct Lake-modus leser motoren relasjoner direkte fra metadataene i Delta-tabellen. Forhold fungerer best når:

• Dimensjonsnøkkelkolonner har lav kardinalitet i forhold til faktatabellrader.
• Referanseintegritet opprettholdes i kildedataene. Når referanseintegritet holder, bruker motoren INNER joins i stedet for LEFT OUTER joins, noe som forbedrer spørringsytelsen.
• Kolonner brukt i relasjoner er indeksert i de underliggende Delta-tabellene.

Tverrkilde-relasjoner

Fabric semantiske modeller kan koble tabeller fra ulike datalagre. En faktatabell fra et lakehouse kan ha en sammenheng med en dimensjonstabell fra et lager, eller til en tabell som er aksessert gjennom et SQL-analyseendepunkt. Disse krysskildekoblingene bruker sammensatte modellmuligheter.

Når tabeller kommer fra forskjellige kilder, bestemmer lagringsmodusen for hver tabell hvordan relasjonen fungerer ved spørringstidspunktet. Motoren løser hver side uavhengig og kobler sammen resultatene.

Relasjonstyper

En-til-mange-relasjoner

En-til-mange er den vanligste relasjonstypen i et stjerneskjema. En unik verdi i en dimensjonstabell relaterer seg til mange rader i en faktatabell. For eksempel matcher én produktrad i produktdimensjonen tusenvis av ordrerader i salgsfaktatabellen.

Konfigurer én-til-mange-relasjoner med filterretningen som flyter fra dimensjonen ("en"-siden) til faktatabellen ("mange"-siden). Dette er det standard stjerneskjema-filtermønsteret.

Mange-til-mange-relasjoner

Mange-til-mange-relasjoner kreves når ingen av tabellene har unike verdier for relasjonskolonnen. Bruk en brotabell for å løse disse relasjonene. Et bridgebord står mellom to bord og inneholder unike kombinasjoner av tangentene fra hver side.

For eksempel, hvis en kunde kan ha flere kontoer og en konto kan tilhøre flere kunder, løser en Customer-Account bridge-tabell relasjonen. Brotabellen har én-til-mange-relasjoner til både kunde- og kontotabellene.

Filterretning

I de fleste stjerneskjema-implementasjoner brukes enkelretningsfiltrering fra dimensjon til fakta. Dette gir forutsigbar filterpropagasjon og unngår tvetydighet i søkeresultatene.

Toveis filtrering er noen ganger nødvendig for mange-til-mange-relasjoner eller når dimensjonstabeller må filtreres etter verdier i faktatabellen. Bruk toveis filtre med måte, fordi de kan forringe spørringsytelsen og skape uventet filteratferd i rapporter.

Referanseintegritet

Assume referential integrity-innstillingen forteller motoren å bruke INNER joins i stedet for LEFT OUTER joins når man spør på tvers av en relasjon. I Direct Lake- og DirectQuery-moduser kan denne innstillingen forbedre ytelsen betydelig fordi den reduserer antall rader motoren behandler.

Aktiver denne innstillingen når du er sikker på at hver fremmednøkkelverdi i faktatabellen har en tilsvarende verdi i dimensjonstabellen. Hvis referanseintegriteten brytes, forsvinner rader med ikke-matchede nøkler lydløst fra spørringsresultatene.

Inaktive relasjoner og USE-forhold

Kun én aktiv relasjon kan eksistere mellom to tabeller om gangen. Når du trenger flere relasjonsveier (som en ordredato og en forsendelsesdato, begge knyttet til samme datodimensjon), gjør ett forhold aktivt og de andre inaktive.

Bruk USERELATIONSHIP funksjonen i DAX for å aktivere en inaktiv relasjon i en beregning:

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

Dette mønsteret holder modellen ren samtidig som det støtter flere analytiske perspektiver på de samme dataene.

Håndter snøfnuggskjema i semantiske modeller

Kildedata kommer ofte i et normalisert snøfnuggskjema, hvor dimensjonstabeller deles opp i flere relaterte tabeller. For eksempel kan en produktdimensjon deles inn i produkt-, underkategori- og kategoritabeller, hver lenket gjennom fremmednøkler.

I en semantisk modell har du to alternativer: flate ut snøfnugget til et stjerneskjema, eller bevare den normaliserte strukturen.

Flate ut til stjerneskjema

Flattening betyr å kombinere de normaliserte dimensjonstabellene til en enkelt denormalisert dimensjonstabell. Produkttabellen vil inkludere kolonner for underkategori og kategori direkte, og eliminere de ekstra tabellene og relasjonene.

Flat ut når:

• Den kombinerte dimensjonstabellen er fortsatt liten i forhold til faktatabellen (som nesten alltid er tilfelle for dimensjoner).
• Du vil ha enklere filterstier fra dimensjon til fakta. Hvert filter går gjennom ett forhold i stedet for en kjede.
• AI-forbruk er en prioritet. Færre tabeller og enklere relasjoner gir Copilot og dataagenter klarere veier til riktige data.

Flat ut dimensjonstabeller under dataforberedelse i lakehouses eller dataflows, før dataene når den semantiske modellen. Bruk Power Query-sammenslåinger, SQL-joins eller notatboktransformasjoner for å kombinere de normaliserte tabellene til én dimensjon.

Bevar snøfnuggstrukturen

I noen tilfeller gir det mening å beholde den normaliserte strukturen:

• Dimensjonshierarkiet har flere nivåer, og flattening ville skape dusinvis av overflødige kolonner.
• Flere faktatabeller deler subdimensjonstabeller (som en delt kategoritabell brukt av både salgs- og lagerfakta), og denormalisering vil skape inkonsistente kopier.
• Sikkerhet på radnivå må anvendes på et spesifikt nivå i hierarkiet.

Når du bevarer en snøfnuggstruktur, må du konfigurere forholdene nøye. Hver relasjon i kjeden må bruke enkelretningsfiltrering fra den ytterste tabellen mot faktatabellen slik at filtrene propagerer korrekt. Et filter på Kategori må flyte gjennom Underkategori, deretter gjennom Produkt, og inn i faktatabellen.

Når man skal bruke komposittmodeller for tverrkildescenarier

Bruk komposittmodeller når stjerneskjemaet ditt dekker flere Fabric-datalagre eller inkluderer eksterne kilder. Vanlige scenarioer omfatter:

• Faktatabeller i et innsjøhus med dimensjonstabeller som oppbevares i et lager.
• Sanntids strømmingsdata fra et eventhus kombinert med historiske data i et innsjøhus.
• Referansedata fra en ekstern kilde (Import) kombinert med Fabric-native faktatabeller (Direct Lake).

I disse scenarioene konfigurerer du lagringsmodusen for hver tabell uavhengig og verifiserer at krysskilde-relasjoner fungerer akseptabelt på dine forventede datavolumer.