Discussion :

[kyrandia]

Bonjour,

Apparemment on peut lier deux fournisseurs de données dans BO à partir de dimensions communes, mais ça ne répond pas à mon besoin suivant :

F1 : code equipement (D), nom équipement(D), prix achat équipement(I)
F2 : code équipement (D), code contrat(D), cout contrat(I)

mon but est d'obtenir la jointure entre les deux fournisseurs sur le code équipement pour obtenir un listing code équipement, nom équipement, prix achat équipement, code contrat, coût contrat.

La liaison ne fonctionne pas car entre les deux fournisseurs les dimensions ne sont pas communes, de plus je ne peux pas utiliser la notion de union ou intersection pour la même raison, n'y a t-il pas un moyen de faire une jointure simple entre deux fournisseurs de données ou faut-il que je passe par le SQL à la carte.

Merci d'avance.

[Sergio63]

Bonjour,

Il y a un truc qui m'échappe : ces champs proviennent-ils de la même base de données ?

Dans ce cas si tu utilises un univers et que celui-ci est bien fait, tu ne dois pas avoir besoin de de 2 requêtes, une seule suffit.

Si tu fonctionnes en SQL à la carte alors je vois 2 solutions :
- Faire la jointure en SQL (c'est je pense la meilleure).
- Considérer que tous les champs qui ne sont pas des indicateurs (en dehors du code équipement bien sûr) sont des informations puis lier les 2 fournisseurs sur le code équipement.

Cordialement

Sergio

[kyrandia]

Bonjour,

Il y a un truc qui m'échappe : ces champs proviennent-ils de la même base de données ?

Dans ce cas si tu utilises un univers et que celui-ci est bien fait, tu ne dois pas avoir besoin de de 2 requêtes, une seule suffit.

Si tu fonctionnes en SQL à la carte alors je vois 2 solutions :
- Faire la jointure en SQL (c'est je pense la meilleure).
- Considérer que tous les champs qui ne sont pas des indicateurs (en dehors du code équipement bien sûr) sont des informations puis lier les 2 fournisseurs sur le code équipement.

Cordialement

Sergio

Oui les deux tables sont bien reliées dans le même univers par le code équipement.( table equipement avec tous mes équipement) et une table contrat (avec tous les contrats liés aux équipements). Mon besoin et d'obtenir tous le listing de mes équipement et d'avoir un complément d'info via les contrats. En gros faire une jointure externe. ceci et possible, mais dès que je pose une condition lié à un champ de la table contrat, je pers un certain nombre d'enregistrement de mes équipements (et je ne le veux pas).
Donc j'ai imaginé passer par ces deux requêtes.

en gros voici ce que je veux (il y a d'autres infos...) :
Table equipements :
code équipement nom équipement
1 'TOTO'
2 'TITI'
3 'TUTU'
Tables contrats
code équipement code contrat annee
1 A 2001
1 A 2008
3 B 2008

résultat souhaité avec filtre annee=2008
code équipement nom équipement code contrat
1 'TOTO' A
2 'TITI' null
3 'TUTU' B

voilà.

[Sergio63]

Ok, je comprend mieux, l'univers fait une équi-jointure (comme cela est le cas en général pour des raisons de performances) et lorsque tu demandes un champ sur les contrats, les équipements qui n'en ont pas passent à la trappe.

Si tu te débrouilles en SQL et que tu connais la structure de ta base de données, il faut passer par du SQL à la carte. Tu fais une jointure externe dans la requête et tu auras le résultat escompté. Tu peux utiliser le bouton 'Visualiser le SQL" de l'éditeur de requête pour t'aider à rédiger le SQL.

Sinon, je ne vois qu'une autre solution, exporter tes cubes et faire la jointure dans Access ou dans Excel avec la fonction RechercheV

Cordialement

Sergio

[waloux1]

je pense que si tu as acces au designer tu peux la faire dans l'univers comme tu le ferais dans un sql

Si j'ai bien compris ??

[Sergio63]

Bien sûr ma réponse sous-entend qu'il n'est pas possible de modifier l'univers.

Mais attention tout de même, modifier un univers n'est pas anodin et cela peut avoir des conséquences sur des requêtes d'autres utilisateurs. Peut-être que si il a été conçu tel qu'il est c'est qu'il y de bonnes raisons, que c'est le meilleur compromis pour la majorité des utilisateurs même si cela ne convient pas à mon besoin du moment.

Ecrire une requête en SQL évite tous ces risques.

Sinon la solution peut-être de copier l'univers, de le modifier et de l'utiliser en local.

Cordialement

Sergio

[Benoit_Durand]

Et via le bouton micro cube (le petit cube bleu) tu ne peux pas lier les données ?

[kyrandia]

Bonjour,

Merci Sergio pour ta réponse, effectivement, créer une jointure externe dans un univers n'est jamais anodin.
Je pense que tous les utilisateurs ne souhaitent pas cette jointure externe, donc mieux vaut dans mon cas passer par du SQL à la carte, pour ce besoin utilisateur précis.

Il n'en reste pas moins surprenant que BO n'ait pas de possibilités de faire de jointure entre deux fournisseurs de données, sauf sur des dimensions communes aux deux fournisseurs...

A+

[Benoit_Durand]

Bonjour,

Il n'en reste pas moins surprenant que BO n'ait pas de possibilités de faire de jointure entre deux fournisseurs de données, sauf sur des dimensions communes aux deux fournisseurs...

On atteint très rapidement les limites de BO WebI et DeskI....

[Bruno2r]

Bonjour,

Il y a un truc qui m'échappe : ces champs proviennent-ils de la même base de données ?

Dans ce cas si tu utilises un univers et que celui-ci est bien fait, tu ne dois pas avoir besoin de de 2 requêtes, une seule suffit.

Si tu fonctionnes en SQL à la carte alors je vois 2 solutions :
- Faire la jointure en SQL (c'est je pense la meilleure).
- Considérer que tous les champs qui ne sont pas des indicateurs (en dehors du code équipement bien sûr) sont des informations puis lier les 2 fournisseurs sur le code équipement.

Cordialement

Sergio

Bonjour,
Bien sûr que le SQL à la carte est une solution ... radicale

Moi j'aurais opté pour la 2ème proposition de Sergio dans la mesure ou le seul objet indicateur est le coût du contrat (donc au niveau le plus fin).

Si tu avais eu l'indicateur à un niveau supérieur que le niveau le plus fin, il aurait fallu enlever la fonction d'agrégation Somme au profit de Néant (Gestionnaire de données, onglet Definition)

Je reste persuadé qu'en faisant

1. 2 voire 3 requêtes distinctes
2. en ne laissant en dimension que Code en rattachant les autres (non indicateurs) comme information de la dimension Code
3. En liant la Dimension unique Code

La synchronisation est parfaite.
Précision : Pourquoi je dis 2 voire 3 requêtes ?
C'est l'observation des SQL qui déterminera si 2 Requêtes sont suffisantes.
Ceux-ci devra être affranchi de l'équijointure.

[kyrandia]

Bonjour Bruno,

Je n'avais pas pensé à la notion d'information, je commence à comprendre son intérêt dans mon cas.
Ce n'est malheureusement pas une solution, car j'utilise l'analyse multidimensionnelle dans d'autres rapports avec des objets nécessaires ici, et il me semble qu'on ne peut pas utiliser des informations dans ce cas...

voilà, j'utilise le SQL à la carte, et ça marche bien, il suffit juste que j'ai autant d'objet BO que que de champs dans le SELECT de mon SQL à la carte.

A+