Aide de Tableau Desktop et de la création Web

Un modèle de relations multi-faits est un modèle de données qui vous permet d’ajouter des tables non connexes dans une source de données unique, puis d’utiliser des champs connexes lors de l’analyse visuelle pour assembler les tables en fonction du contexte. Contrairement à la fusion, les données existent dans une source de données unique : les concepts de sources de données primaires et secondaires ne s’appliquent pas, et chaque donnée est prise en compte dans les jointures gauche. Contrairement à un modèle de données avec une table unique, les tables de base multiples conservent leur propre contexte en ce qui concerne les tables qu’elles se partagent. Un modèle de données de relations multi-faits vous offre plus d’options pour une analyse multi-facteurs dans Tableau.

Imaginons que vous voulez analyser comment la météo et les ventes de crèmes glacées évoluent ensemble. La météo et les ventes de crèmes glacées se produisent toutes deux à des moments et à des lieux précis, mais il n’y a aucun lien direct entre les ventes de crèmes glacées et la météo. Il s’agit de données non connexes qui se rapportent toutes les deux aux concepts partagés de date et de lieu.

Cette question se prête à la création d’un modèle de relations multi-faits. Ventes de crèmes glacées et Météo peuvent chacune être ajoutées comme une table de base et associées à la Date et au Lieu, qui sont des tables partagées.

Modèle de données avec des tables de base multiples, comportant deux tables non connexes (Ventes de crèmes glacées et Météo) et deux tables partagées (Date et Lieu). Il existe une table intermédiaire, Parlor Info, entre Ventes de crèmes glacées et Lieu.

Pourquoi avons-nous développé la capacité de modéliser des tables non connexes?

L’analyse consiste souvent à réunir des tables de données qui n’ont même pas de relation directe les unes avec les autres, mais qui se rapportent toutes les deux à la même information commune, (telle que la date ou le lieu). Un modèle de relations multi-faits prend en charge le couplage sémantique lâche en introduisant le concept de degrés de relation ainsi que la possibilité de créer un modèle de données avec plusieurs tables de base non connexes.

• Le couplage sémantique est un terme utilisé pour décrire à quel point les données sont étroitement associées. Une jointure ou une union est un couplage sémantique étroit; elles rassemblent plusieurs tables en une nouvelle table physique qui agit alors comme une table unique. Une relation est un couplage plus lâche entre les tables qui les unit logiquement, tout en préservant leur statut distinct de tables séparées. À l’autre bout du spectre du couplage sémantique se trouve la fusion des données, qui permet de combiner visuellement des résultats provenant de sources de données distinctes en fonction des éléments qu’ils se partagent. Un modèle de relations multi-faits est plus proche du côté fusion du spectre, mais dans une source de données unique plutôt que dans plusieurs sources de données.

Un modèle de relations multi-faits (modèle de données avec plusieurs tables de base) autorise l’utilisation de tables non connexes dans le modèle, à condition que ce modèle utilise également des tables partagées. Au cours de l’analyse, les champs d’une table partagée « assemblent » conjointement des tables de données non connexes en fonction des dimensions partagées qu’elles ont en commun (comme le fait de se produire au même endroit ou au même moment). Les avantages des relations sont tous conservés, y compris la granularité ou le niveau de détail natif de chaque table.

Comme dans le cas d’un modèle de données avec une table de base unique, Tableau détermine en arrière-plan le meilleur type de jointure à utiliser en fonction de la structure de la visualisation. Mais dans un modèle de relations multi-faits, les options de jointure sont développées afin d’inclure des jointures externes et des jointures croisées et de prendre en charge plusieurs niveaux de relations. Pour plus d’informations, consultez À propos des modèles de données avec relations multi-faits.

L’origine du nom

Les relations multi-faits tirent leur nom de l’analyse multi-facteurs. Dans un modèle d’entrepôt de données, les données sont stockées dans une table de faits centrale entourée de tables de dimensions. Dans ce contexte, fait désigne des mesures ou des métriques, qui sont des champs numériques de données qui capturent des faits relatifs aux données : les mesures de Tableau. Les tables de dimensions contiennent des attributs relatifs à ces faits.

Les schémas basés sur des tables de faits sont souvent structurés en étoile ou en flocon, selon la manière dont les tables de dimensions sont organisées. Lorsque plusieurs tables de faits doivent être analysées, on parle d’analyse multi-facteurs. L’analyse est réalisée dans le contexte des tables de dimensions communes, appelées dimensions partagées ou dimensions conformes. Dans Tableau, vous créez ces modèles de données à l’aide de relations. C’est pourquoi nous avons baptisé cet ensemble de fonctionnalités des « relations multi-faits ».

Quand utiliser les modèles de données avec des relations multi-faits

Si vos données sont constituées de tables qui sont toutes associées les unes aux autres, vous pouvez continuer d’utiliser les sources de données ayant une table de base unique qui ont été créées avec des relations. Un modèle de relation multi-faits est nécessaire lorsque vos données couvrent plusieurs concepts, soit sous la forme de tables de faits multiples, soit dans des contextes différents et non connexes.

Dans la mesure du possible, créez vos sources de données avec une seule table de base. Dans un modèle de données avec une table de base unique, chaque table est connexe et il est inutile de prendre en compte les degrés de relation. N’utilisez les relations multi-faits que si cette structure de modèle de données est nécessaire.

Analyse multi-facteurs

L’analyse multi-facteurs est un cas d’utilisation essentiel des relations multi-faits dans Tableau. Dans cet exemple, Fait A et Fait B partagent une table Date.

Pour modéliser cela dans Tableau, les tables de faits deviennent des tables de base et des relations entrantes multiples sont établies pour leur table de dimension partagée.

Autres scénarios

Toutefois, les modèles de données avec des relations multi-faits ne visent pas seulement l’analyse multi-facteurs. Tableau ne requiert pas une définition stricte des tables de faits ou des tables de dimensions. Toute table peut être une table de base (même si elle devrait remplir les caractéristiques des tables de base). Voici quelques scénarios selon lesquels une source de données avec des tables de base multiples pourrait être utile : 

• Cheminement par étapes, par exemple des tables de base pour les demandes, les relevés de notes et les événements d’anciens élèves pour une table partagée Élèves.
• Contextes différents pour des événements similaires, par exemple des tables de base pour les rendez-vous chez le médecin et les factures, et des tables partagées pour donner une idée de la situation aux médecins ou aux patients.
• Différents domaines pouvant être mis en corrélation, par exemple des scénarios qui auraient été mieux gérés grâce à la fusion des données, comme la mise en corrélation des ventes de crèmes glacées et de la météo dans les tables partagées de date et de lieu.

Pour en savoir plus sur l’utilité des relations multi-faits, consultez ce billet de blogue Tableau : Quand et comment utiliser les relations multi-faits dans Tableau.

Identifier les tables de base

Dans un modèle de relations multi-faits, l’orientation dans l’espace est importante. Autrement dit, les tables qui constituent les tables de base du côté gauche du modèle et les tables partagées en aval ont un impact sur la manière d’évaluer les relations pour générer les résultats analytiques.

Imaginez un nœud papillon conceptuel composé de factures, de rendez-vous, de médecins et de patients :

La bonne façon de créer le modèle de données dans Tableau est d’utiliser les factures et les rendez-vous comme tables de base, et les médecins et les patients comme tables partagées (plutôt que les médecins et les patients comme tables de base).

Correct : Factures et Rendez-vous comme tables de base	Incorrect : Médecins et Patients comme tables de base

Théoriquement, un patient (ou un médecin) est l’entité qui assemble l’événement d’un rendez-vous et l’événement d’une facture.

Si votre modèle de données est inversé (par exemple avec Médecins et Patients comme tables de base au lieu de Rendez-vous et Factures), le comportement d’assemblage de la jointure externe ne sera d’aucune utilité. Votre analyse peut afficher de nombreuses mesures et ambiguïtés à l’échelle de la table. Si vous vous retrouvez avec des champs associés de manière ambiguë auxquels vous ne vous attendiez pas, réévaluez les tables que vous utilisez comme tables de base et voyez si votre modèle de données doit être inversé.

Caractéristiques des tables de base et des tables partagées

Si vous effectuez une analyse multi-facteurs, les tables de faits deviennent les tables de base et toutes les tables de dimensions partagées sont des tables partagées. Tableau n’exige pas de respecter scrupuleusement les caractéristiques des tables de faits et des tables de dimensions. Toutefois, certains attributs peuvent vous aider à identifier les tables qui doivent être des tables de base et celles qui doivent être des tables partagées.

Notez que si des tables intermédiaires existent entre une table de base et une table partagée, vous pouvez permuter la table de base sans modifier fondamentalement le modèle de données. (Comme Parlor Info et Ice Cream Sales dans le premier exemple.) Ce qui importe, c’est de savoir quelles tables sont en amont des tables partagées et quelles tables sont partagées.

Essayer plutôt une table de base supplémentaire

Plusieurs scénarios semblent indiquer que vous devez créer un modèle de relations multi-faits avec plusieurs tables de base plutôt qu’une source de données avec une table de base unique :

• Si vous essayez de créer une source de données avec un cycle, la table en aval doit être une autre table de base.
• Si vous avez une série de tables connexes dans les mêmes ensembles de clauses de relation (telles que la date et le lieu), ces dimensions doivent être extraites et transformées en tables partagées.
  • Ceci s’avère très utile, car les clauses de relation multiples doivent toutes être vraies (une logique ET) pour que les tables soient connexes pour ces enregistrements.
  • Si, au contraire, vous souhaitez analyser des enregistrements dont l’un peut être vrai à un moment donné (un OU contextuel), cette flexibilité est assurée en configurant un modèle de données avec des tables de dimensions partagées.
• Si vous utilisez une combinaison mais souhaitez obtenir une combinaison équivalente sans aucune source de données primaire et secondaire, créez un modèle de données qui combine les sources de données de la combinaison avec leurs champs de liaison dans une ou plusieurs tables partagées.