Développement de technologies géospatiales

Transcription

1 Développement de technologies géospatiales Livrable 2 : Rapport et démonstrateur technologique pour la création de données, des métadonnées et leur utilisation Eveline Bernier, M.Sc. Université Laval, Chaire CRNSG de recherche industrielle en bases de données géospatiales décisionnelles Yvan Bédard, Ph.D. Université Laval, Chaire CRNSG de recherche industrielle en bases de données géospatiales décisionnelles

2

3 Table des matières 1. Introduction Définition du cas d utilisation : la tempête de verglas de Inventaire des données Architecture et technologies utilisées En général Dans le cadre du prototype Modélisation multidimensionnelle En général Dans le cadre du prototype Processus d extraction, de transformation et de chargement des données (ETL) En général Dans le cadre du prototype Considérations et nuances Volume de données et temps de traitementsal Le cube Planification et ses possibilités d analyse Le cube Analyse et ses possibilités d analyse Gestion des métadonnées Problèmes rencontrés Points à considérer en vue de faciliter le déploiement d applications SOLAP SOLAP et temps-réel Conclusion Références Annexes ii Développement de technologies géospatiales Livrable 2

4 Liste des figures Figure 1. Découpage territorial du prototype Figure 2. Architecture ROLAP Figure 3. Architecture MOLAP Figure 4. Architecture HOLAP Figure 5. Modèle en étoile Figure 6. Modèle en flocon Figure 7. Architecture du prototype développé Figure 8. Composants du gabarit multidimensionnel Figure 9. Pictogrammes multidimensionnels Figure 10. Les trois niveaux de modélisation conceptuelle multidimensionnelle Figure 11. Modèle conceptuel multidimensionnel du cube Verglas-Planification (niveau Cube et dimensions) Figure 12. Modèle conceptuel multidimensionnel du cube Verglas-Analyse (niveau Cube et dimensions) Figure 13. Modèle d implantation du cube Verglas-Planification (en étoile) Figure 14. Modèle d implantation du cube Verglas-Analyse (en étoile) Figure 15. Implantation d une dimension de type étoile Figure 16. Implantation d une dimension de type parent-enfant Figure 17. Étapes suivies pour la production des données multidimensionnelles Figure 18. Extrait du fichier de lignes de commandes SAS Figure 19. Répartition de la population selon des vues tabulaire, graphique et cartographique33 Figure 20. Analyse de la répartition de la population à différents niveaux de détail Figure 21. Nb. de personnes par groupe d âge, par type de population et par arrondissement 34

5 Figure 22. Graphique de la population par groupe d âge, par type de population, pour l arrondissement Le Plateau Mont-Royal Figure 23. Analyse du nombre de bâtiments par type, par arrondissement, qui sont reliés à des lignes à 120kV et 315 kv Figure 24. Cartographie des bâtiments reliés à la ligne d électricité Figure 25. Exemple d analyse via le cube Verglas-Analyse Figure 26. Localisation des bâtiments où une intervention militaire a eu lieu Figure 27. Analyse du type d équipement par type de bâtiment déployé par un secours militaire Figure 28. Dimensions balancée et débalancée Liste des tableaux Tableau 1. Inventaire de données... 9 Tableau 2. Sommaire des étapes suivies Tableau 3. Métadonnées SOLAP iv Développement de technologies géospatiales Livrable 2

6 .

7 1. Introduction Le présent projet vise à décrire les différentes étapes normalement requises lors du développement d une application SOLAP. Pour ce faire, un prototype SOLAP a été développé afin de concrétiser chacune de ces étapes en plus de démontrer les capacités d un tel outil à supporter la prise de décision. Plus spécifiquement, les étapes de développement ont inclus la définition d un cas d utilisation (tempête de verglas), l inventaire des données, la modélisation multidimensionnelle, la création de la base de données multidimensionnelle ainsi que les différentes fonctions de nettoyage, de fusion, d agrégation et de synthèse des données (ETL) préalables au peuplement de la base de données. De plus, un volet métadonnée a été intégré afin de gérer adéquatement les métadonnées multidimensionnelles. Le prototype développé permet également l affichage d images satellitaires ou orthophotographies à des fins de contexte. Finalement, des documents de différentes natures (images, photographies, vidéo, enregistrements vocaux) ont être associés directement aux données (à différents niveaux), ce qui résulte en un prototype SOLAP hypermédia. Le prototype développé repose sur la technologie JMap Spatial OLAP, un engin SOLAP développé par l équipe du Dr Yvan Bédard du Centre de recherche en géomatique de l Université Laval et commercialisé par KHEOPS Technologies (un partenaire de la Chaire). Le tout ayant été couplé avec une base de données relationnelle (Oracle), structurée selon un schéma multidimensionnel. Ce rapport débute par la description du cas d utilisation retenu pour le développement du prototype, soit la tempête de verglas qui a touché une grande partie du Québec en 1998 (section 2). Il présente ensuite brièvement l inventaire des données utilisées (section 3) et décrit l architecture technologique à la base du prototype (section 4). La section 5 discute des concepts de modélisation multidimensionnelle et présente les modèles propres au prototype. La section 6 aborde le processus d extraction, de transformation et de chargement (ETL) des données et présente les différentes étapes ayant été réalisées préalablement à l obtention de la base de données relationnelle finale. Les sections 7 et 8 présentent concrètement les deux cubes du prototype avec des exemples d analyse pour chacun. La section 9 traite de la gestion des métadonnées alors que celle qui suit discute des problèmes rencontrés lors du développement du prototype. Les points à considérer en vue de faciliter le déploiement d applications SOLAP font l objet de la section 11. La section 12 présente les concepts de SOLAP temps-réel, quasi-réel et juste à temps. Finalement, la dernière section conclut ce rapport. Le tout est complété d un cédérom contenant des exemples d analyses sous forme d animations vidéo. La plupart des sections débutent par un survol théorique de l aspect traité pour ensuite décrire concrètement ce qui a été réalisé dans le cadre du prototype. 6 Développement de technologies géospatiales Livrable 2

8 2. Définition du cas d utilisation : la tempête de verglas de 1998 Le prototype SOLAP a été développé en utilisant des données (réelles et simulées) issues de la tempête de verglas qui a touché plusieurs régions du Canada en De l est ontarien au Nouveau-Brunswick, des millions de personnes se sont retrouvées sans électricité, certaines pendant plus d un mois. Cette tempête a eu des impacts à différents paliers de la société, économiques, sociaux et environnementaux. Parmi eux notons des pertes de vie, des dommages majeurs aux infrastructures électriques, au milieu agricole (érablières et vergers) ainsi qu au milieu forestier, qui constitue sans doute l impact environnemental le plus important et visible du sinistre. Quelques statistiques : La tempête aura duré 5 jours et laissé entre 50 et 90 mm de verglas; 1000 pylônes électriques sont tombés ainsi que poteaux de bois, 120 lignes de transports ont été endommagées; soldats ont été mobilisés, le plus important déploiement militaire en tant de paix de l'histoire du Canada; 3 millions de personnes ont été en panne simultanément à un certain moment donné. Des dizaines de milliers de personnes ont été privées de courant durant plus d'un mois; 454 centres d'hébergement se sont ouverts recevant, dans des conditions souvent lamentables, des centaines de milliers de personnes sinistrées. Les hôpitaux ont été submergés, les médecins et les infirmières littéralement débordés; Des milliers de personnes ont perdu plusieurs semaines d'emploi, entraînant une hausse de 250% de demande de chômage; Le coût des travaux de consolidation du réseau hydroélectrique s'élèvera pour sa part à 850 millions de dollars. Deux volets ont été développés dans le cadre du prototype : le volet Planification et le volet Analyse. Le premier permet de mieux se préparer en vue d un éventuel sinistre de ce type en permettant de répondre à des questions du genre : Quelle est la répartition de la population par groupe d âge, par MRC, par municipalité, par arrondissement? Quels sont les municipalités ayant le plus haut taux de population âgée de 70 ans et plus? Combien de bâtiments peuvent servir de centres d hébergement lors d un tel sinistre et où sont-ils situés? Quel est le nombre de CHSLD (Centre d hébergement et de soins de longue durée) dans l arrondissement Outremont et où sont-ils localisés? Développement de technologies géospatiales Livrable 2 7

9 Le deuxième volet supporte l analyse des données issues des événements de janvier 1998 (données pour la plupart simulées). Il permet notamment de répondre à des questions du type : Quels sont les types d équipements d urgence (matériel (lit, génératrice), médical, etc.) et les types de secours (médical, militaire, etc.) qui ont été les plus utilisés par arrondissement, par type de bâtiment, etc.? Quelle est la répartition des secours militaire sur le territoire de la Ville de Montréal? 8 Développement de technologies géospatiales Livrable 2

10 3. Inventaire des données Le prototype développé couvre principalement les régions administratives (RA) de Laval, Montréal et Montérégie (qui ont été les plus touchées par la tempête) mais inclut également le découpage des municipalités régionales de comté (MRC) et des RA pour l ensemble de la province du Québec. Les sources de données spatiales utilisées sont présentées au tableau suivant. Tableau 1. Inventaire de données NOM SOURCE UTILISATION Planif CUBE Analyse Bâtiment BNDT 50K Niveau inférieur (1) de la dimension Découpage territorial X X (ptie) Arrondissement SDA-20K Niveau 2 de la dimension Découpage territorial X X Municipalité BDGA-1 000K Niveau 3 de la dimension Découpage territorial X X MRC BDGA-1 000K Niveau 4 de la dimension Découpage territorial X X RA BDGA-1 000K Niveau 5 de la dimension Découpage territorial X X Réseau électrique Hydro-Québec (extrait de BGTE) Dimension Réseau électrique X Réseau routier RRN Géobase Couche de contexte (vectorielle) X X Image satellitaire CanImage Couche de contexte (raster) X Orthophoto MRNFQ Couche de contexte (raster) X Développement de technologies géospatiales Livrable 2 9

11 Figure 1. Découpage territorial du prototype Par ailleurs, les données descriptives (population, groupe d âge, etc.) ont été simulées. Certaines auraient toutefois pu être récupérées de Statistiques Canada ou de l Institut de la statistique du Québec. Ces organismes fournissent gratuitement plusieurs données statistiques relativement à la population (démographique, recensement). La plupart des données sont téléchargeables en format Excel. Statistiques Canada dispose également de données au format multidimensionnel Beyond 20/ Développement de technologies géospatiales Livrable 2

12 4. Architecture et technologies utilisées 4.1 En général En général, l architecture d un système (S) OLAP se compose de trois composantes principales : 1) la base de données, 2) le serveur et 3) le module client. La base de données contient les données résumées et agrégées et doit être structurée de manière multidimensionnelle. Le serveur (S)OLAP gère la structure multidimensionnelle ainsi que l accès aux données alors que le module client permet aux utilisateurs d explorer les données sous diverses formes : tabulaires, graphiques, cartographiques. Le type de base de données utilisé définit l architecture du système : Relational OLAP (ROLAP), Multidimensional OLAP (MOLAP) et Hybrid OLAP (HOLAP). ROLAP Une telle architecture se compose d une base de données relationnelle qui est structurée selon un schéma multidimensionnel (voir section suivante). Cette base de données se compose des données détaillées et des données agrégées de l entrepôt qui sont stockées sous forme de tables dans une base de données relationnelle. Le serveur extrait les données via des requêtes SQL et interprète les données selon une vue multidimensionnelle avant de les présenter au module client. MOLAP Figure 2. Architecture ROLAP Les données détaillées ainsi que les données agrégées sont stockées dans une base de données multidimensionnelle (souvent appelée cube ou hypercube). Une base de données multidimensionnelle utilise une structure propriétaire au logiciel utilisé. Le serveur MOLAP extrait les données de l hypercube et les présente correctement au module client. Développement de technologies géospatiales Livrable 2 11

13 Figure 3. Architecture MOLAP HOLAP Cette architecture est un croisement des deux architectures précédentes. Les données détaillées sont stockées dans une base de données relationnelle et les données agrégées sont stockées dans une base de données multidimensionnelle. Le serveur HOLAP accède à ces deux bases de données et les présente au module client, selon une vue multidimensionnelle dans le cas des données de la BD relationnelle. Modèles multidimensionnels Figure 4. Architecture HOLAP Lorsqu une base de données relationnelle est utilisée pour stocker les données, il est nécessaire de simuler une structure multidimensionnelle via des modèles particuliers. Ces modèles peuvent être de type Étoile, Flocon, Mixte ou autre. Le modèle en étoile comprend : un objet central, nommé table de faits, 12 Développement de technologies géospatiales Livrable 2

14 connecté à un certain nombre d objets de manières radiale, appelés tables de dimension. La table des faits, comme son nom l indique, contient les faits. Les tables de dimensions contiennent les attributs définissant chacun des membres des dimensions et sont dénormalisées. Figure 5. Modèle en étoile Le schéma en flocon est dérivé du schéma en étoile où les tables de dimension sont normalisées (la table des faits reste inchangée). Avec ce schéma, chacune des dimensions est décomposée selon sa ou ses hiérarchie(s). Figure 6. Modèle en flocon Pour plus d information sur ces concepts, le lecteur est invité à consulter Bédard et al. [2001] et Rivest [2000]. 4.2 Dans le cadre du prototype Le prototype développé repose sur une architecture ROLAP, dans laquelle les données sont conservées dans une base de données relationnelle (ORACLE), structurée selon un schéma en étoile (figures 13 et 14). Le serveur d application ainsi que le client Développement de technologies géospatiales Livrable 2 13

15 SOLAP sont développés autour de la technologie JMap et son extension Spatial OLAP 1. Cette extension résulte des travaux de recherche de l équipe du Dr Yvan Bédard et est commercialisée par KHEOPS Technologies (un partenaire de la Chaire). Figure 7. Architecture du prototype développé Serveur de données Le serveur de données consiste en une base de données relationnelle de format Oracle dans laquelle les données sont stockées selon un schéma en étoile. Autant les données agrégées que détaillées y sont conservées étant donné qu aucun calcul d agrégation n est effectué à la volée de par le type de serveur utilisé (ROLAP). Les données ont été regroupées en deux cubes différents, l un pour la planification et l autre pour l analyse (voir section 5.2). Les données spatiales sont, quant à elles, conservées dans leur format natif (shapefile). Serveur d application Le serveur d application se compose de deux modules. Le premier, le JMapServer, est le serveur cartographique responsable d exécuter les requêtes spatiales. Son extension JMap Spatial OLAP est quant à elle responsable du traitement des requêtes SOLAP. Elle interroge directement la base de données via des requêtes SQL et un pilote JDBC et prépare les résultats interprétables par le client. L extension dispose également d un sous-système d administration permettant de configurer l accès aux bases de données relationnelles multidimensionnelles (schémas en étoile, en flocon, etc.) et de définir les relations entre les informations de type OLAP et les différentes couches de données spatiales. Client SOLAP Le client SOLAP consiste en un applet JAVA qui est démarré en accédant à une URL spécifique via un navigateur Web. Une fois chargée et démarrée, l applet communique 1 Pour plus d information sur la technologie JMap SOLAP Extension, le lecteur est invité à consulter 14 Développement de technologies géospatiales Livrable 2

16 directement avec le serveur d application pour effecteur les requêtes OLAP et SOLAP. Le client est responsable de l affichage cartographique, tabulaire ou graphique. L administration du client s effectue via le JMapWebAdmin qui se compose de pages Web dynamiques et permet aux administrateurs de configurer le JMapServeur et l extension SOLAP. Développement de technologies géospatiales Livrable 2 15

17 5. Modélisation multidimensionnelle 5.1 En général À l instar des applications transactionnelles, il est nécessaire de modéliser la base de données décisionnelle avant de procéder à son implantation dans le futur système. À l heure actuelle, il n existe pas de méthode formelle de modélisation multidimensionnelle. Toutefois, l équipe du Dr Bédard a défini certaines règles et une extension multidimensionnelle à l outil Perceptory est en cours de développement. Extension multidimensionnelle à Perceptory L extension multidimensionnelle propose d étendre le formalise orienté-objets UML avec des pictogrammes gérant les aspects multidimensionnels (et spatio-temporels). La méthode de modélisation prévoit trois niveaux, soit les niveaux Cube (1), Dimension (2) et Membre (3). Le premier niveau permet la description générale du ou des cube(s) de l application ainsi que de ses composantes (dimensions et mesures). Le deuxième niveau permet la description détaillée des dimensions (hiérarchies et niveaux). Finalement, le troisième niveau permet de décrire plus spécifiquement les membres des dimensions (voir Annexe 1). Graphiquement, les composantes actuelles de Perceptory peuvent être utilisées pour modéliser tous les éléments multidimensionnels (cube, dimension, mesure, niveau et membre). Les paquetages sont utilisés pour les cubes et les dimensions alors que les classes sont utilisées pour décrire les mesures, les niveaux et les membres (figure 8). Figure 8. Composants du gabarit multidimensionnel De nouveaux pictogrammes ont également été créés afin de clairement identifier les différents éléments multidimensionnels. Les 6 nouveaux pictogrammes sont présentés au tableau 1 et s insère généralement à gauche du nom du paquetage (cubes et dimensions) ou de la classe (mesures, niveaux et membres). 16 Développement de technologies géospatiales Livrable 2

18 Cube Dimension descriptive spatiale temporelle Mesure Membre Figure 9. Pictogrammes multidimensionnels Niveau 1 Niveau 2 Niveau 3 Figure 10. Les trois niveaux de modélisation conceptuelle multidimensionnelle L extension multidimensionnelle permettra également d assister la modélisation en permettant de : Développement de technologies géospatiales Livrable 2 17

19 gérer la syntaxe du modèle (liens entre les cubes, dimensions, niveaux et membres); documenter les métadonnées; créer les modèles multidimensionnels à partir de modèles transactionnels ou de bases de données sources; générer l implantation (en schéma en étoile); générer le code d implantation de la base de données. 5.2 Dans le cadre du prototype Les deux figures qui suivent présentent les modèles conceptuels multidimensionnels des deux cubes du prototype (figures 11 et 12). Elles sont suivies des modèles d implantation respectifs (figures 13 et 14). Le modèle conceptuel de 3 e niveau (membres) du cube Verglas-Analyse est présenté à titre indicatif à l annexe 1. Figure 11. Modèle conceptuel multidimensionnel du cube Verglas-Planification (niveau Cube et dimensions) 18 Développement de technologies géospatiales Livrable 2

20 Figure 12. Modèle conceptuel multidimensionnel du cube Verglas-Analyse (niveau Cube et dimensions) Développement de technologies géospatiales Livrable 2 19

21 Figure 13. Modèle d implantation du cube Verglas-Planification (en étoile) 20 Développement de technologies géospatiales Livrable 2

22 Figure 14. Modèle d implantation du cube Verglas-Analyse (en étoile) Les pictogrammes situés à la droite du nom de la classe illustrent le type d implantation suggérée pour la dimension. L étoile ( ) signifie une dimension où chaque niveau hiérarchique est représenté par un nouveau champ dans la table. Une occurrence se compose donc au minimum de tous les identifiants des niveaux auxquelles elle est associée (Figure 15). Développement de technologies géospatiales Livrable 2 21

23 Figure 15. Implantation d une dimension de type étoile Une dimension parent-enfant est illustrée par le pictogramme. Ce type d implantation est basé sur deux colonnes de table qui définissent ensemble les relations hiérarchiques entre les membres de la dimension. L'une de ces colonnes est appelée colonne clé du membre et identifie chaque membre de la dimension ; l'autre colonne est appelée colonne parent et identifie le parent de chaque membre de la dimension. Figure 16. Implantation d une dimension de type parent-enfant 22 Développement de technologies géospatiales Livrable 2

24 6. Processus d extraction, de transformation et de chargement des données (ETL) 6.1 En général Le développement d une application décisionnelle, de par sa nature intégratrice, nécessite au préalable l extraction de données diverses à partir de systèmes sources hétérogènes. Ces systèmes sources diffèrent généralement tant au niveau de leur format, de leur structure et de leurs données. Les processus d extraction, de transformation et de chargement des données, communément regroupés sous l appellation ETL (Extract, Transform and Load), sont ainsi utilisés pour extraire les données des systèmes sources, les transformer (voire les intégrer) et les charger dans le système cible, par exemple un entrepôt de données. Par extension, un «outil ETL» dispose de toutes les fonctionnalités nécessaires à ces processus (voir le livrable 1 pour une revue des outils ETL (spatiaux) actuellement disponibles sur le marché). Dans le domaine décisionnel non spatial, les opérations d ETL permettent notamment de : extraire les données ; filtrer / sélectionner les données ; ordonner / fusionner les données ; joindre / associer les données ; reformater les données / convertir les types de données (p.ex. : de numérique à monétaire) ; agréger les données (p. ex. : avec des opérateurs de sommation ou de moyenne) ; enrichir les données. Dans le domaine décisionnel spatial, il est nécessaire de prendre en compte une nouvelle composante, soit la composante spatiale. De nouvelles opérations doivent alors s ajouter afin de permettre la manipulation des données géométriques. Ces nouvelles opérations permettent notamment de : changer le format de projection cartographique ; modifier la structure des données spatiales ; fusionner les données géométriques ; agréger les données géométriques ; généraliser les données géométriques. Évidemment, les opérations touchant les données géométriques sont beaucoup plus complexes que celles touchant les données descriptives (décisionnel non spatial). Une agrégation de données numériques se fait aisément via des formules mathématiques ou Développement de technologies géospatiales Livrable 2 23

25 statistiques standard. À l opposé, l agrégation ou la généralisation de données spatiales est une lourde tâche qui, dans bien des cas, ne peut être complètement automatisée. Les processus ETL, d un point de vue général, ne sont pas plus amplement abordés dans ce rapport étant donné qu ils font l objet du livrable Dans le cadre du prototype Peu d opérations d extraction et de transformation ont été nécessaires dans le cadre du prototype puisque la plupart des données étaient inexistantes et ont dues être générées spécifiquement aux fins du prototype. Les seules opérations de ce type ont concerné les données géospatiales. Toutefois, des opérations subséquentes ont été nécessaires afin de calculer les agrégations qui doivent être explicitement stockées dans la base de données étant donné l architecture utilisée (ROLAP). La figure suivante illustre les différentes étapes suivies afin de créer la base de données ROLAP contenant les données détaillées et agrégées. Figure 17. Étapes suivies pour la production des données multidimensionnelles Extraction et transformation des données géométriques Différentes opérations ont dues être réalisées afin d uniformiser les données géospatiales : 1. Uniformiser le datum et le système de projection de tous les jeux de données (NAD83, MTM). Cette opération s est effectuée automatiquement via l outil FME. 24 Développement de technologies géospatiales Livrable 2

26 2. Délimiter la zone du prototype et ne conserver que les données qui y sont contenues. Les régions administratives ainsi que les municipalités régionales de comté (MRC) ont été conservées pour l ensemble du Québec. Les municipalités ont été nettoyées afin de ne conserver que celles appartenant aux régions administratives suivantes : Laval(13), Montréal(06) et Montérégie (16). Seuls les arrondissements de la municipalité (ville) de Montréal ont été conservés. Les infrastructures pour le transport d énergie (i.e. lignes de transmission d électricité) ont été limitées à ces mêmes régions administratives. Idem pour le réseau routier (couche de contexte). Ces opérations ont été effectuées via l outil ArcGIS et l opérateur de Clip (environ 4 minutes pour le plus gros jeu de données, i.e. les routes). 3. Identifier et stocker les relations de type parent-enfant entre les niveaux (voire membres) de la dimension découpage. Certains bâtiments ont été associés aux arrondissements (Montréal) alors que d autres ont été directement associés aux municipalités. Cette situation a entraîné un changement au niveau de la définition de la dimension Découpage. A priori, celle-ci avait été définie selon une structure en étoile. Toutefois, le fait d avoir différents niveaux de parents pour les membres d un même niveau nécessite de revoir la structure en parent-enfant. Ceci provient de fait que pour certains bâtiments, l identifiant «Arrondissement» aurait été nul ce qui engendre des problèmes lors de l agrégation. Les arrondissements ont été associés à la municipalité correspondante (i.e. Montréal) Les municipalités ont été associées aux MRC correspondantes et les MRC ont été associées aux RA correspondantes. Ces opérations ont été effectuées facilement avec l opérateur d analyse spatiale (are contained by) de ArcGIS. Elles ont résultées en l ajout de l identifiant du père dans la table enfant. 4. Identifier et stocker les lignes de transports électriques qui desservent chaque bâtiment. Cette opération a été effectuée manuellement (les données ne correspondent donc pas nécessairement avec la réalité) dans ArcGIS en tentant de relier chaque bâtiment à la ligne le plus près. Création et peuplement de la base de données ACCESS Les données descriptives de l application ont premièrement été intégrées dans une base de données MS Access, étant donné la facilité de manipulation associée à ce format. À noter que cette étape est nullement obligatoire. Les données auraient pu être Développement de technologies géospatiales Livrable 2 25

27 traitées dès le départ dans la base de données Oracle. Ce choix se justifie uniquement par la facilité de manipulation des bases de données Access. Dimensions spatiales La première étape a consisté en l importation des données descriptives reliées aux données géométriques (i.e. les fichiers.dbf) afin de définir et peupler les dimensions spatiales Découpage territorial et Réseau électrique. Les relations père-fils entre les différents niveaux de découpage territorial qui ont été définies au préalable (i.e. au niveau géométrique) ont servies à respecter la hiérarchie de la dimension. L importation de fichiers.dbf peut se faire directement dans Access (fonction Import) ou via l outil FME. Dimensions descriptives La deuxième étape a consisté en la création et le peuplement des différentes dimensions descriptives. Bien qu il s agisse de données fictives, ces dimensions ont été peuplées sur la base des informations contenues dans le rapport de la Commission Nicolet sur la tempête de Verglas de 1998 afin d obtenir un prototype plus près de la réalité. Dimensions temporelles Deux dimensions temporelles ont été définies, une pour chaque cube. La première se compose d un seul niveau hiérarchique (i.e. année) alors que la seconde se compose des niveaux Jour, Mois et Année. Tables de faits Le développement d une application SOLAP (et plus globalement, toute application multidimensionnelle) est normalement basée sur un, voire plusieurs systèmes transactionnels existant. Les données détaillées, i.e. les faits, sont donc déjà existants. En ce qui concerne le prototype développé, ces faits ont dû être créés. À cette fin, deux programmes VB (Visual Basic) ont été définis afin de peupler, le plus aléatoirement possible, les tables de faits qui seront utilisées par chacun des cubes. Un premier programme peuple la table de faits du cube Planification. Il consiste à générer, pour chaque bâtiment habitable, un nombre aléatoire d occupants (dont la portée varie selon le type de bâtiment). Un profil est associé à chaque occupant et définit son âge et son type de population (sourd et muet, handicapé mental, etc.). Un fait se compose donc des informations suivantes : Id_fait Id_pop Id_age Id_decoup Id_type_batim Id_elect Id_temps Nb_batim Nb_pers nbligne Il s agit des identifiants des niveaux inférieurs (i.e. les plus détaillés) de toutes les dimensions et des trois mesures du cube (nombre de bâtiments, nombre de personnes et nombre de lignes électriques). Le id_temps est identique pour tous les faits et équivaut à l année Un deuxième programme permet de peupler la table de faits du cube Analyse. Ce programme est plus complexe que le premier car en plus de générer les occupants de 26 Développement de technologies géospatiales Livrable 2

28 chaque bâtiment (dont le nombre peut varier si le bâtiment sert de centre d hébergement aux sinistrés), il doit également définir si un secours a été nécessaire et si des équipements spécifiques ont été utilisés. Également, les données doivent varier en fonction des jours critiques de la tempête (i.e. du 5 au 20 janvier). Dans ce cube, un fait est ainsi constitué des éléments qui composent la table de faits Planification en plus des identifiants des dimensions Fonction, Équipement et Secours. Création et peuplement de la base de données ORACLE Une fois les données (dimensions et tables de faits) correctement créées dans la base de données Access, la base de données Oracle qui sera utilisée au final par le client SOLAP a été créée et peuplée. Cette étape se réalise facilement soit en exportant les tables Access en fichier CSV (Comma Separated Value) et en insérant ces données dans les tables Oracle, soit en exportant le tout en fichiers.ctl et en exécutant ces fichiers via SQLLOADER. Création de la table de faits temporaire nécessaire aux calculs d agrégation de SAS Le logiciel SAS, qui est utilisé pour calculer les agrégations, nécessite à la base une table de faits qui contient les identifiants de tous les niveaux de toutes les dimensions. Les tables de faits préalablement créées ne possèdent que les identifiants des niveaux détaillés. Par exemple, la table de faits originale du cube Planification ne contient que l identifiant du bâtiment qui réfère à la dimension Découpage territorial. La table de faits requise par SAS doit, quant à elle, également contenir les identifiants des niveaux Arrondissement, Municipalité, MRC et RA pour chaque occurrence. Création du programme VB qui crée les lignes de commandes à être exécutées dans SAS Un programme VB a été défini afin de créer un fichier contenant les lignes de commande devant être exécutées dans SAS afin de calculer toutes les agrégations. Un extrait de ce fichier est présenté à la figure suivante : Développement de technologies géospatiales Livrable 2 27

29 Figure 18. Extrait du fichier de lignes de commandes SAS Il s agit en fait d un fichier texte (.sas) qui comprend toutes les combinaisons possibles et qui indique à SAS comment agréger les mesures (p.ex. SUM(NB_PERSONNE)). Création des agrégations par SAS et leur importation dans la table de faits originale L exécution des lignes de commandes dans SAS crée une nouvelle table dans Oracle qui contient des faits de niveaux agrégés. Ceux-ci doivent donc être ajoutés aux occurrences de la table de faits originale qui contient les faits de niveau détaillé. Ceci s effectue directement dans Oracle avec la commande INSERT INTO. Création des index sur les identifiants des dimensions dans la table de faits Finalement, afin d accélérer les réponses aux requêtes du client SOLAP, il est nécessaire de créer des index sur les identifiants de chaque dimension. Ceci s effectue simplement dans Oracle via la commande CREATE BITMAP INDEX. Définition des paramètres de chaque cube via l administrateur JMAP SOLAP La première étape consiste à configurer la connexion à la base de données source. La deuxième étape vise à charger toutes les sources de données spatiales. JMap peut lire plusieurs formats dont le format shapefile dans lequel sont conservées les données spatiales du prototype. Ces sources (qui deviennent des couches dans le langage JMap) sont ensuite regroupées en Projet. Finalement, la configuration des cubes permet de définir leurs composantes (i.e. lier les dimensions, la table de fait et déterminer les mesures). De nouvelles mesures (dites calculées) peuvent également être créées. 28 Développement de technologies géospatiales Livrable 2

30 Le tableau qui suit présente sommairement les étapes suivies ainsi que le temps et la complexité qui leurs sont associés (Tableau 2). Tableau 2. Sommaire des étapes suivies ÉTAPE OUTIL UTILISÉ TEMPS COMPLEXITÉ Inv. de données Recherche et inventaire de données spatiales et descriptives Internet et géorépertoires ½ journée Peu élevée Modélisation Conception des modèles conceptuels de chaque cube Conception des modèles d implantation de chaque cube Perceptory Perceptory 1 journée 0.5 journée Peu élevée Peu élevée Extraction, nettoyage et transformation des données géométriques ArcGIS/FME 1.5 journée Moyennement élevée ETL Création et peuplement de la base de données détaillées ACCESS 0.5 journée Élevée Création de la structure de chaque cube, peuplement des données détaillées (import de Access) et création de la table de faits temporaire nécessaire aux calculs d agrégation de SAS ORACLE (scripts sql, et SQLLoader) 2 heures Peu élevée Création du programme VB qui crée les lignes de commandes à être exécutées dans SAS Visual Basic 0.5 journée Moyennement élevée ETL (SOLAP) Création des agrégations par SAS et leur importation dans la table de faits originale SAS Quelques minutes Nulle (automatique) Création des index sur les identifiants des dimensions dans la table de faits ORACLE (scripts sql) Quelques minutes Peu élevée Configuration des vues SOLAP Définition des paramètres de chaque cube via l administrateur JMAP SOLAP JMap SOLAP Administrator 2 heures Peu élevée Développement de technologies géospatiales Livrable 2 29

31 6.3 Considérations et nuances Recherche et inventaire de données spatiales et descriptives En général, cette étape ne consiste qu en l inventaire des données puisque les données sources sont normalement existantes dans les systèmes transactionnels. Le temps requis pour cette étape est très variable et dépend notamment du nombre et de la complexité des systèmes sources. Il en va de même pour la complexité de cette étape. Création et peuplement de la base de données détaillées Tel que mentionné précédemment, les données détaillées auraient très bien pu être créées directement dans Oracle. L utilisation d Access dans le cas présent se justifie uniquement par sa facilité de manipulation. La complexité élevée de cette étape est associée au peuplement de la table de faits et n est pas uniquement applicable à ce projet. En règle générale, il est rare de disposer a priori de cette table; les données existent, mais elles ne sont pas sous forme de faits. Création du programme VB qui crée les lignes de commandes à être exécutées dans SAS D une manière générale, le programme pour créer ce fichier de commande est relativement simple. Il peut devenir toutefois complexe lorsque certaines subtilités doivent être prises en compte lors de l agrégation. Par exemple, certaines valeurs peuvent ne pas s agréger à tous les niveaux, d autres peuvent devoir être ajoutées à partir d un niveau spécifique, etc. Il est donc important, à ce niveau, de bien maîtriser la signification et la portée des agrégations. Création des agrégations par SAS et leur importation dans la table de faits originale Les temps de traitements SAS varient en fonction de la taille de la base de données détaillées et du nombre d agrégations. Dans le cas présent, quelques minutes ont suffi. Toutefois, il n est pas rare d avoir des temps de traitements de quelques jours. À titre d exemple, un projet précédent a nécessité 10 jours de traitements pour un volume d environ occurrences (13 Go de données) [Proulx et al., 2006]. 6.4 Volume de données et temps de traitements Tel que mentionné précédemment, les architectures ROLAP requièrent que toutes les agrégations soient calculées et stockées dans la base de données. Évidemment, le volume de données est significativement plus important que celui des architectures MOLAP ou HOLAP. Il est possible d estimer rapidement le nombre d agrégations à stocker en multipliant simplement le nombre de niveaux (incluant le niveau «Tous») par dimension. Ainsi, une application ayant 4 dimensions avec 3 niveaux par dimension génèrera 34 agrégations (i.e. 81 agrégations). Le nombre de combinaisons de données détaillées peut également être estimé (théoriquement) en multipliant la somme des membres du niveau détaillé de chaque dimension [Proulx & Bédard, 30 Développement de technologies géospatiales Livrable 2

32 2004]. En pratique, il est plutôt rare d atteindre ce nombre puisqu il n existe pas toujours de valeur pour chaque combinaison possible. Comparativement à une architecture MOLAP, l architecture ROLAP peut nécessiter jusqu à 80% plus d espace disque pour les mêmes agrégations. Ceci s explique par le fait que sont associés à la structure MOLAP de puissants algorithmes de compression de données. De plus, certaines optimisations sont possibles afin de ne stocker qu une partie des agrégations, le reste étant calculé à la volée. Les temps de calcul des agrégations pour une architecture ROLAP sont évidemment fonction du nombre de membres par dimension mais surtout du nombre d agrégations à calculer. Il est par conséquent pratiquement impossible à déterminer de manière générique. Dans le cadre du cube Planification, 360 agrégations ont été calculées (2 (temps) X 2 (population) X 3 (âge) X 3 (réseau électrique) X 2 (type de bâtiment) X 5 (découpage)). Le temps de calcul est d environ 3 minutes. Quant au volume de données, la table de faits complète (i.e. donnée détaillées et agrégées) est d environ 36 fois plus volumineuse que la table de faits initiale (i.e. données détaillées seulement). Sa taille est de 2.66 Go comparativement à 75 Mo pour la table initiale. Dans le cadre du cube Analyse, 240 agrégations on été calculées (3 (temps) X 5 (découpage) X 2 (type bâtiment) X 2 (fonction) X 2 (secours) X 2 (équipement)). La taille de la table de faits avant agrégation est de 55 Mo alors que celle après agrégation est de 535 Mo. Le temps de calcul des agrégations est d environ 2 minutes. Comme complément d information, le lecteur est invité à consulter [Proulx & Bédard, 2004] qui compare les approches transactionnelle et multidimensionnelle autant d un point de vue théorique que pratique. Les architectures ROLAP et MOLAP sont également comparées via une implantation concrète d un même sujet d étude. Les bases de données résultantes sont finalement exploitées par un SIG et par un outil SOLAP afin de faire ressortir la facilité et la rapidité avec lesquelles les outils SOLAP supportent le processus de prise de décision. Développement de technologies géospatiales Livrable 2 31

33 7. Le cube Planification et ses possibilités d analyse Le cube planification a été développé en vue d analyser le profil d un secteur géographique par rapport à différents critères démographiques (type de population, âge). De manière simple, il permet l analyse de la répartition de la population à partir des régions administratives jusqu aux bâtiments (figures 19 et 20). Par ailleurs, il permet des analyses plus poussées en combinant notamment les dimensions type de population et classe d âge à la dimension découpage pour avoir un portrait démographique d une ou plusieurs régions (figures 21 et 22). En modifiant la mesure analysée, il est également possible d analyser la relation entre les bâtiments et le réseau électrique (combien de bâtiments sont affectés par une ligne électrique donnée, combien d arrondissements dessert la ligne électrique X, etc.) Finalement, en combinant tout ceci, il est possible d obtenir un portrait complet sur les bâtiments (nombre et type), leurs occupants (nombre de personnes, type de population, classe d âge) et leur lien avec le réseau électrique. À noter que ce cube ne présente que des données (simulées) pour l année Voici une brève liste d interrogations auxquelles l analyse de ce cube peut répondre : Quels sont les arrondissements avec le plus fort taux de personnes âgées et dont la condition de santé est mauvaise (ex. mobilité réduite)? Où sont situés les CHSLD qui accueillent plus de 10 personnes dans la région de Montréal? Quel est le nombre de bâtiments et leur type qui sont reliés aux lignes électriques dont la tension est de 120 kv. Si une panne se produisait sur la ligne à 120 kv no 1117, combien d hôpitaux en seraient affectés? Quel est le nombre de bâtiments qui peuvent potentiellement accueillir des sinistrés, par MRC? 32 Développement de technologies géospatiales Livrable 2

34 Figure 19. Répartition de la population selon des vues tabulaire, graphique et cartographique À partir de la carte représentant la répartition de la population au niveau des municipalités, il est facile de naviguer jusqu aux niveaux des bâtiments en utilisant la fonction de forage spatial. Figure 20. Analyse de la répartition de la population à différents niveaux de détail Développement de technologies géospatiales Livrable 2 33

35 En ajoutant les dimensions Type de population et Classe d âge, il est possible d obtenir un portrait plus précis d un certain type de population. La figure suivante présente le nombre de personnes âgées de 70 ans et plus, à mobilité réduite versus en santé (autre), par arrondissement. Le graphique en camembert qui lui succède illustre le même phénomène mais pour un arrondissement en particulier (Figure 22). Figure 21. Nb. de personnes par groupe d âge, par type de population et par arrondissement Figure 22. Graphique de la population par groupe d âge, par type de population, pour l arrondissement Le Plateau Mont-Royal 34 Développement de technologies géospatiales Livrable 2

36 Ce cube permet également d analyser les bâtiments relativement à leur affectation au réseau électrique. Chaque bâtiment étant relié à une ligne électrique particulière, il est possible de connaître par exemple, le nombre de bâtiments, et leur localisation, qui sont reliés à une ligne en particulier (figures 23 et 24). Figure 23. Analyse du nombre de bâtiments par type, par arrondissement, qui sont reliés à des lignes à 120kV et 315 kv Développement de technologies géospatiales Livrable 2 35

37 Figure 24. Cartographie des bâtiments reliés à la ligne d électricité Développement de technologies géospatiales Livrable 2

38 8. Le cube Analyse et ses possibilités d analyse Le cube Analyse permet d explorer différentes données (simulées) relativement à la tempête de verglas ayant touché le Québec en janvier Les principales analyses portent sur le type de secours (militaire, médical, policier, etc.) ainsi que les équipements de secours (chauffage d appoint, génératrice, lit de camps, etc.) déployés lors de cette crise. D envergure beaucoup plus significative au départ, la portée du cube a dû être limitée, notamment en réduisant son nombre de dimensions. Cette limitation a été nécessaire afin de faciliter et surtout d accélérer les traitements nécessaires à la création du cube (voir section 10 pour les détails). Dans sa forme finale, le cube permet notamment de : Déterminer les bâtiments ayant servi de centre d hébergement ainsi que le nombre de personnes hébergées, par jour, pour la région de Montréal ou ses arrondissements. Déterminer le nombre de bâtiments (ou de personnes) ayant eu recours à un secours militaire ainsi que les équipements de secours utilisés pour la région de Montréal ou ses arrondissements. Identifier et cartographier les arrondissements pour lesquels il y a eu une intervention médicale pour la période du 5 au 9 janvier. etc. À l ouverture du cube, un premier tableau permet de déterminer le nombre de bâtiments situés dans la région de Montréal (affichage par défaut). Un forage sur la dimension Type de secours (présent en colonne) permet de catégoriser ce nombre en fonction du type de secours déployés. Un second forage, cette fois sur la dimension Découpage, permet finalement d analyser le nombre de bâtiments selon le type de secours pour chaque arrondissement de la ville de Montréal. Développement de technologies géospatiales Livrable 2 37

39 Figure 25. Exemple d analyse via le cube Verglas-Analyse Il est ensuite possible d obtenir une carte à partir du tableau des arrondissements de la figure précédente. Un simple forage sur un arrondissement en particulier permet de localier les bâtiments où une intervention militaire a eu lieu (Error! Reference source not found.). Figure 26. Localisation des bâtiments où une intervention militaire a eu lieu 38 Développement de technologies géospatiales Livrable 2

40 Finalement, la figure suivante illustre l analyse du type d équipements déployés par un secours militaire selon le type de bâtiments. Figure 27. Analyse du type d équipement par type de bâtiment déployé par un secours militaire Développement de technologies géospatiales Livrable 2 39

41 9. Gestion des métadonnées À l instar des applications transactionnelles, les applications multidimensionnelles doivent également prévoir la gestion des métadonnées afin de documenter adéquatement les données descriptives et spatiales qu elles exploitent. Globalement, un référentiel de métadonnées peut être simplement défini selon 4 composantes (Proulx et al., 2006; Marco, 2000). 1. Les métadonnées de gestion 2. les métadonnées techniques a. métadonnées d objets b. métadonnées ETL c. métadonnées OLAP Les métadonnées de gestion permettent de comprendre la signification des données et soutiennent l analyse des données (p. ex. : coordonnées de la personne responsable et du propriétaire des données, date de création, fréquence de mises à jour). Les métadonnées techniques réfèrent au développement et à la maintenance de l entrepôt de données et sont destinées aux usagers techniques. Elles comprennent les métadonnées d entités, les métadonnées ETL et les métadonnées OLAP. Les métadonnées d objets contiennent les informations sur le modèle de données de l'entrepôt et fournit les informations au niveau des tables et des attributs. La source de données de ces métadonnées est le dictionnaire de données du SGBD sur lequel est déployé l'entrepôt. Les métadonnées ETL contiennent les traitements effectués sur les tables et les sources de données lors de l'extraction, transformation et peuplement de l'entrepôt ou le chargement et le traitement des données pour la création des comptoirs de données et des vues de données (S)OLAP. Ces métadonnées peuvent être gérées en utilisant le modèle ISO Lineage, présenté à l annexe 3. Finalement, les métadonnées OLAP contiennent les métadonnées sur les objets définis pour l'application (dimensions, cubes) et les transformations appliquées sur les données d'analyses (calculs) propres à une application OLAP. MÉTADONNÉES SOLAP Plus tôt cette année (janvier 2006), l équipe du Dr Bédard a été mandatée afin d analyser les métadonnées nécessaires à la description d une application SOLAP pour le compte du ministère des Transports du Québec [Proulx et al., 2006]. Le rapport qui en découle propose de nouvelles métadonnées qui devraient accompagnées toute application SOLAP. Celles-ci sont présentées au tableau suivant (Tableau 1). 40 Développement de technologies géospatiales Livrable 2

42 «Aucune proposition connue n'est encore officialisée pour la définition de métadonnées OLAP. La présente proposition est donc basée sur une compilation de connaissances sur les référentiels de métadonnées, les méta-modèles d'entrepôt et les API d'application OLAP référencés à l'annexe B. Un consensus est toutefois donné autour des concepts du Common Warehouse Metamodel (CWM) proposé par l'omg qui traite le volet des métadonnées OLAP. Cette proposition est donc fortement inspirée du contenu du CWM-OLAP.» Tableau 3. Métadonnées SOLAP Métadonnées Base de données : Nom de la base de données : Identifiant : Description : Statut : Type de base de données : Pilote : Adresse : Nom d utilisateur : Requête de validation : Cube : Nom du cube : Description : Identifiant : Date de création : Date de dernière mise à jour : Type SOLAP : Définitions Une base de données supporte un ensemble d éléments SOLAP implantés dans le système (cubes et/ou dimensions). Nom de la base de données SOLAP. Numéro identifiant la base de données. Courte description du contenu ou du domaine d'utilisation de la base de données SOLAP. Indique le statut de la base de données (connectée, en erreur). Indique la technologie supportant la base de données. Pilote utilisé pour l accès à la base de données. Adresse URL pour la connexion à la base de données. Nom d utilisateur pour la connexion à la base de données. Requête de validation utilisée pour vérifier la connexion. Un Cube est une collection de valeurs analytiques; c'est-à-dire les mesures qui partagent les mêmes dimensions. Nom du cube. Courte description du cube. Numéro unique identifiant le cube. Date de création du cube. Date de dernier chargement des dimensions du cube. Domaine : ROLAP/MOLAP/HOLAP Type d'implantation du cube. Développement de technologies géospatiales Livrable 2 41