Développement d’un prototype exploratoire d’application ...

of 62/62
1 Québec, Qc 24, bd de la Victoire Canada G1K 7P4 67000 Strasbourg - France Mémoire de soutenance du Diplôme d’Ingénieur ENSAIS Développement d’un prototype exploratoire d’application SIG pour la détermination des besoins d’utilisateurs en santé environnementale PROJET GÉOIDE Virginie PUJOS Correcteurs : Spécialité TOPOGRAPHIE M. KOEHL Juin 1999 M. GRUSSENMEYER
  • date post

    04-Feb-2022
  • Category

    Documents

  • view

    1
  • download

    0

Embed Size (px)

Transcript of Développement d’un prototype exploratoire d’application ...

1
Québec, Qc 24, bd de la Victoire Canada G1K 7P4 67000 Strasbourg - France
Mémoire de soutenance du Diplôme d’Ingénieur ENSAIS
Développement d’un prototype exploratoire d’application SIG pour la détermination des besoins d’utilisateurs en
santé environnementale
PROJET GÉOIDE
Virginie PUJOS Correcteurs : Spécialité TOPOGRAPHIE M. KOEHL Juin 1999 M. GRUSSENMEYER
2
REMERCIEMENTS
Je tiens à remercier tout particulièrement mon maître de stage, le Dr Yvan Bédard qui a trouvé ce
sujet qui fait collaborer le Centre de Recherche en Géomatique (CRG) de l’Université Laval et le Centre de
Santé Public de Québec, me permettant ainsi d’être confrontée à un milieu que je ne connaissais pas du tout :
celui de la santé environnementale. Yvan Bédard m’a suivie et conseillée pendant toutes les étapes du projet.
Je n’oublierai pas de remercier aussi :
Pierre Gosselin qui a été un des initiateurs de ce projet et qui a bien voulu qu’une petite étudiante française
participe à sa réalisation.
Marie-France Gagnon et Germain Lebel du Centre de Santé Public qui m’ont fourni les données et qui ont
fait preuve de patience lors de ma multitude de questions.
Pierre Marchand, étudiant en doctorat, qui fort de son expérience dans ce sujet a su me conseiller de
manière très juste et toujours appropriée. Il a suivi de près toutes les étapes de mon projet et a passé un temps
considérable à m’expliquer tout ce que je ne comprenais pas.
Yves van Chestein, professeur en Géomatique, qui m’a très souvent dépanné lors de mes problèmes
informatiques et qui apporte sa bonne humeur au sein du CRG.
Suzie Larrivée, professionnelle de recherche, toujours prête à répondre aux questions d’ordre technique et
ce, avec le sourire.
Sylvain Vallières, étudiant en maîtrise qui m’a donné d’astucieux conseils concernant l’utilisation de
MapInfo.
Tristan Alzial, ESGT 98 et étudiant en maîtrise, pour tous les petits coups de pouces quotidiens qu’il m’a
apportés en informatique.
I. PRESENTATION DE L’ENVIRONNEMENT DE STAGE
1) Le Centre de Recherche en Géomatique de l’Université Laval page 7
2) L’équipe santé et environnement du Centre Hospitalier Universitaire de Québec page 7
3) Le projet ICEM-SE du réseau canadien de Centres d'excellence en géomatique GEOIDE page 8
II. MISE EN CONTEXTE
1) Problématique page 10
2) Objectifs page 10
c) Etapes de la méthode mise au point page 14
4) Découverte des logiciels et lectures préliminaires page 16
III. ANALYSE DES DONNEES DU PROJET
1) Le découpage territorial au Québec
a) Le découpage spatial administratif page 17
b) Le découpage spatial dans le monde de la santé page 17
2) Analyse des données du CSPQ page 18
3) Problème de la confrontation des données page 20
4) Visualisation sous Brain des éléments qui constitueront l’hypercube page 20
IV. TRAITEMENTS DES DONNEES DESCRIPTIVES DU PROTOTYPE
1) Le changement de méthode dû aux problèmes spatio-temporels Etapes à suivre page 26
2) Création de la table Access page 27
3) Création de l’hypercube avec Transformer
a) Définition d’un hypercube page 34
b) Création de l’hypercube page 35
4) Passage sous Powerplay
a) Quelques explications sur l’environnement de Powerplay page 40
b) Exploration de notre hypercube page 43
4
page 44
2) Les cartes thématiques page 48
3) Les principes de la semiologie graphique
a) En théorie page 50
b) Dans le cas présent page 53
CONCLUSION page 55
TABLE DES FIGURES
Figure 1. Positionnement du prototypage jetable par rapport au cycle de vie d’un SIRS page 11
Figure 2. Représentation du prototype exploratoire dans le système complet page 12
Figure 3. Structure multidimensionnelle pour représenter des évènements page 13
Figure 4. Structure multidimensionnelle à six dimensions page 14
Figure 5. La fonction « drill down » page 14
Figure 6. Étapes théoriques à suivre page 15
Figure 7. Carte des MRC et zoom sur les municipalités page 17
Figure 8. Carte des RSS et zoom sur les CLSC page 18
Figure 9. Exemple de tableau de données sur le cancer page19
Figure 10. Carte des MRC page 20
Figure 11. Carte des CLSC page20
Figure 12. The brain - présentation globale page 21
Figure 13. The brain – structuration des données page 22
Figure 14. The brain – activation d’un élément page 22
Figure 15. The brain – création d’un nouvel élément page 22
Figure 16. The brain – nomination du nouvel élément page 23
Figure 17. The brain – effacer un élément page 23
Figure 18. The brain – effacer un élément (suite) page 23
Figure 19. The brain – liens entre les différents objets page 24
Figure 20. The brain – Utilisation de la police d’Yvan Bédard page 25
Figure 21. Différence de digitalisation entre les CLSC et les municipalités page 27
Figure 22. Requête SQL d’union page 28
Figure 23. Requête de création de table page 29
Figure 24. Résumé des étapes de création de la table Access page 29
Figure 25. Requête SQL de calcul de superficie des municipalités page 32
Figure 26. Tableau résultat de la requête de calcul de la superficie page 33
Figure 27. Requête de joint des tables des municipalités et des adultes page 34
Figure 28. Environnement de Transformer page 35
Figure 29. Premier hypercube réalisé page 36
Figure 30. Structure de la dimension « Yvan » page 39
Figure 31. Environnement de Powerplay page 40
Figure 32. Barre multidimensionnelle de Powerplay page 40
Figure 33. Fenêtre Categories de Powerplay page 41
Figure 34. Visualisation du problème des totaux page 42
6
Figure 35. Structure de l’hypercube ADULTE (seconde itération) sous Powerplay page 45
Figure 36. Hypercubes des adultes (à gauche) et des enfants (à droite) page 46
Figure 37. Les variables visuelles page 50
Figure 38. Échelle de mesure des propriétés page 51
Figure 39. Recommandations sur l’utilisation des variables visuelles page 51
7
I. PRESENTATION DES ORGANISMES
1) Le Centre de Recherche en Géomatique de l’Université Laval
Le Centre de Recherche en Géomatique (CRG) de la Faculté de Foresterie et de Géomatique de l’Université
Laval à Québec a été créé en 1989 afin d'offrir un cadre de formation et de recherche pluridisciplinaire dans
le secteur de la géomatique. Il regroupe une centaine de spécialistes dans des disciplines de base en
géomatique (géodésie, législation foncière, photogrammétrie, systèmes d'information à référence spatiale,
cartographie numérique et télédétection), dans des disciplines complémentaires telles que l'informatique, les
systèmes d'information organisationnels et les sciences sociales ainsi que dans certains domaines
d'application de la géomatique (foresterie, agriculture, génie, climatologie et géologie). Tous œuvrent dans le
but d'améliorer les méthodes, techniques et outils d'acquisition et de gestion des données sur le territoire. Le
Centre est reconnu et financé par le Fonds pour la Formation de Chercheurs et l'Aide à la Recherche du
Québec ainsi que par le gouvernement canadien. C'est le seul du genre au Canada et l'Université Laval est
d'ailleurs la tête dirigeante du nouveau Réseau Canadien de Centres d'Excellence en Géomatique appelé
GEOIDE (GEOmatique pour des Interventions et des Décisions Eclairées).
Informations tirées du site Web du CRG.
Le CRG possède pour quatre millions de dollars canadiens soit environ seize millions de francs
d’équipement de pointe. Une multitude de logiciels sont à la disposition des chercheurs et des étudiants :
logiciels de SIG (Systèmes d’Information Géographique), d’OLAP (On-Line Analytical Processing, que l’on
peut traduire par processus d’analyse interactif), de télédétection, de COGO (calculs topographiques), de
GPS, de photogrammétrie, de cartographie, de gestion de base de données (SGBD) et de traitement de texte.
Tous les ordinateurs du CRG sont reliés par réseau sous l’environnement Windows NT.
Le Dr Yvan Bédard, membre du CRG et professeur de SIG a été mon maître de stage.
2) L’équipe santé et environnement du Centre Hospitalier Universitaire de Québec
Depuis plus de 25 ans, d’importantes sommes d’argent ont été consacrées à la santé publique et à
l’environnement au sein du Centre Hospitalier Universitaire de Québec (CHUQ). Plusieurs équipes de
professionnels et de chercheurs provenant de domaines aussi divers que l’anthropologie, la biologie,
l’épidémiologie, la foresterie, la géographie, la génétique, la médecine, la nutrition, la psychologie, les
sciences de l’environnement, la sociologie, la statistique et la toxicologie, travaillent au CHUQ. Ce groupe
d’environ 125 personnes répond aux demandes d’information du public et mène des recherches et
interventions avec des partenaires de divers milieux (ministères, universités, firmes privées,…). Ces équipes
détiennent des mandats officiels des gouvernements aux niveaux régional, provincial, national et
international. L’interdisciplinarité du groupe constitue un atout majeur qui lui permet d’évaluer de façon
8
exhaustive les effets positifs ou négatifs sur la santé des impacts environnementaux reliés aux projets de
développement ou aux politiques gouvernementales.
Informations tirées de la plaquette du CHUQ.
Le Dr Pierre Gosselin, Marie-France Gagnon et Germain Lebel ont été mes interlocuteurs privilégiés au sein
du CHUQ. Le Dr Gosselin était le responsable de mon stage pour le secteur de la santé.
3) Le projet ICEM-SE du réseau canadien de Centres d'excellence en géomatique GEOIDE
Une équipe multidisciplinaire formée de gens compétents dans les domaines de la santé environnementale,
de la géomatique et de l’informatique a été mise en place pour créer une interface cartographique pour
l'exploration multidimensionnelle des indicateurs de santé environnementale sur le Web. Le nom donné à ce
projet est ICEM-SE. Les objectifs de cette recherche sont de réduire et prévenir les risques pour la santé qui
sont d’origine environnementale. Ceci nécessite un accès simple et rapide à des données de bonne qualité,
lesquelles doivent être analysées de façon utile pour supporter les décisions et interventions. Pour atteindre
leurs objectifs de gestion, plusieurs organisations en santé publique désirent acquérir un logiciel SIG leur
permettant de géoréférencer leurs données. Il en résulte une capacité accrue d'analyse de ces observations,
que ce soit par la simple production de cartes thématiques pour mieux illustrer un phénomène, ou par
l'utilisation de fonctions d'analyse spatiale. Cependant, l’utilisation d'un SIG n'est qu'un premier pas. En
effet, il est fréquemment admis que les SIG sont limités dans les fonctions d'analyse multiéchelle (ex. analyse
locale vs régionale), de statistique spatiale et de gestion des données temporelles (historiques et prédictives),
car ils n'ont pas été conçus initialement pour de telles opérations. Cela implique beaucoup d’efforts pour les
manipulations et les temps de réponse sont importants pour chaque opération. De plus, les SIG demeurent
inaccessibles aux non-spécialistes parce qu’ils sont trop complexes à utiliser (ex. : requièrent SQL avec
opérateurs spatiaux). Il est aujourd'hui impossible pour un non-spécialiste des SIG d'analyser rapidement et
facilement les données de santé environnementale, surtout lorsqu'une telle analyse demande de comprendre
l'évolution d'un phénomène sur une période donnée et de comparer plusieurs thèmes à différents niveaux de
détail. Cette constatation est la problématique au cœur du présent projet.
Parallèlement au développement des outils SIG, le monde informatique a vu apparaître les marchés de
données ou Data Marts (sorte de Data Warehouses – entrepôts de données – simplifiés, présentant des
données fortement agrégées dans une structure multiniveau et multithème appelée multidimensionnelle), les
outils d'analyse statistique (ex. SPSS, SAS), les outils d'exploration de données (OLAP) et les outils de
forage automatique de données (Data Mining). Chacun de ces outils permet de résoudre, mais de façon
séparée et partielle, une partie des problèmes mentionnés ci-avant et ceci, seulement pour les données non
spatiales.
9
Dans le cadre du présent projet, il a été proposé de concentrer les efforts sur l'exploitation maximale des
marchés de données et des outils OLAP en conjonction avec les SIG. Ce projet, d'une durée de trois années,
permettra ainsi de faciliter la gestion temporelle et la gestion multiéchelle des données spatiales grâce à
l'approche base de données multidimensionnelle utilisée dans les Data Marts. Ce projet permettra également
d'exploiter ces données de façon très rapide et très simple grâce à une interface cartographique de type
SOLAP (Spatial OLAP). L’utilisation de ces logiciels permettra d’approcher la solution désirée, soit : avoir
un système d’information efficace pour la description et l'analyse des données complexes en santé
environnementale.
Finalement, considérant le désir de rendre ce genre d'outil disponible à plusieurs utilisateurs situés dans
différentes régions, et ceci à un coût acceptable, l'utilisation d'un Intranet comme support de développement
a été privilégiée.
Les résultats attendus de ce projet de recherche appliquée incluent la mise en place d'un prototype
fonctionnel de système de description et d'analyse des données complexes en santé environnementale, basé
sur le projet de Système d’Information à Référence Spatiale en santé environnementale (SIRS-SE) du Comité
de santé environnementale, ainsi que le développement de nouvelles connaissances grâce à l'expérimentation.
Informations tirées de la proposition de projet GEOID
10
II. MISE EN CONTEXTE
Pendant ma session d’automne 1998 à l’Université Laval, Yvan Bédard et Pierre Gosselin m’ont proposé de
travailler pendant la session d’hiver sur le sujet suivant : « développement d’un prototype exploratoire
d’application SIG pour la détermination des besoins d’utilisateurs en santé environnementale ». Ce sujet m’a
permis de mettre en pratique la notion de cycle de vie d’un SIG qui m’a été inculquée pendant le cours de
fondements des SIG donné en automne 1998 et de proposer un projet d’expérimentation des technologies des
SIG dans un domaine bien particulier, celui de la santé environnementale. Il s’agit donc de mettre à profit les
connaissances de géomatique afin de travailler dans un domaine complètement différent. La partie qui suit a
été réalisée à l’aide des notes du cours de maîtrise « Analyse et conception de SIRS » d’Yvan Bédard (1998).
1) Problématique
Dans le cadre du réseau GEOIDE, le CSPQ (Centre de Santé Publique de Québec) et le CRG ont décidé de
collaborer sur le développement d'une interface cartographique pour l'exploration simple et rapide des
données de santé environnementale sur le Web. Ce projet vient se greffer à un autre projet (SIRS-SE) visant
à mettre en place le système d'information exploité par cette interface cartographique.
L’analyse préliminaire réalisée en juillet 1998 par la Direction de la Santé Publique de Québec et la Régie
Régionale de la Santé et des Services Sociaux de Québec représente la phase d’évaluation d’opportunité. En
effet, cette étude porte sur la faisabilité d’un Système d’Information Géographique en santé
environnementale. Le résultat de cette étude est qu’il est devenu nécessaire de réaliser un SIG pour répondre
aux nouveaux besoins des utilisateurs. Ce système serait rentable, pas trop coûteux et bien accueilli par les
utilisateurs potentiels, ce qui représente des facteurs clés pour le succès de la mise en place d’un tel système.
La problématique à laquelle fait face la nouvelle équipe CSPQ-CRG est de définir plus précisément les
besoins du CSPQ ainsi que les possibilités de nouvelles offres technologiques proposées par le CRG. Ce type
de problème étant très fréquent avec les nouvelles technologies, particulièrement les technologies
exploratoires du type de celles financées par GEOIDE, il devient primordial d'utiliser l'approche
méthodologique la plus efficace dans une telle situation : le prototypage rapide.
2) Objectifs
En ce qui nous concernait, notre but était donc de prendre en compte les données à intégrer au prototype et de
réaliser celui-ci jusqu’au bout, sachant que le nombre d’itérations dépendrait du temps mis à notre
disposition, c’est-à-dire une session. Le prototype que nous avons réalisé n’est que la première étape du
projet de réalisation d’un SIRS-SE d’une durée de quatre ans.
11
Les outils à notre disposition pour créer ce prototype étaient un logiciel OLAP couplé avec des logiciels de
SIG. Les objectifs étaient clairs : après analyse des données de la santé, le prototype devait être réalisé en
deux points : d’abord permettre une navigation dans les données descriptives à l’aide du logiciel OLAP, puis
mettre aux points des cartes rendant compte des mêmes données mais cette fois sous forme graphique.
Un projet utilisant ces deux sortes de logiciels a déjà été réalisé au CRG sur des données forestières l’été
dernier par Cécile Rebout et Pierre Marchand. Ce couplage représente une solution très innovatrice, laquelle
nécessite cependant davantage de recherche et développement avant d'être répandue de façon importante
dans la communauté géomatique. C'est d'ailleurs ce à quoi se consacre l'équipe du Dr Bédard dans le cadre
d'un autre projet GEOIDE et c'est dans un tel contexte d'innovation technologique que le CSPQ s'est joint au
projet et que nous avons réalisé le présent projet. Il est important de signaler ici que GEOIDE a commencé
officiellement le 4 mars dernier et que notre projet se situe vraiment au tout début de la démarche.
3) Méthode utilisée
Afin d’atteindre nos objectifs (création d’un prototype OLAP et fabrication de cartes thématiques), nous
avons dû définir les termes de prototype et d’OLAP. Ensuite, nous avons défini la méthode.
a) Définition d’un prototype
Un projet d’expérimentation des technologies permet d’évaluer les risques et les possibilités d’une
technologie de l’information par rapport à un domaine d’application particulier. Alors qu’un SIRS est
directement implanté dans une organisation, le projet d’expérimentation est réalisé dans un environnement de
« laboratoire »; c’est ce qui représente la plus grosse différence entre ces deux systèmes. Il a pour but de
diminuer les risques associés à l’utilisation d’une nouvelle technologie de l’information, d’évaluer les
impacts de l’implantation d’un projet sur le plan technologique et d’évaluer les impacts de cette nouvelle
technologie dans l’organisation en confrontant le nouveau système aux capacités réduites avec les futurs
utilisateurs. Dans le cadre de notre projet, le Centre de Santé Publique a choisi d’expérimenter des
technologies éprouvées sur le marché mais non utilisées dans un domaine d’application précis au lieu de se
diriger vers des outils encore peu présents sur le marché. Étant donné l’état d’avancement du système
d’information du CSPQ, le choix de la technique d’exploration a été simple : le prototypage exploratoire.
Figure 1. Positionnement du prototypage jetable par rapport au cycle de vie d’un SIRS
12
Contrairement à d’autres projets d’expérimentation qui se réalisent plus tard dans le cycle de vie d’un SIRS
(prototype évolutif, projet pilote, …), le prototype exploratoire est réalisé dès les premières étapes de la mise
en place d’un SIRS (figure 1).
Le prototypage exploratoire est une activité complémentaire facultative par rapport aux activités de
développement de systèmes d’information, qui suscite les réactions des utilisateurs face à diverses
composantes d’un système dans un environnement de « laboratoire ». Un prototype rapide est un petit
système partiellement fonctionnel qui est développé itérativement en étroite collaboration entre les
utilisateurs et les développeurs. Il sert à préciser les demandes et les offres avec la présentation, à chaque
itération, d'une ébauche d'un sous-ensemble du système final. Chaque itération permet de converger vers une
meilleure compréhension utilisateur-développeur, et ainsi de déterminer plus précisément les besoins avant
de procéder au développement du système global et final; conséquemment, il n'y a aucune obligation pour
l'utilisateur d'implanter le système sur la technologie SIG choisie puisque, par définition, un prototype rapide
est "jetable" (il n'aura servi qu'à mieux connaître les besoins et les offres et, en ce sens, aura servi à la
formation mutuelle des intervenants). Une telle stratégie permet d'identifier les différences de perception
entre l'utilisateur et le développeur tôt dans le processus de mise en œuvre d'un système, et d'y remédier
rapidement (épargnant ainsi des sommes importantes si l’on compare avec le fait de remédier au tout lorsque
l'on est très avancé dans le développement du système). Le prototype jetable sert à favoriser l’apprentissage
et la formation des utilisateurs par un contact direct avec ces nouvelles technologies, leur permettant ainsi
d’en cerner les capacités et les limites, ainsi que de vérifier la faisabilité et la performance de certaines
solutions fonctionnelles ou techniques, le but n’étant pas de réaliser le système entièrement mais de montrer
ce qu’il est possible de faire avec les nouvelles technologies.
Figure 2. Représentation du prototype exploratoire dans le système complet (cf. Bédard, 1998)
13
b) Définition d’un OLAP
L’OLAP (On-Line Analytical Processing) est un terme qui est apparu ces dernières années et qui renvoie à
un contexte de marketing plutôt qu’à un contexte technique. Il serait possible de le définir comme un
traitement de l’information orienté sur la décision et basé sur l’analyse. Les données brutes sont prétraitées et
préparées pour l’analyse, ce qui implique un nettoyage des données très tôt dans le processus. Avec cette
technique, l’accès aux données et les calculs sont rapides et précis. Le système a besoin d’assurer que les
vues sont facilement organisées et que les interfaces sont conviviales et intuitives. Généralement, les données
traitées sont en très grand nombre (pouvant atteindre des centaines de gigaoctets), les niveaux de détails sont
multiples, et il y a plusieurs facteurs d’analyse. Le nombre d’utilisateurs et de sites peut atteindre quelques
milliers. Ces utilisateurs ne vont pas suivre des procédures prédéfinies, mais choisir de façon autonome les
données à analyser. Ceci impose au système d’avoir une grande flexibilité.
L’hypercube et la représentation des dimensions
La notion d’hypercube (qui comporte généralement plus de trois dimensions) est fondamentale pour une
bonne compréhension d’un logiciel multidimensionnel. Comme un tableur utilise des feuilles de calculs ou
une base de données utilise des tables, l’OLAP se sert d’un hypercube. Il ne faut pas imaginer un cube
traditionnel car dès que l’on dépasse trois dimensions, la représentation devient très compliquée. Pour définir
une structure multidimensionnelle, il faut s’imaginer que chaque dimension est représentée par un segment
vertical. Il existe donc autant de segments verticaux que de dimensions. Chaque sous-catégorie d’une
dimension est représentée par un intervalle du segment. La figure 3 montre un exemple d’hypercube
tridimensionnel représenté à la manière d’un OLAP à gauche, et sous forme d’un cube classique à droite.
Dans cet exemple, les trois dimensions sont le temps, les produits et les variables.
Figure 3. Structure multidimensionnelle pour représenter des évènements (cf Thomsen, 1997)
Si l’étude porte sur plus de dimensions, il suffit de rajouter des segments verticaux comme sur la figure 4
afin de compléter l’hypercube. Dans ce cas-là, trois autres dimensions ont été rajoutées : les magasins, le
type de clients et le scénario.
14
Figure 4. Structure multidimensionnelle à six dimensions (cf. Thomsen, 1997)
La navigation dans les données va consister par la suite à choisir les dimensions souhaitées ou un sous-
ensemble de celles-ci. Il n’est pas obligatoire de travailler avec toutes les dimensions en même temps.
Le terme de « drill down » ou « forage » est un processus de navigation qui permet de descendre à un niveau
plus détaillé. Comme le montre la figure 5, en effectuant un drill down sur une catégorie, les résultats qui
s’affichent réfèrent à une sous-catégorie. L’opération inverse s’appelle le « drill up ».
Figure 5. La fonction « drill down » (cf. Thomsen, 1997)
15
c) Étapes de la méthode mise au point
Au départ, pour créer notre hypercube, nous devions suivre le processus de la figure 6.
Figure 6. Étapes théoriques à suivre
Ces étapes ont été définies par Pierre Marchand qui s’est aidé de son expérience de la Forêt Montmorency
pour nous conseiller. Cependant, à cause de plusieurs problèmes techniques, il nous a été impossible de les
suivre exactement. Nous expliquerons les difficultés rencontrées et les changements qui sont survenus dans
la méthode dans la partie IV.1).
En ce qui concerne les cartes à réaliser, le logiciel à utiliser était au choix parmi ceux du CRG (MapInfo,
GeoMedia, ArcView et MGE). Aucune contrainte n’a été imposée, car même si le CSPQ ne possède
actuellement que MapInfo, il faudra sûrement qu’il s’équipe avec un logiciel plus puissant dans l’avenir.
4) Découverte des logiciels et lectures préliminaires
Comme c’est souvent le cas dans les organisations, un certain temps fut nécessaire pour obtenir les données
du CSPQ. Ce temps a été mis à profit pour découvrir les différents logiciels nécessaires à la réalisation de ce
projet.
En ce qui concerne MapInfo (version 4.5.2), en peu de temps, nous nous sommes remémoré toutes les
fonctions que nous avions utilisées pendant le cours de fondements des SIG en automne dernier. En
16
revanche, nous avons dû découvrir entièrement le logiciel Powerplay et son module Transformer. Le but était
de comprendre la structure des fichiers utilisés et la manière de fabriquer un hypercube. Ces étapes seront
décrites ultérieurement dans le mémoire.
De plus, pour nous familiariser avec le sujet, nous avons lu le mémoire de Cécile Rebout qui traite de la mise
en place d’un OLAP jumelé avec le logiciel GeoMedia Pro, c’est-à-dire d’un SOLAP et l’analyse
préliminaire réalisée par la Direction de la Santé Publique de Québec et la Régie Régionale de la Santé et des
services Sociaux de Québec. En effet, cette dernière explique bien le choix des logiciels et la provenance des
données.
17
III. ANALYSE DES DONNÉES 1) Le découpage territorial au Québec
a) Le découpage spatial administratif
Le territoire est composé de 17 Régions Administratives ou RA. Chaque RA est composée de Municipalités
Régionales de Comté ou MRC exceptions faites des Communautés Urbaines de Québec et de Montréal et de
l’Outaouais. Les MRC sont elles-mêmes constituées de municipalités. Il y a environ 1500 municipalités au
Québec. Ce nombre est en constante variation car plusieurs fusions ont été réalisées ces dernières années.
Figure 7. Carte des MRC et zoom sur les municipalités
b) Le découpage spatial dans le monde de la santé
La province de Québec est divisée en 18 Régions SocioSanitaires ou RSS. Chaque RSS est divisée en
plusieurs Centres Locaux de Services Communautaires ou CLSC. En général, chaque CLSC possède un
établissement où sont recueillies les données mais un établissement peut parfois couvrir deux CLSC ou, en
zone urbaine, un CLSC peut voir un établissement principal et des établissements secondaires appelés points
de service. Au moment du projet, il y avait 170 CLSC dans toute la province mais seuls 156 étaient à l’étude.
18
Figure 8. Carte des RSS et zoom sur les CLSC
2) Analyse des données du CSPQ
Les données mises à notre disposition par le CSPQ étaient celles qui avaient permis récemment de compléter
un atlas du cancer sur le territoire de la province de Québec. Celles-ci possédaient le format de MapInfo
(*.tab, *.dat, *.map, *.id), logiciel de SIG utilisé actuellement par le CSPQ.
Les fichiers *.tab décrivent la structure de la table, les *.dat contiennent les données tabulaires, les *.map
contiennent tous les objets graphiques, alors que les fichiers *.id assurent le lien entre les données
descriptives et les objets graphiques. Nous avions aussi des *.dbf qui contenaient des données tabulaires et
qui avaient été générés automatiquement par un logiciel du CSPQ.
Il est reconnu que l’analyse des données est une étape indispensable au développement d’un bon prototype.
Des données qui sont mal analysées peuvent entraîner une perte de temps considérable lors des étapes
suivantes. Il vaut donc mieux passer un peu plus de temps à « éplucher » les données et ne pas omettre d’en
traiter une partie.
Les données du CSPQ peuvent se diviser en trois grands groupes.
Une première partie des données portait sur les divisions administratives en santé environnementale et
référait donc à des objets graphiques.
19
Une seconde partie était une série de « workspaces » (*.wor). On peut définir un workspace comme un
espace de travail. Quand on sauve un workspace sous MapInfo, on fige le travail effectué. Le grand défaut de
MapInfo est qu’il est impossible de sauvegarder des cartes thématiques sous un nom particulier. Marie-
France Gagnon et Germain Lebel ont donc sauvé chaque carte thématique sous un workspace différent afin
de ne pas avoir à refaire le même travail indéfiniment. Ces cartes nous montrent ce que recherche le CSPQ
comme document final. Cependant, les fichiers *.wor ne nous seront d’aucune utilité pour la suite du projet.
Une troisième partie concerne les données du cancer. Ce sont des fichiers MapInfo eux aussi mais ils ne
sont reliés à aucun objet graphique. Ils contiennent tous à peu près les mêmes informations. Une liste
complète de toutes les abréviations utilisées dans ces tableaux est disponible en annexe 1. Les données ont
été divisées en trois catégories : celles qui concernent les enfants, celles qui se rapportent aux femmes et
celles relatives aux hommes. Chaque cancer correspond à un tableau différent.
L’analyse d’un de ces tableaux (figure 9) permettra une meilleure compréhension de ce qu’il contient.
Figure 9. Exemple de tableau de données sur le cancer
Dans la colonne clsc_e se trouvent les numéros qui identifient les différents CLSC. Par exemple, 02101
correspond au CLSC « Fjord » qui se situe dans la RSS Saguenay-Lac-Saint-Jean. La colonne Topo_e
renvoie à un certain type de cancer. Ici, le numéro 157 correspond au cancer du pancréas. N_fem indique le
nombre de femmes touchées par la maladie. Tx_fem correspond au taux de cancer. Rts_157 donne le rapport
de taux standardisé du cancer du pancréas. P_fem renvoie à la valeur statistique qui va conclure sur le fait
que cette valeur est significative ou non. Ici, nous regardons un tableau où toutes les données sont
significatives car il commence par 01. Un autre tableau rassemblant des données sur le cancer du pancréas
chez les femmes portera le nom de If 99157 car il portera sur des données non significatives. Cette distinction
a été effectuée par le CSPQ pour faciliter la réalisation des cartes thématiques. C_v_fem correspond au
coefficient de variation.
Tous ces chiffres peuvent paraître difficiles à comprendre pour une personne qui ne fait pas partie du
domaine de la santé environnementale, mais il n’était pas indispensable d’en connaître la signification
exacte : il suffisait de savoir quelles données étaient les plus importantes à intégrer dans le système pour les
futurs utilisateurs. Par soucis de précision, nous préférons indiquer que l’annexe 2 présente les modus
operandi pour ces paramètres.
3) Problème de la confrontation des données
Pour créer un prototype, il est nécessaire de confronter un bon nombre de données. Il aurait été possible bien
sûr de ne garder que les données du CSPQ mais l’envergure du projet est différente. Il s’agit de prouver que
l’on peut intégrer des données provenant de découpages spatiaux hétérogènes comme les limites
administratives, les bassins versants,… Compte tenu de l’espace-temps, nous avons dû abandonner le fait
d’intégrer dans notre prototype les bassins versants car le temps d’obtention des données était trop long.
Cependant, ils seront certainement incorporés dans le SIRS final car ils représentent un bon moyen de
confronter des données de la santé avec d’autres de l’environnement. C’est souvent dans un même bassin
versant que vont se regrouper des facteurs de pollution identiques, les mêmes facteurs météorologiques. Il est
donc vraiment dommage que nous n’ayons pas pu concrétiser cette proposition. Par contre, l’idée
d’introduire des données de découpages administratifs a été retenue.
Les limites des RA sont très semblables à celles des RSS, elles diffèrent surtout dans le Grand Nord. Les
MRC et les CLSC se ressemblent aussi la plupart du temps mais, parfois, une municipalité fera partie d’une
MRC et pas d’un CLSC.
Figure 10. Carte des MRC Figure 11. Carte des CLSC
En regardant de plus près les figures 10 et 11, il est possible de voir quelques différences entre les
limites, surtout dans le Grand Nord.
4) Visualisation sous Brain des éléments qui constitueront l’hypercube
Pour créer le prototype, il est nécessaire de créer un hypercube avec le module Transformer du
logiciel Powerplay de la firme Cognos. C’est une étape qu’il ne faut pas négliger. C’est là qu’est
décidée la forme finale de la structure d’analyse qui pourra être réalisée sous Powerplay. Il ne
21
s’agit pas dans ce paragraphe de décrire les étapes réalisées ultérieurement avec Transformer
mais de comprendre que pour construire le cube, il est nécessaire de réfléchir aux besoins des
futurs utilisateurs, et aussi à ce que la technologie utilisée pourrait leur apporter sans qu’ils en
soient conscients.
La recherche de la structure du futur hypercube a été grandement facilitée par l’utilisation d’un
nouveau genre de logiciel interactif : « The Brain ». En effet, ce dernier peut être défini comme
un réseau sémantique, c’est-à-dire un outil permettent de gérer différents niveaux d’abstraction.
Par son biais, la création de la structure est facile et la visualisation rapide et agréable. L’arbre
représentant la hiérarchie est à la base du processus de création d’un OLAP. Il aurait été possible
de réaliser un arbre traditionnel type explorer mais la modification d’éléments est extrêmement
plus pratique avec Brain, ce logiciel est plus intuitif, plus rapide par rapport à un graphique à plat.
Il pourrait être utilisé comme outil de navigation.
Nous avons donc réalisé à l’aide de ce logiciel l’inventaire de l’existant (toutes les données mises
à notre disposition), et une autre partie représente ce qu’il restait à faire.
Les copies d’écran ci-dessous montrent sommairement le fonctionnement du logiciel.
Figure 12. The brain - présentation globale
Au centre de la figure 12, on peut voir le nom du projet, Multid perspec en éco enviro, qui a été
divisé en deux sous-ensembles : inventaires et olap. Tout ceci se trouve dans un environnement
Windows. Chaque petit rond vert situé sous un sous-ensemble signifie que ce dernier est lui-
même divisé. Tous les noms que l’on retrouve dans la bande située au bas de l’écran bleu sont
22
eux-mêmes des sous divisions et permettent de faire des liens entre sous-ensembles. La fenêtre
blanche située au bas de l’écran permet de rajouter des commentaires si besoin est.
L’écran ci-dessous (figure 13) est obtenu après « forage ». On voit que les parents sont toujours
placés au-dessus des enfants. Dans cet exemple-ci, on peut voir les noms des catégories que l’on
veut pouvoir analyser dans Powerplay : c’est le résultat de l’analyse des données existantes.
Figure 13. The brain – structuration des données
L’utilisation de ce logiciel est très facile. Pour passer d’un sous-ensemble à un autre, il suffit de
cliquer sur l’objet, qui deviendra le centre de l’écran suivant (figure 14).
Figure 14. The brain – activation d’un élément
Pour créer un nouveau sous-ensemble, il suffit de cliquer sur le point rouge et de déplacer la
souris (figure 15).
23
A ce moment là, une fenêtre apparaît et on peut inscrire le nom du sous-ensemble (figure 16).
Figure 16. The brain – nomination du nouvel élément
En revanche, si une erreur a été faite et qu’il est nécessaire d’effacer le sous-ensemble créé, il
suffit de pointer sur le lien qui existe entre le père et le fils; ce lien devient rouge (figure 17).
Figure 17. The brain – effacer un élément
Un simple clic permet l’affichage d’une fenêtre qui demande si l’utilisateur veut vraiment faire
disparaître ce lien (figure 18).
Figure 18. The brain – effacer un élément (suite)
24
Il est aussi possible de voir si une donnée est commune à plusieurs sous-ensembles. Quand la
donnée est rendue active, on peut regarder tous les liens qui s’opèrent avec les différentes tables
(figure 19).
Figure 19. The brain – liens entre les différents objets
Ceci constitue le principal avantage de l’utilisation d’un tel logiciel dans un OLAP. En effet, on
peut ainsi se rendre compte de la redondance de données. Le processus d’écriture de ce réseau
met en évidence des concepts ou problématiques qui ne sont pas toujours accessibles dans une
approche traditionnelle.
Ce logiciel nous a apporté un gain de temps précieux car il est possible tout de suite de montrer
des propositions à un interlocuteur (futurs utilisateurs par exemple) et les rajouts ou suppressions
d’analyses sont simples à faire en temps réel; la dynamique de développement n’est donc pas
freinée. The Brain permet de faire le lien entre un niveau de l’arbre et les données qui y sont
rattachées, il facilite la gestion d’une augmentation de volume de données et d’une implantation
complexe.
Quand le projet sur la forêt Montmorency a été réalisé, le CRG ne possédait pas encore ce logiciel
et de ce fait, cette phase a été beaucoup plus longue.
De plus, nous aimerions ajouter que quand nous avons réalisé l’inventaire de tous les fichiers dont
nous disposions, nous avons inséré un pictogramme qui permet rapidement de s’apercevoir si la
25
carte rattachée au fichier représente des éléments de types polygonal (-) ou ponctuel (!) , ceci
également afin de gagner du temps en analyse (figure 20). Cette police a été créée par Yvan
Bédard avec pour objectif de s'en servir dans les outils AGL (Ateliers de Génie Logiciel) utilisés
pour la conception des SIRS et se trouve en totalité en annexe 3 (en plus d'être téléchargeable
depuis le site web http://sirs.scg.ulaval.ca/yvanbedard).
Figure 20. The brain – Utilisation de la police d’Yvan Bédard
26
IV. TRAITEMENT DES DONNEES 1) Le changement de méthode dû aux problèmes spatio-temporels
Comme nous l’avons déjà indiqué dans la partie II.3), la méthode que nous devions utiliser n’a
pas pu être complètement mise en place.
En fait, les données primaires du CSPQ se trouvaient dans une projection quelconque, et notre
premier objectif était de les ramener dans une projection Lambert bien spécifique car c’est celle
qui correspondait le mieux à la taille du territoire. Cette projection n’étant pas disponible dans la
version 4 de MapInfo, il fallait donc passer sous GeoMedia.
On voit bien ici la facilité de passage entre les différents logiciels pour pouvoir réaliser toutes les
opérations que l’on désire. Ceci ne serait pas possible dans une entreprise qui n’achète
généralement qu’une sorte de logiciel. Nous avons, dans le cas présent, profité de l’équipement
du CRG.
La version actuelle de MapInfo que possède le CRG (4.5.2) ne permet pas de sauver les données
en format GeoMedia. Il faut donc passer par un format intermédiaire : le format d’Arcview (.shp).
C’est sous GeoMedia que se sont présentés les problèmes. La carte parraissait correcte mais les
coordonnées fournies par le logiciel ne correspondaient à aucun système choisi ou même connu.
Aucun membre du CRG ayant déjà travaillé sous GeoMedia ne trouva d’où provenait le
problème. Après avoir essayé différentes choses pendant deux semaines, nous nous sommes
résolus à demander conseil par courrier électronique au responsable d’Intergraph. N’ayant obtenu
aucune réponse, nous avons décidé de mettre les données dans le système « latitude/longitude »
qui existe sous Mapinfo et de les garder telles quelles. Nous les avons fait apparaître dans le
même plan que les données des MRC et des municipalités que le CRG possédaient. Là, nous nous
sommes aperçus, Pierre Marchand et moi que nous ne pourrions pas nous servir de la fonction
OVERLAY d’Arcinfo car la digitalisation était trop différente entre les municipalités et les CLSC
et qu’il n’y avait donc pas équivalence des limites.
La fonction OVERLAY permet de mettre tous les éléments sur une même couche (ou niveau) et
engendre de la même façon une table unique pour cette couche : on parle d’héritage spatial. Cette
table nous est indispensable pour créer l’hypercube sous Transformer (module du logiciel OLAP
Powerplay). Cependant, quand il y a des différences de cet ordre (figure 21) :
27
Figure 21. Différence de digitalisation entre les CLSC et les municipalités
la pointe qui provient sûrement d’une erreur de digitalisation va engendrer un nouveau polygone
triangulaire qui contiendra des informations, alors que dans notre projet il ne représente rien. Ceci
découle aussi du fait que les données proviennent de sources différentes et ne datent certainement
pas de la même année. Ces problèmes spatio-temporels nous ont donc forcés à changer de
méthode. Il a été décidé de créer la table sous Access de manière manuelle : l’héritage spatial a
été généré à la main.
2) Création de la table Access
Nous pensions au début pouvoir réaliser cette table sous Excel, mais nous nous sommes vite
rendu compte que cela était impossible. En effet, pendant un jour et demi, nous avons voulu
réaliser notre table en faisant des copier/coller des données du CSPQ pour les rajouter dans une
table qui contenait les découpages administratifs, et ce en traitant tous les cancers un à un et en
les associant avec chaque région concernée.
Nous avons été confrontés à un premier problème : notre découpage était administratif, c’est-à-
dire qu’il suivait la hiérarchie municipalité-MRC-RA alors que nos données faisaient référence à
des CLSC, donc au découpage de la santé. Nous avons donc contacté Marie–France Gagnon qui
nous a fourni quelques temps plus tard une table *.xls de ces concordances de découpages
spatiaux. Cependant, cette table ne tenait pas compte des fusions de municipalités qui se sont
opérées depuis 1990. Étant donné qu’il était quand même plus simple d’utiliser cette table que de
refaire tout le travail manuellement en regardant des fichiers MapInfo et en pointant chaque
municipalité (il y en a plus de 1500!) pour lui faire correspondre le bon CLSC, nous avons décidé
de nous servir de cette table.
En reportant les données sur le cancer, nous nous sommes vite rendu compte que cette méthode
était bien trop longue. Nous avons donc demandé conseil à Suzie qui nous recommanda de passer
sous Access. Nous ne nous étions jamais servis du logiciel Access pendant toute notre scolarité et
CLSC 1 Mun 1
CLSC 2 Mun 2
28
nous ne savions pas quelles étaient les possibilités d’un SGBD. Yvan Bédard nous proposa de
réaliser un TP qu’il donne à ses étudiants et qui explique ce que l’on peut faire pour rentrer les
données et les gérer par la suite. Nous avons joint ce TP en annexe 4.
Étant un peu plus au courant des capacités du logiciel, nous avons commencé à travailler avec
celui-ci.
La première étape fut de rassembler toutes les données du cancer dans une même table.
Nous avons donc importé dans Access tous les fichiers *.dbf donnés par le CSPQ et nous nous
sommes rendus compte qu’il y avait plus de fichiers que dans l’extension *.tab. Ceci provenait du
fait que le CSPQ n’avait pas réalisé des cartes sur tous les types de cancers et n’avait donc pas eu
besoin de *.tab pour tous les fichiers. Certains fichiers comme celui du cancer de la prostate chez
la femme étaient générés automatiquement par le programme SAS du CSPQ. Il a donc fallu
d’abord faire un tri dans les fichiers.
Ensuite, il a fallu regarder la structure de tous les fichiers qui, hélas pour nous, différait. Pour les
tableaux des hommes et des femmes, nous avons défini la structure suivante :
noms des colonnes : TOPO_E | CLSC_E | NBRE_CANCER | TX | RTS | P | C_V,
avec évidement les mêmes caractéristiques pour les champs (caractères en majuscules, nombres
entiers,…).
Nous avons d’abord rassemblé tous les tableaux nommés 01 et 99 chacun de leur côté. Pour ne
pas perdre cette information, nous avons ensuite créé une colonne NIV_SIGNI où nous avons
encodé cette information et après réunion des deux tables, nous avons rajouté un champ SEXE.
Ainsi, les tableaux finaux pour les femmes et pour les hommes avaient une structure identique.
Nous les avons unis pour former une grande table de 8112 enregistrements, dans laquelle un
champ CAT a été rajouté pour indiquer qu’il s’agissait des données concernant les adultes, et un
autre nommé CANCER_MIXTE/UNISEXE qui permettrait par la suite de faire un certain tri
dans les cancers. À chaque union de table, nous avons utilisé le même style de requêtes SQL
(figure 22) :
29
Quand on réalise une telle requête, il est nécessaire ensuite d’en faire une autre pour créer la table
correspondant à la première requête (figure 23).
Figure 23. Requête de création de table
Pour résumer les différentes étapes, regardons le schéma suivant (figure 24) :
Figure 24. Résumé des étapes de création de la table Access
La structure de la table des enfants était très différente.
Tout d’abord, les enregistrements sont donnés par RSS et non par CLSC. De plus, les
informations sont beaucoup plus complètes vu que l’on a le taux de la province pour chaque
cancer, le nombre d’enfants dans la RSS,… et surtout, le nombre de cancers est beaucoup plus
faible : il n’y a que des données sur les cancers du cerveau et les leucémies. Le nombre
30
d’enregistrements est de ce fait beaucoup plus faible. Suivant les mêmes étapes que pour les
adultes, nous avons modifié toutes nos tables pour qu’elles aient la structure suivante :
noms des colonnes : RSS | TOPO | N_ENF | POP_ENF | TX_BR_ENF (taux brut) | TX |
TX_QC_E | RTS | VAR_ENF | Z_ENF | P_ENF | CASESP_E | C_V | NIV_SIGNI.
Ensuite, nous avons travaillé sur la table des municipalités. A partir du fichier donné par le
CSPQ, nous avons complété notre base de données en rajoutant des informations sur le statut
juridique des municipalités.
Statut juridique Symbole
Municipalité M
Établissement amérindien EI
Terre de la catégorie I pour les Inuits I
Nous avons trouvé ces renseignements sur le site Web du Bureau des Statistiques du Québec
(BSQ). Cependant, depuis 1990, date du fichier du CSPQ, bon nombre de municipalités ont
fusionné et le nom de certaines municipalités a changé, si bien que l’on se retrouve avec des
municipalités du fichiers original auxquelles il est impossible de rajouter l’information voulue. En
observant les codes de municipalités, nous avons observé qu’au départ, toutes les municipalités
avaient un code se terminant par 0 ou 5. La municipalité résultant de la fusion de deux
municipalités ayant des codes qui se suivent se retrouve avec un code terminant par 2,3,7 ou 8.
31
(38028). Grantham (49055) et Drummonville (49060) ont fusionné en Drummonville (49057).
Pour d’autres cas, les fusions étaient plus difficiles à deviner car la fusion entre trois
municipalités est possible, et si les codes ne se suivent pas au départ, le code résultant n’a pas de
réelle logique. Nous ne pouvions nous aider que de la population de 1996 qui se trouvait sur le
site Web et ayant la population de 1991 sur notre fichier du CSPQ, nous pouvions observer la
variation de population qui devait être minime. Même avec tous ces détails, nous ne pouvions pas
trouver la fusion d’une vingtaine de municipalités. Yves van Chestein nous conseilla de prendre
contact avec le Ministère des Affaires Municipales du Gouvernement du Québec. Nous fûmes
étonnés de la rapidité de transmission des informations. En vingt-quatre heures, la quasi-totalité
des regroupements de municipalités nous fut communiquée (cf. extrait en annexe 5 ). En fait, il
aurait mieux valu que nous prenions contact tout de suite avec ce service pour une meilleure
efficacité dans notre travail. Dès lors, la modification de la table des municipalités a été très
rapide.
Plusieurs problèmes se sont posés tout de même :
Bromptonville ayant changé de MRC depuis 1990, son code de municipalité est passé de
42023 à 43023. Cependant, n’ayant en notre possession aucun changement de CLSC (une
municipalité qui change de MRC pourrait dépendre d’un autre CLSC), nous avons décidé de
garder l’ancien numéro de municipalité.
Deux MRC ont été créées : la Côte Nord (982) et Kativik (992). Nous avons redistribué les
municipalités dans ces nouvelles MRC.
Nous n’avons pas trouvé certaines municipalités dans le nouveau fichier des municipalités du
BSQ ni dans le document de regroupement des municipalités. Ayant des données du cancer dans
les CLSC qui dépendaient de ces municipalités, nous avons décidé de toutes les garder. Nous
avons rajouté un statut juridique fictif. La liste de ces municipalités se trouve en annexe 6.
Des municipalités du fichier du BSQ n’ont pas de correspondance dans le fichier du CSPQ.
N’ayant aucune donnée sur le cancer pour ces municipalités, nous avons décidé, en accord avec
Yvan Bédard, de ne pas les considérer. Ces municipalités sont nommées en annexe 7.
En effet, le but du projet n’est pas d’être parfaitement exact mais de montrer les possibilités du
logiciel.
Tout ceci nous a montré le problème des conflits spatio-temporels des données. Les données du
CSPQ sur les municipalités datent d’avant 1990, alors que les statuts juridiques disponibles sur le
Web sont très récents. Afin de conjuguer les données, il faut faire des compromis; mais un
32
problème demeure tout de même car nous nous retrouvons avec les municipalités de 1996 alors
que les données du cancer datent d’avant 1993. Si on veut étudier la situation de 1993, alors les
données sont faussées car les municipalités sont plus importantes en population qu’elles ne
l’étaient en réalité. En effet, nous avons additionné les populations des villes qui fusionnaient
pour garder le même nombre de citoyens dans la province entière. Dans un système définitif, il
faudra régler ce problème en prenant un fichier des municipalités et un fichier sur les données du
cancer datant de la même période.
Nous avons ensuite rajouté une colonne superficie dans notre table : le but était de calculer par la
suite la densité de population par municipalité pour voir si le nombre de cancers augmentait avec
des populations plus denses. Pour cela, nous nous sommes servis de Mapinfo, nous avons ouvert
le fichier des municipalités et réalisé la requête SQL suivante (figure 25) :
Figure 25. Requête SQL de calcul de superficie des municipalités
Cela nous a donné comme résultat un tableau contenant les codes de toutes les municipalités du
Québec avec leur superficie respective en km2 (figure 26).
33
Figure 26. Tableau résultat de la requête de calcul de la superficie
Ensuite il a fallu intégrer cette table dans Access et faire un joint avec la table des municipalités.
Cependant, nous avons dû rajouter des superficies fictives pour certaines municipalités car le
fichier MapInfo datant d’avant 1990, le problème des municipalités fusionnées s’est encore posé;
les codes donnés dans le tableau format MapInfo ne correspondaient pas forcément avec les
nouveaux codes rentrés quelques temps auparavant dans la table des municipalités. La liste des
municipalités aux superficies fictives se trouve en annexe 8.
L’étape suivante consistait à réunir les trois tables résultantes : celle des municipalités, celle des
adultes et celle des enfants. La table des adultes et celle des enfants ne pouvaient pas être unies
car elles ne contenaient pas le même nombre de colonnes. Il a donc fallu que nous fassions des
joints avec une colonne commune. Pour joindre les municipalités avec les adultes, nous avons
choisi la colonne des codes de municipalités en prenant pour type de joint celui qui garde toutes
les informations de la table des municipalités et qui rajoute celles de la table des adultes quand les
codes des municipalités sont égaux dans les deux tables. Ainsi, même les municipalités où aucun
type de cancer n’a été recensé figurent dans la table finale. Pour faire le joint en question, il a
suffi de faire une requête en mode «design view » (figure 27).
34
Figure 27. Requête de joint des tables des municipalités et des adultes
Dans cette requête, on précise que l’on garde tous les champs de la table des municipalités
(table.*) et on rajoute tous les champs de la table des adultes qui ne sont pas communs. Ensuite, il
faut faire obligatoirement une autre requête pour créer une table résultat comme nous l’avons vu
précédemment.
En ce qui concerne le rattachement de la table des enfants, la méthode a été différente car nous ne
voulions pas que toutes les données relatives à des RSS (donc à de grandes superficies) soient
copiées pour chaque municipalité. Il a donc fallu faire une union de table en rajoutant des champs
dans les deux tables restantes afin que les structures de celles-ci soit exactement les mêmes.
Après toutes ces étapes, une première version de la grande table Access est donc prête; il est à
présent possible de faire un hypercube.
3 ) Création de l’hypercube avec Transformer
a) Définition d’un hypercube
Afin de pouvoir naviguer facilement dans la base de données pour en retirer des informations
significatives pour l’utilisateur, il est d’abord nécessaire de structurer les données. Comme dans
un arbre généalogique, il va falloir créer des branches qui supporteront de plus petites branches,
et ainsi de suite jusqu’aux feuilles. Dans notre cas, les feuilles correspondraient aux informations
concernant les plus petits détails, alors que les branches indiqueraient les différentes dimensions,
les différents thèmes à l’étude. C’est grâce à cette capacité d’approcher les données d’une
manière multidimensionnelle que l’on parle de création de cube multidimentionnel; une autre
35
dénomination est hypercube. Ce dernier va permettre de faciliter les calculs d’agrégation des
données et par cela même les analyses complexes qui seront réalisées par l’utilisateur.
b) Création de l’hypercube
Après avoir longuement réfléchi sur les données à ma disposition et sur les besoins que pouvaient
avoir les gens du domaine de la santé, qui seront les futurs utilisateurs, nous avons tenté de
réaliser un premier hypercube avec Transformer. Des copies d’écrans seront insérées tout au long
de cette partie pour mieux faire comprendre les différentes étapes.
Le logiciel Transformer de la société Cognos nécessite l’importation d’un table unique qui doit
être de format texte, ASCII,… Dans notre cas, nous avons choisi le format .csv avec des virgules
comme séparateurs de données. Nous avons donc exporté sous Access notre table dans le format
désiré. Il faut faire attention car ce format n’est pas accessible dans toutes les versions de Access.
Normalement, une construction automatique de l’hypercube est possible. Elle a été mise au point
pour des bases de données liées à la gestion d’entreprises. En effet, il faut rappeler que le logiciel
Powerplay est très utilisé dans le monde des affaires, c’est pour ce milieu-là qu’il a été créé à
l’origine. Cependant, la fonction de création automatique du cube ne reflète jamais le résultat de
l’analyse des données complexes; il est donc nécessaire de la désactiver.
Quand l’importation est effectuée, quatre fenêtres apparaissent à l’écran comme l’indique la
figure 28.
36
La fenêtre Dimension Map est celle où les dimensions et sous-dimensions du cube vont être
inscrites. Il suffit de cliquer avec le bouton droit de la souris sur la bande grise pour créer une
nouvelle dimension.
Dans la fenêtre Queries, il est possible de distinguer tous les noms de champs de la table qui a
été importée. C’est en déplaçant les éléments de cette fenêtre vers Dimension Map que l’on va
pouvoir créer la ramification de chaque dimension. Ce déplacement est réalisé en faisant glisser
les éléments désirés vers la dimension choisie de la fenêtre Dimension Map.
Dans la fenêtre Measures, il va falloir choisir les types de mesures utilisées pour faire les
analyses. Cette fenêtre doit contenir obligatoirement au moins un élément. Il est nécessaire que
les types de mesures soient présents dans tous les enregistrements de la table importée.
La fenêtre PowerCubes contient le nom de l’hypercube une fois que toute la structure a été
mise en place et qu’on a lancé une création d’hypercube. Si la structure est modifiée, il faut
relancer la création de l’hypercube avant de passer sous Powerplay.
Dans notre cas, la réalisation de notre premier hypercube a donné, après de nombreuses petites
rectifications, le résultat suivant (figure 29) :
Figure 29. Premier hypercube réalisé
Comme on peut le distinguer sur la copie d’écran, notre cube possède de nombreuses
dimensions :
SPATIAL_ADM : contient le découpage spatial administratif RA - MRC - Municipalités
SPATIAL_SANTE : contient le découpage spatial du domaine de la santé RSS – CLSC
37
ENVIRONNEMENT : donne un critère « Urbain », « Semi-urbain » ou « Rural » à toutes les
municipalités. Ce critère a été choisi avec Yvan Bédard en tenant compte des statuts juridiques
des municipalités. Ainsi, nous avons choisi d’organiser un découpage en tenant compte des
catégories suivantes :
Rural : municipalité de canton, municipalité de cantons unis, municipalité de paroisse,
réserve indienne, territoire non organisé, municipalité de village cri, municipalité de
village nordique, municipalité de village naskapi, établissement amérindien, terre
réservée aux Cris et aus Naskapis, Terre de la catégoie I pour les Inuits.
AUTOCHTONE / NON AUTOCHTONE : de même que précédemment, nous avons choisi de
faire des catégories en regardant les statuts juridiques. Il en est ressorti les résultats suivant :
Non autochtone : cité, ville, municipalité de village, municipalité, municipalité de
canton, municipalité de cantons unis, municipalité de paroisse, territoire non organisé
Autochtone : , réserve indienne, municipalité de village cri, municipalité de village
nordique, municipalité de village naskapi, établissement amérindien, terre réservée aux
Cris et aus Naskapis, Terre de la catégoie I pour les Inuits.
SEXE : distinction homme / femme
AGE : distinction adulte / enfant
CANCERS : contient toutes les sortes de cancers présents dans les données. Pour que les
données soient plus faciles à lire dans Powerplay, nous avons regroupé les cancers par classes en
nous aidant de tableaux pages 6 et 7 de l’atlas des cancers, ce qui a nécessité la création d’un
nouveau champ dans la table Access.
Remarque : La création de ces classes est indispensable car s’il y a plus de dix données
différentes sur un des axes (dimensions), celles-ci deviennent difficiles à étudier. De plus, après
des études en psychologie, il a été prouvé que l’homme ne pouvait prendre en compte que sept
éléments (±2); après ce chiffre, le cerveau n’est plus capable de tout gérer. Cette remarque est à
prendre au sérieux et à utiliser dans l’architecture de notre cube.
NIVEAU SIGNIFICATION : permet de voir si les données sont significatives ou non
(tableaux en 01 ou 99), c’est-à-dire si la probabilité calculée est inférieure ou supérieure à 0,01.
Nous renvoyons à l’annexe 2 pour remémorer la méthode de calcul.
TAUX : toutes les données concernant les taux ont été regroupées en classes délimitées
arbitrairement pour les mêmes raisons que les cancers. Si nous n’avions pas réalisé cette
opération, 77000 nombres différents auraient dû s’afficher dans Powerplay, ce qui est largement
38
au-dessus des limites de gestion du logiciel. Même en établissant ces classes, le nombre de
données différentes est trop important.
RTS : idem que pour les taux.
P : idem que pour les taux.
C_V : idem que pour les taux.
CANCER MIXTE / UNISEXE : à part tous les cancers des organes génitaux, les cancers sont
considérés comme mixtes car ils affectent aussi bien les hommes que les femmes. Cette
dimension peut servir à agréger encore un peu plus les données.
POP_E : cette dimension ne porte que sur les données concernant les enfants; là aussi nous
avons créé des classes de données.
TX_BR_E : idem que pour POP_E.
TX_QC_E : idem que pour POP_E.
DENSITE POP : contient les données de densité de population au kilomètre carré pour chaque
municipalité. Des classes permettent aussi une meilleure lecture des données.
YVAN : cette dimension nous a été demandée par Yvan Bédard pour montrer jusqu’à quel
point il est possible d’agréger les données. Elle représente à elle seule un mini-arbre. Chaque
sous-catégorie ou branche représente un filtre de recherche, ce qui permet d’afficher sous
Powerplay d’une façon détournée plus de dimensions que le logiciel ne peut en gérer. Ainsi, on
peut faire les recherches suivantes (figure 30) :
39
Figure 30. Structure de la dimension « Yvan »
Des noms de dimensions reviennent précédés du signe #. Cela signifie que dans ces
dimensions, les nombres sont remplacés par des lettres. Par exemple, 162 dans la dimension
CANCERS sera remplacé par « poumon » dans la dimension #CANCERS. Cela permet ainsi aux
utilisateurs non familiers des codes utilisés quotidiennement par les gens de la santé de pouvoir
également faire des recherches dans le système.
Dans la fenêtre measures, nous avons choisi plusieurs données différentes : la population en 1991
et le nombre de cancers. Les taux, RTS et P ont été rajoutés après une demande de Germain Lebel
car ce sont des données qui sont très importantes pour les gens de la santé.
C’est ce cube, ainsi structuré, qui a été présenté à Germain Lebel et Marie France Gagnon.
40
a) Quelques explications sur l’environnement de Powerplay
Powerplay est le logiciel dans lequel se fait l’analyse multidimensionnelle et interactive des
données. Comme la plupart des OLAP, il utilise un hypercube comme source de données.
L’utilisateur va choisir les dimensions dont il a besoin pour effectuer ses recherches et le résultat
de sa navigation va se trouver soit sous forme de tableau (par défaut), soit sous forme de
camembert, soit sous forme d’histogramme… Nous pensons que l’histogramme en trois
dimensions permet la meilleure visualisation des données. Un passage sous forme de tableau
permettra à l’utilisateur de recopier des chiffres s’il les trouve intéressants pour son étude.
Cependant, un gros défaut du logiciel est qu’il est impossible dans la version actuelle d’exporter
des données quand l’utilisateur a trouvé une piste de recherche.
Pour mieux comprendre le fonctionnement du logiciel, nous allons observer quelques copies
d’écran.
Figure 31. Environnement de Powerplay
Dans la figure 31, c’est sous forme de tableau qu’a été choisi l’affichage. Les icônes de droite
permettent de changer le tableau en histogramme,… Au-dessus du tableau, on retrouve la barre
multidimensionnelle (figure 32).
41
Toutes les dimensions de l’hypercube se retrouvent dans cette barre. La classe « measures » se
situe à la fin de celle-ci .
Dans la partie de droite, la fenêtre « Categories » (figure 33) regroupe toute la structure mise en
place avec Transformer. C’est là que l’utilisateur choisit les dimensions qu’il veut voir apparaître
à l’écran. Quatre dimensions peuvent être affichées en même temps :
une en ligne (row) : cette dimension ressemblerait à X dans un espace mathématique classique
composé de trois axes;
une en colonne (column) : cela correspondrait au Y;
une en couche (layer) : c’est le type de mesure choisi (par exemple le nombre de cancers),
donc la quantité de cas qui correspondent aux deux critères choisis auparavant en X et Y. Cela
s’apparente donc à Z dans notre vision classique du système à trois axes;
une en filtre (filter) : il est préférable que cette dimension soit subdivisée en classes. Ainsi
n’apparaîtront à l’écran que les données de la classe en question qui correspondent aux trois
critères précédents. Il s’agit d’appliquer une sorte de filtre à nos données.
Figure 33. Fenêtre Categories de Powerplay
42
Remarque : Cette fenêtre possède un défaut de conception : les dimensions sélectionnées
n’apparaissent pas par une mise en valeur quelconque. Le choix d’une couleur différente pour
chaque dimension choisie aurait pu faciliter son utilisation.
Dans la figure 33, nous pouvons apercevoir qu’une des sous-catégories dans chaque dimension
sélectionnée s’appelle blank (ce qui signifie blanc, vide). Ceci est dû à la présence de cases vides
dans la colonne Access. Dès que Powerplay ne trouve pas de valeurs, au lieu de ne pas prendre en
compte ces enregistrements vides, il les compte et nomme le résultat de ce comptage blank. Le
problème est aussi que ces blanks peuvent être très nombreux pour certains champs et qu’ils
empêchent une bonne visualisation des données en histogramme 3D. Nous n’avons pas réussi à
désactiver cette fonction.
De plus, une autre fonction du logiciel empêche une bonne lecture des données : la fonction
total. En effet, dans chaque histogramme, nous remarquons que le dernier enregistrement
correspond à la somme de tous les autres. Ceci implique que le dernier parallélépipède est très
haut par rapport à tous les autres (figure 34). Nous n’avons pas trouvé comment enlever cette
création de totaux par défaut.
Figure 34. Visualisation du problème des totaux
43
Par exemple, sur la figure 34, un regard rapide nous attire vers les enregistrements du fond. A
gauche, ils correspondent aux totaux des cas de cancers dans les différentes RSS, et à droite aux
totaux de tous les types de cancers. Le polygone du fond représente la somme de tous ces totaux,
ce qui aggrave un peu plus la visualisation des données. L’échelle est mal choisie pour connaître
le nombre de cas de cancers dans un cas bien particulier. Si une désactivation de l’option était
possible, le nombre de cancers serait au maximum de 400000, ce qui faciliterait les observations.
Cette fonction fausse donc un peu la vision de l’utilisateur.
Pour naviguer dans les données, il y a deux possibilités : le pivot et le forage.
Le pivot (swap) permet d’échanger les lignes et les colonnes. Cette fonction n’est utile que si
l’utilisateur veut voir les données sous un autre angle.
Le drill (pas de traduction française), quant à lui, est beaucoup plus intéressant. Plusieurs types
sont possibles ;
- le drill up
Ces deux fonctions ont déjà été expliquées au II. 3) b).
- le drill across permet de changer complètement de catégorie à l’étude.
b) Exploration de notre hypercube
L’étape suivante a donc été l’importation de notre hypercube et la création d’un projet Powerplay
*.mdc. Ceci se fait rapidement. Il ne reste plus qu’à observer tous les petits défauts qui se
présentent lors de la navigation et à réparer les erreurs soit sous Access, soit sous Transformer. Ce
projet a nécessité plusieurs itérations avant d’arriver à un projet présentable à Germain Lebel et
Marie-France Gagnon. Les modifications ont déjà été décrites plus tôt dans le rapport.
44
V. MODIFICATION DES DONNEES ET AFFINEMENT DU PROJET
Lors d’une présentation de l’hypercube aux personnes responsables du projet au sein du CSPQ,
plusieurs remarques sont survenues, ce qui a mené à la modification du projet.
La dimension SPATIAL_ADM ne présente aucune utilité pour les gens de la santé, surtout
lorsque les données fournies font référence aux CLSC, donc à une autre sorte de découpage
spatial. Ce point était évident mais le but du projet était de pouvoir intégrer d’autres sortes de
données. La solution trouvée serait de se servir d’autres sources de données des cancers, celles-ci
renvoyant aux codes postaux (il y a un à plusieurs codes postaux par municipalité). Un exemple
de données ainsi référencées se trouve en annexe 9. Ces données ne nous ont pas été
communiquées au départ mais après la présentation de l’hypercube. Il est certain qu’il aurait
mieux valu réaliser le prototype avec ces données car elles ont plus complètes (âge exact des
malades indiqué, critère de riveraineté, information sur l’eau potable disponible,…). Cependant,
lorsque les données nous ont été fournies en janvier, il avait paru plus simple à Germain et Marie-
France de nous