Systèmes d'information décisionnels

Name: Systèmes d'information décisionnels
Uploaded: 2017-10-31T09:56:42+00:00
Duration: PTM33S34
Channel: Gabrielle Damours
Description: 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 Ch4 - 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

Comment faire pour les schémas en flocon ?
Et les schémas en flocon ? L'exemple utilisé se base sur un schéma en étoile : une table de faits les dimensions sont implémentés par une table de dimension La table de faits est déclaré par le Tag Table en début du fichier Les tables de dimension sont déclarés dans le tag level à l'intérieur du tag Hierarchy Dans le tag hierarchy on déclare la table de dimension Dans chaque tag Level on déclare les attributs que l'on prend en compte Comment faire pour les schémas en flocon ? Master SIGLIS

Et les schémas en flocon ?
Pour les schémas en flocon on va utiliser le tag Join Pour les schémas en étoile le Tag Hierarchy contenait un tag Table Pour les schémas en flocon le Tag Hierarchy va contenir un tag Join qui va définir une jointure Le tag Join peut à son tour être composé par un autre tag Join Les Level vont faire référence à des attributs des tables mises en jeu dans la/les jointure Hierarchy Join Table 2 dimensions et 1 table par dimension Hierarchy Join Table 3 dimensions et 1 table par dimension Table Hierarchy Join Table Join Table Join Table 4 dimensions et 1 table par dimension Master SIGLIS

Exemple 1 La hiérarchie obtenue Le schéma de la base sous-jacente
La définition de la Hiérarchie H dans le schéma mondrian <Dimension type="StandardDimension" foreignKey="id_d1" name="H" > <Table name="fact"></Table> <Hierarchy name="H" hasAll="true" primaryKey="id_d1" primaryKeyTable="D1"> <Join leftKey="id_d2" rightKey="id_D2"> <Table name="d1"></Table> <Table name="d2"></Table> </Join> <Level name="att1" table="d1" column="att1" > </Level> <Level name="att2" table="d1" column="att2" > <Level name="att3" table="d2" column="att3" > <Level name="att4" table="d2" column="att4" > </Hierarchy> </Dimension> H att1 att2 att3 att4 La hiérarchie obtenue Master SIGLIS

Exemple 1 - Suite Le lien entre la table fact et D1 est fait par une jointure entre les attributs fact.id_d1 et D1.id_d1 <Dimension type="StandardDimension" foreignKey="id_d1" name="H" > <Table name="fact"></Table> <Hierarchy name="H" primaryKey="id_d1" primaryKeyTable="D1"> <Join leftKey="id_d2" rightKey="id_D2"> <Table name="d1"></Table> <Table name="d2"></Table> </Join> <Level name="att1" table="d1" column="att1" > </Level> <Level name="att2" table="d1" column="att2" > <Level name="att3" table="d2" column="att3" > <Level name="att4" table="d2" column="att4" > </Hierarchy> </Dimension> Le lien entre la table d1 et d2 et D1 est fait par une jointure entre les attributs D1.id_d2 et D2.id_d2 On extrait les attributs att1,att2,att3, att4 pour former les dimensions. Master SIGLIS

Exemple (2) La hiérarchie obtenue Le schéma de la base sous-jacente
La définition de la Hiérarchie H dans le schéma mondrian <Dimension type="StandardDimension" foreignKey="id_d1" name="H" > <Table name="fact"></Table> <Hierarchy name="H" hasAll="true" primaryKey="id_d1" primaryKeyTable="D1"> <Join leftKey="id_d1" rightKey="id_d1"> <Table name="d2"></Table> <Join leftKey="id_d3" rightKey="id_d3"> <Table name="d3"></Table> </Join> <Level name="att1" table="d1" column="att1" ></Level> <Level name="att2" table="d1" column="att2" ></Level> <Level name="att3" table="d2" column="att3" ></Level> <Level name="att4" table="d2" column="att4" ></Level> <Level name="att5" table="d3" column="att5" ></Level> <Level name="att6" table="d3" column="att6" ></Level> </Hierarchy> </Dimension> H att1 att2 att3 att4 att5 att6 La hiérarchie obtenue Master SIGLIS

mondrian-3.0-technical-guide_2-1
Référence 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