CONCEPTION ET DÉVELOPPEMENT D UN SERVICE WEB DE CONSTITUTION DE MINI CUBES SOLAP POUR CLIENTS MOBILES

ETIENNE DUBÉ CONCEPTION ET DÉVELOPPEMENT D UN SERVICE WEB DE CONSTITUTION DE MINI CUBES SOLAP POUR CLIENTS MOBILES Mémoire présenté à la Faculté des études supérieures de l Université Laval dans le cadre du programme de maîtrise en sciences géomatiques pour l obtention du grade de Maître ès sciences (M.Sc.) DÉPARTEMENT DES SCIENCES GÉOMATIQUES FACULTÉ DE FORESTERIE ET DE GÉOMATIQUE UNIVERSITÉ LAVAL QUÉBEC 2008 c Etienne Dubé, 2008

Résumé Les applications d aide à la décision spatiale telles que SOLAP (Spatial OLAP) sont traditionnellement conçues pour les environnements informatiques de bureau. L adaptation des applications SOLAP aux contextes d utilisation mobile (e.g. PDA et téléphones mobiles) pose certains problèmes dus à la nature et aux contraintes de ces environnements. Ce projet de recherche vise à apporter une solution, basée sur une architecture orientée services (SOA), pour l adaptation des cubes de données SOLAP aux environnements mobiles. Il s agit d un service Web capable de transformer les cubes SOLAP des entrepôts de données géo-décisionnelles en mini-cubes de taille réduite, adaptés aux clients mobiles. Le service permet de sélectionner un sous-ensemble des cubes existants par l intermédiaire d opérateurs paramétrables, d appliquer des traitements de simplification aux membres spatiaux, et finalement de transmettre ces données en format XML. Ce travail de recherche ouvre donc la voie à la conception et au développement de nouvelles applications géospatiales décisionnelles mobiles.

Abstract Decision support systems such as SOLAP (Spatial OLAP) have been originally designed as desktop applications. Adapting SOLAP applications to mobility contexts (e.g. using PDAs and mobile phones) pose some challenges due to the constraints of these environments. This research projects aims to provide a solution, based on a Service Oriented Architecture (SOA), for adapting SOLAP data cubes to mobile environments. It consists of a Web service which is capable of transforming SOLAP cubes from spatial data warehouses, in order to create mini-cubes of reduced size, suitable for mobile clients. This service allows selecting a subset of existing cubes (using parameterizable operators), applying simplification algorithms to spatial members, and finally transfering the data in an XML format. This research opens the way to the design and development of new geospatial decisional mobile applications.

Avant-propos Ce mémoire avec insertion d articles comporte deux publications, qui ont été soumises, acceptées et présentées dans le cadre de conférences avec comité de lecture et publiées dans les actes des conférences. Ces articles constituent le corps des chapitres 2 et 3. L étudiant (Etienne Dubé) ayant rédigé le mémoire est également l auteur principal des deux articles, et fut responsable de leur rédaction, de leur soumission pour les conférences ainsi que de leur présentation devant public lors des conférences. Les coauteurs des articles, Thierry Badard et Yvan Bédard, sont respectivement le directeur et le codirecteur de ce projet de maîtrise ; leur rôle dans la rédaction des articles fut d apporter des conseils pour la recherche et la rédaction, de faire une lecture avant la soumission des articles, ainsi que de proposer des corrections et améliorations aux textes. Le texte des articles est présenté de manière intégrale dans le mémoire. Quelques modifications mineures ont été apportées, pour ajuster le texte à la mise en page du mémoire (mise en forme, modification de la numérotation des sections, format des citations et de la bibliographie, changement de quelques termes pour l appel des figures et les renvois). Autrement, le contenu est identique à ce qu on retrouve dans la version ayant fait l objet d une publication. Les articles insérés sont les suivants : Article du chapitre 2 : Dubé, E., T. Badard et Y. Bédard. 2007, «Service Web de constitution en temps réel de mini-cubes SOLAP pour clients mobiles Une architecture orientée services pour l utilisation mobile des données géo-décisionnelles», dans SAGEO 2007, Rencontres internationales Géomatique et territoire (CD-ROM), Clermont-Ferrand, France, ISBN 978-2-85710-078-2. Auteurs : Etienne Dubé, Thierry Badard, Yvan Bédard

v Résumé : Les applications Spatial OLAP (SOLAP) réalisées jusqu à présent sont conçues pour les environnements informatiques de bureau. Dans le but de supporter l aide à la décision géospatiale en situation de mobilité, certaines adaptations à SOLAP sont nécessaires. Cet article décrit une solution, basée sur les architectures orientées services et les technologies des services Web, pour adapter les cubes de données SOLAP afin de répondre aux exigences et contraintes reliées aux environnements informatiques mobiles et aux réseaux sans-fil. Article du chapitre 3 : Dubé, E., T. Badard et Y. Bédard. 2008, «An interoperable XML encoding for the exchange of Spatial OLAP data cubes in SOA environments», dans 31st International Convention MIPRO on Business Intelligence Systems (miprobis), Opatija, Croatie. Auteurs : Etienne Dubé, Thierry Badard, Yvan Bédard Résumé : Les technologies de XML et des services Web ont révolutionné la manière dont les données sont échangées sur Internet. Entre temps, les outils Spatial OLAP (SO- LAP) ont fait leur apparition, réunissant les domaines de l informatique décisionnelle (Business Intelligence) et des systèmes d information géographiques (SIG). Bien que des spécifications de services Web telles que XML for Analysis permettent l utilisation d outils OLAP dans des architectures orientées services (SOA Service Oriented Architecture), il n existe aucune solution permettant l échange de cubes SOLAP complets (contenant les données et métadonnées pour les entités spatiales et descriptives) d une manière interopérable. Cet article propose un nouvel encodage XML pour l échange de cubes de données SOLAP, contenant les données et métadonnées spatiales et descriptives. Cela permet la livraison du schéma du cube, des membres de dimensions (incluant la géométrie des membres spatiaux) et des faits. Ce format XML peut être utilisé dans le développement de services Web pouvant être déployés dans différentes situations, ne se limitant pas aux plateformes client-serveur traditionnelles mais également aux environnements d informatique mobile et ubiquitaire.

Remerciements Ce projet de recherche a été mené grâce à la collaboration et au financement de la Chaire de recherche industrielle CRSNG en bases de données géospatiales décisionnelles 1, dirigée par le professeur Yvan Bédard. Il a aussi bénéficié du programme de bourses d études de Géomatique Canada 2. Je tiens à remercier ces deux organismes pour leur soutien financier. Merci également au professeur Thierry Badard pour sa contribution au financement. Je remercie mon directeur, Thierry Badard, avec qui j ai eu la chance de travailler tout au long de ma maîtrise, pour son expertise, pour la grande confiance qu il m a accordée et pour la latitude dont j ai pu bénéficier pour mener à terme ce travail. Ce climat de travail m a donné l occasion d élargir mes horizons et de développer un nombre de technologies qui vont bien au delà de ce mémoire. Merci également pour m avoir donné l opportunité de présenter nos travaux dans des conférences, au pays et à l étranger. Mes remerciements vont également à l égard du professeur Yvan Bédard, qui outre son implication dans le financement de ce projet par l intermédiaire de la Chaire, a accepté de codiriger mes études. J ai grandement apprécié son point de vue apporté à mes travaux, marqué par ses années d expérience dans le domaine de la recherche. Merci au professeur Omar Boussaïd, de l Université Lumière Lyon 2 (France), pour avoir accepté d être examinateur externe de mon mémoire. J aimerais aussi souligner mon appréciation aux professionnels de recherche de la Chaire, soit Eveline, Frédéric (maintenant professeur au Département), Martin, Marie- Josée, Sonia et Suzie, pour leur assistance et les échanges fructueux en lien avec ce projet. Merci également à Carmen Couture, agente de gestion des études graduées au département des sciences géomatiques, pour ses conseils et son aide. 1 http://mdspatialdb.chair.scg.ulaval.ca/ 2 http://www.cig-acsg.ca

vii J adresse un merci à mes collègues étudiants avec qui j ai partagé de bons moments, entre autres à Benoît, Charlotte, Christophe, Eve, Karl, Marie-Andrée, Mathieu, Rosemarie, Véronique, ainsi qu aux autres étudiantes et étudiants de la Chaire et du CRG. Merci aussi à ceux et celles qui se sont impliqués dans l AGREGE, ce qui a rendu notre passage au département d autant plus agréable. Mes bonnes grâces vont également envers mes colocataires, Maryse, Marjolaine et Pierre-Luc, avec qui j ai partagé mon espace vital ainsi que de nombreuses bières au cours des dernières années. Merci à mes parents, Gaétane et Gérald, pour avoir su dès ma tendre enfance instiller en moi un grand sens de la curiosité. Enfin, je tiens à exprimer toute ma reconnaissance à mon amoureuse, Geneviève Meunier, pour avoir vécu avec moi les joies et les peines des études graduées. Je suis quelqu un de privilégié par ta présence ; ton soutien et ton réconfort furent d une valeur inestimable pour moi.

Table des matières Résumé Abstract Avant-propos Remerciements Table des matières Table des figures Liste des tableaux ii iii iv vi viii xiii xiv 1 Introduction 1 1.1 Contexte................................... 1 1.2 État de l art................................. 3 1.2.1 Informatique décisionnelle, OLAP et SOLAP........... 3 1.2.1.1 Systèmes opérationnels et analytiques......... 3 1.2.1.2 OLAP On-Line Analytical Processing........ 4 1.2.1.3 Spatial OLAP (SOLAP)................. 10 1.2.2 Mobilité en informatique...................... 11 1.2.2.1 Types de plateformes mobiles.............. 12 1.2.2.2 Contraintes de mobilité................. 13 1.2.2.3 Architecture logicielle des plateformes mobiles..... 15 1.2.2.4 Architecture orientée services et environnements mobiles 18 1.2.2.5 Mobilité et géomatique.................. 19 1.2.2.6 Mobilité et OLAP.................... 21 1.2.3 Services Web et architecture orientée services (SOA)...... 22 1.2.3.1 Systèmes répartis, Internet et intergiciels........ 22 1.2.3.2 Services Web....................... 23 1.2.3.3 Architecture orientée services.............. 26

Table des matières ix 1.2.4 Applications des services Web: géomatique et informatique décisionnelle............................... 28 1.2.4.1 Les services Web en géomatique............. 28 1.2.4.2 Services Web pour OLAP................ 29 1.2.4.3 Les services Web en géomatique décisionnelle..... 30 1.3 Problématique................................ 31 1.4 Objectifs................................... 33 1.4.1 Objectif général........................... 33 1.4.2 Objectifs spécifiques........................ 33 1.5 Méthodologie................................ 33 1.6 Structure du document........................... 36 2 Définition des requis et de l architecture du système 38 2.1 Introduction................................. 38 2.1.1 Contributions............................ 39 2.2 Corps de l article.............................. 40 2.2.1 Introduction............................. 40 2.2.2 Concepts et problématique..................... 42 2.2.2.1 Concepts d OLAP et des entrepôts de données décisionnelles........................... 42 2.2.2.2 Spatial OLAP: d un environnement sédentaire jusqu à la mobilité......................... 43 2.2.2.3 Principes des architectures orientées services et des services Web......................... 45 2.2.3 Proposition d une architecture pour le service Web....... 47 2.2.3.1 Cas d utilisation: invocation du service......... 47 2.2.3.2 Construction d un mini-cube: principes conceptuels.. 49 2.2.3.3 Architecture du service.................. 52 2.2.4 Réalisation d un prototype..................... 54 2.2.5 Conclusion.............................. 56 2.2.6 Remerciements........................... 56 2.2.7 Bibliographie partielle (pour l article seulement)......... 57 2.3 Compléments à l article........................... 60 2.3.1 SOLAP et mobilité......................... 60 2.3.1.1 Contraintes de mobilité: comment y palier?...... 60 2.3.1.2 Rôles du service Web................... 62 2.3.2 Métamodèle pour cubes SOLAP.................. 63 2.3.3 Opérateurs de constitution de mini-cubes: approfondissement.. 66 2.3.3.1 Opérateurs de sélection de membres.......... 67 2.3.3.2 Opérateurs de sélection de cellules........... 69 2.3.4 Problèmes liés aux opérateurs de constitution de mini-cubes.. 71

Table des matières x 2.3.4.1 Changement de la définition des membres....... 71 2.3.4.2 Hiérarchies multiples................... 74 2.3.4.3 Simplification géométrique................ 75 2.3.5 Infrastructure technologique SOLAP et diffusion aux mobiles.. 76 2.3.5.1 Service basé sur un outil ETL: failles de l approche.. 77 2.3.5.2 Service basé sur un serveur OLAP........... 78 2.4 Conclusion.................................. 79 3 Encodage XML pour cubes SOLAP et contrat de service 81 3.1 Contributions................................ 81 3.2 Corps de l article.............................. 83 3.2.1 Introduction............................. 84 3.2.2 Requirements for a SOLAP data cube XML format....... 85 3.2.2.1 Representation of both data (facts and members) and metadata (schema).................... 86 3.2.2.2 Based on existing standards............... 86 3.2.2.3 Be independent of particular implementations in OLAP and GIS products..................... 87 3.2.2.4 Support for spatial dimensions and spatial members. 87 3.2.2.5 Support of shared dimensions.............. 87 3.2.2.6 Describing calculated measures and members..... 88 3.2.2.7 Separation of contents and presentation........ 88 3.2.3 Specification of the XML encoding................ 88 3.2.3.1 CubeSchema document.................. 89 3.2.3.2 CubeMembers document................. 91 3.2.3.3 CubeCells document................... 93 3.2.3.4 Relevance of the encoding for spatial data and SOA.. 94 3.2.4 Example of an implementation................... 95 3.2.5 Conclusion and outlooks...................... 96 3.2.6 Acknowledgments.......................... 97 3.2.7 References (for the paper only).................. 97 3.3 Compléments à l article........................... 100 3.3.1 Contrat de service et opérations.................. 100 3.3.1.1 Retour sur WSDL.................... 100 3.3.1.2 Opération GetCapabilities................ 102 3.3.1.3 Opération DescribeSchema............... 103 3.3.1.4 Opération GetMembers................. 104 3.3.1.5 Opération GetCells.................... 108 3.3.1.6 Opération GetCube................... 111 3.3.2 Considérations par rapport aux contraintes de mobilité..... 113 3.3.2.1 Format de données spatiales............... 113

Table des matières xi 3.3.2.2 Verbosité de l encodage XML.............. 114 3.3.2.3 Utilisation des données XML par le client....... 116 3.4 Conclusion.................................. 119 4 Réalisation d un prototype 120 4.1 Choix technologiques............................ 120 4.1.1 Langage de programmation.................... 121 4.1.2 Outil ETL.............................. 122 4.1.3 Moteur OLAP............................ 123 4.1.4 Système de gestion de bases de données relationnel....... 125 4.1.5 Cadre de développement géomatique............... 126 4.1.6 Cadre de développement pour services Web........... 126 4.1.7 Autres outils............................ 127 4.1.8 Jeu de données pour tests..................... 127 4.2 Architecture du système.......................... 129 4.2.1 Architecture générale du système................. 129 4.2.1.1 Systèmes sources..................... 131 4.2.1.2 Procédures ETL..................... 131 4.2.1.3 Entrepôt de données (SGBDR)............. 131 4.2.1.4 Serveur OLAP...................... 132 4.2.1.5 Service Web de constitution de mini-cubes....... 132 4.2.1.6 Clients (mobiles ou autres)............... 132 4.2.2 Architecture détaillée du service Web............... 133 4.2.2.1 Couche d abstraction des objets OLAP......... 133 4.2.2.2 Générateur de requêtes MDX.............. 134 4.2.2.3 Sérialisation XML des objets OLAP.......... 135 4.2.2.4 Couche applicative du service Web........... 135 4.2.2.5 Client pour tests..................... 136 4.3 Tests du service............................... 136 4.3.1 Configuration de l environnement de test............. 136 4.3.2 Tests de performance........................ 137 4.3.2.1 Requêtes effectuées.................... 137 4.3.2.2 Résultats des tests.................... 138 4.3.2.3 Interprétation des résultats............... 139 4.3.3 Compression des données...................... 140 4.3.4 Validation et autres tests...................... 141 4.4 Limites du prototype............................ 141 4.4.1 Opération GetCube......................... 141 4.4.2 Éléments de l encodage XML pour cubes SOLAP........ 142 4.5 Conclusion.................................. 142

Table des matières xii 5 Conclusion et perspectives 144 5.1 Conclusion.................................. 144 5.2 Contributions................................ 146 5.2.1 Encodage XML pour cubes SOLAP et contrat de service.... 146 5.2.2 Outils logiciels pour la géomatique décisionnelle......... 146 5.2.2.1 GeoKettle......................... 147 5.2.2.2 GeoMondrian....................... 147 5.3 Perspectives................................. 149 5.3.1 Services Web auxiliaires pour clients SOLAP mobiles...... 149 5.3.2 Travaux de recherche en géomatique décisionnelle mobile.... 149 Bibliographie 151 A Listages et exemples 159 A.1 Exemples WSDL et SOAP......................... 159 A.2 Définitions XML Schema et WSDL.................... 160 A.2.1 Schéma de l encodage XML pour cubes SOLAP......... 160 A.2.2 Contrat de service du service Web de constitution de mini-cubes 167 A.2.3 Exemples de requêtes et réponses................. 177 A.2.3.1 Opération GetCapabilities................ 177 A.2.3.2 Opération DescribeSchema............... 178 A.2.3.3 Opération GetMembers................. 180 A.2.3.4 Opération GetCells.................... 186 A.3 Configuration et tests du prototype.................... 188

Table des figures 1.1 Mobilité et systèmes géo-décisionnels................... 2 1.2 Application mobile autonome....................... 15 1.3 Application mobile autonome avec synchronisation........... 16 1.4 Architecture avec client mobile lourd................... 17 1.5 Architecture avec client mobile léger................... 18 1.6 Phases du projet.............................. 34 2.1 Mécanisme d invocation du service Web.................. 48 2.2 Schéma du cube (formalisme UML multidimensionnel de Bédard et al. [2006]).................................... 50 2.3 Architecture du prototype de service Web................ 55 2.4 Métamodèle de cube SOLAP........................ 64 2.5 Schéma conceptuel partiel du cube SOLAP «Recensement»...... 67 2.6 Opérateur «Inclusion de membres et de leurs descendants»...... 69 2.7 Opérateur «Agrégation sur un ou plusieurs membres»......... 70 2.8 Opérateur «Réduction de dimension».................. 71 2.9 Opérateur «Inclusion de membre et de leurs descendants» avec hiérarchies multiples................................ 74 2.10 Résultat de l application naïve d un algorithme de simplification géométrique.................................... 76 3.1 Architecture of the Web service for SOLAP mini-cube delivery..... 96 3.2 Conversion XML vers OLAP sur l appareil mobile............ 117 3.3 Mise en œuvre d adaptateurs de conversion XML vers OLAP...... 119 4.1 Schéma du cube SOLAP «Recensement»................ 128 4.2 Schéma d implantation de l entrepôt de données de test......... 130 4.3 Architecture générale du système..................... 131

Liste des tableaux 4.1 Configuration matérielle de l environnement de test........... 136 4.2 Configuration logicielle de l environnement de test............ 137 4.3 Temps d exécution des requêtes de test.................. 139 4.4 Résultats de la compression des messages de réponse.......... 140

Chapitre 1 Introduction 1.1 Contexte Depuis quelques années, on assiste à une percée de l informatique mobile. Grâce aux appareils tels que les ordinateurs portatifs, les téléphones mobiles, les assistants numériques personnels (PDA Personal Digital Assistant) ainsi qu aux réseaux cellulaires numériques et informatiques sans-fil, le concept d informatique ubiquitaire, i.e. en tout lieu et en tout temps, est désormais réalité. Dans le domaine de la géomatique, ces technologies ont donné suite à un nombre important d applications. Outre les produits et services accessibles à un large public, tels que les systèmes de navigation par GPS (Global Positioning System), on retrouve aussi des SIG (systèmes d information géographiques) adaptés aux PDA et autres plateformes mobiles, permettant l exploitation sur le terrain des données à référence spatiale. Néanmoins, tout comme les SIG dans un environnement informatique de bureau, ces logiciels sont peu appropriés pour l analyse exploratoire des données à des fins de prise de décision [Bédard et al., 2005]. Une nouvelle catégorie d outils, dite Spatial OLAP (SOLAP), a été développée à cette fin. SOLAP est basé sur OLAP (On-Line Analytical Processing), provenant du domaine de l informatique décisionnelle (business intelligence), en ajoutant des capacités de gestion des données à référence spatiale et de visualisation cartographique [Rivest et al., 2001]. L avènement de l informatique mobile ouvre la voie à de nouveaux modes d utilisation des technologies géomatiques d aide à la décision. Une utilisation mobile de ces outils comporte deux volets : on peut vouloir enrichir la prise de décision, grâce à l information de mobilité (e.g. position absolue ou relative dans le temps, trajectoire) acquise

Chapitre 1. Introduction 2 Système de positionnement (e.g. GPS) Information de positionnement Lien réseau (sans-fil / cellulaire) Utilisateurs mobiles Données pour aide à la décision Infrastructure technologique (bases de données, services) Fig. 1.1 Mobilité et systèmes géo-décisionnels par les utilisateurs, par l intermédiaire de leurs périphériques mobiles. Par exemple, une compagnie de livraison, dont les camions sont équipés d un système de navigation (récepteur GPS et console), pourrait tirer profit de diverses métriques collectées sur les parcours des véhicules et enrichir les bases de données géospatiales décisionnelles de cette information afin d optimiser les opérations de l entreprise. On parle donc d exploiter la composante de localisation offerte par l environnement informatique mobile. Un second volet concerne le chemin inverse : il s agit de diffuser l information vers les appareils mobiles, afin de supporter la prise de décision sur le terrain. Il est même envisageable de combiner les deux volets dans un seul système intégré, afin que l information de position provenant des utilisateurs nomades soit exploitable en temps réel pour la prise de décision : ainsi, le contexte spatial de l utilisateur vient enrichir en continu l information à laquelle ce dernier a accès (cf. figure 1.1). On peut imaginer l utilité d une telle approche dans les situations d urgences par exemple, où non seulement l information existante peut servir à la prise de décision sur le terrain, mais également où l information de positionnement (absolue et relative) des intervenants prend une importance majeure. De tels systèmes, tenant compte de la position de l utilisateur pour lui fournir une information ou toute autre réponse, sont catégorisés comme étant des services basés sur la localisation (ou LBS Location Based Service) [Steiniger et al., 2006], bien qu au sens large, ce terme englobe toute application mobile qui exploite la notion de positionnement, sans se restreindre uniquement aux systèmes d aide à la décision. Les outils SOLAP, en tant que systèmes d aide à la décision, pourraient s avérer intéressants dans de tels contextes. Toutefois, à l heure actuelle, ils sont conçus pour les environnements informatiques de bureau. D ailleurs, il s agit là de l objectif principal de la chaire de recherche industrielle CRSNG en bases de données géospatiales décision-

Chapitre 1. Introduction 3 nelles qui a financé le présent projet : «Le but, après les cinq premières années de la chaire, est de procurer des solutions permettant un accès facile et rapide à l information géodécisionnelle «partout et en tout temps».» [Bédard, 2007]. Plusieurs adaptations sont nécessaires afin que les outils SOLAP soient utilisables dans un environnement informatique mobile, notamment en ce qui a trait aux interfaces utilisateurs, à la diffusion des cubes de données SOLAP et à l infrastructure technologique supportant ces applications. Ce projet de recherche concerne ces deux derniers points (diffusion des cubes et infrastructure technologique). Les défis de recherche devant être surmontés pour parvenir à une telle solution sont nombreux et concernent plusieurs domaines et technologies : l informatique décisionnelle (business intelligence), les bases de données géospatiales décisionnelles, l informatique mobile ainsi que l architecture orientée services et les services Web. Dans les sections suivantes de ce chapitre, les concepts de ces domaines seront introduits et une revue des travaux de recherche existants sera présentée, afin de mieux cerner la problématique, définir les objectifs à atteindre et élaborer quelques pistes de solution. 1.2 État de l art 1.2.1 Informatique décisionnelle, OLAP et SOLAP 1.2.1.1 Systèmes opérationnels et analytiques Dans l infrastructure informatique des organisations, le fonctionnement des opérations courantes (e.g. ventes, inventaires, commandes et autres processus métiers) s appuient sur des systèmes dits opérationnels. On parle également de systèmes transactionnels ou encore OLTP (On-Line Transactional Processing). Dans ces systèmes, le stockage et l accès aux données font appel aux bases de données relationnelles. Les données y sont organisées dans des schémas normalisés, i.e. qui minimisent la redondance des informations, et qui sont optimisés pour supporter un grand volume de transactions (ajouts et modifications fréquents des données) [O Neil et O Neil, 2001]. Les systèmes d information géographique (SIG) conventionnels font également appel à ce type de bases de données. Il s agit de systèmes opérationnels, puisque les manipulations courantes impliquent généralement l édition des données (ajouts et modifications). Les données transitant dans les systèmes opérationnels peuvent s avérer une véritable mine d or pour les décideurs ; en effet, elles contiennent de l information sur un grand nombre d activités de l organisation. Il y a donc intérêt à effectuer des analyses

Chapitre 1. Introduction 4 de ces données, afin d appuyer la prise de décision. Toutefois, les systèmes opérationnels ne sont pas optimisés pour les applications d analyse. Cela a mené au développement d une nouvelle catégorie de systèmes informationnels, les entrepôts de données (data warehouse en anglais) [Kimball et Ross, 2002]. Ceux-ci mettent en œuvre des modèles de données dénormalisés, c est-à-dire comportant une certaine redondance afin d accélérer les requêtes de type analytique. Les données composant l entrepôt sont puisées à même les systèmes opérationnels. Les données peuvent provenir de plusieurs sources, et sont intégrées, transformées et chargées vers l entrepôt, souvent à l aide d outils ETL (Extract, Transform, Load) [Kimball et Caserta, 2004]. Dans l entrepôt, les données sont fréquemment organisées selon le modèle multidimensionnel, i.e. dans des schémas en étoile, en flocon ou parent-enfant, composés de tables de faits et de dimensions. Plusieurs types d applications sont conçus pour exploiter les données d un entrepôt, par exemple les tableaux de bord (dashboards), la fouille de données (data mining) et les outils OLAP. 1.2.1.2 OLAP On-Line Analytical Processing L acronyme OLAP, pour On-Line Analytical Processing, identifie une catégorie d outils utilisés pour l analyse exploratoire des données, généralement à des fins de prise de décision [Codd et al., 1993; Thomsen, 2002]. Les outils OLAP ont comme notion centrale le cube de données (ou encore hypercube). Il s agit d une structure multidimensionnelle, où les données sont organisées en termes de faits, dimensions et mesures. Les données sont représentées à différents niveaux de détail, en appliquant des fonctions agrégatives pour obtenir des données agrégées (e.g. population par pays) à partir des données détaillées (e.g. population par municipalité). Les applications OLAP présentent une interface conviviale pour la consultation de ces données, et offrent des vues sous forme de tableaux croisés et graphiques. Ils sont également conçus pour offrir un temps de réponse rapide aux requêtes, afin de ne pas nuire au fil de pensée de l analyste lors de l exploration des données. À cette fin, les cubes comportent souvent des données agrégées pré-calculées, ce qui peut accélérer considérablement le traitement des requêtes. Concepts OLAP Certains concepts et termes se rapportant aux éléments constituant un cube OLAP seront utilisés tout au long de ce mémoire. Nous définissons ici ces termes : Cube : structure de données destinées à l analyse, organisées de manière multidimen-

Chapitre 1. Introduction 5 sionnelle et hiérarchique. Un cube est constitué de cellules adressées par des membres disposés sur les dimensions. Un cube n est pas limité à trois dimensions ; il peut en compter un nombre arbitraire. Il ne faut pas non plus confondre les termes «cube» et «entrepôt de données». Les données d un cube sont généralement puisées à même l entrepôt de données 1, mais ce dernier ne présente pas les données selon un vrai modèle multidimensionnel, mais plutôt sous forme relationnelle (relations et tuples). Une surcouche est nécessaire pour présenter les données de l entrepôt sous forme d objets d un modèle multidimensionnel ; en général un moteur OLAP 2 est responsable de cette tâche. Il s occupe d effectuer un mapping relationnel vers multidimensionnel des données de l entrepôt 3, mettant ainsi à disposition des utilisateurs les cubes de données. Dimension : correspond aux différents axes d analyse offerts par le cube. Les dimensions sont des catégories décrivant les thèmes sous lesquels les faits se présentent. L emplacement géographique, le temps, les catégories de produit, les employés d une organisation, les cours d une université sont tous des exemples de thèmes pouvant correspondre à une dimension d un cube. Membre : les instances d entités de la réalité dans les dimensions se nomment membres. Il s agit en autres termes de points sur l axe d analyse que constitue une dimension. Par exemple, une dimension «Limites administratives» peut comporter les membres «Canada», «États-Unis» et «France». La plupart des technologies OLAP du marché permettent également d associer des attributs (ou propriétés) aux membres, outre leur nom. Par exemple, un membre «Supermarché Ste-Foy» de la dimension «Commerce» pourrait comporter des attributs décrivant la superficie du commerce et le nombre d étages ; ces attributs peuvent s avérer utiles pour réaliser certaines analyses (e.g. obtenir le total des ventes pour tous les magasins ayant deux étages ou plus). Niveau : une dimension peut se diviser en plusieurs niveaux, pour modéliser des phénomènes à différentes échelles ou niveaux de détail. Par exemple, une dimension représentant un découpage administratif peut se diviser en niveaux «Pays», «Province», «Région économique» et «Division de recensement» (comté), en 1 Il existe cependant une autre possibilité, dite «architecture sans entrepôt», où les données du cube sont prises à même les sources. 2 Le terme moteur OLAP est utilisé de manière générale pour représenter toute technologie OLAP capable de présenter les données sous un véritable modèle multidimensionnel. Le terme serveur OLAP est plus spécifique, car il dénote une technologie de type client-serveur. Un serveur OLAP comporte à l interne un moteur OLAP. D autres produits OLAP s appuient sur des technologies différentes, e.g. un moteur OLAP embarqué dans une application ou encore un moteur OLAP disponible sous forme de librairie. 3 Ceci est vrai autant pour les technologies ROLAP que MOLAP, puisque les moteurs MOLAP vont également extraire les données depuis un entrepôt pour les placer en stockage dans une structure multidimensionnelle propriétaire. Voir paragraphe «Architectures ROLAP et MOLAP» plus loin dans cette section.

Chapitre 1. Introduction 6 allant du plus général au plus détaillé. Les membres appartiennent à un niveau spécifique (e.g. «Nouveau-Brunswick», «Québec» et «Ontario» appartiennent au niveau «Province»), et peuvent comporter des relations N:1 vers les membres du niveau supérieur (e.g. les trois membres précédents remontent au membre «Canada» du niveau «Pays»). Ces relations sont ce qui permet d agréger les faits, autrement dit faire le calcul d une valeur sommaire à partir des valeurs détaillées. Par exemple, les relations entre les membres des niveaux «Région économique» et «Province» permettent de calculer la population totale des provinces, à partir de la somme des populations des régions économiques appartenant à chaque province. Hiérarchie : certaines dimensions peuvent comporter plus d un ensemble de niveaux permettant de décrire un thème d analyse. Par exemple, on peut décrire le temps selon un découpage jour-semaine ou encore jour-mois-année. On parle alors de hiérarchies multiples ou alternatives. Une dimension peut ainsi comporter plus d une hiérarchie, offrant des chemins différents pour remonter vers les membres de niveau plus général. En règle générale, le niveau le plus détaillé est commun à toutes les hiérarchies à l intérieur d une dimension, puisque ce sont les membres de ce niveau qui définissent le grain de la dimension et par conséquent l adressage des faits détaillés. Fait : il s agit d une unité d information contenant les valeurs des mesures, correspondant au croisement d un membre de chaque dimension. Les liens vers les membres impliqués font également partie du fait. Par exemple, on pourrait énoncer un fait tel que «les ventes du produit «Lait écrémé 2L» pour le supermarché du centre-ville de Québec dans la journée du 21 octobre 2007 sont de 94 unités, pour un montant de 356$.» Dans cet exemple, «Lait écrémé 2L», «supermarché du centre-ville de Québec» et «21 octobre 2007» sont des membres, et «94 unités» et «356$» sont les valeurs pour les mesures «Nombre vendu» et «Montant des ventes». On peut également distinguer les faits détaillés des faits agrégés. Les faits détaillés sont associés à des membres feuilles dans chaque dimension (aux niveaux les plus détaillés). Les valeurs des mesures pour ces faits doivent nécessairement être stockées dans le cube. Les faits agrégés, quant à eux, sont associés au minimum à un membre non-feuille dans au moins une des dimensions (i.e. à un niveau qui n est pas le plus détaillé). Le stockage dans le cube des valeurs de mesures pour les faits agrégés est généralement facultatif, puisque ces valeurs peuvent être calculées à la volée à partir des faits détaillés. Cependant, il est possible de stocker un sous-ensemble ou la totalité des valeurs des faits agrégés, afin d accélérer le traitement des requêtes ou par nécessité selon la technologie du moteur OLAP utilisé (s il ne supporte pas le calcul à la volée des faits agrégés). Les concepts de fait et de mesure sont parfois considérés comme équivalents dans la littérature. Cependant, dans ce mémoire, nous attribuerons une définition spé-

Chapitre 1. Introduction 7 cifique au terme mesure, différente de celle du terme fait (voir définition suivante). Mesure : dans le cadre de ce texte, nous définissons une mesure comme étant une variable dans le cube OLAP représentant une réalité observée (mesurée), pour laquelle chaque fait comporte une valeur. Nous tenons ainsi à distinguer le concept de mesure, qui est une variable, de son instance dans un fait, soit les valeurs données à une mesure pour un fait. Les types de données des mesures sont dans la plupart des cas des nombres scalaires (e.g. unités vendues, montant des ventes, population, température) mais il peut également s agir d objets plus complexes (chaînes de caractères, vecteurs, positions géographiques). Dans ce mémoire, le concept de dimension de mesures est parfois mentionné. Il s agit d un artéfact d implantation qu on retrouve dans certains langages d interrogation, notamment MDX 4 [Microsoft Corporation, 2007b], et dans certains produits OLAP. Une dimension de mesures regroupe toutes les mesures du cube, représentées sous forme de membres dont le nom correspond au nom de la mesure. Cette manière de faire se rattache au concept de symétrie entre mesures et dimensions (plus précisément, de «type-varying symmetry» selon Thomsen [1999]). Un avantage de cette approche est de rendre plus uniforme la syntaxe de certaines expressions calculées (membres ou mesures calculées) ; des membres de dimensions ou des mesures peuvent être employées de la même manière dans de telles expressions 5. Dans tous les cas, la dimension de mesures est créée implicitement par le moteur OLAP, à partir des mesures définies dans le cube ; il s agit d une «pseudo-dimension». Cette dimension n apparaît jamais dans le modèle conceptuel du cube, et il n existe pas de table de dimension correspondant aux mesures dans l entrepôt de données. Cellule : nous définissons une cellule d un cube comme le contenant de la valeur d une mesure pour un fait donné. En contraste avec le terme mesure, une cellule fait référence à un emplacement précis dans le cube ; on peut ainsi dire qu il s agit d une mesure positionnée dans l hypercube, au croisement des membres d un fait. Par exemple, la cellule correspondant à la mesure «Montant des ventes» pour le croisement des membres «Lait écrémé 2L», «supermarché du centre-ville de Québec» et «21 octobre 2007» contient la valeur «356$». Conformément au concept de mesure défini plus haut, une cellule peut contenir comme valeur non seulement un nombre scalaire, mais aussi des types d objets plus complexes. 4 Voir «Langages d interrogation OLAP» plus loin dans cette section. 5 Par exemple, en MDX, une expression permettant d obtenir la différences entre les mesures «Population» et «Nombre de décès» s écrirait : «[Measures].[Population]-[Measures].[Nombre de décès]». Une autre expression permettant d obtenir la différence entre les membres représentant les années 2007 et 2006 s écrirait : «[Temps].[2007]-[Temps].[2006]». Dans les deux cas, la syntaxe est semblable, qu il s agisse de mesures ou de membres.

Chapitre 1. Introduction 8 Architectures ROLAP et MOLAP Les produits OLAP offerts sur le marché suivent principalement deux approches en ce qui concerne le stockage de la base de données multidimensionnelle ; il s agit des approches ROLAP et MOLAP [Pendse, 2006]. L acronyme ROLAP (Relational OLAP) dénote un système OLAP où le stockage des données du cube est exclusivement fait dans un système de gestion de bases de données relationnel (SGBDR). Le moteur ROLAP interprète les requêtes de l utilisateur afin de les transformer en requêtes relationnelles (en langage SQL, par exemple) et ainsi interroger directement l entrepôt de données. En général, les données de l entrepôt sont organisées selon le modèle multidimensionnel de Kimball, i.e. sous forme de tables de faits liées à des tables de dimensions (schéma en étoile, en flocon ou parent-enfant). Certains moteurs ROLAP peuvent également tirer parti d agrégations pré-calculées, présentes dans l entrepôt sous forme de tables d agrégations, de vues matérialisées ou encore stockées à même la table de faits dans un schéma unique [Adamson, 2006]. Cela permet de réduire considérablement le temps de réponse aux requêtes concernant des données agrégés. MOLAP, pour Multidimensional OLAP, implique le stockage des données du cube dans une structure multidimensionnelle propriétaire, spécifique à chaque moteur OLAP. Ces structures sont optimisées, compressées et indexées expressément pour les données multidimensionnelles. Dans plusieurs cas, elles offrent une performance supérieure aux technologies ROLAP [Mundy et Thornthwaite, 2006]. Le contenu des cubes MOLAP est généralement extrait à partir d un entrepôt de données relationnel, et rafraîchi lorsqu il y a une mise à jour des données de l entrepôt. Il existe également une approche dite Hybrid OLAP (HOLAP), combinant les technologies ROLAP et MOLAP dans un même moteur OLAP. Dans ce cas, les données détaillées sont stockées dans l entrepôt de données (dans un SGBDR) alors que les données agrégées sont matérialisées dans une structure de type MOLAP. Le moteur OLAP récupère donc les données depuis ces deux sources, afin de répondre aux requêtes des utilisateurs. En pratique, le choix d architecture technologique ROLAP, MOLAP ou HOLAP est une considération de design physique et d implémentation, et ne devrait pas avoir d impact sur la présentation des données du point de vue de l utilisateur. Un exemple se trouve dans le serveur Microsoft SQL Server Analysis Services, qui supporte les architectures ROLAP, MOLAP et HOLAP. Peu importe le choix de technologie de stockage, un seul et même langage d interrogation (MDX) est utilisé et la vue logique

Chapitre 1. Introduction 9 des cubes présentée à l utilisateur est uniforme. Le serveur OLAP agit donc comme une couche de présentation par-dessus l entrepôt 6, et le mécanisme interne de stockage et d interrogation des cubes n est pas visible, du point de vue des applications clientes. Par conséquent, les considérations de modélisation des cubes OLAP et de conception des applications clientes peuvent se faire indépendamment de la technologie de stockage choisie. Les concepts abordés dans le reste de ce mémoire sont ainsi applicables à toute technologie OLAP, qu il s agisse de ROLAP, MOLAP, HOLAP ou encore toute autre variante d architecture OLAP (e.g. cubes construits à même les sources). Langages d interrogation OLAP Tout comme il existe le langage SQL (Structured Query Language) pour interroger les bases de données relationnelles, des langages de requête ont été conçus pour l accès aux cubes de données multidimensionnelles. Certains se présentent comme des extensions à SQL (comme c est le cas pour Oracle Express) alors que d autres sont de nouveaux langages à part entière. C est le cas de MDX (MultiDimensional expressions), introduit par Microsoft en 1998 lors de la sortie de SQL Server OLAP Services (maintenant Analysis Services). MDX a pris la place en tant que standard de facto et est maintenant utilisé par d autres serveurs OLAP (entre autres les produits de SAP 7, MicroStrategy 8 et Pentaho 9 ) ainsi que plusieurs applications clientes (Cognos 10, Business Objects 11, ProClarity 12, etc.) Contrairement à SQL qui présente un résultat de requête sous forme tabulaire (rangées et colonnes), une requête MDX retourne un jeu de données multidimensionnelles. La clause SELECT permet d instancier un ou plusieurs axes (déterminant ainsi la dimensionnalité du résultat). Les cellules retournées dans le résultat sont déterminées en fonction d une sélection de membres sur chaque axe. Il est aussi possible de paramétrer la requête et de définir des mesures calculées, grâce à un ensemble de fonctions opérant sur les membres ou mesures. Pour plus de détails sur la syntaxe de MDX, le lecteur est invité à consulter des références telles que [Microsoft Corporation, 2007b] et [Spofford et al., 2006]. 6 Ceci est dans les cas où l architecture du serveur OLAP s appuie sur un entrepôt de données ; en autres cas il pourrait s agir de cubes construits à même les sources. 7 http://www.sap.com/ 8 http://www.microstrategy.com/ 9 http://www.pentaho.com/ 10 http://www.cognos.com/ 11 http://www.businessobjects.com/ 12 http://proclarity.com/

Chapitre 1. Introduction 10 1.2.1.3 Spatial OLAP (SOLAP) Les outils OLAP classiques sont limités quant à la représentation des données spatiales. Afin de tirer profit de la composante spatiale, une nouvelle catégorie d outils, dits Spatial OLAP (ou SOLAP), a émergé. Ceux-ci, en combinant des fonctionnalités OLAP et SIG, offrent entre autres des vues cartographiques multi-niveaux, synchronisées ou non avec les vues tabulaires et graphiques traditionnelles, et une navigation simple et intuitive à même ces différentes vues. SOLAP introduit certains nouveaux concepts par rapport au modèle multidimensionnel d OLAP : il s agit des dimensions et mesures spatiales. Une dimension spatiale est composée de membres faisant référence à une réalité pouvant être localisée dans l espace, p. ex. un pays, une ville, une adresse postale. Les dimensions spatiales peuvent être de trois types [Han et al., 1998; Miquel et al., 2002] : Dimension spatiale non géométrique : les membres de cette dimension font référence à des entités localisables géographiquement, mais dont on ne fait pas le stockage d une géométrie. Les données représentées sont généralement nominales (ex. noms de lieux comme villes, régions et pays, adresses postales, etc.). La notion de hiérarchie spatiale y figure aussi fréquemment (ex. découpages administratifs tels que pays province régions municipalités). Dimension spatiale géométrique : les membres de tous les niveaux hiérarchiques de ces dimensions comportent une définition géométrique (ex. point, ligne ou polygone). Dimension spatiale géométrique mixte : seulement certains niveaux hiérarchiques sont cartographiés ; souvent, les membres des niveaux les plus fins (ex. municipalités) ont une représentation géométrique, les autres niveaux supérieurs n étant que descriptifs (alphanumériques). Les dimensions spatiales géométriques et géométriques mixtes comportent des entités spatiales vectorielles. L utilisation de données raster pour la représentation des phénomènes dans l espace a mené à l introduction de nouveaux types de dimensions spatiales matricielles [McHugh, 2008; Bédard et Han, 2008]. Celles-ci peuvent être purement matricielles (tous les niveaux comportent une structure matricielle) ou hybrides (certains niveaux ont une structure matricielle alors que d autres comportent des entités vectorielles). La notion de dimension mixte existe également dans le cas des dimensions matricielles : certains niveaux peuvent omettre la représentation spatiale pour une partie ou l ensemble de leurs membres.

Chapitre 1. Introduction 11 Puisque le concept de dimension matricielle est récent et que les outils SOLAP ne supportent pas directement celles-ci, seules les dimensions spatiales géométriques (et mixtes) ont été considérées dans le cas de ce projet de recherche. Le second concept introduit par SOLAP est celui de mesure spatiale. Elle se présente sous trois formes, soit : Mesure spatiale géométrique : La géométrie résultante issue d un croisement entre les membres d une ou plusieurs dimensions spatiales géométriques, sur lesquels une opération géométrique (union, intersection, etc.) est appliquée [Han et al., 1998]. Cette mesure peut être représentée par le stockage de pointeurs vers les formes géométriques individuelles des membres impliqués ou bien par le stockage soit de l objet géométrique résultant en tant que tel, soit d une approximation de cet objet [Bédard et Han, 2008]. Mesure spatiale numérique : Le résultat du calcul d un opérateur métrique ou topologique (ex. distance, superficie) ; il s agit d une valeur numérique, stockée dans les cellules du cube de données en tant que mesure [Rivest et al., 2001]. Mesure spatiale complète : Il s agit de la combinaison d une mesure spatiale géométrique avec une valeur numérique, par exemple le dénombrement d un phénomène avec sa position [Bédard et Han, 2008]. En plus de quelques prototypes de recherche, l équipe du professeur Yvan Bédard au Centre de Recherche en Géomatique (CRG) a réalisé le développement d un logiciel SOLAP intégré, JMap Spatial OLAP, qui est commercialisé par la firme KHEOPS Technologies [KHEOPS Technologies, 2005]. Il y a aussi un nombre grandissant de solutions OLAP sur le marché qui commencent à intégrer des composants de visualisation cartographique [Proulx et al., 2007]. À l heure actuelle, tous ces produits sont destinés à une utilisation en contexte informatique sédentaire, i.e. sur des ordinateurs personnels, et en architecture client-serveur lorsqu il s agit de données partagées. 1.2.2 Mobilité en informatique Avec l avènement des réseaux de télécommunication sans-fil, qu il s agisse de téléphonie cellulaire numérique (GSM, GPRS, CDMA) ou de réseaux informatiques WiFi (802.11), l informatique est devenue nomade et ubiquitaire. La miniaturisation des composantes électroniques a également permis la production d appareils informatiques mobiles de plus en plus petits et puissants : on n a qu à penser aux téléphones mobiles évolués (smartphones, tels que les Blackberry, Apple iphone, etc.), aux appareils de

Chapitre 1. Introduction 12 divertissement audio-visuels portatifs et aux assistants personnels numériques (PDA). Ces développements technologiques font en sorte que l information est accessible en tout lieu (selon la couverture des réseaux sans-fil) et en tout temps. 1.2.2.1 Types de plateformes mobiles L informatique mobile se définit avant tout par la caractéristique de pouvoir faire l usage d appareils et d applications lorsqu on est en mouvement. Plusieurs catégories de plateformes matérielles permettent un tel type d utilisation ; dans le cadre de notre recherche, nous nous intéressons à trois types d appareils : les ordinateurs portatifs, les assistants personnels numériques (PDA) et les smartphones. Ordinateurs portatifs : de nos jours, ces appareils ont des capacités comparables aux ordinateurs de bureau. D ailleurs, dans plusieurs cas, ils sont utilisés de la même manière, c est-à-dire dans un environnement de bureau sédentaire, ou encore transportés d un emplacement à l autre (e.g. au bureau et à la maison). On peut les considérer comme appareils mobiles lorsqu ils sont utilisés dans d autres types d environnements : en voyage, sur le terrain, dans des véhicules. Dans ces cas, l infrastructure informatique n est plus la même (i.e. indisponibilité du réseau d entreprise, liens de communication de qualité variable), ce qui impose une prise en compte de certaines contraintes (cf. 1.2.2.2) dans la réalisation des applications devant fonctionner dans de tels environnements. Du point de vue des méthodes d entrées et des interfaces utilisateur, on peut considérer que les capacités sont équivalentes à ce qui se trouve sur un ordinateur de bureau. Cela peut différer légèrement dans le cas des Tablet PC où l écran tactile et le stylet remplacent la souris, et dans le cas des portatifs de très petite taille (subnotebooks ou netbooks) dont le clavier et l écran sont de format réduit. En revanche, la taille des ordinateurs portatifs ne les rendent pas propices pour tous les types d utilisation en situation de mobilité. Ils ne sont que réellement utilisables en position assise, et de préférence à un bureau. Leur poids peut également limiter la mobilité des utilisateurs : certains ont le souhait de ne pas avoir à transporter un portatif partout. Les PDA et smartphones viennent combler ce créneau. PDA : les PDA, pour Personal Digital Assistant (assistant numérique personnel), sont des petits ordinateurs qui tiennent dans le creux de la main. Le premier appareil de ce type à être commercialisé fut le Apple Newton, en 1993 [Wikipedia, 2008]. Par la suite, d autres produits firent leur apparition, tels que le Palm Pilot et les Pocket PC (HP ipaq et autres basés sur Windows CE). On peut reconnaître un PDA par