Bases de données Décisionnelles

Hicham BEHJA
 Plan
I. Data Warehouses
1. Problématique
2. Applications
3. Bases de données transactionnelles
4. Entrepôts de données
II. Extraction de connaissances à partir de données (ECD)
1. Définitions
2. Étapes de l’ECD
3. Techniques de l’ECD

2
I. DATA WARHOUSES

3
 1. Problématique

● Objectif
– Améliorer les performances décisionnelles de l'entreprise
● Décisions stratégiques
● Décisions rapides
● Comment ?
– Répondant aux demandes d’analyse des décideurs :
● Qui sont mes clients ?
● Qui sont mes meilleurs clients actuellement?
● Pourquoi sont-ils mes clients ?
● Comment les conserver ou les faire revenir ?
● Ces clients seront-ils intéressants pour moi ?
● Quels sont nos 10 produits les plus bénéficiaires sur la période 2004-2005?
● ...
4
 1. Problématique
● Problèmes à prendre en compte
– Une grande masse de données :
● Distribuée
● Hétérogène
● Très Détaillée
– A traiter :
● Synthétiser / Résumer
● Visualiser
● Analyser
– Pour une utilisation par :
● des experts et des analystes d'un métier
● NON informaticiens
● NON statisticiens
5
 1. Problématique

Les entreprises passent à l’ ère de l’information.

Défi : Transformer leur système d’information qui avait

une vocation de production à un SI décisionnel dont la
vocation de pilotage devient majeure.

6
 2. Applications
● Banque, Assurance
– déterminer les profils client
– Risque d'un Prêt, Prime plus précise
● Commerce
– ciblage de clientèle
– déterminer les promotions
– aménagement des rayons (2 produits en corrélation)

7
 2. Applications
● Santé
– épidémiologie (VIH, ...)
● Économétrie
– prédiction de trafic autoroutier
● Ressources Humaines
– adéquation activité / personnel
● Web
– Restructuration des sites

8
 3. Évolution technologique des BD
Collection des données (avant 1960):
- Traitements primitives des fichiers

SGBD (1970’s):
- SGBDR, et les réseaux d’ordinateurs,
- Langages de requêtes,
- Méthodes d’optimisations

Sytèmes de BD Avancé (1980’s - présent): Data warehousing & data

- Modèle de données avancé (extended-relational, mining (1990’s - présent):
OO, deductive, etc.),
- application-oriented SGBD (GIS, scientific,
engineering, etc.).

Nouvelle génération des SI (2000 - ...)

9
 3. Systèmes transactionnels
● Le transactionnel réfère à un mode
d’exploitation de données tourné vers la
saisie, le stockage, la mise à jour, la sécurité
et l’intégrité des données.
● Par exemple, les systèmes de gestion des
transactions boursières ou bancaires, dont
les guichets automatiques ou les systèmes
d’inventaire dans les magasins

10
 3. Systèmes transactionnels
(Operational Data Store ou Legacy System)
« Le système transactionnel est
généralement une base de données,
développée par application, stockant les
données courantes d’une organisation, c’est-
à-dire qu’il n’y a pas de données d’archives
dans les systèmes transactionnels » (Bédard
et al. 1997)

11
 3. Systèmes transactionnels
● Le système transactionnel réfère aux bases
de données développées afin de gérer les
transactions quotidiennes
● Ces bases de données supportent
habituellement des applications
particulières telles que les inventaires de
magasins, les réservations d’hôtel, etc

12
 3. Systèmes transactionnels
● Le contenu est fait de données actuelles, pas
d’archives
● Les données sont très détaillées (détails de
chacune des transactions)
● La mise à jour s’effectue par de nouvelles
transactions
● Très souvent plusieurs de ces systèmes existent
indépendamment les uns des autres dans les
grandes organisations

13
3. Systèmes transactionnels
La plupart des systèmes transactionnels sont
implantés selon une structure relationnelle
normalisée (à différents degrés) :
– Redondance minimum
– Intégrité des données
– Facilité de mise à jour

14
 3. Systèmes transactionnels
Opérations dans les systèmes transactionnels

● Ajout
● Effacement
● Mise à jour
des enregistrements (habituellement, gros volume
de transactions impliquant chacune un petit
volume de données détaillées)

● Requêtes simples (de type non-agrégatif)

15
 3. Obstacles à l’analyse dans
les systèmes transactionnels
● Les bases de données transactionnelles sont habituellement normalisées de
telle sorte que la duplication des données est à son minimum :
– Assure l’intégrité des données
– Simplifie la mise à jour des données

● Cependant, une très forte normalisation complexifie l’analyse des données:

– Nombre élevé de tables donc nombre élevé de jointures nécessaires entre
les tables (performance pauvre)
– Temps de traitement long
– Élaboration complexe des requêtes

è Difficulté d’optimiser le fonctionnement des systèmes transactionnels et

des systèmes d’aide à la décision qui partagent la même structure de
données.

16
 3. Obstacles à l’analyse dans
les systèmes transactionnels
● De plus, les types d’analyses servant aux processus de décision des
organisations nécessitent :
– Données sommaires (agrégées ou résumées) sur l’ensemble de
l’organisation (provenant des différentes BD dispersées de l’organisation
et intégrées)
– Données historiques
– Réponses rapides (requêtes surtout de type agrégatif), interfaces à l’usager
faciles à utiliser

è Besoin de systèmes dédiés à l’analyse

17
 4. Entrepôts de données
● Origine de deux besoins distincts mais
complémentaires :
● Besoin pour une entreprise d’avoir un panorama complet de
son information
● Besoin pour un département de mieux gérer les données de
l’entreprise
● Tel que mentionné : difficulté d’optimiser le
fonctionnement des systèmes transactionnels et
des systèmes d’aide à la décision qui partagent le
même ordinateur, la même plate-forme logicielle
et la même structure de données

18
 4. Le Système d’Information

Moyen d’atteindre ces objectifs :

● Un système d’information dédié aux
applications décisionnelles

– En Aval des bases de production (ie bases

opérationnelles)
– En Amont des prises de décision

19
 4. L’Entrepôt de Données

D’après BILL Inmon :

“Un DW est une collection de données thématiques,

intégrées, non volatiles et historisées, organisées
pour la prise de décision.”

20
 4. L’Entrepôt de Données

● Principe
– Base de Données utilisée à des fins d’analyse.
– Transformer des données en information.
– Organisation des données par métier, sujets ou thèmes.
– Intégration des données de production et de gestion et des données
externes
– transformation, agrégation, structuration des données.
● Objectif:
– Retrouver une information historique et transversale à l’entreprise

21
 4. L’Entrepôt de Données

● Caractéristiques :
– orientation sujets («métiers»): à la différence des organisations
traditionnelles organisées par processus fonctionnel
– données intégrées: divers sources de données ;
– données non volatiles: ne pas supprimer les données du DW;
– données datées: trace des données, suivre l’évolution des
indicateurs.

● Comment:
– Fédérer/Regrouper l'ensemble des données de l'entreprise

22
 4. L’Entrepôt de Données

● Les différentes phases du Data warehousing

– Conception
– Construction
– Administration

23
 4. L’Entrepôt de Données

● Conception
– Il s’agit de définir la finalité du DW :
● Piloter quelle activité de l’entreprise ;

● Déterminer et recenser les données à entreposer ;

● Définir les aspects techniques de la réalisation ;

– modèle de données ;
– démarches d’alimentation ;
– stratégies d’administration ;
– définition des espaces d’analyse ;

24
 4. L’Entrepôt de Données

● Construction
– Travail technique.
● Extraction des données des différentes BD de production (internes ou
externes)
● Nettoyage des données, règles d’homogéinisation des données sous
formes de méta données.
● Techniques d’alimentation :
– Chargement des données dans le DW ;
– Fréquences de rafraîchissement :
• par applications d’ interfaces entre les sources de données et le DW ;
• par serveurs de réplication du SGBD ou par outils spécialisés.

25
 4. L’Entrepôt de Données
● Administration
– Assurer la cohésion du système :
● Respecter la cohérence et la fiabilité des informations.
● Unifier la représentation des données.
● Respecter la cohérence des concepts.
● Vérifier la non redondance des informations.
– Simplifier techniquement les systèmes d’information :
● Diminuer le nombre de fichiers.
● Unifier la saisie et le stockage des informations.
● Organiser les mises à jour et la diffusion des informations.
– la qualité et la pérennité des données aux différents applicatifs ;
– la maintenance ;
– la gestion de configuration ;
– les mises à jour ;
– l’organisation, l’optimisation du SI ;
– la mise en sécurité du SI.

26
Différences entre données du système de production et données décisionnelles
Données opérationnelles Données décisionnelles

Orientées application, détaillées, précises au Orientée activité (thème, sujet), condensées,

moment de l’accès représentes des données historiques

Mise à jour interactive possible de la part des Pas de mise à jour interactive de la part des
utilisateurs utilisateurs
Accédées de façon unitaires par une personne à la Utilisées par l’ensemble des analystes, gérées par
fois sous-ensemble
Cohérence atomique Cohérence globale

Uniques (pas de redondance en théorie) Peuvent être redondantes

Structure statique, contenu variable Structure flexible

Petite quantité de données utilisées par un Grande quantité de données utilisée par les
traitement traitements
Réalisation des opérations au jour le jour Cycle de vie différent

Forte probabilité d’accès Faible probabilité d’accès

Utilisées de façon répétitive Utilisée de façon aléatoire

27
 4. La Suite Décisionnelle
Source de données :
DATAWAREHOUSE :
diverses bases de données
Entrepôt de données
« opérationnelles »
« Décisionnelles »
Base de données Agrégées

Base Base Modèle

tampon filtrée « Hypecube »

Métabase :
Description des données

E.T.L. :
Extract Transform and
Load
KDD
PILOTAGE
28
 4. L’Entrepôt de Données

● Quatre points sont déterminants dans la démarche de

création d'un Data Warehouse :
– Les évolutions technologiques : L'entreprise définit son
architecture en fonction de ses besoins.
– La stratégie de l'entreprise : le Data Warehouse est très proche de
la stratégie de l'entreprise.
L'objectif du Data Warehouse se définit en terme métier.
– L'amélioration continue : un Data Warehouse doit évoluer en
fonction des demandes utilisateurs ou des nouveaux objectifs de
l'entreprise.
– La maturité de l'entreprise : certaines entreprises ont déjà un
système décisionnel. D'autres n'ont aucun acquis.
29
 4. Constitution de l'entrepôt
● Extraction des données
– Besoin d’outils spécifiques pour :
● accès aux bases de production (requêtes sur des BD hétérogènes)
● qualité des données : «nettoyer», filtrer, ...
● transformation des données : intégrer, homogénéiser
● datation systématique des données
● Référentiel
– La métabase contient des métadonnées : des données sur les
données du D.W.
● quelles sont les données «entreposées», leur format, leur signification
● les processus de récupération/extraction dans les bases sources
● la date du dernier chargement de l’entrepôt
● l’historique des données sources et de celles de l’entrepôt
30
 4. La Suite Décisionnelle
Source de données :
DATAWAREHOUSE :
diverses bases de données
Entrepôt de données
« opérationnelles »
« Décisionnelles »
Base de données Agrégées

Base Base Modèle

tampon filtrée « Hypecube »

Métabase :
Description des données

E.T.L. :
Extract Transform and
Load
KDD
PILOTAGE
31
 Les composants de base du
DW
Outil de

Alimenter

Alimenter
Datamart 1 requetage
Stockage
Dimensionnel ad-hoc
Extraire

Fichiers plats,
Orienté sujet
SGBDr,
Dédié à un Générateurs d’
autres groupe état
d’utilisateur
TRAITEMENTS
Nettoyage
Application
Transformation Datamart 2 data mining

Système Zone de préparation des Serveur de présentation de DW Portail de

source données restitution

32
 Datamart
● Sous-ensemble d’un entrepôt de données
● Destiné à répondre aux besoins d’un secteur ou
d’une fonction particulière de l’entreprise
● Point de vue spécifique selon des critères métiers
Datamarts du
service Marketing

Datamart du service
DW de l’entreprise Ressources Humaines

33
 Intérêt des datamart
● Nouvel environnement structuré et formaté en
fonction des besoins d’un métier ou d’un usage
particulier
● Moins de données que DW
– Plus facile à comprendre, à manipuler
– Amélioration des temps de réponse
● Utilisateurs plus ciblés: DM plus facile à définir

34
 Les flux de données
● Flux entrant
– Extraction: multi-source, hétérogène
– Transformation: filtrer, trier, homogénéiser, nettoyer
– Chargement: insertion des données dans l’entrepôt
● Flux sortant:
– Mise à disposition des données pour les utilisateurs
finaux

35
 Les différentes zones de
l’architecture
● Zone de préparation (Staging area)
– Zone temporaire de stockage des données extraites
– Réalisation des transformations avant l’insertion dans le DW:
●Nettoyage
● Normalisation…
– Données souvent détruites après chargement dans le DW
● Zone de stockage (DW, DM)
– On y transfère les données nettoyées
– Stockage permanent des données
● Zone de présentation
– Donne accès aux données contenues dans le DW
– Peut contenir des outils d’analyse programmés:
● Rapports
● Requêtes…

36
Cycle de vie décisionnel

37
 Cycle de vie décisionnel
Planification

● La planification aborde la définition et l'étendue du

projet de l'entrepôt, y compris l'appréciation du niveau
de maturité de l'organisation face à ce type d'approche.

● Elle se concentre sur les besoins en terme de ressources

et de niveau de qualification, couplés aux affectations
des tâches, à leur durées et à leur séquencement.

● La planification dépend bien évidemment des besoins.

38
 Cycle de vie décisionnel
Définition des besoins

● Il est essentiel de bien comprendre les utilisateurs et

leurs besoins, sinon l'entrepôt deviendra rapidement
un exercice vain de la part de l'équipe des concepteurs.

● Les besoins une fois définis constituent le point de

départ de trois trajectoires parallèles que sont la
technologie, les données et les interfaces utilisateurs.

39
 Cycle de vie décisionnel
Modèle dimensionnel

● C'est la définition des besoins qui détermine quelles sont les données
requises pour répondre aux besoins d'analyse des utilisateurs.

● Le résultat de cette analyse est le modèle dimensionnel.

● Le modèle identifie :
– La table de fait avec ses mesures et sa granularité
– Les dimensions associées avec attributs et hiérarchisation.

● Cet ensemble d'activités s'achèvera sur le développement d'une mise

en correspondance des données sources et cibles dans des
méta-données.

40
 Cycle de vie décisionnel
Structure physique

● Définition des structures physiques nécessaires pour

l'implémentation physique du modèle dimensionnel.
– Détermination des règles de nommage des objets
– Environnement de la base de données.
– Indexation primaire

● La conception du modèle physique est fortement

dépendante du système utilisé pour l'entrepôt.

41
 Cycle de vie décisionnel
Préparation des données

● La conception de la zone de préparation des

données (staging area) constitue
généralement la tache la plus sous-estimée
du projet entrepôt de données.
● Le processus de préparation se déroule en
trois phases majeures :
– Extraction
– Transformation
– Chargement

42
 Cycle de vie décisionnel
Architecture technique
● La définition de l'architecture technique globale à
mettre en œuvre nécessite la prise en compte :
– des besoins
– de l'environnement existant
– des orientations techniques stratégiques planifiées

● En plus de l'architecture supportant l'entrepôt, il est

nécessaire de mener des réflexions sur les outils de
conception de la zone de préparation des données et
des outils de restitution

43
 Cycle de vie décisionnel
Composants
● A partir de l'étude de l'architecture technique il faut
sélectionner les composants spécifiques
– Plate-forme(s) matérielle(s) et logicielle(s)
– SGBD
– Outils d'extraction
– Outils de restitution

● Une fois les produits évalués et sélectionnés, ceux-ci

doivent être installés et testés méticuleusement afin de
garantir une intégration adéquate d'un bout à l'autre de
l'environnement de l'entrepôt.

44
 Cycle de vie décisionnel
Applications utilisateurs

● Définition d’une série d'applications standard destinés

aux utilisateurs finaux.
– Tous les utilisateurs n'ont pas besoin d'un accès ad hoc à
l'entrepôt.

● Les spécifications de l'application décrivent les

maquettes d'états, les critères de sélection laissés à
l'utilisateur et les calculs nécessaires.

45
 Cycle de vie décisionnel
Déploiement

● Le déploiement est le point de convergence de :

– La technologie
– Des données
– Des applications utilisateurs.

● Une planification est indispensable pour gérer le

déploiement qui comprend également
– la formation des utilisateurs,
– le support utilisateur,
– la prise en compte des demandes d'évolution et de
correction.

46
 Cycle de vie décisionnel
Le projet

● Garantir la qualité des données de production

● Garantir la qualité du DW
● Agrégation, relations entre les sources
● Garantir les temps de réponses
● Permettre de retrouver les informations non-agrégées
● Lien entre les différents niveaux d’agrégation et
pertinence des algorithmes

47
Modélisation d’un DW
• Modèle en étoile (Star Schema)

• Modèle en flocon (Snowflake Schema)

• Modèle mixte (Mixed Schema)

48
 Modélisation
multidimensionnelle
● Exemples :
– Grandes distribution :
● CA annuel : 80 000 M$

● Prix moyen d’un article d’un ticket : 5$

● Nbre d’articles vendus pour un an : 80 * 109 / 5 = 16 * 109

● Volume du DW :

– 16*109 *3 ans * 24 octets = 1,54 To (1,54*1012 = 1 540 Go )

– Téléphonie :
● Nbre d’appels quotidiens : 100 millions
● Historique : 3 ans * 365 jours= 1 095 jours
● Volume du DW :
– 100 millions * 1 095 jours * 24 octets = 3,94 To
– Cartes de crédit :
● Nbre de clients : 50 millions
● Nbre moyen mensuel de transactions : 30
● Volume :
– 50 millions * 26 mois * 30 transactions * 24 octets = 1,73 To

49
 Modélisation
Entité/Association
● Avantages:
– Normalisation:
● Éliminer les redondances

● Préserver la cohérence des données

– Optimisation des transactions

– Réduction de l’espace de stockage
● Inconvénients pour un utilisateur final:
– Schéma très/trop complet:
● Contient des tables/champs inutiles pour l’analyse

– Pas d’interface graphique capable de rendre

utilisable le modèle E/A
– Inadapté pour l’analyse
50
 Exemple d’un schéma E/A
Mode
Transporteur
d’expédition

Produit
Contrat Commande
client
Type de Groupe de
contrat Client produits
Magasin

Famille de
Employé Région de produits
Stock ventes

Fonction Division de
Fournisseurs
ventes
51
 Modélisation des DW
● Nouvelle méthode de conception autour des
concepts métiers
– Ne pas normaliser au maximum
● Introduction de nouveaux types de table:
– Table de faits
– Table de dimensions
● Introduction de nouveaux modèles:
– Modèle en étoile
– Modèle en flocon

52
 Les types de modèles

Modèle en étoile Modèle en flocon

53
 Modèle en étoile
● Le schéma en étoile tire son nom de sa configuration
● Une table de fait centrale et des dimensions
● Les dimensions n’ont pas de liaison entre elles
● Avantages:
– Facilité de navigation
– Nombre de jointures limité
● Inconvénients:
– Redondance dans les dimensions
– Toutes les dimensions ne concernent pas les mesures
– Alimentation complexe.
54
 Modèle en étoile
Dimension Temps
ID temps
année
mois
jour Dimension produit
… ID produit
Dimension Magasin
ID magasin nom
description code
Table de faits Achat prix
ville
ID client poids
surface
ID temps groupe
…
ID magasin famille
ID région …
ID produit
Quantité achetée Dimension Client
Dimension Region
Montant des achats ID client
ID région
pays nom
description prénom
district vente adresse
…. …

55
 Modèle en flocon
● Une table de fait et des dimensions décomposées en sous
hiérarchies
● On a un seul niveau hiérarchique dans une table de dimension
● La table de dimension de niveau hiérarchique le plus bas est
reliée à la table de fait. On dit qu’elle a la granularité la plus fine
● Modèle floconné = Modèle en étoile + normalisation
des dimension

● Avantages:
– Normalisation des dimensions
– Économie d’espace disque
● Inconvénients:
– Modèle plus complexe (jointure)
– Requêtes moins performantes

56
 Modèle en flocon
Dimension produit
ID produit
Dimension Temps ID groupe
ID temps nom
annee code
mois prix
Dimension Magasin jour poids Dimension groupe
ID magasin … … ID groupe
description ID famille
ville Table de faits Achat
nom
surface ID client
…
… ID temps
ID magasin
Dimension Region ID région
ID région Dimension Famille
ID produit
ID division vente ID famille
Quantité achetée
pays nom
Montant des achats
description …
….
Dimension Client
Dimension
ID client
Division vente
nom
ID division vente
prénom
description
adresse 57
….
… 57
Modèle en flocon

58
 Modèle mixte

▪ Il s’agit d’une structure qui résulte de la

meilleure combinaison des deux types de
modèles précédents
– Seules quelques dimensions seront normalisées,
souvent il s’agit des plus grandes tables et celles
contenant le plus de redondance

59
Modèle mixte

60
 Table de faits
● Table principale du modèle dimensionnel
● Contient les données observables (les faits) sur le sujet étudié
selon divers axes d’analyse (les dimensions)

Table de faits des ventes

Clés étrangères Clé date (CE)
vers les Clé produit (CE)
dimensions Clé magasin (CE)
Quantité vendue
Faits Coût
Montant des ventes

61
 Table de faits (suite)
● Fait:
– Ce que l’on souhaite mesurer
● Quantités vendues, montant des ventes…

– Contient les clés étrangères des axes d’analyse

(dimension)
● Date, produit, magasin, …
– Trois types de faits:
● Additif

● Semi additif

● Non additif

62
 Typologie des faits
● Additif: additionnable suivant toutes les dimensions
– Quantités vendues, chiffre d’affaire
– Peut être le résultat d’un calcul:
● Bénéfice = montant vente - coût
● Semi additif: additionnable suivant certaines dimensions
– Solde d’un compte bancaire:
●Pas de sens d’additionner sur les dates car cela représente
des instantanés d’un niveau
● Σ sur les comptes: on connaît ce que nous possédons en
banque
● Non additif: fait non additionnable quelque soit la dimension
– Prix unitaire: l’addition sur n’importe quelle dimension donne un
nombre dépourvu de sens

63
 Granularité de la table de faits
● Répondre à la question :
– Que représente un enregistrement de la table de faits?
● La granularité définit le niveau de détails de la
table de faits:
– Exemple: une ligne de commande par produit, par
client et par jour

Précision des
analyses
- + Finesse
Taille de
l’entrepôt
64
 Table de dimension
● Axe d’analyse selon lequel vont être étudiées les données
observables (faits)
● Contient le détail sur les faits

Dimension produit
Clé de substitution Clé produit (CP)
Code produit
Description du produit
Attributs de la Famille du produits
dimension Marque
Emballage
Poids
65
 Table de dimension (suite)
● Dimension = axe d’analyse
– Client, produit, période de temps…
● Contient souvent un grand nombre de colonnes
– L’ensemble des informations descriptives des faits
● Contient en général beaucoup moins
d’enregistrements qu’une table de faits

66
 La dimension Temps
● Commune à l’ensemble du Dimension Temps
DW Clé temps (CP)
● Reliée à toute table de faits Jour
Mois
Trimestre
Semestre
Année
Num_jour_dans_année
Num_semaine_ds_année

67
 Granularité d’une dimension
● Une dimension contient des membres organisés
en hiérarchie :
– Chacun des membres appartient à un niveau hiérarchique
(ou niveau de granularité) particulier
– Granularité d’une dimension : nombre de niveaux
hiérarchiques
– Temps :
● année – semestre – trimestre - mois

68
 Évolution des dimensions
● Dimensions à évolution lente
● Dimensions à évolution rapide

69
 Évolution des dimensions
● Dimensions à évolution lente
– Un client peut se marier, avoir des enfants…
– Un produit peut changer de noms ou de formulation:
● « Raider » en « Twix »

● « yaourt à la vanille » en « yaourt saveur vanille »

– Gestion de la situation, 3 solutions:

● Écrasement de l’ancienne valeur

● Versionnement

● Valeur d’origine / valeur courante

70
 Dimensions à évolution lente (1/3)
● Écrasement de l’ancienne valeur :
– Correction des informations erronées
● Avantage:
– Facile à mettre en œuvre
● Inconvénients:
– Perte de la trace des valeurs antérieures des attributs
– Perte de la cause de l’évolution dans les faits mesurés

Clé produit Description du produit Groupe de produits

12345 Intelli-Kids Logiciel
Jeux éducatifs

71
 Dimensions à évolution lente (2/3)
● Ajout d’un nouvel enregistrement:
– Utilisation d’une clé de substitution
● Avantages:
– Permet de suivre l’évolution des attributs
– Permet de segmenter la table de faits en fonction de l’historique
● Inconvénient:
– Accroit le volume de la table

Clé produit Description du produit Groupe de produits

12345 Intelli-Kids Logiciel
25963 Intelli-Kids Jeux éducatifs
72
 Dimensions à évolution lente (3/3)
● Ajout d’un nouvel attribut:
– Valeur origine/valeur courante
● Avantages:
– Avoir deux visions simultanées des données :
● Voir les données récentes avec l’ancien attribut
● Voir les données anciennes avec le nouvel attribut
– Voir les données comme si le changement n’avait pas eu lieu
● Inconvénient:
– Inadapté pour suivre plusieurs valeurs d’attributs intermédiaires

Clé produit Description du Groupe de Nouveau groupe

produit produits de produits
12345 Intelli-Kids Logiciel Jeux éducatifs
73
 Évolution des dimensions
● Dimensions à évolution lente
● Dimensions à évolution rapide
– Subit des changements très fréquents (tous les mois)
dont on veut préserver l’historique
– Solution: isoler les attributs qui changent rapidement

74
 Dimensions à évolution rapide
● Changements fréquents des attributs dont on veut garder
l’historique
– Clients pour une compagnie d’assurance
● Isoler les attributs qui évoluent vite

75
 Dimensions à évolution rapide
(suite)
Dim client

Faits Clé_client
Dim client
Nom Faits
Clé_client Clé_client
… Prénom Clé_client
Nom
Adresse Clé_démog
Prénom
Date_naissance
Adresse
…
Date_nais
… Dim_démographique
Revenus Clé_démog
Niveau_étude Revenus
Nb_enfants Niveau_étude
Statut_marital Nb_enfants
Profil_financier Statut_marital
Profil_achat Profil_financier
Profil_achat 76
 Schéma en étoile vs schéma en flocon
La technologie Certaines technologies telle que MicroStrategy requièrent un schéma en flocons de neige
alors que d’autres comme Cognos requièrent le schéma en étoile

La nature des requêtes Certaines requêtes se prêtent mieux à la structure dimension-fait. Pas forcément toutes
les requêtes mais quand c’est le cas un schéma en étoile est le meilleur choix

Besoins d’affaires spécifiques Ils existent des besoins d’affaires qui ne peuvent tout simplement pas être structurés en
schéma en étoile. La relation entre l’entité « client » et l’entité « compte » dans le
domaine bancaire, celle entre l’entité « client » et l’entité « police d’assurance »
dans le domaine des assurances ne peuvent être représentées par un schéma en
étoile à cause de la relation n à m qui lie ces entités.

Besoin de flexibilité Le schéma en flocons de neige devrait être utilisé lorsque l’on a besoin d’une plus
grande flexibilité dans la corrélation à travers les niveaux et les composantes d’une
dimension. L'avantage principal d'un flocon de neige est la plus grande flexibilité
dans les données

Ratio Attributs Maître : Lorsque le ratio entre deux niveaux de hiérarchie d’une dimension est élevé, il est
Nombre de rangées préférable d’utiliser un modèle en flocon ce qui permettra de diminuer la volumétrie
Détail stocker (au delà d’un rapport 1:5 par exemple)

Gestion complexe de Quand il s’agit de cas complexe de gestion de l’évolution de dimension, un schéma en
dimension flocons de neige est préférable. Les cas complexes peuvent être la gestion de
l’historisation des liens, la gestion de l’historisation des attributs…

Difficulté de navigation dans Le constat que le schéma en étoile est plus compréhensible que le schéma en flocons de
les hiérarchies neige est complètement subjectif. En particulier quand la dimension est composée
de plusieurs colonnes.
77
 Méthodologie: 9 étapes de
1. Choisir le sujet
Kimball
2. Choisir la granularité des faits
3. Identifier et adapter les dimensions
4. Choisir les faits
5. Stocker les pré-calculs
6. Établir les tables de dimensions
7. Choisir la durée de la base
8. Suivre les dimensions lentement évolutives
9. Décider des requêtes prioritaires, des modes de requêtes

78
 Alimentation/ mise à jour de
l’entrepôt
● Entrepôt mis à jour régulièrement
● Besoin d’un outil permettant d’automatiser les chargements dans
l’entrepôt

Utilisation d’outils ETL (Extract, Transform, Load)

79
 Définition d’un ETL
● Offre un environnement de développement
● Offre des outils de gestion des opérations et de maintenance
● Permet de découvrir, analyser et extraire les données à partir
de sources hétérogènes
● Permet de nettoyer et standardiser les données
● Permet de charger les données dans un entrepôt

80
 ETL
● Pour alimenter le DataWareHouse, on utilise un ETL
( Extract, Transform and Load ), outil basé sur le
principe de métabases.
● Décrit les données, leur provenance et les
transformations effectuées.
● Permet d’agréger, de classifier, de normaliser, de
qualifier, de nettoyer et de consolider les données
extraites.
81
 ETL
● Les concepteurs doivent mettre en place une
stratégie de mise à jour pour l’historisation et
prévoir la volumétrie.
● L’alimentation peut être en batch ou file de l’eau.
Les ETL peuvent être intégrés aux outils de
modélisations ou de restitution.

82
 ETL
● Les ETL peuvent se concevoir de 2 manières :
– manuellement : en lançant des scripts ( PL/SQL, …)
– avec des logiciels ( qui sont chers : ~10k€ )
● Le chargement des données correspond à 60-70 %
du projet : analyser décrire expliquer exposer
● Identifier les sources
● Où ? Mainframe, fichiers, SGBDR, ERP, Internet, …
● Comment ? Réseau local, WAN, transferts des fichiers.
● Quand ? Cohérence, normalisation

83
 ETL
● Construire le référentiel
● Définir la fréquence des chargements
● Décrire le niveau d’historisation
● Expliquer la volumétrie
● Analyser la qualité des données
● Exposer la complexité des transformations
● Considérer la reprise des données
● Gérer les rejets
● Mettre en place les sauvegardes/restaurations
84
 ETL: Problèmes rencontrés

● Souvent peu d’entreprises ont des logiciels qui

permettent la création d’ETL, car ce sont des outils
coûteux. Il faut souvent réaliser l’alimentation à la
main.
● La fréquence de mise à jour du DataWareHouse (
quotidiennement, hebdomadairement,
mensuellement, …) peut influencer sa structure. De
plus, une volumétrie des flux trop importante peut
entraîner un problème d’exploitation.
85
 ETL: Problèmes rencontrés

● Penser à la volumétrie des sources de données et à la

fréquence de mise à jour.
● Faire attention aux environnements trop mouvants,
c’est à dire aux mises à jour trop fréquentes .
● Synchroniser l’alimentation des différents Data Mart
qui composent son outil décisionnel sinon on peut
obtenir des rapports dans la phase de
RESTITUTION faussés.
● S’assurer que les différentes méta bases soient
cohérentes.
86
 Extraction
● Extraire des données des systèmes de production
● Dialoguer avec différentes sources:
– Base de données,
– Fichiers,
– Bases propriétaires
● Utilise divers connecteurs :
– ODBC,
– SQL natif,
– Fichiers plats

87
 Transformation
● Rendre cohérentes les données des différentes sources
– Transformer, nettoyer, trier, unifier les données
– Exemple: unifier le format des dates
(MM/JJ/AA 🢥JJ/MM/AA)
● Etape très importante, garantit la cohérence et la fiabilité des
données

88
 Chargement
● Insérer ou modifier les données dans l’entrepôt
● Utilisation de connecteurs:
– ODBC,
– SQL natif,
– Fichiers plats

89
Aperçu d’un ETL

90
III. Les Bases
Multidimensionnelles

91
 1. OLAP
« Il s’agit d’une catégorie de logiciels axés sur
l’exploration et l’analyse rapide des données
selon une approche multidimensionnelle à
plusieurs niveaux d’agrégation » (Caron, 1998)

92
 1. OLAP
● Catégorie de logiciels :
– S’exprime par une grande quantité de produits
logiciels disponibles sur le marché
● Exploration et analyse rapide :
– OLAP vise à assister l’usager dans son analyse
en lui facilitant l’exploration de ses données et
en lui donnant la possibilité de le faire
rapidement
Rapidité et facilité

93
 1. OLAP
● Facilité
– L’usager n’a pas à maîtriser des langages
d’interrogation et des interfaces complexes
– L’usager interroge directement les données, en
interagissant avec celles-ci
● Rapidité
– OLAP exploite une dénormalisation maximale des
données, sous la forme d’une pré-agrégation stockée
– L’usager devient opérationnel en très peu de
temps
L’usager peut se concentrer sur son analyse
et non sur le processus (les moyens utilisés
pour l’analyse)
94
 1. OLAP
● Approche multidimensionnelle :
– Basée sur des thèmes d’analyse (dimensions)
– Plus intuitive
● Plusieurs niveaux d’agrégation :
– Les données peuvent être groupées à différents niveaux
de granularité (les regroupements sont pré-calculés, par
exemple, le total des ventes pour le mois dernier calculé
à partir de la somme de toutes les ventes du mois).
– Granularité : niveau de détail des données
emmagasinées dans une base de données.

95
 1. Vocabulaire OLAP
Dimension :
● Une dimension peut être définie comme un thème, ou un axe
(attributs), selon lequel les données seront analysées (en
fonction de …)
– Ex. Temps, Découpage administratif, Produits

● Une dimension contient des membres organisés en hiérarchie,

chacun des membres appartenant à un niveau hiérarchique (ou
niveau de granularité) particulier
– Ex. Pour la dimension Temps, les années, les mois et les jours peuvent être
des exemples de niveaux hiérarchiques. 1998 est un exemple de membre
du niveau Année

96
 1. Vocabulaire OLAP
Mesure :
● Une mesure est un élément de donnée sur lequel
portent les analyses, en fonction des différentes
dimensions
– Ex. coût des travaux, nombre d’accidents, ventes,
dépenses

97
 1. Vocabulaire OLAP
Fait :
● Un fait représente la valeur d’une mesure, mesurée
ou calculée, selon un membre de chacune des
dimensions (ex. ce qui est recueilli par les
systèmes transactionnels).

– Ex. « le coût des travaux en 1995 pour la région casa

est 250 000 Dh » est un fait qui exprime la valeur de la
mesure « coût des travaux » pour le membre « 1995 »
du niveau « année » de la dimension « temps » et le
membre « Casa » du niveau « région » de la dimension
« découpage administratif ».
98
 1. Vocabulaire OLAP
Cube :
● Un ensemble de mesures organisées selon un
ensemble de dimensions (aussi hypercube)
– Ex. Un cube de ventes qui comprend :
● Les dimensions Temps, Produit, Magasin
● La mesure Ventes en Dh

99
 1. Cube multidimensionnel
Ce cube multidimensionnel présente les profits
d’entreprises agricoles par propriété, par exploitation et
par année.
Cas 1: visualisation des
profits des propriétés > =
0.05 km2 pour toutes les
exploitations durant les 4
années.

Cas 2: visualisation des

profits des propriétés >=
1.5 km2 pour l’exploitation
de légumes pour l’année
1993.
100
 1. Composantes OLAP
● L’architecture OLAP consiste en trois services :
Base de données :
– Doit supporter les données agrégées ou résumées
– Peut provenir d’un entrepôt ou d’un marché de données*
– Doit posséder une structure multidimensionnelle (SGDB
multidimensionnel ou relationnel)
Serveur OLAP :
– Gère la structure multidimensionnelle dans le SGBD
– Gère l’accès aux données de la part des usagers
Module client :
– Permet aux usagers de manipuler et d’explorer les données
– Affiche les données sous forme de graphiques statistiques et de tableaux
● Selon le type de base de données accédé, plusieurs configurations sont
possibles : multidimensionnelle, relationnelle ou hybride

101
 2. MOLAP
(OLAP Multidimensionnel)
▪ Les données détaillées de base ainsi que les données
agrégées de l’entrepôt sont stockées dans une base de
données multidimensionnelle (souvent appelée cube ou
hypercube)
▪ Une base de données multidimensionnelle utilise une
structure propriétaire au logiciel utilisé (≈ matrice)
▪ Le serveur MOLAP extrait les données de l’hypercube et
les présente directement au module client

102
 2. MOLAP
(OLAP Multidimensionnel)

103
3. ROLAP (OLAP Relationnel)
▪ Les données détaillées de base ainsi que les données
agrégées de l’entrepôt sont stockées sous forme de tables
dans une base de données relationnelle
▪ La base de données relationnelle doit être structurée selon
un modèle particulier (étoile, flocon, …)
▪ Le serveur extrait les données par des requêtes SQL et
interprète les données selon une vue multidimensionnelle
avant de les présenter au module client

104
3. ROLAP (OLAP Relationnel)

105
 4. HOLAP (OLAP Hybride)
▪ Architecture qui consiste en un croisement des
architectures MOLAP et ROLAP
▪ Les données détaillées de base de l’entrepôt sont
stockées dans une base de données relationnelle et
les données agrégées sont stockées dans une base
de données multidimensionnelle
▪ Le serveur HOLAP accède deux bases de données
et les présente au module client, selon une vue
multidimensionnelle dans le cas des données de la
BD relationnelle

106
4. HOLAP (OLAP Hybride)

107
5. MOLAP vs ROLAP vs HOLAP

Critère de ROLAP MOLAP HOLAP

comparaison

Stockage des BD BD BD
données de base relationnelle multidimension relationnelle
(détaillées) nelle

Stockage des BD BD BD
agrégations relationnelle multidimension multidimension
nelle nelle

Performance des Le moins Le plus Performance

requêtes performant performant moyenne
(habituellement)

108
 5. Structure
multidimensionnelle
Pour une configuration ROLAP ou HOLAP, il est
nécessaire de simuler une structure
multidimensionnelle dans un SGBD relationnel à
l’aide de modèles particuliers qui permettent de mieux
répondre aux besoins multidimensionnels :
– Modèle en étoile (Star Schema)
– Modèle en flocon (Snowflake Schema)
– Modèle mixte (Mixed Schema)
– Modèle en constellation (Fact Constellation Schema)

109
 5. Structure
multidimensionnelle
▪ Modèle en étoile
▪ Le schéma en étoile tire son nom de sa configuration:
● Objet central, nommé table des faits

● Connecté à un certain nombre d’objets de manière radiale, les

tables de dimension
– La table des faits, comme son nom l’indique, contient les
faits
– Les tables de dimensions contiennent les attributs définissant
chacun des membres des dimensions. Elles sont
dénormalisées

110
 5. Structure
multidimensionnelle
• Modèle en étoile

DIMENSION 1 DIMENSION 4

FAITS
DIMENSION 2 DIMENSION 5

Mesures

DIMENSION 3 DIMENSION N

111
 5. Structure
multidimensionnelle
• Modèle en étoile

112
 5. Structure
multidimensionnelle
(Modèle en étoile)
● Avantages :
– Facilité de navigation
– Performances : nombre de jointures limité ; gestion des
données creuses.
– Gestion des agrégats
– Fiabilité des résultats
● Inconvénients :
– Toutes les dimensions ne concernent pas les mesures
– Redondances dans les dimensions
– Alimentation complexe.

113
 5. Structure
multidimensionnelle
(Modèle en étoile)
● Quelques exemples de modèles en étoile de DW

– Dans la grande distribution :

● Quelques tables de faits : détaillées et volumineuses
● Tables de dimensions :
– Classiques : produit, fournisseur, temps, établissement (structure
géographique, fonctionnelle), ...
– Stratégiques : Client, Promotions, ....
– Dans le secteur des banques :
● Tables de faits : nombreuses, dédiées à chaque produit , peu détaillées et
peu volumineuses.
● Tables de dimensions :
– Classiques : produit, temps, établissement (structure géographique,
fonctionnelle), ...
– Stratégiques : Client, ....

114
 5. Structure
multidimensionnelle
(Modèle en flocon)
▪ Modèle en flocon
▪ Le schéma en flocon est dérivé du schéma en étoile
où les tables de dimension sont normalisées (la
table des faits reste inchangée)

▪ Avec ce schéma, chacune des dimensions est

décomposée selon sa ou ses hiérarchie(s)
▪ Modèle floconné = Modèle en étoile +
normalisation des dimension

115
 5. Structure
multidimensionnelle
(Modèle
▪ Modèle en flocon
en flocon)

116
 5. Structure
multidimensionnelle
(Modèle en flocon)
● Lorsque les tables sont trop volumineuses
● Avantages :
– réduction du volume,
– permettre des analyses par pallier (drill down)
sur la dimension hiérarchisée.
● Inconvénients :
– navigation difficile ;
– nombreuses jointures.

117
 5. Structure
multidimensionnelle
(Modèle en flocon)
▪ Modèle en flocon

118
 5. Structure
multidimensionnelle
▪ Calculer ou estimer le nombre d’enregistrements
● Prendre en compte :
– La table des faits
– Les dimensions significatives
– Les agrégats
– Les index
– Saisonnalité des ventes
– Croissance du CA, des encours, du nombre de points
de ventes
119
 5. Structure
multidimensionnelle
● Exemples :
– Grandes distribution :
● CA annuel : 80 000 M$

● Prix moyen d’un article d’un ticket : 5$

● Nbre d’articles vendus pour un an : 80 * 109 / 5 = 16 * 109

● Volume du DW :

– 16*109 *3 ans * 24 octets = 1,54 To (1,54*1012 = 1 540 Go )

– Téléphonie :
● Nbre d’appels quotidiens : 100 millions
● Historique : 3 ans * 365 jours= 1 095 jours
● Volume du DW :
– 100 millions * 1 095 jours * 24 octets = 3,94 To
– Cartes de crédit :
● Nbre de clients : 50 millions
● Nbre moyen mensuel de transactions : 30
● Volume :
– 50 millions * 26 mois * 30 transactions * 24 octets = 1,73 To
120
 5. Structure
multidimensionnelle
▪ Modèle mixte
▪ Il s’agit d’une structure qui résulte de la
meilleure combinaison des deux types de
modèles précédents
– Seules quelques dimensions seront normalisées,
souvent il s’agit des plus grandes tables et celles
contenant le plus de redondance

121
 5. Structure
multidimensionnelle
▪ Modèle mixte

122
 5. Structure
multidimensionnelle
OLTP vs OLAP

123
 5. Structure
multidimensionnelle
OLTP vs OLAP

124
 IV. Les Outils

● Un marché fragmenté :
– Constitution du DataWarehouse
– Stockage
– Extraction d’Information
– Outils Métier

125
 Quelques systèmes
● Intelligent miner d’IBM (couplé avec le SGBD DB2)
– Classification, association, régression, analyse de séquences,
regroupement
● Entreprise miner de SAS
– Multiples outils d’analyse statistique, classification, …
● Mine set de Silicon graphics.
– Classification, association et divers outils statistiques. Très
puissant en terme de visualisation
● Clémentine de SPSS
– En plus des fonctionnalités classiques, l’utilisateur peut y
rajouter ses propres algorithmes
● DBMiner de DBMiner technologie.
– Il se distingue par le fait qu’il incorpore les fonctionnalités
d’OLAP
• More at http://www.kdnuggets.com/software 126
 Bibliographie - WWW
● http://www.dw-institute.com/
– The Data Warehouse Institute
● http://pwp.starnetic.com/larryg/
– Infos dont accès à des livres blancs sur le DW
● http://www.promotheus.eds-fr/themes/dw/
– Institut Promotheus, thème DW
● http://www.cait.wustl.edu/cait/papers/prism/
– Société Prisme fondée par W.H. Inmon
● http://www.olapcouncil.org/
– Outils OLAP
● http://www.mediatid.fr/datawarehouse
– forum sur le Data Warehouse
127
 Bibliographie - Livres
● Jean Michel Franco, «Le Data Warehouse / Le Data
Mining», Eyrolles, 1997
● Ralph Kimball, «Entrepôts de Données», Intl Thomson
Pub.,1997, ISBN 2-84180-021-0
● Rob Mattison,» Data Warehousing -Strategies, Technologies
and Technics», IEEE Computer Society 1996, ISBN 0-07-
041034-8
● W. H. Inmon, «Building the Data Warehouse», ed. Wiley,
1996
● W. H. Inmon, «Managing the Data Warehouse», ed.
Wiley,1997
128