Discussion :

[guen]

Bonjour,

Je bloque sur la conception d'une mesure (ou peut-être de mon modèle à la base...).
Dans le cadre de visites sur des vergers où l'on collecte des critères, je cherche à obtenir la dernière valeur disponible pour un critère donné (c'est à dire lorsque le critère a été noté pour la dernière fois, la date max).
J'ai un modèle de ce type :


avec :

• la date de l'audit AUDIT_Date dans la table audit (le "chapeau"),
• la valeur du critère DETAUD_Valeur_num dans la table audit_detail (une ligne par critère identifié par son code VARAUD_Code)
• le (ou les car il peut y en avoir plusieurs) ilots concerné ILOT_Code dans la table ilot relié à l'audit par une table de relation plusieurs à plusieurs audit_ilot (c'est une approche plus BDD que BI je pense...)

cela me donne une table à plat du style

où l'on voit bien 2 visites pour les ilots 107.7 et 128.2 (la colonne des valeurs étant filtrée sur mon critère VARAUD_Code=estimation de rendement en l'occurence)
Ce que je veux donc : c'est avoir dans mon tableau seulement la valeur de DETAUD_Valeur_num pour la dernière date disponible, soit 5766 pour l'ilot 107.7 et 9822 pour le 127.1 (1 seule valeur)
En créant une mesure

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
DerniereDate = LASTDATE(Audit[AUD_Date])

j'obtiens bien la date de dernière visite sur l'ilot quand je mets la mesure dans ce tableau mais comment je vais chercher alors la valeur associée à cette date ?
J'ai cherché du côté de LOOKUPVALUE mais en vain pour le moment..
Est-ce que vous avez une idée s'il vous plait ?
Bonne journée

Guen

[Nicolas MENDEZ]

Hello Guen,

Avant tout, concernant la formule, tente de regarder du côté de LASTNONBLANK()

Ensuite je pense que le modèle pourrait être optimisé et qu'il pourrait être bon de préciser quelques points sur le modèle :

- Les relations de cardinalité *<->* sont à éviter
- Les relations à double sens sont à éviter ( pour pas dire bannir sauf dans certains cas assez précis ). Elles crées des ambiguïté de parcours dans le modèle et génèrent des résultats faux dans certaines restitutions.
- Les relations en pointillés sont des relations inactives et bien souvent dues à une ambiguïté de parcours... cf point précédent
- Une relation dans Power BI n'est pas du tout une jointure comme en SGBDR
- Une seule relation active à la fois peut exister entre 2 tables

Le modèle à privilégier est un modèle étoile avec des relations 1->*. C'est une table transactionnelle au centre et des tables référentielles autour.

[guen]

Merci pour ta réponse Nicolas
Effectivement, je suis avant tout un développeur en SGBDR et du coup, je patauge en BI...Habituellement, je n'ai pas de relation *<->* et j'efface les relations pointillés. Je vais réfléchir comment construire une table centrale plutôt mais dur dur...
Merci tout de même !
Bonne soirée (en belgique...)

guen

[Nicolas MENDEZ]

Oui ca fait toujours cet effet au début...


Tous tes relevés de données doivent aller dans ta table centrale, et les axes par lesquels tu veux les regrouper sont tes référentiels autour... (dates, ilots à priori ...)

Bon week end BI entre 2 match

[guen]

Bonjour Nicolas,

J'abuse un peu de ton temps et de tes compétences du coup car je ne suis pas sûr de mon coup....
J'essaye de construire un modèle en étoile et j'en suis là :

j'ai mis en table de fait centrale, ma table audit fusionnée avec la table audit_ilot (qui indique le ou les ilots concernés par l'audit) et audit_variable (qui comprend la réponse donnée à chacune des variables). j'ai peut-être intérêt à ce niveau à éclater cela en analyse croisée pour avoir une colonne par variable d'audit plutôt qu'une ligne... ce sera plus simple pour l'analyse ensuite... mais c'était même pas là ma question... J'ai mis ensuite les détails des ilots, variables, modèle d'audit et une table calendrier en dimension autour.
Je me pose la question sur la table exploitation (un ilot appartient à une exploitation et une exploitation peut avoir plusieurs ilots). J'étais tenté de conserver ma liaison entre la table ilot et exploitation (logique base de données..., actuellement inactive sur le modèle ci-dessus) mais je n'avais plus de modèle en étoile. j'ai donc reporté l'index de l'exploitation dans ma table de faits. Sauf que je ne peux plus du coup avec ce modèle analyser des éléments de parcellaire dans le même fichier (combien de surface d'ilot par exploitation, quelle surface par variété pour les exploitations d'un groupe donné par exemple) puisqu'elles ne sont plus liées... Est-ce que ça veut dire qu'il faut créer des fichiers (modèles) différents selon ce que l'on veut analyser ? je ne peux pas avoir un modèle unique ?
Et tant que j'y suis, j'ai une info numérique surface dans la table ilot qui sert souvent dans les analyses (somme de surface par...), cela veut dire que dans le contexte d'analyse d'audit ci-dessus, il faudrait que cet info soit plutôt dans la table des faits que dans une dimension ? (il me semble que l'on ne mets pas de mesure issue d'une dimension..)
Je patauge peut-être...
Merci de ton aide (ou quelqu'un d'autre bien-sûr !)
Guen

[Nicolas MENDEZ]

Salut Guen,

Je vois que ça a bien avancé et dans le bon sens à priori ...

Concernant la modélisation étoile, elle me semble plutôt super mis à part pour exploit/ilots comme tu l'indiques.

Pas possible de garder ton schéma avec la relation entre ilot et exploitation, car ce n'est plus une étoile !!! cette relation crée une ambiguïté de parcours et Power BI est assez prévenant à ce sujet, c'est pour cela qu'il la passe en pointillés, cad qu'elle est désactivée.

Du coup à y regarder un peu mieux, entre ilots et exploitations il y a un lien et le grain le plus fin est côté ilots.

Donc la table à conserver en dimension connectée à la table de faits, c'est ILOTS que tu viens fusionner avec exploitation. Autrement dit tu fusionnes Exploitation dans Ilots qui reste connecté aux faits.

Même si cela semble étrange à cause d'une redondance de données potentiellement importante dans ilots, c'est d'une efficacité redoutable dans Power BI car il s'articule autour d'un modèle Tabulaire (colonnes) et non en lignes ce qui permet dans ce cas un bon taux de compression de la donnée ( sur des volumétries importantes )

Ainsi tu préserves ta structure en étoile... CQFD


Dernier point tous tes calculs DOIVENT partir de ta table de faits...

Tiens nous informés

[guen]

merci pour ta réponse rapide et claire !
ça fait effectivement une sacré redondance des données et en plus, je ne vois pas du coup comment j'ajoute dans mon modèle la liaison entre l'exploitation et les groupes d'exploitation comme le bio par exemple (relation N à N qui se fait en BDD grâce à une table intermédiaire exploitation_groupe). il faudrait démultiplier tout cela au sein de la table ilot du coup ? c'est énorme. Pareil pour la relation entre les ilots et les signes de qualité (relation 1-N, un ilot pouvant avoir plusieurs signes de qualité)
Et si je comprends bien le principe du modèle en étoile, cela veut dire que si je veux analyser les interventions culturales réalisées sur les ilots (infos issues de la même base de données), cela constituerai logiquement une autre table de faits mais potentiellement liée aux mêmes dimensions (temps et exploitation-ilot), cela ne pose pas de pb ? j'ai lu qq part que l'on parlait de constellation...
Toujours est-il que je n'ai pas réussi non plus à résoudre mon problème initial de récupération de la dernière valeur d'audit avec ce nouveau modèle (pas trouvé mieux avec LASTNONBLANK...)...
Je crois que je ne suis pas fait pour la BI !