Concevoir un schéma en étoile pour les modèles sémantiques

Vous avez choisi la façon dont les données circulent dans votre modèle sémantique. Concevez maintenant le schéma en étoile qui l’organise pour des requêtes claires et performantes. Un schéma en étoile relie les tables de faits aux tables de dimensions par des relations, créant ainsi les chemins de filtrage dont dépendent les rapports et l'utilisation de l'IA. Si vous êtes familiarisé avec la création d'un schéma en étoile dans Power BI Desktop, cette unité se concentre sur les décisions de conception de relation qui importent à mesure que les modèles augmentent en complexité et en échelle.

Schéma en étoile dans un modèle sémantique

Dans un schéma en étoile, les tables de faits stockent des événements métier mesurables (tels que les transactions commerciales, les lignes de commande et les visites web), et les tables de dimension fournissent le contexte descriptif (tels que les détails du produit, les informations client et les attributs de date). Les tables de dimension filtrent les tables de faits par le biais de relations, ce qui permet aux utilisateurs de segmenter les métriques par tout attribut descriptif.

Dans un modèle sémantique Fabric, ce modèle fournit une propagation claire des filtres pour les rapports et l'utilisation par l’IA. Quand Copilot ou un agent de données génère une requête en langage naturel, un schéma en étoile bien organisé offre des voies claires à l'IA vers les données appropriées. Les relations ambiguës ou circulaires confondent les consommateurs de rapports et les outils IA.

Comment le mode de stockage affecte les relations

Les relations dans un modèle sémantique se comportent différemment en fonction du mode de stockage. Il est essentiel de comprendre ces différences pour concevoir un schéma en étoile qui fonctionne correctement dans différents scénarios.

Relations avec "Direct Lake"

En mode Direct Lake, le moteur lit les relations directement à partir des métadonnées de la table Delta. Les relations sont optimales quand :

• Les colonnes clés de dimension ont une faible cardinalité par rapport aux lignes de table de faits.
• L’intégrité référentielle est conservée dans les données sources. Lorsque l’intégrité référentielle est conservée, le moteur utilise des jointures INNER au lieu de jointures LEFT OUTER, ce qui améliore les performances des requêtes.
• Les colonnes utilisées dans les relations sont indexées dans les tables Delta sous-jacentes.

Relations entre sources

Les modèles sémantiques de Fabric peuvent connecter des tables de différents magasins de données. Une table de faits d'un lakehouse peut avoir une relation avec une table de dimension d'un entrepôt ou avec une table accessible via un point de terminaison d'analyse SQL. Ces connexions entre sources utilisent des fonctionnalités de modèle composite.

Lorsque les tables proviennent de différentes sources, le mode de stockage de chaque table détermine le fonctionnement de la relation au moment de la requête. Le moteur résout chaque côté indépendamment et joint les résultats.

Types de relations

Relations un-à-plusieurs

Un-à-plusieurs est le type de relation le plus courant dans un schéma en étoile. Une valeur unique dans une table de dimension est liée à de nombreuses lignes d’une table de faits. Par exemple, une ligne de produit dans la dimension Product correspond à des milliers de lignes de commande dans la table de faits Sales.

Configurez des relations un-à-plusieurs avec la direction du filtre qui passe de la dimension (côté « un ») à la table de faits (côté « plusieurs »). Il s’agit du modèle de filtre de schéma en étoile standard.

Relations plusieurs-à-plusieurs

Les relations plusieurs-à-plusieurs sont requises lorsque aucune table n’a de valeurs uniques pour la colonne de relation. Utilisez une table de pont pour résoudre ces relations. Une table de pont se trouve entre deux tables et contient des combinaisons uniques des clés de chaque côté.

Par exemple, si un client peut avoir plusieurs comptes et qu’un compte peut appartenir à plusieurs clients, une table de pont Customer-Account résout la relation. La table de pont a des relations un-à-plusieurs avec les tables Customer et Account.

Direction du filtre

Dans la plupart des implémentations de schéma en étoile, utilisez un filtrage dans une seule direction de la dimension vers le fait. Cela fournit une propagation de filtre prévisible et évite l’ambiguïté dans les résultats de la requête.

Le filtrage bidirectionnel est parfois nécessaire pour les relations plusieurs-à-plusieurs ou lorsque les tables de dimension doivent être filtrées par des valeurs dans la table de faits. Utilisez des filtres bidirectionnels avec parcimonie, car ils peuvent dégrader les performances des requêtes et créer un comportement de filtre inattendu dans les rapports.

Intégrité référentielle

Le paramètre d’intégrité référentielle Assume indique au moteur d’utiliser des jointures INNER plutôt que des jointures LEFT OUTER lors de l’interrogation sur une relation. Dans les modes Direct Lake et DirectQuery, ce paramètre peut améliorer considérablement les performances, car il réduit le nombre de lignes que le moteur traite.

Activez ce paramètre lorsque vous êtes certain que chaque valeur de clé étrangère dans la table de faits a une valeur correspondante dans la table de dimension. Si l’intégrité référentielle est violée, les lignes avec des clés sans correspondance disparaissent silencieusement des résultats de la requête.

Relations inactives et USERELATIONSHIP

Une seule relation active peut exister entre deux tables à la fois. Lorsque vous avez besoin de plusieurs chemins de relation (par exemple, une date de commande et une date d’expédition relatives à la même dimension Date), rendez une relation active et les autres inactives.

Utilisez la USERELATIONSHIP fonction dans DAX pour activer une relation inactive dans un calcul :

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

Ce modèle permet de nettoyer le modèle tout en prenant en charge plusieurs perspectives analytiques sur les mêmes données.

Gérer le schéma snowflake dans les modèles sémantiques

Les données sources arrivent souvent dans un schéma en flocon normalisé, où les tables de dimension sont divisées en plusieurs tables associées. Par exemple, une dimension Product peut être séparée en tables Product, Subcategory et Category, chacune liée par le biais de clés étrangères.

Dans un modèle sémantique, vous avez deux options : aplatir le flocon en un schéma en étoile ou préserver la structure normalisée.

Aplatir en schéma en étoile

L’aplatissement signifie combiner les tables de dimension normalisées en une table de dimension dénormalisée unique. La table Product inclut de manière directe les colonnes Sous-catégorie et Catégorie, supprimant les tables et relations supplémentaires.

Aplatir quand :

• La table de dimensions combinées est toujours petite par rapport à la table de faits (qui est presque toujours le cas pour les dimensions).
• Vous souhaitez simplifier les chemins de filtre entre la dimension et le fait. Chaque filtre transite par une relation au lieu d’une chaîne.
• La consommation d’IA est une priorité. Moins de tables et de relations plus simples donnent Copilot et les agents de données des chemins plus clairs aux données appropriées.

Aplatir les tables de dimension pendant la préparation des données dans lakehouses ou dataflows, avant que les données atteignent le modèle sémantique. Utilisez les fusions de Power Query, les jointures SQL ou les transformations de carnets de notes pour combiner les tables normalisées en une dimension unique.

Conserver la structure de flocons de neige

Dans certains cas, la conservation de la structure normalisée est logique :

• La hiérarchie de dimensions a plusieurs niveaux et l’aplatissement créerait des dizaines de colonnes redondantes.
• Plusieurs tables de faits partagent des tables de sous-dimension (par exemple, une table catégorie partagée utilisée par les faits Sales et Inventory), et la dénormalisation créerait des copies incohérentes.
• La sécurité au niveau des lignes doit être appliquée à un niveau spécifique dans la hiérarchie.

Lorsque vous conservez une structure flocon de neige, configurez soigneusement les relations. Chaque relation de la chaîne doit utiliser le filtrage unidirectionnel de la table la plus externe vers la table de faits afin que les filtres se propagent correctement. Un filtre sur Catégorie doit transiter par Sous-catégorie, puis par Produit, et enfin dans la table de faits.

Quand utiliser des modèles composites pour les scénarios inter-sources

Utilisez des modèles composites lorsque votre schéma en étoile s’étend sur plusieurs magasins de données Fabric ou inclut des sources externes. Les scénarios courants sont les suivants :

• Tables de faits dans un lakehouse avec des tables de dimension conservées dans un entrepôt.
• Données en streaming temps réel provenant d’un centre d'événements, combinées à des données historiques dans un lakehouse.
• Données de référence provenant d'une source externe (Importation) combinées à des tables de faits natives à Fabric (Direct Lake).

Dans ces scénarios, configurez le mode de stockage pour chaque table indépendamment et vérifiez que les relations entre sources s’exécutent de manière acceptable sur vos volumes de données attendus.