[Vxi3] N'appliquer les conditions qu'après exécution de la requête

[jomakay]

Bonjour,

J'ai un problème qui me creuse la tête depuis des jours et des jours. Je ne sais pas s'il y a une solution et si cette solution se fait à travers Designer ou Deski/Webi donc je poste dans le forum Designer, désolé si ce n'est pas le bon endroit.

Alors je vais essayer d'être clair pour vous exposer mon problème.

- J'ai une table de dimension qui répertorie tous les contrats.
- J'ai quatre tables de fait qui répertorient différentes activités des contrats (montants)
- Certaines de ces tables de fait ont plusieurs occurences par contrat.
- Tous les contrats ne se retrouvent pas forcément dans toutes les tables de fait.

J'ai donc relié la table de dimension contrat avec les 4 tables de fait par des jointures externes.

Mon problème intervient lorsque j'interroge une table de fait qui a plusieurs occurences du contrat et une autre table de fait
En effet, les lignes se retrouvent "multipliées" par le nombre d'occurence et les sommes ainsi calculées sont fausses.

Exemple pour être clair :

Table contrat : 1 ligne
Table de fait A : 1 ligne, montant = 100
Table de fait B : 2 lignes, montant = 200 et montant = 300

Une requête sur ce contrat donne deux lignes :

contrat, 100, 200
contrat, 100, 300

==> Le résultat après agrégation donne contrat, 200, 500 au lieu de contrat, 100, 500

Pour remédier à ce problème, je suis passé par l'option du Designer : "Plusieurs instructions SQL pour chaque indicateur".
==> Les sommes sont faites séparément en deux requêtes, le résultat est alors correct. BO liant en quelque sorte sur la dimension contrat de lui-même.

A ce moment-là intervient un autre problème.
Si je pose une condition sur le montant, ex : montant2 > 1000, BO me renvoie quand même la ligne !

Résultat : contrat, 100, (null)

La condition n'est appliquée par BO que sur la deuxième requête qui ne renvoie aucun résultat. Mais la première requête, elle, renvoie bien la ligne puis BO lie les deux requêtes sur la dimension.
Le résultat n'est donc pas celui attendu par l'utilisateur.

Ma question est donc : Comment faire pour que la condition ne soit appliquée qu'après exécution de la requête ? (comme un filtre global) Ou comment appliquer la condition sur l'ensemble des requêtes ?
J'ai essayé pas mal de choses comme les paramètres du Designer mais rien n'y fait... si quelqu'un a une petite idée, ce serait vraiment gentil...

Merci beaucoup

[djam21]

Plutôt que de filtrer ta requête, filtre ton rapport...

Tu ramènes tout puis tu appliques un filtre sur l'onglet...

[jomakay]

Merci djam21 de ta réponse.

J'avais effectivement pensé à cette solution mais je cherchais à mettre çà en place pour un utilisateur lambda qui crée sa requête.

L'utilisation "logique" de BO est de mettre la condition dans la requête...

[tedo01]

Bonjour,
Autre solution : faire une requête par table de fait...

[jomakay]

Oui, c'est ce que j'ai fait en cochant la case "Plusieurs instructions SQL pour chaque indicateur".

Mais à ce moment-là, la condition ne s'applique que sur une des requêtes et pas sur l'ensemble des requêtes.

En cherchant j'ai trouvé une piste à mon problème.
Les tables de fait reliées comme je l'ai décrit est appelé pour BO "Interruption de séquences".

Si quelqu'un s'y connait donc en interruption de séquences, çà m'intéresse. J'ai trouvé la définition sur le forum déjà : http://business-intelligence.develop...page=II-B#C-10

Ainsi que dans la doc BO. Mais c'est après qu'intervient le problème, la condition ne s'applique que sur une des sous-requêtes ainsi générées et non pas sur l'ensemble.

[tedo01]

Bonjour,
Ce n'est pas ça que je propose.
Ma solution consisterait en autant de fournisseur de données que de tables de faits...

[TomDuBouchon]

Bonjour,

Le problème se situe surtout sur l'implémentation d'une ventilation non-cohérente après exécution des requêtes...

Pour être plus clair, que vous passiez par des contextes (interruption), par une instruction pour chaque indicateur reviendra au même. Je vous donne un exemple :

Requête 1 :
Client | Ancienneté
toto | 6

Requête 2 :
Client | N° commande | Prix
toto | 1001 | 30
toto | 1002 | 50

Si on a plusieurs requêtes ou des contextes ou une instruction par indicateur, le résultat reviendra à ce qu'il y a ci-dessus. (qui est logique)

Le problème intervient lors de la création du tableau :

Si on ne met pas la dimension N° Commande :
Client | Ancienneté | Prix
toto | 6 | 80

... ici le résultat est correct. Or ci on ajoute la dimension N° Commande :
Client | Ancienneté | N° Commande | Prix
toto | 6 | 1001 | 30
toto | 6 | 1002 | 50

... Dans ce cas, la somme de pied de page donnera :
toto | 12 | - | 80

... Ce qui évidemment est faux.

Donc, pour résoudre le problème, deux solutions :

• Soit vous créer un tableau croisé pour afficher le détail des commandes, en plaçant l'ancienneté dans l'en-tête (de gauche) du tableau, afin qu'il n'y ait qu'une seule valeur d'ancienneté ramenée pour le client "toto".
• Soit, dans la somme de pied de page, il ne faut pas mettre :
  Code :

  =Somme(<Ancienneté>)

  mais plutôt :
  
  Code :

  =<Ancienneté> Dans Rapport

Concernant vos filtres, je vous conseille de créer une requête par table de faits comme le conseille tedo, et d'appliquer les filtres sur chacune d'entre elles (quitte à passer par une sous-requête si besoin est)

[jomakay]

Merci pour vos réponses.

tedo : d'accord je n'avais pas compris ce que vous vouliez dire.

tom : cela confirme bien ce que je pensais. pour un utilisateur lambda de l'univers, il n'y a pas de solution pour avoir une utilisation "classique" du requêtage (une seule requête avec les conditions appliquées sur cette même requête, sans ajouter de filtres après requête).

Merci encore

[Poulppy]

J'ai déjà eu ce type de problème :
Pour le résoudre j'avais été obligé d'utiliser une ruse :

J'ai créé 1 fournisseur par indicateur.
J'ai ajouté des Informations différentes dans les fournisseurs de données (si il n'y a pas d'information alors en créer une).
Dans les rapports j'ai ensuite créé un filtre dynamique pour ne voir que les données dont les deux informations sont renseignées.
C'est pas TOP mais bon, il n'y a pas toujours le choix.