Héritage des propriétés d'un univers BO sous Business Query

[perleurferd]

Bonjour,

j'ai un problème d'utilisations d'objets agrégables sous BO :
1 - les requêtes que j'effectue via BO avec ces objets (agrégables : sum ou count) fonctionnent très bien lorsqu'elles sont exécutées sous BO
2 - par contre la même requête exécutée sous excel avec business query en partant du même univers Bo bien entendu n'effectue pas l'agrégation et retourne le résultat de la requête dans son détail sans réaliser l'agrégation

J'ai l'impression que Business Query ne tire pas partie de toutes les options des objets définis dans BO...
Quelqu'un s'est-il déjà retrouvé face à ce problème ?

[BzhCH]

Bonjour
tu as tout à fait raison. BusinessQuery ne fait que "déposer" le contenu du cube dans la feuille Excel. Il n'y a pas d'agrégation entre le cube et la feuille contrairement à BO qui agrège entre le cube et le bloc de présentation.
Il faut donc utiliser les fonctions Excel pour faire cela "à la main"
Bon courage!

[perleurferd]

Merci BzhCH de ta réponse.
En fait ce comportement ne m'arrange pas du tout du fait que certaine requêtes peuvent renvoyer plusieurs centaines de millier de lignes...

[BzhCH]

Oui, Excel étant limité à 65535 lignes...
Mais comme tu aurais voulu agréger, est-ce que tu ne peux pas le faire dans ta requête? Mais peut-être n'as-tu pas accès à la modification de ton univers?
Verifie bien que tes indicateurs sont bien agrégés dans l'univers, c'est-à-dire définis en SUM(table.colonne). C'est une règle impérative à appliquer dans Designer!

[perleurferd]

En fait j'ai la main sur l'univers via le designer.
Pourquoi je n'ai pas réalisé l'agrégation via la définition de la requête de l'objet c'est qu'en faisant ainsi j'ai des temps de répones beaucoup trop important sur la requête (c'est une requête avec jointures ouvertes sur trois tables) lorsque les indicateurs sont définis ainsi (le GROUP BY pouvant alors être réalisé sur une dizaine de champs répartis sur les trois tables. J'avais donc pris le parti de réaliser l'agrégation sous BO (les temps de réponses sont divisés par 4 voir 5).
Donc oui la solution par sum() dans la requête fonctionne mais elle n'est pas optimale pour BO.

[BzhCH]

Oui, je vois le pb
Quand tu parles de jointures ouvertes, ce n'est pas de jointures externes plutôt?
Donc 2 solutions à mon humble avis:
- ajouter des index dans les tables externes
- créer une table dérivée dans ton univers BO. Mais ça te fait modifier la définition des objets et ça ne t'arrange peut-être pas...
Question annexe: quel SGBD tu utilises?

[perleurferd]

Rebonjour,

déjà merci pour tes réponses...

En fait il s'agit bien de jointures externes et ouvertes (OUTER JOIN), la base de données que j'utilise est sql server 2000.
En fait pour optimiser le temps sous BO j'avais effectivement déjà travailler les index mais avec des gains de temps minimes finalement, donc l'agrégation sous BO m'avait finalement pas mal aidé...

Comme apparamment il n'y a pas vraiment de solution je vais essayer de revoir mes index.

[BzhCH]

Oui, je tedemandais si tu avais essayé les tables dérivées...
Si ta requête est fixe (pas d'invite), tu peux créer une table dérivée qui serait l'image exacte de ta query (copier/coller du SQL généré dans l'éditeur de requête).
A partir de là tu peux définir une nouvelle classe avec toutes les colonnes de ta table dérivée en ajoutant des agrégations à tes définitions SQL des colonnes indicateurs . Ta nouvelle query utilisera directement ces objets.
C'est un peu du bricolage mais ça marche bien en général.