Relations du tableau de bord
Aperçu
Cette fonctionnalité est en aperçu public.
Les relations de tableau de bord vous permettent de modéliser la logique de jointure entre vos datasets dans les tableaux de bord AI/BI, afin que vous puissiez créer des modèles de données multi-faits et multi-grains et des mesures réutilisables entre les datasets sans pré-joindre les données en SQL. Vous modélisez la relation une seule fois, puis l'utilisez dans chaque visualisation du tableau de bord.
Quel problème les relations résolvent-elles ?
Avant les relations, un auteur qui voulait joindre des métriques de plusieurs tables de faits (par exemple, orders.revenue et shipments.cost), regroupées par région, devait pré-joindre les deux tables de faits à la dimension de région et agréger soigneusement pour éviter le fan-out, la duplication de lignes qui se produit lorsqu'une jointure multiplie les lignes au lieu de les faire correspondre un à un. Cette logique de jointure résidait dans SQL, dupliquée dans chaque dataset qui en avait besoin.
Grâce aux relations, l'auteur définit la jointure une seule fois. Le moteur de query décide quoi joindre à l'exécution, en fonction des champs de la visualisation. Il n'y a pas d'expansion, de double comptage ou de doublon SQL.
Comment fonctionnent les relations de tableau de bord ?
Vous définissez une relation entre deux datasets de tableau de bord en choisissant un champ de jointure dans chacun et en définissant la cardinalité, telle que plusieurs-à-un d'une table de faits vers une dimension. Les datasets liés forment alors un graphe traversable, et le moteur de query résout les jointures dont chaque visualisation a besoin au moment de la query, de sorte que les filtres et les mesures circulent entre les datasets connectés sans pré-joindre les données en SQL.
Un modèle peut couvrir plusieurs tables de faits qui se rejoignent à des dimensions partagées, et une dimension peut se ramifier en flocon de neige vers d'autres dimensions. La Figure 1 montre un modèle avec trois tables de faits jointes via quatre dimensions partagées, dont deux en flocon de neige un niveau plus loin.
Figure 1re. Un modèle de relation de tableau de bord couvre plusieurs tables de faits jointes via des dimensions partagées, avec certaines dimensions organisées en flocon un niveau plus loin. Même une dimension en flocon de neige comme Géographie reste accessible depuis chaque table de faits connectée.
Pour créer des relations et des mesures cross-dataset, consultez Créer des relations de tableau de bord.
Quels modèles de données sont pris en charge ?
Les relations de tableau de bord effectuent des jointures au moment de la query entre les tables en fonction de la cardinalité spécifiée de la relation. Vous pouvez joindre des tables de faits via une dimension conforme (une dimension partagée par plusieurs tables de faits), mais pas directement entre elles par des jointures plusieurs-à-plusieurs.
Le tableau suivant décrit les modèles pris en charge et non pris en charge, et comment résoudre les modèles non pris en charge lorsqu'ils se présentent :
Modèle | Pris en charge | À quoi cela ressemble | Résolution |
|---|---|---|---|
Snowflake schema | ✅ Oui | Une table de faits joint une chaîne de dimensions, par exemple | Aucun nécessaire |
Dimensions partagées | ✅ Oui | Deux tables de faits rejoignent la même dimension conforme ; par exemple, | Aucun nécessaire |
Chemin de jointure ambiguë | ❌ Non | Une dimension accessible depuis une table de faits par plus d'un chemin, par exemple | Donner un alias à un itinéraire, par exemple |
Relation cyclique. | ❌ Non | Une boucle fermée de jointures sans chemin univoque, par exemple | Aliassez une table dans la boucle pour rompre le cycle. |
Comment résoudre les chemins de jointure ambigus et cycliques ?
L'aliassage fonctionne car chaque copie aliasée d'une table est un nœud distinct dans le graphe, de sorte que chaque chemin de jointure mène à une seule cible. Les deux modèles non pris en charge créent chacun un type de chemin en double différent, et l'aliassage le supprime.
Un chemin de jointure ambigu se produit lorsqu'une table de faits peut atteindre la même dimension par plus d'une voie. Par exemple, Orders atteint Country à la fois via Regions et via Customers, donc une requête qui regroupe les commandes par pays a deux jointures candidates et aucun moyen de choisir entre elles. Pour le résoudre, aliassez la dimension une fois par route, comme Country (region) et Country (customer). Chaque route pointe alors vers sa propre copie, de sorte qu'un champ comme le pays du client se résout en un seul chemin.
Figure 2. L'alias de la dimension partagée donne à chaque itinéraire sa propre cible, de sorte que le chemin de jointure est non ambigu.
Une relation cyclique est une boucle fermée de jointures. Si Orders rejoint Regions, Regions rejoint Customers, et Customers rejoint Orders, la boucle ne donne pas au moteur de query de lieu non ambigu pour start ou stop, de sorte qu'il ne peut pas résoudre les jointures. Pour le résoudre, créez un alias pour une table dans la boucle afin de la transformer en un chemin unique que le moteur de query peut suivre de bout en bout. Dans la figure 3, A, B et C représentent trois tables quelconques dans une telle boucle, et A′ est l'alias qui la rompt.
Figure 3. L'aliasing d'une table dans la boucle rompt le cycle en un chemin unique et traversable.
Comment fonctionnent les mesures inter-datasets ?
Lorsque les tables de faits partagent une dimension conforme, vous pouvez définir une mesure une seule fois au niveau du modèle et la faire puiser dans plus d'une table de faits. Le moteur de query agrège chaque table de faits indépendamment et combine les résultats au niveau de la dimension partagée, de sorte que la mesure reste correcte, quels que soient les champs ajoutés par un spectateur à la visualisation.
Par exemple, avec Orders, Shipments et Returns joints par le biais de dimensions partagées, vous pourriez définir des mesures inter-datasets comme celles-ci au niveau du modèle :
Net Revenue = SUM(Orders.revenue) - SUM(Returns.refund)
Fulfillment Rate = SUM(Shipments.units) / SUM(Orders.units)
Return Rate = SUM(Returns.units) / SUM(Orders.units)
Chacune de ces tables s'appuie sur deux tables de faits à la fois, sans expansion ni double-comptage. La figure 1 présente les dimensions partagées sur lesquelles cela repose, où trois tables de faits se rejoignent à quatre dimensions conformes.
L'importance de l'ordre des champs
Le premier champ que vous ajoutez définit la racine, la table par rapport à laquelle tous les autres champs sont résolus. À partir de cette racine, trois types de champs se comportent différemment :
Type de champ | Joignable à partir d'une table non racine ? |
|---|---|
Champ (dimension) | Oui, à travers n'importe quelle chaîne plusieurs à un, quel que soit le nombre de sauts |
Mesure (agrégat) | Oui, elle s'agrège indépendamment, puis se joint à la dimension partagée |
Colonne native (non agrégée) | Non, à moins que cette table de faits ne soit la racine |
Ainsi, en partant de orders revenue, customer region et shipments cost sont tous deux disponibles, mais pas ship mode: une colonne brute sur Shipments, inaccessible car Shipments n’est pas la racine. start from ship mode instead, and the root flips, so now Shipments' own columns are available too.
Comment les relations de tableau de bord se comparent-elles aux vues de métriques ?
Les deux peuvent modéliser le même graphe de jointure, mais ils résolvent des problèmes différents :
- Les vues métriques sont à granularité fixe. Vous les interrogez directement avec SQL, et ils conviennent bien aux schémas en étoile et en flocon de neige.
- Les relations de tableau de bord sont de granularité dynamique. Ils vous permettent de combiner des champs et des mesures de n'importe quelle table à travers le graphe sémantique, ce qui les rend plus adaptés à la modélisation sur plusieurs tables de faits.
Un graphe de relations de tableau de bord peut inclure des vues métriques en tant que nœuds, avec des relations comme arêtes qui les connectent. La vue métrique gère la logique à grain unique, et les relations gèrent la couche multi-facteurs supérieure.
Aspect | Relations de tableau de bord | Vues métriques |
|---|---|---|
Portée | Un seul tableau de bord. | Unity Catalog, partagé entre les tableaux de bord, les agents Genie et d'autres outils. |
Idéal pour | Prototypage, analyse spécifique aux tableaux de bord, itération rapide | Métriques qui doivent être gouvernées et réutilisées de manière cohérente. |
Crée un objet UC | Non | Oui |
Si vous start avec une relation de tableau de bord et avez ensuite besoin que le même modèle soit gouverné et partagé, vous pouvez le promouvoir en vue de métriques. Consultez les vues de métriques Unity Catalog et Exporter vers une vue de métriques Unity Catalog. Pour une comparaison plus large de toutes les options de modélisation des données disponibles dans les tableaux de bord AI/BI, consultez Choisir la bonne approche.
Quelle est la différence entre le grain fixe et le grain dynamique ?
La granularité affecte les champs que vous pouvez sélectionner et le niveau de détail auquel ils sont exprimés. Une vue de métrique verrouille une table à une granularité fixe, telle qu'au niveau du client, tandis que les relations sont dynamiques, basées sur les champs utilisés dans le tableau de bord, tels qu'au niveau du client, de la commande ou de l'expédition.
La différence réside dans la racine. Une vue métrique intègre la racine dans la dimension au moment de la définition : Customer est toujours la racine, de sorte que chaque query regroupe par Customer, et le sélecteur de champ n'offre toujours que Customer comme champ de regroupement, même s'il extrait toujours des mesures de toute table de faits connectée. Les relations de tableau de bord choisissent plutôt la racine par query : Orders ou Shipments peut servir de racine, selon le champ que vous ajoutez en premier, de sorte que le sélecteur de champs vous permet de regrouper par n’importe quelle table connectée plutôt que par la dimension seule.
Figure 4. La racine est fixe dans une vue de métriques, mais choisie par query dans une relation de tableau de bord.
Malgré cette différence, les deux partagent la même limite sous-jacente : vous ne pouvez toujours pas regrouper la mesure d'une table de faits par la colonne d'une autre table de faits directement, car les deux ne se rejoignent qu'au niveau de la dimension partagée.
Pourquoi les relations de tableau de bord sont-elles limitées à un tableau de bord ?
Le support des relations dans Unity Catalog est en cours.