Documente Academic
Documente Profesional
Documente Cultură
Emmanuel Ferragu
Emmanuel Ferragu est consultant expert des systmes dinformation dcisionnels. Il possde prs de 15 ans dexprience dans ce domaine
et intervient en tant quarchitecte et modlisateur de donnes auprs de ses clients
ISBN 978-2-311-01243-9
Prface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XV
Avant-propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII
Objectif du livre et public vis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVIII
Prrequis la lecture du livre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVIII
Organisation du livre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVIII
Chapitre 2
Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1 Dfinition dune dimension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2 Niveaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3 Hirarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.1 Dfinition dune hirarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.2 Relations hirarchiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.3 Forage au sein des hirarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.4 Hirarchies simples et hirarchies alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.5 Hirarchies quilibres. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3.6 Hirarchies dsquilibres. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.7 Hirarchies gnralises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.4 Niveaux interdimensionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.5 Relation dhritage entre niveaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Chapitre 3
Gestion des modifications temporelles intervenant
au sein des dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.1 Gestion temporelle de type 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2 Gestion temporelle de type 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.3 Gestion temporelle de type 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.4 Gestion temporelle hybride ou gestion temporelle de type 12 . . . . . . . . . . . . . 55
3.5 Absence de gestion temporelle (type 0). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.6 Cas courants dutilisation des diffrents types de gestion temporelle . . . . . . . 56
3.7 Cas des corrections derreurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.8 Reprsentation graphique de la gestion temporelle
dans un diagramme MCMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Chapitre 4
Relations factuelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.1 Dfinition dune relation factuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2 Grain dune relation factuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3 Rle dun niveau pour une relation factuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4 Cardinalits dun niveau pour une relation factuelle . . . . . . . . . . . . . . . . . . . . . . 61
Chapitre 5
Mtamodle et synthse de la notation graphique
des MCMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.1 Mtamodle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.2 Synthse de la notation graphique utilise
pour la reprsentation des MCMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Chapitre 6
Bonnes pratiques de modlisation dun MCMD . . . . . . . . 95
6.1 Bonne pratique n 1: tout schma factuel dun MCMD doit comporter
une dimension temporelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.2 Bonne pratique n 2: assurer la conformit des dimensions sur lensemble
dun MCMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.3 Bonne pratique n 3: assurer la conformit des indicateurs . . . . . . . . . . . . . . . . 98
6.4 Bonne pratique n 4: dfinir un MCMD unique pour lensemble
des activits de lentreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.5 Bonne pratique n 5: dfinir le grain le plus fin possible pour les relations
factuelles lmentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.6 Bonne pratique n 6: ne pas mlanger diffrents types
(Transaction, Instantan, Instantan Accumul) dans une mme relation
factuelle lmentaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Chapitre 8
Modlisation logique des hirarchies . . . . . . . . . . . . . . . . . . . . 131
8.1 Modlisation logique des hirarchies quilibres . . . . . . . . . . . . . . . . . . . . . . . . . 131
8.1.1 Approche en flocon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
8.1.2 Approche en toile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
8.2 Modlisation logique des hirarchies dsquilibres . . . . . . . . . . . . . . . . . . . . . . 132
8.2.1 Modlisation logique des hirarchies niveau manquant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
8.2.2 Modlisation logique des hirarchies incompltes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
8.2.3 Modlisation logique des hirarchies rcursives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
8.3 Modlisation logique des hirarchies gnralises . . . . . . . . . . . . . . . . . . . . . . . . 164
8.4 Modlisation logique des hirarchies alternatives . . . . . . . . . . . . . . . . . . . . . . . . . 167
Chapitre 9
Intgration de la gestion temporelle
dans la modlisation logique des dimensions . . . . . . . . . . . 169
9.1 Cas dune dimension avec uniquement des attributs
et relations hirarchiques dont la gestion temporelle est de type 1 . . . . . . . . . . 169
9.1.1 Gestion de type 1 avec une approche en toile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
9.1.2 Gestion de type 1 avec une approche en flocon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
9.2 Cas dune dimension avec uniquement des champs
dont la gestion temporelle est de type 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
9.2.1 Gestion de type 2 avec une approche en toile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
9.2.2 Gestion de type 2 avec une approche en flocon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
9.3 Cas dune dimension contenant la fois des attributs et/ou relations
hirarchiques de type 1 et de type 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
9.4 Cas dune dimension avec attribut(s) ou relation(s) hirarchique(s)
de type 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
9.5 Cas dune dimension avec attribut(s) de type hybride (type 12) . . . . . . . . . . . 184
9.6 Cas des corrections derreurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
9.7 Gestion temporelle des hirarchies rcursives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
9.7.1 Gestion temporelle dune hirarchie rcursive avec la 1re approche (table parent-enfant) . . 186
9.7.2 Gestion temporelle dune hirarchie rcursive avec la 2e approche (table intermdiaire) . . . 189
9.7.3 Gestion temporelle dune hirarchie rcursive avec la 3e approche (nested sets ou LR) . . . . 195
Chapitre 10
Modlisation logique des relations factuelles . . . . . . . . . . . 199
10.1 Drivation logique des indicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
10.1.1 Drivation logique des indicateurs drivs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
10.1.2 Drivation logique des indicateurs lmentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
10.2 Niveaux avec rles multiples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
10.3 Tables de faits sans faits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
10.4 Tables de couverture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
10.5 Drivation logique des relations factuelles en relation 1..N
(ou 0..N) avec un niveau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
10.5.1 Simplification de la relation 1..N par la cration de plusieurs relations 1..1. . . . . . . . . 212
10.5.2 Cration dune table intermdiaire entre la table de faits
et la table de dimension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Chapitre 11
Techniques complmentaires de modlisation logique
des dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
11.1 Dimensions dgnres et dimensions fourre-tout . . . . . . . . . . . . . . . . . . . . . . . . 223
11.1.1 Dimensions dgnres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
11.1.2 Tables de dimension fourre-tout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
11.2 Dimensions gantes et minidimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
11.2.1 Dimensions gantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
11.2.2 Minidimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
11.2.3 Plusieurs minidimensions pour une mme dimension gante . . . . . . . . . . . . . . . . . . . . . . . 232
11.2.4 Limitation occasionne par les minidimensions et solutions de contournement . . . . . . 236
11.3 Attributs forte cardinalit et regroupements par tranches . . . . . . . . . . . . . . . . 238
Chapitre 12
Traitement des cas particuliers des niveaux
interdimensionnels et de lhritage . . . . . . . . . . . . . . . . . . . . . . 245
12.1 Drivation logique des niveaux interdimensionnels . . . . . . . . . . . . . . . . . . . . . . . 245
12.2 Drivation logique des schmas factuels contenant
des relations dhritage entre niveaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
12.2.1 Premire mthode: une table de dimension unique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
12.2.2 Deuxime mthode: une table de dimension par sous-type . . . . . . . . . . . . . . . . . . . . . . . . 251
Chapitre 13
Valeurs NULL et valeurs par dfaut . . . . . . . . . . . . . . . . . . . . . 255
13.1 viter les valeurs NULL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
13.2 La valeur NULL dans les tables de dimension . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
13.3 La valeur NULL dans les cls trangres des tables de faits . . . . . . . . . . . . . . . . 257
13.4 La valeur NULL dans les indicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Chapitre 14
Tables de faits fusionnes et agrgats . . . . . . . . . . . . . . . . . . . 263
14.1 Tables de faits fusionnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
14.2 Agrgats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
14.2.1 Exemples de tables de faits agrges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
14.2.2 Choix des tables de faits agrges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
excutes dans les SIO sont prvisibles : elles sont connues lavance car elles sont
programmes au sein du logiciel autour duquel est conu le SIO. Or, pour que lex-
cution de ces transactions unitaires et prvisibles soit efficace et seffectue sans erreur,
le modle de donnes sous-jacent au SIO doit tre un modle de type entit-associa-
tion et hautement normalis (on utilise en rgle gnral la 3e forme normale). Mais les
informations utiles la prise de dcision doivent tre accdes non pas unitairement
mais en masse (par exemple, lensemble des ventes effectues au cours de lanne
2012). De plus, les demandes dinformations de la part des dcideurs de lentreprise
sont par nature imprvisibles contrairement aux transactions effectues dans les SIO.
Or, nous verrons dans la section suivante quun modle de donnes hautement nor-
malis nest pas adapt pour la rcupration imprvisible dinformations en masse.
Dans un SIO, les donnes enregistres sont constamment modifies et parfois sup-
primes sans que les anciennes valeurs de ces donnes ne soient conserves : une fois
quune commande a t livre, lhistorique des diffrents statuts par lesquels cette
commande est passe ( en attente de traitement , en prparation , expdie )
peut souvent tre supprim. Lorsquun client change dadresse, son ancienne
adresse est remplace par la nouvelle car la conserver est inutile pour le systme de
gestion des ventes. Or, lhistorique des valeurs modifies constitue un ensemble
dinformations utiles pour les dcideurs dune entreprise ou dune organisation :
par exemple, connatre ladresse dun client au moment o il a pass une com-
mande (et non pas son adresse actuelle) est utile en matire de gomarketing.
Mme si depuis la fin des annes 1990, de nombreux projets de rationalisation du
SI ont vu le jour par lintermdiaire de la mise en place de progiciels de gestion
intgrs (PGI), les SIO dune organisation ne sont en rgle gnral pas intgrs : ils
ont t construits brique par brique, sans cohrence densemble, au fur et mesure
de lmergence de nouveaux besoins dautomatisation de processus mtier. Ils fonc-
tionnent le plus souvent en silo , relativement indpendamment les uns des
autres, ne schangeant des donnes les uns avec les autres que par lintermdiaire
dinterfaces point point. Chaque SIO possde sa propre base de donnes, do
une trs grande redondance de donnes au sein de lensemble du systme dinfor-
mation de lorganisation. De plus, les donnes redondantes (cest--dire prsentes
dans plusieurs SIO) sont souvent incohrentes car elles ne peuvent pas tre mises
jour en mme temps dans chaque SIO dans lesquels elles sont prsentes ; elles ne
sont synchronises que priodiquement. Or, les informations ncessaires la prise
de dcision sont le plus souvent parpilles dans de multiples SIO ; il est donc
ncessaire de les rassembler dans un endroit unique et de les mettre en cohrence
pour pouvoir les exploiter de manire optimale.
Le constat de linaptitude des SIO restituer les donnes quils stockent a amen les
organisations construire des systmes part, ddis la restitution dinformations,
que lon a appel des systmes dinformation dcisionnels (SID)1. Par opposition
un SIO dont lobjectif est lexcution dun processus mtier, un SID a pour but lva-
luation de la performance des processus. Il a pour vocation de faciliter la prise de dci-
sion en fournissant des rponses des questions telles que : quelle fut lvolution du
chiffre daffaires et de la marge brute pour chaque catgorie de produits entre le pre-
mier semestre de cette anne et celui de lanne prcdente ? Quelle est la rentabilit
moyenne des clients du secteur des grandes entreprises par rapport celui des ETI2 et
celui des PME ? Quelle fut lvolution annuelle des encours de crdit octroys la
clientle professionnelle par les diffrentes agences de mon rseau bancaire ?
Un SID est donc un systme dinformation ddi aux dcideurs dune organisation
et permettant, au moyen dune base de donnes et dune interface daccs aux donnes,
aux utilisateurs dobtenir des informations utiles la prise de dcision.
Le tableau 1 illustre les principales diffrences entre les SIO et les SID.3
ADRESSE
De nombreux auteurs ont montr les limites de ce modle pour la modlisation des
SID. Pour une dmonstration complte et illustre des inconvnients de cette tech-
nique de modlisation pour la conception des SID, le lecteur pourra se rfrer au livre
de Ralph Kimball, Entrepts de donnes. Guide pratique de modlisation dimensionnelle,
2e dition ou encore au livre de Jean-Marie Gouarn, Le projet dcisionnel. Enjeux,
modles et architectures du Data Warehouse.
Je me contenterai donc de rappeler ces limites, qui sont les suivantes :
La normalisation des donnes induite par le modle entit-association a pour cons-
quence la cration dans la base de donnes de trs nombreuses tables afin dviter la
redondance des donnes stockes. Lexcution de requtes vocation dcisionnelle
requiert alors laccs ces tables via la ralisation de nombreuses jointures. La pr-
sence de ces multiples jointures rend les requtes dextraction difficiles optimiser
et en gnral trs lentes. Ce problme est exacerb par la ncessit de conserver dans
les SID un historique des donnes (contrairement aux SIO pour lesquels seules les
donnes courantes ont le plus souvent besoin dtre conserves). En effet, lhistori-
sation des donnes entrane lapparition de relations N..N (plusieurs plusieurs)
entre les donnes, ce qui a pour consquence la cration de tables supplmentaires.
1. Les attributs, les associations et les cardinalits des associations sont absentes de la figure.
DATE
PRODUIT
Le rectangle Vente au centre de la figure symbolise les faits de vente alors que les
rectangles Date, Client, Produit et Magasin en priphrie reprsentent les dimensions.
Le principal avantage dun modle multidimensionnel par rapport un modle
entit-association rside peut-tre dans sa simplicit : cela saute aux yeux lorsque lon
compare le modle de la figure 2 avec celui de la figure 1. Un modle tel que celui de la
figure 2 est en effet trs simple comprendre pour un utilisateur alors que celui de la
figure 1 est difficilement lisible pour les non-initis.
Lautre avantage majeur dun modle multidimensionnel est quil est ddi aux dci-
deurs de lorganisation. Il peut donc et doit donc tre conu avec eux, en fonction de
la vision quils ont des processus mtier et de leurs besoins danalyse par rapport
chacun de ces processus. Les faits, indicateurs et dimensions contenus dans un modle
multidimensionnel ne sont pas simplement obtenus au moyen dun travail doptimisa-
tion dun modle entit-association via des techniques telles que la dnormalisation.
Au contraire, ces faits, indicateurs et dimensions sont modliss lissue dun travail
collaboratif entre les concepteurs dun SID et les utilisateurs de celui-ci. Seuls les utili-
sateurs sont mme de slectionner les processus mtier et, au sein de ces processus, les
activits dignes dintrt pour eux. Seuls les utilisateurs sont mme de dfinir les
indicateurs qui permettront de mesurer la performance des processus slectionns et les
dimensions au travers desquelles ils souhaiteront analyser ces indicateurs.
Lawrence Corr et Jim Stagnitto, dans leur ouvrage Agile Data Warehouse Design, ont
une vision intressante de ce que reprsente un modle multidimensionnel. En effet, ils
dfinissent les dimensions et les indicateurs dun modle multidimensionnel comme
tant les lments permettant de rpondre au sujet dun processus mtier des questions
telles que les suivantes : Qui (Who) ? Quoi ou Quest ce qui (What) ? Quand (When) ? O
(Where) ? Pourquoi (Why) ? Comment (HoW) ? Combien (hoW many) ? Ils appellent
dailleurs ces sept questions les 7Ws1. Les six premires questions permettent didentifier
les dimensions alors que la septime permet de dfinir les indicateurs. Si lon considre le
modle de la figure 2, on saperoit que les dimensions Date, Client, Produit et Magasin
permettent effectivement de rpondre respectivement aux questions suivantes : quand (a
eu lieu la vente) ?, qui (a achet le produit) ?, quoi ou plutt quest-ce qui (a t vendu) ?
o (a eu lieu la vente) ?
1. En rfrence la lettre W prsente dans chacune des questions.
1. Les termes de data warehouse et de data mart sont conceptuellement trs proches. En ralit, leur
utilisation dpend de larchitecture choisie : dans certaines architectures, il nexiste que des data marts
alors que dans dautres, il peut nexister quun data warehouse sans data marts associs ou encore un data
warehouse associs des data marts. (Le plus souvent, le data warehouse est centralis et unique pour une
entreprise alors que, quand on fait rfrence des data marts, il en existe en gnral plusieurs.)
SI SI dcisionnel
oprationnels
Couche Couche de Couche de restitution
dacquisition stockage
Ventes
Ventes ETL data mart cube Restitution
Commercial OLAP
Fabrication
Fabrication
data mart
ETL Restitution
Marketing
Achats
Achats
data mart
ETL Restitution
RH
RH Finance
modle multidimensionnel
(souvent) ou modle entit-
association (parfois)
1. Il sagit dun parti pris, certains auteurs retenant une autre classification : il nexiste l encore pas de
consensus sur une typologie darchitectures pour les SID.
Supposons que nous souhaitions suivre le processus de vente dans une entreprise mul-
tinationale de distribution.
Les magasins se situent dans diffrents pays sur lensemble des continents du globe.
Certains de ces pays, tels que la France, sont dcoups en dpartements.
Les magasins sont galement regroups selon une organisation de vente compose
de districts de vente, appartenant eux-mmes un pays, chaque pays appartenant
une rgion de vente.
Dans certains pays, un taux de TVA est appliqu la vente des produits. Ce taux
dpend du pays et de la catgorie du produit vendu.
X
TICKET
VENTE (T)
Numro Ticket
Figure 1.1
Quantit Vendue (+)
CATEGORIE (t1) SOUS-CATEGORIE (t1) PRODUIT Prix Unitaire HT (/)
Code Catgorie Code Sous-Catgorie Code Produit Prix Unitaire TTC (/)
Libell Catgorie (t1) Libell Sous-Catgorie (t1) Libell Produit (t1) Montant Vente HT (+) PROMOTION
Montant Vente TTC (+) Code Promotion
Nombre Produits Distincts Vendus (#) Libell Promotion (t1)
TVA
Code TVA Caissier
Taux TVA (t2)
(t2) (t1)
Libell TVA (t1) Gographie EMPLOYE
Conseiller Matricule
MAGASIN Nom (t1)
+ Code Magasin Prnom (t1)
CONTINENT PAYS DEPARTEMENT Date Naissance (t0)
26/08/13 12:46
SID.qxp:Copie de MEP 03/09/13 21:37 Page1
Emmanuel Ferragu
Emmanuel Ferragu est consultant expert des systmes dinformation dcisionnels. Il possde prs de 15 ans dexprience dans ce domaine
et intervient en tant quarchitecte et modlisateur de donnes auprs de ses clients
ISBN 978-2-311-01243-9