BO - Requête trop volumineuse

[Alexeyev]

Bonjour,
Je suis novice sur BO et je suis façe à un problème.
J'ai une requête qui ramène une série de contrats (beaucoup !) sur une période donnée. Chaque ligne (chaque contrat, donc) possède une vingtaine d'informations (type de crédit, montants, taux, etc...).
BO agrège les lignes similaires pour réduire le nombre de ligne, ce qui est important car nous ne pouvons pas traiter un nombre de lignes trop grand.
Mon problème :
J'ai besoin de rajouter une information, le taux client. Cette information existe, bien sûr, mais je ne peux pas la rajouter tel quel dans la requête, parce que ce taux étant si particulier au contrat, cela empêche BO d'agréger suffisament les données, et on se retrouve avec un nombre de lignes bien trop grand.
Je voulais savoir si il était possible de faire un réquête "à deux étages"; de faire un requête sur une autre pour permettre une agrégation plus grande en intégrant le taux client dans un premier temps, puis en l'agrégat par la suite...
Merci de vos réponses si vous avez une idée !

[bastoonet]

Tu peux parfaitement faire plusieurs requetes dans ton rapport !!! Et cumuler les informations ! (créer un nouveau fournisseur de donnée); il faut alors au moins un objet commun entre tes 2 requetes !!

Ex :
Requete 1 : objets <A> <B><C>
1 X oui
2 Z non

Requete 2 : objets <A> <D><E>
1 + 10€
2 - 20€
3 - 50€

Affichage tableau
<A> <B><C> <D> <E>
1 X oui + 10€
2 Z non - 20€
3 - 50€


BO va lier par défaut les objets qui ont le meme nom dans la requete !!!
Tu peux vérifier ou modifier les lien en allant dans "visualiser les données" (cube) et en selectionnant un objet puis en allant dans l'onglet définition !!

[BzhCH]

Je ne suis pas certain de bien comprendre, mais si tu as des lignes identiques et que tu veux agréger tu devrais forcer le DISTINCT dans ta requête pour ne pas avoir de doublons... (Editeur de requête/bouton Options/Cocher Pas de doublons)
Est-ce que cela ne peut pas t'aider?

[Alexeyev]

Oui, je suis tout à fait d'accord avec ce que tu dis, mais le fait d'avoir 2 requêtes parallèles qui alimentent le même rapport, en somme, ne me permet de réduire le nombre de lignes affichées !

En fait, j'ai besoin du taux client dans ma requête pour le multiplier par un montant (déjà présent dans la requête) et calculer un ratio.
Les contrats sont déjà agrégés quand leurs caractéristiques sont proches (ie des groupes de 2 à 50 contrats seulement, vu le nombre de critères, 17 !).

Le problème est que si j'introduis en plus le taux client, qui est propre à chaque contrat ou presque, cela revient à raisonner "au niveau contrat" et non plus au niveau des agrégats de BO, et alors le nombre de lignes passe de quelques centaines de milliers à plus de 6 millions, ce qui est trop grand pour le traitement ultérieur.

Donc l'idée serait de construire une requête (ou plusieurs, ou n'importe quel système...) qui permettrait de conjuguer deux avantages a priori contradictoires :
- avoir le taux client pour calculer ce fameux ratio
- conserver le nombre de ligne actuel (ce qui interdit de raisonner au niveau contrat)

Je ne sais pas si je suis bien clair, la question est un peu épineuse !

[Alexeyev]

En réponse à BzhCH, et pour illlustrer mon propos, voiçi toutes les entêtes de colonnes dans la requête :

Catégorie de taux client, Code aléa, Libellé d’aléa, Code convention en cours contrat, Libellé convention, Code produit, Libellé produit, Période d’analyse, Mois aléa, No TS, Code cne/cnr/ce, DA en années, Niveau 60, No enveloppe, Type de taux TVI, Devise capital ISO, Nb contrats [note : compte le nombre de contrats agrégés dans le ligne]; Libellé mode d’amort, Capitaux Moyens Valeur [à partir de cette colonne ces montants sont agrégés], Capital restant dû avant aléa, Montant débloqué, Encours date bilan, Montant autorisé, CMV x Taux d intérêts client, CMVxTVI total du contrat, Intérêts acquis

Chaque contrat a de multiples caractérstique, si bien que peu sont semblables... les lignes ne sont pas des doublons, car chacune correspond à un contrat, mais quand les contrats ont les même caractéristiques, ont les met sur la même ligne (agrégation) et leurs montant s'aditionnent, ne donnant plus qu'un chiffre total.

[BzhCH]

Donc ce sont tes objets qui ne sont pas correctement définis dans l'univers
Ton capital restant par exemple ne doit pas être défini comme Table.ColonneMontant mais comme Somme(Table.ColonneMontant)
Ainsi ce sera ton SGBD qui fera l'agrégation et non pas BO.

[Alexeyev]

Le truc, c'est qu'on veut justement que ce soit BO qui agrège, parce que les données non agrégés font péter notre base (gérée sous Access, qui elle-même aliment un TCD dans Excel).

BO gère bien les grands nombres de données, mais Access a une limite... en l'occurence, quadn on importe des données non agrégées, au vu de la quantité de données, la base dépasse 1 Go et boum ! Ca pète...

[BzhCH]

Je ne comprends pas très bien... Tes données sont déjà dans Access ou pas?
Si oui, je ne vois pas où quel problème pose l'agrégation...
Explique-moi un peu le cheminement des infos

[Alexeyev]

Le cheminement est simple : la requête est faite dans BO, elle sort des données, disons, "brutes", puis celles-ci sont importées dans Access pour y être traitées, et enfin cette base Access alimente un tableau croisé dynamique dans Excel, notre principal outil de travail.

L'arnaque, c'est que si je mets le taux d'intéret client dont j'ai besoin tel quel dans la requête BO, le niveau d'agrégation des données diminue énormément (puisque le taux client, par définition ou presque, est propre à chaque contrat, et donc il y a peu de chances de trouver deux contrats avec 2 taux identiques à agréger), et donc le volume des données générés par BO est trop important pour Access : la base attient ou dépasse 1Go, et le plus souvent elle crashe...

Donc le challenge est d'obtenir une requête BO qui inclue le taux client, mais qui concserve le même niveu d'agrégation et donc le même volume de données (nombre de lignes).
Je ne sais pas si c'est possible mais c'est ce que me demande mon boss, donc...

[BzhCH]

Alors peux-tu me dire d'où viennent les données que tu vas lire depuis BO?
Tu utilises un univers?

[Alexeyev]

Oui, j'utilise un univers, il s'agit de l'une des bases de données de l'entreprise... l'univers et la requête existent depuis bien longtemps, bien avant que j'arrive... en quoi cela influe-t-il sur le problème ?

[BzhCH]

J'essaie de comprendre!
Donc, si je comprends bien,
- tu fais une requête dans BO qui te ramène de milliers (millions?) de ligne
- tu agrèges cela dans un tableau BO qui te diminue le nombre de ligne en agréageant (par des sommes) lorsque les critères sont identiques,
- tu exportes le résultat vers Access (peux-tu me dire comment?)
- ça fonctionne
- mais quand tu ajoutes un critère, l'agrégation est moindre et ça pète dans Access ...
C'est juste?

[Alexeyev]

C'est exactement ca... pour exporter la requête, on enregistre le résultat dans un fichier texte qu'on charge dans Access, tout bêtement.
Le nombre de lignes non agrégé est d'environ 6 millions...

On est obligé de traiter ce résultat dans Access car on doit le croiser avec de nombreuses autres données qui ne sont disponibles que dans des tables Access, dans la même base ou en liaison avec d'autres, c'est assez complexe comme architecture...

[BzhCH]

Ouais!...
Le problème est donc entre le fichier texte et Access! Et je ne vois pas comment BO peut t'y aider car le nombre de lignes que tu obtiens semble incompressible.
Ce que j'essaierai de faire (je reviens à ma théorie du début), c'est de modifier l'univers pour que l'agrégation se fasse sur le serveur (le 1er, pas Access) en redéfinissant les montants en Somme(Table.Colonne) au lieu de Table.Colonne comme cela semble être le cas actuellement.
De là, je devrais récupérer dasn le cube (résultat de la requête) le même nombre de lignes que dans le tableau que tu as aujourd'hui.
Et j'agirais alors depuis le cube pour en exporter les données directement vers une table de ta base Access. Pour cela:
- aller dans Gestionnaire de données (icone Rubik's cube)
- sélectionner la requête
- cliquer sur Exporter
- sélectionner Export vers SGBD, en y entrant une DSN (source ODBC pointant vers ta base Access par exemple)
Je pense cette solution beaucoup plus efficace que ce que tu fais actuellement et moins gourmande en ressources Access.

[Alexeyev]

Si je comprends bien, il faut que lorsque je clique sur un champ agregé dans le rapport, il affiche la formule (par exemple) :
=Somme(<Capitaux Moyens Valeur>)

Si c'est bien ca que tu me dis, alors c'est déjà le cas pour tous les champs agregés.
A mon sens, le problème vient du fait qu'inclure une nouvelle information aussi précise que le taux client empechera de toute façon d'agréger les lignes.

Si on ajoutait une info toute bête, du style : "les contrats correspondent soit au critère A, soit au critère B", cela n'empêcherait pas l'agrégation ; mais le taux client est un critère si fin que c'est presque comme si on ajoutait le numéro de contrat, ce dernier critère empêchant par nature tout agrégation.
Je me trompe ?

Pour l'exportation directe dans Access, par contre, je prends note, je vais essayer !

[Alexeyev]

J'ai regardé précisement les ordres de grandeur sur les mois écoulés de 2007 :
Le total des lignes fait dans les 6 millions, mais en sélectionant le période qui m'intéresse, on arrive pour chaque mois à environ 1 million et demi de contrats, avec un taux d'agrégation d'envrion 30 contrats par ligne, ce qui ramène leur nombre à environ 50.000.
C'est l'objectif de volume : conserver un résultat qui ne fasse pas plus de 50.000 lignes... parce que Access ne pourra pas traiter les 1.5 millions de contrats !

Pour la méthode d'export, j'ai essayé mais je ne peux pas sélectionner l'option "export vers un SGBDR", l'option est grisée !

[BzhCH]

Non, non, ce n'est pas ça!
C'est dans l'univers qu'il faut faire cette modif'. Pour cela bien sûr, il faut avoir Designer...
Autre solution (que je n'aime pas vraiment mais qui peut dépanner), aller modifier le SQL généré. Si tu veux suivre cette voie, dis-le moi car si tu ne connais pas SQL, ça peut être coton...

[BzhCH]

Si l'option est grisée, c'est que ton Supervisor l'a désactivée...

[Alexeyev]

Pour le SQL je crois que je serai pas assez compétent...
En ce qui concerne la modification de l'univers, il faudrait que je voie avec l'administrateur de nos bases de données, et je doute qu'il accepte !
Je vais lui en toucher un mot...
Merci pour tout !