La personnalisation dans les entrepôts de données.

République Algérienne Démocratique et Populaire
‫وزارة ا ـــ ــ ــــــ ا ــــ ـــــ و ا ـــ ـــــ ا ــ ــ ــــــــ‬
Ministère de l'Enseignement Supérieur et de la Recherche Scientifique
UNIVERSITE DES SCIENCES ET DE LA TECHNOLOGIE d'ORAN Mohamed Boudiaf
Faculté des Sciences
Département d'Informatique
Spécialité : Informatique
Option: Système, Réseaux et bases de données
MEMOIRE
Présenté par
Mr. KHALLADI Rachid.
Pour l'obtention du diplôme de Magister en Informatique
Thème
La personnalisation dans les entrepôts de données.
Devant la commission d'examen composée de :
Qualité
Président
Rapporteur
Examinateur
Examinateur
Noms et Prénoms
Mme. BELBACHIR Hafida
Mme. ZAOUI Lynda
Mr. RAHAL Sid Ahmed
Mme. NAIT-BAHLOUL Safia
Grade
Professeur
M.conf.A
M.conf.A
M.conf.A
Etb d'origine
USTO
USTO
USTO
ES-SENIA
Année universitaire : 2014-2015
Résumé
Les entrepôts de données sont devenus aujourd’hui incontournable dans le
domaine de l’aide à la prise de décision. Couplés avec les possibilités des
techniques OLAP, ils permettent une étude analytique poussée des données,
procurant une efficace aide à la décision dans tous les domaines.
Aujourd’hui l’information joue un rôle capital dans le processus d’aide à la
décision (connaitre la bonne information au bon moment), et comme la volumétrie
des données connues pour être importante dans les entrepôts de données, le role
central que joue l’utilisateur dans le processus décisionnel, au niveau de l’analyse
en ligne et les limitées montrées par les systèmes OLAP quant la prise en compte
de ses preferences sont les éléments qui justifient pleinement le recours à la
personnalisation afin de lui offrir des informations pertinentes répondant a ses
besoins attendus.
Notant que ces dernières années, on assiste à une forte inflation de volume
d’informations en raison de l’accroissement des capacités de calcul et de stockage,
dans ce contexte de surcharge d’informations, il y a lieu de développer des outils
informatiques pour faciliter la recherche et l’extraction rapide de l’information
pertinente. Un de ces outils et la personnalisation qui consiste à répondre au mieux
aux attentes de chaque utilisateur.
Le but principal, fixé au début du mémoire, était de concevoir et de réaliser
un système d’interrogation personnalisé d’un entrepôt de données. La modélisation
et la gestion des préférences utilisateur, l’exploitation du profil utilisateur dans la
transformation de ses requêtes, dans la manière avec laquelle sont présentés ces
résultats et enfin la réutilisation de ses requêtes posées précédemment sont les
contributions principales apportées dans ce mémoire.
Afin de parvenir cet objectif, nous avons, au cours de notre etude
bibliographique, passé en revue quelques notions théoriques entourant le sujet.
Nous avons donc présenté les entrepôts de données et illustré, à l’aide d’exemples,
les différentes possibilités qu’ils offrent. Ensuite, nous avons décrit les systèmes
OLAP (ROLAP, HOLAP et DOLAP) dont ils sont issus et les opérations
effectuées sur les cubes de données afin de mieux exploiter les données de ces
derniers.
Par la suite, l’étude sur les langages et outils disponibles qui permettent
l’interrogation des entrepôts de données nous a conduits à opter pour la
personnalisation des requêtes écrites en langage MDX. Du fait que ce langage est
le plus utilisé actuellement dans l’interrogation des entrepôts de données.
Sur la personnalisation de l’information, nous avons présenté les notions de
profil utilisateur, préférence utilisateurs et le processus de personnalisation.
Afin de concrétiser la notion de personnalisation dans les entrepôts de
données, on a réalisé un prototype appelé Personnalisation. A travers celui-ci,
nous avans essayé de synthétiser les principales fonctionnalités d’un système de
personnalisation. Les algorithmes employés dans ce prototype sont l’algorithme de
personnalisation de contenu [Bellatreche et al, 2006] et notre algorithme
STRUCTURATION pour la génération des structures possibles pour un ensemble
des références.
Le principal objectif de l’ensemble des exemples pratiques réalisés avec
notre prototype était la démonstration de l’efficacité des algorithmes employés
dans l’implémentation de ce prototype, ainsi que pour démontrer les avantages des
différentes propositions.
Les qualités des différents résultats obtenus démontrent l’utilité de la
personnalisation dans les systèmes d’information, et le confort offert aux
utilisateurs dés qu’ils obtiennent ce qu’ils veulent sans qu’ils soient surchargés par
des informations qui ne les intéresse plus.
Introduction générale
Chapitre I :
Les entrepôts de données.
1. Introduction
09
2. Vocation des entrepôts de données
09
2.1 Intégration des sources de données
09
2.2 Au cœur de l’architecture décisionnelle
11
3. Stratégie de conception et de modélisation des entrepôts de données
12
3.1 Stratégie de conception
13
3.2 Conception de base et de modélisation des entrepôts de données
14
4. Exploitation de l’entrepôt et analyse OLAP
15
4.1 Types d’OLAP
15
4.2 Analyse d’OLAP
16
17
7. Conclusion
Chapitre II :
Les langages d'interrogation des entrepôts de données.
1. Introduction
19
2. Les langages de données
19
2.1 Types de langage de données
3. L’extension du SQL
19
19
4. Les langages graphique de manipulation de données
20
4.1. GHRAPHIC OLAP-SQL
21
4.2 GOGNOS PowerPlay 7.3
21
4.3 CRYSTAL Analysis 10
21
4.4 RATINAL Rose XDE
22
4.5 Limitations des langages graphiques.
22
5. Le langage script de manipulation de données MDX
22
5.1 Définition
22
5.2 Caractéristiques de MDX
22
5.3 Forme d’une requête OLAP sous MDX
22
5.4 Structure du résultat d’une requête MDX
23
5.5 Les avantages et inconvénients du MDX
24
24
6. Conclusion
Chapitre III :
La personnalisation des données.
1. La personnalisation de l’information
26
1.1 Architecture du system personnalisé
26
2.1. Les domaines d’utilisation de la personnalisation de l’information
27
2. Le profil d’utilisateur
28
2.1. Définition
28
2.2. Contenu du profil utilisateur
28
3. Les préférences utilisateur
29
3.1. Des préférences sur le contenu de la réponse a la requête
29
3.2 Des préférences sur la présentation de la réponse
29
3.3 Des conditions d’exploitations
30
4. Le langage des préférences
30
4.1. Les types d’approches de modélisation
31
4.2. Caractéristiques d’un langage de préférence
31
31
5. La personnalisation et OLAP
5.1. Le processus de personnalisation
31
5.2. Types de personnalisation
32
5.3. Types des requêtes
33
6. Travaux de personnalisation dans les entrepôts de données
33
6.1 La personnalisation inspiré de la recherche d’information
33
6.2 La personnalisation dans l’évolution des schémas
40
6.3 La personnalisation dans la réutilisation des requêtes
44
6.4 La personnalisation contextuelle
47
49
7. Conclusion
Chapitre IV :
Conception et implémentation.
1. Introduction
2. L’Algorithme FINDStruct
52
53
3. L’Algorithme STRUCTURATION
54
4. Discrimination entre plusieurs ensembles de références
60
5. Simplification du choix de l’utilisateur pour une structure parmi un ensemble
60
6. Implémentation
62
6.1 Le prototype ‘ Personnalisation ‘
62
6.2. Technologies employées
63
6.3. Principe de base de l’application
63
6.4 Présentation de l’application
64
6.5 Quelques fenêtres du prototype
68
6.6 Exemples et discussion
70
7. Conclusion
Conclusion générale
75
FIG.1
FIG.2
FIG.3
FIG.4
FIG.5
FIG.6
FIG.7
FIG.8
FIG.9
FIG.10
FIG.11
FIG.12
FIG.13
FIG.14
FIG.15
FIG.16
FIG.17
FIG.18
FIG.19
FIG.20
FIG.21
FIG.22
FIG.23
FIG.24
FIG.25
FIG.26
FIG.27
FIG.28
FIG.29
FIG.30
Architecture Décisionnelle
Cube « Ventes »
Architecture d’un système de personnalisation
La personnalisation avant l’accès aux données de cube
La personnalisation après l’accès aux données de cube
Ordre sur les visualisations
Exemple de grille d’analyse
Architecture générale d’un entrepôt de donnée évolutif
Principe du modele R-DW
Définition des liens d’agrégations
Schéma multidimensionnelle pour observer le NBI
Schéma de la dimension AGENCE
Schéma multidimensionnelle pour observer le NBI selon le type
agence
Schéma d’une base de contexte
Exemple de recommandation
Exemple de hiérarchie des attribues du contexte
L’algorithme FindStruct
Architecteur de système « Personnalisation »
Requête personnalisée
Requête personnalisée
Résultat de requête
Résultat de requête
Liste des structures possibles
Liste des structures possibles
Résultat de requête
Résultat de requête
Résultat de requête
Résultat de requête
Résultat de requête
Résultat de requête
11
23
26
32
32
38
39
41
41
42
43
43
44
45
46
48
53
62
72
72
72
72
73
74
74
74
74
74
74
74
Un entrepôt de données peut être vu comme une grosse base de données modélisée pour
accueillir, après nettoyage et homogénéisation, les informations en provenance des différents
systèmes de production de l’entreprise.
Il est vrai que la création de l’entrepôt n’est pas un objectif final. L’important, c’est son
exploitation. La vocation de l’entrepôt de données est de supporter l’analyse des données. Ainsi,
l’entrepôt de données constitue un support pour les outils d’analyse en ligne issus de la
technologie OLAP (On-Line Analytical Processing). Ce sont ces outils qui permettent
d’accompagner les décideurs d’une entreprise en leur fournissant une possibilité de naviguer
facilement dans les données.
Ainsi l’entrepôt de données permet d’offrir des contextes d’analyses aux utilisateurs pour
les aider dans leur prise de décision. Il s’avère alors que les utilisateurs peuvent avoir besoin de
contextes d’analyses spécifiques, répondant à des besoins particuliers voir individuels d’où la
personnalisation.
La personnalisation a pour objectif de faciliter l’expression des besoins de l’utilisateur
afin de ne retenir que les informations qualifiées pertinentes pour un sujet donné en écartant
celles non pertinentes. Cependant, cette pertinence est définit par un ensemble de critères et de
préférences personnalisables et spécifiques à chaque utilisateur ou communauté d’utilisateurs et
stocké dans une structure appelée Profil Utilisateur. Dans ce contexte, plusieurs approches ont vu
le jour, et chacune d’elles aborde la notion de personnalisation selon ses idées mais l’objectif
commun est d’acheminer des solutions efficaces vers la gamme des problématiques relatives à
cet axe de recherche.
Le but de notre travail est de découvrir comment ce champ de recherche prend sa place
dans les bases de données relationnelles en parcourant les progrès atteints dans ce domaine et les
difficultés rencontrées. Ainsi, et comme les exigences d’analyses décisionnelles face à
l’éclatement du volume de données manipulées donne lieu à la mise en place des nouveaux
concepts tels que entrepôt de données et OLAP (On Line Analytical Processing) qui sont rangés
dans une nouvelle classe de bases de données dites multidimensionnelles et qui n’a pas
bénéficier parfaitement de la personnalisation en raison de sa fraîcheur et surtout sa particularité,
on a consacré dans ce travail une partie pour étudier les progrès achevés dans ce champ de
recherche ainsi que les obstacles rencontrée et les perspectives proposées.
Après avoir exploré la personnalisation dans les bases de données multidimensionnelles
(entrepôts des données) et les travaux contribuant à l’avancement des recherches dans cet axe,
nous proposerons comme contribution un algorithme pour la génération de l’ensemble de toutes
les formes d’affichage possibles que peut prendre le résultat d’exécution d’une requête MDX.
7
Chapitre 1
Les entrepôts de données
1. Introduction :
Dans ce 1er chapitre, nous présenterons les concepts généraux qui caractérisent les
entrepôts de données, leur objectif, leur modélisation...etc. Et ensuite nous présenterons les
systèmes OLAP (On Line Analytical Process), qui permettent l’interrogation efficace des
entrepôts de données selon une vue multidimensionnelle de celle-ci.
2. Vocation des entrepôts de données :
L’entrepôt de données permet avant tout d’intégrer des sources de données. Mais son
objectif final n’est autre que de supporter un processus d’analyse en ligne. Par rapport aux
aspects d’intégration et d’analyse, l’entrepôt se trouve finalement être au cœur de l’architecture
décisionnelle dont l’objectif est de construire de l’information utile à l’aide à la décision.
2.1. Intégration de sources de données
Un système d’intégration a pour objectif d’assurer à un utilisateur un accès à des sources
multiples, réparties et hétérogènes, à travers une interface unique. En effet, l’avantage d’un tel
système est que l’utilisateur se préoccupe davantage de ce qu’il veut obtenir plutôt que comment
l’obtenir, l’objectif étant l’obtention d’informations. Ainsi, cela le dispense de tâches telles que
chercher et trouver les sources de données adéquates, interroger chacune des sources de données
en utilisant sa propre interface et combiner les différents résultats obtenus pour finalement
disposer des informations recherchées. Différentes solutions ont été proposées face au problème
de l’hétérogénéité des sources réparties de données.
En effet, pour faire des recherches sur l’ensemble de ces sources, une intégration de
celles-ci est nécessaire. Deux approches sont alors envisageables : migrer les requêtes vers les
sources de données ou migrer les données pour les centraliser dans une source cible. Ceci
consiste à suivre respectivement une approche "non matérialialisée", appelée aussi approche
virtuelle ou une approche "matérialisée", appelée aussi approche d’entreposage [Boussaid et
al,2003].
Ainsi, on parle généralement de système OLAP, sous-entendant ainsi un système
d’informations répondant aux Règles évoquées par Codd ou aux critères FASMI. L’aspect
analyse y est crucial. C’est d’ailleurs cet aspect qui est mis en avant lorsque l’on oppose le terme
OLAP à celui d’OLTP « On Line Transaction Processing ». Dans ce cas, ce sont les
caractéristiques des applications qui sont comparées. Les applications OLTP ont une architecture
permettant de gérer des transactions en temps réel. Elles peuvent être vues comme des
applications de production permettant d’effectuer des traitements factuels tels que l’ajout, la
suppression et la modification de clients par exemple. Les applications OLAP sont, quant à elles,
des applications d’aide à la décision permettant d’effectuer des traitements ensemblistes qui ont
pour objectif de résumer l’information en réduisant une population à une valeur, un
comportement. Dans ce cas, l’aspect « en ligne » s’applique à l’analyse, c’est le temps de
9
Chapitre 1
Les entrepôts de données
réponse qui doit être quasi instantané. Les deux types d’applications peuvent alors être comparés
selon différents aspects. Nous présentons le tableau comparatif suivant inspire de [Teste, 2000],
qui dresse les comparaisons d’un point de vue données et d’un point de vue utilisateurs.
Bases de production
Entrepôts de données
Exhaustives, détaillées
Résumées, agrégées
Courantes
Statiques
Mises à jour
Recalculées
Dynamiques
Statiques
Orientées applications
Orientées sujets d’analyse
De l’ordre des giga-octets
De l’ordre des téraoctets
Agents opérationnels
Décideurs
Nombreux
Peu
Concurrents
Non concurrents
Concurrents
Interrogations
Requêtes Prédéfinies
Requêtes imprévisibles
Réponses immédiates
Réponses moins rapides
Accès à peu d’informations
Accès à de nombreuses
informations
Données
Utilisateurs
Le focus sur l’analyse peut également être envisagé dans le contexte du terme analyse
OLAP, i.e. analyse en ligne. Dans ce cas, il s’agit d’un type d’analyse qui se distingue des
analyses statistiques ou de la fouille de données par exemple, qui sont présentes en fin de
l’architecture décisionnelle. Nous reviendrons par la suite sur ce concept d’analyse en ligne.
2.2. Au cœur de l’architecture décisionnelle
L’entrepôt de données est le support nécessaire à la réalisation d’une architecture
qualifiée de décisionnelle, qui va permettre, comme l’indique son nom, l’aide à la décision grâce
au processus d’analyse qu’elle offre.
Cette architecture décisionnelle, peut être représentée classiquement selon le schéma de la fig 1.
On peut y distinguer la partie sources, la partie gestion des données et enfin la partie analyse. On
parle généralement d’architecture n-tiers en raison des différentes couches possibles pour gérer
les données (entrepôt, magasin, etc.) et réaliser des analyses.
10
Chapitre 1
Les entrepôts de données
Cette architecture met en avant deux phases caractéristiques que sont l’intégration des
données et l’analyse. Ces phases sont basées sur cinq éléments essentiels qui composent le
système décisionnel :
• sources de données : ce sont les bases de production (relevant d’un système OLTP), les
fichiers . . . qui correspondent à des sources internes ; mais elles peuvent également être
d’origine externe (Internet, bases de partenaires, etc.) ;
• entrepôt de données : c’est le lieu de stockage massif où sont centralisées les
informations utiles pour les décideurs ; il est associé a un ensemble de métadonnées
(informations sur les données) qui forme en quelque sorte un référentiel de données
contenant différentes informations telles que les Règles de transformation et de nettoyage
des données permettant d’assurer différentes taches telles que la maintenance de
l’entrepôt.
• magasins de données : ce sont des extraits de l’entrepôt orientés métiers, activités (on
parle de données verticalisées), contenant un volume moindre de données, permettant
alors des analyses plus rapides ;
• cubes de données : ce sont des contextes d’analyse multidimensionnels ;
1
[FAVRE, 2007]
• outils d’analyse : ils permettent de manipuler les données et de les analyser.
Les processus d’analyse peuvent s’opérer aussi bien sur l’entrepôt de données, que sur les
magasins de données, ou encore sur les cubes de données.
11
Chapitre 1
Les entrepôts de données
3. Stratégie de conception et modélisation des entrepôts de données :
En 1996, Bill Inmon [Inmon, 1996] définit un entrepôt de données comme étant une
« collection de données orientées sujet, intégrées, non volatiles et historisées, organisées pour le
support du processus d’aide à la décision ». Les données sont « orientées sujet » dans la mesure
où elles sont organisées par thème, l’entrepôt de données est organisé autour des sujets majeurs
et des métiers de l’entreprise.
Il permet une vision transversale des différentes activités de l’entreprise. Le fait que les
données soient « intégrées » exprime leur provenance de sources différentes. Cette intégration
nécessite une bonne connaissance des sources de données, des Règles de gestion, de la
sémantique des données, etc. En outre, les données sont « historisées » afin de rendre possible la
réalisation d’analyses au cours du temps, nécessitant un recours à un référentiel temporel associe
aux données. De plus, les données sont dites « non volatiles ».
Cela signifie que les données stockées au sein de l’entrepôt de données ne peuvent pas
être supprimées. Une requête émise sur les mêmes données à différents intervalles de temps doit
donner le même résultat. Cela doit permettre de conserver la traçabilité des informations et des
décisions prises. Enfin, les données sont « organisées pour le support du processus d’aide à la
décision » ; il s’agit en l’occurrence d’une organisation multidimensionnelle. Cette organisation
est en effet propice à l’analyse et, en particulier, à l’agrégation, comme nous le montrerons par la
suite [FAVRE, 2007].
3.1. Stratégie de conception
L’un des points clés de l’entreposage réside dans la conception du schéma. En effet, les
possibilités d’analyse sont conditionnées par ce dernier. C’est pourquoi différents travaux ont
propose des méthodes pour déterminer le schéma de l’entrepôt [Kimball et al, 2000], [Golfarelli
et al, 1998[, [Moody et al, 2000], [Trujillo et al, 2001]. La construction du schéma de
l’entrepôt n’étant pas une tâche facile, plusieurs travaux ont propose l’automatisation partielle
[Soussi et al, 2005], ou complète de cette tâche [Kim et al, 2003], [Peralta et al, 2003], [Phipps
et al, 2002].
Par exemple, dans [Peralta et al, 2003], des Règles symbolisent la connaissance que l’on
a sur la construction d’un entrepôt de données. Les Règles définies sont par exemple, la
combinaison de deux tables pour en fournir une troisième, la suppression de données ne vérifiant
pas une condition, ... Chacune des Règles est spécifiée grâce à une description, des structures
cibles, un état de départ, des conditions d’application et un état final. C’est un algorithme qui
gère l’ordre d’exécution des différentes Règles pour la génération du schéma final. Cette
génération consiste en une succession de transformations sur le schéma source, chaque Règle
déterminant quelle transformation doit être appliquée en tenant compte des différentes conditions
de conception fournies par le schéma transforme, de la base de données source et des relations
entre les deux.
Un autre exemple d’automatisation de la construction du schéma est proposé dans [Kim
et al, 2003]. Dans le contexte de la CRM (Customer Relationship Management), des Règles de
type « si-alors » permettent de représenter les campagnes marketing à analyser.
12
Chapitre 1
Les entrepôts de données
La clause « si » présente les caractéristiques déterminant la population cible de la
campagne marketing (exemple : clients âgés entre 20 et 30 ans et dont les achats pour les deux
derniers mois sont supérieurs à 100 euros), et la clause « alors » comprend les caractéristiques de
la campagne marketing elle-même (par exemple, support de la campagne : envoi d’un e-mail,
indicateurs à suivre : nombre d’e-mails lus).
L’approche orientée données ignore les besoins d’analyse à priori. Elle concerne en
particulier les travaux sur l’automatisation de la conception de schéma. En effet, cette approche
consiste à construire le schéma de l’entrepôt à partir de ceux des sources de données et suppose
que le schéma qui sera construit pourra répondre à tous les besoins d’analyse.
Par exemple, dans [Golfarelli et al, 1998], les auteurs proposent une méthodologie semiautomatique pour construire un schéma d’entrepôt de données à partir des schémas entitérelation qui représentent les bases de données sources. Dans [Peralta et al, 2003], les auteurs
représentent les connaissances sur la construction de l’entrepôt de données sous forme de Règles.
Un algorithme gère alors l’ordre d’exécution des Règles qui permettent une succession de
transformations sur le schéma source pour obtenir le schéma logique final de l’entrepôt.
Les approches orientées besoins d’analyse, quant à elles, proposent de définir le schéma
de l’entrepôt en fonction des besoins d’analyse et supposent que les données disponibles
permettront la mise en œuvre d’un tel schéma. Parmi les approches orientées besoins d’analyse,
certains auteurs proposent une distinction entre les approches guidées par les buts et les
approches guidées par les utilisateurs [List et al, 2002].
L’approche orientée buts suppose que le schéma de l’entrepôt est défini selon les
objectifs d’analyse de l’entreprise [Ulbrich et al, 2000]. Ainsi, on suppose que tous les employés
de l’entreprise ont des besoins d’analyses similaires vis-à-vis de l’exploitation de l’entrepôt de
données. Autrement dit, tous les employés ont la même vision analytique de l’entrepôt de
données.
Dans l’approche orientée utilisateurs, ces derniers sont interroges afin de collecter
l’ensemble de leurs besoins d’analyse avant de construire l’entrepôt de données, ce qui permet de
garantir l’acceptation du système par les utilisateurs. Cependant la durée de vie de ce schéma
peut être courte, étant donne que le schéma dépend beaucoup des besoins des personnes
impliquées dans le processus de développement de l’entrepôt. Pour y remédier, dans [Poe, 1996],
l’auteur propose une méthodologie pour conduire les entretiens avec les utilisateurs pour la
collecte des besoins. Il est alors recommande d’interroger différents groupes d’utilisateurs pour
avoir la vision la plus complété possible des besoins des utilisateurs.
Dans ces deux approches, nous considérons tout simplement qu’il s’agit de besoins
d’analyse qui sont exprimés, certains sont plus globaux, au sens où l’ensemble des utilisateurs
partage ce besoin, d’autres plus spécifiques, sans pour autant que l’aspect personnalisation ne
soit aborde d’ailleurs.
Enfin, l’approche mixte considère à la fois les besoins d’analyse et les données pour la
construction du schéma. Cette approche est celle qui fait l’objet de plus d’investigations
aujourd’hui. L’idée générale est de construire des schémas candidats a partir des données
(démarche ascendante) et de les confronter aux schémas définis selon les besoins (démarche
descendante) [Bonifati et al, 2001], [Phipps et al, 2002], [Soussi et al, 2005]. Ainsi, le schéma
construit constitue une réponse aux besoins réels d’analyse et il est également possible de le
mettre en œuvre avec les sources de données.
13
Chapitre 1
Les entrepôts de données
3.2. Concepts de base et modélisation des entrepôts de données
La modélisation des entrepôts de données se base sur deux concepts fondamentaux : le
concept de fait et le concept de dimension. Un fait représente un sujet d’analyse, caractérisé par
une ou plusieurs mesures, qui ne sont autres que des indicateurs décrivant le sujet d’analyse. Ce
fait est analysé selon des axes d’observations constituant également ses descripteurs.
Un entrepôt de données présente alors une modélisation dite « multidimensionnelle » puisqu’elle
répond à l’objectif d’analyser des faits en fonction de dimensions qui constituent les différents
axes d’observation des mesures. Ces dimensions peuvent présenter des hiérarchies qui offrent la
possibilité de réaliser des analyses à différents niveaux de granularité (niveaux de détail).
Ces concepts de base ont permis de définir trois schémas classiques reconnus comme
relevant d’un niveau logique de conception, en raison du recours à la notion de table (table de
faits, table de dimension).
Le premier schéma est le schéma en étoile. Il se compose d’une table de faits centrale et
d’un ensemble de tables de dimension. Le deuxième schéma est le schéma en flocon de neige. Il
correspond à un schéma en étoile dans lequel les dimensions ont été normalisées, faisant ainsi
apparaitre des hiérarchies de dimension de façon explicite. La normalisation permet un gain
d’espace de stockage en évitant la redondance de données, mais engendre une dégradation des
performances, dans la mesure où elle multiplie le nombre de jointures à effectuer pour l’analyse.
Le troisième et dernier schéma est le schéma en constellation, aussi appelé flocon de faits. Ce
schéma fait coexister plusieurs tables de faits qui partagent ou pas des dimensions communes
(hiérarchisées ou non).
Au-delà de ces schémas logiques qui sont à la base des représentations
multidimensionnelles, un travail a été réalisé afin de revenir sur une modélisation conceptuelle. Il
n’existe à ce jour aucun consensus sur la méthodologie de conception de l’entrepôt, comme cela
peut être le cas avec la méthode MERISE pour la conception des bases de données relationnelles
[Tardieu, 1983]. Il n’existe pas non plus de consensus au niveau de la modélisation de
l’entrepôt. Différentes pistes ont été proposées ; elles se basent sur l’utilisation de paradigmes
variés tels que le paradigme entité association comme dans [Tryfona et al, 1999], [Franconi,
1999] par exemple, le paradigme objet grâce à la modélisation UML (Unified Modeling
Language) comme dans [Lujan-Mora, 2006], [Abello, 2006], ou des paradigmes plus
spécifiques dédies tels que ceux présentés dans [Golfarelli, 1998]. Une bonne description et
comparaison de ces modèles est donnée dans [Annoni, 2007].
4. Exploitation de l’entrepôt et Analyse OLAP
L’objectif final d’un entrepôt est l’analyse des données en vue de la prise de décision.
Différents types d’analyse peuvent être réalisés vue l’analyse en ligne OLAP. Il s’agit en
l’occurrence d’une navigation dans les données. Cette analyse peut être qualifiée d’exploratoire.
Le principe général est d’arriver au cours de la navigation à détecter des points intéressants
qu’on essaye de décrire, d’expliquer en naviguant, par exemple en allant chercher davantage de
détails, pour cela il existe plusieurs types d’OLAP.
14
Chapitre 1
Les entrepôts de données
4.1 Type d’OLAP [FAVRE, 2007] :
4.1.1 ROLAP :
(Relational On-Line Analytical Process), il permet le stockage infini des données dans un
SGBD relationnel. Le langage SQL (Structured Query Language) est utilisé pour effectuer les
différents traitements sur les données, en utilisant des requêtes en générale très complexes et très
exigeantes en termes de ressources et de temps d’exécution. Les systèmes relationnels sont plus
performants pour de gros volumes de données et proposent des mécanismes de sécurité plus
poussés (poser un filtre sur les requêtes, réduisant l’accès à certaines données à un groupe
d’utilisateurs).
4.1.2 MOLAP :
(Multidimensional On-Line Analytical Process) c’est une approche multidimensionnelle
« pure », les données sont stockées dans une base de données multidimensionnelle (cube) le plus
souvent propriétaire. Il ya la limitation quand à la quantité des données traitées. Serveur de
traitement OLAP est l’approche la plus adaptée aux traitements. Un serveur, conjointement avec
la base de données, est dédié à effectuer les différents traitements de données. Dans ce cas les
performances en termes de rapidité sont généralement très bonnes.
4.1.3 HOLAP :
(Hybrid On-Line Analytical Process), c’est une approche qui permet de combiner les
avantages de ROLAP et de MOLAP. Il s’agit d’exploiter une technologie multidimensionnelle
pour les données agrégées (agrégats) et une approche relationnelle pour les données détaillées.
4.1.4 DOLAP :
(Desktop On-Line Analytical Process), apparue assez récemment, c’est une petite
quantité de données (mini-base multidimensionnelle ou extraction de cube) dans un fichier sur le
poste client de l'utilisateur. Un nombre limité de traitements OLAP se font sur le poste client de
l’utilisateur et sont assurés par un client de traitement OLAP. Il s’agit d’une alternative
«bureau».
Aujourd’hui plusieurs termes sont apparus comme JOLAP [WEB6] (JAVA OLAP) qui est une
API (Application Programming Interface) JAVA (Langage de programmation orienté objet)
permettant de se connecter à des applications et des serveurs OLAP, tentant de normaliser
l’accès aux bases de données multidimensionnelles et également comme OOLAP (Object
OLAP), faisant référence à l’utilisation du modèle objet, mais cette technologie n’apparait pas
dans les solutions commerciales et elle fait l’objet de travaux de recherche [JUNG et AL, 2004].
4.2 Analyse d’OLAP
L’analyse OLAP est l’un des modes d’analyse les plus courants dans le décisionnel. Elle
permet de mettre en évidence une analyse particulière des données qui est l'objet d'un
questionnement particulier.
15
Chapitre 1
Les entrepôts de données
4.2.1 Opérations OLAP liées à la structure :
Ce sont les opérations qui agissent sur la structure multidimensionnelle, qui visent à
changer le point de vue des données.
Opérations
Extraction d’un
données (Dice)
Pivot (Rotate)
Description
bloc de elle extrait un “sous-cube’’ du cube principal. Donc elle
travaille que sous un sous-cube
consiste à faire effectuer à un cube une rotation autour d’un
de ces axes passant par le centre de deux faces opposées, de
manière à présenter un ensemble différent.
Permutation (Switch)
consiste à inter-changer la position des membres d’une
dimension.
Extraction d’une Tranche du consiste à sélectionner une dimension, il s’agit de couper une
cube (Slice)
tranche du cube afin d’observer les données de la dimension.
Division (Split)
consiste à présenter chaque tranche du cube et passer d’une
présentation tridimensionnelle d’un cube à sa présentation
sous forme d’un ensemble de tables. Sa généralisation permet
de découper un hypercube de dimension 4 en cubes
Emboitement (Nest)
permet d’imbriquer des membres à partir du cube.
L’intérêt de cette opération est qu’elle permet de grouper sur
une même représentation bidimensionnelle toutes les
informations (mesures et membres) d’un cube, quel que soit le
nombre de ses dimensions.
Enfoncement (Push)
permet de combiner les membres d’une dimension aux
mesures du cube, i.e. de faire passer des membres comme
contenu de cellules.
4.2.2 Les opérations OLAP liées à la granularité :
Les opérations agissant sur la granularité d’observation des données, caractérisent la
hiérarchie de navigation entre les différents niveaux. Elles correspondent aux opérations
suivantes :
Opérations
Description
Forage vers le haut (Drill-up ou Consiste à représenter les données du cube à niveau de
Roll-up ou Scale-up)
granularité supérieur conformément à la hiérarchie définie sur
la dimension. Une fonction d’agrégation est utilisée (somme,
moyenne, etc.) en paramètre à l’opération, indique comment
sont calculés les valeurs du niveau supérieur à partit de celles
du niveau inférieur
Forage vers le bas (Drill-down Elle fait l’inverse de la précédente (Roll-up), elle consiste à
ou Roll-down ou Scale-down)
représenter les données du cube à niveau de granularité de
niveau inférieur, donc sous une forme plus détaillée
(descendre dans la hiérarchie d’une dimension).
16
Chapitre 1
Les entrepôts de données
5. Conclusion
Dans ce chapitre, nous avons évoqué les principaux concepts lies a la conception et a
l’exploitation des entrepôts de données. Cette présentation nous a permis de positionner le
contexte général des travaux qui seront présentées. La réussite du processus d’entreposage
repose entre autres sur une bonne conception du schéma, puisque c’est ce dernier qui va
déterminer les possibilités d’analyse de l’entrepôt.
Ainsi, de nombreux travaux de recherche ont été menés sur la conception de schéma des
entrepôts de données. Ces travaux témoignent aujourd’hui de la nécessite de prendre en compte à
la fois les sources de données et les besoins d’analyse [Nabli et al, 2005], plutôt que d’avoir
recours, par exemple, à une approche uniquement guidée par les données telle que celle proposée
par [Golfarelli et al, 1998]. Mais, une fois l’entrepôt de données construit, ces sources de
données et ces besoins d’analyse peuvent subir des changements.
17
Chapitre 2
Les langages d'interrogation des entrepôts de données
1. Introduction :
Ce chapitre est consacré aux langages d’interrogation des entrepôts de données. Nous
citerons les différents types de langages de données, quelques langages de manipulation des
entrepôts de données et nous présenterons la forme des requêtes OLAP (On Line Analytical
Process) sous MDX (MultiDimensional eXpressions).
2. Les langages de données :
La représentation multidimensionnelle des données a donner naissance aux nouveaux
langages de données permettant de définir, et de manipuler les schémas des entrepôts de données
d’une manière assimilable par la machine. Ces langages de données sont constitués d’un
ensemble d’opérations qui peuvent être classées selon le type de langage de données.
2.1 Types de langages de données :
Les langages de données dédiés aux entrepôts de données sont classés en trois types et
qui se présentent comme suit [RAVAT et AL, 2002] et [CROZAT, 2002]:
2.1.1
Le langage de définition de données (LDD) :
Ce langage permet de définir les opérateurs nécessaires à la définition d’un schéma
multidimensionnel comme la création des cubes (définition des faits), dimensions et hiérarchies
ainsi que la mise à jour (la modification et / ou la suppression) de ses éléments.
2.1.2 Le langage de contrôle des données (LCD) :
Ce langage permet de gérer la sécurité de l’entrepôt de données, il définit les opérateurs
nécessaires à l’affectation et à la suppression des droits des utilisateurs (les permissions) sur les
éléments du schéma multidimensionnel.
2.1.3 Langage de manipulation des données (LMD) :
Ce langage adresse des requêtes à l’entrepôt de données et définit les opérateurs
nécessaires à la consultation des données.
3. L’extension de SQL (Structured Query Language) :
La majorité des outils du marché proposent une modélisation ROLAP. Dans ces systèmes
chaque dimension est implantée sous forme d’une table. Chaque fait est défini par une table et
son identifiant est une clé primaire composée des clés étrangères correspondantes aux
dimensions liées.
Néanmoins, le langage d’assertion standard des bases de données relationnelles (SQL
(Structured Query Language), iso 1992) sur lequel reposent ces outils n’est pas adapté et manque
d’expressivité pour la définition d’une base multidimensionnelle (limitation dans l’analyse de
données). De même les requêtes de comparaison utilisées dans le décisionnel sont difficiles à
formuler, certaines ne sont pas formulables ; c’est le cas du classement.
19
Chapitre 2
Les langages d'interrogation des entrepôts de données
C’est pour cela que les SGBD (Systèmes de gestion des bases de données) relationnels
(ORACLE) proposent une extension pour le langage d’interrogation SQL (Structured Query
Language). ORACLE étend l’opérateur GROUP BY en intégrant les commandes CUBE et
ROLL UP qui permettent l’expression de calculs de sous totaux.
Microsoft dans SQL SERVEUR propose un langage pour l’interrogation des bases de
données multidimensionnelles en étendant la clause SELECT pour permettre l’affichage et la
navigation des données en ligne et en colonnes [WEB7].
Cependant, les SGBD relationnels (Systèmes de gestion des bases de données) essaient
d’intégrer certains concepts de l’approche OLAP mais ils restent incomplets et ne profitent pas
de la puissance des concepts multidimensionnels.
Par exemple, dans [RAVAT et AL, 2002], un langage dédié aux bases multidimensionnelles
implantées est proposé sous une forme relationnelle OLAP (OLAPSQL), ce langage intègre les
commandes de définition, de contrôle et de manipulation d’une base de données
multidimensionnelle organisée en constellation. Ce langage repose sur l’exécution du standard
SQL (Structured Query Language). Le langage de définition (OLAP-LDD) permet de spécifier
simplement les composants (faits et dimensions et hiérarchie) du schéma multidimensionnel avec
une abstraction complète des tables relationnelles. Le langage de contrôle (OLAP-LCD) permet
de définir de manière uniforme des droits sur tout ou partie du schéma. Enfin le langage de
manipulation (OLAP-LMD) offre un mécanisme unique de consultation reposant sur l’extension
de la commande SELECT.
4. Les langages graphiques
[HAFYANE,2008 ] :
de
manipulation
de
données
On va présenter quelques travaux de recherche, ainsi que des outils commerciaux, qui ont
proposé des interfaces graphiques dédiées aux multidimensionnelles. Les magasins de données
sont généralement destinés aux décideurs de l’entreprise souvent non spécialistes de
l’informatique. Il doit, donc, être muni d’interfaces graphiques adaptées à des utilisateurs non
informaticiens.
Cependant, les travaux sur les langages de manipulation graphique, sont beaucoup plus rares que
ceux sur les langages de définition graphique.
Dans [CABIBBO ,1998], l’auteur a proposé en plus d’une algèbre, un langage de
manipulation graphique simple. Dans [BOHNLEIN et AL, 2002], les auteurs ont proposé un
requêteur graphique basé sur une interface utilisateur simple et conviviale.
Mais ces travaux ne s’appuient pas sur une algèbre multidimensionnelle et le formalisme
du modèle employé, le SDWM (Semantic Data Warehouse Model), est trop chargé pour des
représentations de schémas en constellation.
Au sein de l’équipe SIG (Systèmes d’informations de gestion), dans [TOURNIER,
2004], un langage graphique de manipulation et d’interrogation de données est proposé basé sur
une algèbre multidimensionnelle de [RAVAT et AL, 2002].
Ces propositions ont été validées par l’implantation de prototype GRAPHIC OLAP-SQL.
4.1 GRAPHIC OLAP-SQL :
Est un outil graphique qui repose sur un ensemble d’interfaces utilisateurs permettant de
définir, de manipuler, de visualiser et consulter des bases de données multidimensionnelles
structurées en constellation. Il intègre essentiellement deux modes de fonctionnement : textuel au
20
Chapitre 2
Les langages d'interrogation des entrepôts de données
travers du langage OLAP-SQL, et graphique au travers d’un graphe de visualisation de la
constellation. Quant aux outils commerciaux, ils s’améliorent d’année en année.
4.2 COGNOS PowerPlay7.3 :
Numéro un mondial du “Business Intelligence’’, ce logiciel, outil d’analyse OLAP se
présente sous la forme d’un tableur muni de fonctions très évoluées. Il permet l’analyse d’un
cube de données (un schéma en étoile). La présentation conceptuelle du cube se fait sous la
forme d’arborescence. Les requêtes se font par glisser, déplacer des éléments (mesures,
dimensions, hiérarchies, paramètres et attributs faibles) vers la fenêtre de présentation des
résultats (un tableur), en les positionnant en lignes ou en colonnes.
4.3 CRYSTAL Analysis 10 :
‘Crystal decisions’, acquisition du géant ‘Business Objects’, développe ‘Crystal
Analysis’, un outil de visualisation de résultants et une extension pour Excel. Il propose pour la
visualisation des données conceptuelles la même arborescence utilisée par tous les concurrents et
se limite à la visualisation d’un seul fait. Des fonctionnalités avancées de sélection sont mises en
avant mais elles requièrent toutes de maitriser un langage de requête textuel (SQL en général).
4.4 RATIONAL Rose XDE :
Rose XDE, un éditeur de schémas UML (Unified Modeling Language) très connu est
édité par Rational Software, racheté par IBM. Mais comme UML est une méthode sur le
paradigme objet, la modélisation multidimensionnelle via XDE n’est pas indépendante de
l’architecture sous-jacente et impose le support du paradigme objet.
4.5 Limitations des langages graphiques :
Selon [TOURNIER, 2004], ces logiciels bien que puissants et faciles d’utilisation,
souffrent de l’absence de visualisation globale du schéma multidimensionnel car ils se limitent à
la présentation d’un unique schéma en étoile.
De plus, le système de visualisation par arborescence est absolument inutilisable en cas
de schéma large, imposant un parcours lent et fastidieux. Il existe aussi des outils issus de
l’industrie, qui se concentrent essentiellement sur les aspects de l’interrogation.
Plusieurs requêteur (Business Object, Tempo, Discover 2000) et outils OLAP
(PowerPlay, Discover, Essbase, Express, Mercury) sont proposés. Les requêteurs facilitent la
construction de requêtes SQL (jointures masquées, alias de noms d’attributs,...). Les outils
OLAP (On Line Analytical Process) se concentrent sur l’analyse multidimensionnelle en
proposant des objets graphiques (tableaux croisés,...). Ces outils manipulent les données de
l’entrepôt ou des magasins.
Cependant, même si les requêteurs graphiques sont simples et facilitent l’accès aux
informations, ils restent limités pour un processus d’analyse complexe. Les outils spécifiques à
OLAP offrent de nombreuses possibilités de manipulation multidimensionnelle, mais ils sont
difficiles d’accès pour les non informaticiens [RAVAT et AL, 2002].
21
Chapitre 2
Les langages d'interrogation des entrepôts de données
5. Le langage de script de manipulation des données MDX:
5.1 Définition [WEB8], [WEB9] :
MDX, acronyme de MultiDimensional eXpressions, est un langage de requêtes qui sont
exprimées sous forme d’un script à base d’instruction. Le MDX comprend une syntaxe qui prend
en charge la définition le contrôle et la manipulation de données et d’objets multidimensionnels
(bases de données multidimensionnelles) crée par Microsoft, de la même manière que SQL est
utilisé pour les bases de données relationnelles(Le langage MDX est aux cubes ce que SQL est
aux tables) [PEGUIRON, 2006].
5.2 Caractéristiques de MDX :
Le MDX offre une syntaxe assez similaire à celle de SQL, mais il ne s’agit pas d’une
extension du langage SQL, en fait, certaines des fonctionnalités prises en charge par MDX
peuvent être fournies, avec certes moins d’efficacité ou de facilité, par SQL.
A l’instar d’une requête SQL, chaque requête MDX nécessite une demande de données
(la clause SELECT), un point de départ (la clause FROM) et un filtre (la clause WHERE). Ces
mots clés, ainsi que d’autres, fournissent les outils nécessaires à l’extraction de portions de
données spécifiques d’un cube en vue d’une analyse. Le MDX fournit également un jeu robuste
de fonctions pour la manipulation des données extraites, ainsi que la possibilité d’enrichir MDX
avec des fonctions définies par l’utilisateur.
MDX, comme, SQL fournit un langage de définition de données, DDL ( Data Definition
Language), pour la gestion des structures de données. Certaines commandes de MDX permettent
de créer et de supprimer des cubes, des dimensions, des mesures, ainsi que les objets qui leur
sont subordonnés.
5.3 Forme d’une requête OLAP sous MDX :
Le cube est l’élément (structure) clé dans les bases de données multidimensionnelles. Un
cube peut avoir plusieurs dimensions et la dimension Mesure est la seule que chaque cube doit
contenir. Chaque dimension des membres provenant d’attributs et chaque membre représente un
élément unique au sein d’une dimension. Les mesures sont les membres de la dimension
Mesures et ces mesures représentent les données organisées par les autres dimensions du cube.
Les concepts de cube, dimension, membre et mesure sont importants pour mieux se rendre
compte de la syntaxe MDX (voir exemple).
Une requête MDX permet de rechercher des mesures à des niveaux différents de
granularité, en formulant une expression unique et peut construire une visualisation pour
l’ensemble des résultats.
Pour cela, une syntaxe a été proposée pour rédiger une requête OLAP sous MDX dans
[SPOFFORD, 2001], [ISRAEL, 2001] et [GRAUA, 2004] et qui se présente ainsi :
SELECT les colonnes, les lignes et autres axes (sélectionner les axes d’analyse)
FROM le cube (le cube sur lequel porte l’analyse)
WHERE les dimensions tranchées (conditions de sélection d’axes d’analyse)
22
Chapitre 2
Les langages d'interrogation des entrepôts de données
Exemple: si nous avons le cube ‘Ventes’ présenté dans cette figure
FIG. 2 - Cube « Ventes »
Ce cube est composé de trois dimensions qui sont Temps, Produit, Magasin et la
dimension
Mesures.
La dimension Temps contient deux membres T1etT2
La dimension Produit contient deux membres P1et P2
La dimension Magasin contient deux membres V1etV2
La dimension Mesures contient deux mesures (membres) quantité(q) et prix(p).
La requête MDX qui permet de voir les quantités vendues des produits P1 et P2 et qui
correspondent aux temps T1 et T2 est la suivantes :
SELECT {Produit.[P1],Produit.[P2]} ON COLUMNS,
{Temps.[T1],Temps.[T2]} ON ROWS
FROM Ventes
WHERE Mesures.quantite
5.4 Structure du résultat d’une requête MDX :
Le résultat d’une telle requête est un tableau multidimensionnel, dont les cellules ne
contiennent qu’une valeur (contrairement aux cubes) et dans lequel on peut naviguer avec les
opérations décrites dans le chapitre précédent.
Une requête MDX permet de rechercher des mesures à des niveaux différents de
granularité en formulant une expression unique et de spécifier comment afficher la réponse sous
forme de table croisée. De plus la syntaxe MDX distingue l’identification des axes d’affichage
par ’COLUMNS’ et ’ROWS’. Ainsi, l’emplacement des informations de la requête sur ces axes
est précisé.
Exemple: si nous avons le cube ‘Ventes’ présenté ci après;
Le résultat de la requête de l’exemple précédent est une table croisée de deux lignes et deux
colonnes et qui se présente ainsi :
23
Chapitre 2
Les langages d'interrogation des entrepôts de données
5.5 Les avantages et inconvénients du langage MDX [WEB10] :
Le langage MDX possède une syntaxe un peu ardue. Néanmoins le temps que nous
passons à son assimilation est largement compensé par celui que nous gagnons lors de l’écriture
des requêtes du langage SQL [PEGUIRON, 2006]. De plus, les fondements et les formalisations
théoriques de ce langage sont mal connus, et il présente l’inconvénient de ne pas être clos.
Si l’utilisation interactive des cubes est intéressante, leur structure multidimensionnelle
associée à la puissance de ce langage en fait des outils de prédilection pour le reporting
opérationnel d’entreprise ou d’administration. Au-delà de cet aspect, le MDX permet d’explorer
les données de cubes et crée la vraie valeur autour des données et c’est ici que se trouve la plus
value. Il n’en reste pas moins que MDX reste un langage, qui n’est pas forcément simple à
appréhender. Des éditeurs commencent à proposer des outils multidimensionnels.
6. Conclusion :
L’interrogation des entrepôts de données est une tache cruciale, qui permet de naviguer
dans le cube de données afin d’exploiter les résultats obtenus. Il s’agit de manipuler des données
à l’aide des outils qu’on appelle langages d’interrogation.
Dans ce chapitre nous avons présenté quelques langages d’interrogation des entrepôts de
données permettant de manipuler les données du cube, alors que nous sommes intéressés par les
outils de manipulation des données et parmi les quels le langage MDX qui est le plus répandu
pour l’interrogation des entrepôts de données. Nous avons également présenté l’expression d’une
requête OLAP sous MDX que nous allons utiliser dans la suite de notre travail. Mais lors de
l’exploitation des données de l’entrepôt par les différents langages, l’utilisateur s’embrouille
dans cet important volume d’informations disponibles et le filtrage des informations pertinentes
de celles non pertinentes rendent son analyse difficile. Pour cela des approches de
personnalisation sont proposées afin de faciliter l’extraction des informations, qui l’objet du
chapitre suivant.
24
Chapitre 3
La personnalisation des données
1. La personnalisation de l’information :
La personnalisation de l’information constitue un enjeu majeur pour l’industrie
informatique. Que ce soit dans le contexte des systèmes d’information d’entreprise, du
commerce électronique, de l’accès au savoir et aux connaissances ou même des loisirs. La
pertinence de l’information délivrée, son intelligibilité et son adaptation aux usages et
préférences des clients constituent des facteurs clés du succès ou du rejet de ces systèmes.
1.1 Architecture du système personnalisé [MOULOUDI, 2007] :
Dans cette architecture illustrée à la Fig.3 : Architecture d’un système de
personnalisation, l’auteure montre la possibilité de personnalisation en utilisant l’un des deux
types de la personnalisation suivants :
1.1.1 Personnalisation de la requête :
Qui consiste à l’intégration des informations du profil à la requête entrante afin de
sélectionner le contenu.
1.1.2 Personnalisation du résultat :
Qui consiste à l’intégration des informations du profil au résultat après avoir sélectionner
le contenu.
Etant donnée, une requête « q » est transformée à l’aide de profil utilisateur pour obtenir
une requête « q’ ». Le moteur de requête exécute cette dernière « q’ » sur la source de données
« I » afin d’extraire une partie de données « I’= I (q’) ». A la fin de l’opération
le moteur de la personnalisation transforme le résultat « I’ » pour obtenir le résultat « I’’ = q’’
(I’) » présentés à l’utilisateur (La FIG.3 illustre mieux ce contexte).
• Si I’’= q’(I) alors la personnalisation est faite uniquement par transformation (réécriture)
de la requête,
• Si q’= q alors la personnalisation est faite uniquement par transformation (tri, agrégation,
etc.) de la réponse de la requête.
FIG.3 - Architecture d’un système de personnalisation
26
Chapitre 3
La personnalisation des données
1.2 Les domaines d’utilisation de la personnalisation de l’information :
Nous avons évoqués au début de ce chapitre une définition de la personnalisation de
l’information, ainsi que l’architecture d’un système personnalisé. Mais , dans quels domaines est
utilisée la personnalisation ?!
1.2.1 Dans le domaine de l’interaction homme-machine (IHM) :
Le profil va contenir des informations qui vont permettre au système d’adapter
l’affichage des résultats selon les préférences de l’utilisateur. Exemple : c’est le cas de
l’environnement de Yahoo ! Qui recueille dans le profil un certain nombre d’informations
personnelles et adapte la page d’accueil en fonction des centres d’intérêt de l’internaute.
1.2.2 Dans le domaine de la recherche d’information (RI) :
Le profil utilisateur peut être représenté de différentes manières dont nous évoquons ici
quelques exemples. Dans certain cas, le profil utilisateur peut être confondu avec la requête ellemême de l’utilisateur. Dans ce cas, le profil utilisateur est alors défini par un vecteur de motsclés, avec éventuellement un poids associé à chaque mot-clé [PRETSCHNER et GAUCH,
1999]. Un profil utilisateur peut également contenir les statistiques d’actions avec le système
(nombre de clics, temps de lecture, etc.) [BRADLEY et AL, 2000], ceci permet par la suite
d’inférer sur les préférences en cernant davantage sont comportement.
Une autre alternative consiste à stocker dans le profil utilisateur des fonctions d’utilités
sur un domaine d’intérêt, qui permettent d’exprimer l’importance relative des sujets de ce
domaine, les uns par rapport aux autres [CHERNIACK et AL, 2003].
1.2.3 Dans le domaine des bases de données (BD) :
Le profil utilisateur peut contenir par exemple les habitudes d’interrogation de celui-ci,
en l’occurrence les prédicats souvent utilisés dans ces requêtes ou des ordres dans ces prédicats
[KOUTRIKA et IOANNIDIS, 2004].
1.2.4 La personnalisation dans les entrepôts de données :
Si la personnalisation n’est pas une idée nouvelle dans les domaines précédemment
évoqués, elle constitue un axe de recherche émergent dans le domaine des entrepôts de données.
L’intérêt de cet axe de recherche peut être motivé à la fois vis-à-vis de la volumétrie des données
connue pour être importante dans les entrepôts de données et du rôle central que joue l’utilisateur
dans le processus décisionnel. En effet, il est en interaction directe avec le système au niveau de
l’analyse des données, en particulier dans le contexte de la navigation. Différentes pistes ont
d’ores et déjà été initiées.
La première proposition s’inspire largement du domaine de la recherche d’informations
(en RI ou en BD). En effet, il s’agit d’affiner la requête de l’utilisateur pour mieux répondre à ses
besoins [BELLATRECCHE et AL, 2005], [BELLATRECCHE et AL, 2006] et
[MOULOUDI, 2007]. Dans ce cas, le concept de profil est utilisé. Il s’agit d’exprimer des
préférences et de satisfaire des contraintes de visualisation. Ce travail trouve un intérêt
particulier dans la mesure où l’aspect visualisation est primordial dans le contexte de l’analyse
en ligne.
27
Chapitre 3
La personnalisation des données
La seconde voie se focalise davantage sur l’utilisation du système et se rapproche
davantage de ce qui se fait en IHM (Interaction Homme-Machine). En effet, dans [RAVAT et
AL, 2006], la personnalisation s’effectue au niveau de la navigation. Il s’agit de représenter les
habitudes d’analyse de l’utilisateur, sous forme de coefficients de préférences pour faciliter sa
navigation.
Un autre type de travail est abordé dans [CHOONG et AL, 2007]. Il s’agit de considérer
une analyse en ligne comme une session interactive durant laquelle l’utilisateur lance des
requêtes. Ainsi, il est intéressant que chaque utilisateur dispose de son propre espace de travail.
L’objectif étant d’organiser les requêtes, de faciliter leur réutilisation voir de partager ces
requêtes avec d’autres utilisateurs.
2. Le profil utilisateur :
2.1 Définition :
La notion de profil utilisateur apparait comme étant à la base de la personnalisation, mais
elle est loin d’être définie de façon standard malgré les Plusieurs approches développées.
Comme WebMate [CHEN et AL, 1998] et WebNant [ZACHARIS et
PANAYIOTOPOULOS, 2001] (Les approches adaptatives) et [PRETSCHNER et GAUCH
1999], [GAUCH et AL 2003] (Les approches sémantiques). Ainsi dans [BOUZEGHOUB et
KOSTADINOV, 2005], les auteurs tentent de classifier les différents types d’information
pouvant être contenues dans un profil utilisateur et de définir un modèle de profil générique et
flexible pouvant s’adapter à différents scénarios de la personnalisation. Dans [MOULOUDI,
2007], le profil utilisateur est défini comme étant :
“Une collection d’information sur l’utilisateur cette collection peut être vue comme un ensemble
de caractéristiques avec des valeurs associées contenant par exemple les préférences
d’utilisateurs’’ , ces préférences que nous évoquerons dans la troisième section.
2.2 Contenu du profil utilisateur :
Comme indiqué précédemment, un profil utilisateur peut être représenté simplement par un
ensemble de caractéristiques permettant au système d’identifier et de modéliser l’utilisateur tout
en respectant sa vie privée [FAVRE, 2007]. Cependant, même si cette vision fait consensus, la
structure et le contenu des différents profils pouvant être identifiés dans la littérature sont très
hétérogènes d’une application à l’autre. En effet, même si plusieurs applications visent à remplir
la même tâche, on peu souligner le fait qu’il existe presque autant de types de profils utilisateurs
qu’il y a d’applications. Un profil utilisateur ne se limite pas aux préférences sur le contenu des
données mais contient également [KOSTADINOV, 2008] :
- des informations personnelles, que l’on appelle aussi démographiques, telles que le nom,
le prénom, l’âge, etc.
- des préférences sur le contenu de la réponse à la requête, des préférences sur la
présentation de la réponse, et / ou des conditions d’exploitation.
Ces informations peuvent être complétées pour adapter encore mieux le processus de la
personnalisation de l’information.
28
Chapitre 3
La personnalisation des données
3. Les préférences utilisateur :
Des préférences utilisateur correspondent à un ensemble de critères permettant pour un
utilisateur spécifique :
- de mesurer la pertinence d’une information, et
- d’évaluer si une information est plus pertinente qu’une autre information.
3.1 Des préférences sur le contenu de la réponse à la requête :
Pour déterminer le contenu personnalisé, le profil doit porter sur les tuples de la réponse à
la requête. Un tel profil est défini et utilisé dans [AGRAWAL et WIMMERS, 2000]
[CHOMICKI, 2003], [KIEßLING, 2002] et [TORLONE et CIACCIA, 2002].
Par exemple [AGRAWAL et WIMMERS, 2000] offre un moyen d’exprimer les préférences du
profil utilisateur à l’aide de fonctions affectant des scores aux tuples de la réponse et permettant
de les ordonner selon leur importance et ainsi de déterminer quels sont les tuples les plus
intéressants. Notons qu’en SQL, l’ordonnancement des tuples peut être fait par l’intermédiaire de
la clause “order by’’ qui permet de classer et de trier les résultats SQL, mais “order by’’ ne
correspond pas à la prise en compte des préférences utilisateur.
3.2 Des préférences sur la présentation de la réponse :
Afin de faciliter la tâche d’analyse de la masse de données, la personnalisation de la
présentation permet de construire une façon adaptée pour afficher le contenu personnalisé. On
fait intervenir ici des informations du profil sur la présentation telle que la disposition des
informations à l’affichage. Ainsi, l’information affichée, même si c’est une réponse à une même
requête, n’est pas identique pour tous les utilisateurs qui ont souvent des besoins différents.
Ce type de personnalisation n’a pas été beaucoup traité dans les BDs. [DAS et AL, 2006]
ont introduit la sélection et l’ordonnancement d’attributs comme nouveau modèle d’extraction
d’informations de BD qui complète le modèle de ré-ordonnancement (ou de classification) de
tuples de résultat d’une requête [AGRAWAL et AL, 2003] [CHAUDHURI et AL, 2004].
L’approche est basée sur l’importance de l’attribut.
L’avantage de la méthode est de constituer une autre manière de présenter moins
d’attributs et de faciliter l’exploration des tuples de la réponse selon leur importance :
- la sélection permet de déterminer les attributs utiles à afficher, et
- l’ordonnancement permet d’ordonner les attributs sélectionnés par ordre décroissant de
leur utilité à l’affichage.
Les auteurs définissent plusieurs variantes pour la notion d’utilité d’attribut (le score, l’ordre,
l’ordre relatif, etc.). Ensuite, ils proposent une approche qui retourne et affiche les Top attributs
de chacune de ces variantes côte à côte.
3.3 Des conditions d’exploitation :
3.3.1 Contrainte :
Une contrainte est une fonction booléenne sur un ensemble de requêtes, elle est utilisée
pour exprimer des critères que les préférences de cellules d’un ensemble de réponses doivent
satisfaire. On trouve les conditions liées au matériel utilisé par l’utilisateur et/ou les contraintes
liées à l’utilisateur lui-même que nous allons distinguer en deux types :
29
Chapitre 3
La personnalisation des données
3.3.1.1 Contraintes techniques :
Ce sont les caractéristiques techniques des dispositifs utilisés. La taille d’affichage, la
capacité de la mémoire, la vitesse du réseau, etc., varient ainsi en fonction du matériel : PC,
ordinateur portable, téléphone WAP12, PDA13, etc.
La description des caractéristiques matérielles est utilisée dans le but d’afficher la
réponse à la requête dans un format cohérent avec les capacités du dispositif de sortie. Ces
caractéristiques sont vues comme des contraintes d’ordre matériel, que l’on doit satisfaire et
respecter lors de l’exécution de la requête et la présentation du résultat. Par exemple dans les
bases de données [KOUTRIKA et IOANNIDIS, 2005], propose de prendre en compte les
contraintes suivantes :
- cost : le coût d’exécution d’une requête doit être réduit au minimum ou satisfaire une
certaine limite supérieure.
- size : par définition, la personnalisation de requête vise d’une part à avoir de plus petites
réponses. D’autre part, les réponses vides sont toujours indésirables. Par conséquent, la
taille de la réponse doit être comprise dans un intervalle donné.
3.3.1.2 Contraintes utilisateur
Elles peuvent être liées à l’utilisateur lui même .Ce sont des règles qui vont déterminer
par exemple le type de la présentation du résultat souhaité par un utilisateur suivant sa fonction :
préférer une présentation sous forme d’un graphe à une présentation sous forme d’un arbre.
3.3.2 Le contexte de requête :
Dans [MOULOUDI, 2007], le contexte de requête peut être défini comme toutes les
contraintes qui forment un ensemble de paramètres intervenant dans l’exécution de la requête et
/ou la présentation de sa réponse.
- les différents paramètres intervenant dans l’exécution de la requête tels que le dispositif
d’accès à l’information, la connexion réseau, l’emplacement, etc.
- les paramètres intervenant dans la présentation de la réponse tels que les choix
disponibles pour l’affichage, l’organisation des résultats, etc.
Ces paramètres sont utilisés sous forme de contraintes dans le processus de personnalisation.
4. Le langage de préférence :
Le langage de préférence permet de décrire des préférences utilisateur et une méthode de
personnalisation, autrement dit un algorithme exploitant les préférences utilisateur qui sont
souvent représentées et stockées dans un profil propre à utilisateur et permet également le calcul
de la réponse personnalisée. On distingue deux types de langages de préférences par rapport à
l’approche de modélisation adoptée que nous évoquons dans ce qui suit, et qui sont :
- Le langage de préférence quantitatif,
- Le langage de préférence qualitatif.
30
Chapitre 3
La personnalisation des données
4.1 Les types d’approches de modélisations :
4.1.1 Approche quantitative :
Dans ce premier type d’approche, les préférences utilisateur sont exprimées (calculées) à
l’aide de fonctions qui attribuent une valeur à chaque élément et la pertinence d’un élément
dépend de la valeur attribuée.
4.1.2 Approche qualitative:
Dans ce second type d’approche, les préférences utilisateur sont exprimées par des
relations binaires de préférences.
4.2 Caractéristique d’un langage de préférence :
Un langage de préférence est caractérisé par :
-Les éléments sur lesquels portent les préférences utilisateur :
Les éléments pertinents pour l’utilisateur sont traités, il s’agit de déterminer les éléments sur
lesquels l’utilisateur porte son intérêt, comme ceux manipulés dans les bases de données
relationnelles (tuple, domaine d’attribut, etc.). Par exemple des préférences exprimées sur des
tuples vont permettre de spécifier comment comparer ces tuples.
-Le type de relation de préférence :
Précise la relation de préférence définie entre des éléments de base de données permettant de les
comparer. Cette relation de préférence peut être une relation binaire ou, plus spécifiquement une
relation d’ordre.
-Les compositions possibles des préférences :
Indique si on peut combiner les relations de préférence et quel type de composition est possible.
Cette composition est un aspect crucial au niveau de la modélisation de préférence car elle
permet d’exprimer de nouvelles relations tout en préservant les propriétés importantes des
relations d’ordre.
-L’utilisation des préférences conditionnelles :
Indique si un langage de préférence permet de modéliser une préférence qui dépend d’une
condition donnée.
5. La personnalisation et OLAP :
5.1 Le processus de personnalisation :
Le processus de la personnalisation a pour vocation de répondre aux trois questions cidessous : pourquoi, quoi et comment personnaliser pour faciliter l’accès à une ressource
importante d’informations ?
pourquoi ?
Fournir une réponse rapide, réduite, utilisable et adaptée à l’utilisateur en fonction de son profil
(défini par cet utilisateur ou appris) et du contexte.
quoi ?
L’adaptation prend en compte le contenu et la mise en forme de la réponse
comment ?
Il est possible de personnaliser, à l’aide de l’un ou l’autre des deux moyens suivants :
transformation de la requête et transformation de la réponse à la requête.
31
Chapitre 3
La personnalisation des données
5.2 Les types de personnalisation :
5.2.1 La personnalisation de la requête :
Consiste à transformer la requête de l’utilisateur, en effet, la requête de l’utilisateur est
enrichie avec le profil utilisateur, ensuite elle est exécutée par le système afin de fournir la
réponse personnalisée.
FIG.4 - La personnalisation avant l’accès aux données de cube
5.2.2 La personnalisation de la réponse :
Consiste à transformer la réponse, la requête de l’utilisateur est exécutée par le système,
ensuite la réponse est filtrée ou réordonnée afin d’aboutir à la réponse personnalisée.
FIG.5 - La personnalisation après l’accès aux données de cube
32
Chapitre 3
La personnalisation des données
5.3 Types de requêtes :
Dans [MOULOUDI, 2007], deux types de requêtes ont été distinguées qui sont :
5.3.1 Requêtes de comparaison :
Ce type de requêtes permet de déterminer si un élément est préféré à un autre, en effet, il
vérifie si des éléments sont comparables et indique l’élément préféré à l’autre. Et dans ce type on
trouve :
-Les requêtes de dominance, et
-Les requêtes d’ordre.
5.3.2 Requêtes d’optimisation :
Ce type de requêtes permet de déterminer l’ensemble des éléments préférés d’un
ensemble et on distingue :
-Les requêtes d’optimisation sans contraintes, et
-Les requêtes d’optimisation avec contraintes.
6. Travaux de personnalisation dans les entrepôts de données :
Comme nous l’avons déjà dit, le processus de personnalisation dans les entrepôts de
données est un axe émergent, donc il n’a pas été beaucoup traité dans les bases de données
multidimensionnelles. Dans [FAVRE, 2007], ces travaux peuvent être classés comme suit :
6.1 La personnalisation inspirée de la recherche d’information :
Avant de présenter ces travaux nous allons définir quelques concepts essentiels pour
mieux se rendre compte.
6.1.1 Concepts et définition :
6.1.1.1 Référence d’une cellule :
Une cellule ou fait de c est un tuple de l’instance de la table des faits f, et sa référence est
un tuple et elle est définie à partir de la table des faits.
Exemple :
Soit le cube de vente suivant : C= {D1, D2, D3, D4, F} tel que,
La dimension temps est D1= {Temps1, Temps 2, Temps 3, Temps 4, Temps 5, Temps 6},
La dimension produit est D2= {produit 1, produit 2, produit 3, produit 4},
La dimension ville est D3= {ville 1, ville 2, ville 3, ville 4},
La dimension mesure est D4= {quantite, prix},
Une cellule du cube de données vente présenté précédemment qui correspond au tuple
(Temps1, produit 1, ville 1, quantite, quantite 1). La référence de cette cellule est le tuple
(Temps1, produit 1, ville 1, quantite) appartenant respectivement aux dimensions temps, produit
et ville.
33
Chapitre 3
La personnalisation des données
6.1.1.2 Structure :
Définit le placement des dimensions sur les différents axes et l’ordre d’apparition des
membres de chaque dimension sur un axe donné. Et décrit avec précision la table croisée utilisée
pour afficher une instance donnée d’un cube. En MDX la structure est définie dans la requête.
Une structure d’affichage spécifie le moyen d’organiser un ensemble de références dans un
tableau croisé, notamment en précisant comment placer les dimensions du cube analysé sur les
axes d’analyse. Étant donné qu’un utilisateur peut préférer voir un même ensemble de références
en utilisant une structure donnée plutôt qu’une autre.
Exemple :
La dimension temps est placée en colonnes et la dimension produit est imbriquée dans la
dimension ville et sont placées en lignes.
6.1.1.3 Grille d’analyse :
Une grille d’analyse est le résultat (ou visualisation) de l’exécution d’une requête MDX
sous la forme d’une grille de cellules. Elle (grille d’analyse) constituée seulement d’un ensemble
de références de structures. Veut dire qu’elle ne contient pas de faits. Et pour chaque grille
possède une structure et un ensemble de références propre à elle. Dans la pratique, on constate
que les grille d’analyses considérées sont généralement des grilles régulières, dans le sens où leur
ensemble de références est un produit cartésien de sous ensembles de membres des différentes
dimensions d’analyse.
Exemple :
Le langage de requêtes MDX permet uniquement de définir des grilles d’analyse régulières.
6.1.1.4 Visualisation :
Une visualisation permet de présenter les données d’un cube à un utilisateur sous forme
d’une table croisée. Elle contient les données du cube et est caractérisée par unestructure qui
permet de préciser la forme de présentation des données du cube à l’affichage.
6.1.1.5 La contrainte de visualisation :
Indique si un cube avec sa structure peut être visualisé.
Exemple :
34
Chapitre 3
La personnalisation des données
6.1.2 Travaux de BELLATRECHE et AL 2005 :
Dans [BELLATRECHE et AL, 2005], les auteurs ont proposé une méthode pour la
personnalisation des requêtes OLAP en exploitant le profil utilisateur pour apporter une
meilleure visualisation à ce dernier (l’utilisateur). Dans cette approche, la personnalisation
consiste à transformer la requête utilisateur avant l’accès au cube de données.
Dans cette méthode, l’utilisateur est interrogé afin de donner ses préférences et une contrainte de
visualisation. Ces préférences utilisateurs qui classent les membres, les dimensions et la
contrainte de visualisation qui contrôlent les résultats sont stockées dans le profil utilisateur. Et
une définition du profil utilisateur dans le contexte OLAP est proposée.
Les préférences utilisateur définissent une relation de pré ordre total pour l’ensemble des
membres de toutes les dimensions. Cette relation de préordre total sur les membres utilisée pour
définir une relation monotone de préordre total sur les cubes. Par Exemple, pour les membres m1
est plus intéressant que m2 veut dire que m1
m2. Pour les cubes si le cube C1 est le sous cube
de C2 (C1 C2), alors C1 moins intéressant que C2 et C1 C2.
Les auteurs introduisent les contraintes de visualisation ou d’ordre machine dans ce contexte.
Ces contraintes précisent la taille de l’écran d’affichage du dispositif (machine), ou plus
précisément le nombre maximal de graduations qui peuvent être affichées sur les différents axes
d’analyse
Exemple :
Soit un cube de vente C composé de trois dimensions location, produit et temps et une
mesure quantité.
La dimension localisation contient quatre membres qui sont : L1, L2, L3, L4
La dimension temps contient six membres qui sont les années : A1, A2, A3, A4, A5, A6
La dimension produit contient quatre produits qui sont : P1, P2, P3, P4
Soient C1et C2 deux sous cubes de cube initial C tel que :
L’ensemble des membres de C1est l’ensemble M1= {L1, P1, P2, P3, P4, A3, A4, A5, A6},
L’ensemble des membres de C2 est l’ensemble M2 = {L1, L2, L3, L4, P1, P2, A5, A6},
Soit la relation de préordre total
définie sur les dimensions location, temps et
produit comme suit : (P1, P2) >p A6>p A5>p (L1, L2, L3, L4) >p (A1, A2, A3, A4) >p (P3, P4)
Donc nous avons : M1\ M2= {P3, P4, A3, A4} et M2\ M1= {L2, L3, L4}
Les membres les plus intéressants définis par
et qui distinguent C1 de C2 sont L1, L2 et
L3. Ces membres appartiennent à C2 et n’appartiennent pas à C1, donc C2 est préféré à C1
(C1 C2).
Soit la contrainte de visualisation VT, G définie comme suit : G= (4,4), veut dire que la grille
d’affichage est composée de quatre lignes et de quatre colonnes. Pour le cube C1, il ne peut pas
être affiché, mais le cube C2 peut être affiché (location en lignes, produit et temps en colonnes).
35
Chapitre 3
La personnalisation des données
6.1.3 Travaux de BELLATRECHE et AL 2006 :
L’approche de personnalisation des requêtes OLAP proposée dans [BELLATRECHE et
AL, 2006], qui se base sur les travaux réalisés dans [BELLATRECHE et AL, 2005] sur le
problème de la personnalisation des requêtes OLAP. Dans cette méthode, il s’agit de combiner la
requête originale de l’utilisateur (q) avec le profil utilisateur (Γ) qui contient ses préférences et
vérifiant les contraintes de visualisation pour avoir une requête (q*) personnalisée et prête à être
exécutée sur le cube de données.
Dans cette méthode, les auteurs ont proposé un modèle de préférence basé sur la relation
d’ordre partiel qui est plus flexible et plus pratique que celui proposé dans [BELLATRECHE et
AL, 2005], qui se présente ainsi : les préférences utilisateur définissent des relations d’ordre
partiel sur les membres de chaque dimension notée (<di) et sur toutes les dimensions notée (<d).
Par exemple pour les dimensions, D1 et D2 deux dimensions d’un cube, on dit que la dimension
D1 est plus intéressante que D2 si D2<d D1.
Et pour les membres d’une dimension, on dit que le membre m1 est plus intéressant que m2 si
m2<di m1 tel que m1 et m2 appartiennent à la même dimension. Ces relations d’ordre vues
précédemment sont combinées pour définir un ordre lexicographique sur les références de
cellules qui définissent à leur tour une relation d’ordre partiel sur les requêtes qui sont exprimées
en langage MDX. Par exemple si on prend deux requêtes q1 et q2, on dit que q2 est préférée à q1
pour un utilisateur, si son profil prétend que les références des cellules de la réponse de q2 sont
préférées à celles de q1.
Les auteurs introduisent les contraintes de visualisation ou d’ordre machine dans ce
contexte. Ces contraintes précisent la taille de l’écran d’affichage du dispositif (machine), ou
plus précisément le nombre maximal de graduations qui peuvent être affichées sur les différents
axes d’analyse.
Exemple :
Soit la requête MDX suivante :
SELECT {[Location].L1,[Location]. L2},
{[temps]. A3,[ temps]. A4,[ temps]. A5,[ temps].A6},
{[ produit].P3,[ produit].P4,[produit]. P1,[ produit]. P2}
FROM C
WHERE [Measures].quantite
Tel que C est le cube défini dans l’exemple précédent et les relations d’ordre définies sur les
dimensions (<d) et les membres de chaque dimension (<di) comme suit :
Temps <d location et produit <d location
A1<temps A2<temps A3<temps A4<temps A5<temps A6
P1 <produit P2 <produit P3<produit P4
L1, L2, L3, L4<location L1, L4<location L2, L3<location L1 et L3<location L2
La requête MDX personnalisée obtenue est :
SELECT {[temps]. A3,[ temps]. A4,[ temps]. A5,[ temps].A6} ON COLUMNS,
CROSSJOIN ({[Location].L1,[Location]. L2},
{[produit].P3,[ produit].P4}) ON ROWS
FROM C
WHERE [Measures].quantite
36
Chapitre 3
La personnalisation des données
Si nous avons une contrainte de visualisation qui permet d’afficher une table croisée de
quatre lignes et quatre colonnes, alors le résultat de cette requête peut être affiché.
6.1.4 Travaux de MOULOUDI 2007:
L’approche de personnalisation des requêtes OLAP proposée par Mouloudi dans
[MOULOUDI, 2007], peut être effectuée à l’aide de méthodes différentes et qui se présentent
ainsi :
-dans la première, il s’agit de personnaliser la requête de l’utilisateur qui veut dire transformer la
requête de l’utilisateur avant l’accès aux cubes de données,
- et l’autre consiste à personnaliser la réponse de la requête utilisateur qui veut dire transformer
le résultat de la requête utilisateur après l’accès au cube de données.
L’auteur a montré que sous certaines conditions (la relation d’ordre définie sur les grilles
d’analyse est monotone à l’inclusion des références et la contrainte définie sur les grilles
d’analyse est invariante par projection) que les deux types de personnalisation aboutissent aux
mêmes résultats. Mais lors de l’implémentation, l’auteur s’est limité à la première seulement.
Dans cette approche, la personnalisation de la visualisation d’une requête OLAP exprimée en
langage MDX passe par la personnalisation d’une grille d’analyse associée à cette visualisation.
Les préférences utilisateur dites de contenu définissent un ordre lexicographique sur les
références de cellules du cube de donné considéré, cet ordre sur les références désigné par ordre
utilisateur sur les références noté <R, est défini à partir de deux types d’ordre : un ordre partiel
sur les dimensions et sur les ensembles de membres de chaque dimension comme dans
[BELLATRECHE, 2006]. Et les préférences utilisateur de placement dites de présentation
définissent un ordre total strict sur les dimensions et sur tous les membres des de chaque
dimension. Ces préférences sont utilisées pour définir un ordre (n’est pas total) sur les structures
noté (<s). Par exemple une structure S1 est préférée à S2 si S2 <s S1 (voir annexe B).
L’ordre défini sur l’ensemble des références est combiné avec celui défini sur les
structures pour avoir un ordre strict sur les grilles d’analyses noté (<G). On dit que la grille G1 est
préférée à G2 (G2<G G1) si l’ensemble de références de G1 est préféré à celui de G2 ou les deux
ensemble de références sont équivalents et la structure de la grille G1 est préférée à celle de G2
telle que : une grille G= (R, S) (est un couple composé d’un ensemble de références R et une
structure S). Cette définition nous montre que les préférences utilisateur de placement ne sont
prises en compte pour comparer deux grilles que si les préférences utilisateur de contenu ne
permettent pas de les comparer, donc elle privilégie le contenu sur la présentation.
Elle a introduit les contraintes utilisateur et de dispositif, les premières sont liées à un
utilisateur ; elles précisent comment un utilisateur veut visualiser ses données et les secondes
sont liées à un dispositif d’affichage particulier (PDA, téléphone mobile, etc.). Elles précisent par
exemple quelle est la taille de l’écran d’affichage du dispositif, ou plus précisément le nombre
maximal de graduations qui peuvent être affichées sur les différents axes d’analyse.
37
Chapitre 3
La personnalisation des données
FIG.6 - Ordre sur les visualisations
Les préférences utilisateur sur les visualisations définissent une relation d’ordre partiel,
-La relation d’ordre utilisée pour comparer les visualisations est obtenue par composition des
d’ordres des ensembles de références et d’ordre sur des structures,
-La combinaison des ordres est une composition multidimensionnelle lexicographique,
-Dans cette solution ils proposé des requêtes prédéfinies pour l’utilisateur.
-Exemple :
Soit l’ensemble de référence suivant : R= {L1, L2, L3} × {P1, P2, P3, P4} × {A3, A4, A5,
A6}
Temps <D Location et Produit <D Location, notons que Temps, Produit et mesures ne sont pas
comparables.
Pour la dimension produit P1 <produit P2 <produit P3<produit P4
Pour la dimension location L4<location L1, L4<location L2, L3<location L1 et L3<location L2
L1 et L2 ne sont pas comparables.
Pour La dimension temps A1<temps A2<temps A3<temps A4<temps A5<temps A6
Soient les trois sous ensembles de références suivant :
R1 = {L3} × {A5, A6}, R2= {L1} × {A5, A6} et R3 = {L2} × {A5, A6},
Nous avons pour tout tuple t = (L3, A5, A6) de la Grille1 et t’ de Grille2 = (L2, A5, A6)
Les membres qui rendent Grille1 et Grille2 différentes appartiennent à la dimension
Location, d’après l’ordre défini sur les membres de cette dimension L3<location L1, la
Grille2 est préférée à Grille1.
Les membres qui rendent Grille1 et Grille3 différentes appartiennent à la dimension
Location, d’après l’ordre défini sur les membres de cette dimension L3<location L2, la
38
Chapitre 3
La personnalisation des données
Grille3 est préférée à Grille1.
Les membres qui rendent Grille2 et Grille3 différentes appartiennent à la dimension Location,
d’après l’ordre défini sur les membres de cette dimension, L1 et L2 ne sont pas comparables.
Donc la Grille2 et la Grille3 ne sont pas comparable.
FIG. 7
-
6.1.5 Conclusion :
Le tableau ci-dessous récapitule l’essentiel des travaux de personnalisation dans les
entrepôts de données étudiés. Même si l’objectif est le même et qui est celui d’adapter la réponse
à la requête utilisateur en faisant intervenir ses préférences. Les méthodes proposées pour cela (la
personnalisation) n’abordent pas nécessairement ce problème de la même manière (ou abordent
ce problème presque de la même manière, et elles différent au niveau de la modélisation des
préférences).
Dans chaque méthode de personnalisation, on cherche à personnaliser les requêtes utilisateur
selon son profil. Ce dernier (profil) contient des préférences qui définissent des relations d’ordre
dans [BELLATRECHE, 2006] et [MOULOUDI, 2007] ou de préordre dans
[BELLATRECHE, 2005]. Par l’ajout de contraintes qui ne sont pas nécessairement prises en comptes
par toutes les méthodes [BELLATRECHE, 2005] vise d’abord à produire des résultats intéressants
pour un utilisateur, ensuite présenter les résultats sous la forme souhaitée par l’utilisateur et en fin avoir
pour une requête personnalisée de plus petites réponses.
Selon le type de personnalisation, les méthodes visant à personnaliser le contenu de l’information
utilisent les préférences utilisateur sur des requêtes sans avoir l’accès au cube de données, l’inconvénient
est le risque d’avoir les réponses vides et de ne fournir aucune information à l’utilisateur. Ce n’est pas
nécessairement le cas pour les méthodes personnalisant après l’accès au cube de données. En effet le
traitement peut se faire après l’exécution de la requête utilisateur, c'est-à-dire sans la prise en compte de la
personnalisation dans le calcul des résultats, ensuite, trouver parmi ces résultats ceux jugés intéressant du
point de vu utilisateur.
39
Chapitre 3
La personnalisation des données
6.2 La personnalisation dans l’évolution de schémas :
6.2.1 Travaux de FAVRE 2007 :
L’approche de personnalisation proposée dans [Favre, 2007], est une solution basée sur
une évolution du schéma de l’entrepôt guidée par les utilisateurs. Il s’agit en effet de recueillir
les connaissances de l’utilisateur et de les intégrer dans l’entrepôt de données afin de créer de
nouveaux axes d’analyse.
Cette solution s’appuie sur la définition d’un modèle formel d’entrepôt de données évolutif, basé
sur des règles «si-alors», appelées aussi règles d’agrégation, qui permettent de représenter les
connaissances des utilisateurs. Le modèle d’entrepôt évolutif est soutenu par une architecture qui
place l’utilisateur au cœur du processus d’évolution du schéma de l’entrepôt.
Cette approche se base donc sur une architecture qui permet de gérer tout le processus
décisionnel : acquisition des connaissances utilisateurs sous forme de règles, intégration de ces
règles dans l’entrepôt, évolution du schéma de l’entrepôt et enfin l’analyse en ligne.
L’évolution de schéma consiste plus précisément en l’ajout de nouveaux niveaux de granularité
dans les hiérarchies de dimensions existantes. Afin de soutenir cette architecture, l’auteur à
proposé un modèle d’entrepôt de données évolutif à base de règles d’agrégation qui permettent
l’expression des connaissances utilisateurs, ainsi que la mise à jour des hiérarchies de dimension.
Ce modèle, nommé modèle R-DW (Rule-based DataWarehouse), permet de modéliser un
entrepôt de données évolutif flexible, pour la prise en compte de nouveaux besoins d’analyse.
L’architecture globale de l’entrepôt de données évolutif guidé par les utilisateurs est présentée
dans la Fig8. Architecture générale d’entrepôt de données évolutif guidé par les utilisateurs. Elle
se décompose en quatre modules, le premier module est l’acquisition des connaissances
utilisateurs [ESPIL et AL, 2002].
40
Chapitre 3
La personnalisation des données
FIG . 8
Le modèle R-DW à base de règles est composé d’une partie fixe et d’une partie évolutive
Fig.9 : Principe du modèle R-DW. La partie fixe comprend la table des faits et les dimensions
qui lui sont directement reliées. La partie évolutive comprend l’ensemble des hiérarchies qui sont
définies lors de la conception du schéma initial ou lors de la personnalisation des analyses.
FIG ; 9
Le modèle R-DW ne permet pas l’ajout d’un niveau directement relié à la table des faits,
qui constituerait ainsi une nouvelle dimension. Ce choix est motivé par deux aspects.
Premièrement, il assure une cohérence des données stockées dans l’entrepôt. Si l’on envisage la
création de dimension par les utilisateurs, cela engendrerait une évolution dans le processus
d’alimentation de l’entrepôt. En effet, une telle évolution nécessite une modification du
processus ETL qui ne peut être réalisée par l’utilisateur. Deuxièmement, la partie fixe du modèle
41
Chapitre 3
La personnalisation des données
R-DW constitue une réponse à de besoins d’analyse initiaux, pouvant être communs aux
différents utilisateurs, défini lors de la conception de l’entrepôt.
La modélisation initiale fournit ainsi un schéma de l’entrepôt pouvant servir à l’ensemble des
utilisateurs pour l’analyse.
Comme son nom l’indique, le modèle R-DW est basé sur des règles. Celles-ci vont
permettre la création de nouvelles hiérarchies par ajout de niveau de granularité au-dessus d’une
table de dimension ou l’extension des hiérarchies existantes par ajout d’un niveau de granularité
en fin de hiérarchie ou au sein de celle-ci.
Les règles utilisées dans le modèle R-DW sont de type «si-alors», tel que :
-La clause «si» permet d’exprimer les conditions sur les attributs caractérisant le niveau de
granularité inférieur, c’est-à-dire le niveau à partir duquel sera généré le nouveau niveau.
-Dans la clause «alors» figure la définition du niveau de granularité à créer, c’est-à-dire la
définition des valeurs des attributs caractérisant ce nouveau niveau de granularité.
Ces règles qualifiées de règles d’agrégation puisqu’elles établissent un lien d’agrégation entre
deux niveaux de granularité dans une hiérarchie de dimension. Les règles d’agrégation « si-alors
» exprimées par les utilisateurs doivent satisfaire deux contraintes pour que la création du niveau
se réalise Fig.10
La première contrainte est que les clauses «si» des règles d’agrégation définissent une
partition des instances du niveau inférieur. La deuxième contrainte est liée au lien d’agrégation
défini entre le niveau inférieur et le niveau créé. Chaque sous-ensemble d’instances de cette
partition est associé à une et une seule instance du niveau créé.
FIG . 10
Exemple :
Soit l’entrepôt de données suivant qui nous permet d’étudier le NBI (Net Banking
Income), ce qui correspond à ce que rapporte un client à l’établissement bancaire. Le schéma
multidimensionnel considéré est fourni dans la figure d’au-dessous. Il permet d’analyser la
mesure NBI selon les dimensions CLIENT, AGENCE et ANNEE. La dimension AGENCE
présente une hiérarchie.
42
Chapitre 3
La personnalisation des données
FIG . 11
Il est ainsi possible d’agréger les données selon le niveau UNITE_COMMERCIALE qui
est un regroupement d’agences par rapport à leur localisation géographique, tel que le montre le
schéma de la dimension AGENCE de la Fig.12
FIG . 12
Supposons qu’un utilisateur veut analyser le NBI selon le type d’agence ; il sait qu’il en
existe trois : type «étudiant» pour les agences ne comportant que des étudiants, type «non
résident» lorsque les agences ne gèrent que des clients ne résidant pas en France et le type
«classique» pour les agences ne présentant pas de particularité. Ces informations n’étant pas
présentes dans l’entrepôt, il est impossible pour lui d’obtenir cette analyse.
Nous proposons alors à l’utilisateur d’intégrer sa propre connaissance sur les types d’agence afin
de créer un niveau TYPE_AGENCE. Cela passe par la mise à jour (création) de la hiérarchie de
la dimension agence en ajoutant le niveau TYPE_AGENCE au-dessus du niveau AGENCE
selon le schéma de la Fig.13
L’utilisateur pourra ainsi réaliser une analyse du NBI en fonction du TYPE_AGENCE.
43
Chapitre 3
La personnalisation des données
FIG . 13
Exemple de règles d’agrégation :
Les règles suivantes déterminent les valeurs des attributs Age_Class et Age_Class_Description
qui caractérisent le niveau de granularité AGE construit au- dessus de la dimension CLIENT :
Règle1 :
Si Age < 18
Alors Description_ Class_ Age= ‘ mineur ’ ET Classe_ Age = ‘moins de 18 ans’
Règle2 :
Si Age 18
Alors Description_ Class_ Age= ‘ majeur’ ET Classe_ Age = ‘plus de 18 ans’
6.3 La personnalisation dans la réutilisation des requêtes :
6.3.1 Travaux de CHOONG et AL 2007 :
L’auteur et ses collaborateurs ont proposé dans [CHOONG et AL, 2007], un modèle de
personnalisation des requêtes d’analyse en ligne de données multidimensionnelles, qui permette
de lancer, de naviguer dans des requêtes, d’organiser, de réutiliser, de partager une analyse, de
découvrir des requêtes fréquemment posées et de Proposer des recommandations à l’utilisateur et
son implantation est en cours qui fait partie de leur perspective.
Ce modèle est divisé en deux niveaux, données et système. Le niveau données permet de décrire
les données manipulées, c’est-à-dire ce qui compose une analyse, à savoir les objets et les liens
entre eux. Le niveau système, spécifie comment il est possible de naviguer dans les données ou
comment éditer ces données.
Pour le premier niveau, les auteurs ont considéré 3 relations : Objects qui est une relation
ternaire. Un fait object(Oid,A,V) indique que l’objet identifié par Oid a un descripteur qui a pour
attribut A et valeur V. Contexts qui est une relation binaire. Un fait contexts(Cid, Oid) indique
que l’objet identifié par Oid appartient au contexte identifié par Cid. references est une relation
quaternaire.
44
Chapitre 3
La personnalisation des données
Un fait références (Oid1,Oid2, A, V) indique qu’il existe un lien de l’objet Oid1(requête
OLAP) vers l’objet Oid2(requête OLAP) et que ce lien est décrit par un attribut A et sa valeur V.
Les instances de ces 3 relations constituent une instance de la Base de contexte. On remarque
que cela forme un graphe qui va être questionné par la suite.
Le système est une paire <Base, Etat> où Base est une instance de base de contextes et Etat est
un triplet <P, Onav, Oed> qui représente ce qui est montré à l’utilisateur. P est une requête,
écrite sous forme de programme à l’aide du langage défini précédemment. Onav est l’identifiant
de l’objet (requête OLAP) posé par autre utilisateur, appelé l’objet navigué. Oed est l’identifiant
de l’objet (requête OLAP) créé par l’utilisateur et appelé l’objet édité.
La base de contextes qui contient les objets, les contextes et les références et qu’une
instance de base de contextes est un ensemble fini de faits tel que chaque objet appartient à un et
un seul contexte. On remarquera donc que l’ensemble des contextes est une partition de
l’ensemble des objets.
Une base de contextes peut être décrite comme un graphe, plus une partition de l’ensemble des
noeuds du graphe (les contextes) dont les noeuds sont les objets, les arcs sont les références entre
les objets et les ensembles d’objets (les contextes) voir Fig.14
Cette visualisation est similaire au modèle utilisé pour décrire le Web où les pages sont les
noeuds, les liens entre les pages sont les arcs et les ensembles de pages des sites.
FIG . 14
Dans cette approche, les notions de hubs et autorités sont définies. Une autorité est un
contexte qui est référencé par tous les autres contextes et un hub est un contexte qui permet
d’accéder à tous les autres contextes. Il y a deux(2) types de descripteurs : les descripteurs
associés aux objets (requête OLAP) et les descripteurs associés aux références.
Les descripteurs associés aux objets. La plupart du temps, ces descripteurs sont ajoutés par
l’utilisateur pour caractériser un objet (requête OLAP). De tels descripteurs peuvent être : topic
dont la valeur donne une description textuelle de l’objet (requête OLAP) ou code dont la valeur
est le code (SQL, MDX) de la requête. Cependant, dans certains cas, ces descripteurs associés
aux objets sont ajoutés ou mis à jour par le système afin de collecter les informations relatives à
la navigation de l’utilisateur. De tels descripteurs peuvent être : launched dont la valeur est un
compteur qui indique combien de fois l’objet a été évalué, browsed dont la valeur est un
compteur qui indique combien de fois l’objet a été visualisé ou result dont la valeur est le résultat
de la requête qui est usuellement affiché sous la forme d’un tableau croisé (table
multidimensionnelle).
45
Chapitre 3
La personnalisation des données
Le second type, à savoir, les descripteurs associés aux références qui indiquent comment
les objets (requêtes OLAP) sont organisés soit à l’intérieur d’un contexte (on parle de références
intra contexte) soit entre les contextes (on parle de références inter contextes). Des références
intra contexte peuvent être, par exemple : order of importance : dont la valeur exprime une
relation d’ordre sur les objets d’un contexte. Ceci peut être interprété comme un ordre
d’importance intéréssant pour l’utilisateur, query containment dans ce cas, la référence relie 2
requêtes de sorte que l’une filtre l’autre (c’est le sens usuel du query containment), qyey logs :
dont la valeur exprime dans quel ordre les requêtes ont été définies. En ce qui concerne les
références inter contextes, les descripteurs peuvent être : comes-from : qui indique que l’objet
source est une copie d’un autre objet et qu’il a donc été pris dans un autre contexte, copied-to qui
est le descripteur inverse de comes-from.
Cette approche s’intéresse à celle de recommandation. Le terme recommandation est issu
du E-commerce et consiste à indiquer à l’utilisateur que s’il est intéressé par un objet donné, il
risque d’être aussi intéressé par d’autres objets pour telle ou telle raison.
Pour ce faire, les auteurs exploitent un type particulier de références nommées comes-from qui
sont créées lorsqu’un utilisateur réutilise une requête d’un autre utilisateur.
Une recommandation peut être définie de différentes manières.
Par exemple un utilisateur est en train de visualiser l’objet (requête OLAP) O1, une
recommandation à O1 sont tous les objets référencés par les réutilisation de O1. Ici, l’objet
(requête OLAP) O2 est une réutilisation de O1, l’objet (requête OLAP) O3a, l’objet (requête
OLAP) O3b sont référencés par l’objet (requête OLAP) O2, donc Tous les objets dans la zone
violette peuvent être des recommandations pour un utilisateur visualisant O1 (exemple
recommandantion-figure suivante)
FIG.15 - Exemple de recommandation
Exemple :
Cet exemple illustre une analyse simple exécutée dans un environnement multiutilisateur
en montrant les actions de l’utilisateur pour organiser, réutiliser, évaluer ou partager des requêtes
OLAP. Il y a 2 utilisateurs : user1 et user2 et 2 cubes de données : ‘Tourisme’ & ‘Agriculture’.
Ainsi qu’une base de sessions d’analyses qui ont déjà été faites par user1 et user2.
Voici un exemple d’environnement de travail, celui user2.
46
Chapitre 3
La personnalisation des données
User2 peut poser de nouvelles requêtes sur l’ensemble des données existantes (les deux de cubes
de données) et de visualiser les résultats.
User2 peut naviguer dans ‘Tourisme en Malaisie’ ou sont stockés les objets de user1 (ses
requêtes OLAP ou les résultats d ses requêtes) lors d’une précédente analyse (partage et
réutilisation). Cet espace de travail ou session d’analyse est appelé un contexte (C’est un
ensemble d’objets (requêtes OLAP)).
6.4 La personnalisation contextuelle :
6.4.1 Travaux de PITOURA et STEFANIDIS 2002:
Dans [PITOURA et STEFANIDIS, 2002], les auteurs ont proposé une approche de
personnalisation basée sur l’utilisation des préférences contenues dans le profil utilisateur et qui
porte sur le contenu. Ces préférences dites préférences quantitatives contextuelles sont
représentée par le modèle de fonction de score.
Le contexte est défini comme un terme utilisé pour exprimer la situation de l’utilisateur
au moment de la soumission de sa requête, incluant l’environnement entouré (temps et/ou
l’endroit). Dans cette approche, les auteurs ont utilisé le contexte pour montrer (indiquer) qu’un
attribut ne fait pas partie du schéma de la base de données. Pour avoir plus de flexibilité dans le
contexte décrit, les attributs contextuels prennent des valeurs dans les domaines d’hiérarchies.
Cette approche est valable pour les deux cas de modèles quantitatif et qualitatif. Ces attributs de
contexte appartiennent à une hiérarchie associée des niveaux d’agrégation de données (peuvent
être visualisée aux niveaux de granularité différents).
Une hiérarchie d’attributs est le couple (L, <), tel que : L= {L1, L2,... Lm-1, All} de m
niveaux et “<’’est un ordre partiel entre les niveaux de L (L1<L2<... Lm-1< All), All est le niveau
le plus haut (le plus agrégé) et L1est le niveau le plus bas.
Une préférence contextuelle quantitative « P » sur un schéma d’une base de données R (A1, A2,
A3, ..., Ad) est le triplet (EC, prédicat, score) tel que :
-EC est l’état de contexte, qui est un n-tuple de la forme (c1 , c2,……. Cn), où ci appartient au
domaine de l’attribut Ci
-prédicat de la forme
qui spécifie la condition en fonction de aij appartenant au domaine Aij (1< ij <d),
-et score est un nombre réel compris entre 0 et 1 (voir exemple).
Environnement de contexte est un ensemble de paramètres de contexte et on distingue
deux types de paramètres de contexte simples qui sont des attributs qui prennent des valeurs dans
leurs domaines et composés qui sont des ensembles de paramètres de contexte simples.
Le score d’un tuple est déterminé de la façon suivante :
-Si aucune des préférences spécifiée pour l’état de contexte (EC) n’est applicable au tuple, c'està-dire, les prédicats correspondant dans les préférences définies pour EC ne sont pas prise part,
alors le score par défaut “0’’ est attribué au tuple t.
-Si plusieurs préférences sont applicables au tuple t, alors le score attribué à ce dernier est celui
de la préférence qui a le plus grand score.
Le prédicat d’un tuple t noté préd1(t) englobe un autre prédicat du même tuple t noté préd2 si
quelque soit le tuple t appartient à l’instance de la base de données, préd1(t)
47
Chapitre 3
La personnalisation des données
-préd2(t), qui veut dire que préd1 est plus spécifique que préd2 et dans ce cas le score du tuple est
celui du prédicat le plus spécifique (l’utilisateur spécifie ou affine).
Cette méthode consiste en premier lieu à définir les préférences qui vérifient les
différentes circonstances et les regrouper en accordant l’une à l’autre :- Leur partie du contexte, ainsi en créant les groupes de préférences applicables pour les états
de contextes semblables.
-Leur partie du non-contexte (i.e. la partie prédicat et score), ainsi en créant les groupes de
préférences qui produisent des scores similaires.
En second, les préférences de chaque groupe sont utilisées pour calculer le score
intéressant de chaque tuple d’un groupe donné. Et en dernier, pour chaque requête soumise par
l’utilisateur, on cherche le contexte similaire dans les groupes de requete et en utilisant les scores
de tuples des groupes retournés afin d’obtenir rapidement des résultats classifiés basés sur les
scores calculés.
FIG . 16
Exemple :
Soit le schéma de la base de données suivant :
Film (titre, année, réalisateur, genre, langue, durée)
Les paramètres simples de contexte (attributs de contexte) sont : compagnie, période et humeur
Utilisateur (id_user, âge, sexe)
Environnement de contexte est le quadruplet (utilisateur, compagnie, période, humeur)
Une instance de la base de données présentée au-dessous
48
Chapitre 3
La personnalisation des données
Soit le profil suivant qui contient ces préférences :
P1= ((amis), genre = horreur, 0.8), P2= ((amis), réalisateur = Hitchcock, 0.7)
P3= ((seul), genre = Drama, 0.9), P4= ((seul), (genre = Drama ˄ réalisateur = Spielberg),0.5)
Dans le contexte amis, les deux préférences P1 et P2 sont applicables au tuple t2.
Dans le contexte seul, les deux préférences P3 et P4 sont applicables au tuple t3.
Dans le premier cas, aucun des deux prédicats de P1 et P2 n’englobe l’autre donc le score
de t2 est le maximum des deux prédicats qui est 0.8. Dans l’autre cas le prédicat de P4 englobe le
prédicat de P3 le score de t3 est 0.5 parce que l’utilisateur a attribué le score 0.9 pour film de
Drama et le score 0.5 pour film de Drama et réalisateur Spielberg.
7. Conclusion :
Au cours de ce chapitre, nous avons vu que le processus de personnalisation n’a pas été
beaucoup traité dans les bases de données multidimensionnelles (les entrepôts de données). Au
cours de notre étude bibliographique, nous avons pu trouver quelques travaux traitant la
personnalisation de requêtes dans le domaine des entrepôts de données sur lesquels nous avons
présentés une synthèse sur :
Des langages de préférences à travers les critères, tels que la relation de préférence
utilisée pour représenter des préférences utilisateur, quels sont les éléments d’un cube de
données sur lesquels un utilisateur peut exprimer ses préférences, quelles sont les combinaisons
possibles de préférences, etc.
Des méthodes de personnalisation à travers des critères, tels que comme le type de la
personnalisation, sur quoi porte la personnalisation (objet de la personnalisation), etc.
Dans les bases de données multidimensionnelles, les méthodes proposées personnalisent le
contenu de l’information retournée à l’utilisateur et se sont intéressées peut à la présentation. Ces
méthodes se sont concentrées sur un objectif principal et qui est celui de fournir rapidement
l’information pertinente qui intéresse l’utilisateur en tenant compte de sont profil.
La personnalisation de requêtes et leurs réutilisations dans les bases de données
multidimensionnelles nécessitent la prise en compte de ses particularités comme la difficulté
d’explorer la masse d’information en raison de la structure complexe des données
multidimensionnelles (hiérarchie, niveaux, etc.).
Notons que les travaux étudiés proposent de personnaliser le contenu de l’information en
satisfaisant les contraintes de présentation. Leur objectif est de permettre à l’utilisateur de
trouver l’information pertinente et lui faciliter son exploration. Ces approches nous ont permis
d’opter pour une approche hybride basée sur leur combinaison, telle que celles proposées dans
[BELLETRECHE et AL, 2005], [BELLETRECHE et AL, 2006], [MOULOUDI et AL,
2005] et [PITOURA et STEFANIDIS, 2002] pour la personnalisation des requêtes OLAP qui
porte sur le contenu et la présentation et [CHOONG et AL 2007] pour leurs réutilisations.
49
Chapitre 3
La personnalisation des données
Il faut signaler que ce domaine (la personnalisation dans les entrepôts de données) est
encore au stade de recherche. De ce fait, il résulte un manque de démarches de conception
complètes qui traitent de toutes les étapes de conception.
50
Chapitre 4
Conception et implémentation
1. Introduction
Les systèmes OLAP permettent aux utilisateurs de naviguer dans l’entrepôt de données,
dans le but d’extraire des informations utiles qui vont les aider dans la prise de décisions lors de
leurs analyses. Ces systèmes ont connus un développement important grâce à leurs capacités à
permettre un accès direct et dynamique aux données analysées. Cependant ils sont élaborés pour
un groupe de décideurs ou un sujet d’analyse pour lesquels sont présumés des besoins
parfaitement identiques.
Mais, ces systèmes sont limités et ils ne peuvent pas prendre en compte les centres
d’intérêt, les préférences et le contexte des requêtes de chaque utilisateur, ce qui rend les
analyses difficile et lentes.
L’extraction des informations pertinentes dans un important volume de données pose un
quelques problèmes tels que :
•
•
•
•
•
La taille des réponses est souvent volumineuse ce qui embrouille les utilisateurs lors de
l’exploration.
La qualité de l’information délivrée n’est pas prise en compte, ce qui laisse l’utilisateur
souvent embarrassé quant à son utilité et rend difficile la prise de décision à base de cette
information.
La présentation des résultats n’est pas prise en compte, ce qui ne répond pas aux attentes
de l’utilisateur (présentation unique pour tous les utilisateurs). L’utilisateur doit naviguer
dans la présentation espérant de trouver l’information pertinentes.
La pertinence des résultats se réduit parfois dans la mesure où ils ne sont pas adaptés ni
aux contextes ni aux préférences utilisateurs. Autrement, les résultats fournis ne sont pas
adéquats avec le matériel utilisé (le dispositif de l’interaction, PDA, …).
L’organisation et le partages des analyses ne sont pas pris en compte, et entrain de poser
plusieurs requêtes pour trouver ce qui l’intéresse.
Pour cela, et afin d’apporter des réponses satisfaisantes à ces problèmes ont se vois
obliger d’utiliser des outils de personnalisation de l’information peut. Et cela, en fournissant un
ensemble réduit de réponses intéressantes répondent aux besoins attendus de l’utilisateur.
L’objectif de La personnalisation est de faciliter l’expression des besoins de l’utilisateur
afin de ne lui retenir que les informations qualifiées pertinentes pour un sujet donné en écartant
ceux non pertinentes.
Cependant, cette pertinence est définit par un ensemble de critères et de préférences
personnalisables et spécifiques à chaque utilisateur ou communauté d’utilisateurs et stockés dans
une structure appelée Profil Utilisateur.
Les exigences d’analyses décisionnelles face à l’éclatement du volume de données
manipulées donne lieu à la mise en place des nouveaux concepts tels que Data Warhouses et
OLAP qui sont rangés dans une nouvelle classe de bases de données dites multidimensionnelles
et qui n’a pas bénéficier parfaitement de la personnalisation en raison de sa fraîcheur et surtout
sa particularité, on a étudier dans les chapitres précédents, les progrès brillants achevés dans ce
champ de recherche.
52
Chapitre 4
Conception et implémentation
Après avoir exploré la personnalisation dans les entrepôts des données et les travaux
brillants contribuant à l’avancement des recherches dans cet axe, on va proposer comme
contribution un algorithme pour la génération de l’ensemble de toutes les formes d’affichage
possibles que peut prendre le résultat d’exécution d’une requête MDX.
Nous présenterons dans ce chapitre notre algorithme « STRUCTURATION » qui génère
les différentes structures possibles pour un ensemble des références d’une requête MDX et
respectent le contraint de visualisation VT,G., Cet algorithme est basé sur les travaux de
[Bellatrech et al,2006] qui donne la possibilité de supporté la discrimination entre plusieurs
ensembles de références en simplifiant le choix de l’utilisateur pour une structure parmi un
ensemble proposé.
Tous d’abord, on va présenter l’algorithme de [Bellatrech et al.2005] concernant la
détermination pour un ensemble de références s’il existe une structure pour sa visualisation ou
non.
2. L’algorithme FindStruct [Bellatrech et al.2005]
Concernant la structure S*, [Bellatrech et al.2005] utilise un algorithme appelé
FindStruct dont le rôle est de calculer une structure S* pour le cube C* si elle existe. Cet
algorithme est montré dans la fig.17.
Étant donné un cube C et une contrainte de visualisation v, cet algorithme examine si v peut être
satisfaite, c.-à-d. s’il existe une structure S tels que v(C,S)=true. Ce problème est considéré par
[Bellatreche et al, 2005] comme un problème NP-complet.
FIG .17 - l’algorithme FindStruct [Bellatreche et al, 2005]
53
Chapitre 4
Conception et implémentation
Etant donner VT,G une contrainte de visualisation dans V* avec T = {T1, T2} et
G ={G1,G2}. Cet algorithme teste si l’existe une structure S de C tels que VT,G(C, S)=true (basé
sur la programmation dynamique). Au départ, l’algorithme calcule l'ensemble D’={Di1,..,DiM}
des dimensions qui doivent être placées sur les axes visibles. Puis, il est clair que la cellule
t’[k][j] de tableau t’ est différent de null ( à la mième itération (1≤m≤M) de la boucle principale
« voir les étapes 6 à 16 »)s’il 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 représenter l’un de la partition {S1,S2} de D’ satisfait la
contrainte, c.à.d. S1=t’[k][j] et S2=Em\S1.
Exemple :
Dans le contexte de l’exemple précédent, supposons qu’on 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 s’il existe une structure S*
telque VT,G(C*,S*)= true quand T=<∅,∅> et G=<4,4>. Au départ, on a K1=4 et K2=K3=2.
D'ailleurs, puisque T1=T2=∅, nous avons
G’1=G’2=1 et t[1][1]=∅. Les autres cellules de t sont initialisées à null.
Finalement, nous avons D’={D*1,D*2,D*3}.
A la première itération de la boucle principale, supposons Di=D*1.
Dés que t[1][1]= ∅, et 1*K1= 4≤4, on obtient t’[4][1]={D*1} et t’[1][4] = ∅.
A la deuxième itération, Di=D*2. Dés que t[4][1]={D*1} et 1*K=2≤4, on obtient
t’[4][2]={D*1}.Dés que t[1][4] = ∅, et 1*K=2≤4, on obtient également t’[2][4]={D*2}.
A la troisième et dernière itération, Di=D*3. Quand t[4][2] = {D*1} et 2*K=3≤4, on
obtient t’[4][4] = {D*1}. Dés 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 dernière stockée).
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.
3. L’algorithme STRUCTURATION
Le principe de l’algorithme STRUCTURATION est de construire au départ l’ensemble de
toutes les structures possibles de l’ensemble des dimensions sélectionnées pour une requête
MDX en respectant la contrainte de visualisation VT,G et sans prendre en considération
l’ensemble ou le sous ensemble des références à examiné. Lorsque cet ensemble des structures
est généré, l’ensemble ou le sous ensemble de références est utilisé pour éliminer de cet
ensemble des structure celles qui ne respecte pas la contrainte de visualisation VT,G .
L’algorithme STUCTURATION consiste en une fonction qui utilise d’autres fonctions tel
que : PUT_DIMS_ON_AXIS, Next_Set_Comb, To_One_Set et Duplicate_Set.
54
Chapitre 4
Conception et implémentation
La définition de ces fonctions est comme suit :
Function Next_Set_Comb( SET )
Input :
SET, A set of subsets of two subesuets.
subsets SET = {S / S={x1,x2} and x1∩x2 = Φ }
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. For every e ∈ x2 do
4. Let S2 = {x3,x4} such that x3 = x1U e
5. x4 = x2
6. Remove e from x4
7. If For every S’ of Next_Set S’ != S2 then Insert S2 in Next_Set
8. Return Next_Set
Function PUT_DIMS_ON_AXIS (Dims_Set, Axis_One, Axis_Two)
Input :
Dims_Set, A set of selected dimensions (from the user query);
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 S1∩S2 = Φ and
Axis_One ⊆ S1 and Axis_Two ⊆ S2
1. Let Str1 = {}
2. Let Str2 = {}
3. For every dim ∈ Dims_Set do
4. If dim ∈ Axis_One then Str1 = Str1U dim
5. Remove dim from Dims_Set
6. else If dim ∈ Axis_Two then Str2 = Str2 U dim
7. Remove dim from Dims_Set
8. Let k is the number of all possible two subsets {x1,x2}of the elements of Dims_Set such that:
k = Dims_Set.size() Div 2 and x1∩x2 = Φ.
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. AXI[i] = Next_Set_Comb(AXI[i-1])
55
Chapitre 4
Conception et implémentation
13. i = i +1
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. S1 = S1 U Axis_One
19. S2 = S2 U Axis_Two
20. Return Axis_Set
Function To_One_Set(SET)
Input :
SET, a set of subsets of two subesuets
subsets such that :
SET = {S / S = {S1 /S1={x1,x2} and x1∩x2 = Φ }}
Output :
One_SET, A set of subsets of two subesuets
subsets such that :
One_Set = {S / S={x1,x2} and x1∩x2 = Φ }
1. Let One_Set = {}
2. For every S of SET do
3. For every S1={x1,x2} of S do
4. Insert S1 in One_Set
5. Return One_Set
Function Duplicate_Set(SET)
Input :
SET, A set of subsets of two subesuets
subsets such that :
SET = {S / S={x1,x2} and x1∩x2 = Φ }
Output :
Duplicated_SET, A set of subsets of two subesuets
subsets such that :
Duplicated_Set = {S / S={x1,x2} and x1∩x2 = Φ }
1. Let Duplicated_SET = {}
2. For every S={x1,x2} of SET do
3. Insert S in Duplicated_Set
4. If {x2,x1} not in Duplicated_Set then Insert {x2,x1} in Duplicated_Set
5. Return Duplicated_Set
56
Chapitre 4
Conception et implémentation
Function STRUCTURATION (Selected_Dims_Set, Ref_Set)
Input :
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. Let gr1 = grad(ax1) // grad(ax1) is calculated for the references set Ref_Set
5. Let gr2 = grad(ax2) // grad(ax1) is calculated for the references set Ref_Set
6. If gr1<=Grad_1 and gr2<=Grad_2 then
7. Insert S in Structures_Set
8. Return Structures.
Exemple descriptif
Soit Sel_Dims l’ensemble des dimensions sélectionnées par l’utilisateur, et Axis_1 et
Axi_2 deux ensembles des dimensions que l’utilisateur 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 l’ensemble de références suivant :
REF = {( Food,1998, Orléans,Unite Sales);
(Drink,1997,Tours,Unite Sales);
(Drink,1997,Orléans,Unite Sales);
(Cloth,1997,Orléans,Unite Sales);
(Cloth,1998,Tours,Unite Sales);
(Drink,1998,Orléans,Unite Sales);
(Food,1997,Orléans,Unite Sales);
(Food,1997,Tours,Unite Sales) };
La première étape de fonction STRUCTURATION consiste à trouver les différentes
affectations possibles pour les dimensions sélectionnées en utilisant la fonction
Put_Axis_On_Dims().
57
Chapitre 4
Conception et implémentation
Cette dernière fonctionne comme suit :
En entrée : Sel_Dims , Axi_1 et Axi_2.
Str1 = {}
Str2 = {}
En exécutant 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 l’étape 8 de la fonction Put_Dims_On_Axis, k = 2 Div 2 = 1
A l’étape 9 de la fonction Put_Dims_On_Axis, AXI = {{S1,S2}} tel que :
S1={} et S2 = {Location,Measures}
A l’étape 10 de la fonction Put_Dims_On_Axis, i = 1
A l’étape 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 l’étape 12 de la
fonction Put_Dims_On_Axis on :
AXI[1] = Next_Set_Comb(AXI[0])
Le déroulement de la fonction Next_Set_Comb(AXI[0]) sera comme suit :
Au départ Next_Set = {}
A la deuxième étape de cette fonction et lorsque AXI[0] comporte qu’une seule sous
ensemble de deux ensemble, alors la boucle for sera exécutée un seule fois tel que :
S = {{}{ Location,Measures }}
A l’étape 3, et pour e = Location on a :
à l’étape 4 : S2 = {x3,x4} tel que x3 = {}U {Location}
à l’étape 5 : x4 = {Location,Measures}
à l’étape 6 : x4 = {Measures}
A l’étape 7 et puisque dans Next_Set n’existe pas un sous ensemble équivalent a
S2 alors S2 va être inséré dans Next_Set.
A l’étape 3, et pour e = Measures on a :
à l’étape 4 : S2 = {x3,x4} tel que x3 = {}U Measures
à l’étape 5 : x4 = {Location,Measures}
à l’étape 6 : x4 = {Location}
A l’étape 7 et puisque dans Next_Set = {{{{Location},{Measures}}}} n’existe
pas un sous ensemble equivalent a S2 = {{Measures},{Location}} alors S2 va être inséré dans
Next_Set.
A la dernière étape de la fonction Next_Comb l’ensemble retourné par cette fonction est
Next_Set tel que :
Next_Set = {{{{Location},{Measures}},
{{Measures},{Location}}}} et la fin de la fonction Next_Comb.
A l’étape 13 de la fonction Put_Dims_On_Axis on a :
i = 1+1 = 2, et puisque k+1 = 2 = i alors la boucle WHILE s’arrête.
A l’étape 15 de la fonction Put_Dims_On_Axis, on a Axis_set retourne le résultat d’exécution de
To_One_Set({{{{Location},{Measures}},{{Measures},{Location}}}})
Le déroulement de To_One_Set sera comme suit :
A son premier étape, One_Set = {}
Au second :
pour S = {{{},{Location,Measures}}} de
SET={{{{},{Location,Measures}}},
{{{Location},{Measures}},{{Measures},{Location}}}}
Au troisième, pour S1 = {{},{Location,Measures}} de S on a :
Au quatrième, One_Set = {{{},{Location,Measures}}}
58
Chapitre 4
Conception et implémentation
pour S = {{{Location},{Measures}},{{Measures},{Location}}} de
SET={{{{},{Location, Measures}}},
{{{Location},{Measures}},{{Measures},{Location}}}} on a :
Au troisième, pour S1 = {{Location},{Measures}} de S on a :
Au quatrième, One_Set = {{{},{Location,Measures}},
{{Location},{Measures}}}} et pour S1 = {{Measures},{Location}} de S on a :
Au quatrième,
One_Set = {{{},{Location,Measures}},
{{Location},{Measures}},
{{Measures},{Location}}}
Au cinquième, la fonction To_One_Set retourne l’ensemble One_Set.
A l’étape 16 de la fonction Put_Dims_On_Axis, on a
Axis_Set = Duplicate_Set(Axis_Set)
Le déroulement de la fonction Duplicate_Set est très simple et donne le résultat suivant :
Axis_Set = { {{},{Location,Measures}},
{{Location},{Measures}},
{{Measures},{Location}},
{{Location,Measures},{}}}
De l’étape 17 à 19 de la fonction Put_Dims_On_Axis, pour chaque sous
ensemble S = {S1,S2} de Axis_Set ajouter les éléments de Str1 à S1 et ceux de
Str2 à S2. à la fin de la boucle Axis_Set devient :
Axis_Set = { {{Product},{Time,Location,Measures}},
{{Product, Location},{Time, Measures}},
{{Product, Measures},{Time, Location}},
{{Product, Location, Measures},{Time}}}
Et à l’étape finale, la fonction Put_Dims_On_Axis retourne Axis_Set qui contient les
différentes structures possibles pour la requête de l’utilisateur.
A la seconde étape de la fonction STRUCTURATION on a
Structures_Set = {}
De l’étape 3 à 7, la fonction STRUCTURATION et d’après l’ensemble des références
Ref_Set va calculer pour chaque ensemble S = {ax1, ax2} de Dims_On_Axis grad(ax1) le
nombre de graduation pour l’ensemble ax1 et grad(ax2) le nombre de graduation pour
l’ensemble ax2 et les comparer avec respectivement Grad_1 et Grad_2 les graduations fixées par
l’utilisateur dans ses contraintes de visualisation. Si grad(ax1) et grad(ax2) ne dépassent 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 ={{Product, Location},{Time, Measures}}
grad({Product, Location}) = 3x2 = 6 > Grad_1
grad({Time, Measures}) = 2x1 = 2 < Grad_2
S = {{Product, Measures},{Time, Location}}
grad({Product, Measures}) = 3x1 = 3 < Grad_1
grad({Time, Location}) = 2x2 = 44 = Grad_2
59
Chapitre 4
Conception et implémentation
S = {{Product, Location, Measures},{Time}}
grad({Product, Location, Measures}) = 3x2x1 = 6 > Grad_1
grad({Time}) = 2 < Grad_2
À la fin de fonction STRUCTURATION, l’ensemble des structures retournées est :
Structures_Set = {{{Product},{Time,Location,Measures}},
{{Product, Measures},{Time, Location}}}
4. Discrimination entre plusieurs ensembles de références
Le résultat obtenu par l’utilisation de l’algorithme de personnalisation PersoVisu de
[Bellatrech,2006] est atteint sans accès au cube de données et peut comporte plus d’un sous
ensemble des références personnalisés d’après le profil de l’utilisateur. Mais ce dernier a
l’ambition de choisir parmi cet ensemble que les sous ensembles qui mènent à des résultats
complets ou au moins à des résultats qui ne correspondent pas à des données éparses (lorsqu’un
grand nombre de cellules d’un cube de données sont vides, on parle alors de données éparses).
Basant sur ce problème de données éparses qui peuvent figurer dans le cube de données choisi, le
nombre des sous ensembles des références peut être diminué si on sélectionne parmi cet
ensemble que les sous ensembles des références qui renvoi un pourcentage minime pour le
nombre des cellules vides par rapport au nombre total des cellules dans le cube de données
choisi.
Il est clair que cette optimisation nécessite des accès aux données du cube pour retourner pour
chaque sous ensemble de références le nombre des cellules non vides (utilisant l’opérateur
COUNT).
L’efficacité d’une telle optimisation est assurée lorsqu’il existe parmi les sous ensembles de
références des sous ensembles comportant des cellules vides ou représentant des données
éparses.
Cette optimisation est supportée par notre prototype à travers l’option «discrimination »
qui va offrir à l’utilisateur la possibilité de filtrer l’ensemble des sous ensembles des références
pour qu’on garde que ceux qui répondent au critère défini par cette optimisation.
5. Simplification de choix de l’utilisateur pour une structure parmi
un ensemble
D’après notre algorithme STUCTURATION conçu pour la génération de l’ensemble de
toutes les structures possibles pour un ensemble des références, il existe des structures où la
totalité ou la plupart des dimensions sélectionnées sont placées sur un seul axe, ou bien des
structures où la différence entre le nombre de graduations sur les deux axes est considérable.
Ainsi, la majorité des assistants personnels PDA, SmartPhone (téléphone intelligent : un
téléphone mobile couplé à un PDA) ou les téléphones mobiles disposent des écrans d’une forme
carrée. Cette caractéristique peut nous conduit à introduire une nouvelle définition concernant la
visualisation des résultats d’exécution des requêtes OLAP sur ces appareils. Cette définition
qualifier une visualisation d’être la meilleure si elle est réalisée par une structure où la différence
entre le nombre de graduations sur ses deux axes est minime. Il est possible d’utiliser un seuil
afin contrôler cette différence entre le nombre des graduations sur les deux axes d’une structure.
Le seuil peut aider l’utilisateur à justifier ses visualisations.
60
Chapitre 4
Conception et implémentation
L’utilisateur de notre prototype Personnalisation peut bénéficier de cette optimisation
pour éliminer toutes les structures qui ne représentent pas des meilleures visualisations pour leurs
cubes sélectionnés.
Exemple :
Soit Dims un ensemble de dimensions d’une requête 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.
Soit quelques structures parmi celles proposées à l’utilisateur 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 désigne par DiffDim la difference de nombre des dimensions entre deux axes d’une
structure, et Diffgrad sa différence 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) = │(3×2×2×1)– 0│ = 12
Diffgrad(S2) = │0 - (3×2×2×1)│= 12
Diffgrad(S3) = │(3×2×2) – 1│= 11
Diffgrad(S4) = │1 - (3×2×2)│= 11
Diffgrad(S5) = │(3×2) – (2×1)│= 4
Diffgrad(S6) = │3 – (2×2×1)│= 1
Diffgrad(S7) = │(2×2×1)– 3│= 1
Diffgrad(S8) = │2 - (3×2×1)│= 4
Diffgrad(S9) = │(3×2×1) – 2│= 4
Diffgrad(S10) = │(2×2) – (3×1)│ = 1
Diffgrad(S11) = │(3×2) – (2×1)│= 4
Diffgrad(S12) = │(2×1) – (3×1)│= 1
D’après notre définition pour la meilleure visualisation, les structures qui seront
sélectionnées sont :
61
Chapitre 4
Conception et implémentation
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 sélectionnées 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
6. Implementation
6.1 Prototype ’Personnalisation’
Nous avons présentés précédemment des algorithmes de personnalisation des requêtes
OLAP, dans ce chapitre, on a pour objectif de montrer et discuter une application développé
Peronnalisation qui implémente ces algorithmes de personnalisation. Cette application consiste
en une simulation java s’exécutant sur un terminal pervasif d’un utilisateur.
Le schéma suivant décrit le principe de base pour le fonctionnement de notre système de
personnalisation :
1 : Pseudo + mot de passe
2 : Profil d’utilisateur + Requêtes MDX
(personnalisées et non personnalisées).
3 : Exécution d’une requête MDX
(personnalisée ou non personnalisée) .
4 : Résultat du l’opération 3.
FIG.18 : Architecteur de système « Personnalisation »
62
Chapitre 4
Conception et implémentation
6.2 Technologies employées
Le schéma montre plusieurs technologies participées dans la réalisation de ce système tel
que :
Oracle :
- Serveur OLAP : Il fait partie de la catégorie des serveurs R-OLAP, c'est-à-dire qu'il
accède à des données contenues dans une base relationnelle, dont on peut exécuter des
requêtes utilisant le langage MDX, également utilisé dans
-
SQL Server : Ce langage permet de créer des requêtes dont l’équivalent en langue SQL
nécessiterait un grand nombre de requêtes et des temps d’exécution beaucoup plus longs.
Ce serveur est le plus souvent utilisé conjointement avec JPivot ou JRubik, outils qui
proposent une interface graphique de consultation et manipulation des données.
Tomcat : Issu du projet Jakarta, Tomcat est désormais un projet principal de la fondation
Apache. Tomcat implémente les spécifications 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
considéré comme un serveur HTTP.
Tomcat a été écrit en langage Java, il peut donc s'exécuter via la JVM (machine
virtuelle java) sur n'importe quel système d'exploitation la supportant.
Easyphp : fut le premier package WAMP à voir le jour (1999). Il s'agit d'une plateforme de
développement 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 web Apache et un serveur de bases de données MySQL),
un interpréteur de script (PHP), ainsi qu'une administration SQL phpMyAdmin. Il dispose d'une
interface d'administration permettant de gérer les alias (dossiers virtuels disponibles sous
Apache), et le démarrage/arrêt des serveurs. Il permet donc d'installer en une seule fois tout le
nécessaire au développement local du PHP. Par défaut, le serveur Apache crée 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.
Java : Apparu en 1991, le langage JAVA a commencé à être intéressant à partir de 1995 avec sa
prise en charge par le navigateur phare de l'époque, Netscape. Ce langage ne cesse de se
développer. Il s'agit d'un langage orienté objet dont la syntaxe est très proche de celle du C++.
C'est également un langage portable, c'est à dire qu'il s'adapte à une foule de plate-formes
différentes. C'est là l'une des qualités de JAVA.
6.3 Principe de base de l’application « personnalisation »
Le système est composé de l’application Personnalisation et les différents serveurs.
L’application est composée à son tour de deux parties, l’interface utilisateur qui lui permet
d’interagir avec le système et le noyau qui effectue les diverses opérations concernant le
processus de personnalisation.
63
Chapitre 4
Conception et implémentation
Les serveurs employés dans ce système sont :
• Serveur de base de données utilisant le SGBD MySql d’EasyPHP pour stocker la
base de données des profils utilisateur.
• Serveur de base de données utilisant le SGBD MySql pour stocker les données de
l’entrepôt de données.
• Serveur OLAP d’oracle : Ce serveur est chargé d’exécuter des requêtes de type MDX
sur l’entrepôt de données.
Pour naviguer sur notre système « personnalisation », un utilisateur doit avoir un compte sur ce
système. Le compte utilisateur représente son profile.
Pour ouvrir une session sur ce système, l’utilisateur introduit son nom d’utilisateur et son mot de
passe. Si l’authentification à réussite, l’utilisateur reçoit depuis le serveur de base de données
contenant la base de données des profils utilisateur ses préférences, ses contraintes de
visualisations et ses requêtes MDX personnalisées et non personnalisées.
L’interface graphique de l’utilisateur lui a permet de construire de nouvelles requêtes ou
d’utiliser celles déjà crées. L’utilisateur a la possibilité de faire une discrimination entre
l’ensemble des requêtes personnalisées pour diminuer leur nombre. Cette opération nécessite
l’utilisation pour chacune d’elles une requêtes MDX qui renvoi leurs nombres des cellules non
vides. Pour exécuter ces requêtes, une connexion est établit vers le serveur OLAP. Ce dernier
exécute les requêtes et récupère les résultats en interrogeant l’entrepôt de données sur le serveur
de base de données utilisant le SGBD MySql et envoi ces résultats a l’utilisateur. Après la
sélection d’une requête et une structure pour cette dernière, l’utilisateur peut procéder a
l’exécution de cette requête personnalisée. Cette requête est envoyée sur le serveur OLAP. Ce
dernier interroge l’entrepôt de données à nouveau pour obtenir le résultat de l’exécution puis il
formate le résultat en table croisée avec des cellules et leurs coordonnés avant de l’acheminer
vers l’utilisateur.
6.4 Présentation de l’application
La base de données des profils utilisateur (Foodmart)
Stockée sur le serveur de base de données qui emploi le SGBD MySql d’EasyPHP. Cette base
de données stocke les informations concernant chaque utilisateur et elle comporte 21 tables qui
sont:
Tables
Axisone
Axistwo
Cube
Dimbetter
Dimensions
Dimless
Graduation
Levbetter
Description
stocke pour chaque utilisateur les dimensions qu’il souhaite voir sur
l’axe numéro un.
stocke pour chaque utilisateur les dimensions qu’il souhaite voir sur
l’axe numéro deux.
stocke les différents cubes.
stocke pour une dimension, les dimensions qui sont plus préférées par
un utilisateur que cette dimension.
stocke les dimensions de l’entrepôt de données.
stocke pour une dimension, les dimensions qui sont moins préférées
par un utilisateur que cette dimension.
stocke pour chaque utilisateur la graduation choisit.
stocke pour un niveau d’une dimension, les niveaux qui sont plus
préférées par un utilisateur que ce niveau.
64
Chapitre 4
Levels
Levless
Members
Pers_query
Pers_query_from
Pers_query_select
Pers_query_where
Prefmembers
Query
Query_from
Query_select
Query_where
Users
Conception et implémentation
stocke pour un niveau d’une dimension, les niveaux qui sont plus
préférées par un utilisateur que ce niveau.
stocke pour un niveau d’une dimension, les niveaux qui sont moins
préférées par un utilisateur que ce niveau.
stocke les membres de chaque niveau de chaque dimension de
l’entrepôt.
stocke les noms des requêtes personnalisées.
stocke les cubes utilisés par chaque requête personnalisée.
stocke les dimensions, les niveaux et les membres constituants la
clause «SELECT» d’une requête personnalisée.
stocke les dimensions, les niveaux et les membres constituants la
clause «WHERE» d’une requête personnalisée.
stocke pour un niveau d’une dimension les membres préférés par
l’utilisateur. Ces membres sont ordonnés.
stocke les noms des requêtes non personnalisées.
stocke les cubes utilisés par chaque requête non personnalisée.
stocke les dimensions, les niveaux et les membres constituants la
clause «SELECT» d’une requête non personnalisée
stocke les dimensions, les niveaux et les membres constituants la
clause «WHERE» d’une requête non personnalisée.
stocke pour chaque utilisateur son nom et son mot de passe.
L’entrepôt de données
Les données de cet entrepôt (base de données de teste FoodMart) sont stockés sur le serveur de
base de données utilisant le SGBD MySql, avec l’ensemble des tables de dimensions suivant :
Tables
Customers
Education Level
Gender
Marital Statuss
Product
Promotion media
Promotions
Store
Time
Yearly Income
Measures
Description
stocke les informations concernant les clients.
stocke le niveau d’éducation pour chaque client.
le sexe de client, male ou female.
stocke la situation marital pour chaque client «S» : célibataire ou «M» :
marié.
stocke les produits a vendre dans FoodMart.
stocke les medias utilisées pour une promotion, tel que : les journaux,
la tv ou le radio.
identifier la promotion qui a déclenchée le vente.
stocke la localisation de différentes stockes (dépôts) dans la chaîne
(pays, état, cité).
stocke pour chaque vente, la période quand le vente était déclenché.
stocke les revenues de chaque client.
cette table contient plusieurs mesures tel que :
• Unit Sales : nombre d'unités vendues.
• Store Cost : coût de marchandises vendues.
• Store Sales : valeur des transactions de ventes.
• Sales Count : nombre des transactions de ventes.
Les données de l’entrepôt sont interrogées indirectement par le système. Par le baie d’un serveur
OLAP destinée a l’exécution des requêtes MDX sur les données d’un entrepôt de données et le
formatage des résultats sous forme d’une table croisée.
65
Chapitre 4
Conception et implémentation
L’interface utilisateur:
Elle comporte l’ensemble des différentes fenêtres qui permet à un utilisateur de :
- L’authentifier : Chaque utilisateur a son propre nom d’utilisateur et mot de passe pour
naviguer sur ce système.
- Définition et modification des préférences : Ces préférences représentent
l’ordonnancement choisi par l’utilisateur sur l’ensemble des dimensions de cube de
données, ainsi que sur les niveaux des dimensions et bien sur, un autre ordonnancement
concerne les membres des niveaux. Cet ordonnancement est partiel, autrement dis que
l’utilisateur n’est 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, l’utilisateur peut spécifier quelques contraintes concernant la
forme que doit prendre un résultat sur l’écran de son mobile. Ces contraintes permettent à
l’utilisateur de désigner un ensemble de dimensions qu’il souhaite voir toujours sur le premier
axe et un autre ensemble sur le second. Ainsi, l’utilisateur peut indiquer le nombre maximal des
membres que doit comporter chaque axe, on parle de nombre de graduation pour chaque axe.
- Parcours des requêtes prédéfinies : Ces requêtes sont soient personnalisées ou non, et
sont stockées sur son profil. L’utilisateur peut effectuer les différentes opérations offertes
sur ses requêtes tel que :
• l’édition d’une requête non personnalisée afin de la modifier,
• le changement du nom d’une requête,
• la suppression d’une requête,
• la personnalisation d’une requête non personnalisée,
• l’exécution d’une requête personnalisée.
- Construction d’une nouvelle requête: C’est l’interface qui aide l’utilisateur à
construire une nouvelle requête en passant par les étapes suivantes :
• Sélection de cube.
• Sélection de l’ensemble des dimensions pour la clause «SELECT».
• Sélection pour chaque dimension sélectionnée dans l’étape précédente, un ensemble des
niveaux.
• Sélection pour chaque niveau sélectionné dans l’étape précédente, un ensemble des
membres.
• Sélection de l’ensemble des dimensions pour la clause «WHERE». Cet ensemble doit
être différent de celle de la clause «SELECT».
• Sélection pour chaque dimension sélectionnée dans l’étape précédente, un niveau et un
membre. (cette étape aura lieu si l’utilisateur a choisi dans l’étape précédente au moins
une dimension).
• La sauvegarde de la requête générée sur le profile de l’utilisateur sous un nom bien
défini.
- personnalisation d’une requête non personnalisée ou l’exécution d’une autre
personnalisée: Ces requêtes sont soient des requêtes générées nouvellement ou des
requêtes de l’ensemble stockées sur le profil utilisateur.
Le résultat de la personnalisation d’une requête non personnalisée peut contenir plus
d’une requête personnalisée due à l’utilisation de l’ordre partiel. Dans ce cas, l’utilisateur
peut utiliser la discrimination entre les requêtes résultantes afin de réduire leur nombre si
66
Chapitre 4
Conception et implémentation
possible. Pour une requête personnalisée sélectionnée, l’utilisateur doit choisir une
structure parmi les différentes structures proposées. Ainsi, l’utilisateur a aussi la
possibilité de faire une réduction de nombre des structures proposées pour la requête
personnalisée sélectionnée (si possible bien sur).
Et après le choix de la structure, l’utilisateur peut faire :
• La sauvegarde de la requête personnalisée sur le profil de l’utilisateur sous un nom bien
défini.
• L’exécution de la requête personnalisée afin d’afficher le résultat.
Noyau :
Cette partie se cache derrière l’interface de l’application, ce qui rend son fonctionnement
transparent à l’utilisateur. On distingue deux rôles pour cette partie, le premier concerne tout ce
qui est lié à l’utilisateur et la gestion de son profil, tandis que le second garantit la meilleure
gestion de trafic avec le serveur des requêtes MDX Oracle.
C’est grâce noyau que le système gère toutes les interactions de l’utilisateur avec son interface
graphique pour :
• l’interrogation du serveur MySql d’EasyPhp pour la récupération des données
concernant l’utilisateur depuis son profil, ou leur mettre à jour, ou même pour l’insertion
d’autres (par exemple lorsque l’utilisateur ajoute des nouvelles préférences à son profil
ou sauvegarde des nouvelles requêtes personnalisées ou non personnalisées).
• Personnalisation d’une requête en utilisant l’algorithme choisi pour cette opération
selon les étapes suivantes :
- L’extraction de l’ensemble des dimensions utilisées dans la requête.
- L’extraction de l’ensemble des références de la requête.
- La construction de l’ensemble de différentes structures possibles pour l’ensemble des
dimensions extraites sans prendre en compte l’ensemble de références extraites.
- L’application de l’algorithme de personnalisation décrit précédemment (utilisant les
préférences utilisateur et ses contraintes de visualisations).
- Due à la nature partielle de l’ordre employé par l’algorithme de personnalisation, le
résultat peut admettre plus d’une requête personnalisée (le résultat consiste à un ensemble
des sous ensembles des références). C’est là où on peut voir l’impact de notre
contribution qui consiste à réduire le nombre de ces requêtes par le principe de
discrimination. Dans ce cas, le système est obligé d’interroger la base de données
FoodMart qui se trouve sur le second serveur de base de données MySql avec
l’intermédiaire de Serveur OLAP).
- Pour un sous ensemble sélectionné des références, le système construit l’ensemble des
structures appropriées pour ces références en utilisant dans cette opération l’ensemble de
toutes les structures possibles pour l’ensemble des dimensions de la requête généré dans
l’étape 3, et les contraintes de visualisations depuis le profil utilisateur.
- Parmi les structures de l’ensemble généré dans l’étape 6, en peut distinguer des
structures où la totalité ou la plupart des dimensions sont affectées sur un seul axe.
Et d’après notre proposition, le système peut donner une suggestion pour éliminer ces
structures et ne garder que les structures qui ont la moindre différence entre le nombre
des dimensions affectées sur chaque un des ses deux axes.
- Pour un sous ensemble des références sélectionné et une structure parmi l’ensemble
proposé, le système génère la requête MDX personnalisée.
• Interroger l’entrepôt de données pour exécuter une requête MDX et récupérer le résultat
afin de l’afficher.
67
Chapitre 4
Conception et implémentation
6.5 Quelques fenêtres de prototype
Menu principal
Choix de l’ensemble
des
membres préférés
pour un niveau d’une
dimension.
L’ordonnancement
entre les membres
préférés d’un niveau
d’une dimension.
Menu de contraintes
de
visualisation.
L’ordonnancement
entre
les niveaux d’une
dimension.
Menu des requêtes
non
personnalisées
stockées sur le profil
utilisateur.
Renommer ou
Sélection de cube
exécuter une requête
utilisé pour la requête.
personnalisée
prédéfinie (enregistrée
sur le profil).
68
Chapitre 4
Conception et implémentation
Sélection des
dimensions que
l’utilisateur souhaite
voir sur le premier
axe.
Sélection des
dimensions que
l’utilisateur souhaite
voir sur le second axe.
Le nombre de
graduations
maximales pour
chaque axe
Menu des requêtes
non
personnalisées
stockées sur le profil
utilisateur.
Renommer ou
personnaliser une
requête non
personnalisée
prédéfinie
(enregistrée sur le
profil).
Une requête
personnalisée peut
admettre plusieurs
structures
d’affichages.
La requête
personnalisée de la
requête générée.
La requête
personnalisée
générée (selon la
structure choisie).
69
Chapitre 4
Conception et implémentation
Sélection de
l’ensemble des
dimensions pour la
clause «SELECT».
Sélection de
l’ensemble des
niveaux pour chaque
dimension
sélectionnée pour la
clause «SELECT».
Sélection de
l’ensemble des
membres pour chaque
niveau sélectionné de
chaque dimension
sélectionnée pour la
clause «SELECT».
Sélection de
l’ensemble des
dimensions pour la
clause «WHERE».
Sélectionner pour
chaque
dimension choisit
pour la
clause «WHERE», un
niveau
et un membre pour ce
niveau.
La requête générée.
Sauvegarde de la
requête
générée (non
personnalisée)
sur le profil
utilisateur.
L’ensemble de toutes
les
requêtes
personnalisées
possible (due à
l’utilisation
de l’ordre partiel).
6.6 Exemples et discussions
A travers l’exemple pratique suivant, on va essayer d’aborder l’objectif principal de notre
système « personnalisation » . Cet objectif consiste à ne présenter à l’utilisateur que les résultats
respectant ses préférences figurées dans son profil.
70
Chapitre 4
Conception et implémentation
Il sera aussi l’occasion d’évaluer l’efficacité de notre algorithme STRUCTURATION pour la
générations de l’ensemble de toutes les structures possibles pour un ensemble de références en
tenant compte les contraintes de visualisation de l’utilisateur.
L’évaluation de la proposition concernant la discrimination entre plusieurs sous-ensembles de
références ainsi que la suggestion pour une structure parmi un ensemble de plusieurs structures
proposées par le système font partie de l’objectif principal de cet exemple pratique.
6.6.1 Exemple : Discriminations et suggestions
6.6.1.1 Discrimination entre les sous-ensembles de références
Pour cet exemple, et pour certaines raisons d’analyse, l’utilisateur 1 formate la requête 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]
Lors de l’exécution de la requête, le système renvoie deux sous-ensembles de références
(Figure 1) due au soutient de l’ordre partiel (l’utilisateur n’a pas de préférences entre quelques
dimensions parmi celles utilisées dans la requête). Les deux sous ensembles de références 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
L’utilisateur 1 ne sait pas lequel parmi ces deux sous-ensembles de références qui est
pertinent en terme de nombre des cellules vides que contient chacun. Pour ne pas tomber dans le
mauvais choix, il préfère passer cette responsabilité au système qui va calculer le nombre des
cellules vides pour chacun des deux sous-ensembles de références afin de ne garder pour
l’utilisateur que celui qui réalise le plus petit nombre (Fig.19).
71
Chapitre 4
Conception et implémentation
Après les calculs, le système trouve que R0 est mieux que R1 en terme de nombre
d’occurrences de la cellule vide (Fig.20). Pour que le résultat soit confiant à l’utilisateur 1, ce
dernier exécute les deux sous-ensembles de références afin de comparer le nombre des cellules
vides qu’ils contiennent. Dans les deux cas, le système propose à l’utilisateur une seule structure
selon la contrainte de visualisation choisie :
FIG.19
FIG.20
Pour l’ensemble R0 :
Structure : {Store} AND {Product, Promotion Media}
Requête :
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]
Résultat : montré sur la Fig.21.
Pour l’ensemble R1 :
Structure : { Product } AND { Promotion Media, Store }
Requête :
FIG.21
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
FROM Sales
WHERE [Measures].[Measures Level].[Sales Count]
Résultat : montré sur la Fig.22.
FIG.22
72
Chapitre 4
Conception et implémentation
• Discussion des résultats
D’après les résultats obtenus on a :
- Le nombre total pour chacun des deux résultats égale à 12.
- Le nombre des cellules vides dans R0 égale à 2.
- Le nombre des cellules vides dans R1 égale à 8.
Si en désigne par Pr_Null le pourcentage d’apparition des cellules vides dans
chacun des deux résultats, ce pourcentage est donné par :
Pr_Null =nombre total des cellules / nombre des cellules vides
Pour R0 : Pr_Null = 2/12 =1/6
et pour R1 : Pr_Null =8/12 =2/3
Ce résultat justifie le choix de système pour le sous ensemble R0 puisque il montre que le
pourcentage d’apparition des cellules vides dans R0 égale à 1/6 et il est moins que 2/3, le
pourcentage d’apparition des cellules vides apparaissant dans R1.
6.6.2 Suggestions pour un ensemble des structures proposées
Considérons que l’utilisateur 1 à changé la contrainte de visualisation par la suivante : G<4,6> et
qu’il n’a pas précisé des dimensions à mettre sur chacune des deux axes.
Dans cet exemple, l’utilisateur 1 veut savoir si la situation maritale (S ou M) d’une personne
influe sur leur consommation des produits laitiers (Dairy) et les boissons (Drinks) pendant
l’année 1997 ?
Pour obtenir une réponse à cette problématique, l’utilisateur 1 va construit la requête 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 d’une telle requête par le système personnalisation donne à l’utilisateur le
sous-ensemble de références 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 l’algorithme STRUCTURATION, le système propose à
l’utilisateur l’ensemble des structures suivantes (Fig.23) :
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 }
FIG.23
Si l’utilisateur 1 ne veut garder que les structures qui ont des nombres de graduation identiques
ou rapprochés pour les deux axes, alors il doit cocher «Structures with only nearest axis».
Dans ce cas, le système va comparer toutes les structures de l’ensemble afin de garder celles qui
ont une différence entre les nombres de graduation des deux axes minime (Fig24).
Sinon, s’il ne trouve aucune différence, alors il va comparer
73
Chapitre 4
Conception et implémentation
cet ensemble basant sur la différence entre les nombres
des dimensions sur les deux axes, afin de ne garder
que celles qui réalisent 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 }
FIG.24
Les résultats d’exécution en utilisant l’ensemble de références
avec chacune de ces structures filtrées seront :
(Fig25, Fig.26, Fig.27 et Fig.28 pour respectivement les structures 2, 3, 5 et 6).
FIG.25
FIG.26
FIG.27
FIG.28
Tandis que les résultats d’exécution de l’ensemble de références pour les structures éliminées
suivant :
1. { Measures } et { Marital Status × Product }
4. { Marital Status × Product } et { Measures }
Sont respectivement (Fig.29 et Fig.30 ):
FIG.29
FIG.30
74
Chapitre 4
Conception et implémentation
• Discussion des résultats
D’après les deux ensembles des résultats, il est clair que le but de cette optimisation est
de supporter les visualisations qui garantissent un placement des données (sinon des dimensions)
équitable ou bien rapproché sur les deux axes de cube résultant. Cette idée ne veut pas dire que
les structures éliminées sont indésirables, puisque toutes les structures proposées par le système
sont correctes, mais c’est juste pour alléger le choix de structure pour l’utilisateur en cas où
l’ensemble des structures proposées par le système est assez grand.
7. Conclusion
Parmi nos propositions présentées dans ce chapitre, l’algorithme STRUCTURATION qui
est différent de celui de [Bellatrech et al.2005] (FindStruct) de fait que ce dernier a pour but
d’affirmer pour un cube C l’existence d’une structure S respectant la contrainte de visualisation
VT,G ou non en calculant cette structure si elle existe, tandis que notre algorithme
STRUCTURATION calcule pour un cube de données C l’ensemble de toutes les structures
possibles qui respectent la contrainte de visualisation VT,G.
Ainsi, et avec l’existence d’une part, des structures parmi celles générées par notre
algorithme STRUCTURATION où la totalité ou la plupart des dimensions sélectionnées sont
placées sur un seul axe, ou bien des structures où la différence entre le nombre de graduations
sur les deux axes est considérable, et la forme carrée que prendre la majorité des assistants
personnels PDA, SmartPhone (téléphone intelligent : un téléphone mobile couplé à un PDA)
d’une autre part, on a introduit une nouvelle définition concernant la visualisation des résultats
d’exécution des requêtes OLAP sur ces appareilles.
Cette définition qualifier une visualisation d’être la meilleure si elle est réalisée par une
structure où la différence entre le nombre de graduations sur ses deux axes est minime. Cette
différence peut être supervisée par un seuil afin d’aider l’utilisateur à justifier ses visualisations.
Ensuite , Nous avons faits une étude de cas pour donner un aperçu pratique pour le
prototype développé Personnalisation ainsi que son fonctionnement de base. Après avoir exploré
les algorithmes de personnalisation des requêtes OLAP dans la partie précédente, cette partie a
pour objectif de montrer et discuter le prototype développé Personnalisation qui implémente ces
algorithmes de personnalisation. Ce prototype consiste en une simulation d’une application java
s’exécutant sur un smart phone d’un utilisateur.
A travers l’exemple pratique, on a essayé d’aborder l’objectif principal de notre système
Personnalisation. Cet objectif consiste à ne présenter à l’utilisateur que les résultats respectant
ses préférences figurées dans son profil.
Il a été aussi l’occasion d’évaluer l’efficacité de notre algorithme STRUCTURATION
pour la générations de l’ensemble de toutes les structures possibles pour un ensemble de
références en tenant compte les contraintes de visualisation de l’utilisateur. L’évaluation de la
proposition concernant la discrimination entre plusieurs sous-ensembles de références ainsi que
la suggestion pour une structure parmi un ensemble de plusieurs structures proposées par le
système font partie de l’objectif principal de cet exemple pratique.
75
Dans ce mémoire, on a essayé d’éclairer la notion de personnalisation, ses enjeux dans les
diverses disciplines et surtout d’enlever certaines ambiguïtés qui entourent ce concept dans les
entrepôts de données.
On a constaté que la personnalisation dans les entrepôts de données et comme dans les
bases de données relationnelles, elle est basée sur l’utilisation de profil utilisateur pour lui donner
une réponse appropriée à ses préférences. Le principe est lorsqu’un utilisateur interroge un
entrepôt de données par une requête OLAP, ses préférences stockées dans son profil doivent
êtres prises en considération.
Certaines particularités qui caractérisent les entrepôts de données exigent l’introduction
des autres factures telles que la présentation des résultats. Cette information est aussi stockée
dans le profil de l’utilisateur et lui permet d’exprimer la forme que doit prendre le résultat
d’exécution de sa requête OLAP.
Pour cet objectif (donner à l’utilisateur ce qui lui convient), il y a des travaux récents qui
adoptent la notion de recommandation. Dans ce contexte, la recommandation figure dans
l’enrichissement de schéma de l’entrepôt de données par des nouveaux niveaux de granularité ou
par la suggestion des requêtes OLAP à l’utilisateur en basant sur l’enchaînement des requêtes
des autres utilisateurs qui le précèdent sur le même système.
Afin de concrétiser la notion de personnalisation dans les entrepôts de données, on a
réalisé un prototype appelé Personnalisation. D’après ce dernier, on a essayé de synthétiser les
principales fonctionnalités d’un système de personnalisation. Les algorithmes employés dans ce
prototype sont l’algorithme de personnalisation de contenu [Bellatreche et al, 2006] et notre
algorithme STRUCTURATION pour la génération des structures possibles pour un ensemble des
références.
Le principal objectif de l’ensemble des exemples pratiques réalisés avec notre prototype
été la démonstration de l’efficacité des algorithmes employés dans l’implémentation de ce
prototype, ainsi que pour démontrer les avantages des différentes propositions.
Les qualités des différents résultats obtenus démontrent l’utilité de la personnalisation
dans les systèmes d’information, et le confort offert aux utilisateurs dés qu’ils obtiennent ce
qu’ils veulent sans qu’ils soient surchargés par des informations qui ne les intéresse plus.
79
[ABELLO, 2006] A Abello, J Samos, and F Saltor. YAM2 : A Multidimensional Conceptual
Model Extending UML. Information Systems, 31(6) :541–567, 2006.
[AGRAWAL et AL, 2003] Agrawal, Chaudhuri, Das et Gionis. “ Automated ranking of
database query results”. 8iemme Conférence internationale sur les bases de données avancées.
2003.
[AGRAWAL et WIMMERS, 2000] Agrawaland et Wimmers. “A framework for expressing
and combining preferences”. Proceedings of the 2000 ACMSIGMOD International Conference
on Management of Data, 2000, Dallas, Texas, USA.
[ANNONI, 2007] E Annoni. Eléments méthodologiques pour le développement des systèmes
décisionnels dans un contexte de réutilisation. Thèse de doctorat, Institut de Recherche en
Informatique de Toulouse - Université Toulouse 1, Toulouse, France, 2007.
[APPLIX, 1998] Applix INC. TM1 Technology, 1998. White paper.
[ARBOR, 19898] Arbor Software. Essbase, 1998. White paper.
[BELLATRECHE et AL, 2005] L. Bellatreche, A. Giacometti, P. Marcel, H. Mouloudi, and
D. Laurent. “A Personalization Framework for OLAP Queries”. In 8th ACM International
Workshop on Data Warehousing and
OLAP (DOLAP 05), Bremen, Germany, pages 9–18. ACM Press, 2005.
[BELLATRECHE et AL, 2006] L. Bellatreche, A. Giacometti, P. Marcel, and H. Mouloudi.
“Personalization of MDX Queries”. Dans la 22èmes journées Bases de Données Avancées (BDA
06), Lil le, France, 2006.
[BOHNLEIN et AL, 2002]
M. Böhnlein, M. Plaha, Ulbrich-Vom et A. Ende. “Visual
Specification of Multidimensional Queries Based on Semantic Data Model”. Article de
recherché, Data Warehouse Zum Corporate Knowledge Center, DW 2002, 2002.
[BONIFATI et AL, 2001] A Bonifati, F Cattaneo, S Ceri, A Fuggetta, and S Paraboschi.
Designing Data Marts for DataWarehouses. ACM Transactions on Software Engineering and
Methodology, 10(4) :452–483, 2001.
[BOUSSAID et AL, 2003] O Boussaid, F Bentayeb, J Darmont, and S Rabaseda. Vers l’entreposage des données complexes. structuration, intégration et analyse. Ingenierie des Systemes
d’Information, 8(5-6) :79–107, 2003.
[BOUZEGHOUB et KOSTADINOV, 2005]
M. Bouzeghoub et D. Kostadinov. “
Personnalisation de l’information : aperçu de l’état de l’art et définition d’un modèle flexible de
profils”. Dans IIème Conférence en Recherche d’Informations et Applications (CORIA 05),
Grenoble, France, 2005.
[BRADLEY et AL, 2000] K. Bradley, R. Rafter, and B. Smyth. “Case-Based User Profiling
for Content Personalisation”. In International Conference on Adaptive Hy-permedia and
Adaptive Web- Based Systems (AH 00), Trento, Italy, volume 1892 of LNCS, pages 62–72.
Springer, 2000.
[CABIBBO, 1998] L. Cabibbo et R. Torlone. “From a Procedural to Visual Query Language
for OLAP”’. Article de recherché, 10th IEEE International Conference on scientific and
Statistical Database Management, 1998.
[CHAUDHURI et AL, 2004] Chaudhuri ,Das, Hristidis et Weikum. “Probabilistic ranking of
database query results”. The Thirtieth International Conference on Very Large Data Bases
Toronto, Canada, 2004.
[CHAUDHURI et DAYAL1, 1997]
S .Chaudhuri et U.Dayal. An Overview of Data
Warehousing and OLAP Technology. SIGMOD Rec., 1997.
[CHEN et AL, 1998] L. Chen, K. Sycara. WebMate: A Personal Agent for Browsing and
Searching, In Proceedings of the 2nd International Conference on Autonomous Agents and Multi
Agent Systems, Minneapolis, MN, May 10-13, 1998.
[CHERNIACK et AL, 2003] M. Cherniack, E.F. Galvez, M.J. Franklin, and S.B. Zdonik.
“Profile-Driven Cache Management”. In 19th International Conference on Data Engineering
(ICDE 03), Bangalore, India, pages 645–656. IEEE ComputerSociety, 2003.
[CHOMICKI, 2003]
Chomicki. “Preference formulas in relational queries”. ACM
TransDatabase Systems, 2003
[CHOONG et AL, 2007] Y.W. Choong, A. Giacometti, D. Laurent, P. Marcel, E. Negre, and
N. Spyratos. “Context-based Exploitation of DataWarehouses”. Dan la 3ème journée
francophones sur les Entrepôts de Données et l’Analyse en ligne (EDA 07), Poitiers, France,
volume B-3 of Revue des Nouvel les Technologies de l’Information, pages 131–146. Cépaduès
Editions, 2007.
[CODD, 1993] E. Codd. “Providing OLAP (On-Line Analytical Processing) to Users-Analists:
an IT mandate’’. Technical report, E.F.Codd and Associates, 1993.
[CROZAT, 2002] S. Crozat. “Introduction aux bases de données’’. Support de cours, 2002.
[DAS et AL, 2006] Das, Hristidis, Kapoor, et Sudarshan. “Ordering the attributes of query
results”. SIGMOD Conference, 2003.
[ESPIL et AL, 2002] M. Espil, A. Vaisman et L. Terribile. “Revising Data Cubes with
Exceptions: a Rule-based Perspective”. In IVth International Workshop on Design and
Management of Data Warehouses (DMDW 02), Toronto, Canada, volume 58 of CEUR
Workshop Proceedings, 2002.
[FAVRE, 2007] Cécile Favre. “Evolution de schémas dans les entrepôts de données : mise à
jour de hiérarchies de dimension pour la personnalisation des analyses’’. Thèse de doctorat,
Université Lumière-Lyon2, Lyon, France, 2007.
[FRANCO, 1997] J. M. Franco. “Le Data Warehouse Le Data Mining’’. Eyrolles, 1997.
[FRANCONI, 1999] E. Franconi and U. Sattler. A Data Warehouse Conceptual Data Model for
Multidimensional Aggregation : a Preliminary Report. Italian Association for Artificial
Intelligence AI*IA Notizie, 1 :9–21, 1999.
[GAUCH et AL 2003] S. Gauch, J. Chaffe et A. Pretschner. Ontology-Based User Profiles for
Search and Browsing, To appear in J. User Modeling and User-Adapted Interaction, the Journal
of Personalization Research , Special Issue on User Modeling for Web and Hypermedia
Information Retrieval, 2003.
[GOLFARELLI et AL, 1998] M Golfarelli, D Maio, and S Rizzi. Conceptual Design of Data
Warehouses from E/R Schemes. In XXXIst Annual Hawaii International Conference on System
Sciences (HICSS 98), Big Island, Hawaii, USA, volume 7, pages 334–343, 1998.
[GOLFARELLI, 1998] M Golfarelli, D Maio, and S Rizzi. The Dimensional Fact Model : A
Conceptual Model for Data Warehouses. International Journal of Cooperative Information
Systems, 7(2-3) :215–247, 1998.
[GRAUA, 2004] C. Graua. “SQL Serveur 2000, Analysis Service et DTS”. ENSMP, France,
2004. [email protected].
[GUERRERO, 2002] Edgard Ivan Benitez Guerrero. Infrastructure adaptable pour l’évolution
des entrepôts de données. Thèse de doctorat, Université Joseph Fourrier – Grenoble1, Grenoble,
France, 2002.
[HAFYANE, 2008] S. Hafyane. “Langage d’interrogation graphique des bases de données
multidimensionnelles temporelle’’. Thèse de Magister, Institut national de formation en
informatique (INI), Alger, Algérie, 2008.
[INMON, 1992] W H Inmon. Building the Data Warehouse. QED Technical Publishing Group,
Wellesley, Massachusetts, U.S.A, 1992.
[INMON, 1996]
Edition, 1996.
W H Inmon. Building the Data Warehouse. John Wiley & Sons, Second
[INMON, 2002]
Edition, 2002.
W H Inmon. Building the Data Warehouse. John Wiley & Sons, Third
[ISRAEL, 2001] M. Israel. “SQL Serveur 2000”. Eyrolles, 2001.
[KENAN, 1995] Kenan Systems Corporation. An Introduction to Multidimensional Database
Technology, 1995. White paper.
[KENAN, 1997] Kenan Systems Corporation. Multidimensional Database Technology and
Data Warehousing, 1997. White paper.
[KIEßLING, 2002] Kießling. “Foundations of preferences in database systems”. 2002.
[KIM et AL, 2003] H J Kim, T H Lee, S G Lee, and J Chun. Automated Data Warehousing for
Rule-Based CRM Systems. In XIVth Australasian Database Conference on Database
Technologies, pages 67–73. Australian Computer Society, 2003.
[KIMBALL, 1996] R Kimball. The Data Warehouse Toolkit. John Wiley, U.S.A, 1996
[KIMBALL et AL, 2000] R Kimball, L Reeves, M Ross, and W Thornthwaite. Concevoir et
deployer un data warehouse. Eyrolles, 2000.
[KOSTADINOV, 2008] D. Kostadinov. “Personnalisation de l’information : une approche de
gestion de profils et de reformulation de requêtes”. Thèse de doctorat, Université de Versailles
Saint- Quentin en Yvelines, France, 2008.
[KOUTRIKA et IOANNIDIS, 2004] G. Koutrika and Y. Ioannidis. “Personalization of Queries
in Database Systems”. In 20th International Conference on Data Engineering (ICDE 04), Boston,
Massachusetts, USA, pages 597–608. IEEE Computer Society, 2004.
[KOUTRIKA et IOANNIDIS, 2005] Koutrika et Ioannidis. “Constrained optimalities in query
personalization”. SIGMOD Conference, 2005.
[LIST et AL, 2002] B List, R Bruckner, K Machaczek, and J Schiefer. A Comparison of Data
Warehouse Development Methodologies Case Study of the Process Warehouse. In XIIIth
International Conference on Database and Expert Systems Applications (DEXA 02), Aix-enProvence, France, volume 2453 of LNCS, pages 203–215. Springer, 2002.
[LUJAN-MORA, 2006] S Lujan-Mora, J Trujillo, and I Y Song. A UML Profile for
Multidimensional Modeling in Data Warehouses. Data and Knowledge Engineering, 59(3) :725–
769, 2006.
[LOPEZ & AL, 2000] N.LOPEZ, J.MIGUEIS et M.PICHON, intégrer UML dans vos projet,
EYROLLES, 2000
[MOODY et AL, 2000] D LMoody andMA R Kortink. From Enterprise Models to Dimensional
Models : a Methodology for Data Warehouse and Data Mart Design. In Design and Management
of Data Warehouses, page 5, 2000.
[MOULOUDI, 2007] H Mouloudi. Personnalisation de requêtes et visualisations OLAP sous
contraintes. Thèse de doctorat, Université Franois Rabelais, Tour, France, 2007.
[MULLER, 1997] modélisation objet avec UML, Pierre-Alain Muller, 1997.
[NABLI et AL, 2005] A Nabli, A Soussi, J Feki, H Ben-Abdallah, and F Gargouri. Towards an
Automatic Data Mart Design. In VIIth International Conference on Enterprise Information
Systems (ICEIS 05), Miami, Florida, USA, pages 226–231, 2005.
[PEGUIRON, 2006] F. Peguiron. “Application de l’Intelligence Economique dans un système
d’Information Stratégique Universitaire : les apports de la modélisation des acteurs”. Thèse de
doctorat, Université Nancy2, Nancy, France, 2006.
[PERALTA et AL, 2003] V Peralta, A Illarze, and R Ruggia. On the Applicability of Rules to
Automate Data Warehouse Logical Design. In Ist International Workshop on Decision Systems
Engineering (DSE 03), in conjunction with the XVth International Conference on Advanced
Information Systems Engineering (CAiSE 03), Klagenfurt/Velden, Austria, volume 75 of CEUR
Workshop Proceedings. CEUR-WS.org, 2003.
[PHIPPS et AL, 2002] C Phipps and K C Davis. Automating Data Warehouse Conceptual
Schema Design and Evaluation. In IVth International Workshop on Design and Management of
Data Warehouses (DMDW 02), Toronto, Canada, volume 58 of CEUR Workshop Proceedings,
pages 23–32. CEUR-WS.org, 2002.
[PITOURA et STEFANIDIS, 2008] E. Pitoura et K. Stefanidis. “Fast contextual preference
scoring of database tuples”.EDBT’08, 2008, Nantes, France.
[POE, 1996] V Poe. Building a Data Warehouse for Decision Support. Prentice Hall, 1996.
[PRETSCHNER et GAUCH, 1999] A. Pretschner and S. Gauch. “Ontology Based
ersonalized Search”. In 11th IEEE International Conference on Tools with Artificial Intelligence
(ICTAI 99), Chicago, Illinois, USA. IEEE ComputerSociety, 1999.
[RAVAT et AL, 2002] F. Ravat, O. Teste, and G. Zurfluh. “Personnalisation de bases de
données multidimensionnelles”. Dans le 25ème Congrès Informatique des Organisations et
Systèmes d’Information et de Décision (INFORSID 07), Perros-Guirec, France, pages
121–136, 2007.
[SOUSSI et AL, 2005] A Soussi, J Feki, and F Gargouri. Approche semi-automatisée de
conception de schémas multidimensionnels valides. In Iere journée sur les Entrepôts de Données
et l’Analyse en ligne (EDA 05), Lyon, volume B-1 of Revue des Nouvelles Technologies de
l’Information, pages 71–90. Ce- padues Editions, 2005.
[SPOFFORD, 2001] G. Spofford. “MDX Solutions”. Willey, 2001.
[TEST, 2000] O Teste. Modélisation et manipulation d’entrepôts de données complexes et
historiées. Thèse de doctorat, Institut de Recherche en Informatique de Toulouse - Universite
Toulouse 3, Toulouse, France, 2000.
[TORLONE et CIACCIA, 2002] Torlone, Ciaccia. “Finding the best when it’s a matter of
préférence”. Dans SEBD, 2002.
[TOURNIER, 2004] R. Tournier. “ Bases de données multidimensionnelles : Etude et
Implantation d’un langage graphique ”. Rapport de DEA, IRIT, Université Paul Sabatier,
Toulouse, France, 2004.
[TARDIEU, 1983] H Tardieu, A Rochfeld, and R Coletti. La methode Merise. Les Editions
d’Organisation, Paris, 1983.
[TRUJILLO et AL, 2001] J Trujillo, M Palomar, J Gomez, and I-Y Song. Designing Data
Ware- houses with OO Conceptual Models. Computer, 34(12) :66–75, 2001.
[TRYFONA et AL, 1999] N Tryfona, F Busborg, and J G Borch Christiansen. starER : A
Concetual Model for Data Warehouse Design. In IId ACM International Workshop on Data
Warehousing and OLAP (DOLAP 99), Kansas City, Missouri, USA, pages 3–8. ACM Press,
1999.
[ULBRICH et AL, 2000] A Ulbrich vom Ende M Boehnlein. Business Process Oriented
Development of Data Warehouse Structures. In Data Warehousing 2000 Methoden
Anwendungen, Friedrichshafen, Germany. Physica Verlag, 2000.
[WU et BUCHMANN, 1997] Ming-Chuan Wu et Alejendro Buchmann. Research Issues In
Data Warehousing. Dans GI-Fachtagung Daten Banken In Buro, Technik und Wissenschaft,
Germany, 1997.
[ZACHARIS et PANAYIOTOPOULOS, 2001] NZ. Zacharis, T. Panayiotopoulos. Web
Search Using a Genetic Algorithm, IEEE Internet Computing, vol. 5, n° 2, pp. 18-26, MarchApril 2001.
[WEB1]
[WEB2]
[WEB3]
[WEB4]
[WEB5]
[WEB6]
[WEB7]
[WEB8]
[WEB9]
http: //www.inmoncif.com
http://www.stanford.edu
http : //www.olapreport.com
http : //www.olapreport.com/fasmi.htm
http ://www.linux-france.org/prj/jargonf/F/FASMI.html
http ://www.java.sun.com/products/jmi/pres/JOLAPOverview.pdf
http: //www.technet.microsoft.com/fr-fr/library/
http://www.smile.fr
http : //www.msdn.microsoft.com/fr-fr/sqlserveur/