Systèmes d'information décisionnels

Slides:



Advertisements
Présentations similaires
REFERENTIEL DE LA SERIE STG
Advertisements

Etudes de cas A vous de faire Bases de données DRES – B. TALON.
Module 5 : Implémentation de l'impression
Bases de Données XML Natives
ACubeOLAP Client Olap en ACube.
Fonctionnalités des SGBD
Le Modèle Logique de Données
Algèbre relationnelle
Vue d’ensemble du Data warehousing et de la technologie OLAP
51 Les technologies XML Cours 6 : XML et les architectures N-tiers – Tier Métier Janvier Version 1.0 -
Relations avec les entity beans Michel Buffa UNSA
Intégrer vos données avec.
TP 3-4 BD21.
Gestion de la persistance des objets
Les fonctions.
1 ARCHITECTURE DACCÈS la méthode générale modèle de données définitions module daccès / modules métiers construction des modèles les modules daccès, les.
Les requêtes La Requête est une méthode pour afficher les enregistrements qui répondent à des conditions spécifiques. La requête est donc un filtre.
Initiation au système d’information et aux bases de données
Contrôles d'accès aux données
Mise en œuvre du langage MDX - 1 ère partie- Présentation de lexemple et des outils utilisés -1-
Plan du Cours Définition de la BI Objectif de la BI Fonctionnement d’une plateforme BI Technologies de la BI Composantes de la BI Les caractéristiques.
Modélisation E/R des Données
Chap 4 Les bases de données et le modèle relationnel
Les instructions PHP pour l'accès à une base de données MySql
Mapping Objet-Relationnel
L’utilisation des bases de données
EPID-CPI-ISAIP Philippe Bancquart - mise à jour 24/02/ page 1 SQL PHILIPPE BANCQUART.
Mise en œuvre du langage MDX
Mise en œuvre du langage MDX
1 PHP 1.Langage PHP 1.1. Types de base, variables et constantes 1.2. Opérateurs et expressions 1.3. Instructions 1.4. Fonctions 2.Accès aux bases de données:
Les concepts et les méthodes des bases de données
Module 5 : Publication de ressources dans Active Directory
EPID-CPI-ISAIP Philippe Bancquart - mise à jour 24/02/ page 1 SQL jointure PHILIPPE BANCQUART.
Introduction.
CSC All Reserved, Usinor Leading to Succes with CSC in the Business Intelligence Projects BW Petit Bateau 28 février 2002.
Mise en œuvre du langage MDX
Initiation MS Access 2010 Requêtes - Sélection (travail en autonomie)
Présentation du produit
JDBC L'API JDBC est utilisée pour utilisée pour intéragir avec une base de données.
CAS COMPTOIR (TD1 / SI3) TRANSFORMATION D’UN SI EXISTANT 1.
Créer des packages.
1 BDs Orientées Objets Witold LITWIN. 2 Pourquoi ? F Les BDs relationnelles ne sont pas adaptées aux applications CAD/CAM, cartes géo... F le problème.
Optimisation de requêtes
05/02/98WEB ESNIG Modèle logique de données Oracle Designer/2000 & Oracle Web Server.
1 PHP 5 Notions fondamentales (cours #5) Formation continue – Cégep de Sainte-Foy.
Master 1 - SIGLIS SID Pentaho Stéphane Tallard Notes.
P2. Le modèle multidimensionnel est bien adapté pour mesurer des données que l’on peut exprimer comme cela. Le modèle OLAP STD - Notes1.
Sélection de colonnes (la projection)
LE DATA WAREHOUSE.
MATHÉMATIQUES DISCRÈTES Chapitre 6 (relations)
Master 1 SIGLIS Intégration des données dans l’entreprise Stéphane Tallard JDBC: Java Database Connectivity Master 1 SIGLIS1JDBC.
1 Initiation aux bases de données et à la programmation événementielle Responsable : Souheib BAARIR. (le sujet de votre .
Modélisation des documents: DTD et Schéma
Quinio1 Bases de données : modèlisation et SGBD Séance 3 B Quinio.
Module 1 : Vue d'ensemble de Microsoft SQL Server
1 Structure en MC Principes Stockage des données dans la mémoire volatile d’un ordinateur Problèmes Stockage temporaire «Petits» volumes de données Langages.
Modèles des Data Warehouses
Des fonctions d’oubli intelligentes dans les entrepôts de données
Objectifs du développement Des agendas culturels et services quotidiens de La Libre Belgique et de La Dernière Heure et proposera des services d’informations.
Data warehouse pour le Data mining
SOAP et les RPC XML SOAP WSDL RPC. Rappels sur le XML Langage avec des balises Très lisible Pour stocker des données Séparation entre contenu et présentation.
Systèmes d'information décisionnels
Initiation aux bases de données et à la programmation événementielle
Op é rateurs ensemblistes Module 4. 2 La clause GROUP BY La clause GROUP BY est nécessaire dès que l'on utilise des fonctions de calculs statistiques.
Master 1 SIGLIS Java Lecteur Stéphane Tallard Correction du TD Chapitre 3.
DATA Warehouse Elabore par: Ajlani Wael Karous Nabil Salhi Mahmoud.
Cours 11 Entrepôts de données
Projet de session Par Eve Grenier Dans le cadre du cours SCG Réalisation d’applications en SIG Jeudi le 20 avril 2006.
PROJET DE SESSION PRÉSENTÉ PAR : Rosemarie McHugh DANS LE CADRE DU COURS : SCG Réalisation d’applications en SIG 16 avril 2007.
ARIANE : Interopérabilité sémantique et accès aux sources d'information sur Internet Sylvain Aymard, Michel Joubert, Dominique Fieschi, Marius Fieschi.
Transcription de la présentation:

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. 2013 - 2014 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 2013 - 2014 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 2013 - 2014 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 2013 - 2014 Master SIGLIS

Exemple : datasources.xml <DataSources>   <DataSource>     <DataSourceName>MondrianFoodMart</DataSourceName>     <DataSourceDescription>FoodMart 2000 Data Warehouse From MS Analysis Services</DataSourceDescription>     <URL>http://localhost:8080/mondrian/xmla</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 2013 - 2014 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. 2013 - 2014 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. 2013 - 2014 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 2013 - 2014 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> 2013 - 2014 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 2013 - 2014 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 2013 - 2014 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 2013 - 2014 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é , ... ) 2013 - 2014 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> 2013 - 2014 Master SIGLIS

Les tables et les attributs utilisés pour les jointures <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> 2013 - 2014 Master SIGLIS

Le cube sales: les données des dimensions Gender et Time <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> 2013 - 2014 Master SIGLIS

Le cube Sales : Les mesures <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> 2013 - 2014 Master SIGLIS

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 2013 - 2014 Master SIGLIS

A vous TD Entreprise 2013 - 2014 Master SIGLIS