{"id":9913,"date":"2026-10-14T18:02:35","date_gmt":"2026-10-14T18:02:35","guid":{"rendered":"http:\/\/french.arabpsychology.com\/statistics\/comment-sous-ensembler-donnees-sas-exemples\/"},"modified":"2026-10-14T18:02:35","modified_gmt":"2026-10-14T18:02:35","slug":"comment-sous-ensembler-donnees-sas-exemples","status":"publish","type":"psych_stat","link":"https:\/\/french.arabpsychology.com\/?psych_stat=comment-sous-ensembler-donnees-sas-exemples","title":{"rendered":"Comment cr\u00e9er un sous-ensemble de donn\u00e9es dans SAS (3 exemples)"},"content":{"rendered":"

Dans le domaine de l’ing\u00e9nierie logicielle et du traitement analytique des donn\u00e9es massives, le syst\u00e8me SAS (Statistical Analysis System<\/a>) demeure une r\u00e9f\u00e9rence institutionnelle incontournable au sein des industries bancaires, pharmaceutiques, \u00e9pid\u00e9miologiques et assurantielles. La manipulation efficace des structures tabulaires constitue le socle fondamental sur lequel reposent l’int\u00e9grit\u00e9, la robustesse et la rapidit\u00e9 des calculs statistiques. L’op\u00e9ration de sous-ensemble, commun\u00e9ment d\u00e9sign\u00e9e par le terme anglophone subsetting<\/em>, repr\u00e9sente l’un des m\u00e9canismes les plus critiques de cette cha\u00eene de traitement. Elle consiste \u00e0 extraire de mani\u00e8re d\u00e9terministe une sous-partie congrue d’une table ma\u00eetresse, soit en isolant des variables pertinentes, soit en filtrant des observations selon des crit\u00e8res logiques rigoureux.<\/p>\n

Une gestion non optimis\u00e9e des sous-ensembles de donn\u00e9es engendre fr\u00e9quemment des goulots d’\u00e9tranglement majeurs, caract\u00e9ris\u00e9s par une saturation de la m\u00e9moire vive et une sollicitation excessive des op\u00e9rations d’entr\u00e9e-sortie (I\/O) sur disque. Lorsque les jeux de donn\u00e9es atteignent des dizaines de gigaoctets ou des centaines de millions d’enregistrements, l’incapacit\u00e9 \u00e0 restreindre pr\u00e9cocement le volume d’informations trait\u00e9es p\u00e9nalise lourdement les performances globales de l’infrastructure informatique. L’ing\u00e9nieur d\u00e9cisionnel et le biostatisticien doivent par cons\u00e9quent ma\u00eetriser avec une exactitude chirurgicale les rouages internes de l’\u00e9tape DATA de SAS, ainsi que le comportement intime du vecteur de donn\u00e9es du programme (Program Data Vector, ou PDV).<\/p>\n

Ce trait\u00e9 technique a pour vocation d’exposer de mani\u00e8re exhaustive, m\u00e9thodique et document\u00e9e la th\u00e9orie et la pratique du partitionnement de donn\u00e9es au sein de l’\u00e9cosyst\u00e8me SAS. \u00c0 travers l’analyse m\u00e9ticuleuse d’un jeu de donn\u00e9es de r\u00e9f\u00e9rence normalis\u00e9, nous d\u00e9cortiquerons trois approches canoniques : l’extraction de variables par l’instruction KEEP<\/code>, l’\u00e9viction cibl\u00e9e de colonnes via l’instruction DROP<\/code>, et l’exclusion conditionnelle d’observations fond\u00e9e sur la clause IF-THEN DELETE<\/code>. Nous \u00e9largirons ensuite cette analyse aux instructions WHERE<\/code>, au subsetting IF<\/em>, ainsi qu’aux options de tables, tout en int\u00e9grant les imp\u00e9ratifs m\u00e9thodologiques propres \u00e0 la recherche quantitative.<\/p>\n

1. Introduction aux principes du sous-ensemble de donn\u00e9es dans SAS<\/h2>\n

1.1 D\u00e9finition et importance de la r\u00e9duction dimensionnelle des donn\u00e9es<\/h3>\n

Dans l’architecture de donn\u00e9es relationnelle et tabulaire de SAS, le partitionnement ou sous-ensemble se scinde en deux dimensions g\u00e9om\u00e9triques compl\u00e9mentaires : la r\u00e9duction verticale et la r\u00e9duction horizontale. La r\u00e9duction verticale correspond \u00e0 la s\u00e9lection exclusive des colonnes, attributs ou variables indispensables \u00e0 l’\u00e9tude envisag\u00e9e, \u00e9liminant ainsi les dimensions superflues qui alourdissent inutilement la largeur de chaque enregistrement. \u00c0 l’inverse, la r\u00e9duction horizontale rel\u00e8ve du filtrage des lignes ou observations, ne conservant que les unit\u00e9s statistiques r\u00e9pondant formellement \u00e0 un faisceau de crit\u00e8res logico-math\u00e9matiques pr\u00e9d\u00e9finis.<\/p>\n

L’importance de cette double r\u00e9duction s’\u00e9value au regard des contraintes physiques des syst\u00e8mes informatiques. Bien que les architectures modernes b\u00e9n\u00e9ficient de capacit\u00e9s d’adressage m\u00e9moire \u00e9tendues, l’empreinte spatiale d’une table influe directement sur les cycles CPU n\u00e9cessaires \u00e0 son balayage s\u00e9quentiel et sur la taille des blocs de transfert entre les sous-syst\u00e8mes de stockage et la m\u00e9moire cache. Selon les standards architecturaux d\u00e9finis par l’Organisation internationale de normalisation<\/a> en mati\u00e8re d’efficacit\u00e9 logicielle, la limitation pr\u00e9coce du p\u00e9rim\u00e8tre des donn\u00e9es constitue le premier levier de fiabilisation d’un pipeline analytique.<\/p>\n

Dans la perspective de la mod\u00e9lisation statistique avanc\u00e9e (r\u00e9gressions multivari\u00e9es, analyses factorielles, mod\u00e8les \u00e0 \u00e9quations structurelles), la constitution d’une matrice \u00e9pur\u00e9e pr\u00e9vient les erreurs d’alignement dimensionnel et simplifie consid\u00e9rablement la phase d’audit. Une table all\u00e9g\u00e9e r\u00e9duit le risque de redondance d’information, limite la pr\u00e9sence de valeurs aberrantes ou manquantes non document\u00e9es, et garantit que seules les covariables valid\u00e9es sur le plan th\u00e9orique participent \u00e0 l’ajustement des param\u00e8tres.<\/p>\n

1.2 Structure g\u00e9n\u00e9rale de l’\u00e9tape DATA et cycle d’ex\u00e9cution<\/h3>\n

L’\u00e9tape DATA repr\u00e9sente le moteur proc\u00e9dural et transformationnel fondamental du langage SAS. Contrairement aux proc\u00e9dures pr\u00e9-param\u00e9tr\u00e9es (telles que PROC REG<\/code>, PROC MEANS<\/code> ou PROC FREQ<\/code>) dont l’ex\u00e9cution repose sur des algorithmes matriciels fig\u00e9s, l’\u00e9tape DATA offre un environnement de programmation it\u00e9ratif et s\u00e9quentiel d’une grande granularit\u00e9. Sa vocation premi\u00e8re r\u00e9side dans l’ingestion, le nettoyage, la restructuration et la persistance de l’information sous la forme de nouvelles tables SAS propri\u00e9taires.<\/p>\n

Au c\u0153ur de cette \u00e9tape se trouve l’instruction SET<\/code>, qui agit comme le connecteur logique vers une ou plusieurs tables SAS pr\u00e9alablement mat\u00e9rialis\u00e9es sur le disque dur ou dans une biblioth\u00e8que temporaire (g\u00e9n\u00e9ralement la biblioth\u00e8que WORK<\/code>). L’instruction SET<\/code> prend en charge l’ouverture de la table source, la lecture s\u00e9quentielle des descripteurs de m\u00e9tadonn\u00e9es, ainsi que le chargement successif de chaque enregistrement physique dans les zones tampons du compilateur SAS.<\/p>\n

Le cycle d’ex\u00e9cution de l’\u00e9tape DATA ob\u00e9it \u00e0 une boucle implicite strictement r\u00e9gul\u00e9e. \u00c0 chaque it\u00e9ration de la boucle, l’environnement SAS ex\u00e9cute de haut en bas l’int\u00e9gralit\u00e9 des instructions programm\u00e9es par l’utilisateur. D\u00e8s que le pointeur atteint la fin structurelle de l’\u00e9tape DATA (marqu\u00e9e par le mot-cl\u00e9 RUN;<\/code>), le syst\u00e8me d\u00e9clenche une \u00e9criture automatique des valeurs courantes dans la table de destination, r\u00e9initialise les zones m\u00e9moires non persistantes, puis incr\u00e9mente son compteur interne avant de charger l’observation suivante issue de l’instruction SET<\/code>. Ce m\u00e9canisme de boucle implicite perdure jusqu’\u00e0 ce que le pointeur d’entr\u00e9e atteigne le marqueur de fin de fichier (EOF, End-Of-File<\/em>).<\/p>\n

1.3 Objectifs p\u00e9dagogiques et aper\u00e7u des trois m\u00e9thodes fondamentales<\/h3>\n

L’objectif de cet expos\u00e9 est de doter le programmeur, le biostatisticien et l’analyste de donn\u00e9es d’une grille de lecture rigoureuse concernant l’impact algorithmique de ses choix de syntaxe. Trop souvent, les instructions de s\u00e9lection sont employ\u00e9es de fa\u00e7on interchangeable sans une compr\u00e9hension claire de leurs r\u00e9percussions sur l’architecture m\u00e9moire du syst\u00e8me. Nous nous proposons de d\u00e9composer la logique formelle de trois op\u00e9rations canoniques afin de lever toute ambigu\u00eft\u00e9 op\u00e9rationnelle.<\/p>\n

La premi\u00e8re m\u00e9thode analys\u00e9e s’articule autour de l’instruction KEEP<\/code>. D\u00e9di\u00e9e \u00e0 la s\u00e9lection affirmative des colonnes, cette instruction permet de d\u00e9clarer express\u00e9ment la liste des variables dont la pr\u00e9sence est requise dans la table r\u00e9sultante. Elle incarne le principe de s\u00e9curit\u00e9 par d\u00e9faut : toute variable non mentionn\u00e9e est irr\u00e9vocablement exclue de la sortie d\u00e9finitive, pr\u00e9munissant ainsi le syst\u00e8me contre la persistance involontaire de variables sensibles ou parasites.<\/p>\n

La deuxi\u00e8me m\u00e9thode repose sur l’usage sym\u00e9trique de l’instruction DROP<\/code>. Utilis\u00e9e pour l’\u00e9lagage cibl\u00e9, elle sp\u00e9cifie nominativement les variables qui doivent \u00eatre rejet\u00e9es de la table finale, tout en maintenant automatiquement l’ensemble des autres colonnes d\u00e9finies dans la table source. Cette approche s’av\u00e8re particuli\u00e8rement ergonomique lorsqu’une fraction n\u00e9gligeable du dictionnaire de donn\u00e9es doit \u00eatre \u00e9limin\u00e9e.<\/p>\n

La troisi\u00e8me m\u00e9thode aborde la r\u00e9duction horizontale \u00e0 travers la construction conditionnelle IF-THEN DELETE<\/code>. Ce paradigme combine l’\u00e9valuation d’un pr\u00e9dicat bool\u00e9en et le d\u00e9clenchement d’une rupture imm\u00e9diate de l’it\u00e9ration courante. Lorsqu’une observation \u00e9choue au test logique, l’instruction DELETE<\/code> ordonne au syst\u00e8me d’avorter l’\u00e9criture de l’enregistrement dans la table cible et de r\u00e9orienter instantan\u00e9ment le pointeur d’ex\u00e9cution vers l’en-t\u00eate de la boucle de l’\u00e9tape DATA pour traiter la ligne suivante.<\/p>\n

2. Architecture interne du Program Data Vector (PDV) et flux de donn\u00e9es<\/h2>\n

2.1 Le r\u00f4le du Program Data Vector lors de la compilation<\/h3>\n

L’\u00e9tape DATA ne s’ex\u00e9cute pas de mani\u00e8re interpr\u00e9t\u00e9e directe ; elle subit pr\u00e9alablement une phase de compilation formelle au cours de laquelle SAS construit une structure m\u00e9moire d\u00e9di\u00e9e appel\u00e9e le Program Data Vector (PDV). Le PDV repr\u00e9sente la zone de travail en m\u00e9moire vive (RAM) o\u00f9 sont mat\u00e9rialis\u00e9es les colonnes de donn\u00e9es lors du traitement de chaque observation. Durant cette phase de compilation, le compilateur lit le code s\u00e9quentiellement afin d’identifier l’ensemble des variables d\u00e9clar\u00e9es, de d\u00e9terminer leur type (num\u00e9rique ou caract\u00e8re) et d’allouer la longueur en octets requise pour chacune d’elles.<\/p>\n

En sus des variables explicites issues des tables sources ou cr\u00e9\u00e9es par le programmeur, le compilateur SAS injecte syst\u00e9matiquement deux variables automatiques au sein du PDV : _N_<\/code> et _ERROR_<\/code>. La variable _N_<\/code> fonctionne comme un compteur d’it\u00e9rations de l’\u00e9tape DATA, d\u00e9butant \u00e0 la valeur 1 et s’incr\u00e9mentant \u00e0 chaque retour au sommet de la boucle logique. La variable _ERROR_<\/code> agit comme un drapeau d’int\u00e9grit\u00e9 binaire, prenant la valeur 0 en r\u00e9gime normal et passant \u00e0 la valeur 1 d\u00e8s lors qu’une anomalie intervient en cours d’ex\u00e9cution (conversion de type invalide, division par z\u00e9ro, ou d\u00e9bordement math\u00e9matique).<\/p>\n

Il est imp\u00e9ratif de souligner que les variables automatiques _N_<\/code> et _ERROR_<\/code> poss\u00e8dent des attributs internes particuliers : elles sont temporaires et ne sont jamais \u00e9crites sur le disque dans la table SAS finale. Le PDV agit ainsi comme une interface de conversion entre les flux d’octets bruts persistants et les environnements d’\u00e9valuation alg\u00e9brique du processeur.<\/p>\n

\"\"<\/figure>\n

2.2 Comportement du PDV durant la phase d’ex\u00e9cution<\/h3>\n

Une fois la phase de compilation achev\u00e9e avec succ\u00e8s, l’\u00e9tape DATA bascule dans sa phase d’ex\u00e9cution. Le flux logique s’ouvre par l’initialisation des variables du PDV. Dans le cas d’une lecture via l’instruction SET<\/code>, les emplacements m\u00e9moires assign\u00e9s aux variables import\u00e9es sont aliment\u00e9s par la lecture s\u00e9quentielle du bloc de donn\u00e9es source situ\u00e9 sur le disque. Chaque appel \u00e0 SET<\/code> lit un enregistrement physique unique et en copie les valeurs dans les slots correspondants du PDV.<\/p>\n

Contrairement aux variables calcul\u00e9es localement (qui sont r\u00e9initialis\u00e9es \u00e0 la valeur manquante \u00e0 chaque d\u00e9but d’it\u00e9ration, sauf si elles font l’objet d’une instruction RETAIN<\/code>), les variables issues d’une instruction SET<\/code> b\u00e9n\u00e9ficient d’une persistance naturelle tout au long du cycle de vie de l’it\u00e9ration courante. Les calculs math\u00e9matiques, transformations textuelles ou r\u00e9assignations logiques s’op\u00e8rent alors directement sur les valeurs h\u00e9berg\u00e9es temporairement dans le PDV.<\/p>\n

L’aboutissement normal du cycle d’ex\u00e9cution survient lorsque le compilateur atteint l’instruction implicite ou explicite OUTPUT<\/code>. \u00c0 cet instant pr\u00e9cis, le gestionnaire d’\u00e9criture prend une photographie des donn\u00e9es contenues dans le PDV et les transf\u00e8re dans la m\u00e9moire tampon de sortie, en vue de leur s\u00e9rialisation d\u00e9finitive sur le support de stockage. D\u00e8s cette \u00e9criture consign\u00e9e, le PDV est r\u00e9initialis\u00e9 selon les r\u00e8gles de gestion de l’\u00e9tape DATA, pr\u00e9parant la structure m\u00e9moire pour l’it\u00e9ration subs\u00e9quente.<\/p>\n

2.3 Point d’intervention des instructions de sous-ensemble<\/h3>\n

La compr\u00e9hension du point d’intervention temporel des instructions de sous-ensemble au sein du cycle de vie du PDV est indispensable pour pr\u00e9venir toute erreur de logique architecturale. Les instructions KEEP<\/code> et DROP<\/code> n’agissent pas sur la pr\u00e9sence des variables \u00e0 l’int\u00e9rieur du PDV durant la phase de calcul ; elles fonctionnent comme des masques de filtrage appliqu\u00e9s au moment strict du d\u00e9versement du PDV vers la table cible finale.<\/p>\n

Ainsi, lorsqu’une instruction DROP points;<\/code> est formul\u00e9e, la variable points<\/code> est bel et bien allou\u00e9e dans le PDV lors de la compilation, et elle est lue depuis la table source durant l’ex\u00e9cution. Elle demeure totalement accessible pour effectuer des tests logiques ou des calculs d\u00e9riv\u00e9s au sein de l’\u00e9tape DATA. Ce n’est qu’au moment pr\u00e9cis de l’appel \u00e0 l’\u00e9criture (OUTPUT<\/code>) que le syst\u00e8me SAS consulte le dictionnaire des m\u00e9tadonn\u00e9es, constate la pr\u00e9sence de la directive d’\u00e9viction, et ignore physiquement la colonne lors de la cr\u00e9ation du fichier binaire de sortie.<\/p>\n

\u00c0 l’inverse, l’instruction DELETE<\/code> (notamment dans la s\u00e9quence IF condition THEN DELETE;<\/code>) intervient activement en amont de l’\u00e9criture. Lorsqu’elle est d\u00e9clench\u00e9e, elle interrompt imm\u00e9diatement le fil s\u00e9quentiel des instructions restantes pour l’it\u00e9ration en cours. L’instruction OUTPUT<\/code> implicite situ\u00e9e \u00e0 la fin de l’\u00e9tape DATA est tout simplement court-circuit\u00e9e. Le PDV est alors vid\u00e9 de ses valeurs transitoires, la ligne courante est d\u00e9finitivement rejet\u00e9e, et le syst\u00e8me incr\u00e9mente _N_<\/code> pour proc\u00e9der sans d\u00e9lai \u00e0 la lecture de l’enregistrement source suivant.<\/p>\n

3. Pr\u00e9sentation et initialisation du jeu de donn\u00e9es de r\u00e9f\u00e9rence<\/h2>\n

3.1 Structure syntaxique de l’\u00e9tape DATA d’initialisation<\/h3>\n

Afin d’illustrer rigoureusement les concepts d\u00e9velopp\u00e9s dans ce m\u00e9moire, nous instancions un environnement exp\u00e9rimental contr\u00f4l\u00e9 \u00e0 travers un jeu de donn\u00e9es sportif canonique. Ce jeu de donn\u00e9es synth\u00e9tise les performances offensives et d\u00e9fensives de plusieurs franchises de basket-ball professionnel nord-am\u00e9ricain. Sa cr\u00e9ation repose sur la combinaison conventionnelle d’une \u00e9tape DATA d’affectation et de l’instruction d’ingestion directe DATALINES<\/code>.<\/p>\n

La formulation syntaxique de ce bloc d’instanciation se structure selon le standard suivant :<\/p>\n

data original_data;
\ninput team $ points rebounds;
\ndatalines;
\nWarriors 28 12
\nWizards 18 9
\nRockets 22 10
\nCeltics 21 8
\nThunder 31 14
\nSpurs 27 11
\nNets 26 7
\n;
\nrun;<\/code><\/p>\n

Dans ce segment de code, l’instruction data original_data;<\/code> ordonne au compilateur d’allouer les structures descripteurs d’une nouvelle table enregistr\u00e9e dans la biblioth\u00e8que temporaire WORK<\/code>. L’instruction input<\/code> d\u00e9finit la grille de lecture du flux textuel brut : le modificateur alphanum\u00e9rique dollar ($<\/code>) informe le compilateur que l’attribut team<\/code> doit \u00eatre configur\u00e9 comme une cha\u00eene de caract\u00e8res de longueur standard, tandis que les variables points<\/code> et rebounds<\/code> re\u00e7oivent le type num\u00e9rique flottant par d\u00e9faut (double pr\u00e9cision, standard IEEE 754<\/a>).<\/p>\n

3.2 D\u00e9tail des variables et m\u00e9tadonn\u00e9es du mod\u00e8le<\/h3>\n

Le jeu de donn\u00e9es de r\u00e9f\u00e9rence original_data<\/code> est mod\u00e9lis\u00e9 selon une matrice rectangulaire de dimension sept par trois, totalisant ainsi sept observations ind\u00e9pendantes r\u00e9parties sur trois variables homog\u00e8nes. Chaque dimension repr\u00e9sente un axe d’\u00e9valuation quantitatif ou qualitatif univoque :<\/p>\n