Discussion :

[marchand_de_sable]

Bonjour.

Dans un Source Qualifier (SQ) j'aimerai effectuer 2 jointures différentes sur une même table. Cas typique pour récupérer l'utilisateur qui a créé un enregistrement (MaTable.ID_USER_CREAT) et celui qui l'a modifié en dernier (MaTable.ID_USER_MODIF).

Dans mon SQ, je tente de modifier la propriété "User Defined Join" en utilisant la syntaxe Informatica :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
{
MaTable LEFT OUTER JOIN USER as USER_CREAT ON
MaTable.ID_USER_CREAT=USER_CREAT.ID_USER
 
LEFT OUTER JOIN USER as USER_MODIF ON
MaTable.ID_USER_MODIF=USER_MODIF.ID_USER
}

Ma base est sous Oracle, et je constate déjà que pour les jointures externes, Informatica utilise la syntaxe (+)...
Et malheureusement, Informatica supprime l'alias lorsqu'il traduit ma jointure....
Le SQL devient :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
SELECT ...
FROM MaTable, USER, USER
WHERE
MaTable.ID_USER_CREAT=USER_CREAT.ID_USER(+)
AND 
MaTable.ID_USER_MODIF=USER_MODIF.ID_USER(+)

Pourtant, l'aide Informatica et les différents tutos vus sur le net semblent dire que ça devrait fonctionner...
Je me suis trompé quelque part ?

Merci d'avance.

[Glutinus]

Salut,

Informatica est paresseux.

En fait il génère d'abord le corps du select.
S'il y a seulement un user defined join il rajoute un where.
S'il y a seulement un filter, il rajoute un where.
S'il y a les deux, il fait un where <user_defined_join> AND <filter>.

Mais tu es loin d'être complètement démuni.

Solution 1 / tu fais un SQ overridé.
Double clique sur le SQ, onglet properties, tu cliques sur le petit ergot au bout de la ligne de SQL Query.
Ca ouvre une fenêtre, tu cliques sur generate, puis après tu complètes ta requête, tu sauvegardes.

Solution la plus simple, mais par exemple si tu changes le corps du select il faut bien s'assurer de plein de choses. Je ne recommande pas si tu es débutant.

Solution 2/ tu utilises deux SQ puis après un joiner.
Avantage : très lisible.
Inconvénient : moins performant, sauf si tu l'optimises. Si tu as beaucoup de volumétrie, tu seras tenté effectivement de passer par l'override.

Solution 3/ tu utilises le user defined joined et tu tapes exactement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
MaTable.ID_USER_CREAT=USER_CREAT.ID_USER(+)
AND 
MaTable.ID_USER_MODIF=USER_MODIF.ID_USER(+)

plus ou moins les (+).

Ne pas mettre le WHERE car Informatica le générera pour l'explication tout en haut.

Tu peux tester ensuite en faisant un generate SQL que tu cancelleras après, pour voir quelle requête exacte Informatica va générer.

Après c'est pas du SQL avec LEFT OUTER JOIN que je trouve plus élégant aussi, mais c'est grave ?

[marchand_de_sable]

Solution 1 / tu fais un SQ overridé.

=> Interdit chez mon client.

Solution 2/ tu utilises deux SQ puis après un joiner.

=> Je suis d'accord, c'est très lisible. Mais dans mon mapping, j'ai beaucoup de jointures multiples sur les mêmes tables.
Or apparemment, dans chaque Joiner on ne peux lier que 2 flux à la fois. Je vais avoir une 10aine de Joiner à la fin. Je préfèrerais une autre solution...

Solution 3/ tu utilises le user defined joined et tu tapes exactement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
MaTable.ID_USER_CREAT=USER_CREAT.ID_USER(+)
AND 
MaTable.ID_USER_MODIF=USER_MODIF.ID_USER(+)

Je ne l'aime pas, mais la syntaxe (+) n'est pas gênante.
En revanche, je ne vois pas la diffférence entre cet exemple et le mien : comment Informatica sait que USER_CREAT est l'alisas de la table USER ? (en l'occurence, quand j'essaie ça ne fonctionne pas).

Pour revenir sur la solution 2/, petite question : un Joiner ne lie que 2 flux.
Or dans une transformation je peux faire plusieurs lookups liés, qui peuvent chacun retourner plusieurs lignes et remplacer ainsi une cascade de Joiner. Mais est-ce que le résultat est le même ?

[Glutinus]

Re,

Effectivement je devais être fatigué j'avais mal lu.

Dans ce cas, effectivement le choix de lookups peut être beaucoup mieux.

La lookup lit une table, la monte en cache dans un fichier et travaille directement depuis le flux.
C'est donc pratique pour remonter des références de ce genre.

Dans ton cas, tu peux créer une lookup qui pointe sur USER.
Mettre ID_USER_CREAT en input de la lookup.
Garder ID_USER en cochant L.
Mettre comme conditions de jointure ID_USER_CREAT et ID_USER.
Mettre les champs que tu veux sortir de référence (le nom où je ne sais) en sortie et continuer ton flux.

Copier la transfo lookup et mettre cette fois-ci ID_USER_MODIF en tant qu'entrée et condition.

Avantage : lecture plus simple du mapping, rapidité de traitement.
Inconvénient : s'il y a plusieurs clés ID_USER - a priori ce n'est pas le cas - Informatica va choisir une des lignes au hasard, ou alors la première etc. selon l'option que tu coches ; il faut donc être assuré de l'unicité de la clé de ta lookup si tu ne veux pas de cas bizarres.
La lookup ne filtre pas de donnée, s'il n'y a aucune correspondance, elle sort "null".
"null" est également une condition de jointure : si tu mets null en entrée et qu'il existe "null" en ID_USER tu sors la ligne correspondante.

Tu peux aussi mettre la transforamtion en mode "active" et faire sortir plusieurs lignes, mais je ne recommande pas. Dans mon idée : lookup = une seule ligne de sortie et transforamtion passive ; sinon on utilise un joiner.