2. 2
Plan
1. Modélisation des données décisionnelles
2. Aspects fondamentaux de la modélisation
multidimensionnelle
1. Fait
2. Dimension
3. Mesure
3. Modèles d’un Data Warehouse
4. Conception d’un Data Warehouse
5. Conclusion
3. 3
Limites du modèle E/A pour les SID
Ø Le modèle conceptuel utilisé aujourd’hui couramment pour la
conception des BD des SIO est le modèle entité-association, en 3ème
forme normale.
Ø Le succès du traitement des transactions dans les BDR est
essentiellement dû à l’apport de la modélisation entité/relation.
Ø Les limites de ce modèle sont:
Modèle complexe
De très nombreuses tables afin d’éviter la redondance des
données stockées.
L’exécution de requêtes à vocation décisionnelle requiert alors
l’accès à ces tables via la réalisation de nombreuses jointures.
Risque de dégradation des performances
Pas de compréhension pour l’utilisateur
Données historiques difficilement représentées
Contraire aux objectifs du DW
4. 4
Modélisation des données décisionnelles
Ø Utilisation de concepts pour :
Optimiser la restitution de données selon les axes métiers de
l’entreprise
Gérer et visualiser les données de manière rapide et intuitive
Retrouver et analyser rapidement les données à partir de diverses
sources
Intégrer plusieurs bases de données
Extraire, grouper, organiser et corréler et transformer les données
Ø Modélisations Multidimensionnelle
5. 5
Modélisation multidimensionnelle
Ø Introduite par Ralph Kimball en 1996.
Ø Un modèle multidimensionnel est un modèle de données
dédié à l’analyse d’un processus métier et optimisé pour
cette analyse.
Ø Dans un modèle multidimensionnel, les données sont
représentées en fonction des besoins d’analyse des
utilisateurs.
Ø Dans un tel modèle, les processus métier et les activités
réalisées au sein de ces processus sont décrits en terme de
faits, mesurés par des indicateurs, ainsi qu’en terme de
dimensions.
6. 6
Modélisation multidimensionnelle
Ø Méthode de conception logique qui vise à présenter les
données sous une forme standardisée, intuitive et qui
permet des accès hautement performants
Ø Permet de considérer un sujet analysé comme point dans un
espace à plusieurs dimensions
Ø Les données sont organisées de manière à mettre en
évidence:
Le Sujet à Le Fait
Les perspectives de l’analyse à La table des dimensions
8. 8
Fait
Ø Un fait représente un sujet qu’on souhaite analyser
Ce qui est important pour les affaires de l’entreprise et
devrait être analysé
Ø Un fait est identifié via les valeurs de ses dimensions
Un fait ne peut pas être une cellule vide
Ø Généralement, un fait devrait être
Attaché à exactement une valeur de chaque dimension
9. 9
Fait
Ø Un fait :
Ø modélise le sujet de l'analyse
Ø est formé de mesures correspondant aux informations de l'activité
analysée.
Ø ces mesures sont numériques et généralement valorisées de façon
continue, on peut les additionner, les dénombrer ou bien calculer le
minimum, le maximum ou la moyenne.
Ø Exemple : le fait de « Vente » peut être constitué des mesures
d'activités suivantes :
Ø quantité de produits vendus et
Ø montant total des ventes
10. 10
Fait
uUn 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).
u Ex. « le coût des travaux en 1995 pour la région 02 est 250 000 $ » 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 « 02
» du niveau « région » de la dimension « découpage administratif ».
l Tables des faits : comme son nom l’indique, contient les faits
11. 11
La table de faits
Ø Les mesures sont stockées dans les tables de faits
Ø Table de fait contient les valeurs des mesures et les
clés vers les tables de dimensions
12. 12
Fait - Table des Faits
Fait
u Sujet d’analyse
u Grain de mesure de l’activité
u Résultat d’une opération d’agrégation des données
u Exemple: Chiffre d’affaires, nombre de vente, gain, nombre de
transaction... à en général : une valeur numérique
u Les mesures sont stockées dans la table des faits
Table des faits
u Clé composite référencent des clés primaires des tables de
dimensions
u Contient les valeurs des mesures et des clefs vers les tables
de dimensions à traduit une relation (n,m) entre les
dimensions
u Plusieurs tables de fait dans un DW
u Les faits les plus utiles d’une table des faits sont numériques
et additifs
13. 13
Faits – Tables des Faits
Ø Exemple:
Fait: Montant des ventes, chaque jour pour chaque produit
dans chaque magasin
Ø A en général plusieurs lignes et peu de colonnes
14. 14
Mesure vs attribut
Ø Mesure
Dépendent d'un événement d'affaires (le sujet);
Ont souvent des valeurs continues (ou un grand nombre de valeurs
discrètes possibles);
Servent dans le calcul d’indicateurs de performance;
Ex: montant total et quantité d'une commande.
Ø Attribut
Indépendants des événements d'affaires;
Ont souvent des valeurs discrètes;
Servent à filtrer ou étiqueter les faits;
Ex: jour et heure d'une transaction, âge d'un client, etc.
15. 15
Dimension
Ø Une dimension peut être définie comme :
Un thème, ou un axe (attributs), selon lequel les données seront
analysées
Ex : Temps, Découpage administratif, Produits
Ø Une dimension contient des membres organisés en
hiérarchie :
Chacun des membres appartient à un niveau hiérarchique (ou niveau
de granularité) particulier
Ex : pour la dimension Temps: année – semestre – mois – jour
16. 16
Dimension
Ø Le sujet analysé, le fait, est analysé suivant différentes perspectives
ou axes caractérisant ses mesures de lʼactivité : on parle de
dimensions.
Ø Une dimension :
Ø • modélise un axe d'analyse
Ø • se compose de paramètres correspondant aux informations faisant
varier les mesures de l'activité.
Ø Ex: Dans l'exemple précédent, le fait « Vente » peut être analysé suivant
différentes perspectives correspondant à trois dimensions : la dimension
Temps, la dimension Geographie et la dimension Categorie :
17. 17
Dimension
Ø Les dimensions sont le noyaux des BD multidimensionnelles
Ø Les dimensions sont utilisées pour:
La sélection des données
Groupement des données à un niveau de détail
Ø Les dimensions sont les axes sur lesquels on souhaite baser
l’analyse des données : la date, la région géographique, le
type de produit, etc...
Ø Chaque dimension est composée des « Valeurs de la
dimensions »
Ø Les dimensions fournissent le contexte des faits (qui, quoi,
quand, où, pourquoi et comment)
18. 18
Dimension
u Les dimensions sont composées d’un niveau de hiérarchie
u Typiquement 3-5 niveaux de détails
u Produit: Produit -> Type ->Catégorie
u Magasin: Magasin -> Zone -> Ville -> Pays
u Temps: jour -> Mois -> Trimestre -> Année
u Les valeurs de dimensions sont organisées selon une structure arborescente (hiérarchie)
u Chaque dimension a un niveau bas et un niveau haut
u Hiérarchie
u Décomposition d’une dimension en arborescence de niveaux
u Un niveau peut avoir des attributs
u Simple et non hiérarchique, exemple : Jour – jour ouvrable
u Un attribut
u Caractéristique d’un niveau d’une hiérarchie (ex : prix d’un article)
u Agrégat
u Résultat d’un indicateur par rapport à des niveaux (ex : chiffre d’affaire du
mois)
u Les dimensions doivent comporter des informations complètes
u Exemple : la dimension temps peut contenir : saison, vacances, événement,
etc.
19. 19
Table des Dimensions
Ø Contient une clé primaire unique
qui correspond à l’un des
composants de la clé multiple de
la table des faits
Ø Les tables dimensionnelles sont
les points d’entrée de l’entrepôt
de données
Ø Les dimensions
Thème (ou axe) selon lequel les
données sont analysées
En général sous forme textuelle
Parfois discrète (ensemble limité de
valeurs): couleurs, parfums
Ø A en général plusieurs colonnes
et peu de lignes
20. 20
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
21. 21
Vue
Ø Représentation d’une ou plusieurs requêtes de l’utilisateur du SID
À une requête correspond une et une seule vue
À une vue peuvent correspondre plusieurs requêtes
Ø Une vue correspond également à un hyper-cube dont :
Chaque dimension est décrite par une entité dont le contenu est décrit par
l’association de ces entités
Les propriétés de l’association sont des faits ou mesures
Les propriétés des entités intervenant dans la vue sont des conditions
Ø Les combinaisons des conditions sont les coordonnées qui déterminent
des valeurs de faits, comme une combinaison de valeurs numériques
peut déterminer la position d’un point dans l’espace
Ø Un fait n’est pas seulement un élément du résultat de la requête, mais il
doit être déterminé par l’association des conditions
22. 22
Vue
Ø Exemple 1:
Requête: Quels sont les frais de déplacement et le
kilométrage des commerciaux de la région nord ayant
des véhicules de 10 à 14 CV en avril 2004?
Vue:
Frais de déplacement
Kilométrage
Par Employé (fonction)
Par Véhicule (puissance)
Par Région
Par Mois
23. 23
Vue
Ø Exemple 2:
Requête: Quelles ont été les marges sur les ventes du
produit ‘P023’ pour le client Ben Salah Ahmed à
Hammamet durant le mois de Janvier?
Vue:
Marge
Produit
Client
Région
Mois
24. 24
Vue
Ø Exemple 3:
Requête: Quels ont été les revenus sur les ventes de la
marque ‘Teams’ en Tunisie durant l’année 2011?
Vue:
Revenu
Marque
Pays
Année
25. 25
Vue
Ø Exemple 4:
Requête: Quels ont été les quantités vendues de la gamme
‘G006’ durant le Trimestre 2 pour la région du nord ?
Vue:
Quantité
Gamme
Trimestre
Région
26. 26
Domaine et Contexte
Ø Domaine
Concerne un utilisateur ou un ensemble cohérent d’utilisateurs
Implique un vocabulaire commun et une manière commune
d’appréhender l’information
Ø Contexte
Ensemble de faits et dimensions assemblées selon des critères
sémantiques formels de cohérence
Caractérisé par une association unique, groupant tous les faits relevés
dans les vues
27. 27
Contexte : Activité des Ventes
Ø En opérant une relation superficielle entre les trois vues des exemples 2,
3 et 4, on détecte deux sortes d’éléments de rapprochement
Certaines informations (entités ou faits) se retrouvent dans plusieurs
vues
Certaines entités, appartenant à des vues différentes, sont
fonctionnellement liées les unes aux autres.
On peut intégrer ces vues en un seul contexte comportant une
association porteuse des faits: Marge, Revenu, Quantité, qui
comporte neuf entités distinctes
29. 29
Hiérarchie
Ø Élément fondamental dans la structure d’un contexte
Ø Représente pour l’utilisateur des chemins de consolidation
d’indicateurs (faits)
Ø Chaque niveau est représenté par une entité́
Ø Certaines entités sont rattachées à d’autres par des liens
d’appartenance ou de regroupement hiérarchique
Ø Certains de ces chemins sont connus (Jour, Mois, Année),
d’autres doivent être repérés par une analyse précise du
vocabulaire des utilisateurs (Produit, Gamme, Marque)
31. 31
Granularité
Ø Le « grain » d’une dimension est le niveau de sélection le
plus fin possible de cette dimension
Le grain de la dimension Temps est Mois
Le grain de la dimension Territoire est Région
Ø L’intégration de chaque nouvelle vue est donc susceptible
de modifier le grain sur une ou plusieurs dimensions
Ø Le grain d’un contexte découle de la combinaison des grains
de toutes les dimensions. Il définit le niveau de détail
pouvant être obtenu par la requête la plus sélective et la
plus fine possible mettant en jeu toutes les dimensions.
32. 32
Granularité (Exemple)
Ø Grain du contexte: combinaison Produit-Mois-Client-Région
S’applique à tous les faits
Ø Règle: Tous les faits d’un contexte doivent être définis pour le grain de
ce contexte
Si les 3 indicateurs marge, revenu et quantité sont dans le contexte,
alors ils ont un sens à tous les niveaux.
Exemple: si la marge n’est définie que par Pays et par Mois, alors que
les autres le sont par Région et par Trimestre, il y aurait décalage de
grain entre les faits
Décalage à les faits n’appartiennent pas tous au même contexte à
facteur d’incohérence
34. 34
Modélisation Multidimensionnelle: Caractéristiques
Ø Lisibilité
Ø Performances (chargement + exécution des requêtes)
Ø Évolutivité
Ø Redondances envisageables
Pas de mise à jour en ligne (chargement uniquement)
Pas de problème d’intégrité des données (contrôles à l’acquisition)
Privilégier l’accessibilité plutôt que la normalisation
Ø Requêtes ensemblistes, portant sur de gros volumes de données
Projections, restrictions, regroupements, agrégations
Adaptation du modèle pour des requêtes ad-hoc
Techniques d’optimisation basées sur les chemins d’accès
Ø Pré-calcul de certains agrégats + dé-normalisation
35. 35
Modélisation Multidimensionnelle: Avantages
Ø Structure prévisible et standardisée
Ø Diminution du nombre de tables et de jointures
Ø Modèle évolutif qui peut être modifié sans peine
Ajout de nouveaux faits non prévus initialement, à partir du moment où
ils sont cohérents avec la granularité de la table des faits existante
Ajout de nouvelles dimensions, à partir du moment où une seule valeur
de la dimension est définie pour chaque enregistrement factuel
existant
Ajout d’attributs dimensionnels nouveaux
Changement de granularité: Décomposition des enregistrements d’une
dimension existante en un niveau de détail plus fin à partir d’une date
déterminée
37. 37
Règles d’élaboration et d’Intégration des Vues
Ø La structure des vues externes se déduit directement des requêtes des
utilisateurs, non des connexions possibles entre les entités
Ø Dans un domaine, il existe un ou plusieurs sous-ensembles de vues
liées entre elles par des critères de cohérence sémantique et
structurelles. à Contextes
Ø La liste exhaustive des vues n’est jamais figée
Ø La normalisation du MDD permet d’anticiper et d’intégrer
automatiquement dans chaque contexte le plus grand nombre possible
de vues probables d’après la structure vue connues.
Ø Entre deux entités intervenant dans une vue, il doit exister un et un seul
chemin de navigation sémantique et ce chemin doit être le plus court
possible
38. 38
Démarche de Synthèse des Vues- Contextes
Ø Identifier les faits de l’association
Ø Identifier les liens de dépendance entre les entités
Ø Regrouper les entités dépendantes dans une même
dimension
Ø Nommer les dimensions
Les dimensions pour lesquelles on trouve facilement un nom
sont dites « Dimensions fortes »
Celles pour lesquelles on doute du nom associé sont dites «
Dimensions douteuses »
La structure d’une dimension douteuse peut varier à terme
39. 39
Normalisation des Contextes
Ø Un contexte regroupant un nombre élevé de dimensions a
peu de chances de correspondre à une réalité et serait d’un
maniement trop complexe
En général, le nombre de dimensions d’un contexte varie entre 4 et 12
dimensions
Au delà de ce nombre, la probabilité de redondance dimensionnelle
devient de plus en plus importante
Ø Un contexte est dit cohérent lorsque toutes les vues qu’il
autorise ont une signification dans le domaine de l’utilisateur
40. 40
Règles de Normalisation Dimensionnelle
Ø Règle 1:
Il ne doit pas y avoir de dépendance fonctionnelle entre deux entités
appartenant à des dimensions différentes d’un même contexte
Conséquence: Regroupement des entités dépendantes dans une
même dimension
Ø Exemple: Si les produits sont organisés par région, on doit intégrer
l’entité Région dans la dimension Produit
41. 41
Règles de Normalisation Dimensionnelle
Ø Règle 2:
Tous les faits d’un contexte doivent être définis d’une manière cohérente pour
toutes les combinaisons dimensionnelles de ce contexte
Conséquence: Les faits qui ne sont valables que pour certaines dimensions
nécessitent l’éclatement du contexte
Ø Exemple:
42. 42
Règles de Normalisation Dimensionnelle
Ø Règle 3:
Tous les faits d’un contexte doivent être définis pour le grain
de ce contexte
Le grain d’un contexte découle de la combinaison des grains de
toutes les dimensions
Le grain d’une dimension est le niveau de sélection le plus fin
possible de cette dimension
Ø Règle 4:
Le graphe de chaque dimension doit être acyclique
Conséquence: Il faut rompre les cycles
43. 43
Forme Dimensionnelle Normale
Ø Le MDD correspond à un domaine qui se présente sous
forme d’une constellation ou galaxie dans laquelle chaque
étoile correspond à un contexte
Ø Une même entité ou un même fait peut appartenir à plus
d’un contexte, à condition de conserver une définition unique
Ø Pour ces raisons pratiques, il est préférable de représenter
les contextes sous une forme déconnectée
46. 46
Modèle d’un Data Warehouse
Ø Modèle en étoile
Ø Modèle en flocon de neige
Ø Modèle en constellation
47. 47
Modèle en étoile
§ Une (ou plusieurs) table(s) de faits comprenant une ou
plusieurs mesures
§ Plusieurs tables de dimension dé-normalisées: descripteurs
des dimensions.
§ Les tables de dimension n'ont pas de lien entre elles.
§ Avantages
ü Facilité de navigation.
ü Performances : nombre de jointures limité; gestion des
données creuses.
ü Gestion des agrégats
§ Inconvénients
ü Redondances dans les dimensions.
ü Alimentation complexe..
54. 54
Modèle en Flocon de Neige
u Dérivé du schéma en étoile où les tables de dimensions sont
normalisées
u La table des faits reste inchangée
u Chacune des dimensions est décomposée selon sa (ou ses)
hiérarchie(s)
u Exemple: Commune, Département, Région, Pays, Continent
u Utilisé lorsque les tables sont très volumineuses
u Avantages
u Réduction du volume
u Permettre des analyses par pallier (drill down) sur la dimension hiérarchisée
u Inconvénients
u Navigation difficile
u Nombreuses jointures
55. 55
Modèle en Flocon de Neige
Ø Le schéma en flocon est dérivé du schéma en étoile où les
tables de dimensions 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).
Ø Exemple : Commune, Département, Région, Pays,
Continent
58. 58
Modèle en Flocon de Neige
Ø Modèle en étoile + normalisation des dimensions
Ø Lorsque les tables sont trop volumineuses
Ø Avantages :
Réduction du volume,
Ø Inconvénients :
Navigation difficile,
Nombreuses jointures.
60. 60
Modèle en Constellation
Ø Fusionner plusieurs modèles en étoile qui utilisent des
dimensions communes
Ø Un modèle en constellation comprend donc :
Plusieurs tables de faits
Des tables de dimensions communes ou non à ces tables de
faits
61. 61
Le modèle en constellation
Ø La modélisation en constellation consiste à fusionner
plusieurs modèles en étoile qui utilisent des
dimensions communes.
Ø Un modèle en constellation comprend donc plusieurs
tables de faits et des tables de dimensions
communes ou non à ces tables de faits.
63. 63
Synthèse
Ø Modèle en étoile
Taille de dimension plus grosse
Ø Modèle en flocon de neige
Jointures pour reconstruire
Ø Modèle en étoile >> Modèle en flocon
car tables de dimension << tables de fait
