L'une des premières commandes que l'on apprend en programmation SAS© est la PROC SORT. Si son utilisation semble triviale pour une seule variable, les résultats peuvent parfois dérouter les utilisateurs lorsqu'il s'agit d'appliquer un tri sur trois critères ou plus.
Une confusion fréquente survient lorsque l'on tente de trier une table selon une logique complexe, par exemple : par ville (croissant), puis par dette (décroissant), et enfin par numéro de compte (croissant). En inspectant le résultat, il arrive souvent que la dernière variable (le numéro de compte) semble totalement désordonnée.
Est-ce une erreur de code ? Un bug de SAS© ? Non, il s'agit simplement d'une mauvaise interprétation de la logique hiérarchique du tri.
Pour comprendre pourquoi votre troisième variable ne semble pas triée, il faut visualiser le tri comme une série de filtres ou de poupées russes.
Lorsque vous soumettez l'instruction suivante :
SAS© n'essaie pas de trier toutes les colonnes indépendamment. Il applique une hiérarchie stricte :
Niveau 1 (Town) : SAS© trie d'abord tout le jeu de données par ville.
Niveau 2 (Debt) : Le tri par dette ne s'active que l'intérieur des groupes où la ville est identique. C'est un critère de départage.
Niveau 3 (AccountNumber) : Ce tri ne devient visible et effectif que si les deux premiers critères (Ville ET Dette) sont strictement identiques pour plusieurs observations.
Le problème de perception vient du fait que, dans de nombreux jeux de données réels, la combinaison des deux premières variables est souvent unique.
Imaginez une ligne où la ville est "Paris" et la dette est "500". S'il n'y a aucune autre ligne avec exactement "Paris" et "500", le tri par numéro de compte n'a jamais l'occasion de s'appliquer. Le numéro de compte apparaîtra donc à la position déterminée uniquement par les deux premiers critères. Si vous regardez la colonne accountnumber de haut en bas sans tenir compte des autres, elle semblera aléatoire.
Prenons un cas précis pour illustrer ce fonctionnement. Supposons que nous ayons plusieurs observations, mais que le tri par numéro de compte ne soit effectif que pour un sous-groupe spécifique :
Groupe A (Town='Apex', Debt=50.00) : Une seule ligne. Le numéro de compte est affiché tel quel.
Groupe B (Town='Apex', Debt=37.95) : Trois lignes existent avec ces valeurs exactes.
Groupe C (Town='Boston', Debt=100.00) : Une seule ligne.
Dans ce scénario, le tri du numéro de compte (3ème variable) ne sera visible que pour le Groupe B. Si les numéros de comptes pour ce groupe sont 3131, 5108 et 9923, ils apparaîtront bien dans cet ordre croissant.
Cependant, si vous comparez visuellement le numéro de compte du Groupe A avec celui du Groupe B, il n'y aura aucune logique de tri apparente entre eux, car la hiérarchie supérieure (la Dette) a pris le pas.
Si votre troisième variable de tri semble désordonnée, vérifiez vos données. Il est fort probable que vous ayez très peu de doublons sur la combinaison des deux premières variables.
Le tri fonctionne correctement, mais son effet est "masqué" par la forte cardinalité des critères précédents. Le tri par la variable n n'est utile que pour départager les ex aequo des variables 1 à n-1.
