Entrepôts de données

(1)

Entrepˆ ots de donn´ ees

Premi`ere partie

Thierry Hamon

Bureau H202 Institut Galil´ee - Universit´e Paris 13

&

LIMSI-CNRS hamon@limsi.fr

https://perso.limsi.fr/hamon/Teaching/P13/DWH-AIR3-2020- 2021/

AIR3 – DWH

(2)

Sources des transparents

F. Boufares, LIPN, Universit´e Paris Nord P. Marcel, LI, Universit´e de Tours

Bernard Espinasse, Ecole Polytechnique Universitaire de Marseille

Melanie Herschel, Universit´e Paris Sud

(3)

Pr´ esentation du cours

Dans la suite du cours de AIR2 et AIR3 sur les BD Objectifs de l’enseignement :

Connaˆıtre et manipuler des notions liées aux Entrepôts de données (ED/DWH)

Introduction et définition d’un entrepôt de données Modélisation et Architecture d’un entrepôt de données OLAP et implémentation des entrepôts de données Répartition des enseignements

3×3h de cours Partiel

4×3h de TP

Evaluation lors du dernier TP

(4)

Pr´ esentation du cours

Programme des enseignements

Introduction et définition d’un entrepôt de données Modélisation et Architecture d’un entrepôt de données OLAP et implémentation des entrepôts de données

4×3h de TP

(5)

Pr´ esentation du cours

Programme des enseignements

Introduction et définition d’un entrepôt de données Modélisation et Architecture d’un entrepôt de données OLAP et implémentation des entrepôts de données Répartition des enseignements

4×3h de TP

(6)

Historique

G´en´erations de SGBD

Volume de données Type de données Indépendance physique Portabilité

Hiérarchies, Réseaux

SGBD 1 1960 − 1970 − 1980

1970 − 1980 − 1990 Relationnels

SGBD 2

SGBD 3 1980 − 1990 − 2000

Avancés

SGBD4/5 2004/5 − 2010

2010 − 202X?

Big Data

Puissance

(7)

Historique

Applications 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

Volume de données Type de données

Performance

(8)

Historique

Applications BD, ED, FD, ...

Entrepôts de Données Intégration de Données Bases de Données

Applications : Paie, Marketing, Financière

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)

Volume de données Type de données

(9)

Historique

Structure et type de donn´ees

Relationnelle

& objet

Structure de données TABULAIRE Relations

Hiérarchique

& Réseau

Structure de données en RESEAU

Stockage et calcul distribués

Puissance

Cohérence Performance Structure HIERARCHIQUE

des données

Type de données COMPLEXE

Cloud computing

(10)

Historique

Exemples de SGBD

SGBD 1

COADSYL, 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 Intégration de Données

SGBD4/5

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

XML, ...

MapReduce, Hadoop Teradata, Oracle

Puissance

(11)

Quelle quantit´ e d’information ? sous quelle forme ?

Il y a plus de 15 ans !

en 2000 :

entre 1 et 2 ExaOctets par ann´ee (1 Eo = 2²⁰ To) 90% ´electronique

taux 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 accèder à ces données, tirer partie de ces données ?

→Les bases de donn´ees ne suffisent plus

(12)

Des bases de donn´ ees aux Entrepˆ ots de donn´ ees

(13)

Introduction

Avant les entrepˆots de donn´ees/Data Warehouses

La majeure partie des applications Bases de Donn´ees reposent aujourd’hui sur trois couches :

La couche la plus externe est celle de qui permet de pr´esenter les donn´ees aux utilisateurs.

Elle est appel´eeGraphical User Interfaces GUI.

La couche application interm´ediaire inclut le programme de l’application

Elle ne stocke pas les donn´ees.

La couche la plus interne g`ere le stockage des donn´ees.

Elle est appel´ee la coucheBase de Donn´ees.

(14)

Introduction

BD1

Graphical User Interfaces GUI GUI

Couche Présentation

BD2

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

Decision support System OLTP Application OLTP Application

Couche Application

Couche Base de Données

Insert, Update, Delete

Read, Select

(15)

Introduction

Les applications interrogent les donn´ees avec, par exemple, le langage SQL (Select)

et les mettent à jour par l’intermédiaire des opérations Insert,UpdateetDelete

qui constituent des transactions.

Celles-ci doivent avoir certaines propriétésACID (Atomicité, Cohérence, Isolation et Durabilité)

Ce type d’application est appel´e On-Line Transaction Processing OLTP.

(16)

Introduction

Données volumineuses & Besoins nouveaux Vers les entrepôts de données

→Syst`emes d’Information D´ecisionnel

Systèmes d’Aide à la Décision (DSS) :

Rapports, Etats, Tableaux de Bord, Graphiques, Synthèses, Groupement, Agrégat, Résumé ...

(Reporting Tools, Management Information System, Executive Information System, Decision Support System DSS)

(17)

Introduction

Vers les entrepˆots de donn´ees Remarques

Contrairement aux applications OLTP, qui consultent et mettent à jour les données des BD opérationnelles, les DSS lisent les données seulement pour avoir de nouvelles informations à partir des données sources Bénéfice de cette approche : seules les BD opérationnelles ont à être créées et maintenues

Un ensemble de méta-données est utilisés pour les 2 systèmes.

Les DSS ne n´ecessitent que des travaux suppl´ementaires mineurs.

(18)

Introduction

Vers les entrepˆots de donn´ees Remarques

Cependant, il y a plusieurs d´esavantages :

(quand le DSS et les applications OLTP se partagent les mêmes BD) Un DSS ne peut utiliser que les données actuellement stockées dans les BD

les analyses historiques sont donc souvent impossibles à cause des opérations de mises à jour qui changent les données historiques L’utilisation des BD en mode multi-utilisateurs

ce qui implique des opérations de verrouillage des données (Locking operations) et donc des problèmes de performance

car les requêtes analytiques demandent l’accès à de très grands nombre de tuples.

(19)

Introduction

La solution est de s´eparer la BD orient´ee Transaction

de la BD orientée Aide à la Décision d’où la naissance du concept

Entrepˆot de Donn´ees = Data Warehouse.

Les DWH sont physiquement séparés des SGBD opérationnels (BD opérationnelles)

(20)

Introduction

D´efinition rapide d’un Data Warehouse

Le Data Warehouse est une collection de données orientées sujet, intégrées, non volatiles, historisées, organisées pour le support d’un processus d’aide à la décision

Un système de DWH peut être formellement défini comme un triplet

L’ensemble des opérations associées peut être présenté en 4 catégories (ETL, Agrégation et Groupement)

(21)

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

(22)

Introduction

Le DWH intègre des données à partir de sources multiples et hétérogènes

afin de répondre aux requêtes du système d’aide à la décision.

Ce type d’application est appel´e On-Line Analytical Processing OLAP

OLAP permet la transformation des donn´ees en informations strat´egiques

(23)

Nouveaux concepts/nouvelle perspective

Entrepˆot de donn´ees

r´ecolte, stockage et gestion efficace des gros volumes de donn´ees

OLAP

requˆetes interactives complexes sur ces volumes Data mining (fouille de donn´ees)

extraction automatique de propriétés cachées données→ information→ connaissances

(24)

Analyse OLAP

(On-Line Analytical processing)

Techniques OLAP :

apparition en recherche dans les ann´ees 70

mais développement dans les années 90 dans l’industrie Réalisation de synthèses, d’analyses et de la consolidation dynamique de données multidimensionnelles

Manière la plus naturelle d’exploiter un ED étant donné son organisation multidimensionnelle

(25)

Fouille de donn´ ees

(Data Mining)

Recherche de connaissances cachées dans les données (modèle de comportement)

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

Méthodes : régression linéaire, arbres de décision, réseaux de neurones, ...

Int´egration croissante dans les entrepˆots

(26)

Visualisation des donn´ ees de l’ED

Objectif: Faciliter l’analyse et l’interprétation de données Synthèse des données de l’entrepôt

→ Conversion des donn´ees complexes de l’entrepˆot en images,

en graphiques 2D et 3D en animations

(27)

Introduction : Comparaison

Pourquoi pas des SGBDs pour les entrepôts de données ? les 2 systèmes sont performants

SGBD : calibré pour l’OLTP ; méthodes d’accès index, contrôle de concurrence, reprise

Entrepôt : calibré pour l’OLAP ; requêtes OLAP complexes, vue dimensionnelle, consolidation

Fonctions et donn´ees diff´erentes

Données manquantes : l’aide à la décision (AD) a besoin des données historiques qui ne se trouvent pas dans les BD opérationnelles

Consolidation : l’AD a besoin de données consolidées (agrégats) alors qu’elles sont brutes dans les BD opérationnelles

(28)

Introduction : Comparaison

SGBD hétérogènesvs. Entrepôts de données

Traditionnellement, l’intégration de BD hétérogènes se fait par le biais de

Wrappers/médiateurs au dessus des BD hétérogènes Approches orientées requêtes

Quand une requête est posée sur un site client, un métadictionnaire est utilisé pour la traduire en plusieurs requêtes appropriées à chacune des BD. Le résultat est l’intégration de réponses partielles

L’ex´ecution des requˆetes demande donc beaucoup de ressources

Entrepôts de données : approche orientée mise à jour les informations sont intégrées et stockées pour une

(29)

Introduction : Comparaison

BD opérationnelle vs. Entrepôts de données OLTP (On-Line Transaction Processing)

Ex´ecution en temps r´eel des transactions, pour

l’enregistrement des op´erations quotidiennes : inventaires, commandes, paye, comptabilit´e

Par opposition au traitement en batch OLAP (On-Line Analytical Processing)

Traitement efficace des requêtes d’analyse pour la prise de décision qui sont par défaut assez complexes (bien qu’a priori, elles peuvent être réalisées par les SGBD classiques)

(30)

Introduction : Comparaison

BD opérationnelle vs. Data Warehouse : OLTP vs. OLAP Données : courantes, détailléesvs. historiques, consolidées Conception : modèle ER + applicationvs. modèle en étoile + sujet

Vues : courantes, locales vs. évolutive, intégrée

Mode d’accès : mise à jourvs. lecture seule mais requêtes complexes

(31)

Introduction : Comparaison

Systèmes OLTP Systèmes OLAP Données exhaustives Données résumées

Données courantes Données historiques Données dynamiques Données statiques Données non volumineuses Données Volumineuses

Orient´es applications Orient´es sujets Utlisateurs nombreux Utilisateurs peu nombreux

Utilisateurs variés Décideurs Mises à jour, interrogation Interrogations

Réquêtes simples Requêtes complexes

(32)

Architecture du DWH

Architecture Multi-tiers

MVS (TSO, DB2 ...)

DataWareHouse UNIX (Oracle, ...)

Windows (SQL Server, Excel, ...)

Dictionnaire de Méta−données

Oracle 9i (Olap) Oracle Express

Data select (requetes)

Business Objects (rapports, analyses)

SAS (Datamining)

Data Marts

OLAP SERVER

T(ransform) L(oad) E(xtract)

00 11 0000 1111

(33)

Conception logique des DWHs

Donn´ees multidimentionnelles

Montant des ventes comme une fonction des param`etres produits, mois, r´egion

Dimensions : Produit, Lieu, Temps

Catégorie

Chemins de consolidation hiérarchiques

Produit

Mois Région

Industrie

Produit

Pays

Ville Magasin

Année

Jour

Semaine Mois

Trimestre Région

(34)

Domaines d’application

Ceux de l’informatique d´ecisionnelle (Business Intelligence) pour

aider atteindre les objectifs strat´egiques 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.)

(35)

Domaines d’application

Informatique d´ecisionnelle

Entrepˆot de donn´ees

Outils de veille strat´egique et de recueil d’information (intelligence ´economique)

Aide aux décideurs pour prendre les bonnes décisions sur la base des données disponibles

Exemples :

Quels sont les 5 produits les plus vendus pour chaque sous-catégorie de produits qui représente plus de 20% des ventes dans sa catégorie de produits ?

Quelle est la priorit´e d’exp´edition 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

´

eté expédiées ?

(36)

Applications

Commerce, finance, transport, télécommunications, santé, services, ...

gestion de la relation client

gestion des commandes, des stocks pr´evisions de ventes

d´efinition de profil utilisateur analyse de transactions bancaires d´etection de fraudes

...

(37)

Principales applications autour d’un ED

Réalisation de rapports divers (Reporting) Réalisation de tableaux de bords (Dashboards) Fouille de données (Data Mining)

Visualisations autour d’un ED (visualizations) ...

(38)

Exploitation d’un ED

Rapports (Reporting) :

Besoin d’un accès régulier à des informations presque figées Ex: dans les hôpitaux, rapports mensuels envoyés aux agences nationales

Rapport :

une ou plusieurs requˆetes

une mise en page (diagrammes, histogrammes) Production manuelle ou automatique des rapports

(39)

Exploitation d’un ED

Tableaux de bords (Dashboards) :

Affichage d’une quantité limitée d’informations dans un format graphique facile à lire

Utilisation fr´equente par les cadres sup´erieurs pour avoir (qui ont besoin) un rapide aper¸cu des changements les plus importants

→ un aper¸cu en temps r´eel d’´evolutions

Ex : Paris 13 en chiffres(paris13en-chiffres2014.pdf) Remarque : Pas vraiment utile pour une analyse complexe et d´etaill´ee

(40)

Exemples d’application

Domaine bancaire

Un des premiers utilisateurs des ED

Regroupement des informations relatives `a un client pour une demande de cr´edit

Lors de la commercialisation d’un nouveau produit : Mailing ciblés rapidement élaborés à partir de toutes les informations disponibles sur un client

Recherche de fraudes sur les cartes de cr´edit :

Mémorisation des mouvements et contrôlesa posteriori, pour détecter les comportements suspects

Echanges d’actions et de conseils de courtages´ Déterminer des tendances de marchés grâce à :

la m´emorisation de l’historique

(41)

Exemples d’application

Grande distribution

Regroupement d’informations sur les ventes pour l’analyse du comportement

(produits à succès, suivi des modes, habitudes d’achats, préférences des clients par secteur géographique)

Mise en évidence les règles de consommation grâce à la fouille de données

Cas d’école : Explo(r|it)ation du panier de la ménagère : connaˆıtre les produits achetés en même temps

Impacts :

augmentation des ventes grâce à un meilleur marketing amélioration des taux de rotation de stocks

´

elimination des produits obsol`etes

d´efinition des rabais, remises, ristournes, promotions meilleure n´egociation des achats

(42)

Exemples d’application

T´el´ecommunications

Grande masse de donn´ees :

Plusieurs mois de descriptions détaillées des appels Pour chaque appel : appelant, appelé, heure et durée Exploitation de ces données pour

analyser le trafic

mieux cerner les besoins des clients classer les clients par cat´egories

comprendre le comportement des clients (changement d’op´erateurs, besoins)

(43)

Exemples d’application

Assurance et de la pharmacie

Domaines très demandeurs de techniques décisionnelles pour Déterminer le facteur de risque d’un assuré

Meilleure connaissance des clients, d´etection de rejets, ciblage du marketing, etc

Détecter l’impact d’un médicament, ses effets indésirables, etc.

Couplage avec les technologies du Web : Data Webhouse (encore plus de donn´ees et donc plus d’informations)

(44)

D´ efinitions (Inmon 1996)

Un entrepôt de données est une collection de données orientées sujet, intégrées, non volatiles, historisées, organisées pour le support d’un processus d’aide à la décision

Orient´e Sujet : Le but des DWH est

d’am´eliorer la prise de d´ecision, de planification,

et le contrˆole des sujets majeurs de l’entreprise comme les relations entre les clients, les produits, les r´egions

contrairement des applications OLTP qui sont organis´ees autour des flux de donn´ees de l’entreprise

(45)

D´ efinitions (Inmon 1996)

Données Intégrées:

Les données dans un DWH sont chargées de différentes sources contenant des données sur différents formats.

Les données doivent être vérifiées, triées et tranformées dans un format unifié afin de faciliter et accélérer l’accès.

(46)

D´ efinitions (Inmon 1996)

Données Historisées: et donc datées :

avec une conservation de l’historique et de son ´evolution pour permettre les analyses comparatives (par exemple, d’une ann´ee sur l’autre, etc.).

Dans un Data Warehouse, un référentiel de temps est nécessaire : c’est l’axe temps ou l’axe période.

(47)

D´ efinitions (Inmon 1996)

Donnn´ees Non-volatiles : stables

en lecture seule non modifiables

Afin de conserver la tra¸cabilité des informations et des décisions prises, les informations stockées au sein du Data Warehouse ne doivent pas disparaˆıtre...

(48)

Construction et d’exploitation d’un entrepˆ ot de donn´ ees

Processus en 3 phases :

1 Construction de la BD d´ecisionnelle

Modélisation conceptuelle des données multiformes et multi-sources Conception de l’entrepôt de données

Alimentation de l’entrepˆot (extraire, nettoyer, transformer, charger) Stockage physique des donn´ees

2 Sélection des données à analyser Besoins d’analyse de l’utilisateur Data marts (Magasins de données) Cubes multidimensionnels

Tableaux ou tables bidimensionnels

3 Analyse des donn´ees

(49)

Pr´ esentation des couches

Graphical User Interfaces GUI GUI

Couche Présentation

BD2 BD1

Target DataBase

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

Decision support System OLTP Application OLTP Application

Couche Application

Couche Base de Données

Insert, Update, Delete Read, Select

Load DataWareHouse

(50)

Architecture du DWH

Architecture Multi-tiers

MVS (TSO, DB2 ...)

Data Marts

OLAP SERVER

00 11 0000 1111

(51)

Op´ erations

Extraction (Extraction) : Ces opérations permettent de filtrer les données à partir de données sources (BD, fichiers, sites web...) dans des BD temporaires.

Transformation (Transformation) : Ces op´erations permettent de transformer les donn´ees extraites dans un format uniforme.

Les conflits entre les modèles, les schémas et les données sont résolus durant cette phase.

Chargement(Load) : Ces opérations permettent de charger les données transformées dans la BD cible.

La BD cible est souvent implant´ee avec un SGBD relationnel-objet.

Agrégat et Groupement(Agregating and Grouping) : La BD cible doit permettre de stocker les données opérationnelles et les données issues de calculs.

(52)

Architecture

Introduction

Objectifs :

regrouper les données sources concevoir le schéma de l’entrepôt remplir l’entrepôt

maintenir l’entrepˆot

(53)

Architecture fonctionnelle de l’entrepˆ ot

Les données d’un entrepôt se structurent suivant un axe synthétique : établissement d’une hiérarchie d’agrégation incluant

les données détaillées : les événements les plus récents les données agrégées : synthèse des données détaillées les données fortement agrégées : synthèse à un niveau supérieur des données agrégées

un axe historique

incluant les données détaillées historisées représentant les

´

ev´enements pass´es

→Stockage des méta-données : informations concernant les données de l’ED (provenances, structures, méthodes utilisées pour l’agrégation, ...)

(54)

Architecture du DWH

MVS (TSO, DB2 ...)

Applications en

Data Marts

OLAP SERVER

Outils Front−End

Controle et chargement des données OLAP

00 11 0000 1111

(55)

Entrepˆ ots et magasins de donn´ ees

Data Warehouses et Data marts

Entrepˆots de donn´ees

Collecte l’ensemble de l’information utile aux décideurs à partir des sources de données (BD opérationnelle, BD externes, ...) Centralisation de l’information décisionnelle

Garantie de l’intégration des données extraites et de leur pérennité dans le temps

Magasins de donn´ees Orient´es sujet

Aide efficace aux processus OLAP

Extraction d’une partie des donn´ees utiles : pour une classe d’utilisateurs ou

pour un besoin d’analyse sp´ecifique

(56)

Entrepˆ ots et magasins de donn´ ees

Calcul, stockage, organisation

Entrepˆots de donn´ees

Puissantes machines pour la gestion de très grandes bases de données de détail historisées

Lieu de stockage centralisé d’un extrait des bases de production Organisation des données suivant un modèle facilitant la gestion efficace des données et leur historisation

Magasins de donn´ees

Petits entrepôts avec une infrastructure plus légère, mise en œuvre rapide

Données extraites d’un ED ou de BD existantes pour un besoin d’aide à la décision particulier

Organisation des donn´ees suivant un mod`ele facilitant les

(57)

Entrepˆ ot vs. Data mart

Caract´eristiques Entrepˆot Data Mart

utilisateur toute l’entreprise un d´epartement

BD SQL type serveur BD MD, OLAP

´

echelle du modèle de données entreprise département

champs applicatifs multi-sujet quelques sujets

sources de donn´ees multiples quelques unes

stockage plusieurs BD distribu´ees une BD

taille >100 Go 10 `a 20 Go

temps de mise en place 9 `a 18 mois 6 `a 12 mois

coˆut plusieurs Me 100 Ke`a 0,5 Me

mat´eriel Unix Petit serveur

(58)

Vue logique de l’entrepˆ ot

Hiérarchie de dépôts :

Operational Data Store (ODS)

regroupement des données intégrées récupération des sources

Corporate Data Warehouse (CDW) regroupement les vues agr´eg´ees

(59)

BD vers Data marts

(60)

Architecture fonctionnelle d’un ED : 3 niveaux

Extraction de données des BD (OLTP) et de l’extérieur, selon 2 stratégies :

détection instantanée des mises à jour sur les BD pour intégration dans l’ED (approchepush)

détection périodique des mises à jour des BD pour intégration dans l’ED (approchepull)

Fusiondes donn´ees dans l’ED

Intégration, chargement et stockage des données dans l’entrepôt, organisées par sujet

Rafraˆıchissement au fur et à mesure des mises à jour Exploitationdes données

Rapports, tableaux de bords, visualisation, ...

Analyse et exploration des donn´ees entrepos´ees (OLAP)

(61)

Niveau extraction

Moniteur et Adaptateur de sources Moniteur (source monitor) :

Rˆole :

détection des mises à jour effectuées sur la source d’information identification les données à envoyer à l’ED pour sa mise à jour Implémentation :

Utilisation de triggers si les SGBD en disposent

Sinon, interrogation périodique de chaque base locale ou son journal afin de récupérer les mises à jour effectuées durant la dernière période

Adaptateur de source (source wrapper) : Rˆole :

traduction des requêtes et les données depuis le modèle d’une source vers le modèle de l’ED et vice-versa

(62)

Niveau fusion

M´ediateur M´ediateur (mediator) :

Rˆole :

donner une vision intégrée des différentes sources d’information extraire des parties de ces vues intégrées (à l’aide de requêtes) :

Obligation/besoin de nettoyer, transformer, r´eorganiser et filtrer les donn´ees

Intégration et fusion des données issues de sources multiples Implémentation :

utilisation du SGBD de l’entrepˆot

fusion grˆace `a des unions ou des jointures de sources multiples, des

(63)

Niveau exploitation

Moteur OLAP et outils de fouille

Moteur OLAP

Traitement des données de l’ED ou des Magasins de données : Exécution des requêtes interactives complexes

Analyse interactive des donn´ees suivant des points de vue ou des niveaux de d´etail particuliers

Visualisation des r´esultats de ces analyses Op´erations OLTP classiques

Outils de fouille de donn´ees (Data Mining) :

Traitement des données de l’ED ou des Magasins de données : Extraction automatique de propriétés cachées

Extraction automatique de connaissances valides, nouvelles, compr´ehensibles, pertinentes, implicites, ...

(64)

Dictionnaire et m´ eta-donn´ ees

Dictionnaire contenant des informations (méta-données) sur : toutes les données de l’ED

chaque ´etape de la construction de l’ED

le passage d’un niveau de donn´ees `a un autre (exploitation de l’ED)

Rôle : définition, fabrication, stockage, accès et présentation des données

(65)

Donn´ ees sources

Les données des entreprises sont généralement : Surabondantes

Eparpill´ees

Peu structurées pour l’analyse Modifiées quotidiennement Problème : Prise de décision difficile

Solution : Utilisation d’outils et de techniques visant à préparer les données pour l’analyse Data warehousing

Il s’agit d’une technique visant à extraire des données de différentes sources afin de les intégrer selon des formats plus adaptés à l’analyse et la prise de décision

→Problématique d’intégration et définition dewrappers

(66)

Donn´ ees sources h´ et´ erog` enes

Nécessité d’intéger des données hétérogènes, modifiées quotidiennement

BD

relationnelles objets distribu´ees fichiers textes

documents HTML, XML bases de connaissances ...

Mais aussi des repr´esentations de donn´ees et de noms de

(67)

Probl` eme des sources h´ et´ erog` enes

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

(68)

Sources h´ et´ erog` enes

Pour un même concept : schémas différents noms d’attribut différents types de données différents valeurs différentes

s´emantiques diff´erentes

(69)

H´ et´ erog´ en´ eit´ e des donn´ ees et des applications

Illustration

Source d’information Application gestion commerciale progiciel sybase

gestion marketing progiciel SQL server gestion financi`ere, paye DB2/IBM

suivi de production Oracle contrˆole qualit´e Oracle gestion du temps Oracle gestion des stocks Oracle

fichier mailings Fichier ASCII r´ef´erences nationales Document excel source (Goglin, 1998)

(70)

Processus d’alimentation d’un ED

Entreposage des donn´ees

Rˆole de l’alimentation de l’entrepˆot

rassembler de multiples données sources souvent hétérogènes

homogénéiser les données sources

Homogénéisation réalisée selon des règles précises Les règles d’homogénéisation sont :

mémorisées sous forme de méta-données stockées dans le dictionnaire de données

utiliser pour assurer des tâches d’administration et de gestion des données entreposées

(71)

Processus d’alimentation d’un ED

Après avoir con¸cu le modèle des données, comment alimenter l’entrepôt ?

Faut-il ramener toutes les donn´ees sous le mˆeme format ? Si oui, quel format choisir et pourquoi ?

Sinon, comment faire pour interroger toutes ces diff´erentes structures ?

Quel(s) langage(s) d’interrogation va-t-on utiliser ? Quelle architecture utiliser ?

→probl´ematique de l’ETL (Extracting, Transforming and Loading)

(72)

Processus d’alimentation d’un ED

4 ´etapes :

1 S´election des donn´ees sources

2 Extraction des donn´ees

3 Nettoyage et Transformation

4 Chargement

Etapes 1 et 2 : Jusqu’à 80 % du temps de développement d’un entrepôt

→outil : Oracle Warehouse Builder (OWB)

(73)

S´ election des donn´ ees sources

Quelles donn´ees de production faut-il s´electionner pour alimenter l’ED ?

Définir l’utilité des données sources

Doit-on prendre l’adresse complète ou séparer le code postal ? Réorganiser les données sélectionnées pour qu’elles deviennent des informations

Faire une synthèse des données sources pour les enrichir Dénormaliser les données pour créer des liens entre les données et permettre des accès différents

(74)

Extraction des donn´ ees

Un extracteur (wrapper) est associé à chaque source de données Sélection et extraction des données

Formatage des données dans un format cible commun en général, le modèle Relationnel

Utilisation d’interfaces comme ODB, OCI, JDBC

(75)

Nettoyage et Transformation des donn´ ees

Objectifs du nettoyage :

Résolution des problèmes de consistance des données au sein de chaque source

Remarques :

une centaine de type d’inconsistances ont été répertoriées 5 à 30 % des données des BD commerciales sont erronées

(76)

Types d’inconsistances

Présence de données fausses dès leur saisie fautes de frappe

diff´erents formats dans une mˆeme colonne texte masquant de l’information (e.g., ”N/A”) valeur nulle

incompatibilit´e entre la valeur et la description de la colonne duplication d’information, ...

Persistance de donn´ees obsol`etes

Confrontation de données sémantiquement équivalentes mais syntaxiquement différentes

(77)

Nettoyage des donn´ ees

Fonctions d’analyse Fonctions de normalisation Fonctions de conversion

Usage de dictionnaires de synonymes ou d’abréviations Définition de table de règles remplacer valeur par

Mr M

monsieur M

mnsieur M

masculin M

M M

Msieur M

M. M

Monseur M

Utilisation d’expressions r´eguli`eres, suppression de doublons, de valeur nulle, ...

(78)

Nettoyage des donn´ ees

fonctions de conversion

(79)

Transformation

Objectif : suppression des incohérences sémantiques entre les sources, problématique lors de l’intégration

des sch´emas des donn´ees

(80)

Transformation

Problèmes lors de l’intégration des schémas

Probl`eme de mod´elisation

Utilisation de différents modèles de données Problèmes de terminologie

2 noms différents pour désigner un objet 2 objets différents désignés par un même nom Incompatibilités de contraintes

Contraintes incompatibles pour 2 concepts ´equivalents

(81)

Transformation

Problèmes lors de l’intégration des schémas

Conflit s´emantique

Diff´erents niveaux d’abstraction pour un mˆeme concept Conflits de structures

Différentes propriétés pour un même concept Conflits de représentation

2 représentations différentes choisies pour les mêmes propriétés d’un même objet

(82)

Transformation

Résolution des problèmes survenant lors de l’intégration des schémas

Demande une solide connaissance de la s´emantique des sch´emas

Peu trait´ee par les produits du march´e Nombreux travaux de recherche

Opération généralement réalisée à la main...

(83)

Transformation

Résolution des problèmes survenant lors de l’intégration des schémas

Utilisation d’heuristiques de réconciliation des schémas basées sur l’existence de similarités entre :

noms de tables et d’attributs types de donn´ees

instances

structure des schémas contraintes d’intégrité

(84)

Transformation

Problème lors de l’intégration des données

Equivalence de champs´ Equivalence d’enregistrements´

(85)

Transformation

Résolution des problèmes survenant lors de l’intégration des données

´Equivalence de champs :

Deux chaˆınes sont ´equivalentes si l’une est le pr´efixe de l’autre

→ Mesure de la compatibilit´e des champs Pour 2 champsc1 et c2

n(c_i):=nombre de chaˆınes dec_i n_e :=le nombre de chaˆınes ´equivalentes compatibilit´e :=ne/((n(c1) +n(c2))/2)

(86)

Transformation

Résolution des problèmes survenant lors de l’intégration des données

´Equivalence d’enregistrements : fusion d’enregistrements

pour tous les tuples concern´es si noss1 = noss2 et nom1 = nom2

fusionner personne1 et personne2 si (noss1 = noss2 ou nom1 = nom2)

et adresse1 = adresse2

fusionner personne1 et personne2 ...

(87)

Chargement des donn´ ees

Objectif : Stockage des données nettoyées et préparées dans la BD opérationnelle (ODS)

Op´eration :

risquant d’être assez longue plutôt mécanique

la moins complexe

Mais il est nécessaire de définir et mettre en place : des stratégies pour assurer de bonnes conditions à sa réalisation

une politique de rafraˆıchissement

(88)

Chargement des donn´ ees

Définitions de vues relationnelles sur les données sources Matérialisation des vues dans l’entrepôt

Mais aussi, pr´eparation `a la restitution tris

consolidations (pr´e-agr´egation) indexation

partitionnement des données enregistrement de méta-données ...

(89)

Pr´ eparation ` a la restitution

Agr´egation

Calcul de vues agrégées Définition des indexes Stockage dans le CDW Personnalisation

Construction de magasins de donn´ees (Data Marts) Construction de cubes de donn´ees

Construction des pr´esentations demand´ees par les utilisateurs

(90)

M´ eta-donn´ ees

Toutes les informations n´ecessaires pour la construction et l’administration de l’entrepˆot

informations présentes dans l’entrepôt données source

données dérivées, dimensions, hiérarchies contraintes d’intégrités schéma de l’entrepôt indexes, partitions

requêtes prédéfinies ...

informations d’administration

r`egles de nettoyage, transformation, extraction politique de rafraˆıchissement

s´ecurit´e

monitoring, statistiques

(91)

M´ eta-donn´ ees

Chaque composant de l’entrepôt fournit des méta-données

doit connaitre celles des autres composants doit savoir où ces méta-données sont situées Une BD est dédiée aux méta-données

(92)

Common Warehouse Metamodel

Spécification d’un langage d’échange de méta-données d’entrepôt proposé par l’OMG (Object Management Group)

bas´e notamment sur UML, XML

con¸cu par IBM, Unisys, NCR, Oracle, Hyperion, ...

(93)

Mod´ elisation multidimensionnelle

Lien direct entre les analyses d´ecisionnelles (OLAP) et une mod´elisation de l’information conceptuelle :

proche de la perception qu’en a l’analyste

basée sur une vision multidimensionnelle des données Modèle multidimensitionnel : les données sont vues comme des data cubes

Un cube de dimensionn est dit uncubo¨ıde

Le treillis des cubo¨ıdes d’un entrepˆot de donn´ees forme un data cube

La mod´elisation multidimensionnelle a donn´e naissance aux concepts de fait et de dimension (Kimball 1996)

(94)

Cube de donn´ ees

(95)

Exemple de treillis de cube

(96)

Cube de donn´ ees

Sujet analysé : un point dans un espace à plusieurs dimensions Organisation des données pour mettre en évidence le sujet analysé et les différentes perspectives de l’analyse

data cube (par exemple, les ventes) : vision des donn´ees sur plusieurs dimensions

(97)

Concept de fait

Un fait :

mod´elisation du sujet de l’analyse

Mesures correspondant aux informations de l’activité analysée Mesures numériques, généralement valorisées de fa¸con

continue. On peut les additionner les d´enombrer

calculer le minimum, le maximum ou la moyenne Exemple : le fait deVente peut être constitué des mesures d’activités suivantes :

quantit´e de produits vendus montant total des ventes

(98)

Concept de dimension

Axes ou perspectives caract´erisant les mesures de l’activit´e d’un fait Une dimension :

mod´elisation un axe d’analyse

nécessité pour chaque dimension, de définir ses différents niveaux de détail

→Définition d’une (ou plusieurs) hiérarchie(s) de paramètres se compose de paramètres correspondant aux informations faisant varier les mesures de l’activité

Dans l’exemple pr´ec´edent :

Analyse du faitVente suivant diff´erentes perspectives correspondant

`

a trois dimensions :

la dimension Temps

(99)

Hi´ erarchie des param` etres d’une dimension

Hi´erarchie de param`etres d’une dimension :

D´efinition des niveaux de d´etail de l’analyse sur cette dimension

Exemple :

Dimension temps :

H1 : jour <mois<trimestre <année H2 : jour <mois<semestre<année H3 : jour <mois<saison<année Dimension géographie :

ville<d´epartement<region´

Dimension cat´egorie :

couleur<nomProduit<gamme<typeProduit

(100)

Objets intervenant dans les sch´ emas

Tables de faits (fact tables)

Les faits num´eriques (les mesures)

Les clés étrangères vers les tables de dimension Tables de dimension (dimension tables)

composées d’une ou plusieurs hiérarchies catégorisant les données

Identifiant unique

Pour distinguer les enregistrements dans les tables Relations entre les objets

elles assurent l’intégrité des opérations

(101)

Objets intervenant dans les sch´ emas

Exemple de tables de dimension : i t e m ( nom item , marque , t y p e )

temps ( j o u r , s e m a i n e , mois , t r i m e s t r e , a n n e e ) La table des faits contient des mesures unites_vendues les clés externes font référence à chaque table de dimension

(102)

Type d’approches des DW

Approche mat´eralis´ee Approche virtuelle Approche hybride

(103)

Approche des DW

Approche mat´eralis´ee :

Instanciation (mat´erialisation) de tous les membres de tous les

´

eléments appartenant à l’entrepôt

Stockage physique de données dans l’entrepôt Volume de données très important

Stockage physique des r´esultats des requˆetes Aucun calcul lors de l’interrogation

(104)

Approche des DW

Approche virtuelle :

Pas de matérialisation des éléments de l’entrepôt

Stockage des données dans les systèmes opérationnels sources Stockage de l’expression de la requête

Nécessité de recalculer les requêtes à chaque appel

(105)

Approche des DW

Approche hybride :

Combinaison entre les approches totale et virtuelle Implantation physique des niveaux agr´eg´es

Conservation des informations détaillées dans les systèmes de production

(106)

Strat´ egies d’implantation d’un ED

3 strat´egies :

1 Utilisation d’un SGBD Relationnel (syst`emes ROLAP)

SGBDR : Nécessité des adaptations pour répondre aux besoins des ED Stockage des données dans un SGBDR

Utilisation d’un middle-ware pour implémenter les opérations spécifiques de l’OLAP

2 Utilisation d’un SGBD Multidimensionnel (syst`emes MOLAP)

SGBD capable de stocker et traiter des données multidimensionnelles Basé sur un stockage par tableau (technique des matrices creuses) Indexation rapide des données calculées

3 Utilisation d’un SGBD Hybride (syst`emes HOLAP)

Tirer profit des avantages des technologies ROLAP et MOLAP :

(107)

Conception logique d’un entrepˆ ot

D´efinition des objets

D´efinition des relations entre objets

→ Choix d’un mod`ele de conception (sch´ema)

Utilisation, par exemple, d’Oracle Designer ou Oracle WareHouse Builder

(108)

Conception logique d’un entrepˆ ot

ROLAP : sch´ema de BD relationnelle refl´etant la vue de l’analyste multidimensionnelle

hi´erarchis´ee

schéma en étoile (star schema) schéma en flocon (snowflake schema) constellation de faits (fact constellation)

NB: le schéma en étoile est souvent utilisé pour l’implantation physique