Systèmes d'information décisionnels

Systèmes d'information décisionnels
Master 1 - SIGLIS Master 2 SIGLIS Systèmes d'information décisionnels Stéphane Tallard Paramétrage d'un serveur OLAP Mondrian

Modrian est un moteur ROLAP :
Mondrian Modrian est un moteur ROLAP : il traduit des requêtes MDX en requêtes SQL il exécute les requêtes SQL sur une base relationnelle il renvoie les résultats sous une forme multidimensionnelle via une API Java. un schéma Mondrian permet de paramétrer la transformation de la base relationnelle en une base multidimensionnelle. Master SIGLIS

     Architecture de Mondrian 2013 - 2014 Master SIGLIS
 Analyseur de schéma XML  Interfaces (JRubik, Saiku, ..) Analyseur MDX  Gestion du cache + Générateur SQL  SGBD Relationnel Master SIGLIS

. . . Architecture datasources.xml
Décrit la liste des sources de données. . . . source1.xml sourcen.xml Chaque fichier se comporte comme une interface entre le SGBD et cube OLAP Master SIGLIS

On peut avoir n sources de données
datasources.xml Structure Les différents schémas sont regroupé par source de données (datasource) On peut avoir n sources de données Chaque datasource peut contenir plusieurs schémas contenus dans un catalogue DataSources DataSource Description de la source de données Catalogs Catalog Emplacement du schéma Contient notamment la chaîne de connexion à la base Chaque catalogue contient un chemin vers un fichier qui permet de faire une traduction BD relationnel / Cube OLAP DataSources DataSource Catalogs Catalog 1..n 1..n 1..n Master SIGLIS

Exemple : datasources.xml
<DataSources> <DataSource> <DataSourceName>MondrianFoodMart</DataSourceName> <DataSourceDescription>FoodMart 2000 Data Warehouse From MS Analysis Services</DataSourceDescription> <URL> <DataSourceInfo>Provider=mondrian; Jdbc=jdbc:odbc:MondrianFoodMart; JdbcDrivers=sun.jdbc.odbc.JdbcOdbcDriver</DataSourceInfo> <ProviderType>MDP</ProviderType> <AuthenticationMode>Unauthenticated</AuthenticationMode> <Catalogs> <Catalog name="FoodMart"> <Definition>/WEB-INF/schema/FoodMart.xml</Definition> </Catalog> <Catalog name="Marketing"> <DataSourceInfo>Provider=mondrian; Jdbc=jdbc:odbc:MarketingDB; JdbcDrivers=sun.jdbc.odbc.JdbcOdbcDriver</DataSourceInfo> <Definition>/WEB-INF/schema/Marketing.xml</Definition> </Catalog> </Catalogs> </DataSource> .... chaîne de connexion JDBC définition d'un fichier schéma Master SIGLIS

Le schéma Mondrian Le schéma Mondrian est un fichier XML
le schéma définit une base de données multi-dimensionnelle il contient un model logique composé de : cubes, de mesures, de dimensions ... d'une correspondance vers un model physique. les informations du schéma permettent de traduire les requêtes MDX en requêtes SQL le modèle physique ce sont les données source. Master SIGLIS

Le schéma mondrian est un fichier XML
Table de faits: le cube est défini à partir de la table de faits Une dimension peut contenir plusieurs hiérarchies. Par ex: La dimension temps contient les hiérarchies Année/Trimestre/Mois/ et Années/Saison (Printemps,été, hiver, printemps)/Semaines (S1 à S52). Schema Cube Table Dimension Hierarchy Level Measure Calculated Member * 1 * 1 * * * * A une hierarchie correspond une table (modèle en étoîle). Les mesures Si la hiérarchie est le temps structuré en Année/Trimestre/Mois alors Année, Trimestre et Mois constituent les levels de la hierarchie. Master SIGLIS

Exemple de schema 2013 - 2014 Master SIGLIS <Schema>
<Cube name="Sales"> <Table name="sales_fact_1997"/> <Dimension name="Gender" foreignKey="customer_id"> <Hierarchy hasAll="true" allMemberName="All Genders" primaryKey="customer_id"> <Table name="customer"/> <Level name="Gender" column="gender" uniqueMembers="true"/> </Hierarchy> </Dimension> <Dimension name="Time" foreignKey="time_id"> <Hierarchy hasAll="false" primaryKey="time_id"> <Table name="time_by_day"/> <Level name="Year" column="the_year" type="Numeric" uniqueMembers="true"/> <Level name="Quarter" column="quarter" uniqueMembers="false"/> <Level name="Month" column="month_of_year" type="Numeric" uniqueMembers="false"/> <Measure name="Unit Sales" column="unit_sales" aggregator="sum" formatString="#,###"/> <Measure name="Store Sales" column="store_sales" aggregator="sum" formatString="#,###.##"/> <Measure name="Store Cost" column="store_cost" aggregator="sum" formatString="#,###.00"/> <CalculatedMember name="Profit" dimension="Measures" formula="[Measures].[Store Sales]-[Measures].[Store Cost]"> <CalculatedMemberProperty name="FORMAT_STRING" value="$#,##0.00"/> </CalculatedMember> </Cube> </Schema> Le sales est calculé à partir de la table de faits sales_fact_1997 Cube sales dimension On a une table de faits, 2 tables de dimensions. Chaque niveau correspond à une partie de chaque table de dimension dimension Les mesures sont des attributs de la table de fait. les mesures Master SIGLIS

Définition des mesures
<Measure name="Unit Sales" column="unit_sales" aggregator="sum" formatString="#,###"/> <Measure name="Store Sales" column="store_sales" aggregator="sum" formatString="#,###.##"/> <Measure name="Store Cost" column="store_cost" aggregator="sum" formatString="#,###.00"/> <CalculatedMember name="Profit" dimension="Measures" formula="[Measures].[Store Sales]-[Measures].[Store Cost]"> <CalculatedMemberProperty name="FORMAT_STRING" value="$#,##0.00"/> </CalculatedMember> Le cube sales définit trois mesures chaque mesures a des propriétés : son nom (name) column (la colonne correspondante dans la table de faits ) un agrégateur (aggrégator) : sum, max, min, count, ... formatString indique comment la valeur est affichée il est possible d'utiliser un requête SQL pour calculer la valeur d'une mesure <Measure name="Promotion Sales" aggregator="sum" formatString="#,###.00"> <MeasureExpression> <SQL dialect="generic"> ( case when sales_fact_1997.promotion_id = 0 then 0 else sales_fact_1997.store_sales end) </SQL> </MeasureExpression> </Measure> Master SIGLIS

Les dimensions Définition un membre c'est un ensemble de valeurs particulières d'un attribut ex : Gender a deux membres 'M' et 'F' une hiérarchie est un ensemble de membres organisés en une structure ex : la dimension Store est organisé en magasins, ville, état et nation la hiérarchie permet de calculer des sous-totaux intermédiaires un niveau (level) est un item de la hiérarchie regroupant des membres une dimension est une collection de hiérarchies Master SIGLIS

Définition des dimensions
<Dimension name="Gender" foreignKey="customer_id"> <Hierarchy hasAll="true" allMemberName="All Genders" primaryKey="customer_id"> <Table name="customer"/> <Level name="Gender" column="gender" uniqueMembers="true"/> </Hierarchy> </Dimension> nom de l'attribut dans la table de faits nom de l'attribut dans la table Dimension La dimension "Gender" contient une seule hiérarchie constitué d'un seul niveau "Gender" Pour chaque vente, Gender indique le sexe de l'acheteur Les valeurs de la dimension se trouvent dans la colonne "gender" de la table customer Pour trouver le gender relié à un fait il faut faire une jointure entre la table sales_fact_1997 et customer sur l'attribut sales_fact_1997.customer_id et customer.customer_id Le membre "All Genders" est un membre fictif qui est l'ensemble des membres possibles Master SIGLIS

Hérarchies multiples l'attribut name est absent: on prend par défault le nom de la dimension <Dimension name="Time" foreignKey="time_id"> <Hierarchy hasAll="false" primaryKey="time_id"> <Table name="time_by_day"/> <Level name="Year" column="the_year" type="Numeric" uniqueMembers="true"/> <Level name="Quarter" column="quarter" uniqueMembers="false"/> <Level name="Month" column="month_of_year" type="Numeric" uniqueMembers="false"/> </Hierarchy> <Hierarchy name="Time Weekly" hasAll="false" primaryKey="time_id"> <Table name="time_by_week"/> <Level name="Week" column="week" uniqueMembers="false"/> <Level name="Day" column="day_of_week" type="String" uniqueMembers="false"/> </Dimension> Définit deux hiérarchies "Time" et "Time Weekly" basées sur les tables time_by_day et time_by_week Master SIGLIS

Définition d'une dimension temps
<Dimension name="Time" type="TimeDimension"> <Hierarchy hasAll="true" allMemberName="All Periods" primaryKey="dateid"> <Table name="datehierarchy"/> <Level name="Year" column="year" uniqueMembers="true" levelType="TimeYears" type="Numeric"/> <Level name="Quarter" column="quarter" uniqueMembers="false" levelType="TimeQuarters" /> <Level name="Month" column="month" uniqueMembers="false" ordinalColumn="month" nameColumn="month_name" levelType="TimeMonths" type="Numeric"/> <Level name="Week" column="week_in_month" uniqueMembers="false" levelType="TimeWeeks" /> <Level name="Day" column="day_in_month" uniqueMembers="false" ordinalColumn="day_in_month" nameColumn="day_name" levelType="TimeDays" </Hierarchy> </Dimension> La dimension "Year" correspond à l'attribut "year" de la table "datehierarchy" La dimension "Quarter" correspond à l'attribut "quarter" de la table "datehierarchy" La dimension "Month" correspond à l'attribut "month" de la table "datehierarchy" La dimension "Week" correspond à l'attribut "week_in_month" de la table "datehierarchy" uniqueMembers vaut "false" quand les valeurs sont partagés entre les membres du niveau supérieur (ex: on peut avoir deux fois le même jour pour deux mois différents) type="TimeDimension" permet d'utiliser des opérateurs spécifiques. L'attribut "levelType" permet de définir le type de la valeur ( TimeMonth  mois, TimeYears  anné , ... ) Master SIGLIS

Le cube Sales : la base relationnelle sous jacente
<Schema> <Cube name="Sales"> <Table name="sales_fact_1997"/> <Dimension name="Gender" foreignKey="customer_id"> <Hierarchy hasAll="true" allMemberName="All Genders" primaryKey="customer_id"> <Table name="customer"/> <Level name="Gender" column="gender" uniqueMembers="true"/> </Hierarchy> </Dimension> <Dimension name="Time" foreignKey="time_id"> <Hierarchy hasAll="false" primaryKey="time_id"> <Table name="time_by_day"/> <Level name="Year" column="the_year" type="Numeric" uniqueMembers="true"/> <Level name="Quarter" column="quarter" uniqueMembers="false"/> <Level name="Month" column="month_of_year" type="Numeric" uniqueMembers="false"/> <Measure name="Unit Sales" column="unit_sales" aggregator="sum" formatString="#,###"/> <Measure name="Store Sales" column="store_sales" aggregator="sum" formatString="#,###.##"/> <Measure name="Store Cost" column="store_cost" aggregator="sum" formatString="#,###.00"/> <CalculatedMember name="Profit" dimension="Measures" formula="[Measures].[Store Sales]-[Measures].[Store Cost]"> <CalculatedMemberProperty name="FORMAT_STRING" value="$#,##0.00"/> </CalculatedMember> </Cube> </Schema> Master SIGLIS

Les tables et les attributs utilisés pour les jointures

Le cube sales: les données des dimensions Gender et Time

Le cube Sales : Les mesures

mondrian-3.0-technical-guide_2-1
Référence L'exemple est basé sur un schéma en étoîle mondrian-3.0-technical-guide_2-1 Chapitre "How to design a Mondrian Schema" p.17 à 54 Master SIGLIS

A vous TD Entreprise Master SIGLIS

Systèmes d'information décisionnels

Présentations similaires

Présentation au sujet: "Systèmes d'information décisionnels"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Systèmes d'information décisionnels

Présentations similaires

Présentation au sujet: "Systèmes d'information décisionnels"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back