Exploration collaborative de cubes de données

Présentation au sujet: "Exploration collaborative de cubes de données"— Transcription de la présentation:

1 Exploration collaborative de cubes de données
NEGRE Elsa Université François Rabelais Tours JIRC’09 22 Janvier 2010

2 Plan Contexte / Problématique BD multidimensionnelles Intuitions
Recommandation de requêtes Expérimentations et Résultats Conclusion et Perspectives Cette présentation s’articule selon 6 points. Après avoir introduit la problématique, et le contexte, je ferai un rapide aperçu des notions de BDM utiles. Ensuite, j’aborderai le cœur de notre travail : la génération de recommandations. Puis je présenterai les expérimentations et les résultats obtenus. Enfin, la Conclusion et les Perspectives.

3 Contexte / Problématique
Informations → Exploration de cubes de données Plusieurs utilisateurs Les systèmes d’aide à la décision : 3 parties : systèmes transactionnels (OLTP), Entrepôt en lui-même, systèmes analytique (OLAP) Nous nous intéressons à l’analyse interactive de cube de données. Nous nous situons donc ici. Pour obtenir des informations, l’utilisateur explore un cube de données en lançant une séquence de requêtes mais quelles requêtes lancées?, Dans quelle partie du cube naviguer pour obtenir l’information intéressante? Les cubes sont explorés par différents utilisateurs, ainsi, nous allons utiliser une méthode collaborative pour répondre à notre problématique qui est : Comment aider l’utilisateur à avancer dans son exploration du cube de données en lui proposant des requêtes pertinentes ? Problématique : Comment aider l’utilisateur à avancer dans son exploration du cube de données en lui proposant des requêtes pertinentes ?

4 Plan Contexte / Problématique BD multidimensionnelles Intuitions
Recommandation de requêtes Expérimentations et Résultats Conclusion et Perspectives BD multidimensionnelles

5 Modélisation des bases de données multidimensionnelles
1. Introduction 2. BDM 3. Intuitions 4. Recommandation 5. Expérimentations 6. Conclusion et Perspectives Modélisation des bases de données multidimensionnelles Dimension (D) sort(TEMPS)={DateV, Mois, Trimestre, Année, AllT} Fait (F) sort(VENTES)={Immatriculation, DateV, CodeVille, NomM, Valeur} Cube N-dimensionnel, C = <D1, …, DN, F> MesVentes = <MESURES,VEHICULES,GEOGRAPHIE,TEMPS,VENTES> Pour être analysées, les données multidimensionnelles issues de l’entrepôt sont structurées. Nous modélisons un cube de données de manière classique, c’est-à-dire comme un schéma en étoile avec une table de faits en BCNF (Forme normale de Boyce-Codd). Ainsi, d’un point de vue conceptuel, la modélisation est liée au concept de cube, de fait et de dimension. Exemple !! BCNF = Une relation est en forme normale de Boyce-Codd si et seulement si ses clés candidates sont les uniques sources de DF MESURES = dimension qui détaille le nom des mesures Schéma en étoile inspiré par [Golfarelli+:IJCIS’98]

6 Le langage MDX [Microsoft:1998]
1. Introduction 2. BDM 3. Intuitions 4. Recommandation 5. Expérimentations 6. Conclusion et Perspectives Le langage MDX [Microsoft:1998] Requête : {Rouge} X {Centre, Limousin} X πAnnée(Temps) X {Montant} Références : {<Montant, Rouge, Centre, 2007>, <Montant, Rouge, Limousin, 2007> <Montant, Rouge, Centre, 2008>, <Montant, Rouge, Limousin, 2008>} Résultat : La communauté des BD s’est intéressée à la définition d’un langage dédié aux données multidimensionnelles. Cependant, chaque langage propose des propriétés qui lui sont spécifiques et aucun langage formel standard n’a été établi. En pratique, le langage MDX doté d’une syntaxe de type SQL est utilisé par tous les serveurs OLAP. Il représente donc un moyen syntaxique d’interrogation des données multidimensionnelles du cube. Exemple de requête MDX posé sur le cube précédent qui cherche le montant des ventes de véhicules rouges en régions Centre et Limousin et indique la structure d’affichage. Cette requête est le Produit cartésien de requêtes. C’est aussi un ensemble de références. Notons que dans la suite, nous considérons une seule instance de cube, ainsi q est assimilée à ces références. Le résultat de cette requête est présenté sous forme de tableau croisé où les références sont les coordonnées des cellules. Ne pas explicité l’exemple !! < Montant,Rouge,Centre,2008, >

7 Analyse multidimensionnelle
1. Introduction 2. BDM 3. Intuitions 4. Recommandation 5. Expérimentations 6. Conclusion et Perspectives Analyse multidimensionnelle Interrogation : Quelles sont les mauvaises ventes ? Session d’analyse [Sarawagi:VLDB’00] : s1 = q1 → q2 → q3 q1 = Ventes dans les départements de la région Centre, quels que soient les véhicules et les informations temporelles q2 = Ventes dans les villes d’Indre-et-Loire, quels que soient les véhicules et les informations temporelles q3 = Ventes de véhicules selon leur couleur dans les villes d’Indre-et-Loire, quelles que soient les informations temporelles L’analyse multidimensionnelle consiste en l’interrogation d’un cube de données afin de manipuler et d’analyser les données multidimensionnelles. Le terme d’analyse est utilisé pour caractériser le fait qu’un décideur explorant interactivement un cube de données cherche souvent à obtenir des résultats ou a expliquer ces résultats. Ainsi, par exemple : Session = séquence finie de requêtes Réponse : Les véhicules réalisant des mauvaises ventes sont les véhicules rouges et les véhicules bleus dans la ville de Tours.

8 1. Introduction 2. BDM 3. Intuitions 4. Recommandation 5. Expérimentations 6. Conclusion et Perspectives Environnement Une fois les données chargées, elles sont organisées dans des cubes de données en faits et dimensions. Les décideurs réalisent alors des sessions d’analyses via des requêtes MDX sur les cubes de données afin de trouver les solutions à différentes taches décisionnelles. Enfin, ces sessions sont enregistrées dans un log de requêtes.

9 Plan Contexte / Problématique BD multidimensionnelles Intuitions
Recommandation de requêtes Expérimentations et Résultats Conclusion et Perspectives Intuitions

10 Filtrage collaboratif en :
1. Introduction 2. BDM 3. Intuitions 4. Recommandation 5. Expérimentations 6. Conclusion et Perspectives Intuitions Filtrage collaboratif en : RI Web Usage Mining e-commerce Utiliser les comportements connus d'une population pour envisager les futures actions d'un utilisateur particulier et Rechercher, par comparaison, les utilisateurs ayant des comportements semblables OLAP Exploitation des précédentes sessions des autres utilisateurs pour générer des recommandations

11 Problèmes / Solutions Problèmes : Solutions :
1. Introduction 2. BDM 3. Intuitions 4. Recommandation 5. Expérimentations 6. Conclusion et Perspectives Problèmes / Solutions Problèmes : Comment déterminer la similarité entre deux sessions/séquences de requêtes ? Comment déterminer la similarité entre deux requêtes ? Dans quel ordre présenter les requêtes recommandées ? Solutions : Distance entre séquences de requêtes Distance entre requêtes Ordonnancement de requêtes Nous voulons donc exploiter les traces des requêtes que les différents utilisateurs ont déjà lancées. Dans ce contexte particulier, recommander des requêtes soulève les problèmes suivants liés à l’exploitation de ce log de requêtes déjà lancées sur le cube de données? Ainsi, 1, 2 et 3. Nous proposons d’apporter les réponses suivantes à ces problèmes : 1,2 et 3. Notons que ces solutions vont être exploiter dans un cadre générique.

12 Plan Contexte / Problématique BD multidimensionnelles Intuitions
Recommandation de requêtes Jkjhkjhk Kjkjjk Kjkjk Expérimentations et Résultats Conclusion et Perspectives Recommandation de requêtes Distances entre sessions Cadre générique de génération de recommandations Instanciations du cadre Nos contributions incluent donc : a) Puisque à notre connaissance, il n’existe pas de distance classique entre données ou requêtes multidimensionnelles.

13 Distances entre références
1. Introduction 2. BDM 3. Intuitions 4. Recommandation 5. Expérimentations 6. Conclusion et Perspectives Distances entre références Références : r1 : <Montant, Rouge, Blois, 2008> r2 : <Montant, Rouge, Tours, 2008> r3 : <Montant, Rouge, Vendome, 2008> Distance de Hamming : simplicité d’utilisation mais grossière dh(r1,r2) = compare(Blois,Tours) + 0 = 1 dh(r1,r3) = compare(Blois,Vendome) + 0 = 1 Distance basée sur le plus court chemin : prise en compte des hiérarchies : compliquée mais fine dsp(r1,r2) = dm(Blois,Tours) + 0 = 4 dsp(r1,r3) = dm(Blois,Vendome) + 0 = 2 Hamming : quantifier la différence entre 2 séquences de symboles de même longueur SP : caractéristique importante en OLAP : hiérarchies Concept issu de la théorie des graphes Par conséquent, dsp montre que r3 est + proche de r1 que r2. ce qui n’est pas le cas de dh. Ne détailler qu’une ligne à l’oral !! 37000 Tours IndreEtLoire 41100 Vendome 41000 Blois LoirEtCher 33000 AllG Bordeaux Gironde Centre Aquitaine dh(r1,r2) = dh(r1,r3) et dsp(r1,r2) ≠ dsp(r1,r3)

14 Distance de Hausdorff Requêtes :
1. Introduction 2. BDM 3. Intuitions 4. Recommandation 5. Expérimentations 6. Conclusion et Perspectives Distance de Hausdorff Requêtes : q1 : Montant des ventes de véhicules rouges à Blois quelle que soit l’année : {<Montant, Rouge, Blois, AllT>} = {r11} q2 : Montant des ventes de véhicules rouges ou bleus à Tours en 2008 : {<Montant, Rouge, Tours, 2008>, <Montant, Bleu, Tours, 2008>} = {r21, r22} Distance de Hausdorff entre requêtes : = 7 d_sp Hausdorff considère que 2 ensembles sont proches si chaque élément de l’un des ensembles est proche des éléments de l’autre ensemble. Utilisable car nos requêtes sont des ensembles de références. r11 r21 r22 q1 q2 5 7

15 Distance entre sessions (1)
1. Introduction 2. BDM 3. Intuitions 4. Recommandation 5. Expérimentations 6. Conclusion et Perspectives Sessions : s1 : q3 s2 : q1 → q2 Distance de Levenshtein entre sessions dLevenshtein(s1, s2) = dLevenshtein(q3, q1→q2) Opérations : Substitution d’une requête q par une requête q’ Insertion (suppression) d’une requête Possibilités : e1 : q q (q1→q2) e2 : q Ø q (q1→q2) Coût Si chaque opération vaut 1 coût(e1) = 2 < coût(e2) = 3 Distance entre sessions = coût minimal dLevenshtein(s1, s2) = 2 subst(q3,q1) ajout(q2) Calculer la distance entre 2 sessions s1 et s2 qui est le nombre minimal d’opérations nécessaires pour transformer s1 en s2 Operations autorisées : insertion, suppression et substitution suppr(q3) ajout(q1) ajout(q2)

16 Distance entre sessions (2)
1. Introduction 2. BDM 3. Intuitions 4. Recommandation 5. Expérimentations 6. Conclusion et Perspectives Distance entre sessions (2) Dans notre contexte : Coût des opérations : Substitution d’une requête q par une requête q’ = dH(q,q’) Ajout (suppression) de requête = α Exemple : Sessions : s1 : q3 s2 : q1 → q2 e1 : q q (q1→q2) dLevenshtein(s1, s2) = coût(e1) = dH(q1,q3) + α Alpha : pas détaillé ici mais il faut savoir que des tests nous ont permis de donner une valeur. Ici on utilise Hausdorff mais ca peut être n’importe quelle distance entre requêtes. subst(q3,q1) ajout(q2)

17 Présentation du cadre Match Rep
1. Introduction 2. BDM 3. Intuitions 4. Recommandation 5. Expérimentations 6. Conclusion et Perspectives Présentation du cadre Nous voulons aider l’utilisateur à avancer dans son exploration des données. Nous proposons donc d’exploiter ce que les autres utilisateurs du système ont fait durant leurs précédentes navigations dans le cube et d’utiliser ces informations comme base pour recommander ce que pourrait être la prochaine requête. A cet effet, nous présentons un cadre générique pour recommander des requêtes MDX qui utilise à la fois le log du serveur, c’est-à-dire l’ensemble des sessions de requêtes déjà posées pour naviguer dans le cube et la séquence de requêtes de la session courante. Le cadre que nous proposons repose sur le processus suivant : Prétraitement des logs Génération des recommandations candidates en cherchant d’abord les sessions qui coïncident le mieux avec la session courante puis en prédisant ce que pourrait être la prochaine requête Ordonnancement des recommandations candidates afin de présenter les requêtes à l’utilisateur par ordre d’intérêt Ce cadre est générique dans le sens où il n’impose pas de méthode spécifique de prétraitement des logs, de génération des recommandations candidates ou d’ordonnancement des candidats. Au lieu de cela, ces actions sont laissées comme paramètres du cadre qui, de fait, peut être instancié de différentes manières afin de changer la méthode de calcul des recommandations. Match Rep

18 dH(q3,q4) < dH(q3,q5) [Hamming]
1. Introduction 2. BDM 3. Intuitions 4. Recommandation 5. Expérimentations 6. Conclusion et Perspectives ClusterH Classes : c1={q1}, c2={q2,q22,q3,q32}, c3={q4}, c4={q5,q6} K-médoïdes K-médoïdes -> classes de requêtes On fait du clustering car faible densité des logs car intérêt des utilisateurs différents donc partie du cube exploré très différentes Médoïdes des classes en couleur <g2,3> : position du suffixe le plus long Suffixes de gc Médoïde du successeur dH(q3,q4) < dH(q3,q5) [Hamming]

19 1. Introduction 2. BDM 3. Intuitions 4. Recommandation 5. Expérimentations 6. Conclusion et Perspectives EdSP Identité Pas de clustering car dsession nous permet de gérer la problème de densité. On prend la session des logs qui matche le mieux avec la session courante Distance de Levenshtein Dernier

20 Plan Contexte / Problématique BD multidimensionnelles Intuitions
Recommandation de requêtes Expérimentations et Résultats Jjhhj Kjkjkjk Conclusion et Perspectives Expérimentations et Résultats Le système Notre générateur Les tests

21 Le système 1. Introduction 2. BDM 3. Intuitions 4. Recommandation 5. Expérimentations 6. Conclusion et Perspectives Cube de données stocké dans le SGBD MySQL via le serveur OLAP Mondrian qui est un serveur open source qui fonctionne avec MDX. Les sessions de requêtes des utilisateurs précédents ont été enregistrées dans un log de requêtes. Log + sc dans RecoOLAP qui interagit avec le serveur OLAP Mondrian Enfin, le système retourne à l’utilisateur l’ensemble ordonné des recommandations. Montrer à l’écran !!

22 Notre générateur Le cube Les sessions : Propriétés :
1. Introduction 2. BDM 3. Intuitions 4. Recommandation 5. Expérimentations 6. Conclusion et Perspectives Le cube Base de données FoodMart (OLAP Mondrian [Pentaho:2009]) Les sessions : 300 références max. par requête MDX X sessions Y requêtes max. par session Z dimensions pour le pool de départ Propriétés : Variation de la densité des logs générés grâce à Z Obtention des requêtes successives grâce aux opérateurs de Sarawagi (Diff, Relax, Excep) Données synthétiques car pas de Benchmark Nous générons des ensembles de sessions sur la BD FoodMart fournie avec le moteur OLAP Mondrian. Notre générateur utilise les paramètres suivant : un nombre X de sessions dans le log, un nombre maximal Y de requêtes par session, un nombre Z de dimensions dans le pool de départ pour jouer sur la densité du log. Foodmart = 13 dimensions, tirage aléatoire de deux dimensions parmi les Z pour créer la rpemière requête de la session. Ce générateur n’est bien entendu pas parfait…

23 Analyse de performance
1. Introduction 2. BDM 3. Intuitions 4. Recommandation 5. Expérimentations 6. Conclusion et Perspectives Analyse de performance Première expérience = évaluation du temps nécessaire pour générer une recommandation. Codage : manière + rapide de calculer dh que dsp Observations Augmentation linéaire du temps avec la taille des logs Temps acceptable < 1 sec. (sauf EdSP)

24 Validation croisée (1) qrec = qat sc = q1 → … → qn-1 → ? (qat) ?
1. Introduction 2. BDM 3. Intuitions 4. Recommandation 5. Expérimentations 6. Conclusion et Perspectives Log Sessions courantes de taille n Log initial sc = q1 → … → qn-1 → ? (qat) Notre seconde expérience consiste à mesurer le rappel et la précision des recommandations. Nous utilisons une validation croisée à 10 échantillons, inspiré par chatzopoulou (ssdbm09): l’ensemble généré de sessions est partitionné en 10 sous ensembles de tailles égales et, à chaque fois, 9 sous-ensembles sont utilisés comme log et chaque session du sous-ensemble restant est utilisée comme base de session courante. Plus précisément, pour chaque session sc de taille n, nous utilisons la séquence des n-1 requêtes comme session courante et nous calculons les recommandations pour la nième requête. Cette nième requête est appelée la requête attendue. Puis nous regardons dans quelle mesure les membres de la requête recommandée englobent les membres de la requête attendue. qrec = qat ?

25 Validation croisée (2) Exemple :
1. Introduction 2. BDM 3. Intuitions 4. Recommandation 5. Expérimentations 6. Conclusion et Perspectives Exemple : qat = {<Montant, Rouge, Blois, 2008>} qrech = {<Montant, Rouge, Tours, 2009>} Précision(qrech) = 2/4 = 1/2

26 Validation croisée (3) Observations :
Exemple : Densité forte : f=0.8 pour plus de 80% des sessions Densité faible : Clusterh : f=0.8 pour plus de 20% des sessions Edsp : f=0.8 pour plus de 45% des sessions Nuancer les résultats car générateur pas parfait Observations : x% des sessions ont une F-mesure ≥ y F-mesure augmente lorsque la densité augmente ClusterH : performances moins bonnes pour densité faible Distance de Hamming favorisée par calcul de rappel/précision

27 Plan Contexte / Problématique BD multidimensionnelles Intuitions
Recommandation de requêtes Expérimentations et Résultats Conclusion et Perspectives Conclusion et Perspectives

28 Conclusion Recommandation de requêtes MDX Expérimentations : RecoOLAP
1. Introduction 2. BDM 3. Intuitions 4. Recommandation 5. Expérimentations 6. Conclusion et Perspectives Conclusion Recommandation de requêtes MDX Méthode collaborative de guidage de l’utilisateur pour l’exploration de gros volumes de données Prétraitement du log de requêtes Génération de requêtes candidates Ordonnancement des recommandations candidates 4 instanciations Expérimentations : RecoOLAP Comparaison des différentes instanciations Efficacité de notre technique

29 Perspectives (1) Améliorer les performances du système
1. Introduction 2. BDM 3. Intuitions 4. Recommandation 5. Expérimentations 6. Conclusion et Perspectives Améliorer les performances du système D’autres types de recommandations Exemple : Sessions ne différant que d’une sélection Exemple edsp ou pour proposer une vraie architecture avec des index… Notre méthode collaborative nous permet de recommander des requêtes présentes dans le log alors que dans ce cas de figure, nous souhaitons recommander une requête qui n’existe pas dans le log, mais une modification d’une requête existante. Ceci pose en effet un certains nombres de problèmes, car ce n’est pas aussi simple qu’il n’y parait. Cette idée fait d’ailleurs l’objet d’une proposition de stage de M2. Recommandation

30 Perspectives (2) Expérimentations sur données réelles
1. Introduction 2. BDM 3. Intuitions 4. Recommandation 5. Expérimentations 6. Conclusion et Perspectives Expérimentations sur données réelles IRSA (Institut interRégional pour la SAnté) Elaboration des sessions en cours Contribution à un système collaboratif de gestion de requêtes Plateforme de génération de recommandations Adapter l’approche aux besoins des utilisateurs Diverses méthodes de calcul de sessions / requêtes candidates Prendre en compte les valeurs des mesures [Giacometti+:DOLAP’09] Diverses techniques (collaborative, contenu [Chatzopoulou+:SSDBM’09], prise en compte du contexte et du profil de l’utilisateur [Jerbi+:ICEIS’09, Bellatreche+:DOLAP’05, Golfarelli+:SSDBM’09]) Possibilités sophistiquées de gestion de requêtes [Khoussaïnova+:CIDR’09] Pb soulevé par Khoussaïnova:CIDR’09, nous voulons des logs conviviaux permettant de faire apparaitre les liens entre requêtes, les recommandations et qui soit facilement utilisable. Nos travaux de EDA’07 peuvent être étendu dans ce sens.

31 Merci de votre attention

32 ANNEXES

33 Défaveur de SP La requête attendue Les recommandations Raisons
qat = {<Montant, Rouge, Blois, 2008>} Les recommandations qrecoh = {<Montant, Rouge, Tours, 2009>} qrecosp = {<Montant, AllV, LoirEtCher, AllT>} Raisons dHh (qat, qrecoh) = = 2 dHsp (qat, qrecosp) = = 3 Précision = Précision(qrecoh) = 2/4 = 1/2 Précision(qrecosp) = 1/4

34 BD : Recommandation vs. Personnalisation
ajout de conditions de sélection en fonction du profil de l’utilisateur. La requête personnalisée est incluse dans la requête initiale. Q : ventes de véhicules à Tours en 2007 Q* : ventes de véhicules bleus ou rouges à Tours en 2007 Recommandation : La requête recommandée est : soit une requête issue d’un ensemble de requêtes, soit une requête calculée. La requête recommandée n’est pas forcément incluse dans la requête initiale. Q* : ventes de véhicules en région Centre en 2008

35 Combinaisons