Discussion :

[AlexFred]

bonjour,

je cherche à faire un merge à partir de tables A et B by une série de variables.
A ces variables sont associées des formats, les mêmes dans les 2 tables.

J'aimerais que ce merge prenne en compte les formats associés ( correspondants à des regroupements de modalités )
Or, apparemment, il n'en tient pas compte.

Que faut-il faire?
D'avance merci

[datametric]

passer par une proc sql qui est plus souple pour le type de clef etc...

[AlexFred]

Je veux bien passer par SQL, mais tout d'abord quelqu'un peut il m'expliquer pourquoi quand je lance le code suivant :

Code :

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

1
2
3
4
5
proc sql;
   title 'Inner Join';
   select u_eff, u_code_disc_elvire2, regionB, i_sexe2, e_type_etab
      from S.gr_s_homo3 as l, S.regr4 as r
      where l.u_eff=r.u_eff;

je récupère ces erreurs.

Code :

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

1
2
3
4
5
ERREUR: Référence ambiguë, la col. u_eff se trouve dans plus d'une table.
ERREUR: Référence ambiguë, la col. u_code_disc se trouve dans plus d'une table.
ERREUR: Référence ambiguë, la col. regionB se trouve dans plus d'une table.
ERREUR: Référence ambiguë, la col. i_sexe2 se trouve dans plus d'une table.
ERREUR: Référence ambiguë, la col. e_type se trouve dans plus d'une table

merci

[datametric]

C'est écrit : la colonne se trouve à la fois dans les deux tables. Donc il ne sait pas laquelle prendre.

[AlexFred]

mais justement je préfixe les variables pour les distinguer.

D'ailleurs, l'exemple de ce code se trouve dans la doc SAS et pourtant cela ne marche pas


J'ai bien le droit d'avoir des noms de variables identiques dans 2 tables.
Avec merge cela ne pose pas de problème.

[datametric]

Si cela peut poser problème car ce n'est pas aussi simple.

par rapport au SQL, ton SELECT u_eff, u_code_disc_elvire2, regionB, i_sexe2, e_type_etab doit également contenir des préfixes car il sait pas si de la première ou de la deuxième table il doit prendre ces champs.

par rapport au MERGE, lorsque les deux tables ont deux champs identiques alors le champ de la table de droite remplace celui de la table de gauche. Le tout dans la table d'arrivée bien entendu.

dans ton SQL tu devras regarder quelque chose comme WHERE put(l.u_eff,monformat.)=put(r.u_eff,monformat.) pour que tu puisses joindre sur le résultat de l'application du format.

[AlexFred]

Merci Datametric,

ta solution marche parfaitement. (put(l.u_eff,monformat)=put(r.u_eff,monformat))

Toutefois, maintenant pris par le jeu de la compréhension, j'aimerais faire la même chose avec le merge, mais comment faire l'éqivalent de put(l.u_eff,monformat)=put(r.u_eff,monformat) sachant que là, je n'ai plus de préfixe.
Ou alors il faut que je recréé ces préfixes, mais comment.
Voici mon code actuel.

Code :

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

1
2
3
4
5
6
7
8
9
10
data table_homo aa2 bb2;
    merge S.regr4BB (in=aa) S.gr_s_homo4 (in=bb);
	format u_eff effquar. u_code_disc_elvire2 fmtCd3d. regionB regionB_L. ;
	*by put(u_eff,effquar.) put(u_code_disc_elvire2,fmtCd3d.) put(regionB,regionB_L.) i_sexe2 e_type_etab ; 
	by u_eff u_code_disc_elvire2 regionB i_sexe2 e_type_etab;
	if aa and bb then output table_homo;
	else if aa and not bb then output aa2;	
	else if not aa and bb then output bb2;
	else put 'pb';
run;

A plus

[datametric]

tu ne peux pas et c'est pour cela que je t'invitais à passer par du SQL qui est beaucoup moins psycho-rigide que SAS.

Note également que ton étape format u_eff effquar. u_code_disc_elvire2 fmtCd3d. regionB regionB_L. ; ne sert que pour tes yeux : la colonne est visualisable avec le format mais c'est tout.

pour retrouver une équivalence, il faudrait créer une tierce colonne Y = put(l.u_eff,monformat) dans chaque table et merger avec. Le danger évident est la répétition des valeurs dans Y.

[Manoutz]

Bonjour Alexfred,

Dans une (ou deux, si aucune des tes variables d'origine n'est au bon format de merging) de tes tables d'origine, il faut que tu créée une nouvelle variable au bon format. Débarrase toi de l'ancienne variable et renomme la nouvelle variable par le nom de l'ancien (pour que le by puisse fonctionner). Egalement possible, tu créée une nouvelle variable dont le format sera le même pour les deux tables et tu merges sur cette variable.

Manoutz

[AlexFred]

Merci à Manoutz et Datametric,

Cela marche bien aussi avec merge maintenant en créant des variables pour les 2 tables, puis sort by ces nouvelles variables et merge by ...

Votre aide m'a permis de voir un peu mieux les forces et faiblesses de Merge by et proc SQL. Et c'est pas toujours évident.

Toutefois, avant de mettre la balise Resolu, j'aimerai comprendre comment je peux ne pas appliquer un format, quand celui ci s'applique par défaut

Code :

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

1
2
proc print data=S.gr_s_homo4(obs=10); var u_eff ueffB u_code_disc_elvire2 u_code_disc_elvire2B regionB regionBB;
 run;

ce qui me donne comme output
u_code_disc_ u_code_disc_
Obs u_EFF ueffB elvire2 elvire2B regionb regionBB

1 0 <= effectif <= 37 0 <= effectif <= 37 (vide) (vide) AQUITAINE AQUITAINE
2 0 <= effectif <= 37 0 <= effectif <= 37 (vide) (vide) AQUITAINE AQUITAINE
3 0 <= effectif <= 37 0 <= effectif <= 37 (vide) (vide) AQUITAINE AQUITAINE
4 0 <= effectif <= 37 0 <= effectif <= 37 (vide) (vide) AQUITAINE AQUITAINE

Franchement, je ne vois pas la différence.
...

[datametric]

parce que la ligne FORMAT ne sert qu'à l'affichage. SAS travaille avant tout sur les données enregistrées (les données brutes) lorsqu'il s'agit d'étapes DATA.

dans l'étape suivante, le champ A contient une valeur brute alors que B contient sa transformation définitive en un champ texte.
Quoique tu fasses sur B, une ligne FORMAT ne change pas la façon dont tu peux la lire alors que sur A, différents tests sont possibles.

Code :

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

1
2
3
4
5
6
data dt;
a='01feb2009'd;
b=put(a,date9.);
/* format a date9. */
/* format a monyy. */
run;

[AlexFred]

Merci pour ce petit programme,
mais dans mon cas c'est pas tout à fait cela d'après moi.

car quand je fais par exemple

Code :

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

proc print data=dt; run;

j'obtiens:Obs a b

1 17929 01FEB2009
alors que moi j'obtiens par exemple
Aquitaine Aquitaine et que quand je faisais le merge by
dans 1 cas il me prenait la valeur 73 et dans l'autre cas la valeur Aquitaine.*

D'où ma question, comment me débarrasser du format associé pour faire réapparaitre à la place de Aquitaine, la valeur 73

A +

[datametric]

As-tu décommenté l'une des lignes que je t'ai fourni ? Je ne crois pas. Cela devait te servir à voir que le format monyy ou date9 appliqué sur A, modifiait l'affichage dans ta proc print.

Fais le et tu verras que ta proc print t'affiche des valeurs différentes pour A alors que la valeur stockée est toujours la même. Pour B la valeur est en dur et égale à "01FEB2009" quoi que tu fasses.

Il te faut annuler l'utilisation d'un format pour pouvoir visualiser la véritable valeur.
Soit dans la table : ce sera définitif,
Soit dans la proc print : ce sera temporaire.

Code :

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

1
2
3
proc print data=dt;
format a b;
run;

Pour le merge il utilisera la valeur 17929 et non ce qui apparaît avec monyy ou date9

[AlexFred]

Vraiment c'est super logique avec SAS !!!!
Il faut utiliser le statement format a pour annuler le format associé.

Effectivement cela marche à tous les coups.

Mais qu'est que c'est piégeant.

Bravo Datamétic.


Encore une petite dernière question?
Pour le merge je m'en suis sorti comme on me l'a suggéré en créant une variable bis=put(var,monformat);dans les tables avant le merge.
Pouvait t-on le faire directement dans le merge, sans création de variable bis?

Merci

[datametric]

C'est logique au contraire car la ligne sous-entend que la variable n'a pas de format associé.

L'étape DATA a été créée en 1977 et à l'époque les développeurs ne soupçonnaient pas cela.
L'apparition du SQL et ensuite son intégration dans l'outil a permis de contourner certaines rigidités.
Peu de logiciels ont la possibilité de gérer des formats, il faut donc admettre certaines lacunes.

[AlexFred]

C'est logique au contraire car la ligne sous-entend que la variable n'a pas de format associé.

Effectivement on peut voir cela comme ça.
Ceci montre en tout cas qu'on peut, peut être trouver une logique partout !!!
Le tout est de trouver celle qui permet de résoudre le problème

L'étape DATA a été créée en 1977 et à l'époque les développeurs ne soupçonnaient pas cela.
L'apparition du SQL et ensuite son intégration dans l'outil a permis de contourner certaines rigidités.
Peu de logiciels ont la possibilité de gérer des formats, il faut donc admettre certaines lacunes

Effectivement, j'ai découvert cette rigidité.
Cela montre qu'il faut suivre les évolutions de plus près ...

En tous cas, merci encore à Manoutz et Datamétric.