[ypicot]

Bonjour

Difficile de répondre comme cela. Pourrais-tu partager un pbix contenant un extrait du fichier ?

Yvan

[ypicot]

Bonjour

De multiples questions, je vais essayer de répondre à certaines d’entre elles.

Tout dépend de la publication du rapport. Si je comprends bien, ce rapport sera publié via un PBI pro ou premium. La limite ne concerne pas réellement le nombre de lignes, mais la taille totale du rapport.

Une licence pro autorise 1Go par espace de travail. En gros, la taille occupée dans le cloud correspond à la taille de ton fichier .pbix, tu peux donc te faire une idée à partir de là. Pour aller plus loin, voir les licences Premium par utilisateur ou par capacité.

Tu peux opter pour du DirectQuery quand tu dépasses cette limite de taille, puisque seules les infos de connexion seront stockées dans ton pbix (et donc dans le cloud). Attention cependant : d’une manière générale, le DirectQuery est *beaucoup* plus lent que l’import, VertiPaq (le moteur interne de PBI) étant optimisé pour l’analyse de données. De plus, la source de données est solicitée à chaque modification de filtre par l’utilisateur (on peut presque dire : à chaque clic de l’utilisateur). Enfin, tu as des tas de fonctions DAX (EOMONTH, RELATEDTABLE, …) incompatibles avec DirectQuery quand tu les utilises pour créer une colonne ou des règles de sécurité au niveau des lignes (Row Level Security ou RLS).

Hormis les points évoqués ci-dessus il n’y a pas à ma connaissance de réelle limite à la taille des données, si ce n’est… la patience de l’utilisateur. Un fichier de qques millions de lignes mais avec du DAX complexe, des tas de hiérarchies, du RLS, et tu exploses les temps de réponse.

Je n’ai pas d’expérience concrète concernant les gateway, mais il me semble qu’on peut s’en passer uniquement si les données sont dans Azure, pas dans un autre cloud.

Yvan

[ypicot]

Bonjour

Je plussois la réponse de Philippe.

Vu de ma fenêtre, le mode focus est davantage une loupe pour les analystes / concepteurs (donc plutôt orienté PBI desktop) que comme un outil destiné aux utilisateurs finaux.

Quand ces derniers ont besoin de ce type de fonctionnalité, je créé un bouton pointant sur une page qui contient uniquement le visuel a zoomer, ce qui me permet accessoirement de garder le titre, afficher un rappel des filtres et autres personnalisations qui sont souvent demandées.

Inconvénient (parfaitement assumé) : cela charge un peu l’ensemble du rapport, donc à utiliser avec parcimonie.

Yvan

[ypicot]

Bonjour

Si je comprends bien, tu souhaites que les samedis et dimanches n’apparaissent pas sur l’axe des X.

Pour cela, une des possibilités est d’avoir deux tables :

• Une (fausse) table de dates “semaine”, dimDatesSemaine, qui ne contient que les jours en semaine
• Une table des faits, qui va contenir la mesure que tu souhaites

Un exemple de dimDatesSemaine en DAX :

<pre class=”language-php”>dimDatesSemaine =
FILTER(
dimDates,
WEEKDAY(dimDates[Date], 2)<=5
)

dimDates est une vraie table de dates (qui est indispensable dans la majorité des cas, et très utile dans les autres), créée avec un CALENDARAUTO ou autre.

Attention, ne pas définir dimDatesSemaines comme table de dates (ce qui est de toutes façons impossible car elle ne contient pas tous les jours).

Concernant la mesure, il y a une petite astuce. En effet, si tu n’as aucune valeur pour un jour donné, PBI va sauter le jour en question. Il faut donc ajouter zéro au résultat pour éviter le BLANK.

Imaginons que tu souhaites avoir le nombre de clients créé par jour, la mesure serait :

<pre class=”language-php”>CLI Nb = COUNTROWS ( t_clients ) + 0

Le résultat est le suivant :

[ypicot]

Pour le format :

Divise par 1000 😉

Pour le filtre :

Le filtre de page fonctionne parfaitement (et heureusement). Pour t’en convraincre, créé les deux mesures suivantes, mets-les dans des cartes (éventuellement sur une autre page) et joue avec les filtres.

Nb valeurs = COUNTROWS( BDD_Index )

Nb valeurs sans mois = CALCULATE( [Nb valeurs], ALL(DateTable[Mois]) )

CommentID=aNIfrZuAGGKQQ26, PostID=iA9tRGPMkjRagYF

[ypicot]

Bonjour

Effectivement ce résultat est bizarre a première vue. Je manque cruellement de temps pour analyser ton fichier plus en profondeur, mais je vais regarder cela de plus près (d’ici un mois… j’espère que tu n’es pas pressé…).

Sinon, pour ta question concernant le format, tu peux aller plus loin dans le format personnalisé que tu as déjà ébauché, et mettre par exemple :

### ### ### ### ##0 "MWh"

CommentID=HgUcGf20fIEdqh0, PostID=iA9tRGPMkjRagYF

[ypicot]

Bonjour

A ma connaissance, il n’est pas possible de récupérer les valeurs calculées pour afficher les prévisions.

J’ai eu l’occasion de discuter avec un analyste il y a qques temps (donc ce que je vais dire n’est pas de première main). D’après lui, la méthode utilisée par PBI (le lissage exponentiel) n’est pas fondamentalement mauvais, mais manque de pertinence dès que les données varient un peu trop, par exemple quand les variations saisonnières sont impactées par d’autres phénomènes.

Sa solution : utiliser R ou Python pour monter lui-même ses propres modélisations… (il était statisticien à la base).

Sinon, voici un lien vers une mesure faisant de la prévision :

https://www.daxpatterns.com/budget/

CommentID=sFavT5oaibTXcZ8, PostID=wMAZs0I7IroPum8

[ypicot]

Bonjour

Dans un modèle simple, tu as :

• d’un coté la/les table(s) de faits, qui contient les champs nécessaires aux mesures (Chiffre d’affaires, nombre de clients, …)

• d’un autre coté les tables de dimension (ou axes d’analyse)

De manière intuitive, la différence entre les deux se fait avec PAR :

• Je veux le nombre de clients (faits) PAR ville (dimension)

• Je veux la somme des chiffre d’affaires (faits) PAR type de produits (dimension)

Il est possible qu’une table de faits d’un visuel devienne table de dimension pour un autre :

• Je veux le nombre de clients PAR ville sur un visuel, et le nombre de factures PAR client sur un autre visuel

A noter que les segments sont toujours basés sur une table de dimension, puisqu’ils correspondent à un axe d’analyse.

Il y a quasiment toujours plusieurs tables de dimension pour une table de faits.

La relation entre la table de faits et une table de dimensions est 1 à N sauf cas exceptionnel (je n’en ai jamais rencontré hormis dans des modèles plus ou moins mal fichus dans lesquels il manquait des données).

Le sens de filtrage est très souvent unidirectionnel, dimension vers faits.

Le modèle que tu utilises dans le .pbix est un faux modèle à deux tables.

Il te faudrait 3 tables, comme suggéré par David :

• une table de dimension “étudiants” (id, nom, ville, …)

• une table de dimension “cours”(id, matière, niveau, …)

• une table de faits “inscriptions” (id_etudiant, id_cours, date_inscription, …)

A partir de là, tu pourras secouer tes données dans tous les sens.

CommentID=F94ZkyM1EFP6qUu, PostID=IyndyFmmRfvaVuL

[ypicot]

Perso, j’ai tendance à me méfier des “données qui ne changent jamais”.

L’exemple classique, celui des civilités.

Ben oui, c’est toujours Monsieur, Madame ou Mademoiselle, non ?

Ha ben non, Mademoiselle n’existe plus.

Et accessoirement, quelle est la civilité pour un notaire ? Ha ben m…, ou l’avait oublié celui-là 😉

CommentID=DaQAvvzyC6XO6ex, PostID=i0Cf90Xqr6wwz82

[ypicot]

Bonjour

Tout est une question de contexte. Je suppose que tu as tous les droits sur la BdD (sinon tu ne parlerai pas de supprimer des enregs ou créer une table).

• la table est mise à jour peu fréquemment (voire quasiment jamais, ce qui semble être le cas ici) : la solution 1 est la plus simple. Lors de la maintenance, personne n’aura à se poser la question de l’utilité de deux tables “country”.

• Tu tiens à garder un historique des données (ou bien la table est mise à jour régulièrement) : tu peux créer une vue qui fait le DISTINCT. A noter que si la table source est mise à jour, tu n’as rien à faire (et ça, c’est cooooool). Si je comprends bien la volumétrie de tes données, ce n’est pas cette vue qui va mettre ton serveur à genoux.

CommentID=s5gW1QhaXNHSOBI, PostID=i0Cf90Xqr6wwz82

[ypicot]

Bonjour

J’avoue ne jamais avoir prété attention au format des dates dans les filtres.

Après qques essais, le format de date dans le filtre reste chez moi 03/10/2023, que ce soit sur Desktop (même après avoir modifié ledit format dans les paramètres Windows) ou en ligne.

A priori, j’aurai tendance à regarder plutôt du coté des paramètres du compte en ligne, mais mon absence de compétence en tant qu’admin ne me permet pas d’aller plus loin.

CommentID=TQ6F8NBQuE74I7Y, PostID=0RWZHcZe6RqccZQ

[ypicot]

Bonjour

Je suppose que ta date est dans une gallerie horizontale.

L’idée serait de passer par une fonction Patch, qui met à jour la liste sous-jacente.

Cela pourrait ressembler à :

Patch(masource ; date=ThisItem.MaDate ; {Title : "Fermeture"} )

A ajuster en fonction des contrôles que tu utilises.

CommentID=clDO2uD70BSNwgV, PostID=Ueg5xaSXBkM9TZ5

[ypicot]

Oups… Confondre Patch et UpdateIf… Merci de m’avoir corrigé.

SubCommentID=XbZs7Du9Spm2Lhe, CommentID=clDO2uD70BSNwgV, PostID=Ueg5xaSXBkM9TZ5

[ypicot]

Il ne faut pas hésiter à créer de nouvelles mesures si le besoin s’en fait sentir. Je suis intervenu une fois sur un modèle qui en contenait environ 200 (dont une très grande partie pour gérer de l’affichage dynamique ou du formatage conditionnel).

As-tu le lien vers le stackoverflow ?

SubCommentID=CuJBFoILzNL7RUf, CommentID=KZUlKRwMWRmoIjf, PostID=iA9tRGPMkjRagYF

[ypicot]

Désolé, je n’aide pas les personnes qui sont avant moi dans l’ordre alphabétique… 😈

Effectivement, il existe plusieurs sites (http://regextester.com, http://regexr.com, …), sans oublier la foultitude d’outils qu’on peut trouver dans les éditeurs de texte ou sur github…

Un des avantages de https://regex101.com est qu’il permet de choisir -dans une certaine mesure- son moteur de regex. D’après ce que j’ai compris, celui qui se rapproche le plus de PowerApps est celui de Javascript, mais c’est à vérifier.

SubCommentID=a4aIOSDxwicXkx0, CommentID=lgzXMYCN1CgA3UU, PostID=JQwAjzxTqfzURiO