Plan. Motivation. Les requêtes MDX considérées. Le profil utilisateur. Les contraintes de visualisation. La personnalisation.

Transcription

1 Personnalisation de requêtes MDX Ladjel Bellatreche 1 Arnaud Giacometti 2 Patrick Marcel 2 Hassina Mouloudi 2 1 LISI, Université de Poitiers 2 LI, Université François Rabelais de Tours BDA 2006

2 Plan Motivation Les requêtes MDX considérées Le profil utilisateur Les préférences Les contraintes de visualisation La personnalisation Conclusion

3 Motivation Exemple SELECT {[City].Tours,[City].Orleans}, {[Year].2003,[Year].2004,[Year].2005,[Year].2006}, {[Category].shoes,[Category].cloth, [Category].food,[Category].drink} FROM SalesCube WHERE [Measures].quantity Différentes visualisations possibles selon le profil

4 Motivation Problématique Pas de travaux sur la personnalisation de requêtes OLAP Particularités des requêtes OLAP : la requête porte sur des faits à différents niveaux de détail la requête comporte une partie mise en forme du résultat qu est-ce qu un profil utilisateur pour ce type de requêtes? peut-on calculer automatiquement la visualisation des faits préférés? ne pas accéder à la table des faits pour personnaliser

5 Motivation Objectif Étant donné : une requête MDX q des préférences utilisateur P une contrainte de visualisation v calculer q telle que : q q q est la plus proche de q satisfaisant v q est la plus intéressante au regard de P trouver q max P {q q v(q ) = true}

6 Les requêtes MDX considérées Les requêtes MDX Q MDX les requêtes MDX de forme : SELECT SX 1 ON AXIS(1),... SX K ON AXIS(K) FROM C WHERE SX K+1 soit q Q MDX, pour i [1,...,K + 1], SX i (q) est une requête de l algèbre relationnelle S i (q) est le schéma de cette requête ref i (q) est la réponse à cette requête schéma sch(q) = i [1,...,K+1] S i(q) structure struct(q) = S 1 (q),...,s K (q) références ref (q) = ref 1 (q)... ref K+1 (q)

7 Les requêtes MDX considérées Exemple SalesCube de schéma Product(Item,Category),Time(Day,Month,Year), Location(City,Region,Country),Measure(name), sales(item,day,city,name,val) q = SELECT FROM WHERE [City].members ON COLUMNS CROSSJOIN({[Year].2005,[Year].2006},{[Product].members}) ON ROWS SalesCube [Measure].quantity sch(q) = {Location,Time,Product,Measure} struct(q) = {Location},{Time,Product} ref (q) = π City (Location) {2005,2006} (π Category (Product) π Item (Product)) {quantity}

8 Le profil utilisateur Les préférences Les préférences Les préférences consistent en : un ordre partiel sur les dimensions : D < d D si D préférée à D pour chaque dimension D i, un ordre partiel sur les membres : m < i m si m préféré à m

9 Le profil utilisateur Les préférences Les préférences Les préférences consistent en : un ordre partiel sur les dimensions : D < d D si D préférée à D pour chaque dimension D i, un ordre partiel sur les membres : m < i m si m préféré à m On en déduit un ordre sur les références : (t,t ) les dimensions où t et t diffèrent M = max <d ( (t,t )) les dimensions préférées où t et t diffèrent t t si D i M,t(D i ) < i t (D i )

10 Le profil utilisateur Les préférences Ordre sur les requêtes L ordre sur les références fournit un ordre partiel sur les requêtes : pour q,q Q MDX : q q si sch(q) = sch(q ) et t ref (q), t ref (q ),t t q q si sch(q) = sch(q ) et quelque soit l instance de C, ref (q) ref (q ) L ordre sur les requêtes est tel que si q q alors q q

11 Le profil utilisateur Les préférences Exemple Soient les préférences : Location < d Time et Product < d Time 2005 < Time 2006, drink < Product food q 1 = SELECT FROM WHERE {[Year].2005} ON COLUMNS ({[Category].food, [Category].drink}, {[City].Tours}) ON ROWS SalesCube [Measure].quantity q 2 = SELECT FROM WHERE {[Category].drink} ON COLUMNS ({[Year].2006},{[City].Tours}) ON ROWS SalesCube [Measure].quantity

12 Le profil utilisateur Les préférences Exemple Soient les préférences : Location < d Time et Product < d Time 2005 < Time 2006, drink < Product food q 1 = SELECT FROM WHERE {[Year].2005} ON COLUMNS ({[Category].food, [Category].drink}, {[City].Tours}) ON ROWS SalesCube [Measure].quantity q 2 = SELECT FROM WHERE {[Category].drink} ON COLUMNS ({[Year].2006},{[City].Tours}) ON ROWS SalesCube [Measure].quantity car : ref (q 1 ) = { 2005,food,Tours,quantity, 2005,drink,Tours,quantity } ref (q 2 ) = { 2006,drink,Tours,quantity } et 2005,food,Tours,quantity 2006,drink,Tours,quantity 2005,drink,Tours,quantity 2006,drink,Tours,quantity

13 Le profil utilisateur Les contraintes de visualisation Contraintes Une contrainte v est : une fonction booléenne définie sur Q MDX anti-monotone si q,q Q MDX si q q et v(q ) = true alors v(q) = true Utilisation d un algorithme par niveau pour calculer le plus grand ensemble de références satisfaisant v

14 Le profil utilisateur Les contraintes de visualisation Contraintes Exemple de contrainte de visualisation anti-monotone : pour une structure T = T 1,...,T K et un tuple d entiers G = G 1,...,G K v T,G (q) = true si q contient K axes les dimensions de T k sont affichées sur l axe k l axe k ne comporte pas plus de Gk positions

15 La personnalisation Le principe Contexte : les tables de dimensions sont en mémoire pas d accès à la table de faits Pour une requête q, des préférences P et une contrainte v : 1. calcul des sous-ensembles de ref (q) les plus grands possibles visualisables selon v contenant les références préférées selon P 2. calcul des structures permettant de visualiser ces ensembles

16 La personnalisation L algorithme Les références de ref (q) peuvent être ordonnées des plus préférées (R 1 ) au moins préférées (R n ) : ref (q) = R 1... R n 1. M 0 = { } 2. pour i de 1 à n faire 2.1 prendre R i les préférées à l étape i 2.2 pour chaque R de M i 1 ajouter à M i l ensemble R R i tel que : R i est le plus grand sous-ensemble de R i tel que R R i satisfait v 3. pour chaque R de M n calculer les structures S permettant de visualiser R 4. construire les requêtes MDX à partir des couples R,S

17 La personnalisation Exemple La requête : SELECT FROM WHERE Les préférences : {[City].Tours, [City].Orleans}, {[Year].2003,[Year].2004,[Year].2005,[Year].2006}, {[Category].shoes,[Category].cloth,[Category].food,[Category].drink} SalesCube [Measures].quantity (Time < d Location) et (Product < d Location) 2002 < Time 2003 < Time 2004 < Time 2005 < Time 2006 electronics < Product shoes < Product cloth < Product food < Product drink (Centre < Location Tours) et (Centre < Location Orleans) quantity < Measures price La contrainte de visualisation : v T,G : T =, et G = 4,4

18 La personnalisation Exemple Etape 1 : R 1 = { 2006,drink,Orleans,quantity, 2006,drink,Tours,quantity } drink Orleans Tours 2006

19 La personnalisation Exemple Etape 2 : R 2 = { 2006,food,Orleans,quantity, 2006,food,Tours,quantity, 2005,drink,Orleans,quantity, 2005,drink,Tours,quantity } drink food Orleans Tours Orleans Tours

20 La personnalisation Exemple Etape 3 : R 3 = { 2005,food,Orleans,quantity, 2004,drink,Orleans,quantity, 2005,food,Tours,quantity, 2004,drink,Tours,quantity, 2006,cloth,Orleans,quantity, 2006,cloth,Tours,quantity } or on ne peut pas visualiser 3 années, 3 catégories et 2 villes drink food Orleans Tours Orleans Tours Tours Orleans food drink cloth

21 La personnalisation Exemple Etc. Au final une des requêtes générées est : SELECT FROM WHERE {[Year].2003,[Year].2004,[Year].2005,[Year].2006} ON COLUMNS CROSSJOIN({[City].Tours,[City].Orleans}, {[Category].food,[Category].drink}) ON ROWS SalesCube [Measures].quantity

22 Conclusion Conclusion et perspectives Contribution : un cadre pour la personnalisation de requêtes OLAP développement d un prototype pour applications mobiles

23 Conclusion Conclusion et perspectives Contribution : un cadre pour la personnalisation de requêtes OLAP développement d un prototype pour applications mobiles Perspectives : utiliser plutôt un langage clos! ajouter au profil des préférences sur la structure prendre en compte des contraintes telles que : le coût d évaluation de la requêtes la cardinalité de la réponse