Tableaux dans LuckyTemplates : types et distinctions

Je souhaite passer un peu de temps aujourd'hui à parler des tables dans LuckyTemplates. Nous rencontrons tout le temps des tables à chaque problème, mais nous ne passons pas vraiment beaucoup de temps à y penser seuls. Vous pouvez regarder la vidéo complète de ce tutoriel au bas de ce blog.

Il y a eu récemment un message du membre de LuckyTemplates, Ashton, qui pose toujours de bonnes questions qui suscitent la réflexion. Sa question m'a fait penser à un modèle que je vois assez régulièrement et que je souhaite aborder dans ce didacticiel.

Ce n'était pas une erreur qu'il a commise, mais c'est une erreur courante. Je vois souvent des gens dire qu'ils ont des problèmes avec une table virtuelle, par exemple, alors que ce n'est pas une table virtuelle en premier lieu.

Il existe une réelle distinction entre les types de tables dans LuckyTemplates.

L'analogie que je donnerais serait si quelqu'un disait : « Hé, j'ai récemment adopté un chien et j'ai des problèmes avec le chien et je me demande si vous pouvez m'aider » et ce n'est pas un chien, mais un loup. Ce sont tous les deux des chiens, mais il y a quelques distinctions assez importantes dont vous voulez tenir compte.

Ainsi, même s'ils appartiennent tous à la même famille, tout comme les tables de LuckyTemplates, ce sont des distinctions importantes qui affectent réellement la solution et la manière dont vous utilisez ces tables. Et donc, ce que je voulais faire, c'était revoir la question d'Ashton, puis approfondir un peu les différences entre les tables que vous trouvez dans LuckyTemplates et montrer comment cela influence la façon dont vous les gérez.

La question était assez simple, mais il y a un peu plus qu'il n'y paraît initialement. Il disposait d'un ensemble de données simple indiquant simplement les clients, le type de fruit qu'ils ont acheté, la quantité, puis juste un numéro d'index.

Il voulait avoir une trancheuse avec une capacité de sélection multiple afin que si vous choisissiez dire orange, cela afficherait tous les clients qui ont acheté des oranges, mais cela montrerait également ce qu'ils ont acheté d'autre.

Donc, si nous désactivons cette sélection (orange), nous pouvons voir l'ensemble de données complet. Nous pouvons également voir que ce sont les deux clients (Joe et Mary) qui ont acheté des oranges, mais ils ont également chacun fait un achat supplémentaire.

Et donc, la première chose que nous savons, c'est que la trancheuse de fruits doit être une table de trancheuse déconnectée. S'il s'agissait d'une trancheuse ordinaire, vous toucheriez l'orange et cela supprimerait essentiellement tout sauf l'orange dans la table. Nous savons aussi, parce que c'est dynamique, que nous avons un problème de table virtuelle.

Alors approfondissons un peu cela, mais avant de le faire, examinons les différents types de tables que nous trouvons dans LuckyTemplates.

Table des matières

• Trois types de tableaux dans LuckyTemplates
• Solution de mesure DAX pour une table virtuelle
• Conclusion

Trois types de tableaux dans LuckyTemplates

Il existe trois types de tableaux que l'on retrouve régulièrement. Le premier est le plus courant et c'est une table physique, et ce sont vraiment vos données primaires. Chaque fois que vous obtenez des données ou que vous entrez des données directement via cette option ou dans Power Query , vous effectuez une référence ou une duplication, ou vous chargez des données via une requête vide, comme une table de dates, c'est une table physique.

Une table physique n'est pas entièrement dynamique, mais elle possède toutes ces autres caractéristiques qui augmentent la taille du fichier car il s'agit de données physiques. Il est accessible dans Power Query. En règle générale, les relations dans le modèle de données sont construites via des relations physiques. Ils ne sont pas obligés de l'être, mais ils le sont généralement. Ils sont utilisés pour les données principales et vous les visualisez via la vue des données ou via Power Query.

Une table physique n'est pas entièrement dynamique, mais elle possède toutes ces autres caractéristiques qui augmentent la taille du fichier car il s'agit de données physiques. Il est accessible dans Power Query. En règle générale, les relations dans le modèle de données sont construites via des relations physiques. Ils ne sont pas obligés de l'être, mais ils le sont généralement. Ils sont utilisés pour les données principales et vous les visualisez via la vue des données ou via Power Query.

Celle qui est souvent confondue avec la table virtuelle est cette table calculée ou ce que nous pouvons également appeler une table d'expression DAX. Cela présente une analogie directe avec les colonnes calculées créées via des expressions DAX . Cela se fait via l'onglet Modélisation et l'option Nouvelle table, puis vous entrez l'expression DAX.

Celle qui est souvent confondue avec la table virtuelle est cette table calculée ou ce que nous pouvons également appeler une table d'expression DAX. Cela présente une analogie directe avec les colonnes calculées créées via des expressions DAX. Cela se fait via l'onglet Modélisation et l'option Nouvelle table, puis vous entrez l'expression DAX.

Comme vous pouvez le voir dans le tableau de comparaison ci-dessous, la table calculée a un profil assez différent de la table physique ou de la table virtuelle. Ce n'est pas complètement dynamique.

Il doit être actualisé afin de récupérer les nouvelles informations. Cela augmente la taille physique du fichier. Contrairement à une table physique simple, elle n'est pas accessible dans Power Query. Tout comme une colonne calculée ne s'affiche pas dans Power Query, une table calculée ne s'affiche pas non plus. Mais il possède les autres aspects d'une table physique.

En règle générale, les tables calculées sont utilisées pour prendre en charge les tables et utilisées plus couramment pour le débogage. Il existe maintenant de meilleurs outils comme DAX Studio et Tabular Editor, il n'est donc pas utilisé aussi fréquemment pour cela. Vous affichez ce tableau via la vue des données.

Et franchement, comme les colonnes calculées, c'est généralement quelque chose à éviter. Il existe de meilleures façons de faire les choses que par le biais de tableaux calculés.

Et puis l'analogie avec les mesures sont les vraies tables virtuelles . Ceux-ci sont créés dans le contexte des mesures via le code de mesure DAX. Ils sont entièrement dynamiques, contrairement aux deux autres types de tables. Ils n'augmentent pas la taille du fichier car ils sont à la demande. Tout comme les mesures, les tables virtuelles sont calculées à la demande en mémoire et sont toutes utilisées au cours des contextes pour lesquels elles sont nécessaires.

Ils ne sont pas accessibles dans Power Query. Vous ne pouvez pas mettre une relation physique sur ceux-ci. Si vous les reliez dans votre modèle de données, vous le faites en utilisant des relations virtuelles, le plus souvent avec .

Les tables virtuelles sont utilisées pour les calculs intermédiaires dans les mesures car une mesure ne peut pas renvoyer une valeur de table et doit renvoyer une valeur scalaire. Vous les utilisez donc généralement comme calcul intermédiaire sur lequel vous générez vos échelles, qui sont le produit résultant de votre mesure.

Vous pouvez visualiser ces tables dans des outils tels que DAX Studio, Tabular Editor ou New Table, ce qui est encore une fois probablement la méthode la moins souhaitable car elle encombre votre modèle de données avec un tas de tables supplémentaires, à moins que vous ne le supprimiez.

Solution de mesure DAX pour une table virtuelle

Pour en revenir à la question d'Ashton, en regardant le tableau, on peut dire que c'est dynamique. Nous pouvons également faire des choix multiples et cela change complètement à la volée. Et donc à cause de cela, nous savons que c'est une table virtuelle car les deux autres (tables physiques et calculées) ne sont pas entièrement dynamiques. Nous savons également qu'il s'agit d'une table déconnectée, comme je l'ai mentionné au début.

J'ai utilisé le concept du canard en caoutchouc pour résoudre ce problème. Dans un tutoriel précédent, j'ai parlé de ce concept d'esquive en caoutchouc, qui développe une solution conceptuelle au problème avant de commencer à creuser dans le DAX spécifique.

Et donc, pour la solution de canard en caoutchouc ici, ce que j'ai fait a été essentiellement de mettre en place cette table de trancheuse déconnectée. Ensuite, j'ai récolté la valeur de ces trancheuses. Ensuite, je suis venu avec une table virtuelle qui a filtré les clients par ceux qui avaient acheté les sélections dans la table déconnectée.

Ensuite, j'ai pris cette liste de clients et filtré notre ensemble de données d'origine par ces clients pour trouver les clients et les achats effectués par ces clients, en plus de la valeur du slicer.

Examinons la mesure spécifique pour voir comment cela s'est déroulé et certaines des considérations que vous avez en travaillant avec des tables virtuelles.

La première chose était de développer deux mesures de récolte pour nos valeurs. Le premier étant la valeur du slicer déconnecté.

Comme nous avions la multi-sélection dans l'exigence, cela signifiait que nous ne pouvions pas simplement utiliser . Donc, ce que j'ai fait, c'est utiliser la fonction pour capturer potentiellement une ou plusieurs sélections dans ce trancheur déconnecté. Pour les clients, puisque nous allons avoir un client sur chaque ligne que nous évaluons, nous pouvons utiliser SELECTEDVALUE.

La prochaine chose que j'ai faite était cette variable de table virtuelle ( VAR Buyers ) qui commence par . Ensuite, il s'agit de filtrer les clients selon qu'ils ont fait ou non un achat de fruits qui était dans nos valeurs du trancheur déconnecté.

Nous pouvons vérifier cela en faisant une requête DAX. Nous pouvons le faire dans DAX Studio ou dans Tabular Editor. Prenons donc notre mesure de table virtuelle ici, copions-la dans Tabular Editor. Nous veillerons à ce que cela nous donne les valeurs que nous nous attendons à voir, à savoir Joe et Mary.

Les requêtes DAX renvoient toujours des tables et commencent toujours par EVALUATE, nous ajoutons donc EVALUATE ici. Cependant, nous n'obtenons rien dans le résultat. Cela est dû au fait que la variable de récolte de fruits de déconnexion sélectionnée ( SelDisconnFruit ) n'a aucune connaissance du segment. C'est hors contexte.

Donc, la façon de tester cela consiste en quelque sorte à définir artificiellement cette valeur de trancheuse. Nous allons remplacer SelDisconnFruit par une petite table ici. Tapez Orange (la valeur de ce segment) entre parenthèses sinueuses . Et maintenant, nous obtenons le résultat ici, qui est Joe et Mary. Avec cela, la table virtuelle fonctionne exactement comme nous le pensions.

Nous pouvons donc revenir maintenant à notre expression de mesure. L'un des problèmes avec les tables virtuelles est qu'il est facile de créer des tables virtuelles dans une mesure . Mais vous ne pouvez pas renvoyer une table virtuelle comme résultat d'une mesure . Nous devons donc retourner un scalaire, mais qui capture l'aspect pertinent de la table virtuelle.

Donc ici, nous avons la table virtuelle qui nous indique quels clients ont acheté les fruits qui se trouvaient dans le trancheur de valeur. Nous pouvons configurer une autre variable ( VAR BuyerIn ) qui dit, si le client sélectionné était dans la table de cet acheteur, alors il en obtient un . Et sinon, il obtient un zéro .

Ensuite, nous prenons les résultats de cela et les mettons dans le volet de filtre. La mesure des acheteurs clés , disons-nous, en est une et ce seront les clients qui ont acheté, dans ce cas, des oranges.

Et donc en faisant cela, nous filtrons notre table de données d'origine jusqu'aux enregistrements corrects. Vous pouvez voir qu'il crée maintenant cette table virtuelle et qu'il filtre correctement en fonction de chaque sélection.

Tables virtuelles à l'intérieur des fonctions d'itération dans LuckyTemplates - Concepts DAX
Création de relations virtuelles dans LuckyTemplates à l'aide de la fonction TREATAS
Comment utiliser la fonction DAX COUNTROWS dans les tables virtuelles

Conclusion

C'est l'essentiel de ce que je voulais couvrir aujourd'hui. Il s'agit d'un exemple de table virtuelle assez simple, mais mettant l'accent sur la différence entre les tables physiques, les tables calculées et les tables virtuelles.

Il y a beaucoup de problèmes intéressants à revoir en ce qui concerne les tables virtuelles, en particulier avec le débogage des mesures de table virtuelle. C'est quelque chose sur lequel je reviendrai dans les prochaines semaines, mais pour l'instant, c'est tout ce tutoriel.

Acclamations!