Aide de Tableau Desktop et de la création Web

Un modèle avec relations multi-faits (relations entre plusieurs tables de faits) est un modèle de données qui vous permet d’ajouter des tables non liées dans une seule source de données, puis d’utiliser des champs liés lors de l’analyse visuelle pour assembler les tables en fonction du contexte. Contrairement à la fusion, les données existent au sein d’une seule source de données : les concepts de sources de données principales et secondaires ne s’appliquent pas et aucune donnée n’est supprimée des jointures de gauche. Contrairement à un modèle de données à table unique, plusieurs tables de base conservent leur propre contexte concernant les tables partagées entre elles. Un modèle de données avec relations multi-faits vous offre davantage d’options pour effectuer une analyse multi-faits dans Tableau.

Imaginez que vous souhaitiez analyser l’évolution conjointe de la météo et des ventes de glaces. La météo et les ventes de glaces ont lieu à des heures et en des lieux précis, mais il n’y a pas de lien direct entre les ventes de glaces et la météo. Il s’agit de données indépendantes qui se rapportent toutes deux aux concepts partagés de date et de lieu.

Cette question se prête à la création d’un modèle avec relations multi-faits. Les tables Ice Cream Sales et Weather peuvent chacune être ajoutées en tant que tables de base et liées aux tables Date et Location, qui sont des tables partagées.

Un modèle de données à plusieurs tables de base, avec deux tables non liées (Ice Cream Sales et Weather) et deux tables partagées (Date et Location). Il existe une table intermédiaire, Parlor Info, entre Date et Location.

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

L’analyse implique souvent de rassembler des tables de données qui n’ont même pas de relation directe les unes avec les autres, mais qui se rapportent toutes deux aux mêmes informations communes (telles que la date ou le lieu). Un modèle avec relations multi-faits prend en charge un couplage sémantique lâche en introduisant le concept de degré de relation et la possibilité de créer un modèle de données avec plusieurs tables de base non liées.

• Le couplage sémantique est un terme utilisé pour décrire dans quelle mesure les données sont étroitement combinées. Une jointure ou une union est un couplage sémantique étroit. Les deux processus regroupent plusieurs tables dans une nouvelle table physique qui agit alors comme une seule table. Une relation est un couplage plus lâche entre les tables. Elle relie les tables entre elles logiquement, en conservant leur statut distinct en tant que tables séparées. Encore plus loin dans le spectre du couplage sémantique se trouve la fusion des données, où les résultats de sources de données distinctes sont visuellement combinés en fonction d’éléments partagés entre les deux. Un modèle avec relations multi-faits est plus proche de l’extrémité de fusion du spectre, mais au sein d’une seule source de données plutôt qu’entre plusieurs sources de données.

Un modèle avec relations multi-faits (un modèle de données comportant plusieurs tables de base) autorise des tables non liées dans le modèle tant qu’il s’y trouve également des tables partagées. Au cours de l’analyse, les champs d’une table partagée assemblent des tables de données, qui étaient autrement non liées, sur la base de dimensions qu’elles ont en commun (par exemple, se produisant au même endroit ou au même moment). Tous les avantages des relations sont conservés, y compris la granularité de chaque table ou le niveau de détail natif.

Comme pour un modèle de données de table de base unique, Tableau détermine le meilleur type de jointure à utiliser en arrière-plan en fonction de la structure de la visualisation. Mais dans un modèle avec relations multi-faits, les options de jointure sont étendues de manière à inclure des jointures externes et croisées et gérer ainsi différents niveaux de relation. Pour plus d’informations, voir À propos des modèles de données avec relations multi-faits.

D’où provient ce nom ?

Les relations multi-faits tirent leur nom de l’analyse multi-faits. 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, les faits désignent des mesures ou métriques, qui sont des champs de données numériques capturant des faits sur les données : les mesures de Tableau. Les tables de dimensions contiennent des attributs sur ces faits.

Les schémas basés sur des tables de faits sont souvent structurés en forme d’étoile ou de flocon de neige, selon la manière dont les tables de dimensions sont organisées. Lorsqu’une analyse doit être effectuée sur des tables de faits, on parle alors d’analyse multi-faits. L’analyse est effectué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. Nous avons donc nommé cette suite de fonctionnalités « relations multi-faits ».

Dans quels cas utiliser des modèles de données avec relations multi-faits

Si vos données sont constituées de tables qui sont toutes liées les unes aux autres, vous pouvez vous en tenir à des sources de données de table de base unique construites avec des relations. Un modèle avec relations multi-faits est nécessaire lorsque vos données couvrent différents concepts, soit sous la forme de plusieurs tables de faits, soit sous la forme de différents contextes non liés.

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 de table de base unique, chaque table est liée et il n’est pas nécessaire de prendre en compte les degrés de relation. N’utilisez des relations multi-faits que lorsque cette structure de modèle de données est requise.

Analyse multi-faits

L’analyse multi-faits est un cas d’utilisation principal pour les relations multi-faits dans Tableau. Dans cet exemple, Fact A et Fact B partagent une table Date.

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

Autres scénarios

Cependant, les modèles de données avec relations multi-faits ne sont pas uniquement destinés à l’analyse multi-faits. Tableau n’exige pas de définition stricte des tables de faits ou de dimensions. N’importe quelle table peut être une table de base (même si elle doit répondre aux caractéristiques des tables de base). Certains scénarios indiquant une source de données à plusieurs tables de base peuvent être utiles : 

• Parcours des étapes, tels que des tables de base pour les candidatures, les relevés de notes et les événements des anciens élèves pour une table partagée Étudiants.
• Contextes différents pour les mêmes événements, comme des tables de base pour les événements de rendez-vous médicaux et la facturation, avec des tables partagées pour définir le contexte des médecins ou des patients.
• Différents domaines pouvant être corrélés, tels que des scénarios qui seraient auparavant mieux gérés avec la fusion des données, par exemple la corrélation entre ventes de glaces et la météo via les tables partagées de date et de lieu.

Identifier les tables de base

Dans un modèle de relations multi-faits, la directionnalité est importante. Autrement dit, les tables qui constituent les tables de base sur le côté gauche du modèle et les tables partagées en aval ont un impact sur la manière dont les relations sont évaluées pour renvoyer les résultats analytiques.

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

La manière correcte de créer le modèle de données dans Tableau consiste à utiliser les factures et les rendez-vous comme tables de base, et les médecins et les patients comme tables partagées (et non avec 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

Conceptuellement, un patient (ou un médecin) est l’entité qui relie 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 pas aussi utile. Il se peut que votre analyse montre de nombreuses mesures et ambiguïtés au niveau de la table. Si vous vous retrouvez avec des champs liés de manière ambiguë auxquels vous ne vous attendiez pas, réévaluez les tables que vous utilisez comme tables de base et voyez s’il faut inverser votre modèle de données.

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

Si vous effectuez une analyse multi-faits, 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 le strict respect des caractéristiques des tables de faits et de dimensions. Cependant, 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, s’il existe des tables intermédiaires entre une table de base et une table partagée, vous pouvez échanger celle qui est la table de base sans modifier fondamentalement le modèle de données. (Par exemple les tables Parlor Info et Ice Cream Sales dans le premier exemple.) Ce qui compte, c’est de voir quelles tables se trouvent en amont des tables partagées et quelles tables sont partagées.

Essayer plutôt une table de base supplémentaire

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

• Si vous essayez de créer une source de données avec un cycle, la table en aval doit plutôt être une autre table de base.
• Si vous disposez d’une série de tables liées par 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.
  • Cette fonction est particulièrement utile car plusieurs clauses de relation doivent toutes être vraies (logiquement, un opérateur AND) pour que les tables soient liées pour ces enregistrements.
  • Si, à la place, vous souhaitez analyser des enregistrements où l’un d’eux peut être vrai à un moment (un opérateur contextuel OR), vous obtenez cette flexibilité en configurant un modèle de données avec des tables de dimensions partagées.
• Si vous utilisez une combinaison mais souhaitez disposer d’une combinaison équivalente sans sources de données principales et secondaires, 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.