Avec l’essor ces dernières années des grandes plateformes Web (par exemple, Google, Facebook, Twitter, Amazon), ont été développées des solutions de gestion des mégadonnées (big data) basées sur des approches décentralisées permettant la gestion et le stockage de gigantesques masses de données. Cette approche décentralisée repose sur le principe de la scalabilité, c’est-à-dire l’ajustement d’une manière progressive et continue du stockage et des traitements au volume des données. Ce type d’architecture distribuée a connu récemment le développement de systèmes de gestion de fichiers massivement distribués et de nouvelles techniques de parallélisation massive des traitements. Adossés à ce contexte de distribution massive, différents systèmes de stockage sont apparus ces dernières années. Ces systèmes, qualifiés de systèmes not-only-SQL (ou NoSQL), relaxent les fondements de l’approche relationnelle pour pouvoir supporter les masses de données distribuées. De ce fait, il est envisageable de construire des entrepôts de données massives reposant sur ce principe de scalabilité de l’espace de stockage. Dans ce papier, nous étudions l’instanciation d’entrepôts de données avec les systèmes orientés documents. Dans un premier temps, nous étudions les enjeux primaires des entrepôts tels que la modélisation, l’interrogation, le chargement des données et les cubes OLAP. Dans un deuxième temps, nous proposons des améliorations qui sont spécifiques aux systèmes orientés documents. En particulier, nous proposons des versions étendues des cubes OLAP qui exploitent l’imbrication. Nous montrons que ces cubes répondent plus rapidement à des charges de travail composées de requêtes OLAP de type “drill-down”.

Les données des systèmes d'analyse en ligne (OLAP, On-Line Analytical Processing) sont traditionnellement gérées par des bases de données relationnelles. Malheureusement, il devient difficile de gérer des mégadonnées (de gros volumes de données, « Big Data »). Dans un tel contexte, comme alternative, les environnements « Not-Only SQL » (NoSQL) peuvent fournir un passage à l'échelle tout en gardant une certaine flexibilité pour un système OLAP. Nous définissons ainsi des règles pour convertir un schéma en étoile, ainsi que son optimisation, le treillis d'agrégats pré-calculés, en deux modèles logiques NoSQL : orienté-colonnes ou orienté-documents. En utilisant ces règles, nous implémentons et analysons deux systèmes décisionnels, un par modèle, avec MongoDB et HBase. Nous comparons ces derniers sur les phases de chargement des données (générées avec le benchmark TPC-DS), de calcul d'un treillis et d'interrogation.

Les systèmes NoSQL (Not Only SQL) se développent notamment grâce à leur capacité à gérer facilement de grands volumes de données, et leur flexibilité en terme de type de données. Dans cet article, nous étudions l'implantation d'un entrepôt de données multidimensionnelles avec un système NoSQL orienté documents. Nous proposons des règles de transformation qui permettent de passer d'un modèle conceptuel multidimensionnel vers un modèle logique NoSQL orienté documents. Nous proposons trois types de transformation pour implanter les entrepôts de données multidimensionnelles. Nous expérimentons ces trois approches avec le système MongoDB, et étudions le chargement des données, les processus de transformation d'un type d'implantation à un autre ainsi que le pré-calcul d'agrégats inhérents aux entrepôts de données multidimensionnelles.

L’exploration OLAP (On-Line Analytical Processing) de données est un processus incrémental basé sur des requêtes effectuant une recherche d’informations dans un Entrepôt de Données (ED) multidimensionnelles. Afin de faciliter l’exploration d’un décideur, des systèmes de recommandation ont été proposés. Toutefois, lors de l’utilisation d’un nouveau système, ces systèmes de recommandations ne fonctionnent plus (problème de démarrage à froid). Dans cet article, nous proposons des recommandations pour un décideur qui est confronté à un problème de démarrage à froid. Notre processus est composé de quatre étapes : identifier le squelette des requêtes OLAP, prévoir des opérations candidates, calculer des recommandations sur les opérations candidates et classer ces recommandations.

Les systèmes d’aide à la décision occupent une place prépondérante au sein des entreprises et des grandes organisations, pour permettre des analyses dédiées à la prise de décisions. Avec l’avènement du big data, le volume des données d’analyses atteint des tailles critiques, défiant les approches classiques d’entreposage de données, dont les solutions actuelles reposent principalement sur des bases de données R-OLAP. Avec l’apparition des grandes plateformes Web telles que Google, Facebook, Twitter, Amazon… des solutions pour gérer les mégadonnées (Big Data) ont été développées et appelées « Not Only SQL ». Ces nouvelles approches constituent une voie intéressante pour la construction des entrepôts de données multidimensionnelles capables de supporter des grandes masses de données. La remise en cause de l’approche R-OLAP nécessite de revisiter les principes de la modélisation des entrepôts de données multidimensionnelles. Dans ce manuscrit, nous avons proposé des processus d’implantation des entrepôts de données multidimensionnelles avec les modèles NoSQL. Nous avons défini quatre processus pour chacun des deux modèles NoSQL orienté colonnes et orienté documents. De plus, le contexte NoSQL rend également plus complexe le calcul efficace de pré-agrégats qui sont habituellement mis en place dans le contexte ROLAP (treillis). Nous avons élargis nos processus d’implantations pour prendre en compte la construction du treillis dans les deux modèles retenus.Comme il est difficile de choisir une seule implantation NoSQL supportant efficacement tous les traitements applicables, nous avons proposé deux processus de traductions, le premier concerne des processus intra-modèles, c’est-à-dire des règles de passage d’une implantation à une autre implantation du même modèle logique NoSQL, tandis que le second processus définit les règles de transformation d’une implantation d’un modèle logique vers une autre implantation d’un autre modèle logique.

Les systèmes d'Entrepôts de Données et OLAP spatiaux (EDS et SOLAP) sont des technologies d'aide à la décision permettant l'analyse multidimensionnelle de gros volumes de données spatiales. Dans ces systèmes, la qualité de l'analyse dépend de trois facteurs : la qualité des données entreposées, la qualité des agrégations et la qualité de l’exploration des données. La qualité des données entreposées dépend de critères comme la précision, l'exhaustivité et la cohérence logique. La qualité d'agrégation dépend de problèmes structurels (e.g. les hiérarchies non strictes qui peuvent engendrer le comptage en double des mesures) et de problèmes sémantiques (e.g. agréger les valeurs de température par la fonction Sum peut ne pas avoir de sens considérant une application donnée). La qualité d'exploration est essentiellement affectée par des requêtes utilisateur inconsistantes (e.g. quelles ont été les valeurs de température en URSS en 2010 ?). Ces requêtes peuvent engendrer des interprétations erronées des résultats. Cette thèse s'attaque aux problèmes d'incohérence logique qui peuvent affecter les qualités de données, d'agrégation et d'exploration. L'incohérence logique est définie habituellement comme la présence de contradictions dans les données. Elle est typiquement contrôlée au moyen de Contraintes d'Intégrité (CI). Dans cette thèse nous étendons d'abord la notion de CI (dans le contexte des systèmes SOLAP) afin de prendre en compte les incohérences relatives aux agrégations et requêtes utilisateur. Pour pallier les limitations des approches existantes concernant la définition des CI SOLAP, nous proposons un Framework basé sur les langages standards UML et OCL. Ce Framework permet la spécification conceptuelle et indépendante des plates-formes des CI SOLAP et leur implémentation automatisée. Il comporte trois parties : (1) Une classification des CI SOLAP. (2) Un profil UML implémenté dans l'AGL MagicDraw, permettant la représentation conceptuelle des modèles des systèmes SOLAP et de leurs CI. (3) Une implémentation automatique qui est basée sur les générateurs de code Spatial OCL2SQL et UML2MDX qui permet de traduire les spécifications conceptuelles en code au niveau des couches EDS et serveur SOLAP. Enfin, les contributions de cette thèse ont été appliquées dans le cadre de projets nationaux de développement d'applications (S)OLAP pour l'agriculture et l'environnement.