Bd decionnel

1. Bases de données Décisionnelles
Hicham BEHJA

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

3. 3
I. DATA WARHOUSES

4. 4
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?
 ...

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

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

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

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

9. 9
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):
- Modèle de données avancé (extended-relational,
OO, deductive, etc.),
- application-oriented SGBD (GIS, scientific,
engineering, etc.).
Data warehousing & data
mining (1990’s - présent):
Nouvelle génération des SI (2000 - ...)

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

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

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

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

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

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

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

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

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

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

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

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

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

23. 23
4. L’Entrepôt de Données
 Les différentes phases du Data warehousing
– Conception
– Construction
– Administration

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

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

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

27. 27
Données opérationnelles Données décisionnelles
Orientées application, détaillées, précises au
moment de l’accès
Orientée activité (thème, sujet), condensées,
représentes des données historiques
Mise à jour interactive possible de la part des
utilisateurs
Pas de mise à jour interactive de la part des
utilisateurs
Accédées de façon unitaires par une personne à la
fois
Utilisées par l’ensemble des analystes, gérées
par 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
traitement
Grande quantité de données utilisée par les
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
Différences entre données du système de production et données décisionnelles

28. 28
4. La Suite Décisionnelle
Source de données :
diverses bases de
données
« opérationnelles »
Métabase :
Description des données
E.T.L. :
Extract Transform and
Load
DATAWAREHOUSE :
Entrepôt de données
« Décisionnelles »
Base de données Agrégées
Base
tampon
Base
filtrée
Modèle
« Hypecube »
KDD
PILOTAGE

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

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

31. 31
4. La Suite Décisionnelle
Source de données :
diverses bases de
données
« opérationnelles »
Métabase :
Description des données
E.T.L. :
Extract Transform and
Load
DATAWAREHOUSE :
Entrepôt de données
« Décisionnelles »
Base de données Agrégées
Base
tampon
Base
filtrée
Modèle
« Hypecube »
KDD
PILOTAGE

32. 32
Les composants de base du
DW
Stockage
Fichiers plats,
SGBDr,
autres
TRAITEMENTS
Nettoyage
Transformation
Datamart 1
Dimensionnel
Orienté sujet
Dédié à un
groupe
d’utilisateur
Outil de
requetage
ad-hoc
Générateurs
d’état
Extraire
Datamart 2
Application
data mining
Zone de préparation des
données
Serveur de présentation de DW Portail de
restitution
Alimenter
Alimenter
Système
source

33. 33
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
Ressources Humaines
DW de l’entreprise

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

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

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

37. 37
Cycle de vie décisionnel

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

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

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

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

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

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

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

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

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

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

48. 48
Modélisation d’un DW
• Modèle en étoile (Star Schema)
• Modèle en flocon (Snowflake Schema)
• Modèle mixte (Mixed Schema)

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

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

51. 51
Exemple d’un schéma E/A
Mode
d’expédition
Transporteur
Produit
Groupe de
produits
Famille de
produits
Division de
ventes
Région de
ventes
Magasin
Commande
client
Type de
contrat
Contrat
Client
Employé
Fonction
Stock
Fournisseurs

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

53. 53
Les types de modèles
Modèle en étoile Modèle en flocon

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

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

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

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

58. 58
Modèle en flocon

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

60. 60
Modèle mixte

61. 61
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é date (CE)
Clé produit (CE)
Clé magasin (CE)
Quantité vendue
Coût
Montant des ventes
Clés étrangères
vers les
dimensions
Faits

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

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

64. 64
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
Taille de
l’entrepôt
- + Finesse

65. 65
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é produit (CP)
Code produit
Description du produit
Famille du produits
Marque
Emballage
Poids
Clé de substitution
Attributs de la
dimension

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

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

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

69. 69
Évolution des dimensions
 Dimensions à évolution lente
 Dimensions à évolution rapide

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

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

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

73. 73
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
produit
Groupe de
produits
12345 Intelli-Kids Logiciel
Nouveau groupe
de produits
Jeux éducatifs

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

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

76. 76
Dimensions à évolution rapide
(suite)
Dim_démographique
Clé_démog
Revenus
Niveau_étude
Nb_enfants
Statut_marital
Profil_financier
Profil_achat
Dim client
Clé_client
Nom
Prénom
Adresse
Date_nais
…
Revenus
Niveau_étude
Nb_enfants
Statut_marital
Profil_financier
Profil_achat
Dim client
Clé_client
Nom
Prénom
Adresse
Date_naissance
…
Faits
Clé_client
…
Faits
Clé_client
Clé_démog

77. 77
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 :
Nombre de rangées
Détail
Lorsque le ratio entre deux niveaux de hiérarchie d’une dimension est élevé, il est
préférable d’utiliser un modèle en flocon ce qui permettra de diminuer la volumétrie
stocker (au delà d’un rapport 1:5 par exemple)
Gestion complexe de
dimension
Quand il s’agit de cas complexe de gestion de l’évolution de dimension, un schéma en
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
les hiérarchies
Le constat que le schéma en étoile est plus compréhensible que le schéma en flocons
de neige est complètement subjectif. En particulier quand la dimension est
composée de plusieurs colonnes.

78. 78
Méthodologie: 9 étapes de
Kimball
1. Choisir le sujet
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

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

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

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

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

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

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

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

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

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

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

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

90. 90
Aperçu d’un ETL

91. 91
III. Les Bases
Multidimensionnelles

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

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

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

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

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

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

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

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

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

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

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

103. 103
2. MOLAP
(OLAP Multidimensionnel)
Base de données
multidimensionnelle
(hypercube)
Serveur MOLAP Client OLAP

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

105. 105
3. ROLAP (OLAP Relationnel)
Base de données
relationnelle
(étoile ou flocon)
Serveur ROLAP
Vue
multidimensionnelle
Client OLAP

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

107. 107
4. HOLAP (OLAP Hybride)

108. 108
BD
relationnelle
MOLAP HOLAP
5. MOLAP vs ROLAP vs HOLAP
Critère de
comparaison
ROLAP
Stockage des
données de base
(détaillées)
BD
relationnelle
BD
multidimension
nelle
BD
relationnelle
Stockage des
agrégations
BD
multidimension
nelle
BD
multidimension
nelle
Performance des
requêtes
(habituellement)
Le moins
performant
Le plus
performant
Performance
moyenne

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

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

111. 111
5. Structure
multidimensionnelle
DIMENSION 1
DIMENSION 5
DIMENSION 3
DIMENSION 2
DIMENSION 4
FAITS
Mesures
DIMENSION N
• Modèle en étoile

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

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

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

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

116. 116
5. Structure
multidimensionnelle
(Modèle en flocon)
 Modèle en flocon

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

118. 118
5. Structure
multidimensionnelle
(Modèle en flocon)
 Modèle en flocon

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

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

121. 121
5. Structure
multidimensionnelle
 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
 Modèle mixte

122. 122
5. Structure
multidimensionnelle
 Modèle mixte

123. 123
5. Structure
multidimensionnelle
OLTP
(On-line transaction processing)
OLAP
(On-line analytical processing)
 Priorité à la sécurité et l’intégrité
des données.
 Optimisation du rapport “espace de
stockage vs. quantité de données”
(non-redondance des données).
 BD mise à jour fréquemment
(transactions).
 Priorité à l’analyse et l’exploration
des données
 Optimisation du temps de réponse
aux requêtes (redondance
encouragée s’il y a gain de
performance)
 Gestion de données pré-agrégées,
en mode lecture (mise à jour
contrôlée)
OLTP vs OLAP

124. 124
5. Structure
multidimensionnelle
OLTP
(On-line transaction processing)
OLAP
(On-line analytical processing)
 Outil de requête tributaire de la
structure de données (un usager
doit connaître la structure de la
base de données pour l’interroger
efficacement).
 Requêtes “non-agrégatives” i.e.
visitent peu d’enregistrements,
mais mettent à contribution les
techniques d’indexation pour
retourner un nombre relativement
restreint d’enregistrements
répondant à certains critères.
 Absence d’outil de requête i.e.
l’usager interagit directement avec
les données
 Requêtes principalement du type
“agrégatif” i.e. calculs de totaux,
variance, maxima et minima, etc…
OLTP vs OLAP

125. 125
IV. Les Outils
Un marché fragmenté :
– Constitution du DataWarehouse
– Stockage
– Extraction d’Information
– Outils Métier

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

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

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