Entrep^ots de donn ees - LIMSI · MapReduce, Hadoop Teradata, Oracle Performances Cohérence Puissance 8/136. Introduction Historique Quelle quantit e d’information ? sous quelle

Entrepots de donneesPremiere partie

Thierry Hamon

Bureau H202Institut Galilee - Universite Paris 13

&LIMSI-CNRS

[email protected]

https://perso.limsi.fr/hamon/Teaching/P13/DWH-AIR3-2017-2018/

AIR3 – DWH

1/136

[email protected]

https://perso.limsi.fr/hamon/Teaching/P13/DWH-AIR3-2017-2018/

Sources des transparents

F. Boufares, LIPN, Universite Paris Nord

P. Marcel, LI, Universite de Tours

Bernard Espinasse, Ecole Polytechnique Universitaire deMarseille

2/136

Presentation du cours

Dans la suite du cours de AIR2 et AIR3 sur BD

Objectifs de l’enseignement :Connaıtre et manipuler des notions liees aux Entrepots dedonnees (ED)

Programme des enseignements

Introduction et definition d’un entrepot de donneesModelisation et Architecture d’un entrepot de donneesOLAP et implementation des entrepots de donnees

Repartition des enseignements

2 × 3h de cours (maintenant)Partiel le 5 decembre (14h-17h)4 × 3h de TP (en fevrier/mars)Evaluation lors du dernier TP

3/136








3/136








3/136

Introduction

Historique

HistoriqueGenerations de SGBD

Volu

me

de

don

née

s

Typ

e d

e d

on

née

s

Ind

épen

dan

ce p

hysi

qu

e

Port

ab

ilit

é

Hiérarchies, Réseaux

SGBD 1

1960 − 1970 − 1980

1970 − 1980 − 1990

Relationnels

SGBD 2

SGBD 3

1980 − 1990 − 2000

Avancés

Avancés

SGBD4/5

2004/5 − 2010

2010 − 2020?

Big Data

Puissance

Cohérence

Performance

4/136

Introduction

Historique

HistoriqueApplications BD, ED, FD, ...

Entrepôts de Données

Intégration de Données

Bases de Données

Applications : Paie, Marketing, Financière

(50 tables de quelques milliers de lignes) 50 Mo

Fouille de données

(Analyse du comportement des clients, etc.)

Intégration de plusieurs systèmes d’information nationaux et internationnaux)

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

(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

Téraoctets par jour, Pétaoctets par an

(Applications analytique,

prise de décision, analyse prédictive)

BigData / Datamasse

Volu

me

de

don

née

s

Typ

e d

e d

on

née

s

Performance

5/136

Introduction

Historique

HistoriqueApplications BD, ED, FD, ...

Entrepôts de Données


Bases de Données

Applications : Paie, Marketing, Financière

(OLTP: quelques secondes) (Batch : < 1 heure)

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

Nécessité de modifications techniques et fonctionnelles

au bout de quelques jours

Applications : Gestion des risques, Analyse des ventes

(Batch : < 1 heure)

Applications : Génome, Astronomie

Analyse climatique, Physique quantique,

Analyse tendancielle

(Temps réel)

Volu

me

de

don

née

s

Typ

e d

e d

on

née

s

Performance

6/136

Introduction

Historique

HistoriqueStructure et type de donnees

Volu

me

de

don

née

s

Typ

e d

e d

on

née

s

Ind

épen

dan

ce p

hysi

qu

e

Port

ab

ilit

é

Relationnelle

& objet

Structure de données

TABULAIRE

Relations

Hiérarchique

& RéseauStructure de données

en RESEAU

Stockage etcalcul distribués

Puissance

Cohérence

Performance

Structure HIERARCHIQUE

des données

Type de données

COMPLEXE

Cloud computing

7/136

Introduction

Historique

HistoriqueExemples de SGBD

Volu

me

de

don

née

s

Typ

e d

e d

on

née

s

Ind

épen

dan

ce p

hysi

qu

e

Port

ab

ilit

é

SGBD 1COADSYL,

SOCRATE,

...

ORACLE 5/6

INGRES,

DB2, ...

SGBD 2

SGBD 3

ORACLE 7/8,

INGRES, DB2, Sybase,

Verssant Enjin (O2),

ObjectStore, Orlent,

SQLServer, ACCESS, ...

MySQL, PostGreSQL,

Bases de données

Entrepôts de données


SGBD4/5

ORACLE 9i, 10g, 11g, 12c

DB2, ...

XML, ...

MapReduce, Hadoop

Teradata, Oracle

Performances

Cohérence

Puissance

8/136

Introduction

Historique

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

9/136

http://groups.ischool.berkeley.edu/archive/how-much-info-2003/execsum.htm

http://groups.ischool.berkeley.edu/archive/how-much-info-2003/execsum.htm

Introduction

BD → ED

Des bases de donnees aux Entrepots de donnees

10/136

Introduction

BD → ED

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 ne stocke pas les donnees.

La couche la plus interne gere le stockage des donnees.Elle est appelee la couche Base de Donnees.

11/136

Introduction

BD → ED

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

12/136

Introduction

BD → ED

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.

13/136

Introduction

BD → ED

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)

14/136

Introduction

BD → ED

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.

15/136

Introduction

BD → ED

IntroductionRemarques

Cependant, il y a plusieurs desavantages :(quand le DSS et les application OLTP se partagent les memes BD)

Un DSS ne peut utiliser que les donnees actuellementstockees dans 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 performance

car les requetes analytiques demandent l’acces a de tres grands

nombre de tuples.

16/136

Introduction

BD → ED

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)

17/136

Introduction

BD → ED

IntroductionDefinition d’un Data Warehouse

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)

18/136

Introduction

BD → ED

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

19/136

Introduction

BD → ED

Introduction

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

20/136

Introduction

BD → ED

Nouveaux concepts/nouvelle perspective

Entrepot de donneesrecolte, stockage et gestion efficace des gros volumes

OLAPrequetes interactives complexes sur ces volumes

Data mining (fouille de donnees)extraction automatique de proprietes cacheesdonnees → information → connaissances

21/136

Introduction

BD → ED

Analyse OLAP(On-Line Analytical processing)

Techniques OLAP :

apparition en recherche dans les annees 70mais developpement dans les annees 90 dans l’industrie

Realisation de syntheses, d’analyses et de la consolidationdynamique de donnees multidimensionnelles

Maniere la plus naturelle d’exploiter un ED etant donne sonorganisation multidimensionnelle

22/136

Introduction

BD → ED

Fouille de donnees(Data Mining)

Recherche de connaissances cachees dans les donnees (modelede comportement)

Domaine jeune a l’intersection de l’Intelligence Artificielle, lesStatistiques, les BD

Methodes : regression lineaire, arbres de decision, reseaux deneurones, ...

Integration croissante dans les entrepots

23/136

Introduction

BD → ED

Visualisation des donnees de l’ED

Objectif: Faciliter l’analyse et l’interpretation de donnees

Synthese des donnees de l’entrepot→ Conversion des donnees complexes de l’entrepot

en images,en graphiques 2D et 3Den animations

24/136

Introduction

BD vs. DWH

Introduction

Pourquoi pas des SGBDs pour les entrepots de donnees ?

les 2 systemes sont performants

SGBD : calibre pour l’OLTP ; methodes d’acces index,controle de concurrence, repriseEntrepot : calibre pour l’OLAP ; requetes OLAP complexes,vue dimensionnelle, consolidation

Fonctions et donnees differentes

Donnees manquantes : l’aide a la decision (AD) a besoin desdonnees historiques qui ne se trouvent pas dans les BDoperationnellesConsolidation : l’AD a besoin de donnees consolidees(agregats) alors qu’elles sont brutes dans les BDoperationnelles

25/136

Introduction

BD vs. DWH

Introduction : ComparaisonEntrepots 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 la traduire en plusieursrequetes appropriees a chacune des BD. Le resultat estl’integration de reponses partiellesL’execution des requetes demande donc beaucoup deressources

Entrepots de donnees : approche orientee mise a jour

les informations sont integrees et stockees pour uneinterrogation directePlus efficace en cout d’execution des requetes

26/136

Introduction

BD vs. DWH

Introduction : 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)

27/136

Introduction

BD vs. DWH


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

28/136

Introduction

BD vs. DWH


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

29/136

Introduction

BD vs. DWH

Architecture du DWHArchitecture Multi-tiers

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)

��

��

��

��

��

��

30/136

Introduction

BD vs. DWH

Conception logique des DWHs

Donnees multidimentionnelles

Montant des ventes comme une fonction des parametresproduits, mois, region

Dimensions : Produit, Lieu, Temps

Catégorie

Chemins de consolidation hiérarchiques

Produit

Mois

Régio

n

Industrie

Produit

Pays

Ville

Magasin

Année

Jour

SemaineMois

Trimestre

Région

31/136

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

32/136

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 ?

33/136

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

...

34/136

Introduction

Applications

Principales applications autour d’un ED

Realisation de rapports divers (Reporting)

Realisation de tableaux de bords (Dashboards)

Fouille de donnees (Data Mining)

Visualisations autour d’un ED (visualizations)

...

35/136

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

36/136

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

37/136

paris13en-chiffres2014.pdf

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

38/136

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

39/136

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)

40/136

Introduction

Applications

Exemples d’applicationAssurance et de la 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)

41/136

Definition d’un DWH

Definitions (Inmon 1996)

Un entrepot de donnees est une collection de donnees orienteessujet, integrees, non volatiles, historisees, organisees pour lesupport d’un processus d’aide a la decision

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 clients, les produits, les regions

contrairement des applications OLTP qui sont organisees autourdes flux de donnees de l’entreprise

42/136



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.

43/136



Donnees Historisees :

et donc datees :

avec une conservation de l’historique et de son evolutionpour permettre les analyses comparatives (par exemple,d’une annee sur l’autre, etc.).

Dans un Data Warehouse, un referentiel de temps estnecessaire : c’est l’axe temps ou l’axe periode.

44/136



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

45/136


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

46/136


Presentation des couches

Graphical User Interfaces GUIGUICouche Présentation

BD2

BD1Target DataBase

Ressources externes

(file system, ftp, www, ...)

Decision support SystemOLTP Application OLTP ApplicationCouche Application

Couche Base de Données

Insert, Update, Delete Read, Select

LoadDataWareHouse

47/136


Architecture du DWHArchitecture Multi-tiers

MVS (TSO, DB2 ...)

DataWareHouse

UNIX (Oracle, ...)


Excel, ...)

Dictionnaire de

Méta−données

Applications en

production

Oracle 9i (Olap)

Oracle Express

Data select

(requetes)

Business Objects


SAS

(Datamining)

Data Marts

OLAP SERVER


T(ransform)

L(oad)

E(xtract)

��

��

��

��

��

��

48/136


Operations

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.

49/136

Architecture

ArchitectureIntroduction

Objectifs :

regrouper les donnees sources

concevoir le schema de l’entrepot

remplir l’entrepot

maintenir l’entrepot

50/136

Architecture

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

51/136

Architecture


Architecture du DWH

MVS (TSO, DB2 ...)

DataWareHouse

UNIX (Oracle, ...)


Excel, ...)

Dictionnaire de

Méta−données

Applications en

production

Oracle 9i (Olap)

Oracle Express

Data select

(requetes)

Business Objects


SAS

(Datamining)

Data Marts

OLAP SERVER


T(ransform)

L(oad)

E(xtract)

��

��

��

��

��

��

52/136

Architecture


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

53/136

Architecture


Entrepots et magasins de donneesCalcul, stockage, organisation

Entrepots de donnees

Puissantes machines pour la gestion de tres grandes bases dedonnees de detail historiseesLieu de stockage centralise d’un extrait des bases de productionOrganisation des donnees suivant un modele facilitant lagestion efficace des donnees et leur historisation

Magasins de donnees

Petits entrepots avec une infrastructure plus legere, mise enœuvre rapideDonnees extraites d’un ED ou de BD existantes pour un besoind’aide a la decision particulierOrganisation des donnees suivant un modele facilitant lestraitements decisionnels

54/136

Architecture


Entrepot vs. Data mart

Caracteristiques Entrepot Data Martutilisateur toute l’entreprise un departement

BD SQL type serveur BD MD, OLAPechelle du modele de donnees entreprise departement

champs applicatifs multi-sujet quelques sujetssources de donnees multiples quelques unes

stockage plusieurs BD distribuees une BDtaille > 100 Go 10 a 20 Go

temps de mise en place 9 a 18 mois 6 a 12 moiscout plusieurs Me 100 Kea 0,5 Me

materiel Unix Petit serveur

55/136

Architecture


Vue logique de l’entrepot

Hierarchie de depots :

Operational Data Store (ODS)

regroupement des donnees integreesrecuperation des sources

Corporate Data Warehouse (CDW)

regroupement les vues agregees

56/136

Architecture


BD vers Data marts

57/136

Architecture


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)

58/136

Architecture


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

59/136

Architecture


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

60/136

Architecture


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

61/136

Architecture


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

62/136

Architecture


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

63/136

Architecture


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

64/136

Architecture


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)

65/136

Architecture


Sources heterogenes

Pour un meme concept :

schemas differents

noms d’attribut differents

types de donnees differents

valeurs differentes

semantiques differentes

66/136

Architecture


Heterogeneite des donnees et des applicationsIllustration

Source d’information Application

gestion commerciale progiciel sybasegestion marketing progiciel SQL server

gestion financiere, paye DB2/IBMsuivi de production Oracle

controle qualite Oraclegestion du temps Oraclegestion des stocks Oracle

fichier mailings Fichier ASCIIreferences nationales Document excel

source (Goglin, 1998)

67/136

Architecture

Alimentation de l’ED

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

68/136

Architecture


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)

69/136

Architecture


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)

70/136

Architecture


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

71/136

Architecture


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

72/136

Architecture


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

73/136

Architecture


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

74/136

Architecture


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

75/136

Architecture


Nettoyage des donneesfonctions de conversion

76/136

Architecture


Transformation

Objectif : suppression des incoherences semantiques entre lessources, problematique lors de l’integration

des schemas

des donnees

77/136

Architecture


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

78/136

Architecture


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

79/136

Architecture


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

80/136

Architecture


Transformation

Resolution des problemes survenant lors de l’integration desschemasUtilisation d’heuristiques de reconciliation des schemas basees surl’existence de similarites entre :

noms de tables et d’attributs

types de donnees

instances

structure des schemas

contraintes d’integrite

81/136

Architecture


TransformationProbleme lors de l’integration des donnees

Equivalence de champs

Equivalence d’enregistrements

82/136

Architecture


Transformation

Resolution des problemes survenant lors de l’integration desdonneesEquivalence de champs :

Deux chaınes sont equivalentes si l’une est le prefixe de l’autre→ Mesure de la compatibilite des champs

Pour 2 champs c1 et c2

n(ci ) := nombre de chaınes de cine := le nombre de chaınes equivalentes

compatibilite := ne/((n(c1) + n(c2))/2)

83/136

Architecture


Transformation

Resolution des problemes survenant lors de l’integration desdonneesEquivalence d’enregistrements :

fusion d’enregistrements

pour tous les tuples concernes

si noss1 = noss2 et nom1 = nom2

fusionner personne1 et personne2

si (noss1 = noss2 ou nom1 = nom2)

et adresse1 = adresse2

fusionner personne1 et personne2

...

84/136

Architecture


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

85/136

Architecture


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

86/136

Architecture


Preparation a la restitution

Agregation

Calcul de vues agregeesDefinition des indexesStockage dans le CDW

Personnalisation

Construction de magasin de donnees (Data Marts)Construction de cubes de donneesConstruction des presentations demandees par les utilisateurs

87/136

Architecture

Meta-donnees

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

88/136

Architecture

Meta-donnees

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

89/136

Architecture

Meta-donnees

Common Warehouse Metamodel

Specification d’un langage d’echange de meta-donnees d’entrepot

propose par l’OMG (Object Management Group)

base notamment sur UML, XML

concu par IBM, Unisys, NCR, Oracle, Hyperion, ...

90/136

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

Un cube de dimension n est dit un cuboıde

Le treillis des cuboıdes d’un entrepot de donnees forme undata cube

La modelisation multidimensionnelle a donne naissance auxconcepts de fait et de dimension (Kimball 1996)

91/136

Modelisation

Cube de donnees

92/136

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

93/136

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

94/136

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

95/136

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

96/136

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

97/136

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

98/136

Implementation d’un entrepot

Type d’approches des DW

Approche materalisee

Approche virtuelle

Approche hybride

99/136


Approche des DW

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

100/136


Approche des DW

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

101/136


Approche des DW

Approche hybride :

Combinaison entre les approches totale et virtuelle

Implantation physique des niveaux agreges

Conservation des informations detaillees dans les systemes deproduction

102/136


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

103/136


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

104/136


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

105/136


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

106/136


Exemple de schema en etoile

107/136


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

108/136


Schema en etoile

Un element de la dimension localisation :

store id : mid2

store name : Auchan

city Villetaneuse

region Ile de France

country France

109/136


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

110/136


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

111/136


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

112/136


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

113/136


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

114/136


Schema en floconexemple

Chaque dimension du schema en etoile precedent est denormalisee

115/136


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

116/136


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)

117/136


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

118/136


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)

119/136


Implementation physique

Implementation physique des DW

Mise en œuvre :

Vues relationnelles materialisees definies sur les bases sources,decouplees (independantes) des sources

Interrogation

BD multidimentionnellesOutils OLAP

120/136




Phase 1 :Il faut assurer la migration :

des entites vers des tables

des relations vers des cles etrangeres

des attributs vers des colonnes

des identifiants uniques vers des cles primaires

121/136




Phase 2 :Il faut creer un ensemble de structures parmi les suivantes :

les tablespaces

les tables et les tables partitionnees

les vues

les contraintes d’integrites

les dimensions, ...

Et pour ameliorer les performances

les index et les index partionnes

les vues materialisees

122/136



Types de vues materialiseesVues materialisees avec agregationsc r e a t e m a t e r i a l i z e d view l o g on s a l e sw i t h sequence , r o w i d

( p r o d i d , c u s t i d , t i m e i d , c h a n n e l i d , promo id ,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 sp a r a l l e lb u i l d immediater e f r e s h f a s t on commitass e l e c t e . p r o d i d , s . t i m e i d ,

count (∗ ) as c o u n t g r p ,sum ( s . a m ou n t s o l d ) as s u m d o l l a r s a l e s ,count ( s . a m ou n t s o l d ) 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 ) as 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 sgroup by s . p r o d i d , s . t i m e i d ;

123/136



Types de vues materialiseesVues materialisees contenant seulement des jointuresc r e a t e m a t e r i a l i z e d view 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 view l o g on t i m e sw 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 l o g on c u s t o m e r sw 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 vp a r a l l e l b u i l d immediater e f r e s h f a s tass e l e c t s . r o w i d ” s a l e s r i d ” , t . r o w i d ” t i m e s r i d ” ,

c . r o w i d ” c u s t o m e r s r i d ” , c . c u s t i d ,c . c u s t l a s t n a m e , s . amount so ld ,s . q u a n t i t y s o l d , s . t i m e i d

from s a l e s s , t i m e s t , c u s t o m e r s cwhere 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 (+);

124/136



Types de vues materialisees

Vues materialisees basees sur d’autres vues

c r e a t e m a t e r i a l i z e d view l o g on s a l e sw 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 l o g on t i m e sw 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 l o g on c u s t o m e r sw 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 j o i n s a l e s c u s t t i m er e f r e s h f a s t on commit ass e l e c t c . c u s t i d , c . c u s t l a s t n a m e , s . amount so ld , s . t i m e i d ,

t . d a y n u m b e r i n w e e k n s . r o w i d s r i d , t . r w o i d t r i d ,c . r w o i d c r i d

from s a l e s s , t i m e s t , c u s t o m e r s cwhere 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/136



Types de vues materialisees

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 ew i t h r o w i d ( cust name , d a y n u m b e r i n w e e k n am o u n t s o 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 c u s t t i m er e f r e s h f a s t on commit ass e l e c t count (∗ ) 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 ( a m o u n t s o l d ) c n t s a l e s , c u s t l a t n a m e ,d a y n u m b e r i n w e e k

from j o i n s a l e s c u s t t i m egroup 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 ;

126/136

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 ?

127/136

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

128/136

Maintenance

Pas reconstruction

Rafraıchissement periodique et de maniere incrementale

Prise en compte des changements des sources

Suppression des donnees anciennes

129/136

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

130/136

Maintenance

Comparaison d’image de la sourceprincipe

F1 et F2 deux images de la source ensemble d’enregistrements dela forme (K ,B)

calculer F1 - F2 et F2 - F1

deduire insert,K ,B et delete,K ,B

calculer la jointure de F1 et F2

selectionner les enregistrements ou la partie B contient desdifferences

deduire (update, K ,B)

131/136

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

132/136

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

133/136

Maintenance

Maintenance de vue

Probleme des requetes evaluees

a la source

apres changement de l’etat de la source

→ Compensation a la demande :

Compenser l’effet de la mise a jour par les requetes(Eager Compensating Algorithm – ECA)

134/136

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

135/136

Maintenance

A suivre : OLAP, manipulation OLAP, evolution SQL

136/136

Documents

Entrep^ots de donn ees - LIMSI · MapReduce, Hadoop Teradata, Oracle Performances Cohérence Puissance 8/136. Introduction Historique Quelle quantit e d’information ? sous quelle