Modelisation Dimensionnnelle Diap

University of Applied Sciences of Western Switzerland
School of Business Administration Neuchâtel

Business Data Processing
Haute école de Gestion Arc

Informatique de Gestion
Informatique décisionnelle
Modélisation dimensionnelle
Eddy.Meylan@he-arc.ch
E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 1

Thème : Modélisation dimensionnelle
• Modélisation dimensionnelle
• Faits & Dimensions
• Hiérarchies
• Modèle en flocon
• Assemblage des modèles dimensionnels
• Dimensions à évolutions lentes
• Méthode de conception

Projet global
Gestion
Gestiondu
duprojet
projet
Définition
Définitionde
de Installation
Installationetet
l l’architecture
’architecture sélection
sélection
technique
technique des
desproduits
produits
Définition Conception
Conceptionetet
Définition Modélisation Conception développement
des
des Modélisation Conception développement
Planification de
Planification
du
besoins
besoins
dimensionnelle
dimensionnelle du
dumodèle
modèle delalazone
zone Déploiement
Déploiement
duprojet
projet de physique
physique de préparation
de préparation
de des
l l’entreprise
’entreprise desdonnées
données
Spécification
Spécification Conception
Conception
de
del l’application
’application de
del l’application
’application
utilisateur
utilisateur utilisateur
utilisateur
Maintenance
Maintenance
etet
croissance
croissance

Spécification des besoins en objectif qualité
Spécification
Défaut
qualité
Besoins
Hors sujet
QUALITE
TOTALE
Backlog Double
Qualité
illusion
plus ?
Qualité moins
Réalisation
• La modélisation consiste à transformer les données

sources en structures logiques décisionnelles
finalisées.
• Ce n’est pas le modèle physique !
• La modélisation dimensionnelle diffère de la

modélisation entité/relation.
• C’est la seule technique viable permettant de

fournir des données aux utilisateurs finaux dans le
cadre d’un système décisionnel

Modélisation entité/relation
• La modélisation entité/relation est adaptée aux

système OLTP.
• Elle vise à éliminer les redondances
• Il est bien adapté aux transactions
– Mais est difficilement interrogeable
• Le succès du traitement des transactions au sein

des bases de données relationnelles est
essentiellement dû à l’apport de la modélisation
E/R
Exemple de modèle E/R

Le modèle E/R et les système décisionnels
• Il faut l’éviter dans les systèmes décisionnels !!
• L’utilisateur ne peut ni lire ni intégrer un tel modèle

• Le modèle E/R n’est pas interrogeable par voie
logicielle
• L’adoption d’un modèle E/R pour un système

décisionnel aura des conséquences
catastrophiques au niveau des performances

• On peut définir cinq axe de qualification d ’un

modèle de données dimensionnelle
• Lisibilité pour l ’utilisateur final

• Performance au chargement des données
• Performance à l ’exécution des requêtes
• L ’administration des données
• L ’Evolutivité du modèle
– Certains axes sont antinomiques !!

Lisibilité pour l ’utilisateur final
• L ’utilisateur final (analyste) doit pouvoir facilement

manipuler les données.
• Les données doivent être simple à comprendre,

mais permettre plusieurs analyses différentes selon
des critères différents (dimensions)
• Plus le modèle est lisible (intuitif) pour les

utilisateurs, moins sera long (coûteux) de définir
une sur couche pour le rendre compréhensible
Performance au chargement des données
• Les entrepôts de données sont constitués de

grosses quantités de données.
• Les données sont souvent de sources hétérogènes
• Il est assez simple de charger dans une structure

simple. Le chargement nécessite souvent une
transformation/filtrage des données sources

Performance à l ’exécution des requêtes
• L ’exécution des requête doit être rapide pour les

analystes
– On estime généralement 30 secondes comme un
maximum
• Il est généralement nécessaire de créer des
agrégations de données et/ou des redondances
– Cette création de redondances et agrégations est
antagoniste avec les performance de chargement.
– Il complique également l ’administration du système

L ’administration des données
• L ’administration du système est fondamentale

• La difficulté n ’est pas tant de construire l ’entrepôts
mais de le faire vivre.
– Tracer les requêtes
– Modification / adaptation des objets
– Maîtrise et industrialisation de l ’extraction des données

L ’Evolutivité du modèle
• Le développement de l ’entrepôt est bien plus

incrémental qu ’itératif.
• Chaque projet ne doit pas déboucher sur un

modèle d ’information isolé des autres

Modèle dimensionnel ou Schéma en étoile
Table
Tabledimension
dimension
temps
temps
Table
Tablede
defait
fait
Numero
Numero PK PK Table
vente
vente Tabledimension
dimension
jour_semaine
jour_semaine Produit
Numero Produit
mois Numero PK PK
mois
temp_num Numero
Numero PK
trimestre temp_num(FK)
(FK) PK
trimestre
produit_num description
annee produit_num(FK)
(FK) description
annee
magasin_num type
magasin_num(FK)
(FK) type
ventes categorie
categorie
ventes
unites_vendues
unites_vendues
Table
Tabledimension
dimension Mesures ou faits
cout
cout
magasin
magasin
Numero
Numero PK
PK
nom
nom
adresse
adresse

Table de faits
• Une table de faits est une table qui contient les

données à analyser.
– Une table de fait est souvent reconnaissable par sa taille.
En effet, lorsqu'on visualise un schéma, c'est celle qui
est au centre et qui est la plus grande.
– Ce type de table est aussi facilement reconnaissable car

elle comporte un grand nombre de clés étrangères afin
de la lier avec des tables de dimensions.

Finesse ou grain de la table de faits
• L'unité de temps la plus petite est appelée le

grain/finesse de la table de faits.
– Dans notre exemple, le grain est journalier.
– Pour connaître celui-ci, il suffit de consulter la table de

dimension Temps et de regarder la plus petite valeur
(jour_de_semaine).

Les faits
• La table de faits peut aussi contenir des champs

qui ne sont pas des clés étrangères. Ce sont les
faits (ou mesures)
– Le faits doivent être valorisés de façon continues et être
additifs.
• Certains faits sont dérivés de faits élémentaires, on

les nomme des faits calculés
– Ils doivent être pris en compte lors de la modélisation
» Ils peuvent être physiquement stockés ou non dans la tables de
faits.
» Ils doivent être identifiés (*)

Faits semi-additifs et non additifs
• Il peut exister des faits semi-additifs et non additifs.
• Les faits semi-additifs peuvent être additionnés

pour certaines dimensions seulement
– Cas se présentant avec une agrégation
• Les faits non additifs ne peuvent être ajoutés.

– Uniquement des comptages ou des impressions

Table de dimensions
• Dans un star schéma, les tables qui entourent la

table de fait sont appelées tables de dimensions.
• Ces tables sont composées d'attributs qui sont

souvent de type caractère et discret.
– Ces attributs servent à stocker la description des
dimensions et sont utilisés comme source de contraintes
et d'en-têtes de lignes dans le jeu de réponses de
l'utilisateur.

Attribut ou fait ?
• Il est important de bien comprendre la différence

entre un attribut et un fait afin de placer ceux-ci
dans les bonnes tables (dimensions || faits). On
peut s ’inspirer des règles simples suivantes.
Attributs Faits
Attribut de type numérique X
Attribut de type caractère X
Valeur discrète X
Variation continue X
Table de faits X
Table de dimensions X
Relation entre schéma relationnel et reporting
Table dimension Table de fait Table dimension

Table dimension Table de fait Table dimension
temps vente Produit
temps vente Produit
Numero PK
Numero PK Numero PK Numero PK
jour_semaine Numero PK Numero PK
jour_semaine temp_num (FK) description
mois temp_num (FK) description
mois produit_num (FK) type
trimestre produit_num (FK) type
trimestre magasin_num (FK) categorie
annee magasin_num (FK) categorie
annee Table dimension
Table dimension ventes
ventes
magasin
magasin unites_vendues
unites_vendues
cout
Numero PK cout
Numero PK
nom Fait calculé
nom
adresse
adresse
Mois Categorie Produit nb prix

Janvier Nettoyage Lessive 25 250.-
Nettoyage Savon 120 240.-
…
Alimentation Beurre 23 25.-
…
La dimension temps
• La dimension temps figure systématiquement dans le

modèle relationnel
– Le DW est une série temporelle
• Conceptuellement nous n ’avons pas besoin d ’une
table de dimension temps, les hiérarchies peuvent
être obtenues avec des fonctions à partir de
date/heure.
• Pour des question de performance il est préférable de
créer une table de dimension
– Avec un grain journalier, 10 ans d ’exploitation -> ~3653 tup.

Dimensions et hiérarchies
• Une dimension est un ensemble de valeur

décomposable.
• Les valeurs d'une dimension sont généralement
organisées à l'intérieur d'une hiérarchie
– Ex: jours, mois, semestre, année, …
• L ’accès au niveau supérieur dans une hiérarchie
est appelé "rolling up" et au niveau inférieur
"drilling down"

Exemple de hiérarchies
• Dimension de production
– Catégories,
– Département, etc.
• Dimension géographique,
– villes
– canton,
– pays, etc
• Dimension temporelle
– années
– trimestre
– mois, etc.

Hiérarchie simple ou multiple
• Simple Multiple
Pays Année
Forage vers
le haut
(Rolling Up)
Canton
Trimestre Saison Semaine
Ville Mois
Forage vers
le bas
(Drilling Down) Date
Quartier

Exemple pour un suivi des ventes
Région
Année Concession
Mois vendeur
Jour Marque
Chiffres
Performance Modèle
journalière
des vendeurs Véhicule

Exemple pour une analyse des ventes
Région
Année Concession
Mois vendeur
Agrégats
Jour Marque
Ventes mensuelles
des concessions Modèle
par modèle
Véhicule

Exemple pour le pilotage des ventes
Région
Année Concession
Indicateurs
Mois vendeur
Contribution
annuelle Marque
Jour des marques
par région
Modèle
Véhicule

Forage vers le haut ou vers le bas
• A remarquer que le forage se fait dans une

hiérarchie
– Plus restrictif qu’une dimension !
• Si l’outil d’analyse du cube ne supporte pas les

hiérarchies multiples, il faudra créer autant de
hiérarchies simples qu’il y a de hiérarchies dans la
hiérarchie multiple

Stockage des hiérarchies
• Une dimension hiérarchisée peut être stockée dans

une table unique.
– Des attributs seront répétés, non respect des formes
normales.
– On a un schéma en étoile
• Une dimension hiérarchisée peut être stockée dans

n tables en relation père-fils
– On parle de schéma en flocon

Schéma flocon
Table Table
Table
Table
Tabledimension
dimension Table dimension
dimension
dimension dimension
temps
temps Categorie
Table Produit
Produit Categorie
Tablede
defait
fait
Numero
Numero PK Numero Numero
Numero PK
PK vente
vente Numero PK PK PK
jour_semaine cate_num description
jour_semaine
Numero cate_num(FK)
(FK) description
mois Numero PK PK
mois description
description
temp_num
temp_num(FK)
(FK)
trimestre
trimestre
produit_num
produit_num(FK)
(FK)
annee
annee
magasin_num Table
Tabledimension
magasin_num(FK)
(FK) dimension
ventes magasin
magasin
Mesures ventes
unites_vendues
unites_vendues Table
Tabledimension
dimension
ou Numero
Numero PK PK
cout
cout canton
canton
faits canton_num(FK)
canton_num(FK) Table
Tabledimension
dimension
nom Numero
nom Numero PK PK pays
pays
adresse pays_num
adresse pays_num(FK)
(FK)
Numero
Numero PK
PK
nom
nom
nom
nom
Modèle en flocon
• Avantages
– Plus propre, respect de la 3NF
– Gain de place de stockage (!)
• Pas un avantage, négligeable sur les tables de dimensions
• Création d’index pour les jointures !!
• Inconvénients
– Plus complexe pour l ’utilisateur final
– Plus de jointures, donc plus lent
• Selon les spécialistes aguerris :
– Evitez le « floconage » des dimensions, même si elles
sont grandes, car les performances seront mauvaises !
Exemple de star schéma (GOsalesDW)

Méta-données des hiérarchies
• Le modèle en étoile ne représente pas

explicitement les hiérarchies !!
• C’est lors de la modélisation dimensionnelle qu’il

faut déterminer les hiérarchie et les protocoler.
– Il n’existe pas de modèle formel
• On peut utiliser des modèles graphiques et/ou des

représentations à puces

Modèle dimensionnel et E/R
• Il est important de comprendre que UN modèle E/R

se décompose en plusieurs schémas
dimensionnels.
• On créera un modèle en étoile pour chaque
« sujet » à analyser.
• Un entrepôt de données est constitué de plusieurs
schémas en étoile avec des dimensions communes
– Schéma en constellation

Assemblage des modèles dimensionnels
• Une des question critique de la construction d’un

système décisionnel complet est la planification de
la construction de l’entrepôt.
• Deux tendances extrémistes :

– Perspective centralisée et monolithique
– Construction de zone thématiques distincts selon les
besoins ponctuels

Perspective centralisée et monolitique
• Cette approche à peu de chances d’aboutir
• Le temps de développement d’un entrepôt est

souvent de plusieurs années/hommes !!
• Le résultat obtenu a beaucoup de chance de ne

pas satisfaire les utilisateurs.
• Effet « tuyau de poêle »

Construction de zone thématiques distincts selon
les besoins ponctuels
Data
Mart
Méta
données
Analyse
Données
Data
de Mart
production Méta
données Reporting
Analyse
Approche itérative
• La pratique à démontré qu’une approche

architecturale par étape est la plus efficace.
• Les datamarts permettent d’éviter de devoir
planifier tout l’entrepôt de données, qui est une
tâche quasi insurmontable.
• La création de l’entrepôt datamart par datamart
risque de créer un structure dimensionnelle
incohérente.
• Il faut intégrer les datamarts dans l’entrepôt en
définissant des dimensions conformes et des faits
standards

Schéma en constellation
Dimension
Dimension
Dimension
Dimension Dimension
Dimension
Dimension
Dimension
Table
Tablede
defait
fait
Table
Tablede
defait
fait
Dimension
Dimension
Dimension
Dimension Dimension
Dimension
Table
Tablede
defait
fait
Dimension
Dimension

Consolidation des datamarts
• Une fois les datamarts recensés, il faut les

consolider pour déterminer les dimensions
conformes et les faits standards
• L’utilisation d’une matrice permet d’identifier les

dimensions conformes, et celles qui sont
importantes pour l’entrepôt.
– Matrice de l’architecture en bus de l’entrepôt

Dimensions conformes
• On appel une dimension conforme, une dimension

qui a la même signification dans touts les tables de
faits avec lesquelles elle peuvent être liées.
• La responsabilité essentielle de la conception d’un

entrepôt de données consiste à établir, diffuser,
maintenir et appliquer les dimensions conformes.
– Il une dimension conforme est souvent un amalgame de
données provenant de plusieurs systèmes opérationnels,
voir de données externes

Faits conformes
• Il est également nécessaire d’établir des faits

(mesures) conformes pour l’entrepôt.
• Par exemple un fait comme recette, benefice ou
prix doit être identique dans chaque datamart
– Même contexte dimensionnel
– Même unité de mesure
» Unités monétaires (Francs, Euro, monnaies étrangères !!)
» Attention par exemple, au conditionnement, boite, douzaine,
kilo,…
» Il est parfois nécessaire de stocker le même fait dans différentes
mesures

Exemple de constellation (Foodmart2000)

Les clés des dimensions
• Toutes les clés de l’entrepôt doivent être des clés

de substitution dépourvues de signification
• Eviter les clés intelligentes

– Les jointures sont considérablement pénalisées
– Les dimensions à évolution lente sont une catastrophe
• Eviter les clés du système de production

– Réutilisation des clés dans le système productif
» Pas de gestion d’historique
– Modification du système de production, ajout d’une source différente
avec les mêmes clés

Dimension à évolution lente
• Chaque dimension est indépendante de toutes les

autres, mais parfois le contenu d'une dimension
peut changer par rapport au temps.
• Le concepteur, doit admettre que les dimensions
sont constantes pour conserver une structure
dimensionnelle indépendante.
– Cependant, il est parfois nécessaire de procéder à des
ajouts mineurs afin de se rendre compte du caractère
évolutif de cette dimension.
• Ces dimensions quasi constantes sont appelées
"dimensions à évolution lente".
– SCD : Slowly Changing Dimensions
Dimension à évolution lente du premier type (SCD1)
• Les anciennes valeurs ne sont pas conservées. La

nouvelle valeur remplace simplement l'ancienne.
Personne Est remplacé Personne

123456 par 123456
Dupont Dupont
Henri Henri
Célibataire Marié

Dimension à évolution lente du second type (SCD2)
• On conserve la situation initiale ainsi que la

situation actuelle. On créer alors un second
enregistrement de la dimension avec la nouvelle
valeur.
• Ce deuxième tuple comporte évidemment une
nouvelle clé.
Personne Personne
On ajoute
123456 123456.1
Dupont Dupont
Henri Henri
Célibataire Marié

Dimension à évolution lente du troisième type (SCD3)
• Ajout de nouveaux champs pour l'attribut concerné.

Il est aussi possible d'ajouter un champ "Date
d'effet".
– La valeur du nouvel attribut est écrasée et la valeur du
champ (Date d'effet) est mise à jour. Le contenu du
champ d'origine n'est jamais modifié.
Personne Personne
Est remplacé
123456 123456
Dupont par Dupont
Henri Henri
Célibataire Célibataire
14.2.2000
Marié

Normalisation et évolution lente
• Une tentative de normalisation plus forte

(floconage) ne résout pas les évolutions des
dimensions.
– Perte de l’ interrogation par voie logicielle
Personne Personne
remplace
123457 123456
Dupont le Dupont
Henri Henri
Marié Célibataire
123456
• La gestion de l ’évolution des dimensions est de

toute façon un casse tête !
Grandes dimensions
• Il est possible qu’une dimension atteigne une très

grande taille.
» Ex : Dimension humaine pour un pays : ~ 100’000’000
» Ex : Clients pour telecom : ~10’000’000
• Doit être particulièrement performante
– Navigation rapide dans la dimension
– Ne pas pénaliser la navigation dans la table de fait
– Pas de doublons
• La majorité des attributs sont moyennement
intéressants pour l’entrepôt
– Nom ou prénom de clients ??

Mini dimensions
• On peut éviter pas mal de problèmes des grandes

dimensions et/ou des dimensions à évolution lente
par l’ajout de mini dimensions
• Par exemple
– Etat civil,Sexe, niveaux d’ages,..
» Devrait être dans la dimension « client » mais bien plus efficace
si elle est une (des) dimension(s) séparée(s)

Cas particulier : Table de fait sans faits
• Chaque table de faits comporte plusieurs champs

de clés suivis de champs de faits numériques,
valorisés de façon continues et additifs.
• Il existe dans certains cas des tables de faits dans
lesquelles il n'y a pas de faits mesurés !
– Ces tables sont appelées table de faits sans fait.
• Il existe deux types de tables de faits sans fait:
– Tables de suivi d'événements
– Tables de couverture

Table de suivi d ’évènements
• afin de pouvoir construire une situation il est

nécessaire d'enregistrer les occurrences de
plusieurs dimensions simultanément
– Les événements sont souvent créés à partir de tables de
faits comportant un certains nombres de clés. Chaque
clé représente la participation de la dimension à
l'événement.
– Ces tables d'événements n'ont généralement pas de faits
numériques évidents qui leur sont associés. C'est pour
cette raison qu'elles sont appelées tables de faits sans
fait.

Tables de couvertures
• Les tables de couverture sont souvent des tables

d'événements qui n'ont pas eu lieu.
• Les tables de couverture sont habituellement sans
fait, comme les tables de suivi d'événements.

Exemple
• Dans un magasin, la base de données enregistre

seulement les articles qui sont passés par la
caisse.
– Comme les articles non-vendus ne sont pas stockés
dans la base, il est difficile de répondre à des questions
tel que "Quels sont les articles en action qui n'ont pas
été vendus ?"
• Afin de répondre à cette question, il est nécessaire
de construire une table de couverture dont les
tuples contient tous les articles en action.

Processus de conception
• Détermination du processus d ’activité à modéliser

» C ’est le processus opérationnel de l ’organisation, étayé par une
application existante
• Détermination du grain du processus d ’activité

» Le grain est le niveau de détail atomique des données
• Détermination des dimensions applicables

» Le choix des dimension s ’accompagne des libellés
• Détermination des faits mesurés

Principes de modélisation
• La première étape de la conception consiste à

choisir les processus d ’activité à modéliser, sur la
base d ’une connaissance de l ’activité et des
sources de données disponibles
• La modélisation doit transformer l’expression des

besoins en un schéma dimensionnel

Définition du grain, étape 2
• La seconde étape de la conception est le choix du

grain de la table de faits pour chaque processus
d ’activité
– Un entrepôt de données exige presque toujours des
informations exprimées dans le grain le plus bas possible
pour chaque dimension.
» Non parce que les requêtes portent sur les enregistrements
individuels, mais parce que les requêtes doivent faire des coupes
dans la base de données selon des critères bien précis.

Modification du grain
• L ’énoncé précis du grain détermine les dimensions

principales de la table de faits.
– Il est possible d ’ajouter ensuite des dimensions
supplémentaires, a condition que celle ci ne puissent
prendre qu ’une valeur pour chaque combinaison des
dimensions élémentaires.
– Si l ’on veut un dimension supplémentaire qui détruit le
grain choisi initialement en entraînant la génération
d ’enregistrements supplémentaires, il faut alors revoir la
définition du grain pour reprendre en compte la
dimension supplémentaire

Normalisation
• La table de faits atteint naturellement un haut degré

de normalisation
• Tout effort de normalisation des tables d ’une base
de données dimensionnelle afin d ’économiser
l ’espace disque est une perte de temps
• Les tables de dimension ne doivent pas être
normalisées mais rester des tables plates
– Des tables de dimensions normalisées ne sont plus
navigables.
– Les gains d ’espace disques sont de l ’ordre de 1% par
rapport à l ’ensemble du schéma

Les neufs décisions majeurs
– Les processus , et partant, l ’identité des tables de faits

– Le grain de chaque table de faits
– Les dimensions de chaque table de faits
– Les faits, y compris les faits calculés
– Les attributs des dimensions,
» avec des descriptions complètes et la terminologie adéquate
– Comment suivre les dimensions à évolution lente
– Les agrégats, les dimensions hétérogènes, les mini-dimensions,
les modes de requêtes et autres décisions de stockages
– L ’étendue historique de la base de données
– Le délai pour le chargement et l ’extraction des données
Les interviews
• Interview des utilisateurs finaux

– Spécification des attentes des utilisateurs finaux
– Prise de conscience des utilisateurs de la construction de
l ’entrepôt
• Interview des DBA
– Confrontation aux réalités des thèmes qui surgissent lors
des interview avec les utilisateurs finaux
» Il est judicieux d ’intercaler les interview des DBA entre ceux des
utilisateurs finaux
– Analyse des structures et de la qualité effective des
données

Création de modèles réalistes
• Il est fondamental de se rappeler que l’entrepôt

s’alimente par le système OLTP
• Il faut disposer de la source de données pour
chaque attribut ou fait du modèle
– Plus les données nécessaires à leurs consolidations
• C’est au moment de la modélisation qu’il faut

s’assurer de la disponibilité de ces données

Mapping
F(x)
F(x)
F(x)
F(x)
U
F(x)

Outils de conceptions
• Il existe des outils complets pour le décisionnel

– Design
– Déploiement
– ETL
• Si vous ne disposez pas d’outils ad hoc, privilégiez

le dialogue avec l’utilisateur
– PowerPoint pour le Star Schéma
– Excel pour le Mapping

Quelques points de conception
• Les intitulés utilisés pour la création des datamarts,

des dimensions, des attributs et des faits sont
vraisemblablement ceux dont l’utilisateur final aura
connaissance. Choisissez-les avec soin.
• Un attribut ne peut exister que dans une et une
seule dimension, alors qu’un fait peut figurer dans
plusieurs tables de faits.
• Si une dimension semble apparaître a plusieurs
endroits, cela signifie probablement qu’elle joue
plusieurs rôles. Nommer ces rôles et traitez les
comme des dimensions différentes.

Bibliographie
• Entrepôts de données
– Guide pratique du concepteur de « data warehouse »
» R. Kimball
» Thomson Publishing
» ISBN : 2-84180-021-0
• Concevoir et déployer un data warehouse

– Guide de conduite de projet
» R.Kimbal, L.Reeves, M.Ross, W.Thornthwaite
» Eyrolles
» ISBN : 2-212-09165-6

Modelisation Dimensionnnelle Diap

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Modelisation Dimensionnnelle Diap

Transféré par

Droits d'auteur :

Formats disponibles

University of Applied Sciences of Western Switzerland

School of Business Administration Neuchâtel

Haute école de Gestion Arc

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 1

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 2

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 3

• La modélisation consiste à transformer les données

• La modélisation dimensionnelle diffère de la

• C’est la seule technique viable permettant de

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 5

• La modélisation entité/relation est adaptée aux

• Le succès du traitement des transactions au sein

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 7

• Il faut l’éviter dans les systèmes décisionnels !!

• L’utilisateur ne peut ni lire ni intégrer un tel modèle

• L’adoption d’un modèle E/R pour un système

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 8

• On peut définir cinq axe de qualification d ’un

• Lisibilité pour l ’utilisateur final

– Certains axes sont antinomiques !!

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 9

• L ’utilisateur final (analyste) doit pouvoir facilement

• Les données doivent être simple à comprendre,

• Plus le modèle est lisible (intuitif) pour les

• Les entrepôts de données sont constitués de

• Les données sont souvent de sources hétérogènes

• Il est assez simple de charger dans une structure

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 11

• L ’exécution des requête doit être rapide pour les

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 12

• L ’administration du système est fondamentale

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 13

• Le développement de l ’entrepôt est bien plus

• Chaque projet ne doit pas déboucher sur un

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 14

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 15

• Une table de faits est une table qui contient les

– Ce type de table est aussi facilement reconnaissable car

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 16

• L'unité de temps la plus petite est appelée le

– Pour connaître celui-ci, il suffit de consulter la table de

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 17

• La table de faits peut aussi contenir des champs

• Certains faits sont dérivés de faits élémentaires, on

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 18

• Il peut exister des faits semi-additifs et non additifs.

• Les faits semi-additifs peuvent être additionnés

• Les faits non additifs ne peuvent être ajoutés.

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 19

• Dans un star schéma, les tables qui entourent la

• Ces tables sont composées d'attributs qui sont

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 20

• Il est important de bien comprendre la différence

Table dimension Table de fait Table dimension

Mois Categorie Produit nb prix

• La dimension temps figure systématiquement dans le

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 23

• Une dimension est un ensemble de valeur

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 24

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 25

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 26

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 27

E. Meylan/ 22/11/2005 Informaticien de Gestion HES / Modélisation dimensionnelle 28