Designstjerneskema for semantiske modeller

Du valgte, hvordan data flyder ind i din semantiske model. Design nu stjerneskemaet, der organiserer det, for klare, performante forespørgsler. Et stjerneskema forbinder faktatabeller med dimensionstabeller gennem relationer og skaber de filterstier, som rapporter og AI-forbrug afhænger af. Hvis du er bekendt med at bygge stjerneskemaer i Power BI Desktop, fokuserer denne enhed på de relationsdesignbeslutninger, der betyder noget, efterhånden som modellerne vokser i kompleksitet og skalerer.

Stjerneskema i en semantisk model

I et stjerneskema gemmer faktatabeller målbare forretningsbegivenheder (såsom salgstransaktioner, ordrelinjer og webbesøg), og dimensionstabeller giver den beskrivende kontekst (såsom produktdetaljer, kundeinformation og datoattributter). Dimensionstabeller filtrerer faktatabeller gennem relationer, hvilket gør det muligt for brugere at opdele metrikker efter enhver beskrivende attribut.

I en Fabric-semantisk model giver dette mønster ren filterudbredelse for både rapporter og AI-forbrug. Når Copilot eller en dataagent genererer en forespørgsel på naturligt sprog, giver et velorganiseret stjerneskema AI'en klare veje til de rigtige data. Tvetydige eller cirkulære relationer forvirrer både rapportforbrugere og AI-værktøjer.

Hvordan lagringstilstand påvirker relationer

Relationer i en semantisk model opfører sig forskelligt afhængigt af lagringstilstanden. Forståelse af disse forskelle er afgørende for at designe stjerneskemaer, der fungerer godt i forskellige scenarier.

Direkte sø-relationer

I Direct Lake-tilstand læser motoren relationer direkte fra metadata i Delta-tabellen. Forhold fungerer bedst, når:

• Dimensionsnøglekolonner har lav kardinalitet i forhold til faktiske tabellrækker.
• Referenceintegritet opretholdes i kildedataene. Når referentiel integritet gælder, bruger motoren INNER joins i stedet for LEFT OUTER joins, hvilket forbedrer forespørgselsydelsen.
• Kolonner, der bruges i relationer, er indekseret i de underliggende Delta-tabeller.

Tværkilde-relationer

Fabric semantiske modeller kan forbinde tabeller fra forskellige datalagre. En faktatabel fra et lakehouse kan have en relation til en dimensionstabel fra et lager eller til en tabel, der tilgås via et SQL-analyse-endpoint. Disse krydskildeforbindelser bruger sammensatte modelfunktioner.

Når tabeller kommer fra forskellige kilder, bestemmer lagringstilstanden for hver tabel, hvordan relationen fungerer ved forespørgselstidspunktet. Motoren løser hver side uafhængigt og sammensætter resultaterne.

Relationstyper

En til mange-relationer

Én-til-mange er den mest almindelige forholdstype i et stjerneskema. En unik værdi i en dimensionstabel relaterer sig til mange rækker i en faktatabel. For eksempel matcher én produktrække i produktdimensionen tusindvis af ordrerækker i salgsfaktatabellen.

Konfigurer én-til-mange-relationer med filterretningen, der flyder fra dimensionen ("den eneste" side) til faktatabellen ("den mange" side). Dette er det standard stjerneskema-filtermønster.

Mange til mange-relationer

Mange-til-mange relationer er nødvendige, når ingen af tabellerne har unikke værdier for relationskolonnen. Brug en brotabel til at løse disse relationer. Et bridgebord står mellem to borde og indeholder unikke kombinationer af tangenterne fra hver side.

For eksempel, hvis en kunde kan have flere konti, og en konto kan tilhøre flere kunder, løser en Customer-Account bridge-tabel relationen. Bridgetabellen har én-til-mange relationer til både kunde- og kontotabellerne.

Filterretning

I de fleste stjerneskema-implementeringer anvendes enkeltretningsfiltrering fra dimension til faktum. Dette giver forudsigelig filterudbredelse og undgår tvetydighed i forespørgselsresultater.

Tovejsfiltrering er nogle gange nødvendig for mange-til-mange-relationer eller når dimensionstabeller skal filtreres efter værdier i faktatabellen. Brug tovejsfiltre sparsomt, da de kan forringe forespørgselsydelsen og skabe uventet filteradfærd i rapporter.

Referentieel integritet

Indstillingen Antag referenceintegritet fortæller motoren at bruge INNER joins i stedet for LEFT OUTER joins, når der forespørgs på tværs af en relation. I Direct Lake- og DirectQuery-tilstande kan denne indstilling markant forbedre ydeevnen, fordi den reducerer antallet af rækker, motoren behandler.

Aktivér denne indstilling, når du er sikker på, at hver fremmednøgleværdi i faktatabellen har en matchende værdi i dimensionstabellen. Hvis referenceintegriteten brydes, forsvinder rækker med umatchede nøgler lydløst fra forespørgselsresultaterne.

Inaktive relationer og USE-forhold

Der kan kun eksistere én aktiv relation mellem to tabeller ad gangen. Når du har brug for flere forholdsveje (såsom en ordredato og en forsendelsesdato, der begge relaterer sig til samme datodimension), skal du gøre én relation aktiv og de andre inaktive.

Brug USERELATIONSHIP funktionen i DAX til at aktivere en inaktiv relation i en beregning:

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

Dette mønster holder modellen ren, samtidig med at det understøtter flere analytiske perspektiver på de samme data.

Håndter snefnugskema i semantiske modeller

Kildedata ankommer ofte i et normaliseret snowflake-skema, hvor dimensionstabeller er opdelt i flere relaterede tabeller. For eksempel kan en produktdimension opdeles i produkt-, underkategori- og kategoritabeller, som hver især er forbundet via fremmednøgler.

I en semantisk model har du to muligheder: flade snefnugget ud til et stjerneskema eller bevare den normaliserede struktur.

Flad ud til stjerneskema

Fladning betyder, at de normaliserede dimensionstabeller kombineres til en enkelt denormaliseret dimensionstabel. Produkttabellen ville inkludere kolonner for Underkategori og Kategori direkte, hvilket eliminerer de ekstra tabeller og relationer.

Flade ud, når:

• Den kombinerede dimensionstabel er stadig lille i forhold til faktatabellen (hvilket næsten altid er tilfældet for dimensioner).
• Du ønsker enklere filterstier fra dimension til fakta. Hvert filter bevæger sig gennem én relation i stedet for en kæde.
• AI-forbrug er en prioritet. Færre tabeller og enklere relationer giver Copilot og dataagenter klarere veje til de rigtige data.

Flad dimensionstabeller ud under dataforberedelse i lakehouses eller dataflows, før dataene når den semantiske model. Brug Power Query-sammenfletninger, SQL-joins eller notesbogstransformationer til at kombinere de normaliserede tabeller til én dimension.

Bevar snefnugsstrukturen

I nogle tilfælde giver det mening at bevare den normaliserede struktur:

• Dimensionshierarkiet har flere niveauer, og udfladning ville skabe dusinvis af overflødige kolonner.
• Flere faktatabeller deler subdimensiontabeller (såsom en delt kategoritabel, der bruges af både salgs- og lagerfakta), og denormalisering ville skabe inkonsistente kopier.
• Sikkerhed på rækkeniveau skal anvendes på et specifikt niveau i hierarkiet.

Når du bevarer en snefnugstruktur, skal du konfigurere relationerne omhyggeligt. Hver relation i kæden skal bruge enkeltretningsfiltrering fra den yderste tabel mod faktatabellen, så filtrene udbredes korrekt. Et filter på Kategori skal flyde gennem Underkategori, derefter gennem Produkt og ind i faktatabellen.

Hvornår skal man bruge sammensatte modeller til cross-source scenarier

Brug sammensatte modeller, når dit stjerneskema spænder over flere Fabric-datalagre eller inkluderer eksterne kilder. Almindelige scenarier omfatter:

• Faktatabeller i et søhus med dimensionstabeller, der opbevares i et lager.
• Realtids streamingdata fra et eventhouse kombineret med historiske data i et søhus.
• Referencedata fra en ekstern kilde (Import) kombineret med Fabric-native faktatabeller (Direct Lake).

I disse scenarier skal du konfigurere lagringstilstanden for hver tabel uafhængigt og verificere, at krydskilde-relationer fungerer acceptabelt på dine forventede datamængder.