Beruflich Dokumente
Kultur Dokumente
et les Systèmes
Multidimensionnels
1
1. Définition d’un Data warehouse
2
1. Définition d’un Data warehouse
1. 2. Données intégrées
1. 2 Données intégrées
3
1. Définition d’un Data warehouse
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.
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 7
1. 4 Données historisées
4
1. Définition d’un Data warehouse
1. 4 Données historisées
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
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 11
Bases de
Extraction Bases externes
production
Transformation
Chargement
Rafraîchissement
Outils
d’administration
Bases
multidimensionnelles
Datamarts
Outil ROLAP
6
3. Architecture d’un Data warehouse
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
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 13
EXTRACTION
7
3. Architecture d’un Data warehouse
TRANSFORMATION
TRANSFORMATION
8
3. Architecture d’un Data warehouse
CHARGEMENT/RAFRAICHISSEMENT
CHARGEMENT/RAFRAICHISSEMENT
9
3. Architecture d’un Data warehouse
LES OUTILS
3. 3 Dictionnaire de Données
10
3. Architecture d’un Data warehouse
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.
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 21
11
3. Architecture d’un Data warehouse
Modèles de présentation
Modèles de diffusion
Modèles d’intégration
12
3. Architecture d’un Data warehouse
3. 5 Les bases multidimensionnelles et les outils OLAP
13
3. Architecture d’un Data warehouse
3. 5 Les bases multidimensionnelles et les outils OLAP
3.5.3 Les 12 règles de E.F. CODD (1993)
14
3. Architecture d’un Data warehouse
3. 5 Les bases multidimensionnelles et les outils OLAP
3.5.3 Les 12 règles de E.F. CODD (1993)
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.
15
3. Architecture d’un Data warehouse
3. 5 Les bases multidimensionnelles et les outils OLAP
3.5.5 Les outils relationnels OLAP
Interface de
présentation
Hypercube virtuel
Base de données
relationnelle
16
3. Architecture d’un Data warehouse
3. 5 Les bases multidimensionnelles et les outils OLAP
3.5.6 Intégration Infocentre Hypercube
Hypercubes clients
Table de dimension
Table de dimension
Table de
Faits Table de dimension
Table de dimension
Table de dimension
Serveur relationnel
17
3. Architecture d’un Data warehouse
3. 5 Les bases multidimensionnelles et les outils OLAP
3.5.7 Les outils multidimensionnels MOLAP
Interface de
présentation
Serveur matriciel
18
3. Architecture d’un Data warehouse
3. 5 Les bases multidimensionnelles et les outils OLAP
3.5.7 Les outils multidimensionnels MOLAP
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
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 37
19
3. Architecture d’un Data warehouse
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.
20
4. Le Marché du Data warehouse
4. 1 Les solutions applicatives
21
4. Le Marché du Data warehouse
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.
Informix MetaCube
22
4. Le Marché du Data warehouse
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
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 45
GQL Requêteur
Andyne
Pablo Analyse OLAP
Impromptu Requêteur
Cognos
Powerplay Analyse OLAP
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.
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 47
24
5. Développement d’un Data warehouse
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.
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 49
25
5. Développement d’un Data warehouse
5. 2 Phase 1: découvrir et définir les initiatives
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.
26
5. Développement d’un Data warehouse
5. 3 Phase 2: définition de l ’infrastructure
5.3.2 Infrastructure organisationnelle
• 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…).
27
5. Développement d’un Data warehouse
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.
28
5. Développement d’un Data warehouse
5. 4 Phase 3: mise en œuvre des applications
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.
PI P2 P3
Itérative inter-projets
(pilote) (pilote)
Itérative inter-projets
(pilote)
Vision
projet
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
A minimiser pour préserver la fiabilité
Redondances et la cohérence du système Autorisées.
(normalisation).
Non. Pas de mises à jour en ligne.
Mises à jour Oui Mise à jour dans la phase de chargement/
rafraîchissement.
Nombre de tables
manipulées dans les Faible en général Elevé en général.
requêtes
• 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).
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 60
30
6. Modélisation des données d’un Data warehouse
6. 1 Introduction
6.1.2 Modèle multidimensionnel
ts n
JOUR
MOIS
i tan oye
ab m
’h at
LE re d ’ach
L
VI omb oir d
PRODUIT - n ouv
- libellé -p e
ag
- prix unitaire N h ôm
O c
GI de
R E au x
Copyright J. Akoka - I. Comyn-WattiauTYPE DE PRODUIT
- N.Prat -t 62
Un cube d’analyse des ventes
31
6. Modélisation des données d’un Data warehouse
N
MEDIA
N
UTILISE code_media
nom_media
utilisat_media prix_insertion
production_media
pourcent_limite
EST DU
1
TYPE_MEDIA
type_media
insertion
unite_media
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 64
32
6. Modélisation des données d’un Data warehouse
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)
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 65
33
6. Modélisation des données d’un Data warehouse
6. 3 Modélisation logique des données
6. 3.1 L’approche MAP (Akoka-Prat)
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)
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.
34
6. Modélisation des données d’un Data warehouse
Clé D1
Clé Dimension 1 (D1) Clé D2 Clé Dimension 2 (D2)
Attribut Clé D3 Attribut
Mesure
Dimension 3
35
CONSOMMATEUR
code_conso
y Exemple: CSP
age
PRODUIT
UTILISE
code_conso
code_media
utilisat_media
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 71
36
6. Modélisation des données d’un Data warehouse
type_media
insertion
CONSOMMATEUR unite_media
code_conso MEDIA
CSP
age code_media
revenu nom_media
sexe prix_insertion
ville production_media
etat_civil pourcent_limite
type_media
UTILISE
code_conso
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat code_media 73
utilisat_media
37
6. Modélisation des données d’un Data warehouse
6. 3 Modélisation Logique des données
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
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 75
38
7. Modélisation mathématique. Agrégations et
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
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 77
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
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).
8. Conclusion et perspectives
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…).
40
8. Conclusion et perspectives
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.
41