[V6] Doublons dans indicateurs sous designer [Résolu]

[Cespa]

Bonjour à tous

Je me décide à poster car j'ai un gros problème dont je n'ai toujours pas trouvé la solution, malgré de nombreux essais et recherches sur le net.

Je précise que je dois faire tout mon travail en amont dans l'univers, pour que les utilisateurs finaux puissent faire des requêtes très simples sous BO.

Je vais essayer d'expliquer mon problème par un exemple. J'ai deux tables :

- Table Individu :
Un champ ID et un champ pondération.
Mon univers sera utilisé par des statisticiens, donc on prend le champ pondération pour calculer le nombre d'individus. (un individu compte pour 1,5 par exemple)
- Table Emploi :
Contient le champ ID de l'individu, un champ salaire, et un champ autre. Le champ "autre" et l'ID forment la clé de la table

Dans la table "emploi", on peut trouver plusieurs occurrences d'un même individu (à cause du champ "autre" qui peut prendre plusieurs valeurs).

J'ai deux choses à faire à partir de cet univers :
- calculer le nombre d'individu : pour cela il faut sommer les valeurs de "pondération".
- calculer le salaire moyen pondéré : autrement dit faire un produit salaire*pondération.

Le gros problème est qu'un même ID apparaît plusieurs fois dans la table Emploi, du coup en utilisant des indicateurs basiques de somme, j'obtiens des chiffres erronés.

Pour le salaire, j'ai réussi à bidouiller un indicateur qui fait sum(salaire*pondération)/count(distinct ID), et ça m'a l'air de marcher, mais dès que je le lie à l'indicateur du nombre pondéré d'individu, ça me fait n'importe quoi.

Et pour ce nombre pondéré, rien à faire, j'ai essayé d'utiliser les cardinalités dans l'univers, cela ne change rien apparemment. J'ai aussi tenté de faire un indicateur de somme sur la formule "max(pondération)" mais cela ne donne que le max sans sommer. J'ai aussi essayé de passer par des tables d'alias avec des jointures complexes genre "select max... where..." mais sans succès, on me comptait toujours les doublons.

Bref, je suis perdue j'espère avoir été un peu claire dans mon explication. Si les cardinalités marchaient dans designer, je n'aurais pas de problème je pense, mais là je n'ai pas réussi à trouver une solution de remplacement.

Est-ce que quelqu'un a déjà rencontré ce problème, ou a une idée pour le résoudre ? De mon côté, j'ai l'impression de ne plus rien avoir en stock.

Merci de votre aide.

[TomDuBouchon]

Bonjour,

En fait, pour t'en sortir, il faut que tu reviennes au niveau des tables, pour ensuite appliquer ta moyenne.

Si tes tables sont liées sur ID, il faut que tu crées un objet (salaire pondéré) de type indicateur, avec fonction de projection 'Aucune', et avec la formule suivante :

Code :

avg(INDIVIDU.PONDERATION*EMPLOI.SALAIRE)

[Cespa]

Que veux-tu dire par revenir au niveau des tables ?

Merci pour la fonction, mais malheureusement je ne peux pas l'utiliser dans le cas présent. Je dois calculer ma moyenne en fonction du coefficient de pondération, en gros ça doit suivre la formule :
(EMPLOI.SALAIRE*INDIVIDU.PONDERATION)/SUM(INDIVIDU.PONDERTION)

Dans cet exemple :

Deux enregistrements dans INDIVIDU :
ID1, PONDERATION = 2
ID2, PONDERATION = 3

Deux enregistrements dans EMPLOI :
ID1, AUTRE1, SALAIRE=1000
ID2, AUTRE2, SALAIRE=1200

Je dois obtenir cette moyenne là :
(1000*2 + 1200*3)/(2+3) = 1120

Alors qu'avec la formule classique avg, j'aurai (1000*2 + 1200*3)/2 = 2800


Pour en revenir à mon vrai problème, c'est que j'ai des enregistrements de ce type dans EMPLOI :
ID1, AUTRE1, SALAIRE=1000
ID1, AUTRE3, SALAIRE=1000
ID2, AUTRE2, SALAIRE=1200

Du coup mes indicateurs compte le salaire et la pondération d'ID1 une fois de trop.

Désolée, j'ai un problème compliqué. Je vais continuer à chercher une solution, mais si quelqu'un a une idée, je suis preneuse !

[TomDuBouchon]

Que veux-tu dire par revenir au niveau des tables ?

Je voulais dire faire appel aux tables et pas aux objets dans la définition de la formule.

Pour en revenir à mon vrai problème, c'est que j'ai des enregistrements de ce type dans EMPLOI :
ID1, AUTRE1, SALAIRE=1000
ID1, AUTRE3, SALAIRE=1000
ID2, AUTRE2, SALAIRE=1200

Du coup mes indicateurs compte le salaire et la pondération d'ID1 une fois de trop.

Cela veut-il dire que SALAIRE ne doit être compté qu'une seule fois puisqu'il correspond à ID1 ? Dans ce cas, comment se fait-il qu'il soit dans la table EMPLOI et pas INDIVIDU ?

[Cespa]

En fait, à la conception du MCD, il y avait plusieurs tables liées par une relation :

INDIVIDU relié à AUTRE (qui comportent des données sur l'emploi), et un individu peut avoir plusieurs données sur son emploi (donc cardinalité 0,n / 0,n).

Dans cette relation, il y avait l'indicateur SALAIRE. Et en passant au MPD, cette relation est devenue une table de fait EMPLOI, avec un salaire, mais plusieurs occurrences d'ID.

Je suppose que cette conception n'a pas été très bien pensée, mais il m'est impossible de revenir dessus maintenant.

Sinon, je pense devoir me tourner vers la solution de secours : n'utiliser que des objets de type dimension dans l'univers. Les calculs se feront dans le document BO, et je pense que là ce sera plus simple d'obtenir des résultats corrects. Mais ça m'embête beaucoup, parce qu'il va falloir expliquer ça aux utilisateurs, et c'est pas gagné.

[TomDuBouchon]

Personnellement, je te conseille de faire autrement : en passant par une table dérivée.

Tu reprends le SQL de ta table EMPLOI, et tu crées donc une table dérivée nommée "SALAIRE" par exemple.

Le SQL doit ressembler à :

Code sql :

SELECT ID, SALAIRE FROM EMPLOI GROUP BY ID, SALAIRE

ainsi que d'autres informations si tu en as besoin, mais sans le AUTRE, afin que tu n'es qu'une seule ligne par ID.

Ensuite, tu lies cette nouvelle table avec ta table INDIVIDU sur ID.

Enfin, il ne te reste plus qu'à créer l'objet avec le calcul que tu souhaites.

[Cespa]

Merci pour cette réponse l'idée est bonne et ça me permettra de ne pas modifier l'existant, mais j'ai quelques scrupules à le faire car ça ne fera peut-être pas très propre dans le datawarehouse de ma boîte.

Entre temps, j'ai un peu creusé l'idée de corriger mes calculs sur BO, et j'ai testé l'option "Sans doublons" dans la requête.
En cochant cette option, j'ai de bons résultats en intégrant dans la requête INDIVIDU.PONDERATION et EMPLOI.SALAIRE (en tant qu'objet indicateur dans l'univers). En revanche, dès que j'ajoute EMPLOI.AUTRE, les calculs sont faux dans le tableau si on n'affiche pas la colonne "AUTRE".

Malgré ce petit détail, je me dis que l'option "sans doublons" est une bonne alternative, et que je pourrai sensibiliser les utilisateurs à faire attention à mettre dans le tableau tout ce qu'ils mettent dans la requête.

Pour faciliter la chose, est-il possible à partir de l'univers, de forcer l'option "Sans doublons" pour toute les requêtes ? Car je vois déjà venir les utilisateurs qui oublieront de cocher, et qui publieront des stats fausses.

[TomDuBouchon]

Malheureusement, pas à ma connaissance

[Cespa]

Merci quand même

Je vais rester sur l'idée d'utiliser l'option "Sans doublons", et prévenir mes utilisateurs des règles pour bien faire leurs requêtes. En espérant que ce ne soit pas une gymnastique trop compliquée.

La prochaine fois, il faudra mieux penser la conception des tables dès le départ.

[Julien59]

Envoyé par Cespa

La prochaine fois, il faudra mieux penser la conception des tables dès le départ.

C'est la base du décisionnel
Par contre, je te conseille d'utiliser la table dérivée comme te l'a conseillé Tom.
Les utilisateurs n'écoutent pas toujours (pas souvent) ce qu'on leurs dit.
Au moins ils pourront utiliser leurs objets sans vraiment se préoccuper de savoir si la case sans doublons est cochée ou non...
A toi de voir