MONDRIAN Jpivot Final
MONDRIAN Jpivot Final
MONDRIAN Jpivot Final
NAVIGATION
MULTIDIMENTIONNELLE AVEC
Mondrian/JPivot
Présenté par :
Nom et prénom matricules
CM-UDS-14SCI2036
MFONE ABDOULAYE
ATCHAZE ARIEGE CM-UDS-14SCI1923
Table of Contents
Introduction ........................................................................................................................................ 2
I. Architecture logicielle utilisée ...................................................................................................... 3
A. Le serveur MONDRIAN et le client JPivot ................................................................3
1. Le serveur MONDRIAN ..........................................................................................3
Les moteurs OLAP ..........................................................................................................3
2. Le Client JPIVOT......................................................................................................4
II. Fonctionnement générale............................................................................................................ 5
A. Installation et configuration de MONDRIAN/JPIVOT ..............................................5
1. Prérequis ...................................................................................................................5
2. Installation de MONDRIAN/JPIVOT et Configuration de la connexion au serveur
mysql ...............................................................................................................................5
3. Configuration de source de données en JPIVOT ........................................................6
4. .....................................................................................................................................6
III. Exemple d’entrepôt sous MONDRIAN .......................................................................................... 8
A. Description de l’entrepôt ...........................................................................................8
B. Schéma MONDRIAN de l’entrepôt en XML ........................................................... 10
C. Cube ........................................................................................................................ 10
D. Mesures ................................................................................................................... 10
E. Dimensions, membres, hiérarchies et nivedaux ........................................................... 11
F. Correspondances des dimensions et des hiérarchies avec les tables ............................. 12
G. Membre « All » et par défaut ................................................................................... 14
H. La dimension « temps » ........................................................................................... 14
IV. Analyses OLAP en JPIVOT........................................................................................................... 15
1. Origine de MDX ..................................................................................................... 15
2. Format et exemple d’une requête MDX ................................................................... 16
3. Quelques exemples de requêtes MDX ..................................................................... 18
B. Usage de l’interface JPIVOT ................................................................................... 19
Conclusion ......................................................................................................................................... 24
Bibliographie : ................................................................................................................................... 25
1
MONDRIAN/JPIVOT
Introduction
L’évolution permanente des technologies de l’information conduit de plus en plus
d’acteurs (entreprises, recherche,...) à conserver leurs données et ainsi préserver la mémoire
de leurs activités. Les données collectées par ces acteurs sont un atout puissant pour dégager
des tendances passées, actuelles et surtout futures. À partir des gisements de données ainsi
constitués, il est naturel de chercher à les exploiter au mieux. Apparus pour gérer de très gros
volumes de données issues de sources hétérogènes, les entrepôts de données ou en anglais
Data warehouses, constituent l’outil essentiel de collecte et de mise à disposition des données
en vue de leur analyse. L’analyse de ces données fait appel à des traitements OLAP (On-Line
Analytical Processing), qui se distinguent des processus OLTP (On-Line Transactional
Processing) principalement par leur complexité et par le nombre de données.
2
MONDRIAN/JPIVOT
On distingue 3 familles de moteur OLAP sont : les R-OLAP, les M-OLAP et les H-OLAP :
Un cube Mondrian peut également être implémenté dans une plate-forme telle que
Jasper, Pentaho ou SpagoBI. L'interrogation se fera alors à travers l'outil « JPivot », en mode
3
MONDRIAN/JPIVOT
web. Ci-dessous le schéma d'architecture nous permet de comprendre les mécanismes mis en
œuvres :
2. après validation du format de la requête, celui-ci utilise le schéma XML correspondant aux
données à traiter afin de transmettre une demande formatée à la couche de requêtage SQL
2. Le Client JPIVOT
JPivot est un outil qui permet aux utilisateurs d’exécuter des navigations OLAP. Couplé à
Mondrian, ce duo logiciel performant est employé dans la plupart des suites décisionnelles
open source. JPivot est une bibliothèque de balises JSP. JPivot est le compagnon visuel du
moteur OLAP Mondrian. Tout comme Mondrian, JPivot est open source et écrit en Java. Il est
donc possible, au sein d’une organisation, d’écrire son propre client OLAP en modifiant
4
MONDRIAN/JPIVOT
JPivot. JPivot a l’avantage d’être disponible gratuitement et de fonctionner avec une panoplie
de plateformes.
5
MONDRIAN/JPIVOT
8. Rendez-vous sur votre navigateur et saisissez http: // localhost: 8080 / mondrian et vous
obtiendrez une page d'accueil Mondrian comme ci-dessous.
Provider=mondrian;Jdbc=jdbc:odbc:MondrianFoodMart;Catalog=/WEB
-INF/queries/FoodMart.xml;
JdbcDrivers=sun.jdbc.odbc.JdbcOdbcDriver;
Par
Provider=mondrian;Jdbc=jdbc:mysql://localhost/foodmart?user=fo
odmart&password=;Catalog=/WEB-INF/queries/
FoodMart.xml;JdbcDrivers=com.mysql.jdbc.Driver;
• fourheir.jsp,
• mondrian.jsp,
• colors.jsp
• arrows.jsp
6
MONDRIAN/JPIVOT
jdbcUrl="jdbc:odbc:MondrianFoodMart" catalogUri="/WEB-INF/queries/FoodMart.xml">
Par
Copiez le fichier JAR du pilote JDBC (dans notre cas, le fichier mysql-connector-
java3.0.17-ga-bin.jar) dans TOMCAT_HOME/common/endorsed. Relancez ensuite
Tomcat. Connectez-vous à Mondrian via l'adresse http://localhost:8080/mondria .( si tout est
bien configuré on doit pas avoir une page d'erreur.) Vous verrez alors une table que vous
pouvez explorer de façon hiérarchique et une barre d'outils de titre qui comprend des icônes
de configuration.
7
MONDRIAN/JPIVOT
8
MONDRIAN/JPIVOT
exemple, la dimension Time et la dimension Product sont organisées ainsi comme le montre la
figure suivante :
Ce cube présente les dimensions Product et Time avec un certain niveau de détail.
9
MONDRIAN/JPIVOT
C. Cube
Un cube (<Cube>) est une collection de mesures et de dimensions, identifiée par un
Nom. Les dimensions et les mesures ont la table de faits en commun (dans l'exemple, la table
de faits est "sales_fact_1997"). Le cube « Sales » est spécifié dans le schéma Précédent ainsi :
<Cube name="Sales">
<Table name="sales_fact_1997"/>
...
</Cube>
La table de faits est définie en utilisant <Table>. Si la table de faits n'est pas dans le Schéma
par défaut, on peut fournir explicitement son schéma en utilisant l'attribut "schema". Par
exemple, <Table schema="dmart" name="sales_fact_1997"/>.
D. Mesures
Il existe deux types de mesures : les mesures calculées et non calculées. Dans le schéma
XML précédent, le cube « Sales » des ventes définit plusieurs mesures, dont "Unit Sales" Et
"Store Sales". La mesure "Profit" est une mesure calculée à partir des mesures "Store Sales" et
"Store Cost". Voici ces spécifications liées au cube « Sales » :
formatString="#,###"/>
10
MONDRIAN/JPIVOT
formatString="#,###.00"/>
Remarque :
L'attribut optionnel "datatype" spécifie les types selon lesquels les valeurs des
cellules seront représentées dans le cache de MONDRIAN et comment elles seront
retournées. L'attribut "datatype" peut avoir pour valeur "String", "Integer",
"Numeric", "Boolean", "Date", "Time", et "Timestamp". La valeur par défaut est
"Numeric" à l'exception des opérateurs "count" et "distinct-count" qui ont une valeur
par défaut "Integer".
L’attribut optionnel "formatString" donne le format à utiliser lors de l'affichage des
données. Par exemple, la mesure "Unit Sales" est affichée sans décimales, alors que la
mesure "Store Sales" est affichée avec deux décimales. L'emplacement des
caractères ',' et '.' dépend des notations adoptées pour afficher les décimales.
12
MONDRIAN/JPIVOT
selon plusieurs tables, on peut utiliser l'attribut primaryKeyTable pour lever toute
Ambiguïté :
<Cube name="Sales">
...
<Dimension name="Product" foreignKey="product_id">
<Table name="product_class"/>
<Table name="product"/>
</Join>
</Hierarchy>
</Dimension>
</Cube>
Remarque : l'attribut uniquemembers est utilisé pour optimiser les commandes SQL. Si On
sait que les valeurs d'un niveau d'une table de dimensions sont uniques sur toutes les Valeurs
d'un niveau parent, il faut alors mettre l'attribut uniquemembers="true" et "false" Sinon.
Par exemple, dans la dimension "Time", la hiérarchie "[Year].[Month]" peut avoir La valeur
uniquemembers="false" au niveau de "Month" car un même mois peut être présent Dans
différentes années. Dans la hiérarchie "[Product Class].[Product Name]", si l’on est Sûr que
"[Product Name]" est unique, alors on peut mettre uniquemembers="true". Dans le Cas
contraire, mettez "false". Dans le niveau le plus haut de la hiérarchie, l'attribut
Uniquemembers="true" car il n'y a aucun niveau parent.
13
MONDRIAN/JPIVOT
Par exemple, Dans la hiérarchie "Time", le membre par défaut serait la première année de la
hiérarchie. Le changement du membre par défaut peut prêter à confusion, alors on doit
le laisser Toujours vrai (hasall="true"). L'élément <Hierarchy> a également l'attribut
"defaultmember", utilisé pour changer le membre par défaut de la hiérarchie. Ci-dessous, un
Exemple :
H. La dimension « temps »
La dimension temps est basée sur l'année, le mois, la semaine et le jour. Elle est
implantée d'une manière particulière sous MONDRIAN pour prendre en compte la
Spécificité des fonctions liées au temps comme :
parallelperiod([level[, index[, member]]])
periodstodate([level[, member]])
mtd([member])
qtd([member])
ytd([member])
lastperiod(index[, member])
La dimension temps a un attribut "type" dont la valeur est "timedimension". Le rôle D'un
niveau d'une dimension temps est indiqué par l'attribut "leveltype", dont les valeurs Permises
sont les suivantes :
14
MONDRIAN/JPIVOT
15
MONDRIAN/JPIVOT
MDX est fait pour naviguer dans les bases multidimensionnelles et pour définir des
requêtes sur tous les objets (dimensions, hiérarchies, niveaux, membres et cellules) afin
d'obtenir (simplement) une représentation sous forme de tableaux croisés.
La syntaxe de MDX ressemble à celle de SQL par ses mots clé SELECT, FROM, WHERE,
mais leurs sémantiques sont différentes.
Structure de la requête :
SQL : SELECT column1, column2, …, columnn FROM table
Une Hiérarchie est composée de niveaux ("levels"). Un niveau correspond à un des attributs
de votre base de données. Le plus important est que la séquence des niveaux réponde à une
logique de navigation.
Par exemple, la hiérarchie "Time" est composée des niveaux "Year", "Quarter" et
"Month" ; la hiérarchie "Store" est composée des niveaux "Country", "State", "City" et "Store
Name". Le sens et l'ordre de navigation sont importants.
Un niveau est lui-même composé de membres. Les membres sont les valeurs d'un niveau
détectées par le moteur OLAP et stockées dans les métadonnées. Par exemple, les membres du
niveau "Country" sont "Canada", "Mexico" et "USA".
Un Membre est une instance d'un niveau. Les enfants d'un membre sont tous les membres du
niveau immédiatement en dessous de celui-ci.
16
MONDRIAN/JPIVOT
[Time].[2012]
[Product].[Food]
[Product].[Food].[Baked Goods]
Un tuple est une suite de plusieurs membres entre parenthèses séparés par une virgule. Un
tuple donne la liste des membres qui identifient une ou plusieurs cellules dans un cube. Une
cellule étant l'intersection des dimensions d'un cube de données.
Un set est un ensemble ordonné de tuples. Un set peut être vu comme une plage de valeurs. Le
set commence par une accolade "{", dans laquelle sont énumérés les tuples séparés par des
virgules, et se termine par une accolade appariée "}"
Un set suivi du mot clef « ON » suivi d'un « nom d'axe spécifique » fait référence à un
numéro d'ordre s'il y a plus de 2 axes de restitution, ou simplement aux noms d'axes explicites
« COLUMNS » et « ROWS ».
Parenthèses en MDX :
{ } : Ensemble des éléments servant à la création d’une dimension du résultat de la
requête
( ) : Sélection de tuples dans la clause WHERE
[ ] : Représentation d’espaces, de caractères spéciaux et d‘interprétation non
numérique de chiffres.
REMARQUE: Dans MDX les [ ] sont optionnels, excepté pour un nom avec des caractères
« espace » , avec des chiffres, ou qui sont des mots-clés MDX, quand ils sont requis.
En MDX les mesures sont des éléments d’une dimension spéciale nommée « Measures » (ces
mesures peuvent être utilisées aussi dans les clauses WHERE et FROM).
Dans cette requête, la clause FROM spécifie la source de données. Ici c’est un ou plusieurs
cubes.
Si plusieurs cubes nécessaires, cela implique une jointure multidimensionnelle : chaque paire
de cubes doit alors posséder au moins une dimension concordante
La clause SELECT indique les résultats que l’on souhaite récupérer par la requête. Les
« axes » sont utilisés pour éviter toute confusion avec les dimensions du cube. ON
COLUMNS indique que la donnée doit être représentée suivante une colonne tandis que ON
ROWS indique que la donnée doit être représentée suivante une ligne. WHERE indique les
restrictions sur le ou les cubes de départ.
SELECT
SELECT
Les requêtes que nous allons exécuter portent sur l’analyse du cube « Sales » de la datamart
« Foodmart ». Ce cube a été conçu pour l’analyse d’une chaine de magasins d’épicerie et leurs
promotions, clients et produits [1]. Les tables suivantes présentent les dimensions et mesures
associées à ce cube.
19
MONDRIAN/JPIVOT
20
MONDRIAN/JPIVOT
21
MONDRIAN/JPIVOT
Calculated Members
Display the store sales, store cost and profit made by stores.
WITH MEMBER [Measures].[ProfitPercent] as '(([Measures].[Store Sales] -
[Measures].[Store Cost]) / [Measures].[Store Cost])', FORMAT_STRING = "#.00%"
SELECT {[Measures].[Store Sales], [Measures].[Store Cost], [Measures].[ProfitPercent]}
ON COLUMNS,
NON EMPTY [Store].[Store Name].Members ON ROWS
FROM [Sales]
22
MONDRIAN/JPIVOT
23
MONDRIAN/JPIVOT
Conclusion
A priori, la performance du couple Mondrian/JPivot semble correcte. Au cours des
démonstrations réalisées, le serveur a tenu ses promesses en déployant rapidement des
tableaux croisés dans chacun des cubes. En ce qui concerne JPivot, l’interface, comme toute
interface web, perd en performance dès lors que le volume des données est trop grand, et ce
n’est non pas pour des questions de performance du serveur de Mondrian.
24
MONDRIAN/JPIVOT
Bibliographie :
25