Vous êtes sur la page 1sur 41
Le Le Data Data Warehouse Warehouse et et les les Systèmes Systèmes Multidimensionnels Multidimensionnels 1

LeLe DataData WarehouseWarehouse etet lesles SystèmesSystèmes MultidimensionnelsMultidimensionnels

1

1. Définition d’un Data warehouse (DW) • Le Data warehouse (entrepôt de données) est une

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. Définition d’un Data warehouse     1. 1 Données orientées sujet   • Données

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

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat   3   1. Définition d’un Data warehouse
 

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

  1. Définition d’un Data warehouse     1. 2. Données intégrées   • Les
 

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

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat   5   1. Définition d’un Data warehouse
 

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

1. Définition d’un Data warehouse     1. 3 Données non-volatiles   • Une information

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

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat   7   1. Définition d’un Data warehouse
 

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

  1. Définition d’un Data warehouse   1. 4 Données historisées   • Le DW
 

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

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat   9   1. Définition d’un Data warehouse
 

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

2. Objectifs d’un Data warehouse • permet le développement d ’appl ications décisionnelles et de

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
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
Requeteur
Outil frontal
Outils
ou tableau
OLAP
multidimensionnels
MOLAP

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

12

3. Architecture d’un Data warehouse 3. 1 Les Bases de Données • Bases de données

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

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

  3. Architecture d’un Data warehouse   3. 2 Opérations sur les données   TRANSFORMATION
 

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

J. Akoka - I. Comyn-Wattiau - N.Prat   1 5 3. Architecture d’un Data warehouse  

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

  3. Architecture d’un Data warehouse   3. 2 Opérations sur les données CHARGEMENT/RAFRAICHISSEMENT
 

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

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 1 7   3. Architecture d’un Data warehouse
 

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

3. Architecture d’un Data warehouse     3. 2 Opérations sur les données LES OUTILS

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

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 1 9   3. Architecture d’un Data warehouse
 

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

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

3. Architecture d’un Data warehouse 3. 5 Les bases multidimension nelles et les outils OLAP

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 de présentation
Modèles de diffusion
Modèles d’intégration
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 multidimension nelles et les outils OLAP

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

3. Architecture d’un Data warehouse 3. 5 Les bases multidimension nelles et les outils OLAP

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 multidimension nelles et les outils OLAP

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

3. Architecture d’un Data warehouse 3. 5 Les bases multidimension nelles et les outils OLAP

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 multidimension nelles et les outils OLAP

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

3. Architecture d’un Data warehouse 3. 5 Les bases multidimension nelles et les outils OLAP

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 multidimension nelles et les outils OLAP

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

3. Architecture d’un Data warehouse 3. 5 Les bases multidimension nelles et les outils OLAP

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 multidimension nelles et les outils OLAP

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

3. Architecture d’un Data warehouse 3. 5 Les bases multidimension nelles et les outils OLAP

3. Architecture d’un Data warehouse

3. 5 Les bases multidimensionnelles et les outils OLAP

3.5.6 Intégration Infocentre Hypercube

Principe proche de l ’OLAP relationnel 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 L ’outil d ’infocentre assure la gestion d ’un référentiel commun, la sélection des données et leur valorisation 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 multidimension nelles et les outils OLAP

3. Architecture d’un Data warehouse

3. 5 Les bases multidimensionnelles et les outils OLAP

3.5.6 Intégration Infocentre Hypercube

Hypercubes clients

Serveur relationnel

Table de dimension Table de dimension Table de Faits Table de dimension Table de dimension
Table de dimension
Table de dimension
Table de
Faits
Table de dimension
Table de dimension
Table de dimension

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

34

3. Architecture d’un Data warehouse 3. 5 Les bases multidimension nelles et les outils OLAP

3. Architecture d’un Data warehouse

3. 5 Les bases multidimensionnelles et les outils OLAP

3.5.7 Les outils multidimensionnels MOLAP

Les BD multidimensionnelles sont propriétaires (pas de standard) Les données sont dynamiquement structurées et compressées (optimisation de l ’espace disque) Les données sont organisées en dimensions et hiérarchies Les formules de calcul sont généralement complexes 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 multidimension nelles et les outils OLAP

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

Interface de présentation Serveur matriciel
Interface de présentation Serveur matriciel

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

36

3. Architecture d’un Data warehouse 3. 5 Les bases multidimension nelles et les outils OLAP

3. Architecture d’un Data warehouse

3. 5 Les bases multidimensionnelles et les outils OLAP

3.5.7 Les outils multidimensionnels MOLAP La constitution de la base se fait selon le processus suivant extraction des données provenant des SGBD ou fichiers décomposition des données en dimensions, attributs et variables calcul des consolidations chargement de l ’hypercube selon la structure dimensionnelle choisie L ’interrogation de la base possède les caractéristiques suivantes :

interface graphique (drill down, slice and dice, etc) gestion des seuils et des alertes (codage couleurs) temps de réponse court et constant SQL non implémenté Exemple : Oracle Express

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

37

3. Architecture d’un Data warehouse 3. 6 Les limites du multidimensionnel Structure figée (l’hypercube do

3. Architecture d’un Data warehouse

3. 6 Les limites du multidimensionnel

Structure figée (l’hypercube doit être construit à chaque

Format et langage propriétaire

modification) Accès au détail difficile

Peu d ’outils disponibles

Outils d ’administration insuffisants

Difficulté de réaliser des sélections sur un hypercube

Pas de standard ni pour la structure physique ni pour l ’interrogation Manque de souplesse et absence de gestion de méta-données

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

38

  3. Architecture d’un Data warehouse 3. 7 Conclusion     Un marché florissant nombreux
 

3.

Architecture d’un Data warehouse

3. 7 Conclusion

 
 

Un marché florissant nombreux outils (ROLAP,MOLAP, ) concentration du nombre d ’éditeurs de logiciels Nécessité de méthodologie de conception démarche modélisation conceptuelle et logique implication des utilisateurs Un avenir réel l’informatique opérationnelle est mature la demande des utilisateurs est importante la technologie est disponible.

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

39

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 3 9   4. Le Marché du Data
 

4.

Le Marché du Data warehouse

Le marché du décisionnel regroupe une trentaine d’acteurs Les éditeurs peuvent être regroupés en quatre catégories solutions applicatives bases de données multidimensionnelles client ROLAP client OLAP

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

40

4. Le Marché du Data warehouse   4. 1 Les solutions applicatives L’offre la plus

4.

Le Marché du Data warehouse

 

4.

1 Les solutions applicatives

L’offre la plus ancienne l’offre verticale (spécialisée dans un secteur tel que la banque ou la grande distribution) l’offre horizontale (consacrée à une fonction précise) l’offre fondée sur un progiciel 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

J. Akoka - I. Comyn-Wattiau - N.Prat   4 1 4. Le Marché du Data warehouse

4.

Le Marché du Data warehouse

 

4.

1 Les solutions applicatives

exemples de produits :

Editeur

Produit

Fonction

 

Comshare

Boost sales and marging planning Boost sales analysis

Prévision, planification 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

  4. Le Marché du Data warehouse   4. 2 Bases de données multidimensionnelles  
 

4.

Le Marché du Data warehouse

 

4.

2 Bases de données multidimensionnelles

 

Quatre acteurs principaux répartis en deux catégories :

 

les spécialistes qui fournissent une technologie multidimensionnelle performante 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

J. Akoka - I. Comyn-Wattiau - N.Prat   4 3   4. Le Marché du Data
 

4.

Le Marché du Data warehouse

 

4.

3 Client ROLAP

 

Offre la plus récente sur le marché 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 l ’administrateur offre à l ’utilisateur un point de vue multidimensionnel sur une base relationnelle 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

  4. Le Marché du Data warehouse 4. 4 Client OLAP Utilisation d ’un outil
 

4.

Le Marché du Data warehouse

4.

4 Client OLAP

Utilisation d ’un outil d’infocentre pour interroger les données relationnelles, puis représenter l’information récupérée sous forme multidimensionnelle solution proposée par les éditeurs d’infocentre deux outils sont utilisés : l’analyse multidimensionnelle et l’infocentre relationnel inconvénients :

 

pour alimenter l’outil multidimensionnel, il faut rapatrier un volume de données important de la base relationnelle vers l’outil 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

  Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 45   4. Le Marché du Data
 

4.

Le Marché du Data warehouse

4.

4 Client OLAP

 

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

Editeur

Editeur

Fonction

 

Andyne

GQL

Requêteur

Pablo

Analyse OLAP

Cognos

Impromptu

Powerplay

Requêteur

Analyse OLAP

 

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

46

  5. Développement d’un Data warehouse 5. 1 Introduction 5.1.1 Caractéristiques d ’un data warehouse
 

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

. Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 4 7   5. Développement d’un Data
 

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

  5. Développement d’un Data warehouse 5. 2 Phase 1: découvrir et définir les initiatives
 

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

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 49   5. Développement d’un Data warehouse 5.
 

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

  5. Développement d’un Data warehouse 5. 2 Phase 1: découvrir et définir les initiatives
 

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

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 5 1   5. Développement d’un Data warehouse
 

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

  5. Développement d’un Data warehouse 5. 3 Phase 2: définitio n de l ’infrastructure
 

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

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 5 3   5. Développement d’un Data warehouse
 

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

  5. Développement d’un Data warehouse   5. 4 Phase 3: mise en œuvre des
 

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

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 5 5   5. Développement d’un Data warehouse
 

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

5. Développement d’un Data warehouse 5. 4 Phase 3: mise en œuvre des applications 5.4.2

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

Vision Vision d’entreprise projet 5. Développement d’un Data warehouse 5. 5 Conclusion: schéma général du
Vision
Vision
d’entreprise
projet
5. Développement d’un Data warehouse
5.
5 Conclusion: schéma général du processus
PI
P2
P3
Projet 1
Projet 2
Projet 3
(pilote)
(pilote)
(pilote)
Projet 3
Projet 1
Projet 2
(déploiement)
(déploiement)
(déploiement)
stejorp-retnievitratéI
stejorp-retnievitratéI
stejorp-retnievitratéI
stejorp-retnievitratéI stejorp-retnievitratéI Copyright J. Akoka - I. Comyn-Wattiau - N.Prat Incrémentale

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

Incrémentale : multi projet

Vision d’entreprise 58
Vision
d’entreprise
58
6. Modélisation des données d’un Data warehouse 6. 1 Introduction 6.1.1 Nécessité de techniques de

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

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.

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

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

6. Modélisation des données d’un Data warehouse 6. 1 Introduction 6.1.2 Modèle multidimensionnel • Opérations

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

différentes perspectives.

selon

and

dicing:

visualisation

des

données

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
6.
Modélisation des données d’un Data warehouse
6.
1 Introduction
6.1.2
Modèle multidimensionnel
DIMENSION
Attribut de dimension
Fait
CA
PRODUIT
- libellé
- prix unitaire
TYPE DE PRODUIT
Copyright J. Akoka
- I. Comyn-Wattiau - N.Prat
62
Un cube d’analyse des ventes
- VILLE -
d d ’habitants
nombre
pouvoir
’achat moyen
ANNEE
REGION
de chômage
-
taux
TR EMI STRE
OM SI
JO
RU
6. Modélisation des données d’un Data warehouse 6. 2 Modélisation Conceptuelle des données La plupart

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

6. 2 Modélisation Conceptuelle des données

La plupart des démarches proposées aujourd’hui font l’impasse sur cette phase 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. Principe :

établir un modèle conceptuel entité-association traduire ce modèle sous forme logique multidimensionnelle par des règles de mapping 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 Exemple :

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

6. 2 Modélisation Conceptuelle des données

Exemple : SIAD de média-planning

CONSOMMATEUR N ACHETE code_conso CSP unites_par_sem age revenu sexe ville etat_civil N MEDIA N UTILISE
CONSOMMATEUR
N
ACHETE
code_conso
CSP
unites_par_sem
age
revenu
sexe
ville
etat_civil
N
MEDIA
N
UTILISE
code_media
nom_media
utilisat_media
prix_insertion
production_media
pourcent_limite
N
EST DU
1
TYPE_MEDIA
type_media
insertion
unite_media

N

PRODUIT code_produit nom_produit unite_produit
PRODUIT
code_produit
nom_produit
unite_produit

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

64

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

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)

LESLES CONCEPTSCONCEPTS Une dimension est une donnée élémentaire permettant d’identifier un objet (ex : code d ’un produit). C’est l ’axe d ’analyse 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 ) 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

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)

effectuer la modélisation conceptuelle à l ’aide du modèle entité- association simplifier le schéma entité-association ainsi obtenu en :

éliminant les associations d’ordre supérieur à 3 éliminant les associations réflexives traduire le schéma ainsi simplifié en schéma multidimensionnel à l’aide des règles de transformation suivantes :

l’identifiant de chaque entité E-A devient une dimension dans le schéma logique multidimensionnel 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

LALA DEMARCHEDEMARCHE

66

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

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)

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 (un lien d’héritage entre deux entités est traduit par une relation dans le schéma logique multidimensionnel)

LALA DEMARCHEDEMARCHE

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

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)

LALA DEMARCHEDEMARCHE une association dont une des cardinalités maximales au moins est égale à 1 est traduite par une relation dans le modèle logique multidimensionnel 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

6. Modélisation des données d’un Data warehouse 6. 3 Modélisation Logique des données 6.3.2 Le

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

Le modèle en étoile se compose de deux type de table :

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

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

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

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

70

CONSOMMATEUR code_conso Exemple: CSP PRODUIT age SIAD de média- revenu code_produit sexe nom_produit ville
CONSOMMATEUR
code_conso
Exemple:
CSP
PRODUIT
age
SIAD
de
média-
revenu
code_produit
sexe
nom_produit
ville
planning
unite_produit
etat_civil
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)
ACHETE
code_conso
code_produit
unites_par_sem
CONSOMMATEUR
MEDIA
code_conso
code_media
CSP
nom_media
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
6. Modélisation des données d’un Data warehouse 6. 3 Modélisation Logique des données 6.3.3 Le
6. Modélisation des données d’un Data warehouse 6. 3 Modélisation Logique des données 6.3.3 Le

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

Ce modèle est dérivé de celui en étoile. Toutefois, les tables de dimensions sont normalisées et les redondances éliminées

exemple : Cas média-planning (partiel)

éliminées exemple : Cas média-planning (partiel) TYPE_MEDIA type_media insertion unite_media CONSOMMATEUR

TYPE_MEDIA

type_media

insertion

unite_media

CONSOMMATEUR code_conso MEDIA CSP age code_media revenu nom_media sexe prix_insertion ville production_media
CONSOMMATEUR
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
UTILISE
code_conso

code_media

utilisat_media

type_media UTILISE code_conso code_media utilisat_media Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 73 Règles de

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

73

Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 73 Règles de passage ER modèle en flocon
Copyright J. Akoka - I. Comyn-Wattiau - N.Prat 73 Règles de passage ER modèle en flocon

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

6. Modélisation des données d’un Data warehouse 6. 3 Modélisation Logique des données 6.3.4 Comparaison

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

Le modèle en flocon offre une vue plus claire de la structure de l’information permettant notamment de déceler une hiérarchie 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 Kimball préfère le modèle en étoile sur la base de deux arguments :

la dénormalisation permet d ’améliorer les performances du système lors de l ’exécution des requêtes 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 Formules Formules : : Quatre Quatre types types de

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

FormulesFormules :: QuatreQuatre typestypes dede formulesformules Descriptive : pour le choix d’alternative (ex : réparer un pont ou en construire un nouveau) 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) Exploratoire : représentant les relations entre données (ex :

l’analyse de régression statistique) Prescriptive : ce sont de simples descriptions, ne comportant pas de comparaisons (ex : les agrégations)

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

76

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

formules

Formules d’agrégations : composante clé du modèle multidimensionnel (ex : sommes, moyennes, équations pondérées conditionnelles) Formules non agrégatives : formules les plus couramment utilisées (ex : ratios, produits, différences) 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

AgrégationsAgrégations ::

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

77

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

formules

AgrégationsAgrégations ::

Qualifications : lors de la rédaction de formules, il faut vérifier si celles-ci sont justes pour la totalité de la hiérarchie Précédence des calculs : préciser l’ordre des calculs entre

différentes

résultat différent Formules conditionnelles : utilisées dans le cas d’exceptions connues

un

dimensions

lorsque

ceux-ci

peuvent

produire

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

78

8.

Conclusion et perspectives

8.

1 Conclusion

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 ». Le data warehouse est le cœur, l ’ossature du système d ’information décisionnel. % 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). 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

Agents « intelligents »:

Un agent agit pour un utilisateur sans solliciter son intervention explicite. Un agent « intelligent » est capable d ’apprendre en fonction d ’événements extérieurs. Technique 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

8. Conclusion et perspectives 8. 2 Quelques perspectives Internet: Complémentarité Inte rnet/data warehouse.

8. Conclusion et perspectives 8. 2 Quelques perspectives

Internet:

Complémentarité Internet/data warehouse. Internet=moyen d ’acquisition de données externes. Intranet/Extranet=moyen d ’accès au data warehouse.

CRM:

Customer Relationship Management (Gestion de la Relation Client) Un des domaines d ’application privilégiés du data warehouse.

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

81