Daxone http://daxone.fr 100% Power BI et DAX Thu, 21 Nov 2019 14:05:07 +0000 fr-FR hourly 1 https://wordpress.org/?v=5.3.2 Les nouveautés de Novembre 2019 http://daxone.fr/les-nouveautes-de-novembre-2019/?utm_source=rss&utm_medium=rss&utm_campaign=les-nouveautes-de-novembre-2019 http://daxone.fr/les-nouveautes-de-novembre-2019/#respond Thu, 21 Nov 2019 06:51:17 +0000 http://daxone.fr/?p=565 Un tour de quelques-unes des nouvelles possibilités de la dernière version. J’en ai choisi deux : le nouveau ruban de l’interface et l’arbre de décomposition. Présentation et avis

L’article Les nouveautés de Novembre 2019 est apparu en premier sur Daxone.

]]>
La dernière mouture de Power BI Desktop est là : l’occasion de regarder ce que Microsoft nous a mijoté.
Comme vous le savez certainement, le blog de Power BI propose une présentation très complète des nouveautés : https://powerbi.microsoft.com/fr-fr/blog/ (malgré le /fr-fr, c’est bien de l’anglais …).
Daxone vous propose un regard critique sur certains de ces points.

La nouvelle interface de Power BI

C’était dans l’air depuis quelque temps : un nouveau ruban, qui s’approche de ceux des autres outils de la suite Office. Les avis sont partagés : pour certains, un pas en avant, pour d’autres, un raté.

Notez d’abord que la fonction est encore en preview, il faudra donc penser à l’activer par le biais des options (Menu Fichier > Options et paramètres > Options : dans la section Fonctionnalités en préversion, cocher Ruban mis à jour).

La volonté est très claire : se rapprocher le plus possible du ruban d’Excel, et unifier les produits.

Les bénéfices incluent un comportement dynamique (les fonctions indisponibles ne sont plus seulement grisées, elles sont ôtées du ruban) et l’apparition d’un onglet spécifique en fonction de l’objet sélectionné.

Le ruban Outil de mesure apparaît lorsque je sélectionne une mesure. Il regroupe l’ensemble des fonctions utiles pour manipuler l’objet.

Comme dans Office, il est aussi possible de réduire le ruban à une ligne pour gagner de la place (utilisez pour ça le petit triangle à droite du ruban) :

Enfin le ruban corrige un bug ou deux, notamment celui par lequel la partie supérieure de l’écran se figeait parfois, obligeant à minimiser et relever l’application.

D’après Microsoft, ce n’est que le premier pas : d’autres nouveautés sont prévues, notamment l’interface sombre (dark theme), l’ajout d’une galerie de visuels (comme dans Excel), et l’ajout de fonctionnalités pour paramétrer les visuels.

Notez que l’interface de Power Query, elle, n’a pas bougé.

Un blog destiné à recueillir vos remarques et demandes est disponible : https://powerbi.microsoft.com/fr-fr/blog/updated-ribbon-experience-for-power-bi-desktop/

Mon avis :

Si globalement j’accueille positivement ce nouveau ruban, je regrette l’absence de possibilité de personnalisation (j’aimais bien mes raccourcis Enregistrer, Actualiser, Annuler tout à fait en haut de la fenêtre), et je ne suis pas convaincu non plus par le menu Fichier (notamment pour enregistrer)

Un nouveau visuel : l’arbre de décomposition

Bon, le nom en français a un côté morbide, mais pensez à un arbre de répartition permettant d’analyser une mesure en fonction de dimensions que vous aurez choisies, avec une touche d’IA.

Notez d’abord que la fonction est encore en preview, il faudra donc penser à l’activer par le biais des options (Menu Fichier > Options et paramètres > Options : dans la section Fonctionnalités en préversion, cocher Enable decomposition tree visual).

Mise en place

La mise en place est très simple : sélectionnez une mesure, et un ensemble de dimensions pour l’analyser (l’ordre des dimensions n’est pas important).

Le résultat initial montre la valeur totale de la mesure :

Le signe + permet de décomposer soit en fonction d’une dimension que vous choisissez, soit en laissant l’IA calculer la catégorie qui contribue le plus (Valeur élevée) ou le moins à la valeur de la mesure, parmi toutes les catégories de toutes les dimensions de l’analyse :

Le résultat dans ce cas :

Notez l’icône Ampoule, qui indique (ici et dans d’autres visuels) le recours à l’IA. 

Dans le cas où vous utilisez l’IA, la catégorie qui contribue le plus est recalculée à chaque rafraîchissement.

Pour aller plus loin

Le nouveau visuel, à l’instar de tous les autres, permet le filtrage croisé : en cliquant sur l’une des barres de l’arbre, vous filtrez tous les autres visuels :

Et maintenant en jouant sur le filtrage (j’ai cliqué sur la barre représentant le montant pour T2) :

Les autres visuels (cartes, tableau) sont bien filtrés

Il existe des possibilités de formatage, notamment sur la densité de l’arborescence, la couleur des barres positives et négatives, et la mise à l’échelle de la barre (niveau maximal, ou relatif au nœud parent, ou encore au nœud supérieur – total) :

NB : il y a une option dont je n’ai pas compris le fonctionnement, à savoir le type d’analyse – relatif ou absolue – de l’IA. Si vous avez une idée, laissez un commentaire 😊

******

Il y a bien sûr d’autres fonctionnalités présentent dans cette mise à jour :

  • La mise en forme conditionnelle pour les boutons (possibilité de changer le texte du bouton, sa couleur, …)
  • De nouveaux visuels personnalisés, dont le prometteur Filtre hiérarchique
  • Et du côté de l’accès aux données, un connecteur LinkedIn Sales, et une mise à jour du connecteur Web par l’exemple, qui prend en charge les liens sur la page cible (plus là-dessus dans un futur billet)
  • Enfin dans Power Query, un très alléchant module d’AI permettant l’analyse de texte et d’image, mais réservé aux détenteurs d’un compte Premium…

L’article Les nouveautés de Novembre 2019 est apparu en premier sur Daxone.

]]>
http://daxone.fr/les-nouveautes-de-novembre-2019/feed/ 0
Time Intelligence : les bases fondamentales des calculs cumulatifs http://daxone.fr/time-intelligence-les-bases-fondamentales-des-calculs-cumulatifs/?utm_source=rss&utm_medium=rss&utm_campaign=time-intelligence-les-bases-fondamentales-des-calculs-cumulatifs http://daxone.fr/time-intelligence-les-bases-fondamentales-des-calculs-cumulatifs/#respond Thu, 14 Nov 2019 04:55:55 +0000 http://daxone.fr/?p=554 Power BI offre de nombreuses fonctions de Time Intelligence (« analyse historique », « analyse dans le temps » ?) toutes prêtes à l’emploi. Des « syntax sugars » comme disent les anglophones. Mais encore faut-il comprendre comment elles fonctionnent, et savoir revenir aux fondamentaux de ce type d’analyse. C’est ce que nous allons voir dans ce post, avec les sommes cumulatives et le cas du cumul hebdomadaire, que Power BI n’a pas prévu

L’article Time Intelligence : les bases fondamentales des calculs cumulatifs est apparu en premier sur Daxone.

]]>
Les briques de base de la Time Intelligence

Toute analyse historique est basée sur la modification du contexte de filtre, autrement dit sur les données prises en compte pour le calcul. Les Syntax Sugars font cela implicitement, et c’est la raison pour laquelle leur utilisation peut être complexe (on ne sait pas toujours ce qui se passe sous le capot).
C’est là qu’une bonne connaissance de la fonction CALCULATE et de la manière dont Power BI filtre les données jouent un rôle capital. Associée la FILTER, à MAX et aux opérateurs > et <, CALCULATE permet de faire à peu près tout.


Dans le cadre d’un calcul cumulatif, l’une des clés est la comparaison

Datum[Date] <= MAX(Datum[Date])


MAX([Date]) signifie ici la date courante (ce qui n’est pas nécessairement intuitif), c’est celle du contexte de filtre initial (ou naturel) : dans une table affichant les revenus quotidiens, c’est la ligne où vous vous trouvez (mais ça marcherait tout aussi bien avec les années, les trimestres, les mois etc.).

La syntaxe

FILTER (ALL(Datum) ; Datum[Date] <= MAX (Datum[Date]))

revient donc à générer une table contenant toutes les dates jusqu’à la date courante.

Et par conséquent

CALCULATE([Montant] ;
            FILTER(ALL(Datum);
                    Datum[Date] <= MAX(Datum[Date])
            )
)

permet de calculer, pour chaque ligne de la table, le montant cumulé depuis le début (première ligne de la table).

A partir de là, tout devient possible : imaginons que vous ayez lancé une campagne de promotion le 2 mai et que vous souhaitiez connaître le revenu cumulé depuis :

CALCULATE([Montant] ;
            FILTER(ALL(Datum);
              	Datum[Date] <= MAX(Datum[Date]) &&
		Datum[Date] >= DATE(2019,5,2)
            )
)


Le cumul mensuel, lui, s’écrit

CALCULATE([Montant] ;
            FILTER(ALL(Datum);
                    Datum[Date] <= MAX(Datum[Date]) &&
                    MONTH(Datum[Date]) = MONTH(MAX(Datum[Date]))
            )
)

C’est aussi simple que ça !


Nota bene : il est souvent utile, lors de la mise en place de ces formules, de créer une variable pour la date max :

VAR DDate = Max(Datum[Date])
RETURN


Dans ce cas, le CALCULATE peut s’écrire simplement :

CALCULATE([Montant] ;
            Datum[Date] <= DDate
)


Mais vous ne pouvez pas utiliser la fonction MAX directement dans le CALCULATE :

CALCULATE([Montant] ;
            Datum[Date] <= Max(Datum[Date])
)

génère une erreur « Une fonction MAX a été utilisée dans une expression TRUE/FALSE utilisée en tant qu’expression de filtre de table ».


Les Syntax Sugars


Pour ce qui concerne les cumuls, il existe un ensemble de fonctions prêtes à l’emploi. Elles sont le plus souvent simples à utiliser, et vous en trouverez des descriptions très facilement (https://docs.microsoft.com/fr-fr/dax/time-intelligence-functions-dax par exemple, ou encore https://dax.guide/).


DATESYTD et ses variantes DATESQTD et DATESMTD remplacent la partie filtre de CALCULATE, et retournent respectivement une liste de dates depuis le début de l’année / du trimestre / du mois jusqu’à la date courante :

CALCULATE(
    [Montant];
    DATESYTD(Datum[Date])
)


TOTALYTD (et TOTALQTD, TOTALMTD) simplifient encore la syntaxe (plus besoin du CALCULATE) :

TOTALYTD([Montant];
            Datum[Date])

affiche ainsi un cumul pour chaque année (idem pour les trimestres et les mois respectivement).


Notez que pour être sûr que les fonctions Time Intelligence fonctionnent correctement, il est impératif de disposer d’une table du temps.


Le cas non prévu du cumul hebdomadaire


Les Syntax Sugars sont pratiques, mais ne couvrent pas tous les cas de figure – tout ce qui sort de l’ordinaire impose de repartir de la syntaxe fondamentale à base de CALCULATE et de filtrage.

Or un type d’analyse courant n’est pas proposé par Power BI : il s’agit du cumul hebdomadaire. Voyons sa mise en place dans un exemple détaillé.


L’objectif ici est de réaliser le tableau ci-dessous, permettant de suivre le cumul hebdomadaire des montants, et de calculer le pourcentage de progression du montant cumulé par rapport au total de la semaine :


La donnée critique ici, c’est le champ Année_Semaine_ISO, dont nous avons vu la mise en place dans le billet consacré à la semaine (ICI). En effet, pour obtenir le cumul hebdomadaire, le filtre ne devra retenir que les dates inférieures ou égales à la date courante, partageant la même semaine ISO. A partir de là, le calcul est très simple :

    CALCULATE(
        [Montant];
        FILTER(ALL(Datum);
                Datum[Année_Sem_ISO] = AnSemISO_DDate &&
                Datum[Date] <= DDate
        )
    )


DDate et AnSemISO_DDate sont définies dans des variables, en utilisant les règles de calcul précisées dans le billet évoqué plus haut, consacré à la semaine. Voici donc le script en intégralité :


De même, pour la progression hebdomadaire, il suffit de diviser le cumul par le total hebdomadaire. Ce dernier est calculé à l’aide d’un filtre retenant toutes les dates partageant la même semaine que la date en cours :

L’article Time Intelligence : les bases fondamentales des calculs cumulatifs est apparu en premier sur Daxone.

]]>
http://daxone.fr/time-intelligence-les-bases-fondamentales-des-calculs-cumulatifs/feed/ 0
La création de la colonne Semaine : quelle norme ? http://daxone.fr/la-creation-de-la-colonne-semaine-quelle-norme/?utm_source=rss&utm_medium=rss&utm_campaign=la-creation-de-la-colonne-semaine-quelle-norme http://daxone.fr/la-creation-de-la-colonne-semaine-quelle-norme/#respond Wed, 13 Nov 2019 05:06:10 +0000 http://daxone.fr/?p=525 Le calcul de la semaine s’avère plus complexe qu’il n’y paraît : deux normes co-existent, et celle que nous utilisons en Europe (considérée comme universelle) – la norme ISO 8601 – n’est pas celle que Power BI utilise par défaut. Détails, calculs et une pépite non-documentée dans le billet.

L’article La création de la colonne Semaine : quelle norme ? est apparu en premier sur Daxone.

]]>
Les normes de calcul de la semaine

Deux systèmes de calcul du numéro de semaine co-existent (dans Power BI ou ailleurs) : pour le calendrier grégorien, la semaine 1 commence le premier janvier, et se termine le premier dimanche ou le premier lundi de l’année (respectivement WEEKNUM([Date] ;1) ou WEEKNUM([Date] ;2) en DAX). C’est le système utilisé aux USA notamment.

L’autre système, largement utilisé en Europe, « est un système de calendrier faisant partie de la norme d’horodatage ISO 8601. Le système est principalement utilisé par les gouvernements et entreprises pour baser également les années comptables et fiscales et la planification de projets à cycles hebdomadaires de travail, ainsi que pour le paiement des salaires ou des loyers (quand ceux-ci sont versés hebdomadairement) » (Wikipédia). Dans cette norme, la première semaine de l’année est celle contenant 4 jours au moins. D’où l’existence d’un décalage entre les deux calendriers : dans le premier, une semaine 53, d’une durée comprise entre 1 et 6 jours, va s’intercaler en fin d’année (le 31 décembre 2018 fait donc partie de la semaine 201853) ; dans le second, la semaine 1 peut débuter dès les derniers jours de l’année précédente (le 31 décembre 2018 fait donc partie de la semaine 201901).

Une différence de numérotation

Le calcul de la semaine en norme ISO 8601 : un paramètre caché

C’est, je crois, Gerhard Brueckl, dans son blog, qui signale dès 2012 l’existence d’un paramètre caché pour la fonction WEEKNUM (http://blog.gbrueckl.at/2012/04/iso-8601-week-in-dax/) : en effet, WEEKNUM([Date] ;21) renvoie directement le numéro de semaine dans la norme ISO.

Par convention, cette semaine est notée W suivi du numéro de semaine :

"W" & FORMAT(WEEKNUM([Date];21);"00")

Mais comme le montre l’image ci-dessus, l’année ISO peut également varier : le 31 décembre 2018 appartient à 2018-S53 et à 2019-W01. Gerhard Brueckl propose donc le calcul suivant pour la colonne Année_ ISO :

Que j’adapte en introduisant des variables (pour optimiser le script) et en complétant avec le numéro de semaine (selon la norme officielle) :

Cette colonne va s’avérer particulièrement importante pour le calcul des cumuls hebdomadaires, comme nous le verrons dans le prochain billet.

Un nouveau script pour la table Datum

Je vous propose donc un nouveau script pour la table, que vous pouvez afficher ICI.

La table filtrée sur 2018 et 2019 semaine W01 et W52

L’article La création de la colonne Semaine : quelle norme ? est apparu en premier sur Daxone.

]]>
http://daxone.fr/la-creation-de-la-colonne-semaine-quelle-norme/feed/ 0
Le choix des couleurs pour le rapport http://daxone.fr/le-choix-des-couleurs-pour-le-rapport/?utm_source=rss&utm_medium=rss&utm_campaign=le-choix-des-couleurs-pour-le-rapport http://daxone.fr/le-choix-des-couleurs-pour-le-rapport/#respond Wed, 06 Nov 2019 10:54:53 +0000 http://daxone.fr/?p=505 Un petit pas de côté dans cet article, où il ne s’agit ni de M ni de Dax, mais plus simplement de ce qui va embellir et personnaliser votre rapport : les couleurs. Le choix judicieux de la palette de couleurs est un aspect important de la « composition visuelle » de votre rapport, et participe de l’utilisation qui en sera faite, et du plaisir à le lire

L’article Le choix des couleurs pour le rapport est apparu en premier sur Daxone.

]]>
Les couleurs vous serviront à harmoniser l’apparence de vos rapports, à le rendre donc plus agréable à consulter, mais aident aussi à reposer l’œil : quand vous passez votre journée à consulter des rapports, autant que ça ne soit pas une source de stress oculaire … Et (accessoirement) c’est aussi comme ça que vous pourrez implémenter une charte graphique, par exemple en vous inspirant d’un logo.

Voyons ça de plus près …

Les couleurs

Dans mon livre (aux éditions ENI – https://www.editions-eni.fr/livre/power-bi-desktop-de-l-analyse-de-donnees-au-reporting-9782409019906), j’évoque en détail les règles de composition – en deux mots, rester simple ! C’est vrai en particulier des couleurs.
Marco et Alberto, de SQLBI, proposent des rapports quasi-monochromes, où la touche de couleur n’est justifiée que si elle a du sens (un point rouge pour indiquer une valeur minimale ou aberrante).

Sans aller jusque-là, il est néanmoins important que l’équilibre des couleurs soit agréable, et reflète l’identité du service ou de l’entreprise, ou la vôtre, tout simplement.

Mais comment choisir les couleurs, et comment les utiliser dans Power BI ?

Les choix des couleurs

Le Net propose de nombreux outils pour créer des palettes équilibrées, ou retrouver un code couleur à partir d’une image ou d’un logo. Et de son côté, Power BI permet de personnaliser les couleurs, en utilisant le code HEX, mais aussi d’importer un thème de couleurs.

Afin d’illustrer ces points, je vous propose un rapport de départ, basé sur les couleurs par défaut de Power BI :

Imaginons maintenant que nous souhaitions améliorer ces couleurs, en nous basant sur un logo (celui du site daxone.fr).

Récupérer les codes couleurs

Un premier site nous permet de rapidement trouver le code des couleurs : https://imagecolorpicker.com/fr. Il suffit d’y envoyer l’image, puis de cliquer sur les différentes couleurs pour récupérer le code correspondant (il est précédé d’un #, et apparaît surligné en blanc sur l’image ci-dessous) :

Dans cet exemple, le code à récupérer est FED020.

Il s’agit ensuite d’utiliser la couleur personnalisée dans Power BI :

Au fur et à mesure que vous importez les couleurs, la palette se précise. Rapidement, vous disposez de vos 2 ou 3 couleurs de base (+ le noir).

Dans notre exemple, voici le résultat, où l’on « voit » bien mieux l’identité visuelle :

Il existe bien d’autres sites, je vous recommande en particulier celui d’Adobe (https://color.adobe.com/fr/create), qui permet de créer de nombreuses palettes, soit à partir d’un code, soit à partir d’une image :

Utiliser et partager un thème de couleur

Vous pouvez pousser cette logique un peu plus loin, et souhaiter par exemple utiliser le même thème dans plusieurs rapports, voire partager un thème avec d’autres personnes.

Les thèmes de couleurs dans Power BI sont basés sur des fichiers JSON. Or il est très simple de changer de thème, et d’en importer de nouveaux (onglet Accueil) :

La question est donc de créer le thème. C’est là que les choses se complique un peu. Peut-être disposez-vous d’une équipe de graphistes, en mesure de coder un fichier JSON (description complète sur le site de Microsoft, en suivant le lien Comment créer un thème sur l’image ci-dessus).

Mais il existe une alternative : le Report Theme Generator (https://powerbi.tips/tools/report-theme-generator-v3/ ). Cet outil graphique permet de créer des thèmes très complets, et de générer le fichier JSON, sans avoir besoin de coder.

En voici un exemple simple. Il suffit d’entrer le code dans la section Selected Color en haut à gauche, et de l’ajouter avec la fonction Add Selected Color en bas de l’image, puis de télécharger le thème :

Une fois le fichier JSON sur votre poste, utilisez la fonction Importer un thème de Power BI pour retrouver la palette de couleurs dans votre rapport :

L’article Le choix des couleurs pour le rapport est apparu en premier sur Daxone.

]]>
http://daxone.fr/le-choix-des-couleurs-pour-le-rapport/feed/ 0
Les paramètres dans Power Query et dans les rapports (2) http://daxone.fr/les-parametres-dans-power-query-et-dans-les-rapports-2/?utm_source=rss&utm_medium=rss&utm_campaign=les-parametres-dans-power-query-et-dans-les-rapports-2 http://daxone.fr/les-parametres-dans-power-query-et-dans-les-rapports-2/#respond Sat, 02 Nov 2019 05:34:00 +0000 http://daxone.fr/?p=453 Suite du dossier consacré aux paramètres : cette fois-ci, j’évoque les paramètres-filtres et les autres modifications du code de la requête. Les paramètres-filtres nous donneront l’occasion de voir la génération d’une liste de valeurs pour le paramètre

L’article Les paramètres dans Power Query et dans les rapports (2) est apparu en premier sur Daxone.

]]>

Archives

Les paramètres Filtre et Tri et les listes de valeurs

Les paramètres-filtres

Il faut le rappeler ici : l’effet d’un paramètre se manifeste au moment de l’envoi de la requête à la source de données.

Un paramètre-filtre de requête est donc très différent d’un filtre de rapport (slicer), puisque le paramètre va réduire le volume de données.

C’est par conséquent particulièrement utile lorsqu’il s’agit de maîtriser la masse de données ramenée au moment de l’actualisation du rapport. Associé à un modèle de document (PBIT), le paramètre-filtre est un outil particulièrement efficace pour encadrer la requête envoyée par un utilisateur.

Dans une moindre mesure, c’est un outil qui facilite la modification du périmètre de la requête (basculer rapidement d’un périmètre à un autre, sans avoir besoin de passer par Power Query).

Le point de départ, à nouveau, c’est créer une première requête sur la source : dans cet exemple, un fichier Excel de relevés de la qualité de l’air, fourni par l’OMS. Le fichier propose des relevés des niveaux de particules PM10 par Région, Ville et Année, entre autres. Il fait 12000 lignes, et je veux m’assurer qu’un nombre restreint de lignes sera extrait.

Je vais créer un paramètre-filtre pour l’année, un autre pour la région. La subtilité ici, c’est que je souhaite que ces paramètres s’appuient sur une liste de valeurs générée automatiquement à partir des données du fichier.

Rappelez-vous : lors de la création d’un paramètre, un choix s’offre, de permettre toutes les valeurs, de les limiter à une liste saisie manuellement, ou d’utiliser une requête. C’est cette troisième option qui va nous intéresser.

Regardons-en dans un premier temps la démarche générale :

  1. Il s’agit d’abord de créer une nouvelle requête basée sur la même source (utilisez pour ça le raccourci Sources récentes)
  2. Puis ne garder qu’une colonne (Supprimer les autres colonnes)
  3. Supprimer les doublons
  4. En enfin, convertir cette requête en liste

J’effectue aussi cette opération pour les années, pour me retrouver avec deux listes.

Passons maintenant aux paramètres. Leur création ne pose aucune difficulté, puisque les listes sont disponibles avec l’option … Requête :

A ce stade, j’ai donc 5 entrées dans la zone requête de Power Query :

  • La liste Années
  • Le paramètre Année
  • La liste Régions
  • Le paramètre Région
  • La requête utile, celle dont je me servirai dans le rapport

C’est sur cette dernière que je vais maintenant appliquer un filtre basé sur chacun des paramètres.

Attention : à ce jour, il n’est pas possible de créer simplement des « listes en cascade », c’est-à-dire des listes dont les valeurs dépendent d’un autre paramètre (ex., une liste de villes générée en fonction du pays choisi préalablement). Par ailleurs, il n’est pas possible de choisir plusieurs valeurs lors de l’appel du paramètre. Ces deux points sont prévus dans une version prochaine de Power BI.

Lors de l’application d’un filtre textuel « Egal à » sur la colonne Région, je vais pouvoir invoquer le paramètre et le choisir dans la liste déroulante (il est d’ailleurs possible de créer le paramètre à la volée) :

Cette opération est répétée pour les années.

Notez le script M résultant :

 = Table.SelectRows(#"Lignes filtrées", each [Year] = Année)
et
= Table.SelectRows(#"Colonnes supprimées", each [Region] = Région)

 Remarque : avant de passer au rapport lui-même, notez qu’il est inutile de charger les listes Année et Région !

Reste à appliquer et fermer Power Query. Le résultat de la requête tient compte des deux valeurs actuelles définies à la création des paramètres.

Pour exécuter la requête sur un autre périmètre (c’est là que la démarche pêche un peu, mais nous verrons comment améliorer ce point avec les modèles de document), il faut utiliser la fonction Modifier les requêtes > Modifier les paramètres, et choisir dans la liste déroulante.

Attention à bien penser à appliquer les modifications (à relancer la requête) :

Si vous souhaitez afficher sur le rapport les choix de région et d’année, la formule suivante suffit :

                AnnéeRégion = MAX(PM_10[Year]) & " / " & MAX(PM_10[Region])

 

Les paramètres modificateurs du script de la requête

Les paramètres peuvent également servir à rendre dynamique des portions du script M de la requête.

Dans le scénario que je vous propose, je souhaite extraire le top X des villes en termes de moyenne annuelle de particules PM10 (colonne Annual mean du tableau) pour une région et une année données.

Ici, top X signifie que je laisse à l’utilisateur le soin d’extraire 5, 10 ou 25 villes (je pourrais bien entendu laisser un choix totalement ouvert, voire facultatif).

Sur la base du fichier précédent, je vais donc créer un nouveau paramètre Top X :

Je vais ensuite, en m’appuyant sur l’UI, trier les lignes de la table par ordre décroissant de moyenne annuelle. Enfin, toujours à l’aide de l’UI (fonction Conserver les lignes > Conserver les premières lignes), je vais appeler et choisir dans la liste déroulante le paramètre Top X :

Notez le code M généré :

      = Table.FirstN(#"Lignes triées",#"Top X")

(Ici, l’appel du paramètre est encadré de doubles guillemets et précédé d’un dièse : c’est parce son nom contient un espace).

***

En définitive, si j’actualise le rapport, voici la fenêtre des paramètres et le résultat :

Ceci est un exemple parmi beaucoup d’autres d’utilisation des paramètres pour modifier le script.

Dans le prochain article, j’évoquerai les modèles de document PBIT et leur rapport avec les paramètres et les fonctions dans Power Query

L’article Les paramètres dans Power Query et dans les rapports (2) est apparu en premier sur Daxone.

]]>
http://daxone.fr/les-parametres-dans-power-query-et-dans-les-rapports-2/feed/ 0
Les paramètres dans Power Query et dans les rapports (1) http://daxone.fr/les-parametres-dans-power-query-et-dans-les-rapports-1/?utm_source=rss&utm_medium=rss&utm_campaign=les-parametres-dans-power-query-et-dans-les-rapports-1 http://daxone.fr/les-parametres-dans-power-query-et-dans-les-rapports-1/#respond Wed, 30 Oct 2019 04:43:49 +0000 http://daxone.fr/?p=429 Modifier simplement la requête Power Query, changer facilement de source, de filtre, mais aussi proposer à l’utilisateur de faire varier les calculs des mesures, et même la structure d’un visuel, - c’est tout cela que permettent de réaliser les paramètres. Tour d’horizon en trois parties.

L’article Les paramètres dans Power Query et dans les rapports (1) est apparu en premier sur Daxone.

]]>

Archives

Le paramètre Source de données, création d’un paramètre

Les paramètres offrent la possibilité de modifier le périmètre de la requête Power Query, de passer par exemple d’une base de données de DEV à une base de PROD, d’un fichier à un autre, ou encore de modifier, de manière simple, le filtre appliqué à une ou plusieurs colonnes (changer d’année, de produit, etc.).

Dans la première partie de ce dossier, j’évoquerai tout ce qui touche aux paramètres de Power Query, et leur création, ainsi que les limites de la solution.

Associé à un modèle de document (template .pbit), ils permettent de maîtriser la manière dont l’utilisateur va interroger la source de données, tout en lui laissant une certaine dose de liberté quant au périmètre de la requête. Et ce dans le but principal de limiter la taille du résultat.

Enfin ils peuvent également servir de base à la création d’une fonction : nous en verrons un exemple facilitant la création de table.

Ces notions seront abordées dans une deuxième partie.

Mais le terme « paramètre » s’entend aussi au niveau du rapport, avec les scénarios What If – « que se passerait-il si tel ou tel « paramètre » évoluait ? » -, et j’étendrai encore cette notion, en évoquant le « paramètre » permettant à l’utilisateur de choisir l’indicateur analysé (CA hors-taxe ? Ou TTC ? Ou peut-être encore la TVA ?).

Ces points seront traités dans la troisième partie du dossier.

L’utilisation la plus connue des paramètres de Power Query est la possibilité de changer rapidement de source de données : c’est très utile lorsqu’il s’agit de passer facilement d’un environnement de développement (test) à un environnement de production ; d’une base de données historisée à une base à l’instant t ; ou encore d’un fichier stocké en local à un fichier stocké sur le réseau. A condition, bien entendu, que les deux sources aient la même structure, ou du moins que les colonnes utilisées pour générer les visuels soient présentes et organisées de même manière dans les deux sources.

Un peu d’UI et une pincée de M

Il suffira pour créer ce paramètre (dans Power Query, Accueil > Gérer les paramètres > Nouveau paramètre) de renseigner manuellement les noms des instances (dans le cas d’une base) et de créer un second paramètre pour les noms des bases elles-mêmes (voir l’image ci-dessus).

Dans le cas d’un paramètre pour changer de fichier source, c’est plus simple encore.  Une fois le document Power BI créé (dans mon cas, il est initialement basé sur un des deux fichiers source, Facts -2019.xlsx), il suffit de renseigner le paramètre avec le ou les chemins d’accès et le nom des fichiers :

Notez que le paramètre peut être facultatif et qu’il est typé (texte, numérique, date pour l’essentiel). Les valeurs suggérées sont soit libres (« Toutes les valeurs »), soit basées sur une liste saisie manuellement (« Liste de valeurs »), soit basées sur une liste générée à partir d’une requête (nous en verrons un exemple plus loin). Enfin une valeur par défaut et une valeur actuelle peuvent être demandées.

Une pincée de M

Attention : une fois le paramètre créé, il faut ouvrir l’éditeur avancé de la table initiale (Facts -2019.xlsx), pour modifier la ligne Source du script M :

Source = Excel.Workbook(File.Contents("C:\Users\andre\Desktop\Facts - 2019.xlsx"), null, true)

devient

Source = Excel.Workbook(File.Contents(ChoixFichier), null, true)

ChoixFichier est le nom du paramètre.

Pour SQL Server, le script modifié ressemblera à ça :

Source  = Sql.Database(SqlSrvInstance, Database, [Query="SELECT…” (etc.)

SqlSrvInstance, Database sont les deux paramètres.

 

Une fois la requête exécutée, pour passer d’un fichier à un autre, il suffit (…) d’ouvrir le menu Modifier les requêtes > Modifier les paramètres, et d’utiliser le menu déroulant pour choisir le fichier :

Et d’appliquer les modifications (bandeau jaune en haut de la page).

(Nous verrons dans la suite du dossier qu’il existe d’autres possibilités d’invoquer le paramètre).

Le petit plus : et si nous décidions de créer un titre dynamique dans le rapport en affichant le nom de la source et la date d‘actualisation ? Une démarche possible consiste, d’abord dans Power Query :

  • A référencer le paramètre (clic droit > Référence)
  • A convertir le résultat en table (onglet Transformer > Vers la table)
  • A renommer et typer la colonne
  • Et à fermer et appliquer

Dans le rapport, créer une mesure

Source_actualisation = MAX(ChoixSource[source]) & " - "& TODAY()

 Et le résultat (j’utilise le visual Carte):

Dans la suite de ce dossier, nous verrons la création de deux autres types de paramètres (filtre et tri), la création de modèles de document et leur lien avec les paramètres, et la création de fonction.

L’article Les paramètres dans Power Query et dans les rapports (1) est apparu en premier sur Daxone.

]]>
http://daxone.fr/les-parametres-dans-power-query-et-dans-les-rapports-1/feed/ 0
Une question de temps (1) : ajouter la table du temps http://daxone.fr/une-question-de-temps-1-ajouter-la-table-du-temps/?utm_source=rss&utm_medium=rss&utm_campaign=une-question-de-temps-1-ajouter-la-table-du-temps http://daxone.fr/une-question-de-temps-1-ajouter-la-table-du-temps/#respond Mon, 21 Oct 2019 04:03:34 +0000 http://daxone.fr/?p=155 Le premier aspect de la question du temps dans Power BI repose sur la mise en place de la table du temps dans le modèle : quand faut-il le faire ? Et faut-il ajouter une table du temps, ou plusieurs ? Les réponses dans ce premier billet

L’article Une question de temps (1) : ajouter la table du temps est apparu en premier sur Daxone.

]]>

Archives

Ajouter la table du temps

(Remarque : 13 novembre 2019, en complément de cet article, mise à jour du script de création de la table, avec la question de la colonne semaine, que vous trouverez ICI)

La question du temps dans Power BI possède à mon sens 4 couches :

• La base indispensable, autrement dit la table du temps (ou les tables du temps) dans le modèle
• Le fonctionnement clé de l’analyse, autour des fonctions CALCULATE, FILTER et DATEADD
• La découverte des nombreuses fonctions de Time Intelligence présentes en DAX
• L’exposition de cas particuliers (je pense à des difficultés de granularité – de niveau de détail – entre la table du temps et la table des faits*, au travail sur les heures, les minutes, les secondes, etc.)
(* la table des faits est celle où sont enregistrées les transactions, par exemple le montant de la ligne de facture, le résultat d’un échantillonnage, la quantité commandée, etc. C’est la table centrale du modèle, à laquelle sont liées les tables de dimension – la liste des produits, des clients, ou encore la table du temps – du moins dans un modèle simple)

Dans cette première partie du dossier, je vous propose de regarder de près la table du temps, sa construction, les différentes colonnes qui la composent et la mise en place de la relation (ou des relations) avec la table des faits.

Faut-il toujours ajouter une table du temps ?

A première vue, dans un modèle de données simple (par exemple, l’import d’une feuille Excel comprenant une date), Power BI propose des outils automatiques qui semblent fonctionner correctement.

Ces outils reposent sur l’option Date/heure automatique (activée par défaut) que vous trouverez dans les options du fichier actif (mais aussi dans les options globales). Cette option crée automatiquement une table du temps, cachée et non-modifiable, pour chaque date du modèle. Et génère pour le champ de type Date une hiérarchie automatique (Année, Trimestre, Mois, Jour).

Le danger ici est de voir se créer un nombre important de tables (qui vont donc augmenter la taille du modèle), sans pouvoir les personnaliser (ajout de la semaine par exemple).

D’autre part, le champ Date que vous utiliserez dans votre rapport sera bien celui de la table que vous avez importée, avec ses « trous » : si aucune transaction n’a eu lieu à une date donnée, mettons le 10 janvier, cette date n’apparaît pas dans le tableau résultant, ce qui, en soit, est une perte d’information.

Les possibilités de filtrer à l’aide d’un slicer seront difficiles à mettre en place : puisque chaque date a sa propre table du temps, un slicer ne peut filtrer la mesure (mettons le HT) que pour une date (la date de commande et pas le date de règlement – qui nécessitera un deuxième slicer).

Enfin les fonctions de Time Intelligence auront un comportement parfois curieux et pourront générer des résultats incomplets :

Il est donc recommandé de de désactiver l’option Date/heure automatique et de créer sa propre table du temps.

 

Comment créer la table du temps ?

Si la table du temps n’existe pas déjà dans la source de données – auquel cas il faut utiliser celle-là -, un peu de DAX permet de la créer assez simplement.

Je vous propose un script (fichier .txt), que vous pouvez télécharger librement, coller dans la barre de formule Créer une table, et adapter à votre situation (les instructions pour son utilisation sont comprises en commentaire dans le script – il importe notamment de fixer les dates de début (toujours un 1er janvier) et de fin (toujours un 31 décembre), en fonction de la période utile à l’analyse – et plus précisément des années).

Le résultat génère la table suivante :

Si vous avez besoin de créer plusieurs tables du temps, je vous recommande de copier-coller le code autant de fois que nécessaire (ou utiliser la commande Dax Table du temps 2 = Table du temps). Et penser à renommer les colonnes : il faut toujours éviter d’avoir deux objets portant le même nom dans le modèle !

 

Faut-il mettre une table du temps, ou plusieurs ?

Enfin se pose la question de savoir s’il faut une table et plusieurs relations (une sur chaque date significative, et la relation active sur la date la plus utilisée, les autres relations étant donc par définition inactives), ou plusieurs tables (une pour chaque date significative).

Il n’y a pas de bonne réponse ici : tout dépend du type d’analyse que vous souhaitez faire. La règle à appliquer est la suivante :

 

  • Si vous souhaitez comparer plusieurs mesures sur une date (un axe du temps commun), alors une table du temps. C’est l’illustration 1 ci-dessous, avec le modèle correspondant.
    Par exemple, comparer le montant des achats et le montant des ventes pour un mois donné.
    Dans ce cas de figure, il s’agit donc de créer autant de mesures que nécessaire, et d’activer à la demande les relations inactives à l’aide de la fonction USERELATIONSHIP.

  • Si vous souhaitez comparer une mesure sur plusieurs dates (par ex., date de réalisation, date de règlement), alors plusieurs tables du temps. C’est l’illustration 2 et son modèle.
    Par exemple, créer une matrice pour répartir le CA en fonction de la date de commande et de la date de règlement.

L’article Une question de temps (1) : ajouter la table du temps est apparu en premier sur Daxone.

]]>
http://daxone.fr/une-question-de-temps-1-ajouter-la-table-du-temps/feed/ 0
Les raccourcis clavier de l’éditeur Dax http://daxone.fr/les-raccourcis-clavier-de-lediteur-dax/?utm_source=rss&utm_medium=rss&utm_campaign=les-raccourcis-clavier-de-lediteur-dax http://daxone.fr/les-raccourcis-clavier-de-lediteur-dax/#respond Thu, 17 Oct 2019 03:32:13 +0000 http://daxone.fr/?p=255 L’éditeur de formules Dax propose plusieurs raccourcis clavier plus ou moins cachés .. et plus ou moins intéressants. Ils permettent de gagner du temps et de la cohérence lors de l’écriture de formule.

L’article Les raccourcis clavier de l’éditeur Dax est apparu en premier sur Daxone.

]]>

Archives

L’éditeur de formules Dax propose plusieurs raccourcis clavier plus ou moins cachés .. et plus ou moins intéressants. Ils permettent de gagner du temps et de la cohérence lors de l’écriture de formule.

 

Je vous propose mon top 5, suivi de la liste complète compilée à partir du site de l’éditeur et du blog XXL BI de Daniil Maslyuk.

Et si vous en connaissez d’autres, laissez-moi un commentaire 🙂

 

Le top 5 des raccourcis clavier

 

Sélectionner toutes les occurrences du terme (ou des caractères) actuellement sélectionné
(ex, une colonne, une table ou une fonction qu’il faut remplacer partout dans la formule)
Ctrl+F2 (ou Ctrl+Maj+L)
Mettre en commentaire
(ou à l’inverse, enlever la mise en commentaire)
Sélectionner la ou les lignes et Ctrl+/
Aller à la ligne avec indentation (retrait) Maj+Entrée
Copier une ligne au-dessus / en-dessous Maj+Alt+↑ ou ↓
Valider une proposition de fonction d’Intellisense Tab

La liste (presque) complète des raccourcis

Manipuler les lignes

Déplacer une ligne vers le haut/le bas Alt+↑ ou ↓
Aller à la ligne sans indentation Alt+Entrée
Insérer une ligne en-dessous Ctrl+Entrée
Insérer une ligne au-dessus Ctrl+Maj+Entrée
Sélectionner la ligne actuelle Ctrl+I
Naviguer jusqu’à une ligne en indiquant son numéro Ctrl+G (taper ensuite Entrée pour masquer la zone de saisie du numéro de ligne)

 Saisir du texte

Insérer plusieurs curseurs aux endroits choisis en cliquant (utile pour saisir un même texte à plusieurs endroits) Alt+Clic
Activer plusieurs curseurs au même endroit sur plusieurs lignes Ctrl+Alt+↓ ou Ctrl+Alt+↑

Sélectionner le mot entier (là où se trouve le curseur)

(Si une portion de texte a déjà été sélectionnée, Ctrl+D sélectionne la prochaine occurrence de la même sélection, et ainsi de suite : cela permet de modifier l’ensemble des portions sélectionnées d’un coup)

Ctrl+D

 Commentaire et indentation

Augmenter l’indentation / réduire l’indentation Tab / Maj+Tab
Aller à la ligne sans indenter Alt+Entrée

 Utiliser Intellisense

Pour rappeler la fenêtre Intellisense Alt+I

 

L’article Les raccourcis clavier de l’éditeur Dax est apparu en premier sur Daxone.

]]>
http://daxone.fr/les-raccourcis-clavier-de-lediteur-dax/feed/ 0