Bases de Donnees AvanceesDataWareHouse
Thierry Hamon
Bureau H202Institut Galilee - Universite Paris 13
&LIMSI-CNRS
https://perso.limsi.fr/hamon/Teaching/P13/BDA-INFO2-2016-2017/
INFO2 – BDA
1/97
Introduction
Les entrepots de donnees/Data Warehouses
La majeure partie des applications Bases de Donnees reposentaujourd’hui sur trois couches :
La couche la plus externe est celle de qui permet de presenterles donnees aux utilisateurs.Elle est appelee Graphical User Interfaces GUI.
La couche application intermediaire inclut le programme del’applicationElle meme et ne stocke pas les donnees.
La couche la plus interne gere le stockage des donnees.Elle est appelee la couche Base de Donnees.
2/97
Introduction
Introduction
Les applications interrogent les donnees avec, par exemple,
le langage SQL (Select)
et les mettent a jour par l’intermediaire des operationsInsert, Update et Delete
qui constituent des transactions.
Celles-ci doivent avoir certaines proprietes ACID (Atomicite,Coherence, Isolation et Durabilite)
Ce type d’application est appele On-Line Transaction ProcessingOLTP.
3/97
Introduction
Introduction
BD1
Graphical User Interfaces GUIGUICouche Présentation
BD2
Ressources externes
(file system, ftp, www, ...)
Decision support SystemOLTP Application OLTP ApplicationCouche Application
Couche Base de Données
Insert, Update, DeleteRead, Select
4/97
Introduction
Quelle quantite d’information ? sous quelle forme ?Il y a plus de 10 ans !
en 2000 :
entre 1 et 2 ExaOctets par annee (1 Eo = 220 To)90% electroniquetaux de croissance annuel de 50 %
en 2003 : 5 Eo en 2002, 92% electronique
Lyman&Varian, 2003 (http://groups.ischool.berkeley.edu/archive/
how-much-info-2003/execsum.htm)
Comment acceder a ces donnees, tirer partie de ces donnees ?→ Les bases de donnees ne suffisent plus
5/97
Introduction
IntroductionDonnees volumineuses & Besoins nouveaux
→ Systemes d’Information Decisionnel
Systemes d’Aide a la Decision :
Rapports, Etats, Tableaux de Bord, Graphiques, Syntheses,Groupement, Agregat, Resume ...(Reporting Tools, Management Information System, ExecutiveInformation System, Decision Support System DSS)
6/97
Introduction
IntroductionRemarques
Contrairement aux applications OLTP, qui consultent etmettent a jour les donnees des BD operationnelles,
les DSS lisent les donnees seulement pour avoir denouvelles informations a partir des donnees sources
Benefice de cette approche : seules les BD operationnelles ont aetre creees et maintenues
Un ensemble de meta-donnees est utilises pour les 2 systemes.
Les DSS ne necessitent que des travaux supplementairesmineurs.
7/97
Introduction
IntroductionRemarques
Cependant, plusieurs desavantages :(quand le DSS et les application OLTP se partagent les memesBD)
Le DSS ne peut utiliser que les donnees actuellement stockeesdans les BDdonc les analyses historiques sont souvent impossibles a cause des
operations de mises a jour qui changent les donnees historiques
L’utilisation des BD en mode multi-utilisateursce qui implique des operations de verrouillage des donnees (Lockingoperations) et donc des problemes de performances
car les requetes analytiques demandent l’acces a de tres grands
nombre de tuples.
8/97
Introduction
Introduction
La solution est de separer
la BD orientee Transactionde la BD orientee Aide a la Decision
d’ou la naissance du conceptEntrepot de Donnees = Data Warehouse.
Les DWH sont physiquement separes des SGBD operationnels (BDoperationnelles)
9/97
Introduction
Applications
Domaines d’application
Ceux de l’informatique decisionnelle (Business Intelligence)pour
aider atteindre les objectifs strategiques d’une entreprise etfaciliter son pilotage
avoir une connaissance plus approfondie de l’entreprise
anticiper les besoins clients
prendre en compte les nouveaux canaux de distribution (venteen ligne, etc.)
10/97
Introduction
Applications
Domaines d’applicationInformatique decisionnelle
Entrepot de donnees
Outils de veille strategique et de recueil d’information(intelligence economique)
Aide aux decideurs pour prendre les bonnes decisions sur labase des donnees disponibles
Exemple :
Quels sont les 5 produits les plus vendus pour chaquesous-categorie de produits qui represente plus de 20% desventes dans sa categorie de produits ?
Quelle est la priorite d’expedition et quel est le revenu brutpotentiel des commandes de livres qui ont les 10 plus grandesrecettes brutes parmi les commandes qui n’avaient pas encoreete expediees ?
11/97
Introduction
Applications
Applications
Commerce, finance, transport, telecommunications, sante, services,...
gestion de la relation client
gestion des commandes, des stocks
previsions de ventes
definition de profil utilisateur
analyse de transactions bancaires
detection de fraudes
...
12/97
Introduction
Applications
Exploitation d’un ED
Rapports (Reporting) :
Besoin d’un acces regulier a des informations presque figeesEx: dans les hopitaux, rapports mensuels envoyes aux agencesnationales
Rapport :
une ou plusieurs requetesune mise en page (diagrammes, histogrammes)
Production manuelle ou automatique des rapports
13/97
Introduction
Applications
Exploitation d’un ED
Tableaux de bords (Dashboards) :
Affichage d’une quantite limitee d’informations dans unformat graphique facile a lire
Utilisation frequente par les cadres superieurs pour avoir (quiont besoin) un rapide apercu des changements les plusimportants→ un apercu en temps reel d’evolutionsEx : Paris 13 en chiffres (paris13en-chiffres2014.pdf)
Remarque : Pas vraiment utile pour une analyse complexe etdetaillee
14/97
Introduction
Applications
Exemples d’applicationDomaine bancaire
Un des premiers utilisateurs des ED
Regrouper les informations relatives a un client pour unedemande de credit
Lors de la commercialisation d’un nouveau produit : mailingcibles rapidement elabore a partir de toutes les informationsdisponibles sur un client
Recherche de fraudes sur les cartes de credit : memorisationdes mouvements et controles a posteriori, pour detecter lescomportements suspects
Echanges d’actions et de conseils de courtagesDeterminer des tendances de marches grace a :
la memorisation de l’histoireune exploitation par des outils decisionnels avances
15/97
Introduction
Applications
Exemples d’applicationGrande distribution
Regroupement d’informations sur les ventes pour l’analyse ducomportement(produits a succes, suivi des modes, habitudes d’achats, preferences
des clients par secteur geographique)
Mise en evidence les regles de consommation grace a la fouillede donneesCas d’ecole : Explo(r|it)ation du panier de la menagere :connaıtre les produits achetes en meme temps
Impacts :
augmentation des ventes grace a un meilleur marketingamelioration des taux de rotation de stockselimination des produits obsoletesdefinition des rabais, remises, ristournes, promotionsmeilleure negociation des achats
16/97
Introduction
Applications
Exemples d’applicationTelecommunications
Grande masse de donnees :
Plusieurs mois de descriptions detaillees des appelsPour chaque appel : appelant, appele, heure et duree
Exploitation de ces donnees pour
analyser le traficmieux cerner les besoins des clientsclasser les clients par categoriescomprendre le comportement des clients (changementd’operateurs, besoins)
17/97
Introduction
Applications
Exemples d’applicationAssurance et pharmacie
Domaines tres demandeurs de techniques decisionnelles pour
Determiner le facteur de risque d’un assure
Meilleure connaissance des clients, detection de rejets, ciblagedu marketing, etc
Detecter l’impact d’un medicament, ses effets indesirables,etc.
Couplage avec les technologies du Web : Data Webhouse(encore plus de donnees et donc plus d’informations)
18/97
Definition d’un DWH
Definition d’un Data WarehouseDefinitions (Inmon 1996)
Le Data Warehouse est une collection de donnees orientees sujet,integrees, non volatiles, historisees, organisees pour le support d’unprocessus d’aide a la decision
Un systeme de DWH peut etre formellement defini comme untriplet <BD cible, meta-donnees, un ensemble d’operations>
L’ensembles des operations peut etre presentes en 4 categories(ETL, Agregation et Groupement)
19/97
Definition d’un DWH
Definition d’un Data WarehouseDefinitions (Inmon 1996)
Oriente Sujet :Le but des DWH est
d’ameliorer la prise de decision, de planification,
et le controle des sujets majeurs de l’entreprise comme lesrelations entre les marchants, les produits, les regions
contrairement des applications OLTP qui sont organisees autourdes flux de donnees de l’entreprise
20/97
Definition d’un DWH
Definition d’un Data WarehouseDefinitions (Inmon 1996)
Donnees Integrees :
Les donnees dans un DWH sont chargees de differentessources contenant des donnees sur differents formats.
Les donnees doivent etre verifiees, triees et tranformees dansun format unifie afin de faciliter et accelerer l’acces.
21/97
Definition d’un DWH
Definition d’un Data WarehouseDefinitions (Inmon 1996)
Donnees Historisees :
et donc datees : avec une conservation de l’historique et deson evolutionpour permettre les analyses comparatives (par exemple, d’uneannee sur l’autre, etc.).
Dans un Data Warehouse un referentiel de temps estnecessaire : C’est l’axe temps ou periode.
22/97
Definition d’un DWH
Definition d’un Data WarehouseDefinitions (Inmon 1996)
Donnnees Non-volatiles :
stables
en lecture seule
non modifiables
Afin de conserver la tracabilite des informations et desdecisions prises, les informations stockees au sein du DataWarehouse ne doivent pas disparaıtre...
23/97
Architecture et conception
Architecture des DWHs
Le DWH integre des donnees a partir de sources multiples etheterogenes
afin de repondre aux requetes du systeme d’aide a la decision.
Ce type d’application est appele On-Line AnalyticalProcessing OLAP
OLAP permet la transformation des donnees en informationsstrategiques
24/97
Architecture et conception
Architecture des DWHs
OLAP
BD opérationnelles
Sources externes
Méta−données
Entrepot de données
Intégrer
Maintenir
Extraire
Nettoyer
Transformer
Charger (Load)
Rafraichir
Utiliser
25/97
Architecture et conception
Construction et d’exploitation d’un entrepot de donneesProcessus en 3 phases :
1 Construction de la BD decisionnelle
Modelisation conceptuelle des donnees multiformes etmulti-sourcesConception de l’entrepot de donneesAlimentation de l’entrepot (extraire, nettoyer, transformer,charger)Stockage physique des donnees
2 Selection des donnees a analyser
Besoins d’analyse de l’utilisateurData marts (Magasins de donnees)Cubes multidimensionnelsTableaux ou tables bidimensionnels
3 Analyse des donnees
Stastiques et reporting, OLAP, Data Mining
26/97
Architecture et conception
Architecture du DWH
MVS (TSO, DB2 ...)
DataWareHouse
UNIX (Oracle, ...)
Windows (SQL Server,
Excel, ...)
Dictionnaire de
Méta−données
Applications en
production
Oracle 9i (Olap)
Oracle Express
Data select
(requetes)
Business Objects
(rapports, analyses)
SAS
(Datamining)
Data Marts
OLAP SERVER
Outils Front−EndControle et chargement des données OLAP
T(ransform)
L(oad)
E(xtract)
����
��������
����
��������
����
��������
27/97
Architecture et conception
Entrepots et magasins de donneesData Warehouses et Data marts
Entrepots de donnees
Collecte l’ensemble de l’information utile aux decideurs a partirdes sources de donnees (BD operationnelle, BD externes, ...)Centralisation de l’information decisionnelleGarantie de l’integration des donnees extraites et de leurperennite dans le temps
Magasins de donnees
Orientes sujetAide efficace aux processus OLAPExtraction d’une partie des donnees utiles :
pour une classe d’utilisateurs oupour un besoin d’analyse specifique
28/97
Architecture et conception
Operations dans un Data Warehouse
Extraction (Extraction) : Ces operations permettent de filtrer lesdonnees a partir de donnees sources (BD, fichiers, sites web...) dansdes BD temporaires.
Transformation (Transformation) : Ces operations permettent detransformer les donnees extraites dans un format uniforme.
Les conflits entre les modeles, les schemas et les donnees sontresolus durant cette phase.
Chargement (Load) : Ces operations permettent de charger lesdonnees transformees dans la BD cible.
La BD cible est souvent implantee avec un SGBD relationnel-objet.
Agregat et Groupement (Agregating and Grouping) : La BD cibledoit permettre de stocker les donnees operationnelles et les donneesissues de calculs.
29/97
Architecture et conception
Architecture fonctionnelle
Architecture fonctionnelle de l’entrepotLes donnees d’un entrepot se structurent suivant
un axe synthetique : etablissement d’une hierarchied’agregation incluant
les donnees detaillees : les evenements les plus recentsles donnees agregees : synthese des donnees detailleesles donnees fortement agregees : synthese a un niveausuperieur des donnees agregees
un axe historique
incluant les donnees detaillees historisees representant lesevenements passes
→ Stockage des meta-donnees : informations concernant les
donnees de l’ED (provenances, structures, methodes utilisees pour
l’agregation, ...)
30/97
Architecture et conception
Architecture fonctionnelle
Architecture fonctionnelle d’un ED : 3 niveaux
Extraction de donnees des BD (OLTP) et de l’exterieur,selon 2 strategies :
detection instantanee des mises a jour sur les BD pourintegration dans l’ED (approche push)detection periodique des mises a jour des BD pour integrationdans l’ED (approche pull)
Fusion des donnees dans l’ED
Integration, chargement et stockage des donnees dansl’entrepot, organisees par sujetRafraıchissement au fur et a mesure des mises a jour
Exploitation des donneesRapports, tableaux de bords, visualisation, ...Analyse et exploration des donnees entreposees (OLAP)Requetes complexes pour analyse de tendance, extrapolation,decouverte de connaissances, ... (Fouille de donnees)
31/97
Architecture et conception
Architecture fonctionnelle
Niveaux extractionMoniteur et Adaptateur de sources
Moniteur (source monitor) :Role :
detection des mises a jour effectuees sur la sourced’informationidentification les donnees a envoyer a l’ED pour sa mise a jour
Implementation :
Utilisation de triggers si les SGBD en disposentSinon, interrogation periodique de chaque base locale ou sonjournal afin de recuperer les mises a jour effectuees durant laderniere periode
Adaptateur de source (source wrapper) :Role :
traduction des requetes et les donnees depuis le modele d’unesource vers le modele de l’ED et vice-versa
32/97
Architecture et conception
Architecture fonctionnelle
Niveau fusionMediateur
Mediateur (mediator) :Role :
donner une vision integree des differentes sourcesd’information
extraire des parties de ces vues integrees (a l’aide derequetes) :
Obligation/besoin de nettoyer, transformer, reorganiser etfiltrer les donneesIntegration et fusion des donnees issues de sources multiples
Implementation :
utilisation du SGBD de l’entrepot
fusion grace a des unions ou des jointures de sourcesmultiples, des selections et des agregats
33/97
Architecture et conception
Architecture fonctionnelle
Niveau exploitationMoteur OLAP et outils de fouille
Moteur OLAPTraitement des donnees de l’ED ou des Magasins de donnees :
Execution des requetes interactives complexesAnalyse interactive des donnees suivant des points de vue oudes niveaux de detail particuliersVisualisation des resultats de ces analysesOperations OLTP classiques
Outils de fouille de donnees (Data Mining) :Traitement des donnees de l’ED ou des Magasins de donnees :
Extraction automatique de proprietes cacheesExtraction automatique de connaissances valides, nouvelles,comprehensibles, pertinentes, implicites, ...
34/97
Architecture et conception
Architecture fonctionnelle
Dictionnaire et meta-donnees
Dictionnaire contenant des informations (meta-donnees) sur :
toutes les donnees de l’ED
chaque etape de la construction de l’ED
le passage d’un niveau de donnees a un autre (exploitation del’ED)
Role : definition, fabrication, stockage, acces et presentationdes donnees
35/97
Architecture et conception
Architecture fonctionnelle
Meta-donneesToutes les informations necessaires pour la construction etl’administration de l’entrepot
informations presentes dans l’entrepot
donnees sourcedonnees derivees, dimensions, hierarchiescontraintes d’integrites schema de l’entrepotindexes, partitionsrequetes predefinies...
informations d’administration
regles de nettoyage, transformation, extractionpolitique de rafraıchissementsecuritemonitoring, statistiquestracage des donnees...
36/97
Architecture et conception
Architecture fonctionnelle
Meta-donnees
Chaque composant de l’entrepot
fournit des meta-donnees
doit connaitre celles des autres composants
doit savoir ou ces meta-donnees sont situees
Une BD est dediee aux meta-donneesSpecification d’un langage d’echange de meta-donnees d’entrepot :Common Warehouse Metamodel
37/97
Donnees sources
Donnees sources
Les donnees des entreprises sont generalement :
Surabondantes
Eparpillees
Peu structurees pour l’analyse
Modifiees quotidiennement
Probleme : Prise de decision difficileSolution : Utilisation d’outils et de techniques visant a preparer lesdonnees pour l’analyse Data warehousing
Il s’agit d’une technique visant a extraire des donnees dedifferentes sources afin de les integrer selon des formatsplus adaptes a l’analyse et la prise de decision
→ Problematique d’integration et definition de wrappers
38/97
Donnees sources
Donnees sources heterogenes
Necessite d’integer des donnees heterogenes, modifieesquotidiennement
BD
relationnellesobjetsdistribuees
fichiers textes
documents HTML, XML
bases de connaissances
...
Mais aussi des representations de donnees et de noms dechamps/colonnes heterogenes
39/97
Donnees sources
Probleme des sources heterogenesExemple
Chaıne de concessionnaires automobiles
concession 1
vehicules(serie, modele, couleur, autoradio, ...)
ex :
vehicules(’1234’, ’Clio 5p, ’rouge’, ’ABS’, ...)
concession 2
automobiles(num serie, modele, couleur)options(num serie, option)
ex :
automobiles(1234, ’Clio’, ’R’)
automobiles(2345, ’Clio’, ’R’)
options(1234, ’ABS)
40/97
Donnees sources
Sources heterogenes
Pour un meme concept :
schemas differents
noms d’attribut differents
types de donnees differents
valeurs differentes
semantiques differentes
41/97
Donnees sources
Processus d’alimentation d’un EDEntreposage des donnees
Role de l’alimentation de l’entrepot
rassembler de multiples donnees sources souventheterogeneshomogeneiser les donnees sources
Homogeneisation realisee selon des regles precises
Les regles d’homogeneisation sont :
memorisees sous forme de meta-donnees stockees dans ledictionnaire de donneesutiliser pour assurer des taches d’administration et degestion des donnees entreposees
42/97
Donnees sources
Processus d’alimentation d’un ED
Apres avoir concu le modele des donnees, comment alimenterl’entrepot ?
Faut-il ramener toutes les donnees sous le meme format ?
Si oui, quel format choisir et pourquoi ?
Sinon, comment faire pour interroger toutes ces differentesstructures ?
Quel(s) langage(s) d’interrogation va-t-on utiliser ?
Quelle architecture utiliser ?
→ problematique de l’ETL (Extracting Transforming and Loading)
43/97
Donnees sources
Processus d’alimentation d’un ED
4 etapes :
1 Selection des donnees sources
2 Extraction des donnees
3 Nettoyage et Transformation
4 Chargement
Etapes 1 et 2 : Jusqu’a 80 % du temps de developpement d’unentrepot
→ outil : Oracle Warehouse Builder (OWB)
44/97
Donnees sources
Selection des donnees sources
Quelles donnees de production faut-il selectionner pour alimenterl’ED ?
Definir l’utilite des donnees sourcesDoit-on prendre l’adresse complete ou separer le code postal ?
Reorganiser les donnees selectionnees pour qu’elles deviennentdes informations
Faire une synthese des donnees sources pour les enrichir
Denormaliser les donnees pour creer des liens entre lesdonnees et permettre des acces differents
45/97
Donnees sources
Extraction des donnees
Un extracteur (wrapper) est associe a chaque source de donnees
Selection et extraction des donnees
Formatage des donnees dans un format cible communen general le modele Relationnel
Utilisation d’interfaces comme ODB, OCI, JDBC
46/97
Donnees sources
Nettoyage et Transformation des donnees
Objectifs du nettoyage :
Resolution des problemes de consistance des donnees au seinde chaque source
Remarques :
une centaine de type d’inconsistances ont ete repertoriees5 a 30 % des donnees des BD commerciales sont erronees
47/97
Donnees sources
Types d’inconsistances
Presence de donnees fausses des leur saisie
fautes de frappedifferents formats dans une meme colonnetexte masquant de l’information (e.g., ”N/A”)valeur nulleincompatibilite entre la valeur et la description de la colonneduplication d’information, ...
Persistance de donnees obsoletes
Confrontation de donnees semantiquement equivalentes maissyntaxiquement differentes
48/97
Donnees sources
Nettoyage des donnees
Fonctions d’analyse
Fonctions de normalisation
Fonctions de conversion
Usage de dictionnaires de synonymes ou d’abreviations
Definition de table de regles remplacer valeur parMr M
monsieur Mmnsieur Mmasculin M
M MMsieur M
M. MMonseur M
Utilisation d’expressions regulieres, suppression de doublons,de valeur nulle, ...
49/97
Donnees sources
Transformation
Objectif : suppression des incoherences semantiques entre lessources, problematique lors de l’integration
des schemas
des donnees
50/97
Donnees sources
TransformationProblemes lors de l’integration des schemas
Probleme de modelisation
Utilisation de differents modeles de donnees
Problemes de terminologie
2 noms differents pour designer un objet2 objets differents designer par un meme nom
Incompatibilites de contraintes
Contraintes incompatibles pour 2 concepts equivalents
51/97
Donnees sources
TransformationProblemes lors de l’integration des schemas
Conflit semantique
Differents niveaux d’abstraction pour un meme concept
Conflits de structures
Differentes proprietes pour un meme concept
Conflits de representation
2 representations differentes choisies pour les memes proprietesd’un meme objet
52/97
Donnees sources
Transformation
Resolution des problemes survenant lors de l’integration desschemas
Demande une solide connaissance de la semantique desschemas
Peu traitee par les produits du marche
Nombreux travaux de recherche
Operation generalement realisee a la main...
53/97
Donnees sources
Chargement des donnees
Objectif : Stockage des donnees nettoyees et preparees dans l’ODS
Operation :
risquant d’etre assez longue
plutot mecanique
la moins complexe
Mais il est necessaire de definir et mettre en place :
des strategies pour assurer de bonnes conditions a sarealisation
une politique de rafraıchissement
54/97
Donnees sources
Chargement des donnees
Definitions de vues relationnelles sur les donnees sources
Materialisation des vues dans l’entrepot
Mais aussi, preparation a la restitution
trisconsolidations (pre-agregation)indexationpartitionnement des donneesenregistrement de meta-donnees...
55/97
Modelisation
Modelisation multidimensionnelle
Lien direct entre les analyses decisionnelles (OLAP) et unemodelisation de l’information conceptuelle :
proche de la perception qu’en a l’analyste
basee sur une vision multidimensionnelle des donnees
Modele multidimensitionnel : les donnees sont vues comme descubes de donnees (data cubes)La modelisation multidimensionnelle a donne naissance auxconcepts de fait et de dimension (Kimball 1996)
56/97
Modelisation
Cube de donnees
57/97
Modelisation
Cube de donnees
Sujet analyse : un point dans un espace a plusieurs dimensions
Organisation des donnees pour mettre en evidence le sujetanalyse et les differentes perspectives de l’analyse
data cube (par exemple, les ventes) : vision des donnees surplusieurs dimensions
58/97
Modelisation
Concept de fait
Un fait :
modelisation du sujet de l’analyse
Mesures correspondant aux informations de l’activite analysee
Mesures numeriques, generalement valorisees de faconcontinue. On peut
les additionnerles denombrercalculer le minimum, le maximum ou la moyenne
Exemple : le fait de Vente peut etre constitue des mesuresd’activites suivantes :
quantite de produits vendus
montant total des ventes
59/97
Modelisation
Concept de dimensionAxes ou perspectives caracterisant es mesures de l’activite d’un faitUne dimension :
modelisation un axe d’analyse
necessite pour chaque dimension, de definir ses differentsniveaux de detail→ Definition de une (ou plusieurs) hierarchie(s) de parametres
se compose de parametres correspondant aux informationsfaisant varier les mesures de l’activite
Dans l’exemple precedent :
Analyse du fait Vente suivant differentes perspectives correspondanta trois dimensions :
la dimension Tempsla dimension Geographiela dimension Categorie
60/97
Modelisation
Hierarchie des parametres d’une dimension
Hierarchie de parametre d’une dimension :
Definition des niveaux de detail de l’analyse sur cettedimension
Exemple :
Dimension temps :
H1 : jour < mois < trimestre < anneeH2 : jour < mois < trimestre < anneeH3 : jour < mois < saison < annee
Dimension geographie :ville < departement < r egion
Dimension categorie :couleur < nomProduit < gamme < typeProduit
61/97
Modelisation
Objets intervenant dans les schemas
Tables de faits (fact tables)
Les faits numeriques (les mesures)Les cles etrangeres vers les tables de dimension
Tables de dimension (dimension tables)
composees d’une ou plusieurs hierarchies categorisant lesdonnees
Identifiant unique
Pour distinguer les enregistrements dans les tables
Relations entre les objets
elles assurent l’integrite des operations
62/97
Modelisation
Objets intervenant dans les schemas
Exemple de tables de dimension :
i t em ( nom item , marque , t y p e )temps ( j o u r , semaine , mois , t r i m e s t r e , annee )
La table des faits contient des mesures unites_vendues
les cles externes font reference a chaque table de dimension
63/97
Implementation d’un entrepot
Type d’approches des DW
Approche materalisee
Approche virtuelle
Approche hybride
64/97
Implementation d’un entrepot
Approches des DWH
Approche materalisee :
Instanciation (materialisation) de tous les membres de tous leselements appartenant a l’entrepot
Stockage physique de donnees dans l’entrepot
Volume de donnees tres important
Stockage physique des resultats des requetes
Aucun calcul lors de l’interrogation
65/97
Implementation d’un entrepot
Approches des DWH
Approche virtuelle :
Pas de materialisation des elements de l’entrepot
Stockage des donnees dans les systemes operationnels sources
Stockage de l’expression de la requete
Necessite de recalculer les requetes a chaque appel
66/97
Implementation d’un entrepot
Approches des DWH
Approche hybride :
Combinaison entre les approches totale et virtuelle
Implantation physique des niveaux agreges
Conservation des informations detaillees dans les systemes deproduction
67/97
Implementation d’un entrepot
Strategies d’implantation d’un ED3 strategies :
1 Utilisation d’un SGBD Relationnel (systemes ROLAP)
SGBDR : Necessite des adaptations pour repondre aux besoins des EDStockage des donnees dans un SGBDRUtilisation d’un middle-ware pour implementer les operations specifiquesde l’OLAP
2 Utilisation d’un SGBD Multidimensionnel (systemes MOLAP)
SGBD capable de stocker et traiter des donnees multidimensionnellesBase sur un stockage par tableau (technique des matrices creuses)Indexation rapide des donnees calculees
3 Utilisation d’un SGBD Hybride (systemes HOLAP)
Tirer profit des avantages des technologies ROLAP et MOLAP :
un ROLAP pour stocker et gerer les donnees detailleesun MOLAP pour stocker et gerer les donnees agregees
68/97
Implementation d’un entrepot
Conception logique d’un entrepot
Definition des objets
Definition des relations entre objets
→ Choix d’un modele de conception (schema)Utilisation, par exemple, d’Oracle Designer ou OracleWareHouse Builder
69/97
Implementation d’un entrepot
Conception logique d’un entrepot
ROLAP : schema de BD relationnelle refletant la vue de l’analyste
multidimensionnelle
hierarchisee
schema en etoile (star schema)
schema en flocon (snowflake schema)
constellation de faits (fact constellation)
NB: le schema en etoile est souvent utilise pour l’implantationphysique
70/97
Implementation d’un entrepot
Schema en etoile
Structure simple utilisant le modele entite-relation
une entite/table centrale (table des faits)
objets de l’analysetaille tres importantebeaucoup de champs
des entites/tables peripheriques (tables de dimensions)
criteres/dimension de l’analysetaille peu importantepeu de champs
71/97
Implementation d’un entrepot
Exemple de schema en etoile
72/97
Implementation d’un entrepot
Schema en etoile
Representation d’un faitIl a ete 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
73/97
Implementation d’un entrepot
Schema en etoile
Un element de la dimension localisation :
store id : mid2
store name : Auchan
city Villetaneuse
region Ile de France
country France
74/97
Implementation d’un entrepot
Schema en etoile
Attributs de la table des faits
des cles etrangeres formant une cle primaire
des mesures associees a chaque cle primaire
Association de type (0, n) ↔ (1, 1) connectant les differentesdimensions aux faits
75/97
Implementation d’un entrepot
Normalisation
Table des faits en forme normale de Boyce-Codd
Tables de dimensions non normalisees
chaque attribut non cle depend fonctionnellement de la seule cle de la
relation
76/97
Implementation d’un entrepot
Tables de dimensions
Representation d’une ou plusieurs hierarchies
Enregistrement de donnees 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 normalisees
77/97
Implementation d’un entrepot
Schema en flocon
Evolution du schema en etoile
Decomposition des dimensions du modele en etoile ensous-hierarchies
Conservation du fait
Eclatement des dimensions suivant leur hierarchie desparametres
Normalisation des tables de dimensions
Structure hierarchique des dimensionsUn niveau inferieur identifie un niveau superieur
Chaque dimension du schema en etoile precedent est denormalisee
78/97
Implementation d’un entrepot
Schema en flocon
Avantages
Formalisation d’une hierarchie au sein d’une dimensionMaintenance des tables de dimensions simplifieeReduction de la redondance
Inconvenients
Denormalisation des dimensions generant une plus grandecomplexite en termes de lisibilite et de gestionNavigation couteuse
79/97
Implementation d’un entrepot
Schema en floconexemple
Chaque dimension du schema en etoile precedent est denormalisee
80/97
Implementation d’un entrepot
Schema de constellation de faits
Modele en constellation :
Fusion de plusieurs modeles en etoile qui utilisent desdimensions communes
Enregistrement de plusieurs faits avec des dimensionscommunes ou non
Exemple : Vente de medicaments dans des pharmacies
une constellation est constituee de 2 schemas en etoile :
Schema en etoile 1 : VENTEs effectuees dans les pharmaciesSchema en etoile 2 : analyse des PRESCRIPTIONs desmedecins
Dimensions Temps et Geographie partagees par les faitsPRESCRIPTION et VENTE
81/97
Implementation d’un entrepot
Schema de constellation de faits
Generalisation du schema en etoile
Plusieurs tables des faits
Partage de tables de dimensions
En general, on a
un schema de constellation de faits pour l’entrepot
une etoile de la constellation pour un magasin de donnees(Data Mart)
82/97
Implementation d’un entrepot
Pre-agregations
Agregation des faits selon une ou plusieurs dimensions
2 moyens de les representer :
1 une table des faits separee/dediee avec les tables pour lesdimensions correspondantes
2 dans la meme table des faits, en codant les niveauxhierarchiques dans les tables de dimensions
83/97
Implementation d’un entrepot
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)
84/97
Maintenance
Maintenance des DW
Quand et comment assurer les mises a jour (la maintenance)d’un entrepot ?
Quelles anomalies peuvent etre causees par la maintenance ?
A quel niveau pourrait-on automatiser cette maintenance ?
Comment mesure et assurer la performance et quel criterechoisir ?
La maintenance ou l’auto-maintenance poura-t-elle a elleseule garantir les performances ?
85/97
Maintenance
Maintenance des DWrefreshing
3 strategies :
1 Reconstruction periodique
la plus simplela plus longueelle suppose une longue periode d’indisponibilite
2 Mise a jour periodique
volume de donnees concerne plus petitalgorithmes plus complexes que pour une reconstruction
3 Mise a jour instantanee
necessite de nombreuses communications
86/97
Maintenance
Pas reconstruction
Rafraıchissement periodique et de maniere incrementale
Prise en compte des changements des sources
Suppression des donnees anciennes
87/97
Maintenance
Detection des changements
Depend des sources
Triggers utilises pour declencher la mise a jour
Exploitation des logs des changements
Extraction des changements pertinents par requetes
Comparaison de differentes images de la source
88/97
Maintenance
Maintenance de vue
Contexte
la source signale les mises a jour
l’entrepot questionne la source
la source envoie les donnees concernees
l’entrepot met la vue a jour
89/97
Maintenance
Maintenance de vueSolutions possibles
Verrouillage des sources pour la mise a jour de l’entrepot
contraignant pour les sources
Recalcul de la vue
couteux en temps et en ressource
Garder des copies de chaque relation impliquee dans une vue
couteux en espace et en propagation de mises a jour
90/97
Maintenance
Maintenance des vues materialisees
Maintenance de donnees
Pour la maintenance periodique→ Utilisation des vues materialisees partionnees suivant desdates
Pour les maintenances immediates et differees→ Utilisation des commandes refresh on commit etrefresh on demand
91/97
Conclusion : BD vs. DWH
Conclusion
Pourquoi pas des BDs pour Data WareHouse ?
les 2 systemes sont performants
SGBD – calibres pour l’OLTP : methodes d’acces index,controle de concurrence, repriseWareHouse - calibres pour l’OLAP : requetes OLAPcomplexes, vue dimensionnelle, consolidation
Fonctions et donnees differentes
Donnees manquantes : l’aide a la decision a besoin des donneeshistoriques qui ne se trouvent pas dans les BD operationnellesConsolidation : l’AD a besoin de donnees consolidees(agregats) alors qu’elles sont brutes dans les BDoperationnelles
92/97
Conclusion : BD vs. DWH
ComparaisonData Warehouse vs. SGBD heterogenes
Traditionnellement, l’integration de BD heterogenes se fait parle biais de
Wrappers/mediateurs au dessus des BDs heterogenesApproches orientees requetes
Quand une requete est posee sur un site client, unmetadictionnaire est utilise pour le traduire en plusieursrequetes appropriees a chacune des BD. Le resultat estl’integration de reponses partiellesL’execution des requetes demandent donc beaucoup deressources
Data Warehouse : approche orientee mise a jour
les informations sont integrees et stockees pour uneinterrogation directe. Plus efficace en cout d’execution desrequetes
93/97
Conclusion : BD vs. DWH
Comparaison
Data Warehouse vs. BD operationnelle
OLTP (On-Line Transaction Processing)
Execution en temps reel des transactions, pourl’enregistrement des operations quotidiennes : inventaires,commandes, paye, comptabilitePar opposition au traitement en batch
OLAP (On-Line Analytical Processing)
Traitement efficace des requetes d’analyse pour la prise dedecision qui sont par defaut assez complexes (bien qu’a priori,elles peuvent etre realisees par les SGBD classiques)
94/97
Conclusion : BD vs. DWH
Comparaison
Data Warehouse vs. BD operationnelle : OLTP vs. OLAP
Donnees : courantes, detaillees vs. historiques, consolidees
Conception : modele ER + application vs. modele en etoile +sujet
Vues : courantes, locales vs. evolutive, integree
Mode d’acces : mise a jour vs. lecture seule mais requetescomplexes
95/97
Conclusion : BD vs. DWH
Comparaison
Systemes OLTP Systemes OLAP
Donnees exhaustives Donnees resumees
Donnees courantes Donnees historiques
Donnees dynamiques Donnees statiques
Donnees non volumineuses Donnees Volumineuses
Orientes applications Orientes sujets
Utlisateurs nombreux Utilisateurs peu nombreux
Utilisateurs varies Decideurs
Mises a jour, interrogation Interrogations
Requetes simples Requetes complexes
96/97
Conclusion : BD vs. DWH
A suivre
Fouille de donnees
97/97
Top Related