Perso OLAP

Rpublique algrienne dmocratique et populaire
Ministre de lEnseignement Suprieur et de la Recherche Scientifique Universit de -MascaraFacult des Sciences et Technologie Dpartement de Mathmatique et dInformatique
MEMOIRE
Prsent pour obtenir le diplme
Magister en Informatique
(Option : Systmes d'Informations et de Connaissances)
Prsent Par
Mr. BENAOUDA Habib
THEME
Personnalisation des requtes

Soutenu le : 28/04/2010
Prsident : Rapporteur : Mr. LEHIRECHE Ahmed Mr. MALKI Mimoun
devant le jury compos de :

MCA MCA MCA MCB MAA Universit S.B.A Universit S.B.A Universit S.B.A Universit S.B.A Universit MASCARA
Examinateurs : Mr. BENSLIMANE Sidi Mohamed Mr. BENSABER Amar Djamel Mr. BENMIMOUN Youcef
Rsum
Le but de la personnalisation est de faciliter lexpression du besoin de lutilisateur et de lui permettre dobtenir des informations pertinentes lors de ses accs un systme dinformation. La pertinence de linformation se dfinit par un ensemble de critres et de prfrences personnalisables spcifiques chaque utilisateur ou communaut dutilisateurs. Les donnes dcrivant les utilisateurs sont souvent regroupes sous forme de profils. Le contenu du profil dun utilisateur varie selon les approches et les applications. Dans ce travail nous allons prsenter la personnalisation de linformation en faisant un tat de lart de la personnalisation dans les bases de donnes relationnelles et nous allons prsentons les travaux rcents de la personnalisation dans le domaine des bases de donnes multidimensionnelles et comment elle sadapte avec la nature particulire de cet axe de recherche. Comme proposition, on introduit un nouvel algorithme qui gnre pour une requte OLAP (ON-Line Analytical Processing) toutes les sortes daffichage possibles. Mots-Cls : personnalisation, prfrences utilisateur, relation de prfrence, Entrept de donnes, requte MDX, visualisation, structure, contraintes.
Abstract
The goal of personalization is to facilitate the expression of the need for the user and enable it to obtain relevant information in its access to an information system. The relevance of information is defined by a set of criteria and customizable preferences specific to each user or user community. Data describing users are often grouped in the form of profiles. The contents of the users profile vary depending on the approaches and applications. In this paper we will present the personalization of information through a state of the art of customization in relational databases, and we will present recent work of customization in the multidimensional databases field and how it fits with the particular nature of this research area. As proposed, we introduce a new algorithm that generates for an OLAP (OnLine Analytical Processing) query all kinds of possible visualisations. Keywords: personalization, user preferences, preference relation, data warehouse, MDX queries, visualization, structure, constraints.
Table de matires
Chapitre 01 : Introduction gnrale Chapitre 02 : La personnalisation de linformation
4 7
2.1 Introduction ..... 7 2.2 Dfinitions .. 7 2.2.1 La personnalisation .... 7 2.2.2 La Prfrence ... 9 2.2.3 Le profil utilisateur .... 9 2.3 La personnalisation de linformation ..... 11 2.4 Distinction entre les approches et les techniques de la personnalisation de linformation .... 12 2.4.1 Le filtrage des rsultats ... 13 2.4.2 Le re-ordonnancement des rsultats de la requte ... 14 2.4.3 La recommandation .... 16 2.5 Conclusion ....... 17
Chapitre 03 : La personnalisation dans les bases de donnes relationnelles

18 3.1 Introduction ...... 18 3.2 Dfinitions utiles et Concepts de base .. 20 3.3 Le profil utilisateur, dfinition, gestion et utilisation ... 24
3.4 La personnalisation de linformation : procds et techniques .. 26 3.4.1 Approche de [Koutrika et Ioannidis, 2004] .... 26 + [Koutrika et Ioannidis, 2005a] ... 28 + [Koutrika et Ioannidis, 2005b] .. 29 + [Koutrika et al, 2006] .... 29 3.4.2 Approche de [Agrawal et Wimmers, 2000] .. 30 3.4.3 Approche de [Chomicki, 2002] . 33 + [Chomicki, 2004] 35 + [Chomicki, 2006] 36 3.4.4 Approche de [Kieling, 2002] 36 + [Kieling, 2005] ... 39 + [Endres et Kieling, 2008a] ... 39 + [Endres et Kieling, 2008b] .. 40 3.4.5 Approche de [Das et al, 2006] . 42 3.5 Conclusion . 44
Chapitre 04 : La personnalisation des requtes OLAP
47
4.1 Introduction ..... 47 4.2 Les entrepts de donnes . 49 4.3 La personnalisation des requtes OLAP . 56 4.3.1 Personnalisation portant sur le schma de lentrept de donnes ... 56 4.3.1.1 Personnalisation base sur ladaptation .. 56 4.3.1.2 Personnalisation base sur la recommandation 57 4.3.2 Personnalisation base sur la recommandation des requtes OLAP . 60
4.3.3 Personnalisation base sur lenrichissement de la requte OLAP par les prfrences utilisateur en satisfaisant des contraintes sur la prsentation .. 63 4.4 Dfinitions et concepts de base . 65 4.5 Algorithmes pour la personnalisation .. 70 4.5.1 Approche de [Bellatreche et al, 2005] .. 70 4.5.2 Approche de [Bellatreche et al, 2006] .. 73 4.6 Conclusion .. 83
Chapitre 05 : Contribution
85
5.1 Introduction ..... 5 5.2 Lalgorithme FindStruct [Bellatrech et al.2005] 85 5.3 Lalgorithme POSSIBLE_STRUCTURES .. 87 5.4 Discrimination entre plusieurs ensembles de rfrences 96 5.5 Simplification de choix de lutilisateur pour une structure parmi un ensemble .. 97 5.6 Conclusion . 99
Chapitre 06 : Exprimentations
101
6.1 Prototype My Cube 101 6.1.1 Technologies employes 102 6.1.2 Principe de fonctionnement de base pour le systme de personnalisation My Cube . 103 6.1.3 Prsentation de prototype .. 105 6.1.4 Les diffrentes fentres de prototype ... 112 6.2 Exemples et discussions ... 117 6.2.1 Exemple 1 : Une seule requte, deux profils utilisateur, deux rsultats diffrentes .. 117
Discussion des rsultats ... 125 6.2.2 Exemple 02 : Discriminations et suggestions . 125 6.2.2.1 Discrimination entre les sous-ensembles de rfrences . 125 Discussion des rsultats .. 128 6.2.2.2 Suggestions pour un ensemble des structures proposes..129 Discussion des rsultats 132 6.3 Conclusion 132
Chapitre 07 : Conclusion et perspectives
134
7.1 Conclusion . 134 7.2 Perspectives ... 135
Bibliographie
137
Introduction gnrale
Chapitre 01 : Introduction gnrale

Malheureusement, ce nest pas tout le monde aime ce que vous aimez ! Ainsi, les choses qui attirent votre attention peuvent ne pas tre considres par les autres. a nimplique pas que vous avez des mauvais gots par rapport aux autres ou que vos choix sont males cibls, mais tout simplement et sans doute ce sont les diffrences demeures dans vos origines, comportements, orientations, localisations, situations ou dautres critres. Cest donc partir de ces critres de discrimination entre les choses que vos gots et vos choix ne correspondent pas obligatoirement ceux dsignant les autres. A cette fin, et lorsque vous tes charg de servir quelquun, autan mieux connatre ses prfrences pour donner a chacun ce quil veut et sans que vous le surcharger par les besoins des autres qui ne lintressent plus. Cest la meilleure dmarche pour garder vos partenaires et vos clients et gagner leurs confiances et garantir leurs fidlits. Si on bascule vers les industries daujourdhui, et exactement le domaine dinformatique, ces notions doivent tres bien matrises que ce soit dans le contexte des systmes dinformation dentreprise, du commerce lectronique, de laccs au savoir et aux connaissances ou mme des loisirs. A ce stade, linformation dlivre aux usagers doit satisfaire le maximum possible ses exigences et quelle soit adapts a leurs prfrences. Et pour arriver raliser cet objectif, lindustrie informatique adopte une technique appele la
personnalisation de linformation. La personnalisation a pour objectif de faciliter lexpression des besoins de lutilisateur afin de ne lui retenir que les informations qualifies pertinentes pour
4
Introduction gnrale un sujet donn en cartant ceux non pertinentes. Cependant, cette pertinence est dfinit par un ensemble de critres et de prfrences personnalisables et spcifiques chaque utilisateur ou communaut dutilisateurs et stocks dans une structure appele Profil Utilisateur. Dans ce contexte, plusieurs approches ont vu le jour, et chacune delles aborde la notion de personnalisation selon ses ides mais lobjectif commun est dacheminer des solutions efficaces vers la gamme des problmatiques relatives cet axe de recherche. Le but du prsent travail est de dcouvrir comment ce champ de recherche prend sa place dans les bases de donnes relationnelles progrs atteints dans ce domaine et les difficults rencontres. Ainsi, et comme les exigences danalyses dcisionnelles face lclatement du volume de donnes manipules donne lieu la mise en place des nouveaux concepts tels que Data Warhouses et OLAP (On Line Analytical Processing) qui sont rangs dans une nouvelle classe de bases de donnes dites multidimensionnelles et qui na pas bnficier parfaitement de la on parcourant les
personnalisation en raison de sa fracheur et surtout sa particularit, on a consacr dans ce travail une partie pour tudier les progrs brillants achevs dans ce champ de recherche ainsi que les obstacles rencontres et les perspectives proposes. Aprs avoir explor la personnalisation dans les bases de donnes multidimensionnelles (entrepts des donnes) et les travaux brillants
contribuant lavancement des recherches dans cet axe, on va proposer comme contribution un algorithme pour la gnration de lensemble de toutes les formes daffichage possibles que peut prendre le rsultat dexcution dune requte MDX. Dans ce mmoire on va considrer lorganisation suivante :
Introduction gnrale Dans le second chapitre, on introduit dune faon gnrale la notion de la personnalisation de linformation, ensuite le troisime chapitre prsentera ladaptation de cet outil dans les bases des donnes relationnelles. Le chapitre 04, aprs avoir prsent les notions de bases des entrepts de donnes et le concept OLAP, il rvlera comment les chercheurs de ce demain ont vu ce phnomne (personnalisation) et lessentiel de ses derniers rsultats atteints. Dans le chapitre 05, et comme contribution, on va prsenter un nouveau algorithme qui concerne la personnalisation de la forme daffichage pour le rsultat dexcution dune requte OLAP ainsi que quelques autres propositions pour llimination des rsultats nuls et le choix dune meilleur visualisation. Pour donner un aperu pratique sur la personnalisation des requtes OLAP tudi dans les chapitres prcdents, le chapitre 06 comportera une prsentation de notre prototype My Cube qui implmente les algorithmes de personnalisation, ainsi que des exemples illustratifs validant nos propositions. Le dernier chapitre comportera une conclusion synthtisant les principaux points attaqus et quelques perspectives pour les futurs travaux.
Chapitre 02
La personnalisation de linformation
Chapitre 02 : La personnalisation de linformation

2.1 Introduction Avant daborder la personnalisation de linformation, il est indispensable de dcouvrir les diffrentes concepts utiliss tel que la prfrence et le profil utilisateur, ensuite, nous allons prsenter la personnalisation de linformation dune manire gnrale, en citant ses techniques et approches et finalement on va voir comment les moteurs de recherches actuels pensent la personnalisation de linformation et leur impact. 2.2 Dfinitions 2.2.1 La personnalisation La personnalisation peut tre une action d'ordre matriel (modification impliquant une activit physique sur l'objet) ou phnomne psychologique quasi-anthropologique d'identification d'un artefact une forme humaine, une personne, une fonction sociale. Dans le langage courant moderne la personnalisation est l'appropriation d'un mdium lectronique, crit ou dun produit de consommation effectue selon des donnes personnelles fournies par un usager, ou par la volont de l'utilisateur lui-mme. Il y a trois grandes familles de personnalisations :
active : l'utilisateur prend en charge le produit manufactur et le modifie intuitivement ou logiquement pour l'adapter son utilisation.
Chapitre 02
passive : le fournisseur, l'industriel, le prestataire de service ajuste son produit finit en fonction de paramtres qui caractrisent ses utilisateurs.
interactive : La personnalisation de contenu est en train d'voluer trs grande vitesse grce aux progrs de l'interactivit et de l'intelligence artificielle : un produit peu tre livr "neutre" puis "apprendre" et s'autodesigner ou se reprogrammer au contact de l'usager alors simultanment actif et passif dans le processus de personnalisation interactif.
Dans le web, la personnalisation implique la cration automatique de pages web qui sadaptent aux intrts de linternaute. La personnalisation sorganise selon des donnes implicites (fureteurs, provenances, parcours observ dans un site, etc.) ou explicites (informations fournies par linternaute sur ses prfrences). Lexpression sur mesure est parfois utilise lorsquil est question de donnes explicites. Dans les mdias crits, que ce soit des magazines ou des publications promotionnelles, la personnalisation seffectue partir de bases de donnes dinformations et utilise parfois la technique de fusion de fichiers dans le marketing direct. Non seulement le document crit sadresse-t-il directement par son nom au lecteur concern, mais le contenu (les articles ou mme la publicit) est plus particulirement cibl selon les caractristiques de ce dernier. Le mme principe de personnalisation a t repris du reste par lindustrie de lobjet promotionnel (tasse, t-shirt, porte-cls, etc.), du jeu vido (par exemple, The Sims) ou mme de la littrature pour enfants qui offre maintenant des livres personnaliss - que lon pense aux ditions Lili et Lo ou Alphakid, livres personnaliss pour enfants au Canada qui, plus rcemment, personnalise les illustrations de ses livres. Des chercheurs associs des industriels font avancer la qualit de la personnalisation des artefacts en nourrissant l'espoir d'arriver un jour produire
8
Chapitre 02
des objets complexes standards (donc bon marchs pour une grande distribution) et aussi extrmement personnalisables, notamment le digital human laboratory a Tokyo et nombres d'tudes cognitives et sociologiques. [Jameson, 1999] 2.2.2 La Prfrence La prfrence est l'expression d'un choix, en raison de critres soit subjectifs (on parle alors de got, notamment en matire de prfrence sexuelle), soit objectifs, bass sur des critres clairement noncs. C'est aussi un concept, utilis en sciences sociales, particulirement en conomie. Plus gnralement, il peut tre vu comme une source de motivation. Par exemple, le bonheur est gnralement prfr la souffrance. De mme, consommer plus d'un bien est gnralement (mais pas toujours) prfr en consommer moins. Avoir un penchant, un faible, dsigne une orientation plus permanente, et non une prfrence ponctuelle et circonstancie. En microconomie, les prfrences du consommateur sont modlises grce des relations de prfrences. [Jameson, 1999]
2.2.3 Le profil utilisateur Ou encore modle utilisateur, est un ensemble de donnes qui concernent l'utilisateur d'un service informatique.
Chapitre 02
Outre les informations d'identification de base (par exemple, l'identifiant ou des lments d'tat civil), le profil utilisateur peut regrouper des informations trs diverses selon les besoins. Parmi celles-ci :
des
caractristiques
personnelles
pouvant
influencer
fortement
l'interaction (ge, sexe, etc.),
les intrts et les prfrences gnrales relatives la tche accomplir, qui permettent une adaptation aux attentes de l'utilisateur,
les comptences ou le niveau d'expertise relatifs la tche (pour dterminer par exemple un degr d'autonomie et dceler un besoin d'aide ou de formation),
le but courant de l'utilisateur (dont l'impact est fort, mais la dtermination souvent difficile),
sur les capacits non cognitives lies l'individu, par exemple pour adapter l'interface un handicap (ccit, surdit, handicap moteur, etc.)
un historique des interactions avec le service, qui peuvent permettre de modliser les habitudes comportementales
une mesure de l'tat psychologique (stress, fatigue, etc.) qui restent difficiles dterminer
Les donnes du profil utilisateur sont tre reprsentes diffremment selon les besoins. En gnral, on les stocke dans une table sous la forme de couples attribut-valeur o chaque couple reprsente une proprit du profil. Les proprits peuvent ventuellement tre regroupes par catgories. Les valeurs peuvent tre de tous types (numriques, alphanumriques) mais elles peuvent aussi stocker des distributions de probabilits (pour les services adaptatifs). Les donnes du profil utilisateur peuvent tre :
10
Chapitre 02

Renseignes par l'utilisateur lui-mme (profil rflexif) Renseignes par slection d'un profil pr-existant cr par des experts du domaine (profil expert)
Apprises par le systme au cours de l'utilisation (profil dynamique)
Il est aussi possible de partir d'un profil existant et de s'en servir comme prototype. Dans ce cas le prototype peut tre copi pour tre adapt. Cela offre l'avantage d'avoir des informations typiques et de les affiner au fur et mesure. [Jameson, 1999] 2.3 La personnalisation de linformation Il est difficile didentifier la personnalisation de linformation comme un domaine de recherche en soi puisquelle intervient dans de nombreuses technologies. La personnalisation de linformation a t particulirement aborde dans la communaut Recherche dInformation (RI), la communaut Bases de Donnes (BD) et la communaut de l'interaction Homme-Machine (IHM). Dans le domaine de la RI, lutilisateur fait partie du processus de personnalisation. Lvaluation dune requte se fait gnralement de faon interactive et incrmentale; chaque itration, le systme tient compte des informations collectes partir des interactions prcdentes avec lutilisateur ou profite de lexprience des autres utilisateurs (filtrage collaboratif). La personnalisation est ainsi dfinie comme un apprentissage ralis partir des prfrences rendues par les utilisateurs l'issue de la prsentation des rsultats successifs du systme. Dans le domaine des IHM, la notion de profil, souvent appel modle d'utilisateur, se focalise plus sur le niveau d'expertise et le mtier de l'utilisateur afin de dterminer le type de dialogue que le systme va avoir avec lui, les mtaphores graphiques les plus appropries ainsi que les modalits de livraison des rsultats qu'il attend du systme d'information.
11
Chapitre 02
Dans le domaine des BD, il nest pas courant dintgrer lutilisateur dans le processus de recherche dinformations. Une requte SQL contient en gnral lensemble des critres jugs utiles une slection de donnes pertinentes. Les profils sont alors intgrs directement aux requtes par les utilisateurs ou lors de la compilation de ces dernires; ils sont alors pris en compte en une seule fois durant le filtrage de l'information. [Bouzeghoub et Kostadinov, 2005]
2.4 Distinction entre les approches et les techniques de la personnalisation de linformation La personnalisation de linformation sexprime par un ensemble de critres et de prfrences spcifiques chaque utilisateur ou une communaut dutilisateurs. Les donnes dcrivant les prfrences des utilisateurs sont souvent sauvegardes sous forme de profils. Ils existent plusieurs faons de classifier les approches dexpression de prfrences. Selon le type de donnes utilises pour la comparaison de deux lments on distingue des prfrences intrinsques et extrinsques. Les prfrences intrinsques portent uniquement sur les valeurs des attributs dun lment tandis que les prfrences extrinsques prennent en compte des facteurs extrieurs comme lorigine dun lment. Une autre manire de classer les approches de personnalisation est base sur la manire de comparer deux lments. On retrouve ici lapproche qualitative o la prfrence est spcifie directement par des relations binaires de prfrence et lapproche quantitative o les prfrences sont exprimes indirectement par le biais de fonctions qui attribuent un nombre chaque lment et la pertinence dun lment dpend du nombre attribu. Lapproche qualitative est plus gnrale que lapproche quantitative car elle peut dfinir les relations de prfrences sur des fonctions numriques si elles sont
12
Chapitre 02
donnes explicitement, tandis que toutes les relations de prfrences ne peuvent pas tre captures par des fonctions numriques. Le besoin dadapter la manire de fournir les donnes aux besoins des utilisateurs est la raison, de plus en plus de systmes dinformation proposent des services adapts afin de mieux cibler leurs clients. Les services de personnalisation les plus couramment utiliss sont le filtrage du rsultat, le re-ordonnancement des lments du rsultat et la recommandation dlments. [Kostadinov, 2003]
2.4.1 Le filtrage des rsultats Le principe de base de cette approche est dexcuter la requte sans prendre en compte la personnalisation et ensuite appliquer un post traitement sur le rsultat afin dliminer les rsultats non pertinents pour lutilisateur. Le filtrage peut tre fait soit en appliquant des requtes supplmentaires sur le rsultat, soit en traitant chaque lment sparment afin dtudier sa pertinence. Un exemple de systme qui filtre les rsultats une fois la requte excute est CASPER(Case-Based Profiling for Electronic Recruitment) ( [Bradley 2000]). Cest un systme de recherche dannonces de travail. La requte de lutilisateur est value en deux tapes : extraction dannonces sur le serveur faite sur la base de similarit entre les termes et non sur un matching exact et filtrage des rsultats non-pertinents sur le client. Chaque annonce contient un nombre fixe d'attributs. Lors de la comparaison entre les termes de la requte de lutilisateur et les caractristiques des annonces sur le serveur on ne cherche pas un matching exact, mais une similarit qui dpasse un certain seuil afin dlargir lespace de recherche. Les termes sont reprsents dans des ontologies et la similarit entre deux termes est dfinie par la distance entre eux dans ces ontologies. Ensuite, les rsultats sont envoys vers le client. Ces rsultats contient un enregistrement des annonces qu'il a aimes et celles qu'il n'a pas apprcies. Grce ces enregistrements, on dtermine si un lment est pertinent ou pas et seuls les
13
Chapitre 02
annonces pertinentes sont affiches lutilisateur. La pertinence de chaque nouvelle annonce est dfinie sur la base de la pertinence des annonces les plus similaires dj traites. La similarit entre deux annonces est fonction des similarits des attributs de ces annonces. Un autre exemple est le systme MyGlobalNews ([Ferreira et Silvia, 2001]). C'est un systme de filtrage qui offre en plus des services de souscription et notification des utilisateurs des vnements qui peuvent les intresser (dissmination de l'information). La manire de filtrer les rsultats est la mme que celle dcrite dans lexemple prcdent. La requte de l'utilisateur est remplace par son profil et le systme va calculer le matching entre le profil et les documents. Les profils des clients ainsi que les documents sont reprsents par des vecteurs de mots cls qui rend possible la comparaison entre les deux. Seuls les documents dont le matching dpasse un certain seuil sont inclus dans le rsultat. Leur nombre ne dpasse pas celui donn dans le profil. Lavantage du filtrage des rsultats est sa simplicit parce quil ne ncessite aucune modification du fonctionnement des fournisseurs dinformation. Tout le traitement est fait aprs lexcution de la requte. Les inconvnients sont le volume de donnes changes entre le serveur et le client et le risque dlimination dlments pertinents. Le filtrage des rsultats se fait le plus souvent sur le cot client donc on a un gros transfert de donnes et en plus il y a un risque de suppression dobjets pertinents par le fait que les lments du rsultat qui sont jugs non intressants sont limins dfinitivement. [Kostadinov, 2003]
2.4.2 Le re-ordonnancement des rsultats de la requte Le principe du re-ordonnancement est de modifier lordre de laffichage des rsultats pour le client. Il sagit dun post traitement qui, tant donn les lments retourns par une requte, essaie de trouver une manire dchanger leurs emplacements en fonction des prfrences de lutilisateur sans pour autant
14
Chapitre 02
ngliger lordre qui a t attribu aux objets du rsultat par le moteur de recherche. Lchange de lordre dapparition des lments du rsultats est fait gnralement en appliquant une fonction qui permet de calculer le nouveau rang de lobjet. Un exemple de fonction permettant deffectuer le re-ordonnancement est donn par [Pretschner et Gauch, 1999]. On considre que chaque document est caractris par les quatre catgories les plus significatives qui dcrivent son contenu. Les catgories sont des mots cls et leur signification est calcule par la frquence dapparition de ces mots cls dans le texte. Dans ce cas le nouveau rang dun document di not (di) est fonction du rang qui lui a t attribu par le moteur de recherche ((di)), de lintrt que lutilisateur porte aux quatre catgories les plus significatives (cj) (le poids que lutilisateur donne ces mots cls) et au niveau auquel les catgories dcrivent le contenu ((cj,di)).
(di ) = (di ) 0.5 + 1 4 ( (ci ) (ci, di ))
i =1
i =4
Dans cette formule (di) est lancienne position du document di, ((cj, di) est la frquence dapparition du terme cj dans le document di Le systme extrait les termes des documents les plus significatifs sur la base des frquences TF-IDF . Pour un utilisateur donn lintrt quil porte une catgorie est calcul en fonction du temps quil a pass sur le document et la longueur du document (en nombre de caractres). Initialement cet intrt est gal zro et priodiquement le systme analyse les documents visits pour mettre jour les valeurs des intrts du profil. Une des formules qui servent calculer lajustement de lintrt i(ci) pour la catgorie ci est:
i (ci ) = log temps (ci, d ) log longueur
Les autres formules ressemblent celle-ci et la seule chose qui change est lexpression du logarithme :
log temps temps temps temps est remplac par : log , log ou log longueur log(log temps ) temps temps 15
Chapitre 02
Dans ce cas lintrt que lutilisateur porte sur les quatre catgories les plus significatives pour un document ((cj)) est donn par les valeurs actuelles de ces catgories dans le profil. Le re-ordonnancement des rsultats de la requte a le grand avantage de ne pas exclure des lments du rsultat. Cest en quelque sorte une garantie que lutilisateur va trouver ce qui lintresse et le seul objectif de cette approche est de faire gagner du temps aux clients. Cest une technique trs peu utilise dans les systmes de personnalisation parce quelle ncessite le calcule du nouvel rang de chaque lment du rsultat ce qui demande beaucoup du temps. [Kostadinov, 2003]
2.4.3 La recommandation La recommandation est un service de personnalisation qui consiste proposer lutilisateur des lments vis vis de ses prfrences ou en se servant de lexprience des autres utilisateurs. GroupLens ([Fink 2000]) est un exemple de systme de recommandation. Dans ce systme lutilisateur donne explicitement des notes aux lments quil consulte ou le systme devine son intrt pour les lments sur la base de ses activits passes. GroupLens offre des services de recommandation sur la base de la gestion de groupes d'utilisateurs ayant les mmes intrts. Il propose trois types de recommandations : personnelle, anonyme et consultation rapide. Comme dans lexemple prcdent lorsque le systme dispose de suffisamment dinformations sur le client, il est capable de lui fournir des recommandations personnelles sur la base de ses activits passes sans prendre en compte les autres utilisateurs. Par contre si le systme manque dinformations sur le client, il cherche quel groupe le client pourrait appartenir et fait des recommandations collaboratives en lui proposant des lments que les utilisateurs du groupe ont apprcis et que le client na pas encore consult.
16
Chapitre 02
La recommandation personnelle et collaboratives demandent beaucoup du temps de calcul. Lorsque le systme doit fournir une rponse rapide, il fait des recommandations sur la base des affinits prdfinies entre les produits sans prendre en compte les apprciations des utilisateurs. Par exemple un utilisateur qui achte un camra se verra proposer des cassettes et des piles appropries. La recommandation dlments est la technique de personnalisation la plus utilise par les systmes actuels. Elle a lavantage de pouvoir rpondre aux demandes des nouveaux utilisateurs et de fournir aux utilisateurs des rsultats sans les borner dans leur choix. Cette approche est aborde principalement dans le domaine de la recherche dinformation parce quil manque la notion de requte (lutilisateur est uniquement guid) et la recommandations se fait au cours dune session et pas sur une simple demande. [Kostadinov, 2003].
2.5 Conclusion Le but de ce chapitre est de mieux shabitu avec la notion de personnalisation dune faon gnrale travers les diffrentes manipulations de ce concept (personnalisation) par les diffrentes disciplines, ainsi que les objectifs viss daprs lintgration de la personnalisation dans ces derniers. Dans le chapitre suivant nous allons aborder limpact de ce paradigme dans le domaine des bases de donnes relationnelles merges dans cet axe de recherche. et la gamme des approches
17
Chapitre 03
La personnalisation dans les bases de donnes relationnelles
Chapitre 03 : La personnalisation dans les bases de donnes relationnelles
3.1 Introduction Un des points critiques de l'volution informatique est l'accroissement du volume d'information de manire exponentielle. Ce phnomne est d au progrs atteint en terme des capacits de calcul et de stockage. Pour contrecarrer les difficults engendres par cette surcharge informationnelle et afin daffronter toutes les obstacles rencontres dans ce contexte, il est indispensable de dvelopper des techniques et des outils informatiques efficaces et robustes pour faciliter la recherche et lextraction rapide des informations, ou damliorer ceux existants afin les sadapter avec les nouvelles exigences imposes par ce nouveau phnomne. Parmi les outils informatiques qui vus comme le grand espoir pour demain dans ce domaine, en distingue la personnalisation qui consiste ne retenir lutilisateur que les informations vus pertinentes ces souhaits. Cette pertinence en question est obtenue en exploitant lensemble de critres et de prfrences spcifiques chaque utilisateur ou communaut dutilisateurs afin de faciliter lexpression du ses besoins, amliorer ses possibilits
dinteraction avec un systme donn et de lui permettre dobtenir des informations pertinentes lors de ses interactions avec un systme dinformation. Les critres et les prfrences utilisateur sont souvent regroupes dans une structure appele profile utilisateur qui considr son tour comme un autre problme en terme de son organisation et sa structuration.
18
Chapitre 03
Dans ce contexte, il y a autant des approches qui contribuent la rsolution de ce problme chacune selon ces ides bases sur des angles de visions
diffrentes. Cependant, les progrs raliss dans ce stade narrivent pas contenir la totalit des problmes lis la personnalisation. Lunique objectif de ces approches est de fournir une rponse rapide, rduite, utilisable et adapte aux souhaits de lutilisateur en fonction de ses prfrences, soit en personnalisant le contenu de la rponse ou sa mise en forme. La procdure peut tre procde soit par la transformation de la requte ou la transformation de la rponse la requte. Pour le premier cas, la requte utilisateur est enrichie avec le profil puis elle est excute par le systme pour fournir la rponse personnalise, tandis que dans le second, la requte utilisateur est excute par le systme puis la rponse est filtre ou rordonne pour aboutir la rponse personnalise. On peut diviser les travaux sur la personnalisation en deux secteurs. Les auteurs de premier secteur comme dans les travaux de
[Bouzeghoub et Kostadinov, 2005] sintressent plus en plus au profil utilisateur et tous ce quils dpend (sa dfinition, son contenu, sa gestion et son
utilisation), et dans le second, les auteurs battrent la procd de personnalisation elle-mme on essayant toujours damliorer le processus de personnalisation comme cest le cas dans les travaux de [Koutrika et Ioannidis, 2004], [Chomicki, 2002], [Kieling, 2002], [Agrawal et Wimmers, 2000] et dautres. Dans le reste de ce chapitre nous allons partis de quelques notions et concepts de bases lies a cet axe de recherche, passons par le profil utilisateur et tous ce quil dpend et juste aprs il sera lieu un tat de lart concernant la personnalisation de linformation dans les bases de donnes relationnelles pour arriver finalement a dcouvrir les bases de donnes multidimensionnelles et ces particularits par rapport aux celles relationnelles, et comment elles intgrent la personnalisation a travers les travaux rcents achevs dans ce domaine.
19
Chapitre 03
3.2 Dfinitions utiles et Concepts de base Nous allons prsenter dans cette section, toutes les notions de base autour le concept prfrence et la relation quelle modlise. Relation binaire : Une relation binaire R sur un ensemble E est un sousensemble du produit cartsien E E, cest--dire un ensemble de couples (x, y) dlments de E. Si un couple (x, y) appartient la relation R, on notera x R y au lieu de (x, y) R dans ce qui suit. Une relation binaire peut possder les proprits de base suivantes. On dit que la relation R sur E est : rflexive si pour tout x E, x R x irrflexive si pour tout x E,(x R x) symtrique si pour tout x, y E, x R y y R x antisymtrique si pour tout x, y E, x R y et y R x x = y asymtrique si pour tout x, y E, x R y (y R x) connexe si pour tout x, y E, x , y x R y ou y R x complte si pour tout x, y E, x R y ou y R x transitive si pour tout x, y, z E, x R y et y R z x R z ngativement transitive si pour tout x, y, z E,(x R y) et (y R z) (x R z) Relation dindiffrence : tant donne une relation R sur un ensemble E, la relation dindiffrence note R est dfinie pour tout x, y E par : x R y si x R y y R x Notons que la relation dindiffrence R est symtrique. Relation dincomparabilit : Etant donne une relation R sur un ensemble E, la relation dincomparabilit note R est dfinie pour tout x, y E par : x R y si (xRy) (yRx)
20
Chapitre 03
On note que la relation dincomparabilit R est symtrique. Relation de prfrence : Une relation de prfrence sur un ensemble dlments E est une relation binaire. Dans ce cas, tant donne une relation de prfrence note R : x R y signifie que x est strictement prfr y, x R y signifie que x et y sont galement prfrs, et enfin x R y signifie quil ny a ni indiffrence, ni prfrence entre x et y et on dit que x et y ne sont pas comparables. Relation dordre : On appelle relation dordre sur un ensemble E toute relation binaire sur E qui est rflexive, antisymtrique et transitive. En particulier, si la relation dordre est complte alors lordre est dit total, sinon cest un ordre partiel. Pr-ordre : Un pr-ordre sur un ensemble E est une relation binaire rflexive et transitive. A une relation dordre on peut associer une relation obtenue en restreignant celle-ci aux couples dlments distincts. Relation dordre strict : Une relation dordre strict sur un ensemble E est une relation binaire irrflexive et transitive. Lordre strict est dit faible, sil est partiel et ngativement transitif. On utilisera le symbole pour reprsenter une relation dordre et le symbole > pour reprsenter une relation dordre strict. Fonction dutilit : Une fonction dutilit est une faon dattribuer des valeurs aux lments dun ensemble de telle sorte que les lments les plus intressants reoivent des valeurs suprieures ceux qui le sont moins. Formellement, une fonction dutilit u est une fonction dfinie de E vers [0,1] : u : E [0, 1] x u(x)
21
Chapitre 03
On note que pour toute fonction dutilit u, on peut associer une relation dordre total u dfinie pour tout x, y E par : x u y si u(x) u (y)
On note aussi que dans cette reprsentation par une fonction dutilit, deux lments de mme utilit sont considrs comme indiffrents. Combinaison de relations de prfrence Les relations de prfrence peuvent tre composes de plusieurs manires. On distingue gnralement des compositions unidimensionnelle et
multidimensionnelle : 1. composition unidimensionnelle : les relations de prfrence composes sont dfinies sur un ensemble. Le rsultat de cette composition est une nouvelle relation de prfrence dfinie sur le mme ensemble. tant donnes deux relations de prfrence 1 et 2 sur un ensemble dlments E, le rsultat dune composition unidimensionnelle de 1 et 2 est une autre relation 12 sur E. Des exemples de compositions sont la composition boolenne (union, intersection et diffrence), la fermeture transitive et la composition prioritaire. Composition boolenne : La relation 12 est obtenue de faon classique en calculant lunion, lintersection ou la diffrence des relations 1 et 2. Composition prioritaire : Cest la composition de prfrences prioritaires dites aussi prfrences hirarchiques. Soient 1 et 2 deux relations sur E, la composition prioritaire 1 et 2, note 12 = 1 2, est la relation de prfrence dfinie par : pour tout x, y E, x 12 y x 1 y (x 1 y x 2 y) [Chomicki, 2003] La relation de prfrence prioritaire 12 obtenue par cette composition signifie que 1 est plus importante que 2. 2. composition multidimensionnelle : partir des relations de prfrence dfinies sur des ensembles diffrents, on dfinit une nouvelle relation de prfrence sur le produit cartsien de ces ensembles. tant donnes deux relations de prfrence 1 sur E1 et 2 sur E2, le rsultat dune composition
22
Chapitre 03
multidimensionnelle de 1 et 2 est une relation de prfrence 12 sur E1E2. La composition multidimensionnelle permet ainsi de dfinir des relations de prfrence sur des ensembles de tuples partir de relations de prfrence sur des ensembles dlments atomiques. Des exemples de compositions multidimensionnelles sont la composition Pareto et la composition lexicographique. Composition Pareto : Cest la composition de prfrences de la mme importance. Soient deux relations de prfrence 1 sur E1 et 2 sur E2, la composition Pareto de 1 et 2, note 12 = 1 2, est une relation de prfrence dfinie par : pour y2 (x1 1 y1 x1 1
tout x = (x1, x2) et y = (y1, y2) lments de E1 E2, x 12 y (x1 1 y1 (x2 2 y2 x2 2 y2)) (x2 y1)) o 1 {1 , =}, 2 { 2 , =}, c.--d. lincomparabilit ([Chomicki, 2003]) ou lgalit ([Kieling et Kstler, 2002]). La composition Pareto signifie que 1 et 2 sont galement importantes. Composition lexicographique : Cest la composition de prfrences selon un ordre lexicographique. Cette composition peut tre dfinie comme suit : Soient deux relations de prfrence 1 sur E1 et 2 sur E2, la composition lexicographique de 1 et 2 , note 12 = L(1 , 2 ), est la relation de prfrence dfinie par : pour tout x = (x1, x2) et y = (y1, y2) lments de E1E2, x 12 y x1 1 y1 (x1 1 y1 x2 1 y2) o 1 {1, =}. Prfrences entre les sous-ensembles dun ensemble : Supposons que X et Y soient ces deux sous-ensembles sur lesquels un utilisateur doit exprimer ses prfrences, comment dfinir une relation de prfrence pour les comparer ?
2
23
Chapitre 03
Nous donnons maintenant un exemple de dfinition dune relation de prfrence s sur P(E) partir dune relation de prfrence E sur E. Pour tous sousensembles X et Y de E, on dit que X est prfr Y, not X s Y, si : pour tout y Y, x X | x E y Notons que si E est un ordre partiel sur E alors s est un ordre partiel sur P(E). On a vu dans la section prcdente comment on peut dfinir des relations de prfrence sur des lments dun ensemble, sur des tuples et sur des ensembles dlments. On va voir maintenant, dans la section suivante, comment on peut utiliser ces relations de prfrence pour remplir le profil utilisateur et dans le processus de personnalisation.
3.3 Le profil utilisateur, dfinition, gestion et utilisation Il y a plusieurs dfinitions de profils que dapplications. On distingue deux approches diffrentes et complmentaires: La premire est plus simple, elle est base sur linstanciation d'un modle gnrique de profils et consiste en une identification et une modlisation conceptuelle des diffrents attributs de profils. Elle a l'avantage d'une implmentation rapide mais a l'inconvnient d'tre borne par les seuls types d'informations prvus. La seconde approche est base sur la spcification au moyen d'un langage de description de profils. Elle est plus ouverte mais il est plus difficile de trouver un langage uniforme en raison de la grande diversit des informations constituant un profil. En tout tat de cause, mme l'approche langage ncessite une identification des types d'information constituant un profil. Le contenu de profil varie selon le domaine dapplication et les donnes quils caractrisent sont utilises diffrents moments du cycle de recherche
24
Chapitre 03
dinformations. Elles peuvent jouer le rle de substituant de la requte initiale et donc devenir elles-mmes la requte excuter, elles peuvent servir pour enrichir le contenu de la requte ou encore tres utilises pour adapter les rsultats selon les modalits de prsentation. En rgle gnrale, elles peuvent aussi influer sur l'excution de la requte sans ncessairement intervenir dans l'expression de celle-ci. Dans le domaine dIHM, et lorsque le principal but est de faciliter linteraction de lutilisateur avec le systme a travers une interface lisible et claire, les informations concernant lutilisateur (ge, niveau dexpertise, handicaps etc.) ou dautres concernant la technologie quil utilise (type du media, logiciels etc.) peut font partie de profil utilisateur en prcisant ces prfrences lies ses informations. Le profil de lutilisateur dans le domaine de la RI, est gnralement
dfini l'aide d'un vecteur de mots cls avec ventuellement un poids associ chaque mot [Fereira et Silva, 2001], [Pretschner et Gauch,1999], [Crabtree et Soltusiak, 1998], [Croft et Cronen, 2001]. Son contenu est souvent utilis pour remplacer la requte de lutilisateur [Ferreira et Silva, 2001] ou pour rajouter des mots cls supplmentaires. Dans le domaine des BD, le profil de lutilisateur contient des donnes qui expriment ses habitudes, des prdicats frquemment utiliss dans ses requtes ou des dfinitions d'ordre dans les prdicats. Lintrt de
lutilisateur pour chacun de ces lments est exprim par un degr qui est un nombre rel compris entre 0 et 1. Dans ce contexte, le travail ralis par [Koutrika et Ioannidis, 2004] propose une approche denrichissement de la requte de lutilisateur par de nouveaux critres de slection contenus dans son profil. Ceci est fait en deux tapes : (i) slection des k-meilleurs critres du profil de lutilisateur, et (ii) intgration des
25
Chapitre 03
critres slectionns dans la requte en spcifiant le nombre minimal (L) de critres dont lintrt est infrieur 1 qui doivent tre satisfaits. 3.4 La personnalisation de linformation : procds et techniques Mme si le but est unique et qui consiste ne retenir lutilisateur que des rponses pertinentes satisfaisant ses prfrences lors de ses interactions avec les systmes, les chercheurs empruntent diffrentes chemins suivant des visions diverses pour aboutir cet objectif. A ce stade, nous allons prsenter lensemble des approches dans ce domaine en explorant les efforts effectus par les acteurs de la communaut de base de donne dont lobjectif est datteindre le maximum avantage attendu de la personnalisation. On peut distinguer deux types des approches : les approches qualitatives et les approches quantitatives. Le premier type est bas sur lutilisation des relations de prfrences pour exprimer ces prfrences, tandis que le seconde est bas sur des fonction de scores (fonctions dutilits). Les approches en question sont celui de [Koutrika et Ioannidis, 2004], [Chomicki, 2003], [Kieling, 2002], [Agrawal et Wimmers, 2000],
[Das et al, 2006].
3.4.1 Approche de [Koutrika et Ioannidis, 2004] Dans cette approche, lexpression des prfrences est base sur les fonctions de score. Son principe est denrichir la requte (de type Select-Project-Join) avec les prfrences utilisateur que contient son profil afin que lvaluation de requte tienne compte ces prfrences. Exemple 1 Considrons une base de donnes Cinma dcrite par le schma cidessus. Les cls primaires sont soulignes. THEATRE(tid, name, phone, region),
26
Chapitre 03
PLAY(tid, mid, date), MOVIE(mid, title, year), CAST(mid, aid, award, role), ACTOR(aid, name), DIRECTED(mid, did), DIRECTOR(did, name), GENRE(mid, genre) Soient deux utilisateurs, Julie et Rob qui veulent savoir les filmes passant ce soir. Typiquement, cela se fait travers une interface simple, qui transforme ses demandes en une requte de la forme : select MV.title from MOVIE MV, PLAY PL where MV.mid=PL.mid and PL.date=2/7/2003 Cependant, Julie aime des comdies et des romans suspense, tandis que Rob aime les filmes du sci-fi et lactrice J. Roberts. Les prfrences de chacun des deux utilisateurs peuvent tre stockes dans un profil utilisateur afin que les intgrer automatiquement par le systme dans la requte originale. Cette ide permet davoir des rsultats classifis selon les intrts de chaque un des utilisateurs comme le montre la figure suivante :
Figure 1. Prfrences de Julie et Rob. Formellement, les prfrences sont reprsentes par des fonctions de score qui associent des degrs dintrt des requtes. Ces prfrences dfinissent un ordre total sur des requtes et sont stockes dans des profils utilisateurs. Les conditions de slection dune requte sont marques par des degrs dintrt
27
Chapitre 03
dans lintervalle [0,1]. Dans ce cas, en peut comparer deux requtes sans accder aux donnes, et une requte avec un degr dintrt plus lev est qualifie plus intressante quune autre. Les prfrences sont dites atomiques et sont de la forme <q, d> avec q la condition atomique et le degr dintrt d [0, 1]. Il y a un autre type de prfrences drives des prfrences utilisateur atomiques dites prfrences implicites. Dans cette approche, le processus de personnalisation est bas sur un mcanisme de rcriture de requte. Etant donne une requte et un ensemble de prfrences utilisateur. Ce dernier est utilis pour modifier la requte laide de ce mcanisme qui va enrichir la requte par les prfrences et ensuite la excuter. Plus prcisment, tant donns une requte Q et un profil utilisateur U o sont stockes les prfrences atomiques (slection atomique et jointure, arrtes dans le graphe de personnalisation), soit P lensemble de prfrences de slections extraites partir de U et lies Q. Une requte personnalise, note Qx, est une combinaison de Q et dun sous-ensemble Px de P telle que : Qx := Q Px On note que dans cette approche la rponse peut tre vide puisque la personnalisation est faite sans accs aux donnes. Ce model de prfrence est la base des autres travaux rcents de mme auteurs qui sont : + [Koutrika et Ioannidis, 2005a] : ce travail est une continuation de [Koutrika et Ioannidis, 2004] o la personnalisation de requte prendre en considration dautres contraintes comme le temps dexcution dune requte et/ou la taille des rsultats qui peuvent tre imposes par le contexte de la recherche, tel que le dispositif utilis, la connexion rseau, etc. Par exemple, si lutilisateur accde linformation en utilisant un tlphone mobile, il est prfrable de construire une requte personnalise qui sexcute rapidement et retourne des rponses courtes. Lapproche en question est appele CQP(constrained query personalization) et
28
Chapitre 03
consiste intgrer dynamiquement aux requtes fournies et sous forme de paramtres, lintrt de lutilisateur et les contraintes sur le temps et la taille de la rponse. Une requte Q dans cette approche est caractrise par le cot dexcution Cost(Q), la taille du rsultat Size(Q) et le degr dintrt Doi(Q) : Doi : par dfinition, personnalisation de requte mne produire des rsultats qui intressent lutilisateur. Donc, le paramtre Doi doit tre maximis ou satisfaire une borne infrieure. Cost : par nature, le cot dexcution doit tre maximis ou satisfaire une borne suprieure. Size : par dfinition, la personnalisation de requte mne des petites rponses. Dans lautre partie, des rponses vides sont toujours indsirables. Par consquent, le paramtre taille (Size) doit toujours satisfaire une borne infrieure (par dfaut 1) et possible une borne suprieure. + [Koutrika et Ioannidis, 2005b] : elle considre comme amlioration de [Koutrika et Ioannidis, 2004] on formulant des prfrences qui ne sont pas considres par lancien travail dans lesquelles seules les prfrences dites positives et exactes de prsence sont prises en compte. Ces prfrences sont du type : I like actor W. Allen. Le nouveau type de prfrence considr est : prfrence variable : I like films with duration around 2h, prfrence ngative : I do not like thrillers ou concernant labsence des valeurs : I like movies without violence. + [Koutrika et al, 2006] : dans ce travail, la rponse une requte donne est compose de linformation qui vrifie les conditions de slection de la requte dune part, et elle peut contenir linformation implicitement lie la requte dautre part (recommandation). Par exemple Si un utilisateur recherche des informations en fixant uniquement la condition Woody Allen, une rponse possible peut tre de la forme suivante
29
Chapitre 03
: Woody Allen was born on December 1, 1935 in Brooklyn, New York, USA. As a director, Woody Allens work includesMatch Point (2005), Melinda and Melinda (2004), Anything Else (2003). As an actor, Woody Allens work includes Hollywood Ending (2002), The Curse of the Jade Scorpion (2001). C.-d., le sous-schma du schma de la base de donnes rpondant la condition de slection Woody Allen ainsi que toutes les donnes relatives cette information (telles que les films dans lesquels il a jou ou ceux quil raliss, etc.). 3.4.2 Approche de [Agrawal et Wimmers, 2000] Cette approche est base sur les caractristiques suivantes : Un utilisateur exprime la prfrence pour une entit en fournissant des scores numriques entre 0 et 1, ou des veto, ou explicitement nonant l'indiffrence. Par dfaut, indiffrence est suppos. Ainsi, un utilisateur nonce ses prfrences seulement pour les entits de lenvironnement quil entour. Une entit est dcrite par un ensemble des attributs nomms, chaque attribut peut prendre des valeurs de certains types. Le symbole * peut tre employ pour dsigne n'importe quel lment de ce type. Par exemple, (peinture, cubiste, *) se rapporte n'importe quelle peinture cubiste, (peinture, *, Picasso) se rapporte les peintures de Picasso, et (*, *, de Picasso) se en rapporte un dessin de modle de Picasso. Les prfrences peuvent tre combines laide dun oprateur
gnrique. Ce dernier permet de combiner des fonctions de prfrence dun mme utilisateur ou de plusieurs utilisateurs, pour avoir une nouvelle fonction de prfrence et obtenir un score final. Les spcifications des prfrences sont dcouples de la faon dont elles sont combines. Les mmes prfrences peuvent tre combin dans diffrentes manires en selon l'application.
30
Chapitre 03
L'autonomie de diverses prfrences est prserve. Le prfrence pour une entit peut tre chang sans affecter les scores des entits indpendantes. L'opration de combinaison est caractrise par la proprit de fermeture transitive de sorte que le rsultat de combinaison de deux prfrences puisse tre encore combin avec une autre prfrence. Daprs ces caractristiques, la relation de prfrence est un ordre total. Ainsi, les prfrences dun utilisateur sont dfinies en utilisant des fonctions de score qui associent des degrs dintrt aux tuples et pas aux requtes comme cest le cas pour lapproche prcdente. Le principe est de comparer les tuples en fonction de scores quils possdent aprs le calcul de la rponse la requte afin de dire quun tuple est prfr un autre sil dispose le score le plus lev. Lobjectif est de dterminer les meilleurs tuples (ou les Top-K tuples) de la rponse une requte utilisateur en se basant sur le profil : {<t, score> | ( <t, score>)(score > score)} Une prfrence est exprime par lutilisateur sur une entit (ou une relation) donne dcrite par un ensemble de noms dattributs. Chaque attribut prend ses valeurs dun type donn (ints, strings, floats, booleans, etc.). La prfrence est dfinie sur les attributs et quantifie en score. Elle est note par <tuple, score>, avec score [0, 1] {,} (score = 1 : niveau le plus lev de prfrence, score = 0 : niveau le plus bas de prfrence, score = : reprsente un veto et score = : aucune prfrence nest indique). Exemple 2 Soit la relation Book(Title,Vendor,Price), la prfrence pour un prix de valeur 10 de nimporte quel vendeur et de nimporte quel titre dun livre est de 0.8 et qui est donne par {, , 10, 0.8}. La notion de fonction de prfrence est introduite et permet de spcifier des prfrences utilisateurs. Elle est dfinie comme suit.
31
Chapitre 03
- Fonction de prfrence : Une fonction de prfrence est une fonction qui fait correspondre un score des tuples. Si p est une fonction de prfrence, dom(p) dsigne un record type donn qui est le domaine de p, o record type est un ensemble de paires (nom : type). Exemple 3 Soit la table ci-dessous dcrivant une instance de la relation Car. Car Make Bmw Ford Ford Ford Toyota Ferrari Bmw Model 330 Escort Escort Escort Corolla 360 360 Color Black Wihte Yellow Wihte Silver Red Black Price 100k 20k 12k 18k 15k 100k 100k Year 1995 1997 1990 1995 2003 1995 1995 t1 t2 t3 t4 t5 t6 t7
Table 1. Relation Car. Soient A0 et B0 deux fonctions de prfrence de deux utilisateurs, dom(A0) = {Model : string, Color : string} et dom(B0) = {Model : string, Price : int}. Les prfrences sont alors dcrites dans les tables de base de donnes qui refltent la structure des tables dattributs et ont une colonne supplmentaire de score contenant lvaluation des attributs. Pour lexemple prcdent, les fonctions de prfrence de deux utilisateurs A0 et B0 sur lachat dune voiture sont respectivement stockes dans les tables de structure (Model, Color, Score) et (Model, Price, Score). Ce mcanisme permet aux diffrents utilisateurs de dfinir des prfrences sur des sous-ensembles diffrents dattributs dune mme table (T1 : Model, Color et T2 : Model, Price). A0 Model
Escort Escort
Color Score
red white 0.8 0.7
B0
Model
Escort Escort
Price Score
20K 15K 0.6 0.9
Table 2. Prfrences de A0
Table 3. Prfrences de B0
32
Chapitre 03
Les prfrences peuvent tre combines laide dune seule fonction gnrique, appele combine. Cette dernire permet de combiner des fonctions de prfrence dun mme utilisateur ou de plusieurs utilisateurs, pour avoir une nouvelle fonction de prfrence et obtenir un score final.
3.4.3 Approche de [Chomicki, 2002] Daprs [Chomicki, 2002], les relations de prfrences peuvent tre dfinies en utilisant des formules logiques, et peuvent tre mme intgres dans les langages de lalgbre relationnelle. Cette intgration est typiquement supporte laide dun oprateur relationnel appel winow. Les formules de prfrence sont dfinies comme suit. Soit R une relation de schma R(A) o A = {A1, . . . ,Ak} est un ensemble dattributs avec : dom(A) = dom(A1) . . . dom(Ak). - formule de prfrence : tant donns deux k-uplets t1, t2 dom(A), une formule de prfrence, note C(t1, t2), est une formule de premier-ordre dfinissant une relation de prfrence C comme suit : t1 C t2 C(t1, t2)
Dans cette approche, lutilisation de la notation c pour une relation de prfrence suppose quil existe une formule de prfrence C correspondante. En particulier, une formule de prfrence dite intrinsque lorsque elle est de la forme : C = D1 . . . Dm, m > 0 o : - chaque formule Di est une conjonction Di = Ci,1 . . . Ci,ki , i [1,m]. - chaque Ci, j est une formule atomique dun des deux types suivants : - contraintes dgalit : x = y, x y, x c ou x = c, o x et y sont des variables, et c est une constante, et - contraintes dordre rationnel : xy ou xc, o {=, , <, >, , }, x et y sont des variables, et c est un nombre rationnel.
33
Chapitre 03
Si m = 1 alors C est une formule de prfrence conjonctive. Prenons la relation Car de lexemple 5, on va illustrer les formules de prfrence par les deux exemples suivants : Exemple 4 Supposons quun utilisateur prfre un tuple de voiture un autre si et seulement si leur marque est identique et lanne dans le premier tuple est plus rcente. Pour ces prfrence, on dfinit une relation de prfrence note, C1, en utilisant une formule de prfrence C1 par : (mk,m, c, p, y) C1 (mk,m, c, p, y) C1((mk,m, c, p, y), (mk,m, c, p, y)) mk = mk y > y et qui traduit bien le fait de prfrer une voiture une autre de mme marque si elle est plus rcente. [Chomicki, 2002] introduit un oprateur spcial find all the most preferred tuples according to a given preference relation. Cet oprateur s'appelle Winow et peut tre facilement combin avec d'autres oprateurs relationnels, afin d'exprimer des requtes avec prfrences complexes [Chomicki, 2002] [Chomicki, 2003] [Chomicki, 2004]. operateur winnow : Si R est un schma de relation et C une formule de prfrence dfinissant une relation de prfrence C sur R, alors loprateur winnow, not wC(R), est dfini par : pour toute instance r de R, wC (r) = {t r | t r, t C t} On note que loprateur winnow retourne les tuples dune instance donne dune relation qui ne sont domins par aucun autre tuple de cette instance. De plus, si une relation de prfrence sur un schma de relation est dfinie en utilisant une formule de prfrence qui est un ordre partiel strict, alors pour toute instance non vide et finie sur ce schma, loprateur winnow renvoie un rsultat non vide. On peut formuler des requtes avec des prfrences comme montr par lexemple suivant :
34
Chapitre 03
Exemple 5 Si on considre la relation Car de lexemple 3, et la relation de prfrence C1 dfinie en utilisant la formule C1: (mk,m, c, p, y) C1 (mk,m, c, p, y) mk = mk y > y, la rponse la requte de prfrence wC1 (Car) fournit pour chaque voiture linformation sur la marque la plus rcente. Pour linstance de la relation Car donne par la figure 2.1, lapplication de winnow va retourner les tuples suivants : Wc1Car Marke Ford Ford Ford Model Escort Escort Escort Color Wihte Wihte Yellow Price 20k 18k 12k Year 1997 1995 1990 t2 t4 t4
Table 4. Une instance de la table Car De cette faon, une requte avec des prfrences est une requte de lalgbre relationnelle contenant au moins une occurrence de loprateur winnow. Les fondements de [Chomicki, 2002] sont a la base des autres travaux rcents de mme auteur tel que : + [Chomicki, 2004] : dans ce travail, Chomicki tudie trs largement l'optimisation smantique des requtes de prfrence et classifie en tant que smantique n'importe quelle technique d'optimisation de requtes qui sappui sur des contraintes d'intgrit. Dans le contexte des requtes de prfrence, et malgr la prsence des techniques spcialises d'valuation, l'oprateur Winnow reste toujours une opration coteuse. De ce fait, Chomicki dveloppe des techniques doptimisation pour: 1. enlever les occurrences redondantes de Winnow ; 2. spcifier quand une valuation plus efficace de Winnow est possible. Une valuation plus efficace de Winnow peut tre ralise, par exemple, si la relation de prfrence donne est un ordre faible (un ordre partiel strict ngativement transitif). + [Chomicki, 2006] : dans cette nouvelle vision, lauteur propose un cadre formel pour une approche itrative et incrmentale pour construire et valuer les
35
Chapitre 03
requtes de prfrence. Le problme est que dans les travaux prcdents, les prfrences sont considres comme statiques et ne prennent pas en compte le mode dynamique (prfrences d'utilisateur changent) de prfrences utilisateur et son influence sur la rponse. A cette fin, linterrogation avec prfrence doit considre comme un processus itratif et incrmental.
3.4.4 Approche de [Kieling, 2002] Daprs [Kieling, 2002], toute relation de prfrence est une relation dordre strict et toute expression de prfrence est dfinie partir de constructeurs de prfrence dits de base. Les constructeurs de bases sont de deux types : numrique (AROUND, BETWEEN, LOWEST, HIGHEST) ou non-numrique (POS, NEG, POS/NEG, POS/POS, EXPLICIT). Formellement, un constructeur de prfrence de base a deux arguments, le premier caractrisant l'attribut et la seconde l'ordre partiel strict. Ci-dessus des exemples de quelques constructeurs de prfrence de base : - prfrence POS : Soit un ensemble fini de valeurs prfres dun attribut A de domaine dom(A), not POS-set dom(A). Un constructeur de prfrence positive, not P := POS(A, POS-set), dfinit la relation de prfrence p par : pour tout x, y dom(A), x p y y < POS-set x POS-set. On dit que x est prfre y si et seulement si x du domaine de lattribut A appartient lensemble de valeurs POS-set et y non. Exemple 6 supposons quun utilisateur prfre une voiture de couleur rouge Cette prfrence peut tre exprime par le constructeur de prfrence P := POS(Color, {red}) qui signifie que red est prfre toutes les autres couleurs du domaine de lattribut Color.
36
Chapitre 03
La relation prfrence, note p, peut tre dfinie en utilisant la formule de prfrence suivante: Pour x, ydom(Color), y p x (y =red)(x =black x =white x =yellow x =silver) - prfrence LOWEST : Soit lattribut A de domaine dom(A). Un constructeur de prfrence plus petit, not P := LOWEST(A), dfinit la relation de prfrence p par : Pour tout x, y dom(A), x p y y > x o > est le symbole mathmatique est suprieur . On dit que x est prfre y si et seulement si y du domaine de lattribut A est suprieure x du mme domaine. Exemple 7 un utilisateur prfre une voiture plus ancienne (c.--d. des voitures des annes passes). On peut exprimer cette prfrence par le constructeur de prfrence P := LOWEST(Year) Dans ce sens, la relation prfrence, note p, peut tre dfinie en utilisant la formule de prfrence suivante : pour x, y dom(Year), x p y y > x Dans cette approche, pour dfinir une fonction dutilit, il faut dfinir un constructeur de prfrence de base, appel SCORE. - prfrence SCORE : Soit lattribut A de domaine dom(A). tant donne une fonction dutilit f : dom(A) R, un constructeur de prfrence, not P := SCORE(A, f ), dfinit la relation de prfrence p par : pour tout x, y dom(A), x p y f (y) < f (x) o < est lordre est infrieur sur R. La puissance dun model de prfrence est montre par la capacit de manipuler des constructeurs de prfrences complexes. Dans cette approche, il est possible de dfinir a partir des constructeurs de base et par composition des expressions de prfrence, dites complexes, qui dfinissent en intention des relations de prfrence sur des domaines dattributs (dans le cas de composition unidimensionnelle) ou sur des tuples de relation (dans le cas de composition multidimensionnelle).
37
Chapitre 03
Les compositions boolennes dcrites sont lintersection, lunion disjointe et la somme linaire pour le cas unidimensionnel. En peut accumuler les diffrents scores en un seul score global par lapplication dune fonction de combinaison monotone multi-attribut, note F. - expression de prfrence numrique (rankF): tant donnes les expressions de prfrence P1 = SCORE(A1, f1) et P2 = SCORE(A2, f2) et une fonction de combinaison F : R R R, lexpression de prfrence P = rankF(P1, P2), appele expression de prfrence numrique, dfinit la relation de prfrence p par : pour tout x = (x1, x2) et y = (y1, y2) lments de dom(A1) dom(A2), x p y F( f1(y1), f2(y2)) < F( f1(x1), f2(x2)) rankF est un constructeur de prfrence qui peut tre appliqu uniquement avec SCORE. Reposant sur le model de base fond dans [Kieling, 2002], plusieurs dautres travaux de mme auteur ont vue le jour tel que : + [Kieling, 2005] : ce travail consiste a introduire la notion de substituabl values (SV-smantics) comme un nouveau concept smantique pour les prfrences complexes. Ce concept caractrise les bonnes valeurs identiques parmi les valeurs indiffrentes. La construction de prfrence Pareto et prioritaire conserve les ordres partiels stricts, qui rsout des problmes bien connus cruciaux de requtes prfrences. Daprs [Kieling, 2005] il est possible de prciser une nouvelle manire base sur la smantique pour faire face l'effet infme de dbordement des moteurs de requtes. D'ailleurs, il est possible de prouver que les lois connues de l'algbre relationnel de prfrence restent valides sous la SV-smantics. Puisque la plupart de ces lois se fondent sur la transitivit, la conservation de l'ordre partiel strict, il est essentiel doptimiser algbriquement des requtes prfrences complexes. De mme, les algorithmes d'valuation efficaces bien connus pour l'oprateur de
38
Chapitre 03
slection de prfrence se fondent sur la transitivit. Selon [Kieling, 2005], les constructeurs de prfrence avec la SV-smantics permettent une
personnalisation intuitive et puissante des requtes de base de donnes et sont en mme temps la solution pour une valuation efficace de requtes de prfrence. + [Endres et Kieling, 2008a] : les auteurs tudier des requtes de base de donnes prfrences contenant des hard constraintes de somme (hard sum constraints prefernce queries) portant sur plusieurs attributs appartenant plusieurs relations. Et puisque chaque condition se rapporte des attributs de plus de deux relations, les oprateurs de jointure pair-wise peut n'enlvent pas les rsultats intermdiaires bass sur ces conditions. Ainsi, la production des produits cartsiens des relations peut mener aux cots de mmoire et de calcul trs levs. Les auteurs introduisent des techniques de rcriture de requtes qui peut tres utilises par les oprateurs de jointure pour enlever les tuples qui ne seront jamais dans le rsultat final de lvaluation. Ce travail prend en considration une seul hard constraint de somme sur plusieurs attributs, mais dans la vie relle, les requtes de base de donnes ne se limitent pas seulement une seul hard constraint, mais ils utilisent plusieurs contraintes diffrentes. + [Endres et Kieling, 2008b] : ce travail est considr comme extension de [Endres et Kieling, 2008a] pour pallier ce problme, le principe est le mme dont lobjectif est doptimiser le calcul du produit cartsien qui peut mener aux cots levs en terme de mmoire et de calcul. [Endres et Kieling, 2008b] dveloppent des techniques algbriques d'optimisation pour transformer une requte prfrence avec des multiple hard constraints afin de permettre son traitement efficace par les moteurs de base de donnes. cette fin, les auteurs prsentent un critre de dominance et introduisent des techniques de rcriture pour liminer les tuples domins avant deffectuer le produit cartsien et en consquence acclrer l'valuation. Ces techniques mnent aux nouvelles lois de transformation de prfrence et prolongent les rgles dveloppes prcdentes.
39
Chapitre 03
Exemple 8 Considrons une base de donnes stockant les informations de nutrition pour le service individuel de diffrents types de relations de nourriture comme des soupes, des viandes et des boissons. Un utilisateur, Mme Diet, veut accomplir sa feuille de rgime et est donc intresse trouver les repas qui rpondent des exigences alimentaires telles qu'une restriction sur le nombre des calories (calorie), la quantit de vitamine C (Vc) et la quantit de graisse totale de lipide. Par exemple, les recommandations pour une vieille femelle de 30 ans, qui est modrment en activit, sont au maximum 1100 calories, au moins 38 mg de vitamine C et 9 g maximal de graisse pour un repas principal. Cependant, dans le contexte d'un rgime, chaque utilisateur a ces prfrences concernant ses repas. Mme Diet aime par exemple la soupe de poulet comme dpart. Le plat principal devrait tre boeuf et le cholestrol du boeuf devrait tre le moins possible. Pour la boisson elle aime le vin rouge. Ces prfrences sont galement importantes pour elle (prfrence de Pareto). Le repas complet doit accomplir les restrictions de 1100 calories maximales, au moins 38g de vitamine C et 9g maximale de graisse pour sa feuille personnalise de rgime. Mme Diet veut dcouverte tous les repas qui accomplissent les hard constraints et satisfont ses prfrences. En utilisant l'approche de [Kieling, 2002] de modlisation des prfrences en tant qu'ordres partiels stricts, les contraintes hard et soft mentionnes ci-dessus peuvent tre exprimes par Preference SQL [Kieling et Kostler, 2002] comme suit : SELECT S.name, M.name, B.name FROM Soups S, Meats M, Beverages B WHERE S.cal + M.cal + B.cal 1100 AND S.Vc + M.Vc + B.Vc 38 AND S.fat + M.fat + B.fat 9 PREFERRING S.name IN (Chicken soup) AND (M.name IN (Beef) AND M.Cholesterol LOWEST) AND B.name IN (Red wine)
40
Chapitre 03
Cette requte exprime les prfrences de Mme Diet's aprs le mot-cl PREFERRING.C'est une prfrence Pareto(AND) comprendre des prfrences concernant les soups, les viandes et les boissons. IN dnote une prfrence pour des membres d'un ensemble donn, cest POS-preference. La prfrence entire est value sur le rsultat de somme des contraintes dures. La requte dans l'exemple est une requte de prfrence contenant des multiple hard constraints de somme dans sa condition et des prfrences d'utilisateur sur quelques attributs. Par consquent, nous appelons telles requtes des requtes de prfrence avec des contraintes multiples. Lobjectif de [Endres et Kieling, 2008b] est dliminer les tuples de relations qui absolument ne peuvent jamais tre dans lensemble de rsultat avant deffectuer le produit cartsien. Ceci rduit les tailles de relation et par consquence les cots de calcul et de la mmoire ncessaire pour le produit cartsien. 3.4.5 Approche de [Das et al, 2006] Dans lindustrie, les bases de donnes de plusieurs domaines ont un nombre trs grand d'attributs allant jusqu 100 ou plus. Avec ce nombre important d'attributs, il nest pas habituellement possible de montrer tous les attributs pour le top-n rponses une requte. Les affichages tabulaires des rponses sur les sites web peuvent typiquement montrer seulement quelques attributs qui sont considrs comme les plus "utiles" l'utilisateur. Cependant, la dcision pour le des attributs a affichs est habituellement fait manuellement, et fixe pour tous les utilisateurs, sans prendre en compte pour un utilisateur particulier quels sont les attributs susceptibles d'tre utiles pour lui. En consquence, les tuples de rponse une requte peuvent tres montrs avec un ensemble fixe d'attributs qui n'indiquent pas les dtails ncessaires pour les exigences de l'utilisateur. La prsente situation mne les auteurs poser le problme de choix d'attribut comme suit :
41
Chapitre 03
Etant donn une requte et une fonction dordonnancement des rsultats de requte, comment arriver a choisir le Top-m dattributs les plus utiles dans le calcul des Top-n tuples ordonns de la rponse, avec m << M attributs et n << N tuples o m est un petit nombre (par exemple, m = 15) et M et N sont respectivement le nombre personnalisation. Donc le problme consiste trouver les tuples les plus intressants du rsultat par rapport aux prfrences utilisateur et qui correspondent une slection donne dattributs. Ces prfrences dfinissent une relation dordre entre les tuples de la rponse la requte (la comparaison entre les tuples se fait aprs laccs aux donnes). Laffichage consiste monter le dtail des tuples les plus intressants correspondant la slection dattributs choisie (la slection des attributs se fait avant laccs aux donnes). Le calcul des scores dun tuple dpend lensemble dattributs slectionns pour laffichage. Par consquent, plusieurs scores diffrents peuvent tre associs un mme tuple. Daprs [Das et al, 2006], la notion d'utilit d'attribut est tout fait large, et la slection des attributs peut tre effectue de diffrentes faons. 1. Slection des attributs base sur le Score: pour cette manire de slection d'attributs, il est intressant de dterminer le top-m attributs qui ont linfluence le plus important dans les scores calculs de top-n tuples retourns pour une requte. Pour motiver ceci, considrer une requte qui cherche des voitures sport a deux portes dernires modles. Une fonction dordonnancement raisonnable pour de telles voitures peut reprsente le cas o le prix et la puissance de moteur ont les plus grandes influences pour le calcul de leurs scores. La tche de ce fait est pour dterminer et renvoyer ces attributs. des attributs et le nombre des tuples sans
42
Chapitre 03
2. Slection des attributs base sur lordonnancement : Cette manire de slection d'attributs est lgrement diffrente de la manire prcdente. Ici il intressant de dterminer le top-m attributs qui sont les plus influents dans lordonnancement de top-n tuples le plus haut que le reste des tuples satisfaisant galement les conditions de la requte. Si nous considrons la requte ci-dessus, bien que les prix et les puissances de moteur seront influencer les scores plus leves, elle peut se produire que la plupart des tuples, mme ceux en dehors de top-n, ont des prix et des puissances de moteur semblables. Ainsi d'autres attributs (comme fabriquant ou ge) peuvent tres critiques en diffrenciant entre le top-n tuples et le reste. 3. Slection des attributs relative base sur lordonnancement : Pour cette manire de slection d'attributs, il est souhaitable de savoir le top-m attributs qui sont les plus influents dans la prservation des ordonnancements relatifs de top-n tuples retourns parmi chacun dautre. Noter que cette troisime manire est tout fait diffrente de la seconde l o nous avons souhait savoir quels attributs ont spar le top-n tuples du reste des tuples, tandis qu'ici nous souhaitons savoir quels sont les attributs les plus responsables dans la dtermination de la permutation particulire o le top-n tuples sont retourns. Par exemple, les ordonnancements relatifs de top-n tuples peuvent tres le plus strictement assortir avec les ordonnancements relatifs des valeurs des attributs kilomtrage et NumCylinders correspondant de ces tuples. Le top dattributs retourn pour chacune des ces mthodes ci-dessus donne diffrents types d'information, dont chacun a un rle jouer en aidant les utilisateurs comparer les rponses ordonnes dune requte, et en comprenant pourquoi ces rponses ont t retournes. A cette fin, [Das et al, 2006] propose une approche hybride appel "the SplitPane approach", qui renvoie et affiche le top dattributs de chacune de ces mthodes cte cte.
43
Chapitre 03
3.5 Conclusion Il est claire daprs notre tude bibliographique, que les diffrentes approches dcrites ci-dessus abordent le problmes de personnalisation de diffrentes faons, en utilisant des mthodes et techniques diverses pour atteindre le seul objectif qui est ladaptation de rponse de la requte au souhaits de lutilisateur en faisant intervenir ses prfrences pour ne retenir lui que les rsultats pertinentes. La plupart de ces approches visent personnaliser linformation aprs laccs aux donnes pour viter le risque davoir des rponses vides (ne fournir aucune information lutilisateur) qui est le majore inconvnient pour ceux personnalisant avant laccs aux donnes. Lexpression des prfrences utilisateur pour les approches de type qualitatif est faite laide des relations de prfrence qui est le cas pour les travaux de [Chomicki ,2003] et [Chomicki , 2006], tandis que pour ceux de type quantitatif, elle est base sur une fonction de score comme cest le cas pour [Koutrika et al 2004], [Agrawel et Wimmers, 2000] et [Das et al, 2006]. Lorsque ces approches utilisent des relations de prfrences et des fonctions de scores la foi, elles dites qualitatives et quantitatives comme montrent les travaux de [Kieling, 2002], [Kieling et Kostler, 2002], [Kieling et al, 2005], [Kieling et al, 2008a] et [Kieling et al, 2008b]. Une approche de type qualitatif est plus gnrale car la dfinition dune relation de prfrence peut tre faite on basant sur une fonction de score. Cependant, ce nest pas toute relation qui peut tre capture par une fonction de score. Mme, une relation de prfrence peut tre une relation binaire, un ordre total ou un ordre partiel. Par exemple, lordre total dans [Koutrika et Ioannidis, 2004] et [Agrawal et Wimmers, 2000] permet de comparer tous les rsultats dune requte donne. Cependant, on utilise un ordre partial comme dans [Kieling, 2002] [Chomicki, 2003] lorsque on ne peut pas modliser toutes les prfrences
44
Chapitre 03
avec un ordre total (par exemple, un utilisateur na pas de prfrence entre objet A et un objet B, mais les prfre tous les deux C). Quelques approches dfinissent des oprateurs (winow de [Chomicki, 2003], constructeurs de prfrence de base comme AROUND, LOWEST, HIGHEST, POS, NEG et EXPLICIT pour [Kieling, 2002]) et mme prennent en compte la composition des prfrences (fonction combine de [Agrawel et Wimmers, 2001], composition boolenne, fermeture transitive, composition par priorits, composition Pareto et composition lexicographique dans [Chomicki , et al 2003] et loprateur de composition numrique rankF de [Kieling et al, 2002]) pour arriver aux dautres complexes qui peuvent aider lutilisateur prendre des dcisions. La synthse de ces approches est donne par la table comparative ci-aprs. Aprs avoir synthtiser dans ce chapitre le paradigme de personnalisation et ces enjeux dans les bases de donnes relationnelles, le chapitre suivant sera consacre la personnalisation dans le champ des bases de donnes multidimensionnelles et comment pouvant bnficier des progrs raliss dans ceux relationnelles pour arriver hberger parfaitement les fondements de personnalisation considrs dans le relationnel vers le multidimensionnel en prenant en compte la particularit de ce dernier.
45
Chapitre 03
Approche 2004 2005a Koutrika 2005b 2006 Agrawel 2000 2003 Chomicki 2006 Qualitative Contenu / Aprs Quantitative Contenu / Aprs Quantitative Contenu / Avant Type Quand Personnaliser ?

prfrences portent sur Requtes Requtes Requtes (seules les prfrences dites positives et exactes de prsence sont prises en compte) Requtes (lintroduction de la notion des requtes prcises) Tuples Tuples Partiel strict Formule de prfrence Total Fonction de score Non Oui Ordre Base sur Oprateur Combinaison de prfrences
Total
Fonction de score
fonction gnrique combine winow oprateurs de rvision : union, composition prioritaire et composition Pareto Constructeurs de bases + le model BMO d-parameters et SV-Relations
Oui (fonction combine)
Tuples (Prend en considration le mode dynamique de prfrences)
Oui (cinq types de composition)
2002
Attributs et Tuples Attributs et Tuples (introduction de la notion de SV-smantics comme un nouveau concept pour les prfrences complexes) Attributs et Tuples (optimisation de requtes de base de donnes prfrences contenant des hard constraints de somme (hard sum constraints prefernce queries) portant sur plusieurs attributs appartenant plusieurs relations) Attributs et Tuples (optimisation de requtes de base de donnes prfrences contenant des contraintes multiples (multiple constraints prefernce queries) portant sur plusieurs attributs appartenant plusieurs relations) Attributs et Tuples
2005 Quantitative et Qualitative
Kieling
2008a
Contenu / Aprs
Partiel strict
Formule de prfrence et Fonction de score
Dominance-Criterion
Oui (pareto rankF)
2008b
Extended Dominance-Criterion
Das
2006
Quantitative
Contenu et Forme / Avant et Aprs
Total
Fonction de score
Table 05 : Table comparatif pour les approches de personnalisation dans les bases de donnes relationnelles
46
Chapitre 04
LOLAP et la personnalisation
Chapitre 04 : La personnalisation des requtes OLAP

4.1 Introduction Actuellement, la majorit des systmes d'information sont constitus par des bases de donnes utilises par les services de production tels que le processus de fabrication, la gestion des approvisionnements, la gestion des ventes. Les exploitation directes des donnes des bases de production laide des traitements de type OLTP (On-Line Transactional processing) s'avre souvent inadapts leurs besoins dcisionnels en raison de temps d'accs importants, de structures de donnes sotriques, d'informations rparties dans plusieurs sites. Face ce problme, les industriels ont progressivement mis en place un nouveau concept qui consiste en une vritable interface entre les bases de donnes et les dcideurs. Ce concept est lentrept de donnes (Data Warehouse[Inmo, 1996]), qui a pris forme au dbut des annes 1990 et il est devenu depuis, sous de multiples variantes, la cl de vote de ce que nous appelons, linformatique dcisionnelle . L'informatique dcisionnelle a pour objectif d'laborer des systmes d'analyse de donnes ddis au soutien et l'amlioration des processus dcisionnels des entreprises. Les entrepts de donnes constituent l'outil essentiel de collecte et de mise disposition des donnes en vue de leur analyse. Le but est de collecter des donnes dcrites de manire multidimensionnelle afin de les mettre la disposition des dcideurs des fins d'analyse. Cette analyse fait appel des
47
Chapitre 04
traitements OLAP (On-Line Analytical Processing) [Codd et al, 1993], qui se distinguent des processus OLTP On-Line Transactional Processing)
principalement par leur complexit et par le nombre de donnes. En effet, les bases multidimensionnelles sont l'un des nouveaux
dveloppements remarquables de la conception des bases de donnes qui tend de faon considrable les possibilits d'analyse de grands ensembles de donnes multidimensionnels. Les donnes dune base de donnes multidimensionnelle proviennent dun entrept de donnes et sont organises sous forme de cube de donnes, c.--d. dune base de donnes dont les tables constituent un schma en toile [Kimball, 1996]. Un cube est une reprsentation multidimensionnelle des donnes dans cet entrept. Il est dcrit par les tables de dimensions (les axes danalyse) et une table de faits (les mesures) et interrog par des requtes de type OLAP. Le caractre multidimensionnel (hirarchie, niveaux, etc.) des requtes OLAP et sa complexit rendre la navigation et lexploration de masse importante dinformation renvoye par cette dernire trs difficile. Cette difficult peut tre diminue si on arrive filtrer cette masse dinformation en ngligeant celles vu inutiles pour le processus danalyse. Mais comment peut-on ralis a ? Cest sans doute la personnalisation qui a dmontr son efficacit dans les bases de donnes relationnelles en rsolvant le mme problme, mais le contexte actuel (multidimensionnel) est diffrent en raison de ses particularits. Le nombre limit des travaux contribuant dans cet axe de recherche indique que les chercheurs sont tout fait au dbut de la route vers une gamme des objectifs souligns par les experts de ce domaine. Ces objectifs sont plus que celles souligns dans la communaut de base de donnes relationnelle en raison de la complexit implique par la spcificit multidimensionnelle des requtes OLAP.
48
Chapitre 04
Dans ce chapitre, nous allons explorer trois types de personnalisation OLAP : - Personnalisation portant sur le schma de lentrept de donnes : [Bentayeb et al, 2009] - Personnalisation base sur la recommandation des requtes OLAP : [Giacometti et al, 2008] - Personnalisation base sur lenrichissement de la requte OLAP par les prfrences utilisateur en satisfaisant des contraintes sur la prsentation : [Bellatreche et al, 2005], [Bellatreche et al, 2006] et [Hassina, 2007].
4.2 Les entrepts de donnes L'approche des entrepts de donnes ("data warehousing") est aujourd'hui unanimement reconnue comme tant une solution adapte et performante, permettant d'amliorer la prise de dcision dans les entreprises [Wido, 1995] [Inmo, 1996][Gatz et al., 1999] [Jark et al., 1999]. La dfinition la plus gnralement accepte dun entrept de donnes sarticule autour de quatre caractristiques : intgration, orientation sujet, sensibilit au temps, nonvolatilit et dun objectif, laide la dcision. Cette dfinition semble avoir t propose pour la premire fois en 1994 par Bill Inmon, qui avec Ralph Kimball, est probablement lauteur actuellement le plus visible dans la littrature professionnelle amricaine : son livre de rfrence est mme disponible en japonais! Daprs cette clbre dfinition, les principales caractristiques dun entrept de donnes sont les suivantes : Lentrept de donnes est orient sujets, cela signifie que les donnes collectes doivent tre orientes mtier et donc tries par thme ainsi ; Lentrept de donnes est compos de donnes intgres, c'est--dire qu'un nettoyage pralable des donnes est ncessaire dans un souci de rationalisation et de normalisation ;
49
Chapitre 04
Les donnes du lentrept de donnes sont non volatiles ce qui signifie qu'une donne entre dans l'entrept l'est pour de bon et n'a pas vocation tre supprime ; Les donnes du lentrept de donnes doivent tre historises, donc dates. Lentrept de donnes vise la mise en uvre des solutions efficaces pour la gestion et lanalyse interactive de gros volumes de donnes laide doprateurs spcifiques de (a) consolidation et agrgation pour rsumer linformation et de (b) prsentation et structuration pour naviguer et explorer linformation. Il existe actuellement diffrentes manires pour limplantation dun entrept de donnes : Relational OLAP (ROLAP), Multidimensional OLAP (MOLAP), Hybrid OLAP (HOLAP), Desktop OLAP (DOLAP) et Spatial OLAP (SOLAP). ROLAP : les donnes sont organises selon des schmas relationnels spcialiss (flocon de neige, constellation, toile, etc.). Le langage de requtes SQL et dautres fonctionnalits des systmes relationnels ont t adapts cette organisation. Donc, ROLAP est une base de donnes relationnelle + SQL avanc. MOLAP : les donnes sont organises sous forme de cube. Les systmes de bases de donnes qui supportent cette organisation offre un langage propritaire pour linterrogation et la manipulation de ces cubes. MOLAP est une base de donnes dimensionnelle + serveur de traitement OLAP. HOLAP : les donnes sont maintenues par un SGBD relationnel alors que les agrgation le sont dans un SGBD multidimensionnel. De ce fait, HOLAP est du MOLAP pour les donnes sommaires et ROLAP pour les donnes dtailles DOLAP (Desktop OLAP) : La base DOLAP est une base OLAP trs limite en taille hberge sur le poste client. Elle est bien entendue trs rapide. Cest un fichier sur le poste client + client de traitement OLAP SOLAP (Spatial OLAP) : le SOLAP est un systme daide la dcision qui doit intgrer les concepts et mthodologies issues la fois de SIG (Les Systmes
50
Chapitre 04
dInformation Gographique) et de lOLAP. Ce systme a t dfini afin de concilier analyse multidimensionnelle et analyse spatiale. On distingue deux types de traitements de requtes qui sont utiliss : les traitements transactionnels en ligne (OLTP : OnLine Transactional Processing) sur les donnes sources de lentrept et les traitements analytiques en ligne (OLAP : On-Line Analytical Processing) sur les donnes de lentrept. Pour faciliter laccs ces donnes, les entrepts ont adopt lapproche des bases de donnes multidimensionnelles. Les bases de donnes multidimensionnelles sont gnralement dcrites par un schma multidimensionnel qui comporte les faits (table des faits) que lon souhaite tudier et les diffrentes dimensions (tables de dimensions) selon lesquelles on veut tudier les faits. Table de fait : Elle contient les donnes observables (les faits ou les mesures) que l'on possde sur un sujet et que l'on veut tudier, selon divers axes d'analyse (les cls des diffrentes dimensions). Les faits , dans un entrept de donnes, reprsentent les donnes les plus volumineuses et sont normalement numriques, puisque d'ordre quantitatif. Il peut s'agir du montant en argent des ventes, du nombre d'units vendues d'un produit, etc. Table de dimension : Cest la table qui contient les axes d'analyse (les dimensions) selon lesquels on veut tudier des donnes observables (les faits) qui, soumises une analyse multidimensionnelle, donnent aux utilisateurs des renseignements ncessaires la prise de dcision. On appelle dimension un axe d'analyse. Il peut s'agir des clients ou des produits d'une entreprise, d'une priode de temps comme un exercice financier, des activits menes au sein d'une socit, etc. Une hirarchie dcrit les diffrents niveaux de dtail dans une dimension, appels niveaux de granularit.
51
Chapitre 04
On distingue trois types de schmas qui sont souvent utiliss pour modliser les donnes de lentrept : Le schma en toile : Dans ce type de schma [Kimball, 1996], les mesures sont reprsentes par une table de faits et chaque dimension par une table de dimension. La table de faits rfrence les tables de dimensions en utilisant une cl trangre pour chacune delles et stocke les valeurs des mesures pour chaque combinaison de cls. Autour de cette table des faits figurent les tables de dimensions qui regroupent les caractristiques des dimensions. La table de faits est normalise et peut atteindre une taille importante par rapport au nombre de n-uplets. Les tables de dimensions sont gnralement non normalises afin de minimiser le nombre de jointures ncessaire pour valuer une requte. Ce schma est largement utilis dans les applications industrielles. Cependant, un schma en toile est souvent un concept centr requte, par opposition au schma centr mise jour employ par les applications de type OLTP. Les requtes typiques de ce schma sont appeles les requtes de jointures en toile (Star Join Queries ) qui ont les caractristiques suivantes : - Il y a des jointures multiples entre la table des faits et les tables de
dimensions. - Il ny a pas de jointure entre les tables de dimensions. - Chaque table de dimensions impliques dans une opration a plusieurs prdicats de slection sur ses attributs descriptifs : SELECT <Liste de projection><Liste dagrgation> FROM<Nom de la table des faits><Liste des noms de tables de dimensions> WHERE <Liste des prdicats de slection & jointure> GROUP BY <Liste des attributs des tables de dimensions> La figure suivante montre un schma en toile pour le cube VENTES o la table des faits VENTES stocke la quantit de produits vendus et les tables correspondants aux PRODUIT, CLIENT et TEMPS qui comportent les informations pertinentes sur ces dimensions.
52
Chapitre 04
Figure1 : un exemple dun schma en toile [Bellatreche, 2000] Nous constatons daprs la figure que la table de dimension TEMPS nest pas normalise, et donc le schma en toile ne capture pas directement les hirarchies (cest--dire les dpendances entre les attributs). Le schma en flocon de neige : Le schma en toile ne reflte pas les hirarchies associes une dimension [JLS 1999b]. Il exige que les informations compltes associes une hirarchie de dimension soient reprsentes dans une seule table, mme lorsque les diffrents niveaux de la hirarchie ont des proprits diffrentes. Pour rsoudre ce problme, le schma en flocon de neige a t propos pour tendre le schma en toile en gardant la mme table des faits mais en clatant les tables de dimensions afin de permettre une reprsentation plus explicite de la hirarchie [JLS 1999b]. Cet clatement peut tre vue comme une normalisation des tables de dimensions. Contrairement au schma en toile, le schma en flocon de neige capture les hirarchies entre les attributs. La figure montre un schma en flocon de neige aprs la normalisation de la table de dimension TEMPS.
53
Chapitre 04
Figure2: un exemple dun schma en flocon de neige [Bellatreche, 2000] Schma en constellation : Il est possible davoir plusieurs tables des faits partageant des tables de dimensions. Dans ce cas, les tables des faits forment une famille [KS 1995]. Chaque membre de cette famille possde ses propres dimensions. Si les tables des faits partagent une dimension, il faut vrifier que cette dimension soit exactement la mme. Le schma rsultant sappelle constellation des faits [CD 1997]. Les donnes ainsi organises sont sous forme de cubes multidimensionnels. Un cube est une reprsentation calcule partir des donnes de lentrept. Le cube prsente les mesures de lanalyse, lmentaires ou agrges, en fonction des diffrents niveaux de granularit des dimensions. Exemple 1 Nous pouvons modliser les donnes de ventes en utilisant un cube qui est dcrit sous forme de schma en toile par la figure. Ce cube, nomm SalesCube, est compos dune table de faits Sales et de quatre dimensions qui sont Time, Product, Location et Measures.Chaque cellule de ce cube stocke la valeur dunemesure donne pour un produit particulier sur une localisation particulire pour une priode donne. Nous
54
Chapitre 04
pouvons, par exemple, avoir la hirarchie suivante pour la dimension localisation : all country region city.
Figure 3 : Le cube SalesCube en schma en toile [Golfarelli and Rizzi, 1998] Dans le contexte OLAP, la communaut des bases de donnes sintresse la dfinition dune modlisation logique en prenant en compte la nature multidimensionnelle et hirarchise des donnes. Plusieurs modles
multidimensionnels formels et langages dinterrogation correspondants ont t proposs [Romero et Abell, 2007] (prsentant un tat de lart) o lobjectif majeur est la vision multidimensionnelle des donnes pour faciliter les prises de dcisions. Cependant, chaque approche prsente une vision particulire des besoins, de la terminologie et du formalisme de lanalyse multidimensionnelle. En consquence, il ny a aucun modle multidimensionnel formel consensuel tabli. En pratique, le langage utilis est le langage MDX propos par Microsoft. Il est dot dune syntaxe de type SQL et reprsente un moyen syntaxique de dfinition et dinterrogation des donnes multidimensionnelles de lentrept. A la diffrence dune requte SQL, une requte MDX renvoie une grille multidimensionnelle de cellules (ou table croise) comme rsultat la requte. De plus, la prsentation du rsultat est indique dans la requte MDX (nombre de dimensions, nombre daxes, etc.).
55
Chapitre 04 4.3 La personnalisation des requtes OLAP
Daprs les travaux raliss dans cet axe de recherche, on peut distinguer plusieurs types de personnalisation OLAP. Les auteurs ont exploit diffrentes caractristiques des entrepts de donnes qui peuvent mnent des rsultats excellentes dans ce qui concerne la personnalisation OLAP. En peut distinguer parmi ces travaux le travail de [Bentayeb et al, 2009] qui est bas sur ladaptation de schma de lentrept de donnes selon les besoins de lutilisateur ainsi lui recommander des requtes OLAP, le travail de [Giacometti et al, 2008] repose aussi sur la recommandation mais avec une autre philosophie base sur la proposition des requtes OLAP similaires celles employes dans les sessions prcdentes par dautres utilisateurs. Les travaux de [Bellatreche et al, 2005] et [Bellatreche et al., 2006] proposent dtendre le processus de personnalisation des bases de donnes relationnelles aux ceux multidimensionnelles en tenant compte de leurs particularits et complexits. Dans ce travail, nous avons concentr nos tudes sur le travail de [Bellatreche et al, 2006], et toutes nos amliorations proposes concerne lalgorithme associ ce dernier. 4.3.1 Personnalisation portant sur le schma de lentrept de donnes [Bentayeb et al, 2009] propose deux types de personnalisation OLAP dans les entrepts de donnes : ladaptation et la recommandation. 4.3.1.1 Personnalisation base sur ladaptation Selon [Bentayeb et al, 2009], l'adaptation permet aux utilisateurs d'exprimer ses propres besoins en termes de rgles dagrgation dfinies dun niveau fils (niveau existant) un niveau parent (nouveau niveau). La clause si, en effet, dtermine des conditions sur les attributs du niveau fils pour les instances groupes et qui forment une partition. La clause Then dtermine les agrgats du niveau parent, chacun correspond un sous-ensemble de la partition. Dans ce cas-ci, le systme est adaptatif puisqu'il s'adapte en voluant le
56
Chapitre 04
schma d'entrept de donnes pour tenir compte de les nouvelles informations de lutilisateur.
4.3.1.2 Personnalisation base sur la recommandation Les oprateurs OLAP classiques sont conus pour crer des agrgats intuitifs. Cependant, pour permet aux utilisateurs de trouver les agrgats non prvus et appropris qui expriment des relations profondes dans un entrept de
donnes, [Bentayeb et al, 2009] proposent de combiner les techniques de data mining et OLAP. Ils choisissent d'employer la mthode K-means, en raison du format de partition que prendre son rsultat et ainsi pour prsenter les agrgats qui sont smantiquement plus riches que ceux fournis par les oprateurs classiques d'OLAP. L'utilisateur doit fixer les paramtres des algorithmes d'une manire interactive pour obtenir les partitions appropries. Puis, le systme recommande l'utilisateur les partitions obtenues. Si ces derniers sont valides par l'utilisateur, elles sont intgres dans l'entrept de donnes et un nouveau niveau de hirarchie est alors cr. Cette nouvelle hirarchie propose lutilisateur des nouvelles requtes OLAP qui nont pas possible avec lancien schma. Pour crer un nouveau niveau dans une hirarchie de dimension, [Bentayeb et al., 2009] considre seulement des hirarchies classiques dans ces techniques d'adaptation et de recommandation. En d'autres termes, chaque occurrence fils dans un niveau fils est lie une seule occurrence parent dans un niveau parent mais chaque occurrence parent peut associe plusieurs occurrences fils comme reprsent sur le schma suivant :
57
Chapitre 04
Figure 4 : Cration d'un nouveau niveau de granularit. Dans chacune des deux techniques, l'adaptation et la recommandation, le nouveau schma d'entrept de donnes offre la possibilit dlaborer des nouvelles requtes OLAP qui on ts pas possible avec lancienne schma. Exemple 2: Soit la compagnie de LCL qui reprsente une banque franaise. Nous nous basons sur un extrait de l'entrept de donnes au concernant de la gestion des comptes. Soit deux mesures qui sont le bnfice net d'oprations bancaires (NBI) et le COT (COST). Le NBI est le bnfice obtenu partir de la gestion des comptes de clients. Comme son nom indique, la deuxime mesure correspond au cot des comptes de clients. On observe ces mesures selon plusieurs dimensions : CUSTOMER (CLIENT), AGENCY (AGENCE) et YEAR (ANNE) (figure a). La dimension AGENCY est organise comme hirarchie qui dfinit la structure commerciale gographique de LCL, c.--d. que AGENCY est groupe dans COMMERCIAL UNIT, qui est groupe dans DIRECTION.
Figure 5-a : Entrept de donnes LCL initial.
58
Chapitre 04
Figure 5-b: Entrept de donnes LCL personnalis. Maintenant, prenons le cas de la personne responsable de produits d'tudiant dans la banque LCL. Il/elle sait qu'il y a trois types d'agences : - "student" pour les agences qui recueillent seulement les comptes dtudiant, - "foreigner" pour les agences dont les clients n'habitent pas en France, et - "classical" pour d'autres agences. Cependant, cette information n'est pas stocke dans l'entrept de donnes et donc elle ne peut pas tre utilise pour effectuer l'analyse concernant les agences "tudiant". Avec lapproche de personnalisation de
[Bentayeb et al, 2009] base sur ladaptation, l'utilisateur a la possibilit d'intgrer sa connaissance spcifique dans l'entrept de donnes. Alors le systme s'adapte selon la nouvelle connaissance de utilisateur en crant un nouveau niveau de granularit AGENCIES GROUP qui correspond au niveau dsir dans la dimension AGENCY (figure 5-b). Supposons maintenant que l'utilisateur veut grouper les agences selon la population de la ville o l'agence est situe (Population) et le nombre de clients (CustNumber) mais rellement il/elle ne sait pas comment. Pour atteindre cet objectif, lapproche de personnalisation de [Bentayeb et al, 2009] base sur la recommandation en utilisant la mthode de K-means va extraire la connaissance automatiquement partir de l'entrept de donnes pour fournir probablement les
59
Chapitre 04
partitions appropries des agences. Basant sur les partitions obtenues, le systme recommande l'utilisateur un niveau de granularit AGENCIES GROUPE (figure 5-b). Ce nouveau niveau de granularit AGENCIES GROUPE permet dlaborer plusieurs dautres requtes OLAP. Par exemple, on peut observer l'volution de ACCOUNTS MANAGEMENT (NBI) par CUSTOMER
(segmentation), YEAR (anne) et AGENCIES GROUP (AgenciesGroupName).
4.3.2 Personnalisation base sur la recommandation des requtes OLAP Lapproche de [Giacometti et al, 2008] est base sur la recherche dune certaine similarit entre les requtes de lutilisateur actuel (en cours dinteraction avec lentrept de donnes) et les requtes employes par dautres utilisateurs qui ont interroger le cube avant lui afin de lui recommander la requte excute prochainement. La similarit en question est capture en comparant les squences des requtes dans les sessions (la navigation dun utilisateur a travers un entrept de donnes) prcdentes avec celles de la session actuelle. Lapproche comprendre: 1- Partitionnement de lensemble de toutes les requtes des sessions
prcdentes en classes. Chaque classe comporte des requtes similaires. 2- Gnration des recommandations candidates en slectionnant
premirement des sessions similaires a celle courante. 3- Classement des requtes candidates afin de prsenter lutilisateur celles les plus appropries dabord. Cette approche est gnrique puisque elle ne prcise pas la faon de partitionnement de lensemble des requtes des sessions prcdentes, ainsi que la gnration des requtes candidates ou les classer. Alors il considre ces actions comme des paramtres du lapproche, et quils peuvent tre instanceies selon les besoins danalyses.
60
Chapitre 04
1- Partitionnement de log et calcul des sessions gnralises : Cette tape consiste a partitionner le log (lensemble des sessions des utilisateurs). Ce partitionnement est bas sur lutilisation dune distance entre les requtes afin dobtenir comme rsultat un ensemble des classes des requtes similaires. Pour passer des sessions gnralises, les requtes de chaque session vont tres remplac par la classe quelle appartient. La session gnralise courante peut tre aussi calcule mais en utilisant a classificateur pour trouver la classe quelle elle appartient chacune de ses requtes. 2 Calcul des recommandations candidates : Maintenant, lensemble des recommandations candidates sera calcul en utilisant lensemble des sessions gnralises calcul dans ltape prcdente et la squence des requtes de la session courante. Le principe est bas sur : - Trouver un ensemble des sessions gnralises assortissant la session gnralise courante. - Calculer, pour un ensemble des sessions gnralises, un ensemble des classes candidates. - Trouver pour chaque classe candidate la requte quelle reprsente. 3. ordonnancement des recommandations candidates : Le rle de cet tape rside dans la slection une requte parmi les requtes constituants lensemble calcul dans l'tape prcdente en respectant le critre de satisfaction exprim par lutilisateur. Pour raliser cette tache, il est ncessaire de classer les requtes afin dordonner les recommandations candidates. Exemple 3: Considrons un serveur OLAP utilise par plusieurs utilisateurs. Chaque utilisateur peut initialiser une session sur ce serveur pour interrogeant le cube de donnes par une squence des requtes MDX. On dit que le serveur log ces sessions c--d les requtes lances pendant chaque session. Pour le moment supposons que le log est compos des trois sessions suivantes :
61
Chapitre 04
s1 = {q1, q2, q3, q4}, s2 = {q5, q6, q7} et s3 = {q8, q9, q10}, sachant que qi est une requte de type MDX. Supposons maintenant quune nouvelle session (session courante) est initie par un utilisateur, et quelle est dfinie pour linstant par : {q11, q12}. Cet utilisateur est certainement intress par la faon dont les autres utilisateurs ont explor le cube de donnes afin de concevoir sa prochaine requte. Maintenant, tant donn le nombre des utilisateurs et le nombre des sessions, le log peut tre trs grande, mais pas aussi grande que le cube lui-mme. En outre, les utilisateurs peuvent avoir diffrents intrts, ainsi leurs requtes interrogent des parties diffrentes du cube de donnes. Ca signifie qu'il est moins probable de trouver une requte utilise plus d'une fois dans le log. Ainsi le log peut tre grande et dispers. Pour contrecarrer ce problme, lensemble des requtes des sessions de log doit tre partitionne en classes. Chaque classe doit contenir des requtes similaires. Et aprs, pour gnrer les sessions gnralises, il faut remplacer chaque requte dans les sessions de log par la classe quelle appartient. Dans ce cas, supposons les sessions gnralises suivantes : g1 = {c1, c2, c3, c4}, g2 = {c2, c3, c5} et g3 = {c4, c3, c5} lorsque par exemple q2, q5 appartient a la classe c2, q3, q6, q9 appartiennent a la classe c3 ainsi de suite. Bien sure, dans la session courante elle-mme, les requtes peuvent tres remplaces les classes aux quelles appartiennent. Dans ce cadre, supposons que la session courante gnralise est g = {c2, c3}, lorsque il est trouv que q11 appartient c2 et q12 appartient c3. On peut trouver maintenant que la session courante est assortissante avec les sessions de log s1 et s2 (lorsque dans notre cas g est sous squence de g1 et g2). Daprs ces deux sessions, il est possible de prdire que les requtes quon doit recommander lutilisateur sont celles appartenant aux classes candidates
c4 = {q4, q8} et c5 = {q7, q10}. Pour cet exemple, supposons que ces requtes sont q4 et q7. Elles sont appeles requtes candidates.
62
Chapitre 04
Finalement, et afin de ne proposer lutilisateur quune seule requte parmi ces requtes candidates, il faut tous dabord ordonner les requtes candidates par exemple en basant sur la proximit avec la dernire requte de la session courante. Si on suppose que lordonnancement est {q7, q4}, alors la premire requte recommander lutilisateur sera q7. 4.3.3 Personnalisation base sur lenrichissement de la requte OLAP par les prfrences utilisateur en satisfaisant des contraintes sur la prsentation Dans le domaine de Data Warhouse et OLAP, l'utilisateur (dcideur) est oblig de manipuler une grande quantit de donnes destines la prise de dcision, et trs souvent, la rponse une requte OLAP risque de ne pas s'afficher entirement sur le dispositif utilis pour la visualisation. Ainsi, la procdure de prendre une dcision est base sur une analyse interactive entre lutilisateur (dcideur) et les donnes affiches. A cette fin, il serait trs utile de fournir l'utilisateur la visualisation la plus satisfaisante pour la rponse sa requte OLAP pour faciliter ces analyses dcisionnelles. Il est possible de bnficier de lide soutenue par la communaut des bases de donnes relationnelles qui consiste utiliser une technique appele la personnalisation de requte. Le principe de cette technique est de tenir compte les prfrences de lutilisateur lors de la rponse sa requte. Ces prfrences sont souvent stockes dans une structure appele profil utilisateur. Dans le cadre de la personnalisation dans les bases de donnes multidimensionnelles, les propositions survenait dans les travaux de [Bellatreche et al, 2005] et [Bellatreche et al., 2006] proposent dtendre le processus de personnalisation des bases de donnes relationnelles aux ceux multidimensionnelles en tenant compte de leurs particularits et complexits. Dans ce contexte particulier, la modlisation de profil utilisateur est base sur lordonnancement des dimensions, et tous ses membres. Et concernant la
63
Chapitre 04
reprsentation, le profil utilisateur doit permettre de prciser une prvision sur la forme de laffichage des rsultats en fixant un ordre dapparition des dimensions sur les axes de la visualisation. Ces ordres (prfrences) sont le point de dpart pour les algorithmes de personnalisation dvelopps pour calculer la rponse personnalise. Il est utile de prciser la structure de laffichage par lutilisateur (son profil). De ce fait, pour un utilisateur particulier, les informations concernant ces dimensions prfres, ou les membres prfrs, ou encore quel niveau de dtail il prfre voir les donnes, pouvant font partie de son profil. Lexpression de contraintes portant sur les caractristiques du tableau crois permettant de visualiser la rponse prfre doit tre possible. La rponse prfre pourra tre contrainte ne pas dpasser une certaine taille, avoir un certain nombre daxes, ou faire figurer telle ou telle imbrication de dimension sur un axe particulier. Exemple 4 : Supposant qu'un utilisateur doit prendre une dcision en utilisant son systme prfr OLAP. La dcision concerne les ventes des produits dans diffrents endroits, par diffrents vendeurs diffrentes priodes. Les donnes de ventes sont stockes dans un schma en toile comme le montre la figure :
Figure 6 : Le schma en toile interrog Supposant que lutilisateur veut connatre les ventes groupes par produits, annes et rgions. Evidemment, si le nombre de catgories et/ou le nombre
64
Chapitre 04
dannes sont grands, il sera difficile dafficher la rponse entirement sur lcran. Dailleurs, il y a diffrentes faons pour afficher le rsultat, par exemple, si lutilisateur est responsable de la rgion nord, il sera plus intressant par la visualisation prsente par la figure (visualisation 01) :
Figure 7: visualisation 01 Dautres part, si le profil utilisateur indique quil est responsable des ventes les plus rcentes des boissons et de nourriture quoi que la rgion, alors il sera plus intress par la visualisation prsente par la figure (visualisation 02) :
Figure 8: visualisation 02 Il est important de noter que les faits montrs ci-dessus sont un sous ensemble du mme ensemble de rponses. Ces deux sous ensembles et la manire avec laquelle ils sont prsents dpendent les prfrences de lutilisateur stockes dans son profil.
4.4 Dfinitions et concepts de base Dans les dfinitions survenu dans les deux travaux [Bellatreche et al, 2005] et [Bellatreche et al, 2006], on considrent pour un cube donn C, un ensemble de dimensions fixe D et chaque dimension D D tant un ensemble fini de membres. D'ailleurs, nous disons qu'un membre m appartient D, dnot m D, sil existe D dans D tels que m D. Cube : un cube N-dimensionnel C est un tuple C = {D1Dn, f} o :
65
Chapitre 04 i [1,N], Di est un dimension dans D. f est une application de D1Dn vers R.
tant donn deux cubes N-dimensionnels C = {D1Dn, f } et C = {D1Dn, f}, C est un sous cube de C not CC, si i [1,N], Di Di et f est une restriction de f pour DDn not f| D1Dn. Cellules dun cube : pour une instance de cube N-dimensionnel c, tel que c = {d1, . . . ,dN,f}, une cellule ou fait de c est un tuple de linstance de la table des faits f . Rfrence dune cellule : une rfrence de cellule dun cube N-dimensionnel c, est un tuple de D(c)( f ) o D(c) = {D1, . . . ,DN}. Une telle rfrence est dfinie partir de la table des faits. On note par rf(c), lensemble de ces rfrences, c.--d. : rf(c) = D(c)( f ) Plus gnralement, on appelle rfrence de c tout tuple de (d1) . . . (dN), o (di) est lensemble des membres de chaque dimension DiD(c), i[1,N]. Une telle rfrence est dfinie partir des tables de dimension. On note rfF(c), ou plus simplement rfD(c) lensemble de ces rfrences, c.--d : rfD(c) = Ni=1(di), i [1,N]. On note que rfD(c) rfF(c). La diffrence entre ces deux ensembles est lensemble des rfrences de cellules vides quon note rfNull(c) avec : rfNull(c) = rfD(c) \ rfF(c) Structure : Une structure S d'un cube C indique comment les faits de C sont prsents l'utilisateur. Formellement, Une structure K-dimensionnelle S dun cube N-dimensionnel C = {D1Dn,f} est un K-tuple S = {S1.Sk} tel que k N et Sk (k=1,,k} sont des sous ensembles disjoints de { D1Dn}. On note S lensemble de toutes les structures. [Bellatreche et al, 2005] Visualisation : Une visualisation est un tuple {C, S} o C est un cube et S est une structure de C.
66
Chapitre 04
Etant donn un ordre strict sur un ensemble de visualisation V not <V. Pour deux visualisations v1 et v2 de V, on dit que v1 est plus intressante que v2 si : v2 <V v1. Etant donn un cube et une structure, une contrainte de visualisation est une fonction boolenne indiquant si le cube peut tre visualis en utilisant cette structure. Contrainte de visualisation : tant donn un ensemble de visualisations V, une contrainte de visualisation V sur V est une fonction boolenne dfinie sur V. Pour une visualisation v V, on dit que v satisfait la contrainte V si : V(v) = true. Notons que, le profil utilisateur est constitu par les prfrences utilisateur et la contrainte de visualisation. Requtes OLAP : Les requtes OLAP considres dans ces travaux sont celles dfinies en utilisant le langage MDX (acronyme de Multi-Dimensional eXpressions) dvelopp par Microsoft pour interroger des cubes de donnes. Lun des aspects les plus intressants de MDX est ce quun utilisateur peut poser plusieurs requtes OLAP lies dans une seul expression, c.--d. il peut demander des mesures diffrents niveaux de granularit dans une seul expression. D'ailleurs, l'utilisateur peut indiquer comment l'ensemble de rsultat de a requte sera visualis. Exemple 5 : Considrons la requte MDX suivante : SELECT [Location].members ON COLUMS, CROSSJOIN ([year].members, [category].members) ON ROWS FROM SalesCube WHERE [Measures].quantity Cette expression MDX demande la quantit totale des produits vendus par anne et catgorie tous les niveaux de dimension Location (cit, rgion et pays). D'ailleurs, elle indique que les membres des dimensions Time et Product
67
Chapitre 04
seront imbriqus sur des lignes, et les membres de la dimension Location seront apparatra sur des colonnes. Dans le travail de [Bellatreche et al, 2006], les auteurs considrent les requtes MDX de la forme : SELECT SX1 ON AXIS(1), ..., SXK ON AXIS(K) FROM C WHERE TX; o SXk (k [1, K]) sont des expressions densemble, C = {D1Dn, f} est un cube de donnes et TX est lexpression dun tuple. Plus prcisment, si S est l'ensemble de dimensions qui occurrent dans SX, SX dfinit une instance de relation de schma S. Pour lexemple prcdent : l'expression densemble [Location].members dfinit l'ensemble de tuples
dom(Location ) du schma {Location}. - l'expression densemble CROSSJOIN ([year].members, [category].members) dfinit l'ensemble de tuples dom(year )dom(category ) de schma {Time, Product }. Dans ce qui suit, nous dnotons par QMDX l'ensemble des requtes de la forme prsente ci-dessus. D'ailleurs, tant donn une requte qQMDX avec K axes, nous employons les notations suivantes : - Pour chaque k[1,K], Sk(q) dnote l'ensemble de dimensions C qui
occurrent dans l'expression densemble SXk, et refk(q) dnote l'ensemble de tuples dfinis par SXk. - SK+1(q) dnote l'ensemble de dimensions C qui occurrent dans l'expression de tuple TX, et refK+1(q) dnote le singleton {t} o t est le tuple dfini par TX. Noter que pour chaque k [1, K+1], refk(q) est une relation de schma Sk(q)D(C).
68
Chapitre 04
Structure dune requte MDX et ses rfrences : Etant donn un cube Ndimensionnel C = {D1Dn, f}. Une structure K-dimensionnel S dfini sur C un tuple S ={S1,,Sk}lorsque Sk(k [1,K]) sont des sous ensembles de D(C). Considrons q QMDX une requte MDX avec k axes, la structure de q dnote par S(q), est une structure (K+1)-dimensionnel dfinie par : S(q)={S1(q), ..,Sk(q), Sk+1(q)}, d'ailleurs, le schma de q dnot par sch(q), est dfini par : sch(q)=
k +1 k =1
Sk(q).
Pour q, lensemble de rfrences ref(q) est dfinis par : ref(q)=ref1(q)...refK(q) refK+1(q). Les tuples dans ref(q) sont dits rfrences de cellules de q ou tout simplement rfrences de q. Exemple 6 : Prenons la requte MDX de l'exemple 5. S(q) indique sur quel axe chaque dimension est visualise, c.--d. S(q)={S1(q),S2(q),S3(q)}, S1(q)={Location} , S2(q)={Time, Product}et S3(q)={Measures}. D'ailleurs, l'ensemble de rfrences l de o q est dfini par : ref(q)=ref1(q)ref2(q)ref3(q) ref1(q)=dom(Location),
ref2(q)=dom(year)dom(category ) et ref3(q)={quantity}. 4.5 Algorithmes pour la personnalisation Dans cette section nous expliquons les travaux de [Bellatreche et al, 2005] et [Bellatreche et al, 2006] et les algorithmes destins a la personnalisation dans les bases de donnes multidimensionnelles.
4.5.1 Approche de [Bellatreche et al, 2005] Les prfrences stockes dans un profil utilisateur sont exprimes par lordonnancement des membres de toutes les dimensions. Ces prfrences sont ajoutes la requte originale lors de processus de personnalisation. En plus de
69
Chapitre 04
ces prfrences, il y a des contraintes dites de visualisations qui font partie de ce profil, et son rle rside dans la spcification de la forme de laffichage pour le rsultat. Dans lalgorithme propos dans [Bellatreche et al, 2005], la personnalisation de requte utilisateur et ses visualisations sont combines ds quen calcul la partie de rponse la plus intressante en respectant les contraintes de visualisation. Si les contraintes de visualisation permettent de dfinir la structure daffichage de rsultats, lalgorithme a pour seulement de trouver le cube le plus intressant et visualisable par cette structure, sinon, le travail stendre vers la recherche dune structure adquate pour visualiser ce cube. Le pr-ordre total dfini sur les membres de toutes les dimensions de cube est utilis pour dfinir une relation de pr-ordre entre les personnalisations possibles (sous cubes) de cet cube. Ce pr-ordre entre les sous cubes est dfini en respectant la proprit de monotonie suivante : Etant donn que C1 est un sous cube dun cube C2, alors C1 est moins intressant que C2 par le fait que C2 contient plus dinformations que C1. Le principe de cet algorithme est de construire pour un cube donn C, lensemble de toutes les personnalisations possibles (sous cubes respectant les prfrences utilisateur et les contraintes de visualisation), ensuite, faire ressortir de cet ensemble, un sous cube C* ayant les caractristiques suivantes : - il existe S* un structure qui permet de le visualiser. - Il nexiste pas un autre sous cube plus intressant que C* et visualisable (C* est maximal par rapport la relation de pr-ordre entre les sous cubes). Dans le cas o les contraintes de visualisation ne prcisent pas exactement la structure de sous cube optimal C*, une structure respectant les prfrences de lutilisateur et ses contraintes de visualisation doit tre trouve. De ce fait, cet
70
Chapitre 04
algorithme personnalise a la fois, lensemble des mesures a prsentes lutilisateur, et a prsentation. Dans ce travail, le problme est formul de la manire suivante : Pour un cube C, une contrainte de visualisation v et un pr-ordre sur C, trouver une visualisation <C*,S*> de C tel que : C* p{C C| S, v(C,S)=true} et v(C*,S*)=true. La proposition dassocier des utilits (des entiers dans [0,1]) pour chaque membre de toutes les dimensions permet de dfinir une fonction dutilit pour un cube par : Fu(C)=
mM ( C )
( m)
Et ensuite : lordre u sur C par : C u C si seulement si Fu(C) Fu(C). Enfin, tant donn deux cubes C et C tel que : C C, en peut dire que C uC. Concernant la contrainte de visualisation, cette dernire est obtenue partir de structure S=<S1,..,Sk> et un entier G par : VG(C,S)= true si seulement si ( DSk D G ) avec k [1,K]. Etant donn un ensemble fixe de dimensions D, et un pr-ordre total p entre les membres dans D. pour chaque paire de membres (m,m) D2, on dit que m est prfr que m si seulement si : m pm. Et lorsque m pm et m pm, on dit quelles sont galement prfrs. Par consquent, on dfinit un pr-ordre total entre les cubes par : pour deux cubes C1 et C2, C1 est moins intressant que C2, not par C1 pC2 si pour chaque m1 M(C1)\ M(C2), il existe m2 M(C2)\ M(C1) tel que : m1 pm2. De ce fait, deux cubes C1 et C2 sont toujours comparables avec respect au p si lensemble des membres qui distingue C1 de C2 nest pas vide, c'est--dire que : (M(C1)\M(C2)) I (M(C2)\M(C1)) Exemple 7 : Prenons le cube C de l'exemple 1, et supposons C1 et C2 deux sous cubes de C dfinies par :
71
Chapitre 04
- C1={D11, D12, D13, f1} avec D11={north}, D12={food, drink, cloth}, D13={2002, 2003, 2004, 2005} et f1=f|D11xD12xD13. - C2={D21, D22, D23, f2} avec D21={north, south, east, west}, D22={food}, D23={2004, 2005} et f2=f|D21xD22xD23. Nous avons M(C1)={north, food, drink, cloth, book, 2002, 2003, 2004, 2005}et M(C2)={north, south, east, west, food, drink, 2004, 2005}. Supposons P est le pr-ordre total dfini sur D1 U D2 U D3 par : (drink P food) >P 2005 >P 2004 >P (north P southP east P west) >P (2000P 2001P 2002P 2003) >P (clothP book). Ce pre-ordre total dfini le profil de l'utilisateur qui obtient la visualisation prsente dans la figure 3. Basons sur le pre-order P dfini sur C, nous avons : - M(C1)\M(C2)={cloth, book, 2002, 2003}, - M(C2)\M(C1)={south, east, west}. En plus, les membres les plus intressants qui distinguent C1 de C2 sont south, east et west. Puisque tous ces membres appartiennent C2, nous avons C1 P C2. Maintenant, et concernant les contraintes de visualisations considres, tant donn T=<T1,..,Tk> une structure K-dimensionnel et G=<G1,..GK> un K-tuple des entiers. Pour chaque cube C=<D1,..,DN,f> et structure S=<S1,..,SL>, on dfinit la contrainte de visualisation VT,G par : VT,G(C,S) = true si L=K et - Pour k [1,K], on a Tk Sk, cette contrainte signifier que lutilisateur veut voir les dimensions dans Tk sur laxe k - Pour k [1,K], on a Di Sk|Di| Gk, cette contrainte signifier que lutilisateur peut avoir un nombre maximal Gk sur laxe K. - Pour i [1,N], si Di (S1 Sk), alors |Di|=1. cette contrainte signifier que chaque dimension qui ne figure pas sur les axes visibles doit contient seulement un membre. Dans ce travail, en plus le cube personnalis obtenu, il est possible de chercher une structure S pour visualiser un cube C si elle existe.
72
Chapitre 04
tant donn un cube C et une contrainte de visualisation v, le principe est dexamine si v peut tre satisfaite ou non, c.--d. sil existe une structure S tels que v(C,S)=true. Ce problme est considr par [Bellatreche et al, 2005] comme un problme NP-complet.
4.5.2 Approche de [Bellatreche et al, 2006] Contrairement au pr-ordre total dfini dans [Bellatreche et al, 2005], le modle de prfrence dfini dans [Bellatreche et al, 2006] est bas sur un ordonnancement partiel qui est et selon les auteurs plus flexible et ralisable que le premier. Ainsi, lobjet personnalis dans les deux propositions se diffre ds que dans [Bellatreche et al, 2005], les auteurs cherchent personnaliser la rponse a une requte OLAP (le cube rsultant aprs lexcution de la requte), tandis que, dans [Bellatreche et al, 2006], lide consiste a personnaliser la requte ellemme avant lexcution (en basant sur ses rfrences). Dans cette nouvelle proposition, tant donn une requte MDX q, un profil d'utilisateur et une contrainte, lalgorithme propos calcule une version personnalise de q de la faon suivante : Cette requte personnalise est une sous requte de q (dans le sens de l'inclusion des requtes), dont lobjectif est de rduire la cardinalit de l'ensemble de rponse. La rponse cette requte personnalise doit satisfaire la contrainte. Cette requte personnalise est galement la plus intressante en respectant le profil d'utilisateur. Dans cette proposition, le profil utilisateur est dfini par le tuple ={<d,{<1,..,<N}}o :
73
Chapitre 04
- <d est un ordonnancement partiel sur lensemble de dimensions D(C) de cube C. Etant donn deux dimensions Di et Dj, on dit que Di est moins intressant que Dj si Di <d Dj. - Pour chaque i [1,N], <i est un ordonnancement partiel sur lensemble des membres de Di, Di (C),. Pour deux membres m1 et m2 dans dom(Di), m1 est moins intressant que m2 si m1<i m2. Lordonnancement spcifi daprs le profil utilisateur permet dobtenir un ordonnancement pour les rfrences de cellules. Supposons t et t0 deux rfrences de cellules de schma D0 D(C). Si (t, t0) est l'ensemble de dimensions o t et t0 diffre, alors t et t0 sont comparables seulement avec le respect au dimensions les plus importantes dans (t,t0)={Di D | t(Di) t0(Di)}, c.--d. lensemble de dimensions max<d( (t,t0)). On dit que t est moins intressant que t0 avec respect au not t t0, si pour chaque dimension Di max <d( (t,t0)), on a t(Di) <i t0(Di). Exemple 8: Etant donn le cube dfini dans l'exemple 1, supposons <Location, <Measures }} le profil utilisateur dfini sur C par : - (Year <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 . Supposons t = {2005, food, Centre, price} et t0 = {2006, drink, Orleans, price}deux rfrences de schma sch(t) = sch(t0) = {Time, Product, Location, Measures}. Nous avons (t, t0) = {Time, Product, Location}. Puisque max<d( (t,t0))={Location }et t(Location) = Centre <Location t0(Location) = Orleans, on a : t < t 0 . ={<d,{<Time, <Product,
74
Chapitre 04
Dans [Bellatreche et al, 2006], la personnalisation est procde au niveau de la requte en comparant leurs ensembles de rfrences. Pour un profil dfini sur un cube C et deux requtes MDX q et q0 dfinies sur C, q est moins intressante que q0 dnot par q q0 si sch(q)=sch(q0) et ( t ref(q))( t0 ref(q0))(t t0). Exemple 9: Supposons les deux requtes MDX q et q0 dfinies par : q : SELECT [Location].members ON COLUMNS, CROSSJOIN({[year].2005,[year].2006}, {[category].shoes,[category].cloth}) ON ROWS FROM SalesCube WHERE [Measures].quantity q0 : SELECT [Location].members ON COLUMNS, CROSSJOIN({[year].2003,[year].2004, [year].2005,[year].2006}, {[category].food,[category].drink}) ON ROWS FROM SalesCube WHERE [Measures].quantity On a ref(q) ={2005, 2006}{shoes, cloth}adom(Location){quantity} et ref(q0) = {2003, 2004, 2005, 2006} {food, drink} adom(Location) {quantity}. Daprs le profil utilisateur dfini dans lexemple prcdent, on peut remarquer que q0 est prfre que q, c.--d. q q0 puisque : t ref(q), t0 ref(q0) tel que : t t0. Par exemple, pour le tuple t = {2005, shoes, Orleans, quantity} ref(q), il existe un le tuple t0 = {2005, food, Orleans, quantity} ref(q0) o (t, t0) = {Product}. Ds que max<d( (t, t0))={Product} et t(Product)<Product t0(Product),alors t t0. Lun des critres que la requte personnalise doit satisfaire est la contrainte de visualisation. Cette satisfaction est dfini comme suit : tant donn un cube Ndimensionnel C=<D1,..,DN,f>, une structure K-dimensionnel T=<T1,..,Tk> et un
75
Chapitre 04
K-tuple des entiers G=<G1,..GK>. La dfinition dune contrainte de visualisation VT,G pour chaque requte q QMDX est donne par : VT,G(q) = true si q contient K axes et : - Pour k [1,K], on a Tk Sk(q), cette contrainte signifier que lutilisateur veut voir les dimensions dans Tk sur laxe k de q. - Pour k [1,K], on a |refk(q)| Gk, cette contrainte signifier que lutilisateur peut avoir un nombre maximal Gk sur laxe K de q. On arrive maintenant la formulation de problme dans [Bellatreche et al, 2006] tel que : Etant donn : - Une requte MDX q QMDX. - Une contrainte v V dfinie sur QMDX, et - Un profil utilisateur sur un cube C. Le but est de calculer lensemble Q* des requtes personnalises dfini par : Q*= max {q QMDX | q q v(q)=true}. Ce calcul peut tre effectu par lalgorithme en deux phases : Phase 1 : Calculer des sous-ensembles de rfrences de q les plus intressants qui peuvent tres visualiss en respectant la contrainte v. Cet ensemble est dnot dans la fonction Perso (voir la figure ) par Mi-1. En utilisant la fonction MaxSubset prsente sur la figure, cet ensemble est calcul itrativement dans la boucle principale de fonction Perso (voir les tapes 3-11). Phase 2 : Dterminer les structures qui permettent de visualiser les sousensembles de rfrences de q les plus intressants calculs dans la premire phase. Noter que ces structures sont calcules en utilisant la fonction FindStruct de [Bellatreche et al, 2005] dans la deuxime boucle de la fonction Perso (tapes 13-15). Pour la premire phase, lensemble des rfrences T de q est partitionn en basant sur lordonnancement comme suit : T = T1 TP
76
Chapitre 04 Tel que :
- T1 = max (T). T1 contient les rfrences de T les plus intressants. - Ti+1= max (T \ (Uik=1Tk)) pour i[0,P-1]. Pour deux sous ensembles X et Y de ref(q), on dit que X est moins intressant que Y dnot par X Y si pour chaque x X, il existe y Y tel que x y. En plus, pour chaque sous ensemble X de ref(q), une fonction boolenne Cv est dfint par : Cv(X) = true sil existe une structure S (pour visualiser X ) et une requte q q[X,S] tel que : v(q) = true.
Figure 9: lalgorithme Maxsubset[Bellatreche et al, 2006]
77
Chapitre 04
Figure 10: lalgorithme Perso[Bellatreche et al, 2006] Exemple 10: Cet exemple illustre le fonctionnement de fonctions Perso et MaxSubset pour personnaliser une requte MDX. Prenons le profil utilisateur de lexemple 8, et q la requte MDX suivante avec la contrainte de visualisation VT,G dfinie par T=<,> et G=<4,4>: q : SELECT {[Location].Tours, [Location].Orleans}, {[year].2003,[year].2004, [year].2005,[year].2006}, {[category].shoes,[category].cloth,[category].food, [category].drink} FROM SalesCube WHERE [Measures].quantity Noter que l'utilisateur ne rien dit concernant la structure utilise pour afficher la rponse. Pour cette requte, lensemble de rfrences ref(q) = {2006, 2005, 2004, 2003} {Orleans, Tours} {drink, food} {quantity}. D'ailleurs, ref(q) = T1 .. T7 o les ensembles des rfrences Tk (k [1, 7]) sont :
78
Chapitre 04
La fonction Perso calcul lensemble des requtes personnalises Q* = Perso(q,VT,G, ) de la faon suivante : A la premire itration (i = 1), on a M1 = MaxSubset(, T1) = {T1} lorsque vT,G(T1) = true. De la mme manire, nous pouvons voir que M2 = MaxSubset(T1, T2) = {T1 T2}. A la troisime itration (i = 3), on a M3 = MaxSubset(T1 T2, T3). Lorsque il nest pas possible de visualiser les mesures concernant 3 annes, 3 produits et 2 locations avec une table croise qui n'a plus de 4 lignes et 4 colonnes, on a VT,G(T1 T2 T3) = false. Alors, nous n'avons pas M3 = {T1 T2 T3}. En effet, nous pouvons montrer que M3 = {R3, R3} lorsque : R3 = T1 T2 {(2005, food,Orleans, quantity), (2004, drink,Orleans, quantity), (2005, food, Tours, quantity), (2004, drink, Tours, quantity)}, et R3 = T1 T2 {(2006, cloth,Orleans, quantity), (2005, food,Orleans, quantity), (2006, cloth, Tours, quantity), (2005, food, Tours, quantity)}. Nous dtaillons maintenant comment M3 est calcul par la fonction MaxSubset : 1. A la premire itration (k = 1) de fonction MaxSubset, C1 contient toutes les 1-sous-ensembles de T3, c.--d. 6 lments. Dailleurs, on a I1 = C1 lorsque toutes les candidates dans C1 sont intressantes avec le respect au Cv. 2. A la deuxime itration (k = 2) de fonction MaxSubset, C2 contient toutes les 2-sous-ensembles de T3, c.--d., 15 lments. Noter que quatre lments de C2 sont intressants avec respect au Cv quand il est possible de visualiser seulement 2 annes, 3 produits et 2 locations, ou 3 annes, 2 produits et 2 locations. Les lments de C2 qui ne sont pas intressants :
79
Chapitre 04
{(2006, cloth,Orleans, quantity), (2004, drink,Orleans, quantity)}, {(2006, cloth,Orleans, quantity), (2004, drink, Tours, quantity)}, {(2004, drink,Orleans, quantity), (2006, cloth, Tours, quantity)}, {(2006, cloth, Tours, quantity), (2004, drink, Tours, quantity)} ds que lajout de lun de ces 2-sous-ensembles va donner 3 annes, 3 produits et 2 locations, ce qui ne peut pas tre visualis. 3. A la troisime itration (k = 3), nous pouvons montrer que C3 contient 8 lments et que sont tous intressants, c.--d. I3 = C3. 4. A la quatrime et dernire itration (k = 4), nous pouvons montrer que C4 contient 2 lments et que sont tous intressants, c.--d. I4 = C4 (voir R3 et R3 quand ces 4-sous-ensembles de T4 sont ajouts). A la quatrime itration (i = 4) de fonction Perso, on a M4 = MaxSubset(R3, T4) = {R4,R4 } lorsque : R4 = R3 {(2004, food,Orleans, quantity), (2003, drink,Orleans, quantity), (2004, food, Tours, quantity), (2003, drink, Tours, quantity)}, et R4 = R3 {(2006, shoes,Orleans, quantity), (2005, cloth,Orleans, quantity), (2006, shoes, Tours, quantity), (2005, cloth, Tours, quantity)}. A cinquime itration (i = 5), on M5 = MaxSubset(R4, T5) = {R5,R05 }lorsque : R5 = R4 {2003, food,Orleans, quantity), (2003, food, Tours, quantity)}, et R5 = R4 {(2005, shoes,Orleans, quantity), (2005, shoes, Tours, quantity)}. A la sixime itration (i = 6), on a M6 = MaxSubset(R5, T6) = {R5,R5 } lorsque plus de catgories de product et years peuvent tres ajouts lensemble de rfrences R5 or R5 de sorte qu'ils puissent tre visualiss en utilisant une table croise qui na plus de 4 lignes et 4 colonnes. Pour la mme raison, quand i = 7, on a M7 = MaxSubset(R5, T7) ={R5,R5 } lorsque ni R5 T7 ni R5 T7 est affichable. a la fin, on a Q*= {q[R5, S5a], q[R5, S5b], q[R5 , S5a], q[R5, S5b]} lorsque : R5 = {2006, 2005, 2004, 2003} {Orleans, Tours} {drink, food} {quantity}, S5a = <{Y ear}, {Location, Product}, {Measures}>,
80
Chapitre 04
S5b = <{Location, Product}, {Y ear}, {Measures}>. R5 = {2005, 2006} {Orleans, Tours}{drink, food, cloth, shoes} {quantity}, S5a = <{Location, Y ear}, {Product}, {Measures}>, S5b = <{Product}, {Location, Y ear}, {Measures}>. Par exemple on peut prsenter l'utilisateur la requte MDX personnalise correspond q[R5, S5a]. S5a est essentiellement utilise pour dterminer comment les dimensions apparatrent dans la clause ON de la requte MDX. R5 est utilis pour fournir pour chaque dimension lextension de l'ensemble de membres apparaissant dans la table croise rsultante. De ce fait, la requte personnalise correspondant q[R5, S5a] qui peut tre propose l'utilisateur sera : SELECT {[year].2003,[year].2004, [year].2005,[year].2006} ON COLUMNS, CROSSJOIN({[Location].Tours,[Location].Orleans}, {[category].food,[category].drink}) ON ROWS FROM SalesCube WHERE [Measures].quantity Daprs cet exemple de personnalisation, on peut remarquer que le rsultat contient deux sous ensembles de rfrences et pour chacun deux structures daffichages possibles. Cela est due a lutilisation de lordre partiel strict qui ne permet pas dtablir la relation de prfrence entre tous les lments de profil utilisateur (membres et dimensions) et par consquent en peut obtenir lors de calcul de slection des rfrences les plus intressantes en terme de prfrences utilisateur et contraintes de visualisation, plusieurs sous ensembles de rfrences galement importants. Cette galit dimportance entre les sous ensembles de rfrences est traduit par lexistence des rfrences (lordre entre les sous ensembles des rfrences est obtenu a partir de lordre entre les rfrences) non comparables en fonction de la relation de prfrence dfinie par les prfrences utilisateur exprims dans son profil.
81
Chapitre 04
Cette cas fait partie de travail de [Hassina, 2007] qui valide les propositions survenu dans [Bellatreche et al., 2006] a travers limplantation de ses algorithmes. Afin dobtenir un ordre total strict, [Hassina, 2007] propose de combiner lordre partiel strict introduit dans [Bellatreche et al., 2006] avec un nouveau ordre total dite de ordre total machine. Cette ide est base sur la supposition dexistence de deux types dordres machines tel que : un ordre machine not <Dm sur les dimensions du cube considr, des ordres machine nots <Dim sur lensemble des membres de chacune des dimensions Selon [Hassina, 2007], ces ordres sont des ordres stricts totaux, et quen pratique, ils peuvent correspondre lordre lexicographique sur les chanes de caractres ou lordre de stockage des informations sur le disque.
4.6 Conclusion Au cours de ce chapitre, nous avons essay de synthtiser les solutions proposes dans ce qui concerne le paradigme de personnalisation dans la communaut des bases de donnes multidimensionnelles (entrepts de donnes). On a dcouvris quil y a autant de travaux modlisant le concept de personnalisation selon plusieurs angles de visions et diffrentes ncessits quil pose le contexte dutilisation de ce concept. Dans ce chapitre, nous avons explor trois types de personnalisation OLAP : 1- Personnalisation portant sur le schma de lentrept de donnes [Bentayeb et al, 2009]. Cette personnalisation est effectue soit par ladaptation ou par la recommandation. Pour le premier type, ladaptation est faite en voluant le schma d'entrept de donnes pour tenir compte les nouvelles informations de lutilisateur. Tandis que le second permet de
82
Chapitre 04
trouver les agrgats non prvus et appropris qui expriment des relations profondes dans un entrept de donnes. 2- Personnalisation base sur la recommandation des requtes OLAP : travail de [Giacometti et al, 2008] dont lobjectif est de trouver une certaine similarit entre les requtes de lutilisateur actuel et les requtes employes par dautres utilisateurs qui ont interrog le cube avant lui afin de lui recommander la requte excute prochainement. 3- Personnalisation base sur lenrichissement de la requte OLAP par les prfrences utilisateur en satisfaisant des contraintes sur la prsentation [Bellatreche et al, 2005], [Bellatreche et al, 2006]. Ces deux propositions hritent ses fondements de bases de la personnalisation dans les bases de donnes relationnelles. Les prfrences de lutilisateur qui constituent le profil utilisateur, sont modlises par une relation dordre qui ordonne les dimensions ainsi que les membres de chacune delles. Cette relation est un pr-ordre total dans [Bellatreche et al., 2005] tandis que dans [Bellatreche et al., 2006], elle consiste un ordre partiel strict. Le profil utilisateur comporte aussi des contraintes dites de visualisation pour spcifier la forme que doit prendre un rsultat lors de laffichage. Dans [Bellatreche et al., 2005], la personnalisation est applique aprs lexcution de requte OLAP et elle consiste a trouver parmi lensemble des personnalisations possibles (sous cubes) de cube rsultant le sous cube le plus intressant en terme de prfrences utilisateurs et satisfaisant les contraintes de visualisation. Le principe reste le mme pour [Bellatreche et al., 2006], sauf quil se diffre avec le premier dans laction o il vite laccs a la table des faits dont la taille est trs volumineuse en personnalisant la requte OLAP exprim en MDX avant quelle soit excute en basant sur son ensemble de rfrences. Cette dernire ide a linconvnient davoir des cellules vides et mme la
83
Chapitre 04
possibilit darriver une rponse o la totalit de ses cellules contient lobjet NULL.
Le nombre limit des travaux contribuant dans cet axe de recherche et le manque remarquable dun modle consensuel bas sur des rgles standards qui acquise les accords de toutes les acteurs de la communaut de bases de donnes multidimensionnelles, exprime la ncessit de concentrer tous les efforts et dexploiter le maximum des capacits pour bien matriser les enjeux de ce paradigme afin de fournir des systmes personnaliss robustes et efficaces. Dans ce cadre, on va essayer de proposer dans le chapitre suivant un algorithme qui gnre pour un ensemble des rfrences, lensemble de toutes les structures possibles et ensuite filtrer cet ensemble afin de ne garder que celles respectant notre dfinition concernant la meilleure visualisation.
84
Chapitre 05
Contribution
Chapitre 05 : Contribution
5.1 Introduction Dans ce chapitre, nous allons prsent notre algorithme
POSSIBLE_STRUCTURES qui gnre les diffrentes structures possibles pour un ensemble des rfrences dune requte MDX et respectent le contraint de visualisation VT,G., ainsi quune petite proposition pour que lalgorithme de personnalisation de [Bellatrech et al,2006] puisse supporte la discrimination entre plusieurs ensembles de rfrences, et mme faire simplifier le choix de lutilisateur pour une structure parmi un ensemble propos. Avant de prsenter notre algorithme pour la gnration de lensemble de toutes les structures possibles pour un ensemble des rfrences respectant, on va prsent celui de [Bellatrech et al.2005] concernant la dtermination pour un ensemble de rfrences sil existe une structure pour sa visualisation ou non.
5.2 Lalgorithme FindStruct [Bellatrech et al.2005] Concernant la structure S*, [Bellatrech et al.2005] utilise un algorithme appel FindStruct dont le rle est de calculer une structure S* pour le cube C* si elle existe. Cet algorithme est montr dans la figure 1. tant donn un cube C et une contrainte de visualisation v, cet algorithme examine si v peut tre satisfaite, c.--d. sil existe une structure S tels que v(C,S)=true. Ce problme est considr par [Bellatreche et al, 2005] comme un problme NP-complet.
85
Chapitre 05
Contribution
Figure 1: lalgorithme FindStruct [Bellatreche et al, 2005] Supposons VT,G une contrainte de visualisation dans V* avec T = {T1, T2} et G ={G1,G2}. Cet algorithme est bas sur la programmation dynamique qui teste si lexiste une structure S de C tels que VT,G(C, S)=true. Au dpart, lalgorithme calcule l'ensemble D={Di1,..,DiM} des dimensions qui doivent tre places sur les axes visibles. Puis, il est clair que la mime itration (1 m M) de la boucle principale (voir les tapes 6 16), la cellule t[k][j] de tableau t est diffrent de null sil existe une partition de Em= {Di1,..,Dim} D dans deux ensembles S1 et S2 tels que pour p=1,2 , on a Tp Sp et Dj Sp|Dj| G. D'ailleurs, si t[k][j] null, la fonction FindStruct utilise t[k][j] pour reprsenter lun de la partition {S1,S2} de D satisfait la contrainte, c.--d. S1=t[k][j] et S2=Em\S1.
86
Chapitre 05 Exemple 1 :
Contribution
Dans le contexte de lexemple prcdent, supposons quon a un cube C={D*1,D*2,D*3,f*} avec D*1={north, south, east, west}, D*2={drink, food}, D*3={2004, 2005}. On fait appel a la fonction FindStruct pour tester sil existe une structure S* telque VT,G(C*,S*)= true quand T=<,> et G=<4,4>. Au dpart, on a K1=4 et K2=K3=2. D'ailleurs, puisque T1=T2=, nous avons G1=G2=1 et t[1][1]=. Les autres cellules de t sont initialises null. Finalement, nous avons D={D*1,D*2,D*3}. A la premire itration de la boucle principale, supposons Di=D*1. Ds que t[1][1]= , et 1*K1= 4 4, on obtient t[4][1]={D*1} et t[1][4] = . A la deuxime itration, Di=D*2. Ds que t[4][1]={D*1} et 1*K=2 4, on obtient t[4][2]={D*1}.Ds que t[1][4] = , et 1*K=2 4, on obtient galement t[2][4]={D*2}. A la troisime et dernire itration, Di=D*3. Quand t[4][2] = {D*1} et 2*K=3 4, on obtient t[4][4] = {D*1}. Ds t[2][4] = {D*2} et 2*K=3 4, on obtient galement t[4][4] ={D*2,D*3}. A la fin, supposons que t[4][4] = {D*2, D*3} (cette solution est la dernire stocke). Dans ce cas, FindStuct renvoi la structure <{D*2, D*3}, {D*1}>, qui signifie que la contrainte de visualisation VT,G peut tre satisfaite. 5.3 Lalgorithme POSSIBLE_STRUCTURES Le principe de lalgorithme POSSIBLE_STRUCTURES est de construire au dpart lensemble de toutes les structures possibles de lensemble des dimensions slectionnes pour une requte MDX en respectant la contrainte de visualisation VT,G et sans prendre en considration lensemble ou le sous ensemble des rfrences examin. Lorsque cet ensemble des structures est gnr, lensemble ou le sous ensemble de rfrences est utilis pour liminer de
87
Chapitre 05 cet ensemble des structure celles qui ne visualisation VT,G .
Contribution respecte pas la contrainte de
Lalgorithme POSSIBLE_STRUCTURES est trs simple et consiste en une fonction qui utilise dautres fonctions tel que : PUT_DIMS_ON_AXIS, Next_Set_Comb, To_One_Set et Duplicate_Set. La dfinition de ces fonctions est comme suit :
Function Next_Set_Comb( SET ) Input : SET, A set of subsets of two subesuets. SET = {S / S={x1,x2} and x1x2 = } Output : Next_Set, for every subset S1 = {x1,x2} of the input set SET, this set contain all
combinations of its first subset x1 with the elements of the second subset x2.
1. Let Next_Set ={} 2. For every S={x1,x2} of SET do 3. 4. 5. 6. 7.
For every e x2 do Let S2 = {x3,x4} such that x3 = x1 U e

x4 = x2
Remove e from x4 If For every S of Next_Set S != S2 then Insert S2 in Next_Set
8. Return Next_Set
88
Chapitre 05
Function PUT_DIMS_ON_AXIS (Dims_Set, Axis_One, Axis_Two) Input : Dims_Set, A set of selected dimensions (from the user query);
Contribution
Axis_One, A set of the dimensions must appear on the first axis (from the user profil); Axis_Two, A set of the dimensions must appear on the second axis (from the user profil); Output : Axis_Set, set of all possible two subsets from Dims_Set sash that :
for every subset1 Axis_Set/ subset1 = {S1,S2} and S1S2 = and Axis_One S1 and Axis_Two S2 1. Let Str1 = {} 2. Let Str2 = {} 3. For every dim Dims_Set do 4. 5. 6. 7. such that: k = Dims_Set.size() Div 2 and x1x2 = . 9. Let AXI is set of a set of two subsets such that: AXI[0] = {{S1,S2}}: S1={} and S2 = Dims_Set 10. Let i = 1 11. While i < k+1 do 12. 13. AXI[i] = Next_Set_Comb(AXI[i-1]) i = i +1
If dim Axis_One then Str1 = Str1 U dim Remove dim from Dims_Set else If dim Axis_Two then Str2 = Str2 U dim Remove dim from Dims_Set
8. Let k is the number of all possible two subsets {x1,x2}of the elements of Dims_Set
14. end while

15. Let Axis_Set = To_One_Set(AXI) 16. Axis_Set = Duplicate_Set(Axis_Set)
17. For every S = {S1,S2} Axis_Set do 18. 19. 20. Return Axis_Set S1 = S1 U Axis_One S2 = S2 U Axis_Two
89
Chapitre 05
Function To_One_Set(SET) Input : SET, a set of subsets of two subesuets such that :
SET = {S / S = {S1 /S1={x1,x2} and x1x2 = }}
Contribution
Output : One_SET, A set of subsets of two subesuets such that :

One_Set = {S / S={x1,x2} and x1x2 = } 1. Let One_Set = {} 2. For every S of SET do 3. 4.
For every S1={x1,x2} of S do Insert S1 in One_Set
5. Return One_Set
Function Duplicate_Set(SET) Input : SET, A set of subsets of two subesuets such that :
SET = {S / S={x1,x2} and x1x2 = }
Output : Duplicated_SET, A set of subsets of two subesuets such that :

Duplicated_Set = {S / S={x1,x2} and x1x2 = } 1. Let Duplicated_SET = {} 2. For every S={x1,x2} of SET do 3. 4.
Insert S in Duplicated_Set If {x2,x1} not in Duplicated_Set then Insert {x2,x1} in Duplicated_Set
5. Return Duplicated_Set
90
Chapitre 05
Function POSSIBLE_STRUCTURES(Selected_Dims_Set, Ref_Set) Input :
Contribution
Selected_Dims_Set, A set of the selected dimensions (from the user query). Grad_1, the maximal number of graduations for the first axis (from the user profil) Grad_2, the maximal number of graduations for the second axis (from the user
profil).
Ref_Set, a set of references Output : Structures_Set, a set of structures from Dims_On_Axis which satisfy the following
condition: for every structure S1 = {ax1,ax2} of Structures_Set we have : grad(ax1) <= Grad_1 and grad(ax2) <= Grad_2, such that : grad(x) returns the number of graduation on this axis. 1. Let Dims_On_Axis = Put_Dims_On_Axis(Selected_Dims_Set) 2. Let Structures_Set = {} 3. For every S={ax1,ax2} of Dims_On_Axis do 4. 5. 6. 7. 8. Return Structures.
Let gr1 = grad(ax1) // grad(ax1) is calculated for the references set Ref_Set Let gr2 = grad(ax2) // grad(ax1) is calculated for the references set Ref_Set If gr1<=Grad_1 and gr2<=Grad_2 then Insert S in Structures_Set
Exemple 2 : (exemple descriptif) Soit Sel_Dims lensemble des dimensions slectionnes par lutilisateur, et Axis_1 et Axi_2 deux ensembles des dimensions que lutilisateur souhaite voir sur le premier axe et le second respectivement, et G la contrainte de visualisation tel que : Sel_Dims = {Product,Time,Location,Measures } Axi_1 = {Product} Axi_2 = {Time} G = <4,4> Soit REF lensemble de rfrences suivant :
91
Chapitre 05 REF = { Food,1998, Orlans,Unite Sales Drink,1997,Tours,Unite Sales Drink,1997,Orlans,Unite Sales Cloth,1997,Orlans,Unite Sales Cloth,1998,Tours,Unite Sales Drink,1998,Orlans,Unite Sales Food,1997,Orlans,Unite Sales Food,1997,Tours,Unite Sales }
Contribution
La premire tape de fonction POSSIBLE_STRUCTURES consiste trouver les diffrentes affectations possibles pour les dimensions slectionnes en utilisant la fonction Put_Axis_On_Dims(). Cette dernire fonction comme suivant : En entre : Sel_Dims , Axi_1 et Axi_2. Str1 = {} Str2 = {} En excutant les instructions des tapes 3 7 de la fonction
Put_Dims_On_Axis, on obtient : Str1 = {Product} ; Str2 = {Time} et Sel_Dims = {Location,Measures} A ltape 8 de la fonction Put_Dims_On_Axis, k = 2 Div 2 = 1 A ltape 9 de la fonction Put_Dims_On_Axis, AXI = {{S1,S2}} tel que : S1={} et S2 = {Location,Measures} A ltape 10 de la fonction Put_Dims_On_Axis, i = 1 A ltape 11 de la fonction Put_Dims_On_Axis de la fonction
Put_Dims_On_Axis, i = 1 et k+1 = 2 et la boucle WHILE commence et, dans ltape 12 de la fonction Put_Dims_On_Axis on : AXI[1] = Next_Set_Comb(AXI[0]) Le droulement de la fonction Next_Set_Comb(AXI[0]) sera comme suit : Au dpart Next_Set = {}
92
Chapitre 05
Contribution
A la deuxime tape de cette fonction et lorsque AXI[0] comporte quune seule sous ensemble de deux ensemble, alors la boucle for sera excute un seule fois tel que : S = {{}{ Location,Measures }} A ltape 3, et pour e = Location on a : ltape 4 : S2 = {x3,x4} tel que x3 = {} U {Location} ltape 5 : ltape 6 : x4 = {Location,Measures} x4 = {Measures}
A ltape 7 et puisque dans Next_Set nexiste pas un sous ensemble quivalent a S2 alors S2 va tre insr dans Next_Set. A ltape 3, et pour e = Measures on a : ltape 4 : S2 = {x3,x4} tel que x3 = {} U Measures ltape 5 : ltape 6 : x4 = {Location,Measures} x4 = {Location}
A ltape 7 et puisque dans Next_Set = {{{{Location},{Measures}}}} nexiste pas un sous ensemble equivalent a S2 = {{Measures},{Location}} alors S2 va tre insr dans Next_Set. A la dernire tape de la fonction Next_Comb lensemble retourn par cette fonction est Next_Set tel que : Next_Set = {{{{Location},{Measures}}, {{Measures},{Location}}}} et la fin de la fonction Next_Comb. A ltape 13 de la fonction Put_Dims_On_Axis on a : i = 1+1 = 2, et puisque k+1 = 2 = i alors la boucle WHILE sarrte. A ltape 15 de la fonction Put_Dims_On_Axis, on a Axis_set retourne le rsultat dexcution de To_One_Set({{{{Location},{Measures}},{{Measures},{Location}}}}) Le droulement de To_One_Set sera comme suit : A son premier tape, One_Set = {}
93
Chapitre 05 Au second : pour S = {{{},{Location,Measures}}} de SET={{{{},{Location,Measures}}}, {{{Location},{Measures}},{{Measures},{Location}}}} Au troisime, pour S1 = {{},{Location,Measures}} de S on a : Au quatrime, One_Set = {{{},{Location,Measures}}}
Contribution
pour S = {{{Location},{Measures}},{{Measures},{Location}}} de SET={{{{},{Location, Measures}}}, {{{Location},{Measures}},{{Measures},{Location}}}} on a : Au troisime, pour S1 = {{Location},{Measures}} de S on a : Au quatrime, One_Set = {{{},{Location,Measures}}, {{Location},{Measures}}}} et pour S1 = {{Measures},{Location}} de S on a : Au quatrime, One_Set = {{{},{Location,Measures}}, {{Location},{Measures}}, {{Measures},{Location}}} Au cinquime, la fonction To_One_Set retourne lensemble One_Set. A ltape 16 de la fonction Put_Dims_On_Axis, on a Axis_Set = Duplicate_Set(Axis_Set) Le droulement de la fonction Duplicate_Set est trs simple et donne le rsultat suivant : Axis_Set = { {{},{Location,Measures}}, {{Location},{Measures}}, {{Measures},{Location}}, {{Location,Measures},{}}} De ltape 17 19 de la fonction Put_Dims_On_Axis, pour chaque sous ensemble S = {S1,S2} de Axis_Set ajouter les lments de Str1 S1 et ceux de Str2 S2. la fin de la boucle Axis_Set devient :
94
Chapitre 05 Axis_Set = { {{Product},{Time,Location,Measures}}, {{Product, Location},{Time, Measures}}, {{Product, Measures},{Time, Location}}, {{Product, Location, Measures},{Time}}}
Contribution
Et ltape finale, la fonction Put_Dims_On_Axis retourne Axis_Set qui contient les diffrentes structures possibles pour la requte de lutilisateur. A la seconde tape de la fonction POSSIBLE_STRUCTURES on a Structures_Set = {} De ltape 3 7, la fonction POSSIBLE_STRUCTURES et daprs lensemble des rfrences Ref_Set va calculer pour chaque ensemble S = {ax1, ax2} de Dims_On_Axis grad(ax1) le nombre de graduation pour lensemble ax1 et grad(ax2) le nombre de graduation pour lensemble ax2 et les comparer avec respectivement Grad_1 et Grad_2 les graduations fixes par lutilisateur dans ses contraintes de visualisation. Si grad(ax1) et grad(ax2) ne dpassent pas respectivement Grad_1 et Grad_2 alors S va tre ajout a Structures_Set : Grad_1 = 4 et Grad_2 = 4. S = {{Product},{Time,Location,Measures}} grad({Product}) = 3 < Grad_1 grad({Time,Location,Measures}) = 2x2x1 = 4 = Grad_2
S est insr dans Structures_Set
S ={{Product, Location},{Time, Measures}} grad({Product, Location}) = 3x2 = 6 > Grad_1 grad({Time, Measures}) = 2x1 = 2 < Grad_2
S ne sera pas insr dans structures_Set
S = {{Product, Measures},{Time, Location}} grad({Product, Measures}) = 3x1 = 3 < Grad_1 grad({Time, Location}) = 2x2 = 44 = Grad_2
S est insr dans Structures_Set
S = {{Product, Location, Measures},{Time}}

95
Chapitre 05
Contribution
grad({Product, Location, Measures}) = 3x2x1 = 6 > Grad_1 S ne sera pas insr dans structures_Set grad({Time}) = 2 < Grad_2
la fin de fonction POSSIBLE_STRUCTURES, lensemble des structures retournes est : Structures_Set = {{{Product},{Time,Location,Measures}}, {{Product, Measures},{Time, Location}}}
5.4 Discrimination entre plusieurs ensembles de rfrences Le rsultat obtenu par lutilisation de lalgorithme de personnalisation PersoVisu de [Bellatrech,2006] est atteint sans accs au cube de donnes et peut comporte plus dun sous ensemble des rfrences personnaliss daprs le profil de lutilisateur. Mais ce dernier a lambition de choisir parmi cet ensemble que les sous ensembles qui mnent des rsultats complets ou au moins des rsultats qui ne correspondent pas des donnes parses (lorsquun grand nombre de cellules dun cube de donnes sont vides, on parle alors de donnes parses). Basant sur ce problme de donnes parses qui peuvent figurer dans le cube de donnes choisi, le nombre des sous ensembles des rfrences peut tre diminu si on slectionne parmi cet ensemble que les sous ensembles des rfrences qui renvoi un pourcentage minime pour le nombre des cellules vides par rapport au nombre total des cellules dans le cube de donnes choisi. Il est clair que cette optimisation ncessite des accs aux donnes du cube pour retourner pour chaque sous ensemble de rfrences le nombre des cellules non vides (utilisant loprateur COUNT). Lefficacit dune telle optimisation est assure lorsquil existe parmi les sous ensembles de rfrences des sous ensembles comportant des cellules vides ou reprsentant des donnes parses. Cette optimisation est supporte par notre prototype travers loption discrimination qui va offrir lutilisateur la possibilit de filtrer lensemble
96
Chapitre 05
Contribution
des sous ensembles des rfrences pour quon garde que ceux qui rpondent au critre dfini par cette optimisation. 5.5 Simplification de choix de lutilisateur pour une structure parmi un ensemble Daprs notre algorithme POSSIBLE_STRUCTURES pour la gnration de lensemble de toutes les structures possibles pour un ensemble des rfrences, il existe des structures o la totalit ou la plupart des dimensions slectionnes sont places sur un seul axe, ou bien des structures o la diffrence entre le nombre de graduations sur les deux axes est considrable. Ainsi, la majorit des assistants personnels PDA, SmartPhone (tlphone intelligent : un tlphone mobile coupl un PDA) ou les tlphones mobiles disposent des crans dune forme carre. Cette caractristique peut nous conduit introduire une nouvelle dfinition concernant la visualisation des rsultats dexcution des requtes OLAP sur ces appareils. Cette dfinition qualifier une visualisation dtre la meilleure si elle est ralise par une structure o la diffrence entre le nombre de graduations sur ses deux axes est minime. Il est possible dutiliser un seuil afin contrler cette diffrence entre le nombre des graduations sur les deux axes dune structure. Le seuil peut aider lutilisateur justifier ses visualisations. Lutilisateur de notre prototype My Cube peut bnficier de cette optimisation pour liminer toutes les structures qui ne visualisations pour leurs cubes slectionns. reprsentent pas des meilleures
Exemple 3: Soit Dims un ensemble de dimensions dune requte tel que : Dims = {Product, Time, Location, Measures} Et : nbr_Mem(Product) = 3, nbr_Mem(Time) = 2, nbr_Mem(Location) = 3, nbr_Mem(Measures) = 1 sont les nombres des membres pour chaque dimensions.
97
Chapitre 05
Contribution
Soit quelques structures parmi celles proposes lutilisateur selon leur ensemble des dimensions Dims : S1 = {{Product, Time, Location, Measures},{}} S2 = {{},{Product, Time, Location, Measures}} S3 = {{Product, Time, Location},{Measures }} S4 = {{Measures },{Product, Time, Location}} S5 = {{Product, Time},{ Location, Measures }} S6 = {{ Product},{Time, Location, Measures }} S7 = {{Time, Location, Measures },{ Product}} S8 = {{Time},{ Product, Location, Measures }} S9 = {{ Product, Location, Measures },{Time}} S10 = {{Time, Location},{Product, Measures }} S11 = {{Product, Location},{Time, Measures }} S12 = {{Time, Measures},{Product, Location}} Si en dsigne par DiffDim la difference de nombre des dimensions entre deux axes dune structure, et Diffgrad sa diffrence sur le nombre de graduation on obtient : DiffDim(S1) = 4 0 = 4 DiffDim(S2) = 0 4 = 4 DiffDim(S3) = 3 1= 2 DiffDim(S4) = 1 3= 2 DiffDim(S5) = 2 2= 0 DiffDim(S6) = 1 3= 2 DiffDim(S7) = 3 1= 2 DiffDim(S8) = 1 3= 2 DiffDim(S9) = 3 1= 2 DiffDim(S10) = 2 2= 0 DiffDim(S11) = 2 2= 0 DiffDim(S12) = 2 2 = 0 Diffgrad(S1) = (3221) 0 = 12 Diffgrad(S2) = 0 - (3221)= 12 Diffgrad(S3) = (322) 1= 11 Diffgrad(S4) = 1 - (322)= 11 Diffgrad(S5) = (32) (21)= 4 Diffgrad(S6) = 3 (221)= 1 Diffgrad(S7) = (221) 3= 1 Diffgrad(S8) = 2 - (321)= 4 Diffgrad(S9) = (321) 2= 4 Diffgrad(S10) = (22) (31) = 1 Diffgrad(S11) = (32) (21)= 4 Diffgrad(S12) = (21) (31)= 1
98
Chapitre 05
Contribution
Daprs notre dfinition pour la meilleure visualisation, les structures qui seront slectionnes sont : Sans utilisation de seuil : Basant sur DiffDim : S5, S10, S11 et S12 Basant sur Diffgrad: S6, S7, S10 et S12 Avec utilisation de seuil : si en choisit comme un seuil pour DiffDim e1 = 2, et pour Diffgrad e2 = 4 les structures qui seront slectionnes sont : Basant sur DiffDim : S3, S4, S5, S6, S7, S8, S9, S10, S11 et S12 Basant sur Diffgrad: S5, S6, S7, S8 S9 , S10 , S11 et S12
5.6 Conclusion Parmi nos propositions prsentes dans ce chapitre, lalgorithme
POSSIBLE_STRUCTURES qui est diffrent de celui de [Bellatrech et al.2005] (FindStruct) de fait que ce dernier a pour but daffirmer pour un cube C lexistence dune structure S respectant la contrainte de visualisation VT,G ou non en calculant cette structure si elle existe, tandis que notre algorithme (POSSIBLE_STRUCTURES) calcule pour un cube de donnes C lensemble de toutes les structures possibles qui respectent la contrainte de visualisation VT,G. En plus, et concernant le nombre des sous ensembles des rfrences que peut contenir le rsultat obtenu par lutilisation de lalgorithme de personnalisation PersoVisu de [Bellatrech,2006] dont lordre utilis est partial, on a propos que
99
Chapitre 05
Contribution
parmi cet ensemble on peut prsent lutilisateur que les sous ensembles qui mnent des rsultats complets ou au moins des rsultats qui ne correspondent pas des donnes parses. Ainsi, et avec lexistence dune part, des structures parmi celles gnres par notre algorithme POSSIBLE_STRUCTURES o la totalit ou la plupart des dimensions slectionnes sont places sur un seul axe, ou bien des structures o la diffrence entre le nombre de graduations sur les deux axes est considrable, et la forme carre que prendre la majorit des assistants personnels PDA, SmartPhone (tlphone intelligent : un tlphone mobile coupl un PDA) dune autre part, on a introduit une nouvelle dfinition concernant la visualisation des rsultats dexcution des requtes OLAP sur ces appareilles. Cette dfinition qualifier une visualisation dtre la meilleure si elle est ralise par une structure o la diffrence entre le nombre de graduations sur ses deux axes est minime. Cette diffrence peut tre supervise par un seuil afin daider lutilisateur justifier ses visualisations. Dans le chapitre suivant, et comme exprimentations, on va donner des exemples pratiques afin de montrer lefficacit de nos ides proposes.
100
Chapitre 06
Exprimentations
Chapitre 06 : Exprimentations
6.1 Prototype My Cube Aprs avoir explor prcdemment les algorithmes de personnalisation des requtes OLAP, ce chapitre a pour objectif de montrer et discuter le prototype dvelopp My Cube qui implmente ces algorithmes de personnalisation. Ce prototype consiste en une simulation dune application java sexcutant sur un tlphone mobile dun utilisateur. Le schma suivant dcrit le principe de base pour le fonctionnement de notre systme de personnalisation :
Figure 1 : Architecteur de systme de personnalisation My Cube
101
Chapitre 06 6.1.1 Technologies employes
Exprimentations
Daprs le schma, on peut distinguer plusieurs technologies participes dans la ralisation de ce systme tel que : Mondrian : est un serveur OLAP (On Line Analytical Processing) disponible sous licence open source. Il fait partie de la catgorie des serveurs R-OLAP, c'est--dire qu'il accde des donnes contenues dans une base relationnelle. Mondrian excute des requtes utilisant le langage MDX, galement utilis dans Microsoft SQL Server. Ce langage permet de crer des requtes dont lquivalent en langue SQL ncessiterait un grand nombre de requtes et des temps dexcution beaucoup plus longs. Ce serveur est le plus souvent utilis conjointement avec JPivot ou JRubik (prsents plus loin), outils qui proposent une interface graphique de consultation et manipulation des donnes. Le projet Mondrian a maintenant rejoint le projet Pentaho. Tomcat : Issu du projet Jakarta, Tomcat est dsormais un projet principal de la fondation Apache. Tomcat implmente les spcifications des servlets et des JSP de Sun Microsystems. Il inclut des outils pour la configuration et la gestion, mais peut galement tre configur en ditant des fichiers de configuration XML. Comme Tomcat inclut un serveur HTTP interne, il est aussi considr comme un serveur HTTP. Tomcat a t crit en langage Java, il peut donc s'excuter via la JVM (machine virtuelle java) sur n'importe quel systme d'exploitation la supportant. Easyphp : fut le premier package WAMP voir le jour (1999). Il s'agit d'une plateforme de dveloppement Web, permettant de faire fonctionner localement (sans se connecter un serveur externe) des scripts PHP. EasyPHP n'est pas en soi un logiciel, mais un environnement comprenant deux serveurs (un serveur
102
Chapitre 06
Exprimentations
web Apache et un serveur de bases de donnes MySQL), un interprteur de script (PHP), ainsi qu'une administration SQL phpMyAdmin. Il dispose d'une interface d'administration permettant de grer les alias (dossiers virtuels disponibles sous Apache), et le dmarrage/arrt des serveurs. Il permet donc d'installer en une seule fois tout le ncessaire au dveloppement local du PHP. Par dfaut, le serveur Apache cre un nom de domaine virtuel (en local) 127.0.0.1 ou localhost. Ainsi, quand on choisit Web local dans le menu d'EasyPHP, le navigateur s'ouvre sur cette URL et affiche la page index.php de ce site qui correspond en fait au contenu du dossier www d'EasyPHP. Mysql : est un systme de gestion de base de donnes (SGBD). Selon le type d'application, sa licence est libre ou propritaire. Il fait partie des logiciels de gestion de base de donnes les plus utiliss au monde, autant par le grand public (applications web principalement) que par des professionnels, en concurrence avec Oracle ou Microsoft SQL Server. Java : Apparu en 1991, le langage JAVA a commenc tre intressant partir de 1995 avec sa prise en charge par le navigateur phare de l'poque, Netscape. Ce langage ne cesse de se dvelopper. Il s'agit d'un langage orient objet dont la syntaxe est trs proche de celle du C++. C'est galement un langage portable, c'est dire qu'il s'adapte une foule de plate-formes diffrentes. C'est l l'une des qualits de JAVA. 6.1.2 Principe de fonctionnement de base pour le systme de
personnalisation My Cube Le systme de personnalisation est compos de lapplication My Cube et les diffrents serveurs.
103
Chapitre 06
Exprimentations
Lapplication est compose son tour de deux parties, linterface utilisateur qui lui permet dinteragir avec le systme et le noyau qui effectue les diverses oprations concernant le processus de personnalisation. Les serveurs employs dans ce systme sont : Serveur de base de donnes utilisant le SGBD MySql dEasyPHP pour stocker la base de donnes des profils utilisateur. Serveur de base de donnes utilisant le SGBD MySql pour stocker les donnes de lentrept de donnes (base de donnes de teste Foodmart). Serveur dapplications Tomcat pour dployer le serveur OLAP Mondrian. Serveur OLAP Mondrian install au sein de serveur Tomcat. Ce serveur est charg dexcuter des requtes de type MDX sur lentrept de donnes.
Pour naviguer sur le systme de personnalisation My Cube, un utilisateur doit avoir un compte sur ce systme. Le compte utilisateur reprsente son profile. Pour initier une session sur ce systme, lutilisateur introduit son nom dutilisateur et son mot de passe (message 1). Si lauthentification russite, lutilisateur reoit depuis le serveur de base de donnes contenant la base de donnes des profils utilisateur ses prfrences, ses contraintes de visualisations et ses requtes MDX personnalises et non personnalises (message 2). Linterface graphique de lutilisateur permet a lutilisateur de construire des requtes a zro ou dutiliser celles de son profil. Dans les deux cas, le rsultat de personnalisation dune requte par le noyau peut contient plus dune requte. Daprs le systme, lutilisateur a la possibilit de faire une discrimination entre lensemble des requtes personnalises pour diminuer leur nombre. Cette opration ncessite lutilisation pour chaque une delles une requtes MDX qui renvoi leurs nombres des cellules non vides. Pour excuter ces requtes, une connexion est tablit vers le serveur Tomcat o le serveur OLAP Mondrian est install (message 3). Ce dernier excute les requtes et rcupre les rsultats en
104
Chapitre 06
Exprimentations
interrogeant lentrept de donnes sur le serveur de base de donnes utilisant le SGBD MySql et envoi ces rsultats a lutilisateur (message 4). Avec ou sans discrimination, et aprs la slection dune requte et une structure pour cette dernire, lutilisateur peut procder a lexcution de cette requte personnalise. Cette requte est envoye sur le serveur OLAP Mondrian (message 5). Mondrian interroge lentrept de donnes a nouveau pour obtenir le rsultat de lexcution. Le serveur Mondrian formate le rsultat en table croise avec des cellules et leurs coordonns lutilisateur (message 6). avant de lacheminer vers
6.1.3 Prsentation de prototype La base de donnes des profils utilisateur Stocke sur le serveur de base de donnes qui emploi le SGBD MySql dEasyPHP. Cette base de donnes stocke les informations concernant chaque utilisateur et elle comporte 21 tables qui sont: o Axisone : stocke pour chaque utilisateur les dimensions quil souhaite voir sur laxe numro un. o Axistwo : stocke pour chaque utilisateur les dimensions quil souhaite voir sur laxe numro deux. o Cube : stocke les diffrents cubes. o Dimbetter : stocke pour une dimension, les dimensions qui sont plus prfres par un utilisateur que cette dimension. o Dimensions : stocke les dimensions de lentrept de donnes. o Dimless : stocke pour une dimension, les dimensions qui sont plus prfres par un utilisateur que cette dimension. o Graduation : stocke pour chaque utilisateur la graduation choisit. o Levbetter : stocke pour un niveau dune dimension, les niveaux qui sont plus prfres par un utilisateur que ce niveau.
105
Chapitre 06
Exprimentations
o Levels : stocke pour un niveau dune dimension, les niveaux qui sont plus prfres par un utilisateur que ce niveau. o Levless : stocke pour un niveau dune dimension, les niveaux qui sont plus prfres par un utilisateur que ce niveau. o Members : stocke les membres de chaque niveau de chaque dimension de lentrept. o Pers_query : stocke les noms des requtes personnalises. o Pers_query_from : stocke les cubes utiliss par chaque requte personnalise. o Pers_query_select : stocke les dimensions, les niveaux et les membres constituants la clause SELECT dune requte personnalise. o Pers_query_where : stocke les dimensions, les niveaux et les membres constituants la clause WHERE dune requte personnalise. o Prefmembers : stocke pour un niveau dune dimension les membres prfrs par lutilisateur. Ces membres sont ordonns. o Query : stocke les noms des requtes non personnalises. o Query_from : stocke les cubes utiliss par chaque requte non personnalise. o Query_select : stocke les dimensions, les niveaux et les membres constituants la clause SELECT dune requte non personnalise. o Query_where : stocke les dimensions, les niveaux et les membres constituants la clause WHERE dune requte non personnalise. o Users : stocke pour chaque utilisateur son nom et son mot de passe.
106
Chapitre 06 Lentrept de donnes
Exprimentations
Les donnes de cet entrept (base de donnes de teste FoodMart) sont stocks sur le serveur de base de donnes utilisant le SGBD MySql, avec lensemble des tables de dimensions suivant : o Customers : stocke les informations concernant les clients. o Education Level : stocke le niveau dducation pour chaque client. o Gender : le sexe de client, male ou female. o Marital Statuss : stocke la situation marital pour chaque client S : clibataire ou M : mari. o Product : stocke les produits a vendre dans FoodMart. o Promotion media : stocke les medias utilises pour une promotion, tel que : les journaux, la tv ou le radio. o Promotions : identifier la promotion qui a dclenche le vente. o Store : stocke la localisation de diffrentes stockes (dpts) dans la chane (pays, tat, cit). o Time : stocke pour chaque vente, la priode quand le vente tait dclench. o Yearly Income : stocke les revenues de chaque client.
et la table de fait : o Measures : cette table contient plusieurs mesures tel que : Unit Sales : nombre d'units vendues. Store Cost : cot de marchandises vendues. Store Sales : valeur des transactions de ventes. Sales Count : nombre des transactions de ventes. Les donnes de lentrept sont interroges indirectement par le systme. Par le baie de Mondrian, un serveur OLAP destine a lexcution des requtes multidimensionnelles (MDX) sur les donnes dun entrept de donnes et le formatage des rsultats sous forme dune table croise.
107
Chapitre 06 Linterface utilisateur:
Exprimentations
Cest lensemble des diffrentes fentres constituants linterface de lapplication et qui permet un utilisateur de : - Sauthentifier sur le serveur (nom dutilisateur et mot de passe) : Chaque utilisateur a son propre nom dutilisateur et mot de passe pour naviguer sur ce systme. (la fentre 01) - Dfinir ces prfrences ou les modifier : Ces prfrences
reprsentent lordonnancement choisi par lutilisateur sur lensemble des dimensions de cube de donnes, ainsi que sur les niveaux des dimensions et bien sur, un autre ordonnancement concerne les membres des niveaux. Cet ordonnancement est partiel, c-a-d que lutilisateur nest pas oblig de classifier toutes les dimensions, les niveaux de chaque dimension et les membres de chaque niveau dans chaque dimension. En plus de ces ordonnancements, lutilisateur peut spcifier quelques contraintes concernant la forme que doit prendre un rsultat sur lcran de son mobile. Ces contraintes permettent lutilisateur de dsigner un ensemble de dimensions quil souhaite voir toujours sur le premier axe et un autre ensemble sur le second. Ainsi, lutilisateur peut indiquer le nombre maximal des membres que doit comporter chaque axe, on parle de nombre de graduation pour chaque axe. (Les fentres de 04 11) - Parcourir ses requtes prdfinies : Ces requtes sont soient personnalises ou non, et sont stockes sur son profil. Lutilisateur peut effectuer les diffrentes oprations offertes sur ses requtes tel que : ldition dune requte non personnalise afin de la modifier, le changement le nom dune requte, la suppression dune requte, la personnalisation dune requte non personnalise,
108
Chapitre 06 lexcution dune requte personnalise. (Les fentres de 12 15)
Exprimentations
- Construire une requte a zro : Cest linterface qui aide lutilisateur construire une nouvelle requte en passant par les tapes suivantes : Slection de cube. Slection de lensemble des dimensions pour la clause SELECT. Slection pour chaque dimension slectionne dans ltape prcdente, un ensemble des niveaux. Slection pour chaque niveau slectionn dans ltape prcdente, un ensemble des membres. Slection de lensemble des dimensions pour la clause WHERE. Cet ensemble doit tre diffrente de celle de la clause SELECT. (cette tape est optionnelle, c-a-d que lutilisateur peut ne choisi aucune dimension) Slection pour chaque dimension slectionne dans ltape prcdente, un niveau et un membre. (cette tape aura lieu si lutilisateur a choisi dans ltape prcdente au moins une dimension). La sauvegarde de la requte gnre sur le profile de lutilisateur sous un nom bien dfini. (Les fentres de 16 23) - personnalise une requte non personnalise ou excuter une autre personnalise: Ces requtes sont soient des requtes gnres nouvellement ou des requtes de lensemble stockes sur le profil utilisateur.
109
Chapitre 06
Exprimentations
Le rsultat de la personnalisation dune requte non personnalise peut contenir plus dune requte personnalise due lutilisation de lordre partiel. Dans ce cas, lutilisateur peut utiliser la discrimination entre les requtes rsultantes afin de rduise leur nombre si possible. Pour une requte personnalise slectionne, lutilisateur doit choisir une structure parmi les diffrentes structures proposes. Et ainsi l,
lutilisateur a aussi la possibilit de faire une rduction de nombre des structures proposes pour la requte personnalise slectionne (si possible bien sur). Et aprs le choix de la structure, lutilisateur peut faire : La sauvegarde de la requte personnalise sur le profile de lutilisateur sous un nom bien dfini. Noyau : Cette partie se cache derrire linterface de linterface, ce qui rend son fonctionnement transparent lutilisateur. En peut distinguer deux rles pour cette partie, le premier concerne tous ce qui est lie a lutilisateur et la gestion de son profil, tandis que le second garantis la meilleur gestion de trafic avec le serveur des requtes MDX Mondrian. Cest grce noyau que le systme gre toutes les interactions de lutilisateur avec son interface graphique pour : interroger le serveur MySql dEasyPhp pour rcuprer les donnes concernant lutilisateur depuis son profil, ou les mettre a jour, ou mme pour insrer dautres (par exemple lorsque lutilisateur ajoute des nouvelles prfrences a son profil ou fait sauvegarder des nouvelles requtes personnalises ou non personnalises). Personnaliser une requte en utilisant lalgorithme choisi pour cette opration selon les tapes suivantes :
110
Lexcution de la requte personnalise afin dafficher le rsultat.
(Les fentres de 24 30)
Chapitre 06
Exprimentations
1- Extraire lensemble des dimensions utilises dans la requte. 2- Extraire lensemble des rfrences de la requte. 3- Construire lensemble de diffrentes structures possibles pour lensemble des dimensions extraites sans prendre en lensemble de rfrences extraites. 4- Appliquer lalgorithme de personnalisation dcrit prcdemment (utilisant les prfrences utilisateur et ses contraintes de
visualisations). 5- Due la nature partiel de lordre employ par lalgorithme de personnalisation, le rsultat peut admettre plus dune requte personnalise (le rsultat consiste a un ensemble des sous ensembles des rfrences). Cest l o en peut voir limpact de notre contribution qui consiste rduire le nombre de ces requtes par le principe de discrimination comme montr prcdemment. Dans ce cas, le systme est oblig dinterroger la base de donnes FoodMart qui se trouve sur le second serveur de base de donnes MySql avec lintermdiaire de Serveur Mondrian). 6- Pour un sous ensemble slectionn des rfrences, le systme construit lensemble des structures appropries pour ces rfrences en utilisant dans cette opration lensemble de toutes les structures possibles pour lensemble des dimensions de la requte gnr dans ltape 3, et les contraintes de visualisations depuis le profil utilisateur. 7- Parmi les structures de lensemble gnr dans ltape 6, en peut distinguer des structures o la totalit ou la plupart des dimensions sont affectes sur un seul axe. C--d que la diffrence entre le nombre des dimensions affectes sur chaque axe est considrable. Et daprs notre proposition, le systme peut donne une suggestion pour liminer ces structures et ne garder si possible que les structures qui
111
Chapitre 06
Exprimentations
ont la moindre diffrence entre le nombre des dimensions affectes sur chaque un des ses deux axes. 8- Pour un sous ensemble des rfrences slectionn et une structure parmi lensemble propos, le systme gnre la requte MDX personnalise. Interroger lentrept de donnes pour excuter une requte MDX et
rcuprer le rsultat afin de lafficher.
6.1.4 Les diffrentes fentres de prototype
01 Authentification
02 Menu principal
03 Menu de profil utilisateur
112
Chapitre 06
04 Lordonnancement entre les dimensions. 05 Lordonnancement entre les niveaux dune dimension.
Exprimentations
06 Choix de lensemble des membres prfrs pour un niveau dune dimension.
07 Lordonnancement entre les membres prfrs dun niveau dune dimension.
08 Menu de contraintes de visualisation.
09 Slection des dimensions que lutilisateur souhaite voir sur le premier axe.
10 11 Slection des dimensions que Le nombre de graduations lutilisateur souhaite voir sur maximales pour chaque axe le second axe.
12 Menu des requtes non personnalises stockes sur le profil utilisateur.
113
Chapitre 06
Exprimentations
13 Renommer ou personnaliser une requte non personnalise prdfinie (enregistre sur le profil).
14 Menu des requtes non personnalises stockes sur le profil utilisateur.
15 Renommer ou excuter une requte personnalise prdfinie (enregistre sur le profil).
16 17 Slection de cube utilis pour Slection de lensemble des la requte. dimensions pour la clause SELECT.
18 Slection de lensemble des niveaux pour chaque dimension slectionne pour la clause SELECT.
114
Chapitre 06
Exprimentations
19 Slection de lensemble des membres pour chaque niveau slectionn de chaque dimension slectionne pour la clause SELECT.
20 Slection de lensemble des dimensions pour la clause WHERE.
21 Slectionner pour chaque dimension choisit pour la clause WHERE, un niveau et un membre pour ce niveau.
22 La requte gnre.
23 Sauvegarde de la requte gnre (non personnalise) sur le profil utilisateur.
24 Lensemble de toutes les requtes personnalises possible (due lutilisation de lordre partiel).
115
Chapitre 06
Exprimentations
25 26 Lutilisation de la Une requte personnalise discrimination peut rduire le peut admettre plusieurs nombre des requtes structures daffichages. personnalises.
27 La requte personnalise de la requte gnre.
28 La requte personnalise gnre (selon la structure choisie).
29 Sauvegarde de la requte personnalise sur le profil utilisateur.
30 Le rsultat dexcution dune requte personnalise.
Note : Il existe dautres fentres concernant les messages dinformations et les messages derreurs ne sont pas montres dans cette collection.
116
Chapitre 06 6.2 Exemples et discussions
Exprimentations
A travers lexemple pratique suivant, on va essayer daborder lobjectif principal de notre systme de personnalisation My Cube. Cet objectif consiste ne prsenter lutilisateur que les rsultats respectant ses prfrences figures dans son profil. Il sera aussi loccasion dvaluer lefficacit de notre algorithme
POSSIBLE_STRUCTURES pour la gnrations de lensemble de toutes les structures possibles pour un ensemble de rfrences en tenant compte les contraintes de visualisation de lutilisateur. Lvaluation de la proposition concernant la discrimination entre plusieurs sousensembles de rfrences ainsi que la suggestion pour une structure parmi un ensemble de plusieurs structures proposes par le systme font partie de lobjectif principal de cet exemple pratique.
6.2.1 Exemple 1 : Une seule requte, deux profils utilisateur, deux rsultats diffrentes : Soit Bena et Ali deux utilisateurs inscrits sur notre systme de personnalisation My Cube. Les prfrences des deux utilisateurs ainsi que leurs contraintes de visualisation sont dfinies comme suit : Profil de Bena : Lordonnancement des dimensions : Store > Time Product > Time Product > Marital Status Time > Warehouse > Customers > Measures > Gender Lordonnancement des niveaux pour chaque dimension : Customers : State Province > City > Name Product : Product Category > Product Name > Product Family > Product
117
Chapitre 06
Exprimentations
Departement > Product > Brand Name > SubCategory. Store : Store Country > Store Name > Store State > Store City. Time : Quarter > Year > Month. Warehouse : Country > Warehouse Name > State Province > City. Lordonnancement des membres prfrs pour chaque niveau de chaque dimension : Measures : Measures Level : Sales Count > Store Coste > Store Sales Customers : Country: USA > Canada > Mexico Gender : Gender : M > F Marital Status : Marital Status : M > S Product : Product Family : Food > Drink > Non-Consumable Product Departement : Meat > Eggs > Breakfast Foods>Dairy > SeaFood Product Category : Meat > Vegetables > Fruit > Bread > Eggs Promotion Media : Media Type : Product Attachement > TV > Radio Promotions: Promotion Name : Big Promo > Free For All > Three For One Store : Store Country : USA > Canada > Mexico Store Name : Store 19 > Store 20 > Store 9 Time : Year : 1998 > 1997 Quarter : Q3 > Q2 > Q4 > Q1 Month : 9 > 8 > 7 > 6 > 5 > 4 > 10 > 11 > 12 > 3 > 2 > 1 Yearly Income :Yearly Income : $90K $110K > $70K $90K > $50K $70K Warehouse : Country : USA > Canada > Mexico Placement des dimensions sur les deux axes : Axe1 = {Product} Axe2 = {Customers,Time} Contrainte de visualisation : G = (3,4) // c-a-d que lutilisateur veux voir au maximum trois graduations sur le premier axe et quatre sur le second.
118
Chapitre 06 Profil de Ali : Lordonnancement des dimensions : Measures > Gender Product > Gender Lordonnancement des niveaux pour chaque dimension : Product: Product Family > Product Category
Exprimentations
Lordonnancement des membres prfrs pour chaque niveau de chaque dimension : Measures : Measures Level : Store Coste > Sales Count > Store Sales > Unit Sales Gender : Gender : M > F Product : Product Family : Food > Drink > Non-Consumable Product Category : Dairy > Bread > Vegetables > Fruit Placement des dimensions sur les deux axes : Axe1 = {} Axe2 = {} Contrainte de visualisation : G = (2,3) // c-a-d que lutilisateur veux voir au maximum deux graduations sur le premier axe et trois sur le second.
Requte : Soit la requte MDX suivante que les deux utilisateurs iront excuter chacun sur son appareil PDA : SELECT [Measures].[Measures Level].Store Cost, [Measures].[Measures Level].Store Sales, [Measures].[Measures Level].Unit Sales, [Gender].[Gender].F, [Gender].[Gender].M, [Product].[Product Family].Food, [Product].[Product Family].Drink, [Product].[Product Family].Non-Consumable,
119
Chapitre 06 [Product].[Product Category].Dairy, [Product].[Product Category].Bread, [Product].[Product Category].Meat FROM Sales WHERE [Time].[Year].1997
Exprimentations
Il est clair que la requte ne prcise pas la structure daffichage puisque cest lapplication qui va la trouver. Daprs les deux profils utilisateur, on remarque que les dimensions de cette requte sont toutes ordonnes par lutilisateur Bena tandis que lutilisateur Ali nas pas un choix prcis entre les deux dimensions Product et Measures de la requte. Les niveaux des dimensions de la requte sont tous ordonns par les deux utilisateurs. Et ce qui concerne les membres employs par la requte, on remarque que lordonnancement est presque totale pour les deux utilisateurs sauf que lutilisateur Ali na pas de choix pour le membre Meat et la mme chose pour lutilisateur Bena par rapport le membre Bread. On passe maintenant lexcution de la requte par les deux utilisateurs : Bena : Pour cet utilisateur, et due son ordre utilis qui est presque total, la personnalisation de cette requte donne un seul sous ensemble des rfrences nomm query01 (Figure 01). Dans ce cas lutilisateur na pas besoin de la discrimination.
Figure 01
120
Chapitre 06
Exprimentations
Dans ltape suivante, lutilisateur obtient un ensemble de rfrence comportant une seule structure (Figure 02). On peut justifier ce rsultat par le fait que lutilisateur a dj choisi pralablement (dans son profil) de placer les deux dimensions Product et Time
respectivement sur le premier et le second axe et que le nombre de graduations sur le premier ne dpasse pas trois (3) et sur le second ne dpasse pas quatre (4). Aprs avoir slectionner le sous-ensemble de rfrences ainsi que la structure, il ne reste lutilisateur que de visualiser la syntaxe finale de
Figure 02
sa requte MDX personnalise (Figure 03) :
SELECT { [Product].[Product Category].[Dairy], [Product].[Product Category].[Meat], [Product].[Product Category].[Bread]} ON COLUMNS, CROSSJOIN( {[Measures].[Measures Level].[Unit Sales], [Measures].[Measures Level].[Store Cost]}, {[Gender].[Gender].[M], [Gender].[Gender].[F]} )ON ROWS FROM Sales WHERE [Time].[Year].[1997] Et finalement, lutilisateur excute la requte MDX personnalise et obtient le rsultat sur son appareil PDA (Figure 04).
121
Chapitre 06
Exprimentations
Figure 03
Figure 04
Pour lutilisateur Ali : Lordre partiel utilis par lutilisateur Ali va influe srement sur le rsultat de personnalisation de la requte MDX en question. Ali obtient un ensemble de deux sous-ensembles des rfrences nomms respectivement query 01 et query 02 (Figure 05).
Figure 05
122
Chapitre 06
Exprimentations
Lutilisateur Ali essaye dexploiter loption de la discrimination entre ces deux sous-ensembles de rfrences mais aucune suggestion nest propose par lapplication (Figure 06). a peut tre traduit par le fait que les deux sousensembles ne
contiennent aucune cellule vide ou bien quils ont le mme pourcentage dexistence cellules vides. des
Figure 07
Figure 06
Lutilisateur slectionne le second sous-ensemble de rfrences (image 07). Le systme My Cube propose lutilisateur deux structures (cet ensemble des structures est gnr par lalgorithme POSSIBLE_STRUCTURES)
pour visualiser le rsultat dexcution de cette requte MDX
personnalise sur son appareil PDA (Figure 08). Le filtrage propos

Figure 08
par le systme ne donne aucune
nouvelle lutilisateur (nous nutilisons pas un seuil pour notre prototype My Cube) (Figure 09).
Figure 09
123
Chapitre 06
Exprimentations Lutilisateur na pas dautre choix que de slectionner lune des deux structures proposes et finalement il choisit la seconde structure (image 10).
Figure 10
La syntaxe finale de la requte MDX personnalise (pour le sous-ensemble des rfrences et la structure slectionns) est maintenant devant lutilisateur sur son PDA (Figure 11) : SELECT CROSSJOIN({[Gender].[Gender].[M], [Gender].[Gender].[F]}, { [Product].[Product Family].[Food]})ON COLUMNS, {[Measures].[Measures Level].[Store Cost], [Measures].[Measures Level].[Store Sles], [Measures].[Measures Level].[Unit Sales]} ON ROWS FROM Sales WHERE [Time].[Year].[1997]
Figure 11
Il ne reste lutilisateur Ali que dexcuter la requte personnalise pour afficher le rsultat associ (Figure 12).
Figure 12
124
Chapitre 06 Discussion des rsultats
Exprimentations
On peut remarquer que les deux utilisateurs ont interrog le systme My Cube afin dobtenir des rponses leurs requtes qui tait identiques au dpart, mais au cours des diffrentes phases du processus de personnalisation, les deux utilisateurs ont eu des ensembles de rfrences et des structures diffrentes qui ont men finalement des rponses diffrentes. Pour ceux qui nont pas une ide claire sur le concept de personnalisation vont srement imaginer quil y a une anomalie dans le systme qui mne ces rponses diffrentes. Mais il faut savoir que cest lune des principales caractristiques dun systme de personnalisation bas sur lutilisation des profils utilisateur. Puisque cest le contenu (prfrences) de ces derniers qui dtermine les lments qui doivent apparatrent dans le rsultat et mme la forme que ce dernier doit prendre dans laffichage.
6.2.2 Exemple 02 : Discriminations et suggestions 6.2.2.1 Discrimination entre les sous-ensembles de rfrences Pour cet exemple, et pour certaines raisons danalyse, lutilisateur Bena formate la requte suivante : SELECT [Product].[Product Family].[Food], [Product].[Product Family].[Drink], [Product].[Product Family].[Non-Consumable], [Promotion Media].[Media Type].[Bulk Mail], [Promotion Media].[Media Type].[Radio], [Store]. [Store Country].[Canada], [Store].[Store Country].[Mexico], [Store].[Store Country].[USA], [Store].[Store Name].[Store 19], FROM Sales WHERE [Measures].[Measures Level].[Sales Count]
125
Chapitre 06
Exprimentations
Lors de lexcution de la requte, le systme renvoie deux sous-ensembles de rfrences (Figure 13) due au soutient de lordre partiel (lutilisateur na pas de prfrences entre quelques dimensions parmi celles utilises dans la requte). Les deux sous ensembles de rfrences sont : (Avec comme niveaux (Levels): Product Family, Media Type, Store Country pour respectivement les dimensions Product, Promotion Media et Store)
R0 : Food, Bulk Mail, USA Drink, Bulk Mail, USA Food, Bulk Mail, Canada Food, Radio, USA Drink, Bulk Mail, Canada Food, Bulk Mail, Mexico Drink, Radio, USA Food, Radio, Canada Drink, Bulk Mail, Mexico Drink, Radio, Canada Food, Radio, Mexico Drink, Radio, Mexico R1 : Food, Bulk Mail, USA Drink, Bulk Mail, USA Food, Bulk Mail, Canada Food, Radio, USA Drink, Bulk Mail, Canada Non-Consumable, Bulk Mail, USA Drink, Radio, USA Food, Radio, Canada Drink, Radio, Canada Non-Consumable, Bulk Mail, Canada Non-Consumable, Radio, USA Non-Consumable, Radio, Canada
Figure 13
Lutilisateur Bena ne sait pas lequel parmi ces deux sous-ensembles de rfrences qui est pertinent en terme de nombre des cellules vides que contient chacun. Pour ne pas tomber dans le mauvais choix, il prfre passer cette responsabilit au systme qui va calculer le nombre des cellules vides pour chacun des deux sous-ensembles de rfrences afin de ne garder pour lutilisateur que celui qui ralise le plus petit nombre (Figure 14).
Figure 14
126
Chapitre 06
Exprimentations
Aprs les calculs, le systme trouve que R0 est mieux que R1 en terme de nombre doccurrences de la cellule vide (Figure 14). Pour que le rsultat soit confiant lutilisateur Bena, ce dernier excute les deux sous-ensembles de rfrences afin de comparer le nombre des cellules vides quils contiennent. Dans les deux cas, le systme propose lutilisateur une seule structure selon la contrainte de visualisation choisie : Pour lensemble R0 : Structure : {Store} AND {Product, Promotion Media} Requte : SELECT { [Store].[Store Country].[USA], [Store].[Store Country].[Canada], [Store].[Store Country].[Mexico]} ON COLUMNS, CROSSJOIN( {[Product].[Product Family].[Food], [Product].[Product Family].[Drink]}, {[Promotion Media].[Media Type].[Bulk Mail], [Promotion Media].[Media Type].[Radio]}) ON ROWS FROM Sales WHERE [Measures].[Measures Level].[Sales Count] Rsultat : montr sur la Figure 15. Pour lensemble R1 : Structure : { Product } AND { Promotion Media, Store } Requte : SELECT { [Product].[Product Family].[Food], [Product].[Product Family].[Drink], [Product].[Product Family].[Non-Consumable] } ON COLUMNS, CROSSJOIN( { [Promotion Media].[Media Type].[Bulk Mail], [Promotion Media].[Media Type].[Radio] }, { [Store].[Store Country].[USA], [Store]. [Store Country].[Canada] } ) ON ROWS
127
Chapitre 06
Exprimentations
FROM Sales WHERE [Measures].[Measures Level].[Sales Count] Rsultat : montr sur la Figure 16.
Figure 15
Figure 16
Discussion des rsultats Daprs les rsultats obtenus on a : - Le nombre total pour chacun des deux rsultats gale 12. - Le nombre des cellules vides dans R0 gale 2. - Le nombre des cellules vides dans R1 gale 8. Si en dsigne par Pr_Null le pourcentage dapparition des cellules vides dans chacun des deux rsultats, ce pourcentage est donn par : Pr_Null = Pour R0 : Pr_Null =
nombre des cellules vides nombre total des cellules
2 1 8 2 = et pour R1 : Pr_Null = = 12 6 12 3
Ce rsultat justifie le choix de systme pour le sous ensemble R0 puisque il montre que le pourcentage dapparition des cellules vides dans R0 gale
2 3 1 et 6
il est moins que , le pourcentage dapparition des cellules vides apparaissant dans R1.
128
Chapitre 06
Exprimentations
6.2.2.2 Suggestions pour un ensemble des structures proposes Considrons que lutilisateur Bena chang la contrainte de visualisation par la suivante : G<4,6> et quil na pas prciser des dimensions mettre sur chacune des deux axes. Dans cet exemple, lutilisateur Bena veut savoir si la situation maritale (S ou M) dune personne influe sur leur consommation des produits laitiers (Dairy) et les boissons (Drinks) pendant lanne 1997 ? Pour obtenir une rponse cette problmatique, lutilisateur Bena va construit la requte suivantes : SELECT [Measures].[Measures Level].Unit Sales, [Marital Status].[ Marital Status].M, [Marital Status].[ Marital Status].S, [Product].[Product Category].Drinks, [Product].[Product Category].Dairy, FROM Sales WHERE [Time].[Year].1997 La personnalisation dune telle requte par le systme My Cube donne lutilisateur le sous-ensemble de rfrences suivant : { MeasuresLevel Marital Status Product Category | Unit Sales, M, Dairy, MeasuresLevel Marital Status Product Category | Unit Sales, S, Dairy, MeasuresLevel Marital Status Product Category | Unit Sales, M, Drinks, MeasuresLevel Marital Status Product Category | Unit Sales, S, Drinks} Basant sur lalgorithme POSSIBLE_STRUCTURES, le systme propose lutilisateur lensemble des structures suivantes (Figure 17) :
129
Chapitre 06 1. { Measures } et { Marital Status Product } 2. { Marital Status } et { Measures Product } 3. { Product } et { Measures Marital Status } 4. { Marital Status Product } et { Measures } 5. { Measures Product } et { Marital Status } 6. { Measures Marital Status } et { Product }
Exprimentations
Si lutilisateur Bena ne veut garder que les structures qui ont des nombres de graduation identiques ou rapprochs pour les deux axes, alors il doit cocher Structures with only nearest axis.
Figure17
Dans ce cas, le systme va comparer toutes les structures de lensemble afin de garder celles qui ont une diffrence entre les nombres de graduation des deux axes minime (Figure 18). Sinon, sil ne trouve aucune diffrence, alors il va comparer cet ensemble basant sur la diffrence entre les nombres des dimensions sur les deux axes, afin de ne garder que celles qui ralisent le nombre minimum. 2. { Marital Status } et { Measures Product } 3. { Product } et { Measures Marital Status } 5. { Measures Product } et { Marital Status } 6. { Measures Marital Status } et { Product }
Les rsultats dexcution en utilisant lensemble de rfrences avec chacune de ces structures filtres seront : (Figure 19, Figure 20, Figure 21 et Figure 22 pour respectivement les structures 2, 3, 5 et 6).
Figure18
130
Chapitre 06
Exprimentations
Figure 19
Figure 20
Figure 21
Figure 22
Tandis que les rsultats dexcution de lensemble de rfrences pour les structures limines suivant : 1. { Measures } et { Marital Status Product } 4. { Marital Status Product } et { Measures } Sont respectivement (Figures 23 et 24 ):
131
Chapitre 06
Exprimentations
Figure 23
Figure 24
Discussion des rsultats Daprs les deux ensembles des rsultats, il est clair que le but de cette optimisation est de supporter les visualisations qui garantissent un placement des donnes (sinon des dimension) quitable ou bien rapproch sur les deux axes de cube rsultant. Cette ide ne veut pas dire que les structures limines sont indsirables, puisque toutes les structures proposes par le systme sont correctes, mais cest juste pour allger le choix de structure pour lutilisateur en cas o lensemble des structures proposes par le systme est assez grand.
6.3 Conclusion Ce chapitre t un champ dessai pour donner un aperu pratique pour le prototype dvelopp My Cube ainsi que son fonctionnement de base. Les exemples traits dans ce chapitre Aprs avoir explor les algorithmes de personnalisation des requtes OLAP dans la partie prcdente, cette partie a pour objectif de montrer et discuter le prototype dvelopp My Cube qui implmente ces algorithmes de
personnalisation. Ce prototype consiste en une simulation dune application java sexcutant sur un tlphone mobile dun utilisateur.
132
Chapitre 06
Exprimentations
A travers lexemple pratique suivant, on va essayer daborder lobjectif principal de notre systme de personnalisation My Cube. Cet objectif consiste ne prsenter lutilisateur que les rsultats respectant ses prfrences figures dans son profil. Il sera aussi loccasion dvaluer lefficacit de notre algorithme
POSSIBLE_STRUCTURES pour la gnrations de lensemble de toutes les structures possibles pour un ensemble de rfrences en tenant compte les contraintes de visualisation de lutilisateur. Lvaluation de la proposition concernant la discrimination entre plusieurs sousensembles de rfrences ainsi que la suggestion pour une structure parmi un ensemble de plusieurs structures proposes par le systme font partie de lobjectif principal de cet exemple pratique.
133
Conclusion et perspectives
Chapitre 07 : Conclusion et perspectives
7.1 Conclusion travers ce travail, on a essay dclairer la notion de personnalisation, ses enjeux dans les diverses disciplines et surtout denlever certaines ambiguts qui entourent ce concept dans les entrepts de donnes. Daprs cette tude, on a constat que la personnalisation dans les entrepts de donnes et comme dans les bases de donnes relationnelles, elle est base sur lutilisation de profil utilisateur pour lui donner une rponse approprie ses prfrences. Le principe est lorsquun utilisateur interroge un entrept de donnes par une requte OLAP, ses prfrences stockes dans son profil doivent tres prises en considration. Certaines particularits qui caractrisent les entrepts de donnes exigent lintroduction des autres factures tel que la prsentation des rsultats. Cette information est aussi stocke dans le profil de lutilisateur et lui permet dexprimer la forme que doit prendre le rsultat dexcution de sa requte OLAP. Pour ce mme objectif en question (donner lutilisateur ce qui lui convient), il y a des travaux rcents qui adoptent la notion de recommandation. Dans ce contexte, la recommandation figure dans lenrichissement de schma de lentrept de donnes par des nouveaux niveaux de granularit ou par la suggestion des requtes OLAP lutilisateur en basant sur lenchanement des requtes des autres utilisateurs qui le prcdent sur le mme systme. Afin de concrtiser la notion de personnalisation dans les entrepts de donnes, on a ralis un prototype appel My Cube. Daprs ce prototype, on a
134
Conclusion et perspectives essay de synthtiser les principales fonctionnalits dun systme de personnalisation. Les algorithmes employs dans ce prototype sont lalgorithme de personnalisation de contenu [Bellatreche et al, 2006] et notre algorithme POSSIBLE_STRUCTURES pour la gnration des structures possibles pour un ensemble des rfrences. Le principal objectif de lensemble des exemples pratiques raliss avec notre prototype t la dmonstration de lefficacit des algorithmes employs dans limplmentation de ce prototype, ainsi que pour dmontrer les avantages des diffrentes propositions. Les qualits des diffrents rsultats obtenus dmontrent lutilit de la personnalisation dans les systmes dinformation, et quel confort offre aux utilisateurs ds quils obtiennent ce quils veulent sans quils soient surchargs par des informations qui ne les intresse plus.
7.2 Perspectives Au cours de la ralisation de notre systme de personnalisation My Cube, on a remarqu quil y a des difficults pour personnaliser la forme que doit prendre le rsultat sur lcran de PDA. Ces difficults sont traduites par le fait que les algorithmes de personnalisation de prsentation ne prennent pas en considration la longueur des noms des dimensions, des niveaux et des membres qui sont variables. Par exemple pour le niveau Category de dimension PRODUCT, on a les trois membres suivants : Food, Drink et Non-Consumable avec les longueurs 4, 5 et 14 respectivement. On peut remarquer facilement que la longueur de membre Non-Consumable reprsente presque longueur de membre Food ainsi que la longueur de membre Drink. Dans ce cadre, on propose comme perspective de prendre en considration dans les algorithmes de slection des structures, les variations entre les longueurs des noms des diffrentes granularits (dimensions, niveaux et trois fois la
135
Conclusion et perspectives membres) lors de test de la satisfaction des structures pour un ensemble de rfrences. Ainsi, et toujours comme perspective dans ce qui concerne le profil utilisateur, on peut proposer de gnrer une synthse des prfrences quil contient afin de lexploit dans le processus de personnalisation. Le principe de cette synthse est de souligner toutes les correspondances qui existent entre les prfrences de lutilisateur dans lentrept de donnes afin dutiliser ces informations lors de processus de personnalisation pour liminer les lments menant a des rsultats nuls (cellules vides). Si on arrive considr cette notion de synthse de profil discut prcdemment, nous serons en face dun autre problme figurant dans le fait que lordonnancement des diffrents lments de granularit (dimensions, niveaux et membres) de lentrept de donnes peut tre chang dune situation une autre selon les ensembles des lments (rfrences) de granularit slectionns pour chaque situation. Et dans ce cadre l, et comme perspective, on peut penser un nouveau type dordonnancement que lon appellera ordre occasionnel. Le nouveau type dordre sera un ordre variable selon lensemble des rfrences slectionnes. Finalement, et comme perspective, si lon veut avoir appui sur une ontologie pour dcrire les profils utilisateurs dans un domaine donn, il faut trouver un mcanisme de transition entre les ontologies dcrivant les profils utilisateurs pour diffrents domaines tout en conservant la cohrence des prfrences de lutilisateur. Par exemple, si un usager dans un secteur sanitaire utilisant un systme personnalis veut naviguer sur un autre systme biologique personnalis, et que les deux systmes utilisent chacun une ontologie pour dcrire les profils de ses usagers. Alors il sera trs utile dutiliser une autre ontologie pour faire passer le profil de lusager du secteur sanitaire vers le secteur biologique.
136
Bibliographie
Bibliographie
[Agrawal et Wimmers, 2000] Agrawal, R. and Wimmers, E. L. (2000). A framework for expressing and combining preferences. In Chen, W., Naughton, J. F., and Bernstein, P. A., editors, Proceedings of the 2000 ACMSIGMOD International Conference onManagement of Data, May 16-18, 2000, Dallas, Texas, USA, pages 297306. ACM. [Agrawal et al., 2003] Agrawal, S., Chaudhuri, S., Das, G., and Gionis, A. (2003). Automated ranking of database query results. In CIDR. [Amato et Straccia, 1999] User Profile Modeling and Applications to Digital Libraries, Giuseppe Amato, Umberto Straccia , Proc. 3rd European Conf. Research and Advanced Technology for Digital Libraries, ECDL, 1999. [Bellatreche et al., 2005] Bellatreche, L., Giacometti, A., Marcel, P., Mouloudi, H., and Laurent, D. (2005). Apersonalization framework for olap queries. In Song, I.-Y. and Trujillo, J., editors, DOLAP, pages 918. ACM. [Bellatreche et al., 2006] Bellatreche, L., Giacometti, A., Marcel, P., and Mouloudi, H. (2006). Personalization of mdx queries. In BDA06 : 22`emes journes Bases de Donnes Avances, Lille, 17-20 octobre 2006, Actes. [Bentayeb et al, 2009] Fadila Bentayeb, Ccile Favre: RoK: Roll-Up with the K-Means Clustering Method for Recommending OLAP Queries. DEXA 2009: 501-515 [Bouzeghoub et Kostadinov, 2005] M. Bouzeghoub et D. Kostadinov. Personnalisation de linformation : Aperu de ltat de lart et dfinition dun modle flexible de dfinition de profils. In Actes de la 2nde Confrence en Recherche dInformation et Applications CORIA. [Bradley et Rafter, 2000] Case-Based User Profiling for Content Personalisation, K. Bradley, R Rafter, B. Smyth, Lecture Notes in Computer Science, 2000 [Chomicki, 2002] Chomicki, J. (2002). Querying with intrinsic preferences. [Chomicki, 2003] Chomicki, J. (2003). Preference formulas in relational queries. ACM Trans. Database Syst., 28(4) :427466. [Chomicki, 2004] J. Chomicki. Semantic Optimization of Preference Queries. In International Symposium on Constraint Databases, pages 133148, Paris, France, June 2004. Springer-Verlag, LNCS 3074. [Chomicki et Song, 2005] J. Chomicki and J. Song, Monotonic and Nonmonotonic Preference Revision, in Proc. IJCAI 2005 Multidisciplinary Workshop on Advances in Preference Handling, Edinburgh, Scotland, UK, (2005). [Chomicki, 2006] J. Chomicki. Iterative Modification and Incremental Evaluation of Preference Queries. In International Symposium on Foundations of Information and Knowledge Systems (FOIKS), pages 6382. Springer, LNCS 3861, 2006. [Codd et al., 1993] Codd, E. F., Codd, S. B., and Salley, C. T. (1993). Providing olap (on-line
137
Bibliographie
analytical processing) to user-analysts : An it mandate. In Technical Report. [Crabtree et Soltusiak, 1998] Soltysiak S., Crabtree B., Automatic learning of user profilestowards the personalisation of agent services, BT Technol J. Vol 16 No 3, July 1998, pp 110117. [Croft et Cronen, 2001] Croft W. B., Cronen-Townsend St., Lavrenko V., Relevance Feedback and Personalization:A Language Modeling Perspective, In: Proceedings of the Second DELOS Network of Excellence Workshop on "Personalisation and Recommender Systems in Digital Libraries", Dublin City University, Ireland, 18-20 June 2001. [Das et al., 2006] Das, G., Hristidis, V., Kapoor, N., and Sudarshan, S. (2006). Ordering the attributes of query results. InChaudhuri, S.,Hristidis,V., and Polyzotis,N., editors, SIGMOD Conference, pages 395406. ACM. [Endres et Kieling, 2006] Markus Endres and Werner Kieling, Transformation of TCPNet Queries into Preference Database Queries [Endres et Kieling, 2008a] M. Endres and W. Kieling. Optimization of Preference Queries under Hard Sum Constraints. In Proceedings of the 4th Multidisciplinary Workshop on Advances in Preference Handling (AAAI). Chicago, Illinois (USA), 2008. [Endres et Kieling, 2008b] In Proceedings of the ACM Conference VLDB 08, August 2430, 2008, Auckland, New Zealand [Ferreira et Silva, 2001] MySDI:A Generic Architecture to Develop SDI Personalised Services, J. Ferreira, A. Silva, ICEIS (1) 2001: 262-270 [Fink 2000] A Review and Analysis of Commercial User Modeling Servers for Personalization on the World Wide Web, J.Fink, A. Kobsa, User Modeling and User-Adapted Interaction 10: pp. 209-249, 2000 [Gatz et al., 1999] Gatziu S., Jeusfeld M.A., Staudt M., Vassiliou Y., "Design and Management of Data Warehouses", Report on the DMDW'99, ACM SIGMOD Record, 28(4), Dec. 1999. [Giacometti et al, 2008] Giacometti, A., P. Marcel, et E. Negre (2008). A Framework for Recommending OLAP Queries. In 11th ACM International Workshop on Data Warehousing and OLAP (DOLAP 08), Napa Valley, California, USA, pp. 7380. [Hassina, 2007] Hassina MOULOUDI, Personnalisation de requtes et visualisations OLAP sous contraintes, THSE POUR OBTENIR LE GRADE DE DOCTEUR, cole Doctorale : Sant, Sciences et Technologies,Universit Franois Rabelais Tours,2007 [Inmo, 1996] Inmon W.H., "Building the Data Warehouse", John Wiley&Sons, ISBN 047114161-5. [Jameson, 1999] Jameson A., User Adaptive Systems An integrated Overview. Tutorial presented at the 7th International Conference on User Modeling, June 20-24, 1999. [Jark et al., 1999] Jarke M., Lenzerini M., Vassiliou Y., Vassiliadis P., "Fundamentals of Data Warehouses", Ed. Springer Verlag, ISBN 3-540-65365-1, 1999.
138
Bibliographie
[Kostadinov, 2003] KOSTADINOV Dimitre. Personnalisation de l'infornation et gestion des profls utilisateurs : rapport ralis en 2003 pour l'obtention d'un DEA, Universit de Versailles. [Kimball, 1996] Kimball, R. (1996). The Data Warehouse Toolkit. John Wiley & Sons. [Kieling, 2002] Kieling,W. (2002). Foundations of preferences in database systems. InVLDB : Proceedings of 28th International Conference on Very Large Data Bases, [Kieling et Kostler, 2002] W. Kieling and G. Kostler, Preference SQL - Design, Implementation, Experiences., in Proceedings of the International Conference on Very Large Data Bases (VLDB), pp. 9901001, Hong Kong, China, (2002). [Kieling, 2005] W. Kieling. Preference Queries with SV-Semantics. In Proceedings of the 11th International Conference on Management of Data (COMAD), pages 1525, 2005. 11th International Conference on Management of Data (COMAD), pages 1525, 2005. [Koutrika et Ioannidis, 2004] Koutrika, G. and Ioannidis, Y. E. (2004). Personalization of queries in database systems. In ICDE 04 : Proceedings of the 20th International Conference on Data Engineering, pages 597608, Washington, DC, USA. IEEE Computer Society. [Koutrika et Ioannidis, 2005a] Koutrika, G. and Ioannidis, Y. E. (2005a). Constrained optimalities in query personalization. In SIGMOD Conference, pages 7384. [Koutrika et Ioannidis, 2005b] Koutrika,G. and Ioannidis, Y. E. (2005b). Personalized queries under a generalized preference model. In ICDE, pages 841852. [Koutrika et al., 2006] Koutrika,G., Simitsis,A., and Ioannidis, Y. E. (2006). Prcis : The essence of a query answer. In ICDE, page 69. [Pretschner et Gauch, 1999] Pretschner, A. and Gauch, S. (1999). Personalization on the web.Technical report, Information and Telecommunication Technology Center, Department of Electrical Engineering and Computer Science, The University of Kansas. [Romero et Abell, 2007] Romero, O. and Abell, A. (2007). On the need of a reference algebra for olap. In Song, I. Y., Eder, J., and Nguyen, T. M., editors, DaWaK, volume 4654 of Lecture Notes in Computer Science, pages 99110. Springer. [Wido, 1995] J. Widom, "Research problems in data warehousing", ACM CIKM'95, 1995.
139

Perso OLAP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Perso OLAP

Uploaded by

Copyright:

Available Formats

Rpublique algrienne dmocratique et populaire

Mr. BENAOUDA Habib

Personnalisation des requtes

devant le jury compos de :

Chapitre 03 : La personnalisation dans les bases de donnes relationnelles

Chapitre 04 : La personnalisation des requtes OLAP

Chapitre 07 : Conclusion et perspectives

7.1 Conclusion . 134 7.2 Perspectives ... 135

Chapitre 01 : Introduction gnrale

Chapitre 02 : La personnalisation de linformation

l'interaction (ge, sexe, etc.),

Apprises par le systme au cours de l'utilisation (profil dynamique)

La personnalisation dans les bases de donnes relationnelles

Chapitre 03 : La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

[Das et al, 2006].

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

La personnalisation dans les bases de donnes relationnelles

Oui (fonction combine)

Tuples (Prend en considration le mode dynamique de prfrences)

Oui (cinq types de composition)

2005 Quantitative et Qualitative

Formule de prfrence et Fonction de score

Oui (pareto rankF)

Contenu et Forme / Avant et Aprs

Chapitre 04 : La personnalisation des requtes OLAP

Chapitre 04 4.3 La personnalisation des requtes OLAP

Figure 5-a : Entrept de donnes LCL initial.

(segmentation), YEAR (anne) et AGENCIES GROUP (AgenciesGroupName).

Chapitre 04 Tel que :

Figure 9: lalgorithme Maxsubset[Bellatreche et al, 2006]

Chapitre 05 cet ensemble des structure celles qui ne visualisation VT,G .

Contribution respecte pas la contrainte de

1. Let Next_Set ={} 2. For every S={x1,x2} of SET do 3. 4. 5. 6. 7.

For every e x2 do Let S2 = {x3,x4} such that x3 = x1 U e

Remove e from x4 If For every S of Next_Set S != S2 then Insert S2 in Next_Set

14. end while

Output : One_SET, A set of subsets of two subesuets such that :