Chantiers sociologiques et anthropologiques.
Actes du 58e colloque de l’ACSALF 1990.

“Datation des événements
dans un questionnaire et
gestion de la base de données.”

Par Jean RENAUD et Alain CARPENTIER

[232]
[233]

L’avantage de la datation des données

Depuis 1972 (et de façon beaucoup plus marquée depuis 1980) s’est développée une nouvelle classe de modèles d’analyse statistique connue en anglais sous le nom de « Event History Analysis » et qu’on pourrait nommer en français l’analyse du changement d’état ou l’étude des déterminants du changement, ou encore, l’analyse de biographies. Ce développement qui a sa source dans la solution de problèmes mathématiques d’estimation (1972) et de mise au point d’algorithmes informatiques efficaces (1979 et 1980) est en train de modifier les théories sociologiques elles-mêmes. Le centre d’intérêt passe de la connaissance des déterminants pour ainsi dire statiques d’un état (par exemple pourquoi certains travailleurs œuvrent dans un secteur industriel plutôt que dans un autre ?) à la connaissance des déterminants du mouvement menant à cet état (pourquoi certains travailleurs changent de secteur industriel et vont vers un secteur donné ?).

Se distinguant des modèles économiques traitant des séries temporelles qui portent sur des agrégats ou des collectivités plutôt que sur des individus, et inspirée de l’étude des tables de mortalité des démographes et des travaux des biostatisticiens, cette nouvelle forme d’analyse statistique est utilisée en sciences sociales par l’introduction de causes qui sont variables dans le temps (augmentation de salaire modifiant les chances de changer d’emploi) et du repérage d’événements multiples et répétables pris comme variables dépendantes (changements d’emploi). Dans le cas de la recherche sur l’établissement des nouveaux immigrants, cette méthode qui permet [234] l’étude d’interrelations dynamiques, s’avère utile puisque les itinéraires professionnels de d’emploi, l’apprentissage linguistique, la nature et l’étendue du ménage, et le choix du lieu de résidence fournissent des conditions pour une transformation des uns et des autres.

Formellement, la variable dépendante dans ce modèle est obtenue par la mesure du temps passé dans un « état ». À partir de cette information, il est possible d’estimer une table de « survie » ou de « séjour » représentant la probabilité d’un changement d’état pour chaque unité de temps, c’est-à-dire la probabilité qu’une transition ait lieu à un moment donné. Cette information, transposée au niveau des individus à l’étude, est reliée à des prédicteurs afin d’en expliquer la variation, puis sont identifiés (dans un contexte de régression dite de survie) les facteurs qui font fluctuer cette probabilité en introduisant des variables indépendantes qui sont, soit métriques, soit catégorielles modifiées en polydichotomies.

Nous allons traiter, dans ce texte, des problèmes de cueillette et de bases de données reliés au recours à des événements datés.

Comment obtenir des données datées

Les outils nécessaires à la cueillette et à la saisie de ce genre de données doivent être adaptés afin de supporter le rappel temporel des événements. Nous avons donc testé l’utilisation d’un calendrier aide-mémoire accompagné de deux questionnaires : l’un orienté sur le calendrier (consignes et questions), et un autre de type plus conventionnel.

Après avoir présenté ces supports à la cueillette, nous tenterons de cerner le degré de précision des datations ainsi obtenues. Puis, nous présenterons un aperçu des problèmes de gestion de base de données temporelles.

Le calendrier

La localisation temporelle d’événements, plus ou moins rapprochés de la date d’interview, fait appel, nécessairement, à la mémoire du répondant. Le type d’événement même peut faire qu’on se souvienne plus ou moins facilement de sa date d’avènement. Des événements [235] plus rares et/ou bouleversants comme une naissance, une mortalité, un déménagement ou un changement d’emploi risquent d’être plus facilement, et plus précisément datables que le dernier rendez-vous avec un médecin (à moins que ce rendez-vous n’est été l’objet d’un annonce de maladie incurable...). C’est donc en se basant sur ces événements plus marquants que le répondant peut tendre à se rappeler plus facilement d’autres événements « plus banals ».

Un calendrier où sont résumées différentes séquences d’événements permet la validation et la contre-validation des événements entre eux. Ce calendrier, un document séparé du questionnaire, est en fait une grille où sur un des axes on retrouve des dates, et sur l’autre, les événements en question. On y trace alors des lignes correspondant à la durée de chacun des événements. Le répondant peut donc, en se fiant à la date d’un déménagement par exemple, dater le début d’un cours suivi quelques semaines avant ou après ce déménagement. Le calendrier d’événements du répondant ainsi que celui du conjoint ou du responsable du ménage sont ainsi complétés.

Avant l’interview, l’axe des dates n’est qu’une série de nombre allant de 1 à 60 (pour les 60 premières semaines de l’arrivée au Québec). L’intervieweur doit donc, lors des premières minutes de la rencontre avec le répondant, ajuster et coller une règle des dates sur le calendrier. Le but est d’ajuster la date effective de la semaine d’arrivée au Québec du répondant avec la première semaine absolue du calendrier. Cette date ne peut que faire l’objet d’une très grande présence à la mémoire ; elle marque, pour les immigrants, le début d’une vie dans un nouveau pays.

Au moins deux hypothèses de calendrier sont possibles : l’un où on ne retrouve que les dates de début et de fin des différents événements, et l’autre où on y code une partie ou l’ensemble des qualificatifs de ces événements. Les deux hypothèses permettent cette aide à la mémoire. Cependant, la deuxième hypothèse comporte des difficultés supplémentaires de codage post-interview.

Si l’avantage principal de l’usage d’un calendrier est l’aide à la mémoire pour la datation, toutes autres informations portées sur celui-ci semblent, suite à notre expérience, n’avoir aucun avantage pour le répondant. Les informations, autres que les dates, inscrites [236] sur le calendrier, pour une question pratique d’espace d’abord, ne peuvent y être transcrites que sous forme abrégée ou codée. Le répondant n’y peut donc s’y référer et la saisie des données n’est pas simplifiée, au contraire. La solution semble donc être à mi-chemin entre un calendrier ne contenant que des dates et un calendrier contenant des dates et d’autres informations.

Certaines informations, autres que des dates, peuvent être inscrites dans un calendrier sans perdre les qualités du calendrier, et sans donner trop de cauchemars aux codeurs. Il s’agit, lorsque la nature de l’information le permet, de marquer les dates de début et de fin d’événement à l’aide de codes. Par exemple, pour un cours suivis, la date de début sera marquée par le code de la langue du cours (F pour français, A pour anglais et * pour autres), tandis que la date de fin est inscrite avec le code du type de fin de ce cours (1- en cours au moment de l’entrevue (troncature), 2- abandon, 3- fin normale). Ainsi, cinq indices sont inscrits sur une même ligne :

Ce type de codification prévoit, bien entendu, lorsque l’information est pertinente, qu’une colonne ou une ligne par type de cours a été prévue. Dans ce cas, la colonne ou la ligne dans laquelle se trouve l’information apporte l’indication du type de cours suivi.

Pour d’autre événements où l’information à obtenir est plus complexe, le calendrier ne contiendra que les dates de début et de fin, alors que les caractéristiques de ces événements seront saisis par un questionnaire de type conventionnel (questions et réponses sur questionnaire).

Les questionnaires

Comme nous l’avons déjà annoncé plus haut, deux questionnaires complémentaires ont été utilisés. Le premier regroupe les consignes se rapportant au calendrier ainsi que les questions propres aux différents événements saisis par celui-ci.

[237]

Le deuxième questionnaire (ou questionnaire no 2) est de type plus conventionnel. Il se veut surtout l’outil pour obtenir les informations non datables telles que, principalement, la situation avant la venue au Québec (pays de résidence, emplois, études) du répondant et du conjoint s’il existe, la situation économique au Québec, l’utilisation et la connaissance des langues et la scolarité des enfants (s’il y a lieu). Il contient aussi des informations dont on ne s’intéresse qu’à la datation de la première occurrence comme les dates de cohabitation avec le parrain d’immigration, le premier contact avec un médecin ou un spécialiste de la santé, le premier contact avec une association ethnique, l’ouverture du compte en banque, etc.

La précision temporelle des données

La connaissance de la précision avec laquelle les répondants ont daté leurs informations est vitale à l’analyse : cette précision impose d’elle même la périodicité que l’analyse pourra prendre en compte. Nous allons montrer que, pour les variables qui sont issues du questionnaire calendrier, cette précision est de l’ordre de la semaine alors qu’elle n’est que saisie au mois près dans la plupart des questions du questionnaire no 2.

Pour identifier la précision temporelle des réponses, il suffit de voir si l’unité de temps de fait utilisée est celle qui a été codée à partir des réponses ou si, au contraire, elle est d’un niveau inférieur. Dans le cas des événements où l’entrevue et la codification demandaient d’identifier la semaine, comme dans la partie calendrier, on pourra tester si chaque semaine du mois (le mois étant l’unité moins précise du temps) est utilisée avec la même fréquence dans le rapport d’un événement. Si tel est bien le cas, on pourra conclure que la précision est bien de l’ordre de la semaine. Dans le cas contraire, on conclura que le temps effectivement rapporté par les interviewés (ou effectivement noté par les intervieweurs) n’est précis qu’au mois près.

Plus spécifiquement, dans le cas des questions que nous avons posées en demandant une précision à la semaine depuis l’arrivée, nous regarderons si la première semaine du mois (i.e. celle contenant le premier du mois) est mentionnée de façon plus fréquente. Cette mention correspondrait à la réponse « en début de tel mois », voire « à [238] tel mois », réponses que l’intervieweur aurait noté à la semaine contenant le début du mois. Pour la vaste majorité des événements, il n’y a pas de raison de croire que cette semaine particulière ait une signification différente des autres et qu’elle doive apparaître plus souvent (ou moins souvent) que les autres. On s’attend donc que cette semaine ait une probabilité de 12/52 puisqu’elle apparait 12 fois par 52 semaines. Cette probabilité de 0,231 est la probabilité théorique (P) à laquelle sont comparés les probabilités observées (p) pour chaque événement (tableau 1).

On constate qu’à une exception près la première semaine du mois n’apparaît pas plus souvent que ce à quoi on s’attend si les réponses sont de fait fournies avec une précision de l’ordre de la semaine. En fait, la seule exception tend plutôt à confirmer cette précision : la scolarité des enfants étant liée à une horloge externe — celle de [239] l’école — (deuxième semaine de septembre 1988 et deuxième semaine de janvier 1989), cela expliquerait que seulement 8% des enfants aient été déclarés avoir débuté l’école la première semaine du mois.

Interviewés de façon rétrospective sur l’année écoulée avec l’aide d’un repère visuel que constitue leur calendrier d’établissement, les immigrants ont fourni sur les grands événements de leur vie au Québec des réponses avec une précision de l’ordre de la semaine.

Il n’en va pas ainsi d’événements disparates pour lesquels on demandait une date absolue. Ces événements que l’on retrouve au tableau 2 sont notés avec une précision temporelle de beaucoup inférieure. Dans ce cas, le test le plus simple que l’on puisse faire consiste à regarder la distribution des jours du mois qui sont fournis (ou notés par les intervieweurs ou codé par les codeurs, ces derniers ayant eu comme consigne de noter le jour 1 en l’absence d’information sur le jour au questionnaire). Alors qu’on s’attend que chaque jour du mois soit utilisé 3% (12/365) des fois, le jour 1 est de beaucoup au delà de ce seuil pour tous les événements ainsi saisis. Il est même très largement au-delà du seuil de 12/52 qu’on aurait observé si les réponses avaient été données à la semaine près.

Dans ce cas, que ce soit à cause de la nature de l’événement ou parce que le questionnaire ne forçait pas le recours au calendrier d’établissement pour dater l’information, celle-ci est beaucoup plus imprécise que la précédente : elle est, somme toute, notée au mois près.

[240]

La construction des données pour l’analyse

Chaque type d’événements saisi par le calendrier a sa propre occurrence : un répondant peut, sur la période couverte par l’enquête, avoir eu 3 logements, 2 emplois et n’avoir suivis aucun cours ; un autre aura eu 1 seul logement, 6 emplois et suivis 5 cours de différents types. On voit, plus loin dans ce texte que la solution la plus parcimonieuse, et la plus souple lors des analyses, est de constituer un fichier de données par type d’événement ou par type d’information. On aura, par exemple, un fichier d’emplois où chaque cas est un épisode d’emploi plutôt qu’un individu. On fera de même pour les logements, les cours suivis, etc. Un seul des fichiers, qu’on peut qualifier de « fiche mère », est un fichier des personnes de l’échantillon. Cependant que ce soit la « fiche mère » ou tout autres fichiers, le numéro d’identification du répondant doit apparaître comme clef universelle sur chacune des unités d’analyse des fichiers. On rencontrera, pour un fichier d’emplois par exemple, le numéro d’identification d’un individu autant de fois que celui-ci aura connu d’emploi pendant la période couverte. De même, si un individu n’a pas eu d’emploi, son numéro d’identification ne se retrouvera sur aucun des emplois du fichier.

Cette solution prime, à notre avis, sur celle de créer un fichier rectangulaire unique qui à toute fin pratique, serait en partie vide. Ce type de fichier nécessite en effet que l’espace pour le plus grand nombre d’épisode de chacun des événements soit réservé même pour ceux qui n’ont connu aucun événement. Cette matrice, en plus d’être creuse, ne permet pas d’une manière aussi simple le jeu de construction de données propres et adaptées à une analyse particulière, ce que permet la division un événement/un fichier.

En fait, cette méthode de constitution des données fait que chaque analyse exige une construction particulière de l’information. Les données ne peuvent être utilisées telles quelles (fichier par fichier) que de manière très limitée. Passons maintenant à la description des quatre types « purs » de jonctions de fichiers. Ces quatre types, seront les building blocks des jonctions réelles.

[241]

Comment créer un fichier pour une analyse particulière ?

Rendons clair au départ que les données doivent être préparées de façon spécifique pour chaque analyse. Le moment de l’occurrence de l’événement étudié comme variable dépendante impose le rejet de toute information qui lui est temporellement postérieure et la construction des informations antérieures. Le changement dans la définition de l’événement étudié entraînera alors la nécessité de reconstruire un nouveau fichier d’analyse.

On a d’une part des fichiers où chaque répondant n’apparaît qu’une fois et une seule. C’est le cas par exemple du fichier contenant les informations générales relatives aux répondants (date d’arrivée, âge, sexe, etc.). Comme ces fichiers contiennent un enregistrement et un seul pour chaque répondant, on les appellera fichiers rectangulaires complets ou fichiers de type l. Pour certaines analyses, ces fichiers seront considérés comme événementiels parce qu’ils contiennent la date de l’événement non répétable (p.e. date du premier contact avec le système bancaire canadien, avec le système de santé, avec une association ethnique).

On a, d’autre part, des fichiers où les « cas », les enregistrements (les records dirait SPSS) portent sur un événement donné et un répondant apparaît autant de fois au fichier qu’il a eu d’événements de ce type. Par exemple, un immigrant ayant eu trois emplois apparaît trois fois au fichier emploi alors que celui qui n’a connu qu’un emploi n’y apparaît qu’une fois et celui qui n’a pas travaillé durant la période d’observation n’y apparaît pas du tout. On appellera les fichiers de ce type des fichiers événementiels ou fichiers de type 2.

Pour fins d’analyse, il ne suffit pas de prendre « le » fichier et de le traiter comme dans une enquête normale puisque l’information sur un répondant est disséminée dans plusieurs fichiers et, dans les fichiers de type 2, sur plusieurs enregistrements. Le présent document tente de tracer les procédures les plus utiles pour le traitement de ces données.

[242]

I. Les grands types de traitement des fichiers

A. La conservation ou le cumul de l’information portant sur les événements du même genre qui se sont produits avant l’événement à l’étude : jonction de type A.

Pour étudier un événement répétable comme l’emploi, il est utile d’aller chercher de l’information sur les emplois précédemment tenus par un répondant donné pour mieux comprendre un emploi donné. Par exemple, on voudra savoir si le répondant a déjà travaillé en français au Québec, quelle est son expérience de travail totale depuis la migration, etc. afin de voir si ces éléments sont des prédicteurs de sa stabilité dans un emploi donné.

Ce type de jonction ne porte que sur un seul fichier de type 2 : on joint l’information concernant un (des) événement(s) précédent(s) d’un répondant à un événement de même nature mais subséquent pour le même répondant.

Le numéro d’identification du répondant est la clé de la jonction d’information. La date de l’événement sert à préparer l’ordre des enregistrements d’un même répondant.

B. Joindre deux fichiers parallèles, i.e. où il y a une correspondance un à un entre les enregistrements des deux fichiers : jonction de type B.

L’idée centrale ici est de créer un nouveau fichier contenant les variables des deux fichiers d’origine. Par exemple, si un fichier contient la date d’arrivée au Québec, la langue préférée pour l’entrevue et le sexe alors que l’autre contient l’âge et l’état civil, on peut vouloir créer un seul fichier contenant ces cinq variables afin d’étudier leurs relations.

Ce type de jonction porte sur deux fichiers qui non seulement sont de même longueur mais contiennent exactement les mêmes « cas ». Il peut tout aussi bien s’appliquer à des fichiers de type 1 qu’à des fichiers de type 2.

Dans le cas de fichiers de type 1, le numéro d’identification est la seule clé de correspondance entre les 2 fichiers à joindre. Dans le cas de fichiers de type 2 à joindre, la conjonction du numéro d’identification avec la date constitue la clé.

[243]

C. Joindre deux fichiers non parallèles, i.e. où il n’y a pas de correspondance un à un entre les enregistrements. Un fichier fournit les « cas », l’autre des variables. Jonction de type C.

L’exemple le plus clair de ceci sur des données événementielles est la jonction entre un fichier de type 2 contenant des événements répétables et un fichier de type 1. Les répondants apparaissent de zéro à n fois au premier fichier et ils apparaissent exactement une fois au second fichier. On voudra joindre à chaque événement du premier fichier des données issues du second décrivant la personne ayant connue ces événements.

Le résultat de cette jonction est un fichier rectangulaire : les données sur une personne donnée seront répétées autant de fois que cette personne a connue d’événements dans le fichier à l’étude.

Le numéro d’identification des répondants est la seule clé pour cette jonction.

D. Joindre deux fichiers événementiels. Jonction de type D.

La jonction entre deux fichiers événementiels présente une difficulté logique absente des types précédents : un événement ne peut servir d’explication à un autre que s’il lui est temporellement antérieur. Si cette difficulté est aisément solutionnées pour les jonctions de type A, il n’en va pas si simplement ici. On veut combiner deux types différents d’événements qui ont chacun leur périodicité propre.

Par exemple, si on veut joindre le fichier portant sur l’emploi à celui portant sur le non-emploi, il n’est évidemment pas question que les périodes de non-emplois qui suivent un emploi donné viennent expliquer celui-ci ! Au contraire, on ne voudra apparier à un emploi donné que les informations sur le(s) non-emploi(s) qui le précède (nt).

Cette jonction recourt à trois clés : le numéro d’identification du répondant, la date de l’événement de premier fichier et la date de l’événement du second fichier.

E. La combinatoire

Les quatre types de jonction décrits brièvement ci-dessus peuvent être combinés pour produire les informations qu’on désire réellement analyser. Ils sont des cas purs, des buildings blocks mais, en pratique, on devra recourir à des séquences d’opération de jonction.

[244]

Par exemple, on peut vouloir cumuler des informations sur l’ensemble des non-emplois qui précèdent un emploi afin de mieux expliquer celui-ci. Dans ce cas, on fera une jonction de type A avant de faire une jonction de type D.

Dans le cas d’analyse de type régression de survie, on devra prendre soin de ne pas évacuer de l’analyse (i.e. du groupe à risque) les personnes n’ayant pas vécu un événement. Pour tous les événements datés répétables, on devra, après avoir produit une jonction de type C (ou D) reliant ces événements aux variables de base (« stables ») rajouter les répondants n’ayant pas connu l’événement. Pour ceux-ci, outre les variables de base on prendra la date de l’entrevue pour obtenir la mesure de leur durée de séjour dans un état et on créera une variable de troncature indiquant le retrait de l’observation à cette date.

II. Procédures [1]

A. Les fichiers sources pour ces jonctions

La jonction de type A peut être faite à partir de fichiers de données en ASCII ou créés par un SAVE de SPSS.

Les jonctions de type B et C nécessitent des fichiers créés par un SAVE de SPSS.

La jonction de type D nécessite des fichiers de données en ASCII.

Le plus sécuritaire est de procéder avec les fichiers SAVE de SPSS le plus possible (type A, B, C) et d’écrire avec un WRITE à partir de ces fichiers pour les jonctions de type D. On évitera ainsi une multiplication indue des sources d’erreur.

B. Avant quelque traitement...

Toutes les procédures qui suivent présument que les fichiers ont été triés par le numéro du répondant (NO_ID) et, s’il s’agit d’un fichier événementiel (type 2), qu’ils ont été triés aussi (2^ème clé) sur la date de l’événement. Cette dernière exigence implique le recours à des transformations préalables afin de créer une seule variable [245] « date » commune à l’ensemble des répondants, que leurs réponses aient été fournies en « numéro de semaine » ou en « date calendrier ».

Pour les jonctions de fichier où la date entre en compte, la façon de mesurer importe peu : que ce soit des semaines depuis l’arrivée (questionnaire calendrier), la date calendrier, le nombre de secondes depuis l’entrée en vigueur du calendrier grégorien (14 octobre 1582), etc. n’importe pas. Ce qui est vital par ailleurs c’est

1. que la date soit notée de la même façon sur les fichiers qu’on veut joindre ;

2. que la date ne constitue qu’une seule variable numérique (i.e. la date 25/01/47 ne va pas parce qu’elle contient des caractères non numériques, les « / »).

C. La jonction de type A : procédures

On n’a qu’un seul fichier et on veut « passer » l’information d’un enregistrement à l’autre. La création des nouvelles variables (concernant le passé) va se faire avec les moyens usuellement utilisés avec SPSS pour créer des variables : COMPUTE, IF, DO IF, RECODE, etc. La seule différence tient à ce qu’on va prendre un moyen qui permet de ne pas effacer (initialiser) le contenu des variables lorsqu’on lit un nouveau cas. La procédure permettant cela est LEAVE. (cf. les manuels pour les détails).

Si, à titre d’exemple, on travaille sur le fichier des emplois (type 2) et qu’on a une variable (fran) qui contient 1 si l’emploi est en français et 2 autrement et qu’avec cela on veut créer une variable (dejafran) qui indique si le répondant a déjà travaillé (dans le passé au Québec) en français dans ses emplois précédents, on utilisera les instructions du tableau 3.

Tableau 3

DO IF (NO_ID NE LAG (NO_ID,1)) OR MISSING(LAG(NO_ID, 1)) /* si nouveau répondant

+ COMPUTE DEJAFRAN=0 /* initialiser à zéro

+ ELSE /* si même répondant que précédant

+ IF (LAG (FRAN. l) EQ 1)

+ COMPUTE DEJAFRAN=1 /* mettre à 1 si français déjà utilisé avant

END IF

LEAVE DEJAFRAN /* conserver la valeur accumulée de la variable pour le cas suivant

[246]

Si on veut calculer son expérience de travail acquise au Québec avant un emploi donné, on fera comme au tableau 4.

Tableau 4

DO IF (NO_ID NE LAG (NO_ID,1)) OR MISSING(LAG(NO_ID,1)) /* si nouveau répondant

+ OMPUTE EXPERIEN = 0 /* initialiser a zéro

+ ELSE /* si même répondant que précédant

+ COMPUTE EXPERIEN = EXPERIEN + (LAG (DATEFIN.l) — LAG (DATEDE- BU,1)) /* accumuler exp.

END IF

LEAVE EXPERIEN /* conserver la valeur accumulée de la variable pour le cas suivant

Les deux exemples montrent la nécessité de tester si on est en présence d’un nouveau répondant et de faire une déclaration LEAVE pour que la valeur de la variable créée soit conserver pour utilisation par l’enregistrement suivant. Le reste est affaire usuelle de création de variables.

Une dernière remarque. Les cas étant triés par NO_ID et par la date, les valeurs s’accumulent d’un événement à l’autre pour un répondant. Pour chaque événement, on a l’information la plus « à date » qui soit disponible.

D. La jonction de type B : procédures

Cette jonction se fait par un
MATCH FILES FILE= / FILE= /BY

de SPSS (ou JOIN de SPSS-PC). Il suffit que les fichiers soient triés dans le même ordre (la variable de tri sera déclarée après le / BY) et qu’ils contiennent exactement les mêmes cas. Le tableau 5 joint deux fichiers sur la base du NO_ID (sous l’hypothèse que les NO_ID sont uniques dans les fichiers, i.e. qu’on est en présence de fichiers de type 1).

Tableau 5

FILE HANDLE A /NAME=’ ... ’ /* fichier créé par un SAVE

FILE HANDLE B /NAME=’ ... ¹ /* fichier créé par un SAVE

MATCH FILES FILE=A / FILE=B / BY NO_ID /* joindre par le NO_ID

E. La jonction de type C : procédures

Cette jonction se fait par un

[247]

MATCH FILES FILE= / TABLE= / BY

de SPSS. On remarquera qu’un des fichiers à joindre, celui contenant les « cas » est identifié par le FILE= alors que l’autre fichier qui fournit des variables mais pas des cas est identifié par le TABLE=. Un même répondant peut apparaître plusieurs fois dans le fichier FILE= mais les identificateurs doivent être uniques dans le fichier référencé par TABLE. Encore une fois, les fichiers doivent avoir été triés au préalables sur la variable constituant la clé de jonction (usuellement le NO_ID).

Le tableau 6 illustre cette jonction.

Tableau 6

FILE HANDLE A /NAME=’ ... ’ /* fichier contenant les cas (probablement de type 2)

FILE HANDLE B /NAME=’ ... ’ /* fichier de type 1

MATCH FILES FILE=A / TABLE=B / BY NO_ID /* joindre par le NO_ID

F. La jonction de type D : procédures

Cette jonction est de beaucoup la plus complexe en ceci qu’elle ne peut être faite de façon automatique et simple. J’ai, pour contrer cette complexité, écrit un INPUT PROGRAM qui devrait satisfaire la plupart des besoins pour ce type de jonction. Ce petit programme SPSS-X est long ... mais l’usager n’a que peu de choses à y changer pour qu’il fonctionne à sa convenance. Pas de panique !

Décrivons d’abord les opérations qui sont effectuées.

Le programme lit d’abord un cas sur le fichier EVENT1 contenant les cas (i.e. le fichier qui sera créé portera sur ces individus-évènements). Ensuite, il examine si des événements correspondants à cet individu (NO_ID) existent sur le fichier EVENT2. Si oui, il jumelle les informations du fichier EVENT ! a l’enregistrement de même NO_ID du fichier EVENT2 et dont la date est soit simultanée soit antérieure (la plus proche disponible s’il y en a plusieurs) à l’événement mesuré par le fichier EVENT1 : on va ainsi chercher les informations les plus récentes qui sont susceptibles d’influer sur l’événement de EVENT1.

Pour réaliser cela, les deux fichiers doivent être en ASCII (i.e. avoir été produits par un WRITE de SPSS.). De plus, les deux premières informations doivent être, dans l’ordre, le NO_ID (l’identificateur [248] de l’individu) et la date de l’événement. Pour cette dernière information, il s’agit de la date qui est pertinente pour l’analyse envisagée : soit la date de début de l’épisode, soit la date de fin de l’épisode selon le cas. L’unité dans laquelle est mesurée la date importe peu mais doit être la même sur les deux fichiers à joindre. Les fichiers doivent avoir été triés selon le NO_ID (clé 1) et la date (clé 2).

L’INPUT PROGRAM que j’ai écrit devrait pouvoir être simplifié (pour l’usager) lorsque une version 3.0 ou meilleure de SPSS-X sera disponible à l’Université de Montréal. On pourra alors utiliser des MACROS pour faire des changements qui, pour l’heure, doivent être fait main.

Pour s’en servir

1. Prendre une copie informatique du programme (ne pas le transcrire « à la main » : cela créerait nécessairement des erreurs !)

2. Effectuer les modifications indiquées par des COMMENT *****.

Les changements portent sur

1. Les FILE HANDLE (i.e faire monter les bons fichiers !)

2. Le nombre et la liste de variables et le format de lecture de chaque fichier

3. les caractéristiques du fichier à produire (SAVE, WRITE,...)

ATTENTION

1. Sur EVENT1 : les deux premières variables doivent s'appeler NO_ID et DATE ; le nom des autres variables importe peu

2. Sur EVENT2 : les variables sont lues sous le nom de #T, puis transformées en LU, LUAVA, NONLU et finalement, ce qui doit être conservé est nommé ECRIT. Ces noms sont réservés ; ne pas les modifier. Ce qui importe pour lire le fichier EVENT2, c’est le nombre total de variables à y lire, le programme leur donne des noms. Les deux premières variables à être lues doivent être l’identificateur de l’individu et la date pertinente (début ou fin selon le cas) de l’événement.

[249]

Le programme est conçu pour trois variables au total pour chacun des fichiers (le numéro d’identification de l’individu, la date et une variable quelconque). Lorsque plus de trois variables sont utilisées, il suffit, là où indiqué, de changer le chiffre 3 par le chiffre correspondant au nombre de variables réellement utilisées.

3. Toujours vérifier les résultats obtenus en listant les deux fichiers originaux et le fichier produit. Vérifier avec soin les derniers cas (qui sont facilement affectés par la présence d’une ligne blanche à la fin de certains fichiers de données)

Pour éviter d’alourdir le texte, cette série de commandes SPSS décrivant l’INPUT PROGRAM est donnée en annexe.

[250]
[251]

Annexe : INPUT PROGRAM pour jonction de type D

(copier l’ensemble de ces lignes)

title jonction de deux fichiers d’évènements répétables

Comment les lignes qui doivent être modifiées pour faire une jonction entre deux fichiers sont PRÉCÉDÉES d’une ligne de ************** ces modifications portent sur la description des variables, leur format, leur nombre, le nom des fichiers

comment le fichier EVENT1 contient la var dépendante, i.e. fournit les cas le fichier EVENT2 fournit les infos « a date » pour le fichier 2 Ces fichiers doivent être déjà tries sur id du cas et date.

comment cette passe est conçue avec trois variables par fichier. On peut aisément modifier cela :

pour le fichier EVENT1, simplement lire plus de variables (NO_ID et DATE doivent cependant être présents avec ces noms) pour le fichier EVENT2

s’assurer que le premier élément lu est l’identificateur de cas (comme NO_ID) et que le deuxième élément contient la DATE de l’évènement puis modifier partout ou le chiffre « 3" apparait ci-dessous par le nombre de variables contenues (id et date incluses) dans le fichier EVENT2 enfin, modifier les formats de lecture

Comment NE PAS changer les noms EVENT1 et EVENT2

SEULEMENT CHANGER le nom entre guillemets (name=’abc.def...’)

ET la valeur de LRECL (longueur maximale d’une ligne de données)

comment ******************************************

file handle EVENTl/name=’$user.test.EVENTl’/lrecl=6

comment ******************************************

file handle EVENT2/name=’$user.test.EVENT2’/lrecl=7

INPUT PROGRAM

Comment NVAR1 contient le nombre de variables du fichier EVENT 1 NVAR2 contient le nombre de variables du fichier EVENT2

comment ******************************************

COMPUTE N VAR 1=3

comment ******************************************

[252]

COMPUTE NVAR2=3

LEAVE NVAR1, NVAR2

Comment finde2 vaut 1 lorsque le fichier 2 est a sa fin (EOF)

compute finde2=0

LEAVE finde2

Comment NONLU contient les valeurs par défaut pour les cas sans information pertinente sur le fichier 2 (ici, il est mis a -1)

LU contient les dernières valeurs lues sur le fichier2

LUAVA contient les avant-dernières (lu-avant) valeurs lues sur le fichier2

Comment INITIALISATION

comment ******************************************

mettre la valeur de NVAR2 dans la parenthèse

vector nonlu lu luava écrit #t (3)

compute findecas=l

loop #i=l to nvar2

+ compute nonlu(#i)=-l

+ compute luava(#i)=0

+ compute lu(#i)=0

end loop

comment ******************************************

LEAVE NONLU 1 TO NONLU3.LUAVA1 TO LUAVA3, LUI TO LU3

comment BOUCLE PRINCIPALE

LOOP

+ do if (findecas eq 1)

comment lecture d’un cas du fichier EVENT1

comment ******************************************

+ data list file=EVENTl /no_id,date,y (3f2.0)

[253]

+ compute findecas=0

comment ******************************************

+ LEAVE NO_ID to Y, FINDECAS

+ end if

comment on réglé pour commencer les cas ou le fichier EVENT2 est épuisé

do if (finde2 eq 1)

do if (no_id eq luaval)

do if (date ge luava2)

do if ((no_id eq lu1) and (date 1t lu2))

loop #i=l to nvar2

compute ecrit(#i)=luava(#i)

 end loop

compute findecas=l

end case

end if

end if

end if

do if (findecas ne 1)

do if ((no_id eq lu1) and (date ge lu2))

loop #i=1 to nvar2

compute ecrit(#i)=lu(#i)

end loop

compute findecas=l

end case

else

loop #i=l to nvar2

compute ecrit(#i)=nonlu(#i)

end loop

compute ecrit(1)=no_id

compute findecas=l

end case

end if

end if

else

comment on réglé maintenant lorsque le fichier 2 n’est pas à sa fin

+ DO IF (NO_ID EQ luAVAl)

+ do if (date ge luava2)

+ do if (no_id eq lu1)

[254]

+ do if (date 1t lu2)

+ loop #i=l to nvar2

+ compute ecrit(#i)=luava(#i)

+ end loop

+ compute findecas=l

+ end case

+ else

comment ******************************************

+ DATA LIST FILE=EVENT2 end=finde2/#tl TO #t3 (2f2.0,f3.0)

+ do if (finde2 ne 1)

+ loop #i= 1 to nvar2

+ compute luava(#i)=lu(#i)

+ compute lu(#i)=#t(#i)

+ end loop

+ end if

+ end if

+ else

+ loop#i=l to nvar2

+ compute ecrit(#i)=luava(#i)

+ end loop

+ compute findecas=l

+ end case

+ end if

+ else

+ loop #i=l to nvar2 + compute ecrit(#i)=nonlu(#i)

+ end loop

+ compute ecrit(l)=no_id

+ compute findecas=l

+ end case

+ end if

+ ELSE

+ do if (nojd ge lu1)

comment ******************************************

+ DATA LIST FILE=EVENT2 end=finde2/#tl TO #t3 (2f2.0,f3.0)

+ do if (finde2 ne 1)

+ loop #i= 1 to nvar2 + compute luava(#i)=lu(#i)

+ compute lu(#i)=#t(#i)

+ end loop

+ end if

+ else

+ loop #i=l to nvar2

+ compute ecrit(#i)=nonlu(#i)

[255]

+ end loop

+ compute ecrit(l)=no_id

+ compute findecas=l

+ end case

+ end if

+ END IF

end if

END LOOP

END INPUT PROGRAM

comment finir par un SAVE OUTFILE= ...

avec soit un KEEP

(garder no_id et autres var lues sur EVENT1 et Ecrit1 à Ecrit??) ou un DROP (nonlu1 to lu??, findecas, finde2)

comment on peut également terminer par un WRITE en ne gardant que les variables du KEEP ci-dessus

Illustration des jonctions de type a, b, c et d

Jonction de type A :

EXEMPLE : Création d’une variable DEJAFRAN qui indique si le répondant a déjà travaillé en français (fichier de type 2).

On fait... (avec SPSSX 2.2 ou mieux)

DO IF (NO_ID NE LAG(NO_ID,l)) OR

MISSING(LAG(NO_ID,1))

COMPUTE DEJAFRAN=0

.ELSE

IF (LAG(FRAN,1) EQ 1)

COMPUTE DEJAFRAN=1

END IF

LEAVE DEJAFRAN

On obtient...

Note : La variable sujette au LAG doit être numérique.

[257]

Jonction de type B :

EXEMPLE : Joindre deux fichiers parallèles, i.e. où il y a une correspondance un à un entre les enregistrements des deux fichiers (fichier de type 1)

On a...

On fait... (avec SPSSX 2.2 ou mieux)

FILE HANDLE FICHE 1 /NAME=’...’

FILE HANDLE FICHE2 /NAME=’...’

MATCH FILES FILE = FICHE1 / FILE = FICHE2 / BY NO_ID

On obtient...

Note : FICHE1 et FICHE2 doivent avoir été créés par un SAVE

[258]

Jonction de type C :

EXEMPLE : Joindre deux fichiers non parallèles, i.e. où il n’y a pas de correspondance un à un entre les enregistrements. Un fichier fournit les « cas » (fichier de type 2), l’autre des variables (fichier de type 1).

On a...

On fait... (avec SPSSX 2.2 ou mieux)

FILE HANDLE FICHEI /NAME=\... ’

FILE HANDLE FICHE2 /NAME=’.... ’

MATCH FILES FILE = FICHEI / TABLE = FICHE2 / BY NO_ID

 On obtient...

[259]

Jonction de type D :

EXEMPLE : Joindre deux fichiers événementiels : un fichier contenant la variable dépendante (le ou les emplois en français du répondant) et un fichier de variables indépendantes si celle-ci sont temporellement simultanées ou antérieures à la variable dépendante (l’emploi français du conjoint).

On a...

On fait... comme décrit à la fin du document... On obtient...

[260]