0% ont trouvé ce document utile (0 vote)
128 vues36 pages

Cours3 DataWarehouse

Transféré par

fethi
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd
0% ont trouvé ce document utile (0 vote)
128 vues36 pages

Cours3 DataWarehouse

Transféré par

fethi
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

Gestion de données

Réparties
(DW)

1
Data warehouse

• Motivations et architecture
• Conception de la BD support
• Alimentation du DW
• Exploitation OLAP
• Conclusion

2
Data warehouse

Définition, vocabulaire, composantes


Architectures
Structures multidimensionnelles
Opérations OLAP

3
OLTP et OLAP

Reports
&
Appli.
Appli.
Appli.
OLAP Analysis

ETL
OLTP DW

DM Aides à
la décision
4
Datawarehouse

• Entrepôt de données
– Ensemble de données historisées variant dans le temps,
organisé par sujets, consolidé dans une base de données
unique, géré dans un environnement de stockage
particulier, aidant à la prise de décision dans
l’entreprise.
• Trois fonctions essentielles :
– collecte de données de bases existantes et chargement
– gestion des données dans l’entrepôt
– analyse de données pour la prise de décision

5
Datamart

« Le marché de données est une


implantation localisée d’un entrepôt de
données à usage unique » (traduction libre
Devlin 1997)

« L’entrepôt de données est prévu pour


l’entreprise dans son ensemble alors que le
marché de données est sectoriel (il peut être
un sous-ensemble exact ou modifié de
l’entrepôt de données) » (Bédard et al, 1997)
6
Définitions
Systèmes Entrepôts de données Marchés de données
transactionnels (ST)
Construit pour les Construit pour l'analyse Construit pour l'analyse
transactions (OLTP)
Données détaillées Données détaillées et Données détaillées et
résumées résumées
Intégré selon les Intégré pour l'entreprise Intégré par sujet ou
applications département
Mis à jour continuellement Jamais mis à jour, Jamais mis à jour,
seulement ajout de seulement ajout de
nouvelles données nouvelles données
Données actuelles Données actuelles et Données actuelles et
d’archive d’archive
Source originale des Données importées des Données importées des
données ST ST et/ou d’entrepôts
Structure normalisée Structure dénormalisée* Structure dénormalisée*

7
Architecture type

• Une architecture d’entrepôt de données possède


les caractéristiques suivantes :
– les données sources sont extraites de systèmes, de bases
de données et de fichiers
– les données sources sont nettoyées, transformées et
intégrées avant d’être stockées dans l’entrepôt
– l’entrepôt est en lecture seulement et est défini
spécifiquement pour la prise de décision
organisationnelle
– les usagers accèdent à l’entrepôt à partir d’interfaces et
d’applications (clients)
8
Architecture type

9
Architecture centralisée
(Corporated architecture)

Entrepôt de données
Systèmes centralisé, unique et intégré
transactionnels de l’organisation
Clients distribués
de l’organisation

Il s’agit de la version centralisée et intégrée d’un entrepôt


regroupant l’ensemble des données de l’entreprise. Les
différentes bases de données sources sont intégrées et sont
distribuées à partir de la même plate-forme physique
10
Architecture fédérée
(Federated architecture)

Département A

Département B

Département C
Entrepôt de données
de l’organisation
Systèmes
transactionnels Marchés de données Clients
de l’organisation distribués par distribués
département

Il s’agit de la version intégrée d’un entrepôt où les


données sont introduites dans les marchés de
données orientés selon les différentes fonctions de
l’entreprise 11
Concevoir le DW
• Export de données des sources
– Hétérogènes et variées
– Fichiers, BD patrimoniales, Web, …
– Définition des vues exportées
• Définition d'un schéma global
– Intègre les données utiles
– S'appuie sur le modèle relationnel
• Nécessité d'une gestion de méta-données
– Description des sources
– Description des vues exportées
– Description du schéma global

12
Organisation par sujet
• Les données sont organisées par sujets majeurs:
– Clients, produits, ventes, …
• Sujet = faits + dimensions
– Collecte les données utiles sur un sujet
• Exemple: ventes
– Synthétise une vue simple des événements à analyser
• Exemple: Ventes (N°, produit, période, magasin, )
– Détaille la vue selon les dimensions
• Exemple: Produits(IDprod, description, couleur, taille, …)
• Magasins(IDmag, nom, ville, dept, pays)
• Periodes(IDper, année, trimestre, mois, jour)

13
Schémas en étoile
• Une table de faits encadrées par N tables de dimensions

Produits
IDprod
Periode Table de faits “ventes” description
couleur
sIDper
periode taille
année fournisseur
trimestre produit
mois Magasins
magasin
jour
IDmag
unités_vendues nom
montant_ventes ville
département
taxes_ventes pays
14
Vocabulaire
Les outils traditionnels de gestion et d’exploitation
des données sont du type transactionnel ou OLTP
(On-Line Transaction Processing)
Les nouveaux outils d’exploitation des données sont
de type analytique :
Entrepôts de données (Data Warehouses)
Marchés de données (Data Marts)
Requêteurs et rapporteurs (Querying and Reporting Tools)
OLAP (On-Line Analytical Processing)
Fouille de données automatique (Data Mining)

15
Schémas en flocons
• Raffinement du schéma étoile avec des tables normalisées
par dimensions
Produits Fournisseurs
IDprod IDfour
description description
couleur type
taille Adresse
Ventes IDfour
• Avantages
– Évite les redondances
– Conduit aux constellations (plusieurs tables de faits à dimensions
partagées)

16
Conception du schéma intégré
• Isoler les faits à étudier
– Schéma des tables de faits
• Définir les dimensions
– Axes d'analyse
• Normaliser les dimensions
– Éclater en plusieurs tables liés par contraintes référentielles
• Intégrer l'ensemble
– Plusieurs tables de faits partagent quelques tables de dimension
(constellation d’étoiles)

17
Bilan conception
• Le datawarehouse regroupe,
historise, résume les données de
l'entreprise
• Le concepteur définit schéma
exportés et intégrés
– des choix fondamentaux !
– Ciblage essentiel !
• Le datamart c’est plus ciblé et plus
petit.
• Questions ?
– Peut-on ajouter des données au
niveau de l’entrepôt ?

18
Alimenter le DW
• ETL = Extracteur+Intégrateur
– Extract + Transform + Load
• Extraction
– Depuis les bases sources ou les journaux
– Différentes techniques
• Push = règles (triggers)
• Pull = requêtes (queries)
– Périodique et répétée
• Dater ou marquer les données envoyées
– Difficulté
• Ne pas perturber les applications OLTP

19
Transformation
• Accès unifiés aux données
– Unification des modèles
• Traduction de fichiers, BD réseaux, annuaires en tables
• Evolution vers XML (modèle d'échange) plus riche
– Unification des accès
• Rowset, SQL limité, SQL complet, …
• Mapping plus ou moins sophistiqué
– Unification des noms
• Appeler pareil les mêmes choses et différemment les choses différentes
• Application des "business rules"
– Elimination des doubles
– Jointure, projection, agrégation (SUM, AVG)
• Cleaning des données

20
Data Cleaning
• Valeurs manquantes (nulles)
– Ignorer le tuple
– Remplacer par une valeur fixe ou par la moyenne
• Valeurs erronées ou inconsistantes
– Générées en présence de bruits
– Détecter par une analyse de voisinage
• Écart par rapport à la moyenne
• Factorisation en groupes (outliers)
– Remplacer par une valeur fixe ou par la moyenne
• Inspection manuelle de certaines données possible
21
Chargement
• Pas de mise à jour
– Insertion de nouvelles données
– Archivage de données anciennes
• De gros volumes
– Périodicité parfois longue
– Chargement en blocs (bulk load)
– Mise à jour des index et résumés
• Problèmes
– Cohabitation avec l'OLAP ?
– Procédures de reprises ?

22
Gérer l'entrepôt
• Base relationnelle
– Support de larges volumes (qq 100 gigas à qq téras)
– Historisation des données (fenêtres)
– Importance des agrégats et chargements en blocs
• Base spécialisée
– Base multidimensionnelle
– Combinaison des deux
• Machine support parallèle
– Multiprocesseurs
– Mémoire partagée, cluster, bus partagé, etc.

23
Le multidimensionnel

• Dimensions: • Indicateurs:
– Temps – Nombre d’unités
– Géographie vendues
– Produits – CA
– Clients – Coût
– Canaux de ventes..... – Marge.....

24
Cube de données

0
10
Date
NumFou 2002 350 600 300

0
15
2001 300 500 400

0
12
NumPro 2000 250 200 F2
F1
P1 P2 P3
25
Le data cube et les
dimensions
Axe d'analyse: La géographie
(Pays - région - ville)

Variables analysées:
Nb unités, CA, marge...

Axe d'analyse: Les produits


(classe, produit)

Axes d'analyse: dimensions


Axe d'analyse: Le temps Variables analysées: indicateurs
(Année, trimestre, mois, semaine)
26
La granularité des dimensions

Temps Jours Mois Trimestres Années

Géographie Villes Régions Pays

Produits Numéros Types Gammes Marques

27
Le multidimensionnel
Exemple
• Montant des ventes fonction de (Mois, région, Produit)

Granularité des dimensions :


on
gi

Type Région Année


Catégorie Pays Trimestre


Produit

Produit Ville Mois Semaine

Magasin Jour

Mois
28
La navigation
multidimensionnelle
Projection en 2 dimensions Coupe d ’un cube
Produits Produits
pour une région donnée
CA CA

Région
Temps en semaines
Réduction selon 1 dimension
Produits Zoom selon une dimension
France

CA Est Sud Ouest

Temps en mois Lyon Marseille Nice


29
L'algèbre des cubes
• Roll up :
– Agréger selon une dimension
• Semaine  Mois
• Drill down :
– Détailler selon une dimension
• Mois  Semaine
• Slice et Dice:
– Sélection et projection selon 1 axe
• Mois = 04-2003 ; Projeter(Région, Produit)
• Pivot :
– Tourne le cube pour visualiser une face
• (Région,Produit)(Région, Mois)

30
Le multidimensionnel
Les vues d'un cube
• Partant d'un cube 3D, il est possible d'agréger selon une
dimension tournante
• On obtient un treillis de vues (calculable en SQL)

NumPro, NumFou, Date

NumPro, NumFouNumPro, DateNumFou, Date

NumPro NumFou Date

31
Le multidimensionnel
Extension de SQL
• ROLLUP: • CUBE:
– SELECT <column list> – SELECT <column list>
– FROM <table…> – FROM <table…>
– GROUP BY – GROUP BY
ROLLUP(column_list);
CUBE(column_list);
• Crée des agrégats à n+1
niveaux, n étant le nombre • Crée 2n combinaisons
de colonne de groupage d'agrégats, n étant le
– n, n-1, n-2,…0 colonnes nombre de colonne de
groupage

32
Implémentation
Exemple CUBE

Animal Lieu Quantite Animal Lieu Quantite


Chien Paris 12 Chat Paris 18
Chat Paris 18 Chat Naples 9
Tortue Rome 4 Chat - 27
Chien Rome 14 Chien Paris 12
Chat Naples 9 Chien Naples 5
Chien Naples 5 Chien Rome 14
Tortue Naples 1 Chien - 31
Tortue Naples 1
• SELECT Animal, Lieu, Tortue Rome 4
SUM(Quantite) as Quantite Tortue - 5
- - 63
FROM Animaux
- Paris 30
GROUP BY Animal, Lieu - Naples 15
WITH CUBE - Rome 18
33
Implémentation
Exemple ROLLUP

Animal Lieu Quantite Animal Lieu Quantite


Chien Paris 12 Chat Paris 18
Chat Paris 18 Chat Naples 9
Tortue Rome 4
Chat - 27
Chien Rome 14
Chat Naples 9
Chien Paris 12
Chien Naples 5 Chien Naples 5
Tortue Naples 1 Chien Rome 14
Chien - 31
Tortue Naples 1
• SELECT Animal, Lieu,
Tortue Rome 4
SUM(Quantite) as Quantite Tortue - 5
FROM Animaux - - 63
GROUP BY Animal,Lieu
WITH ROLLUP
34
Implémentation
Quelques outils OLAP
• Oracle • Cognos
– OLAP API = Datacube – Impromptu = Reporting
– Express = Analyse – Powerplay = Datacube
– Report = Reporting – Query = Requêtage
• Business Object • Hyperion
– BusinessQuery = – ESS Base = Base MOLAP
Requêtage – ESS Analysis= Analyse +
– BusinessObject = Datacube
Requêtage + Analyse +
Reporting
– WebIntelligence =
Datacube
35
Implémentation
Les Data …
• Datawarehouse
– entrepôt des données historisées de l'entreprise
• Datamart
– magasin de données ciblé sur un sujet précis
• Datamining
– exploration des données afin de découvrir des connaissances
• Datacube
– cube de présentation d'unités selon 3 dimensions
• Datawebhouse
– entrepôt des données collectées sur le web

36

Vous aimerez peut-être aussi