CONCEPTION ET D VELOPPEMENT D'UN SERVICE WEB DE CONSTITUTION DE MINI CUBES SOLAP … · 2018-04-14 · tion des applications SOLAP aux contextes d’utilisation mobile (e.g. PDA et

ETIENNE DUBÉ

CONCEPTION ET DÉVELOPPEMENT D’UNSERVICE 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éomatiquespour l’obtention du grade de Maître ès sciences (M.Sc.)

DÉPARTEMENT DES SCIENCES GÉOMATIQUESFACULTÉ DE FORESTERIE ET DE GÉOMATIQUE

UNIVERSITÉ LAVALQUÉBEC

2008

c©Etienne Dubé, 2008

Résumé

Les applications d’aide à la décision spatiale telles que SOLAP (Spatial OLAP) sonttraditionnellement conçues pour les environnements informatiques de bureau. L’adapta-tion des applications SOLAP aux contextes d’utilisation mobile (e.g. PDA et téléphonesmobiles) pose certains problèmes dus à la nature et aux contraintes de ces environne-ments. Ce projet de recherche vise à apporter une solution, basée sur une architectureorientée services (SOA), pour l’adaptation des cubes de données SOLAP aux environ-nements mobiles. Il s’agit d’un service Web capable de transformer les cubes SOLAPdes entrepôts de données géo-décisionnelles en mini-cubes de taille réduite, adaptés auxclients mobiles. Le service permet de sélectionner un sous-ensemble des cubes existantspar l’intermédiaire d’opérateurs paramétrables, d’appliquer des traitements de simpli-fication aux membres spatiaux, et finalement de transmettre ces données en formatXML. Ce travail de recherche ouvre donc la voie à la conception et au développementde nouvelles applications géospatiales décisionnelles mobiles.

Abstract

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

Avant-propos

Ce mémoire avec insertion d’articles comporte deux publications, qui ont été sou-mises, acceptées et présentées dans le cadre de conférences avec comité de lecture etpubliées dans les actes des conférences. Ces articles constituent le corps des chapitres2 et 3. L’étudiant (Etienne Dubé) ayant rédigé le mémoire est également l’auteur prin-cipal des deux articles, et fut responsable de leur rédaction, de leur soumission pourles conférences ainsi que de leur présentation devant public lors des conférences. Lescoauteurs des articles, Thierry Badard et Yvan Bédard, sont respectivement le direc-teur et le codirecteur de ce projet de maîtrise ; leur rôle dans la rédaction des articlesfut d’apporter des conseils pour la recherche et la rédaction, de faire une lecture avantla soumission des articles, ainsi que de proposer des corrections et améliorations auxtextes.

Le texte des articles est présenté de manière intégrale dans le mémoire. Quelquesmodifications mineures ont été apportées, pour ajuster le texte à la mise en page dumémoire (mise en forme, modification de la numérotation des sections, format des ci-tations et de la bibliographie, changement de quelques termes pour l’appel des figureset les renvois). Autrement, le contenu est identique à ce qu’on retrouve dans la versionayant 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éelde mini-cubes SOLAP pour clients mobiles — Une architecture orientée services pourl’utilisation mobile des données géo-décisionnelles », dans SAGEO 2007, Rencontres

internationales Géomatique et territoire (CD-ROM), Clermont-Ferrand, France, ISBN978-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 sontconçues pour les environnements informatiques de bureau. Dans le but de supporterl’aide à la décision géospatiale en situation de mobilité, certaines adaptations à SOLAPsont nécessaires. Cet article décrit une solution, basée sur les architectures orientées ser-vices et les technologies des services Web, pour adapter les cubes de données SOLAPafin de répondre aux exigences et contraintes reliées aux environnements informatiquesmobiles et aux réseaux sans-fil.

Article du chapitre 3 :

Dubé, E., T. Badard et Y. Bédard. 2008, « An interoperable XML encoding for theexchange of Spatial OLAP data cubes in SOA environments », dans 31st International

Convention MIPRO on Business Intelligence Systems (miproBIS), Opatija, Croatie.


Résumé : Les technologies de XML et des services Web ont révolutionné la manièredont 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 quedes spécifications de services Web telles que XML for Analysis permettent l’utilisationd’outils OLAP dans des architectures orientées services (SOA — Service Oriented Ar-

chitecture), 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’unemanière interopérable.

Cet article propose un nouvel encodage XML pour l’échange de cubes de donnéesSOLAP, contenant les données et métadonnées spatiales et descriptives. Cela permetla livraison du schéma du cube, des membres de dimensions (incluant la géométrie desmembres spatiaux) et des faits. Ce format XML peut être utilisé dans le développe-ment de services Web pouvant être déployés dans différentes situations, ne se limitantpas aux plateformes client-serveur traditionnelles mais également aux environnementsd’informatique mobile et ubiquitaire.

Remerciements

Ce projet de recherche a été mené grâce à la collaboration et au financement dela Chaire de recherche industrielle CRSNG en bases de données géospatiales décision-nelles1, dirigée par le professeur Yvan Bédard. Il a aussi bénéficié du programme debourses d’études de Géomatique Canada2. Je tiens à remercier ces deux organismespour leur soutien financier. Merci également au professeur Thierry Badard pour sacontribution au financement.

Je remercie mon directeur, Thierry Badard, avec qui j’ai eu la chance de travaillertout au long de ma maîtrise, pour son expertise, pour la grande confiance qu’il m’aaccordé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 unnombre de technologies qui vont bien au delà de ce mémoire. Merci également pourm’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 outreson implication dans le financement de ce projet par l’intermédiaire de la Chaire, aaccepté 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), pouravoir accepté d’être examinateur externe de mon mémoire.

J’aimerais aussi souligner mon appréciation aux professionnels de recherche de laChaire, 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 ceprojet. Merci également à Carmen Couture, agente de gestion des études graduées audépartement des sciences géomatiques, pour ses conseils et son aide.

1http://mdspatialdb.chair.scg.ulaval.ca/2http://www.cig-acsg.ca

http://mdspatialdb.chair.scg.ulaval.ca/

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, Rose-marie, 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 notrepassage au département d’autant plus agréable.

Mes bonnes grâces vont également envers mes colocataires, Maryse, Marjolaine etPierre-Luc, avec qui j’ai partagé mon espace vital ainsi que de nombreuses bières aucours des dernières années.

Merci à mes parents, Gaétane et Gérald, pour avoir su dès ma tendre enfance instilleren moi un grand sens de la curiosité.

Enfin, je tiens à exprimer toute ma reconnaissance à mon amoureuse, GenevièveMeunier, pour avoir vécu avec moi les joies et les peines des études graduées. Je suisquelqu’un de privilégié par ta présence ; ton soutien et ton réconfort furent d’une valeurinestimable pour moi.

Table des matières

Résumé ii

Abstract iii

Avant-propos iv

Remerciements vi

Table des matières viii

Table des figures xiii

Liste des tableaux xiv

1 Introduction 11.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 État de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 Informatique décisionnelle, OLAP et SOLAP . . . . . . . . . . . 31.2.1.1 Systèmes opérationnels et analytiques . . . . . . . . . 31.2.1.2 OLAP — On-Line Analytical Processing . . . . . . . . 41.2.1.3 Spatial OLAP (SOLAP) . . . . . . . . . . . . . . . . . 10

1.2.2 Mobilité en informatique . . . . . . . . . . . . . . . . . . . . . . 111.2.2.1 Types de plateformes mobiles . . . . . . . . . . . . . . 121.2.2.2 Contraintes de mobilité . . . . . . . . . . . . . . . . . 131.2.2.3 Architecture logicielle des plateformes mobiles . . . . . 151.2.2.4 Architecture orientée services et environnements mobiles 181.2.2.5 Mobilité et géomatique . . . . . . . . . . . . . . . . . . 191.2.2.6 Mobilité et OLAP . . . . . . . . . . . . . . . . . . . . 21

1.2.3 Services Web et architecture orientée services (SOA) . . . . . . 221.2.3.1 Systèmes répartis, Internet et intergiciels . . . . . . . . 221.2.3.2 Services Web . . . . . . . . . . . . . . . . . . . . . . . 231.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éci-sionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281.2.4.1 Les services Web en géomatique . . . . . . . . . . . . . 281.2.4.2 Services Web pour OLAP . . . . . . . . . . . . . . . . 291.2.4.3 Les services Web en géomatique décisionnelle . . . . . 30

1.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311.4 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

1.4.1 Objectif général . . . . . . . . . . . . . . . . . . . . . . . . . . . 331.4.2 Objectifs spécifiques . . . . . . . . . . . . . . . . . . . . . . . . 33

1.5 Méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331.6 Structure du document . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2 Définition des requis et de l’architecture du système 382.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.1.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.2 Corps de l’article . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.2.2 Concepts et problématique . . . . . . . . . . . . . . . . . . . . . 42

2.2.2.1 Concepts d’OLAP et des entrepôts de données décision-nelles . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 ser-vices Web . . . . . . . . . . . . . . . . . . . . . . . . . 45

2.2.3 Proposition d’une architecture pour le service Web . . . . . . . 472.2.3.1 Cas d’utilisation: invocation du service . . . . . . . . . 472.2.3.2 Construction d’un mini-cube: principes conceptuels . . 492.2.3.3 Architecture du service . . . . . . . . . . . . . . . . . . 52

2.2.4 Réalisation d’un prototype . . . . . . . . . . . . . . . . . . . . . 542.2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562.2.6 Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . 562.2.7 Bibliographie partielle (pour l’article seulement) . . . . . . . . . 57

2.3 Compléments à l’article . . . . . . . . . . . . . . . . . . . . . . . . . . . 602.3.1 SOLAP et mobilité . . . . . . . . . . . . . . . . . . . . . . . . . 60

2.3.1.1 Contraintes de mobilité: comment y palier? . . . . . . 602.3.1.2 Rôles du service Web . . . . . . . . . . . . . . . . . . . 62

2.3.2 Métamodèle pour cubes SOLAP . . . . . . . . . . . . . . . . . . 632.3.3 Opérateurs de constitution de mini-cubes: approfondissement . . 66

2.3.3.1 Opérateurs de sélection de membres . . . . . . . . . . 672.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 . . . . . . . 712.3.4.2 Hiérarchies multiples . . . . . . . . . . . . . . . . . . . 742.3.4.3 Simplification géométrique . . . . . . . . . . . . . . . . 75

2.3.5 Infrastructure technologique SOLAP et diffusion aux mobiles . . 762.3.5.1 Service basé sur un outil ETL: failles de l’approche . . 772.3.5.2 Service basé sur un serveur OLAP . . . . . . . . . . . 78

2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

3 Encodage XML pour cubes SOLAP et contrat de service 813.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813.2 Corps de l’article . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

3.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843.2.2 Requirements for a SOLAP data cube XML format . . . . . . . 85

3.2.2.1 Representation of both data (facts and members) andmetadata (schema) . . . . . . . . . . . . . . . . . . . . 86

3.2.2.2 Based on existing standards . . . . . . . . . . . . . . . 863.2.2.3 Be independent of particular implementations in OLAP

and GIS products . . . . . . . . . . . . . . . . . . . . . 873.2.2.4 Support for spatial dimensions and spatial members . 873.2.2.5 Support of shared dimensions . . . . . . . . . . . . . . 873.2.2.6 Describing calculated measures and members . . . . . 883.2.2.7 Separation of contents and presentation . . . . . . . . 88

3.2.3 Specification of the XML encoding . . . . . . . . . . . . . . . . 883.2.3.1 CubeSchema document . . . . . . . . . . . . . . . . . . 893.2.3.2 CubeMembers document . . . . . . . . . . . . . . . . . 913.2.3.3 CubeCells document . . . . . . . . . . . . . . . . . . . 933.2.3.4 Relevance of the encoding for spatial data and SOA . . 94

3.2.4 Example of an implementation . . . . . . . . . . . . . . . . . . . 953.2.5 Conclusion and outlooks . . . . . . . . . . . . . . . . . . . . . . 963.2.6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . 973.2.7 References (for the paper only) . . . . . . . . . . . . . . . . . . 97

3.3 Compléments à l’article . . . . . . . . . . . . . . . . . . . . . . . . . . . 1003.3.1 Contrat de service et opérations . . . . . . . . . . . . . . . . . . 100

3.3.1.1 Retour sur WSDL . . . . . . . . . . . . . . . . . . . . 1003.3.1.2 Opération GetCapabilities . . . . . . . . . . . . . . . . 1023.3.1.3 Opération DescribeSchema . . . . . . . . . . . . . . . 1033.3.1.4 Opération GetMembers . . . . . . . . . . . . . . . . . 1043.3.1.5 Opération GetCells . . . . . . . . . . . . . . . . . . . . 1083.3.1.6 Opération GetCube . . . . . . . . . . . . . . . . . . . 111

3.3.2 Considérations par rapport aux contraintes de mobilité . . . . . 1133.3.2.1 Format de données spatiales . . . . . . . . . . . . . . . 113

Table des matières xi

3.3.2.2 Verbosité de l’encodage XML . . . . . . . . . . . . . . 1143.3.2.3 Utilisation des données XML par le client . . . . . . . 116

3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

4 Réalisation d’un prototype 1204.1 Choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

4.1.1 Langage de programmation . . . . . . . . . . . . . . . . . . . . 1214.1.2 Outil ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1224.1.3 Moteur OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1234.1.4 Système de gestion de bases de données relationnel . . . . . . . 1254.1.5 Cadre de développement géomatique . . . . . . . . . . . . . . . 1264.1.6 Cadre de développement pour services Web . . . . . . . . . . . 1264.1.7 Autres outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1274.1.8 Jeu de données pour tests . . . . . . . . . . . . . . . . . . . . . 127

4.2 Architecture du système . . . . . . . . . . . . . . . . . . . . . . . . . . 1294.2.1 Architecture générale du système . . . . . . . . . . . . . . . . . 129

4.2.1.1 Systèmes sources . . . . . . . . . . . . . . . . . . . . . 1314.2.1.2 Procédures ETL . . . . . . . . . . . . . . . . . . . . . 1314.2.1.3 Entrepôt de données (SGBDR) . . . . . . . . . . . . . 1314.2.1.4 Serveur OLAP . . . . . . . . . . . . . . . . . . . . . . 1324.2.1.5 Service Web de constitution de mini-cubes . . . . . . . 1324.2.1.6 Clients (mobiles ou autres) . . . . . . . . . . . . . . . 132

4.2.2 Architecture détaillée du service Web . . . . . . . . . . . . . . . 1334.2.2.1 Couche d’abstraction des objets OLAP . . . . . . . . . 1334.2.2.2 Générateur de requêtes MDX . . . . . . . . . . . . . . 1344.2.2.3 Sérialisation XML des objets OLAP . . . . . . . . . . 1354.2.2.4 Couche applicative du service Web . . . . . . . . . . . 1354.2.2.5 Client pour tests . . . . . . . . . . . . . . . . . . . . . 136

4.3 Tests du service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1364.3.1 Configuration de l’environnement de test . . . . . . . . . . . . . 1364.3.2 Tests de performance . . . . . . . . . . . . . . . . . . . . . . . . 137

4.3.2.1 Requêtes effectuées . . . . . . . . . . . . . . . . . . . . 1374.3.2.2 Résultats des tests . . . . . . . . . . . . . . . . . . . . 1384.3.2.3 Interprétation des résultats . . . . . . . . . . . . . . . 139

4.3.3 Compression des données . . . . . . . . . . . . . . . . . . . . . . 1404.3.4 Validation et autres tests . . . . . . . . . . . . . . . . . . . . . . 141

4.4 Limites du prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1414.4.1 Opération GetCube . . . . . . . . . . . . . . . . . . . . . . . . . 1414.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 1445.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1445.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

5.2.1 Encodage XML pour cubes SOLAP et contrat de service . . . . 1465.2.2 Outils logiciels pour la géomatique décisionnelle . . . . . . . . . 146

5.2.2.1 GeoKettle . . . . . . . . . . . . . . . . . . . . . . . . . 1475.2.2.2 GeoMondrian . . . . . . . . . . . . . . . . . . . . . . . 147

5.3 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1495.3.1 Services Web auxiliaires pour clients SOLAP mobiles . . . . . . 1495.3.2 Travaux de recherche en géomatique décisionnelle mobile . . . . 149

Bibliographie 151

A Listages et exemples 159A.1 Exemples WSDL et SOAP . . . . . . . . . . . . . . . . . . . . . . . . . 159A.2 Définitions XML Schema et WSDL . . . . . . . . . . . . . . . . . . . . 160

A.2.1 Schéma de l’encodage XML pour cubes SOLAP . . . . . . . . . 160A.2.2 Contrat de service du service Web de constitution de mini-cubes 167A.2.3 Exemples de requêtes et réponses . . . . . . . . . . . . . . . . . 177

A.2.3.1 Opération GetCapabilities . . . . . . . . . . . . . . . . 177A.2.3.2 Opération DescribeSchema . . . . . . . . . . . . . . . 178A.2.3.3 Opération GetMembers . . . . . . . . . . . . . . . . . 180A.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 . . . . . . . . . . . . . . . . . . . 21.2 Application mobile autonome . . . . . . . . . . . . . . . . . . . . . . . 151.3 Application mobile autonome avec synchronisation . . . . . . . . . . . 161.4 Architecture avec client mobile lourd . . . . . . . . . . . . . . . . . . . 171.5 Architecture avec client mobile léger . . . . . . . . . . . . . . . . . . . 181.6 Phases du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.1 Mécanisme d’invocation du service Web . . . . . . . . . . . . . . . . . . 482.2 Schéma du cube (formalisme UML multidimensionnel de Bédard et al.

[2006]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502.3 Architecture du prototype de service Web . . . . . . . . . . . . . . . . 552.4 Métamodèle de cube SOLAP . . . . . . . . . . . . . . . . . . . . . . . . 642.5 Schéma conceptuel partiel du cube SOLAP « Recensement » . . . . . . 672.6 Opérateur « Inclusion de membres et de leurs descendants » . . . . . . 692.7 Opérateur « Agrégation sur un ou plusieurs membres » . . . . . . . . . 702.8 Opérateur « Réduction de dimension » . . . . . . . . . . . . . . . . . . 712.9 Opérateur « Inclusion de membre et de leurs descendants » avec hiérar-

chies multiples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742.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 . . . . . 963.2 Conversion XML vers OLAP sur l’appareil mobile . . . . . . . . . . . . 1173.3 Mise en œuvre d’adaptateurs de conversion XML vers OLAP . . . . . . 119

4.1 Schéma du cube SOLAP « Recensement » . . . . . . . . . . . . . . . . 1284.2 Schéma d’implantation de l’entrepôt de données de test . . . . . . . . . 1304.3 Architecture générale du système . . . . . . . . . . . . . . . . . . . . . 131

Liste des tableaux

4.1 Configuration matérielle de l’environnement de test . . . . . . . . . . . 1364.2 Configuration logicielle de l’environnement de test . . . . . . . . . . . . 1374.3 Temps d’exécution des requêtes de test . . . . . . . . . . . . . . . . . . 1394.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 auxappareils tels que les ordinateurs portatifs, les téléphones mobiles, les assistants numé-riques personnels (PDA — Personal Digital Assistant) ainsi qu’aux réseaux cellulairesnumériques et informatiques sans-fil, le concept d’informatique ubiquitaire, i.e. en toutlieu et en tout temps, est désormais réalité.

Dans le domaine de la géomatique, ces technologies ont donné suite à un nombre im-portant d’applications. Outre les produits et services accessibles à un large public, telsque les systèmes de navigation par GPS (Global Positioning System), on retrouve aussides SIG (systèmes d’information géographiques) adaptés aux PDA et autres plateformesmobiles, permettant l’exploitation sur le terrain des données à référence spatiale. Néan-moins, tout comme les SIG dans un environnement informatique de bureau, ces logicielssont peu appropriés pour l’analyse exploratoire des données à des fins de prise de déci-sion [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 Proces-

sing), provenant du domaine de l’informatique décisionnelle (business intelligence), enajoutant des capacités de gestion des données à référence spatiale et de visualisationcartographique [Rivest et al., 2001].

L’avènement de l’informatique mobile ouvre la voie à de nouveaux modes d’utili-sation des technologies géomatiques d’aide à la décision. Une utilisation mobile de cesoutils comporte deux volets : on peut vouloir enrichir la prise de décision, grâce à l’infor-mation de mobilité (e.g. position absolue ou relative dans le temps, trajectoire) acquise

Chapitre 1. Introduction 2

Infrastructure technologique(bases de données , services)

Information depositionnement

Données pouraide à la décision

Utilisateurs mobiles

Lien réseau(sans-fil / cellulaire)

Système de positionnement

(e.g. GPS)

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 lesparcours des véhicules et enrichir les bases de données géospatiales décisionnelles decette information afin d’optimiser les opérations de l’entreprise. On parle donc d’ex-ploiter 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 lesappareils mobiles, afin de supporter la prise de décision sur le terrain. Il est même envi-sageable de combiner les deux volets dans un seul système intégré, afin que l’informationde position provenant des utilisateurs nomades soit exploitable en temps réel pour laprise de décision : ainsi, le contexte spatial de l’utilisateur vient enrichir en continul’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’in-formation 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 im-portance majeure. De tels systèmes, tenant compte de la position de l’utilisateur pourlui fournir une information ou toute autre réponse, sont catégorisés comme étant desservices 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 exploitela notion de positionnement, sans se restreindre uniquement aux systèmes d’aide à ladécision.

Les outils SOLAP, en tant que systèmes d’aide à la décision, pourraient s’avérerintéressants dans de tels contextes. Toutefois, à l’heure actuelle, ils sont conçus pour lesenvironnements informatiques de bureau. D’ailleurs, il s’agit là de l’objectif principal dela chaire de recherche industrielle CRSNG en bases de données géospatiales décision-


nelles qui a financé le présent projet : « Le but, après les cinq premières années de lachaire, est de procurer des solutions permettant un accès facile et rapide à l’informationgéodécisionnelle « partout et en tout temps ». » [Bédard, 2007]. Plusieurs adaptationssont nécessaires afin que les outils SOLAP soient utilisables dans un environnementinformatique mobile, notamment en ce qui a trait aux interfaces utilisateurs, à la dif-fusion des cubes de données SOLAP et à l’infrastructure technologique supportant cesapplications. Ce projet de recherche concerne ces deux derniers points (diffusion descubes et infrastructure technologique). Les défis de recherche devant être surmontéspour parvenir à une telle solution sont nombreux et concernent plusieurs domaines ettechnologies : l’informatique décisionnelle (business intelligence), les bases de donnéesgéospatiales décisionnelles, l’informatique mobile ainsi que l’architecture orientée ser-vices et les services Web. Dans les sections suivantes de ce chapitre, les concepts de cesdomaines seront introduits et une revue des travaux de recherche existants sera présen-tée, afin de mieux cerner la problématique, définir les objectifs à atteindre et élaborerquelques 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éra-tions courantes (e.g. ventes, inventaires, commandes et autres processus métiers) s’ap-puient sur des systèmes dits opérationnels. On parle également de systèmes transac-tionnels ou encore OLTP (On-Line Transactional Processing). Dans ces systèmes, lestockage et l’accès aux données font appel aux bases de données relationnelles. Lesdonnées y sont organisées dans des schémas normalisés, i.e. qui minimisent la redon-dance des informations, et qui sont optimisés pour supporter un grand volume de tran-sactions (ajouts et modifications fréquents des données) [O’Neil et O’Neil, 2001]. Lessystèmes d’information géographique (SIG) conventionnels font également appel à cetype de bases de données. Il s’agit de systèmes opérationnels, puisque les manipulationscourantes 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éri-table mine d’or pour les décideurs ; en effet, elles contiennent de l’information sur ungrand nombre d’activités de l’organisation. Il y a donc intérêt à effectuer des analyses


de ces données, afin d’appuyer la prise de décision. Toutefois, les systèmes opérationnelsne sont pas optimisés pour les applications d’analyse. Cela a mené au développementd’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èlesde 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, etsont 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éessont fréquemment organisées selon le modèle multidimensionnel, i.e. dans des schémasen étoile, en flocon ou parent-enfant, composés de tables de faits et de dimensions. Plu-sieurs types d’applications sont conçus pour exploiter les données d’un entrepôt, parexemple les tableaux de bord (dashboards), la fouille de données (data mining) et lesoutils OLAP.

1.2.1.2 OLAP — On-Line Analytical Processing

L’acronyme OLAP, pour On-Line Analytical Processing, identifie une catégorie d’ou-tils utilisés pour l’analyse exploratoire des données, généralement à des fins de prisede décision [Codd et al., 1993; Thomsen, 2002]. Les outils OLAP ont comme notioncentrale le cube de données (ou encore hypercube). Il s’agit d’une structure multidi-mensionnelle, 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 fonc-tions agrégatives pour obtenir des données agrégées (e.g. population par pays) à partirdes 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 vuessous forme de tableaux croisés et graphiques. Ils sont également conçus pour offrir untemps de réponse rapide aux requêtes, afin de ne pas nuire au fil de pensée de l’ana-lyste lors de l’exploration des données. À cette fin, les cubes comportent souvent desdonnées agrégées pré-calculées, ce qui peut accélérer considérablement le traitement desrequêtes.

Concepts OLAP

Certains concepts et termes se rapportant aux éléments constituant un cube OLAPseront 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-


sionnelle et hiérarchique. Un cube est constitué de cellules adressées par desmembres disposés sur les dimensions. Un cube n’est pas limité à trois dimen-sions ; il peut en compter un nombre arbitraire. Il ne faut pas non plus confondreles 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ées1, mais ce dernier ne présentepas les données selon un vrai modèle multidimensionnel, mais plutôt sous formerelationnelle (relations et tuples). Une surcouche est nécessaire pour présenter lesdonnées de l’entrepôt sous forme d’objets d’un modèle multidimensionnel ; en gé-néral un moteur OLAP2 est responsable de cette tâche. Il s’occupe d’effectuer unmapping relationnel vers multidimensionnel des données de l’entrepôt3, mettantainsi à disposition des utilisateurs les cubes de données.

Dimension : correspond aux différents axes d’analyse offerts par le cube. Les dimen-sions 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ésd’une organisation, les cours d’une université sont tous des exemples de thèmespouvant correspondre à une dimension d’un cube.

Membre : les instances d’entités de la réalité dans les dimensions se nommentmembres. Il s’agit en autres termes de points sur l’axe d’analyse que consti-tue une dimension. Par exemple, une dimension « Limites administratives » peutcomporter les membres « Canada », « États-Unis » et « France ». La plupart destechnologies OLAP du marché permettent également d’associer des attributs (oupropriétés) aux membres, outre leur nom. Par exemple, un membre « Supermar-ché Ste-Foy » de la dimension « Commerce » pourrait comporter des attributsdécrivant la superficie du commerce et le nombre d’étages ; ces attributs peuvents’avérer utiles pour réaliser certaines analyses (e.g. obtenir le total des ventes pourtous 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 dimen-sion représentant un découpage administratif peut se diviser en niveaux « Pays »,« Province », « Région économique » et « Division de recensement » (comté), en

1Il existe cependant une autre possibilité, dite « architecture sans entrepôt », où les données ducube sont prises à même les sources.

2Le terme moteur OLAP est utilisé de manière générale pour représenter toute technologie OLAPcapable 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 formede librairie.

3Ceci est vrai autant pour les technologies ROLAP que MOLAP, puisque les moteurs MOLAPvont également extraire les données depuis un entrepôt pour les placer en stockage dans une structuremultidimensionnelle propriétaire. Voir paragraphe « Architectures ROLAP et MOLAP » plus loin danscette section.


allant du plus général au plus détaillé. Les membres appartiennent à un niveauspécifique (e.g. « Nouveau-Brunswick », « Québec » et « Ontario » appartiennentau niveau « Province »), et peuvent comporter des relations N:1 vers les membresdu niveau supérieur (e.g. les trois membres précédents remontent au membre « Ca-nada » 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, à par-tir de la somme des populations des régions économiques appartenant à chaqueprovince.

Hiérarchie : certaines dimensions peuvent comporter plus d’un ensemble de niveauxpermettant de décrire un thème d’analyse. Par exemple, on peut décrire le tempsselon un découpage jour-semaine ou encore jour-mois-année. On parle alors dehiérarchies multiples ou alternatives. Une dimension peut ainsi comporter plusd’une hiérarchie, offrant des chemins différents pour remonter vers les membresde 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 membresde ce niveau qui définissent le grain de la dimension et par conséquent l’adressagedes faits détaillés.

Fait : il s’agit d’une unité d’information contenant les valeurs des mesures, correspon-dant au croisement d’un membre de chaque dimension. Les liens vers les membresimpliqués font également partie du fait. Par exemple, on pourrait énoncer unfait tel que « les ventes du produit « Lait écrémé 2L » pour le supermarché ducentre-ville de Québec dans la journée du 21 octobre 2007 sont de 94 unités, pourun montant de 356$. » Dans cet exemple, « Lait écrémé 2L », « supermarché ducentre-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 desventes ». On peut également distinguer les faits détaillés des faits agrégés. Lesfaits détaillés sont associés à des membres feuilles dans chaque dimension (auxniveaux les plus détaillés). Les valeurs des mesures pour ces faits doivent néces-sairement être stockées dans le cube. Les faits agrégés, quant à eux, sont associésau 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 valeursde mesures pour les faits agrégés est généralement facultatif, puisque ces valeurspeuvent être calculées à la volée à partir des faits détaillés. Cependant, il estpossible 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 dumoteur 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 dansla littérature. Cependant, dans ce mémoire, nous attribuerons une définition spé-


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 unevariable dans le cube OLAP représentant une réalité observée (mesurée), pourlaquelle chaque fait comporte une valeur. Nous tenons ainsi à distinguer le conceptde mesure, qui est une variable, de son instance dans un fait, soit les valeursdonnées à une mesure pour un fait. Les types de données des mesures sont dansla 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é. Ils’agit d’un artéfact d’implantation qu’on retrouve dans certains langages d’in-terrogation, notamment MDX4 [Microsoft Corporation, 2007b], et dans certainsproduits 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 me-sure. Cette manière de faire se rattache au concept de symétrie entre mesureset dimensions (plus précisément, de « type-varying symmetry » selon Thomsen[1999]). Un avantage de cette approche est de rendre plus uniforme la syntaxe decertaines expressions calculées (membres ou mesures calculées) ; des membres dedimensions ou des mesures peuvent être employées de la même manière dans detelles expressions5. Dans tous les cas, la dimension de mesures est créée implici-tement par le moteur OLAP, à partir des mesures définies dans le cube ; il s’agitd’une « pseudo-dimension ». Cette dimension n’apparaît jamais dans le modèleconceptuel du cube, et il n’existe pas de table de dimension correspondant auxmesures dans l’entrepôt de données.

Cellule : nous définissons une cellule d’un cube comme le contenant de la valeur d’unemesure pour un fait donné. En contraste avec le terme mesure, une cellule faitréférence à un emplacement précis dans le cube ; on peut ainsi dire qu’il s’agitd’une mesure positionnée dans l’hypercube, au croisement des membres d’un fait.Par exemple, la cellule correspondant à la mesure « Montant des ventes » pourle croisement des membres « Lait écrémé 2L », « supermarché du centre-ville deQuébec » et « 21 octobre 2007 » contient la valeur « 356$ ». Conformément auconcept de mesure défini plus haut, une cellule peut contenir comme valeur nonseulement un nombre scalaire, mais aussi des types d’objets plus complexes.

4Voir « Langages d’interrogation OLAP » plus loin dans cette section.5Par exemple, en MDX, une expression permettant d’obtenir la différences entre les mesures « Po-

pulation » 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 2007et 2006 s’écrirait : « [Temps].[2007]-[Temps].[2006] ». Dans les deux cas, la syntaxe est semblable, qu’ils’agisse de mesures ou de membres.


Architectures ROLAP et MOLAP

Les produits OLAP offerts sur le marché suivent principalement deux approches ence qui concerne le stockage de la base de données multidimensionnelle ; il s’agit desapproches ROLAP et MOLAP [Pendse, 2006].

L’acronyme ROLAP (Relational OLAP) dénote un système OLAP où le stockage desdonnées du cube est exclusivement fait dans un système de gestion de bases de donnéesrelationnel (SGBDR). Le moteur ROLAP interprète les requêtes de l’utilisateur afinde les transformer en requêtes relationnelles (en langage SQL, par exemple) et ainsiinterroger directement l’entrepôt de données. En général, les données de l’entrepôt sontorganisées selon le modèle multidimensionnel de Kimball, i.e. sous forme de tables defaits 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 ouencore stockées à même la table de faits dans un schéma unique [Adamson, 2006]. Celapermet de réduire considérablement le temps de réponse aux requêtes concernant desdonnées agrégés.

MOLAP, pour Multidimensional OLAP, implique le stockage des données du cubedans 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éesmultidimensionnelles. Dans plusieurs cas, elles offrent une performance supérieure auxtechnologies ROLAP [Mundy et Thornthwaite, 2006]. Le contenu des cubes MOLAP estgénéralement extrait à partir d’un entrepôt de données relationnel, et rafraîchi lorsqu’ily a une mise à jour des données de l’entrepôt.

Il existe également une approche dite Hybrid OLAP (HOLAP), combinant les tech-nologies ROLAP et MOLAP dans un même moteur OLAP. Dans ce cas, les donnéesdétaillées sont stockées dans l’entrepôt de données (dans un SGBDR) alors que les don-nées agrégées sont matérialisées dans une structure de type MOLAP. Le moteur OLAPrécupère donc les données depuis ces deux sources, afin de répondre aux requêtes desutilisateurs.

En pratique, le choix d’architecture technologique ROLAP, MOLAP ou HOLAPest une considération de design physique et d’implémentation, et ne devrait pas avoird’impact sur la présentation des données du point de vue de l’utilisateur. Un exemplese trouve dans le serveur Microsoft SQL Server Analysis Services, qui supporte lesarchitectures ROLAP, MOLAP et HOLAP. Peu importe le choix de technologie destockage, un seul et même langage d’interrogation (MDX) est utilisé et la vue logique


des cubes présentée à l’utilisateur est uniforme. Le serveur OLAP agit donc comme unecouche de présentation par-dessus l’entrepôt6, et le mécanisme interne de stockage etd’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 conceptiondes applications clientes peuvent se faire indépendamment de la technologie de stockagechoisie. Les concepts abordés dans le reste de ce mémoire sont ainsi applicables à toutetechnologie OLAP, qu’il s’agisse de ROLAP, MOLAP, HOLAP ou encore toute autrevariante 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 interro-ger les bases de données relationnelles, des langages de requête ont été conçus pourl’accès aux cubes de données multidimensionnelles. Certains se présentent comme desextensions à SQL (comme c’est le cas pour Oracle Express) alors que d’autres sont denouveaux 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 (main-tenant Analysis Services). MDX a pris la place en tant que standard de facto et estmaintenant utilisé par d’autres serveurs OLAP (entre autres les produits de SAP7, Mi-croStrategy8 et Pentaho9) ainsi que plusieurs applications clientes (Cognos10, BusinessObjects11, ProClarity12, etc.)

Contrairement à SQL qui présente un résultat de requête sous forme tabulaire (ran-gé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 di-mensionnalité du résultat). Les cellules retournées dans le résultat sont déterminées enfonction 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 fonctionsopérant sur les membres ou mesures. Pour plus de détails sur la syntaxe de MDX, lelecteur est invité à consulter des références telles que [Microsoft Corporation, 2007b] et[Spofford et al., 2006].

6Ceci est dans les cas où l’architecture du serveur OLAP s’appuie sur un entrepôt de données ; enautres cas il pourrait s’agir de cubes construits à même les sources.

7http://www.sap.com/8http://www.microstrategy.com/9http://www.pentaho.com/

10http://www.cognos.com/11http://www.businessobjects.com/12http://proclarity.com/

http://www.sap.com/

http://www.microstrategy.com/

http://www.pentaho.com/

http://www.cognos.com/

http://www.businessobjects.com/

http://proclarity.com/


1.2.1.3 Spatial OLAP (SOLAP)

Les outils OLAP classiques sont limités quant à la représentation des données spa-tiales. Afin de tirer profit de la composante spatiale, une nouvelle catégorie d’outils, ditsSpatial OLAP (ou SOLAP), a émergé. Ceux-ci, en combinant des fonctionnalités OLAPet SIG, offrent entre autres des vues cartographiques multi-niveaux, synchronisées ounon avec les vues tabulaires et graphiques traditionnelles, et une navigation simple etintuitive à même ces différentes vues.

SOLAP introduit certains nouveaux concepts par rapport au modèle multidimen-sionnel d’OLAP : il s’agit des dimensions et mesures spatiales. Une dimension spatialeest composée de membres faisant référence à une réalité pouvant être localisée dansl’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 lestockage 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 notionde hiérarchie spatiale y figure aussi fréquemment (ex. découpages administratifstels que pays — province — régions — municipalités).

Dimension spatiale géométrique : les membres de tous les niveaux hiérarchiquesde ces dimensions comportent une définition géométrique (ex. point, ligne oupolygone).

Dimension spatiale géométrique mixte : seulement certains niveaux hiérarchiquessont cartographiés ; souvent, les membres des niveaux les plus fins (ex. municipa-lités) ont une représentation géométrique, les autres niveaux supérieurs n’étantque descriptifs (alphanumériques).

Les dimensions spatiales géométriques et géométriques mixtes comportent des en-tités spatiales vectorielles. L’utilisation de données raster pour la représentation desphénomènes dans l’espace a mené à l’introduction de nouveaux types de dimensionsspatiales matricielles [McHugh, 2008; Bédard et Han, 2008]. Celles-ci peuvent être pu-rement matricielles (tous les niveaux comportent une structure matricielle) ou hybrides(certains niveaux ont une structure matricielle alors que d’autres comportent des entitésvectorielles). La notion de dimension mixte existe également dans le cas des dimensionsmatricielles : certains niveaux peuvent omettre la représentation spatiale pour une par-tie ou l’ensemble de leurs membres.


Puisque le concept de dimension matricielle est récent et que les outils SOLAP nesupportent pas directement celles-ci, seules les dimensions spatiales géométriques (etmixtes) 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ésentesous trois formes, soit :

Mesure spatiale géométrique : La géométrie résultante issue d’un croisement entreles membres d’une ou plusieurs dimensions spatiales géométriques, sur lesquelsune 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 lesformes géométriques individuelles des membres impliqués ou bien par le stockagesoit de l’objet géométrique résultant en tant que tel, soit d’une approximation decet objet [Bédard et Han, 2008].

Mesure spatiale numérique : Le résultat du calcul d’un opérateur métrique ou to-pologique (ex. distance, superficie) ; il s’agit d’une valeur numérique, stockée dansles 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èneavec sa position [Bédard et Han, 2008].

En plus de quelques prototypes de recherche, l’équipe du professeur Yvan Bédardau Centre de Recherche en Géomatique (CRG) a réalisé le développement d’un logi-ciel SOLAP intégré, JMap Spatial OLAP, qui est commercialisé par la firme KHEOPSTechnologies [KHEOPS Technologies, 2005]. Il y a aussi un nombre grandissant de so-lutions OLAP sur le marché qui commencent à intégrer des composants de visualisationcartographique [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 com-posantes électroniques a également permis la production d’appareils informatiques mo-biles 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


divertissement audio-visuels portatifs et aux assistants personnels numériques (PDA).Ces développements technologiques font en sorte que l’information est accessible entout 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 fairel’usage d’appareils et d’applications lorsqu’on est en mouvement. Plusieurs catégoriesde plateformes matérielles permettent un tel type d’utilisation ; dans le cadre de notrerecherche, nous nous intéressons à trois types d’appareils : les ordinateurs portatifs, lesassistants personnels numériques (PDA) et les smartphones.

Ordinateurs portatifs : de nos jours, ces appareils ont des capacités comparablesaux ordinateurs de bureau. D’ailleurs, dans plusieurs cas, ils sont utilisés de lamême manière, c’est-à-dire dans un environnement de bureau sédentaire, ou en-core transportés d’un emplacement à l’autre (e.g. au bureau et à la maison). Onpeut les considérer comme appareils mobiles lorsqu’ils sont utilisés dans d’autrestypes d’environnements : en voyage, sur le terrain, dans des véhicules. Dans cescas, l’infrastructure informatique n’est plus la même (i.e. indisponibilité du réseaud’entreprise, liens de communication de qualité variable), ce qui impose une priseen compte de certaines contraintes (cf. 1.2.2.2) dans la réalisation des applicationsdevant fonctionner dans de tels environnements. Du point de vue des méthodesd’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érerlégèrement dans le cas des Tablet PC où l’écran tactile et le stylet remplacent lasouris, 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 pourtous les types d’utilisation en situation de mobilité. Ils ne sont que réellementutilisables en position assise, et de préférence à un bureau. Leur poids peut éga-lement limiter la mobilité des utilisateurs : certains ont le souhait de ne pas avoirà transporter un portatif partout. Les PDA et smartphones viennent combler cecréneau.

PDA : les PDA, pour Personal Digital Assistant (assistant numérique personnel), sontdes petits ordinateurs qui tiennent dans le creux de la main. Le premier appareil dece type à être commercialisé fut le Apple Newton, en 1993 [Wikipedia, 2008]. Parla suite, d’autres produits firent leur apparition, tels que le Palm Pilot et les PocketPC (HP iPAQ et autres basés sur Windows CE). On peut reconnaître un PDA par


son écran tactile, utilisé avec un stylet ou avec un doigt. La plupart des modèlesne comportent pas de clavier, et utilisent plutôt un système de reconnaissancede l’écriture ou encore un mini-clavier tactile (affiché à l’écran) pour la saisiede texte. Les PDA contemporains comportent également de la mémoire flash

(et la capacité d’accepter des cartes mémoire) pour le stockage des données, unmicrophone, un haut-parleur et une sortie audio, ainsi que la connectivité réseausans-fil de type WiFi (802.11) et Bluetooth. Certains modèles offrent même uneinterface de communication par téléphonie cellulaire (3G ou GPRS), ce qui lesplacent à mi-chemin dans la catégorie des smartphones. Finalement, les PDApeuvent supporter le positionnement, soit avec un GPS intégré, par l’ajout d’unmodule GPS ou par connexion à un appareil GPS externe.

Smartphones : il s’agit de téléphones mobiles ayant des capacités informatiques évo-luées. Contrairement aux téléphones mobiles conventionnels, les smartphones com-portent un système d’exploitation avec lequel il est possible d’installer et d’utiliserdes logiciels de toutes sortes. En réalité, la frontière entre les PDA et les smart-

phones est floue ; on considère toutefois que les smartphones sont conçus davantagepour la communication et la téléphonie (format plus petit, interface utilisateuret ergonomie du combiné). Les appareils tels que les Blackberry13, la série E deNokia14 et le Apple iPhone15 sont des exemples de smartphones.

1.2.2.2 Contraintes de mobilité

Comparativement aux environnements de bureau, l’informatique mobile et sans-filcomporte certaines contraintes techniques dont il faut tenir compte dans la conceptionet le développement d’applications ciblant ces environnements [Satyanarayanan, 1996;Al-bar, 2001; Paelke et al., 2003]. On peut classer ces contraintes en quatre catégories :

Interface utilisateur et méthodes d’entrée : Plusieurs appareils mobiles ne com-portent pas les composantes standards d’interface utilisateur que l’on retrouvesur les ordinateurs de bureau (écran de grande dimension, clavier et souris). Lesécrans sont habituellement de taille réduite, avec une résolution d’affichage limi-tée. De plus, un écran tactile (avec ou sans stylet) ou un clavier miniature fontoffice de méthode d’entrée. Ainsi, les applications développées pour un contextemobile doivent tenir compte de ces contraintes afin de présenter une interfaceutilisateur ergonomique et appropriée pour ces appareils.

13http://www.blackberry.com/14http://www.nokiaforbusiness.com/nfb/find_a_product/browse_mobile_devices.html15http://www.apple.com/iphone/

http://www.blackberry.com/

http://www.nokiaforbusiness.com/nfb/find_a_product/browse_mobile_devices.html

http://www.apple.com/iphone/


Capacités de calcul, de stockage et alimentation électrique : Puisque ces ap-pareils doivent être légers et de petite taille, leurs composantes sont conçues enconséquence. Les processeurs employés sont moins rapides afin de réduire leurconsommation électrique. Pour la mémoire non-volatile, la mémoire flash est pré-férée aux disques durs dans la plupart des cas. Cela implique une capacité infé-rieure, en contrepartie d’une meilleure efficacité énergétique ainsi qu’un volumeet un poids réduits. On constate que l’autonomie en alimentation électrique estun facteur important expliquant ces compromis : de plus petites piles, d’une ca-pacité réduite, impliquent le choix de composantes moins énergivores si on sou-haite conserver une durée de fonctionnement acceptable entre chaque charge desbatteries. Ces compromis quant aux capacités de stockage et de calcul ont desconséquences sur le design des logiciels : les traitements complexes mettent plusde temps à s’exécuter (voir même ne peuvent y être exécutés), et la quantité dedonnées pouvant être emmagasinées dans l’appareil est beaucoup plus limitée.

Liens de communication : Bien que les technologies des réseaux sans-fil numériques,que ce soit en téléphonie cellulaire ou dans les réseaux informatiques de type« WiFi », aient connu d’importantes améliorations au cours des dernières années,leur bande passante et leur latence sont grandement variables selon l’emplacementet le fournisseur de services, et ne sont généralement pas encore à la hauteur decelles des réseaux câblés (e.g. réseaux locaux de type Ethernet, liens de commu-nication à fibre optique). À plusieurs endroits dans le monde (dont au Canada) lecoût de transfert de données par téléphonie cellulaire est encore prohibitif, restrei-gnant ainsi le transfert de fichiers volumineux. De plus, la couverture des réseauxsans-fil est sporadique et de portée limitée, surtout en dehors des centres urbains.Des déconnexions intermittentes sont à prévoir lors de l’utilisation, surtout lors-qu’on se déplace. Les applications mobiles doivent donc être conçues en fonctionde ces limites, en contrôlant adéquatement le volume de données qui transitentpar le réseau sans-fil, en prévoyant le délai (latence) possible sur le réseau lorsde ces transferts, et en offrant des modes de fonctionnement connecté/déconnecté(au lieu d’utiliser des connexions persistantes telles que l’on retrouve dans les ap-plications client-serveur en contexte sédentaire) afin de tenir compte de la natureasynchrone des communications.

Interopérabilité entre systèmes : Les appareils mobiles disponibles sur le marchésont très variés, autant du point de vue matériel que logiciel. Plusieurs types dedispositifs existent : les téléphones mobiles, les smartphones, les assistants numé-riques personnels (PDA), les « Tablet PC », les ordinateurs portatifs, etc. Dansune même famille de dispositifs, les caractéristiques peuvent différer d’un fabricantet d’un modèle à un autre. Dans le monde mobile, il existe plusieurs architecturesde processeurs (ARM, MIPS, PowerPC, etc.), plusieurs systèmes d’exploitation(Windows CE, Linux, PalmOS, Symbian, etc.), ainsi que plusieurs langages et


Appareil mobile

Application mobile

Fig. 1.2 – Application mobile autonome

environnements de programmation (C/C++, Java ME, Microsoft .NET CompactFramework, etc.). Cela contraste fortement avec les environnements de bureau oùune bonne partie du parc informatique comporte des caractéristiques très sem-blables (e.g. architecture PC x86, système d’exploitation Windows). Il est impos-sible de supposer qu’un parc d’appareils mobiles soit homogène lorsqu’on fait ledéveloppement d’applications destinées à ces environnements. L’adoption de solu-tions interopérables, autant du point de vue des logiciels clients que des protocolesde communications, est donc essentielle.

1.2.2.3 Architecture logicielle des plateformes mobiles

Les contraintes des environnements informatiques mobiles ont amené le développe-ment d’architectures adaptées à la conception de systèmes logiciels pour ces environ-nements. De manière simplifiée, on peut énoncer quatre grandes catégories d’architec-tures :

Application autonome

(Figure 1.2) Il s’agit d’une simple application mobile qui ne dépend pas de ressourcesdistantes. L’application est installée sur l’appareil mobile, et le stockage de toutes don-nées nécessaires pour son fonctionnement est local. Exemples : calculatrice, bloc-notes,jeux individuels, logiciel de navigation par GPS (avec cartes pré-chargées sur l’appareil).


Appareil mobile

Applicationmobile

Synchronisation

Ordinateur de bureau

Fig. 1.3 – Application mobile autonome avec synchronisation

Application autonome avec synchronisation

(Figure 1.3) Pour ce type d’application, le fonctionnement est similaire à une ap-plication autonome normale (logiciel installé sur l’appareil mobile), mais une synchro-nisation périodique permet l’échange de données avec un autre système, dit « stationde base ». La synchronisation peut s’effectuer en connectant directement l’appareil àun ordinateur de bureau (e.g. par câble USB) ou encore par un lien sans-fil (e.g. Blue-tooth). Un logiciel installé sur la station de base prend en charge l’échange des donnéesavec l’appareil mobile. Les logiciels et protocoles de synchronisation sont généralementpropriétaires et spécifiques à chaque fabricant d’appareil mobile, et sont limités quantaux applications avec lesquelles ils supportent l’échange de données. Exemple : agendapersonnel (synchronisation des tâches, des contacts et des rendez-vous avec un logicielde bureau).

Client lourd

(Figure 1.4) Il s’agit d’une application installée sur l’appareil mobile, et destinéeà interagir avec des ressources à distance, par réseau sans-fil. Cette architecture, quel’on retrouve également dans les environnements informatiques de bureau, est aussisouvent nommée client-serveur : le client se connecte via le réseau à un serveur, quitraite les requêtes et retourne les données au client. Ce type d’architecture est générale-ment dépendant d’une connectivité réseau persistante (pour toute la durée d’utilisationde l’application). Par client lourd, on entend qu’il s’agit d’un logiciel complet installésur l’appareil ; cela n’implique pas nécessairement un logiciel complexe ou lent16. Lesclients lourds comportent plusieurs avantages : puisqu’ils sont développés grâce un envi-ronnement de développement natif à la plateforme mobile, ils peuvent tirer avantage de

16Le terme « client lourd » est apparu avec celui de « client léger », pour distinguer ces deux typesd’architecture logicielle.


Appareil mobile

Client lourd

Requêtes

Réponses

Serveur

Fig. 1.4 – Architecture avec client mobile lourd

toutes les caractéristiques de l’appareil mobile ciblé (e.g. périphériques intégrés tels queGPS, caméra numérique, microphone, cartes à mémoire flash). De plus, leur vitesse deréponse et leur consommation en bande passante sont souvent avantageuses par rapportaux clients légers, puisque la logique de présentation est réalisée à même l’appareil mo-bile ; le serveur n’est sollicité que pour récupérer les données nécessaires (e.g. contenud’un message, liste de transactions bancaires). Toutefois, il peut être souhaitable dedéléguer certains traitements complexes au serveur, vu la puissance de processeur li-mitée des appareils mobiles (cf. contraintes de mobilité, 1.2.2.2). Un inconvénient decette approche est que les applications développées sont couplées à une plateforme enparticulier (e.g. Java ME, .NET Compact Framework) et donc ne sont pas universellesà tous les types d’appareils mobiles ; de plus, elles doivent être déployées et installéessur l’appareil avant de pouvoir être utilisées. Exemples : logiciels de courrier électro-nique (Microsoft Outlook, Mozilla Thunderbird), applications sur mesure (e.g. gestionde l’inventaire).

Client léger

(Figure 1.5) Contrairement aux clients lourds, l’architecture avec client léger n’im-pose pas l’installation d’une application sur l’appareil mobile. L’application proprementdite s’exécute sur un serveur, et l’affichage et l’interaction avec l’utilisateur se font dansun fureteur Web. Le déploiement et la mise à jour de l’application en est donc simpli-fiée, puisqu’il n’est pas nécessaire de la réinstaller sur chaque appareil mobile pour cefaire. De plus en plus, les applications avec client léger s’exécutant dans un fureteurgagnent en interactivité et en ergonomie, grâce à la technologie dite Ajax17, permettantd’éviter le rechargement complet de la page Web lors de chaque interaction de l’utilisa-teur. Ce type d’architecture a l’avantage d’être indépendante du type d’appareil ciblé

17pour Asynchronous JavaScript and XML, bien que l’utilisation d’un encodage XML ne soit pasobligatoire pour réaliser ce type d’application


Appareil mobile

Requêtes

Réponses

Serveur

Application Web

Fureteur

web

Fig. 1.5 – Architecture avec client mobile léger

(puisqu’elle ne requiert qu’un fureteur Web pour fonctionner), et de ne pas nécessiterl’installation d’un logiciel sur l’appareil. Cependant, les furteurs Web de certaines pla-teformes mobiles sont relativement limités dans leur support du langage JavaScript etde la spécification complète de HTML et CSS (Cascading Style Sheet, permettant lamanipulation du rendu visuel des pages), ce qui empêche le fonctionnement de certainespages de style Ajax. De plus, la bande passante limitée inhérente à certains réseaux sans-fil peut réduire la performance des clients légers, puisque la majeure partie de ce qui estaffiché à l’écran est généré et transmis par le serveur, ce qui implique des volumes dedonnées échangées souvent plus importants qu’avec un client lourd. Exemples : GoogleMaps, Google Mail.

1.2.2.4 Architecture orientée services et environnements mobiles

Tel qu’il sera expliqué dans la sous-section suivante (cf. 1.2.3), les architectures orien-tées services (SOA — Service Oriented Architecture) et les services Web peuvent s’ap-pliquer à la conception et au développement d’applications mobiles. Ils constituent unesolution possible à certaines contraintes de mobilité, surtout en ce qui à trait aux pro-blèmes d’interopérabilité et à la gestion des connexions intermittentes lors des échangesde données entre appareils mobiles et serveurs [Duda et al., 2005; Oracle Corporation,2004; Ojala, 2005]. De plus, leur flexibilité les rendent applicables dans plusieurs typesd’architectures logicielles de clients mobiles, qu’il s’agisse d’applications autonomes avecsynchronisation (échange de documents XML entre l’appareil mobile et la station debase), de clients lourds (protocole SOAP18 pour échanges entre client et service) oude clients légers (application Web Ajax contactant un service Web pour récupérer desdonnées).

18cf. sous-section 1.2.3.2


1.2.2.5 Mobilité et géomatique

Certaines applications peuvent tirer parti de l’information de positionnement quiest inhérente à l’utilisation mobile de l’informatique. Un exemple classique se retrouvedans les logiciels de navigation routière (e.g. TomTom19), qui sont disponibles pour lesordinateurs portatifs, PDA et smartphones.

Méthodes de positionnement

Pour que de telles applications soient réalisables, un mécanisme permettant de dé-terminer la position de l’appareil doit être mis en œuvre. Plusieurs méthodes existentpour ce faire :

GPS : Le système de positionnement global (GPS — Global Positioning System) estsans doute la méthode la plus répandue pour obtenir une position. Grâce à ladisponibilité de circuits intégrés bon marché pour la réception GPS, on retrouvemaintenant des fonctionnalités de positionnement dans une foule d’appareils : ré-cepteurs GPS portatifs, systèmes de navigation routière, cartes et modules d’ex-tension GPS pour ordinateurs portables et PDA, téléphones cellulaires avec GPSintégré, etc. De tels récepteurs offrent une précision planimétrique de l’ordre demoins de 10 mètres20, ce qui est généralement adéquat pour l’utilisation qui enest faite. Cependant, la disponibilité du positionnement GPS est limitée par lacouverture des satellites ; dans un environnement très couvert (forêt dense ouzone urbaine construite en hauteur) ou encore à l’intérieur, la réception du signald’au moins quatre satellites (minimum requis pour obtenir une position) n’est pastoujours possible.

Positionnement par cellulaire : Les téléphones mobiles peuvent être positionnésgrâce au signal radio utilisé pour la communication. Une première technique, laplus simple, consiste simplement à identifier la cellule dans laquelle est situé unappareil. Puisque l’emplacement de la tour de communications desservant cettecellule est connu, on peut estimer la position de l’appareil comme étant situé dansun rayon correspondant à la zone de couverture de la cellule. Une méthode plussophistiquée fait appel à la triangulation du signal radio émis par le téléphonemobile : si au moins trois tours reçoivent ce signal, la position de l’appareil peutêtre estimée de manière plus précise [Wang et al., 2008].

Autres méthodes : Lorsque la réception d’un signal de téléphonie mobile ou GPS

19http://www.tomtom.com/20La fiche technique du circuit GPS SiRFstarIII, un des plus courants sur le marché, indique une

précision de 2.5 mètres (http://www.sirf.com/products/GSC3LPProductInsert.pdf).

http://www.tomtom.com/

http://www.sirf.com/products/GSC3LPProductInsert.pdf


n’est pas disponible, il faut se fier à d’autres méthodes. Le positionnement iner-tiel permet d’estimer à l’aide d’accéléromètres ou de gyroscopes la position toutau long d’un trajet, lorsqu’on connaît la position initiale. Cette technique a l’in-convénient d’offrir une précision qui diminue en fonction du temps écoulé de-puis le départ, puisque toute erreur systématique de l’appareil s’accumule au fildu temps [Barshan et Durrant-Whyte, 1993]. D’autres techniques font appel àdes réseaux de capteurs et de puces d’identification à radiofréquences (RFID— Radio-frequency identification) ou bien encore à l’infrastructure existantede réseau sans-fil (WiFi) pour positionner les appareils informatiques mobiles[Kolodziej et Hjelm, 2006]. Ces méthodes sont principalement applicables au po-sitionnement et à la navigation à l’intérieur des édifices.

Positionnement absolu et relatif

Les méthodes de positionnement peuvent se baser sur un système de référence absoluou relatif. Dans le cas d’un système absolu, on parle d’une référence par rapport à laTerre21. Les coordonnées sont généralement exprimées en longitude, latitude et altitude,permettant de donner une position sur n’importe quel point à la surface de la Terre (oumême dans les airs et sous terre). Le système de référence spatial (datum, e.g. WGS84pour le GPS) doit également être connu pour localiser précisément un point.

Le positionnement relatif utilise un système de coordonnées local. Les systèmes depositionnement utilisés dans les bâtiments (e.g. RFID ou par réseau sans-fil) utilisentgénéralement une référence locale. Le système de coordonnées est habituellement car-tésien (e.g. coordonnées X, Y et Z en mètres). L’origine peut être fixe ou mobile ; dansce second cas, on s’intéresse à la position d’un acteur par rapport à un autre acteur quipeut être en mouvement (e.g. position d’une personne sur un navire en mouvement).Un autre cas possible est celui où chaque acteur mobile possède son propre systèmede coordonnées local (dont il est l’origine), et les objets de son entourage sont localisésen fonction de lui-même. Dans tous les cas, il est possible de passer d’un système deréférence absolu à relatif (et vice-versa) lorsqu’on connaît l’emplacement absolu de l’ori-gine. Cela peut être utile lorsqu’on utilise une méthode de positionnement donnant descoordonnées absolues (e.g. GPS) alors que l’application requiert une position relativepar rapport à un point de référence.

21Bien entendu, il ne s’agit pas véritablement d’une référence absolue, puisque la position est donnéepar rapport au centre de la Terre.


1.2.2.6 Mobilité et OLAP

Quelques travaux de recherche existants portent sur les applications OLAP encontexte de mobilité. Cette sous-section en donne un aperçu.

Cuzzocrea et al. [2003] proposent Hand-OLAP, un système conçu pour compresserles cubes de données afin de les adapter aux contraintes des appareils mobiles. Cetteapproche fait appel à un algorithme de compression avec pertes (« lossy compression »),sacrifiant la précision des données pour réduire la taille de stockage. L’approche est éga-lement limitée à une vue bidimensionnelle du cube (e.g. tableau croisé) et aux donnéesagrégées seulement ; ainsi, l’utilisateur mobile ne peut forer jusqu’aux données détaillées.Le concept de client en mode connecté et déconnecté est abordé : lorsque la connexionau réseau sans-fil n’est plus disponible, la vue compressée stockée localement sur l’ap-pareil mobile est utilisée pour répondre aux requêtes de l’utilisateur. Toutefois, noussommes d’avis que le fait de limiter les clients OLAP mobiles à seulement deux dimen-sions, à des niveaux agrégés et à des données approximatives peut être trop restrictifpour certaines applications, par exemple dans une situation d’urgence où l’accès à desdonnées locales détaillées et précises peut s’avérer nécessaire. Nous croyons donc qu’ilest préférable d’offrir le choix des dimensions à inclure, du niveau de détail à conserveret de la précision (e.g. activer ou non la compression avec perte).

Maniatis [2004] décrit un ensemble de requis pour le OLAP mobile, énoncés en fonc-tion de certaines des contraintes des environnements informatiques mobiles (interfaceutilisateur, capacités de calcul, liens de communication). La notion de fonctionnementen mode connecté et déconnecté est aussi mentionnée : l’application doit continuer àêtre utilisable lorsqu’il y a perte de connectivité réseau. Cependant, un des requis sti-pule que seules les données hautement agrégées sont accessibles en mode déconnecté ;tel qu’expliqué au paragraphe précédent, nous croyons qu’il peut être utile de rendredisponible certaines données détaillées dans ce mode de fonctionnement.

Dans tous les cas, ces travaux de recherche ne tiennent pas compte de la dimensionspatiale des cubes de données SOLAP ; il est tout de même possible de s’en inspirer,puisque SOLAP s’appuie sur les concepts OLAP existants. Les applications SOLAP mo-biles sont un sujet de recherche nouveau ; au moment d’entamer ce projet de maîtrise,aucun travail académique ou commercial portant spécifiquement sur ce thème n’a étérecensé. Néanmoins, dans le cadre élargi du projet de recherche sur lequel porte ce mé-moire, Badard et al. [2008] proposent certains critères d’adaptation des outils SOLAPpour les environnements mobiles22. Une liste de requis portant sur l’interface utilisa-

22Cet article fut rédigé par l’équipe de recherche des professeurs Thierry Badard et Yvan Bédard,peu après le démarrage de ce projet de maîtrise.


teur sur les appareils mobiles y est donnée. Plus en lien avec le sujet de ce mémoire, leconcept de mode connecté et déconnecté est abordé, et un ensemble de services Webdestinés aux applications SOLAP mobiles y est proposé. La notion de service Web etd’architecture orientée services (SOA) est abordée plus en détail dans la sous-sectionsuivante.

1.2.3 Services Web et architecture orientée services (SOA)

1.2.3.1 Systèmes répartis, Internet et intergiciels

L’apparition des réseaux informatiques et plus particulièrement d’Internet a consi-dérablement modifié la manière de gérer les données et de réaliser les systèmes qui lestraitent. On parle maintenant de systèmes répartis, c’est-à-dire des systèmes où l’in-formation est véhiculée entre différents tiers, et ce exclusivement par des échanges demessages, via des liens de communication [Coulouris et al., 2001]. Les applications surInternet, telles que le World Wide Web, fonctionnent selon ce principe : un client, soit lefureteur Web, accède à un serveur via un lien réseau, afin de lui soumettre une requête.Le serveur répond au client en lui transmettant le document demandé. Dans le cas leplus simple, deux systèmes sont en jeu dans cet échange : le client et le serveur ; onparle alors d’architecture 2-tiers. Des situations plus complexes sont toutefois monnaiecourante : par exemple l’accès à un site dynamique transactionnel (e.g. pour le com-merce électronique), dont le contenu repose sur un serveur de base de données, impliqueau minimum trois systèmes : le client (fureteur), le serveur Web et le serveur de basede données. Le client communique avec le serveur Web, et ce dernier communique avecle serveur de base de données pour récupérer ou modifier les données demandées ousoumises par le client. Il s’agit d’une architecture 3-tiers ; cela peut se généraliser auxarchitectures n-tiers, où n systèmes entrent dans le fonctionnement d’une applicationrépartie.

Dans le cas du Web, les échanges se font par des formats et protocoles standardisés,soit HTML (Hypertext Markup Language) pour le format des documents (pages Web),HTTP (Hypertext Transfer Protocol) pour le protocole de l’application, et TCP/IP(Transmission Control Protocol / Internet Protocol) pour les protocoles de session etde réseau. L’utilisation de standards dans les échanges de données fait en sorte queles applications ne sont pas nécessairement restreintes à une plateforme matérielle etlogicielle particulière : celles-ci peuvent être utilisables sous différentes architecturesmatérielles, différents systèmes d’exploitation et environnements d’exécution, ainsi quedifférents langages de programmation.


Du point de vue de la conception et du développement des logiciels, la réalisationd’applications réparties constitue une tâche complexe. Le besoin d’échanger des donnéesentre systèmes va au-delà des applications conventionnelles d’Internet (Web, courriel,transfert de fichiers, etc.). Par exemple, les différentes banques ont besoin d’échangerentre elles, en temps réel, de l’information sur les transactions (transferts de fonds,chèques, etc.). Les systèmes logiciels mis en œuvre dans ces organisations peuvent dif-férer d’une compagnie à l’autre ; cela est également vrai pour plusieurs domaines, e.g.commerce électronique, administration publique, universités, et toute autre activité sus-ceptible d’impliquer des systèmes informatiques hétérogènes répartis en plusieurs lieux.Il importe donc d’avoir des standards permettant à ces logiciels de communiquer entreeux dans un système réparti, et ce peu importent les plateformes et les langages deprogrammation employés dans leur réalisation. Les intergiciels (middleware en anglais)existent pour faciliter cette tâche. Ceux-ci sont des couches logicielles qui dissimulentl’hétérogénéité des systèmes, et offrent un modèle de programmation uniforme pourl’échange de données entre systèmes [Coulouris et al., 2001]. Ils offrent des mécanismesd’appel de procédures à distance (RPC — Remote Procedure Call) et d’échange d’objets.Ainsi, les données d’un objet, ainsi que les fonctions associées à ces données (méthodes),peuvent être utilisées de manière transparente, peu importe si ces objets sont locaux oudistants : l’intergiciel s’occupe automatiquement de transmettre les messages d’échangede données. Plusieurs implémentations d’intergiciel existent : Sun RPC23, CORBA24,Java RMI25, Microsoft DCOM26, etc. Certains de ceux-ci sont propriétaires ; i.e. ils nesont disponibles que sur certaines plateformes et leur spécification n’est pas ouverte,limitant ainsi leur potentiel face aux systèmes répartis hétérogènes.

1.2.3.2 Services Web

Les services Web constituent une forme de technologie intergicielle, s’appuyant surdes standards ouverts principalement proposés par le World Wide Web Consortium(W3C), organisme qui publie entre autres les spécifications de HTML et de XML (eX-

tensible Markup Language). XML offre une notation permettant de représenter des do-cuments d’une manière hiérarchisée, sous forme de texte balisé [Harold et Means, 2004].Cette notation est non seulement lisible et modifiable dans n’importe quel éditeur detexte, mais elle peut également être traitée de manière relativement simple par des ou-tils automatisés, et offre une excellente interopérabilité technique avec tous les systèmesd’exploitation et langages de programmation. XML se prête bien à la représentation

23Ou sa version standardisée, ONC RPC : http://www.ietf.org/rfc/rfc1831.txt24http://www.corba.org/25http://java.sun.com/javase/technologies/core/basic/rmi/26http://www.microsoft.com/com/

http://www.ietf.org/rfc/rfc1831.txt

http://www.corba.org/

http://java.sun.com/javase/technologies/core/basic/rmi/

http://www.microsoft.com/com/


de données structurées (e.g. enregistrements d’une base de données, structures arbo-rescentes) et de documents textuels (e.g. traitement de texte, pages Web en XHTML).Cependant, il n’est pas conçu pour la représentation de données binaires non structu-rées (e.g. images matricielles, son, vidéo) ; ces contenus s’avéreraient trop volumineuxet inefficaces à traiter si encodés en XML. De plus, l’aspect auto-descriptif de XMLn’est intéressant que pour les données structurées.

Les services Web sont essentiellement un mécanisme d’échange de messages XMLdans les systèmes répartis, ce qui permet d’appeler des procédures à distance et d’échan-ger des données [Newcomer, 2002; Cerami, 2002]. Ils s’appuient sur des normes exis-tantes, soit XML comme méthode d’encodage des données, et des protocoles standar-disés comme HTTP pour l’échange des messages. Dans leur forme la plus simple, ilpeut s’agir simplement de documents XML directement échangés par des requêtes etréponses HTTP (par les méthodes GET et/ou POST). Cela signifie qu’un service estaccessible comme toute autre ressource sur le Web : il possède une adresse (ou URL —Uniform Resource Locator) et est joignable depuis tout client supportant le protocoleHTTP. La différence majeure par rapport aux autres ressources telles que les pagesWeb est que les services Web ne sont pas destinés à être utilisés directement par despersonnes, mais plutôt par d’autres systèmes qui exploitent les fonctionnalités qu’ilsoffrent.

Le W3C et d’autres consortiums industriels ont défini un ensemble de spécificationsbasées sur XML qui facilitent la conception et l’interopérabilité des services Web, offrantdes fonctionnalités étendues par rapport aux simples messages requête-réponse en XMLsur HTTP. Les plus communes sont WSDL, SOAP et UDDI :

WSDL (Web Services Description Language) : permet de décrire les services Webdans une syntaxe XML commune. Il s’agit d’une forme de métadonnées, décla-rant quelles sont les messages et opérations supportées par le service, ainsi queles informations d’adressage permettant de s’y connecter. En d’autres termes, undocument WSDL constitue un contrat de service, qui fait office de documenta-tion formelle pour les développeurs souhaitant utiliser le service (comme client)ou concevoir une nouvelle implémentation de ce service (comme serveur). Il per-met également la génération de code (ce qu’on appelle communément les stub etskeleton) dans différents langages de programmation. Dans ce sens, il occupe unefonction semblable aux langages de description d’interfaces (IDL — Interface Des-

cription Language) de CORBA et Microsoft DCOM. Finalement, WSDL s’appuiesur la spécification XML Schema [Fallside et Walmsley, 2004] pour la définitionde la structure des messages et le typage des données échangées. Un exemple dedocument WSDL est donné en annexe A (listage A.1).


SOAP (Simple Object Access Protocol) : il s’agit du protocole permettant d’échan-ger les messages entre systèmes. Ce protocole supporte plusieurs paradigmesd’échanges de messages : appel de procédure à distance (RPC), échange de do-cuments, publication et abonnement (publish-subscribe). Un message SOAP com-prend un en-tête optionnel (élément Header) ainsi qu’un corps de message conte-nant la requête ou la réponse (élément Body). Le corps d’un message de réponsepeut également contenir un élément d’erreur (Fault) si un problème a empêchél’exécution de la requête ; ainsi, le client est informé de la nature du problème.Tout comme WSDL, SOAP utilise XML Schema pour définir la structure et lestypes de données des messages. Les messages SOAP sont habituellement trans-portés via le protocole HTTP, mais il est également possible d’employer d’autresprotocoles, comme par exemple SMTP (Simple Mail Transfer Protocol) si on veutfaire l’acheminement par courrier électronique. Des exemples de requête et réponseSOAP sont donnés en annexe A (listages A.2 et A.3).

UDDI (Universal Description, Discovery and Integration) : standard publié par OASIS(Organization for the Advancement of Structured Information Standards), conçupour la description, la découverte (discovery) et l’intégration des services Web.On peut comparer UDDI à un annuaire, donnant une liste des services, selon lenom des entreprises ou organisations qui les offrent, selon la catégorie de service etselon les spécifications techniques employées dans la réalisation de ces services. Lesserveurs UDDI permettent de publier et de rechercher des services, que ce soit surun intranet d’entreprise ou bien publiquement sur Internet. Cette spécifications’inscrit donc dans le même rang que des systèmes tels que le DNS (DomainName System) ou Microsoft Active Directory, en tant que registres fournissantde l’information sur des organisations ou entités, avec l’information d’adressagenécessaire pour exploiter leurs services. Bien qu’UDDI ne soit pas strictementrequis pour le fonctionnement des services Web, il s’avère utile pour faciliter lerepérage et l’interopérabilité des services dans de grandes organisations, ou dansle cas du commerce entre entreprises.

L’appellation « services Web W3C » fait référence aux services Web conformes auxspécifications du W3C, soit SOAP et WSDL. Il s’agit de la plateforme la plus courantepour la conception de systèmes selon les principes de l’architecture orientée services. Ilimporte de mentionner qu’il existe d’autres formes de services Web qui ne suivent pasexactement les spécifications du W3C. Par exemple, les services de type POX/HTTP(Plain Old XML over HTTP), dans lesquels des messages XML sont transmis directe-


ment dans les requêtes et réponses HTTP27 sans encapsulation SOAP, sont une autrevariante de services Web. La même gamme de fonctionnalités qu’on retrouve dans lesservices de style W3C peut être offerte par ce type de service ; la différence se situe dansles protocoles utilisés pour l’encapsulation des messages et les conventions d’appel deces services. La plupart des spécifications de services Web géomatiques de l’OGC (voirsection 1.2.4.1) proposent des interfaces POX/HTTP, bien que les versions récentes deces spécifications supportent également le protocole SOAP.

1.2.3.3 Architecture orientée services

Une architecture orientée services (SOA — Service Oriented Architecture) est avanttout une méthodologie de conception des systèmes informatiques organisationnels baséesur la notion de service [Newcomer et Lomow, 2004]. Un service est, à la base, unensemble de fonctionnalités accomplissant des tâches spécifiques, accessible par réseau.Ces fonctionnalités sont généralement alignées sur des processus organisationnels (i.e.règles d’affaires) ; la définition des tâches qu’un service peut effectuer, ainsi que de lastructure des données échangées, constitue le contrat de service. D’un point de vuepratique, un système conçu selon les principes des architectures orientées services meten œuvre des services Web pour réaliser les différents blocs de fonctionnalités.

Afin de maximiser l’interopérabilité et la réutilisation, les services doivent comporterun couplage faible, c’est-à-dire que l’interface exposée aux clients ne doit pas dépendrede l’implémentation sous-jacente. Un corollaire de ce couplage faible est que le niveaud’abstraction des services de style SOA est relativement élevé : ils réalisent un bloc defonctionnalités plus important que ce que fait généralement un simple appel de procé-dure. Ceci a pour avantage de réduire le nombre d’appels nécessaires pour accomplirune tâche, limitant ainsi le surcoût des échanges sur le réseau. D’autres caractéristiquessouhaitables pour les services SOA sont d’avoir une interface publique bien définie (e.g.par un contrat WSDL), et d’être basés sur des normes ouvertes et bien établies (e.g.celles du W3C).

Une architecture orientée services exploite la notion de service, en combinant cesderniers dans un système plus ou moins complexe visant à distribuer les responsabili-tés. Par exemple, un commerce sur Internet pourrait mettre en œuvre une architecture

27Ce style de services Web est souvent nommé à tort REST, pour REpresentational State Transfer,alors que ce terme dénote un type d’architecture logicielle pour les systèmes en réseau [Fielding,2000]. Le Web en général s’appuie sur les principes de REST ; certains services Web POX/HTTP sontégalement conformes à ce style architectural. Cependant, les interactions du type appel de procédureà distance (RPC) ne sont pas considérées comme étant conformes aux principes de REST.


orientée services de la manière suivante : un service pour les commandes, un pour lagestion d’inventaire et un pour l’expédition. Un client qui achète un article procèdepar un site web présentant une interface conviviale pour les divers services. En premierlieu, la transaction est traitée par le service de commandes : on lui donne l’identifiantd’un article et la quantité désirée. Celui-ci s’occupe d’invoquer le service d’inventaire,pour déterminer si l’article voulu est en stock. D’autres services extérieurs peuvent êtreappelés, par exemple pour effectuer le paiement par une institution financière ou parcarte de crédit. Une fois que la transaction est autorisée par le service de commande, etque les articles achetés sont réservés par le service d’inventaire, le service d’expéditionest invoqué ; on lui donne les coordonnées du client (adresse d’expédition), l’identifiantde la transaction et la description des articles commandés, puis un bon d’expéditionest automatiquement acheminé à l’entrepôt chargé de préparer et d’expédier la mar-chandise. Notons que chaque service peut s’exécuter sur un ordinateur différent, et lesservices peuvent aussi être distribués à divers emplacements géographiques.

On distingue trois rôles distincts dans une architecture orientée services :

Les fournisseurs de services : ils implémentent les fonctionnalités décrites dans lecontrat de service. Ce sont eux qui rendent accessible la logique d’application auxconsommateurs de services, via des liens réseaux.

Les consommateurs de services : ils invoquent les services offerts par les fournis-seurs. Il peut s’agir soit d’applications clientes (e.g. un tableau de bord sur unPC de bureau, indiquant l’évolution des indices boursiers provenant en temps réeld’un service Web) ou bien soit de services qui s’appuient sur la fonctionnalité d’unautre fournisseur de service (e.g. un service Web d’agrégation des indices bour-siers, contactant les services de plusieurs bourses afin de calculer des indicateursagrégés pour les publier auprès des clients).

Les médiateurs : il s’agit de répertoires qui ont pour but de faciliter la découverteet l’invocation des services (e.g. un catalogue UDDI). De cette manière, ils s’in-tercalent entre les fournisseurs et les consommateurs de services, afin d’aider cesderniers à repérer et invoquer les services qui correspondent à leurs besoins. Enpratique, le rôle de médiateur est optionnel ; plusieurs systèmes basés sur les ser-vices Web se contentent d’un couplage direct entre consommateurs et fournisseurs.

Les architectures orientées services ainsi que leur réalisation sous forme de servicesWeb ont comme avantage de favoriser la réutilisation de composants logiciels, et fa-cilitent également l’intégration de systèmes hétérogènes. De ce fait, les efforts et lescoûts de développement sont réduits. Dans un contexte de mobilité, la solution qu’ilsapportent face aux problèmes d’interopérabilité est essentielle : toute plateforme mo-bile, peu importe le matériel ou le système d’exploitation, a la capacité d’interagir de


manière uniforme avec les services Web. Leur support des communications asynchronesles rendent également bien adaptés aux réseaux sans-fil qui ne peuvent garantir desconnexions persistantes [Badard et al., 2008] : chaque requête étant indépendante l’unede l’autre, le client peut contacter le service au moment opportun, lorsque la connecti-vité réseau est disponible. Il n’est pas nécessaire d’établir une connexion persistante etde gérer des sessions, contrairement à ce qui se fait dans les architectures client-serveurtraditionnelles, et le client peut continuer à fonctionner entre deux appels au service,même lorsque la connectivité réseau est coupée. Un point également important concernela répartition des rôles dans une architecture orientée services : il est possible de délé-guer à un service les traitements plus complexes (consommateurs de temps processeur),au lieu de les réaliser à même l’appareil mobile. De cette manière, un puissant serveurqui héberge le service arrivera à exécuter ce traitement en moins de temps que l’appareilmobile, qui comporte un processeur plus lent et une mémoire vive limitée [Duda et al.,2005].

1.2.4 Applications des services Web : géomatique et informa-tique décisionnelle

1.2.4.1 Les services Web en géomatique

Dans le domaine de la géomatique, l’Open Geospatial Consortium (OGC) proposeplusieurs spécifications de services Web, servant principalement à la diffusion des don-nées spatiales sur Internet. Les deux spécifications les plus communes sont les suivantes :

Web Map Service (WMS) : permet la diffusion de cartes créées à la volée. Le clientdemande un thème, une emprise et optionnellement des paramètres de style, deprojection et de format de sortie. Le service fait alors le rendu et retourne unecarte en format raster (e.g. GIF, JPEG ou PNG) ou vectoriel (SVG — Scalable

Vector Graphics, soit une notation XML proposée par le W3C pour les graphiquesvectoriels 2D). Les données retournées ne sont pas des entités cartographiques entant que telles, mais plutôt leur représentation cartographique destinée à l’affi-chage [OGC, 2002].

Web Feature Service (WFS) : offre une interface pour l’interrogation d’entrepôtsd’entités géographiques. Dans la majorité des implémentations, les entités sontencodées en GML (Geography Markup Language, soit une autre spécificationISO/OGC permettant l’encodage en XML d’entités géographiques vectorielles,ainsi que de leurs attributs descriptifs [ISO/TC211, 2004]). Les versions récentes


de WFS supportent également les opérations transactionnelles, soit l’ajout, lasuppression ou la modification d’entités [OGC, 2005b].

Cependant, ces spécifications ne sont pas conçues pour le transfert de cubes dedonnées multidimensionnelles. WMS permet la diffusion de cartes, mais pas des don-nées (entités) à la source de ces cartes. WFS quant à lui est spécifique aux donnéestransactionnelles, et ne supporte pas les concepts du modèle multidimensionnel (i.e.dimensions, membres, mesures et faits). GML, par contre, est une norme intéressante,puisqu’elle concerne la représentation XML des données spatiales vectorielles. Un usagepossible dans une application SOLAP répartie serait l’échange en XML, via un serviceWeb, des membres géométriques des dimensions spatiales.

1.2.4.2 Services Web pour OLAP

Les applications OLAP s’appuyant sur les principes des architectures orientées ser-vices sont susceptibles d’utiliser des solutions technologiques existantes pour ce qui estde l’interrogation et de l’échange de données OLAP par l’intermédiaire de services Web,en utilisant des encodages XML. Deux de ces solutions technologiques, soit XML forAnalysis et XCube, sont présentées dans cette section.

XML for Analysis (XMLA)

L’une des solutions est une spécification de service Web pour l’interrogation descubes de données OLAP, proposée par Microsoft et Hyperion et nommée XML forAnalysis (XMLA) [Microsoft et Hyperion, 2002]. Elle est basée sur le protocole SOAP,et utilise le langage d’interrogation mdXML, qui est simplement une encapsulation enXML de requêtes MDX (MultiDimensional eXpressions, voir sous-section 1.2.1.2). Leschéma de données de XMLA est fortement inspiré du modèle objet OLE DB for OLAP

[Microsoft Corporation, 2007b]. Il s’agit donc d’une spécification de service en partiecouplée à son implémentation, soit SQL Server Analysis Services, le serveur OLAPde Microsoft. Cependant, il existe d’autres implémentations qui sont compatibles avecXMLA. C’est le cas de Mondrian, un serveur OLAP open source [Pentaho Corporation,2007].

XCube

D’un autre côté, un format XML d’échange de données multidimensionnelles a étéproposé ; il s’agit de XCube [Hümmer et al., 2003]. Il définit une série de schémas XML


pour encoder les objets des jeux de données multidimensionnelles, tels que les cubes,dimensions, hiérarchies, niveaux, membres et mesures. Bien qu’il ne s’agisse pas d’unespécification de service Web proprement dite, les éléments XML proposés dans XCubepeuvent être encapsulés à l’intérieur de messages SOAP lors de la réalisation d’un serviceWeb.

1.2.4.3 Les services Web en géomatique décisionnelle

Application de XMLA et XCube dans un contexte SOLAP

La réalisation d’une application SOLAP mobile nécessite un moyen de disséminerles cubes de données SOLAP vers les appareils mobiles. Dans le cas d’une applica-tion SOLAP fonctionnant en mode déconnecté, c’est-à-dire lorsqu’une connexion ré-seau n’est pas disponible, la diffusion de cubes de données suffisamment complets pourêtre consultés de manière autonome devient nécessaire. Or, dans leur version actuelle,les deux solutions technologiques énumérées (XMLA et XCube) s’avèrent insuffisantespour diffuser des cubes de données spatiales multidimensionnelles. XMLA propose unmécanisme d’interrogation des données, mais son format de livraison de données estconçu pour la présentation d’un résultat de requête (exploitable par exemple pour laconstitution de différents affichages : histogrammes, camemberts, tableaux croisés), etnon la transmission de cubes complets (comprenant structure et données). XCube ré-pond mieux à ce critère, mais tout comme XMLA, il ne propose pas de solution pourl’échange des entités géographiques (comprenant des primitives géométriques) des cubesde données SOLAP.

Un exemple de service Web pour SOLAP : GMLA

La littérature actuelle ne contient que très peu de travaux concernant les servicesWeb et les architectures orientées services dans le contexte des applications SOLAP.Un travail de recherche relatif à ce sujet a toutefois été répertorié. Il s’agit d’une réa-lisation d’un service Web, nommé GMLA (GML for Analysis), offrant des opérationspour réaliser des requêtes analytiques (i.e. OLAP) ou géographiques, sur des sources dedonnées multidimensionnelles et géographiques [da Silva et al., 2005]. L’aspect le plusnovateur de cette approche est que l’interrogation et la livraison des données se fait enutilisant des spécifications ouvertes et basées sur XML, soit XMLA, GML et WFS, cequi est conforme aux principes des architectures orientées services. Toutefois, il s’agitd’une approche SIG + OLAP, où les données géographiques et multidimensionnelles


sont interrogées selon des mécanismes différents28. Les membres spatiaux ne sont doncpas intégrés aux cubes ; l’implémentation utilise plutôt des serveurs XMLA et WFS dis-tincts, et l’ajout de la géométrie aux membres spatiaux est faite par le service GMLAlors de l’envoi des données au client. De plus, puisqu’il s’agit d’une extension au serviceXML for Analysis, les mécanismes d’interrogation et le format de livraison sont pré-vus pour la présentation d’un résultat de requête plutôt que pour l’échange de cubescomplets.

1.3 Problématique

Comme il a été énoncé, les applications SOLAP actuelles (e.g. JMap Spatial OLAP)sont conçues pour les environnements informatiques de bureau, dans un contexte sé-dentaire. Elles nécessitent certaines adaptations afin de supporter les environnementsmobiles. Ces adaptations visent à répondre aux contraintes de mobilité énoncées à lasection 1.2.2. Or, dans leur état actuel, les implémentations de SOLAP ne parviennentpas à satisfaire ces contraintes29. Les composantes d’une solution SOLAP qui posentproblème sont les suivantes :

Client SOLAP : le client est l’interface permettant à l’utilisateur de consulter les don-nées des cubes SOLAP. Il peut prendre plusieurs formes : application dédiée (e.g.JMap Spatial OLAP), client Web, intégration dans une autre application (e.g. ta-bleur ou SIG). Les clients SOLAP actuels sont conçus en fonction d’une interfaceutilisateur de bureau, i.e. avec une grande taille d’affichage et l’utilisation du cla-vier et de la souris comme méthodes d’entrée. Ce type d’interface utilisateur n’estpas adéquat dans le cas de plusieurs types d’appareils mobiles (PDA, téléphonemobile), vu les affichages plus petits et les méthodes d’entrée différentes. De plus,les membres spatiaux ayant des représentations cartographiques dont le niveaude détail est trop complexe soulèvent certains problèmes de visualisation sur desaffichages de petite taille et de résolution limitée [Reichenbacher, 2001].

Cubes de données SOLAP : les cubes de données utilisés dans les applications SO-LAP peuvent être de taille imposante ; il n’est pas rare qu’ils atteignent quelques

28L’architecture de GMLA permet le stockage des géométries et des données multidimensionnelles ducube dans un seul et même entrepôt de données, si le SGBD utilisé comporte une cartouche spatiale ;dans ce cas l’interrogation se fait quand même par l’intermédiaire de deux mécanismes différents, soitdes serveurs WFS et OLAP.

29soit l’interface utilisateur et les méthodes d’entrée, les capacités de calcul, de stockage et d’alimen-tation électrique, les liens de communication et l’interopérabilité entre systèmes. Voir la sous-section1.2.2.2.


giga-octets. Que l’application soit basée sur une technologie ROLAP ou MOLAP(cf. 1.2.1.2, « Architectures ROLAP et MOLAP »), elle demande un espace disquesuffisant, ainsi que l’accès continu à un système de gestion de base de données re-lationnel (SGBDR) ou autre mécanisme d’accès performant (i.e. serveur OLAP).Dans un environnement mobile, la capacité de stockage n’est souvent pas suffi-sante pour emmagasiner de tels cubes dans leur intégralité. De plus, les connexionsréseau sans-fil ne sont pas toujours constantes et de qualité adéquate, ce qui peutempêcher l’accès continu au serveur SGBDR ou OLAP. Il est donc pertinent d’of-frir une forme de stockage locale des données SOLAP sur l’appareil mobile, touten considérant qu’il est impossible d’y conserver les cubes en entier. Cela néces-site également de disposer d’une architecture technologique ad-hoc supportant lespotentielles déconnexions.

Architecture logicielle : la majorité des applications OLAP et SOLAP actuelles (ycompris JMap Spatial OLAP) sont déployées sous une architecture client-serveur.Les clients se connectent à un serveur, qui s’occupe d’exécuter les requêtes enrécupérant les données demandées depuis le cube, et en les acheminant au client.Ainsi plusieurs clients peuvent se partager l’accès aux cubes. Chaque requête duclient est traitée par le serveur ; ainsi, une connexion persistante doit être établiepour toute la durée d’utilisation de l’application. Tel qu’énoncé précédemment,la connectivité réseau en environnement mobile rend ce type d’architecture in-adéquat. Le mécanisme de transfert des données SOLAP entre client mobile etserveur doit donc tenir compte de la nature asynchrone des communications.

Il apparait donc que toutes les composantes d’une application SOLAP, telles querencontrées dans un environnement informatique de bureau, ne sont pas adéquates pourles mettre en œuvre dans un environnement mobile, sans devoir leur apporter certainschangements. Ce projet de recherche se penchera principalement sur l’adaptation descubes de données SOLAP et de l’architecture logicielle servant à livrer ces cubes. Celaimplique de concevoir et de développer un ensemble d’opérateurs pour réduire la tailledes cubes30 et pour transformer les données afin de les adapter face aux contraintes demobilité, en tenant compte des besoins et du contexte des utilisateurs. Cet ensembled’opérateurs vise effectivement à produire les mini-cubes, soit des cubes SOLAP de tailleréduite adaptés aux environnements mobiles. Il s’agit d’une première étape à accomplir,préalable à la conception d’une interface utilisateur appropriée pour un client mobile,dans le but ultime de concevoir et mettre au point une solution SOLAP mobile complète.

30Réduire, sans ce sens, ne veut pas simplement dire compresser les données : on souhaite ne retenirqu’un sous-ensemble des données du cube pour les transmettre à l’appareil mobile.


1.4 Objectifs

1.4.1 Objectif général

Ce travail de maîtrise a pour objectif général de concevoir et de mettre en œuvre unearchitecture pour la diffusion des données géo-décisionnelles à destination des clientsmobiles. Ainsi, ce travail doit mener à la conception et à la réalisation de l’infrastructuretechnologique nécessaire pour supporter l’aide à la décision géomatique en mobilité.Il est à noter que le développement d’un client SOLAP mobile, avec une interfaceutilisateur adaptée aux contraintes des plateformes telles que PDA ou téléphone mobile,ne fait pas partie des objectifs de ce projet. L’architecture logicielle mise au point lorsde ce projet sera toutefois nécessaire à l’élaboration future d’un tel client.

1.4.2 Objectifs spécifiques

La démarche de recherche peut être décomposée en trois objectifs spécifiques :

– Évaluer les contraintes reliées aux environnements mobiles en géomatique, et dé-terminer leur impact sur l’adaptation des outils SOLAP à ces environnements.

– Élaborer une méthode pour adapter les cubes de données SOLAP aux environ-nements mobiles, afin de satisfaire les contraintes de mobilité. Il s’agit donc dedéfinir le concept de mini-cube, i.e. un cube de données adapté aux plateformesmobiles.

– Réaliser une infrastructure technologique pour supporter le SOLAP mobile. Cecicomprend tous les éléments logiciels et services nécessaires à la constitution desmini-cubes, ainsi que leur diffusion via des liens de communication (Internet,réseau sans-fil).

1.5 Méthodologie

Puisque ce projet comporte une part importante de développement et de prototy-page, la méthode retenue pour atteindre les objectifs s’inspire fortement du monde dugénie logiciel. La figure 1.6 montre les principales activités qui composent le projet.

En première phase du projet, une revue de littérature a été entreprise. Cette revue


Début

Conceptualisation de la méthode de constitution des mini-cubes

Analyse du problème

Revue des outils logiciels

Revue de littérature

Conception et modélisation de l’architecture du service

Adaptation d’un entrepôt de données de test

Développement du service Web (basé sur serveur OLAP)

et du format XML pour mini-cubes

Tests et validation

Rédaction des articleset du mémoire

Fin

Expérimentation avecune approche ETL

(1ère itération) (2e itération)

(retour partiel sur certains concepts)

Fig. 1.6 – Phases du projet


comprend deux volets : une étude des principes technologiques à mettre en œuvre (i.e.informatique décisionnelle, OLAP et SOLAP, informatique mobile et services Web)ainsi qu’une revue d’articles scientifiques portant sur des travaux connexes. Ainsi, lesbases théoriques sur lesquelles asseoir ce projet furent posées.

Une analyse du problème a été effectuée en parallèle avec la revue de littérature ;cette analyse fut raffinée au fur et à mesure de l’acquisition des concepts. Il s’agit icid’évaluer les contraintes des environnements informatiques mobiles, de comprendre leurimpact sur les applications SOLAP et de dresser les principes généraux de la solutionlogicielle. Ceci a ouvert la voie à une revue des technologies logicielles, telles que lesoutils ETL et les serveurs OLAP, afin de concrétiser les choix technologiques intervenantdans le développement d’une solution.

Après cette phase de démarrage du projet, la conceptualisation d’une méthode pourla constitution des mini-cubes fut entamée. Cette méthode vise à répondre à la pro-blématique de définir les opérateurs permettant de réduire la taille des cubes et de lesadapter aux environnements mobiles. Le chapitre 2 du mémoire porte principalementsur l’élaboration de cette méthode.

Les activités suivantes comprennent la conception et la modélisation de l’architecturelogicielle et des structures de données nécessaires pour le service et l’expérimentationavec une approche ETL. Il a été décidé de ne pas retenir cette avenue pour le prototy-page31. Un bouclage sur les phases précédentes a donc été fait, en prenant une approchebasée sur les fonctionnalités d’un serveur OLAP. Cela a mené aux phases suivantes, soit :l’adaptation d’un entrepôt de données à des fins de tests, le développement itératif duservice Web et du format XML de livraison de mini-cubes, ainsi que la validation etles tests. En parallèle avec ce développement, la rédaction d’articles scientifiques futentreprise, chaque article portant sur des concepts faisant partie de la solution. Versla fin de l’élaboration du prototype, la rédaction de ce mémoire fut entamée. Quelquesretours partiels sur les phases précédentes ont eu lieu, afin de construire graduellementle prototype, élaborer les concepts de manière itérative et pour aller puiser dans la lit-térature de nouveaux éléments théoriques alimentant la conception. Le chapitre 3 porteessentiellement sur la modélisation du service Web et du format XML de livraison, alorsque le chapitre 4 porte sur sa réalisation sous forme de prototype.

31Ce choix sera expliqué dans le chapitre 2 ; l’expérimentation avec l’approche ETL a tout de mêmemené au développement d’un outil ETL adapté aux données spatiales, soit GeoKettle.


1.6 Structure du document

Ce document prend la forme d’un mémoire par articles : les deux chapitres suivantsseront constitués d’articles scientifiques, dont la publication a été acceptée. Les articlessont présentés de manière intégrale : le contenu y est en entier, tel que soumis pourpublication ; par contre, le format de présentation et la mise en page ont été adaptés pourcorrespondre à ceux du mémoire. Il importe de mentionner qu’une partie du contenu deces articles paraîtra redondant, surtout en ce qui concerne les concepts technologiqueset la revue des travaux existants, déjà abordés lors ce premier chapitre. La présentationde l’article au début de chaque chapitre porte sur le nouveau contenu apporté, afin demieux guider le lecteur et attirer son attention vers les parties pertinentes de l’article.Les chapitres s’articulant autour des articles sont également suivis de complémentsd’information, décrivant des notions complémentaires, des remises en perspective etune discussion du contenu. Ces compléments permettent d’aborder les points qui n’ontpu être décrits en détail dans les articles, et d’apporter un regard critique sur certainsaspects de ceux-ci.

Le chapitre 2, basé sur l’article « Service Web de constitution en temps réel de mini-cubes SOLAP pour clients mobiles », décrit de manière plus détaillée l’architecture duservice Web de constitution de mini-cubes. Les opérateurs de constitution de mini-cubesy sont définis. Une description conceptuelle du prototype de service basé sur un serveurOLAP est introduite, comprenant entre autres le contrat de service, soit l’interface deprogrammation mettant à disposition les fonctionnalités du service. En complément àl’article, on retrouve des précisions supplémentaires sur la solution proposée par rapportaux contraintes de mobilité, la définition d’un métamodèle de données représentant lesobjets génériques d’un cube SOLAP, des explications approfondies sur les opérateurs deconstitution de mini-cubes, ainsi qu’une discussion sur les limites de l’approche et surle choix d’une technologie sous-jacente (ETL ou OLAP) pour la réalisation du service.Une brève conclusion vient clore le chapitre, afin de souligner les principaux apports etles perspectives ayant trait à l’architecture proposée.

Le chapitre 3 contient l’article « An interoperable XML encoding for the exchange ofSpatial OLAP data cubes in SOA environments », portant sur un nouvel encodage XMLpour la livraison des cubes de données SOLAP. On y décrit les requis d’un tel formatainsi que le schéma de données et on y mentionne une utilisation possible sous forme deservice Web de constitution de mini-cubes. Les compléments à cet article portent surune description détaillée du contrat de service (WSDL) du service de constitution demini-cubes, avec des exemples de requêtes et de réponses. Finalement, pour conclure lechapitre, on énonce les limites de l’encodage et du service, et on propose en ouverture


quelques pistes de solution.

Le chapitre 4 décrit de manière détaillée le prototype de service Web de constitutionde mini-cubes, c’est-à-dire les choix technologiques qui ont été posés, son architecturelogicielle, les résultats des tests qui ont été réalisés et finalement les limites du prototype.

Finalement, la conclusion vient rappeler les principaux apports de ce projet, et donnequelques perspectives de recherche.

Chapitre 2

Définition des requis et del’architecture du système

2.1 Introduction

Ce chapitre contient la description détaillée de l’architecture technologique visant àproduire les mini-cubes et les livrer aux clients SOLAP mobiles. Cette architecture estpositionnée par rapport aux besoins (cf. contraintes de mobilité, 1.2.2.2, ainsi que 2.2.2.2dans l’article) et aux cas d’utilisation d’un client SOLAP mobile en mode déconnecté(cf. 2.2.3.1), i.e. qui doit pouvoir continuer à fonctionner même lorsque la connectivitéréseau est inaccessible. Les principes conceptuels reliés à la constitution des mini-cubesy sont également introduits (cf. 2.2.3.2), avec la proposition d’une série d’opérateurspermettant la construction de ces mini-cubes à partir des cubes SOLAP existants. Deuxapproches possibles pour l’architecture du service sont énoncées, et quelques servicesWeb auxiliaires qui pourraient venir étendre les fonctionnalités du service de constitu-tion de mini-cubes sont proposés (cf. 2.2.3.3). Finalement, l’architecture générale d’unprototype du service Web est décrite, avec une brève description des opérations ducontrat de service (cf. 2.2.4). Au moment de soumettre l’article pour publication, le dé-veloppement du prototype n’était pas terminé ; les compléments à l’article (cf. section2.3) ainsi que les chapitres 3 et 4 viennent approfondir les concepts sur le contrat deservice Web et le prototype.

Chapitre 2. Définition des requis et de l’architecture du système 39

2.1.1 Contributions

L’article constituant le corps de ce chapitre est référencé ci-dessous.

[Dubé et al., 2007] Dubé, E., T. Badard et Y. Bédard. 2007, « Service Web de consti-tution en temps réel de mini-cubes SOLAP pour clients mobiles — Une architectureorientée services pour l’utilisation mobile des données géo-décisionnelles », dans SA-

GEO 2007, Rencontres internationales Géomatique et territoire (CD-ROM), Clermont-Ferrand, France, ISBN 978-2-85710-078-2.


2.2 Corps de l’article

Titre : Service Web de constitution en temps réel de mini-cubes SOLAP pour clientsmobiles — Une architecture orientée services pour l’utilisation mobile des données géo-décisionnelles.


Résumé : Les applications Spatial OLAP (SOLAP) réalisées jusqu’à présent sontconçues pour les environnements informatiques de bureau. Dans le but de supporterl’aide à la décision géospatiale en situation de mobilité, certaines adaptations à SOLAPsont nécessaires. Cet article décrit une solution, basée sur les architectures orientées ser-vices et les technologies des services Web, pour adapter les cubes de données SOLAPafin de répondre aux exigences et contraintes reliées aux environnements informatiquesmobiles et aux réseaux sans-fil.

Abstract: Existing Spatial OLAP (SOLAP) applications are targeted towards desk-top computer environments. In order to enable geospatial decision support in mobilitycontexts, SOLAP requires some modifications. This paper describes a solution, basedon service-oriented architectures and Web services technologies, designed to adapt SO-LAP data cubes to the requirements and constraints encountered in mobile computingenvironments and wireless networks.

Mots-clés : Spatial OLAP, SOLAP, entrepôt de données géospatiales décisionnelles,informatique mobile sans-fil, service Web, architecture orientée service.

Keywords: Spatial OLAP, SOLAP, geospatial decisional data warehouse, wirelessmobile computing, Web service, service-oriented architecture.

2.2.1 Introduction

Depuis le milieu des années 1990, une catégorie de systèmes d’aide à la décisionexiste sur le marché : il s’agit des outils OLAP, pour On-Line Analytical Processing,permettant d’effectuer une analyse exploratoire des données de manière rapide, inter-active et conviviale. Ces logiciels font partie du domaine appelé Business Intelligence(BI), soit « intelligence d’affaires » ou « informatique décisionnelle », et découlent dubesoin des entreprises et organisations d’appuyer les processus de prise de décisionssur un éventail de données et d’analyses les plus complètes et globales que possible.


Or, les outils OLAP traditionnels sont limités dans leur capacité à traiter et à repré-senter l’information géographique. Une nouvelle classe d’outils, regroupant certainesfonctionnalités des systèmes d’information géographiques (SIG) avec celles d’OLAP, aété développée afin de tirer profit de la composante spatiale ; il s’agit du Spatial OLAP,ou SOLAP [Bédard et al., 2005].

D’un autre côté, l’informatique mobile a fait des avancées considérables au coursde la dernière décennie : on peut le constater avec l’ubiquité des appareils tels queles téléphones mobiles, ordinateurs portatifs et de poche (PDA) pouvant se connecteraux réseaux sans fils, qu’il s’agisse de téléphonie cellulaire ou de réseaux WiFi. Ainsi,les multiples services offerts via Internet sont désormais accessibles en tout lieu et entout temps, au creux de la main. En parallèle, l’évolution du commerce électronique etautres systèmes répartis sur Internet ont donné naissance à un paradigme architecturalainsi qu’une série de protocoles de communication : il s’agit des architectures orien-tées services et des services Web. Ces technologies s’inspirent des principes du Web etdes forces du langage XML pour offrir des moyens de communication efficaces entresystèmes n-tiers sur Internet. Dans le monde de la géomatique, on retrouve ces techno-logies dans les spécifications de l’Open Geospatial Consortium, qui sont utilisées dansle développement d’applications de cartographie sur Internet (web mapping) et la miseen œuvre d’infrastructures de données spatiales.

Les applications SOLAP actuelles sont conçues pour les environnements informa-tiques de bureau. Afin d’aider à la prise de décision en situation de mobilité, soit sur leterrain (e.g. domaines des urgences, de la sécurité publique et de la défense), il seraitsouhaitable d’offrir des versions mobiles de ces applications. Or, les environnementsinformatiques mobiles imposent certaines contraintes : des affichages de taille réduite,des méthodes d’entrées différentes (ex. stylet) ne permettant pas par exemple une saisiefacile et rapide de texte, ce qui nécessite de repenser les interfaces et les interactionsavec les applications. A cela vient s’ajouter des liens de communication sans-fil au débitréduit, à la latence élevée et d’une couverture incomplète, ainsi que des capacités de sto-ckage et de calcul réduites [Duda et al., 2005]. Il en résulte que les applications SOLAPnécessitent certaines adaptations pour répondre à ces contraintes de mobilité. Cet ar-ticle propose une architecture orientée services Web pour la constitution de mini-cubesde données SOLAP, visant à adapter les données SOLAP aux besoins et contraintes desenvironnements mobiles, et à assurer leur diffusion vers les clients mobiles de manièreinteropérable, via des liens de communications sans-fil. La conception d’une telle solu-tion s’inscrit comme une première étape préalable à la définition et à la mise en œuvred’un client SOLAP mobile complet.

L’article se divise comme suit : nous débutons par une revue des concepts mis


en œuvre et de leur problématique par rapport aux contextes mobiles. Par la suite,une architecture orientée service est proposée, avec des explications qui guideront ledéveloppement d’un prototype de service Web pour constitution de mini-cubes SOLAP.Finalement, les travaux de recherche à venir ainsi que certaines perspectives futures sontprésentées.

2.2.2 Concepts et problématique

2.2.2.1 Concepts d’OLAP et des entrepôts de données décisionnelles

OLAP (On-Line Analytical Processing) est défini comme étant « ... le nom donné àl’analyse dynamique requise pour créer, manipuler, animer et synthétiser l’information,par des modèles d’analyse de données exégétiques, contemplatifs et selon des formules »(traduction libre ; Codd et al. [1993]). En d’autres termes, il s’agit d’applications demodélisation descriptive et d’analyse exploratoire des données, conçues à des fins deprise de décision. Les systèmes OLAP sont optimisés pour l’analyse rapide de grandsvolumes de données, par opposition aux systèmes transactionnels (ou OLTP ; On-Line

Transactional Processing). Ces derniers sont plutôt destinés aux opérations courantesd’une organisation (ex. ventes, commandes, réservations, etc.), et sont adaptés à degrands volumes de transactions en lecture et en écriture, chaque transaction indivi-duelle n’affectant qu’une petite quantité de données [Thomsen, 2002]. Les outils OLAPs’appuient sur le modèle de données multidimensionnel, où les données sont représentéesen termes de dimensions, mesures et faits. Les dimensions constituent des axes théma-tiques caractérisant les données (ex. le temps, les lieux, les catégories de produits).Une dimension est composée de membres, représentant les occurrences individuelles duthème (ex. « France », « Belgique », « Canada »). Les membres peuvent être organisésselon différents niveaux de détail, de manière hiérarchique. Quant aux mesures, ellesreprésentent les valeurs quantifiables relevées pour les données (ex. la population, leproduit intérieur brut). Les combinaisons possibles des dimensions, avec les mesuresqui en découlent, forment les faits. Il est possible d’appliquer des fonctions agrégatives(somme, moyenne, médiane, etc.) pour obtenir les mesures à partir des données tran-sactionnelles ou de mesures de membres de niveau inférieur. Ainsi, on peut calculer unevaleur pour un fait caractérisé par les membres d’une dimension du niveau hiérarchiqueinférieur qui s’agrègent vers un membre d’un niveau supérieur (ex. la population duCanada est la somme de la population de chacune de ses provinces). Un jeu de don-nées multidimensionnelles est nommé « cube » ou « hypercube », en faisant référence à


l’organisation des faits selon des axes dimensionnels1.

De nombreuses applications OLAP font usage d’un entrepôt de données décision-nelles pour le stockage des cubes. Ceux-ci sont généralement basés sur des systèmesde gestion de bases de données (SGBD) relationnels, par exemple des serveurs telsqu’Oracle, Microsoft SQL Server, MySQL AB ou PostgreSQL, ou des SGBD enrichistels NCR Terradata, Kognitio et Sand Technologies. Les données des cubes sont or-ganisées selon un modèle multidimensionnel (schémas en étoile, en flocon ou parent-enfant), dont les principes diffèrent des modèles relationnels normalisés des systèmestransactionnels [Kimball et Ross, 2002]. Le peuplement et la mise à jour des entre-pôts de données décisionnelless sont faits depuis diverses sources de données opération-nelles. Des outils nommés ETL (Extract, Transform, Load), permettant l’extraction, latransformation et le chargement de données, sont fréquemment employés pour ce faire[Kimball et Caserta, 2004].

Plusieurs produits OLAP disponibles sur le marché offrent des langages d’interroga-tion adaptés aux données multidimensionnelles ; par exemple le langage MDX (Multi-

dimensional eXpresssions), introduit par Microsoft avec SQL Server Analysis Services[Microsoft Corporation, 2007a] mais aussi employé par d’autres produits tels que Hy-perion Essbase et le serveur OLAP open source Mondrian [Pentaho Corporation, 2007].De tels langages sont aux données multidimensionnelles ce que le langage d’interroga-tion SQL est aux données relationnelles. Des clients OLAP présentant une interfaceutilisateur conviviale existent également. Ceux-ci offrent une vue des données multi-dimensionnelles sous forme de tableaux, graphiques et rapports, et permettent la na-vigation visuelle dans les cubes de données avec des opérateurs tels que le forage etremontage (drill-down, roll-up), sans avoir à connaître un langage d’interrogation desdonnées.

2.2.2.2 Spatial OLAP : d’un environnement sédentaire jusqu’à la mobilité

Le OLAP spatial, ou SOLAP, est le fruit de recherches visant à combiner les tech-nologies OLAP et SIG à l’intérieur d’un outil intégré d’aide à la décision spatiale[Proulx et al., 2002; Rivest et al., 2001]. Un outil SOLAP est défini comme étant « untype de logiciel qui permet la navigation rapide et facile dans les bases de donnéesspatiales et qui offre plusieurs niveaux de granularité d’information, plusieurs thèmes,plusieurs époques et plusieurs modes d’affichage synchronisés ou non : cartes, tableaux

1Notons que dans ce sens, un « cube » n’est pas restreint à trois dimensions : il peut y avoir autantde dimensions que les thèmes d’analyse le requièrent, le terme hypercube étant alors parfois plus usitépour décrire ces cas.


et diagrammes » [Bédard et al., 2005]. En somme, SOLAP étend OLAP avec la gestiondes données (i.e. dimensions et mesures spatiales) et des analyses spatiales ainsi quela visualisation et la navigation cartographique. L’implémentation d’un outil SOLAPintégré a été réalisé par l’équipe de la Chaire de recherche industrielle en bases de don-nées géospatiales décisionnelles (Université Laval, Québec, Canada) avant le début decelle-ci et est commercialisé par la société KHEOPS Technologies ; il s’agit de JMapSpatial OLAP [KHEOPS Technologies, 2005]. Ce logiciel, ayant été développé pour desordinateurs de bureau dans un contexte sédentaire, requiert plusieurs adaptations pourpouvoir être utilisé dans un contexte mobile. Entre autres, les cubes de données ty-piquement déployés sont volumineux, et surtout ils n’ont typiquement pas été conçuspour satisfaire les besoins changeants des utilisateurs mobiles et de leur technologie.Son architecture 3-tiers (client/serveur SOLAP et serveur SGBD) est également peuadaptée pour les appareils mobiles, puisqu’elle nécessite en tout temps la disponibilitéd’un lien réseau à haut débit, situation qui n’est pas garantie en contexte de mobilité.

Badard et al. [2008] présentent et analysent les critères d’adaptation d’un outil SO-LAP (en l’occurrence JMap Spatial OLAP) pour être utilisé dans un environnementmobile. Il en ressort qu’un client SOLAP mobile devrait supporter deux modes defonctionnement : le mode connecté et le mode déconnecté. En mode connecté, chaquerequête de l’utilisateur est acheminée vers le serveur SOLAP et traité par ce dernier.Le résultat de la requête, provenant de cubes stockés dans un entrepôt de données, estensuite retourné au client. Ce mode de fonctionnement est donc similaire à celui des en-vironnements de bureau. Il a comme avantage de mettre à disposition toute la puissancede traitement du serveur SOLAP et la capacité de stockage d’un entrepôt de données,mais par contre, il oblige le client à disposer en tout temps d’un lien réseau sans-fil dedébit suffisant. Le mode déconnecté, quant à lui, permet au client de fonctionner lors-qu’il n’y a aucun lien réseau disponible. Ce mode s’appuie sur la notion de mini-cube,soit un cube de données SOLAP de taille réduite, dont le contenu a été sélectionné parl’utilisateur sur demande, et pouvant être stocké à même la mémoire non-volatile del’appareil mobile. Le mini-cube est transmis au client mobile lorsqu’un lien réseau estdisponible ; le temps de transmission d’un mini-cube se trouve réduit par rapport à celuide cubes de données entiers, ce qui est important avec les réseaux sans-fil, en particulierles liens de téléphonie mobile au débit limité et dont le coût d’utilisation est parfoisélevé. Une fois que le client a obtenu un mini-cube, il peut consulter celui-ci de manièretotalement autonome, même sans connexion réseau. Le service Web de constitutionde mini-cubes, proposé et décrit dans ce présent article, offre l’infrastructure visant àsupporter le mode de fonctionnement déconnecté ; il doit donc offrir les fonctionnalitésrequises pour réduire le volume des données et ainsi produire les mini-cubes. Par soucid’interopérabilité, l’accès à ces fonctionnalités est basé sur une architecture dite orientéeservice, s’appuyant sur la technologie des services Web du W3C.


2.2.2.3 Principes des architectures orientées services et des services Web

Architectures orientées services

Une architecture orientée services est caractérisée par une méthodologie de concep-tion des systèmes informatiques organisationnels, centrée sur la notion de service[Newcomer et Lomow, 2004]. Un service est décrit comme un ensemble de fonction-nalités accomplissant des tâches spécifiques, accessible par un réseau informatique. Ladéfinition de l’ensemble de ces fonctionnalités et la manière spécifique de les invoquer estformalisée par un contrat de service ; ce concept est semblable à celui d’interface dansle vocabulaire du modèle orienté objet. Les services peuvent être combinés les uns avecles autres afin de réaliser des tâches plus complexes. Les composants d’une architectureorientée service se classent en trois catégories : les fournisseurs de services, les consom-mateurs de services et les médiateurs. Les fournisseurs implémentent les fonctionnalitésdécrites par le contrat de service. Les consommateurs invoquent les services offerts parles fournisseurs ; un consommateur peut être soit une application client, soit un services’appuyant sur la fonctionnalité d’un autre fournisseur de service. Les médiateurs ontdeux rôles principaux : ils facilitent d’abord la découverte et l’invocation de services, enprésentant des catalogues de contrats de services en un lieu centralisé. Ils peuvent égale-ment effectuer le routage et le chaînage entre services en fonction de la tâche à réaliser.Par leurs caractéristiques, les architectures orientées services favorisent la réutilisationde composants, et ainsi la réduction des efforts et coûts de développement de systèmeslogiciels complexes.

Services Web W3C

Les services Web, tels que définis par le World Wide Web Consortium (W3C),constituent une implémentation possible des architectures orientées services. Il s’agitde services accessibles sur Internet ou par l’intermédiaire de réseaux privés (intranet),utilisant une norme d’échange de messages basée sur XML (normes SOAP et WSDL),et qui ne sont pas liés à une plateforme logicielle (système d’exploitation, langage deprogrammation) et matérielle (jeu d’instructions du processeur) particulière [Cerami,2002]. Cette caractéristique favorise l’interopérabilité entre systèmes informatiques hé-térogènes. Par exemple, un service Web réalisé en langage Java, s’exécutant sur unserveur Linux, peut sans problème être exploité par un logiciel client basé sur l’en-vironnement .NET sous Windows. Puisqu’il s’agit de services qui communiquent parprotocoles réseaux standardisés, ils peuvent être déployés sur tout réseau informatique,indépendamment de la technologie (réseaux câblés, sans-fil, etc.) ce qui les rendentidéaux pour les systèmes répartis (n-tiers) et l’utilisation mobile. De plus, ils gèrent


efficacement les échanges d’informations asynchrones, ce qui est idéal lorsqu’un lienréseau subit des déconnections et connections successives, situation fréquemment ren-contrée en contexte mobile (dû à une couverture discontinue des réseaux de téléphoniemobile ou WiFi). En comparaison, les protocoles client/serveur classiques requièrentune connexion ininterrompue pendant toute la durée de la session d’utilisation.

Services Web géomatiques OGC

Dans le monde de la géomatique, l’Open Geospatial Consortium (OGC) proposeplusieurs spécifications de services Web. Entre autres, les services WMS (Web Mapping

Service) et WFS (Web Feature Services) définissent des mécanismes respectivement dediffusion de cartes (i.e. de représentations de données spatiales) et d’échanges de donnéesspatiales. WFS, plus particulièrement, permet de servir des entités spatiales vectoriellesindividuelles, d’une manière transactionnelle (opérations sélection — insertion — miseà jour — suppression) [OGC, 2005]. Les données vectorielles transmises sont représen-tées en format GML (Geography Markup Language), qui spécifie un encodage XML desprimitives géométriques telles que points, lignes et polygones [ISO/TC211, 2004]. WFSpermet ainsi une manipulation des données géométriques à la source des cartes. Cepen-dant, son modèle transactionnel convient davantage aux données spatiales tabulaires,composées d’enregistrements (rangées), et non aux données multidimensionnelles qu’onretrouve dans les cubes SOLAP.

Services Web pour entrepôts de données multidimensionnelles et OLAP

Dans le monde des bases de données multidimensionnelles et OLAP, la spécificationXML for Analysis (XMLA) propose un mécanisme d’interrogation des données multi-dimensionnelles via un service Web basé sur le protocole SOAP [Microsoft et Hyperion,2002]. Cette spécification est basée sur le langage d’interrogation mdXML (lui-mêmebasé sur le langage MDX, cf. 2.2.2.1) et est inspirée du modèle objet OLE DB forOLAP [Microsoft Corporation, 2007b]. Il est souvent lié à SQL Server Analysis Ser-vices, le serveur OLAP de Microsoft. Cependant, d’autres implémentations, telles queMondrian, ont adopté XMLA comme interface de programmation, démontrant ainsison interopérabilité [Pentaho Corporation, 2007].

D’un autre côté, un format XML d’échange de données multidimensionnelles a étéproposé ; il s’agit de XCube [Hümmer et al., 2003]. Il définit une série de schémas XMLpour encoder les objets des jeux de données multidimensionnelles, tels que les cubes,dimensions, hiérarchies, niveaux, membres et mesures. Bien qu’il ne s’agisse pas d’unespécification de service Web proprement dit, les éléments XML proposés dans XCube


peuvent être encapsulés à l’intérieur de messages SOAP lors de la réalisation d’un serviceWeb.

Dans leur version actuelle, ces deux spécifications s’avèrent insuffisantes pour diffuserdes cubes de données spatiales multidimensionnelles. XMLA propose un mécanismed’interrogation des données, mais son format de livraison de données est conçu pour laprésentation d’un résultat de requête (exploitable par exemple pour la constitution dedifférents affichages : histogramme, camembert, tableau croisé), et non la transmissionde cubes complets (comprenant structure et données). XCube répond mieux à ce critère,mais tout comme XMLA, il ne propose pas de solution pour l’échange des entitésgéographiques (comprenant des primitives géométriques) des cubes de données SOLAP.Le service Web de constitution de mini-cubes reposera donc sur un nouveau format XMLd’échange de cubes, capable de représenter des cubes complets contenant également desentités (membres) géographiques.

2.2.3 Proposition d’une architecture pour le service Web

La solution proposée, soit le service Web de constitution de mini-cubes, s’articule au-tour de deux concepts : celui du mini-cube (cf. 2.2.2.2) visant à répondre aux contraintesdes appareils mobiles en termes de capacité mémoire (taille réduite des cubes) et enconnectivité réseau (support du mode déconnecté), ainsi que celui des services Web,visant à apporter une solution interopérable bien adaptée aux liens de communica-tion sans-fil. Cette section décrit l’architecture générale de ce service et les nouveauxconcepts développés dans le cadre de ce projet de recherche.

2.2.3.1 Cas d’utilisation : invocation du service

Tel que décrit précédemment, le service Web de constitution de mini-cubes SOLAPvise à supporter un mode de fonctionnement déconnecté pour les clients mobiles. Uncas d’utilisation typique d’un tel service est illustré à la figure 2.1.

L’invocation du service se déroule comme suit :

1. Le client SOLAP mobile invoque à distance le service Web de constitution demini-cubes. Le client peut faire plusieurs requêtes successives pour obtenir del’information (métadonnées) sur les cubes disponibles et les objets qui en fontpartie (i.e. dimensions, hiérarchies, niveaux, membres et mesures). À partir de ces


Service Web deconstitution de mini-cubes

Client SOLAPmobile

2. Requêtes de donnéesmultidimensionnelles (pourconstruction du mini-cube)

Lien réseauintermittent

(sans-fil / cellulaire)

1. Demande de constructiond’un mini-cube

3. Transmission d’unmini-cube

en format XML

4. Désérialisationdu mini-cube (XML vers

BD embarquée)

Entrepôt dedonnées spatiales

multidimensionnelles

<?xml version="1.0"encoding="UTF-8"?><CubeHeader><Dimensionname="geography">[...]


Mini-cube SOLAP(données XML)

Fig. 2.1 – Mécanisme d’invocation du service Web

informations, le client peut choisir un sous-ensemble des données disponibles (soitun sous-cube) et invoquer le service pour demander la construction du mini-cubecorrespondant à ce sous-ensemble de données.

2. Le service Web traite la demande de construction d’un mini-cube en effectuantla sélection des données souhaitées dans l’entrepôt de données spatiales multidi-mensionnelles.

3. Le mini-cube est construit à partir des données sélectionnées, sérialisé en un for-mat d’échange XML (cf. 2.2.2.3, paragraphe « Services Web pour entrepôts dedonnées multidimensionnelles et OLAP ») et transmis au client, dans un ou plu-sieurs messages SOAP de réponse.

4. Le client, lors de la réception du mini-cube XML, peut désérialiser ce dernier pourstockage éventuel dans une base de données embarquée (de structure relationnelle,i.e. ROLAP, ou multidimensionnelle, i.e. MOLAP). La désérialisation du cube etl’usage d’une BD embarquée s’explique par le fait que le mini-cube XML repré-sente un format interopérable d’échange de données, mais n’est pas optimisé pourun stockage compact et un accès rapide aux données par le moteur OLAP.

Une fois le mini-cube stocké sur le client mobile, ce dernier peut fonctionner enmode déconnecté, de manière autonome : l’usager peut donc consulter le cube sansêtre connecté au service Web ou à tout autre serveur (cf. 2.2.2.2). Comme la quan-tité de données du mini-cube est réduite, les opérations courantes d’analyse SOLAPs’exécutent dans un temps acceptable, malgré les limites en puissance de calcul et enmémoire des appareils mobiles. Des analyses plus complexes, requiérant de plus grandsvolumes de données ainsi qu’une plus grande capacité de traitement, pourraient tout demême s’effectuer en les déléguant à un autre service Web dans une architecture élargie,lorsqu’un lien réseau est disponible.


2.2.3.2 Construction d’un mini-cube : principes conceptuels

Les cubes de données SOLAP disponibles dans les entrepôts de données spatialesdécisionnelles sont souvent d’une taille considérable, ce qui demande une capacité destockage bien supérieure à ce qu’offrent les supports de mémoire non-volatile des ap-pareils mobiles (ex. cartes mémoire flash, micro disques durs). De plus, les utilisateursmobiles ont souvent besoin de données propres au contexte dans lequel ils se situent ;alors qu’un entrepôt de données décisionnelles d’une organisation doit offrir les donnéespouvant répondre à un éventail très varié de requêtes provenant de nombreux utili-sateurs, l’utilisateur mobile est appelé à consulter un jeu de données d’une envergureplus restreinte. Il peut s’agir d’un sous-ensemble des données disponibles, selon desthèmes, des époques, des lieux, ou des niveaux hiérarchiques de dimension sélectionnés.Le niveau de détail géométrique des membres de dimensions spatiales et des mesuresspatiales peut également être diminué, par exemple par généralisation cartographique,pour réduire l’espace de stockage et le temps de transmission.

Un sous-ensemble d’un cube est sélectionné en effectuant une restriction sur lesmembres des dimensions ; cette restriction a également pour effet de réduire le nombrede cellules (faits) inclus dans le sous-cube résultant. Prenons le cube SOLAP illustréà la figure 2.2, représentant les ventes de Boutisport, une entreprise fictive spécialiséedans les articles de sport.

Chaque dimension comporte une seule hiérarchie. La dimension Commerce est unedimension spatiale géométrique, avec une représentation cartographique des membres àchaque niveau (polygones représentant le découpage territorial pour les niveaux Pays,Province, Région et Ville, et points représentant la position de chaque point de ventepour le niveau Boutique). La dimension Temps est temporelle, avec les niveaux Année —Mois — Jour. La dimension Produits est thématique ; on y représente les divers produitsvendus avec les niveaux Département (e. g. membres vélo, ski, golf, etc.) — Catégorie

(membres bicyclettes, pièces, accessoires, vêtements, etc. remontant au départementvélo) — Produit (membres casque, porte-bagages, pompe à pneus, etc. remontant à lacatégorie Accessoires). Les faits ont comme granularité les ventes quotidiennes pourchaque produit dans chaque boutique. Les mesures décrivant ces faits sont le nombred’unités vendues et le montant des ventes.

Les opérations suivantes sont offertes par le service Web pour la sélection d’un sous-cube :

Inclusion de membres pour une dimension : le client peut choisir les membresvoulus, dans une ou plusieurs dimensions, pour réduire l’envergure du mini-cube


CUBE : BOUTISPORT

DIMENSION : PRODUITS

DÉPARTEMENT

CATÉGORIE

PRODUIT

DIMENSION : COMMERCE

PAYS

PROVINCE

RÉGION

VILLE

BOUTIQUE

DIMENSION : TEMPS

ANNÉE

MOIS

JOUR

MESURE

Unités vendues Montant des ventes

Fig. 2.2 – Schéma du cube (formalisme UML multidimensionnel de Bédard et al. [2006])

à construire. Par défaut, le membre « Tous » est sélectionné, ce qui revient à incluretous les membres de la dimension. La sélection d’un membre donné impliqueégalement la sélection de tous ses descendants ; ultimement, les membres au niveaufeuille remontant au membre choisi sont sélectionnés. Exemple : dans le cube décrit

ci haut, la sélection du membre Québec au niveau Province implique la sélection

de tous les membres au niveau Région faisant partie du Québec ; idem pour les

membres des autres sous-niveaux Ville et Boutique. Le résultat est la sélection des

membres au niveau Boutique qui sont situés au Québec. Par conséquent, le mini-

cube résultant ne contiendra aucun fait ayant trait aux ventes dans les boutiques

à l’extérieur du Québec.

Agrégation sur un ou plusieurs membres pour une dimension : le client peutchoisir un ou plusieurs membres pour lesquels les mesures des cellules corres-pondantes doivent être agrégées, selon une formule d’agrégation par défaut ouspécifiée, définie dans le cube. Ainsi, tous les membres descendant du membrechoisi sont exclus du cube résultant, puisque le grain des faits a été ramené àun niveau supérieur pour la dimension affectée. Le choix des membres sur les-quels agréger peut aussi s’effectuer sur un niveau ; en choisissant d’agréger surtous les membres d’un niveau, on exclut du mini-cube les membres de tous lesniveaux inférieurs. Exemple : toujours avec le même cube Boutisport, on demande

d’agréger sur le niveau Mois de la dimension Temps. Le niveau Jour ainsi que


tous ses membres seront alors exclus du mini-cube résultant. L’opérateur agrégatif

par défaut pour les mesures Unités vendues et Montant des ventes est la somme.

La nouvelle granularité des faits sera les ventes mensuelles (somme des ventes

quotidiennes, pour chaque mois) pour chaque produit dans chaque boutique.

Exclusion d’une dimension : une ou plusieurs dimensions choisies peuvent être ex-clues des thèmes d’analyse du mini-cube résultant. En terminologie OLAP, il s’agitde l’opération slice. Pour exclure une dimension, on doit choisir un membre decette dimension sur lequel projeter ou agréger les mesures ; par défaut, les mesuressont agrégées sur le membre « Tous ». Exemple : on choisit d’exclure la dimension

Produits lors de la construction d’un mini-cube. Par défaut, le membre « Tous »

de cette dimension est utilisé pour agréger les mesures. Ainsi, la dimension Pro-duit est exclue du mini-cube résultant, et les faits auront comme granularité la

somme des ventes quotidiennes (pour tous les produits) dans chaque boutique.

Sélection de mesures : le client peut choisir quelles mesures doivent être inclusesdans le mini-cube. S’il s’agit de mesures calculées, les autres mesures dont ellesdépendent sont automatiquement incluses. Exemple : on demande d’inclure uni-

quement la mesure Montant des ventes. La mesure Unités vendues ne sera pas

disponible dans le mini-cube résultant.

Pour les dimensions spatiales (géométriques et mixtes), la sélection des membres àinclure ou à agréger peut non seulement se faire de manière descriptive (sélection desmembres par leur nom ou identifiant), mais également avec des opérateurs topologiquesd’analyse spatiale, tels que ceux définis dans la norme ISO TC/211 19107:2003 —

Schéma spatial [ISO/TC211, 2001]. Par exemple, un utilisateur mobile pourrait choisird’inclure les membres de la dimension Commerce qui sont complètement inclus dansun rayon de cinquante kilomètres autour de sa position actuelle.

Des traitements de simplification géométrique peuvent aussi être appliqués auxobjets géométriques des membres spatiaux. Ces traitements visent à réduire la com-plexité des objets vectoriels, et par conséquent réduire la taille en octets qu’ils oc-cupent. Par exemple, un algorithme de filtrage géométrique tel que Douglas-Peucker[Douglas et Peucker, 1973] peut être utilisé sur les géométries des membres qu’on sou-haite simplifier. Par contre, la simplification géométrique comporte un ensemble deproblèmes reliés à la généralisation cartographique. Des techniques plus évoluées, tellesque la représentation multiple [Bédard et Bernier, 2002], les patrons géométriques et lesobjets auto-généralisants [Sabo et al., 2007] ou des agents [Ruas, 1999] pourraient amé-liorer la qualité de cette simplification. La mise en œuvre de telles techniques dépassetoutefois le cadre du présent projet de recherche.


2.2.3.3 Architecture du service

Deux approches possibles ont été envisagées pour la réalisation du service Webde constitution de mini-cubes SOLAP : l’une est basée sur un outil ETL, et permetde construire les mini-cubes à partir des sources de données transactionnelles. L’autreapproche est articulée autour d’un serveur OLAP, et produit les mini-cubes à partir decubes SOLAP existants.

Service basé sur un outil ETL

Une des implémentations possibles s’appuie sur un outil d’extraction, de transfor-mation et de chargement des données, communément appelé ETL (Extract, Transform

and Load). Une telle implémentation permet de construire le mini-cube directement àpartir des sources de données transactionnelles, sans nécessiter un entrepôt de donnéesmultidimensionnel ; une certaine réduction de la complexité des infrastructures et descoûts associés peut ainsi être réalisée. On assure également que les données des mini-cubes soient à jour par rapport aux données sources, ce qui n’est pas toujours le casavec un entrepôt de données mis à jour périodiquement.

Cette approche comporte cependant quelques inconvénients. Les outils ETL exis-tants sont basés sur le modèle de données relationnel ; ils n’offrent pas les capacitésmultidimensionnelles des outils OLAP, ce qui s’avère nécessaire lorsqu’on veut paramé-trer la construction du mini-cube en fonction de critères de sélection multidimensionnels.L’implantation des opérateurs de construction de mini-cubes (cf. 2.2.3.2) serait donccomplexe et difficile dans un environnement ETL. Un inconvénient additionnel est lacharge supplémentaire placée sur les systèmes opérationnels sources ; la performance deceux-ci peut être affectée à chaque fois qu’ils sont sollicités pour la création d’un mini-cube, puisqu’il s’agit d’opérations coûteuses en termes de temps de traitement. Enfin,les traitements spatiaux ETL ne peuvent pas tous être réalisés de façon totalementautomatique.

Dans l’implémentation suggérée ici, la chaîne de traitement ETL est pilotée par leservice Web. Les procédures ETL mises en œuvre doivent produire en sortie des donnéesdans un format d’échange de cubes SOLAP en XML (cf. 2.2.2.3, paragraphe « ServicesWeb pour entrepôts de données multidimensionnelles et OLAP »), qui seront ensuiteacheminées au client dans les messages SOAP de réponse.


Service basé sur serveur OLAP

Une autre approche possible est de développer le service Web autour d’un serveurOLAP, adapté pour supporter les objets géométriques pour les membres des dimensionsspatiales. Le client peut demander la construction d’un mini-cube, selon toutes lesopérations proposées dans la partie 2.2.3.2. Le service communique avec le serveurOLAP en utilisant l’interface de programmation et le langage d’interrogation de celui-ci, afin de récupérer les données et métadonnées nécessaires pour constituer le mini-cube. Enfin, le mini-cube SOLAP est sérialisé en format d’échange XML et acheminéau client.

Bien que cette approche nécessite un entrepôt de données géospatiales décisionnelleset un serveur OLAP, elle permet une implantation simple des opérateurs de constructionde mini-cubes, décrits dans la partie 2.2.3.2. Le temps de réponse rapide des systèmesOLAP apporte également une réponse à la contrainte de temps réel pour la constitutiondes mini-cubes. De plus, la charge sur les systèmes opérationnels (OLTP) est réduite,puisqu’ils ne sont pas sollicités à chaque invocation du service ; les procédures ETLsont responsables d’alimenter l’entrepôt de données, et ne vont typiquement solliciterles systèmes opérationnels que périodiquement, à des temps où leur usage est réduit(ex. à chaque nuit). D’une autre part, cela implique que les mini-cubes sont constituésà partir des données présentes dans l’entrepôt de données, donc à jour seulement de-puis la dernière exécution des procédures ETL. Par contre, ils bénéficient du travailETL géométrique, qui a souvent demandé une assistance manuelle pour résoudre lesproblèmes d’hétérogénéité spatiale. Finalement, il peut être souhaitable de conserverles mini-cubes déjà produits dans un cache ; ainsi, lorsque plusieurs clients demandentun même mini-cube, le temps de réponse peut être grandement accéléré. Ce cache peutêtre réalisé grâce à un service auxiliaire.

Services auxiliaires

Dans une architecture élargie pour applications SOLAP mobiles, d’autres servicesWeb peuvent compléter les fonctionnalités du service de constitution de mini-cubes.Plusieurs de ces services sont décrits dans Badard et al. [2008] ; en voici un aperçu :

– Service d’authentification et de gestion des droits d’utilisation : ce service permetd’authentifier les utilisateurs et de donner accès aux cubes correspondant à leursdroits d’utilisation, afin de sécuriser l’accès aux données confidentielles.

– Service d’entreposage de mini-cubes : sert à indexer et à stocker les mini-cubesgénérés par le service de constitution. De multiples clients peuvent alors téléchar-ger des cubes existants, sans avoir à redemander leur construction (concept de


cache).– Service de chaînage et de livraison de mini-cubes : permet de combiner plusieurs

services de constitution ainsi que différents entrepôts de mini-cubes, afin de donneraccès de manière centralisée à un éventail de sources de données. Offre égalementdivers mécanismes de livraison (immédiate ou différée) des cubes.

Ces services auxiliaires montrent qu’on peut combiner plusieurs services Web dis-tribués, dans une architecture orientée services, pour répondre à un éventail de besoinset de cas d’utilisation particuliers, dans des contextes autant sédentaires que mobiles.

2.2.4 Réalisation d’un prototype

Un prototype de service Web de constitution de mini-cubes SOLAP est en cours dedéveloppement. Ce service est basé sur l’architecture proposée dans la partie 2.2.3.3 (pa-ragraphe « Service basé sur serveur OLAP »). Il est réalisé en langage Java, et exploiteles fonctionnalités du serveur OLAP open source Mondrian (Pentaho Analysis Services)ainsi que les objets spatiaux du cadre de développement GeOxygene [Badard et Braun,2003]. Le choix de technologies open source facilite l’intégration de nouvelles fonction-nalités (i.e. membres spatiaux) dans le serveur OLAP. Un entrepôt de données a étéconstruit à des fins de tests, en utilisant le SGBD PostgreSQL2 avec les extensions spa-tiales PostGIS3. Le peuplement de cet entrepôt est réalisé grâce à une version de Kettle4

(Pentaho Data Integration), modifiée pour supporter les objets géométriques conformesISO supportés par GeOxygene. Le service Web utilise l’interface de programmation duserveur pour interroger les cubes de données et ainsi constituer les mini-cubes. Le clientmobile invoque les fonctionnalités du serveur à l’aide du protocole SOAP, et les données(mini-cubes SOLAP) lui sont retournées dans les messages de réponse, en format XML.L’architecture générale de ce système est illustrée à la figure 2.3.

Le service Web propose les opérations suivantes, inspirées de celles offertes par leservice d’entités cartographiques (WFS) de l’OGC. Ces opérations constituent le contratde service, et sont généralement appelées selon la séquence suivante :

– Opération GetCapabilities, informant le client de la version du service et donnantdes informations sur l’identification (ex. nom de l’organisation responsable duservice, personnes responsables, etc.) et les capacités du service (ex. le support ou

2PostgreSQL est un SGBD relationnel open source ; http://www.postgresql.org.3PostGIS ajoute à PostgreSQL les types de données et opérateurs spatiaux définis par la spécification

OGC Simple Features for SQL ; http://postgis.refractions.net.4Kettle est un outil ETL open source ; http://kettle.pentaho.org.

http://www.postgresql.org

http://postgis.refractions.net

http://kettle.pentaho.org


Sources de données (systèmes opérationnels)

Kettle (procédures ETL)

Extractionde données Chargement

de données


Entrepôt dedonnées spatiales

multidimensionnelles(PostgreSQL+PostGIS)

Serveur OLAP(Mondrian +

extensions spatiales)

Requêtes(SQL)

Réponses

Requêtes(MDX /

API Mondrian)

Réponses

Client SOLAPmobile

Invocationdu service

(Requêtes SOAP)

Réponse(mini-cube XML)

Fig. 2.3 – Architecture du prototype de service Web

non de certaines composantes optionnelles du contrat de service).– Opération DescribeSchema, permettant d’obtenir les métadonnées. On peut de-

mander de décrire des objets tels que les cubes, les dimensions, les hiérarchies,les niveaux et les mesures. Ces objets constituent le schéma des cubes, i. e. ilsdécrivent la structure et non le contenu des cubes.

– Opération GetMembers, permettant d’interroger les dimensions d’un cube et d’ob-tenir les membres. Cette opération doit supporter la navigation dans une hiérar-chie de membres, i. e. obtenir les parents ou enfants d’un membre, obtenir lesmembres selon un niveau, etc. Cette opération propose également une méthode desélection spatiale des membres (selon des opérateurs métriques ou topologiques).

– Opération GetCells, offrant un mécanisme d’interrogation des données (faits) d’uncube. Les informations obtenues précédemment par l’intermédiaire des autres opé-rations (DescribeSchema et GetMembers) permettent de sélectionner les cellulescorrespondant au croisement des membres choisis, pour un cube donné. Elle s’ap-puie sur les opérateurs de construction de mini-cubes (cf. 2.2.3.2). L’argument decette opération est donc une « requête de sélection » multidimensionnelle définis-sant l’ensemble des cellules du cube à obtenir.

– Opération GetCube, permettant de récupérer un mini-cube complet. Cette opéra-tion s’appuie sur GetCells pour obtenir les données voulues, et ajoute en plus tousles membres correspondant à la sélection du sous-cube ainsi que la description duschéma de ce sous-cube (métadonnées, i. e. structure des dimensions, hiérarchies,niveaux et mesures). Le document XML retourné est donc une représentationcomplète du mini-cube demandé (données et métadonnées).

Il importe de mentionner que ce contrat de service constitue une interface tech-nique pour la construction des mini-cubes. Des outils à interface graphique conviviale(i.e. client SOLAP mobile) pourront exploiter ces fonctionnalités, afin de les rendretransparentes à l’utilisateur.


2.2.5 Conclusion

Les architectures orientées services, ainsi que leur réalisation sous forme de servicesWeb, constituent une solution valable pour la diffusion de données géo-décisionnelles,dans un contexte de mobilité. Nous avons établi les principes conceptuels et définil’architecture d’un service Web permettant la constitution de cubes de données SOLAPde taille réduite, adaptés à ces environnements mobiles. La réalisation d’un tel service,s’appuyant sur des normes ouvertes et des technologies open source, a également étédécrite.

Plusieurs travaux restent à compléter pour rendre opérationnel le service Web deconstitution de mini-cubes SOLAP. Des schémas XML, élaborés selon la spécificationW3C XML Schema [Fallside et Walmsley, 2004], devront être développés pour décrirele format d’échange des mini-cubes SOLAP. Un tel format pourra s’appuyer sur desschémas existants, tels que XCube pour la représentation des objets multidimension-nels, ainsi que GML pour les données spatiales. De plus, des travaux portant sur laconception de langages d’interrogation multidimensionnels spatiaux-temporels et d’opé-rateurs géométriques d’agrégation ont été entrepris au sein de la Chaire de rechercheindustrielle en bases de données géospatiales décisionnelles. Ces travaux faciliteront da-vantage la réalisation de services Web pour l’aide à la décision géospatiale. À terme,les architectures orientées services pour SOLAP serviront à réaliser un vaste éventaild’applications, qu’elles soient mobiles ou sédentaires. Là où des services tels que WFScomblent les besoins d’accès aux données spatiales transactionnelles, organisées selonun modèle relationnel, des services tels que celui ici décrit pourront aider à comblerles besoins d’accès aux données spatiales décisionnelles, organisées selon un modèlemultidimensionnel.

2.2.6 Remerciements

Ce projet de recherche est rendu possible grâce au soutien de la Chaire de rechercheindustrielle en bases de données géospatiales décisionnelles, dirigée par le professeurYvan Bédard. Il s’inscrit également dans le cadre des travaux menés par le groupeGeoSOA visant la conception d’une architecture orientée services pour la géomatiquemobile (professeur Thierry Badard).


2.2.7 Bibliographie partielle (pour l’article seulement)

Badard, T., Y. Bédard, F. Hubert, E. Bernier et E. Dubé. 2008, «Web services-orientedarchitectures for mobile SOLAP applications», International Journal of Web Engi-

neering and Technology (IJWET).

Badard, T. et A. Braun. 2003, «OXYGENE — D’une plate-forme interopérable audéploiement de services web géographiques», Revue internationale de géomatique,vol. 3, no 13, pp. 411–430.

Bédard, Y. et E. Bernier. 2002, «Supporting Multiple Representations with SpatialView Management and the Concept of “VUEL”», dans Joint Workshop on Multi-

Scale Representation of Spatial Data, International Society for Photogrammetry and

Remote Sensing (ISPRS) WG IV/3. ICA. Com. On Map Generalization, Ottawa,Canada.

Bédard, Y., M.-J. Proulx et S. Rivest. 2005, «Enrichissement du OLAP pour l’analysegéographique : exemples de réalisation et différentes possibilités technologiques», Re-

vue des Nouvelles Technologies de l’Information — Entrepôts de données et l’Analyse

en ligne.

Bédard, Y., M.-J. Proulx et S. Rivest. 2006, «« Notions de modélisation multidi-mensionnelle (conceptuelle) », notes du cours « Notions avancées de bases de don-nées SIG (SCG-66124) »», http://sirs.scg.ulaval.ca/YvanBedard/enseigne/

note66124.htm.

Cerami, E. 2002, Web Services Essentials, O’Reilly & Associates, Inc., Sebastopol, CA,USA, ISBN 0596002246, 320 pp..

Codd, E. F., S. B. Codd et C. T. Salley. 1993, «Providing OLAP to users-analysts : anIT mandate», white paper, Hyperion Solution Corporation.

Douglas, D. H. et T. K. Peucker. 1973, «Algorithms for the reduction of the number ofpoints required to represent a line or its caricature», Cartographica : The International

Journal for Geographic Information and Geovisualization, vol. 10, no 2, pp. 112–122.

Duda, I., M. Aleksy et T. Butter. 2005, «Architectures for Mobile Device Integrationinto Service-Oriented Architectures», dans Fourth International Conference on Mo-

bile Business (ICBM2005), Sydney, Australia, pp. 193–198.

Fallside, D. C. et P. Walmsley. 2004, «XML Schema Part 0 : Primer (Second Edi-tion)», spécification technique, World Wide Web Consortium. http://www.w3.org/

TR/xmlschema-0/.

http://sirs.scg.ulaval.ca/YvanBedard/enseigne/note66124.htm


http://www.w3.org/TR/xmlschema-0/



Hümmer, W., A. Bauer et G. Harde. 2003, «XCube : XML for data warehouses»,dans DOLAP ’03 : Proceedings of the 6th ACM international workshop on Data

warehousing and OLAP, ACM, New York, NY, USA, ISBN 1-58113-727-3, pp. 33–40.

ISO/TC211. 2001, «Geographic Information - Spatial Schema (ISO 19107) (OGC Topic1 working draft Version 5)», spécification technique, ISO Technical Committee 211.

ISO/TC211. 2004, «Geographic information — Geography Markup Language (GML)(Committee Draft, version 3.1.0)», spécification technique, ISO Technical Committee211 & Open Geospatial Consortium.

KHEOPS Technologies. 2005, «JMap Spatial OLAP», white paper. http://www.

kheops-tech.com/en/jmap/doc/WP_JMap_SOLAP.pdf.

Kimball, R. et J. Caserta. 2004, The Data Warehouse ETL Toolkit, John Wiley & Sons,ISBN 0764567578, 528 pp..

Kimball, R. et M. Ross. 2002, The Data Warehouse Toolkit : The Complete Guide to

Dimensional Modeling (2nd edition), John Wiley & Sons, ISBN 0471200247, 416 pp..

Microsoft et Hyperion. 2002, «XML for Analysis Specification, version 1.1», spécificationtechnique, Microsoft Corporation.

Microsoft Corporation. 2007a, «Multidimensional Expressions (MDX) Reference»,http://msdn2.microsoft.com/en-us/library/ms145506.aspx.

Microsoft Corporation. 2007b, «OLE DB for Online Analytical Processing (OLAP),Programmer’s Reference», http://msdn2.microsoft.com/en-us/library/

ms717005.aspx.

Newcomer, E. et G. Lomow. 2004, Understanding SOA with Web Services, Addison-Wesley Professional, ISBN 0321180860, 480 pp..

OGC. 2005, «Web Feature Service Implementation Specification, version 1.1.0», spéci-fication technique, Open Geospatial Consortium.

Pentaho Corporation. 2007, «Pentaho Analysis Services : Mondrian Project», http://

mondrian.pentaho.org.

Proulx, M.-J., Y. Bédard, M. Nadeau, P. Gosselin et G. Lebel. 2002, «Géomatique etsanté environnementale : innovations résultant du projet ICEM/SE», dans Géoma-

tique 2002, Montéal, Québec, Canada.

http://www.kheops-tech.com/en/jmap/doc/WP_JMap_SOLAP.pdf


http://msdn2.microsoft.com/en-us/library/ms145506.aspx



http://mondrian.pentaho.org



Rivest, S., Y. Bédard et P. Marchand. 2001, «Toward better support for spatial deci-sion making : defining the characteristics of Spatial On-Line Analytical Processing(SOLAP)», Geomatica, vol. 55, no 4, pp. 539–555.

Ruas, A. 1999, Modèle de généralisation de données géographiques à base de contraintes

et d’autonomie, thèse, Université de Marne La Vallée, France.

Sabo, M. N., Y. Bédard, E. Bernier et A. Cardenas. 2007, «Methodology for developinga database of geometric patterns to better support on-the-fly map generalization»,dans International Cartographic Conference, Coruna, Espagne.

Thomsen, E. 2002, OLAP Solutions : Building Multidimensional Information Systems,John Wiley & Sons, Inc., New York, NY, USA, ISBN 0471400300, 688 pp..


2.3 Compléments à l’article

Cette section apporte certaines précisions et éléments d’information complémen-taires pour aider à la compréhension des concepts introduits dans l’article précédent.

2.3.1 SOLAP et mobilité

Dans le chapitre 1, notamment dans la section 1.2.2, il est fait état des contraintestechnologiques des environnements mobiles, que l’on classe en quatre catégories : lesinterfaces utilisateur et les méthodes d’entrées ; les capacités de calcul, de stockage etl’alimentation électrique ; les liens de communication ; l’interopérabilité entre systèmes.Dans l’article, ainsi que dans Badard et al. [2008], SOLAP est positionné par rapport àces contraintes, afin de déterminer ce qui doit être accompli pour réaliser une applicationSOLAP sur plateforme mobile. Nous reprenons ici ces contraintes en expliquant demanière détaillée leurs impacts sur les applications SOLAP, et en apportant des pistesde solutions. Cela permettra de définir plus clairement les rôles que doit combler leservice Web.

2.3.1.1 Contraintes de mobilité : comment y palier ?

Dans un environnement informatique de bureau (sédentaire), les clients SOLAPs’appuient sur une connectivité réseau permanente, dont la bande passante est élevée.En règle générale, les cubes de données sont stockés sur les serveurs (soit à même lesentrepôts de données dans une architecture ROLAP, ou bien dans des structures dedonnées propriétaires dans le cas du MOLAP) ; les clients ne disposent pas de ces don-nées en stockage local. Ainsi, toute requête du client est traitée par un serveur. On parlealors d’une architecture client-serveur. Bien que l’on retrouve ce type d’architecture lo-gicielle dans certaines applications mobiles (cf. 1.2.2.3, paragraphe « Client lourd »),elle comporte certaines limites face aux contraintes des environnements mobiles (cf.1.2.2.2).

Une des contraintes est que la connectivité réseau permanente n’est pas assurée dansle cas des environnements mobiles, dû à la couverture incomplète des réseaux sans-fil.De plus, la bande passante limitée et la latence des communications sont susceptiblesd’augmenter le temps d’attente entre une requête et sa réponse, nuisant au fil de penséede l’analyste. C’est pourquoi un client SOLAP mobile devrait supporter deux modes


d’opération, à savoir le mode connecté et le mode déconnecté.

En mode connecté, un client SOLAP mobile fonctionnerait de manière similaire àun client SOLAP de bureau. Chaque requête faite par l’utilisateur serait obligatoire-ment traitée par le serveur, et les données seraient acheminées au client pour chaqueréponse. Il n’y aurait pas de stockage local des cubes de données dans l’appareil (misà part une mise en mémoire temporaire des résultats de la requête, affichés à l’écran,et possiblement un cache pour éviter la transmission redondante de mêmes données).Bien entendu, un lien de communication fiable, persistant et de débit suffisant devraitêtre établi entre l’appareil mobile et le serveur pour toute la durée d’utilisation. Cemode a pour avantage de mettre à disposition du client l’ensemble des données conte-nues dans les cubes SOLAP du serveur. Toute la puissance de calcul du serveur seraitégalement accessible au client. Cela permet l’exécution de requêtes faisant appel à descalculs parfois complexes (e.g. mesures calculées, dont le résultat est produit à la volée),y compris celles contenant des analyses spatiales. Cependant, le temps d’attente entreune requête et la réponse peut être long si le débit du réseau sans-fil est insuffisant.De plus, lorsque la connectivité réseau n’est plus disponible, l’application cesse toutsimplement de fonctionner.

Le mode déconnecté, quant à lui, nécessiterait un stockage local des cubes de donnéessur l’appareil mobile. Le contenu des cubes, soit les métadonnées (plus spécifiquementle schéma du cube, i.e. la définition des dimensions, hiérarchies, niveaux et mesures) etles données (soit les membres des dimensions et les faits), devraient être présents surl’appareil mobile pour permettre le fonctionnement de l’application en absence de liaisonréseau avec le serveur. Ce stockage local pourrait se faire dans un dispositif de mémoirenon-volatile, i.e. mémoire flash (intégrée ou cartes mémoire) ou micro disque dur. Unmoteur OLAP léger embarqué, intégré à même l’application SOLAP mobile, pourraitainsi faire en tout temps l’interrogation de ces cubes de données stockés localement,même lorsque la connectivité réseau est inexistante. Un mécanisme serait égalementà prévoir pour adapter le contenu des cubes (provenant des sources de données, e.g.entrepôt ou serveur OLAP) et transmettre ce contenu aux appareils mobiles, afin qu’ilssoient stockés localement en prévision d’une utilisation en mode déconnecté.

Bien que cette approche apporte une solution vis-à-vis les limites liées aux liensde communication en mobilité, il faut considérer également d’autres contraintes : soitles capacités de stockage et de puissance de calcul limitées des appareils mobiles. Cescontraintes dépendent du type d’appareil : dans le cas des ordinateurs portatifs, lescapacités sont similaires à celles des ordinateurs de bureau, permettant ainsi le stockageet l’interrogation de cubes de taille substantielle. Par contre, en ce qui concerne les PDAet smartphones, les capacités sont beaucoup plus limitées : les mémoires flash actuelles


sont généralement limitées à quelques giga-octets. La mémoire vive est également pluspetite que ce qu’on retrouve sur les ordinateurs de bureau. Quant aux processeursembarqués de ces appareils5, ils n’offrent qu’une fraction de la capacité de calcul desordinateurs personnels et des serveurs. Ainsi, il est impensable de vouloir stocker etexploiter l’ensemble d’un entrepôt de données de grand volume à même un appareilmobile de ce type. Certains compromis s’avèrent nécessaires dans le but de supporterun mode de fonctionnement déconnecté.

2.3.1.2 Rôles du service Web

Dans un cadre d’utilisation mobile en mode déconnecté, on considère que les uti-lisateurs n’ont besoin que d’un sous-ensemble des cubes de données disponibles pourpouvoir effectuer leurs analyses. Dès lors, on peut mettre à disposition de ces utilisa-teurs un sous-ensemble d’un cube, autrement dit un sous-cube, et permettre le stockagede celui-ci sur l’appareil mobile. Il s’agit d’un compromis intéressant, offrant la possibi-lité d’utiliser une application SOLAP en mode déconnecté avec la portion des donnéesrépondant aux besoins précis de l’analyste. Nous nommons mini-cube ce sous-ensembled’un cube6, transmis à l’appareil mobile et stocké localement sur celui-ci.

Le service Web de constitution de mini-cubes SOLAP est responsable de deux tâchesprincipales :

– La constitution des mini-cubes, en fonction d’opérateurs de constitution per-mettant de sélectionner un sous-ensemble d’un cube existant, selon des critèresmultidimensionnels (navigation dans les hiérarchies de membres des dimensions),descriptifs (sélection selon des attributs textuels ou numériques) et spatiaux (sé-lection selon des attributs géométriques). Ces opérateurs sont présentés dans lapartie 2.2.3.2 de l’article précédent. Les deux sections suivantes approfondissentdavantage la définition de ces opérateurs.

– La livraison des mini-cubes depuis le serveur vers les clients mobiles. Pour assurerun maximum d’interopérabilité avec les diverses plateformes d’informatique mo-bile, cette livraison se fait par l’intermédiaire d’un service Web (cf. 1.2.3.2). Dumême coup, le transport des données sur le réseau (qu’il soit câblé ou sans-fil) est

5Par exemple, la famille de processeurs embarqués Intel XScale (architecture ARM) est disponibledans des fréquences allant de 200 à 624 MHz, ce qui est peu comparé aux processeurs de plus de 2GHz des PC et serveurs actuels.

6et dont la taille est significativement réduite par rapport aux plus gros cube, i.e. méga-octets plutôtque les giga ou même téra-octets des gros entrepôts de données


assuré par les protocoles employés pour l’échange7. Les requêtes au service ainsique les cubes de données retournés au client sont encodés dans un formalismeXML, qui sera décrit en détail au chapitre 3.

2.3.2 Métamodèle pour cubes SOLAP

Afin de définir clairement la terminologie employée dans les exemples à venir, lemodèle de données définissant les objets composant un cube SOLAP est montré àla figure 2.4, sous forme de diagramme de classes UML. Il s’agit en fait d’un méta-modèle d’implantation, puisque tout schéma de cube de données peut être expriméen fonction d’objets de ce modèle. Son niveau d’abstraction le rend également proched’une implantation dans une technologie OLAP donnée. Il fut inspiré en partie dumodèle d’objets multidimensionnels qu’on retrouve dans le langage de requête MDX[Microsoft Corporation, 2007b].

Tout en haut, la classe Entrepôt représente un entrepôt de données contenant descubes SOLAP. Typiquement, une organisation disposera de plusieurs cubes (classeCube) dans un entrepôt, répondant à divers besoins d’analyse. Un entrepôt a un nom,et possède une adresse (URL) permettant d’y accéder via un réseau (i.e. Internet). Dansle cas d’une implémentation conforme aux architectures orientées services (SOA), cetURL est celui donnant accès au service Web de constitution de mini-cubes. Les conceptsse rattachant aux services Web seront vus en détail au chapitre suivant.

La classe Cube représente un cube de données SOLAP. Celui-ci comporte une ouplusieurs dimensions (classe Dimension). Les dimensions peuvent également être detype spatial ou temporel ; cette distinction est purement conceptuelle : en pratique, unedimension est spatiale (géométrique ou mixte) dès lors que les membres d’au moinsun de ses niveaux comportent un attribut géométrique. Il en va de même pour lesdimensions temporelles : elles sont nommées ainsi si leurs membres représentent undécoupage temporel. Il existe également une dimension de mesures pour chaque cube :il s’agit d’un cas particulier de dimension dont les membres représentent les mesures ducube.

Les dimensions peuvent contenir une ou plusieurs hiérarchies (classe Hiérarchie).Lorsqu’il y en a plus qu’une, on parle de hiérarchies multiples : cela est utile lors-qu’on souhaite représenter différents découpages par niveaux (e.g. jour—mois—annéeet jour—semaine—année pour une dimension temporelle). Les hiérarchies sont com-

7soit SOAP sur un transport HTTP, qui est déjà prévu pour opérer sur tout réseau TCP/IP standard


CUBE

Nom

DIMENSION

Nom

NIVEAU

Nom

HIÉRARCHIE

Nom

MEMBRE

Nom

PROPRIÉTÉ

Nom

comporte 0,Nest associée à 1,1

VALEUR PROPRIÉTÉ

comporte 0,N

est associée à 1,1

est décrite par 1,1

décrit 0,N

comporte 1,Nfait partie de 1,N

comporte 1,Nfait partie de 1,1

com

port

e 1

,Nfa

it p

art

ie d

e 1

,1

comprend

0,N

appartient à1,1

CELLULE

Valeur 1,1

est r

éfér

enci

épa

r 1,N

réfé

renc

ie0,

N

comprend

1,N

fait partiede

1,1

DIMENSION DE MESURES

DIMENSION TEMPORELLE

DIMENSION SPATIALE

PROPRIÉTÉ NUMÉRIQUE

PROPRIÉTÉ TEXTUELLE PROPRIÉTÉ GÉOMÉTRIQUE

MESURE

Opérateur d'agrégation 0,N

ENTREPÔT

Nom URL

comporte 0,Nfait partie de 1,1

VALEUR TEXTUELLE

VALEUR NUMÉRIQUE

VALEUR GÉOMÉTRIQUE

est

en

- de

s so

us

de

0,1

est

au

-de

ssu

sd

e0

, 1

estenfant de 0,1

estparent de 0,N

Fig. 2.4 – Métamodèle de cube SOLAP


posées d’un à plusieurs niveaux (classe Niveau), ordonnés du plus sommaire au plusdétaillé. Dans le cas d’une hiérarchie de type parent-enfant, on n’utilise généralementqu’un seul niveau, dans lequel les membres sont liés les uns aux autres de manière ar-borescente8. Mentionnons également qu’une dimension peut être partagée par plusieurscubes au sein d’un entrepôt.

Un niveau définit également quelles propriétés (ou attributs) sont applicables à sesmembres. Ceci est représenté par la classe abstraite Propriété. Les propriétés peuventêtre de divers types de données : il peut s’agir de texte, de nombres ou encore de géo-métries vectorielles (pour les membres spatiaux). Il est également possible d’avoir desreprésentations multiples pour un membre spatial, en définissant plus d’une propriétégéométrique. Les représentations matricielles (raster) telles qu’on retrouve dans les di-mensions spatiales matricielles ou hybrides (cf. 1.2.1.3) ne sont pas supportées dans laversion actuelle de ce modèle, et n’ont pas été implémentées dans le prototype. Il seraittoutefois possible d’étendre le modèle afin de les prendre en compte.

Les membres, quant à eux, sont représentés par la classe Membre. Un membre est uneinstance sur l’axe d’analyse que constitue une dimension. Un membre peut comporter unparent et des enfants, permettant ainsi une navigation hiérarchique parmi les instancesde la dimension. Si un membre ne possède aucun enfant, on parle d’un membre feuille ;il s’agit dans ce cas d’un membre correspondant au grain de la dimension (soit le niveaude détail le plus fin). À l’opposé, un membre n’ayant pas de parent est nommé membre

racine ; celui-ci correspond au niveau le moins détaillé de la dimension (il s’agit dansplusieurs cas du membre « Tous », agrégeant toutes les instances de la dimension).

Lorsqu’il existe des propriétés spécifiées pour les membres d’un certain niveau, cesmembres doivent comporter une valeur pour chacune des propriétés (classe abstraiteValeur Propriété), dont le type concret correspond au type de propriété. C’est cettevaleur de propriété qui contient l’instance concrète de l’attribut du membre (e.g. lagéométrie polygonale représentant les limites administratives de la province de Québec).Il est aussi possible de représenter une omission (donnée manquante) par la valeur« Null ».

Les mesures sont considérées comme un cas particulier de membre (classe Mesure,dérivant de Membre). Les mesures font partie d’une dimension de mesure (cf. 1.2.1.2,définition de « Mesure »). Cette manière de les représenter assure une certaine symé-

8Il importe de dire qu’il ne s’agit que d’un raccourci pour éviter de gérer les hiérarchies parent-enfant comme cas à part : le niveau sert uniquement comme conteneur de membres dans ce cas.Conceptuellement, une hiérarchie parent-enfant comporte tout de même des niveaux implicites, maisqui ne sont ni nommés, ni connus à l’avance lors de la conception du schéma du cube.


trie entre membres et mesures, ce qui simplifie la syntaxe des requêtes : en effet, onpeut considérer que les mesures sont des instances d’un thème d’analyse, représentantles différents types de valeurs mesurées. Plusieurs moteurs OLAP et langages d’inter-rogation de l’industrie gèrent les mesures de cette manière ; c’est le cas de MicrosoftSQL Server Analysis Services, de Mondrian [Pentaho Corporation, 2007], et du langageMDX [Microsoft Corporation, 2007b].

Finalement, les faits du cube sont représentés par la classe Cellule. Une cellulecontient la valeur pour un fait, au croisement d’un membre de chaque dimension (cf.1.2.1.2, définition de « Cellule »). Cette valeur peut être celle d’un fait au niveau leplus détaillé (si tous les membres référant à cette cellule sont des membres feuille),ou bien une valeur agrégée, obtenue avec l’application d’un opérateur agrégatif (e.g.somme, moyenne). Selon l’implémentation du moteur OLAP, cette valeur agrégée peutêtre stockée (dans une table d’agrégations ou dans une structure de type MOLAP) oubien calculée à la volée à partir des faits granulaires. Notons que dans le modèle, unfait absent (un croisement de membres donnés pour lequel il n’y a aucun fait) n’est pasreprésenté par une cellule ayant une valeur « Null », mais bien par l’absence d’un objetcellule9. Ceci s’apparente à la manière dont les faits sont stockés dans une table de faitsd’un schéma étoile : il n’y aura pas de rangée présente pour un fait absent.

2.3.3 Opérateurs de constitution de mini-cubes : approfondis-sement

Les opérateurs de constitution de mini-cubes, décrits dans la partie 2.2.3.2 de l’ar-ticle, servent à sélectionner un sous-ensemble d’un cube présent sur le serveur, afin de letransmettre au client mobile sous forme de mini-cube. Depuis la rédaction de l’article etavec l’avancement du prototype de service Web, ces opérateurs ont été raffinés et grou-pés en deux catégories, soit les opérateurs de sélection de membres et les opérateurs desélection de cellules.

Un nouveau schéma de cube, différent de celui de la partie 2.2.3.2 de l’article etutilisé dans les exemples qui suivent, est présenté à la figure 2.5 10. Ce cube contientdes données de recensement de Statistique Canada, et fut préparé à l’origine par ÈveGrenier pour le cours SCG-66124 — Notions avancées de bases de données SIG. Il a ététransformé et adapté afin de servir aux tests du prototype de service Web de constitution

9d’où la cardinalité 0,N pour la relation membre-cellule : il est possible d’avoir un membre dedimension qui ne réfère à aucune cellule.

10Le formalisme utilisé pour la modélisation du cube est présenté dans Proulx et Rivest [2005].


RECENSEMENT

UNITÉ GÉOGRAPHIQUE

PAYS

RÉGION

PROVINCE

RÉGION ÉCONOMIQUE

DIVISION DE RECENSEMENT

MESURES

Population Naissances Décès

TEMPS

RECENSEMENT

ANNÉE

ÂGE

CATÉGORIE

GROUPE

ÂGE

INTERVALLE

Fig. 2.5 – Schéma conceptuel partiel du cube SOLAP « Recensement »

de mini-cubes (ce point sera abordé plus en détail au chapitre 4, dans la partie 4.1.8).Le cube comprend au total cinq dimensions11, nommées « Âge », « Temps », « Sexe »,« Statut de population » et « Unité géographique ». Pour des fins de présentation desexemples, nous ne retenons que trois dimensions dans le schéma illustré. Notons quela dimension « Âge » comporte une hiérarchie alternative « Catégorie — Intervalle —Âge », en plus de la hiérarchie par défaut « Catégorie — Groupe — Âge ».

2.3.3.1 Opérateurs de sélection de membres

L’exploration d’un cube de données passe en premier lieu par une prise de connais-sance des membres des dimensions. Les membres décrivent les entités de la réalité pourlesquelles on retrouve des faits dans le cube. Afin que l’utilisateur puisse explorer cesur quoi porte les données et choisir ce qui devra être inclus dans le mini-cube, on doitmettre à disposition du client mobile un mécanisme permettant d’obtenir les membresdes dimensions. Dans le contrat de service (cf. partie 2.2.4 de l’article et chapitre 3),cette fonctionnalité est comblée par la méthode GetMembers.

Pour sélectionner un ensemble de membres, il faut en premier lieu spécifier la dimen-

11dimension des mesures exclue


sion, la hiérarchie et le niveau qui contiennent les membres. Ensuite, un ou plusieursopérateurs de sélection sont choisis. Ces opérateurs sont des prédicats appliqués à cha-cun des membres ; si le prédicat est évalué comme vrai, le membre est inclus dansl’ensemble qui est retourné en réponse au client. Les prédicats suivants sont proposés :

Sélection de tous les membres : ce prédicat retourne toujours vrai pour chacun desmembres ; ainsi, tous les membres de la dimension, de la hiérarchie et du niveauspécifié seront inclus dans l’ensemble.

Sélection selon le nom du membre : on spécifie un ou plusieurs noms ; si le nomdu membre évalué est contenu dans la liste, le membre est inclus dans l’ensemble.

Sélection selon la valeur d’un attribut : on spécifie un attribut de membre (unepropriété) ainsi qu’une condition que doit satisfaire la valeur de l’attribut. Sila valeur de l’attribut du membre évalué satisfait la condition (e.g. « Nombred’employés <= 10 » pour un membre « Commerce »), il est inclus dans l’ensemble.

Sélection par analyse spatiale : il s’agit d’un cas particulier d’une sélection selon lavaleur d’un attribut, s’appliquant uniquement aux attributs spatiaux des membresd’une dimension spatiale géométrique. Dans ce cas, on spécifie le nom de la pro-priété contenant la géométrie, ainsi qu’un opérateur d’analyse spatiale (prédi-cat topologique) avec au besoin une géométrie pour fins de comparaison (e.g.le membre doit intersecter le polygone spécifié). Si l’attribut spatial du membreévalué satisfait le prédicat topologique, il est inclus dans l’ensemble. Cet opéra-teur est particulièrement intéressant pour les utilisateurs mobiles, car il permetd’obtenir les membres en fonction de critères de localisation (par exemple selonle positionnement absolu ou relatif du client mobile).

Il est également possible d’inclure les ancêtres ou les descendants des membres del’ensemble, de manière optionnelle. Cela permet au client mobile d’offrir la navigationdans les hiérarchies de membres. De plus, l’opération GetMembers offre une manièred’appliquer des transformations aux attributs spatiaux des membres de l’ensemble :par exemple, un algorithme de filtrage tel que Douglas-Peucker peut être appliquépour la simplification géométrique. Selon les besoins des clients, d’autres transforma-tions peuvent être proposées : changement de format de géométrie (e.g. GML à SVG),changement de systèmes de référence spatiale et de projection cartographique, etc. Ladescription du contrat de service Web, présentée au chapitre 3, décrit plus en détail lesfonctionnalités de l’opération GetMembers.


QUÉBECONTARIO NOUVEAU-BRUNSWICK

BAS-SAINT-LAURENT CAPITALE-NATIONALE CHAUDIÈRE - APPALACHES

LA MITIS RIMOUSKI-NEIGETTE LA CÔTE-DE-BEAUPRÉ COMMUNAUTÉ-URBAINE-DE-QUÉBEC MONTMAGNY BELLECHASSE

...

... ... ...

...

Niveau : Province

Niveau : Région économique

Niveau : Division de recensement

Fig. 2.6 – Opérateur « Inclusion de membres et de leurs descendants »

2.3.3.2 Opérateurs de sélection de cellules

Ces opérateurs, intervenant dans la méthode GetCells du contrat de service (voirchapitre 3), contrôlent quelles cellules sont incluses dans le mini-cube résultant, parune sélection effectuée à partir des membres des dimensions. On peut appliquer un seulde ces opérateurs pour chacune des dimensions12 : il définira quels membres feuillesferont partie de la nouvelle dimension dans le mini-cube. La dimension d’origine, sur leserveur, n’est jamais modifiée ; cette sélection s’applique à la volée et n’affecte que lemini-cube constitué en temps réel par le service Web.

Inclusion de membres et de leurs descendants : se fait sur un ou plusieursmembres, afin d’inclure tous leurs descendants au niveau feuille. Cela a pour effetde restreindre la dimension à un sous-ensemble de ses membres, tout en conser-vant la même granularité que la dimension d’origine. Si on applique cet opérateurà des membres du niveau feuille, cela a simplement pour effet de les inclure unpar un.

Exemple (voir figure 2.6) : pour la dimension « Unité géographique », on choisitle membre « Québec » au niveau « Province ». L’opérateur sélectionne tous lesmembres feuille qui ont comme ancêtre « Québec », soit les divisions de recen-sement qui font partie du Québec. Le mini-cube résultant inclut donc toutes lescellules se rapportant aux divisions de recensement du Québec, mais exclut toutesles autres dans le reste du pays.

Agrégation sur un ou plusieurs membres : les cellules se rattachant aux membressélectionnés avec cet opérateur (donc des cellules contenant des valeurs agrégées)

12Il a été choisi de se limiter à l’application d’un seul opérateur par dimension, afin de simplifierla syntaxe et d’éviter toute sélection conflictuelle (e.g. sélectionner un membre d’un niveau inférieurd’une dimension alors qu’on choisit d’agréger sur un niveau supérieur).


PRODUCTIFS 25-64JEUNES <25 ÂGÉS 25+

ENFANTS 2-11...

...

...

Niveau : Catégorie

Niveau : Groupe

BÉBÉS <2 ADOLESCENTS 12-17 JEUNES ADULTES 18-24

Niveau : Âge

0 1 2 3 ... 12 13 17 18...

Fig. 2.7 – Opérateur « Agrégation sur un ou plusieurs membres »

sont incluses dans le mini-cube. Les membres choisis d’une dimension doivent sesituer à un seul et même niveau. En choisissant tous les membres d’un niveau,cela revient à restreindre la granularité de la dimension à ce niveau (les cellulescorrespondant aux membres des niveaux inférieurs sont exclues du mini-cube).Appliquer cet opérateur à des membres du niveau feuille est également possible :dans ce cas, cela a pour effet d’inclure ces membres, et les cellules qui s’y rat-tachent. Dans ce cas particulier, les valeurs pour ces cellules correspondent auxfaits les plus granulaires, et donc il n’y aura pas d’agrégation appliquée à ces va-leurs. En fait, lorsqu’appliqué à des membres feuille, cet opérateur est équivalentau précédent (inclusion de membres et de leurs descendants).

Exemple (voir figure 2.7) : on souhaite agréger sur les membres « Bébés <2 »,« Enfants 2-11 » et « Adolescents 12-17 » du niveau « Groupe » dans la dimen-sion « Âge » (en considérant uniquement la hiérarchie « Catégorie — Groupe —Âge »). La dimension « Âge » du mini-cube résultant ne comportera plus de ni-veau « Âge », autrement dit le nouveau grain de la dimension sera au niveau« Groupe ». Les membres inclus dans cette dimension seront les trois qui ont étésélectionnés, et les cellules incluses dans le mini-cube se rapporteront uniquementà ces trois groupes d’âge ; les cellules correspondant aux autres groupes d’âgesseront exclues.

Réduction de dimension : cet opérateur permet de « trancher » (slice) sur unmembre d’une dimension. Cela a pour effet d’exclure une dimension du cuberésultant, en définissant sur quel membre les cellules seront projetées. La dimen-sionnalité du mini-cube est donc réduite lorsqu’on applique cet opérateur.

Exemple (voir figure 2.8) : on souhaite obtenir uniquement les statistiques de l’an-née 2001 dans le mini-cube résultant, autrement dit on « tranche » sur le membre« 2001 » au niveau « Année » de la dimension « Temps ». Le mini-cube résul-tant ne contiendra que les cellules se rapportant à l’année 2001, et la dimension« Temps » sera exclue des thèmes d’analyse.


RECENSEMENT

ÂGETEMPSUNITÉ GÉOGRAPHIQUE

RECENSEMENT 2001 (2001-2003)RECENSEMENT 1996 (1996-2000)

...

Niveau : Recensement

Niveau : Année

200120001999 2002...

PAYS

RÉGION

PROVINCE

RÉGION ÉCONOMIQUE

DIVISION DE RECENSEMENT

MESURES

Population Naissances Décès

RECENSEMENT

ANNÉE

CATÉGORIE

GROUPE

ÂGE

INTERVALLE

Schéma du mini-cube résultant:

Fig. 2.8 – Opérateur « Réduction de dimension »

Sélection des mesures : tel qu’indiqué dans le métamodèle présenté à la section 2.3.2,les mesures sont représentées comme un cas particulier de membres, dans unedimension spécifique aux mesures. Ainsi, il est possible d’appliquer un des troisopérateurs précédents pour spécifier quelles mesures on souhaite inclure dans lemini-cube. Puisque la dimension de mesures ne comporte qu’un seul niveau (lesmesures sont toujours des membres feuille), les opérateurs Inclusion de membres

et de leurs descendants et Agrégation sur un ou plusieurs membres ont le mêmeeffet dans ce cas. Si on souhaite ne retenir qu’une seule mesure et exclure lesautres du thème d’analyse, il est possible d’appliquer l’opérateur Réduction de

dimension.

2.3.4 Problèmes liés aux opérateurs de constitution de mini-cubes

2.3.4.1 Changement de la définition des membres

Lorsqu’on choisit d’inclure seulement une partie des membres d’un niveau dans lemini-cube, certains effets sont à prévoir en ce qui concerne la définition des membresdes niveaux supérieurs, ainsi que pour les cellules correspondantes contenant des valeursagrégées pour les mesures. Prenons un exemple, toujours avec le cube de la figure 2.5 :pour la construction d’un mini-cube, on choisit d’agréger uniquement sur les membres« Capitale-Nationale » et « Chaudière-Appalaches » du niveau « Région économique ».Ces deux membres remontent au membre « Québec » du niveau « Province ». Si onsouhaite encore représenter le niveau « Province » dans le mini-cube, il y aurait commeproblème que le membre « Québec » n’aurait plus la même définition que dans le cubed’origine. Premièrement, sa définition sémantique changerait : on ne retrouverait plusque deux régions économiques sous le membre « Québec », au lieu des 17 d’origine.


Les valeurs agrégées pour les mesures correspondant au membre « Québec » ne seraientplus les mêmes : par exemple, on verrait uniquement la somme de la population desdeux régions économiques. La complétude des données est donc affectée, puisque lesinstances du niveau inférieur ne sont plus toutes présentes (se référer au concept de« fullness » tel que décrit par Pourabbas et Rafanelli [2003] et Rafanelli et Shoshani[1990]). Cela introduit le risque de mauvaise interprétation des données par l’utilisateurdu mini-cube.

La définition spatiale du membre « Québec » peut également se trouver altérée,de deux manières possibles : si on conserve la géométrie d’origine, soit les limites duQuébec en entier, la représentation spatiale ne correspondrait plus à la couvertureréelle des données, ce qui peut induire l’utilisateur en erreur. D’autre part, si on génèrela géométrie du membre « Québec » à partir des géométries des membres inférieursinclus dans le mini-cube (en utilisant un opérateur d’agrégation spatiale, e.g. union),la représentation ne serait plus que les limites des deux régions économiques, ce qui necorrespondrait donc pas à la définition spatiale réelle du Québec.

Une telle situation peut survenir avec l’utilisation des opérateurs de sélection decellules « Inclusion de membres et de leurs descendants » et « Agrégation sur un ouplusieurs membres ». Trois approches sont proposées pour gérer ce problème et ainsiréduire le risque de mauvaise interprétation :

– Exclure les niveaux supérieurs de la dimension. Si on fait une inclusion de membres(et de leurs descendants) ou une agrégation sur un ou plusieurs membres, il pour-rait être souhaitable d’exclure complètement du mini-cube tous les niveaux supé-rieurs de la dimension concernée, éliminant de ce fait le problème décrit. En effet,si on ne retient qu’un petit sous-ensemble des membres à un niveau particulier,il est raisonnable de supposer qu’on n’ait plus besoin des catégories supérieuresdans les analyses. Dans l’exemple précédent, tous les membres retenus sont dansla province de Québec ; ainsi, il est fort probable que les autres provinces ne soientpas d’intérêt pour les analyses que l’utilisateur souhaite effectuer à partir de cemini-cube.

– Inclure les membres des niveaux supérieurs, mais en stockant les valeurs agrégéesd’origine pour les cellules correspondant à ces membres. Certaines applicationsOLAP permettent le stockage des valeurs de cellules agrégées, correspondant auxmembres non-feuille du cube, afin de réduire le temps de réponse aux requêtes.Dans le cas de JMap Spatial OLAP, le pré-calcul et le stockage de toutes lescombinaisons possibles de cellules agrégées est obligatoire : aucun calcul n’esteffectué à la volée, et chaque valeur de cellule présentée à l’utilisateur se retrouvedans la table de faits de l’entrepôt de données. Dans ce cas, il est possible de


contourner le problème de l’exemple précédent en altérant manuellement la valeurstockée pour la cellule agrégée correspondant à la population du Québec : aulieu de la somme des populations des deux régions économiques, on y mettra lavaleur d’origine pour la population du Québec en entier. Cette approche n’estpas recommandée car elle viole une des condition de « summarizability » telle quedéfinie par Rafanelli et Shoshani [1990], puisque des valeurs sont manquantes dansle cube pour produire par calcul la valeur agrégée pour la population du Québec(cela introduit un cas d’incomplétude des données). De plus, dans les produitsOLAP autres que JMap Spatial OLAP, il n’est pas garanti qu’une requête utilisela valeur stockée dans une table d’agrégations pré-calculées : il est possible quecertaines requêtes utilisent les faits les plus granulaires pour calculer à la volée lavaleur des cellules agrégées. Dans ce cas des résultats incorrects risquent d’êtreaffichés.Une alternative élégante à ce problème est d’introduire un nouveau membre dansle mini-cube, au niveau « Région économique », nommé « Autres régions écono-miques du Québec ». Ce membre représentera l’agrégation de toutes les régionséconomiques du Québec, sauf « Capitale-Nationale » et « Chaudière-Appalaches ».Formellement, il s’agira d’un membre représentant l’union de la différence entrel’ensemble composé de tous les membres enfants de « Québec » (au niveau « Ré-gion économique ») et l’ensemble composé des membres « Capitale-Nationale »et « Chaudière-Appalaches ». Ainsi, pour la mesure « Population », la sommedes populations des membres « Capitale-Nationale », « Chaudière-Appalaches »et « Autres régions économiques du Québec » sera égale à la valeur d’origine pourla population du Québec. La condition de « summarizability » est ainsi préservée.

– Introduire des avertissements à l’utilisateur. Levesque et al. [2007] proposent uneapproche pour l’identification et la gestion des risques reliés à une mauvaise uti-lisation des cubes de données spatiales. Un des points saillants de cette méthodeest l’introduction d’avertissements à l’utilisateur dans les applications SOLAP,comme mesure de gestion des risques. Si l’application cliente supporte l’intégra-tion de tels avertissements, concernant certains membres du cube, il serait possibled’ajouter un message à afficher comme attribut du membre « Québec », spéci-fiant que la définition du membre a été modifiée dans le mini-cube (i.e. certainsmembres enfants sont absents), par rapport à sa définition d’origine dans le cubesur le serveur. L’utilisateur pourra donc être avisé du changement, ce qui réduit lerisque de mauvaise interprétation. Le développement d’une méthode pour intégreret présenter de tels avertissements dans une application SOLAP dépasse toutefoisle cadre du présent projet de recherche.


JEU N ES < 25

...

...

N iveau : C a tégorie

N iveau : G roupe

EN F AN T S 2-11

N iveau : Â ge

1 2

N iveau : In te rva lle

...

BÉBÉS <2 AD OLESC EN T S 12-17

3...

11 12

<5 5-9 10-14

4 5 9 10...

...

?

Fig. 2.9 – Opérateur « Inclusion de membre et de leurs descendants » avec hiérarchiesmultiples

2.3.4.2 Hiérarchies multiples

Certaines dimensions peuvent avoir des hiérarchies multiples. C’est le cas de ladimension « Âge » du cube montré à la figure 2.5, qui comporte deux hiérarchies :« Âge — Groupe — Catégorie » et « Âge — Intervalle — Catégorie ». Le niveau le plusdétaillé est nécessairement partagé entre les hiérarchies alternatives d’une dimension,puisque c’est à ce niveau que les faits sont liés aux membres de la dimension. Par contre,cette règle ne tient plus pour les niveaux supérieurs : on ne peut pas toujours établirune correspondance 1:1 ou 1:N entre les membres des niveaux de deux hiérarchies ; ladéfinition sémantique des membres ainsi que les relations hiérarchiques (i.e. quel membreest le parent d’un autre) diffèrent. Le nombre de niveaux peut également varier entredeux hiérarchies.

Un exemple de sélection de cellules, utilisant l’opérateur « Inclusion de membres etde leurs descendants », est montré à la figure 2.9. On souhaite inclure toutes les cel-lules correspondant aux descendants (membres feuilles) de « Enfants 2-11 » au niveauGroupe. Les membres « 2 » à « 11 » du niveau « Âge » sont inclus dans le mini-cube. Ce-pendant, il n’existe aucun ensemble de membres du niveau « Intervalle » de la hiérarchiealternative qui corresponde exactement à cette sélection : bien que tous les descendantsdu membre « 5-9 » font partie de l’ensemble sélectionné au niveau « Âge », les membres« <5 » et « 10-14 » ont des descendants qui sont exclus de l’ensemble sélectionné.

Par conséquent, l’application des opérateurs de sélection de cellules se limite à uneseule hiérarchie. Les autres hiérarchies de la dimension ne seront donc pas représentéesdans le mini-cube résultant.


2.3.4.3 Simplification géométrique

Tel qu’expliqué à la fin de la partie 2.2.3.2 de l’article précédent, ainsi que dans lasous-section 2.3.3.1, le service Web de constitution de mini-cubes offre des opérateursde simplification géométrique, intervenant dans la méthode GetMembers, afin de ré-duire la complexité de la géométrie des membres spatiaux. Une telle simplification estsouhaitable pour trois raisons : premièrement, cela a pour effet de réduire la taille destockage des membres spatiaux, et par le fait même le temps de transmission du mini-cube. Deuxièmement, le rendu et l’affichage de géométries simplifiées sera plus rapidesur les appareils mobiles, si on considère que la vitesse de processeur de ces derniersest plus limitée que celle des ordinateurs de bureau. Finalement, des géométries moinsdétaillées sont plus appropriées pour l’affichage sur des écrans de petite taille et defaible définition : la lisibilité se trouve ainsi améliorée par la présentation de cartes plusgénéralisées [Reichenbacher, 2001].

Il importe de spécifier que l’approche proposée (algorithme de simplification deDouglas-Peucker) l’est uniquement à titre de preuve de concept, pour montrer qu’ilest possible de simplifier à la volée les membres spatiaux du cube. Plusieurs problèmespeuvent être introduits par l’application naïve d’un tel algorithme dans le cas de donnéesagrégées multi-échelles telles que l’on retrouve dans les cubes SOLAP. Par exemple, cetalgorithme peut causer des trous et des chevauchements entre deux régions polygonalesadjacentes (voir figure 2.10 pour un exemple), puisque la topologie des membres n’estpas considérée. De plus, des inconsistances peuvent être introduites entre les niveaux :par exemple, si on applique indépendamment la simplification géométrique aux membresdu niveau « Province » ainsi qu’à ceux du niveau « Pays », il est possible que l’uniongéométrique de toutes les provinces du Canada ne soit pas identique à la géométriesimplifiée du Canada. Ce type d’inconsistances est décrit par Bédard et al. [2007] comme« disparités spatiales d’agrégation-généralisation ». Cela ne pose toutefois pas toujoursproblème, dépendamment des besoins d’analyse : une telle situation serait acceptablepour l’affichage de simples cartes thématiques.

Plusieurs travaux de recherche portent sur les problématiques de généralisation car-tographique au sein des cubes de données SOLAP. Les approches multi-agents pour lagénéralisation [Ruas et Duchêne, 2007], les objets auto-généralisants [Sabo, 2007] ainsique les travaux du groupe GiMoDig sur la généralisation cartographique en temps réel[Sester et al., 2004] pourraient apporter des solutions aux problèmes de généralisationdans le cadre de l’adaptation des cubes SOLAP pour une utilisation sur client mo-bile. D’autres recherches prometteuses portent sur la gestion des contraintes d’intégritéspatiales pour les cubes de données [Salehi et al., 2007]. Le processus de généralisa-tion cartographique pourrait être facilité grâce au stockage explicite de la topologie


Chevauchement

Trou

Fig. 2.10 – Résultat de l’application naïve d’un algorithme de simplification géomé-trique

des membres spatiaux13, ainsi qu’avec la définition de contraintes spatiales entre lesdifférents niveaux du cube.

2.3.5 Infrastructure technologique SOLAP et diffusion auxmobiles

Deux approches sont proposées dans l’article en ce qui concerne l’infrastructuretechnologique sur laquelle s’appuie le service Web de constitution de mini-cubes : unebasée sur un outil ETL et une autre basée sur un serveur OLAP. C’est cette dernièresolution qui fut retenue pour le développement du prototype. Cette section reprend plusen détail la réflexion qui a mené à ce choix.

Dans le cadre de nos travaux, nous supposons qu’une organisation qui envisage dedéployer des applications décisionnelles géomatiques pour un environnement informa-tique mobile a déjà mis en place une infrastructure technologique pour les systèmesd’aide à la décision (cf. section 1.2.1), soit un entrepôt de données, des systèmes d’in-

13Cela rejoint l’une des conclusions du mémoire de maîtrise de Declercq [2008] : le stockage explicitede la topologie permettrait d’accélérer le processus de mise à jour de cubes.


tégration (e.g. procédures ETL) servant à alimenter cet entrepôt à partir des sourcesde données, ainsi que des applications analytiques existantes (OLAP/SOLAP, généra-tion de rapports, data mining, etc.). Les applications SOLAP mobiles s’inscrivent donccomme un prolongement de l’infrastructure déjà en place.

2.3.5.1 Service basé sur un outil ETL : failles de l’approche

Dans les toutes premières phases de ce projet de recherche, nous avons envisagéde constituer les mini-cubes à l’aide d’un outil ETL (Extract-Transform-Load). Celaapparaissait raisonnable, puisque ces outils servent entre autres à transformer les don-nées des systèmes opérationnels pour les adapter aux schémas multidimensionnels (enétoile, en flocon et parent-enfant) des entrepôts de données décisionnelles. Par analogie,nous avons supposé qu’il serait viable de transformer, à l’aide d’un ETL, les donnéesexistantes (provenant soit des systèmes opérationnels sources ou bien déjà intégrées etorganisées au sein d’un entrepôt de données) en mini-cubes.

Il s’est avéré que cette approche comporte une faille majeure : les outils ETL gèrentles données selon un modèle relationnel, et non multidimensionnel. Cela convient pourle peuplement des tables d’un entrepôt de données : bien que leurs schémas (étoile,flocon, parent-enfant) soient issus d’une modélisation multidimensionnelle des données,il ne s’agit pas pour autant de cubes OLAP proprement dits ; un serveur OLAP et unmapping relationnel vers multidimensionnel sont nécessaires afin d’offrir une véritablevue multidimensionnelle des données, composée d’objets OLAP (tel que décrit dans lasection 2.3.2).

Or, les opérateurs de constitution de mini-cubes s’appuient sur une vue multidi-mensionnelle des données, afin d’offrir à l’utilisateur un maximum de flexibilité pourla sélection des objets (membres et faits) à inclure dans le mini-cube. L’implémenta-tion de tels opérateurs avec des procédures ETL, agissant sur des objets du modèlerelationnel (tables, colonnes et rangées) serait une tâche extrêmement difficile. En fait,cela impliquerait le développement d’un véritable ETL multidimensionnel, intégrant lesfonctionnalités d’un outil ETL avec celles d’un serveur OLAP, et capable d’appliquerà la volée un mapping relationnel vers multidimensionnel sur le flux de données inté-grées, provenant de différents systèmes sources. De plus, les outils ETL actuels ne sontpas adaptés pour faire l’exportation des données vers des formats XML basés sur desschémas d’applications sur mesure (tel que le format XML pour cubes SOLAP, définidans le chapitre 3), nécessitant davantage d’efforts de développement pour produire descubes en format XML.

Pour ces raisons, l’approche basée sur un outil ETL a été définitivement écartée,


laissant place à la conception d’un service s’appuyant sur les fonctionnalités d’un serveurOLAP.

2.3.5.2 Service basé sur un serveur OLAP

Cette approche fait appel aux fonctionnalités d’un serveur OLAP pour constituerles mini-cubes de données. Ainsi, un tel service se placerait aux côtés des applicationsanalytiques existantes d’une organisation, telles que clients OLAP, SOLAP, tableurs(supportant des sources de données OLAP) et tableaux de bord. Le service comportetrois rôles principaux :

– Accepter et répondre aux requêtes de constitution de mini-cubes, provenant desclients mobiles : il s’agit d’offrir sous forme de service Web SOAP14 les opérationsrequises pour la création des mini-cubes, telles que décrites dans la section 2.2.4de l’article. C’est la partie publique du service, qui est accessible aux utilisateursvia le réseau. Les opérateurs de constitution de mini-cubes (cf. section 2.3.3)sont mis en œuvre dans les appels des opérations GetMembers et GetCells. Plusprécisément, tous les paramètres d’invocation de ces opérateurs sont encodés dansun dialecte XML et encapsulés à l’intérieur des messages SOAP de requêtes.Le chapitre 3 décrit en détail le format de ces requêtes ainsi que des réponsesassociées.

– Traiter les requêtes de constitution de mini-cubes : lorsqu’un client demande del’information sur le schéma d’un cube (opération DescribeSchema), et fait une re-quête sur les membres (GetMembers) ou encore les cellules (GetCells), le serviceWeb doit interroger le serveur OLAP pour obtenir ces données. Les requêtes sontdonc interprétées par le service Web et transformées en appels des méthodes del’interface de programmation (API) du serveur OLAP. Puisque les requêtes trans-mises au serveur OLAP nécessitent l’usage d’un langage d’interrogation multidi-mensionnel, le service doit construire celles-ci à partir des opérateurs de constitu-tion de mini-cubes. Le mécanisme employé dans le prototype, soit la générationde requêtes MDX à partir des opérateurs de sélection de cellules, est décrit dansle chapitre 4 portant sur la réalisation du prototype.

– Transmettre les données du mini-cube au client : les réponses aux requêtes multi-dimensionnelles, provenant du serveur OLAP, doivent être transformées en formatXML afin de pouvoir être transmises vers le client par l’intermédiaire du proto-cole SOAP. Le service Web doit être en mesure d’effectuer cette traduction. Une

14cf. 1.2.3.2. Le choix de l’encapsulation SOAP est arbitraire ; il serait également possible d’offrir unservice POX/HTTP (ou REST) ayant les mêmes fonctionnalités avec un minimum de modificationsau contrat de service.


considération particulière doit être accordée aux objets spatiaux du cube, soit lesgéométries des membres spatiaux, afin de pouvoir les représenter en XML : lasolution retenue est d’encoder les géométries avec la norme GML, par souci deconformité avec les standards de l’OGC et puisqu’il s’agit d’un format supportépar la majorité des cadres de développement logiciels en géomatique. Le chapitresuivant décrit en détail l’encodage XML qui a été développé à cette fin.

Un avantage majeur d’une approche s’appuyant sur un serveur OLAP pour le ser-vice est qu’elle utilise la même infrastructure technologique que les autres applicationsgéo-décisionnelles d’une organisation. Ainsi, les utilisateurs mobiles auront accès auxmêmes cubes de données que les utilisateurs de bureau, tout en ayant à leur disposi-tion des mécanismes très flexibles permettant d’adapter ces données aux particularitésdes environnements mobiles. Les coûts reliés au support de cette catégorie d’utilisa-teur se trouvent également réduits, puisque tous les efforts consacrés à la conception denouveaux cubes, à la mise à jour des cubes existants, à l’enrichissement des cubes parl’ajout de nouvelles sources de données, ainsi que toute autre amélioration apportée auxsystèmes analytiques (e.g. installation de serveurs plus puissants) pourra bénéficier di-rectement aux utilisateurs mobiles, sans avoir à entreprendre de modifications majeuresau service Web de constitution de mini-cubes et aux applications clientes mobiles.

2.4 Conclusion

Ce chapitre a permis de dresser les bases de l’architecture du service Web de consti-tution de mini-cubes. L’article est venu introduire le concept du mini-cube, soit uncube de données SOLAP de taille réduite destiné aux clients mobiles (cf. 2.2.3). Unensemble d’opérateurs permettant de constituer les mini-cubes à partir de cubes SO-LAP existants a été présentée dans l’article (cf. 2.2.3.2) ; sont apportés en complémentle métamodèle de classe décrivant les objets sur lesquels ces opérateurs agissent (cf.2.3.2), ainsi qu’un raffinement et une description plus détaillée de ces opérateurs (cf.2.3.3). Le positionnement de la solution par rapport aux environnements mobiles et auxcontraintes de mobilité a également été abordé (cf. 2.3.1).

Quelques limites et problèmes sont soulevés par l’approche proposée, soit l’applica-tion d’opérateurs de constitution de mini-cubes (cf. 2.3.4). Ces limites se rapportent auchangement de la définition des membres (e.g. exclusion d’une partie des descendantsd’un membre), aux sélections dans les hiérarchies multiples ainsi qu’aux méthodes desimplification géométrique. Sur ce dernier point, les travaux de recherche portant surla généralisation cartographique pourraient apporter des solutions pour mieux adapter


les entités spatiales afin de les afficher convenablement sur les écrans de taille réduitedes appareils mobiles.

Le prochain chapitre porte sur la réalisation de la solution proposée sous formede service Web. Un encodage XML servant à transmettre les mini-cubes SOLAP ysera introduit, de même qu’un contrat de service (WSDL) décrivant les opérateurs deconstitution de mini-cubes.

Chapitre 3

Encodage XML pour cubes SOLAPet contrat de service

Le système présenté dans le chapitre précédent, conçu et développé dans le cadre decette recherche, s’appuie sur les principes des architectures orientées services, réaliséessous forme de services Web. L’échange des données entre le service et les clients mobilesdoit alors s’appuyer sur un encodage XML. Cette manière de faire vise à palier auxcontraintes d’interopérabilité techniques, et ainsi garantir l’accès au service par diverstypes de clients fonctionnant sous des technologies hétérogènes (e.g. matériel, systèmesd’exploitation et applications de différents fournisseurs). Or, il n’existe pas à l’heureactuelle de spécification technique portant sur l’encodage des données spatiales mul-tidimensionnelles (i.e. les cubes SOLAP) en format XML. Il a donc été entrepris dedévelopper un tel encodage. L’article présenté dans ce chapitre porte sur ce nouveauformat d’encodage XML pour les cubes de données SOLAP. Les requis concernant lesparticularités des données spatiales multidimensionnels y sont énoncés (cf. 3.2.2), et ladescription technique du format d’encodage y est faite (cf. 3.2.3). En complément à cetarticle, nous présentons le contrat de service WSDL décrivant formellement la syntaxedes messages qui sont échangés entre le client et le service (cf. 3.3.1), et nous discutonsdes particularités des environnements mobiles dont il faut tenir compte par rapport àl’utilisation d’XML et des services Web (3.3.2).

3.1 Contributions

L’article (en anglais) constituant le corps de ce chapitre est référencé ci-dessous.

Chapitre 3. Encodage XML pour cubes SOLAP et contrat de service 82

[Dubé et al., 2008] Dubé, E., T. Badard et Y. Bédard. 2008, « An interoperable XMLencoding for the exchange of Spatial OLAP data cubes in SOA environments », dans

31st International Convention MIPRO on Business Intelligence Systems (miproBIS),Opatija, Croatie.


3.2 Corps de l’article

Titre : An interoperable XML encoding for the exchange of Spatial OLAP data cubesin SOA environments


Résumé : Les technologies de XML et des services Web ont révolutionné la manièredont 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 quedes spécifications de services Web telles que XML for Analysis permettent l’utilisationd’outils OLAP dans des architectures orientées services (SOA — Service Oriented Ar-

chitecture), 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’unemanière interopérable.

Cet article propose un nouvel encodage XML pour l’échange de cubes de donnéesSOLAP, contenant les données et métadonnées spatiales et descriptives. Cela permetla livraison du schéma du cube, des membres de dimensions (incluant la géométrie desmembres spatiaux) et des faits. Ce format XML peut être utilisé dans le développe-ment de services Web pouvant être déployés dans différentes situations, ne se limitantpas aux plateformes client-serveur traditionnelles mais également aux environnementsd’informatique mobile et ubiquitaire.

Abstract: XML and Web Services technologies have revolutionized the way data areexchanged on the Internet. Meanwhile, Spatial OLAP (SOLAP) tools have emergedto bridge the gap between the Business Intelligence and Geographic Information Sys-tems domains. While Web Services specifications such as XML for Analysis enable theuse of OLAP tools in Service Oriented Architecture (SOA) environments, no solutionaddresses the exchange of complete SOLAP data cubes (comprising both spatial anddescriptive data and metadata) in an interoperable fashion.

This paper proposes a new XML grammar for the exchange of SOLAP data cubes,containing both spatial and descriptive data and metadata. It enables the delivery ofthe cube schema, dimension members (including the geometry of spatial members) andfact data. This XML format can be used in the development of Web Services to bedeployed in various situations, not limited to traditional client-server platforms but alsoubiquitous mobile computing environments.


3.2.1 Introduction

The World Wide Web Consortium’s (W3C) XML (eXtensible Markup Language) spec-ification [World Wide Web Consortium, 2006] has gained large popularity as a dataexchange format on the Internet. Along with the growing acceptance of Service Ori-ented Architecture (SOA) and Web Services technologies [Cerami, 2002], it providesthe means to exchange information between heterogeneous systems, independently ofprogramming language, operating system, hardware and software platforms. XMLgrammars have been developed for various applications. This is also the case for ge-ographic information systems (GIS), with the Geography Markup Language (GML)specification [ISO/TC211, 2004] from the Open Geospatial Consortium (OGC) and In-ternational Organization for Standardization (ISO), along with Web Services proposalssuch as Web Feature Service (WFS) [OGC, 2005], enabling the exchange of geographicfeatures in distributed GIS applications.

In the meantime, SOLAP (Spatial OLAP) tools have been introduced to supportthe exploration and analysis of geospatial decision-support data. It is described as“a type of software that allows rapid and easy navigation within spatial databasesand that offers many levels of information granularity, many themes, many epochsand many display modes that are synchronized or not: maps, tables and diagrams”[Rivest et al., 2005]. Based on OLAP (On-Line Analytical Processing) [Codd et al.,1993] technologies merged with GIS components, these tools provide interactive tabular,graphical and cartographical views of spatial data cubes, which are multidimensionaldatasets comprising spatial data such as the geometry of countries and regions. Thisenables analysts to fully exploit the spatial component characterizing about 80% of allenterprise data [Franklin, 1992].

Emerging SOLAP applications, especially in mobile computing environments, haveprompted the need for an interoperable and reliable way to deliver SOLAP data cubes toheterogeneous clients. Unconventional usage patterns, such as disconnected operationwhen roaming between mobile networks, and inherent limits of mobile computing suchas limited bandwidth and processing capabilities, render traditional client-server OLAPpoorly suited for these cases. SOA and Web Services have been considered as a suitablesolution for these new applications [Badard et al., 2008].

GML and WFS specifications well cover the interchange of transactional geospa-tial data, traditionally found in operational systems. However, analytical systems suchas SOLAP are often based on the multidimensional paradigm, in which data is rep-resented in terms of hypercubes, composed of objects such as dimensions, membersand facts. This contrasts with transactional data, typically represented by tables con-


taining columns and rows. Several proposals have been made for the transmission ofOLAP data through XML documents and Web Services. XML for Analysis (XMLA)[Microsoft and Hyperion, 2002], introduced by Microsoft and Hyperion, is targetedtowards client-server applications using the MDX (“MultiDimensional eXpressions”)query language [Microsoft Corporation, 2007], thus encapsulating MDX queries andresult sets in XML messages. It is therefore not suited for the exchange of completedata cubes (data and metadata) for disconnected operation in mobile clients, and itlacks support for spatial data. XCube, a set of XML document templates for OLAPcubes [Hümmer et al., 2003], is capable of representing complete cubes, but has no pro-vision for spatial data either. Another research paper proposes a Web Service, named“GML for Analysis” (GMLA) [da Silva et al., 2005], which leverages the capabilities ofXMLA and WFS, providing a way to combine multidimensional and spatial queries,and embed spatial data in the result sets. However, like XMLA, this technology issuited for client-server applications using a query-response paradigm, with result setsintended for presentation (i.e. in spreadsheets or other analytical clients), and not forthe transmission of complete SOLAP cubes.

This paper introduces a new XML format for the exchange of multidimensionalgeospatial data, addressing the shortcomings of existing proposals. This format lever-ages the GML grammar for the representation of geographic features, and is inspiredin some aspects by existing XML and Web Service standards used in the OLAP in-dustry. Possible uses of such a format include the dissemination of SOLAP cubes (orsubsets of these cubes) from a central data warehouse to distributed data marts, thetechnical integration of heterogeneous systems (e.g. migrating SOLAP data betweenproducts of different vendors) and the implementation of Web Services for the deliveryof SOLAP data to clients on the Internet or to mobile clients over wireless networks.The paper is divided as follows: first, requirements for the XML exchange of multidi-mensional spatial data are described. This is followed by the technical specification ofthe XML format itself. An application of this format, in the context of a geospatialdecision-support Web Service for the delivery of spatial cubes to mobile devices, is alsoproposed. Finally, future outlooks and research challenges are discussed.

3.2.2 Requirements for a SOLAP data cube XML format

Existing specifications and proposals for the XML exchange of either spatial data (GML,WFS) and multidimensional data (XMLA, GMLA and XCube) do not fully addressthe issue of delivering complete spatial data cubes, comprising both the metadata (thedefinition of the cube schema including dimensions, levels and measures) and the data(the dimension members and the fact cells). This prompts the design of a new XML


format to overcome limits identified in existing ones. Several requirements have beenidentified for such a format, and are presented in this section.

3.2.2.1 Representation of both data (facts and members) and metadata(schema)

The exchange of complete data cubes requires encoding of both cube data and metadata(schema). Query services such as XML for Analysis specify only the transmission ofdata and a subset of the schema (query axes) describing the resulting cell set. Whilesuch a response format is suitable for presentation purposes (e.g. for displaying data ina spreadsheet), it is not sufficient for transmitting the full cube schema, i.e. dimensions,hierarchies and levels.

By including both the full cube schema along with fact and member data, a clientapplication retrieving an XML-encoded data cube will have all the information neces-sary to use the cube in an autonomous manner. This is a first reason why the proposedXML encoding must provide for a representation of both data and metadata. In addi-tion, metadata are necessary to assess the quality of measures.

3.2.2.2 Based on existing standards

In order to address interoperability with current and future systems, the XML encodingfor SOLAP data cubes should be based on existing standards and specifications.

Geography Markup Language (GML) is a standardized way to encode geographicfeatures in XML form, which can be used for spatial members in SOLAP data cubes.GML elements can be embedded inside the XML cube schema, seamlessly includinggeographic features. Nevertheless, other XML specifications, such as Scalable VectorGraphics (SVG), KML (as used in Google Earth) or GeoRSS could be substituted forthis purpose, depending on the specific application context.

With regard to the XML representation of multidimensional data structures in datacubes, the only existing de facto specification is XMLA. However, as explained in theintroduction, it does not fulfill all the requirements for the exchange of complete SOLAPdata cubes.


3.2.2.3 Be independent of particular implementations in OLAP and GISproducts

One of the reasons of using open standards is to avoid lock-in to proprietary softwareplatforms. Since the proposed XML format for SOLAP data cubes aims to be open andinteroperable, it must not be tied to particular OLAP software. This can be achievedby choosing a common subset of features supported by most OLAP servers. Most ofthem support some form of a multidimensional data model, composed of dimensions,hierarchies, levels, members, measures and facts; these objects have to be expressed ina homogeneous form in the XML encoding. As previously explained, using an openstandard like GML also ensures interoperability with regards to geographic data. In-dependence from proprietary query languages and APIs is also a requirement. In thisway, systems implementing the proposed XML encoding could be based on almost anyOLAP and GIS products from the market. The possibility of exchanging SOLAP databetween systems from different vendors is also a benefit of this approach.

3.2.2.4 Support for spatial dimensions and spatial members

SOLAP cubes are characterized by the inclusion of spatial members in geographicdimensions, and sometimes spatial measures [Bédard and Han, 2008]. The proposedXML encoding must provide the mechanisms for including the spatial component inthese members and measures. This requirement is fulfilled by using an XML-basedstandard such as GML for encoding geospatial objects, as previously explained.

3.2.2.5 Support of shared dimensions

More than one cube can refer to the same dimension: for example, a “sales” cube and an-other “payroll” cube could refer to a same “employee” dimension. In the literature, suchshared dimensions are often referred to as conformed dimensions [Kimball and Ross,2002]. In addition, this technique allows one to perform analysis across different cubes,by joining them by their shared dimensions.

The encoding should support this feature, by not restricting a dimension to thecontext of a single cube. Multiple cubes can refer to a shared dimension document,to avoid replicating the dimension schema (hierarchies and levels) and data (members)redundantly across cubes.


3.2.2.6 Describing calculated measures and members

Sometimes, calculated measures (or members) are defined to display expressions com-puted at run-time. Languages such as MDX allow users to define calculated memberswithin a query. Most OLAP products also offer the capability to declare calculatedmembers in the cube schema; in this way calculated measures and members are ac-cessible to all users of the cube. These predefined calculated members should alsobe expressed as part of the cube metadata encoded in XML form, so clients wouldhave access to these members. However, the question of calculated spatial measuresand aggregate operators on spatial members is still a research issue, currently beinginvestigated by our research group. By now, only numerical calculated measures aresupported.

3.2.2.7 Separation of contents and presentation

Separation of contents and presentation is a design practice that aims to distinguishbetween the expression of semantics, as represented in data, and the presentation ofthe information to end users. For example, the same data in a SOLAP cube can bepresented in different forms: cross-tabs, charts, reports and maps. Moreover, the outputdevice can vary: contents can be displayed in an interactive SOLAP desktop client orin a Web page, it can be printed or it can be displayed on the small screen of a mobiledevice such as a personal digital assistant (PDA) or a cell phone. Finally, the graphicsemiology used to represent data depends on the context (purposes, users, standards).

Accordingly, the XML cubes should contain only the data and its structure, i.e.cube schema. Any information specifying how to display the data to users, i.e. textformat, chart colors and style, classes (ranges) for measure values, map symbols and soon, would be external to the XML data cube documents. The rendering and displayformat of SOLAP data can vary greatly and is dependant of the capabilities of theclient application. Moreover, presentation is subject to customization by the user insome applications. For these reasons, the proposed XML format does not specify a wayto encode presentation information.

3.2.3 Specification of the XML encoding

Considering the requirements presented in the last section, a specification of the XMLencoding for SOLAP data cubes has been designed. The proposed encoding is inspired


from the XCube paper [Hümmer et al., 2003] but uses grammar and semantics closerto the data models of most OLAP software (specifically, terminology used in the MDXquery language). A SOLAP data cube encoded with this specification would consistof three documents, respectively for the cube schema, dimension members and celldata. Separating the cube contents in three parts allows for progressive discoveryof cube metadata and data. There are three root elements in the model, one foreach type of document, i.e. CubeSchema, CubeMembers and CubeCells. A W3C XMLSchema (WXS) definition [Fallside and Walmsley, 2004] was developed for formalizingthe semantics of the encoding and for validation of data cube documents1.

3.2.3.1 CubeSchema document

The CubeSchema document encodes information pertaining to the structure of the cube.It identifies the cube name and all its dimensions with their respective hierarchies, levelsand properties. An example CubeSchema document is presented in listing 3.1.

Listage 3.1: CubeSchema document example<?xml version="1.0" encoding="UTF -8"?>

<cubeSchema xmlns="http: // geosoa.scg.ulaval.ca/GeoCubeML"

xmlns:xs="http: //www.w3.org /2001/ XMLSchema"

xmlns:gml="http: //www.opengis.net/gml"

xmlns:xsi="http: //www.w3.org /2001/ XMLSchema -instance"

xsi:schemaLocation ="http: // geosoa.scg.ulaval.ca/GeoCubeML CubeSchema.xsd">

<include fileLocation="WholesalersDimensions .xml" />

<cube name="Sales">

<dimension name="Measures" isMeasure="true">

<dimensionDef >

<level name="MeasuresLevel ">

<property name="aggregators">

<contentType ref="aggregator"

minOccurs="1" maxOccurs="unbounded" />

</property >

<property name="measureType">

<contentType ref="contentType" />

</property >

</level >

</dimensionDef >

</dimension >

<dimension name="Store">

<dimensionUsage defName="WallyWorld Stores" />

</dimension >



</cube>

<sharedDimensions >

<dimensionDef defName="WallyWorld Stores">

1The WXS definition (XSD file) and UML data model are available at: http://geosoa.scg.

ulaval.ca/GeoCubeML/

http://geosoa.scg.ulaval.ca/GeoCubeML/

http://geosoa.scg.ulaval.ca/GeoCubeML/


<hierarchy name="Administrative limits" default="true"/>

<hierarchy name="Population areas" />

<level name="(All)" isAll="true" />



<level name="City">

<inHierarchy hierarchy="Administrative limits" />

<rollupTo level="Province" />

<property name="City geometry">

<contentType ref="gml:AbstractSurface " />

</property >

</level >

<level name="Agglomeration ">

<inHierarchy hierarchy="Population areas" />

<rollupTo level="Province" />

<property name="Agglomeration geometry">

<contentType ref="gml:AbstractSurface " />

</property >

</level >

<level name="Retail outlet">

<rollupTo level="City" />

<rollupTo level="Agglomeration " />

<property name="Retail outlet geometry">

<contentType ref="gml:Point" />

</property >

<property name="Number of floors">

<contentType type="xs:integer" />

</property >

</level >

</dimensionDef >

</sharedDimensions >

</cubeSchema >

At the root of the document lies the <cubeSchema> element. Optional <include>

elements can be used to refer to external XML documents, to be included in the cur-rent cube schema. The <cube> element is used for defining the schema of a cube; therecan be more than one in a single document. The optional <sharedDimensions> ele-ment provides for the definition of dimensions shared across cubes. Shared dimensionscan come from external files, as specified in <include> elements; this allow sharingdimension definitions across many CubeSchema documents.

The <cube> element has one or more <dimension> elements as children. A dimen-sion is identified by its name attribute. An isMeasure optional attribute specifies if thisis the measure dimension, i.e. whose members identify the measures. A dimension canbe defined in two manners: either with a <dimensionDef> element directly embeddedin <dimension>, defining a dimension which is local to the cube, or with a <dimen-

sionUsage> element, which refers to the name of a shared <dimensionDef>, defined inthe <sharedDimensions> element (child of <cubeSchema>).


A <dimensionDef> element has one or more <level> children, defining which levelscompose the dimension. Each <level> element can contain zero or more <rollupTo>

children, identifying the parent level. More than one parent level can be specifiedwhen using multiple hierarchies. In this case, <hierarchy> elements must figure under<cube>, to declare the hierarchy names and which to use by default; <inHierarchy>

elements are used under <level> to specify which hierarchies (one or more) the levelis part of. Omitting <inHierarchy> means that a level is shared by all the hierar-chies of the current dimension. Levels can also have optional <property> elements,declaring member properties (i.e. attributes). Properties have a name, and contain a<contentType> element, specifying either which WXS simple data type (with the type

attribute) or which complex XML elements (with the ref attribute, referring to an ele-ment declared in a WXS definition, with optional minOccurs and maxOccurs attributesdefining cardinality) can be used as property values. This design choice, leveraging W3CXML Schema (WXS), allows the inclusion of any XML element to be used as memberattributes. In the example, properties are declared with “gml:AbstractSurface” and“gml:Point” element references, respectively allowing the use of GML surface (region)or point geometries. Any other XML encoding of geometry could be substituted instead(for example SVG).

3.2.3.2 CubeMembers document

Once a cube schema is specified with the CubeSchema document, the members in its di-mensions have to be described. This is done using the CubeMembers document (listing3.2). Members are represented as <member> elements, and are contained in succes-sively embedded <cubeRef>, <dimensionRef> and <levelRef> elements, referring tothe cube, dimension, and level defined in CubeSchema. A member has a name at-tribute, uniquely identifying it, and can contain <rollupTo> elements, describing theroll-up relationships to other members. These can be to members of a higher level, orto members of the same level as it is the case in parent-child hierarchies. More than one<rollupTo> element can be specified for a member, to account for multiple hierarchies(i.e. a member in a level rolling-up to members in two alternate levels, in differenthierarchies). In this case the parent level must be specified (with the level attribute).Values for member properties are represented with <propertyValue> elements. Thiselement contains data in any form authorized by XML, and constrained by the WXStype specified for the property in CubeSchema. The client application is responsible forensuring conformity to the property’s data type (i.e. by validating <propertyValue>

contents against the WXS definition for the namespace of the data type.) Finally, op-tional <include> elements can also be used under <cubeMembers>, to specify membersstored in external files (e.g. for shared dimensions).


Listage 3.2: CubeMembers document example<?xml version="1.0" encoding="UTF -8"?>

<cubeMembers xmlns="http: // geosoa.scg.ulaval.ca/GeoCubeML"





<cubeRef name="Sales">

<dimensionRef name="Measures">

<levelRef name="MeasuresLevel ">

<member name="Sales amount">

<propertyValue property="aggregators">

<aggregator ><sum /></aggregator >

</propertyValue >

<propertyValue property="measureType">

<contentType type="xs:decimal" />

</propertyValue >

</member >



<member name="Quantity in stock">

<propertyValue property="aggregators">

<aggregator ><sum /></aggregator >

<aggregator dimension="Time">

<avg />

</aggregator >

</propertyValue >

<propertyValue property="measureType">

<contentType type="xs:integer" />

</propertyValue >

</member >

</levelRef >

</dimensionRef >

<dimensionRef name="Store">

<levelRef name="(All)">

<member name="All Stores" isAll="true" />

</levelRef >



<levelRef name="Province">

<member name="Prince Edward Island">

<rollupTo member="Canada" />

<propertyValue property="Province geometry">

<gml:MultiPolygon >

<gml:polygonMember >

<gml:Polygon >

<gml:outerBoundaryIs >

<gml:LinearRing >

<gml:coordinates >

-63.17146699969915 ,46.126305000168074



-63.17146699969915 ,46.126305000168074

</gml:coordinates >

</gml:LinearRing >

</gml:outerBoundaryIs >

</gml:Polygon >

</gml:polygonMember >



</gml:MultiPolygon >

</propertyValue >

</member >




</levelRef >

</dimensionRef >

</cubeRef >

</cubeMembers >

In the example, we see a special case of member in the “Measures” dimension.These are measures, defined using <member> elements, and having the following spe-cial properties which are to be interpreted by the client application. The “aggregator”property contains <aggregator> elements, defining the type of operator used for aggre-gation (sum, average, etc.). More than one <aggregator> element can be specified, toaccount for non-additive or semi-additive measures (for example stocks or population,which cannot be summed across time) [Kimball and Ross, 2002]. Additional aggregatorsmust specify which dimension they apply to (using the dimension attribute), indicat-ing the client application which aggregative formula to use, instead of the default one,when summarizing along this specific dimension. Finally, the “measureType” prop-erty is used to specify the WXS data type or element for cell values corresponding tothis measure, using the same <contentType> element introduced for the CubeSchema

document. This allows for a great flexibility in the representation of non-numericalmeasures, for example geometric spatial measures [Bédard and Han, 2008].

3.2.3.3 CubeCells document

CubeCells, the last type of document, is shown in listing 3.3. It contains the individ-ual cells representing the facts of the cube. A <cubeRef> element identifies the cube(described in a CubeSchema document) to which the cells belong. Then, each cell isrepresented as a <cell> element, composed of a <tuple> with several <memberRef>

elements (each one referring to a member in each dimension) and a <cellValue> forthe value of the fact. A value can be of either a simple data type (number, string)or a complex one (e.g. a GML geometry representing a spatial measure). Usually, aCubeCells document will contain only the cells corresponding to leaf members of eachdimension, or in other words the most granular data. The client application can dy-namically rebuild all the cube cells at less detailed levels, by applying the aggregationoperators defined in CubeMembers for each measure. Cells corresponding to non-leafmembers can also be included if needed (to include pre-computed aggregates for perfor-mance reasons or for cells corresponding to non-summarizable measures which cannotbe obtained from an aggregative formula).

Listage 3.3: CubeCells document example<?xml version="1.0" encoding="UTF -8"?>

<cubeCells xmlns="http: // geosoa.scg.ulaval.ca/GeoCubeML"




<cubeRef name="Sales">

<cell>

<tuple >

<memberRef dimension="Measures" level="MeasuresLevel "

member="Sales amount" />

<memberRef dimension="Product" level="Item"

member="Fuzzy dice" />

<memberRef dimension="Time" level="Day"

member="2007 -08 -23" />

<memberRef dimension="Store" level="Retail outlet"

member="Downtown Quebec City" />

</tuple >

<cellValue >120.00 </cellValue >

</cell>

<cell>

<tuple >

<memberRef dimension="Measures"

level="MeasuresLevel " member="Sales amount" />

<memberRef dimension="Product" level="Item"

member="Fuzzy dice" />

<memberRef dimension="Time" level="Day"

member="2007 -08 -23" />

<memberRef dimension="Store" level="Retail outlet"

member="Sainte -Foy" />

</tuple >

<cellValue >210.00 </cellValue >

</cell>



</cubeRef >

</cubeCells >

3.2.3.4 Relevance of the encoding for spatial data and SOA

The proposed encoding has two characteristics making it suitable for spatial data andSOA: first, it takes into account the specificity of spatial data in a generic and exten-sible manner. By considering that any complex XML data can be part of membersand facts, this encoding can leverage external XML Schemas such as GML, SVG andGoogle KML, allowing for the representation of rich spatial data and extensibility forfuture versions of these standards. Second, its structure is particularly suited to coarse-grained, document-oriented Web services, which have a central role in Service OrientedArchitectures (SOA) [Ort, 2005]. By having a loosely-coupled way to integrate SO-LAP systems, promoting component reuse and interoperability, productivity gains indevelopment can be achieved.


3.2.4 Example of an implementation

The described XML format was first designed for a Web Service for the delivery ofSOLAP mini-cubes to mobile clients [Dubé et al., 2007]. A mini-cube is a data cube ofreduced size, extracted from existing cubes, and adapted with respect to the constraintsof mobile computing (i.e. reduced CPU speed and storage size of PDAs or cell phones,limited bandwidth and coverage of wireless networks).

The Web Service is invoked using the SOAP protocol [Box et al., 2000]. The ser-vice contract, i.e. the operations accessible to clients, is described in WSDL (WebServices Description Language) [Christensen et al., 2001]. The following operations aresupported:

1. GetCapabilities: this operation informs the client about the service version andgives information on the identification (name and address of the organization,etc.).

2. DescribeSchema: this operation is used to get the metadata describing cubes, di-mensions, hierarchies, levels and measures, returned in a <cubeSchema> element.

3. GetMembers: this operation allows querying of cubes’ dimensions to retrieve theirmembers. It must support the navigation into a hierarchy of members, i.e. getthe parents or children of a specific member, get the members of a level, etc.This operation also offers mechanisms to select members based on their spatialattributes, with metric or topological operators. The selected members are re-turned in a <cubeMember> element.

4. GetCells: this operation is intended to query the facts of a data cube. Theargument of this operation forms a multidimensional “select query” that definesthe set of cells to be obtained and returned as part of a <cubeCells> element.

5. GetCube: this operation is used to retrieve a complete cube. It is based on theGetCells operation to get the data, and adds all the members that correspond tothe mini-cube selection and the schema description of this mini-cube (metadata,i.e. dimensions, hierarchies, levels and measures structure). The XML documentthat is returned is a complete representation of the requested mini-cube (data andmetadata), i.e. regrouping <cubeSchema>, <cubeMembers> and <cubeCells>

elements.

A prototype implementation of this Web Service has been developed (Fig. 3.1). Itis based on the open source Mondrian OLAP server and a PostgreSQL DBMS (with


D ata s ourc es (operational system s )

G eoK ett le (E TL proc edures )

Dataextraction Data loading

M in i-cu b e co n stru ctio nW e b S e rv ice

(OL A P -b a se d)

M u ltid im e n sio n a l sp a tia l d a ta w a re h o u se

(PostgreSQL+PostGIS )

O LA P S erv er(GeoM ondr ian:

M ondr ian + spatia l extensions )

Queries(SQL)

Responses

Queries(MDX /

Mondrian API )

Responses

M obile S O LA Pc lient

Serviceinvocation

(SOAP requests )

Response(XML mini -cube )

Figure 3.1: Architecture of the Web service for SOLAP mini-cube delivery

PostGIS spatial extensions) for the data warehouse back-end. It uses Mondrian toquery data cubes and extract a subset of these (i.e. a sub-cube) corresponding toa user-defined selection, done with operations from the service contract. This sub-cube is then serialized to the XML encoding, in order to deliver a mini-cube for usewith a mobile client. The mobile SOLAP client then de-serializes the mini-cube to anembedded database prior to use, since XML is useful as an exchange format, but notsuited for direct query (due to parsing overhead and lack of indexes).

3.2.5 Conclusion and outlooks

The requirements and the specification of an XML encoding for SOLAP data cubeshave been presented. It allows the exchange of geospatial decision-support data inan interoperable manner. It enables the representation of cube metadata and data,and supports spatial members and measures. Its use was also illustrated in a WebService for delivering SOLAP cubes to mobile clients. Other uses include any situationwhere cubes have to be exchanged between different computing environments, as oftenrequired in Enterprise Application Integration (EAI) systems.

It should be noted that XML data size and verbosity could pose problems withregards to the CubeCells documents. Since a data cube can contain millions of facts,encoding all the individual cells with references to members would yield a very largedocument. This can be mitigated with data compression. However, this solution doesnot address parsing overhead. A better approach could consist of a more compactencoding: for example, a multidimensional cell set can be stored by first defining axeswith ordered positions referring to members, and then sequentially writing all cell values.In addition, binary XML formats such as EXI [Schneider and Kamiya, 2008] or FastInfoset [ITU-T, 2005] could be used to further improve parsing speed and reduce datasize, especially for mobile computing environments.


The proposed encoding addresses the requirements listed in section 3.2.2, except for3.2.2.6. Further work is required to enable the representation of calculated members: anew language, with a corresponding XML encoding, will have to be designed to describecalculated members in an interoperable manner. In addition, while the XML formatprovides for technical interoperability between SOLAP systems, it does not solve theproblem of semantic interoperability, i.e. the integration of heterogeneous data cubeswith conflicts in meaning, interpretation and intended uses. Ongoing research workaims to address these issues [Sboui et al., 2007]. Another research novelty which couldeventually extend the XML cube model is the concept of raster-based spatial datacubes, based on a continuous grid division of space instead of discrete (vector) geometricfeatures [Bédard and Han, 2008].

3.2.6 Acknowledgments

This work has been made possible with grants from the NSERC Industrial ResearchChair in Geospatial Databases for Decision Support (http://mdspatialdb.chair.

scg.ulaval.ca). We would also like to thank the Canadian Institute of GeomaticsScholarship Program.

3.2.7 References (for the paper only)

Badard, T., Y. Bédard, F. Hubert, E. Bernier and E. Dubé. 2008, «Web services-oriented architectures for mobile SOLAP applications», International Journal of Web

Engineering and Technology (IJWET).

Bédard, Y. and J. Han. 2008, «Fundamentals of spatial data warehousing for geographicknowledge discovery», in Geographic Data Mining and Knowledge Discovery, 2nd

edition, ed. by H. J. Miller and J. Han, chap. 3, Research Monographs in GeographicInformation Systems, Taylor & Francis.

Box, D., D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. F. Nielsen,S. Thatte and D. Winer. 2000, «Simple Object Access Protocol (SOAP) 1.1», spé-cification technique, World Wide Web Consortium. http://www.w3.org/TR/2000/

NOTE-SOAP-20000508/.


http://mdspatialdb.chair.scg.ulaval.ca


http://www.w3.org/TR/2000/NOTE-SOAP-20000508/



Christensen, E., F. Curbera, G. Meredith and S. Weerawarana. 2001, «Web ServicesDescription Language (WSDL) 1.1», spécification technique, World Wide Web Con-sortium. http://www.w3.org/TR/wsdl.

Codd, E. F., S. B. Codd and C. T. Salley. 1993, «Providing OLAP to users-analysts:an IT mandate», white paper, Hyperion Solution Corporation.

Dubé, E., T. Badard and Y. Bédard. 2007, «Service Web de constitution en temps réelde mini-cubes SOLAP pour clients mobiles: une architecture orientée services pourl’utilisation mobile des données géo-décisionnelles», in SAGEO 2007, Rencontres in-

ternationales Géomatique et territoire (CD-ROM), Clermont-Ferrand, France, ISBN978-2-85710-078-2.

Fallside, D. C. and P. Walmsley. 2004, «XML Schema Part 0: Primer (Second Edi-tion)», spécification technique, World Wide Web Consortium. http://www.w3.org/

TR/xmlschema-0/.

Franklin, C. 1992, «An introduction to geographic information systems: linking mapsto databases», Database, Vol. 15, no. 2, pp. 12–21, ISSN 0162-4105.

Hümmer, W., A. Bauer and G. Harde. 2003, «XCube: XML for data warehouses», inDOLAP ’03: Proceedings of the 6th ACM international workshop on Data warehous-

ing and OLAP, ACM, New York, NY, USA, ISBN 1-58113-727-3, pp. 33–40.


ITU-T. 2005, «Information technology — Generic applications of ASN.1: Fast infoset»,spécification technique, International Telecommunication Union (ITU).

Kimball, R. and M. Ross. 2002, The Data Warehouse Toolkit: The Complete Guide to


Microsoft and Hyperion. 2002, «XML for Analysis Specification, version 1.1», spécifi-cation technique, Microsoft Corporation.

Microsoft Corporation. 2007, «Multidimensional Expressions (MDX) Reference»,http://msdn2.microsoft.com/en-us/library/ms145506.aspx.

OGC. 2005, «Web Feature Service Implementation Specification, version 1.1.0», spéci-fication technique, Open Geospatial Consortium.

Ort, E. 2005, «Service-Oriented Architecture and Web Services: Concepts, Tech-nologies, and Tools», white paper, Sun Microsystems. http://java.sun.com/

developer/technicalArticles/WebServices/soa2/.

http://www.w3.org/TR/wsdl




http://java.sun.com/developer/technicalArticles/WebServices/soa2/



Rivest, S., Y. Bédard, M.-J. Proulx, M. Nadeau, F. Hubert and J. Pastor. 2005,«SOLAP: Merging Business Intelligence with Geospatial Technology for InteractiveSpatio-Temporal Exploration and Analysis of Data», Journal of ISPRS “Advances in

spatio-temporal analysis and representation”, Vol. 60, no. 1, pp. 17–33.

Sboui, T., Y. Bédard, J. Brodeur and T. Badard. 2007, «A Conceptual Framework toSupport Semantic Interoperability of Geospatial Datacubes», in ER Workshops, pp.378–387.

Schneider, J. and T. Kamiya. 2008, «Efficient XML Interchange (EXI) Format 1.0, 3rdworking draft», spécification technique, World Wide Web Consortium. http://www.

w3.org/TR/exi/.

da Silva, J., V. C. Times, R. do Nascimento Fidalgo and R. S. M. de Barros. 2005,«Providing Geographic-Multidimensional Decision Support over the Web», in AP-

Web, Lecture Notes in Computer Science, Vol. 3399, ed. by Y. Zhang, K. Tanaka,J. X. Yu, S. Wang and M. Li, Springer, ISBN 3-540-25207-X, pp. 477–488.

World Wide Web Consortium. 2006, «Extensible Markup Language (XML) 1.0 (FourthEdition)», spécification technique, World Wide Web Consortium. http://www.w3.

org/TR/REC-xml/.

http://www.w3.org/TR/exi/


http://www.w3.org/TR/REC-xml/



3.3 Compléments à l’article

L’encodage XML servant à la transmission des mini-cubes de données entre le ser-veur hébergeant le service Web et le client mobile a été décrit dans l’article. La définitionXML Schema décrivant formellement la syntaxe de cet encodage est présenté en an-nexe A (partie A.2.1, listage A.4). Les suppléments d’information amenés dans cettesection concernent la description du contrat de service donnant la syntaxe XML pourl’invocation des opérations supportées par le service Web, ainsi que les impacts qu’ontles contraintes de mobilité sur certains aspects de l’encodage XML et du contrat deservice.

3.3.1 Contrat de service et opérations

La section 3.2.4 de l’article reprend les opérations du contrat de service Web quifurent brièvement introduites au chapitre précédent. Cette section approfondit davan-tage sur le contenu de ce contrat, en indiquant la définition exacte de chaque opéra-tion, accompagnée d’exemples de requêtes et réponses. Ainsi, le lien est établi entreles opérateurs de constitution de mini-cubes présentés au chapitre précédent et leurimplémentation sous forme de service Web.

3.3.1.1 Retour sur WSDL

Tel que mentionné dans la section 1.2.3 (voir chapitre 1), WSDL (Web Services

Description Language) est une spécification permettant de décrire formellement lescontrats de services Web. Bien que la version 2.02 de WSDL soit la plus récente, lagrande majorité des outils de développement actuels ne supportent que la version 1.1.Par conséquent, les exemples donnés dans cette section s’appuient sur la syntaxe deWSDL 1.1.

Un document WSDL comporte deux rôles principaux. Premièrement, il fait officede documentation du service Web : un développeur qui construit une application s’ap-puyant sur un service peut connaître de manière claire et précise quelles sont les opé-rations supportées par le service, et quels messages peuvent être envoyés en requêteet reçus comme réponse pour chacune de ces opérations. Deuxièmement, le documentWSDL peut servir à la génération automatique de code : des outils pour différents

2Voir http://www.w3.org/TR/wsdl20-primer/

http://www.w3.org/TR/wsdl20-primer/


langages de programmation (Java, C# , C++, etc.) permettent de générer des stubs

et skeletons à partir du document WSDL3. Ceux-ci sont des classes représentant lesopérations et messages supportés par le service ; elles exposent toute l’interface de pro-grammation décrite par le contrat de service, et peuvent être utilisées comme point dedépart pour l’implémentation des portions client (à partir des stubs) et serveur (à partirdes skeletons). Il ne reste alors que la logique d’application à développer.

Un document WSDL comporte cinq sections principales :

– Une section sur les types de données employés dans les messages. Dénotée par l’élé-ment <types>, cette section contient une définition de la structure des élémentsXML entrant dans les messages échangés entre le client et le service. Cette défi-nition s’appuie sur la spécification XML Schema du W3C [Fallside et Walmsley,2004]. Des schémas existants peuvent être intégrés dans cette définition : en plusdes types primitifs définis par XML Schema (integer, string, float, etc.), on peutréutiliser d’autres définitions à même le document WSDL. Dans le cas du serviceWeb de constitution de mini-cubes, le contrat de service WSDL intègre les élé-ments de la définition XML Schema du format XML de livraison de cubes SOLAPdécrit dans l’article, ainsi que celle de GML pour l’encodage des entités spatiales.

– Une section sur les messages composant le service. Il s’agit des éléments <mes-

sage>, déclarant quels sont les messages de requête et de réponse qui sont sup-portés par le service. On y définit quels éléments, préalablement définis dans lasection sur les types de données, forment le corps de chacun des messages.

– Une section sur les opérations composant le service. Ces opérations sont déclaréesdans des éléments <operation>, et regroupées à l’intérieur d’un élément <port-

Type>. Cela permet de grouper les messages en entrée (requête) et en sortie (ré-ponse), tels que déclarés dans la section précédente, à l’intérieur d’une opérationpouvant être invoquée par les clients.

– Une section sur les liaisons (bindings). Il s’agit de l’élément <binding>, spécifiantquel protocole est utilisé pour l’échange des messages de chaque opération déclaréeà la section précédente. Dans le cas du service Web présenté dans ce chapitre, laliaison est faite avec le protocole SOAP. Il est aussi possible de lier les opérationsà d’autres protocoles, par exemple XML sur HTTP (sans encapsulation SOAP)pour les services Web de style POX/HTTP (ou encore REST).

– Une section sur les informations d’adressage. Représentée par l’élément <ser-

vice>, cette section identifie à quelle adresse le service peut être invoqué. Il liela spécification des liaisons (bindings) à un URL représentant le point d’accès

3Par exemple, Apache Axis2, un cadre de développement pour services Web en Java, supporte lagénération de classes Java à partir d’un document WSDL selon trois mappings XML-objets : ADB,XMLBeans et JiBX (voir http://ws.apache.org/axis2).

http://ws.apache.org/axis2


(endpoint) du service. C’est à cette adresse que le client se connecte pour envoyerdes requêtes au service. Par conséquent, cette section doit être configurée spécifi-quement en fonction de l’emplacement réseau du serveur sur lequel le service estdéployé.

La section la plus importante dans le cas du service Web présenté ici est celle décri-vant les types de données employés dans les messages. Puisque les requêtes et réponsesmobilisant les opérateurs de constitution de mini-cubes (tels que définis au chapitre2) impliquent un paramétrage hautement complexe4, elles ne peuvent s’effectuer enpassant de simples éléments des types de données primitifs : de nouveaux élémentscomplexes sont définis dans le document WSDL pour documenter et valider toute lagamme des opérateurs. Des schémas supplémentaires, soit l’encodage XML de cubesdécrit dans l’article, ainsi que GML et OGC Filter Encoding, y sont également misen œuvre, permettant ainsi la livraison des données multidimensionnelles et spatialesdes mini-cubes. Les prochaines sous-sections se consacreront donc principalement àla description des messages employant ces nouveaux types de données, accompagnéed’exemples de requêtes et réponses. L’emphase est mise sur ces exemples, puisqu’ilsdécrivent de manière claire la syntaxe d’invocation du service, par l’entremise de re-quêtes typiques. Pour des fins de référence, le document WSDL complet et les schémasXML associés, avec les déclarations de tous les types de données composant le contratde service, sont donnés en annexe A (partie A.2.2, listages A.5 à A.7). Afin de ne pasalourdir le texte, les en-têtes SOAP ne sont pas montrés ; des messages de requête etde réponse plus complets (en-têtes inclus) sont également en annexe A (partie A.2.3,listages A.8 à A.15).

3.3.1.2 Opération GetCapabilities

L’opération GetCapabilities permet au client d’obtenir des métadonnées telles quel’identification du service, sa version ainsi que les noms et informations de contact del’organisation et des personnes responsables du service. Elle permet également d’obtenirla liste des cubes disponibles. Il s’agit donc d’une opération similaire aux GetCapabilities

des services Web Feature Service (WFS) [OGC, 2005b] et Web Map Service (WMS)[OGC, 2002] de l’OGC.

La requête est composée d’un simple élément <GetCapabilitiesRequest>, sans para-mètres supplémentaires :

4Les requêtes en question comportent souvent plusieurs éléments XML complexes (avec attributset éléments imbriqués) pour paramétrer les opérateurs appliqués aux objets du cube et combiner dessélections spatiales et descriptives. Voir partie 3.3.1.4, listage 3.10 pour un exemple.


Listage 3.4 – Exemple d’élément de requête GetCapabilitiesRequest<mcws:GetCapabilitiesRequest xmlns:mcws="http: // geosoa.scg.ulaval.ca/MinicubeWS" />

La réponse prend la forme suivante :

Listage 3.5 – Exemple d’élément de réponse GetCapabilitiesResponse<mcws:GetCapabilitiesResponse xmlns:mcws="http: // geosoa.scg.ulaval.ca/MinicubeWS">

<mcws:ServiceIdentification >

<mcws:ServiceType >MinicubeWS </mcws:ServiceType >

<mcws:ServiceTypeVersion >0.20</mcws:ServiceTypeVersion >

<mcws:Title >MinicubeWS test</mcws:Title >

<mcws:Abstract >Abstract ...</mcws:Abstract >

</mcws:ServiceIdentification >

<mcws:availableCubes >

<mcws:availableCube name="Recensements" />

</mcws:availableCubes >

</mcws:GetCapabilitiesResponse >

On retrouve dans cette réponse les informations sur l’identification du service (élé-ment <ServiceIdentification>) et la liste des cubes disponibles (élément <available-

Cubes>). Dans l’exemple ci-dessus il n’y a qu’un seul cube listé, soit « Recensements ».Par souci de ne pas complexifier l’implémentation du prototype, la version actuelle ducontrat de service ne comporte qu’une partie des éléments de métadonnées qui pour-raient figurer dans les réponses de l’opération GetCapabilities. Une future version duservice pourrait s’appuyer sur la spécification OGC Web Services Common Specifica-

tion [OGC, 2007] en ce qui concerne la structure des métadonnées, afin de permettreune documentation plus exhaustive du service et également pour assurer une meilleureuniformité et interopérabilité avec les services Web géographiques de l’OGC.

3.3.1.3 Opération DescribeSchema

DescribeSchema est l’opération qui permet d’obtenir le schéma d’un cube, soit lesmétadonnées décrivant sa structure : dimensions, hiérarchies, niveaux et propriétés demembres pour chaque niveau. Le message de requête se compose d’un seul élément<DescribeSchemaRequest>, avec un attribut cubeName spécifiant le nom du cube pourlequel on demande le schéma.

Listage 3.6 – Exemple d’élément de requête DescribeSchemaRequest<mcws:DescribeSchemaRequest xmlns:mcws="http: // geosoa.scg.ulaval.ca/MinicubeWS"

cubeName="Recensements" />

La réponse contient un document CubeSchema, tel que décrit dans l’article inclusdans le présent chapitre, encapsulé dans l’élément <DescribeSchemaResponse> :


Listage 3.7 – Exemple d’élément de réponse DescribeSchemaResponse<mcws:DescribeSchemaResponse xmlns:mcws="http: // geosoa.scg.ulaval.ca/MinicubeWS">

<gcml:cubeSchema xmlns:gcml="http: // geosoa.scg.ulaval.ca/GeoCubeML"

xmlns:xs="http: //www.w3.org /2001/ XMLSchema" xmlns:gml="http: //www.opengis.net/gml"



<gcml:cube name="Recensements">

<gcml:dimension name="Measures" isMeasure="true">

<gcml:dimensionDef >

<gcml:hierarchy name="Measures" default="true" />

<gcml:level name="MeasuresLevel " />

</gcml:dimensionDef >

</gcml:dimension >



</gcml:cube >

</gcml:cubeSchema >

</mcws:DescribeSchemaResponse >

3.3.1.4 Opération GetMembers

Les membres d’un cube sont obtenus par l’opération GetMembers. Les opérateursde sélection de membres, tels que décrits dans la section 2.3.3.1 du chapitre précédent, ysont mis en œuvre afin de permettre au client de paramétrer la sélection des membres,et appliquer des transformations (e.g. simplification géométrique) aux membres et àleurs attributs.

Nous décomposons l’exemple de requête qui suit en trois parties, afin de démontrerl’application de différents opérateurs de sélection de membres. En premier lieu, voici leséléments d’en-tête ainsi que la sélection des membres de la dimension des mesures :

Listage 3.8 – Exemple d’élément de requête GetMembersRequest, partie 1<GetMembersRequest xmlns="http: // geosoa.scg.ulaval.ca/MinicubeWS">

<cubeSelection name="Recensements">

<dimensionSelection name="Measures">

<memberSelection >



<selectAllMembers />

</memberSelection >

</dimensionSelection >

Premièrement, l’élément <cubeSelection> indique qu’on veut obtenir les membresdu cube « Recensements ». Ensuite, un élément <dimensionSelection> spécifie la dimen-sion « Measures ». Finalement, l’élément <memberSelection> avec le prédicat <selec-

tAllMembers> indique qu’on veut récupérer tous les membres représentant les mesuresdu cube.


La partie suivante est comme suit :

Listage 3.9 – Exemple d’élément de requête GetMembersRequest, partie 2<dimensionSelection name="Age">





<levelSelection name="Groupe" include="children" />

<memberSelection >

<memberSelectors >

<selectMembersByName >

<member name="Adolescents 12-17" />

<member name="Jeunes adultes 18-24" />

</selectMembersByName >

</memberSelectors >

</memberSelection >


Cette sélection se fait sur la dimension « Age ». L’élément <levelSelection> spécifie leniveau pour lequel on effectue la requête, soit ici « Groupe ». On indique également qu’onsouhaite récupérer tous les descendants des membres sélectionnés (soit les descendantsde « Adolescents 12-17 » et « Jeunes adultes 18-24 »), grâce à la valeur « children »donnée à l’attribut include.

La dernière partie montre un autre opérateur de sélection de membres :

Listage 3.10 – Exemple d’élément de requête GetMembersRequest, partie 3<dimensionSelection name="Unite geographique">



<levelSelection name="Division de recensement"

include="levelonly" />

<memberSelection >

<memberSelectors >



<selectMembersByProperty

property="Geom Division de recensement">

<GMLPropertySelector GMLPropertyName ="the_geom">

<ogc:Filter xmlns:ogc="http: //www.opengis.net/ogc">

<ogc:BBOX >

<ogc:PropertyName >

the_geom

</ogc:PropertyName >

<gml:Box xmlns:gml="http: //www.opengis.net/gml">

<gml:coordinates >

-71.0 ,45.0 -70.0 ,46.0

</gml:coordinates >

</gml:Box >

</ogc:BBOX >

</ogc:Filter >

</GMLPropertySelector >

</selectMembersByProperty >

</memberSelectors >




<memberFilters >

<propertyMemberFilter

property="Geom Division de recensement">

<douglasPeuckerPropertyFilter tolerance="0.01" />

</propertyMemberFilter >

</memberFilters >

</memberSelection >


</cubeSelection >

</GetMembersRequest >

Cet extrait, plus complexe que les autres, concerne la dimension « Unité géogra-phique ». La sélection des membres se fait au niveau « Division de recensement » uni-quement. On effectue dans ce cas une sélection par analyse spatiale, sur la propriété« Geom Division de recensement » contenant la géométrie surfacique des divisions derecensements. L’élément <GMLPropertySelector> encapsule un prédicat topologiqueencodé selon la spécification OpenGIS Filter Encoding de l’OGC [OGC, 2005a]. Dansce cas, on utilise le prédicat <BBOX> avec un rectangle englobant décrit en GML(élément <Box>) allant de 71◦W à 70◦W en longitude et de 45◦N à 46◦N en latitude.Cela a pour effet de sélectionner tous les membres dont la propriété spatiale « GeomDivision de recensement » comporte une géométrie qui fait intersection avec le rectangleenglobant. Outre l’opérateur BBOX, la sélection par analyse spatiale supporte tous lesprédicats topologiques énoncés dans la norme OpenGIS Filter Encoding : Equals, Dis-

joint, Touches, Within, Overlaps, Crosses, Intersects, Contains ainsi que les opérateursmétriques DWithin et Beyond.

L’extrait précédent montre également l’application d’un filtre de simplification géo-métrique sur la propriété « Geom Division de recensement ». L’élément <propertyMem-

berFilter> indique qu’on veut appliquer un traitement (filtre) sur la propriété « GeomDivision de recensement ». L’élément <douglasPeuckerPropertyFilter>, quant à lui, spé-cifie le traitement à appliquer, soit l’algorithme de simplification de Douglas-Peuckerpour les polylignes. L’attribut tolerance indique la valeur du seuil5 pour l’algorithme, enunités du système de référence spatiale de la propriété géométrique (degrés décimauxdans ce cas, puisque les données sont dans le système de référence spatiale WGS84). Lefiltre est appliqué à tous les membres sélectionnés par les opérateurs spécifiés sous l’élé-ment <memberSelectors>. Le filtre ne s’applique qu’aux membres retournés au client ;les données d’origine du cube ne sont jamais modifiées. Bien que la version actuelledu contrat de service WSDL (cf. A.2.2 en annexe A) ne propose que l’algorithme desimplification de Douglas-Peucker comme filtre de membres, il serait possible d’ajouterd’autres traitements, s’appliquant autant aux données spatiales que descriptives.

5Ce seuil correspond à la distance maximale entre un point de la polyligne d’origine et le segmentapproximant cette polyligne ; au delà de ce seuil, la polyligne d’approximation est resegmentée. Voir :http://www.codeproject.com/KB/recipes/dphull.aspx .

http://www.codeproject.com/KB/recipes/dphull.aspx


La réponse à la requête GetMembers précédente prend la forme d’un élément <Get-

MembersResponse> encapsulant un document CubeMembers, tel que décrit dans l’ar-ticle et illustré ci-après (listage 3.11).

Listage 3.11 – Exemple d’élément de réponse GetMembersResponse

<mcws:GetMembersResponse xmlns:mcws="http: // geosoa.scg.ulaval.ca/MinicubeWS">

<gcml:cubeMembers xmlns:gcml="http: // geosoa.scg.ulaval.ca/GeoCubeML"

xmlns:xs="http: //www.w3.org /2001/ XMLSchema">

<gcml:cubeRef name="Recensements">

<gcml:dimensionRef name="Measures">

<gcml:levelRef name="MeasuresLevel ">

<gcml:member name="Décès" />

<gcml:member name="Population" />

<gcml:member name="Naissances" />

</gcml:levelRef >

</gcml:dimensionRef >

<gcml:dimensionRef name="Age">

<gcml:levelRef name="Groupe">

<gcml:member name="Jeunes adultes 18-24">

<gcml:rollupTo member="Jeunes <25" />

<gcml:propertyValue property="Code Groupe">403</gcml:propertyValue >

</gcml:member >




<gcml:dimensionRef name="Unite geographique">

<gcml:levelRef name="Division de recensement">

<gcml:member name="Le Granit">

<gcml:rollupTo member="Estrie" />

<gcml:propertyValue property="Code Division de recensement">

2430

</gcml:propertyValue >

<gcml:propertyValue property="Geom Division de recensement">

<gml:MultiPolygon xmlns:gml="http: //www.opengis.net/gml">


<gml:Polygon >


<gml:LinearRing >

<gml:coordinates >

-71.10743 ,45.946148 -70.968956 ,45.901024

-70.950653 ,45.915943 -70.896805 ,45.890858

-70.89296 ,45.77998 -70.663681 ,45.781849



-71.129883 ,45.957413 -71.10743 ,45.946148

</gml:coordinates >

</gml:LinearRing >


</gml:Polygon >




</gcml:member >





</gcml:cubeRef >

</gcml:cubeMembers >

</mcws:GetMembersResponse >

On peut voir dans cette réponse quelques uns des membres sélectionnés, en fonctionde la requête précédente. Pour ne pas surcharger cette section, les parties répétitivesde la réponse ont été omises aux endroits indiqués par les commentaires « < !– ... –> »,lorsque cela n’empêchait pas la compréhension de l’ensemble.

3.3.1.5 Opération GetCells

L’opération GetCells permet d’obtenir les cellules (ou faits) du cube, en fonction desopérateurs de sélection de cellules décrits dans la section 2.3.3.2 du chapitre précédent.Ainsi, un sous-ensemble du cube peut être sélectionné et récupéré, afin de constituer unmini-cube de données SOLAP destiné à être consulté en mode déconnecté sur le clientmobile.

Une requête typique prend la forme suivante :

Listage 3.12 – Exemple d’élément de requête GetCellsRequest<GetCellsRequest xmlns="http: // geosoa.scg.ulaval.ca/ MinicubeWS">


<descendantsMemberSelection dimensionName ="Unite geographique">

<memberRef level="Province" member="Québec" />

</descendantsMemberSelection >

<aggregateMemberSelection dimensionName ="Age">

<memberRef level="Groupe" member="Bébés <2" />

<memberRef level="Groupe" member="Enfants 2-11" />

<memberRef level="Groupe" member="Adolescents 12-17" />

</aggregateMemberSelection >

<slicerMemberSelection dimensionName ="Temps">

<memberRef level="Annee" member="2001" />

</slicerMemberSelection >

<slicerMemberSelection dimensionName ="Measures">

<memberRef member="Population" />


</cubeSelection >

</GetCellsRequest >

L’exemple montre l’application de quatre opérateurs de sélection de cellules, enreprenant les exemples présentés dans la section 2.3.3.2 du chapitre précédent :

– L’élément <descendantsMemberSelection> applique l’opérateur Inclusion de

membres et de leurs descendants sur le membre « Québec » du niveau « Pro-vince » de la dimension « Unite geographique ». Cela a pour effet d’inclure les


cellules correspondant aux membres du niveau feuille (soit « Division de recense-ment ») ayant comme ancêtre le membre « Québec ». Les cellules comprises dansle message de réponse concerneront donc toutes les divisions de recensement duQuébec.

– L’élément <aggregateMemberSelection> applique l’opérateur Agrégation sur un

ou plusieurs membres. Les trois membres énoncés dans l’exemple du chapitreprécédent, pour le niveau « Groupe » de la dimension « Age », sont spécifiés.Les cellules du message de réponse correspondront donc à la valeur agrégée pourchacun des trois membres choisis.

– Le premier élément <slicerMemberSelection> correspond à l’opérateur Réduction

de dimension. Dans ce cas, on exclut la dimension « Temps » des thèmes d’analysedu mini-cube, en effectuant une « tranche » (slice) sur le membre « 2001 ». Lescellules du message de réponse concerneront donc uniquement l’année 2001.

– Le deuxième élément <slicerMemberSelection> sert à sélectionner la mesure « Po-pulation ». Tel qu’expliqué dans la section 2.3.3.2 du chapitre précédent, on peututiliser cet opérateur lorsqu’on souhaite ne retenir qu’une seule mesure pour l’ob-tention des cellules du mini-cube.

Donc, l’ensemble de cellules retournées dans la réponse à cette requête concernerontla population de chaque division de recensement du Québec, pour les groupes d’âge« Bébés <2 », « Enfants 2-11 » et « Adolescents 12-17 », et pour l’année 2001. Voici unextrait du message de réponse :

Listage 3.13 – Exemple d’élément de réponse GetCellsResponse<mcws:GetCellsResponse

xmlns:mcws="http: // geosoa.scg.ulaval.ca/MinicubeWS">

<gcml:cubeCells

xmlns:gcml="http: // geosoa.scg.ulaval.ca/GeoCubeML"




<gcml:slicerMembers >

<gcml:tuple >

<gcml:memberRef dimension="Measures"

hierarchy="Measures" level="MeasuresLevel " member="Population" />

<gcml:memberRef dimension="Temps"

hierarchy="Temps" level="Annee" member="2001" />

</gcml:tuple >

</gcml:slicerMembers >

<gcml:cells >

<gcml:cell >

<gcml:tuple >

<gcml:memberRef dimension="Age"

hierarchy="Age" level="Groupe" member="Bébés <2" />

<gcml:memberRef dimension="Sexe"

hierarchy="Sexe" level="(All)" member="All Sexes" />

<gcml:memberRef dimension="Statut de population"

hierarchy="Statut de population" level="(All)"

member="All Statut de populations" />

<gcml:memberRef


dimension="Unite geographique" hierarchy="Unite geographique"

level="Division de recensement" member="Abitibi" />

</gcml:tuple >

<gcml:cellValue >513</gcml:cellValue >

</gcml:cell >

<gcml:cell >

<gcml:tuple >

<gcml:memberRef dimension="Age"

hierarchy="Age" level="Groupe" member="Enfants 2-11" />

<gcml:memberRef dimension="Sexe"

hierarchy="Sexe" level="(All)" member="All Sexes" />




<gcml:memberRef dimension="Unite geographique"

hierarchy="Unite geographique"


</gcml:tuple >


</gcml:cell >



</gcml:cells >

</gcml:cubeRef >

</gcml:cubeCells >

</mcws:GetCellsResponse >

On peut voir (listage 3.13) que la réponse encapsule un document cubeCells, conte-nant les cellules correspondant à la sélection de la requête précédente (listage 3.12).Pour les dimensions exclues des thèmes d’analyse par l’opérateur Réduction de dimen-

sion (élément <slicerMemberSelection> dans la requête), l’élément <slicerMembers>

spécifie sur quels membres la « tranche » a été faite. De plus, on observe que les cellulesfont référence aux membres par défaut pour les dimensions qui n’ont pas fait l’objetd’un opérateur de sélection : dans ce cas, il s’agit du membre par défaut « tous » desdimensions « Sexe » et « Statut de population », représentant la valeur agrégée pourtous les membres. Notons également que seules les cellules au niveau le plus granulairede la sélection font partie de la réponse. Les cellules des valeurs agrégées ne sont pasincluses afin de réduire la quantité de données transmises sur le réseau ; le client peutau besoin recalculer ces valeurs en fonction des opérateurs agrégatifs des mesures, soità la volée (grâce aux fonctionnalités d’un moteur OLAP) ou bien en précalcul pour lesstocker afin d’accélérer certaines requêtes (e.g. via l’utilisation de vues matérialisées). Ilserait aussi possible d’étendre le contrat de service et la fonctionnalité du service Webafin de permettre la diffusion d’un sous-ensemble des cellules agrégées, à la demandedu client, afin d’éviter d’avoir à faire une partie des calculs à la volée ; cela n’a toutefoispas été implémenté dans le prototype actuel, faute de temps.


3.3.1.6 Opération GetCube

L’opération GetCube offre une manière d’obtenir en une seule phase les cellules ducube, les membres référencés par ces cellules ainsi que le schéma du cube. La réponseà une requête GetCube regroupe dans un seul document les éléments <cubeSchema>,<cubeMembers> et <cubeCells>. Ainsi, le client peut récupérer en un seul appel toutesles données constituant un mini-cube complet.

La syntaxe de requête est identique à l’opération GetCells. En fait, un élément<GetCellsRequest> est encapsulé dans l’élément <GetCubeRequest>, spécifiant quelsous-ensemble du cube on souhaite récupérer :

Listage 3.14 – Exemple d’élément de requête GetCubeRequest<GetCubeRequest xmlns="http: // geosoa.scg.ulaval.ca/MinicubeWS"

xmlns:xsi="http: //www.w3.org /2001/ XMLSchema -instance">

<GetCellsRequest >







</cubeSelection >

</GetCellsRequest >

</GetCubeRequest >

La réponse prend la forme suivante :

Listage 3.15 – Exemple d’élément de réponse GetCubeResponse<mcws:GetCubeResponse

xmlns:mcws="http: // geosoa.scg.ulaval.ca/MinicubeWS"

xmlns:gcml="http: // geosoa.scg.ulaval.ca/GeoCubeML">

<gcml:cubeSchema >







</gcml:dimension >



</gcml:cube >

</gcml:cubeSchema >

<gcml:cubeMembers >








</gcml:levelRef >




</gcml:cubeRef >


<gcml:cubeCells >




</gcml:cubeRef >

</gcml:cubeCells >

</mcws:GetCubeResponse >

Cette réponse encapsule les trois éléments constituant les données et métadonnéescomplètes d’un mini-cube. L’élément <cubeSchema> contient le schéma du cube surlequel la requête GetCube porte, soit dans cet exemple celui de « Recensements ». En-suite, l’élément <cubeMembers> regroupe tous les membres référencés par l’ensembledes cellules composant le mini-cube. Une particularité s’ajoute ici : en plus des membresauxquels les cellules au niveau le plus granulaire réfèrent, on retrouve également cer-tains membres des niveaux supérieurs. Les règles dictant quels membres sont inclusvont comme suit :

– Pour les dimensions sur lesquelles l’opérateur aggregateMemberSelection (agré-gation sur un ou plusieurs membres) a été appliqué, seulement les membres auniveau concerné et qui sont référencés par les cellules sont inclus, puisqu’il n’estpas garanti que les membres des niveaux supérieurs soient complets (i.e. certainsde leurs descendants peuvent être absents du mini-cube). En ce qui concerneles niveaux inférieurs de ces dimensions, aucun membre n’est inclus puisque cesniveaux ne font pas partie du mini-cube.

– Pour les dimensions sur lesquelles l’opérateur descendantsMemberSelection (inclu-sion de membres et de leurs descendants) a été appliqué, sont inclus les membresdu niveau concerné et qui sont référencés par les cellules, ainsi que tous leursancêtres jusqu’au niveau sur lequel la sélection des membres a été appliquée.Puisque la sélection d’un membre avec cet opérateur implique l’inclusion de tousses descendants, il est garanti que ce membre soit complet ; ainsi on peut mettreà disposition, pour les besoins d’analyse du client mobile, toute la hiérarchie desmembres allant du membre sélectionné jusqu’aux membres feuilles.

– Pour les dimensions sur lesquelles l’opérateur slicerMemberSelection (réduction dedimension) est appliqué, le membre sur lequel la « tranche » du cube est faite est


inclus. Bien que la dimension soit exclue des thèmes d’analyse, on peut souhaitermettre ce membre à disposition, à titre informatif, afin que l’utilisateur puisseconnaître ce sur quoi les données portent.

– Pour les dimensions sur lesquelles aucun opérateur de sélection de cellules n’estappliqué, le membre par défaut est inclus.

Finalement, l’élément <cubeCells> contient l’ensemble des cellules constituant lemini-cube demandé par la requête, de manière identique à ce qui est retourné parl’opération GetCells.

3.3.2 Considérations par rapport aux contraintes de mobilité

Le format d’encodage XML des cubes de données SOLAP ainsi que le contrat deservice présentés sont suffisamment versatiles et génériques pour être adaptés aux dif-férents environnements informatiques existants, que ce soit en contexte sédentaire oumobile. Ils offrent la fonctionnalité requise pour sélectionner un sous-ensemble d’uncube, afin de constituer un mini-cube, ce qui permet de transmettre au client mobileun volume de données plus restreint et adapté à l’utilisation lorsque déconnecté duréseau, tout en tenant compte des limites en capacité de stockage et de traitement deces appareils.

Cependant, certains aspects de cette solution pourraient s’avérer problématiquesface aux contraintes rencontrées dans les environnements mobiles. Cette section identifieces points en question, tout en apportant des pistes de solution pour y remédier.

3.3.2.1 Format de données spatiales

Les exemples donnés dans l’article en ce qui concerne les géométries des membresspatiaux s’appuient sur l’encodage GML (Geography Markup Language) de l’OGC.Pour les besoins des applications mobiles, certains encodages alternatifs pourraientégalement être offerts. Un des formats XML les plus populaires pour l’encodage desobjets géométriques vectoriels est la norme SVG (Scalable Vector Graphics) du W3C[SVG Working Group, 2003]. Il existe même des profils plus restreints de SVG, mieuxadaptés aux contraintes des appareils mobiles : il s’agit de SVG Tiny et SVG Basic6.

6Voir http://www.w3.org/TR/SVGMobile/

http://www.w3.org/TR/SVGMobile/


Plusieurs librairies de rendu graphique7 permettent d’incorporer facilement des gra-phiques SVG dans les applications. Une application SOLAP mobile pourrait s’appuyersur cette technologie, afin d’offrir un affichage de haute qualité pour les cartes, sans avoirà incorporer un parseur GML, et réduisant ainsi la complexité du client. Le service Webpourrait offrir un tel format en alternative, si le client le demande lors d’une requêteGetMembers. La transformation de la géométrie des membres spatiaux vers l’encodageSVG peut même s’effectuer à la volée, par exemple en utilisant une transformationXSLT (eXtensible Stylesheet Language Transformation [Clark, 1999]) pour convertir leséléments GML en éléments SVG8.

3.3.2.2 Verbosité de l’encodage XML

Les données encodées en XML le sont sous forme de texte. Bien que cela favorise lalisibilité (les données se décrivent par elles-mêmes, ce qui facilite la compréhension duformat par les développeurs) et l’interopérabilité (ces formats peuvent être gérés parplusieurs plateformes logicielles et matérielles hétérogènes, contrairement à la plupartdes formats binaires propriétaires), la taille des données qui doit être transmise s’entrouve augmentée. De plus, la sérialisation (objets en mémoire vers document XML)et la désérialisation (document XML vers objets en mémoire) des données impliquentun surcoût non négligeable en temps de processeur. Dans un contexte de mobilité,lorsqu’on se trouve confronté aux contraintes en bande passante des réseaux sans-fil etaux contraintes en puissance de calcul des appareils, ces particularités de XML peuventcontribuer à dégrader significativement la performance des applications.

Différentes stratégies peuvent être mises en œuvre pour palier à ce problème :

Encodage abrégé : dans le format XML et le contrat de service WSDL proposés, lesnoms des éléments et attributs sont épelés en entier. On pourrait créer une no-menclature abrégée pour ces noms, par exemple en remplaçant un nom d’élémenttel que <descendantsMemberSelection> par <desMemSel>. La diminution de lataille des balises permet donc de réduire la taille totale des documents. Toute-fois, un léger inconvénient de cette approche est de compromettre la lisibilité desdocuments.

Compression des données : sur le Web, la compression des données est fréquemmentemployée afin de réduire la quantité de données à transmettre sur le réseau et ainsi

7Par exemple Apache Batik, une librairie open source pour Java : http://xmlgraphics.apache.

org/batik/8De telles feuilles de style existent déjà, entre autres pour permettre la représentation de cartes par

un serveur WMS, depuis des données GML issues d’un serveur WFS.

http://xmlgraphics.apache.org/batik/

http://xmlgraphics.apache.org/batik/


diminuer le temps d’attente. Cela peut même se faire à la volée : la plupart desserveurs Web (e.g. Apache HTTP Server) et fureteurs peuvent dynamiquementcompresser et décompresser les pages HTML avec l’algorithme gzip. La mêmetechnique peut être appliquée aux services Web, pour compresser les messageséchangés entre clients et serveurs. Généralement, les documents XML se prêtentbien à ce type de compression, puisqu’ils sont textuels et que leur contenu estassez répétitif (les mêmes balises reviennent souvent). Cependant, il existe unsurcoût en temps de traitement : non seulement le serveur doit-il compresserles données, mais le client mobile doit également les décompresser, ce qui peuts’avérer problématique avec un processeur moins rapide. En fait, lorsque la bandepassante est plus limitée, il devient plus avantageux d’utiliser cette approche :le temps gagné lors de la transmission des données dépasse celui nécessaire à lacompression et la décompression. Il s’agit de déterminer à partir de quelle vitessede transmission cette stratégie est viable. Certains travaux de recherche portentd’ailleurs sur cet aspect [Tian et al., 2004].

Encodages XML binaires : il existe maintenant des formats d’encodage binairespour les données XML ; les deux plus connus sont les spécifications Efficient XML

Interchange (EXI) du W3C [Schneider et Kamiya, 2008] et Fast Infoset (définipar l’ITU-T et l’ISO) [ITU-T, 2005]. Au lieu de représenter les données XMLsous forme de texte, ces encodages utilisent des structures de données binaires,plus compactes et nécessitant moins de temps processeur lors de la sérialisation etde la désérialisation. Malgré le fait qu’il ne s’agisse pas de formats textes pouvantêtre lus et édités manuellement, ces encodages permettent de reproduire l’intégra-lité du modèle de données d’XML (soit le XML Information Set [Cowan et Tobin,2004]), et sont ainsi parfaitement équivalents aux fichiers XML textuels. Tout do-cument XML valide peut être converti depuis et vers un de ces formats d’encodagebinaire, de manière transparente.

Contrairement à un simple algorithme de compression (tel que gzip), ces encodagesont deux avantages : Premièrement, l’intermédiaire texte peut être éliminé de laboucle, puisque les parseurs XML conformes à ces spécifications peuvent produireet consommer directement les documents encodés. Par le fait même, le surcoûtimposé par le parsing de documents textuels est éliminé. De plus, les documentsencodés sont de taille encore plus réduite, puisque les encodages XML binaires sontconçus spécifiquement et exclusivement pour les structures de données XML, alorsque les algorithmes de compression sans perte (e.g. gzip) s’appliquent à tout typede données. On peut même après coup appliquer un algorithme de compressionaux documents XML binaires pour réduire davantage leur taille.

Puisque les formats XML binaires sont équivalents au XML textuel en termesde données représentées, les mêmes standards concernant XML et les servicesWeb (e.g. XML Schema, WSDL, SOAP) et concernant les outils technologiques


(parseurs et autres) s’appliquent lors de leur utilisation. Les interfaces de pro-grammation de ces outils (e.g. API de parsing SAX et DOM) restent les mêmes.La seule différence intervient dans les données qui sont échangées sur le réseau,entre le client et le serveur. À cette fin, le cadre de développement logiciel utilisépour l’implémentation du service Web doit supporter la sérialisation et la déséria-lisation pour un encodage binaire. Cet encodage est optionnel ; si le client et leserveur le supportent tous les deux, il peut être utilisé pour accélérer l’échange dedonnées. Sinon, le service Web retombe par défaut à la transmission de messagesXML textuels pour préserver la compatibilité et l’interopérabilité avec tous lesclients. Cependant, à l’heure actuelle, il n’y a pas de standard de facto définitif ence qui concerne les encodages XML binaires. Les deux spécifications les plus envogue sont EXI et Fast Infoset, mais il en existe une panoplie d’autres. De plus,peu d’outils de développement supportent ces encodages actuellement, limitantdavantage leur adoption. Néanmoins, le cadre de développement open source deservices Web Apache Axis2 9 et certains outils XML Java de Sun Microsystems10

supportent maintenant l’encodage Fast Infoset.

3.3.2.3 Utilisation des données XML par le client

Une fois que le mini-cube SOLAP en format XML est récupéré par le client mobile,une dernière étape doit être accomplie avant qu’il soit prêt à être consulté par l’utili-sateur. Il s’agit de transformer les données XML (schéma, membres et cellules) en unestructure OLAP, qu’il s’agisse de ROLAP (s’appuyant sur un stockage relationnel) oude MOLAP (avec des structures de données multidimensionnelles propriétaires). Il fautcomprendre qu’un encodage XML, tel que mis en œuvre dans les services Web, est des-tiné à l’échange de données d’une manière interopérable, indépendante des technologiessous-jacentes (SIG, SGBD, moteur OLAP, etc.) Cela permet à plusieurs fournisseurs dif-férents (producteurs de logiciels et intégrateurs de systèmes) de développer des solutionslogicielles qui peuvent communiquer l’une avec l’autre de manière transparente. Cepen-dant, une structure de données XML est en format texte, n’est pas indexée et donc n’estpas propice aux requêtes de type analytique demandant un temps de réponse rapide.Bien qu’il existe des langages d’interrogation des données XML (e.g. XPath), ceux-ciservent essentiellement à sélectionner des éléments dans l’arborescence d’un documentXML, et n’offrent ni la performance, ni les fonctionnalités (i.e. jointures, opérateursagrégatifs de type « GROUP BY ») nécessaires pour la réalisation d’un moteur OLAP.Donc, une conversion de XML vers une structure de données ROLAP ou MOLAP doit

9Source : http://wso2.org/library/268610Sources : http://java.sun.com/developer/technicalArticles/xml/fastinfoset/ et

https://fi.dev.java.net/how-to-use.html

http://wso2.org/library/2686

http://java.sun.com/developer/technicalArticles/xml/fastinfoset/

https://fi.dev.java.net/how-to-use.html


Fig. 3.2 – Conversion XML vers OLAP sur l’appareil mobile

être effectuée du côté client pour que le mini-cube soit prêt à être consulté.

Puisque le projet de recherche en cours ne comprend pas la conception et le déve-loppement d’un client SOLAP mobile (voir les objectifs de recherche en 1.4.1), cettefonctionnalité n’a pas encore été réalisée. Plusieurs travaux restent à accomplir, afind’identifier et d’évaluer quels produits et technologies OLAP et SOLAP pourraient êtreadaptables à un appareil mobile de type PDA ou smartphone. Nous n’avons donc pasencore de cible spécifique pour la conversion XML vers OLAP. Il est tout de mêmepossible de suggérer deux stratégies pour la réalisation de cette conversion :

Conversion XML vers OLAP sur l’appareil mobile : dans ce scénario, le clientsur l’appareil mobile invoque directement le service Web (e.g. par l’entremise d’unréseau sans-fil) avec une requête de constitution de mini-cube et reçoit en réponseles données en format XML (i.e. les éléments cubeSchema, cubeMembers et cu-

beCells). Le client fait alors la désérialisation de ces structures XML afin de lesdécoder, et les convertit dans le format de stockage (ROLAP ou MOLAP) appro-prié pour le moteur OLAP de l’application mobile (voir figure 3.2). Cependant,on peut supposer que cette conversion nécessitera un certain temps de traitement,et en considérant les contraintes en puissance de calcul des appareils mobiles, celapourrait imposer un certain délai d’attente avant que le mini-cube soit prêt à êtreconsulté (après quoi sa consultation subséquente serait rapide). Dans certaines si-tuations (e.g. interventions en situation d’urgence), un tel délai pourrait s’avérerinacceptable, alors que dans d’autres situations cela ne poserait pas problème.

Adaptateur de conversion XML vers OLAP : cette stratégie consiste à intercalerun logiciel adaptateur entre le client mobile et le service de constitution de mini-cubes. Cet adaptateur s’exécuterait sur un serveur comportant une puissance decalcul significativement supérieure à celle des appareils mobiles, et serait respon-sable de la conversion entre les structures de données XML et OLAP. De cette


manière, ce traitement est délégué à un ordinateur puissant plutôt qu’à l’appa-reil mobile, permettant ainsi un gain de temps. L’adaptateur livre au client unmini-cube dans un format binaire spécifique à la base de données embarquée (qu’ils’agisse d’une technologie ROLAP ou MOLAP) utilisée par le moteur OLAP surlequel s’appuie l’application cliente.

Dans ce cas, il est justifiable de se demander quel est l’intérêt d’utiliser tout demême un format de données XML en intermédiaire. Ne serait-il pas plus simpleet efficace de concevoir le service Web de constitution de mini-cubes pour qu’ilproduise directement le mini-cube dans le format de stockage approprié pour lemoteur OLAP11 de l’application mobile ? La réponse à cette question se situedans la notion d’interopérabilité technique. Les services Web s’appuient sur unéchange XML des données afin qu’ils soient utilisables par tout un éventail declients potentiels, et non seulement le système d’un seul vendeur de logiciel. Danscette solution, l’adaptateur ne contrevient pas à l’interopérabilité de la solution,puisque le service Web est toujours présent pour obtenir les données du cube enformat XML. Le seul rôle de l’adaptateur est de déléguer à un ordinateur puissantla reconstruction du cube en structure binaire, plutôt que d’effectuer cette tâchesur un appareil mobile dont la puissance de calcul est limitée.

Prenons l’exemple suivant, illustré par la figure 3.3 : un vendeur A développeun client SOLAP mobile pour PDA, s’appuyant sur une technologie ROLAP etfonctionnant sur la plateforme Microsoft Windows Mobile. Un autre vendeur B,quant à lui, développe une application de tableaux de bord, comportant des fonc-tionnalités SOLAP, pour les téléphones mobiles. Celle-ci s’appuie sur un moteurMOLAP embarqué, et fonctionne sur la plateforme Java Mobile Edition. À priori,les technologies des deux vendeurs sont incompatibles et nécessitent des formatsde données différents. Supposons maintenant qu’une organisation voudrait dé-ployer des applications SOLAP sur une flotte d’appareils comprenant des PDAet des téléphones mobiles, en faisant appel aux technologies des vendeurs A et B.Les données décisionnelles pour les deux types de clients proviennent de la mêmesource, soit l’entrepôt de données de l’organisation. En mettant en œuvre deuxadaptateurs de conversion XML vers OLAP distincts, soit un pour la technolo-gie du vendeur A et un autre pour la technologie du vendeur B, le système peuts’appuyer sur un seul et même service Web de constitution de mini-cubes, fonc-tionnant de manière indépendante de la technologie spécifique des clients mobiles.Les utilisateurs mobiles sont donc en mesure d’exploiter les données provenant des

11Il faut également savoir que les clients mobiles ne sont pas susceptibles d’utiliser les moteurs OLAPqu’on retrouve dans les environnements serveurs ; les exigences de ceux-ci en termes de configurationmatérielle (taille de mémoire vive et de disque dur, puissance de processeur) et logicielle (systèmed’exploitation) sont complètement différentes de ce qu’on retrouve dans les environnements mobiles.Il n’est donc pas approprié de transmettre aux clients mobiles le contenu des cubes dans une structurepropre à un serveur OLAP ou à un entrepôt de données ; un changement de structure est nécessaire.



Client SOLAPmobile pour PDA

(Vendeur A)

Requête

Requête

Requête

Adaptateur de conversionXML vers OLAP

(Vendeur B)

Requête

Adaptateur de conversionXML vers OLAP

(Vendeur A)

Client SOLAP mobilepour smartphone

(Vendeur B)

BD embarquéeMOLAP

BD embarquéeROLAP





Fig. 3.3 – Mise en œuvre d’adaptateurs de conversion XML vers OLAP

mêmes cubes à la source, évitant ainsi un dédoublement de l’infrastructure infor-matique pour supporter les deux types de clients. Le service Web de constitutionde mini-cubes, conforme aux normes existantes et s’appuyant sur des échangesde messages XML, constitue ainsi le point de convergence de l’infrastructure dediffusion des données aux mobiles.

3.4 Conclusion

Dans ce chapitre, nous avons défini le format d’encodage XML permettant de repré-senter les mini-cubes de données SOLAP de manière interopérable (cf. parties 3.2.2 et3.2.3 de l’article), de manière à les transmettre par l’intermédiaire d’un service Web. Ladescription formelle du contrat de service, sous forme de document WSDL, a égalementété donnée (cf. 3.3.1), accompagnée d’exemples de requêtes et de réponses pour cha-cune des opérations. Des explications ont aussi été amenées, quant au choix du formatde représentation des données spatiales (cf. 3.3.2.1) et au volume des données XMLà transmettre (cf. 3.3.2.2). Finalement, la question du décodage et de l’utilisation desdonnées XML par le client mobile a été apportée en perspective (cf. 3.3.2.3).

Le chapitre suivant portera sur la réalisation du prototype de service Web de consti-tution de mini-cubes, s’appuyant sur les concepts décrits dans le présent chapitre.

Chapitre 4

Réalisation d’un prototype

Afin de mettre en œuvre les fonctionnalités décrites dans les deux chapitres précé-dents, un prototype de service Web a été développé. Ce dernier implémente les opéra-teurs de constitution de mini-cubes (cf. chapitre 2) conformément au contrat de serviceprécédemment décrit (cf. chapitre 3), en s’appuyant sur des librairies et composanteslogicielles existantes. Il s’agit également d’un prototype évolutif, dont la qualité est suf-fisante pour qu’il soit adapté aux futurs travaux de recherche qui vont s’appuyer surl’architecture et les services définis ici, dans le cadre du groupe de recherche GeoSOA(dirigé par le professeur Thierry Badard).

Ce chapitre décrit les choix technologiques qui ont été faits dans le cadre du dé-veloppement du prototype (cf. 4.1), soit quels outils logiciels et quelles données furentutilisées pour développer et tester le service Web. Les différents éléments composantl’architecture générale du système sont aussi explicités (cf. 4.2.1), avec une emphaseparticulière sur l’architecture détaillée de la composante centrale qui fut développée(cf. 4.2.2), soit le service Web de constitution de mini-cubes SOLAP en tant que tel.Des tests de performance du service sont réalisés et interprétés (cf. 4.3). Finalement,les limites du prototype actuel sont énoncées (cf. 4.4).

4.1 Choix technologiques

Le service Web de constitution de mini-cubes s’insère en tant qu’application dans uneinfrastructure technologique d’entrepôt de données spatiales décisionnelles existante, aumême titre que les applications actuelles (e.g. client SOLAP de bureau). Ainsi, pour

Chapitre 4. Réalisation d’un prototype 121

constituer un environnement dans lequel le service peut fonctionner, nous faisons appelà certaines composantes typiques d’une telle infrastructure. Il s’agit des outils ETL, dusystème de gestion de base de données (SGBD) relationnel et du serveur OLAP. Outreces composantes, nous avons fait appel à diverses librairies et cadres de développementpour la gestion des données spatiales, pour la constitution des documents XML et pourle déploiement sous forme de service Web.

La sélection de ces technologies a été faite en fonction de certains critères. Toutd’abord, nous avons favorisé les outils open source, pour leur flexibilité et la possibilitéde les modifier et de les adapter en fonction de nos besoins. Puisque le code sourceest ouvert, il est possible d’ajouter de nouvelles fonctionnalités, par exemple le supportdes données spatiales. Ensuite, le choix du langage de programmation constitue uncritère important. Afin de simplifier le développement, un langage s’exécutant dans unenvironnement géré (avec gestion de la mémoire par ramasse-miettes) est préférable. Lesenvironnements Java et Microsoft .NET (langages C#, VB.NET) sont les principauxcandidats. Les outils logiciels employés dans la solution doivent également proposer uneinterface de programmation propre au langage utilisé.

Les sous-sections suivantes expliquent les choix technologiques et décrivent les cri-tères entrant en jeu.

4.1.1 Langage de programmation

Les deux langages qui ont été considérés pour le développement du prototype sontC# (environnement Microsoft .NET) et Java. Les deux offrent un environnement d’exé-cution virtuel, avec gestion automatique de la mémoire par ramasse-miettes (garbage

collector). Les librairies intégrées à ces environnements comportent un éventail d’outilspour l’accès aux bases de données, la manipulation de données XML et la réalisationde services Web.

Nous avons retenu le langage Java pour les raisons suivantes : premièrement, tel qu’ilsera expliqué dans les sous-sections suivantes, il existe un bon nombre de technologiesopen source conçues pour Java et permettant de gérer les données multidimensionnelleset spatiales. À l’heure actuelle, les seuls outils équivalents pour l’environnement Micro-soft .NET sont des produits commerciaux propriétaires, qui n’offrent pas la flexibilitévoulue (e.g. modifier le code pour ajouter des fonctionnalités) et dont les licences sontsouvent onéreuses. De plus, l’environnement Java est indépendant du matériel et dusystème d’exploitation : un logiciel développé en Java peut s’exécuter sans modificationsur diverses plateformes, soit Windows, Mac OS X, Linux et autres systèmes UNIX. Il


n’en est pas de même pour Microsoft .NET, qui est exclusif à la plateforme Windows1.La solution développée en Java est donc plus versatile et peut être intégrée facilementdans des environnements technologiques variés.

Notre développement s’est articulé autour des versions 5 et 6 de Java ; le codedéveloppé est compatible avec ces deux versions. Par contre, les versions antérieures(1.4 et moins) ne sont pas supportées, puisque certaines nouvelles caractéristiques deJava 5 furent exploitées (soit les generics et l’itération par boucle for sur des interfacesIterable).

4.1.2 Outil ETL

Dans les premières phases de ce projet de recherche, il a été envisagé d’utiliser unoutil ETL (Extract, Transform and Load) pour faire la constitution des mini-cubesde données SOLAP. Bien que cette approche ait été mise de côté pour faire place àun service de constitution de mini-cubes basé sur un moteur OLAP (cf. 2.3.4.3), desefforts de développement ont été consacrés à adapter Kettle (maintenant Pentaho DataIntegration2), un outil ETL open source conçu en Java, afin qu’il supporte les donnéesspatiales. Cet outil a été choisi après avoir évalué des solutions existantes telles que FMEde Safe Software et Microsoft Data Transformation Services. Bien que FME soit un outilETL spécialement conçu pour traiter les données spatiales vectorielles, il n’offre pas defonctionnalités adaptées aux entrepôts de données décisionnelles, soit le chargementet les mises à jour dans les schémas de données multidimensionnels (e.g. en étoile),pour les tables de faits et de dimensions. Microsoft Data Transformation Services estplus adapté aux entrepôts de données, mais il ne supporte pas les données spatiales etpuisqu’il s’agit d’un produit propriétaire fermé, il n’est pas possible de l’adapter pourajouter une telle fonctionnalité. Il est aussi fortement couplé à SQL Server, la solutionSGBD de Microsoft. D’autres ETL open source, soit Enhydra Octopus3 et Talend OpenStudio4 ont également été évalués. Nous n’avons pas retenu Octopus, car son offreen fonctionnalités de transformations était plutôt pauvre et son absence d’interfaceutilisateur le rendait difficile d’utilisation. Quant à Talend Open Studio, il offrait uneinterface utilisateur intéressante (basée sur l’environnement Eclipse RCP5). Cependant,

1Exception faite du projet Mono (http://www.mono-project.com), disponible sous Linux, quioffre maintenant un environnement d’exécution supportant une partie des fonctionnalités de Microsoft.NET.

2http://kettle.pentaho.org3http://www.enhydra.org/tech/octopus/index.html4http://www.talend.com5http://www.eclipse.org/rcp/

http://www.mono-project.com

http://kettle.pentaho.org

http://www.enhydra.org/tech/octopus/index.html

http://www.talend.com

http://www.eclipse.org/rcp/


au moment où nous avons évalué les outils ETL, son moteur de génération de code deprocédures ETL ne supportait que le langage Perl, rendant difficile l’intégration avec lesoutils Java pour les données spatiales. Depuis peu, Talend offre la possibilité de générerdu code Java ; d’ailleurs, la société Camptocamp6 a développé une version géospatialede cet outil open source, qui prend en charge les données spatiales7.

Les extensions spatiales ajoutées à Kettle sont basées sur GeOxygene8, un cadre dedéveloppement géomatique open source en Java. Un type de données Geometry a étéconçu, afin de traiter les géométries vectorielles d’une manière transparente et homogèneaux autres types de données primitifs (nombres entiers et réels, chaînes de caractères,date et heure, etc.). L’implémentation comporte également le support en entrée-sortiepour les bases de données PostGIS, la lecture de fichiers Shapefile, les prédicats to-pologiques (union, intersection, etc.) pour des fins de filtrage et jointures ainsi que lesupport en langage JavaScript pour l’appel de fonctions d’analyse spatiale9. Ce projetfut nommé GeoKettle, et a fait l’objet d’une présentation à la conférence FOSS4G 2007,portant sur les technologies géomatiques open source10. Bien que l’approche ETL aitété écartée en ce qui concerne la constitution des mini-cubes, GeoKettle a tout de mêmeservi lors de la préparation de l’entrepôt de données tests (voir partie 4.1.8). GeoKettlea aussi été utilisé dans la réalisation d’un travail de recherche mené au sein du groupeGeoSOA qui a conduit notamment au développement d’un prototype de service Webpour la mise à jour de cubes SOLAP [Declercq, 2008]. Pour plus d’informations surGeoKettle, se référer à la partie 5.2.2.1 de la conclusion (chapitre 5).

4.1.3 Moteur OLAP

Pour répondre aux besoins d’accès aux données SOLAP, le logiciel JMap SpatialOLAP, développé au Centre de recherche en géomatique (CRG) au sein de l’équipe duprofesseur Yvan Bédard et commercialisé par KHEOPS Technologies, a été considéré.Il s’agit d’une application client-serveur, conçue en Java et s’appuyant sur le moteur derendu cartographique JMap. Elle offre une interface visuelle assez simple d’utilisationpour la visualisation des cubes de données SOLAP, sous forme de tableaux croisés, degraphiques et de cartes thématiques. Cependant, JMap Spatial OLAP ne fonctionnepas avec un véritable moteur OLAP : les données sont stockées directement dans unschéma multidimensionnel (en étoile, en flocon ou en structure parent-enfant) dans un

6http://www.camptocamp.com7Spatial Data Integrator, http://www.spatialdataintegrator.com8http://oxygene-project.sourceforge.net/9Toutes les fonctions de GeOxygene sont ainsi accessibles en JavaScript.

10voir http://www.foss4g2007.org/presentations/view.php?abstract_id=192

http://www.camptocamp.com

http://www.spatialdataintegrator.com

http://oxygene-project.sourceforge.net/

http://www.foss4g2007.org/presentations/view.php?abstract_id=192


SGBD relationnel. Chaque cellule pouvant être affichée doit être pré-calculée et stockéedans le SGBD ; autrement dit, toutes les agrégations pour le croisement de tous lesmembres à tous les niveaux de toutes les dimensions doivent être stockées dans unetable de faits. Les interactions de l’utilisateur avec l’interface graphique sont traitéesafin d’interroger le SBGD avec des requêtes SQL. Il n’existe donc pas de langage derequête multidimensionnel (e.g. MDX) ni d’interface de programmation permettantl’interrogation des données du cube. Pour ces raisons, JMap Spatial OLAP n’a pas étéretenu comme composante centrale dans la réalisation du prototype de service.

Un autre serveur OLAP, Microsoft SQL Server Analysis Services, a été évalué. Ils’agit de la solution OLAP de Microsoft, supportant le langage MDX. C’est un desproduits OLAP les plus populaires du marché. Il n’a toutefois pas été retenu puisque lesupport pour les données spatiales vectorielles n’est pas intégré, et puisqu’il s’agit d’unlogiciel propriétaire, il serait difficile de le modifier pour ajouter cette fonctionnalité. Deplus, il ne propose pas d’interface de programmation en Java, ce qui peut rendre pluscomplexe son intégration avec cet environnement11.

Le choix de technologie OLAP s’est arrêté sur Mondrian12, un serveur OLAP open

source entièrement réalisé en Java. Il s’agit d’un moteur de type ROLAP, c’est-à-direqui s’appuie sur un SGBD relationnel pour le stockage des données du cube. Mondrianest compatible avec tout SGBD qui offre un pilote JDBC (Java Database Connectivity).Son langage de requête est le MDX, tout comme Microsoft SQL Server Analysis Ser-vices. Bien qu’à l’heure actuelle, sa facilité d’utilisation (pour la création de cubes etla configuration) et sa performance ne soient pas toujours au niveau des produits com-merciaux propriétaires, il s’agit tout de même d’un produit suffisamment performantet stable pour être utilisé dans un environnement de production. Il ne comporte pas desupport natif pour les données spatiales vectorielles, mais puisqu’il s’agit d’un logicielopen source, il a été possible d’y apporter quelques modifications afin d’ajouter un typede données pour les géométries vectorielles. Nous avons nommé GeoMondrian13 cetteversion modifiée de Mondrian, comprenant le support pour les types de données géomé-triques. Ainsi, lorsque utilisé de pair avec le SGBD PostgreSQL avec l’extension spatialePostGIS (voir sous-section suivante), il est possible d’intégrer la géométrie des membresspatiaux à même le cube de données, plutôt que de la stocker dans un fichier ou unebase de données séparée. La géométrie des membres spatiaux est représentée commeune propriété de membre, et l’application cliente peut l’obtenir dans le résultat d’unerequête MDX ou en récupérant les membres du cube avec l’API Java de Mondrian.

11Il serait toutefois possible d’utiliser à cette fin le service Web XML for Analysis (XMLA) pourexécuter les requêtes MDX, à partir de l’environnement Java. Cependant, aucun support pour lesdonnées spatiales n’existe actuellement dans XMLA.

12http://mondrian.pentaho.org13Voir partie 5.2.2.2 de la conclusion (chapitre 5) pour plus de détails.



Cette composante spatiale peut ensuite être exploitée de diverses manières : rendu car-tographique, analyse spatiale ou encore conversion en un autre format de données (e.g.GML).

4.1.4 Système de gestion de bases de données relationnel

Le système de gestion de bases de données relationnel (SGBDR) est le point centrald’un entrepôt de données décisionnelles14. Il sert principalement à stocker les donnéesde l’entrepôt, et à les récupérer grâce à un langage de requête tel que SQL. Les systèmesETL peuplent les tables de dimensions et de faits dans le SGBDR à partir des donnéesextraites des systèmes sources. Quant aux applications (e.g. OLAP, tableaux de bord,fouille de données), elles se connectent au SGBDR pour interroger et récupérer cesdonnées intégrées.

Dans le cas d’un entrepôt de données spatiales, le SGBDR doit supporter le stockageet l’interrogation des données spatiales, contenant une géométrie vectorielle. Plusieursproduits sur le marché offrent cette fonctionnalité ; parmi les plus connus, on retrouveOracle Spatial, ArcSDE et PostGIS. Oracle Spatial est la composante du SBGDR Oraclequi offre la gestion des données spatiales (vectorielles et raster). ArcSDE est le moduleSGBDR spatial de la compagnie ESRI, intégré à la suite ArcGIS ; il s’appuie sur unSGBDR tierce partie (IBM DB2, Informix, Oracle et Microsoft SQL Server sont sup-portés) pour le stockage des données. PostGIS15 est un module d’extension au SGBDRopen source PostgreSQL. Il est conforme à la norme Simple Features for SQL de l’OpenGeospatial Consortium (OGC).

Nous avons retenu PostgreSQL avec l’extension spatiale PostGIS puisqu’il s’agitd’une solution entièrement open source, hautement performante et répondant à tous nosbesoins pour le développement du prototype. PostGIS offre également une extension depilote JDBC (PostGIS JDBC Driver Wrapper) permettant un accès simplifié aux objetsgéométriques de la BD à partir des applications Java. Nous avons utilisé ce module enl’intégrant dans Mondrian pour avoir accès aux géométries des membres spatiaux.

14Il importe de préciser que bien qu’un SGBDR soit utilisé, les schémas de données mis en œuvredans les entrepôts ne sont généralement pas de type transactionnel ; on utilise plutôt des structuresdénormalisées, telles que les schémas en étoile. Voir Kimball et Ross [2002] pour plus de détails.

15http://postgis.refractions.net

http://postgis.refractions.net


4.1.5 Cadre de développement géomatique

Nous avons fait appel au cadre de développement géomatique GeOxygene pour lamanipulation des objets spatiaux dans le service Web, ainsi que pour les traitementsde simplification géométrique (algorithme de Douglas-Peucker). Certains autres outilsgéomatiques open source ont aussi été utilisés pour combler les fonctionnalités nonsupportées par GeOxygene : soit les librairies de JUMP16 pour la sérialisation desobjets spatiaux en GML, ainsi que GeoTools17 pour les filtres de sélection spatiale selonl’encodage OGC Filter Encoding.

4.1.6 Cadre de développement pour services Web

L’implémentation d’un service Web est grandement facilitée lorsqu’on dispose d’ou-tils logiciels s’occupant de la gestion des messages dans le protocole choisi (e.g. SOAP),des mappings XML-objets à partir du contrat de service WSDL (et schémas XML asso-ciés), ainsi qu’offrant un support pour les différents patrons d’échange de messages (àsens unique, requête/réponse, inscription/publication) et les différents encodages XML(texte et binaires tel que Fast Infoset ou EXI). Un cadre de développement pour ser-vices Web très populaire dans le monde Java est Apache Axis. Nous avons choisi laseconde version de ce projet, soit Axis218. Il s’agit d’un projet open source, hébergépar la fondation Apache, offrant des interfaces de programmation pour la réalisationde services Web (basés soit sur le protocole SOAP ou selon la méthodologie REST),des outils de génération de code à partir des contrats de service WSDL, ainsi que ledéploiement des services sur le Web, soit nativement ou soit en passant par un serveurd’applications Web Java.

Notre développement de service fut effectué sans recourir à l’outil de générationde code à partir du WSDL. Nous avons testé cet outil, mais la hiérarchie de classesqu’il créait s’est avérée trop complexe, vu la grande complexité du contrat de serviceWSDL et des schémas XML associés (i.e. pour l’encodage XML des cubes SOLAP).Le décodage des requêtes contenues dans les messages SOAP a plutôt été faite avecdu code sur mesure, en employant un parseur XML. Le service Web a également étédéployé à des fins de tests sur un serveur d’application, soit Apache Tomcat19.

16JUMP Unified Mapping Platform — http://www.vividsolutions.com/JUMP/17http://geotools.codehaus.org/18http://ws.apache.org/axis2/19http://tomcat.apache.org/

http://www.vividsolutions.com/JUMP/

http://geotools.codehaus.org/

http://ws.apache.org/axis2/

http://tomcat.apache.org/


4.1.7 Autres outils

Outre les outils énumérés précédemment, nous en avons utilisé quelques autres.Les besoins de parsing et de sérialisation de documents XML ont été comblés grâce àJdom20, une librairie de manipulation de documents XML comprenant un API de styleDOM. L’environnement de développement utilisé est Eclipse21. En plus de la gestion deprojets Java, Eclipse offre, grâce à des extensions22, un riche support pour l’édition et lavalidation de documents XML, XML Schema et WSDL. Nous avons également utilisél’outil Apache Ant23 pour gérer le processus de compilation des sources, la création depaquetages et le déploiement sur le serveur d’application. Finalement, nous avons utiliséun outil de gestion de versionnement de code, soit Subversion24, pour gérer l’évolution ducode de chaque projet (soit GeoMondrian, GeoKettle et le service Web de constitutionde mini-cubes).

4.1.8 Jeu de données pour tests

Puisque le service Web développé est générique, il peut fonctionner avec n’importequel cube de données, en autant qu’il soit construit pour une technologie OLAP suppor-tée (dans ce cas-ci, GeoMondrian). Le choix des données pour des fins de tests du serviceest donc une préoccupation accessoire. Il importe tout de même que le cube comportecertaines caractéristiques pour tester adéquatement le système : soit la présence d’aumoins une dimension spatiale géométrique ou mixte, d’une ou plusieurs dimensions thé-matiques ainsi que l’existence de plusieurs niveaux dans au moins une des dimensions.Un nombre suffisamment élevé de faits est aussi souhaitable, afin d’avoir un volumeadéquat de données duquel on peut extraire un sous-ensemble pour constituer un mini-cube.

Nous avons choisi d’utiliser le cube de données décrit au chapitre 2, à la section 2.3.3.Il s’agit d’un cube constitué à partir de données de recensement de Statistique Canada,utilisé pour les fins du cours SCG-66124 — Notions avancées de bases de données SIG.Dans le chapitre 2, le cube fut présenté afin d’illustrer le fonctionnement des opérateursde constitution de mini-cubes. Pour simplifier les exemples, seulement une partie desdimensions du cube avait été présentée. Ici, nous utilisons la version complète du cube,comportant cinq dimensions : « Unité géographique » (dimension spatiale), « Temps »

20http://www.jdom.org/21http://www.eclipse.org22Web Tools Platform — http://www.eclipse.org/webtools/23http://ant.apache.org/24http://subversion.tigris.org/

http://www.jdom.org/

http://www.eclipse.org

http://www.eclipse.org/webtools/

http://ant.apache.org/

http://subversion.tigris.org/


Fig. 4.1 – Schéma du cube SOLAP « Recensement »

(dimension temporelle), « Âge », « Sexe » et « Statut de population » (dimensions thé-matiques). Trois mesures sont présentes : « Population », « Naissances » et « Décès »,correspondant respectivement à la population recensée, au nombre de naissances et aunombre de décès. Au total, le cube comporte 1 677 312 faits au niveau le plus détaillé.Le schéma conceptuel25 du cube est illustré à la figure 4.1.

Ce cube de données a été préparé à l’origine pour le logiciel JMap Spatial OLAP,et a été stocké sur un SGBD Oracle, avec les géométries des membres spatiaux dansdes Shapefiles séparés (un pour chaque niveau). Les faits agrégés et détaillés sont sto-ckés dans une seule table de faits, avec des clés étrangères pointant vers les colonnescorrespondant aux différents niveaux, comme le requiert JMap Spatial OLAP. Nousavons développé quelques procédures ETL avec GeoKettle afin d’extraire ces donnéesdepuis le SGBD Oracle et les Shapefiles et de les regrouper dans un schéma multidimen-sionnel stocké sur le SGBD PostgreSQL (avec l’extension spatiale PostGIS), utilisableavec GeoMondrian. Pour ce faire, les données spatiales correspondant aux membres dela dimension « Unité géographique », extraites depuis les Shapefiles, ont été intégrées

25Modélisé selon le formalisme multidimensionnel présenté dans Proulx et Rivest [2005].


à même le schéma multidimensionnel sous PostgreSQL (en tant qu’objets PostGIS).Puisque Mondrian (et par extension GeoMondrian) requiert une table de faits conte-nant uniquement les faits détaillés, seuls les faits au niveau feuille ont été extraits depuisla table sous Oracle afin de les charger sur notre entrepôt PostgreSQL. Il serait pos-sible de créer des tables d’agrégations [Adamson, 2006] pour optimiser les performancesdes requêtes sous Mondrian, mais nous avons omis cette étape optionnelle pour ne pasrallonger le temps de développement.

Le modèle d’implantation du schéma multidimensionnel est donné dans un forma-lisme relationnel graphique, à la figure 4.2. Il s’agit d’un schéma en étoile (une table pardimension), à l’exception près que la dimension géographique est dans un schéma enflocon (une table pour chaque niveau de la dimension). Cela est pour éviter le stockagede multiples exemplaires des géométries de niveaux supérieurs (e.g. la géométrie duCanada au niveau « pays » serait répétée pour le nombre total de divisions de recense-ments), ce qui a un coût élevé en espace de stockage et sur la performance des requêtes.Au centre du schéma, on retrouve la table de faits (f_pop).

Finalement, une fois que le schéma en étoile servant au stockage des données du cubeest créé et peuplé, une dernière étape reste à accomplir pour que ce dernier puisse êtreutilisé avec GeoMondrian : il s’agit d’écrire le schéma du cube en XML. Ce fichier deconfiguration, dont la syntaxe est propre à Mondrian (et par extension GeoMondrian),contient la description du mapping entre le contenu de l’entrepôt de données (tables etcolonnes) et les objets OLAP du cube (dimensions, hiérarchies, niveaux, membres etmesures). Mondrian utilise cette information pour construire les requêtes relationnellesSQL servant à récupérer les données de l’entrepôt, à partir des requêtes multidimen-sionnelles MDX soumises par le client. Ce fichier XML est donné en annexe A (listageA.16).

4.2 Architecture du système

4.2.1 Architecture générale du système

L’architecture générale du système a été illustrée dans les deux articles composantles chapitres précédents. Nous reprenons à la figure 4.3 le schéma du système, afind’expliquer le rôle des différentes composantes dans l’architecture.


d_age

PK d_age_key

age_codeage_nomgroupe_codegroupe_nomcategorie_codecategorie_nomintervalle_codeintervalle_nomtous_codetous_nom

d_annee

PK d_annee_key

annee_codeannee_nomrecens_coderecens_nomtous_codetous_nom

d_sexe

PK d_sexe_key

sexe_codesexe_nomtous_codetous_nom

d_statut_pop

PK d_statut_pop_key

membre_codemembre_nom

FK1 parent_key

d_unite_geo_division

PK d_unite_geo_key

division_codedivision_nomdivision_geom

FK1 rg_econo_code_fk

f_pop

PK,FK2 d_age_keyPK,FK3 d_annee_keyPK,FK4 d_sexe_keyPK,FK1 d_statut_pop_keyPK,FK5 d_unite_geo_key

populationnb_naissancenb_deces

d_unite_geo_rg_econo

PK rg_econo_code

rg_econo_nomrg_econo_geom

FK1 province_code_fk

d_unite_geo_province

PK province_code

province_nomprovince_geom

FK1 region_code_fk

d_unite_geo_region

PK region_code

region_nomregion_geom

FK1 pays_code_fk

d_unite_geo_pays

PK pays_code

pays_nompays_geom

Fig. 4.2 – Schéma d’implantation de l’entrepôt de données de test


Fig. 4.3 – Architecture générale du système

4.2.1.1 Systèmes sources

Il s’agit des systèmes dont sont extraites les données à charger dans l’entrepôt. Cessources de données sont souvent des systèmes opérationnels, mais il peut égalements’agir de jeux de données provenant d’un fournisseur externe (e.g. agence collectant desstatistiques) ou bien de données diffusées sur le Web (e.g. service WFS [OGC, 2005b]diffusant des données encodées en GML). Dans l’environnement de test du prototype,les sources de données sont un schéma en étoile stocké sur un SGBD Oracle, ainsi qu’unensemble de Shapefiles contenant les géométries des membres spatiaux (cf. 4.1.8).

4.2.1.2 Procédures ETL

Les données provenant des systèmes sources sont transformées, intégrées et char-gées dans l’entrepôt de données grâce aux procédures ETL. Tel qu’expliqué dans lasous-section 4.1.8, les procédures ETL développées pour GeoKettle font l’extractiondes données du cube sous Oracle et depuis les Shapefiles afin de peupler les tablesde l’entrepôt de données, organisées dans un schéma en étoile dont la structure estappropriée pour GeoMondrian.

4.2.1.3 Entrepôt de données (SGBDR)

L’entrepôt de données contient les tables de faits et de dimensions du schéma enétoile. Ces données sont exploitées par un serveur OLAP ; d’autres systèmes peuventégalement tirer parti de l’entrepôt, par exemple pour la fouille de données (data mi-

ning), les tableaux de bord ou les rapports (reporting). Pour l’environnement de notreprototype, nous avons choisi le SGBD relationnel PostgreSQL, avec l’extension spa-


tiale PostGIS, afin de centraliser en un seul point toutes les données, qu’elles soientdescriptives ou spatiales.

4.2.1.4 Serveur OLAP

Le prototype s’appuie sur GeoMondrian comme serveur OLAP. Il s’agit d’une tech-nologie de type ROLAP (Relational OLAP), présentant aux applications clientes unevue multidimensionnelle de l’entrepôt de données, soit avec des objets tels que dimen-sions, hiérarchies, niveaux, membres, mesures et cellules. Dans notre prototype, Geo-Mondrian n’est pas utilisé en tant que serveur proprement dit ; il est exploité en tantque librairie s’exécutant dans le même processus que le service Web. Cette distinctionn’a qu’un impact au niveau du déploiement du système : le moteur OLAP et le serviceWeb doivent être déployés sur le même serveur, puisque les deux font partie d’une mêmeinstance de processus.

4.2.1.5 Service Web de constitution de mini-cubes

Le service Web de constitution de mini-cubes constitue le point d’intérêt centralde ce projet de recherche. Il s’agit d’un service Web développé à l’aide du cadre dedéveloppement Apache Axis2, et s’exécutant sur un serveur d’applications Web Java (enl’occurence Apache Tomcat). Le service reçoit les requêtes XML (messages SOAP) desclients, telles que définies par le contrat de service (cf. chapitre 3). Il utilise GeoMondrianpour obtenir les objets OLAP demandés par les clients, et s’occupe de retourner lesdonnées sous forme de mini-cubes SOLAP encodés en XML. Les détails d’implantationet les tests de fonctionnement du prototype de service Web sont respectivement décritsdans la sous-section 4.2.2 et dans la section 4.3 de ce chapitre.

4.2.1.6 Clients (mobiles ou autres)

Les clients se connectent au service Web, transmettent les requêtes encapsuléesdans des messages SOAP et reçoivent les réponses du service contenant les donnéesdemandées. Le client est responsable de décoder les cubes XML afin d’en disposer dansun format utilisable par l’application SOLAP sur l’appareil mobile ; le développementd’une telle application dépasse toutefois le cadre de ce projet de recherche. Tel qu’il futdécrit dans la sous-section 3.3.2.3 du chapitre précédent, des services Web auxiliairespeuvent agir comme clients du service de constitution de mini-cubes, en s’intercalant


entre celui-ci et le client mobile, afin d’offrir des fonctionnalités supplémentaires tel quele décodage des données XML.

4.2.2 Architecture détaillée du service Web

Le service Web de constitution de mini-cubes SOLAP a été conçu et développépour être adaptable et réutilisable. Il s’agit donc d’un prototype évolutif. Ce choix dedesign a été fait en fonction des projets de recherche futurs ; en effet, des travaux àvenir au sein du groupe de recherche GeoSOA concerneront le développement de clientsmobiles pour applications géomatiques décisionnelles, qui s’appuieront entre autres surles fonctionnalités offertes par le service. Nous avons donc soigné la qualité du code etaccordé une attention particulière à la modularité du design pour faciliter l’évolutionet les modifications ultérieures.

La sous-section précédente (4.2.1) a fait la description de l’architecture généraledu système, soit l’environnement et les différents composants qui entourent le serviceWeb de constitution de mini-cubes. Cette partie montre comment le service proprementdit est construit, en expliquant le rôle des différents modules développés ainsi que lamanière dont ils interagissent entre eux.

4.2.2.1 Couche d’abstraction des objets OLAP

Puisque le service Web s’appuie sur un moteur OLAP pour la sélection et la ré-cupération des données du cube, un module s’interfaçant avec ce moteur OLAP a dûêtre conçu. Ce module fait office de couche d’abstraction des objets du cube : il estconstitué d’interfaces (au sens Java) représentant les connexions au serveur, les cubes,les dimensions, les hiérarchies, les niveaux, les membres (ainsi que leurs propriétés) etles cellules. Ces interfaces sont abstraites, i.e. elles ne sont pas liées à une technologieOLAP en particulier. Des classes implémentant ces interfaces ont été créées ; dans notrecas nous avons réalisé celles-ci en encapsulant les objets et appels à l’interface de pro-grammation (API) de Mondrian. Il serait également possible de créer d’autres séries declasses implémentant les mêmes interfaces, afin d’offrir le support pour d’autres moteurset API OLAP, e.g. pour XML for Analysis ou olap4j26. Puisque les autres modules duservice n’interagissent avec la couche d’abstraction OLAP que par les interfaces, cesautres moteurs OLAP pourraient facilement s’intégrer, sans avoir à modifier le reste dusystème.

26http://www.olap4j.org

http://www.olap4j.org


Il importe de mentionner que tous les types de données pouvant exister comme pro-priété de membre ou valeur de cellule (faits) sont supportés par la couche d’abstraction.Cela comprend les types classiques tels que les nombres entiers et réels, les chaînes decaractères, les dates, etc. ainsi que les types complexes tels que les géométries vecto-rielles. Une hiérarchie de classes permet de représenter tous ces types, et d’invoquercertaines opérations telles que les algorithmes de simplification géométrique.

4.2.2.2 Générateur de requêtes MDX

Lorsque le client demande les cellules du cube par un appel de l’opération GetCells

(cf. 3.3.1.5), le service doit transmettre au moteur OLAP une requête afin de récupérerles données demandées. La requête GetCells est formulée selon les opérateurs de sélec-tion de cellules (cf. 2.3.3.2), et encodée dans un dialecte XML, respectant les principesde conception des architectures orientées services et offrant un contrat de service fai-blement couplé. Le service Web doit interpréter cette requête XML et la transformeren une requête MDX, capable d’être traitée par le serveur OLAP.

Le générateur de requêtes MDX est responsable de cette tâche : il génère le codeMDX correspondant à l’opération choisie, en fonction des opérateurs de sélection decellules. L’application d’un opérateur sur une dimension cause l’ajout d’un axe dansla clause SELECT ; les membres demandés pour la dimension y sont ajoutés (ou biensélectionnés par une fonction MDX de membres). Le jeu de cellules retourné contientdonc toutes les données demandées, à raison d’un axe par dimension incluse dans le mini-cube. Un exemple de requête GetCells, avec la requête MDX générée correspondante,est donné en annexe A (listage A.17).

Il y a lieu de se demander s’il y a des limitations ou risques associés à la traduction enMDX d’une requête GetCells, paramétrée par des éléments XML. Il faut savoir que lesopérateurs de sélection de cellules (cf. 2.3.3.2 et 3.3.1.5) entrant dans le paramétragede l’opération GetCells répondent aux besoins spécifiques de constitution des mini-cubes. Leur pouvoir expressif n’est pas le même que celui du langage MDX : ils sesituent à un niveau d’abstraction plus élevé, proche de leur domaine d’application.Plusieurs catégories d’expressions, telles que les membres et mesures calculés ou encorele croisement de membres de plusieurs dimensions sur un seul axe de résultat, sontpermises en MDX mais n’ont pas d’équivalent direct dans une requête GetCells. Unmapping de GetCells vers MDX peut être établi, et a été défini selon un ensemble derègles précises faisant partie du module générateur de requêtes MDX du prototype.Toutefois, l’inverse n’est pas vrai ; on ne pourrait pas transformer n’importe quellerequête MDX arbitraire en une requête GetCells équivalente. Quant à la validité de la


génération de code MDX du prototype, elle dépend de la bonne conception du présentmodule, sur lequel on se fie pour obtenir des résultats corrects. Cela fut validé par unerevue attentive du design et du code source de ce module, par l’inspection des requêtesMDX générées pour différents opérateurs de sélection de cellules, et par la vérificationdes résultats de plusieurs requêtes.

Un autre processus de génération de requêtes a aussi lieu dans le fonctionnement in-terne d’une couche logicielle sous-jacente au prototype, soit le serveur OLAP Mondrian.Il s’agit du mapping MDX vers SQL intrinsèque à la technologie ROLAP de Mondrian.Cette composante logicielle est réputée comme étant fiable27 ; on s’attend dès lors àce que les requêtes MDX traitées par le serveur OLAP retournent les bons résultats.Il s’agit d’une pratique qui est fondamentale dans le domaine de l’informatique : unsystème n’est pratiquement jamais construit à partir de rien, et on fera appel à plu-sieurs couches logicielles existantes dont les fonctionnalités et la fiabilité sont connues.Le risque d’une « erreur de traduction » entre MDX et SQL n’est donc pas une préoc-cupation importante dans le contexte du présent projet de recherche.

4.2.2.3 Sérialisation XML des objets OLAP

Le service Web retourne en réponse aux requêtes des clients des documents XMLconformes à l’encodage décrit dans l’article du chapitre 3. La requête DescribeSchema

retourne un document CubeSchema, GetMembers retourne un document CubeMembers

et GetCells retourne un document CubeCells. Le module de sérialisation XML desobjets OLAP est responsable de produire les documents dans l’encodage XML pourcubes SOLAP, à partir des objets de la couche d’abstraction OLAP.

4.2.2.4 Couche applicative du service Web

Ce module constitue le point d’entrée principal du service Web. Une classe nomméeMinicubeWS contient les méthodes pour chacune des opérations du contrat de service,soit GetCapabilities, DescribeSchema, GetMembers, GetCells et GetCube. Ces méthodessont appelées par Apache Axis2 lorsque le serveur d’application reçoit une requête d’unclient, en leur donnant en paramètre l’élément XML de requête, encapsulé dans lemessage SOAP. Des ensembles de classes, associés à chacune des opérations, s’occupent

27Mondrian comporte entre autres une batterie de tests unitaires très exhaustive, permettant devalider le comportement de tous ses modules ; cette pratique de génie logiciel est souvent gage d’unegrande fiabilité.


de décoder la requête et de mobiliser les autres modules du service Web pour traitercette requête et ainsi retourner une réponse au client.

4.2.2.5 Client pour tests

Un client très simple a été conçu pour réaliser la validation et les tests du serviceWeb. Il s’agit d’une application en ligne de commandes, permettant d’invoquer le serviceavec des requêtes préprogrammées (enregistrées dans des fichiers XML) et d’afficherla réponse du service à l’écran, avec le temps d’attente pour obtenir celle-ci. Cetteapplication a été développée en faisant appel à la librairie de client de service Webfournie avec Apache Axis2. Éventuellement, un client avec interface graphique pourraitpermettre de réaliser les requêtes de constitution de mini-cubes d’une manière plusconviviale.

4.3 Tests du service

Afin de déterminer si le service Web répond adéquatement aux besoins pour lesquelsil a été conçu, nous avons fait quelques tests évaluant la performance du service ainsi quela compressibilité des données livrées au client. Cette section décrit quel environnementinformatique a été utilisé à cette fin, et montre les résultats des tests pour chacune desopérations du contrat de service.

4.3.1 Configuration de l’environnement de test

Les tests ont été réalisés sur la configuration matérielle décrite dans le tableau 4.1.

Processeur AMD Athlon 64 X2 3800+ (2 GHz, double coeur)Mémoire vive 2 GB (DDR)Disque dur 400 Go, 7200 RPM, SATA (Seagate ST3400832AS)

Tab. 4.1 – Configuration matérielle de l’environnement de test

La configuration logicielle est décrite dans le tableau 4.2.


Système d’exploitation Microsoft Windows XP Professionnel ServicePack 2

Environnement Java Sun Java(TM) SE Runtime Environment(build 1.5.0_12-b04)

Serveur d’applications WebJava

Apache Tomcat 6.0.16

Moteur OLAP Mondrian 3.0.1.11177 (version de développe-ment en date du 2008-06-16) avec extensionspour données spatiales (GeoMondrian)

Système de gestion de basede données

PostgreSQL 8.3.3 avec cartouche spatialePostGIS 1.3.3

Tab. 4.2 – Configuration logicielle de l’environnement de test

Tous les tests ont été effectués en local, c’est-à-dire avec le client et le service s’exé-cutant sur le même poste de travail (sans passer par une connexion réseau). Cela im-plique que le délai d’attente pour la transmission des messages entre client et service estpresque nul. Dans un environnement réel, avec clients mobiles, le délai de transmissionaurait un impact sur la rapidité des opérations, selon la bande passante disponible surle réseau. Ce délai est toutefois facile à estimer, en le calculant en fonction du débitmoyen du réseau et de la taille des données à transmettre.

4.3.2 Tests de performance

Les tests de performance permettent d’évaluer le temps de réponse du service pourchacune des opérations, sous des conditions d’exécution contrôlées.

4.3.2.1 Requêtes effectuées

Requête GetCapabilities

Il s’agit d’une simple requête GetCapabilities pour obtenir de l’information sur leservice ; cette requête est donnée en annexe A (listage A.8).


Requête DescribeSchema

La requête DescribeSchema testée permet d’obtenir le schéma du cube « Recense-ments » (voir listage A.10 en annexe A).

Requête GetMembers

Cette requête GetMembers permet d’obtenir tous les membres de la dimension demesures, tous les descendants des membres « Adolescents 12-17 » et « Jeunes adultes18-24 » du niveau « Groupe », ainsi que trois membres de la dimension « Unité géogra-phique » obtenus avec une sélection spatiale par rectangle englobant. Une simplificationgéométrique est également appliquée à ces membres (par l’algorithme Douglas-Peucker,avec un seuil de 0.01 degrés décimaux). Le code de la requête est donné en annexeA (listage A.12). La requête retourne 21 membres au total (15 membres descriptifs, 3membres de mesures et 3 membres spatiaux).

Requête GetCells

La requête GetCells servant à ce test récupère les cellules pour constituer un mini-cube à deux dimensions (plus la dimension des mesures). La sélection se fait sur tousles descendants du membre « Québec » de la dimension « Unité géographique » et surtrois membres agrégés (niveau « Groupe ») de la dimension « Âge ». On effectue unetranche sur le membre « 2001 » de la dimension « Temps », ce qui signifie que lescellules retournées seront pour l’année 2001 uniquement. La seule mesure incluse est« Population ». Voir l’annexe A pour la requête complète (listage A.14). La requêteretourne un total de 297 cellules.

4.3.2.2 Résultats des tests

Les requêtes ont été lancées dans l’ordre usuel de découverte des données du cubeexposé via le service Web, soit GetCapabilities, DescribeSchema, GetMembers et ensuiteGetCells, tel qu’un client mobile le ferait en général lors d’une invocation du service.Cette séquence fut exécutée à deux reprises : une première fois immédiatement après ledémarrage du service Web, et une seconde fois après l’exécution du premier groupe derequêtes. Cela a pour but de comparer les temps d’exécution « à froid » et « à chaud »,afin de voir si le service se comporte différemment lors d’invocations répétées. Les tempsd’exécution, donnés en secondes (s) et millisecondes (ms), sont présentés dans le tableau4.3.


Requête Temps d’exécution « à froid » Temps d’exécution « à chaud »

GetCapabilities 4s 141ms 0s 265msDescribeSchema 0s 281ms 0s 31msGetMembers 30s 344ms 16s 47msGetCells 5s 313ms 0s 297ms

Tab. 4.3 – Temps d’exécution des requêtes de test

4.3.2.3 Interprétation des résultats

La première exécution de la requête GetCapabilities dure environ 4 secondes, alorsque la seconde exécution est quasi instantanée (265 ms). Cette différence s’explique parle fait que le service doit s’initialiser lors de la toute première invocation après son dé-marrage : les classes Java sont chargées depuis le disque dur par le serveur d’applicationet les connexions au SGBD sont établies. Ce n’est qu’après ces tâches que le servicepeut répondre à la requête. Ce surcoût est présent peu importe quelle requête est lancéeen premier, et les requêtes subséquentes ne sont plus affectées pour toute la durée defonctionnement du service Web (jusqu’à son redémarrage).

L’opération DescribeSchema s’exécute aussi très rapidement. Tout comme GetCa-

pabilities, cette opération est simple, n’implique qu’un petit volume de données et nenécessite pas de traitements complexes.

La requête GetMembers met 30 secondes à s’exécuter la première fois ; cela peutparaître un peu long vu le nombre de membres peu élevé retournés par la requête. Lagrande majorité du temps de traitement est passée à la sélection spatiale des membres ;tel qu’implanté, cet opérateur n’est pas optimal, puisqu’il n’utilise pas l’indexation spa-tiale du SGBD. Ainsi, les géométries des membres de la dimension spatiale doivent êtrecomparées une par une, augmentant le temps de réponse. De plus, certaines optimi-sations pourraient être apportées à la sérialisation en format GML et aux opérateursde simplification géométriques. La seconde exécution est moins longue (16 secondes),puisque les membres de la dimension spatiale ont déjà été chargés par Mondrian dansle cache de membres (en mémoire vive) ; le moteur OLAP n’a pas à accéder à nouveauau SGBD pour récupérer les données des membres, ce qui explique le gain de temps.

Le temps d’exécution de la première requête GetCells est de 5 secondes. Une obser-vation du temps de processeur consommé par chaque processus lors de l’exécution dela requête montre que la plus grande partie du temps de traitement se situe au niveaudu SGBD relationnel. Cela s’explique par le fait que nous n’avons pas créé et peuplé


de tables d’agrégations pré-calculées (ou vues matérialisées) ; ainsi, certains traitementslors de l’exécution de requêtes MDX retournant des cellules agrégées doivent être prisen charge par le SGBD. Ce dernier peut passer un temps considérable à traiter les re-quêtes SQL que lui soumet Mondrian, requêtes caractérisées par la présence de clausesGROUP BY et d’opérateurs agrégatifs (i.e. SUM ) ; cependant, vu la taille limitée ducube utilisé à des fins de test28, le calcul à la volée des données agrégées s’avère tout demême relativement rapide. Le temps de réponse très court (297 ms) lors de la deuxièmeexécution vient appuyer cette affirmation, puisque Mondrian comporte un cache pourles cellules. Dans ce cas, les données des cellules récupérées depuis le SGBD et agrégéessont stockées en mémoire vive lors du traitement de la première requête, et sont utiliséespour répondre presque instantanément à la seconde requête. Il importe également dementionner que l’ajout de tables d’agrégations pré-calculées dans l’entrepôt contenantles données du cube serait susceptible d’accélérer significativement le traitement desrequêtes GetCells lors de leur première exécution, surtout lorsqu’on dispose de cubesde taille plus importante.

4.3.3 Compression des données

Afin de vérifier quel gain en taille de données (et donc en temps de transmissionsur un réseau au débit limité) il est possible d’obtenir en utilisant des algorithmes decompression classiques, nous avons effectué un simple test avec l’algorithme gzip. Ils’agit de compresser avec l’utilitaire gzip29 des fichiers XML contenant les messages deréponse pour les requêtes GetMembers et GetCells décrites en 4.3.2.1. Les résultats sontprésentés dans le tableau 4.4.

Message deréponse

Taille non-compressée

Taille com-pressée gzip

Ratio (pour-centage del’original)

Temps decompression

GetMembers 13460 octets 2175 octets 16,16% 31 msGetCells 185280 octets 4343 octets 2,34% 46 ms

Tab. 4.4 – Résultats de la compression des messages de réponse

On constate que ces réponses sont très compressibles, et qu’il est possible de réaliserun gain important en taille de stockage, donc en temps de transmission, en appliquantun simple algorithme de compression tel que gzip. On voit également que le temps

281 677 312 faits, ce qui est petit comparé à certains gros cubes29L’utilitaire gzip est disponible dans n’importe quelle distribution de Linux ou dans l’environnement

Cygwin pour Windows.


de compression est négligeable, par rapport au temps d’exécution des requêtes. Si leclient et le service supportent tous les deux un tel algorithme, il peut être activé demanière transparente lors de l’échange de messages. Une telle option n’a pas été im-plantée à l’heure actuelle, mais il serait relativement simple de l’ajouter dans le cadrede développement Apache Axis2 pour l’échange des messages SOAP.

4.3.4 Validation et autres tests

Les tests décrits dans les deux parties précédentes concernent la performance duservice et la compressibilité des données. Cependant, nous n’avons pas pu valider si lerésultat produit par le prototype est adéquat pour répondre aux besoins des utilisateursmobiles, puisque le client mobile SOLAP n’existe pas encore. Une telle validation del’utilisabilité du système complet serait de mise dans les futurs travaux de recherche por-tant sur la conception d’applications SOLAP mobiles. La validité du contenu retournépar le service Web dans les messages de réponse est garanti par leur validation parrapport au schéma XML (W3C XML Schema) décrivant l’encodage XML pour mini-cubes (présenté au chapitre 3 et donné dans la partie A.2.1 de l’annexe A). Quelquesvérifications manuelles ont également été faites pour comparer les données numériquesretournées par l’appel de GetCells avec une requête MDX équivalente ; les résultatsconcordaient pour toutes ces vérifications.

4.4 Limites du prototype

Afin d’économiser du temps dans la réalisation du prototype, certains éléments ducontrat de service ainsi que du format d’encodage des cubes XML n’ont pas été implan-tés pour l’instant. Nous décrivons ici ces limites, en expliquant pourquoi la réalisationde ces fonctionnalités a été reportée.

4.4.1 Opération GetCube

L’opération GetCube, telle que décrite dans le contrat de service (cf. 3.3.1.6 dans lechapitre 3), n’est pas implantée dans le prototype de service Web ; un client qui appellecette opération recevra en retour un message d’erreur (SOAP Fault). Nous avons omisl’implantation de cette opération puisque les mêmes données peuvent être récupérées


grâce à une combinaison des opérations DescribeSchema, GetMembers et GetCells. Uneversion ultérieure du service devrait toutefois comporter cette opération, afin de pouvoirrécupérer toutes les données constituant un mini-cube en un seul appel, simplifiant ainsile fonctionnement des clients.

4.4.2 Éléments de l’encodage XML pour cubes SOLAP

Pour sauver du temps dans la réalisation du prototype, les éléments suivants, faisantpartie de la spécification de l’encodage XML pour cubes SOLAP (cf. article du chapitre3), ont été omis :

Description des mesures : les propriétés des membres de la dimension de mesures(cf. 1.2.1.2, définition de Mesure) permettant de décrire les opérateurs d’agréga-tion à utiliser pour une mesure ne sont pas retournées par l’opération GetMembers.Cette information ne peut être obtenue de manière programmatique à partir del’API de Mondrian ; il serait éventuellement possible d’ajouter cette fonctionna-lité au moteur OLAP, afin que les clients puissent obtenir une description pluscomplète des mesures du cube.

Hiérarchies multiples : la récupération des membres à partir de dimensions compre-nant plus d’une hiérarchie n’a pas été entièrement implémentée et testée. Il esttoutefois possible d’obtenir les membres de la hiérarchie par défaut, dans tous lescas.

Hiérarchies parent-enfant : l’obtention des membres depuis une hiérarchie parent-enfant n’a pas été testée, faute de temps. Il est possible que quelques ajustementsau prototype soient nécessaires afin d’assurer l’application correcte de l’opérateurde sélection de tous les descendants d’un membre, dans le cas d’une dimensionavec hiérarchie parent-enfant.

4.5 Conclusion

Ce chapitre a fait l’état de la réalisation du prototype de service Web de constitutionde mini-cubes SOLAP. Les choix technologiques furent décrits, tant pour le langage deprogrammation, les composantes logicielles utilisées et les données de test. L’architec-ture générale, présentant les différents éléments mis en œuvre dans le système ainsi queles interactions entre ceux-ci, et l’architecture détaillée, montrant le découpage et la


logique de fonctionnement du module de service Web en tant que tel, furent présen-tées. Des tests de performance et de compressibilité des données furent réalisés, tout enfaisant état des optimisations possibles pour améliorer le temps de réponse du service.Finalement, les limites du prototype actuel ont été énoncées.

Il faut savoir que le prototype développé au cours de ce projet de recherche constitueune preuve de concept. Ce prototype évolutif, bien que conçu pour être extensible, neconstitue pas l’unique réalisation possible d’un service Web de constitution de mini-cubes SOLAP. Il serait envisageable de créer une autre implémentation de ce service,s’appuyant sur des choix technologiques entièrement différents, tout en respectant l’en-codage XML et le contrat de service décrits au chapitre 3. Il s’agit là de l’un desavantages des architectures orientées services, dans le sens que la réalisation d’un ser-vice Web est indépendante de sa manière d’interagir avec le monde extérieur (telle quedéfinie par le contrat de service). En d’autres termes, dans une architecture orientéeservices, le contrat de service est faiblement couplé à son implémentation.

Chapitre 5

Conclusion et perspectives

5.1 Conclusion

Le travail accompli au cours de ce projet de recherche a permis de mieux positionnerla faisabilité et les critères technologiques à considérer pour amener les applicationsSOLAP à fonctionner dans les environnements informatiques mobiles, ce qui rejointl’un des objectifs principaux de la Chaire de recherche industrielle CRSNG en basesde données géospatiales décisionnelles1 : « [...] améliorer les bases de données sur leterritoire pour mieux supporter la prise de décision, tant locale que mobile » [Bédard,2007]. La voie est ainsi ouverte au développement de telles applications, fonctionnant deconcert avec l’infrastructure technologique existante en géomatique décisionnelle. Celacadre avec l’objectif général du projet, qui est de concevoir et de mettre en œuvre unearchitecture pour la diffusion des données géo-décisionnelles à destination des clientsmobiles. Pour atteindre cet objectif général, un certain nombre d’étapes ont été franchiesafin de répondre aux objectifs spécifiques :

Premièrement, nous avons identifié les contraintes des environnements informatiquesmobiles (cf. 1.2.2.2) qui font en sorte que les applications SOLAP de bureau actuellesdoivent être modifiées et adaptées pour pouvoir être portées sur des plateformes mobiles.Ces contraintes se rapportent aux interfaces utilisateurs et aux méthodes d’entrée, auxcapacités de calcul, de stockage et d’alimentation électrique, aux liens de communicationet à l’interopérabilité entre systèmes. Dans le cadre de ce projet de recherche, nous noussommes concentrés sur ce qui est nécessaire pour adapter les cubes de données SOLAP

1La Chaire, dont ce projet de maîtrise a bénéficié de l’étroite collaboration, est dirigée par leprofesseur Yvan Bédard. Voir http://mdspatialdb.chair.scg.ulaval.ca/

http://mdspatialdb.chair.scg.ulaval.ca/

Chapitre 5. Conclusion et perspectives 145

face à ces contraintes ; la conception des interfaces utilisateurs et du client mobile ferontpartie de futurs travaux au sein du groupe de recherche GeoSOA2.

Deuxièmement, nous avons élaboré une méthode pour adapter les cubes de don-nées SOLAP aux environnements mobiles. La solution proposée s’articule autour duconcept de mini-cube, soit une version de taille réduite des cubes SOLAP, adaptée auxcontraintes de mobilité. Ces mini-cubes sont constitués à partir de cubes existants, enleur appliquant des opérateurs de constitution de mini-cubes (cf. 2.2.3.2 et 2.3.3), per-mettant de sélectionner un sous-ensemble des membres et des faits correspondant aucontexte d’analyse d’un utilisateur mobile. Ces opérateurs tiennent également comptede la composante spatiale des cubes SOLAP, puisqu’ils offrent des possibilités de sé-lection par analyse spatiale (prédicats topologiques). Ils offrent aussi la possibilité deréduire la complexité des géométries afin de diminuer leur taille de stockage et de lesadapter aux affichages des appareils mobiles. La taille réduite des mini-cubes rend pos-sible leur transmission sur des réseaux sans-fil dont la bande passante est limitée, ainsique leur stockage sur un appareil mobile. Cette possibilité de stockage local des cubespermet également de consulter ceux-ci de manière autonome, lorsqu’aucune connecti-vité réseau n’est disponible. Enfin, les contraintes d’interopérabilité ont été prises encompte par la conception d’un encodage XML pour mini-cubes SOLAP et d’un serviceWeb pour leur livraison (cf. chapitre 3), rendant possible l’utilisation du service et ladiffusion des mini-cubes sur un vaste éventail de plateformes mobiles, peu importe lematériel et les logiciels utilisés.

Finalement, nous avons réalisé cette infrastructure technologique pour le SOLAPmobile, sous forme d’un prototype de service Web de constitution de mini-cubes. Leschoix technologiques ont été décrits et justifiés, tant en termes de l’approche employée(ETL ou OLAP, cf. 2.3.4.3) pour réaliser le prototype que du choix des données de testet des outils logiciels mis en œuvre lors du développement (cf. 4.1). Le service Web conçuet développé dans le cadre de ce projet constitue une première brique d’une architec-ture orientée services pour les applications de géomatique décisionnelle, qu’elles soientde nature mobile ou sédentaire. D’autres services pourront venir s’ajouter à celui-ci,afin de compléter les fonctionnalités offertes (voir perspectives, 5.3). Le développementdu prototype vient également démontrer une manière d’intégrer les éléments existantsd’une infrastructure technologique d’informatique décisionnelle (i.e. entrepôt de don-nées, SGBD et serveur OLAP) dans une architecture orientée services (cf. 4.2). Deplus, plusieurs outils développés au cours du projet constituent des composantes réuti-lisables, qui servent déjà au sein de nouveaux travaux de recherche.

2voir http://geosoa.scg.ulaval.ca pour plus de détails

http://geosoa.scg.ulaval.ca


5.2 Contributions

5.2.1 Encodage XML pour cubes SOLAP et contrat de service

Le développement d’un service Web a nécessité la conception d’un encodage XMLpour les mini-cubes SOLAP, tel que présenté dans l’article inclus au chapitre 3. Un telencodage permet de représenter les métadonnées (schéma du cube, soit les dimensions,hiérarchies et niveaux) et les données (membres et cellules, incluant les membres spa-tiaux et cellules contenant des valeurs géométriques pour des mesures spatiales) d’uncube dans un format d’échange interopérable. L’usage d’un tel format n’est pas res-treint à la diffusion des mini-cubes vers les plateformes mobiles ; il serait envisageablede le mettre en œuvre à d’autres fins, par exemple pour faciliter l’intégration de don-nées provenant de différentes sources multidimensionnelles, pour diffuser des cubes dedonnées à travers une architecture fédérée d’entrepôts de données spatiales (d’un data

warehouse vers plusieurs data marts) ou encore pour tout usage où des données SOLAPont besoin d’être transmises d’une manière indépendante de la plateforme logicielle.

De plus, le contrat de service WSDL (présenté en 3.3.1), décrivant la syntaxe em-ployée pour l’invocation des opérateurs de constitution de mini-cubes, serait assez gé-nérique pour en faire un service Web général de diffusion de cubes SOLAP, et ce peuimporte leur taille. Certaines fonctionnalités (e.g. simplification géométrique) sont spé-cifiques aux mini-cubes pour clients mobiles, mais le reste des opérateurs de sélectionde membres et cellules sont applicables à toute situation où on doit sélectionner unsous-ensemble d’un cube et transmettre ce contenu sur un lien réseau. Pour faire unparallèle avec les services Web géomatiques de l’OGC (cf. 1.2.4.1), le contrat de serviceproposé est aux données spatiales décisionnelles ce que le service WFS (Web Feature

Service) est aux données spatiales transactionnelles, soit un mécanisme de sélection etde diffusion efficace et interopérable.

5.2.2 Outils logiciels pour la géomatique décisionnelle

Le prototype réalisé au cours de ce projet de recherche fait appel à de nombreusestechnologies open source, qui ont été choisies pour la flexibilité qu’elles offrent lorsquevient le temps de les adapter à des besoins particuliers. En particulier, nous avonsétendu les fonctionnalités d’un outil ETL et d’un serveur OLAP afin de leur ajouter lesupport des données spatiales.


5.2.2.1 GeoKettle

Dans le cadre des expérimentations faites avec une approche ETL (Extract, Trans-

form, Load) pour la constitution des mini-cubes, l’outil ETL open source Kettle3 de lacompagnie Pentaho, a été modifié afin de lui ajouter le support pour les types de don-nées géométriques vectorielles (i.e. points, lignes et polygones), des opérateurs d’analysespatiale (accessibles par une interface JavaScript) ainsi que le support en entrée-sortiepour un SGBD spatial (PostGIS) et le format de fichier SIG Shapefile. Nous avonsnommé cette version « spatialisée » GeoKettle. Il s’agit d’un outil puissant et flexiblepour faire l’intégration de données spatiales, ainsi que le peuplement et la mise à jourdes entrepôts de données spatiales. GeoKettle est maintenant distribué comme projetopen source4.

GeoKettle a été utilisé dans le cadre d’un autre projet de recherche de l’équipeGeoSOA, soit la maîtrise de Charlotte Declercq, portant sur la conception et le dé-veloppement d’un service Web de mise à jour de cubes SOLAP [Declercq, 2008]. Desprocédures de mise à jour incrémentielle des tables géospatiales de dimensions et defaits ont été conçues à cette fin. Un autre étudiant du département, Mathieu Bertrand,a également apporté des améliorations à GeoKettle dans le cadre du cours SCG-67210

— Cadres de développement logiciel en géomatique. Ces améliorations comportent l’in-tégration de fonctionnalités provenant de la librairie JCS5 et l’ajout d’une visionneusecartographique pour la visualisation des résultats de transformations sur les champsde type géométrique. Il est prévu de continuer le développement de GeoKettle, notam-ment pour améliorer l’interface utilisateur (avec des boîtes de dialogue pour faciliterl’utilisation des opérateurs d’analyse spatiale), pour intégrer la gestion des systèmes deréférence spatiale et pour ajouter le support pour de nouveaux types de SGBD spatiaux(Oracle Spatial, IBM DB2, etc.) et de formats de fichier (MapInfo, GML, etc.).

5.2.2.2 GeoMondrian

Un autre logiciel de Pentaho, soit le serveur OLAP open source Mondrian6, a étémodifié afin de permettre de supporter les données spatiales vectorielles. Le projetrésultant, GeoMondrian, permet d’exploiter les entrepôts de données stockés dans un

3http://kettle.pentaho.org/4La page Web du projet, où on peut télécharger le code source complet, est accessible à l’adresse

http://www.geokettle.org/5JCS Conflation Suite — http://www.vividsolutions.com/JCS/6http://mondrian.pentaho.org/

http://kettle.pentaho.org/

http://www.geokettle.org/

http://www.vividsolutions.com/JCS/

http://mondrian.pentaho.org/


SGBD spatial7. Les données spatiales sont intégrées à même les cubes, sous forme depropriétés géométriques dans les membres des dimensions8. Ainsi, les membres récupéréspar des appels à l’API de GeoMondrian ou par l’exécution de requêtes MDX peuventcontenir une représentation géométrique : en plus du nom du membre (e.g. « Québec »),l’application cliente a à sa disposition la représentation géométrique du membre (e.g. lagéométrie polygonale des limites du Québec). Cette géométrie peut servir à différentesfins : analyse spatiale, représentation cartographique ou encore conversion dans un autreformat (e.g. GML). C’est ce que fait le prototype du service Web de constitution demini-cubes : la géométrie des membres récupérés depuis le serveur GeoMondrian estconvertie en GML et intégrée aux mini-cubes encodés en XML. GeoMondrian a aussiété utilisé pour réaliser Spatialytics, un nouveau client cartographique Web open source

pour les tableaux de bord géo-décisionnels9.

Pour l’instant, l’intégration des données spatiales au cube ne fait qu’assurer leuracheminement à travers le serveur OLAP, depuis l’entrepôt de données vers l’applicationcliente. Les développements à venir apporteront davantage de fonctionnalités, soit :

– le support pour d’autres SGBD spatiaux (Oracle Spatial, IBM DB2, MySQL, etc.)pour le stockage ROLAP ;

– les mesures spatiales géométriques (géométries vectorielles comme valeurs de me-sure) ;

– le support d’opérateurs d’analyse et d’agrégation spatiale10 par l’intermédiaired’extensions à MDX, afin de supporter les requêtes spatiales et la définition demesures spatiales calculées.

Une fois ces fonctionnalités réalisées, GeoMondrian constituera un véritable serveurSOLAP open source, pouvant servir autant comme plateforme de prototypage dans desprojets de recherche que comme composante dans l’implantation d’applications SOLAPà des fins commerciales.

7Pour l’instant, GeoMondrian supporte le SGBD PostgreSQL avec l’extension PostGIS.8À notre connaissance, GeoMondrian est le premier serveur OLAP intégrant ainsi les données

spatiales à même le cube, par opposition à l’approche conventionnelle qui est de les importer depuisl’application cliente, à partir d’un fichier SIG ou d’une base de données spatiale transactionnelle.

9Ce projet, réalisé par l’auteur de ce mémoire sous le mentorat du professeur Thierry Badard, aété financé par Google dans le cadre des financements accordés à l’OSGeo (Open Source GeospatialFoundation) lors du programme Google Summer of Code 2008. Voir http://code.google.com/soc/

2008/osgeo/appinfo.html?csaid=BD0698C3C10CCB36 et http://www.spatialytics.org/.10Sur ce point, les travaux menés par Eve Grenier sur la définition d’opérateurs d’agrégation dans

le cadre de sa thèse de doctorat [Grenier, 2007] seront d’un grand intérêt.

http://code.google.com/soc/2008/osgeo/appinfo.html?csaid=BD0698C3C10CCB36

http://code.google.com/soc/2008/osgeo/appinfo.html?csaid=BD0698C3C10CCB36

http://www.spatialytics.org/


5.3 Perspectives

5.3.1 Services Web auxiliaires pour clients SOLAP mobiles

Le service Web de constitution de mini-cubes SOLAP est une composante destinéeà faire partie d’un éventail étendu de services Web pour la géomatique décisionnelle,dans une architecture orientée services proposée par le groupe de recherche GeoSOA.Un autre prototype de service faisant partie d’une telle architecture a d’ailleurs étéréalisé en même temps que ce projet, soit le service de mise à jour de cubes SOLAPsur lequel porte le mémoire de Charlotte Declercq [Declercq, 2008]. En ce qui concernela diffusion des cubes SOLAP vers les clients mobiles, d’autres services Web auxiliairesont été proposés (voir Badard et al. [2008] et la partie 2.2.3.3 de l’article du chapitre2) pour compléter les fonctionnalités offertes aux mobiles.

Un de ces services auxiliaires servirait à entreposer les mini-cubes XML générés par leservice de constitution, afin d’en faire un cache. Ce cache permettrait à plusieurs clientsd’accéder à des mini-cubes construits à l’avance selon des besoins particuliers, sans avoirà les régénérer à chaque fois, ce qui accélèrerait significativement leur obtention parles clients mobiles. D’autres services étendus potentiels touchent l’authentification desclients (afin d’assurer la sécurité et d’accorder différents droits d’accès aux clients) etl’administration de l’infrastructure technologique (gestion des connexions aux serveursOLAP et aux entrepôts de données, répartition de la charge sur les nœuds d’un cluster,etc.). Le point important à retenir est que dans une architecture orientée services, ilest possible d’étendre les fonctionnalités offertes en combinant plusieurs services ainsiqu’en greffant de nouveaux services à ceux existant, simplifiant ainsi le développementdu système (par la réutilisation des composantes existantes) et assurant une modularitédans le déploiement de ces services à travers un environnement informatique distribué.

5.3.2 Travaux de recherche en géomatique décisionnelle mo-bile

Outre les développements futurs planifiés pour les projets GeoKettle et GeoMon-drian, et qui seront réalisés par l’équipe GeoSOA du professeur Thierry Badard, lesrésultats de ce projet de maîtrise viendront alimenter de nouveaux travaux de recherche.

La prochaine étape dans le processus de recherche enclenché sera le développementd’applications mobiles pouvant exploiter le service Web de constitution de mini-cubes.


Le projet de doctorat de Belko Diallo, intitulé « Géo-décision en mobilité : Probléma-tique de conception et de mise en œuvre d’applications géo-décisionnelles pour clientsmobiles », permettra d’aborder les problèmes reliés au design des interfaces graphiquespour applications géo-décisionnelles (SOLAP, tableaux de bord et autres outils de visua-lisation de données décisionnelles) adaptées aux appareils mobiles, et visera à apporterdes solutions concrètes pour concevoir et réaliser ces applications mobiles.

Tel qu’il a été expliqué dans l’introduction (cf. 1.1), le contexte de ce projet demaîtrise concerne la diffusion de l’information décisionnelle depuis les entrepôts dedonnées vers les appareils mobiles. Le chemin inverse, soit tirer profit de l’informationde localisation des utilisateurs mobiles pour enrichir les entrepôts de données, constitueune problématique de recherche intéressante. L’alimentation en temps réel des entrepôtsavec ces données spatiales pourrait faire appel à de nombreuses technologies novatrices,par exemple les entrepôts de données et ETL temps réel [Kimball et Caserta, 2004] ainsique les requêtes sur des flux de données continus (Streaming SQL ou autres langagesd’interrogation de flux [Abadi et al., 2003]).

L’informatique mobile est une cible mouvante : entre le début et la fin de ce projetde recherche, de nombreuses innovations technologiques sont venues enrichir l’offre quiexiste dans ce domaine. Mentionnons notamment la mise en marché du Apple iPhone,téléphone mobile offrant de nouvelles méthodes d’entrées (écran tactile multi-doigts,accéléromètre à trois axes) et un navigateur Web moderne capable de supporter lesapplications de type « Ajax ». Tout indique que les progrès en informatique mobilevont continuer au même rythme, créant ainsi des opportunités pour le développementd’applications de plus en plus riches en fonctionnalités, et trouvant leur place dans unmarché en pleine croissance, dû à la multiplication des appareils mobiles et de leuradoption par les consommateurs.

Bibliographie

Abadi, D. J., D. Carney, U. Çetintemel, M. Cherniack, C. Convey, S. Lee, M. Stone-braker, N. Tatbul et S. Zdonik. 2003, «Aurora : a new model and architecture fordata stream management», The VLDB Journal, vol. 12, no 2, pp. 120–139, ISSN1066-8888.

Adamson, C. 2006, Mastering Data Warehouse Aggregates : Solutions for Star Schema

Performance, Wiley Publishing, Inc., ISBN 0471777099.

Al-bar, A. 2001, «A Survey of Adaptive Applications in Mobile Computing», dans

ICDCSW ’01 : Proceedings of the 21st International Conference on Distributed Com-

puting Systems, IEEE Computer Society, Washington, DC, USA, ISBN 0-7695-1080-9, pp. 246–251.

Badard, T., Y. Bédard, F. Hubert, E. Bernier et E. Dubé. 2008, «Web services-orientedarchitectures for mobile SOLAP applications», International Journal of Web Engi-

neering and Technology (IJWET).

Badard, T. et A. Braun. 2003, «OXYGENE — D’une plate-forme interopérable audéploiement de services web géographiques», Revue internationale de géomatique,vol. 3, no 13, pp. 411–430.

Barshan, B. et H. F. Durrant-Whyte. 1993, «An Inertial Navigation System for a Mo-bile Robot», dans Proceedings of the 1993 IEEE/RSJ International Conference on

Intelligent Robots and Systems, Yokohama, Japan, pp. 2243–2248.

Bédard, Y. 2007, «Chaire de recherche industrielle en bases de données géospatialesdécisionnelles», http://mdspatialdb.chair.scg.ulaval.ca.

Bédard, Y. et E. Bernier. 2002, «Supporting Multiple Representations with SpatialView Management and the Concept of “VUEL”», dans Joint Workshop on Multi-

Scale Representation of Spatial Data, International Society for Photogrammetry and

Remote Sensing (ISPRS) WG IV/3. ICA. Com. On Map Generalization, Ottawa,Canada.


Bibliographie 152

Bédard, Y. et J. Han. 2008, «Fundamentals of spatial data warehousing for geogra-phic knowledge discovery», dans Geographic Data Mining and Knowledge Discovery,

2nd edition, H. J. Miller et J. Han, chap. 3, Research Monographs in GeographicInformation Systems, Taylor & Francis.

Bédard, Y., M.-J. Proulx et S. Rivest. 2005, «Enrichissement du OLAP pour l’analysegéographique : exemples de réalisation et différentes possibilités technologiques», Re-

vue des Nouvelles Technologies de l’Information — Entrepôts de données et l’Analyse

en ligne.

Bédard, Y., M.-J. Proulx et S. Rivest. 2006, «« Notions de modélisation multidi-mensionnelle (conceptuelle) », notes du cours « Notions avancées de bases de don-nées SIG (SCG-66124) »», http://sirs.scg.ulaval.ca/YvanBedard/enseigne/

note66124.htm.

Bédard, Y., S. Rivest et M.-J. Proulx. 2007, «Spatial On-Line Analytical Processing(SOLAP) : Concepts, Architectures and Solutions from a Geomatics EngineeringPerspective», dans Data Warehouses and OLAP : Concepts, Architectures and Solu-

tions, R. Wrembel et C. Koncilia, chap. 13, IRM Press (Idea Group), pp. 298–319.

Box, D., D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. F. Nielsen,S. Thatte et D. Winer. 2000, «Simple Object Access Protocol (SOAP) 1.1», spé-cification technique, World Wide Web Consortium. http://www.w3.org/TR/2000/

NOTE-SOAP-20000508/.


Christensen, E., F. Curbera, G. Meredith et S. Weerawarana. 2001, «Web Services Des-cription Language (WSDL) 1.1», spécification technique, World Wide Web Consor-tium. http://www.w3.org/TR/wsdl.

Clark, J. 1999, «XSL Transformations (XSLT)», spécification technique, World WideWeb Consortium. http://www.w3.org/TR/xslt.

Codd, E. F., S. B. Codd et C. T. Salley. 1993, «Providing OLAP to users-analysts : anIT mandate», white paper, Hyperion Solution Corporation.

Coulouris, G., J. Dollimore et T. Kindberg. 2001, Distributed systems (3rd ed.) :

concepts and design, Addison-Wesley Longman Publishing Co., Inc., Boston, MA,USA, ISBN 0-201-61918-0, 772 pp..

Cowan, J. et R. Tobin. 2004, «XML Information Set (Second Edition)», spécificationtechnique, World Wide Web Consortium. http://www.w3.org/TR/xml-infoset/.





http://www.w3.org/TR/wsdl

http://www.w3.org/TR/xslt

http://www.w3.org/TR/xml-infoset/

Bibliographie 153

Cuzzocrea, A., F. Furfaro et D. Saccà. 2003, «Hand-OLAP : A System for DeliveringOLAP Services on Handheld Devices», dans ISADS ’03 : Proceedings of the The Sixth

International Symposium on Autonomous Decentralized Systems, IEEE ComputerSociety, Washington, DC, USA, ISBN 0-7695-1876-1, p. 80.

Declercq, C. 2008, Conception et développement d’un service web de mise à jour en

temps réel de cubes SOLAP, mémoire, Université Laval, Québec, Canada.

Douglas, D. H. et T. K. Peucker. 1973, «Algorithms for the reduction of the number ofpoints required to represent a line or its caricature», Cartographica : The International

Journal for Geographic Information and Geovisualization, vol. 10, no 2, pp. 112–122.

Dubé, E., T. Badard et Y. Bédard. 2007, «Service Web de constitution en temps réel demini-cubes SOLAP pour clients mobiles : une architecture orientée services pour l’uti-lisation mobile des données géo-décisionnelles», dans SAGEO 2007, Rencontres in-

ternationales Géomatique et territoire (CD-ROM), Clermont-Ferrand, France, ISBN978-2-85710-078-2.

Dubé, E., T. Badard et Y. Bédard. 2008, «An interoperable XML encoding for theexchange of Spatial OLAP data cubes in SOA environments», dans 31st International

Convention MIPRO on Business Intelligence Systems (miproBIS), Opatija, Croatie.

Duda, I., M. Aleksy et T. Butter. 2005, «Architectures for Mobile Device Integrationinto Service-Oriented Architectures», dans Fourth International Conference on Mo-

bile Business (ICBM2005), Sydney, Australia, pp. 193–198.

Fallside, D. C. et P. Walmsley. 2004, «XML Schema Part 0 : Primer (Second Edi-tion)», spécification technique, World Wide Web Consortium. http://www.w3.org/

TR/xmlschema-0/.

Fielding, R. T. 2000, Architectural styles and the design of network-based software ar-

chitectures, thèse, University of California, Irvine. Chair-Richard N. Taylor.

Franklin, C. 1992, «An introduction to geographic information systems : linking mapsto databases», Database, vol. 15, no 2, pp. 12–21, ISSN 0162-4105.

Grenier, E. 2007, «Élaboration d’une approche d’agrégation de données géospatialespour le peuplement de cubes géospatiaux», Examen pré-doctoral, Université Laval.

Han, J., N. Stefanovic et K. Koperski. 1998, «Selective Materialization : An EfficientMethod for Spatial Data Cube Construction», dans Research and Development in

Knowledge Discovery and Data Mining, Second Pacific-Asia Conference, PAKDD’98,X. Wu, K. Ramamohanarao et K. Korb, Melbourne, Australia, pp. 144–158.



Bibliographie 154

Harold, E. R. et S. W. Means. 2004, XML in a Nutshell, Third Edition, O’Reilly Media,Inc., ISBN 0596007647, 600 pp..

Hümmer, W., A. Bauer et G. Harde. 2003, «XCube : XML for data warehouses»,dans DOLAP ’03 : Proceedings of the 6th ACM international workshop on Data

warehousing and OLAP, ACM, New York, NY, USA, ISBN 1-58113-727-3, pp. 33–40.

ISO/TC211. 2001, «Geographic Information - Spatial Schema (ISO 19107) (OGC Topic1 working draft Version 5)», spécification technique, ISO Technical Committee 211.


ITU-T. 2005, «Information technology — Generic applications of ASN.1 : Fast infoset»,spécification technique, International Telecommunication Union (ITU).

KHEOPS Technologies. 2005, «JMap Spatial OLAP», white paper. http://www.

kheops-tech.com/en/jmap/doc/WP_JMap_SOLAP.pdf.

Kimball, R. et J. Caserta. 2004, The Data Warehouse ETL Toolkit, John Wiley & Sons,ISBN 0764567578, 528 pp..

Kimball, R. et M. Ross. 2002, The Data Warehouse Toolkit : The Complete Guide to


Kolodziej, K. W. et J. Hjelm. 2006, Local Positioning Systems : LBS Applications and

Services, CRC Press, ISBN 0849333490, 488 pp..

Levesque, M.-A., Y. Bédard, M. Gervais et R. Devillers. 2007, «Towards managing therisks of data misuse for spatial datacubes», dans Proceedings of the 5th International

Symposium on Spatial Data Quality, Enschede, Netherlands.

Maniatis, A. S. 2004, «The case for mobile OLAP», dans EDBT Workshops, Lecture

Notes in Computer Science, vol. 3268, W. Lindner, M. Mesiti, C. Türker, Y. Tzitzikaset A. Vakali, Springer, pp. 405–414. http://dblp.uni-trier.de/db/conf/edbtw/

edbtw2004.html#Maniatis04.

McHugh, R. 2008, Analyse du potentiel de l’analyse matricielle pour optimiser la créa-

tion de cubes spatio-temporels, mémoire, Université Laval, Québec, Canada.

Microsoft et Hyperion. 2002, «XML for Analysis Specification, version 1.1», spécificationtechnique, Microsoft Corporation.



http://dblp.uni-trier.de/db/conf/edbtw/edbtw2004.html#Maniatis04

http://dblp.uni-trier.de/db/conf/edbtw/edbtw2004.html#Maniatis04

Bibliographie 155

Microsoft Corporation. 2007a, «Multidimensional Expressions (MDX) Reference»,http://msdn2.microsoft.com/en-us/library/ms145506.aspx.

Microsoft Corporation. 2007b, «OLE DB for Online Analytical Processing (OLAP),Programmer’s Reference», http://msdn2.microsoft.com/en-us/library/

ms717005.aspx.

Miquel, M., Y. Bédard et A. Brisebois. 2002, «Conception d’entrepôts de données géo-spatiales à partir de sources hétérogènes, exemple d’application en foresterie», Ingé-

nierie des Systèmes d’information, vol. 7, no 3, pp. 89–111.

Mundy, J. et W. Thornthwaite. 2006, The Microsoft Data Warehouse Toolkit : With

SQL Server 2005 and the Microsoft Business Intelligence Toolset, Wiley Publishing,Inc., ISBN 0471267155.

Newcomer, E. 2002, Understanding Web Services : XML, WSDL, SOAP, and UDDI,Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, ISBN 0201750813,332 pp..

Newcomer, E. et G. Lomow. 2004, Understanding SOA with Web Services, Addison-Wesley Professional, ISBN 0321180860, 480 pp..

OGC. 2002, «Web Map Service Implementation Specification, version 1.1.1», spécifica-tion technique, Open Geospatial Consortium.

OGC. 2005a, «OpenGIS Filter Encoding Implementation Specification, version 1.1.0»,spécification technique, Open Geospatial Consortium.

OGC. 2005b, «Web Feature Service Implementation Specification, version 1.1.0», spé-cification technique, Open Geospatial Consortium.

OGC. 2007, «OGC Web Services Common Specification, version 1.1.0 with Corrigen-dum 1», spécification technique, Open Geospatial Consortium.

Ojala, O. 2005, Service Oriented Architecture in Mobile Devices : Protocols and Tools,mémoire, Helsinki University of Technology.

O’Neil, P. et E. O’Neil. 2001, Database : Principles, Programming and Performance,

Second Edition, Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, ISBN1558604383.

Oracle Corporation. 2004, «Web Services and Mobile Interoperability», white paper,Oracle Corporation.




Bibliographie 156

Ort, E. 2005, «Service-Oriented Architecture and Web Services : Concepts, Tech-nologies, and Tools», white paper, Sun Microsystems. http://java.sun.com/

developer/technicalArticles/WebServices/soa2/.

Paelke, V., C. Reimann et W. Rosenbach. 2003, «A visualization design repositoryfor mobile devices», dans AFRIGRAPH ’03 : Proceedings of the 2nd international

conference on Computer graphics, virtual Reality, visualisation and interaction in

Africa, ACM, New York, NY, USA, ISBN 1-58113-643-9, pp. 57–62.

Pendse, N. 2006, «The OLAP Report — OLAP architectures», http://www.

olapreport.com/Architectures.htm.

Pentaho Corporation. 2007, «Pentaho Analysis Services : Mondrian Project», http://

mondrian.pentaho.org.

Pourabbas, E. et M. Rafanelli. 2003, «Hierarchies», dans Multidimensional Databases :

Problems and Solutions, Idea Group, pp. 91–115.

Proulx, M.-J., Y. Bédard, M. Nadeau, P. Gosselin et G. Lebel. 2002, «Géomatique etsanté environnementale : innovations résultant du projet ICEM/SE», dans Géoma-

tique 2002, Montéal, Québec, Canada.

Proulx, M.-J. et S. Rivest. 2005, «Formalisme de modélisation multidimensionnelle etoutil CASE», Support de présentation non publié, Chaire de recherche en base dedonnées géospatiales décisionnelles, Université Laval.

Proulx, M.-J., S. Rivest et Y. Bédard. 2007, «Évaluation des produits commerciauxoffrant des capacités combinées d’analyse multidimensionnelle et de cartographie»,rapport de recherche, Chaire de recherche en base de données géospatiales décision-nelles, Université Laval.

Rafanelli, M. et A. Shoshani. 1990, «STORM : A Statistical Object RepresentationModel», dans Statistical and Scientific Database Management, pp. 14–29.

Reichenbacher, T. 2001, «The World in Your Pocket — Towards a Mobile Cartography»,dans Proceedings of the 20th International Cartographic Conference, Beijing, China.

Rivest, S., Y. Bédard et P. Marchand. 2001, «Toward better support for spatial deci-sion making : defining the characteristics of Spatial On-Line Analytical Processing(SOLAP)», Geomatica, vol. 55, no 4, pp. 539–555.

Rivest, S., Y. Bédard, M.-J. Proulx, M. Nadeau, F. Hubert et J. Pastor. 2005, «SOLAP :Merging Business Intelligence with Geospatial Technology for Interactive Spatio-Temporal Exploration and Analysis of Data», Journal of ISPRS “Advances in spatio-

temporal analysis and representation”, vol. 60, no 1, pp. 17–33.



http://www.olapreport.com/Architectures.htm

http://www.olapreport.com/Architectures.htm



Bibliographie 157

Ruas, A. 1999, Modèle de généralisation de données géographiques à base de contraintes

et d’autonomie, thèse, Université de Marne La Vallée, France.

Ruas, A. et C. Duchêne. 2007, «A Prototype Generalisation System Based on the Multi-Agent System Paradigm», dans Generalisation of Geographic Information : Carto-

graphic Modelling and Applications, W. A. Mackaness, A. Ruas et L. T. Sarjakoski,chap. 14, Elsevier, pp. 269–284.

Sabo, M. N. 2007, Intégration des algorithmes de généralisation et des patrons géo-

métriques pour la création des objets auto-généralisants (SGO) afin d’améliorer la

généralisation cartographique à la volée, thèse, Université Laval, Québec, Canada.

Sabo, M. N., Y. Bédard, E. Bernier et A. Cardenas. 2007, «Methodology for developinga database of geometric patterns to better support on-the-fly map generalization»,dans International Cartographic Conference, Coruna, Espagne.

Salehi, M., Y. Bédard, M. A. Mostafavi et J. Brodeur. 2007, «From Transactional Spa-tial Databases Integrity Constraints to Spatial Data Cubes Integrity Constraints»,dans Proceedings of the 5th International Symposium on Spatial Data Quality, En-schede, Pays-Bas.

Satyanarayanan, M. 1996, «Fundamental challenges in mobile computing», dans PODC

’96 : Proceedings of the fifteenth annual ACM symposium on Principles of distributed

computing, ACM, New York, NY, USA, ISBN 0-89791-800-2, pp. 1–7.

Sboui, T., Y. Bédard, J. Brodeur et T. Badard. 2007, «A Conceptual Framework toSupport Semantic Interoperability of Geospatial Datacubes», dans ER Workshops,pp. 378–387.

Schneider, J. et T. Kamiya. 2008, «Efficient XML Interchange (EXI) Format 1.0, 3rdworking draft», spécification technique, World Wide Web Consortium. http://www.

w3.org/TR/exi/.

Sester, M., L. T. Sarjakoski, L. Harrie, M. Hampe, T. Koivula, T. Sarjakoski, L. Lehto,B. Elias, A.-M. Nivala et H. Stigmar. 2004, «Real-time generalisation and Multiple re-presentation in the GiMoDig mobile service», rapport technique D7.11-D7.2.1, D7.3.1,GiMoDig.

da Silva, J., V. C. Times, R. do Nascimento Fidalgo et R. S. M. de Barros. 2005,«Providing Geographic-Multidimensional Decision Support over the Web», dans AP-

Web, Lecture Notes in Computer Science, vol. 3399, Y. Zhang, K. Tanaka, J. X. Yu,S. Wang et M. Li, Springer, ISBN 3-540-25207-X, pp. 477–488.



Bibliographie 158

Spofford, G., S. Harinath, C. Webb, D. H. Huang et F. Civardi. 2006, MDX Solutions :

with Microsoft SQL Server Analysis Services 2005 and Hyperion Essbase (Second

Edition), Wiley Publishing, Inc., ISBN 0471748080.

Steiniger, S., M. Neun et A. Edwardes. 2006, «Foundations of Location Based Ser-vices — Lesson 1», Notes de cours, GIS Division, Department of Geography,University of Zurich. http://www.geo.unizh.ch/publications/cartouche/lbs_

lecturenotes_steinigeretal2006.pdf.

SVG Working Group. 2003, «Scalable Vector Graphics (SVG) 1.1 Specification», spéci-fication technique, World Wide Web Consortium. http://www.w3.org/TR/SVG11/.

Thomsen, E. 1999, «Symmetry Lost», Intelligent Enterprise Magazine, vol. 2, no 5.http://www.intelligententerprise.com/db_area/archives/1999/993003/

decision.jhtml.

Thomsen, E. 2002, OLAP Solutions : Building Multidimensional Information Systems,John Wiley & Sons, Inc., New York, NY, USA, ISBN 0471400300, 688 pp..

Tian, M., T. Voigt, T. Naumowicz, H. Ritter et J. Schiller. 2004, «Performance Conside-rations for Mobile Web Services», Computer Communications Journal, vol. 27, no 11,pp. 1097–1105.

Wang, S., J. Min et B. K. Yi. 2008, «Location Based Services for Mobiles : Technologiesand Standards», Support de présentation, en ligne, http://to.swang.googlepages.

com/ICC2008LBSforMobilessimplifiedR2.pdf.

Wikipedia. 2008, «Apple Newton — Wikipedia, The Free Encyclopedia», Ressource enligne ; accédé le 25 juin 2008, http://en.wikipedia.org/wiki/Apple_Newton.

World Wide Web Consortium. 2006, «Extensible Markup Language (XML) 1.0 (FourthEdition)», spécification technique, World Wide Web Consortium. http://www.w3.

org/TR/REC-xml/.

http://www.geo.unizh.ch/ publications/cartouche/ lbs_lecturenotes_steinigeretal2006.pdf

http://www.geo.unizh.ch/ publications/cartouche/ lbs_lecturenotes_steinigeretal2006.pdf

http://www.w3.org/TR/SVG11/

http://www.intelligententerprise.com/ db_area/archives/1999/ 993003/decision.jhtml

http://www.intelligententerprise.com/ db_area/archives/1999/ 993003/decision.jhtml

http://to.swang.googlepages.com/ICC2008LBSforMobilessimplifiedR2.pdf

http://to.swang.googlepages.com/ICC2008LBSforMobilessimplifiedR2.pdf

http://en.wikipedia.org/wiki/Apple_Newton



Annexe A

Listages et exemples

A.1 Exemples WSDL et SOAP

Listage A.1 – Exemple de document WSDL<?xml version="1.0" encoding="UTF -8"?>

<definitions name="ServiceDepartement "

targetNamespace ="http: //www.scg.ulaval.ca/wsdl/exemples/servicedept.wsdl"

xmlns="http: // schemas.xmlsoap.org/wsdl/"

xmlns:soap="http: // schemas.xmlsoap.org/wsdl/soap/"

xmlns:tns="http: //www.scg.ulaval.ca/wsdl/exemples/servicedept.wsdl"

xmlns:xsd="http: //www.w3.org /2001/ XMLSchema">

<message name="GetNomCoursRequest ">

<part name="sigle" type="xsd:string"/>

</message >

<message name="GetNomCoursResponse ">

<part name="nom" type="xsd:string"/>

</message >

<portType name="GetNomCours_PortType">

<operation name="getNomCours">

<input message="tns:GetNomCoursRequest "/>

<output message="tns:GetNomCoursResponse "/>

</operation >

</portType >

<binding name="GetNomCours_Binding " type="tns:GetNomCours_PortType ">

<soap:binding style="rpc"

transport="http: // schemas.xmlsoap.org/soap/http"/>

<operation name="getNomCours">

<soap:operation soapAction="getNomCours"/>

<input >

<soap:body

encodingStyle ="http: // schemas.xmlsoap.org/soap/encoding/"

namespace="urn:exemples:ulaval -Departements"

use="encoded"/>

</input >

<output >

<soap:body

encodingStyle ="http: // schemas.xmlsoap.org/soap/encoding/"

namespace="urn:exemples:ulaval -Departements"

Annexe A. Listages et exemples 160

use="encoded"/>

</output >

</operation >

</binding >

<service name="Service_Departement ">

<documentation >Fichier WSDL pour Service_Departement </ documentation >

<port binding="tns:GetNomCours_Binding " name="GetNomCours_Port">

<soap:address

location="http: //www.scg.ulaval.ca:8080/soap/servlet/rpcrouter"/>

</port>

</service >

</definitions >

Listage A.2 – Exemple de requête SOAP<?xml version=’1.0’ encoding=’UTF -8’?>

<SOAP -ENV:Envelope

xmlns:SOAP -ENV="http: // schemas.xmlsoap.org/soap/envelope/"



<SOAP -ENV:Body >

<ns1:getNomCours

xmlns:ns1="urn:exemples:ulaval -Departements"

SOAP -ENV:encodingStyle="http: // schemas.xmlsoap.org/soap/encoding/">

<sigle xsi:type="xsd:string">SCG -65825 </sigle >

</ns1:getNomCours >

</SOAP -ENV:Body >

</SOAP -ENV:Envelope >

Listage A.3 – Exemple de réponse SOAP<?xml version=’1.0’ encoding=’UTF -8’?>

<SOAP -ENV:Envelope

xmlns:SOAP -ENV="http: // schemas.xmlsoap.org/soap/envelope/"



<SOAP -ENV:Body >

<ns1:getNomCoursResponse

xmlns:ns1="urn:exemples:ulaval -Departements"

SOAP -ENV:encodingStyle="http: // schemas.xmlsoap.org/soap/encoding/">

<return xsi:type="xsd:string">

Méthodes de recherche en géomatique

</return >

</ns1:getNomCoursResponse >

</SOAP -ENV:Body >

</SOAP -ENV:Envelope >

A.2 Définitions XML Schema et WSDL

A.2.1 Schéma de l’encodage XML pour cubes SOLAP

Listage A.4 – Définition XML Schema de l’encodage XML pour cubes SOLAP


<?xml version="1.0" encoding="UTF -8"?>



<xs:schema xmlns:xs="http: //www.w3.org /2001/ XMLSchema"

targetNamespace ="http: // geosoa.scg.ulaval.ca/GeoCubeML"

xmlns="http: // geosoa.scg.ulaval.ca/GeoCubeML"

elementFormDefault ="qualified">

<xs:element name="cubeSchema" type="cubeSchemaType" />

<xs:element name="cubeMembers" type="cubeMembersType " />

<xs:element name="cubeCells" type="cubeCellsType " />



<xs:complexType name="cubeSchemaType">

<xs:sequence >

<xs:element name="include" type="includeType" minOccurs="0"

maxOccurs="unbounded" />

<xs:element name="cube" type="cubeType" minOccurs="0"


<xs:element name="sharedDimensions" type="sharedDimensionsType"

minOccurs="0" maxOccurs="1" />

</xs:sequence >

</xs:complexType >

<xs:complexType name="cubeType">

<xs:sequence >

<xs:element name="dimension" type="dimensionType " minOccurs="1"


</xs:sequence >

<xs:attribute name="name" type="xs:string" use="required" />

</xs:complexType >

<xs:complexType name="dimensionType ">

<xs:choice >

<xs:element name="dimensionDef" type="dimensionDefType" />

<xs:element name="dimensionUsage" type="dimensionUsageType " />

</xs:choice >


<xs:attribute name="isMeasure" type="xs:boolean" default="false" />

</xs:complexType >

<xs:complexType name="dimensionUsageType ">

<xs:attribute name="defName" type="xs:string" use="required" />

</xs:complexType >

<xs:complexType name="sharedDimensionsType">

<xs:sequence >

<xs:element name="dimensionDef" type="dimensionDefType" minOccurs="1"


</xs:sequence >

</xs:complexType >

<xs:complexType name="dimensionDefType">

<xs:sequence >

<xs:element name="hierarchy" type="hierarchyType " minOccurs="0"



<xs:element name="level" type="levelType" minOccurs="1"


</xs:sequence >

<xs:attribute name="defName" type="xs:string" />

</xs:complexType >

<xs:complexType name="hierarchyType ">

<xs:attribute name="name" type="xs:string" />

<xs:attribute name="default" type="xs:boolean" />

</xs:complexType >

<xs:complexType name="levelType">

<xs:sequence >

<xs:element name="inHierarchy" type="inHierarchyType " minOccurs="0"


<xs:element name="rollupTo" type="rollupToType" minOccurs="0"


<xs:element name="property" type="propertyType" minOccurs="0"


</xs:sequence >


<xs:attribute name="isAll" type="xs:boolean" default="false" />

</xs:complexType >

<xs:complexType name="inHierarchyType ">

<xs:attribute name="hierarchy" type="xs:string" use="required" />

</xs:complexType >

<xs:complexType name="rollupToType">

<xs:attribute name="level" type="xs:string" use="required" />



</xs:complexType >

<xs:complexType name="propertyType">

<xs:sequence >

<xs:element ref="contentType" minOccurs="1" maxOccurs="1" />

</xs:sequence >


</xs:complexType >



<xs:complexType name="cubeMembersType ">

<xs:sequence >



<xs:element name="cubeRef" type="cubeRefType" minOccurs="0"


</xs:sequence >

</xs:complexType >

<xs:complexType name="cubeRefType">

<xs:sequence >

<xs:element name="dimensionRef" type="dimensionRefType" minOccurs="0"


</xs:sequence >


</xs:complexType >

<xs:complexType name="dimensionRefType">

<xs:sequence >




<xs:element name="levelRef" type="levelRefType" minOccurs="0"


</xs:sequence >


</xs:complexType >



<xs:complexType name="levelRefType">

<xs:sequence >

<xs:element name="member" type="memberType" minOccurs="0"


</xs:sequence >


</xs:complexType >

<xs:complexType name="memberType">

<xs:sequence >

<xs:element name="rollupTo" type="memberRollupToType " minOccurs="0"


<xs:element name="propertyValue " type="propertyValueType " minOccurs="0"


</xs:sequence >


<xs:attribute name="isAll" type="xs:boolean" />

</xs:complexType >

<xs:complexType name="memberRollupToType ">

<xs:attribute name="member" type="xs:string" use="required" />

<xs:attribute name="level" type="xs:string" />

<xs:attribute name="weight" type="xs:double" />

</xs:complexType >

<xs:complexType name="propertyValueType" mixed="true">

<xs:sequence >



<xs:any minOccurs="0" maxOccurs="unbounded" processContents ="skip" />

</xs:sequence >

<xs:attribute name="property" type="xs:string" use="required" />

</xs:complexType >



<xs:complexType name="cubeCellsType ">

<xs:sequence >



<xs:element name="cubeRef" type="cubeCellsCubeRefType " minOccurs="0"


</xs:sequence >

</xs:complexType >


<xs:complexType name="cubeCellsCubeRefType">

<xs:sequence >

<xs:element name="slicerMembers " type="slicerMembersType " minOccurs="0"

maxOccurs="1" />

<xs:element name="cells" type="cellsType" minOccurs="0" maxOccurs="1" />

</xs:sequence >


</xs:complexType >

<xs:complexType name="slicerMembersType">

<xs:sequence >

<xs:element name="tuple" type="tupleType" minOccurs="1" maxOccurs="1" />

</xs:sequence >

</xs:complexType >

<xs:complexType name="cellsType">

<xs:sequence >

<xs:element name="cell" type="cellType" minOccurs="0"


</xs:sequence >

</xs:complexType >

<xs:complexType name="cellType">

<xs:sequence >

<xs:element name="tuple" type="tupleType" minOccurs="1" maxOccurs="1" />

<xs:element name="cellValue" type="cellValueType " minOccurs="1"

maxOccurs="1" />

</xs:sequence >

</xs:complexType >

<xs:complexType name="tupleType">

<xs:sequence >

<xs:element name="memberRef" type="memberRefType " minOccurs="1"


</xs:sequence >

</xs:complexType >

<xs:complexType name="memberRefType ">

<xs:attribute name="dimension" type="xs:string" use="required" />



<xs:attribute name="level" type="xs:string" use="required" />

<xs:attribute name="member" type="xs:string" use="required" />

</xs:complexType >

<xs:complexType name="cellValueType " mixed="true">

<xs:sequence >



<xs:any minOccurs="0" maxOccurs="unbounded" processContents ="skip" />

</xs:sequence >

</xs:complexType >





<xs:complexType name="includeType">

<xs:attribute name="fileLocation" type="xs:anyURI" />

</xs:complexType >



<xs:complexType name="contentTypeType ">



<xs:attribute name="type" type="xs:QName" />



<xs:attribute name="ref" type="xs:QName" />



<xs:attribute name="minOccurs" type="xs:string" />



<xs:attribute name="maxOccurs" type="xs:string" />

</xs:complexType >

<xs:element name="contentType" type="contentTypeType " />



<xs:complexType name="aggregatorType">

<xs:sequence >



<xs:element ref="abstractAggregateOperator " minOccurs ="1" maxOccurs="1" />

</xs:sequence >



<xs:attribute name="dimension" type="xs:string" />

</xs:complexType >



<xs:element name="aggregator" type="aggregatorType" />



<xs:element name="abstractAggregateOperator "

type="abstractAggregateOperatorType " abstract="true" />

<xs:complexType name="abstractAggregateOperatorType " abstract="true" />






<xs:element name="sum" type="sumType"

substitutionGroup="abstractAggregateOperator " />

<xs:complexType name="sumType">

<xs:complexContent >

<xs:extension base="abstractAggregateOperatorType " />

</xs:complexContent >

</xs:complexType >



<xs:element name="avg" type="avgType"


<xs:complexType name="avgType">




</xs:complexType >



<xs:element name="min" type="minType"


<xs:complexType name="minType">




</xs:complexType >



<xs:element name="max" type="maxType"


<xs:complexType name="maxType">




</xs:complexType >



<xs:element name="strcat" type="strcatType"


<xs:complexType name="strcatType">




</xs:complexType >



<xs:element name="geomUnion" type="geomUnionType "


<xs:complexType name="geomUnionType ">




</xs:complexType >

</xs:schema >


A.2.2 Contrat de service du service Web de constitution demini-cubes

Listage A.5 – Contrat de service WSDL<?xml version="1.0" encoding="UTF -8"?>



<definitions xmlns:apachesoap="http: //xml.apache.org/xml -soap"

targetNamespace ="http: // geosoa.scg.ulaval.ca/MinicubeWS"



xmlns:wsdlsoap="http: // schemas.xmlsoap.org/wsdl/soap/"

xmlns:xsd="http: //www.w3.org /2001/ XMLSchema"

xmlns="http: // schemas.xmlsoap.org/wsdl/">



<types >

<schema targetNamespace ="http: // geosoa.scg.ulaval.ca/MinicubeWS"


xmlns="http: //www.w3.org /2001/ XMLSchema" elementFormDefault ="qualified">

<import namespace="http: // geosoa.scg.ulaval.ca/GeoCubeML"

schemaLocation="CubeSchema.xsd" />

<include schemaLocation="GetMembers.xsd" />

<include schemaLocation="GetCells.xsd" />

<element name="GetCapabilitiesRequest ">

<complexType />

</element >

<element name="GetCapabilitiesResponse ">

<complexType >

<sequence >

<element name="ServiceIdentification ">

<complexType >

<sequence >

<element name="ServiceType" type="xsd:string" />

<element name="ServiceTypeVersion " type="xsd:string" />

<element name="Title" type="xsd:string" />

<element name="Abstract" type="xsd:string" />



</sequence >

</complexType >

</element >

<element name="availableCubes">

<complexType >

<sequence >

<element name="availableCube " minOccurs="0"

maxOccurs="unbounded">

<complexType >

<attribute name="name" type="xsd:string" use="required " />


</complexType >

</element >

</sequence >

</complexType >

</element >

</sequence >

</complexType >

</element >

<element name="DescribeSchemaRequest ">

<complexType >

<sequence >

<element name="cubeName" type="xsd:string" minOccurs="1"

maxOccurs="1" />

</sequence >

</complexType >

</element >

<element name="DescribeSchemaResponse ">

<complexType >

<sequence >

<element name="cubeSchema" type="gcml:cubeSchemaType " />

</sequence >

</complexType >

</element >









<element name="GetCubeRequest">

<complexType >

<sequence >

<element ref="mcws:GetCellsRequest" minOccurs="1" maxOccurs="1" />

</sequence >

</complexType >

</element >

<element name="GetCubeResponse ">

<complexType >

<sequence >

<element ref="gcml:cubeSchema " minOccurs="1" maxOccurs ="1" />

<element ref="gcml:cubeMembers" minOccurs="1" maxOccurs="1" />

<element ref="gcml:cubeCells" minOccurs="1" maxOccurs="1" />

</sequence >

</complexType >

</element >

</schema >

</types >





<message name="GetCapabilitiesRequestMessage ">

<part name="input" element="mcws:GetCapabilitiesRequest " />

</message >


<message name="GetCapabilitiesResponseMessage ">

<part name="output" element="mcws:GetCapabilitiesResponse " />

</message >



<message name="DescribeSchemaRequestMessage ">

<part name="input" element="mcws:DescribeSchemaRequest" />

</message >

<message name="DescribeSchemaResponseMessage ">

<part name="output" element="mcws:DescribeSchemaResponse " />

</message >



<message name="GetMembersRequestMessage ">

<part name="input" element="mcws:GetMembersRequest " />

</message >

<message name="GetMembersResponseMessage ">

<part name="output" element="mcws:GetMembersResponse " />

</message >



<message name="GetCellsRequestMessage ">

<part name="input" element="mcws:GetCellsRequest" />

</message >

<message name="GetCellsResponseMessage ">

<part name="output" element="mcws:GetCellsResponse " />

</message >



<message name="GetCubeRequestMessage ">

<part name="input" element="mcws:GetCubeRequest " />

</message >

<message name="GetCubeResponseMessage ">

<part name="output" element="mcws:GetCubeResponse" />

</message >



<portType name="MinicubeWSPortType ">

<operation name="GetCapabilities " parameterOrder="input">

<input name="GetCapabilitiesRequestMessage "

message="mcws:GetCapabilitiesRequestMessage " />

<output name="GetCapabilitiesResponseMessage "

message="mcws:GetCapabilitiesResponseMessage " />

</operation >

<operation name="DescribeSchema" parameterOrder="input">

<input name="DescribeSchemaRequestMessage "

message="mcws:DescribeSchemaRequestMessage " />

<output name="DescribeSchemaResponseMessage "

message="mcws:DescribeSchemaResponseMessage " />

</operation >

<operation name="GetMembers" parameterOrder="input">

<input name="GetMembersRequestMessage "

message="mcws:GetMembersRequestMessage " />

<output name="GetMembersResponseMessage "

message="mcws:GetMembersResponseMessage " />


</operation >

<operation name="GetCells" parameterOrder="input">

<input name="GetCellsRequestMessage "

message="mcws:GetCellsRequestMessage " />

<output name="GetCellsResponseMessage "

message="mcws:GetCellsResponseMessage " />

</operation >

<operation name="GetCube" parameterOrder="input">

<input name="GetCubeRequestMessage " message="mcws:GetCubeRequestMessage" />

<output name="GetCubeResponseMessage "

message="mcws:GetCubeResponseMessage " />

</operation >

</portType >



<binding name="MinicubeWSBinding " type="mcws:MinicubeWSPortType ">

<wsdlsoap:binding style="document"

transport="http: // schemas.xmlsoap.org/soap/http" />

<operation name="GetCapabilities ">

<wsdlsoap:operation soapAction="GetCapabilities " />

<input >

<wsdlsoap:body use="literal" />

</input >

<output >


</output >

</operation >

<operation name="DescribeSchema">

<wsdlsoap:operation soapAction="DescribeSchema" />

<input >


</input >

<output >


</output >

</operation >

<operation name="GetMembers">

<wsdlsoap:operation soapAction="GetMembers" />

<input >


</input >

<output >


</output >

</operation >

<operation name="GetCells">

<wsdlsoap:operation soapAction="GetCells" />

<input >


</input >

<output >


</output >

</operation >


<operation name="GetCube">

<wsdlsoap:operation soapAction="GetCube" />

<input >


</input >

<output >


</output >

</operation >

</binding >



<service name="MinicubeWS">

<port binding="mcws:MinicubeWSBinding " name="MinicubeWS">

<wsdlsoap:address

location="http: // localhost:8088/axis2/services/MinicubeWS/" />

</port>

</service >

</definitions >

Listage A.6 – Définition XML Schema pour l’opération GetMembers (référencé par lecontrat de service WSDL)<?xml version="1.0" encoding="UTF -8"?>



<xsd:schema xmlns:xsd="http: //www.w3.org /2001/ XMLSchema"




xmlns:ogc="http: //www.opengis.net/ogc"

xmlns="http: // geosoa.scg.ulaval.ca/MinicubeWS"


<xsd:import namespace="http: // geosoa.scg.ulaval.ca/GeoCubeML"


<xsd:import namespace="http: //www.opengis.net/ogc"

schemaLocation="OpenGIS.net/filter /1.0.0/ filter.xsd" />

<xsd:element name="GetMembersRequest ">

<xsd:complexType >

<xsd:sequence >

<xsd:element name="cubeSelection " minOccurs="1" maxOccurs="1">

<xsd:complexType >

<xsd:sequence >

<xsd:element name="dimensionSelection " minOccurs="1"


<xsd:complexType >

<xsd:sequence >



<xsd:element name="hierarchySelection " minOccurs="0"


maxOccurs="1">

<xsd:complexType >

<xsd:attribute name="name" type="xsd:string"

use="required" />

</xsd:complexType >

</xsd:element >

<xsd:element name="levelSelection" minOccurs="0"

maxOccurs="1">

<xsd:complexType >

<xsd:attribute name="name" type="xsd:string"

use="required" />



<xsd:attribute name="include" type="xsd:string" />

</xsd:complexType >

</xsd:element >



<xsd:element name="memberSelection " minOccurs="0"


<xsd:complexType >

<xsd:sequence >

<xsd:element name="memberSelectors " minOccurs="0"

maxOccurs="1">

<xsd:complexType >

<xsd:sequence >



<xsd:element ref="mcws:memberSelector "


</xsd:sequence >

</xsd:complexType >

</xsd:element >

<xsd:element name="memberFilters " minOccurs="0"

maxOccurs="1">

<xsd:complexType >

<xsd:sequence >



<xsd:element ref="mcws:memberFilter "


</xsd:sequence >

</xsd:complexType >

</xsd:element >

</xsd:sequence >

</xsd:complexType >

</xsd:element >

</xsd:sequence >

<xsd:attribute name="name" type="xsd:string" use="required" />

</xsd:complexType >

</xsd:element >

</xsd:sequence >


</xsd:complexType >

</xsd:element >

</xsd:sequence >

</xsd:complexType >

</xsd:element >



<xsd:element name="memberSelector" type="mcws:memberSelectorType "

abstract="true" />

<xsd:complexType name="memberSelectorType " abstract="true" />


<xsd:element name="selectAllMembers" substitutionGroup ="memberSelector">

<xsd:complexType >

<xsd:complexContent >

<xsd:extension base="mcws:memberSelectorType " />

</xsd:complexContent >

</xsd:complexType >

</xsd:element >

<xsd:element name="selectMembersByName " type="mcws:selectMembersByNameType "

substitutionGroup="memberSelector" />

<xsd:complexType name="selectMembersByNameType ">


<xsd:extension base="mcws:memberSelectorType ">

<xsd:sequence >

<xsd:element name="member" minOccurs="1" maxOccurs="unbounded">

<xsd:complexType >


</xsd:complexType >

</xsd:element >

</xsd:sequence >

</xsd:extension >


</xsd:complexType >

<xsd:element name="selectMembersByProperty "

type="mcws:selectMembersByPropertyType " substitutionGroup ="memberSelector" />

<xsd:complexType name="selectMembersByPropertyType ">


<xsd:extension base="mcws:memberSelectorType ">

<xsd:sequence >

<xsd:element ref="mcws:propertySelector " minOccurs="0"


</xsd:sequence >

<xsd:attribute name="property" type="xsd:string" use=" required" />

</xsd:extension >


</xsd:complexType >



<xsd:element name="propertySelector" type="mcws:propertySelectorType "

abstract="true" />

<xsd:complexType name="propertySelectorType" abstract ="true" />

<xsd:element name="GMLPropertySelector " type="mcws:GMLPropertySelectorType "

substitutionGroup="propertySelector" />

<xsd:complexType name="GMLPropertySelectorType ">


<xsd:extension base="mcws:propertySelectorType ">

<xsd:sequence >

<xsd:element ref="ogc:Filter" minOccurs="1" maxOccurs="1" />

</xsd:sequence >

<xsd:attribute name="GMLPropertyName " type="xsd:string" use="required" />

</xsd:extension >


</xsd:complexType >

<xsd:element name="valuePropertySelector "

type="mcws:valuePropertySelectorType " substitutionGroup="propertySelector" />

<xsd:complexType name="valuePropertySelectorType ">



<xsd:extension base="mcws:propertySelectorType ">



<xsd:attribute name="value" type="xsd:string" use="required" />

</xsd:extension >


</xsd:complexType >



<xsd:element name="memberFilter" type="mcws:memberFilterType " abstract="true" />

<xsd:complexType name="memberFilterType" abstract="true" />

<xsd:element name="identityMemberFilter" substitutionGroup ="memberFilter">

<xsd:complexType >


<xsd:extension base="mcws:memberFilterType " />


</xsd:complexType >

</xsd:element >

<xsd:element name="propertyMemberFilter" substitutionGroup ="memberFilter">

<xsd:complexType >


<xsd:extension base="mcws:memberFilterType ">

<xsd:sequence >

<xsd:element ref="mcws:propertyFilter " minOccurs="0"


</xsd:sequence >

<xsd:attribute name="property" type="xsd:string" use=" required" />

</xsd:extension >


</xsd:complexType >

</xsd:element >



<xsd:element name="propertyFilter" type="mcws:propertyFilterType "

abstract="true" />

<xsd:complexType name="propertyFilterType " abstract="true" />

<xsd:element name="identityPropertyFilter "

substitutionGroup="propertyFilter">

<xsd:complexType >


<xsd:extension base="mcws:propertyFilterType " />


</xsd:complexType >

</xsd:element >

<xsd:element name="douglasPeuckerPropertyFilter "

substitutionGroup="propertyFilter">

<xsd:complexType >


<xsd:extension base="mcws:propertyFilterType ">

<xsd:attribute name="tolerance" type="xsd:float" use=" required" />

</xsd:extension >


</xsd:complexType >

</xsd:element >




<xsd:element name="GetMembersResponse ">

<xsd:complexType >

<xsd:sequence >

<xsd:element ref="gcml:cubeMembers" minOccurs="1" maxOccurs="1" />

</xsd:sequence >

</xsd:complexType >

</xsd:element >

</xsd:schema >

Listage A.7 – Définition XML Schema pour l’opération GetCells (référencé par le contratde service WSDL)<?xml version="1.0" encoding="UTF -8"?>



<xsd:schema xmlns:xsd="http: //www.w3.org /2001/ XMLSchema"




xmlns="http: // geosoa.scg.ulaval.ca/MinicubeWS"


<xsd:import namespace="http: // geosoa.scg.ulaval.ca/GeoCubeML"


<xsd:element name="GetCellsRequest ">

<xsd:complexType >

<xsd:sequence >

<xsd:element name="cubeSelection " minOccurs="1" maxOccurs="1">

<xsd:complexType >

<xsd:sequence >



<xsd:element ref="mcws:dimensionSelection " minOccurs="1"


</xsd:sequence >


</xsd:complexType >

</xsd:element >

</xsd:sequence >

</xsd:complexType >

</xsd:element >



<xsd:element name="dimensionSelection " type="mcws:dimensionSelectionType "

abstract="true" />

<xsd:complexType name="dimensionSelectionType " abstract="true">

<xsd:attribute name="dimensionName " type="xsd:string" use="required" />

</xsd:complexType >



<xsd:element name="aggregateMemberSelection "

substitutionGroup="dimensionSelection ">

<xsd:complexType >


<xsd:extension base="dimensionSelectionType ">

<xsd:sequence >

<xsd:element name="memberRef" type="mcws:memberRefType "


</xsd:sequence >

</xsd:extension >


</xsd:complexType >

</xsd:element >



<xsd:element name="descendantsMemberSelection"


<xsd:complexType >



<xsd:sequence >





</xsd:sequence >

</xsd:extension >


</xsd:complexType >

</xsd:element >



<xsd:element name="slicerMemberSelection "


<xsd:complexType >



<xsd:sequence >





</xsd:sequence >

</xsd:extension >


</xsd:complexType >

</xsd:element >




<xsd:complexType name="memberRefType ">

<xsd:attribute name="hierarchy" type="xsd:string" use="optional" />

<xsd:attribute name="level" type="xsd:string" use="optional" />

<xsd:attribute name="member" type="xsd:string" use="required" />

</xsd:complexType >



<xsd:element name="GetCellsResponse">

<xsd:complexType >

<xsd:sequence >

<xsd:element ref="gcml:cubeCells" minOccurs="1" maxOccurs="1" />

</xsd:sequence >

</xsd:complexType >

</xsd:element >

</xsd:schema >

A.2.3 Exemples de requêtes et réponses

A.2.3.1 Opération GetCapabilities

Listage A.8 – Requête GetCapabilities, message SOAP complet<?xml version=’1.0’ encoding=’utf -8’?>

<soapenv:Envelope xmlns:soapenv ="http: // schemas.xmlsoap.org/soap/envelope/">

<soapenv:Body >

<mcws:GetCapabilitiesRequest xmlns:mcws="http: // geosoa.scg.ulaval.ca/MinicubeWS" />

</soapenv:Body >

</soapenv:Envelope >

Listage A.9 – Réponse GetCapabilities, message SOAP complet<?xml version=’1.0’ encoding=’utf -8’?>


<soapenv:Body >

<mcws:GetCapabilitiesResponse xmlns:mcws="http: // geosoa.scg.ulaval.ca/MinicubeWS">

<mcws:ServiceIdentification >

<mcws:ServiceType >MinicubeWS </mcws:ServiceType >

<mcws:ServiceTypeVersion >0.20</mcws:ServiceTypeVersion >

<mcws:Title >MinicubeWS test</mcws:Title >

<mcws:Abstract >Abstract ...</mcws:Abstract >

</mcws:ServiceIdentification >

<mcws:availableCubes >

<mcws:availableCube name="Recensements" />

</mcws:availableCubes >

</mcws:GetCapabilitiesResponse >

</soapenv:Body >



A.2.3.2 Opération DescribeSchema

Listage A.10 – Requête DescribeSchema, message SOAP complet<?xml version=’1.0’ encoding=’utf -8’?>


<soapenv:Body >

<mcws:DescribeSchemaRequest xmlns:mcws="http: // geosoa.scg.ulaval.ca/MinicubeWS"

cubeName="Recensements" />

</soapenv:Body >


Listage A.11 – Réponse DescribeSchema, message SOAP complet<?xml version=’1.0’ encoding=’utf -8’?>


<soapenv:Body >

<mcws:DescribeSchemaResponse xmlns:mcws="http: // geosoa.scg.ulaval.ca/MinicubeWS">

<gcml:cubeSchema xmlns:gcml="http: // geosoa.scg.ulaval.ca/GeoCubeML"











</gcml:dimension >

<gcml:dimension name="Age">


<gcml:hierarchy name="Age" default="true" />

<gcml:hierarchy name="Age.Age -Intervalle -Categorie" />

<gcml:level name="(All)" isAll="true" />

<gcml:level name="Categorie">

<gcml:rollupTo level="(All)" />

<gcml:property name="Code Categorie">

<gcml:contentType type="xs:decimal" />

</gcml:property >

</gcml:level >

<gcml:level name="Groupe">

<gcml:rollupTo level="Categorie" />

<gcml:property name="Code Groupe">


</gcml:property >

</gcml:level >

<gcml:level name="Age">

<gcml:rollupTo level="Groupe" />

<gcml:property name="Code Age">


</gcml:property >

</gcml:level >


<gcml:level name="Categorie">


<gcml:property name="Code Categorie">


</gcml:property >

</gcml:level >


<gcml:level name="Intervalle">

<gcml:rollupTo level="Categorie" />

<gcml:property name="Code Intervalle">


</gcml:property >

</gcml:level >

<gcml:level name="Age">

<gcml:rollupTo level="Intervalle" />

<gcml:property name="Code Age">


</gcml:property >

</gcml:level >


</gcml:dimension >

<gcml:dimension name="Temps">


<gcml:hierarchy name="Temps" default="true" />

<gcml:level name="Recensement" />

<gcml:level name="Annee">

<gcml:rollupTo level="Recensement" />

</gcml:level >


</gcml:dimension >

<gcml:dimension name="Sexe">


<gcml:hierarchy name="Sexe" default="true" />


<gcml:level name="Sexe">


</gcml:level >


</gcml:dimension >

<gcml:dimension name="Statut de population">


<gcml:hierarchy name="Statut de population" default="true" />


<gcml:level name="Statut">


</gcml:level >


</gcml:dimension >

<gcml:dimension name="Unite geographique">


<gcml:hierarchy name="Unite geographique" default="true" />


<gcml:level name="Pays">


<gcml:property name="Code Pays">


</gcml:property >

</gcml:level >

<gcml:level name="Region">

<gcml:rollupTo level="Pays" />

<gcml:property name="Code Region">


</gcml:property >

</gcml:level >

<gcml:level name="Province">

<gcml:rollupTo level="Region" />

<gcml:property name="Code Province">



</gcml:property >

<gcml:property name="Geom Province">

<gcml:contentType type="xs:string" />

</gcml:property >

</gcml:level >

<gcml:level name="Region economique">

<gcml:rollupTo level="Province" />

<gcml:property name="Code Region economique">


</gcml:property >

<gcml:property name="Geom Region economique">

<gcml:contentType ref="gml:AbstractGeometry" />

</gcml:property >

</gcml:level >

<gcml:level name="Division de recensement">

<gcml:rollupTo level="Region economique" />

<gcml:property name="Code Division de recensement">


</gcml:property >

<gcml:property name="Geom Division de recensement">

<gcml:contentType ref="gml:AbstractGeometry" />

</gcml:property >

</gcml:level >


</gcml:dimension >

</gcml:cube >

</gcml:cubeSchema >

</mcws:DescribeSchemaResponse >

</soapenv:Body >


A.2.3.3 Opération GetMembers

Listage A.12 – Requête GetMembers, message SOAP complet<?xml version=’1.0’ encoding=’utf -8’?>


<soapenv:Body >

<GetMembersRequest xmlns="http: // geosoa.scg.ulaval.ca/MinicubeWS"


xsi:schemaLocation ="http: // geosoa.scg.ulaval.ca/MinicubeWS GetMembers.xsd">


<dimensionSelection name="Measures">

<memberSelection />


<dimensionSelection name="Age">

<levelSelection name="Groupe" include="children" />

<memberSelection >

<memberSelectors >

<selectMembersByName >

<member name="Adolescents 12-17" />

<member name="Jeunes adultes 18-24" />



<member name="inconnu" />

</selectMembersByName >

</memberSelectors >

</memberSelection >



<dimensionSelection name="Unite geographique">

<levelSelection name="Division de recensement" include="levelonly" />

<memberSelection >

<memberSelectors >

<selectMembersByProperty property="Geom Division de recensement">

<GMLPropertySelector GMLPropertyName ="the_geom">

<ogc:Filter xmlns:ogc="http: //www.opengis.net/ogc">

<ogc:BBOX >

<ogc:PropertyName >the_geom </ogc:PropertyName >

<gml:Box xmlns:gml="http: //www.opengis.net/gml">

<gml:coordinates > -71.0 ,45.0 -70.0 ,46.0 </gml:coordinates >

</gml:Box >

</ogc:BBOX >

</ogc:Filter >

</GMLPropertySelector >

</selectMembersByProperty >

</memberSelectors >

<memberFilters >

<propertyMemberFilter property="Geom Division de recensement">

<douglasPeuckerPropertyFilter tolerance="0.01" />

</propertyMemberFilter >

</memberFilters >

</memberSelection >


</cubeSelection >

</GetMembersRequest >

</soapenv:Body >


Listage A.13 – Réponse GetMembers, message SOAP complet<?xml version=’1.0’ encoding=’utf -8’?>


<soapenv:Body >

<mcws:GetMembersResponse xmlns:mcws="http: // geosoa.scg.ulaval.ca/MinicubeWS">

<gcml:cubeMembers xmlns:gcml="http: // geosoa.scg.ulaval.ca/GeoCubeML"

xmlns:xs="http: //www.w3.org /2001/ XMLSchema">


<gcml:dimensionRef name="Age">

<gcml:levelRef name="Age">

<gcml:member name="19">

<gcml:rollupTo member="Jeunes adultes 18-24" />

<gcml:propertyValue property="Code Age">320</gcml:propertyValue >

</gcml:member >


<gcml:rollupTo member="Adolescents 12-17" />


</gcml:member >




</gcml:member >




</gcml:member >




</gcml:member >





</gcml:member >




</gcml:member >




</gcml:member >




</gcml:member >




</gcml:member >




</gcml:member >




</gcml:member >




</gcml:member >

</gcml:levelRef >

<gcml:levelRef name="Groupe">

<gcml:member name="Adolescents 12-17">



</gcml:member >

<gcml:member name="Jeunes adultes 18-24">



</gcml:member >

</gcml:levelRef >


<gcml:dimensionRef name="Unite geographique">

<gcml:levelRef name="Division de recensement">

<gcml:member name="L’Amiante">

<gcml:rollupTo member="Chaudière - Appalaches" />


2431





<gml:Polygon >


<gml:LinearRing >

<gml:coordinates >

-71.105194 ,46.309143

-71.121681 ,46.297913

-71.098801 ,46.277966

-71.084007 ,46.287724


-70.97937 ,46.190399

-71.013718 ,46.167927

-70.99472 ,46.152752

-71.008499 ,46.144676

-70.970726 ,46.115688

-71.023842 ,46.076305

-71.012703 ,46.06699

-71.025719 ,46.057892

-70.98893 ,46.024101

-71.00782 ,45.987801

-71.0457 ,46.007191

-71.10743 ,45.946148

-71.129883 ,45.957413

-71.162827 ,45.925003

-71.156029 ,45.877884

-71.137314 ,45.85627

-71.179359 ,45.815441

-71.231544 ,45.846287

-71.27417 ,45.829506

-71.349724 ,45.870335

-71.342926 ,45.803886

-71.393265 ,45.768993

-71.468147 ,45.81945

-71.455711 ,45.872551

-71.685066 ,45.967846

-71.510269 ,46.13702

-71.5345 ,46.149288

-71.485863 ,46.213539

-71.467453 ,46.231071

-71.418755 ,46.223522

-71.372826 ,46.26823

-71.414291 ,46.289982

-71.322914 ,46.349075

-71.253242 ,46.300732

-71.105194 ,46.309143

</gml:coordinates >

</gml:LinearRing >


</gml:Polygon >




</gcml:member >

<gcml:member name="Beauce -Sartigan">

<gcml:rollupTo member="Chaudière - Appalaches" />


2429





<gml:Polygon >


<gml:LinearRing >

<gml:coordinates >

-71.10743 ,45.946148

-71.0457 ,46.007191

-71.00782 ,45.987801

-70.991402 ,46.004456

-71.002434 ,46.0103

-70.98893 ,46.024101


-71.025719 ,46.057892

-71.013077 ,46.088642

-70.970726 ,46.115688

-70.909935 ,46.082417

-70.895355 ,46.091911

-70.86013 ,46.062889

-70.847466 ,46.071312

-70.860062 ,46.084198

-70.831474 ,46.10215

-70.845993 ,46.115166

-70.793182 ,46.135147

-70.775024 ,46.119652

-70.748505 ,46.137604

-70.748886 ,46.180912

-70.704361 ,46.212566

-70.714149 ,46.21711

-70.699852 ,46.227196

-70.716675 ,46.234512

-70.673843 ,46.262482

-70.621681 ,46.224159

-70.614105 ,46.195366

-70.592728 ,46.210358

-70.568886 ,46.171837

-70.542145 ,46.189312

-70.513741 ,46.171326

-70.517601 ,46.148609

-70.475624 ,46.14444

-70.486931 ,46.136963

-70.405716 ,46.028141

-70.34697 ,46.027164

-70.280388 ,46.055191

-70.318176 ,46.019325

-70.284615 ,45.995686

-70.315804 ,45.963135

-70.276505 ,45.96727

-70.23951 ,45.944168

-70.263069 ,45.923954

-70.26165 ,45.88842

-70.371826 ,45.835217

-70.398766 ,45.796959

-70.42231 ,45.806744

-70.471664 ,45.788898

-70.499992 ,45.827045

-70.632149 ,45.778912

-70.652779 ,45.802525

-70.663681 ,45.781849

-70.89296 ,45.77998

-70.896805 ,45.890858

-70.950653 ,45.915943

-70.968956 ,45.901024

-71.10743 ,45.946148

</gml:coordinates >

</gml:LinearRing >


</gml:Polygon >




</gcml:member >

<gcml:member name="Le Granit">

<gcml:rollupTo member="Estrie" />



2430





<gml:Polygon >


<gml:LinearRing >

<gml:coordinates >

-71.10743 ,45.946148

-70.968956 ,45.901024

-70.950653 ,45.915943

-70.896805 ,45.890858

-70.89296 ,45.77998

-70.663681 ,45.781849

-70.652779 ,45.802525

-70.632149 ,45.778912

-70.499992 ,45.827045

-70.471664 ,45.788898

-70.42231 ,45.806744

-70.407913 ,45.762344

-70.388618 ,45.751362

-70.384438 ,45.734295

-70.40062 ,45.720001

-70.466736 ,45.706028

-70.526024 ,45.666664

-70.558212 ,45.666927

-70.68866 ,45.568104

-70.677757 ,45.551353

-70.723015 ,45.513805

-70.718002 ,45.489189

-70.630371 ,45.426533

-70.622314 ,45.403091

-70.660683 ,45.377712

-70.680138 ,45.39465

-70.722282 ,45.394672

-70.754776 ,45.427956

-70.797752 ,45.426941

-70.826553 ,45.398392

-70.80262 ,45.366722

-70.819992 ,45.34053

-70.812714 ,45.30254

-70.835297 ,45.293411

-70.849556 ,45.262058

-70.839195 ,45.23407

-70.895348 ,45.239666

-70.922516 ,45.279018

-70.918472 ,45.31184

-70.952705 ,45.338825

-70.985352 ,45.332016

-71.010292 ,45.347519

-71.009201 ,45.319218

-71.09787 ,45.301819

-71.131927 ,45.246696

-71.133492 ,45.458279

-71.160797 ,45.458401

-71.159134 ,45.535843

-71.229515 ,45.582012

-71.204315 ,45.602573

-71.234688 ,45.621712


-71.207626 ,45.64246

-71.393265 ,45.768993

-71.342926 ,45.803886

-71.349724 ,45.870335

-71.27417 ,45.829506

-71.231544 ,45.846287

-71.179359 ,45.815441

-71.137314 ,45.85627

-71.156029 ,45.877884

-71.162827 ,45.925003

-71.129883 ,45.957413

-71.10743 ,45.946148

</gml:coordinates >

</gml:LinearRing >


</gml:Polygon >




</gcml:member >

</gcml:levelRef >







</gcml:levelRef >


</gcml:cubeRef >


</mcws:GetMembersResponse >

</soapenv:Body >


A.2.3.4 Opération GetCells

Listage A.14 – Requête GetCells, message SOAP complet<?xml version=’1.0’ encoding=’utf -8’?>


<soapenv:Body >

<GetCellsRequest xmlns="http: // geosoa.scg.ulaval.ca/ MinicubeWS"


xsi:schemaLocation ="http: // geosoa.scg.ulaval.ca/MinicubeWS GetCells.xsd">

















</cubeSelection >

</GetCellsRequest >

</soapenv:Body >


Listage A.15 – Réponse GetCells, message SOAP partiel (tronqué pour réduire la taille)<?xml version=’1.0’ encoding=’utf -8’?>


<soapenv:Body >

<mcws:GetCellsResponse xmlns:mcws="http: // geosoa.scg.ulaval.ca/MinicubeWS">

<gcml:cubeCells xmlns:gcml="http: // geosoa.scg.ulaval.ca/GeoCubeML"




<gcml:slicerMembers >

<gcml:tuple >

<gcml:memberRef dimension="Measures" hierarchy="Measures"

level="MeasuresLevel " member="Population" />

<gcml:memberRef dimension="Temps" hierarchy="Temps"

level="Annee" member="2001" />

</gcml:tuple >

</gcml:slicerMembers >

<gcml:cells >

<gcml:cell >

<gcml:tuple >

<gcml:memberRef dimension="Age" hierarchy="Age"

level="Groupe" member="Bébés <2" />

<gcml:memberRef dimension="Sexe" hierarchy="Sexe"

level="(All)" member="All Sexes" />







</gcml:tuple >


</gcml:cell >

<gcml:cell >

<gcml:tuple >


level="Groupe" member="Enfants 2-11" />




hierarchy="Statut de population"

level="(All)" member="All Statut de populations" />




</gcml:tuple >


</gcml:cell >



<gcml:cell >

<gcml:tuple >



level="Groupe" member="Adolescents 12-17" />




hierarchy="Statut de population"

level="(All)" member="All Statut de populations" />



level="Division de recensement" member="Maria -Chapdelaine" />

</gcml:tuple >


</gcml:cell >

</gcml:cells >

</gcml:cubeRef >

</gcml:cubeCells >

</mcws:GetCellsResponse >

</soapenv:Body >


A.3 Configuration et tests du prototype

Listage A.16 – Schéma XML pour Mondrian du cube « Recensements »<?xml version="1.0"?>

<Schema name="StatCan">



<Dimension name="Age">

<Hierarchy hasAll="true" primaryKey="d_age_key">

<Table name="d_age" />

<Level name="Categorie" column="categorie_nom "

uniqueMembers ="true">

<Property name="Code Categorie" column="categorie_code"

type="Numeric" />

</Level >

<Level name="Groupe" column="groupe_nom"


<Property name="Code Groupe" column="groupe_code"

type="Numeric" />

</Level >

<Level name="Age" column="age_nom" uniqueMembers ="true">

<Property name="Code Age" column="age_code"

type="Numeric" />

</Level >

</Hierarchy >

<Hierarchy name="Age -Intervalle -Categorie" hasAll="true"

primaryKey="d_age_key">

<Table name="d_age" />

<Level name="Categorie" column="categorie_nom "


<Property name="Code Categorie" column="categorie_code"

type="Numeric" />

</Level >

<Level name="Intervalle" column="intervalle_nom"



<Property name="Code Intervalle"

column="intervalle_code " type="Numeric" />

</Level >

<Level name="Age" column="age_nom" uniqueMembers ="true">

<Property name="Code Age" column="age_code"

type="Numeric" />

</Level >

</Hierarchy >

</Dimension >

<Dimension name="Temps">

<Hierarchy hasAll="false" primaryKey="d_annee_key"

defaultMember ="[Rencensement 2001 (2001 -2003)].[2001]">

<Table name="d_annee" />

<Level name="Recensement" column="recens_nom"

uniqueMembers ="true" />

<Level name="Annee" column="annee_nom" uniqueMembers ="true" />

</Hierarchy >

</Dimension >

<Dimension name="Sexe">

<Hierarchy hasAll="true" primaryKey="d_sexe_key">

<Table name="d_sexe" />

<Level name="Sexe" column="sexe_nom" uniqueMembers ="true" />

</Hierarchy >

</Dimension >

<Dimension name="Statut de population">

<Hierarchy hasAll="true" primaryKey="d_statut_pop_key ">

<Table name="d_statut_pop" />

<Level name="Statut" uniqueMembers ="true" type="Numeric"

column="d_statut_pop_key" nameColumn="membre_nom"

parentColumn="parent_key" nullParentValue ="null" />

</Hierarchy >

</Dimension >



<Dimension name="Unite geographique">

<Hierarchy hasAll="true" primaryKey="d_unite_geo_key "

primaryKeyTable ="d_unite_geo3_division ">

<Join leftKey="rg_econo_code_fk" rightKey="rg_econo_code "

rightAlias="d_unite_geo3_rg_econo ">

<Table name="d_unite_geo3_division " />

<Join leftKey="province_code_fk" rightKey="province_code "

rightAlias="d_unite_geo3_province ">

<Table name="d_unite_geo3_rg_econo " />

<Join leftKey="region_code_fk" rightKey="region_code"

rightAlias="d_unite_geo3_region ">

<Table name="d_unite_geo3_province " />

<Join leftKey="pays_code_fk"

rightKey="pays_code">

<Table name="d_unite_geo3_region " />

<Table name="d_unite_geo3_pays " />

</Join>

</Join>

</Join>

</Join>

<Level name="Pays" table="d_unite_geo3_pays "

column="pays_nom" uniqueMembers ="true">

<Property name="Code Pays" column="pays_code"


type="Numeric" />



</Level >

<Level name="Region" table="d_unite_geo3_region "

column="region_code" type="Integer" nameColumn="region_nom"


<Property name="Code Region" column="region_code"

type="Numeric" />



</Level >

<Level name="Province" table="d_unite_geo3_province "

column="province_code " type="Integer" nameColumn="province_nom"


<Property name="Code Province" column="province_code "

type="Numeric" />

<Property name="Geom Province"

column="province_geom " type="Geometry" />

</Level >

<Level name="Region economique" table="d_unite_geo3_rg_econo "

column="rg_econo_code " type="Integer" nameColumn="rg_econo_nom"


<Property name="Code Region economique"

column="rg_econo_code " type="Numeric" />

<Property name="Geom Region economique"

column="rg_econo_geom " type="Geometry" />

</Level >

<Level name="Division de recensement"

table="d_unite_geo3_division "

column="division_code " type="Integer" nameColumn="division_nom"


<Property name="Code Division de recensement"

column="division_code " type="Numeric" />

<Property name="Geom Division de recensement"

column="division_geom " type="Geometry" />

</Level >

</Hierarchy >

</Dimension >



<Cube name="Recensements">

<Table name="f_pop"></Table >

<DimensionUsage name="Age" source="Age" foreignKey="d_age_key" />

<DimensionUsage name="Temps" source="Temps"

foreignKey="d_annee_key" />

<DimensionUsage name="Sexe" source="Sexe"

foreignKey="d_sexe_key" />

<DimensionUsage name="Statut de population"

source="Statut de population" foreignKey="d_statut_pop_key" />

<DimensionUsage name="Unite geographique"

source="Unite geographique" foreignKey="d_unite_geo_key " />

<Measure name="Population" column="population"

aggregator="sum">



</Measure >

<Measure name="Naissances" column="nb_naissance"

aggregator="sum">




</Measure >

<Measure name="Décès" column="nb_deces" aggregator="sum">



</Measure >

</Cube>

</Schema >

Listage A.17 – Requête GetCells avec code MDX généré correspondantRequête GetCells:

<GetCellsRequest xmlns="http: // geosoa.scg.ulaval.ca/ MinicubeWS"


xsi:schemaLocation ="http: // geosoa.scg.ulaval.ca/MinicubeWS GetCells.xsd">
















</cubeSelection >

</GetCellsRequest >

Requête MDX:

SELECT {[Age ].[ All Ages ].[ Jeunes <25].[ Bébés <2],

[Age ].[ All Ages ].[ Jeunes <25].[ Enfants 2-11],

[Age ].[ All Ages ].[ Jeunes <25].[ Adolescents 12 -17]}

ON AXIS(0),

Descendants ([ Unite geographique ].[ All Unite geographiques ].

[Canada ].[ Centre ].[ Québec],

100, LEAVES)

ON AXIS (1)

FROM [Recensements]

WHERE ([ Measures ].[ Population],

[Temps ].[ Rencensement 2001 (2001 -2003)].[2001])

Documents

CONCEPTION ET D VELOPPEMENT D'UN SERVICE WEB DE CONSTITUTION DE MINI CUBES SOLAP … · 2018-04-14 · tion des applications SOLAP aux contextes d’utilisation mobile (e.g. PDA et