Dans ce chapitre, nous avons présenté le processus de construction de l’entrepôt de données N -Catch. N -Catch a été construit pour stocker les résultats de simulations issus du modèle T N T , et pour analyser le cycle de l’azote à différents niveaux spatio- temporels et de fournir des analyses stratégiques pour la prise de décision. Dans la table 3.2 nous présentons quelques chiffres relatifs au volume des données stockées dans N - Catch. L’un des défis majeur de cette étude résidait dans la quantité et la complexité des données à extraire, à traiter et à analyser. Comme mentionné précédemment, afin d’accélérer l’exécution des requêtes, nous avons utilisé : (i) des index qui nous ont permis de diviser par 5 les temps de calcul des requêtes portant sur les colonnes indexées, et (ii) des vues matérialisées qui assurent à des requêtes complexes et nécessitant seulement un accès aux vues matérialisées, avec donc des temps de réponses quasi instantanés.
Données stockées Description
Entrées/sorites du modèle T N T 9000 fichiers traités (8.6 Go)
Taille de N -Catch 9 Go (sans les index et les vues matérialisées)
Index 2.1 Go
Vues matérialisées 2.7 Go
Table 3.2 – Synthèse des données stockées dans N -Catch
Dans ce travail nous avons proposé une méthodologie de construction d’un entrepôt de données agro-hydrologique, dont les principales contributions sont :
– Le pré-traitement et la transformation des données extraites ;
– La modélisation multidimensionnelle et hiérarchique des pratiques agricoles ; – l’analyse des résultats de simulations en combinant la modélisation spatio-temporelle
des données, l’entreposage des données et l’analyse en ligne.
Ces contributions méthodologiques peuvent être appliquées à une variété de problé- matiques agro-environnementales. Plus généralement, cette approche peut être utilisée pour analyser l’impact des pratiques agricoles sur la qualité des eaux, ou d’autres im- pacts environnementaux. Les différentes phases de conception et de construction de l’entrepôt de données (identification des besoins, modélisation multidimensionnelle, et utilisation de OLAP pour accéder et exploiter des données multidimensionnelles et agré- gées) sont des étapes génériques.
L’entrepôt de données N -Catch peut être utilisé efficacement pour :
– Explorer les dimensions spatio-temporelles et exploiter les simulations afin de fournir une analyse plus fine pour faciliter le processus d’aide à la décision (i.e. rendre les données facilement accessibles par les décideurs) ;
– Permettre aux utilisateurs de synthétiser l’information environnementale et de comprendre les émissions d’azote dans les cours d’eau,
– Analyser les processus agro-hydrologiques et extraire les relations entre les me- sures.
Conclusion 83
Cependant, avec l’analyse OLAP , l’exploration est faite par l’utilisateur mais sans outil pour le guider automatiquement dans l’entrepôt de données N -Catch. C’est à l’uti- lisateur de décider vers quelles données naviguer à la recherche d’informations intéres- santes et c’est aussi à l’utilisateur d’évaluer la pertinence des informations découvertes pour savoir si elles constituent de nouvelles connaissances. Pourtant, l’automatisation de ces tâches serait très utile à l’utilisateur de N -Catch.
Dans la partie suivante, nous proposons de coupler N -Catch avec les requêtes Sky- line afin de permettre aux utilisateurs de formuler de nouvelles requêtes dans N -Catch en combinant des indicateurs environnementaux contradictoires, et de trouver les so- lutions compromis associées à ces attentes. Nous allons montrer comment exploiter les préférences des utilisateurs afin de détecter les données susceptibles de les intéresser.
Troisième partie
Requêtes skyline dans un contexte
multidimensionnel et hiérarchique
Chapitre 4
Calcul incrémental des requêtes
skyline en présence de préférences
dynamiques
4.1
Introduction et motivations
Un nombre considérable de méthodes de calcul de skyline a été proposé dans le cadre des bases de données. La quasi totalité de ces méthodes étaient associées à des dimensions totalement ordonnées. Cependant, dans les applications réelles, les don- nées peuvent inclure des dimensions partiellement ordonnées par nature, comme les dimensions catégoriques (i.e. nominales). Par exemple, dans notre application agro- hydrologique (cf. chapitre 3), le niveau type culture de la dimension agricole est catégo- rique. Certaines études récentes se sont intéressées à la problématique d’extraction de points skyline en présence de dimensions partiellement ordonnées [BGS06], et ont fourni un moyen pour vérifier la dominance entre deux points incomparables pour un ordre partiel donné. Cependant, ces travaux supposent qu’il existe un seul ordre prédéfini sur le domaine de chaque dimension. En particulier, les utilisateurs ne peuvent pas exprimer en ligne des préférences entre les différentes dimensions ni personnaliser les préférences entre les valeurs d’une dimension donnée, et calculer les points skyline associés à ces préférences. Par conséquent, d’autres types de requêtes skyline ont été proposées pour traiter ce problème :
– les préférences inter-dimensions qui permettent à l’utilisateur de spécifier le degré d’importance de différentes dimensions et ainsi de classer les skyline par ordre de préférences [MC11]. Par exemple, la dimension agricole peut être considérée comme plus importante que la dimension spatiale si notre objectif est de caracté- riser les types de cultures qui polluent le plus. Ce type de requêtes permet aussi de réduire le nombre de points skyline qui grandit de manière exponentielle avec le nombre de dimensions, en retournant seulement les K meilleurs points, les top K [BGG07], associés aux préférences inter-dimensions définies.
– les préférences intra-dimensions [WFP 08, WPFW09] qui permettent à chaque utilisateur d’exprimer des préférences sur les différentes valeurs d’une dimension. Ce type de préférences est particulièrement intéressant pour les dimensions no- minales où il n’est pas évident de trouver un ordre consensuel. Par exemple, un utilisateur peut préférer extraire les parcelles les plus polluées avec comme type de culture prairie temporaire, et un autre utilisateur peut plutôt préférer extraire les parcelles avec le type de culture CIPAN.
Dans cette étude, nous nous intéressons particulièrement au calcul en ligne des re- quêtes skyline en présence de préférences intra-dimensions. Un problème intéressant se pose lorsque les utilisateurs ont la possibilité de définir ou de modifier leurs préfé- rences en ligne. Ainsi, sur certaines dimensions l’ordre peut changer dynamiquement. Ce problème constitue un véritable challenge dans le contexte des bases de données volumineuses comme les entrepôts de données, et il a attiré l’attention de travaux ré- cents [WFP 08, WPFW09]. En effet, le skyline évolue lorsque les préférences changent. Une solution naïve serait de recalculer, pour chaque nouvelle préférence, l’ensemble des skyline. Cependant, ceci devient trop coûteux dans un contexte de données volumi- neuses avec une dimensionalité élevée. Le défi est donc le suivant : comment recalculer efficacement le moins de points skyline possible, tout en minimisant l’espace mémoire requis.
Les solutions proposées par Wong et al. dans [WPFW09, WFP 08] développent des méthodes de semi-matérialisation (i.e. matérialisation partielle des préférences et des skyline associés) assurant un calcul en ligne des requêtes skyline impliquant des préfé- rences dynamiques. Précisément, les auteurs de [WFP 08] ont introduit le concept de préférence d’ordre n. Ils ont démontré que le skyline associé à n’importe quelle préfé- rence sur une dimension donnée pouvait être calculé à partir des préférences de premier ordre sur cette même dimension. S’appuyant sur cette propriété (nommée merging pro- perty ), ils proposent de matérialiser les skyline associés aux préférences de premier ordre dans une structure de données spécifique, nommée IPO-tree, afin d’accélérer le calcul en ligne des skyline. Pour gérer le cas de multiples dimensions, ils proposent de stocker toutes les combinaisons possibles des préférences de premier ordre dans la structure IPO-tree. Par conséquent, la taille de IPO-tree induite par cette matérialisation est de
l’ordre de Opcmq, où m représente le nombre de dimensions associées à des préférences
dynamiques, et c la cardinalité maximale d’une dimension. Dans le contexte de bases de données volumineuses et multidimensionnelles, la taille et la gestion de cette structure de données est prohibitive en terme d’espace mémoire et de temps de calcul.
Dans [WPFW09], Wong et al. ont proposé la structure CST (Compressed Ordered skyline Tree), pour matérialiser tous les ordres de préférence possibles. Ils stockent les skyline associés aux divers ordres de raffinement dans une structure de données compacte. Cependant, l’arbre CST construit est très complexe. Cela rend difficile les mises à jour des préférences qui nécessitent une lourde maintenance et des modifications conséquentes au niveau de l’arbre CST . De plus, cette méthode est incomplète. En effet, l’arbre CST est construit graduellement en ajoutant, une par une, les dimensions dynamiques. Au cours de cette construction, certains points sont disqualifiés du skyline
Skyline et préférences dynamiques 89
lors de l’ajout d’une nouvelle dimension, alors qu’ils devraient être dans le skyline. Nous avons notifié ce problème d’incomplétude aux auteurs, et un erratum sera publié prochainement dans [WPFW] (communication personnelle de Wong).
La merging property de Wong et al. ne gère qu’une seule dimension à la fois, et par conséquent, est d’un intérêt limité.
Dans ce chapitre, nous étudions le cas d’un nombre arbitraire de dimensions. Notre
proposition, EC2Sky [BCQ12, BCQ13], se focalise sur comment répondre efficacement
à des requêtes de type skyline en présence de préférences utilisateurs dynamiques sur plusieurs dimensions malgré de gros volumes de données.
L’idée principale d’EC2Sky repose sur l’ajout incrémental des dimensions dyna-
miques lors du calcul des skyline. Comme effet supplémentaire, EC2Sky retourne les
connaissances les plus pertinentes en soulignant les compromis associés aux préférences spécifiées. L’avantage de cette proposition est double. D’une part, la complexité en terme
de stockage mémoire des informations pré-calculées est réduite à Opc mq (où m repré-
sente le nombre de dimensions associées à des préférences dynamiques, et c la cardinalité maximale d’une dimension). D’autre part, le nombre de tests de dominance diminue de manière significative. De l’espace mémoire et des temps d’exécution supplémentaires sont nécessaires au calcul des skyline associés aux préférences de premier ordre comparé à la méthode IPO-tree. Mais nous avons expérimentalement prouvé que le coût total de calcul est beaucoup plus faible que pour IPO-tree. Cette contribution permet un calcul incrémental des skyline associés à un ensemble de préférences, et facilite la modification interactive de ces dernières.
Dans ce chapitre, nous présentons dans la section 4.2 les concepts de base liés aux préférences dynamiques et les principales méthodes de calcul de skyline en présence de telles préférences. Dans la section 4.3, nous développons les aspects formels ainsi que
l’implémentation de notre approche EC2Sky, et nous présentons les résultats de l’éva-
luation expérimentale réalisée sur des données synthétiques qui souligne la pertinence de la solution proposée en la comparant aux références du domaine.