Discussion :

[Irmato]

Bonjour,

contexte général :
Designer
Univers
Espace des catégories
objet - clique droit - Propriété de l'objet
1er onglet "Définition" "
2ème onglet "Propriété"

Je voudrais savoir s'il est indispensable de rajouter manuellement la fonction de calcul (SUM par ex) devant un objet dans la partie SELECT de l'onglet "Définition" que l'on a paramétré en tant qu'indicateur et auquel on a attribué la fonction "somme" dans le 2ème onglet "Propriété".
Tels qu'ont été constitués mes indicateurs actuellement, certains contiennent une fonction dans Select, d'autres non.
Dans B.O., chacun des indicateurs (avec ou sans fonction) ramènent des résultats. La présence de SUM dans le langage SQL change-t-elle les résultats ? Quelle est la différence ?

D'avance merci

Irmato

[Bruno2r]

Bonsoir,
Compte tenu que la fonction Somme est précisé en cas d'agrégation, elle n'est en effet pas utile sur un objet indicateur simple. J'entends par simple dépourvue de fonction.
Exemple :

Code :

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

SELECT TABLENOM.CHAMPNUMERIQUE

En revanche il peut, dans certain cas, être utile de placer une fonction de sommation dans le select d'un objet pour le placer à l'intérieur d'une autre fonction
Exemple la fonction @Aggregate_Aware():

Code :

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

SELECT @Aggregate_Aware(sum( TableAnnée.Valeur), sum( TableMois.Valeur), sum(TableDétail.Valeur)

[raphoun07]

Bonjour,

je sors de la formation Designer, et il nous a été dit dans cette formation que le "sum" dans le select est mieux du point de vue nombre de lignes retournées, performances...
Si on ne le met pas, la somme sera bien effectuée grâce à la fonction "Somme" de projection, mais le formateur estimait important de mettre le "sum" dans le select.

Je ne suis pas sûr que ma réponse n'arrive pas très longtemps après la bataille... mais ça peut servir à d'autres

[atb]

Bonjour,
Je dis peut être des bêtises mais sum au niveau sql et propriété de l'indicateur sont deux choses différentes, en effet;
Au niveau select --> ça va être transmis au sgbd qui s'en charge.
Au niveau de propriété c'est le comportement de l'indicateur dans son contexte dans le rapport.
Elles ramènent le bon résultat certes, mais pour tester il suffit de créer un indicateur qui ramène l'âge par exemple et de spécifier qu'il est une sommation, et vérifier le sql générer !
Donc un mon avis il faut utiliser le sum dans le select et propriété si on veut un comportement correct dans le rapport.

[bastoonet]

Le mieux si on veut un objet qui ramène toujours la somme de quelquechose c'est de le calculer dans l'alimentation de sa BDD (si possible).

Sinon la definition de sum(table.champs) dans la définition SELECT du SQL de l'objet peut etre bien, mais elle peut être un frein à la consitution de rapport complexes car cette objet ne pourra pas toujours etre combiné dans une requete avec d'autre objet, à l'inverse de l'objet sans le SUM !!

Je suis un partisan du calcul à l'affichage BO si on ne peut pas le faire à l'alimentation !!!!!!

[Bruno2r]

Le mieux si on veut un objet qui ramène toujours la somme de quelquechose c'est de le calculer dans l'alimentation de sa BDD (si possible).

Sinon la definition de sum(table.champs) dans la définition SELECT du SQL de l'objet peut etre bien, mais elle peut être un frein à la consitution de rapport complexes car cette objet ne pourra pas toujours etre combiné dans une requete avec d'autre objet, à l'inverse de l'objet sans le SUM !!

Je suis un partisan du calcul à l'affichage BO si on ne peut pas le faire à l'alimentation !!!!!!

Bonjour à vous deux,
bastoonet enfin te revoili
Je ne vois pas à quoi tu fais allusion en évoquant l'objet qui ne pourrait être combiné ...
La fonction somme dans le sql de l'objet ne change strictement rien à l'objet ni à ses capacités de combinaison ni à ses propriétés :
Le SQL ramène un objet numérique résultat du niveau d'agrégation.
Dès lors que le niveau le plus détaillé de la table n'est pas ramené par abandon d'une dimension (ou d'une colonne) le SQL pratique le group by et la somme (sauf précision contraire prévue dans designer).

Il y a deux niveaux d'application d'une fonction d'agrégat :
Dans Designer, sur l'objet (traduit en group by et sum dans le SQL) qui détermine les données récupérées
Dans Reporter pour préciser le sort des données à l'affichage.

Qu'en pensez-vous ?

[Irmato]

Hmm, mon petit niveau sur B.O. ne me permet pas de comprendre toute la siginification de vos commentaires

Je n'ai pas compris ceci :
"Au niveau de propriété c'est le comportement de l'indicateur dans son contexte dans le rapport." (message d'atb)

et cela :
Dès lors que le niveau le plus détaillé de la table n'est pas ramené par abandon d'une dimension (ou d'une colonne) le SQL pratique le group by et la somme (sauf précision contraire prévue dans designer). message de Bruno2r

Par contre, j'ai pu constater que les résultats du rapport différaient selon la présence du sum dans le sql ou non. J'ai également dû supprimer le sum(table.champs) dans le group by du sql généré par BO pour que la requête s'exécute normalement.
Comment cela se fait-il que, dans désigner, le sum se positionne de manière aléatoire devant l'indicateur dans la clause SELECT ??

Irmato

[nevada_smith]

Bonjour à tous

Je pense qu'il faut repréciser les choses.
Il faut distinguer la partie SQL qui sera générée lors de l'exécution de la requête et la fonction de projection qui gère le comportement de l'indicateur dans le document BO.
Dans la partie SQL, on peut mettre la fonction d'agrégation de base de données ce qui fera travailler le moteur SGBD et qui nécessite pour BO de rajouter une clause GROUP BY lors de l'exécution (mais c'est transparent pour nous):

Code :

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

1
2
3
4
 
SELECT TABLENOM.CHAMPTEXTE, SUM(TABLENOM.CHAMPNUMERIQUE) 
FROM TABLENOM
GROUP BY TABLENOM.CHAMPTEXTE

On peut aussi s'abstenir de mettre cette fonction mais dans ce cas, il n'y a pas d'aggrégation au niveau du moteur SGBD et c'est BO qui s'en chargera (personnellement, je n'aime pas trop cette solution car de performance médiocre et générant des fichiers BO plus gros)

Code :

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

1
2
3
 
SELECT TABLENOM.CHAMPTEXTE, TABLENOM.CHAMPNUMERIQUE
FROM TABLENOM

Mais pour se charger de l'agrégation des données et réaliser les cumuls correctement, BO a besoin qu'on lui définisse une fonction d'agrégation (onglet propriété de l'indicateur). Cette fonction d'agrégation déterminera le comportement de l'indicateur au sein du document BO. Par exemple si l'on crée un tableau PAYS, VILLE, CHIFFRE D'AFFAIRE, et que l'on supprime la colonne VILLE, il faut que BO sache comment doit se comporter l'indicateur CHIFFRE D'AFFAIRE pour que le cumul au niveau PAYS soit correct. C'est la fonction d'agrégation qui s'en charge.

Bien sur, c'est la fonction SOMME qui est utilisée à 99%, parfois la fonction NOMBRE, les autres étant extrêmement rares.

[doc malkovich]

lorsque j'ai commencé BO, je ne mettais pas de fonction sum dans le sql - normal, je n'avais pas eu de formation, j'ai appris sur le tas ( la dure vie des ssii )
les rapports étaient lourds, et on avait des problèmes de performance, et j'ai découvert qu'on pouvait rajouter des sum, et là ma vie de designer junior a changé ... c'était génial, les requêtes étaient performantes, tout le monde était heureux
puis sont arrivés les utilisateurs qui avaient des requêtes complexes où ils voulaient mettre l'indicateur sommé en filtre mais qui ne marchaient pas ( par exemple pour avoir les magasins qui ont des clients riches qui font des achats de plus de 1000 FF ( bin oui, c'était avant l'euro ), mais sans afficher les clients ). Là le sum() ne marche pas car on aggrège sur le magasin, et tous les magasins ressortent
depuis je crée 2 indicateurs :
- un indicateur sommé ( en p'tit chewinggum rose )
- un indicateur non sommé ( en ch'tite pyramide bleue )
et j'explique aux utilisateurs à quoi ça sert, généralement ça va, ils ne comprennent pas forcément toutes les subtilités des arcanes de bo, mais je n'ai plus de problème et je peux m'endormir tranquille le soir...

Voilà, merci de m'avoir laissé raconter ma vie ( et peutêtre lu jusqu'au bout ? )
Désolé de m'être répandu