SNDS<\/a>), la s\u00e9lection erron\u00e9e ou l’omission d’une sous-cha\u00eene d\u00e9signant un diagnostic nosologique peut alt\u00e9rer l’estimation de l’incidence d’une pathologie. La ma\u00eetrise des m\u00e9canismes de d\u00e9tection de sous-cha\u00eenes devient alors un imp\u00e9ratif de rigueur m\u00e9thodologique, assurant une parfaite concordance entre les d\u00e9finitions op\u00e9rationnelles de l’\u00e9tude et les observations effectivement retenues pour l’estimation statistique.<\/p>\n1.2 Vue d’ensemble des architectures de filtrage : \u00e9tape DATA versus proc\u00e9dures<\/h3>\n L’environnement SAS offre deux architectures conceptuellement distinctes pour restreindre le traitement d’une table aux lignes satisfaisant une condition textuelle : l’\u00e9valuation en amont via l’instruction WHERE<\/strong> et le sous-ensemble conditionnel s\u00e9quentiel assur\u00e9 par l’instruction IF<\/strong> au sein de l’\u00e9tape DATA. Comprendre la fronti\u00e8re op\u00e9rationnelle entre ces deux modes op\u00e9ratoires n\u00e9cessite de diss\u00e9quer le flux de donn\u00e9es transitant entre le support de stockage physique et le processeur.<\/p>\nL’instruction WHERE<\/strong> op\u00e8re directement au niveau du moteur d’acc\u00e8s aux donn\u00e9es (l’Input Engine). Lorsqu’une clause WHERE<\/strong> est soumise, le moteur SAS \u00e9value le pr\u00e9dicat logique avant m\u00eame que l’enregistrement ne soit transf\u00e9r\u00e9 dans la structure de m\u00e9moire centrale appel\u00e9e Program Data Vector (PDV). Si l’enregistrement ne contient pas la cha\u00eene de caract\u00e8res recherch\u00e9e, il est purement et simplement \u00e9cart\u00e9 du flux de lecture. Cette m\u00e9canique minimise drastiquement les op\u00e9rations d’entr\u00e9es\/sorties (I\/O) et dispense le syst\u00e8me d’allouer des cycles d’horloge \u00e0 l’initialisation du PDV pour les lignes non pertinentes. En outre, la syntaxe WHERE<\/strong> pr\u00e9sente l’avantage unique d’\u00eatre universellement reconnue au sein des proc\u00e9dures d’analyse (notamment PROC PRINT, PROC FREQ ou PROC SQL), autorisant un filtrage \u00e0 la vol\u00e9e sans g\u00e9n\u00e9ration de table interm\u00e9diaire.<\/p>\n\u00c0 l’inverse, l’instruction conditionnelle IF<\/strong> (utilis\u00e9e sous sa forme de sous-ensemble : IF condition;<\/em>) intervient strictement au sein de l’\u00e9tape DATA, en aval du chargement de l’observation dans le Program Data Vector. Chaque observation est d’abord lue depuis le disque ou la m\u00e9moire tampon, les variables y sont instanci\u00e9es, puis la logique s\u00e9quentielle du programme \u00e9value le pr\u00e9dicat. Si la condition textuelle est fausse, le traitement de l’it\u00e9ration courante s’interrompt et le pointeur passe \u00e0 l’observation suivante sans \u00e9crire dans la table de destination. Si cette approche s’av\u00e8re indispensable lorsque le crit\u00e8re de filtrage d\u00e9pend d’une variable calcul\u00e9e dynamiquement au cours de l’\u00e9tape DATA, elle s’av\u00e8re computationnellement sous-optimale pour filtrer des donn\u00e9es brutes pr\u00e9existantes sur des volumes volumineux.<\/p>\n2. Fondements syntaxiques de l’op\u00e9rateur CONTAINS dans l’instruction WHERE<\/h2>\n2.1 Syntaxe fondamentale et s\u00e9mantique de l’op\u00e9rateur CONTAINS<\/h3>\n L’op\u00e9rateur CONTAINS<\/strong> constitue le standard historique et idiomatique du langage SAS pour v\u00e9rifier si une s\u00e9quence sp\u00e9cifique de caract\u00e8res est incluse au sein d’une variable de type caract\u00e8re. Con\u00e7u sp\u00e9cifiquement pour \u00eatre int\u00e9gr\u00e9 aux expressions de filtrage de la clause WHERE<\/strong>, cet op\u00e9rateur relationnel \u00e9value l’appartenance d’une cha\u00eene cible \u00e0 un champ textuel donn\u00e9, sans exiger que ladite cha\u00eene occupe une position ordinale d\u00e9termin\u00e9e. Du point de vue de la formalisation syntaxique, l’instruction adopte la structure g\u00e9n\u00e9rale : WHERE variable CONTAINS ‘cha\u00eene_recherch\u00e9e’;<\/em>. SAS met \u00e9galement \u00e0 disposition un \u00e9quivalent mn\u00e9monique direct, repr\u00e9sent\u00e9 par le point d’interrogation (?<\/em>), de sorte que la formulation WHERE variable ? ‘cha\u00eene_recherch\u00e9e’;<\/em> produit une action rigoureusement identique.<\/p>\nLe fonctionnement interne de CONTAINS<\/strong> repose sur un balayage contigu des octets constituant la variable cible. D\u00e8s lors que la s\u00e9quence exacte sp\u00e9cifi\u00e9e entre guillemets est localis\u00e9e dans l’enregistrement, l’expression retourne la valeur logique VRAI, et l’observation est retenue pour le traitement subs\u00e9quent. Il est primordial de souligner que cet op\u00e9rateur ne requiert aucun caract\u00e8re g\u00e9n\u00e9rique (wildcard) pour d\u00e9signer les positions p\u00e9riph\u00e9riques : la simple d\u00e9signation du fragment textuel suffit \u00e0 d\u00e9clencher la d\u00e9tection d’inclusion.<\/p>\nConsid\u00e9rons, \u00e0 titre d’illustration m\u00e9thodologique, une recherche en psychom\u00e9trie clinique portant sur l’analyse des profils d’anxi\u00e9t\u00e9. Soit un jeu de donn\u00e9es contenant une variable descriptive nomm\u00e9e Diagnostic_Libelle<\/em>. Afin d’isoler l’ensemble des patients pr\u00e9sentant une manifestation document\u00e9e d’anxi\u00e9t\u00e9 g\u00e9n\u00e9ralis\u00e9e au sein d’un libell\u00e9 complexe, la clause s’articulera ainsi :<\/p>\nDATA Cohorte_Anxiete; SET Enquete_Clinique; WHERE Diagnostic_Libelle CONTAINS ‘Anxiete’; RUN;<\/em><\/p>\nDans ce sc\u00e9nario, toute observation dont la variable Diagnostic_Libelle<\/em> contient la suite exacte de sept caract\u00e8res \u00ab Anxiete \u00bb \u2014 que cette s\u00e9quence d\u00e9bute la cha\u00eene, apparaisse au milieu d’une phrase explicative ou termine la description \u2014 sera s\u00e9lectionn\u00e9e avec succ\u00e8s et transmise vers la nouvelle table d’analyse.<\/p>\n2.2 Sensibilit\u00e9 \u00e0 la casse et contraintes de concordance exacte<\/h3>\n Un des pi\u00e8ges majeurs inh\u00e9rents \u00e0 l’usage de l’op\u00e9rateur CONTAINS<\/strong> r\u00e9side dans sa stricte sensibilit\u00e9 \u00e0 la casse (case sensitivity). Dans les syst\u00e8mes d’encodage de caract\u00e8res standards (qu’il s’agisse de configurations ASCII, UTF-8 ou EBCDIC historiques), chaque glyphe poss\u00e8de un point de code binaire distinct selon qu’il est repr\u00e9sent\u00e9 en majuscule ou en minuscule. Par cons\u00e9quent, l’instruction CONTAINS<\/strong> effectue une comparaison binaire rigoureuse, octet par octet. Si une base de donn\u00e9es contient des variations orthotypographiques telles que \u00ab ANXIETE \u00bb, \u00ab Anxiete \u00bb ou \u00ab anxiete \u00bb, une clause formul\u00e9e avec la cha\u00eene litt\u00e9rale ‘Anxiete’ omettra syst\u00e9matiquement tous les enregistrements ne respectant pas scrupuleusement cette r\u00e9partition des casses.<\/p>\nCette sensibilit\u00e9 stricte g\u00e9n\u00e8re un risque \u00e9lev\u00e9 d’erreurs de type II (faux n\u00e9gatifs), o\u00f9 des observations pertinentes pour l’analyse scientifique sont exclues de l’\u00e9chantillon d’\u00e9tude sans qu’aucun message d’erreur ou d’avertissement ne soit \u00e9mis dans le journal d’ex\u00e9cution (SAS Log). Les syst\u00e8mes de saisie en milieu hospitalier ou les formulaires web sans contr\u00f4le d’int\u00e9grit\u00e9 typographique constituent des sources notoires de cette variabilit\u00e9.<\/p>\n
Pour immuniser le filtrage contre ce biais, la pratique recommand\u00e9e consiste \u00e0 combiner l’op\u00e9rateur avec des fonctions de transformation de casse directement encapsul\u00e9es dans la clause de filtrage. En appliquant la fonction UPCASE<\/strong> ou LOWCASE<\/strong> \u00e0 la variable cible, le chercheur uniformise artificiellement la cha\u00eene avant son \u00e9valuation par l’op\u00e9rateur :<\/p>\nWHERE UPCASE(Diagnostic_Libelle) CONTAINS ‘ANXIETE’;<\/em><\/p>\nDans cette configuration, la totalit\u00e9 de la cha\u00eene Diagnostic_Libelle<\/em> est transitoirement convertie en majuscules dans le moteur d’\u00e9valuation, garantissant qu’aucune occurrence ne sera ignor\u00e9e en raison d’une disparit\u00e9 de casse. Il demeure essentiel de s’assurer que la cha\u00eene de r\u00e9f\u00e9rence (ici ‘ANXIETE’) soit elle-m\u00eame enti\u00e8rement transcrite dans la casse adopt\u00e9e par la fonction de normalisation, sous peine de produire une condition universellement fausse qui viderait l’\u00e9chantillon de toute donn\u00e9e.<\/p>\n2.3 \u00c9valuation logique et n\u00e9gation avec NOT CONTAINS<\/h3>\n La logique bool\u00e9enne r\u00e9gissant les clauses de s\u00e9lection SAS autorise l’inversion s\u00e9mantique compl\u00e8te d’un pr\u00e9dicat par l’adjonction de l’op\u00e9rateur unaire NOT<\/strong>. L’association logico-syntaxique NOT CONTAINS<\/strong> (ou son \u00e9quivalent contract\u00e9 NOT ?<\/em>) permet d’op\u00e9rer un filtrage soustractif, en \u00e9liminant syst\u00e9matiquement du flux d’analyse tout enregistrement abritant une s\u00e9quence textuelle proscrite. Ce m\u00e9canisme s’av\u00e8re particuli\u00e8rement f\u00e9cond lors des protocoles d’\u00e9puration de donn\u00e9es, o\u00f9 il convient de purger un fichier d’observations tests, de libell\u00e9s d’erreurs techniques ou de statuts d’invalidation administrative.<\/p>\nSur le plan de l’alg\u00e8bre relationnelle, la n\u00e9gation d’une condition d’inclusion s’exprime de la mani\u00e8re suivante :<\/p>\n
WHERE Diagnostic_Libelle NOT CONTAINS ‘Invalide’;<\/em><\/p>\nDans un contexte d’analyse multidimensionnelle, l’emploi de NOT CONTAINS<\/strong> interagit fr\u00e9quemment avec d’autres expressions logiques. D\u00e8s lors que plusieurs crit\u00e8res d’exclusion doivent \u00eatre appliqu\u00e9s simultan\u00e9ment, l’op\u00e9rateur doit \u00eatre manipul\u00e9 avec une stricte observation des lois de De Morgan. Par exemple, pour exclure \u00e0 la fois les enregistrements marqu\u00e9s comme ‘Invalide’ et ceux annot\u00e9s comme ‘Test’, le praticien doit lier les expressions par un connecteur conjonctif AND<\/strong> :<\/p>\nWHERE Diagnostic_Libelle NOT CONTAINS ‘Invalide’ AND Diagnostic_Libelle NOT CONTAINS ‘Test’;<\/em><\/p>\nLa substitution erron\u00e9e du connecteur AND<\/strong> par un connecteur disjonctif OR<\/strong> constitue l’une des fautes de logique les plus fr\u00e9quentes dans la programmation de filtres textuels. Une telle formulation conduirait en effet \u00e0 la s\u00e9lection universelle de la table, car un enregistrement contenant le mot ‘Invalide’ satisfera trivialement la condition de ne pas contenir le mot ‘Test’, annulant de facto la port\u00e9e restrictive du filtrage.<\/p>\n3. Filtrage par listes discr\u00e8tes : L’op\u00e9rateur IN et ses applications textuelles<\/h2>\n3.1 Diff\u00e9rence conceptuelle entre appartenance discr\u00e8te et inclusion de sous-cha\u00eene<\/h3>\n Dans la bo\u00eete \u00e0 outils du programmeur SAS, il est imp\u00e9ratif d’\u00e9tablir une ligne de d\u00e9marcation th\u00e9orique claire entre la d\u00e9tection d’une sous-cha\u00eene (sub-string matching) et l’\u00e9valuation d’appartenance \u00e0 un ensemble discret de valeurs (membership testing). Alors que des op\u00e9rateurs comme CONTAINS<\/strong> recherchent un motif nich\u00e9 \u00e0 l’int\u00e9rieur d’un vecteur textuel plus vaste, l’op\u00e9rateur IN<\/strong> examine l’\u00e9quivalence int\u00e9grale de la valeur de la variable par rapport \u00e0 une liste de cha\u00eenes constantes autoris\u00e9es.<\/p>\nL’op\u00e9rateur IN<\/strong> ne permet pas, par sa s\u00e9mantique fondamentale, de localiser un fragment isol\u00e9 au milieu d’une phrase. Si une variable Statut_Dossier<\/em> contient la valeur complexe \u00ab Cloture_Definitive_2023 \u00bb, la condition WHERE Statut_Dossier IN (‘Cloture’)<\/em> retournera une valeur logique FAUX, car la valeur scalaire de la variable n’est pas strictement identique \u00e0 l’\u00e9l\u00e9ment de la liste. En revanche, lorsque les modalit\u00e9s textuelles d’un jeu de donn\u00e9es sont cat\u00e9goris\u00e9es et structur\u00e9es sous forme de libell\u00e9s codifi\u00e9s r\u00e9guliers, l’op\u00e9rateur IN<\/strong> s’av\u00e8re sup\u00e9rieur en termes de lisibilit\u00e9 et d’optimisation machine.<\/p>\nD’un point de vue algorithmique, le moteur SAS compile la liste des constantes litt\u00e9rales fournie \u00e0 l’op\u00e9rateur IN<\/strong> sous la forme d’un tableau de hachage interne ou effectue une recherche binaire si le nombre d’\u00e9l\u00e9ments le justifie. Cette optimisation interne rend l’\u00e9valuation de l’appartenance nettement plus rapide qu’une succession de tests disjonctifs d’inclusion partielle, en particulier lorsque le catalogue des statuts autoris\u00e9s comprend plusieurs dizaines d’occurrences textuelles d\u00e9termin\u00e9es.<\/p>\n3.2 Syntaxe et param\u00e9trage de l’op\u00e9rateur IN pour cha\u00eenes multiples<\/h3>\n La formulation syntaxique canonique de l’op\u00e9rateur IN<\/strong> pour les variables textuelles impose l’encapsulation de la liste de valeurs cibles entre parenth\u00e8ses, chaque \u00e9l\u00e9ment \u00e9tant rigoureusement d\u00e9limit\u00e9 par des guillemets simples ou doubles, et s\u00e9par\u00e9 des autres par une virgule ou par un espace blanc. La structure g\u00e9n\u00e9rale s’articule comme suit : WHERE Nom_Variable IN (‘Modalite_A’, ‘Modalite_B’, ‘Modalite_C’);<\/em>.<\/p>\nUne sp\u00e9cificit\u00e9 critique de SAS concerne la gestion des longueurs de cha\u00eenes lors des comparaisons de listes. Lorsque SAS \u00e9value une variable caract\u00e8re par rapport \u00e0 une liste litt\u00e9rale dans un op\u00e9rateur IN<\/strong>, il se conforme aux r\u00e8gles d’alignement du typage de donn\u00e9es. Si la variable cible poss\u00e8de une longueur d\u00e9clar\u00e9e de 10 octets et que la modalit\u00e9 recherch\u00e9e en comporte seulement 5, SAS proc\u00e8de conceptuellement \u00e0 une \u00e9galit\u00e9 apr\u00e8s avoir pris en compte ou neutralis\u00e9 les espaces de fin, selon le param\u00e9trage des options de comparaison.<\/p>\nL’op\u00e9rateur IN<\/strong> d\u00e9montre \u00e9galement une forte valeur ajout\u00e9e lorsqu’il est interfac\u00e9 avec l’\u00e9cosyst\u00e8me des macro-variables SAS. Dans les pipelines de traitement automatis\u00e9s, il est fr\u00e9quent qu’une liste de cha\u00eenes de caract\u00e8res soit g\u00e9n\u00e9r\u00e9e dynamiquement au cours d’une \u00e9tape pr\u00e9alable (via une clause SELECT INTO :<\/em> sous PROC SQL) puis inject\u00e9e dans le filtrage d’un Data Step. L’\u00e9criture syntaxique prend alors la forme modulaire :<\/p>\nWHERE Code_Region IN (&Liste_Regions_Inclusion.);<\/em><\/p>\nCette approche garantit un d\u00e9couplage optimal entre la logique de d\u00e9finition des filtres m\u00e9tiers et le code d’ex\u00e9cution des proc\u00e9dures d’analyse statistique.<\/p>\n
3.3 Gestion des espaces de queue et modificateurs de comparaison<\/h3>\n L’une des sources pr\u00e9\u00e9minentes d’anomalies lors de la comparaison de cha\u00eenes de caract\u00e8res sous SAS r\u00e9side dans l’existence des espaces de queue (trailing blanks). Par d\u00e9faut, SAS stocke les cha\u00eenes de caract\u00e8res sous forme de vecteurs d’octets de longueur fixe. Par cons\u00e9quent, une variable d\u00e9finie par LENGTH Code $8;<\/em> contenant la valeur ‘SAS’ contiendra en r\u00e9alit\u00e9 les trois lettres suivies de cinq espaces blancs. Lors de l’\u00e9valuation d’une \u00e9galit\u00e9 discr\u00e8te, la norme ANSI\/SAS standard stipule que deux cha\u00eenes qui ne diff\u00e8rent que par le nombre d’espaces finaux doivent \u00eatre consid\u00e9r\u00e9es comme \u00e9gales.<\/p>\nCependant, ce comportement peut \u00eatre modifi\u00e9 par des configurations d’environnement ou lors de l’ex\u00e9cution de requ\u00eates via des moteurs tiers (Pass-Through SQL vers des bases de donn\u00e9es relationnelles comme Oracle ou PostgreSQL). Pour contr\u00f4ler explicitement la rigueur de la comparaison au sein de l’environnement SAS de base, l’utilisation de modificateurs et de fonctions de cadrage s’av\u00e8re indispensable.<\/p>\n
Sur le plan des performances compar\u00e9es, il est syst\u00e9matiquement pr\u00e9f\u00e9rable d’utiliser l’op\u00e9rateur IN<\/strong> plut\u00f4t qu’une \u00e9num\u00e9ration de conditions reli\u00e9es par l’op\u00e9rateur OR<\/strong> (par exemple, WHERE Categorie = ‘A’ OR Categorie = ‘B’ OR Categorie = ‘C’;<\/em>). En plus d’offrir une clart\u00e9 syntaxique indiscutable, l’op\u00e9rateur IN<\/strong> permet au compilateur de requ\u00eates de factoriser l’acc\u00e8s \u00e0 la variable et d’utiliser une seule instruction de saut conditionnel au niveau du microprocesseur, r\u00e9duisant de mani\u00e8re mesurable l’empreinte CPU lors de l’it\u00e9ration sur plusieurs dizaines de millions d’enregistrements.<\/p>\n4. Fonctions de recherche textuelle natives : INDEX, FIND et leurs variantes<\/h2>\n4.1 La fonction INDEX : D\u00e9tection de position de sous-cha\u00eenes<\/h3>\n Avant l’enrichissement des fonctions de manipulation textuelle dans les versions modernes de SAS, la fonction INDEX<\/strong> repr\u00e9sentait la m\u00e9thode canonique pour localiser l’emplacement d’une s\u00e9quence de caract\u00e8res au sein d’un champ textuel. La signature de cette fonction scalaire s’\u00e9nonce : INDEX(source, extrait)<\/em>. Contrairement aux op\u00e9rateurs d’\u00e9valuation logique comme CONTAINS<\/strong>, INDEX<\/strong> retourne une valeur num\u00e9rique enti\u00e8re correspondant \u00e0 la position ordinale (base 1) du premier caract\u00e8re de la sous-cha\u00eene localis\u00e9e. Si la sous-cha\u00eene est absente de la source, la fonction renvoie la valeur enti\u00e8re z\u00e9ro (0).<\/p>\nL’exploitation de la fonction INDEX<\/strong> \u00e0 des fins de filtrage repose sur la conversion implicite d’un r\u00e9sultat arithm\u00e9tique en pr\u00e9dicat bool\u00e9en. Dans la logique interne de SAS, toute valeur num\u00e9rique diff\u00e9rente de z\u00e9ro et non manquante est \u00e9valu\u00e9e comme logiquement VRAIE, tandis que le z\u00e9ro est interpr\u00e9t\u00e9 comme FAUX. Ainsi, au sein d’une \u00e9tape DATA, le filtrage conditionnel peut s’\u00e9crire de mani\u00e8re condens\u00e9e :<\/p>\nIF INDEX(Commentaire_Medical, ‘pathologie’) THEN OUTPUT;<\/em><\/p>\nOu, de fa\u00e7on plus formelle et explicite :<\/p>\n
WHERE INDEX(Commentaire_Medical, ‘pathologie’) > 0;<\/em><\/p>\nBien que la fonction INDEX<\/strong> soit extr\u00eamement v\u00e9loce sur le plan de l’ex\u00e9cution brute, elle partage avec l’op\u00e9rateur CONTAINS<\/strong> une stricte sensibilit\u00e9 \u00e0 la casse. Sa principale limitation technique r\u00e9side dans son incapacit\u00e9 \u00e0 moduler la recherche sans l’adjonction de fonctions p\u00e9riph\u00e9riques : elle recherche syst\u00e9matiquement de gauche \u00e0 droite, depuis le premier octet, et ne tol\u00e8re aucun param\u00e8tre de configuration sur la sensibilit\u00e9 typographique ou la direction du balayage.<\/p>\n4.2 La fonction FIND : Flexibilit\u00e9 et arguments modificateurs<\/h3>\n Introduite pour pallier les contraintes rigides de la fonction INDEX<\/strong>, la fonction FIND<\/strong> constitue aujourd’hui la r\u00e9f\u00e9rence pour la recherche textuelle avanc\u00e9e sous SAS. Sa syntaxe g\u00e9n\u00e9rale s’articule autour de deux arguments obligatoires et de deux arguments optionnels : FIND(source, extrait <, modificateurs> <, position_depart>)<\/em>. \u00c0 l’instar d’INDEX<\/strong>, elle retourne un entier indiquant l’index de d\u00e9part du fragment d\u00e9tect\u00e9, ou z\u00e9ro en cas d’\u00e9chec de la correspondance.<\/p>\nLa puissance distinctive de FIND<\/strong> r\u00e9side dans l’int\u00e9gration native d’arguments modificateurs pass\u00e9s sous forme de cha\u00eenes litt\u00e9rales de caract\u00e8res. Les deux modificateurs les plus d\u00e9terminants pour le filtrage sont :<\/p>\n\nLe modificateur ‘i’ (ignore case) :<\/strong> Il rend la recherche totalement insensible \u00e0 la casse sans n\u00e9cessiter la conversion pr\u00e9alable de la variable source par les fonctions UPCASE ou LOWCASE. Cette \u00e9valuation directe au niveau du moteur de recherche interne optimise la consommation de m\u00e9moire cache et \u00e9vite les instanciations transitoires de cha\u00eenes modifi\u00e9es.<\/li>\nLe modificateur ‘t’ (trim) :<\/strong> Il neutralise automatiquement les espaces de remplissage terminaux (trailing blanks) de la sous-cha\u00eene recherch\u00e9e, \u00e9vitant ainsi les faux \u00e9checs caus\u00e9s par un extrait contenant des blancs r\u00e9siduels non d\u00e9sir\u00e9s.<\/li>\n<\/ul>\nCes modificateurs peuvent \u00eatre combin\u00e9s au sein d’un m\u00eame appel. Ainsi, l’instruction :<\/p>\n
WHERE FIND(Historique_Clinique, ‘diabete’, ‘it’) > 0;<\/em><\/p>\nlocalisera avec succ\u00e8s les occurrences telles que \u00ab Diab\u00e8te \u00bb, \u00ab DIABETE \u00bb ou \u00ab Diab\u00e8te de type 2 \u00bb, sans \u00e9gards pour la casse initiale et sans risque de distorsion li\u00e9 aux espaces de queue. De surcro\u00eet, le param\u00e8tre position_depart<\/em> permet d’initier la recherche \u00e0 un index pr\u00e9cis, voire d’inverser le sens de prospection (en sp\u00e9cifiant une position n\u00e9gative) pour explorer la cha\u00eene de droite \u00e0 gauche, conf\u00e9rant \u00e0 la fonction FIND<\/strong> une souplesse algorithmique in\u00e9gal\u00e9e.<\/p>\n4.3 La fonction FINDW : Ciblage des mots entiers<\/h3>\n L’un des d\u00e9fis les plus pernicieux du filtrage textuel par inclusion de sous-cha\u00eenes r\u00e9side dans le probl\u00e8me de l’encapsulation lexicale. Par exemple, si l’on recherche la sous-cha\u00eene \u00ab car \u00bb au moyen des fonctions INDEX<\/strong> ou FIND<\/strong>, le syst\u00e8me s\u00e9lectionnera in\u00e9vitablement des enregistrements contenant les mots \u00ab brancard \u00bb, \u00ab pancarte \u00bb ou \u00ab cardiaque \u00bb. Cette inclusion non intentionnelle g\u00e9n\u00e8re un volume substantiel de faux positifs qui fausse l’analyse.<\/p>\nPour r\u00e9soudre rigoureusement cette probl\u00e9matique, SAS propose la fonction FINDW<\/strong> (Find Word). La sp\u00e9cificit\u00e9 de FINDW<\/strong> est qu’elle n’\u00e9value pas simplement une s\u00e9quence contigu\u00eb d’octets, mais v\u00e9rifie que cette s\u00e9quence constitue un \u00ab mot \u00bb autonome au sens lexical. La signature de la fonction est la suivante : FINDW(source, mot <, delimiteurs> <, modificateurs> <, position_depart>)<\/em>.<\/p>\nPar d\u00e9faut, la fonction reconna\u00eet les d\u00e9limiteurs textuels standards de l’\u00e9criture occidentale (espaces, tabulations, ponctuations usuelles telles que le point, la virgule, le point-virgule ou le point d’exclamation). Il est toutefois possible de red\u00e9finir sur mesure la table des d\u00e9limiteurs accept\u00e9s via le troisi\u00e8me argument. Par ailleurs, FINDW<\/strong> int\u00e8gre \u00e9galement les modificateurs de la fonction FIND, notamment l’argument ‘i’ pour l’insensibilit\u00e9 \u00e0 la casse. Ainsi, l’instruction :<\/p>\nWHERE FINDW(Observations, ‘car’, ‘ ‘, ‘i’) > 0;<\/em><\/p>\nne retiendra que les lignes o\u00f9 le terme \u00ab car \u00bb appara\u00eet isol\u00e9 comme unit\u00e9 lexicale ind\u00e9pendante, garantissant ainsi une \u00e9tanch\u00e9it\u00e9 s\u00e9mantique absolue du filtrage par rapport aux mots compos\u00e9s ou d\u00e9riv\u00e9s.<\/p>\n
5. Gestion rigoureuse de la casse et harmonisation pr\u00e9alable<\/h2>\n5.1 Strat\u00e9gies de normalisation avec UPCASE et LOWCASE<\/h3>\n Dans de nombreuses architectures de production et d’entrep\u00f4ts de donn\u00e9es d\u00e9cisionnels (Data Warehouses), le filtrage direct n’est que l’aboutissement d’une \u00e9tape d’harmonisation textuelle pr\u00e9alable. La confrontation directe d’algorithmes de recherche avec des corpus textuels non normalis\u00e9s induit un co\u00fbt de traitement r\u00e9current. Pour standardiser ces flux, la conversion explicite de casse via les fonctions scalaires UPCASE<\/strong> (conversion int\u00e9grale en majuscules) et LOWCASE<\/strong> (conversion int\u00e9grale en minuscules) repr\u00e9sente la strat\u00e9gie d’ing\u00e9nierie la plus r\u00e9pandue.<\/p>\nLorsqu’elle est mise en \u0153uvre directement dans l’expression de s\u00e9lection, cette approche prend la forme d’un encapsulage fonctionnel :<\/p>\n
WHERE UPCASE(Description_Produit) LIKE ‘%ANTALGIQUE%’;<\/em><\/p>\nCependant, l’application it\u00e9rative de fonctions de modification de casse sur des colonnes volumineuses lors d’une \u00e9tape de filtrage implique une consommation non n\u00e9gligeable de cycles processeur. Pour chaque observation inspect\u00e9e, le moteur SAS doit cr\u00e9er une copie de la cha\u00eene en m\u00e9moire, transformer chaque octet alphab\u00e9tique en son \u00e9quivalent majuscule ou minuscule selon les tables d’encodage du syst\u00e8me d’exploitation, puis ex\u00e9cuter l’algorithme de concordance de motif. Sur des volum\u00e9tries atteignant plusieurs dizaines de gigaoctets, cette p\u00e9nalit\u00e9 computationnelle justifie pleinement la mise en \u0153uvre d’une phase de pr\u00e9paration distincte (data staging), au cours de laquelle une variable normalis\u00e9e d\u00e9di\u00e9e est mat\u00e9rialis\u00e9e de mani\u00e8re permanente sur le disque et index\u00e9e.<\/p>\n
5.2 Utilisation de la fonction PROPCASE pour les structures textuelles formelles<\/h3>\n En dehors des transformations unilat\u00e9rales en majuscules ou minuscules, la fonction PROPCASE<\/strong> applique une convention de casse dite \u00ab casse de nom propre \u00bb (Title Case ou Proper Case), o\u00f9 le premier caract\u00e8re de chaque mot est converti en majuscule tandis que les caract\u00e8res subs\u00e9quents sont transform\u00e9s en minuscules. Cette fonction accepte en second argument optionnel une liste de d\u00e9limiteurs personnalis\u00e9s permettant de contr\u00f4ler pr\u00e9cis\u00e9ment la fronti\u00e8re entre les unit\u00e9s lexicales.<\/p>\nLa fonction PROPCASE<\/strong> trouve son utilit\u00e9 principale dans l’assainissement de colonnes nominales structur\u00e9es, telles que les identit\u00e9s des patients, les d\u00e9signations g\u00e9ographiques ou les noms de sp\u00e9cialit\u00e9s pharmaceutiques saisis de mani\u00e8re d\u00e9sordonn\u00e9e dans des interfaces transactionnelles :<\/p>\nNom_Normalise = PROPCASE(Nom_Patient, \u00a0\u00bb -‘\u00a0\u00bb);<\/em><\/p>\nToutefois, son d\u00e9ploiement \u00e0 des fins de filtrage de sous-cha\u00eenes requiert une vigilance m\u00e9thodologique extr\u00eame. PROPCASE<\/strong> est inadapt\u00e9e au traitement de cha\u00eenes contenant des acronymes, des codes nosologiques normalis\u00e9s (tels que la CIM-10 ou le DSM-5) ou des terminologies scientifiques comportant des majuscules internes (par exemple, les noms de mol\u00e9cules comme \u00ab mRNA \u00bb ou \u00ab IFN-gamma \u00bb). Une conversion aveugle par PROPCASE<\/strong> risque de d\u00e9naturer la morphologie de ces motifs sp\u00e9cifiques et d’invalider par cons\u00e9quent la recherche de sous-cha\u00eenes cibl\u00e9es. Son emploi doit \u00eatre restreint aux flux de validation typographique de donn\u00e9es civiles ou administratives conventionnelles.<\/p>\n6. Filtrage par motifs complexes : Les expressions r\u00e9guli\u00e8res avec PRXMATCH<\/h2>\n6.1 Principes des fonctions Perl Regular Expressions (PRX) dans SAS<\/h3>\n Lorsque la condition de filtrage ne repose plus sur une s\u00e9quence litt\u00e9rale invariable, mais sur une classe de motifs syntaxiques hautement variables (tels que des structures de codes postaux h\u00e9t\u00e9rog\u00e8nes, des formats de num\u00e9ros de s\u00e9curit\u00e9 sociale ou des terminologies cliniques sujettes \u00e0 de multiples flexions morphologiques), les op\u00e9rateurs d\u00e9terministes comme CONTAINS<\/strong> ou FIND<\/strong> atteignent leurs limites structurales. SAS r\u00e9pond \u00e0 cette exigence analytique en int\u00e9grant nativement le moteur d’expressions r\u00e9guli\u00e8res compatibles avec le langage Perl (Perl Regular Expressions, ou PRX).<\/p>\nLa fonction ma\u00eetresse pour le filtrage par motif au sein de cette biblioth\u00e8que est PRXMATCH<\/strong>. Sa signature s’\u00e9nonce : PRXMATCH(motif_ou_id, source)<\/em>. La fonction retourne un entier indiquant la position de d\u00e9part du premier caract\u00e8re satisfaisant l’expression r\u00e9guli\u00e8re dans la cha\u00eene source, ou z\u00e9ro si le motif n’est pas localis\u00e9. La sp\u00e9cification du motif peut se faire de deux mani\u00e8res distinctes : soit par la fourniture directe d’une cha\u00eene litt\u00e9rale compil\u00e9e \u00e0 la vol\u00e9e d\u00e9limit\u00e9e par des barres obliques (par exemple, ‘\/motif\/’<\/em>), soit par l’utilisation d’un identifiant num\u00e9rique pr\u00e9compil\u00e9 g\u00e9n\u00e9r\u00e9 par la fonction PRXPARSE<\/strong>.<\/p>\nSur le plan de l’architecture logicielle, la pr\u00e9compilation via PRXPARSE<\/strong> repr\u00e9sente la norme d’excellence au sein de l’\u00e9tape DATA. Elle compile l’automate d’\u00e9tats finis de l’expression r\u00e9guli\u00e8re une seule et unique fois lors de la phase d’initialisation de l’\u00e9tape DATA, \u00e9vitant ainsi le co\u00fbt prohibitif d’une recompilation syntaxique \u00e0 chaque nouvelle observation trait\u00e9e dans la boucle d’ex\u00e9cution.<\/p>\n6.2 \u00c9criture de motifs textuels pour le filtrage d’enregistrements<\/h3>\n La puissance du moteur PRX r\u00e9side dans la richesse de sa m\u00e9tasyntaxe, qui permet de d\u00e9finir des abstractions de motifs d’une grande compacit\u00e9. Le programmeur peut employer des classes de caract\u00e8res (par exemple, d<\/em> pour tout chiffre, w<\/em> pour tout caract\u00e8re alphanum\u00e9rique), des quantificateurs d’occurrence (+<\/em>, *<\/em>, {n,m}<\/em>), des m\u00e9tacaract\u00e8res d’ancrage (^<\/em> pour borner au d\u00e9but de la cha\u00eene, $<\/em> pour borner \u00e0 la fin) ainsi que des op\u00e9rateurs de disjonction logique (|<\/em>).<\/p>\nConsid\u00e9rons le besoin d’isoler dans un registre \u00e9pid\u00e9miologique l’ensemble des mentions textuelles renvoyant \u00e0 une affection coronaire aigu\u00eb, sous des orthographes variables telles que \u00ab infarctus \u00bb, \u00ab isch\u00e9mie \u00bb ou leurs formes abr\u00e9g\u00e9es m\u00e9dicales courantes. Une clause de s\u00e9lection bas\u00e9e sur PRXMATCH<\/strong> s’\u00e9crira au sein de l’\u00e9tape DATA :<\/p>\nIF PRXMATCH(‘\/(infarctus|ischem(ie|ique)|sca)\/i’, Diagnostic_Texte) > 0 THEN OUTPUT;<\/em><\/p>\nDans cette formulation, l’expression r\u00e9guli\u00e8re r\u00e9sout trois d\u00e9fis en une seule passe : l’op\u00e9rateur de disjonction (barre verticale) prend en charge l’alternative lexicale ; les parenth\u00e8ses groupent les sous-motifs morphologiques ; et le modificateur final ‘i’ garantit une insensibilit\u00e9 totale \u00e0 la casse. De m\u00eame, l’usage des ancres permet d’\u00e9viter les pi\u00e8ges de d\u00e9tection non voulue :<\/p>\n
WHERE PRXMATCH(‘\/^DIABd{2}\/’, Code_Diagnostic) > 0;<\/em><\/p>\nCette condition filtrera exclusivement les enregistrements dont la cha\u00eene commence obligatoirement par le pr\u00e9fixe \u00ab DIAB \u00bb suivi d’exactement deux chiffres, rejetant toute ligne o\u00f9 ce motif appara\u00eetrait de fa\u00e7on fortuite au milieu ou \u00e0 la fin du champ.<\/p>\n
6.3 Comparaison de robustesse : Op\u00e9rateurs standards contre PRXMATCH<\/h3>\n L’arbitrage entre l’usage des op\u00e9rateurs scalaires standards (CONTAINS<\/strong>, FIND<\/strong>) et le recours aux expressions r\u00e9guli\u00e8res (PRXMATCH<\/strong>) implique un compromis critique entre expressivit\u00e9 syntaxique et charge computationnelle. Le d\u00e9ploiement d’un moteur d’expressions r\u00e9guli\u00e8res s’accompagne d’une surconsommation notable de cycles CPU due \u00e0 la complexit\u00e9 de l’automate d\u00e9terministe ou non d\u00e9terministe sous-jacent, capable de revenir sur ses pas (backtracking) lors de motifs ambigus.<\/p>\nLes m\u00e9triques de performance d\u00e9montrent que pour la recherche d’une sous-cha\u00eene fixe et invariable, l’op\u00e9rateur CONTAINS<\/strong> ou la fonction FIND<\/strong> ex\u00e9cutent la requ\u00eate entre 3 et 10 fois plus vite que PRXMATCH<\/strong>. En cons\u00e9quence, la r\u00e8gle architecturale pr\u00e9conise de restreindre l’usage de PRXMATCH aux cas de figure o\u00f9 les op\u00e9rateurs traditionnels n\u00e9cessiteraient une prolif\u00e9ration ing\u00e9rable de clauses conditionnelles imbriqu\u00e9es ou l’application de cascades de fonctions textuelles difficilement maintenables.<\/p>\nEn termes de maintenabilit\u00e9 applicative, les expressions r\u00e9guli\u00e8res introduisent \u00e9galement une dette technique potentielle. La lisibilit\u00e9 d’un motif complexe peut \u00eatre ardue pour des relecteurs de code tiers. Il est donc recommand\u00e9 d’accompagner syst\u00e9matiquement les motifs PRX d’une documentation interne explicitant la grammaire formelle recherch\u00e9e, afin de p\u00e9renniser la conformit\u00e9 du code au sein des environnements d’analyse collaboratifs.<\/p>\n
7. Diff\u00e9rences fondamentales entre les instructions WHERE et IF<\/h2>\n7.1 Moment d’\u00e9valuation dans le pipeline de donn\u00e9es SAS<\/h3>\n Pour concevoir des filtres d’une efficacit\u00e9 optimale, le d\u00e9veloppeur SAS doit ma\u00eetriser la chronologie exacte de l’ex\u00e9cution des instructions \u00e0 l’int\u00e9rieur du moteur de donn\u00e9es. L’instruction WHERE<\/strong> et le sous-ensemble conditionnel IF<\/strong> illustrent deux moments d’intervention profond\u00e9ment discordants dans le pipeline de traitement, tel que synth\u00e9tis\u00e9 ci-dessous :<\/p>\n\nInstruction WHERE :<\/strong> \u00c9valuation pr\u00e9coce au niveau du moteur de lecture (Engine level). L’observation est inspect\u00e9e directement depuis le flux disque\/tampon. Si la condition textuelle n’est pas satisfaite, l’observation est \u00e9limin\u00e9e imm\u00e9diatement sans jamais franchir le seuil du Program Data Vector (PDV).<\/li>\nInstruction IF :<\/strong> \u00c9valuation tardive au sein de l’\u00e9tape DATA (Program execution level). L’observation est obligatoirement charg\u00e9e dans le PDV, les adresses m\u00e9moire des variables sont r\u00e9solues, et les \u00e9ventuelles op\u00e9rations d’assignation amont sont ex\u00e9cut\u00e9es avant que le pr\u00e9dicat ne soit analys\u00e9.<\/li>\n<\/ul>\nCette divergence structurelle produit un impact d\u00e9terminant sur les performances globales du syst\u00e8me d’information. Sur des tables contenant des dizaines de millions d’enregistrements, l’instruction WHERE<\/strong> pr\u00e9serve la bande passante du bus d’entr\u00e9es\/sorties en \u00e9liminant un volume consid\u00e9rable d’enregistrements superflus d\u00e8s la phase d’ingestion. \u00c0 l’inverse, l’instruction IF<\/strong> sollicite l’int\u00e9gralit\u00e9 du cycle de transfert des donn\u00e9es vers le PDV pour chaque ligne de la table source, rendant le traitement consid\u00e9rablement plus lent d\u00e8s lors que le taux de rejet du filtre est \u00e9lev\u00e9.<\/p>\n7.2 Disponibilit\u00e9 des variables d\u00e9riv\u00e9es et calcul\u00e9es<\/h3>\n La contrepartie directe de l’\u00e9valuation pr\u00e9coce de l’instruction WHERE<\/strong> r\u00e9side dans son imperm\u00e9abilit\u00e9 totale aux variables cr\u00e9\u00e9es, d\u00e9riv\u00e9es ou modifi\u00e9es \u00e0 l’int\u00e9rieur m\u00eame de l’\u00e9tape DATA en cours d’ex\u00e9cution. \u00c9tant donn\u00e9 que le moteur WHERE<\/strong> r\u00e9sout ses conditions avant l’instanciation du PDV, il ne poss\u00e8de aucune visibilit\u00e9 sur les colonnes n\u00e9es de calculs arithm\u00e9tiques, de concat\u00e9nations textuelles ou de lectures conditionnelles intervenant plus bas dans le script.<\/p>\nSoit l’exemple d’un script visant \u00e0 concat\u00e9ner deux champs textuels distincts avant filtrage :<\/p>\n
DATA Patients_Cibles; SET Registre_Initial; Libelle_Complet = CATX(‘ – ‘, Code_Pathologie, Description); IF FIND(Libelle_Complet, ‘Critique’, ‘i’) > 0; RUN;<\/em><\/p>\nDans ce sc\u00e9nario, l’utilisation de l’instruction WHERE FIND(Libelle_Complet, ‘Critique’, ‘i’) > 0;<\/em> provoquerait un arr\u00eat imm\u00e9diat de la compilation SAS avec un message d’erreur stipulant que la variable Libelle_Complet<\/em> est introuvable sur la table source Registre_Initial<\/em>. L’instruction IF<\/strong> devient donc structurellement incontournable d\u00e8s lors que la s\u00e9lection repose sur des agr\u00e9gats ou des mutations textuelles synth\u00e9tis\u00e9s au vol.<\/p>\nPour optimiser de tels cas de figure, une strat\u00e9gie hybride est fr\u00e9quemment mise en \u0153uvre : un pr\u00e9-filtrage par WHERE<\/strong> \u00e9limine le gros des donn\u00e9es brutes in\u00e9ligibles en amont, puis un affinage conditionnel par IF<\/strong> op\u00e8re sur les variables calcul\u00e9es au sein du sous-ensemble restreint, combinant ainsi \u00e9conomie d’entr\u00e9es\/sorties et souplesse transformationnelle.<\/p>\n7.3 Compatibilit\u00e9 des instructions avec les proc\u00e9dures SAS (PROC SQL, PROC PRINT)<\/h3>\n L’universalit\u00e9 fonctionnelle de la clause WHERE<\/strong> constitue un atout capital dans l’architecture SAS. Alors que l’instruction IF<\/strong> est strictement confin\u00e9e au p\u00e9rim\u00e8tre de l’\u00e9tape DATA, la clause WHERE<\/strong> peut \u00eatre d\u00e9ploy\u00e9e au sein de la quasi-totalit\u00e9 des proc\u00e9dures analytiques et de reporting (notamment PROC PRINT, PROC FREQ, PROC MEANS, PROC SUMMARY, PROC REG ou PROC LOGISTIC). Cette int\u00e9gration permet d’ex\u00e9cuter des analyses statistiques ou des pr\u00e9sentations tabulaires directement sur un sous-ensemble textuel sans avoir \u00e0 mat\u00e9rialiser au pr\u00e9alable une table interm\u00e9diaire sur le disque de travail (biblioth\u00e8que WORK).<\/p>\nDe surcro\u00eet, au sein de l’environnement PROC SQL<\/strong>, la clause WHERE<\/strong> s’aligne fid\u00e8lement sur les normes internationales du standard ANSI SQL. Lors de l’interrogation de bases de donn\u00e9es relationnelles distantes via le composant SAS\/ACCESS, le moteur SAS est capable d’effectuer une \u00ab pouss\u00e9e de pr\u00e9dicat \u00bb (Predicate Pushdown). Il traduit la clause SAS en dialecte SQL natif du serveur cible (par exemple, transformation de l’op\u00e9rateur CONTAINS en un pr\u00e9dicat relationnel LIKE ‘%valeur%’<\/em>) et d\u00e9l\u00e8gue l’effort de filtrage textuel au serveur de base de donn\u00e9es h\u00f4te, rapatriant uniquement les enregistrements pertinents \u00e0 travers le r\u00e9seau informatique.<\/p>\n8. Optimisation des performances lors du filtrage textuel massif<\/h2>\n8.1 Utilisation des index SAS sur les variables de type caract\u00e8re<\/h3>\n L’optimisation du temps d’acc\u00e8s aux enregistrements lors du filtrage de volum\u00e9tries massives repose largement sur la conception et l’exploitation d’index SAS simples ou composites. Un index SAS est une structure arborescente (g\u00e9n\u00e9ralement un B-Tree) stock\u00e9e dans un fichier distinct (.sas7bndx), qui associe les valeurs distinctes d’une variable aux identifiants physiques des observations correspondantes (Records ID). Toutefois, l’interaction entre les index et les crit\u00e8res de filtrage textuel ob\u00e9it \u00e0 des contraintes techniques tr\u00e8s rigides.<\/p>\n
Pour qu’un index textuel puisse \u00eatre exploit\u00e9 efficacement par l’optimiseur de requ\u00eates SAS dans une clause WHERE<\/strong>, la condition doit porter sur une correspondance exacte (op\u00e9rateur d’\u00e9galit\u00e9 ou op\u00e9rateur IN<\/strong>) ou sur une recherche de pr\u00e9fixe d\u00e9butant au premier octet de la cha\u00eene. D\u00e8s lors que l’on emploie l’op\u00e9rateur CONTAINS<\/strong> ou des fonctions de recherche scalaire (FIND<\/strong>, INDEX<\/strong>), l’index devient structurellement inop\u00e9rant. En effet, l’architecture B-Tree est con\u00e7ue pour ordonner les cha\u00eenes de gauche \u00e0 droite ; elle ne permet pas de localiser efficacement une sous-cha\u00eene dont l’ancrage initial est ind\u00e9termin\u00e9 sans parcourir l’ensemble de la structure arborescente.<\/p>\nEn pr\u00e9sence d’une clause du type WHERE Nom_Variable CONTAINS ‘motif’<\/em>, l’optimiseur de requ\u00eates SAS d\u00e9sactive l’index et bascule syst\u00e9matiquement sur un balayage s\u00e9quentiel int\u00e9gral de la table (Full Table Scan). Le d\u00e9veloppeur ne doit donc pas pr\u00e9sumer qu’une colonne index\u00e9e acc\u00e9l\u00e9rera automatiquement une recherche d’inclusion arbitraire.<\/p>\n8.2 Gestion de la m\u00e9moire et s\u00e9lection des colonnes (Instruction KEEP\/DROP)<\/h3>\n L’allocation de m\u00e9moire pour le Program Data Vector est directement proportionnelle \u00e0 la somme des longueurs d\u00e9clar\u00e9es de l’ensemble des variables composant l’enregistrement. Dans le traitement de m\u00e9gadonn\u00e9es comportant des variables textuelles \u00e9tendues (pouvant atteindre plusieurs milliers d’octets par colonne), la saturation de la bande passante m\u00e9moire devient le principal goulot d’\u00e9tranglement de l’application.<\/p>\n
Pour maximiser le d\u00e9bit de traitement lors des op\u00e9rations de filtrage textuel intensif, il est fondamental de purger imm\u00e9diatement le flux des colonnes non indispensables \u00e0 la cha\u00eene d’analyse via les options de table KEEP=<\/strong> ou DROP=<\/strong> directement lors de l’instruction d’entr\u00e9e SET<\/strong> :<\/p>\nDATA Resultat; SET Source(KEEP=Identifiant Commentaire Statut); WHERE FIND(Commentaire, ‘Urgence’, ‘i’) > 0; RUN;<\/em><\/p>\nCette sp\u00e9cification pr\u00e9vient le chargement en m\u00e9moire vive de dizaines d’autres colonnes volumineuses pour les observations qui seront in fine rejet\u00e9es par le filtre textuel. Parall\u00e8lement, un dimensionnement strict des variables \u00e0 l’aide de l’instruction LENGTH<\/strong> permet d’ajuster l’enveloppe m\u00e9moire allou\u00e9e au strict n\u00e9cessaire, \u00e9vitant de r\u00e9server des allocations standard de 200 octets pour des codes diagnostiques n’en exploitant qu’une dizaine. Une r\u00e9duction de moiti\u00e9 de la largeur du PDV se traduit quasi-lin\u00e9airement par un doublement de la vitesse de balayage s\u00e9quentiel par le microprocesseur.<\/p>\n8.3 Utilisation de l’op\u00e9rateur LIKE et comparaison avec les jokers SQL<\/h3>\n L’op\u00e9rateur LIKE<\/strong> constitue un compromis d’une redoutable efficacit\u00e9 entre la simplicit\u00e9 de l’op\u00e9rateur CONTAINS et la rigueur d’acc\u00e8s permise par les index. Issu de la normalisation relationnelle SQL, l’op\u00e9rateur LIKE<\/strong> s’appuie sur deux m\u00e9tacaract\u00e8res universels :<\/p>\n\nLe symbole pourcentage (%) :<\/strong> Repr\u00e9sente n’importe quelle s\u00e9quence de z\u00e9ro, un ou plusieurs caract\u00e8res.<\/li>\nLe symbole trait de soulignement (_) :<\/strong> Repr\u00e9sente un unique caract\u00e8re arbitraire quelconque.<\/li>\n<\/ul>\nDans la formulation d’un filtre textuel, la clause WHERE Variable LIKE ‘%cible%’<\/em> produit un r\u00e9sultat s\u00e9mantiquement \u00e9quivalent \u00e0 WHERE Variable CONTAINS ‘cible’<\/em>. Toutefois, la sup\u00e9riorit\u00e9 structurelle de LIKE<\/strong> r\u00e9side dans sa capacit\u00e9 \u00e0 restreindre l’ambigu\u00eft\u00e9 de position. Si le praticien sait que la sous-cha\u00eene recherch\u00e9e commence obligatoirement par un radical pr\u00e9cis, l’expression s’\u00e9noncera sous la forme d’une recherche de pr\u00e9fixe :<\/p>\nWHERE Code_Classification LIKE ‘CARDIO%’;<\/em><\/p>\nContrairement \u00e0 CONTAINS<\/strong>, une condition LIKE<\/strong> configur\u00e9e sous forme de pr\u00e9fixe (sans le m\u00e9tacaract\u00e8re ‘%’ en premi\u00e8re position) est reconnue par l’optimiseur de requ\u00eates SAS comme \u00e9tant \u00e9ligible \u00e0 l’utilisation des index B-Tree. Le moteur peut alors effectuer une recherche par saut d’index direct pour extraire les enregistrements en quelques millisecondes, \u00e9vitant ainsi le balayage de dizaines de millions de lignes.<\/p>\n9. Nettoyage des donn\u00e9es et gestion des valeurs manquantes<\/h2>\n9.1 Traitement des espaces superflus avec STRIP, COMPBL et COMPRESS<\/h3>\n L’incoh\u00e9rence des espaces blancs constitue la cause principale d’anomalies lors de l’application de filtres textuels sous SAS. Des cha\u00eenes contenant des blancs ins\u00e9cables, des tabulations ind\u00e9sirables, des doubles espaces interstitiels ou des espaces r\u00e9siduels en t\u00eate de variable peuvent invalider silencieusement les crit\u00e8res de filtrage les plus \u00e9labor\u00e9s. Un protocole robuste d’assainissement s’appuie sur un triptyque fonctionnel hautement sp\u00e9cialis\u00e9 :<\/p>\n
\nLa fonction STRIP :<\/strong> \u00c9limine l’ensemble des espaces situ\u00e9s \u00e0 l’avant (leading blanks) et \u00e0 l’arri\u00e8re (trailing blanks) de la cha\u00eene. Elle s’av\u00e8re nettement sup\u00e9rieure \u00e0 la fonction TRIM<\/strong> historique, qui n’assure que le nettoyage des espaces de queue sans alt\u00e9rer les blancs de t\u00eate.<\/li>\nLa fonction COMPBL :<\/strong> Identifie toutes les s\u00e9quences de deux espaces cons\u00e9cutifs ou plus \u00e0 l’int\u00e9rieur d’une cha\u00eene et les compresse en un unique espace standard. Elle est indispensable pour normaliser les verbatims avant toute analyse lexicale.<\/li>\nLa fonction COMPRESS :<\/strong> Dans sa configuration standard, elle supprime l’int\u00e9gralit\u00e9 des espaces d’une variable. Dot\u00e9e de modificateurs optionnels, elle permet de purger de mani\u00e8re cibl\u00e9e des familles enti\u00e8res de glyphes, tels que la ponctuation, les caract\u00e8res de contr\u00f4le non imprimables ou les caract\u00e8res num\u00e9riques.<\/li>\n<\/ul>\nL’incorporation de ces fonctions au sein m\u00eame de la logique de filtrage permet d’immuniser le traitement contre les perturbations typographiques structurelles :<\/p>\n
WHERE FIND(COMPBL(STRIP(Libelle_Entree)), ‘Condition Cible’, ‘i’) > 0;<\/em><\/p>\nCette instruction garantit que ni un espace superflu plac\u00e9 accidentellement au d\u00e9but du champ par l’op\u00e9rateur de saisie, ni une double frappe de la barre d’espace entre les termes ne pourront faire \u00e9chec \u00e0 l’inclusion de l’observation dans la cohorte d’analyse.<\/p>\n
9.2 Interaction entre filtres de cha\u00eenes et valeurs manquantes (Missing Values)<\/h3>\n La s\u00e9mantique des valeurs manquantes pour les variables textuelles sous SAS diverge substantiellement de celle des variables num\u00e9riques. Tandis qu’une absence de valeur num\u00e9rique est encod\u00e9e en interne par un point (. ou lettres sp\u00e9ciales pour les missing values \u00e9tendues), une valeur manquante de caract\u00e8re est tout simplement repr\u00e9sent\u00e9e par une cha\u00eene de longueur fixe int\u00e9gralement remplie d’espaces blancs, commun\u00e9ment d\u00e9sign\u00e9e sous le terme de cha\u00eene vide (blank string).<\/p>\n
L’application d’un op\u00e9rateur de filtrage textuel sur une variable contenant une valeur manquante induit des comportements contrast\u00e9s qu’il importe de ma\u00eetriser pour pr\u00e9venir les distorsions d’\u00e9chantillonnage :<\/p>\n
\nSi l’on \u00e9value l’\u00e9galit\u00e9 par rapport \u00e0 une cha\u00eene vide (WHERE Variable = ‘ ‘;<\/em>), l’expression retourne VRAI pour toute observation n’abritant que des espaces.<\/li>\nSi l’on applique l’op\u00e9rateur
![\"\"](\"http:\/\/french.arabpsychology.com\/wp-content\/uploads\/2026\/09\/contains1.jpg\")
<\/figure>\n![\"\"](\"http:\/\/french.arabpsychology.com\/wp-content\/uploads\/2026\/09\/contains2.jpg\")
<\/figure>\n