Vous êtes sur la page 1sur 41

Le Data Warehouse

et les Systèmes
Multidimensionnels

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.

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 3

1. Définition d’un Data warehouse

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).

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 4

2
1. Définition d’un Data warehouse

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.

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 5

1. Définition d’un Data warehouse

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.

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 6

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. Définition d’un Data warehouse

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
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 8

4
1. Définition d’un Data warehouse

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.

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 9

1. Définition d’un Data warehouse


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 multi-
dimensionnelle
• des mises à jour périodiques
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 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
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 11

3. Architecture d’un Data warehouse

Bases de
Extraction Bases externes
production
Transformation
Chargement
Rafraîchissement

Dictionnaire Data Warehouse

Outils
d’administration
Bases
multidimensionnelles
Datamarts

Outil ROLAP

Outils Requeteur Outil frontal


multidimensionnels ou tableau OLAP
MOLAP

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 12

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

3. Architecture d’un Data warehouse

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.

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 14

7
3. Architecture d’un Data warehouse

3. 2 Opérations sur les données

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).

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 15

3. Architecture d’un Data warehouse

3. 2 Opérations sur les données

TRANSFORMATION

• Il faut supprimer certaines données aberrantes qui


risqueraient de fausser les analyses.
• Il faut donc épurer et transformer les données.

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 16

8
3. Architecture d’un Data warehouse

3. 2 Opérations sur les données

CHARGEMENT/RAFRAICHISSEMENT

• Effectuer sur les données des opérations de calcul et


d’agrégation.
• Remplacer certaines bases si aucune solution
d’extraction satisfaisante n’est possible.

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 17

3. Architecture d’un Data warehouse

3. 2 Opérations sur les données

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.
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 18

9
3. Architecture d’un Data warehouse

3. 2 Opérations sur les données

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.
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 19

3. Architecture d’un Data warehouse

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...
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 20

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

3. Architecture d’un Data warehouse


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).
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 22

11
3. Architecture d’un Data warehouse

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


Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 23

3. Architecture d’un Data warehouse

3. 5 Les bases multidimensionnelles et les outils OLAP


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...
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 24

12
3. Architecture d’un Data warehouse
3. 5 Les bases multidimensionnelles et les outils OLAP

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.

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 25

3. Architecture d’un Data warehouse


3. 5 Les bases multidimensionnelles et les outils OLAP

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.
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 26

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)

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.

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 27

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)

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.

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 28

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.

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 29

3. Architecture d’un Data warehouse


3. 5 Les bases multidimensionnelles et les outils OLAP
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.

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 30

15
3. Architecture d’un Data warehouse
3. 5 Les bases multidimensionnelles et les outils OLAP
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 multi-
dimensionnelles
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)
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 31

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

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 32

16
3. Architecture d’un Data warehouse
3. 5 Les bases multidimensionnelles et les outils OLAP
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.)

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 33

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

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 34

17
3. Architecture d’un Data warehouse
3. 5 Les bases multidimensionnelles et les outils OLAP
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

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 35

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

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 36

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

3. Architecture d’un Data warehouse


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

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 38

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.

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 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

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 40

20
4. Le Marché du Data warehouse
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

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 41

4. Le Marché du Data warehouse


4. 1 Les solutions applicatives
y exemples de produits :

Editeur Produit Fonction

Comshare Boost sales and marging planning Prévision, planification


Boost sales analysis Analyse des ventes
Commander budget Elaboration budgétaire
Commander FDC Reporting, consolidation
Hyperion Software Hyperion entreprise Reporting, consolidation
Hyperion Pilar Elaboration budgétaire
Oracle Oracle financial analyser Elaboration budgétaire
Oracle sales analyser Analyse des ventes
SAS Institute CFO Vision Reporting

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 42

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.

Catégorie Editeur Produit

Arbor Software Essbase


Spécialistes
Aplix TMI

Autres Oracle Express


(environnement intégré) Gentia Software Gentia

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 43

4. Le Marché du Data warehouse


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

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 44

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

4. Le Marché du Data warehouse


4. 4 Client OLAP
y ces systèmes sont appelés DOLAP, pour Desktop OLAP
y principaux acteurs :

Editeur Editeur Fonction

GQL Requêteur
Andyne
Pablo Analyse OLAP

Impromptu Requêteur
Cognos
Powerplay Analyse OLAP

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 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.
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 47

5. Développement d’un Data warehouse


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 sous-
projets 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.
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 48

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

5. Développement d’un Data warehouse


5. 2 Phase 1: découvrir et définir les initiatives
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).

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 50

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.

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 51

5. Développement d’un Data warehouse


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é…
• …
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 52

26
5. Développement d’un Data warehouse
5. 3 Phase 2: définition de l ’infrastructure
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.
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 53

5. Développement d’un Data warehouse


5. 3 Phase 2: définition de l ’infrastructure
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…).

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 54

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.

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 55

5. Développement d’un Data warehouse


5. 4 Phase 3: mise en œuvre des applications
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.

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 56

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.

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 57

5. Développement d’un Data warehouse


5. 5 Conclusion: schéma général du processus
d’entreprise
Vision

PI P2 P3

Projet 1 Projet 2 Projet 3


Itérative inter-projets

Itérative inter-projets

(pilote) (pilote)
Itérative inter-projets

(pilote)
Vision
projet

Projet 1 Projet 2 Projet 3


(déploiement) (déploiement) (déploiement)
d’entreprise
Vision

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
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.

Utilisateur n ’accède pas directement au modèle Utilisateur a un accès direct au modèle


Modèle de données
de données. de données.

Requêtes manipulent souvent de gros


Volumes de données Résultats des transactions : volumes limités.
volumes de données.

Nombre de tables
manipulées dans les Faible en général Elevé en général.
requêtes

Requêtes prévisibles Oui Non dans de nombreux cas.

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 59

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


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).
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

• 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.

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 61

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


6. 1 Introduction
6.1.2 Modèle multidimensionnel
DIMENSION CA
Attribut de dimension
Fait
TRIMESTRE
ANNEE

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

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

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 63

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


6. 2 Modélisation Conceptuelle des données
y Exemple : SIAD de
média-planning CONSOMMATEUR
N N
PRODUIT

code_conso ACHETE code_produit


CSP nom_produit
age unites_par_sem unite_produit
revenu
sexe
ville
etat_civil

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

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 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é
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 66

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)

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 67

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 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.

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 68

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

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

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 69

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

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é D1
Clé Dimension 1 (D1) Clé D2 Clé Dimension 2 (D2)
Attribut Clé D3 Attribut
Mesure

Dimension 3

Clé Dimension 3 (D3)


Attribut

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 70

35
CONSOMMATEUR

code_conso
y Exemple: CSP
age
PRODUIT

SIAD de média- revenu


sexe
code_produit
nom_produit
planning ville
etat_civil
unite_produit

y On distingue 2 étoiles (structure


ACHETE
multiétoile)
code_conso
y les relations entre étoiles sont code_produit
possibles par le biais de unites_par_sem

dimensions communes à deux


ou plusieurs étoiles (ex : la CONSOMMATEUR MEDIA

dimension consommateur est code_conso code_media


CSP nom_media
commune aux 2 étoiles) age prix_insertion
revenu production_media
sexe pourcent_limite
ville type_media
etat_civil insertion
unite_media

UTILISE

code_conso
code_media
utilisat_media
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 71

Règles de passage ER Î 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.
•Règle 4 : Toute entité E1 reliée à une entité E2 de la règle 2 par
un chemin de relations 1:N est transcrite dans la table de
dimensions de E2.

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 72

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

6. 3 Modélisation Logique des données


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
y exemple : Cas média-planning (partiel) TYPE_MEDIA

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

Règles de passage ER Î 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.
•Règle 3 : Toute entité E1 reliée à une entité E2 de la règle 2 par
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.
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 74

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

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)
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 76

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

7. Modélisation mathématique. Agrégations et


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

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 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).

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 79

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…).

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 80

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.

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 81

41