Discussion :

[amy0o0]

Bonjour à tous,

J'avais déjà posté il y a plusieurs mois à propos de questions similaires, mais j'ai pu approfondir certaines choses et celà m'amène à me poser d'autres questions...
D'autant plus, que j'ai un avis divergent avec une autre personne qui débute également, et je voudrais bien clairifer la situation...

Alors voilà...
Déjà, pour résumer, voilà ce que j'ai compris et dont je suis sûre à 99% :
Si on fait un indicateur avec un select avg(valeur), la moyenne sera calculée dans la base de donnée. Par contre, on ne peut pas mettre une projection "moyenne", car sinon, on a la moyenne de la moyenne, et ce n'est pas pareil que la moyenne. Mais si on mets la projection "Aucune", on ne pourra pas faire des rapports avec des agrégations dans le rapport de manière dynamique. Donc, j'en ai conclu que si je veux un indicateur "moyenne de ma valeur", il faut que je procède ainsi : création d'un indicateur avec select "ma valeur" et avec comme type de projection "moyenne".
Est-ce que déjà, ce raisonnement tiens la route?
Ce qui me mets le doute c'est qu'un de mes collègues me soutient que finalement, c'est mieux de faire la moyenne dans la BDD, et qu'il faut se servir le moins possible des projections... Alors que moi, je pense que justement, tout l'intérêt de BO, c'est les projections, non?
Par contre, il me semble, que si on fait un indicateur avec "select max(ma valeur) et avec comme projection "Max", ça ne pose aucun souci, puisque un max de max, reste le max. Idem, pour le min, pour le count, avec projection somme...

Ensuite, la question que je me pose, c'est comment se comporterait un rapport comportant plusieurs indicateurs avec des projections différentes? Est-ce que ça se passe sans problème? Dans un tableau "simple? Dnas un tableau croisé?

La dernière question que je me pose, est qu'on m'a demandé de faire un indicateur qui représenterait l'écart type d'une dimension. Or, il n'y a pas de type de projection "écart-type" dans BO. Du coup, je me demande ce qui est le mieux à faire entre:
- faire un indicateur avec "select stddev(valeur)" et projection "aucune" (mais pas d'agrégation possible)
- ou bien, ne pas faire d'indicateur, mais le calculer à partir d'autre valeur. Mais dans ce cas, je me pose une autre question... Pour faire le calcul, il me faut la donnée "ma valeur". La faut-il en tant que dimension? ou bien la faut-il en tant que "indicateur"? Si il me la faut en tant qu'indicateur, il faut que je mette un type de projection, et là, je pense que ce n'est pas approprié, mais peut être que je me trompe. Si je fais le calcul dans le rapport, à partir de la dimension "ma valeur", si j'ai bien approfondis la question, il faut préalablement que je crée une variable dans le rapport BO, car on ne peut pas faire de calcul à partir d'une dimension.
Là aussi, est-ce que mon raisonnement et ma connaissance de BO sont ils bons, ou bien, pas du tout?

Merci d'avance pour votre aide et vos éclaircissements !
En espérant que vous avez suivi mon raisonnement quelque peu tortueux

[TomDuBouchon]

Bonjour amy0o0,

Effectivement je vois que tu as gardé en tête des éléments de la discussion qu'on a eu il y a quelques temps déjà.

Donc, tu as bien identifié un des pièges du designer, qui est celui des calculs des moyennes. Car il s'agit d'un cas un peu particulier.
Avant d'aborder ce point, je reprends la phrase suivante :

un de mes collègues me soutient que finalement, c'est mieux de faire la moyenne dans la BDD, et qu'il faut se servir le moins possible des projections... Alors que moi, je pense que justement, tout l'intérêt de BO, c'est les projections, non?

Et bien, personne n'a tort ou raison, car tu pourras te rendre compte à l'usage que dans certains cas il vaut mieux calculer directement dans la BDD, cela générant un GROUP BY dans la requête ce qui sera nettement plus rapide qu'une fonction de projection. En revanche, il sera des fois nécessaire d'avoir le détail valeur par valeur et que l'opération soit effectuée sur le rapport.

Dans le cas de la moyenne, tout dépend. Un indicateur de type avg(valeur) sera tout indiqué s'il faut calculer une seule moyenne globale (dans ce cas là, la projection sera "Aucune" et ne posera pas de problème)
Par contre, à partir du moment où tu auras plusieurs moyennes à ramener, effectivement la fonction de projection pose problème.
Personnellement, je préfère faire simplement un SELECT et laisser la fonction de projection faire la moyenne dans le rapport.

c'est comment se comporterait un rapport comportant plusieurs indicateurs avec des projections différentes? Est-ce que ça se passe sans problème?

Pour ne pas avoir de problème, j'ai préféré laisser cochée l'option de l'univers "Instructions SQL multiples pour chaque indicateur" (dans Designer : Fichier > Paramètres > SQL)

Du coup, je me demande ce qui est le mieux à faire entre:
- faire un indicateur avec "select stddev(valeur)" et projection "aucune" (mais pas d'agrégation possible)
- ou bien, ne pas faire d'indicateur, mais le calculer à partir d'autre valeur. Mais dans ce cas, je me pose une autre question... Pour faire le calcul, il me faut la donnée "ma valeur". La faut-il en tant que dimension? ou bien la faut-il en tant que "indicateur"?

Je te déconseille stddev() car tu vas retomber sur la même problématique que pour avg().
Il vaut mieux donc créer un indicateur avec un SELECT simple et une fonction de projection Somme par exemple.
Il faut bien garde à l'esprit que lorsqu'un indicateur est en SELECT simple, toutes les valeurs sont ramenées dans le cube du fournisseur de données. La fonction de projection n'est là que pour l'affichage.
Donc, si toutes les données sont dans le fournisseur, l'écart-type sera bien calculé sur toutes les valeurs.

[amy0o0]

Merci pour cette réponse qui me permet d'avancer...

Autres questions, suite à ta réponse...
Tu dis :

Je te déconseille stddev() car tu vas retomber sur la même problématique que pour avg().
Il vaut mieux donc créer un indicateur avec un SELECT simple et une fonction de projection Somme par exemple

Pour quoi une projection "somme"? Est-ce qu'une somme d'écart-type donne un écart-type? Ne vaudrait-il pas mieux mettre un type de projection "Aucun" ?
J'avoue que ma connaissance sur ce qu'est un écart-type c'est un peu évanouï...


D'autre part tu dis:

Et bien, personne n'a tort ou raison, car tu pourras te rendre compte à l'usage que dans certains cas il vaut mieux calculer directement dans la BDD, cela générant un GROUP BY dans la requête ce qui sera nettement plus rapide qu'une fonction de projection. En revanche, il sera des fois nécessaire d'avoir le détail valeur par valeur et que l'opération soit effectuée sur le rapport.

Du coup, là je me dis, que c'estt vraiment chouette de faire sleect max, avec projection max, idem pour le min, et ce que je disait dans mon post d'origine pour les dénombrements. Au moins, ça a l'avantage des 2 non?
Et donc, il reste effectivement, le problème des moyennes, et donc si je résume, 2 choix:
- soit faire select projection moyenne
- soit faire select avg() projection aucune.
Tu utilises préférentiellement le premier choix.
Ne serait-ce pas un confort pour l'utilisateur de deski d'avoir finalement 2 indicateurs, un avec le 1er choix et un avec le 2eme choix? Je te pose la question, car comme tu fais un peu plus de Deski, tu as un retour d'expérience plus important que le mien. Peut être est-ce plus perturbateur pour l'utilisateur final...
Je sais, je me répète, mais comme je veux êttre sûre d'avoir tout compris, je reformule avec mes mots :-)

L'avantage du type de projection, c'est qu'il me semble que la mise en forme, notamment, dans des tableau croisés se fait mieux, non?

Merci encore à l'avance...

[TomDuBouchon]

Pour quoi une projection "somme"? Est-ce qu'une somme d'écart-type donne un écart-type? Ne vaudrait-il pas mieux mettre un type de projection "Aucun" ?

Dans ce cas, aucune différence. Pour te l'expliquer simplement : Lorsque tu crées un indicateur avec un SELECT simple, dans ton fournisseur de données tu pourras obtenir par exemple :
Dimension | Indicateur
toto | 2
toto | 3
titi | 4
titi | 1
Et à l'affichage de ton rapport, tu auras :
toto | 5
titi | 5
Mais cela n'empêche pas que toutes les valeurs de Indicateur ont été ramenées.
Donc si tu fais un écart-type, tu auras bien :
toto | 1
titi | 3
... même si tu as une fonction de projection Somme.

Ne serait-ce pas un confort pour l'utilisateur de deski d'avoir finalement 2 indicateurs

C'est justement ça qui est générateur d'erreur, car il ne saura pas lequel utiliser... Et si tu dois expliquer qu'il faut en utiliser un que si on veut faire une moyenne globale, tu n'as pas fini.
A mon avis mieux vaut laisser uniquement celui en SELECT simple avec fonction de projection.

Du coup, là je me dis, que c'estt vraiment chouette de faire sleect max, avec projection max, idem pour le min, et ce que je disait dans mon post d'origine pour les dénombrements. Au moins, ça a l'avantage des 2 non?

Tout à fait... Hormis pour les moyennes justement

[amy0o0]

En fait, je suis désolée...
Mais je n'ai rien compris à ton exemple avec les écarts type...
ou bien, je n'ai pas bien exposé ma question...

Dans ce que je disais, mon indicateur c'est "select stddev(ma_valeur)" avec projection aucune. Car, comme ça, ça me ramène quand même mon écart type calculé en base avec le group by qu'il faut. Mais je suis obligé de mettre projection aucune, sinon, je vais avoir des agrégations dans mon rapport qui ne représenteront plus l'écart type, non?

Toi, tu parlais peut être plus, de faire un indicateur select (ma_valeur) projection somme, avec ensuite, dans le rapport, l'ajout d'une calcul "écart-type". C'est ça?

[TomDuBouchon]

Toi, tu parlais peut être plus, de faire un indicateur select (ma_valeur) projection somme, avec ensuite, dans le rapport, l'ajout d'une calcul "écart-type". C'est ça?

Tout à fait

[amy0o0]

Ah oki...
Mais je suis contente, c'est que j'ai bien suivi !

Du coup, j'ai fait la chose suivante :
un indicateur select stddev (ma_valeur) avec projection aucune
et un indicateur "valeur brute" avec select (ma valeur) avec projection aucune...

Aucune projection, car je me disais que ce serait plus compréhensible pour l'utilisateur, par rapport à l'intitulé "valeur brute".

Tiens, d'ailleurs, juste pour me conforter dans mon apprentissage BO... On ne peut faire des calculs et des variables qu'à partir d'indicateur, et nnon pas de dimension dans son rapport BO, non? Ou bien, je me goure totalement.
Du moins, je pense, que si on veut faire des calculs sur une dimension, il faut d'abord créer une variable de type indicateur qui est égale à la dimension, non?

[TomDuBouchon]

On ne peut faire des calculs et des variables qu'à partir d'indicateur, et nnon pas de dimension dans son rapport BO, non? Ou bien, je me goure totalement.
Du moins, je pense, que si on veut faire des calculs sur une dimension, il faut d'abord créer une variable de type indicateur qui est égale à la dimension, non?

Non, pas de restriction, tu peux faire des calculs à partir de n'importe quel type d'objet. Cependant, il y aura des fois où tu auras besoin de transformer une dimension en indicateur pour réaliser le calcul souhaité effectivement.

[amy0o0]

il me vient une autre question...

Lorsuq'on crée une vraible sur Deski, on spécifie si c'est une dimension, un indicatuer, ou une information.
Si on spécifie que c'est une indicateur, on ne spécifie pas le type de projection. Que fait BO en réalité?

[TomDuBouchon]

Il n'y a pas de fonction de projection attenante. C'est la fonction que tu définis dans ton indicateur qui est importante.

Par exemple, si tu crées une variable de de type indicateur avec la formule :

Code :

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

=<Dimension>

Cela reviendra à avoir une fonction de projection "Aucune" (Bien que côté terminologie, la notion de "fonction de projection" ne serait pas correcte ici)

Si tu veux avoir une "fonction de projection" Somme, il faudra créer la somme dans la formule :

Code :

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

=Somme(<Dimension>)

[amy0o0]

OK!

Merci pour toutes tes réponses...

A force, je vais finir par devenir "experte" BO
Même si je crois que ce n'est pas pour tout de suite.