Dimensions partagées dans la sémantique Tableau

Tableaux associés et non associés

Un autre concept clé dans les tableaux partagés est la différence entre les tableaux associés et non associés.

Deux tableaux sont considérés comme associés lorsqu'ils sont directement connectés par une relation définie. Les requêtes entre les tableaux associés fonctionnent normalement : le système utilise le chemin défini pour les joindre.

Si deux tableaux ne sont absolument pas associés, ce qui signifie qu'ils n'ont aucune connexion directe ou partagée, le système ne peut pas déterminer comment combiner leurs données, et la requête échoue.

Dans certains cas, les tableaux sont connectés uniquement via une dimension partagée. Si vous interrogez des champs des deux tableaux de fait sans inclure de champ du tableau partagé, et que les champs ne sont pas agrégés, le système effectue une jointure croisée. Cela signifie que chaque ligne d'un tableau de fait est combinée à chaque ligne de l'autre, car aucune clé partagée ne permet de les aligner.

Par exemple, si Ventes et Marketing sont tous les deux liés à un tableau Produits partagé, et que vous interrogez [Ventes].[Quantité des ventes] et [Marketing].[Dépenses] sans [Produits].[Nom du produit], le système combine simplement toutes les lignes Ventes avec toutes les lignes Marketing.

Pour éviter cela, la requête doit inclure un champ du tableau partagé, par exemple Produit ou Date, qui agit en tant que clé de jointure et fournit un axe partagé pour regrouper et agréger les valeurs entre les deux faits.

Les dimensions partagées permettent d'analyser les données de tableaux qui seraient autrement isolés, mais uniquement lorsqu'ils sont correctement utilisés dans la requête.

Arborescences de faits et leur structure

Une arborescence de faits est un groupe de tableaux appartenant au même domaine d'activité et connectés entre eux. Il inclut généralement un ou plusieurs tableaux de fait avec des tableaux de dimension.

Cette structure n'est pas seulement un concept de modélisation, c'est quelque chose que le système élabore automatiquement lorsque vous exécutez une requête. Les arborescences de faits permettent à la couche sémantique d'organiser les tableaux en interne afin d'évaluer correctement les dimensions partagées.

Dans l'exemple de diagramme ci-dessus, Marketing est un tableau de fait connecté à des tableaux partagés Produits et Dates. Cela forme son arborescence de fait. Sales est un autre tableau de faits qui se connecte aux mêmes dimensions partagées, formant une arborescence de faits séparée. Cette structure permet au système de comprendre le fonctionnement indépendant de chaque arbre, tout en permettant l'analyse inter-arbres à travers des dimensions partagées.

Les arborescences doivent rester sans cycle. Les cycles introduisent une ambiguïté : si le système peut atteindre le même tableau par plusieurs chemins, il peut ne pas savoir lequel suivre ou comment appliquer correctement les filtres et les agrégations. Pour cette raison, la création d'une relation qui introduit un cycle, par exemple connecter Marketing directement à Sous-catégorie (qui est déjà accessible via Produit), n'est pas autorisée.

Comment les dimensions partagées affectent les requêtes

Les dimensions partagées aident non seulement à structurer votre modèle sémantique, mais elles régissent également le comportement des requêtes à l'exécution, garantissant des résultats précis et une logique cohérente.

Supposons que vous analysez la relation entre les dépenses marketing et la quantité vendue. Ces deux mesures proviennent de tableaux de faits différents : Marketing et Ventes. En soi, ils ne peuvent pas être alignés de façon significative, car il n'y a pas de contexte commun pour les regrouper. Si vous faites simplement glisser les deux champs vers une requête sans utiliser de référence partagée, le système ne peut pas mapper les lignes et peut renvoyer des résultats trompeurs, voire échouer.

Cependant, lorsque vous importez deux dimensions partagées, par exemple Produit et Date, la situation change. Lorsque ces éléments sont en place, vous pouvez demander : « Pour chaque produit et chaque mois, combien avons-nous dépensé en marketing et combien d’unités avons-nous vendues ? »

Les ventes et le marketing sont connectés aux produits et aux dates (tableaux partagés). Par conséquent, le système peut désormais aligner correctement les deux mesures -- par produit, par mois -- et renvoyer des résultats significatifs et agrégés :

Comportement de filtrage

Les filtres sont appliqués de manière à éviter de modifier les données de tableaux non associés.

• Lorsque vous appliquez un filtre à un champ spécifique à un fait, par exemple Type de marketing, il filtre uniquement ce tableau de fait, pas un autre fait ou une dimension partagée.
• Lorsque vous appliquez un filtre à une dimension partagée, par exemple Nom du produit ou Date, il s'applique à tous les tableaux de faits qui lui sont connectés.

Ce comportement empêche les filtres de retirer les enregistrements non associés. Par exemple, si vous sélectionnez En ligne dans le filtre Type de marketing, seules les Dépenses marketing sont mises à jour -- Quantité des ventes reste inchangée.

Les arborescences doivent rester sans cycle. Les cycles introduisent une ambiguïté : si le système peut atteindre le même tableau par plusieurs chemins, il peut ne pas savoir lequel suivre ou comment appliquer correctement les filtres et les agrégations. Pour cette raison, la création d'une relation qui introduit un cycle, par exemple connecter Marketing directement à Sous-catégorie (qui est déjà accessible via Produit), n'est pas autorisée.

Champs calculés et arborescence des faits

Les champs calculés doivent respecter les limites de l'arborescence des faits. Si vous créez un champ calculé au niveau de la ligne, par exemple :

SI [Support].[Priorité] <= 1 ALORS « Élevée » AUTRE « Faible »

-- ce champ est valide tant qu'il reste dans la même arborescence de faits (Support dans le cas présent). Vous pouvez l'utiliser pour analyser des modèles ou filtrer l'activité liée au support par rapport à des dimensions telles que Client ou Produit (si ces dimensions sont partagées), et tout se comportera normalement.

Cependant, si vous essayez de créer un champ calculé qui couvre plusieurs tableaux de fait, par exemple :

[Inventaire].[Quantité] + [Ventes].[Quantité des ventes]

-- la plate-forme va générer une erreur. Il tente de combiner les données au niveau de la ligne de deux arborescences de faits différentes, et le système ne peut pas résoudre un niveau de détail commun pour cette expression. Chaque arborescence de faits a sa propre granularité indépendante et son propre contexte de filtrage.

Pour obtenir des calculs de faits croisés valides, vous devez agréger chaque fait indépendamment, puis combiner ces agrégats au niveau de la vue :

SUM([Inventaire].[Quantité]) + SUM([Ventes].[Quantité des ventes])

Cette expression est autorisée, car les deux mesures sont agrégées avant d'être combinées, et l'agrégation est étendue au niveau du produit ou à n'importe quelle dimension de la vue.

Limitations des dimensions partagées et des arborescences de faits

• Les tableaux de fait doivent rester déconnectés les uns des autres. Ils ne peuvent pas être joints directement. Toute connexion entre eux doit se faire uniquement via des tableaux de dimensions partagés.
• Les champs calculés au niveau de la ligne, qu'il s'agisse de dimensions ou de mesures, doivent être entièrement inclus dans une seule arborescence de faits.
• Vous ne pouvez pas connecter un tableau partagé à un autre tableau partagé, puis à un tableau de fait. En d'autres termes, un seul tableau partagé peut exister dans le chemin de connexion entre un tableau de fait et ses dimensions. Par exemple, si Produits est un tableau partagé connecté à Dates (un autre tableau partagé), puis que les deux se connectent à Ventes, cette structure n'est pas prise en charge.
• Lorsque vous filtrez des champs de plusieurs arborescences de faits dans la même requête, ces filtres doivent être combinés en utilisant une condition AND, pas OR.