CoursDWH AIR3 Cours1

Entrepôts de données
Première partie
Thierry Hamon
Bureau H202
Institut Galilée - Université Paris 13
&
LIMSI-CNRS
hamon@limsi.fr
https://perso.limsi.fr/hamon/Teaching/P13/DWH-AIR3-2020-2021/
AIR3 – DWH
1/137
Sources des transparents
F. Boufares, LIPN, Université Paris Nord

P. Marcel, LI, Université de Tours
Bernard Espinasse, Ecole Polytechnique Universitaire de
Marseille
Melanie Herschel, Université Paris Sud
2/137
Présentation du cours
Dans la suite du cours de AIR2 et AIR3 sur les BD
Objectifs de l’enseignement :
Connaı̂tre et manipuler des notions liées aux Entrepôts de
données (ED/DWH)
3/137
données (ED/DWH)
Programme des enseignements
Introduction et définition d’un entrepôt de données
Modélisation et Architecture d’un entrepôt de données
OLAP et implémentation des entrepôts de données
3/137
données (ED/DWH)
Programme des enseignements
Introduction et définition d’un entrepôt de données
Modélisation et Architecture d’un entrepôt de données
OLAP et implémentation des entrepôts de données
Répartition des enseignements
3 × 3h de cours
Partiel
4 × 3h de TP
Evaluation lors du dernier TP
3/137
Introduction
Historique
Générations de SGBD
Big Data
2010 − 202X?
Indépendance physique
Volume de données
SGBD4/5
Type de données
Avancés
2004/5 − 2010
Portabilité
SGBD 3
Avancés
1980 − 1990 − 2000
SGBD 2
Relationnels
1970 − 1980 − 1990
SGBD 1
Hiérarchies, Réseaux
1960 − 1970 − 1980
Puissance
Performance
Cohérence
4/137
Introduction
Historique
Applications BD, ED, FD, ...
BigData / Datamasse
(Applications analytique,
prise de décision, analyse prédictive)
Téraoctets par jour, Pétaoctets par an
Volume de données
Type de données
Fouille de données
(Analyse du comportement des clients, etc.)
Entrepôts de données (grosses masses de données)

Intégration de plusieurs systèmes d’information nationaux et internationnaux)
(milliers de tables de quelques millions de lignes) > 100 Go
Applications : Gestion des risques, Analyse des ventes

(100 tables de quelques millions de lignes) 2 Go
Bases de Données
Entrepôts de Données
Intégration de Données
Applications : Paie, Marketing, Financière
(50 tables de quelques milliers de lignes) 50 Mo Performance
5/137
Introduction
Historique
Applications BD, ED, FD, ...
Applications : Génome, Astronomie
Analyse climatique, Physique quantique,
Analyse tendancielle
(Temps réel)
Volume de données
Type de données
Entrepôts de données
(OLTP : < 10 secondes) (OLAP < 1 heure)
( MV : agrégation, ...) (Batch : Quotidien ou mensuel < 1h)
Grosse volumétrie : travail d’optimisation et suivi des activités

du DWh nécéssaire
Par expérience, certains traitements ne se terminent pas
au bout de quelques jours
Nécessité de modifications techniques et fonctionnelles
Applications : Gestion des risques, Analyse des ventes

(Batch : < 1 heure) Bases de Données
Entrepôts de Données
Intégration de Données
Applications : Paie, Marketing, Financière
(OLTP: quelques secondes) (Batch : < 1 heure) Performance
6/137
Introduction
Historique
Structure et type de données
Stockage et
calcul distribués
Cloud computing
Relationnelle
& objet Type de données
Volume de données
COMPLEXE
Type de données
Relations
Structure de données
Portabilité
TABULAIRE
Hiérarchique Structure de données

& Réseau en RESEAU
Structure HIERARCHIQUE
des données
Puissance
Performance
Cohérence
7/137
Introduction
Historique
Exemples de SGBD
MapReduce, Hadoop
Teradata, Oracle
SGBD4/5
ORACLE 9i, 10g, 11g, 12c
DB2, ...
Volume de données
XML, ...
Type de données
SGBD 3
ORACLE 7/8,
Portabilité
INGRES, DB2, Sybase,

Verssant Enjin (O2),
ObjectStore, Orlent,
MySQL, PostGreSQL,
SGBD 2 SQLServer, ACCESS, ...
ORACLE 5/6
INGRES,
DB2, ...
Bases de données
SGBD 1 Entrepôts de données
COADSYL, Intégration de Données
SOCRATE,
... Puissance
Performances
Cohérence
8/137
Introduction
Quelle quantité d’information ? sous quelle forme ?

Il y a plus de 15 ans !
en 2000 :
entre 1 et 2 ExaOctets par année (1 Eo = 220 To)
90% électronique
taux de croissance annuel de 50 %
en 2003 : 5 Eo en 2002, 92% électronique
Lyman&Varian, 2003 (http://groups.ischool.berkeley.edu/archive/
how-much-info-2003/execsum.htm)
Comment accèder à ces données, tirer partie de ces données ?

→ Les bases de données ne suffisent plus
9/137
BD → ED
Des bases de données aux Entrepôts de données
10/137
BD → ED
Introduction
Avant les entrepôts de données/Data Warehouses
La majeure partie des applications Bases de Données reposent

aujourd’hui sur trois couches :
La couche la plus externe est celle de qui permet de présenter
les données aux utilisateurs.
Elle est appelée Graphical User Interfaces GUI.
La couche application intermédiaire inclut le programme de
l’application
Elle ne stocke pas les données.
La couche la plus interne gère le stockage des données.
Elle est appelée la couche Base de Données.
11/137
BD → ED
Introduction
Couche Présentation Graphical User Interfaces GUI GUI
Couche Application OLTP Application OLTP Application Decision support System
Read, Select
Insert, Update, Delete
Couche Base de Données BD1 BD2
Ressources externes
(file system, ftp, www, ...)
12/137
BD → ED
Introduction
Les applications interrogent les données avec, par exemple,

le langage SQL (Select)
et les mettent à jour par l’intermédiaire des opérations
Insert, Update et Delete
qui constituent des transactions.
Celles-ci doivent avoir certaines propriétés ACID (Atomicité,

Cohérence, Isolation et Durabilité)
Ce type d’application est appelé On-Line Transaction Processing

OLTP.
13/137
BD → ED
Introduction
Données volumineuses & Besoins nouveaux
Vers les entrepôts de données
→ Systèmes d’Information Décisionnel
Systèmes d’Aide à la Décision (DSS) :

Rapports, Etats, Tableaux de Bord, Graphiques, Synthèses,
Groupement, Agrégat, Résumé ...
(Reporting Tools, Management Information System, Executive
Information System, Decision Support System DSS)
14/137
BD → ED
Introduction
Remarques
Contrairement aux applications OLTP, qui consultent et

mettent à jour les données des BD opérationnelles,
les DSS lisent les données seulement pour avoir de
nouvelles informations à partir des données sources
Bénéfice de cette approche : seules les BD opérationnelles ont à
être créées et maintenues
Un ensemble de méta-données est utilisés pour les 2 systèmes.

Les DSS ne nécessitent que des travaux supplémentaires
mineurs.
15/137
BD → ED
Introduction
Remarques
Cependant, il y a plusieurs désavantages :

(quand le DSS et les applications OLTP se partagent les mêmes BD)
Un DSS ne peut utiliser que les données actuellement
stockées dans les BD
les analyses historiques sont donc souvent impossibles à cause des
opérations de mises à jour qui changent les données historiques
L’utilisation des BD en mode multi-utilisateurs
ce qui implique des opérations de verrouillage des données (Locking
operations) et donc des problèmes de performance
car les requêtes analytiques demandent l’accès à de très grands
nombre de tuples.
16/137
BD → ED
Introduction
La solution est de séparer

la BD orientée Transaction
de la BD orientée Aide à la Décision
d’où la naissance du concept
Entrepôt de Données = Data Warehouse.
Les DWH sont physiquement séparés des SGBD opérationnels (BD
opérationnelles)
17/137
BD → ED
Introduction
Définition rapide d’un Data Warehouse
Le Data Warehouse est une collection de données orientées sujet,

intégrées, non volatiles, historisées, organisées pour le support d’un
processus d’aide à la décision
Un système de DWH peut être formellement défini comme un
triplet
<BD cible, méta-données, un ensemble d’opérations>
L’ensemble des opérations associées peut être présenté en 4

catégories (ETL, Agrégation et Groupement)
18/137
BD → ED
Architecture des DWHs

Méta−données
Extraire
Sources externes
Nettoyer
Transformer
Utiliser
Charger (Load)
Intégrer
Rafraichir
Entrepot de données OLAP
Maintenir
BD opérationnelles
19/137
BD → ED
Introduction
Le DWH intègre des données à partir de sources multiples et

hétérogènes
afin de répondre aux requêtes du système d’aide à la décision.
Ce type d’application est appelé On-Line Analytical
Processing OLAP
OLAP permet la transformation des données en informations
stratégiques
20/137
BD → ED
Nouveaux concepts/nouvelle perspective
Entrepôt de données
récolte, stockage et gestion efficace des gros volumes de
données
OLAP
requêtes interactives complexes sur ces volumes
Data mining (fouille de données)
extraction automatique de propriétés cachées
données → information → connaissances
21/137
BD → ED
Analyse OLAP
(On-Line Analytical processing)
Techniques OLAP :
apparition en recherche dans les années 70
mais développement dans les années 90 dans l’industrie
Réalisation de synthèses, d’analyses et de la consolidation
dynamique de données multidimensionnelles
Manière la plus naturelle d’exploiter un ED étant donné son
organisation multidimensionnelle
22/137
BD → ED
Fouille de données
(Data Mining)
Recherche de connaissances cachées dans les données (modèle

de comportement)
Domaine jeune à l’intersection de l’Intelligence Artificielle, les
Statistiques, les BD
Méthodes : régression linéaire, arbres de décision, réseaux de
neurones, ...
Intégration croissante dans les entrepôts
23/137
BD → ED
Visualisation des données de l’ED
Objectif: Faciliter l’analyse et l’interprétation de données

Synthèse des données de l’entrepôt
→ Conversion des données complexes de l’entrepôt
en images,
en graphiques 2D et 3D
en animations
24/137
BD vs. DWH
Introduction : Comparaison
Pourquoi pas des SGBDs pour les entrepôts de données ?
les 2 systèmes sont performants
SGBD : calibré pour l’OLTP ; méthodes d’accès index,
contrôle de concurrence, reprise
Entrepôt : calibré pour l’OLAP ; requêtes OLAP complexes,
vue dimensionnelle, consolidation
Fonctions et données différentes
Données manquantes : l’aide à la décision (AD) a besoin des
données historiques qui ne se trouvent pas dans les BD
opérationnelles
Consolidation : l’AD a besoin de données consolidées
(agrégats) alors qu’elles sont brutes dans les BD
opérationnelles
25/137
BD vs. DWH
SGBD hétérogènes vs. Entrepôts de données
Traditionnellement, l’intégration de BD hétérogènes se fait par
le biais de
Wrappers/médiateurs au dessus des BD hétérogènes
Approches orientées requêtes
Quand une requête est posée sur un site client, un
métadictionnaire est utilisé pour la traduire en plusieurs
requêtes appropriées à chacune des BD. Le résultat est
l’intégration de réponses partielles
L’exécution des requêtes demande donc beaucoup de
ressources
Entrepôts de données : approche orientée mise à jour
les informations sont intégrées et stockées pour une
interrogation directe
Plus efficace en coût d’exécution des requêtes
26/137
BD vs. DWH
BD opérationnelle vs. Entrepôts de données

OLTP (On-Line Transaction Processing)
Exécution en temps réel des transactions, pour
l’enregistrement des opérations quotidiennes : inventaires,
commandes, paye, comptabilité
Par opposition au traitement en batch
OLAP (On-Line Analytical Processing)
Traitement efficace des requêtes d’analyse pour la prise de
décision qui sont par défaut assez complexes (bien qu’a priori,
elles peuvent être réalisées par les SGBD classiques)
27/137
BD vs. DWH
BD opérationnelle vs. Data Warehouse : OLTP vs. OLAP

Données : courantes, détaillées vs. historiques, consolidées
Conception : modèle ER + application vs. modèle en étoile +
sujet
Vues : courantes, locales vs. évolutive, intégrée
Mode d’accès : mise à jour vs. lecture seule mais requêtes
complexes
28/137
BD vs. DWH
Systèmes OLTP Systèmes OLAP

Données exhaustives Données résumées
Données courantes Données historiques
Données dynamiques Données statiques
Données non volumineuses Données Volumineuses
Orientés applications Orientés sujets
Utlisateurs nombreux Utilisateurs peu nombreux
Utilisateurs variés Décideurs
Mises à jour, interrogation Interrogations
Réquêtes simples Requêtes complexes
29/137
BD vs. DWH
Architecture du DWH
Architecture Multi-tiers
Data select
Dictionnaire de (requetes)
OLAP SERVER
Méta−données
111
0
Oracle Express 000
100
11
MVS (TSO, DB2 ...)
Business Objects
(rapports, analyses)
E(xtract)
T(ransform)
L(oad) DataWareHouse
1
0
011
100
00
11
UNIX (Oracle, ...) Oracle 9i (Olap)
SAS
(Datamining)
1
011
00
000
1
Windows (SQL Server, 11
Data Marts
Excel, ...)
Applications en Controle et chargement des données OLAP Outils Front−End

production
30/137
BD vs. DWH
Conception logique des DWHs
Données multidimentionnelles
Montant des ventes comme une fonction des paramètres
produits, mois, région
Dimensions : Produit, Lieu, Temps
Chemins de consolidation hiérarchiques
on
Régi
Région Année
Industrie
Pays Trimestre
Catégorie
Produit
Ville Mois
Semaine
Produit
Magasin Jour
Mois
31/137
Applications
Domaines d’application
Ceux de l’informatique décisionnelle (Business Intelligence)

pour
aider atteindre les objectifs stratégiques d’une entreprise et
faciliter son pilotage
avoir une connaissance plus approfondie de l’entreprise
anticiper les besoins clients
prendre en compte les nouveaux canaux de distribution (vente
en ligne, etc.)
32/137
Applications
Domaines d’application
Informatique décisionnelle
Entrepôt de données
Outils de veille stratégique et de recueil d’information
(intelligence économique)
Aide aux décideurs pour prendre les bonnes décisions sur la
base des données disponibles
Exemples :
Quels sont les 5 produits les plus vendus pour chaque
sous-catégorie de produits qui représente plus de 20% des
ventes dans sa catégorie de produits ?
Quelle est la priorité d’expédition et quel est le revenu brut
potentiel des commandes de livres qui ont les 10 plus grandes
recettes brutes parmi les commandes qui n’avaient pas encore
été expédiées ?
33/137
Applications
Applications
Commerce, finance, transport, télécommunications, santé, services,

...
gestion de la relation client
gestion des commandes, des stocks
prévisions de ventes
définition de profil utilisateur
analyse de transactions bancaires
détection de fraudes
...
34/137
Applications
Principales applications autour d’un ED
Réalisation de rapports divers (Reporting )

Réalisation de tableaux de bords (Dashboards)
Fouille de données (Data Mining )
Visualisations autour d’un ED (visualizations)
...
35/137
Applications
Exploitation d’un ED
Rapports (Reporting ) :
Besoin d’un accès régulier à des informations presque figées
Ex: dans les hôpitaux, rapports mensuels envoyés aux agences
nationales
Rapport :
une ou plusieurs requêtes
une mise en page (diagrammes, histogrammes)
Production manuelle ou automatique des rapports
36/137
Applications
Exploitation d’un ED
Tableaux de bords (Dashboards) :

Affichage d’une quantité limitée d’informations dans un
format graphique facile à lire
Utilisation fréquente par les cadres supérieurs pour avoir (qui
ont besoin) un rapide aperçu des changements les plus
importants
→ un aperçu en temps réel d’évolutions
Ex : Paris 13 en chiffres (paris13en-chiffres2014.pdf)
Remarque : Pas vraiment utile pour une analyse complexe et
détaillée
37/137
Applications
Exemples d’application
Domaine bancaire
Un des premiers utilisateurs des ED
Regroupement des informations relatives à un client pour une
demande de crédit
Lors de la commercialisation d’un nouveau produit :
Mailing ciblés rapidement élaborés à partir de toutes les
informations disponibles sur un client
Recherche de fraudes sur les cartes de crédit :
Mémorisation des mouvements et contrôles a posteriori, pour
détecter les comportements suspects
Échanges d’actions et de conseils de courtages
Déterminer des tendances de marchés grâce à :
la mémorisation de l’historique
une exploitation par des outils décisionnels avancés
38/137
Applications
Grande distribution
Regroupement d’informations sur les ventes pour l’analyse du
comportement
(produits à succès, suivi des modes, habitudes d’achats, préférences
des clients par secteur géographique)
Mise en évidence les règles de consommation grâce à la fouille
de données
Cas d’école : Explo(r|it)ation du panier de la ménagère :
connaı̂tre les produits achetés en même temps
Impacts :
augmentation des ventes grâce à un meilleur marketing
amélioration des taux de rotation de stocks
élimination des produits obsolètes
définition des rabais, remises, ristournes, promotions
meilleure négociation des achats
39/137
Applications
Télécommunications
Grande masse de données :

Plusieurs mois de descriptions détaillées des appels
Pour chaque appel : appelant, appelé, heure et durée
Exploitation de ces données pour
analyser le trafic
mieux cerner les besoins des clients
classer les clients par catégories
comprendre le comportement des clients (changement
d’opérateurs, besoins)
40/137
Applications
Assurance et de la pharmacie
Domaines très demandeurs de techniques décisionnelles pour

Déterminer le facteur de risque d’un assuré
Meilleure connaissance des clients, détection de rejets, ciblage
du marketing, etc
Détecter l’impact d’un médicament, ses effets indésirables,
etc.
Couplage avec les technologies du Web : Data Webhouse
(encore plus de données et donc plus d’informations)
41/137
Définition d’un DWH
Définitions (Inmon 1996)
Un entrepôt de données est une collection de données orientées

sujet, intégrées, non volatiles, historisées, organisées pour le
support d’un processus d’aide à la décision
Orienté Sujet :
Le but des DWH est
d’améliorer la prise de décision, de planification,
et le contrôle des sujets majeurs de l’entreprise comme les
relations entre les clients, les produits, les régions
contrairement des applications OLTP qui sont organisées autour
des flux de données de l’entreprise
42/137
Données Intégrées :
Les données dans un DWH sont chargées de différentes
sources contenant des données sur différents formats.
Les données doivent être vérifiées, triées et tranformées dans
un format unifié afin de faciliter et accélérer l’accès.
43/137
Données Historisées :
et donc datées :
avec une conservation de l’historique et de son évolution
pour permettre les analyses comparatives (par exemple,
d’une année sur l’autre, etc.).
Dans un Data Warehouse, un référentiel de temps est
nécessaire : c’est l’axe temps ou l’axe période.
44/137
Donnnées Non-volatiles :
stables
en lecture seule
non modifiables
Afin de conserver la traçabilité des informations et des
décisions prises, les informations stockées au sein du Data
Warehouse ne doivent pas disparaı̂tre...
45/137
Construction et d’exploitation d’un entrepôt de données

Processus en 3 phases :
1 Construction de la BD décisionnelle
Modélisation conceptuelle des données multiformes et multi-sources
Conception de l’entrepôt de données
Alimentation de l’entrepôt (extraire, nettoyer, transformer, charger)
Stockage physique des données
2 Sélection des données à analyser
Besoins d’analyse de l’utilisateur
Data marts (Magasins de données)
Cubes multidimensionnels
Tableaux ou tables bidimensionnels
3 Analyse des données
Statistiques et reporting, OLAP, Data Mining
46/137
Présentation des couches
Couche Présentation Graphical User Interfaces GUI GUI
Couche Application OLTP Application OLTP Application Decision support System
Insert, Update, Delete Read, Select
Couche Base de Données BD2
BD1
Target DataBase
Load
DataWareHouse
Ressources externes
(file system, ftp, www, ...)
47/137
Architecture du DWH
Architecture Multi-tiers
Data select
OLAP SERVER
Méta−données
111
0
Oracle Express 000
100
11
MVS (TSO, DB2 ...)
Business Objects
E(xtract)
T(ransform)
1
0
011
100
00
11
SAS
(Datamining)
1
011
00
000
1
Data Marts
Excel, ...)

production
48/137
Opérations
Extraction (Extraction) : Ces opérations permettent de filtrer les
données à partir de données sources (BD, fichiers, sites web...) dans
des BD temporaires.
Transformation (Transformation) : Ces opérations permettent de
transformer les données extraites dans un format uniforme.
Les conflits entre les modèles, les schémas et les données sont
résolus durant cette phase.
Chargement (Load) : Ces opérations permettent de charger les
données transformées dans la BD cible.
La BD cible est souvent implantée avec un SGBD relationnel-objet.
Agrégat et Groupement (Agregating and Grouping) : La BD cible
doit permettre de stocker les données opérationnelles et les données
issues de calculs.
49/137
Architecture
Architecture
Introduction
Objectifs :
regrouper les données sources
concevoir le schéma de l’entrepôt
remplir l’entrepôt
maintenir l’entrepôt
50/137
Architecture fonctionnelle
Architecture fonctionnelle de l’entrepôt

Les données d’un entrepôt se structurent suivant
un axe synthétique : établissement d’une hiérarchie
d’agrégation incluant
les données détaillées : les événements les plus récents
les données agrégées : synthèse des données détaillées
les données fortement agrégées : synthèse à un niveau
supérieur des données agrégées
un axe historique
incluant les données détaillées historisées représentant les
événements passés
→ Stockage des méta-données : informations concernant les
données de l’ED (provenances, structures, méthodes utilisées pour
l’agrégation, ...)
51/137
Architecture du DWH
Data select
OLAP SERVER
Méta−données
111
0
Oracle Express 000
100
11
MVS (TSO, DB2 ...)
Business Objects
E(xtract)
T(ransform)
1
011
00
000
111
SAS
(Datamining)
111
0
0
100
11
Data Marts
Excel, ...)

production
52/137
Entrepôts et magasins de données

Data Warehouses et Data marts
Collecte l’ensemble de l’information utile aux décideurs à partir
des sources de données (BD opérationnelle, BD externes, ...)
Centralisation de l’information décisionnelle
Garantie de l’intégration des données extraites et de leur
pérennité dans le temps
Magasins de données
Orientés sujet
Aide efficace aux processus OLAP
Extraction d’une partie des données utiles :
pour une classe d’utilisateurs ou
pour un besoin d’analyse spécifique
53/137
Entrepôts et magasins de données

Calcul, stockage, organisation
Puissantes machines pour la gestion de très grandes bases de
données de détail historisées
Lieu de stockage centralisé d’un extrait des bases de production
Organisation des données suivant un modèle facilitant la
gestion efficace des données et leur historisation
Magasins de données
Petits entrepôts avec une infrastructure plus légère, mise en
œuvre rapide
Données extraites d’un ED ou de BD existantes pour un besoin
d’aide à la décision particulier
Organisation des données suivant un modèle facilitant les
traitements décisionnels
54/137
Entrepôt vs. Data mart
Caractéristiques Entrepôt Data Mart

utilisateur toute l’entreprise un département
BD SQL type serveur BD MD, OLAP
échelle du modèle de données entreprise département
champs applicatifs multi-sujet quelques sujets
sources de données multiples quelques unes
stockage plusieurs BD distribuées une BD
taille > 100 Go 10 à 20 Go
temps de mise en place 9 à 18 mois 6 à 12 mois
coût plusieurs Me 100 Keà 0,5 Me
matériel Unix Petit serveur
55/137
Vue logique de l’entrepôt
Hiérarchie de dépôts :
Operational Data Store (ODS)
regroupement des données intégrées
récupération des sources
Corporate Data Warehouse (CDW)
regroupement les vues agrégées
56/137
BD vers Data marts
57/137
Architecture fonctionnelle d’un ED : 3 niveaux

Extraction de données des BD (OLTP) et de l’extérieur, selon 2
stratégies :
détection instantanée des mises à jour sur les BD pour intégration
dans l’ED (approche push)
détection périodique des mises à jour des BD pour intégration
dans l’ED (approche pull)
Fusion des données dans l’ED
Intégration, chargement et stockage des données dans l’entrepôt,
organisées par sujet
Rafraı̂chissement au fur et à mesure des mises à jour
Exploitation des données
Rapports, tableaux de bords, visualisation, ...
Analyse et exploration des données entreposées (OLAP)
Requêtes complexes pour analyse de tendance, extrapolation,
découverte de connaissances, ... (Fouille de données)
58/137
Niveau extraction
Moniteur et Adaptateur de sources
Moniteur (source monitor ) :

Rôle :
détection des mises à jour effectuées sur la source d’information
identification les données à envoyer à l’ED pour sa mise à jour
Implémentation :
Utilisation de triggers si les SGBD en disposent
Sinon, interrogation périodique de chaque base locale ou son
journal afin de récupérer les mises à jour effectuées durant la
dernière période
Adaptateur de source (source wrapper ) :
Rôle :
traduction des requêtes et les données depuis le modèle d’une
source vers le modèle de l’ED et vice-versa
59/137
Niveau fusion
Médiateur
Médiateur (mediator ) :
Rôle :
donner une vision intégrée des différentes sources d’information

extraire des parties de ces vues intégrées (à l’aide de requêtes) :
Obligation/besoin de nettoyer, transformer, réorganiser et filtrer
les données
Intégration et fusion des données issues de sources multiples
Implémentation :
utilisation du SGBD de l’entrepôt

fusion grâce à des unions ou des jointures de sources multiples, des
sélections et des agrégats
60/137
Niveau exploitation
Moteur OLAP et outils de fouille
Moteur OLAP
Traitement des données de l’ED ou des Magasins de données :
Exécution des requêtes interactives complexes
Analyse interactive des données suivant des points de vue ou
des niveaux de détail particuliers
Visualisation des résultats de ces analyses
Opérations OLTP classiques
Outils de fouille de données (Data Mining ) :
Traitement des données de l’ED ou des Magasins de données :
Extraction automatique de propriétés cachées
Extraction automatique de connaissances valides, nouvelles,
compréhensibles, pertinentes, implicites, ...
61/137
Dictionnaire et méta-données
Dictionnaire contenant des informations (méta-données) sur :

toutes les données de l’ED
chaque étape de la construction de l’ED
le passage d’un niveau de données à un autre (exploitation de
l’ED)
Rôle : définition, fabrication, stockage, accès et présentation
des données
62/137
Données sources
Données sources
Les données des entreprises sont généralement :
Surabondantes
Eparpillées
Peu structurées pour l’analyse
Modifiées quotidiennement
Problème : Prise de décision difficile
Solution : Utilisation d’outils et de techniques visant à préparer les
données pour l’analyse Data warehousing
Il s’agit d’une technique visant à extraire des données de
différentes sources afin de les intégrer selon des formats
plus adaptés à l’analyse et la prise de décision
→ Problématique d’intégration et définition de wrappers
63/137
Données sources
Données sources hétérogènes

Nécessité d’intéger des données hétérogènes, modifiées
quotidiennement
BD
relationnelles
objets
distribuées
fichiers textes
documents HTML, XML
bases de connaissances
...
Mais aussi des représentations de données et de noms de
champs/colonnes hétérogènes
64/137
Données sources
Problème des sources hétérogènes

Exemple
Chaı̂ne de concessionnaires automobiles
Concession 1
vehicules(serie, modele, couleur, autoradio, ...)
v e h i c u l e s ( ’ 1234 ’ , ’ C l i o 5p , ’ r o u g e ’ , ’ABS ’ , . . . )
Concession 2
automobiles(num serie, modele, couleur)
options(num serie, option)
a u t o m o b i l e s ( 1 2 3 4 , ’ C l i o ’ , ’R ’ )
a u t o m o b i l e s ( 2 3 4 5 , ’ C l i o ’ , ’R ’ )
o p t i o n s ( 1 2 3 4 , ’ABS ’ )
65/137
Données sources
Sources hétérogènes
Pour un même concept :

schémas différents
noms d’attribut différents
types de données différents
valeurs différentes
sémantiques différentes
66/137
Données sources
Hétérogénéité des données et des applications

Illustration
Source d’information Application

gestion commerciale progiciel sybase
gestion marketing progiciel SQL server
gestion financière, paye DB2/IBM
suivi de production Oracle
contrôle qualité Oracle
gestion du temps Oracle
gestion des stocks Oracle
fichier mailings Fichier ASCII
références nationales Document excel
source (Goglin, 1998)
67/137
Alimentation de l’ED
Processus d’alimentation d’un ED

Entreposage des données
Rôle de l’alimentation de l’entrepôt

rassembler de multiples données sources souvent
hétérogènes
homogénéiser les données sources
Homogénéisation réalisée selon des règles précises
Les règles d’homogénéisation sont :
mémorisées sous forme de méta-données stockées dans le
dictionnaire de données
utiliser pour assurer des tâches d’administration et de
gestion des données entreposées
68/137
Après avoir conçu le modèle des données, comment alimenter

l’entrepôt ?
Faut-il ramener toutes les données sous le même format ?
Si oui, quel format choisir et pourquoi ?
Sinon, comment faire pour interroger toutes ces différentes
structures ?
Quel(s) langage(s) d’interrogation va-t-on utiliser ?
Quelle architecture utiliser ?
→ problématique de l’ETL (Extracting, Transforming and Loading)
69/137
4 étapes :
1 Sélection des données sources
2 Extraction des données
3 Nettoyage et Transformation
4 Chargement
Etapes 1 et 2 : Jusqu’à 80 % du temps de développement d’un

entrepôt
→ outil : Oracle Warehouse Builder (OWB)
70/137
Sélection des données sources
Quelles données de production faut-il sélectionner pour alimenter

l’ED ?
Définir l’utilité des données sources
Doit-on prendre l’adresse complète ou séparer le code postal ?
Réorganiser les données sélectionnées pour qu’elles deviennent
des informations
Faire une synthèse des données sources pour les enrichir
Dénormaliser les données pour créer des liens entre les
données et permettre des accès différents
71/137
Extraction des données
Un extracteur (wrapper) est associé à chaque source de données

Sélection et extraction des données
Formatage des données dans un format cible commun
en général, le modèle Relationnel
Utilisation d’interfaces comme ODB, OCI, JDBC
72/137
Nettoyage et Transformation des données
Objectifs du nettoyage :
Résolution des problèmes de consistance des données au sein
de chaque source
Remarques :
une centaine de type d’inconsistances ont été répertoriées
5 à 30 % des données des BD commerciales sont erronées
73/137
Types d’inconsistances
Présence de données fausses dès leur saisie

fautes de frappe
différents formats dans une même colonne
texte masquant de l’information (e.g., ”N/A”)
valeur nulle
incompatibilité entre la valeur et la description de la colonne
duplication d’information, ...
Persistance de données obsolètes
Confrontation de données sémantiquement équivalentes mais
syntaxiquement différentes
74/137
Nettoyage des données

Fonctions d’analyse
Fonctions de normalisation
Fonctions de conversion
Usage de dictionnaires de synonymes ou d’abréviations
Définition de table de règles remplacer valeur par
Mr M
monsieur M
mnsieur M
masculin M
M M
Msieur M
M. M
Monseur M
Utilisation d’expressions régulières, suppression de doublons,

de valeur nulle, ...
75/137
Nettoyage des données

fonctions de conversion
76/137
Transformation
Objectif : suppression des incohérences sémantiques entre les

sources, problématique lors de l’intégration
des schémas
des données
77/137
Transformation
Problèmes lors de l’intégration des schémas
Problème de modélisation
Utilisation de différents modèles de données
Problèmes de terminologie
2 noms différents pour désigner un objet
2 objets différents désignés par un même nom
Incompatibilités de contraintes
Contraintes incompatibles pour 2 concepts équivalents
78/137
Transformation
Problèmes lors de l’intégration des schémas
Conflit sémantique
Différents niveaux d’abstraction pour un même concept
Conflits de structures
Différentes propriétés pour un même concept
Conflits de représentation
2 représentations différentes choisies pour les mêmes propriétés
d’un même objet
79/137
Transformation
Résolution des problèmes survenant lors de l’intégration des

schémas
Demande une solide connaissance de la sémantique des
schémas
Peu traitée par les produits du marché
Nombreux travaux de recherche
Opération généralement réalisée à la main...
80/137
Transformation

schémas
Utilisation d’heuristiques de réconciliation des schémas basées sur
l’existence de similarités entre :
noms de tables et d’attributs
types de données
instances
structure des schémas
contraintes d’intégrité
81/137
Transformation
Problème lors de l’intégration des données
Équivalence de champs
Équivalence d’enregistrements
82/137
Transformation

données
Équivalence de champs :
Deux chaı̂nes sont équivalentes si l’une est le préfixe de l’autre
→ Mesure de la compatibilité des champs
Pour 2 champs c1 et c2
n(ci ) := nombre de chaı̂nes de ci
ne := le nombre de chaı̂nes équivalentes
compatibilité := ne /((n(c1 ) + n(c2 ))/2)
83/137
Transformation

données
Équivalence d’enregistrements :
fusion d’enregistrements
pour tous les tuples concernés
si noss1 = noss2 et nom1 = nom2
fusionner personne1 et personne2
si (noss1 = noss2 ou nom1 = nom2)
et adresse1 = adresse2
fusionner personne1 et personne2
...
84/137
Chargement des données

Objectif : Stockage des données nettoyées et préparées dans la BD
opérationnelle (ODS)
Opération :
risquant d’être assez longue
plutôt mécanique
la moins complexe
Mais il est nécessaire de définir et mettre en place :
des stratégies pour assurer de bonnes conditions à sa
réalisation
une politique de rafraı̂chissement
85/137
Chargement des données
Définitions de vues relationnelles sur les données sources

Matérialisation des vues dans l’entrepôt
Mais aussi, préparation à la restitution
tris
consolidations (pré-agrégation)
indexation
partitionnement des données
enregistrement de méta-données
...
86/137
Préparation à la restitution
Agrégation
Calcul de vues agrégées
Définition des indexes
Stockage dans le CDW
Personnalisation
Construction de magasins de données (Data Marts)
Construction de cubes de données
Construction des présentations demandées par les utilisateurs
87/137
Méta-données
Méta-données
Toutes les informations nécessaires pour la construction et
l’administration de l’entrepôt
informations présentes dans l’entrepôt
données source
données dérivées, dimensions, hiérarchies
contraintes d’intégrités schéma de l’entrepôt
indexes, partitions
requêtes prédéfinies
...
informations d’administration
règles de nettoyage, transformation, extraction
politique de rafraı̂chissement
sécurité
monitoring, statistiques
traçage des données
...
88/137
Méta-données
Méta-données
Chaque composant de l’entrepôt

fournit des méta-données
doit connaitre celles des autres composants
doit savoir où ces méta-données sont situées
Une BD est dédiée aux méta-données
89/137
Méta-données
Common Warehouse Metamodel
Spécification d’un langage d’échange de méta-données d’entrepôt

proposé par l’OMG (Object Management Group)
basé notamment sur UML, XML
conçu par IBM, Unisys, NCR, Oracle, Hyperion, ...
90/137
Modélisation
Modélisation multidimensionnelle
Lien direct entre les analyses décisionnelles (OLAP) et une
modélisation de l’information conceptuelle :
proche de la perception qu’en a l’analyste
basée sur une vision multidimensionnelle des données
Modèle multidimensitionnel : les données sont vues comme des
data cubes
Un cube de dimension n est dit un cuboı̈de
Le treillis des cuboı̈des d’un entrepôt de données forme un
data cube
La modélisation multidimensionnelle a donné naissance aux
concepts de fait et de dimension (Kimball 1996)
91/137
Modélisation
Cube de données
92/137
Modélisation
Exemple de treillis de cube
93/137
Modélisation
Cube de données
Sujet analysé : un point dans un espace à plusieurs dimensions

Organisation des données pour mettre en évidence le sujet
analysé et les différentes perspectives de l’analyse
data cube (par exemple, les ventes) : vision des données sur
plusieurs dimensions
94/137
Modélisation
Concept de fait
Un fait :
modélisation du sujet de l’analyse
Mesures correspondant aux informations de l’activité analysée
Mesures numériques, généralement valorisées de façon
continue. On peut
les additionner
les dénombrer
calculer le minimum, le maximum ou la moyenne
Exemple : le fait de Vente peut être constitué des mesures
d’activités suivantes :
quantité de produits vendus
montant total des ventes
95/137
Modélisation
Concept de dimension
Axes ou perspectives caractérisant les mesures de l’activité d’un fait
Une dimension :
modélisation un axe d’analyse
nécessité pour chaque dimension, de définir ses différents
niveaux de détail
→ Définition d’une (ou plusieurs) hiérarchie(s) de paramètres
se compose de paramètres correspondant aux informations
faisant varier les mesures de l’activité
Dans l’exemple précédent :
Analyse du fait Vente suivant différentes perspectives correspondant
à trois dimensions :
la dimension Temps
la dimension Geographie
la dimension Categorie
96/137
Modélisation
Hiérarchie des paramètres d’une dimension

Hiérarchie de paramètres d’une dimension :
Définition des niveaux de détail de l’analyse sur cette
dimension
Exemple :
Dimension temps :
H1 : jour < mois < trimestre < année
H2 : jour < mois < semestre < année
H3 : jour < mois < saison < année
Dimension géographie :
ville < d épartement < r égion
Dimension catégorie :
couleur < nomProduit < gamme < typeProduit
97/137
Modélisation
Objets intervenant dans les schémas
Tables de faits (fact tables)

Les faits numériques (les mesures)
Les clés étrangères vers les tables de dimension
Tables de dimension (dimension tables)
composées d’une ou plusieurs hiérarchies catégorisant les
données
Identifiant unique
Pour distinguer les enregistrements dans les tables
Relations entre les objets
elles assurent l’intégrité des opérations
98/137
Modélisation
Objets intervenant dans les schémas
Exemple de tables de dimension :

i t e m ( nom item , marque , t y p e )
temps ( j o u r , se m a in e , mois , t r i m e s t r e , a nn ee )
La table des faits contient des mesures unites_vendues

les clés externes font référence à chaque table de dimension
99/137
Implémentation d’un entrepôt
Type d’approches des DW
Approche matéralisée
Approche virtuelle
Approche hybride
100/137
Approche des DW
Approche matéralisée :
Instanciation (matérialisation) de tous les membres de tous les
éléments appartenant à l’entrepôt
Stockage physique de données dans l’entrepôt
Volume de données très important
Stockage physique des résultats des requêtes
Aucun calcul lors de l’interrogation
101/137
Approche des DW
Approche virtuelle :
Pas de matérialisation des éléments de l’entrepôt
Stockage des données dans les systèmes opérationnels sources
Stockage de l’expression de la requête
Nécessité de recalculer les requêtes à chaque appel
102/137
Approche des DW
Approche hybride :
Combinaison entre les approches totale et virtuelle
Implantation physique des niveaux agrégés
Conservation des informations détaillées dans les systèmes de
production
103/137
Stratégies d’implantation d’un ED

3 stratégies :
1 Utilisation d’un SGBD Relationnel (systèmes ROLAP)
SGBDR : Nécessité des adaptations pour répondre aux besoins des ED
Stockage des données dans un SGBDR
Utilisation d’un middle-ware pour implémenter les opérations spécifiques
de l’OLAP
2 Utilisation d’un SGBD Multidimensionnel (systèmes MOLAP)

SGBD capable de stocker et traiter des données multidimensionnelles
Basé sur un stockage par tableau (technique des matrices creuses)
Indexation rapide des données calculées
3 Utilisation d’un SGBD Hybride (systèmes HOLAP)

Tirer profit des avantages des technologies ROLAP et MOLAP :
un ROLAP pour stocker et gérer les données détaillées
un MOLAP pour stocker et gérer les données agrégées
104/137
Conception logique d’un entrepôt
Définition des objets

Définition des relations entre objets
→ Choix d’un modèle de conception (schéma)
Utilisation, par exemple, d’Oracle Designer ou Oracle
WareHouse Builder
105/137
Conception logique d’un entrepôt
ROLAP : schéma de BD relationnelle reflétant la vue de l’analyste

multidimensionnelle
hiérarchisée
schéma en étoile (star schema)
schéma en flocon (snowflake schema)
constellation de faits (fact constellation)
NB: le schéma en étoile est souvent utilisé pour l’implantation
physique
106/137
Schéma en étoile
Structure simple utilisant le modèle entité-relation

une entité/table centrale (table des faits)
objets de l’analyse
taille très importante
beaucoup de champs
des entités/tables périphériques (tables de dimensions)
critères/dimension de l’analyse
taille peu importante
peu de champs
107/137
Exemple de schéma en étoile
108/137
Représentation d’un fait

Il a été acheté 3 exemplaires à 1 euro
du produit pid3
par le client cid1
à la date did3
dans le magasin mid2
dans le chariot cid8
correspondant à la promotion prid1
109/137
Un élément de la dimension localisation :

store id : mid2
store name : Auchan
city Villetaneuse
region Ile de France
country France
110/137
Attributs de la table des faits

des clés étrangères formant une clé primaire
des mesures associées à chaque clé primaire
Association de type (0, n) ↔ (1, 1) connectant les différentes
dimensions aux faits
111/137
Normalisation
Table des faits en forme normale de Boyce-Codd

Tables de dimensions non normalisées
chaque attribut non clé dépend fonctionnellement de la seule clé de la
relation
112/137
Tables de dimensions
Représentation d’une ou plusieurs hiérarchies

Enregistrement de données redondantes
Faut-il les normaliser?
la table des faits constitue l’essentiel du stockage
pas/peu de mises à jour des dimensions
la perte d’espace n’est donc pas significative
→ tables de dimensions : NON normalisées
113/137
Schéma en flocon
Evolution du schéma en étoile

Décomposition des dimensions du modèle en étoile en
sous-hiérarchies
Conservation du fait
Eclatement des dimensions suivant leur hiérarchie des
paramètres
Normalisation des tables de dimensions
Structure hiérarchique des dimensions
Un niveau inférieur identifie un niveau supérieur
Chaque dimension du schéma en étoile précédent est dénormalisée
114/137
Schéma en flocon
Avantages
Formalisation d’une hiérarchie au sein d’une dimension
Maintenance des tables de dimensions simplifiée
Réduction de la redondance
Inconvénients
Dénormalisation des dimensions générant une plus grande
complexité en termes de lisibilité et de gestion
Navigation coûteuse
115/137
Schéma en flocon
exemple
Chaque dimension du schéma en étoile précédent est dénormalisée
116/137
Schéma de constellation de faits

Modèle en constellation :
Fusion de plusieurs modèles en étoile qui utilisent des
dimensions communes
Enregistrement de plusieurs faits avec des dimensions
communes ou non
Exemple : Vente de médicaments dans des pharmacies
une constellation est constituée de 2 schémas en étoile :
Schéma en étoile 1 : VENTEs effectuées dans les pharmacies
Schéma en étoile 2 : analyse des PRESCRIPTIONs des
médecins
Dimensions Temps et Géographie partagées par les faits
PRESCRIPTION et VENTE
117/137
Schéma de constellation de faits
Généralisation du schéma en étoile

Plusieurs tables des faits
Partage de tables de dimensions
En général, on a
un schéma de constellation de faits pour l’entrepôt
une étoile de la constellation pour un magasin de données
(Data Mart)
118/137
Pré-agrégations
Agrégation des faits selon une ou plusieurs dimensions
2 moyens de les représenter :

1 une table des faits séparée/dédiée avec les tables pour les
dimensions correspondantes
2 dans la même table des faits, en codant les niveaux
hiérarchiques dans les tables de dimensions
119/137
Exemple
cas 1
faits1(idProduit,idVille,idJour,5)
faits2(idProduit,idVille,idMois,60)
avec une table jour et une table mois
cas 2
faits(idProduit,idVille,idDate1,5)
faits(idProduit,idVille,idDate2,5)
avec une table date contenant
date(idDate1, 22, 01, 2010)
date(idDate2, ALL, 01, 2010)
120/137
Implémentation physique
Implémentation physique des DW
Mise en œuvre :
Vues relationnelles matérialisées définies sur les bases sources,
découplées (indépendantes) des sources
Interrogation
BD multidimentionnelles
Outils OLAP
121/137
Phase 1 :
Il faut assurer la migration :
des entités vers des tables
des relations vers des clés étrangères
des attributs vers des colonnes
des identifiants uniques vers des clés primaires
122/137

Phase 2 :
Il faut créer un ensemble de structures parmi les suivantes :
les tablespaces
les tables et les tables partitionnées
les vues
les contraintes d’intégrités
les dimensions, ...
Et pour améliorer les performances
les index et les index partionnés
les vues matérialisées
123/137
Types de vues matérialisées

Vues matérialisées avec agrégations
c r e a t e m a t e r i a l i z e d v i e w l o g on s a l e s
with sequence , rowid ( prod id , c u s t i d , time id , c h a n n e l i d ,
p r o m o i d , q u a n t i t y s o l d , a m o u n t s l d ) i n c l u d i n g new v a l u e s ;
c r e a t e m a t e r i a l i z e d view s u m s a l e s
parallel
b u i l d immediate
r e f r e s h f a s t on commit
as
select e . prod id , s . time id ,
count ( ∗ ) as count grp ,
sum ( s . a m o u n t s o l d ) a s s u m d o l l a r s a l e s ,
count ( s . amount sold ) as c o u n t d o l l a r s a l e s ,
sum ( s . q u a n t i t y s o l d ) a s s u m q u a n t i t y s a l e s ,
count ( s . q u a n t i t y s o l d ) as c o u n t q u a n t i t y s a l e s
from s a l e s s
group by s . p r o d i d , s . t i m e i d ;
124/137

Vues matérialisées contenant seulement des jointures
c r e a t e m a t e r i a l i z e d v i e w l o g on s a l e s w i t h r o w i d ;
c r e a t e m a t e r i a l i z e d v i e w l o g on t i m e s w i t h r o w i d ;
c r e a t e m a t e r i a l i z e d v i e w l o g on c u s t o m e r s w i t h r o w i d ;
c r e a t e m a t e r i a l i z e d view s a l e s m v
p a r a l l e l b u i l d immediate
refresh fast
as
s e l e c t s . rowid ” s a l e s r i d ” , t . rowid ” t i m e s r i d ” ,
c . rowid ” c ustomers rid ” , c . cust id ,
c . cust last name , s . amount sold ,
s . quantity sold , s . time id
from s a l e s s , t i m e s t , c u s t o m e r s c
where s . c u s t i d = c . c u s t i d (+) AND
s . t i m e i d = t . t i m e i d (+);
125/137

Vues matérialisées basées sur d’autres vues
c r e a t e m a t e r i a l i z e d v i e w l o g on s a l e s
with rowid ;
c r e a t e m a t e r i a l i z e d v i e w l o g on t i m e s
with rowid ;
c r e a t e m a t e r i a l i z e d v i e w l o g on c u s t o m e r s
with rowid ;
c r e a t e m a t e r i a l i z e d view j o i n s a l e s c u s t t i m e
r e f r e s h f a s t on commit a s
s e l e c t c . c u s t i d , c . cust last name , s . amount sold ,
s . time id , t . day number in weekn s . r o w i d s r i d ,
t . rwoid trid , c . rwoid crid
from s a l e s s , t i m e s t , c u s t o m e r s c
where s . c u s t i d = c . c u s t i d AND s . t i m e i d = t . t i m e i d ;
126/137
c r e a t e m a t e r i a l i z e d view l o g j o i n s a l e s c u s t t i m e
with rowid ( cust name , day number in weekn amount sold )
i n c l u d i n g new v a l u e s ;
c r e a t e m a t e r i a l i z e d view s u m s a l e s c u s t t i m e
r e f r e s h f a s t on commit a s
s e l e c t c o u n t ( ∗ ) c n t a l l , sum ( a m o u n t s o l d ) s u m s a l e s ,
count ( amount sold ) c n t s a l e s , c u s t l a t n a m e ,
day number in week
from j o i n s a l e s c u s t t i m e
group by c u s t l a s t n a m e , d a y n u m b e r i n w e e k ;
127/137
Maintenance
Maintenance des DW
Quand et comment assurer les mises à jour (la maintenance)

d’un entrepôt ?
Quelles anomalies peuvent être causées par la maintenance ?
A quel niveau pourrait-on automatiser cette maintenance ?
Comment mesure et assurer la performance et quel critère
choisir ?
La maintenance ou l’auto-maintenance poura-t-elle à elle
seule garantir les performances ?
128/137
Maintenance
Maintenance des DW
refreshing
3 stratégies :
1 Reconstruction périodique
la plus simple
la plus longue
elle suppose une longue période d’indisponibilité
2 Mise à jour périodique
volume de données concerné plus petit
algorithmes plus complexes que pour une reconstruction
3 Mise à jour instantanée
nécessite de nombreuses communications
129/137
Maintenance
Pas reconstruction
Rafraı̂chissement périodique et de manière incrémentale

Prise en compte des changements des sources
Suppression des données anciennes
130/137
Maintenance
Détection des changements
Dépend des sources

Triggers utilisés pour déclencher la mise à jour
Exploitation des logs des changements
Extraction des changements pertinents par requêtes
Comparaison de différentes images de la source
131/137
Maintenance
Comparaison d’image de la source

principe
F1 et F2 deux images de la source ensemble d’enregistrements de

la forme (K , B)
calculer F1 - F2 et F2 - F1
déduire insert,K ,B et delete,K ,B
calculer la jointure de F1 et F2
sélectionner les enregistrements où la partie B contient des
différences
déduire (update, K ,B)
132/137
Maintenance
Maintenance de vue
Contexte
la source signale les mises à jour
l’entrepôt questionne la source
la source envoie les données concernées
l’entrepôt met la vue à jour
133/137
Maintenance
Maintenance de vue
Solutions possibles
Verrouillage des sources pour la mise à jour de l’entrepôt

contraignant pour les sources
Recalcul de la vue
coûteux en temps et en ressource
Garder des copies de chaque relation impliquée dans une vue
coûteux en espace et en propagation de mises à jour
134/137
Maintenance
Maintenance de vue
Problème des requêtes évaluées

à la source
après changement de l’état de la source
→ Compensation à la demande :
Compenser l’effet de la mise à jour par les requêtes
(Eager Compensating Algorithm – ECA)
135/137
Maintenance
Maintenance des vues matérialisées
Maintenance de données
Pour la maintenance périodique
→ Utilisation des vues matérialisées partionnées suivant des
dates
Pour les maintenances immédiates et différées
→ Utilisation des commandes refresh on commit et
refresh on demand
136/137
Maintenance
A suivre : OLAP, manipulation OLAP, évolution SQL
137/137

CoursDWH AIR3 Cours1

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

CoursDWH AIR3 Cours1

Transféré par

Droits d'auteur :

Formats disponibles

Entrepôts de données

F. Boufares, LIPN, Université Paris Nord

1970 − 1980 − 1990

Entrepôts de données (grosses masses de données)

Applications : Gestion des risques, Analyse des ventes

Grosse volumétrie : travail d’optimisation et suivi des activités

Applications : Gestion des risques, Analyse des ventes

Hiérarchique Structure de données

INGRES, DB2, Sybase,

Quelle quantité d’information ? sous quelle forme ?

Comment accèder à ces données, tirer partie de ces données ?

Des bases de données aux Entrepôts de données

La majeure partie des applications Bases de Données reposent

Couche Présentation Graphical User Interfaces GUI GUI

Couche Application OLTP Application OLTP Application Decision support System

Couche Base de Données BD1 BD2

Les applications interrogent les données avec, par exemple,

Celles-ci doivent avoir certaines propriétés ACID (Atomicité,

Ce type d’application est appelé On-Line Transaction Processing

→ Systèmes d’Information Décisionnel

Systèmes d’Aide à la Décision (DSS) :

Contrairement aux applications OLTP, qui consultent et

Un ensemble de méta-données est utilisés pour les 2 systèmes.

Cependant, il y a plusieurs désavantages :

La solution est de séparer

Le Data Warehouse est une collection de données orientées sujet,

L’ensemble des opérations associées peut être présenté en 4

Architecture des DWHs

Le DWH intègre des données à partir de sources multiples et

Nouveaux concepts/nouvelle perspective

Recherche de connaissances cachées dans les données (modèle

Visualisation des données de l’ED

Objectif: Faciliter l’analyse et l’interprétation de données

BD opérationnelle vs. Entrepôts de données

BD opérationnelle vs. Data Warehouse : OLTP vs. OLAP

Systèmes OLTP Systèmes OLAP

Applications en Controle et chargement des données OLAP Outils Front−End

Conception logique des DWHs

Ceux de l’informatique décisionnelle (Business Intelligence)

Commerce, finance, transport, télécommunications, santé, services,

Principales applications autour d’un ED

Réalisation de rapports divers (Reporting )

Tableaux de bords (Dashboards) :

Grande masse de données :

Domaines très demandeurs de techniques décisionnelles pour

Définitions (Inmon 1996)

Un entrepôt de données est une collection de données orientées

Définitions (Inmon 1996)

Définitions (Inmon 1996)

Définitions (Inmon 1996)

Construction et d’exploitation d’un entrepôt de données

Présentation des couches

Couche Présentation Graphical User Interfaces GUI GUI

Couche Application OLTP Application OLTP Application Decision support System

Insert, Update, Delete Read, Select

Couche Base de Données BD2

Applications en Controle et chargement des données OLAP Outils Front−End

Architecture fonctionnelle de l’entrepôt

Applications en Controle et chargement des données OLAP Outils Front−End

Entrepôts et magasins de données

Entrepôts et magasins de données

Entrepôt vs. Data mart

Caractéristiques Entrepôt Data Mart