Stervormig schema ontwerpen voor semantische modellen

U hebt gekozen hoe gegevens in uw semantische model stromen. Ontwerp nu het stervormige schema dat het organiseert voor duidelijke, goed presterende query's. Een stervormig schema verbindt feitentabellen met dimensietabellen via relaties, waardoor de filterpaden worden gemaakt waarop rapporten en AI-verbruik afhankelijk zijn. Als u bekend bent met het bouwen van stervormige schema's in Power BI Desktop, richt deze les zich op de beslissingen voor het ontwerpen van relaties die van belang zijn naarmate modellen in complexiteit en schaal toenemen.

Stervormig schema in een semantisch model

In een stervormig schema bevatten feitentabellen meetbare zakelijke gebeurtenissen (zoals verkooptransacties, orderlijnen en webbezoeken) en dimensietabellen de beschrijvende context (zoals productdetails, klantgegevens en datumkenmerken). Dimensietabellen filteren feitentabellen via relaties, waardoor gebruikers metrische gegevens kunnen segmenteren op elk beschrijvend kenmerk.

In een semantisch model van Fabric biedt dit patroon heldere filterpropagatie voor zowel rapporten als AI-consumptie. Wanneer Copilot of een gegevensagent een query in natuurlijke taal genereert, biedt een goed georganiseerd sterschema de AI duidelijke paden naar de juiste gegevens. Dubbelzinnige of kringrelaties verwarren zowel rapportgebruikers als AI-hulpprogramma's.

Hoe de opslagmodus van invloed is op relaties

Relaties in een semantisch model gedragen zich anders, afhankelijk van de opslagmodus. Inzicht in deze verschillen is essentieel voor het ontwerpen van stervormige schema's die goed presteren in verschillende scenario's.

Direct Lake-relaties

In de Direct Lake-modus leest de engine relaties rechtstreeks uit de metagegevens van de Delta-tabel. Relaties presteren het beste wanneer:

• Dimensiesleutelkolommen hebben een lage kardinaliteit ten opzichte van feitentabelrijen.
• Referentiële integriteit blijft behouden in de brongegevens. Wanneer referentiële integriteit houdt, gebruikt de engine INNER joins in plaats van LEFT OUTER joins, wat de prestaties van de query verbetert.
• Kolommen die in relaties worden gebruikt, worden geïndexeerd in de onderliggende Delta-tabellen.

Relaties tussen meerdere bronnen

Fabric semantische modellen kunnen tabellen uit verschillende gegevensarchieven verbinden. Een feitentabel van een lakehouse kan een relatie hebben met een dimensietabel vanuit een magazijn of naar een tabel die toegankelijk is via een SQL-analyse-eindpunt. Deze verbindingen tussen bronnen maken gebruik van mogelijkheden voor samengestelde modellen.

Wanneer tabellen afkomstig zijn uit verschillende bronnen, bepaalt de opslagmodus voor elke tabel hoe de relatie op het moment van query's werkt. De motor verwerkt elke kant onafhankelijk en voegt de resultaten samen.

Relatietypen

Een-op-veel-relaties

Een-op-veel is het meest voorkomende relatietype in een stervormig schema. Eén unieke waarde in een dimensietabel heeft betrekking op veel rijen in een feitentabel. Eén productrij in de dimensie Product komt bijvoorbeeld overeen met duizenden orderrijen in de feitentabel Verkoop.

Configureer een-op-veel-relaties met de filterrichting die van de dimensie (de 'een'-zijde) naar de feitentabel loopt (de 'veel'-zijde). Dit is het standaardpatroon voor stervormige schemafilters.

Veel-op-veel-relaties

Veel-op-veel-relaties zijn vereist wanneer geen van beide tabellen unieke waarden heeft voor de relatiekolom. Gebruik een brugtabel om deze relaties op te lossen. Een brugtafel bevindt zich tussen twee tabellen en bevat unieke combinaties van de toetsen van elke kant.

Als een klant bijvoorbeeld meerdere accounts kan hebben en een account bij meerdere klanten kan horen, lost een Klant-Account brugtabel de relatie op. De brugtabel heeft een-op-veel-relaties met zowel de Klant- als de Accounttabellen.

Filterrichting

In de meeste stervormige schema-implementaties gebruikt u filteren in één richting van dimensie tot feit. Dit biedt voorspelbare filterdoorgifte en vermijdt dubbelzinnigheid in queryresultaten.

Bidirectionele filters zijn soms nodig voor veel-op-veel-relaties of wanneer dimensietabellen moeten worden gefilterd op waarden in de feitentabel. Gebruik bidirectionele filters spaarzaam omdat ze de prestaties van query's kunnen verminderen en onverwacht filtergedrag in rapporten kunnen creëren.

Referentiële integriteit

De instelling Referentiële integriteit aannemen geeft aan dat de engine INNER joins moet gebruiken in plaats van LEFT OUTER joins bij het uitvoeren van query's op een relatie. In de modi Direct Lake en DirectQuery kan deze instelling de prestaties aanzienlijk verbeteren, omdat het aantal rijen dat door de engineprocessen wordt verwerkt, wordt verminderd.

Schakel deze instelling in wanneer u er zeker van bent dat elke vreemde sleutelwaarde in de feitentabel een overeenkomende waarde in de dimensietabel heeft. Als de referentiële integriteit wordt geschonden, verdwijnen rijen met niet-overeenkomende sleutels ongemerkt uit de queryresultaten.

Inactieve relaties en USERELATIONSHIP

Er kan slechts één actieve relatie bestaan tussen twee tabellen tegelijk. Wanneer u meerdere relatiepaden nodig hebt (zoals een orderdatum en een verzenddatum die beide betrekking hebben op dezelfde datumdimensie), maakt u één relatie actief en de andere inactief.

Gebruik de USERELATIONSHIP functie in DAX om een inactieve relatie binnen een berekening te activeren:

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

Dit patroon houdt het model schoon en ondersteunt meerdere analytische perspectieven op dezelfde gegevens.

Snowflake-schema verwerken in semantische modellen

Brongegevens komen vaak binnen in een genormaliseerd snowflake-schema, waarbij dimensietabellen worden gesplitst in meerdere gerelateerde tabellen. Een productdimensie kan bijvoorbeeld worden onderverdeeld in de tabellen Product, Subcategorie en Categorie, die elk via vreemde sleutels zijn gekoppeld.

In een semantisch model hebt u twee opties: de sneeuwvlok plat maken in een stervormig schema of de genormaliseerde structuur behouden.

Platgemaakt in stervormig schema

Platmaken betekent dat de genormaliseerde dimensietabellen worden gecombineerd tot één gedenormaliseerde dimensietabel. De tabel Product bevat rechtstreeks subcategorie- en categoriekolommen, waardoor de extra tabellen en relaties worden geëlimineerd.

Afgevlakt wanneer:

• De gecombineerde dimensietabel is nog steeds klein ten opzichte van de feitentabel (wat vrijwel altijd het geval is voor dimensies).
• U wilt eenvoudigere filterpaden van dimensie tot feit. Elk filter doorloopt één relatie in plaats van een keten.
• AI-verbruik is een prioriteit. Minder tabellen en eenvoudigere relaties bieden Copilot en gegevensagenten duidelijkere paden naar de juiste gegevens.

Vlak dimensietabellen af tijdens gegevensvoorbereiding in lakehouses of gegevensstromen, voordat de gegevens het semantische model bereiken. Gebruik Power Query samenvoegingen, SQL-joins of notebooktransformaties om de genormaliseerde tabellen te combineren in één dimensie.

De sneeuwvlokstructuur behouden

In sommige gevallen is het logisch om de genormaliseerde structuur te behouden:

• De dimensiehiërarchie heeft meerdere niveaus en met platmaken worden tientallen redundante kolommen gemaakt.
• Meerdere feitentabellen delen subdimensionale tabellen (zoals een gedeelde categorietabel die wordt gebruikt door zowel verkoop- als inventarisgegevens), en denormalisatie zou inconsistente kopieën maken.
• Beveiliging op rijniveau moet worden toegepast op een specifiek niveau in de hiërarchie.

Wanneer u een sneeuwvlokstructuur behoudt, configureert u de relaties zorgvuldig. Elke relatie in de keten moet filteren in één richting van de buitenste tabel naar de feitentabel gebruiken, zodat filters correct worden doorgegeven. Een filter op Categorie moet via Subcategorie stromen, vervolgens via Product en naar de feitentabel.

Wanneer samengestelde modellen worden gebruikt voor scenario's met meerdere bronnen

Gebruik samengestelde modellen wanneer uw sterschema meerdere Fabric gegevensarchieven omvat of externe bronnen bevat. Veelvoorkomende scenario's zijn onder andere:

• Feitentabellen in een lakehouse met dimensietabellen die in een magazijn worden onderhouden.
• Realtime streaminggegevens uit een eventhouse gecombineerd met historische gegevens in een lakehouse.
• Referentiegegevens uit een externe bron (Import) gecombineerd met Fabric systeemeigen feitentabellen (Direct Lake).

In deze scenario's configureert u de opslagmodus voor elke tabel onafhankelijk en controleert u of cross-sourcerelaties acceptabel presteren op de verwachte gegevensvolumes.