6. Modélisation des données d`un Data warehouse

Transcription

Le Data Warehouse
et les Systèmes
Multidimensionnels
1
1. Définition d’un Data warehouse (DW)
• Le Data warehouse (entrepôt de données) est une
collection de données orientées sujet, intégrées, non
volatiles et historisées, organisées pour le support
d ’un processus d ’aide à la décision (Inmon, 94).
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat
2
1
1. Définition d’un Data warehouse
1. 1 Données orientées sujet
• Données structurées par thèmes (sujets majeurs de
l’entreprise) et non suivant les processus fonctionnels.
• Le sujet est transversal aux structures fonctionnelles et
organisationnelles de l’entreprise. On peut accéder aux
données utiles sur un sujet.
• L’intégration des différents sujets se fait dans une
structure unique.
3
1. 1 Données orientées sujet
• Il n ’y a pas de duplication des informations communes à
plusieurs sujets.
• La base de données est construite selon les thèmes qui
touchent aux métiers de l’entreprise (clients, produits,
risques, rentabilité, …).
• Les données de base sont toutefois issues des Systèmes
d’Information Opérationnels (SIO).
4
2
1. 2. Données intégrées
• Les données, issues de différentes applications de
production, peuvent exister sous toutes formes différentes.
• Il faut les intégrer afin de les homogénéiser et de leur
donner un sens unique, compréhensible par tous les
utilisateurs.
• Elle doivent posséder un codage et une description unique.
5
1. 2 Données intégrées
• La phase d’intégration est longue et pose souvent des
problèmes de qualification sémantique des données à
intégrer (synonymie, homonymie, etc…).
• Ce problème est amplifié lorsque des données externes
sont à intégrer avec les données du SIO.
6
3
1. 3 Données non-volatiles
• Une information est considérée volatile quand les
données sont régulièrement mises à jour comme dans les
Systèmes d’Information Opérationnels.
• Dans un SIO, les requêtes portent sur les données
actuelles. Il est difficile de retrouver un ancien résultat.
• Dans un DW, il est nécessaire de conserver l’historique
de la donnée. Ainsi, une même requête effectuée à deux
mois d’intervalle en spécifiant la date de référence de la
donnée, donnera le même résultat.
7
1. 4 Données historisées
• Dans un SIO, les transactions se font en temps réel, et les
données sont mises à jour constamment. L ’historique des
valeurs de ces données n ’est généralement pas conservé
car il est inutile.
• Dans un DW, la donnée n’est jamais mise à jour.
• Les données du DW s ’ajoutent aux données déjà
engrangées.=> ajout de couches de données successives, à
la manière des strates géologiques
8
4
1. 4 Données historisées
• Le DW stocke donc l’historique des valeurs que la
donnée aura prises au cours du temps.
• Un référentiel de temps est alors associé à la donnée afin
d’être capable d’identifier une valeur particulière dans le
temps.
• Les utilisateurs possèdent un accès aux données
courantes ainsi qu’à des données historisées.
9
1. 5 Support d ’un processus d ’aide à la décision
• Un DW est un système d ’information dédié aux applications
décisionnelles dont les principales contraintes sont :
• des requêtes complexes à plusieurs niveaux d ’agrégation
• la nécessité de disposer d ’informations synthétiques
(« reporting » de gestion, analyse des ventes, gestion de la
masse salariale, etc)
• le stockage des données sous une forme multidimensionnelle
• des mises à jour périodiques
10
5
2. Objectifs d’un Data warehouse
• permet le développement d ’applications décisionnelles et de
pilotage de l ’entreprise et de ses processus
• joue un rôle de référentiel pour l ’entreprise puisqu ’il permet de
fédérer des données souvent éparpillées dans différentes bases de
données
• offre une vision globale et orientée métier de toutes les données que
manipule l ’entreprise
• permet de faire face aux changements du marché et de l ’entreprise
• offre une information compréhensible, utile , rapide et à jour
11
3. Architecture d’un Data warehouse
Bases de
production
Dictionnaire
Bases externes
Extraction
Transformation
Chargement
Rafraîchissement
Data Warehouse
Outils
d’administration
Bases
multidimensionnelles
Datamarts
Outil ROLAP
Outils
multidimensionnels
MOLAP
Requeteur
ou tableau
Outil frontal
OLAP
12
6
3. 1 Les Bases de Données
• Bases de données internes:
•Bases de production de l’entreprise
•Bases créées par les utilisateurs
• Bases de données externes à l’entreprise qui nécessitent
leur identification, leur rapatriement et leur intégration.
•Données achetées à des fournisseurs de données
(Nielsen, INSEE, …)
•Données récupérées sur Internet
13
3. 2 Opérations sur les données
EXTRACTION
• Extraire les données de leur environnement d’origine
(bases de données relationnelles, fichiers plats, …).
• Utiliser une technique appropriée pour n ’extraire que
les données nécessaires : données créées ou modifiées
depuis la dernière opération d’extraction.
14
7
TRANSFORMATION
• Une même donnée peut avoir une structure ou une valeur
différente en fonction de la base (production, externe,
utilisateurs) dont elle provient.
• On peut être confronté à des redondances (un même
client peut apparaître avec différents attributs et
propriétés selon la source consultée).
15
TRANSFORMATION
• Il faut supprimer certaines données aberrantes qui
risqueraient de fausser les analyses.
• Il faut donc épurer et transformer les données.
16
8
CHARGEMENT/RAFRAICHISSEMENT
• Effectuer sur les données des opérations de calcul et
d’agrégation.
• Remplacer certaines bases si aucune
d’extraction satisfaisante n’est possible.
solution
17
CHARGEMENT/RAFRAICHISSEMENT
• Mettre en place des procédures de chargement et de
restauration (en cas de problème).
• Typiquement, la fréquence du chargement est quotidienne
et il est effectué en tout début de matinée.
• Si la disponibilité du système ne peut être interrompue,
envisager la mise en place de systèmes redondants.
18
9
LES OUTILS
• On peut automatiser tout ou partie des opérations décrites.
• Des outils sont disponibles : Extract d’ETI, Genio de
Leonard ’s Logic, SAS/Warehouse Administrator de
SAS…
• Le développement d’outils spécifiques est envisageable
mais risque d ’alourdir les tâches.
19
3. 3 Dictionnaire de Données
• Le dictionnaire de données regroupe les méta-données.
• Une méta-donnée représente une donnée sur les données.
Il s’agit de l’ensemble des informations qui permettent de
qualifier une donnée, notamment par sa sémantique, sa
règle de calcul, sa provenance, sa qualité, etc…
• les méta-données permettent de préciser de quelle table
provient la donnée, à quelles dates et heures elle en a été
extraite, l’état de la base à cet instant, etc...
20
10
3. 3 Dictionnaire de Données
• Une méta-donnée permet de « remonter la chaîne » et de
reconstituer l’ensemble d’événements et données qui ont servi à
obtenir l’information associée.
• Le dictionnaire de données contient toutes les informations
permettant d’exploiter les données.
• C’est un référentiel destiné aux utilisateurs et à l’administrateur
du DW.
• A ce jour, il n’existe pas de normes en ce qui concerne la
structure et la gestion des dictionnaires de données. Chaque outil
propose sa solution et son approche.
21
3. 4 Les Data Marts
• Un data mart (magasin de données) est un DW focalisé sur un
sujet particulier, souvent au niveau départemental ou métier.
• C ’est donc un mini DW lié à un métier particulier de l ’entreprise
(finance, commercial, …).
• Un DW est souvent volumineux (plusieurs centaines de Go voire
quelques To ) avec des performances inappropriées (temps de
réponse trop longs). Un Data mart, quant à lui, comporte moins
de 50 Go, ce qui permet des performances acceptables.
• La création d’un data mart peut être un moyen de débuter un
projet de DW (projet pilote).
22
11
3. 5 Les bases multidimensionnelles et les outils OLAP
3.5.1 Les modèles de
données
Modèles de présentation
Modèles de diffusion
Modèles d’intégration
Bases de données opérationnelles
23
3.5.1 Les modèles de données
• Le modèle d ’intégration unifie les données opérationnelles.
• Le modèle de diffusion représente le modèle conceptuel des
données. Il correspond aux bases multidimensionnelles (serveur
OLAP).
• Le modèle de présentation est un complément au modèle
conceptuel. C’est à travers ce modèle que l’utilisateur voit les
données. Il correspond à différents outils physiques : les
tableurs, les requêteurs, les outils clients OLAP, etc...
24
12
3.5.2 Les outils OLAP (On-Line Analytical Processing)
• OLAP caractérise l’architecture nécessaire à la mise en place
d ’un système d’information décisionnel (SID).
• OLAP s’oppose à OLTP (On-Line Transactional Processing)
qui caractérise les SIO.
25
3.5.2 Les outils OLAP (On-Line Analytical Processing)
• OLAP constitue l’ensemble des outils multidimensionnels
nécessaires à l’accès, stockage et à la manipulation des données
utiles pour un SIAD ou pour un EIS.
• OLAP désigne les outils d ’analyse s’appuyant sur les bases de
données multidimensionnelles.
26
13
3.5.3 Les 12 règles de E.F. CODD (1993)
Vue multidimensionnelle : Les données sont structurées en dimensions
métiers.
Transparence : L ’utilisateur doit pouvoir utiliser les logiciels habituels
(tableurs, …) sans percevoir la présence d ’un outil OLAP.
Accessibilité : L ’outil doit se charger d ’accéder aux données stockées
dans n ’importe quel type de bases de données (interne + externe) et le
faire simultanément.
Performance continue dans les restitutions : A mesure que le nombre
de dimensions ou la taille de la base augmente, l’utilisateur ne doit pas
subir de baisse sensible de performance.
27
Architecture client-serveur : Tout produit OLAP doit fonctionner en
mode C/S avec une répartition des traitements.
Dimension générique : Chaque dimension (avec l’analyse) doit
être équivalent aux autres à la fois dans sa structure et dans ses capacités
opérationnelles. Une seule structure logique dans l’ensemble des
dimensions.
Gestion dynamique des matrices creuses : OLAP doit gérer les cellules
non renseignées de manière optimale.
Support multi-utilisateurs : OLAP doit assurer un accès simultané aux
données, gérer l’intégrité et la sécurité de ces données.
28
14
Opérations entre les dimensions : OLAP doit gérer des calculs associés
entre les dimensions sans faire appel à l ’utilisateur pour définir le
contenu de ces calculs
Manipulation intuitive : Minimiser le recours à des menus ou les allers
et retours avec l ’interface utilisateur
Flexibilité des restitutions : convivialité des états de gestion ou des états
de sortie - ergonomie
Nombre de dimensions et niveaux de hiérarchie illimité : l ’outil doit
gérer au moins quinze dimensions et ne pas limiter le nombre de niveaux
hiérarchiques.
29
3.5.4 Fast Analysis of Shared Multidimensional Information (FASMI)
Analyse : fournir des possibilités d ’analyse (statistiques et autres)
Rapide : l ’essentiel des réponses doit être rendu dans un délai de moins
de cinq secondes
Information : accéder à l ’ensemble des données indépendamment de
leur localisation
Multidimensionnelle :fournir une vue conceptuelle multidimensionnelle
Partagée : être accessible à un grand nombre d ’utilisateurs et ne pas
limiter le nombre de niveaux hiérarchiques.
30
15
3.5.5 Les outils relationnels OLAP
Outils relationnels : requêteurs, infocentres, jointures complexes
exemple : Business Objects (anciennes versions)
Hypercubes relationnels : les données sont stockées dans une BD
relationnelle, mais avec une structure adaptée aux données multidimensionnelles
exemple : SGBD relationnels
OLAP relationnel (ROLAP) : ces outils utilisent directement le modèle
relationnel. Au travers des méta-données, ils permettent de transformer
l ’analyse multidimensionnelle en requêtes SQL : distinguent les axes
d ’analyse et les faits à observer (modèles en étoile ou en flocon)
31
3.5.5 Les outils relationnels OLAP
Interface de
présentation
Hypercube virtuel
Base de données
relationnelle
32
16
3.5.6 Intégration Infocentre Hypercube
y Principe proche de l ’OLAP relationnel
y Intégration d ’un outil d ’infocentre et d ’un outil d ’analyse
multidimensionnelle dans une même interface située sur le poste
client
y L ’outil d ’infocentre assure la gestion d ’un référentiel commun, la
sélection des données et leur valorisation
y L ’outil multidimensionnel assure la création d ’un hypercube,
l ’implémentation des fonctionalités OLAP (consolidation, zoom
avant, glisser-déplacer, gestion des seuils, etc.)
33
3.5.6 Intégration Infocentre Hypercube
Hypercubes clients
Table de dimension
Table de dimension
Table de dimension
Serveur relationnel
Table de
Faits
Table de dimension
Table de dimension
34
17
3.5.7 Les outils multidimensionnels MOLAP
y Les BD multidimensionnelles sont propriétaires (pas de
standard)
y Les données sont dynamiquement structurées et compressées
(optimisation de l ’espace disque)
y Les données sont organisées en dimensions et hiérarchies
y Les formules de calcul sont généralement complexes
y Les temps de réponse sont constants
35
Interface de
présentation
Serveur matriciel
36
18
y La constitution de la base se fait selon le processus suivant
y extraction des données provenant des SGBD ou fichiers
y décomposition des données en dimensions, attributs et variables
y calcul des consolidations
y chargement de l ’hypercube selon la structure dimensionnelle
choisie
y L ’interrogation de la base possède les caractéristiques suivantes :
y interface graphique (drill down, slice and dice, etc)
y gestion des seuils et des alertes (codage couleurs)
y temps de réponse court et constant
y SQL non implémenté
y Exemple : Oracle Express
37
3. 6 Les limites du multidimensionnel
y Format et langage propriétaire
y Structure figée (l’hypercube doit être construit à chaque
modification)
y Accès au détail difficile
y Peu d ’outils disponibles
y Outils d ’administration insuffisants
y Difficulté de réaliser des sélections sur un hypercube
y Pas de standard ni pour la structure physique ni pour
l ’interrogation
y Manque de souplesse et absence de gestion de méta-données
38
19
3. 7 Conclusion
y Un marché florissant
y nombreux outils (ROLAP,MOLAP,..)
y concentration du nombre d ’éditeurs de logiciels
y Nécessité de méthodologie de conception
y démarche
y modélisation conceptuelle et logique
y implication des utilisateurs
y Un avenir réel
y l’informatique opérationnelle est mature
y la demande des utilisateurs est importante
y la technologie est disponible.
39
4. Le Marché du Data warehouse
y Le marché du décisionnel regroupe une trentaine d’acteurs
y Les éditeurs peuvent être regroupés en quatre catégories
y solutions applicatives
y bases de données multidimensionnelles
y client ROLAP
y client OLAP
40
20
4. 1 Les solutions applicatives
y L’offre la plus ancienne
y l’offre verticale (spécialisée dans un secteur tel que la banque ou
la grande distribution)
y l’offre horizontale (consacrée à une fonction précise)
y l’offre fondée sur un progiciel
y l’éditeur intègre généralement dans sa solution une base de
données multidimensionnelle
41
4. 1 Les solutions applicatives
y exemples de produits :
Editeur
Produit
Fonction
Comshare
Boost sales and marging planning
Boost sales analysis
Prévision, planification
Analyse des ventes
Hyperion Software
Oracle
SAS Institute
Commander budget
Elaboration budgétaire
Commander FDC
Reporting, consolidation
Hyperion entreprise
Reporting, consolidation
Hyperion Pilar
Oracle financial analyser
Oracle sales analyser
Analyse des ventes
CFO Vision
Reporting
42
21
4. 2 Bases de données multidimensionnelles
y Quatre acteurs principaux répartis en deux catégories :
y les spécialistes qui fournissent une technologie
multidimensionnelle performante
y les fournisseurs de solutions complètes capables de fournir
en plus de la base de données, un environnement de
développement, d’interrogation et d’administration.
Catégorie
Editeur
Produit
Spécialistes
Arbor Software
Aplix
Essbase
TMI
Autres
(environnement intégré)
Oracle
Gentia Software
Express
Gentia
43
4. 3 Client ROLAP
y Offre la plus récente sur le marché
y l ’information est stockée dans une base de données
relationnelle et un dictionnaire permet de faire apparaître
l ’information sous forme multidimensionnelle
y l ’administrateur offre à l ’utilisateur un point de vue
multidimensionnel sur une base relationnelle
y les principaux acteurs sont :
Editeur
Produit
Business Objects
Business Objects
Microstrategy
DSS Agent
Information Advantage
Decision Suite
Informix
MetaCube
Platinum Technology
Info Beacon
44
22
4. 4 Client OLAP
y Utilisation d ’un outil d’infocentre pour interroger les données
relationnelles, puis représenter l’information récupérée sous
forme multidimensionnelle
y solution proposée par les éditeurs d’infocentre
y deux outils sont utilisés : l’analyse multidimensionnelle et
l’infocentre relationnel
y inconvénients :
y pour alimenter l’outil multidimensionnel, il faut rapatrier un
volume de données important de la base relationnelle vers
l’outil
y le stockage physique des données multidimensionnelles
s’effectue sur le poste de travail, ce qui entraîne une
redondance des données
45
4. 4 Client OLAP
y ces systèmes sont appelés DOLAP, pour Desktop OLAP
y principaux acteurs :
Editeur
Editeur
Fonction
Andyne
GQL
Pablo
Requêteur
Analyse OLAP
Cognos
Impromptu
Powerplay
Requêteur
Analyse OLAP
46
23
5. Développement d’un Data warehouse
5. 1 Introduction
5.1.1 Caractéristiques d ’un data warehouse à prendre en compte
• 4 caractéristiques du data warehouse jouent un rôle fondamental
dans les projets de ce type:
•Les évolutions technologiques: client-serveur et systèmes
ouverts permettent de construire le data warehouse par
intégration des composants les + adaptés.
•Le lien implicite à la stratégie de l ’entreprise: data
warehouses + proches de la stratégie de l ’entreprise que les
systèmes transactionnels.
•Une logique d ’amélioration continue (évolution des
demandes des utilisateurs, nouveaux objectifs de l ’entreprise)
•Un niveau de maturité (acquis décisionnel) différent selon
les entreprises.
47
5. 1 Introduction
5.1.2 Phases du processus de développement
• Démarche proposée=démarche incrémentale: le data warehouse
est construit application par application (décomposition en sousprojets ou « initiatives »).
• 3 grandes phases dans un projet de data warehouse:
•« Découvrir et définir les initiatives »: niveau entreprise;
distinction de 2 sous-phases: étude stratégique et élaboration
du plan d ’action.
•Définition de l ’infrastructure technique et organisationnelle
du data warehouse, conduite du changement: niveau entreprise.
•Mise en œuvre incrémentale des applications: niveau
projet.
48
24
5. 2 Phase 1: découvrir et définir les initiatives
5.2.1 Etude stratégique
• Rôle fondamental.
• Etape 1: sensibilisation, « sponsorship », préparation au
changement.
•Chaque acteur doit être convaincu de la nécessité et de
l ’importance du projet de data warehouse, et de la nécessité de
son implication.
•Rôle du sponsor du projet.
• Etape 2: identification des objectifs métier/entreprise assignés au
data warehouse.
•Effectuée par collaboration entre management, équipes
opérationnelles et équipes informatiques.
49
5.2.1 Etude stratégique
• Etape 3: identification des sous-projets (initiatives) permettant
d ’atteindre les objectifs précédemment identifiés.
•Les initiatives sont ordonnancées par priorité.
•Les initiatives sont indépendantes, bien délimitées, et leur
mise en œuvre est relativement courte (moins de 6 mois en
général).
50
25
5.2.2 Elaboration du plan d ’action
• Etape 1: étude de faisabilité (existence et qualité des données,
contraintes techniques et organisationnelles).
• Etape 2: analyse coûts/bénéfices.
•Exemples: coût de développement, coût du matériel et du
logiciel…
•Estimations ne sont pas détaillées.
•Estimations sont de moins en moins détaillées selon le niveau
de priorité de l ’initiative.
• Etape 3: séquencement et planification des projets.
51
5. 3 Phase 2: définition de l ’infrastructure
5.3.1 Infrastructure technique
• Choix du ou des fournisseur(s) de technologies: choix entre un
unique fournisseur et plusieurs fournisseurs…
• Choix des outils: construire, acheter ou faire avec l ’existant?
• Choix
de
l
’architecture
du
data
warehouse:
centralisée/distribuée/répliquée, Intranet…
• Choix de la structure de stockage: relationnelle,
multidimensionnelle…
• Choix du matériel
• Choix des infrastructures destinées à l ’administration des
systèmes, à la gestion de la sécurité…
• …
52
26
5.3.2 Infrastructure organisationnelle
• Organisation typique des équipes de développement et
d ’exploitation:
•Un 1er centre de compétences responsable de l ’alimentation
du data warehouse à partir des systèmes de production.
•Un second centre de compétences responsable de la gestion et
du support du data warehouse proprement dit. Rôle des
administrateurs de bases de données.
•Un 3è centre de compétences responsable des flux
d ’informations entre les utilisateurs et leur poste de travail
d ’une part, et le data warehouse d ’autre part.
53
5.3.3 Conduite du changement
• Rôle de la formation.
• Rôle des sponsors. Il est souvent souhaitable d ’identifier un
sponsor par initiative, chaque sponsor étant généralement
associé à une entité opérationnelle (marketing, finance,
ressources humaines…).
54
27
5. 4 Phase 3: mise en œuvre des applications
5.4.1 Les 5 étapes
• Etape 1: étude préalable
•Définition et planification des étapes suivantes de manière
plus précise et détaillée que dans les phases précédentes.
•Analyse de l ’existant
•Etude des besoins.
• Etape 2: étude détaillée (cf. parties 6 et 7 + loin)
•Modélisation conceptuelle des données
•Modélisation logique multidimensionnelle
•Modélisation mathématique: définition des agrégations et des
formules.
55
5.4.1 Les 5 étapes
• Etape 3: réalisation
•Définition de l ’interface homme-machine
•Implémentation physique
•Intégration.
• Etape 4: déploiement
• Etape 5: mesures
•Bilan de la mise en œuvre de l ’application de data warehouse
(capitalisation d ’expérience)
•Mesures doivent être effectuées régulièrement.
56
28
5.4.2 Démarche itérative
• Mise en œuvre des applications peut s ’effectuer selon une
approche itérative, de type RAD (Rapid Application
Development).
• Phase de mise en œuvre des applications découpée en deux
sous-phases, avec déroulement des 5 étapes à chaque fois:
•Développement d ’un prototype (pilote)
•Déploiement, généralisation du pilote.
57
Projet 2
(déploiement)
Itérative inter-projets
Projet 3
(pilote)
Vision
projet
Projet 1
(déploiement)
Projet 2
(pilote)
P3
Projet 1
(pilote)
P2
PI
Vision
d’entreprise
5. 5 Conclusion: schéma général du processus
Projet 3
(déploiement)
Vision
d’entreprise
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat Incrémentale : multi projet
58
29
6. Modélisation des données d’un Data warehouse
6. 1 Introduction
6.1.1 Nécessité de techniques de modélisation spécifiques
Système transactionnel
Data warehouse
Redondances
A minimiser pour préserver la fiabilité
et la cohérence du système
(normalisation).
Autorisées.
Mises à jour
Oui
Non. Pas de mises à jour en ligne.
Mise à jour dans la phase de chargement/
rafraîchissement.
Modèle de données
Utilisateur n ’accède pas directement au modèle Utilisateur a un accès direct au modèle
de données.
de données.
Volumes de données
Résultats des transactions : volumes limités.
Requêtes manipulent souvent de gros
volumes de données.
Nombre de tables
manipulées dans les
requêtes
Faible en général
Elevé en général.
Requêtes prévisibles
Oui
Non dans de nombreux cas.
59
6. 1 Introduction
6.1.2 Modèle multidimensionnel
• 3 concepts fondamentaux:
•Les faits mesurent l ’activité. Les faits sont toujours
numériques. Les faits les plus importants et les plus utiles
sont valorisés de façon continue et additifs.
•Les dimensions sont les axes d ’analyse. Elles peuvent être
organisées en hiérarchies telles que la géographie, le
temps…
•Les attributs des dimensions qualifient celles-ci.
Typiquement, les attributs sont textuels et discrets (par
opposition aux faits).
60
30
6. 1 Introduction
• Opérations fondamentales sur des bases multidimensionnelles:
•Drill-down (une donnée agrégée est visualisée à un niveau
de détail plus fin) et consolidation (les données sont
visualisées à un niveau plus agrégé). Le drill-down et la
consolidation se fondent sur l utilisation des hiérarchies entre
dimensions, et des fonctions agrégées (somme, nombre, min,
max, moyenne).
•Slicing and dicing: visualisation des données selon
différentes perspectives.
61
6. 1 Introduction
TRIMESTRE
ANNEE
DIMENSION
Attribut de dimension
Fait
CA
JOUR
MOIS
ts n
an oye
t
i
ab m
’h at
E re d ’ach
L
L
VI omb oir d
PRODUIT
- n ouv
e
- libellé
-p
ag
ôm
- prix unitaire
N
h
O c
GI de
R E au x
DE PRODUIT
-t
Copyright J. Akoka - I. Comyn-WattiauTYPE
- N.Prat
Un cube d’analyse des ventes
62
31
6. 2 Modélisation Conceptuelle des données
y La plupart des démarches proposées aujourd’hui font l’impasse
sur cette phase
y Seuls Thomsen (Building Multidimensional Information
Systems, Wiley, 1997) et Akoka-Prat (Modélisation logique des
systèmes multidimensionnels, Revue des Systèmes de Décision,
1997) proposent une phase conceptuelle.
y Principe :
y établir un modèle conceptuel entité-association
y traduire ce modèle sous forme logique multidimensionnelle
par des règles de mapping
y transformations décrites plus loin
63
6. 2 Modélisation Conceptuelle des données
y Exemple : SIAD de
média-planning
CONSOMMATEUR
N
N
ACHETE
code_conso
CSP
age
revenu
sexe
ville
etat_civil
unites_par_sem
N
PRODUIT
code_produit
nom_produit
unite_produit
MEDIA
UTILISE
utilisat_media
N
code_media
nom_media
prix_insertion
production_media
pourcent_limite
N
EST DU
1
TYPE_MEDIA
type_media
insertion
unite_media
64
32
6. 3 Modélisation logique des données
6. 3.1 L’approche MAP (Akoka-Prat)
y LES CONCEPTS
y Une dimension est une donnée élémentaire permettant d’identifier
un objet (ex : code d ’un produit). C’est l ’axe d ’analyse
y Une variable permet de gérer les données multidimensionnelles.
Elle représente une quantité mesurable, un fait observé. Elle peut
être monodimensionnelle ou multidimensionnelle (ex : des unités
consommées peuvent être dimensionnées par un consommateur,
un produit...)
y Une relation caractérise un lien existant entre les dimensions,
deux ou plus (ex : lien entre le code d ’un média et le type du
média correspondant)
65
y LA DEMARCHE
y effectuer la modélisation conceptuelle à l ’aide du modèle entitéassociation
y simplifier le schéma entité-association ainsi obtenu en :
y éliminant les associations d’ordre supérieur à 3
y éliminant les associations réflexives
y traduire le schéma ainsi simplifié en schéma multidimensionnel à
l’aide des règles de transformation suivantes :
y l’identifiant de chaque entité E-A devient une dimension dans
le schéma logique multidimensionnel
y les propriétés portées par une entité (autres que son identifiant)
deviennent des variables monodimensionnelles liées à la
dimension de cette entité
66
33
y LA DEMARCHE
y les propriétés portées par les associations du schéma conceptuel
deviennent des variables multidimensionnelles dont les
dimensions sont les identifiants des entités liées à l’association
y (un lien d’héritage entre deux entités est traduit par une relation
dans le schéma logique multidimensionnel)
67
y LA DEMARCHE
y une association dont une des cardinalités maximales au moins est
égale à 1 est traduite par une relation dans le modèle logique
multidimensionnel
y toute autre association est traduite au moyen d’une variable
multidimensionnelle liée à l’identifiant de chacune des entités
impliqués dans l ’association, sauf si l ’association est porteuse
d ’au moins une propriété dont la valeur est toujours définie.
68
34
6. 3 Modélisation Logique des données
6.3.2 Le modèle en étoile
y Le modèle en étoile se compose de deux type de table :
y les tables de dimensions qui représentent les axes d ’analyse.
Chaque table de dimension possède un ensemble d’attributs
permettant de décrire les aspects importants de cette
dimension. Chaque table est identifiée par une clé
y la table de faits concerne l’ensemble des mesures de
l’activité. Les enregistrements de cette table sont identifiés
par une clé composée de la concaténation des clés des tables
de dimension
69
6.3 Modélisation Logique des données
6.3.2 Le modèle en étoile
y Il s ’agit d ’un modèle dénormalisé. Les tables de dimension sont
plates. Il existe une grande redondance des données
Dimension 1
Faits
Dimension 2
Clé Dimension 1 (D1)
Attribut
Clé D1
Clé D2
Clé D3
Mesure
Attribut
Dimension 3
Attribut
70
35
CONSOMMATEUR
y Exemple:
SIAD de
planning
y
y
média-
On distingue 2 étoiles (structure
multiétoile)
les relations entre étoiles sont
possibles par le biais de
dimensions communes à deux
ou plusieurs étoiles (ex : la
dimension consommateur est
commune aux 2 étoiles)
code_conso
CSP
age
revenu
sexe
ville
etat_civil
PRODUIT
code_produit
nom_produit
unite_produit
ACHETE
code_conso
code_produit
unites_par_sem
CONSOMMATEUR
MEDIA
code_conso
CSP
age
revenu
sexe
ville
etat_civil
code_media
nom_media
prix_insertion
production_media
pourcent_limite
type_media
insertion
unite_media
UTILISE
code_conso
code_media
utilisat_media
Règles de passage ER
71
Î modèle en étoile
•Règle 1 : Toute association binaire M-N ou ternaire ou plus
porteuse de propriétés devient une table de faits identifiée par
les clés des entités participantes.
•Règle 2 : Toute entité participant à une association de la règle 1
devient une table de dimensions reliée à la table de faits.
•Règle 3 : Toute entité E1 reliée à une entité E2 de la règle 2 par
une relation 1:N est transcrite dans la table de dimension de E2.
un chemin de relations 1:N est transcrite dans la table de
dimensions de E2.
72
36
6.3.3 Le modèle en flocon
y Ce modèle est dérivé de celui en étoile. Toutefois, les tables de
dimensions sont normalisées et les redondances éliminées
TYPE_MEDIA
y exemple : Cas média-planning (partiel)
type_media
insertion
unite_media
CONSOMMATEUR
code_conso
CSP
age
revenu
sexe
ville
etat_civil
MEDIA
code_media
nom_media
prix_insertion
production_media
pourcent_limite
type_media
UTILISE
code_conso
code_media
utilisat_media
Règles de passage ER
73
Î modèle en flocon
•Règle 1 : Toute association binaire M-N ou ternaire ou plus
porteuse de propriétés devient une table de faits identifiée par
les clés des entités participantes.
•Règle 2 : Toute entité participant à une association de la règle 1
devient une table de dimensions reliée à la table de faits.
une relation 1:N devient une sous-table de dimensions reliée à la
table issue de la règle 2.
•Règle 4 : Toute entité E1 reliée à une entité E2 traduite en une
sous-table de dimension en devient une sous-table de
dimensions.
74
37
6.3.4 Comparaison des modèles en étoile et en flocon
y Le modèle en flocon offre une vue plus claire de la structure de
l’information permettant notamment de déceler une hiérarchie
y la normalisation de ce modèle permet de plus de diminuer la
redondance, en réduisant la taille des tables de dimension. A
noter que Kimball a évalué le gain de place disque à 1 % de
l’espace disque total
y Kimball préfère le modèle en étoile sur la base de deux
arguments :
y la dénormalisation permet d ’améliorer les performances du
système lors de l ’exécution des requêtes
y le modèle est plus facile à apprendre par l ’utilisateur non
informaticien
75
7. Modélisation mathématique. Agrégations et
formules
y Formules : Quatre types de formules
y Descriptive : pour le choix d’alternative (ex : réparer un pont ou
en construire un nouveau)
y Prédictive : pour prédire des valeurs non mesurées (ex : si le taux
d’intérêt est corrélé avec une augmentation des ventes
domestiques, la formule prédictive déduira d ’une diminution des
taux d ’intérêt l ’augmentation future des ventes)
y Exploratoire : représentant les relations entre données (ex :
l’analyse de régression statistique)
y Prescriptive : ce sont de simples descriptions, ne comportant pas
de comparaisons (ex : les agrégations)
76
38
formules
y Agrégations :
y Formules d’agrégations : composante clé du modèle
multidimensionnel (ex : sommes, moyennes, équations pondérées
conditionnelles)
y Formules non agrégatives : formules les plus couramment
utilisées (ex : ratios, produits, différences)
y Fonctions attachées aux dimensions ou aux règles : dans le cas de
ratios ou de formules à opérations multiples, il est préférable de
passer par des règles. Dans le cas d’une fonction à appliquer par
défaut avec des exceptions, il est préférable d’attacher la fonction
à la dimension
77
formules
y Agrégations :
y Qualifications : lors de la rédaction de formules, il faut vérifier si
celles-ci sont justes pour la totalité de la hiérarchie
y Précédence des calculs : préciser l’ordre des calculs entre
différentes dimensions lorsque ceux-ci peuvent produire un
résultat différent
y Formules conditionnelles : utilisées dans le cas d’exceptions
connues
78
39
8. Conclusion et perspectives
8. 1 Conclusion
y Le data warehouse est probablement, avec Internet, l ’une des
tendances récentes que les entreprises exploiteront de + en +
dans les années à venir. Sujet « brûlant ».
y Le data warehouse est le cœur, l ’ossature du système
d ’information décisionnel.
y % des investissements informatiques consacrés à la production
et à la gestion devrait s ’inverser d ’ici 2003 au profit de
l ’informatique décisionnelle (source: Meta Group).
y Systèmes d ’information décisionnels = élément de
différentiation entre les entreprises (par opposition aux systèmes
transactionnels avec les ERP).
79
8. 2 Quelques perspectives
y Agents « intelligents »:
yUn agent agit pour un utilisateur sans solliciter son
intervention explicite.
yUn agent « intelligent » est capable d ’apprendre en fonction
d ’événements extérieurs.
yTechnique de « push » (≠ « pull »): L ’utilisateur est averti
des événements remarquables (CA en-dessous d ’un seuil
prédéfini…).
80
40
8. 2 Quelques perspectives
y Internet:
yComplémentarité Internet/data warehouse.
yInternet=moyen d ’acquisition de données externes.
yIntranet/Extranet=moyen d ’accès au data warehouse.
y CRM:
yCustomer Relationship Management (Gestion de la Relation
Client)
yUn des domaines d ’application privilégiés du data
warehouse.
81
41

6. Modélisation des données d`un Data warehouse

Transcription

Documents pareils

TENNIS WAREHOUSE EUROPETM

Entraînement à l`ASSR 2016 - Cité Scolaire Bertran-de-Born

Data Warehouse

Oeuvres complètes

Accueil de loisirs Du bas couserans

didier daubeach - Innovative Artists

À VENDRE | FOR SALE 320 boul. McCaffrey

SERVICE DES AFFAIRES CULTURELLES Allée de la Mairie B.P.

Piccolo Teatro - Biovacances.Net