![](https://www.theinformationlab.fr/wp-content/uploads/2020/06/Cuisson-des-pâtes-au-cookeo-1.jpg)
Les Nouveautés Tableau Desktop 2020.2 a signé l'arrivée d'une toute nouvelle façon de concevoir vos sources de données et de les utiliser.
Cela va grandement simplifier l'utilisation de plusieurs tables, réduire le recours aux LOD, éviter parfois du blending.
C'est prometteur n'est-ce pas ? Alors, en avant pour les détails de cette nouveauté !
Les relations, c'est quoi exactement ?
Tableau a ajouté un nouveau concept pour la construction de vos sources de données : les couches 'physique' et 'logique'.
![](https://help.tableau.com/current/online/en-us/Img/data_model_layers_sm.png)
La couche physique (en vert dans le schéma) c'est celle que vous utilisiez jusqu'à présent pour lier vos tables entre elles via des jointures (gauche, droite, interne ou externe). Elle est toujours présente, rien de nouveau de ce côté là.
'Par dessus' cette couche physique, Tableau a ajouté une couche logique qui vous permet de définir des relations entre plusieurs couches physiques qui sont donc constituées d'une ou plusieurs tables.
Là où vous construisiez plusieurs sources de données indépendantes, pour lesquelles vous usiez de la fusion de données (blending) ou pour gérer différents niveaux de granularité des mêmes données source, Tableau nous propose de ne construire qu'une seule source de données 'multi usage'.
Visuellement dans Tableau voici ce que ça donne :
![](https://content.theinformationlab.fr/images/2020/06/2020-06-11_18-27-11.gif)
Vous pouvez remarquer 3 choses :
- Graphiquement, on voit apparaître une liaison orange au moment de glisser la 2ème table. On appelle ça une 'nouille'. Elle définit la relation qui existe entre 2 tables logiques.
- Cette relation n'utilise pas de symbole de jointure entre les 2 tables.
- L'aperçu montre 2 tables de données distinctes et non pas le résultat d'une jointure. Les tables au niveau de la couche logique ne sont donc pas fusionnées .
En effet, Tableau est maintenant capable de définir automatiquement le bon type de jointure à appliquer dans vos visualisations, le niveau d'agrégation adéquat et peut même garder les valeurs nulles.
Si vous souhaitez conserver le même mode de fonctionnement, c'est bien heureusement toujours possible.
Pour cela, il suffit de double-cliquer sur une table de données et vous retrouvez l'interface que vous connaissez déjà pour définir les relations physiques entre les tables.
![](https://content.theinformationlab.fr/images/2020/06/2020-06-11_18-54-10.gif)
Il faut donc voir la couche logique comme un complément et non pas un remplacement.
Ce complément va vous apporter plus de flexibilité pour l'exploitation de vos sources de données tout en assurant la compatibilité ascendante de vos sources de données existantes.
En effet, Tableau est capable de migrer automatiquement vos sources de données dans son nouveau modèle.
Un source de données créées en 2020.1 (ou versions antérieure comme celle-ci)...
![](https://content.theinformationlab.fr/images/2020/06/image-7-1024x686.png)
... est transformée ainsi en 2020.2
![](https://content.theinformationlab.fr/images/2020/06/image-8-1024x643.png)
Il suffit alors de double cliquer sur la table logique 'Données migrées' pour retrouver nos tables physiques :
![](https://content.theinformationlab.fr/images/2020/06/image-9-1024x641.png)
Côté navigation, ça donne quoi sur une feuille ?
Les dimensions et les mesures sont maintenant rangées par table (ici Author1, Book... et les autres ).
![](https://content.theinformationlab.fr/images/2020/06/image-10-195x705.png)
Adieu le champ 'Nombre d'enregistrements' ! Il est remplacé, pour chaque membre de la relation, par un champ '<nom de la table> (total)'.
Grace à cela, Tableau est dorénavant capable d'afficher le nombre de lignes de chaque table indépendamment, ce qui était impossible jusque là.
![](https://content.theinformationlab.fr/images/2020/06/2020-06-11_19-01-24.gif)
Dans le panneau des données, en bas de la colonne, on retrouve dorénavant les champs générés automatiquement :
- Latitude / Longitude
- Nom de mesure / Valeurs de mesure
Dans ce même espace, viendront s'y ajouter toutes vos mesures créées via un champ calculé.
Exemple de mise en pratique
Pour illustrer la souplesse d'utilisation qu'apportent les Relations, imaginons que je cherche à exploiter les données de toutes les tables suivantes :
![](https://content.theinformationlab.fr/images/2020/06/image-5-1024x622.png)
Il nous faut donc construire :
- Une table logique 'Books' (en haut à gauche à gauche) qui réalise la jointure physique entre les table Book, Info & Award
- Sept tables logiques, dont une qui est en réalité une union de 4 tables physiques (Sales).
Pour construire la table logique 'Book', je m'appuie sur des jointures physiques...
![](https://content.theinformationlab.fr/images/2020/06/2020-06-15_17-25-06.gif)
... et pour le reste de ma source de données, j'utilise les 'nouilles' :
![](https://content.theinformationlab.fr/images/2020/06/2020-06-15_17-33-18-1.gif)
Si vous êtes familier des sources de données dans Tableau, vous n'aurez aucun problème pour la création de vos relations :)
Quelques exemples de mise en pratique
Essayons de répondre à ces 3 questions avec notre seule et unique source de données 'nouvelle mouture' :
- Quel livre à le plus grand nombre d'éditions ?
Rien de bien compliqué pour cette viz, il faut juste piocher la bonne dimension (Title) de la table logique 'Book' et la bonne mesure 'Edition (Total)' pour avoir le nombre d'édition de chaque livre.
![](https://content.theinformationlab.fr/images/2020/06/2020-06-15_17-44-57.gif)
- Quels livres n'ont enregistré aucune vente ?
Je prends la même dimension, mais ce coup-ci j'utilise 'Union (Total)' qui correspond aux données de 'Sales' :
![](https://content.theinformationlab.fr/images/2020/06/2020-06-15_17-49-04-1.gif)
Tableau a été capable de conserver les livres quand bien même ils n'ont aucune vente ! C'est vraiment un énorme avantage :)
- Quels auteurs n'ont aucun livre (oui, c'est bizarre à priori, mais pourquoi pas) ?
Même logique que précédemment, cette fois ci appliquée aux tables Author et Book.
![](https://content.theinformationlab.fr/images/2020/06/2020-06-15_17-54-38.gif)
Si j'avais voulu répondre à ces 3 questions avec le simple modèle physique que l'on connait, j'aurai pu.... mais en construisant 3 sources de données différentes !
La manière d'utiliser la source de données est dorénavant beaucoup plus intuitive, Tableau se chargeant de réaliser les bons agrégats, au bon niveau de détail, en fonction des dimensions et mesures que je lui demande. Nettement plus pratique non ?
Ma vie va-t-elle être vraiment plus simple ?
Je pense sincèrement que oui, et ce pour de nombreuses raisons :
- Le recours au blending (fusion de données) va être beaucoup moins fréquents. Il ne sera plus nécessaire de le redéfinir sur chaque feuille l'utilisant. La publication de source de données sur Tableau Server utilisées dans du blending était d'ailleurs plutôt laborieuse, si on peut s'en passer, c'est pas plus mal :)
A lire aussi : Pourquoi mes données se dupliquent-elles dans Tableau ? - L'utilisation des LODs sera moins systématique puisque Tableau, grâce aux relations, est capable d'agréger les données de différentes tables indépendamment. Bon, ne criez pas victoire trop vite, elles resteront tout de même nécessaires... mais sûrement moins nombreuses.
- Il ne sera plus nécessaire non plus de créer plusieurs sources de données pour gérer différents niveau d'agrégation de vos données.
- On ne va plus perdre les lignes qui ne 'matchent' pas dans notre jointure
- On devrait voir beaucoup moins souvent des tables de données qui 'explosent' en nombre de lignes pour cause de granularité différentes de données.
Il y a sûrement d'autres gains à attendre... j'en saurai un peu plus après quelques mois d'utilisation en conditions réelles chez nos clients.
Ça sera peut-être l'occasion de rédiger un nouvel article de blog pour partager un retour d'expérience.
Et sinon, il y a des limitations ?
La réponse est OUI.
- Les relations ne permettent pas (encore ?) d'utiliser des calculs de jointure pour lier vos tables de données. Il vous faudra utiliser une jointure classique en attendant.
- La sécurité à la ligne de données (aka 'row level security') n'est possible que dans la couche physque.
- Il n'est pas possible de modifier le format de nombre du champ '<nom de la table> (Total)'.
![](https://content.theinformationlab.fr/images/2020/06/image-1.png)
Il est, pour le moment, nécessaire de créer un champ calculé que vous pourrez formater à votre guise
![](https://content.theinformationlab.fr/images/2020/06/image-2.png)
- Les cubes, SAP HANA (avec un attribut OLAP), JSON et Google Analytics sont limités à une seule table logique dans Tableau 2020.2
- Les LODs ne sont pas gérées pour quelques sources de données exotiques. La liste détaillée est dispo dans la doc de Tableau
A part cela, je n'ai rien remarqué. Si vous trouvez quelque chose d'autres, faites m'en part dans les commentaires :)
Pour aller plus loin
Mon collègue Tim Ngwena de The Information Lab UK a réalisé une super vidéo d'une heure qui vous montre tout ça en image (et en anglais) et dont je me suis largement inspiré pour cet article.
La doc Tableau, comme toujours, est très complète et très didactique.
Vous trouverez plus d'info sur la différence entre couche physique et couche logique sur cette page (en français) et les instructions pour créer vos relations.
Sur ce, je m'en vais de ce pas continuer à m'amuser avec mon plat de nouilles !