[Designer V5-V6] Liaisons incorrectes sur des données communes [Résolu]

[tang121]

Bonjour,

Je ne suis pas informaticien, je n'ai que des connaissances limitées en systèmes d'information et en architectures informatiques.
Je suis, de plus, nouvel utilisateur BO (depuis 2 mois seulement)
et j'ai un problème qui me dépasse forcément que mon chef me demande de résoudre.

J'ai réalisé une requête (requête 1) contenant des champs provenant d'une certaine table (table 1). à cela il faut que j'ajoute un autre champ provenant d'une table différente (Table 2).

Notre univers étant ce qu'il est, les tables ne sont pas forcément directement liables entre elles.

A priori, je ne peux pas intégrer le champ de la table 2 à mon rapport.

j'ai donc créé une seconde requête (requête 2), possédant, outre le fameux champ, tous les champs qu'il me sera possible de lier manuellement avec ceux de la requête 1. Mais ils ne sont pas nombreux (3 environ). Je lie les champs manuellement entre eux. Ceci fait, je ne peux toujours pas intégrer le fameux champ à mon rapport.

Je vais donc voir un informaticien qui me dit que la table 2, à cause de l'architecture de notre univers, n'est liée à aucune autre table et donc ses données ne sont liables avec aucune autre de l'univers. Il faudrait pour résoudre le problème faire des modifications lourdes dans l'univers.

Je transmets à mon boss qui me dit que l'informaticien se trompe, qu'il est FORCEMENT possible de lier n'importe quelle table entre elles du moment qu’elles contiennent des données en commun.

Qui a raison ?

Suis-je sensé pouvoir lier n’importe quelle requête entre elle en liant leurs données communes ? L’informaticien à il tort en disant que l’architecture de l’univers peut empêcher le lien de certaines tables entre elles ?

Quelqu’un a-t-il une solution ?

Le fait que le lien manuel entre les tables ait échoué est-il dû au fait que les champs liés étaient trop peu nombreux ?

[ruru9]

Oui, on peut lier entre elles des données provenant de fournisseurs de données différents (à condition que tes deux objets soient de même type (dimension)).

Il m'arrive de lier un champs venant d'une BD Oracle interfacée via un univers avec un champs venant d'un simple fichier excel stocké sur mon poste. Et ca marche bien.

[bastoonet]

Pour pouvoir être liée correctement des éléments doivent avoir le même type...

Requete R1 :
id_client(dimension), id_type(dimension) ,CA(indicateur)

Requete R2 :
id_type(dimension),libellé_type(dimension)

Si on lie ces 2 requetes uniquement sur id_type(R1) lié à id_type(R2) afin d'avoir par exemple le chiffre d'affaire par type !
- on ne pourra pas associer dans le même tableau id_client et libellé_type (sauf si l'on fait un max.(libellé_type)
- on pourra associer automatiquement tous les objets de type indicateur.

[Liszt]

Euh il a l'air pénible ton boss quand même...

Enfin passons. Je suis sur une version supérieure, mais il me semble que la version 6 peut faire des fusions comme la version XI, donc je tente une réponse.

Il faut donc que tes champs que tu vas fusionner soient du même type BO (dimension), du même type (number, integer, varchar), et aient des valeurs en commun (bah ouais, sinon ça fusionnera jamais).

Ensuite, peu importe si la table n°2 n'est liée à aucune autre. L'essentiel est qu'elle soit alimentée par une manière ou par une autre. Après, l'informaticien n'a pas forcément tort car la majorité des architectures ne permet pas la fusion de deux tables qui n'ont rien à voir... (c'est juste BO qui est bizarre ). Enfin je suis pas vraiment sûre (disons qu'on va dire : sûre à 80 %). Bon, j'ai quand même la doc de XI devant les yeux, et ça dit bien "La seule restriction imposée par Web Intelligence (enfin dans ton cas, c'est pareil), est qu'elles doivent être du même type de donénes : des données de type caractère, par exemple"

En fusionnant le champ1 de ta table 1 avec le champ1 de la table 2 (les champs peuvent ne pas se nommer pareil), tu auras les champsX de ta table 2.

Si tu as les tables, tu peux nous les mettre ici (enfin si tu veux, tu peux renommer les champs), et on t'aidera à trouver une soluce.

(J'ai eu le même genre de patron, je sais ce que c'est... )

[tang121]

En fait, je n'ai pas de problème pour lier les deux tables entre elles. j'y arrive car j'ai des champs identiques dans les deux tables.

Je pensais qu'en liant deux tables par leurs champs identiques on pouvait utiliser tous les champs des deux tables ensemble dans un même tableaux (même ceux n'ayant aucun lien).

Mais si je crois bastoonet, ainsi que ce que j'ai vu en pratiquant, ce n'est pas possible. même si deux tables sont liées entre elles par quelque-uns de leurs champs, un champ de la première table n'ayant pas son équivalant dans la deuxième ne peut pas être utilisé avec un champ de la deuxième n'ayant pas son équivalant dans la première.

ai-je bien compris ?

[Liszt]

As-tu essayé de créer des variables de type "Information" reprenant les champs de type "dimension" (non fusionnés) dont tu as besoin ? Ca peut marcher

[bastoonet]

oui tu as bien compris....

le problème réside dans le fait que les objets qui ne sont pas liés dans les requetes ne sont pas forcément dans le même périmètre d'analyse.

[tang121]

mais la remarque de Liszt me parait tout à fait pertinente.

je vais essayer en mettant mon champ en information.

en tout cas merci pour votre aide

[Bruno2r]

Envoyé par Liszt

As-tu essayé de créer des variables de type "Information" reprenant les champs de type "dimension" (non fusionnés) dont tu as besoin ? Ca peut marcher

Envoyé par tang121

mais la remarque de Liszt me parait tout à fait pertinente.
je vais essayer en mettant mon champ en information.
en tout cas merci pour votre aide

La remarque de Liszt n'est pas seulement pertinente ...
Elle est vraie de vraie !

Non seulemment il faut que les données soient de même type (caractère caractère pae exemple)
Non seulemment on ne peut lier que des objets Dimension

Mais on ne pourra pas utiliser les dimensions non "liables" !
D'où le recours quand c'est possible (c'est à dire si ça ne multiplie pas les lignes sinon Bonjour les valeurs en indicateurs !) à leur transformation en objets Information rattachés à la dimension liée.


Sans aucune certitude absolue (car je ne connais pas l'univer)
Mais fort de pas mal d'univers croisés (souvent réplication exacte de la base de production)

Je peux dire que le Boss a raison !

Aucune table non liée à une autre n'a de sens dans un univers (sauf si on veut y stocker les dates de traitement des tables et quelques autres infos sur l'univers). C'est soit un oubli soit un univers pas fini, en tous cas un univers perfectible.

On peut lier les tables (dans la mesure où cela a du sens de le faire et représente une utilité eh oui dans Utilisateur il y a Util ) soit dans l'univers et sinon en sql à la carte.

L'informaticien a raison de dire que le designer de l'univers ne l'a pas prévu.
Le boss est en droit de demander une amélioration de l'univers puisqu'à l'évidence il ne couvre pas tous les besoins !
L'informaticien est en droit de ne pas avoir envie de reprendre un univers dont il n'est pas le concepteur.

Désolé pour la longueur de la réponse.

[Liszt]

Très belle démonstration sur les différents rôles en entreprise

C'est clair qu'à part des tables de paramètres, on lie toutes nos tables chez nous... Donc bon.

[tang121]

et y a-t-il une parade contre cette multiplication des lignes ? (cf Bruno2R)

la donnée transformée en indicateur ne se croise pas avec les données de l'autre table sans ajouter pour chaque valeur une ligne vide...

[Liszt]

Dans la version XI, il y a une case de propriétés à cocher "avoid dupplicate row".

Regarde dans ta version s'il n'y a pas une case à cocher qui se nomme "éviter les doublons" quelque part dans les propriétés.

[maju0906]

Bonjour,
J'ai le même probleme de duplication de ligne lorsque je lis mes 2 dimensions(qui contiennes des noms) mais j'utilise BO 5.1.9 et je n'ai pas "avoid duplicate row" comme option pour ma liaison (seulement pour chaque requete mais ca marche pas ). Ex :

Je lis nom1(julien, vincent) et nom2(julien, vincent) et le résultat me donne (julien,julien,vincent,vincent) et les indicateurs s'ajoutent sur la meme ligne que leur dimensions associe dans le requete.

Merci

[TomDuBouchon]

C'est surprenant...

Normalement, si tu as lié tes dimensions, et que tu affiches tes deux indicateurs en deux colonnes distinctes, si BO trouve une même valeur de ta dimension il devrait mettre les résultats des indicateurs l'un en face de l'autre...

Au pire essaies simplement de faire une somme :

Code :

=Somme(<Indicateur>)

Et vérifies que dans les propriétés de ton tableau tu n'aies coché "Eviter l'agrégation des doublons".

[maju0906]

Merci pour ta réponse mais je me suis mal exprimé.

Le problème vient de ma liaison entre mes 2 dimensions(qui viennent de 2 requetes différentes (qui viennent de de 2 univers différents d'ailleurs)).Mes 2 dimensions possèdent les mêmes valeurs cad des noms (en minuscule). Si je les affiche un par un j'obtient a chaque fois une liste sans doublons. En revanche lorsque je les associe (les affiche ensemble dans un tableau) il m'affiche ca :


nom(1) nom(2)
julien julien
julien julien
vincent vincent
vincent vincent


au lieu de me faire correctement la liaison et de m'afficher :

nom(1) nom(2)
julien julien
vincent vincent

La case "eviter l'agregation de doublons" est bien décocher. De plus je ne peux pas faire de table de liaison en BDD avec les ids des noms par exemple comme je l'ai deja fait pour d'autres problèmes car j'ai plus de 2000 noms et à la main....

[maju0906]

Bon bah tu avais raison....un rtrim et ca marche...
Merci bcp