Méthodes de

IV -

IV
conception
multidimensionne
lle

Méthodes orientées besoins 47

Méthodes orientées données 51
Méthodes hybrides 54
Références Bibliographiques 55

Plusieurs travaux ont été proposés dans le cadre des méthodes de conception
multidimensionnelles, qui peuvent être classifiés en trois catégories :
 Les méthodes orientées données
 Les méthodes orientées besoins
 Les méthodes hybrides
Le critère principal de cette classification qu'on retrouve dans la plupart des articles
présentant un état de l'art du domaine, est le point de départ de la méthode. Nous
présentons dans ce qui suit les trois classes de méthodes, en mettant l'accent sur
une méthode représentative de chaque catégorie.

A. Méthodes orientées besoins

Ces méthodes s'inspirent souvent des approches de génie logiciel, et notamment de

l'ingénierie des besoins. Leur points de départ est l'expression des besoins en
termes d'aide à la décision, afin de cerner la conception dès le début, et d'éviter les
résultats aberrants. Parmi ces méthodes, celle de Ralph Kimball, est sans doute la
plus connue. Celle-ci constitue un cadre assez complet pour la conception d'un
entrepôt de données selon la vision botom-top propre à l'auteur de la méthode. 6
[6]

1. Choisir la procédure

La procédure (ou fonction) fait référence au sujet d'un magasin de données

Nazih Selmoune
47
 Méthodes de conception multidimensionnelle

particulier. Le premier magasin de données à construire est celui qui est susceptible
d'être livré à temps, en respectant les budgets, et est destiné à répondre aux
questions professionnelles les plus importantes au point de vue commercial

Exemple
Pour sélectionner le principal magasin de données d'une compagnie d'assurances
automobile, nous commençons par déterminer que les processus métier discrets de
la compagnie sont notamment :
 La souscription
 La gestion des sinistres

Image 18 Modèle de données source

Les exigences de données associées à ces processus sont exposées dans le
diagramme E/A précédent. Notez que ce diagramme EA constitue une partie de la
documentation du design, qui décrit les systèmes de traitement de transaction en
ligne nécessaires pour soutenir les processus métier de la compagnie.

Nazih Selmoune
48
 Méthodes de conception multidimensionnelle

Image 19 Fonction choisie : Souscription

2. Choisir le grain

Choisir le grain signifie décider exactement de ce que représente un enregistrement

d'une table de faits.

Exemple
Dans notre cas nous optons pour une granularité correspondant l'ensemble des
contrats souscrits par un assuré sur un modèle et d'un type de véhicule donné, au
niveau d'une agence.
La décision relative au grain pour la table de faits détermine aussi le grain de
chacune des tables de dimension. Dans notre cas, le grain de la dimension Assuré
est l'ensemble des détails du client qui souscrit à une assurance automobile.

3. Identifier les dimensions et s'y conformer

Les dimensions déterminent le contexte dans lequel nous pourrons poser des
questions à propos des faits établis dans la table de faits. Un ensemble de
dimensions bien constitué rend le magasin de données compréhensible et en
simplifie l'utilisation.

Nazih Selmoune
49
 Méthodes de conception multidimensionnelle

Exemple
Dans notre exemple, les dimensions pourraient être :
 Assuré
 Modèle_Véhicule
 Type_Véhicule
 Agence
 Temps

Attention
Un ensemble de dimensions mal présenté ou incomplet réduira à coup sûr l'utilité
d'un magasin de données pour une entreprise.6 [6]

4. Choisir les mesures

Le grain de la table de faits détermine les faits utilisables dans le magasin de

données. Tous les faits doivent être exprimés au niveau implicite imposé par le
grain. Les mesures doivent être numériques, et additifs.

Exemple

Exemple de fait-dimensions

5. Emmagasiner les calculs préliminaires dans la table

des faits

Une fois que les faits ont été choisis, il est nécessaire de les réexaminer un à un,
pour déterminer si des opportunités apparaissent d'exploiter des calculs

Nazih Selmoune
50
 Méthodes de conception multidimensionnelle

préliminaires.

6. Finaliser les tables de dimensions

Au cours de cette étape, nous revenons aux tables de dimensions et y ajoutons

toutes les descriptions textuelles possibles aux dimensions. Les descriptions
textuelles seront aussi intuitives et compréhensibles que possible pour les
utilisateurs.

7. Choisir la durée de la base de données

La durée mesure le saut dans le passé qu'une table de faits permet d'effectuer.

8. Suivre les dimensions à modification lente

Le problème des dimensions à modification lente signifie par exemple que la

description appropriée d'un ancien client et d'une ancienne filiale doit intervenir en
accord avec un ancien historique de transaction.
Nous pouvons distinguer trois types fondamentaux de dimensions à modification
lente :
1. le Type 1, où un attribut de dimension modifié est écrasé;
2. le Type 2, où un attribut de dimension modifié provoque la création d'un
nouvel enregistrement de dimension;
3. et le Type 3, où un attribut de dimension modifié provoque la création d'un
attribut alternatif, pour que les deux valeurs, l'ancienne et la nouvelle,
soient simultanément accessibles dans le même enregistrement de
dimension.

9. Décider des priorités de requêtes et des modes de

requêtes

Au cours de cette étape, nous prenons en considération les soucis liés au design
physique. Les soucis les plus prédominants, relatifs au design physique et qui
affectent la perception du magasin de données par l'utilisateur, sont l'ordre de tri
physique de la table de faits sur disque et la présence de résumés ou d'agrégats
pré-enregistrés

10. Finalité

À la fin de cette la mise en pratique de cette méthodologie, nous obtenons un

design d'un magasin de données qui respecte les exigences d'un processus métier
déterminé et assure aussi une intégration aisée avec les autres magasin de
données liés, pour constituer en définitive l'entrepôt de données de toute
l'entreprise.

B. Méthodes orientées données

Les méthodes orientées données mettent l'accent sur la structuration des données
sources existantes (souvent relationnelles), afin de découvrir les caractéristiques
déterminantes des concepts multidimensionnels (mesures, faits, attributs de

Nazih Selmoune
51
 Méthodes de conception multidimensionnelle

dimensions, hiérarchies).
Dans cette catégorie nous citons les travaux de Moody et Kortink qui se basent sur
une expertise des données sources représentées au niveau conceptuel par un
modèle entité relation, ou logique par un modèle relationnel.

Cette expertise conduit en premier lieu à une classification des structures de

données sources en trois groupes :10 [10]
 Entités transactionnelles
 Entités composants
 Entités Classification

Entités transactionnelles
Qui vont par la suite constituer la base de la table des faits dans des schémas en
étoile puisque ce sont les événements que les décideurs vont analyser.

Entités composants
Qui sont les entités sont directement liées à une entité transaction via une relation
un-à-plusieurs. Elles définissent des détails ou des parties constitutives de chaque
événement d'entreprise. Ces entités donneront lieu à des tables de dimensions
dans les schémas en étoile.

Entités Classification
Ces entités sont liées à des entités composants par une chaîne de relations 'un-à-
plusieurs''. Elles représenteront les hiérarchies de la dimension dans le schéma
multidimensionnel.

Exemple
Considérons le modèle logique de données source ci dessous 10 [10] :

La catégorisation des entités donne le résultat ci dessous (Entités transactionnelles

en noir, Entités composants en gris, Entités Classification en blanc

Nazih Selmoune
52
 Méthodes de conception multidimensionnelle

Après applications des règles de transformation vers le modèle en étoile on obtient

le résultat suivant :

Nazih Selmoune
53
 Méthodes de conception multidimensionnelle

Après applications des règles de transformation vers le modèle en flocon de neige

on obtient le résultat suivant :

C. Méthodes hybrides

Plusieurs travaux ont tenté de regrouper les avantages des deux approches afin
d'en éliminer les inconvénients. Certaines en préconisant carrément deux
conceptions parallèles, l'une orientée besoin et l'autre orientée données, une étape
de confrontation permet de sélectionner les concepts inhérents aux deux
conceptions, afin de satisfaire les exigences des décideurs dans le cadre des
données disponibles, dans ce cas nous pouvons citer les travaux de Bonifatti.

Bonifatti propose : 11 [11]

 Une phase de conception orientée besoins, dans laquelle les objectifs des
décideurs sont dévoilés à travers un cycle d'abstraction et un ensemble de
directives pour la génération d'un schéma logique multidimensionnel.
 Une autre phase orientée données peut être déroulée en parallèle afin de
découvrir faits et dimensions à partir de l'analyse de la structure des
données sources (présence d'attributs additifs, relation un à
plusieurs...etc.). Des graphes centrés sur les faits sont construits et traduits
automatiquement en modèles multidimensionnels en étoiles.
 Enfin une étape d'intégration consiste à unifier en premier lieu la
terminologie des deux modèles logiques produits, et une phase
d'appariement qui donne lieu au modèle cible concilié.

Remarque
Bien que l'hybridation d'approches est une piste souvent attrayante, car elle miroite
l'espoir de regrouper les avantages et éliminer les inconvénients, elle conduit
parfois vers le résultat inverse.

Remarque
Nous remarquons également que mis à part la méthode de Ralph Kimball qui
souffre d'absence de formalisation, nous trouvons rarement des projets de mise en
œuvre d'entrepôts de données qui se basent sur les méthodes de conception

Nazih Selmoune
54
 Méthodes de conception multidimensionnelle

proposées dans la littérature. Cet échec à convaincre les praticiens du domaine

montre que le chantier des méthodes de conception d'entrepôts de données est loin
d'atteindre ses limites.

D. Références Bibliographiques

6. T. Connolly, [Link], "Systèmes de base de données", Editions Eyrolles, 2005

10. Moody, D. L., & Kortink, M. A. (2000). From enterprise models to dimensional
models: a methodology for data warehouse and data mart design. In Proceedings
of 2nd International Workshop on Design and Management of Data Warehouses,
Stockholm, Sweden.
11. Bonifati, A., Cattaneo, F., Ceri, S., Fuggetta, A., & Paraboschi, S. (2001).
Designing data marts for data warehouses. ACM Transactions Software Engineering
and Methodology, 10(4):452-483.

Nazih Selmoune
55