This article was downloaded by: [The University of British Columbia]On: 19 April 2013, At: 11:41Publisher: Taylor & FrancisInforma Ltd Registered in England and Wales Registered Number: 1072954 Registeredoffice: Mortimer House, 37-41 Mortimer Street, London W1T 3JH, UK

Journal of Decision SystemsPublication details, including instructions for authors andsubscription information:http://www.tandfonline.com/loi/tjds20

Modélisation conjointe des données etdes processus pour l’implantation deschémas d’entrepôtsFaten Atigui a , Franck Ravat a , Olivier Teste a & Gilles Zurfluh aa IRIT (UMR 5505), Institut de Recherche en Informatique deToulouse, 118 route de Narbonne, 31062, Toulouse, FranceVersion of record first published: 14 May 2012.

To cite this article: Faten Atigui , Franck Ravat , Olivier Teste & Gilles Zurfluh (2012): Modélisationconjointe des données et des processus pour l’implantation de schémas d’entrepôts, Journal ofDecision Systems, 21:1, 27-49

To link to this article: http://dx.doi.org/10.1080/12460125.2012.677641

PLEASE SCROLL DOWN FOR ARTICLE

Full terms and conditions of use: http://www.tandfonline.com/page/terms-and-conditions

This article may be used for research, teaching, and private study purposes. Anysubstantial or systematic reproduction, redistribution, reselling, loan, sub-licensing,systematic supply, or distribution in any form to anyone is expressly forbidden.

The publisher does not give any warranty express or implied or make any representationthat the contents will be complete or accurate or up to date. The accuracy of anyinstructions, formulae, and drug doses should be independently verified with primarysources. The publisher shall not be liable for any loss, actions, claims, proceedings,demand, or costs or damages whatsoever or howsoever caused arising directly orindirectly in connection with or arising out of the use of this material.

Modélisation conjointe des données et des processus pour l’implantationde schémas d’entrepôts

Faten Atigui*, Franck Ravat, Olivier Teste et Gilles Zurfluh

IRIT (UMR 5505), Institut de Recherche en Informatique de Toulouse, 118 route de Narbonne, 31062Toulouse, France

(Received 2 October 2011; final version received 16 January 2012)

Au cours de ces dernières années, plusieurs approches ont abordé la modélisation et ledéveloppement des Entrepôts de Données (ED). La plupart de ces approches fournit dessolutions partielles qui traitent soit la modélisation multidimensionnelle, soit la modélisa-tion des processus d’Extraction-Transformation-Chargement. Toutefois, peu de travaux ontvisé à unifier ces deux problématiques dans un cadre structuré ou à automatiser le proces-sus d’entreposage complet. Afin de pallier ces limites, nous proposons dans ce papier unedémarche unifiée et automatique qui intègre la modélisation des ED et des processus ETL.Cette démarche est définie dans le cadre d’une Architecture Dirigée par les Modèles(MDA). Elle permet (i) de formaliser les besoins des décideurs, ensuite (ii) de générer lesmodèles conceptuel, logique et physique de l’ED et des processus ETL conjoints (iii) ainsique les codes de création et d’alimentation (ETL) des structures multidimensionnelles. Lesrègles de transformation entre modèles sont formalisées en Query/View/Transformation.

During the last few years, several frameworks have dealt with Data Warehousing (DW)design issues. Most of these frameworks provide partial answers that focus either on multi-dimensional modelling (MD) or on Extraction-Transformation-Loading modelling (ETL).However, less attention has been given neither to unifying both modelling issues into a sin-gle structured framework nor to automating the warehousing process. To overcome theselimits, this paper provides a generic unified and automated method that integrates DW andETL processes design. The framework is handled within the Model Driven Architecture(MDA). It (i) first helps the designer in modelling the decision-maker’s requirements andthen (ii) generates the MD model as well as (iii) the logical and the physical models andfinally (iv) generates the code. In this approach, the transformation rules are formalizedusing the Query/View/Transformation (QVT) language.

Mots-clés: modélisation multidimensionnelle; ETL; MDA; OCL; QVT

Keywords: multidimensional Modelling; ETL; MDA; OCL; QVT

1. Introduction

Un entrepôt de données (ED) est une collection de données thématiques, intégrées, non vola-tiles et historisées pour des fins décisionnelles. Les données pertinentes pour la prise de déci-sion sont collectées à partir des sources au moyen des processus d’Extraction-Transformation-Chargement1 (Vassiliadis 2009). Les données extraites sont souvent structurées selon un for-

*Corresponding author. Email: atigui@irit.fr

Journal of Decision SystemsVol. 21, No. 1, January 2012, 27–49

ISSN 1246-0125 print/ISSN 2116-7052 online� 2012 Taylor & Francishttp://dx.doi.org/10.1080/12460125.2012.677641http://www.tandfonline.com

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13

mat multidimensionnel qui organise l’information en termes de faits et de dimensions (Kim-ball 1996).

Le processus d’entreposage se fait en deux phases. Tout d’abord, il faut créer les struc-tures multidimensionnelles de l’ED; ensuite, il faut extraire les données des sources pour ali-menter l’ED. La première phase repose sur trois étapes principales, à savoir la modélisationconceptuelle, la modélisation logique et la modélisation physique. La modélisation conceptu-elle vise à fournir une représentation commune des données provenant de diverses sourcesopérationnelles. Afin de répondre aux besoins des décideurs, le schéma conceptuel est trans-formé en un schéma logique puis en un schéma physique spécifique à une plateforme(Romero et Abelló 2009). La seconde phase vise à décrire et à implanter les processus ETLqui permettent d’alimenter les structures de l’ED. Pour ce faire, il est également nécessaire desuivre un ensemble d’étapes de modélisation conceptuelle, logique et physique (Simitsis etVassiliadis 2003).

Les méthodes actuelles proposent des solutions pour concevoir et implanter soit le schémamultidimensionnel soit les processus d’alimentation, sans pour autant combiner véritablementles deux. En effet, à l’heure actuelle pour développer un projet d’entreposage complet (de cré-ation des structures multidimensionnelles et d’alimentation), le concepteur doit combiner aumoins deux démarches. Le choix de ces démarches doit prendre en compte les problèmesd’intégration et d’interopérabilité. En outre, la plupart des méthodes existantes manquent demécanismes pour générer automatiquement le code et/ou pour décrire tous les aspects du pro-cessus d’entreposage. Ce dernier s’avère coûteux et souvent voué à l’échec lorsqu’il est faitde manière manuelle (Kimball 1996).

Afin de répondre aux limites des approches existantes, nous souhaitons proposer une dém-arche (i) mixte, (ii) unifiée et (iii) automatique pour la conception et l’alimentation d’ED mul-tidimensionnelles. Il s’agit d’une démarche de modélisation «mixte» puisque le schéma del’entrepôt doit être construit à partir des besoins des décideurs et validé en amont par rapportaux sources de données. Nous qualifions cette démarche d’ «unifiée» car elle doit fournir unseul cadre pour la conception conjointe des ED et des processus ETL. Enfin, cette démarcheest dite «automatique» car elle doit proposer un ensemble de règles permettant la générationautomatique des schémas logiques et physiques à partir du schéma conceptuel, permettant ain-si de réduire le temps et l’effort important requis dans un processus d’entreposage.

Dans ce contexte, il est reconnu que l’Architecture Dirigée par les Modèles (MDA: ModelDriven Architecture)1, standard de l’OMG (Object Management Group), est un cadre qui gèrela complexité de développement et de maintenance, réduit considérablement les coûts dedéveloppement, améliore la qualité du logiciel et réalise des niveaux élevés de réutilisation(Kleppe, Warmer et Bast 2003). Ainsi, en utilisant MDA le processus d’entreposage nécessitemoins d’efforts et de temps. MDA permet d’aboutir au code de l’application en partant desmodèles conceptuels grâce à la définition d’une série de transformations. Par ailleurs, MDAoffre un support à l’intégration, l’interopérabilité, l’adaptabilité, la portabilité et la réutilisationdes systèmes d’informations (Kleppe et al. 2003). MDA est basée sur l’utilisation de modèlesaux différentes phases du cycle de développement d’une application. En effet, MDA préconisel’élaboration de trois types de modèles: 1) Le modèle des exigences (Computation IndependentModel: CIM) décrit les services que doit fournir l’application pour répondre aux besoins desutilisateurs, sans spécifier les détails de sa construction. 2) Le modèle d’analyse et de concep-tion (Platform Independent Model: PIM) définit la structure et le comportement du systèmesans indiquer la plateforme d’exécution. 3) Le modèle de code ou de conception concrète(Platform Specific Model: PSM) est la projection d’un PIM sur une plateforme donnée (Blancet Salvatori 2005).

28 F. Atigui et al.

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13

Le papier est organisé comme suit. En section 2, nous présentons les travaux qui ont traitéla modélisation des ED et des processus ETL. En section 3, nous présentons un aperçu denotre démarche. La section 4 décrit le modèle conceptuel unifié. La section 5 présente lemodèle logique ainsi que les règles de transformation vers le modèle physique. En section 6nous présentons le prototype implanté. La section 7 conclut le papier et annonce les futurstravaux.

2. Etat de l’art

La conception et le développement d’ED a fait l’objet de nombreux travaux. Dans la littéra-ture, elle a été abordée selon deux approches complémentaires mais différentes (Rizzi, Abelló,Lechtenbörger et Trujillo 2006). La première approche aborde la conception du schéma multi-dimensionnel qui vise à déterminer la structure de l’entrepôt (Romero et Abelló 2009). Alorsque la seconde vise à modéliser les traitements ETL afin de représenter les processus respons-ables de l’alimentation et de la mise à jour de l’entrepôt (Vassiliadis 2009). Dans cette sec-tion, nous présentons brièvement les travaux qui ont traité la modélisation et ledéveloppement des ED et/ou des processus ETL.

En ce qui concerne la conception des schémas multidimensionnels, les approches exis-tantes se classent en trois grandes catégories (Rizzi et al. 2006). Les approches «descendan-tes» (Tsois, Karayannidis et Sellis 2001; Prat, Akoka et Comyn-Wattiau 2006) proposent deconstruire le schéma de l’entrepôt à partir d’une analyse détaillée des besoins des décideurs.Alors que les approches «ascendantes» (Golfarelli et Rizzi 1998; Hüsemann, Lechtenbörger etVossen 2000) partent d’une analyse détaillée des sources de données afin de sélectionner lesdonnées pertinentes pour la prise de décision. Enfin, les approches «mixte» (Zepeda, Celmaet Zatarain 2008; Romero et Abelló 2010; Mazón et Trujillo 2009; Carmè, Mazón et Rizzi2010; Essaidi et Osmani 2009) considèrent à la fois les besoins des décideurs et la disponibi-lité des données au niveau des sources. Elles présentent l’avantage de concevoir des schémasmultidimensionnels valides par rapport aux sources de données existantes.

Il existe plusieurs manières pour décrire et implanter les processus ETL. Les industrielsproposent de nombreux outils (Barateiro et Galhardas 2005) tels que Microsoft IntegrationServices, Oracle Warehouse Builder, etc. De manière générale, les travaux de recherche prop-osent soit des modèles spécifiques soit d’utiliser et/ou d’étendre des standards existants telsque UML ou le BPMN (Business Process Model Notation). D’une part, Simitsis et Vassiliadis(2003) présentent une méthode pour la conception des processus ETL. Les auteurs proposentdes notations graphiques spécifiques permettant de décrire les problèmes techniques souventrencontrés dans les processus ETL. Simitsis, Skoutas et Castellanos (2010) exploitent lestechnologies du web sémantique afin de faciliter le processus de sélection et de transformationdes données pertinentes à partir des sources. D’autre part, d’autres travaux proposent d’utiliserou d’étendre UML pour décrire le workflow ETL. Trujillo et Luján-Mora (2003) définissent

Tableau 1. Mots clés ETL-OCL.

Mot clé Description

Context Définit le contexte de la contrainte ETL-OCL: les mesures d’un fait ou lesattributs (paramètres ou attributs faibles) d’une dimension.

Derive Indique que la valeur de l’attribut multidimensionnel est dérivée à partir desvaleurs des attributs sources.

Select (expressionbooléenne)

Permet de sélectionner un sous-ensemble qui répond à un critère donné.

Journal of Decision Systems 29

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13

Tableau

2.Opératio

nsde

transformationd’attributssourcesutilisant

ETL-O

CL.

Opératio

nsde

transformation

Descriptio

nETL-O

CL

Identité

Relationde

correspo

ndance

simpleentreun

attribut

source

etun

attribut

ciblede

l’ED.

Opérateur

d’égalité.

Con

version

(attributs)

Con

versionde

lavaleur,du

type

oudu

form

atd’un

attribut

source.

Con

versionarith

métique:lesfonctio

nssum(),prod

uct(),max(),min(),etc.

Con

versionde

chaînesde

caractères:concat(),size(),substring(),toUpp

ercase(),etc.

Con

versionde

types:«A

ttribut.oclAsType(no

uveautype)»:un

attribut

peut

être

ré-typ

éen

untype

auqu

elilestconformé(unentierpeut

être

transforméen

unréel

par

exem

ple),sino

nl’expression

ETL-O

CLestévalué

commeinvalid

e.Sélectio

n(filtre)

Sélectio

ndesattributsqu

irépo

ndentàcritère

donn

é.Les

opérations:«S

elect»,«R

eject»,«If…

else»,

«collect»,

«exists»,etc.

Agrégation

Agrégationdesattributssourcesen

fonctio

nd’autres

attributssources.

L’op

ération«A

GG».

Incorrect

Détecte

lestypeset

lesform

atsde

donn

ées

incorrects.

Exceptio

nslevées

quandl’expression

ETL-O

CLestévaluéeinvalid

e.

Jointure

(classes/

associations)

Jointure

deconceptssources(classes/

associations)ayantdesliens

directsou

indirects.

Navigationàtraverslesassociations

etlesclassespo

uraccéderauxattributs.

Fusion

(mod

èles)

Fusionde

mod

èles

sourceset

dumod

èlecible.

Liens

établis

entrele

mod

èlecible(faitset

dimension

s)et

lesmod

èles

sources(classes

etassociations).

30 F. Atigui et al.

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13

un ensemble d’activités ETL via des classes stéréotypées. Ils utilisent les notes UML pourspécifier les relations de correspondances entre les attributs cible de l’entrepôt et les attributssources. Luján-Mora, Vassiliadis et Trujillo (2004) étendent UML via un diagramme de corre-spondance qui explicite les relations de transformations des attributs sources en attributs ciblede l’ED. Muñoz, Mazón, Pardillo et Trujillo (2008) utilisent les diagrammes d’activités UMLafin de concevoir les processus ETL. Enfin, Muñoz, Mazón et Trujillo (2009) proposent uneapproche dirigée par les modèles pour générer les processus ETL. El Akkaoui et Zimanyi(2009) présentent un modèle conceptuel basé sur le BPMN.

Par rapport aux travaux existants et particulièrement Mazón et Trujillo (2008), l’avantagede notre approche réside dans la description unifiée des structures multidimensionnelles et desprocessus d’alimentation. En effet, nous suivons la même démarche de conception que l’équi-pe de Trujillo qui est une démarche dirigée par les modèles. Cependant, plutôt que définirdeux processus indépendants pour la modélisation de la structure multidimensionnelle d’unED et pour la spécification des traitements ETL, nous unifions dès les premières étapes cesdeux processus. Cette solution permet de limiter des étapes redondantes et coûteuses de laconfrontation du schéma multidimensionnel et de ses processus ETL avec les sources de don-nées. De plus, la confrontation des sources est effectuée dès la définition du CIM et évite ain-si la définition d’attributs dont il serait impossible de définir le processus d’alimentation et derafraîchissement. Ce modèle permet également d’éviter les problèmes d’incohérence, d’inté-gration et d’interopérabilité qui s’imposent si on utilise des modèles et/ou des approches dis-tincts. Par ailleurs, il permet de définir des concepts multidimensionnels (données ettraitement) prêts à être réutilisés pour définir de nouveaux schémas d’entrepôts. Notreapproche présente aussi l’avantage de réutiliser et d’adapter des modèles et langages existants,notamment avec les modèles en constellation (Golfarelli, Maio et Rizzi 1998) reconnus dansla conception multidimensionnelle, et le langage de contrainte OCL2 (Object Constraint Lan-guage) standardisé par l’OMG.

3. Démarche de modélisation dirigée par les modèles

Notre approche est abordée dans un cadre dirigé par les modèles. La Figure 1 présente un aperçude notre proposition. Partant d’une représentation formelle des besoins des décideurs au niveau

Figure 1. Démarche dirigée par les modèles pour le développement d’ED et d’ETL.

Journal of Decision Systems 31

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13

du CIM la démarche permet d’aboutir aux modèles physiques spécifiques à différentes platefor-mes. Les principes de MDA simplifient la tâche du concepteur. Ce dernier construit un modèledes besoins (CIM) et les transformations automatiques le traduisent en une succession de modè-les de façon à obtenir un modèle physique adapté à la plateforme choisie. Pour ce faire, d’abord,un premier modèle multidimensionnel (PIM1 conceptuel) est dérivé à partir du CIM. Deux typesde modèle multidimensionnel peuvent être utilisés en fonction des préférences du concepteur.Le premier est basé sur UML, alors que le second est basé sur les modèles en constellation pré-sentés dans Golfarelli et al. (1998), et Ravat, Teste, Tournier et Zurfluh (2008). Quel que soitson type, ce PIM est complété via des expressions ETL-OCL, définies en se basant sur le lan-gage OCL. Ces expressions permettent de décrire de manière conceptuelle les formules d’extrac-tion et de transformation (projection, conversion, sélection et agrégation) des attributsmultidimensionnels. Par la suite, plusieurs modèles logiques unifiés (PIMs2, tel que le CWM3:relationnel et les expressions en algèbre relationnelle) peuvent être générés à partir des modèlesconceptuels. Ensuite, différents modèles physiques (PSM) peuvent être générés à partir desmodèles logique et conceptuel en fonction de la plateforme de déploiement choisie par le con-cepteur, en l’occurrence la plateforme Oracle. Enfin, la démarche fournit le code de création etd’alimentation (ETL) des structures multidimensionnelles de l’ED.

Les transformations entre les modèles sont formalisées au moyen du langage QVT (Query/View/Transformation)4 de telle sorte que le code final soit généré automatiquement. Principale-ment, trois types de transformations de modèles sont définis. Les transformations «intra-niveau»,graphiquement représentées par des cercles dans la Figure 1, permettent de convertir un modèlesource en un modèle cible dans le même niveau d’abstraction (par exemple du modèle concept-uel en constellation vers le modèle conceptuel basé sur les profils UML). Alors que, les transfor-

Figure 2. PIM multidimensionnel (analyse des montants et des quantités des ventes selon les clients,les produits et les dates).

32 F. Atigui et al.

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13

mations «inter-niveaux» représentées graphiquement par des triangles, permettent de trans-former un modèle source en un modèle cible à deux niveaux d’abstraction différents (par exem-ple, un PIM conceptuel est transformé en un PIM logique). Enfin, lors de la «fusion detransformations» représentée par des losanges dans la Figure 1, plusieurs modèles sources sontcombinés en un modèle cible unique (par exemple les PIM conceptuel et logique sont transform-és en un PSM). Les transformations inter-niveaux et la fusion de transformations sont chargéesd’automatiser le processus d’entreposage, car elles permettent la génération automatique du codefinal à partir des besoins des décideurs. Alors que, les transformations «intra-niveaux» permet-tent d’améliorer le niveau d’intégration et de portabilité dans le système. En effet, elles permet-tent de déduire un PSM à partir d’un autre directement ou en exécutant les transformations«inter-niveaux». La figure suivante représente les différentes étapes de notre approche.

Dans les sections suivantes, nous présentons le modèle multidimensionnel unifié basé sur lesmodèles en constellation. Ensuite, nous présentons le modèle logique et nous détaillons lestransformations vers le modèle physique. Le modèle conceptuel basé sur les profils UML ainsique les transformations de ce modèle vers le modèle logique sont détaillés dans Atigui, Ravat,Teste et Zurfluh (2010) et Atigui, Ravat, Tournier et Zurfluh (2011).

4. Modèle multidimensionnel unifié (PIM1)

La modélisation conceptuelle fournit un haut niveau d’abstraction et permet de se dissocierdes problèmes de déploiement en se concentrant sur les besoins décisionnels (Rizzi et al.2006). Bien qu’il n’existe aucun modèle standard pour la conception des entrepôts de don-nées (Sen et Sinha 2005), les modèles en constellation (Golfarelli et Rizzi 1998; Ravat et al.2008) sont largement acceptés pour représenter les bases de données multidimensionnelles.Cependant, ces modèles permettent de représenter les caractéristiques structurelles des entre-pôts et manquent de mécanismes pour décrire les aspects comportementaux. Pour pallier cettelimite, nous proposons d’étendre l’Object Constraint Language (OCL) et de définir lesexpressions OCL dans le modèle en constellation.

4.1. Pourquoi OCL?

Dans un processus ETL, les données extraites des sources subissent une série de transformationsavant d’être chargées dans l’ED. La modélisation conceptuelle des processus ETL vise à spécifi-er la relation de transformation entre les attributs multidimensionnels cibles et les attributssources. Si on considère que toutes les données à extraire sont disponibles dans une source dedonnées relationnelles, ces opérations peuvent être de trois types:

• La valeur d’un attribut cible est calculée à partir de la valeur d’un attribut sourceunique (opération identité) (DW.Produit.codeP = SR.Produit.codeP);

• La valeur d’un attribut cible est calculée à partir de plusieurs valeurs d’un attributsource unique (DW.Ventes.quantité = Sum(SR.LigneCde.quantité));

• La valeur d’un attribut cible est calculée à partir des valeurs de deux ou plusieurs attri-buts sources (DW.Ventes.montant = Sum(SR.LigneCde.quantité) ⁄ SR.Produit.prix-Unit).

Il est possible d’appliquer une opération de «sélection» dans ces trois cas: seules les val-eurs qui répondent à un critère donné sont extraites (DW.Produit.codeP = SR.Produit.codeP[critère: SR.Produit.description = «TV»]).

Journal of Decision Systems 33

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13

Afin de décrire la structure multidimensionnelle et les processus de transformation demanière conjointe, il est indispensable de fournir un moyen pour spécifier ces différentes opé-rations de manière à compléter le schéma multidimensionnel. En effet, on a besoin d’un lan-gage qui permet de décrire les opérations de transformation de manière indépendante desplateformes et qui relève du niveau d’abstraction conceptuel. Ce langage doit être formel pourpermettre une génération automatique du code final. Il doit également fournir un moyen pourexprimer des relations de «dérivation» entre attributs. En outre, ce langage doit fournir unmoyen pour naviguer entre les différentes concepts (classes, fait, dimensions, etc.) et d’accé-der à leurs attributs. Enfin, il doit permettre d’exprimer des opérations mathématiques(somme, produit, etc.), des opérations sur les chaînes de caractères ainsi que des opérationsde sélection et d’agrégation d’attributs.

Le langage OCL est formel, précis, simple, supporté par nombreux outils (Warmer etKleppe 2003) et donc répond en grande partie à ces besoins. En effet, il permet d’exprimerdes contraintes et des requêtes sur un modèle de manière précise et indépendante des platefor-mes. Il s’agit d’un langage formel qui peut être traduit de manière automatique vers les nive-aux logique et physique. Ce langage vise principalement à raffiner les diagrammes UML enparticulier les diagrammes de classes. Il a été étendu pour exprimer des contraintes et des req-uêtes sur d’autres types de modèles, notamment, les modèles multidimensionnels. Ces exten-sions essentiellement orientées définition des contraintes (Bejaoui, Pinet, Schneider et Bédard2010) ou interrogation (Pardillo, Mazón et Trujillo 2010) ne répondent pas à notre objectifd’extraction et de transformation de données sources pour alimenter un ED. OCL est assezriche pour permettre une description conceptuelle de la plupart des mécanismes ETL. Cepen-dant, il ne fournit pas un moyen pour exprimer l’agrégation des données, fonction souventutilisée pour synthétiser les données sources. Pour le compléter, nous proposons de l’étendrevia une opération d’agrégation de données «AGG» présentée dans la sous-section suivante.

4.2. ETL-OCL: syntaxe

Une expression OCL est définie dans un contexte (une classe, un attribut ou une opérationdans un diagramme de classe). Elle permet d’exprimer des invariants sur un objet ou encorede spécifier que la valeur d’un attribut est dérivée à partir d’un ou plusieurs autres attributs.Elle permet également de définir des post et des pré-conditions sur des opérations. Uneexpression ETL-OCL est définie dans le contexte d’un attribut multidimensionnel. Elleexprime une relation de dérivation entre cet attribut et un ou plusieurs attributs sources.

Le tableau suivant définit les principaux mots clés OCL utilisés pour définir une expres-sion ETL-OCL.

Afin de transformer les données sources, les expressions ETL-OCL utilisent les différentesopérations fournies par la bibliothèque standard d’OCL pour décrire des fonctions sur deschaînes de caractères (concat(), size(), substring(), toInteger(), toUpperCase(), etc.) ainsi quedes fonctions mathématiques appliquées en particulier sur les attributs numériques (min(),max(), product(), sum(), etc.).

Dans notre contexte de modélisation multidimensionnelle, chaque attribut de l’ED estdérivé à partir d’un ou plusieurs attribut(s) source(s). En conséquence, il est possible d’exploi-ter OCL pour formaliser des expressions qui mettent en relation des attributs appartenant àdes modèles différents. Pour ce faire, il est indispensable d’expliciter les relations entre attri-buts en termes de relations entre concepts (classe, fait, dimension, etc.). L’objectif est d’établirdes liens entre les deux modèles pour que la navigation entre les concepts cibles et les con-cepts sources soit possible afin de définir des expressions ETL-OCL. Chaque concept cible(fait ou dimension) est relié à zéro ou un concept (en fonction du type du schéma source: les

34 F. Atigui et al.

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13

classes et les associations s’il s’agit d’un diagramme de classes, les classes d’entité et les clas-ses d’association s’il s’agit d’un modèle E/A, etc.) dans chaque source.

Pour compléter les expressions ETL-OCL, nous définissons l’opération d’agrégation com-me suit:

Définition. AGG (ASI → AF; ASJ [→ select (PASJ)]), où:ASI: attribut agrégé;AF: fonction d’agrégation prédéfinie dans la bibliothèque OCL (sum, count, min, max,

avg (sum / size));ASJ: attributs servant à définir le critère de regroupement;PASJ: prédicat de sélection appliqué aux attributs de regroupement.

Le tableau suivant présente les principaux mécanismes ETL conceptuels présentés dansSimitsis et Vassiliadis (2003) et Trujillo et Luján-Mora (2003) ainsi que leurs formalisationsen ETL-OCL.

Exemple 1. La figure suivante présente le schéma multidimensionnel (en haut de la figure)permettant l’analyse des montants et des quantités des ventes en fonction des produits, desclients des pays européens du bassin méditerranéen et des dates. En bas de la figure le dia-gramme de classes présente un extrait d’une source de données. Chaque concept cible (faitou dimension) est relié à un concept de la source (classe ou association). D’un point de vuegraphique, ces liens sont représentés par des lignes discontinues.

Les expressions ETL-OCL définies sur les attributs de la dimension «Client» et lesmesures du fait «Ventes» sont les suivantes:

Context Client:: codeClient: Integerderive: SR.client.codeC

– Le paramètre codeClient est construit à partir del’attribut codeC de la classe source Client.

Context Client:: nom: Stringderive: SR.client.nom.concat(‘.’).concat (SR.client.prenom)

– L’attribut faible «nomClient» est égal à laconcaténation: «nom.prenom»

Context Client:: sexe: Stringderive: If SR.client.sexe = ‘masculin’ then ‘H’else ‘F’endif

– L’attribut faible sexe vaut «H» si l’attributsource de la classe «Client» est égal «masculin» etvaut «F» sinon.

Context Client:: ville: Stringderive: SR.client.ville – Le paramètre ville est égal à l’attribut ville de laclasse Ville.

Context Client:: pays: Stringderive: SR.client.paysselect(nomP = ‘France’ or nomP = ’Italie’ ornomP = ‘Espagne’ or nomP = ‘Portugal’ ornomP = ‘Grèce’).

– Le paramètre pays est égal à l’attribut pays de laclasse «nomP» de la classe « Pays ». Seuls lespays européens du bassin méditerranéen sontsélectionnés. La navigation se fait en suivant lesrôles.

Context Ventes::quantité: Realderive: AGG (SR.LigneCom.quantité sum(); SR.ligneCom.produit.codeP,SR.ligneCom.commande.client.codeC, SR.ligneCom.commande.dateC)

– La mesure quantité est égale à la somme desquantités de la classe d’association source«LigneCom» calculée par code produit, code clientet date.

Context Ventes::montant: Realderive: AGG ((SR.ligneCom.quantité ⁄SR.ligneCom.produit.prixUnit) sum(); SR.ligneCom.produit.codeP,SR.ligneCom.commande.client.codeC, SR.ligneCom.commande.dateC)

– La mesure montant est égale à la somme desquantités multipliée par le prix unitaire du produit,l’agrégation se fait par code produit, code client etdate.

5. Génération automatique des modèles logique et physique

Dans cette section, nous présentons les règles de transformation du modèle conceptuel (PIM1)en modèle logique (PIM2), ensuite nous présentons les règles de transformation vers le mod-èle physique (PSM) et le code.

Journal of Decision Systems 35

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13

5.1. Modèle logique (PIM2)

Les modèles logiques sont générés automatiquement à partir des modèles conceptuels enappliquant un ensemble de règles. Afin de couvrir autant que possible d’applications d’entre-posage, notre approche fournit un ensemble varié de modèles logiques de l’ED. Le concep-teur peut choisir le modèle le mieux adapté à l’application qu’il a à développer, à savoir leROLAP5 normalisé (étoile), dénormalisé ou optimisé (R-OLAP avec définition des treillis dedonnées) ou encore des schémas XML, etc.

Dans ce qui suit, nous présentons les principales règles de transformation de structuresmultidimensionnelles vers le schéma logique ROLAP dénormalisé ainsi que les règles detransformation relatives aux opérations de chargement vers l’algèbre relationnelle.

5.1.1. Transformation du schéma MD

Le modèle en constellation représente les données en termes de «Fait» et de «Dimension».Les règles suivantes montrent les relations de transformation des différents éléments duschéma en constellation (faits et dimensions) en éléments du schéma R-OLAP dénormalisé(tables).

• R1: Tout schéma en constellation est transformé en un schéma relationnel;• R2: Chaque dimension est transformée en une table où:

- Les colonnes = tous les paramètres et les attributs faibles relatifs aux différenteshiérarchies composant cette dimension;

- Clé primaire = paramètre du plus bas niveau (appelé paramètre racine).• R3: Chaque fait est transformé en une table où:

- Les mesures et les paramètres racines relatifs aux dimensions en relation avec lefait sont transformés en colonnes de cette table;

- Les clés étrangères correspondent aux paramètres racines des dimensions en rela-tion avec le fait;

La clé primaire correspond à la concaténation des clés étrangères référençant les dimen-sions auxquelles est lié le fait.

La formalisation de ces règles de transformationnel QVT (Query/View/Transformation)permet un passage automatique entre le modèle conceptuel et les modèles logiques de notredémarche. QVT est un langage déclaratif standardisé par l’OMG. Une transformation QVTentre deux modèles candidats est spécifiée grâce à un ensemble de relations. Chaque transfor-mation est composée des éléments suivants:

• «Domains»: chaque domaine désigne un modèle candidat et un ensemble d’éléments àrelier.

• «Relation Domain»: permet de spécifier le type de relation entre les domaines, ellepeut être marquée comme «Checkonly» (C) ou «Enforced» (E). Un domaine«Chekonly» permet de vérifier s’il existe une correspondance valide qui satisfait larelation; alors qu’un domaine «Enforced» permet de créer un élément dans le modèlesi le lien de correspondance n’est pas vérifié. Pour chaque domaine le nom de sonmétamodèle sous-jacent doit être spécifié.

• La clause «When»: décrit les pré-conditions qui doivent être remplies pour réaliser latransformation.

36 F. Atigui et al.

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13

• La clause «Where»: détermine les post-conditions qui doivent être remplies par tousles éléments du modèle participant à la relation.

Relation «Main». Cette relation est le point d’entrée au processus de transformation. La par-tie gauche de la Figure 3 montre les éléments du modèle source (md: MD) transformés en élé-ments du modèle R-OLAP dénormalisé (drolap: ROLAP) présenté par la partie droite de lafigure. Un schéma en constellation est transformé en un schéma ROLAP de même nom. Chaquefait est transformé en une table via la relation «FactToFactTable». Chaque dimension est traduiteen une table du schéma relationnel par la relation «DimensionToDimTable» spécifiée au niveaude la clause «Where». Cette clause indique également que toutes les formules d’extraction et detransformation des attributs sources exprimées en ETL-OCL sont traduites en un ensemble derequêtes exprimées en algèbre relationnelle.

Relation «Dimension en table». Une dimension est transformée en une table relationnelledont le nom correspond au nom de la dimension. Tous les attributs (les paramètres et les attri-buts faibles) de la (ou des) hiérarchie(s) composant cette dimension sont transformés en col-onnes de la table en appliquant respectivement les règles «ParameterToColumn» et«WeakAttributeToColumn». Le paramètre racine détermine la clé primaire de cette table viala relation «ParameterToKey» définie par la clause «Where». Enfin, les expressions ETL-OCL définissant les formules d’extraction des différents paramètres et attributs faibles de ladimension sont transformés en requêtes algébriques.

Relation «Fait en table». Une fois les dimensions liées au fait transformées (la pré-condi-tion «DimensionToDimTable» de la clause «When»), le fait est converti en une table ayant lemême nom. Les mesures sont transformées en colonnes au moyen de la relation «MeasureTo-Column» de la clause «Where». Cette clause permet aussi la transformation de toutes lesformules d’extraction des mesures exprimées en ETL-OCL en requêtes algébriques.

5.1.2. Transformation des opérations d’extraction et de transformation: des expressionsETL-OCL vers l’algèbre relationnelle

La description conjointe du schéma MD et des processus d’extraction et de transformationrepose sur l’utilisation des schémas en constellation et du langage ETL-OCL. Dans cette sous-

Figure 3. «Relation Main».

Journal of Decision Systems 37

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13

section nous présentons les opérations logiques qui correspondent aux différentes opérations detransformation conceptuelle. Le tableau suivant résume ces correspondances.

L’opération «Incorrect» est relative au niveau conceptuel uniquement, aucune opération nelui correspond au niveau logique. En effet, cette opération lève une exception (ETL-) OCL etla translation vers le niveau logique n’aura lieu que si cette exception est traitée c’est-à-direque les types et les formats de données sont évalués corrects. L’opération logique «Surrogate»est spécifique au modèle logique en algèbre relationnelle et permet de générer une clé prim-aire automatique identifiant chaque table de manière unique.

Tous comme les règles de transformation de structures, les opérations d’extraction et detransformation exprimées au niveau conceptuel par des requêtes ETL-OCL sont converties enun ensemble de fonctions exprimées en algèbre relationnelle. Dans ce qui suit nous présen-tons la formalisation en QVT (syntaxe graphique) des règles présentées dans le Tableau 3.

Relation «Expression ETL-OCL en expression algébrique». Toute expression ETL-OCLest transformée en une requête algébrique. La clause «When» précise que lesdimensions et les faits du schéma conceptuel doivent être déjà converties en tables. La clause

Tableau 3. Opérations de transformations conceptuelles et leurs équivalentes logiques.

Opérations conceptuel(ETL-OCL) Opérations logiques (Algèbre relationnelle)

Identité Projection (τ) [Attribut] Table.Jointure Jointure de tables reliées par des attributs communs (Table ffl Table)Sélection (critère) Sélection (critère) (c[Attribut] TableConversion Fonctions de conversion.Agrégation Fonctions d’agrégation.Incorrect Aucune opération logique.Fusion Lien de bases de données (DATABASE LINK).

Surrogate: génère une clé unique.

Figure 4. Relation de transformation de dimension en table.

38 F. Atigui et al.

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13

«Where» identifie les relations de correspondances entre les différentes opérations de transfor-mation conceptuelles et logiques.

Relation «Agrégation ETL-OCL en agrégation relationnelle». Cette relation permet latransformation de l’opération d’agrégation définie sur les attributs appartenant à des classesdu niveau conceptuel en une opération d’agrégation définie sur les attributs des tables duniveau logique. Tous les paramètres de cette opération sont transformés en leurs équivalentsdu niveau logique. La clause «When» précise que les faits et les dimensions doivent être con-vertis en tables au préalable.

Relation «Sélection ETL-OCL en restriction relationnelle». Toute opération de sélectiondéfinie au niveau conceptuel en utilisant les opérateurs «Select», «Reject» ou encore l’instruc-tion «If, Else» est transformée en une opération de sélection logique. L’attribut sur lequel portela sélection indique la colonne sur laquelle est définie la restriction logique. L’opérande et le crit-ère de sélection définissent respectivement l’opérande et le critère de sélection logique.

Exemple 2. Les expressions ETL-OCL du modèle conceptuel et présentées dans l’exem-ple1 sont transformées en expressions algébriques comme suit. Les relations sources corre-spondent aux classes du diagramme présenté dans l’exemple 1.

DW.Client = Π [codeC AS codeClient, nom+’.’+prenom AS nom, ville, nomP] (SR.ClientSR.Pays)

DW.Ventes = Π [dateC AS date, codeP AS codeProduit, codeC AS codeClient, quantité,montant] ((Sum ([SR.Commande SR.LigneCom];[SR.LigneCom.codeP, SR.Commande.codeC,SR.Commande.dateC]; [quantite];;)As quantite) (Sum ([SR.Commande SR.LigneCom) SR.Produit]SR.LigneCom.codeP, SR.Commande.codeC, SR.Commande.dateC];[SR.LigneCom.quantite ⁄ SR.Produit.prix_unit] As montant))

Figure 5. Relation de transformation de fait en table.

Journal of Decision Systems 39

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13

5.2. Modèle physique (PSM)

Dans cette section, nous présentons comment obtenir le modèle physique (PSM) à partir desPIMs conceptuel et logique. Les règles de transformation sont formalisées en QVT. Lesmodèles physiques sont dépendants d’une plateforme spécifique (Oracle, Mondrian, etc.). Afind’illustrer notre démarche, nous choisissons de détailler les règles de transformations permet-tant de générer les vues matérialisées Oracle. L’utilisation des vues matérialisées est avantage-use puisque le calcul, le stockage, la mise à jour et le rafraîchissement sont effectuésautomatiquement par le SGBD. Dans cette section, nous présentons les règles de transforma-tion modèle-à-modèle permettant de générer la structure du modèle physique.

5.2.1. Règles de transformation des PIMs en PSM

Le schéma physique Oracle est composé de vues matérialisées et de dimensions. Ladéfinition des vues matérialisées dépend des tables logiques ROLAP et des expressions ETL-OCL, alors que la définition des dimensions dépend des hiérarchies du schéma conceptuel.Par conséquent, le modèle physique est généré en fusionnant le schéma conceptuel (schémaen constellation) et le schéma logique (schéma ROLAP dénormalisé) en appliquant les règlessuivantes:

• R1: Tout schéma ROLAP est transformé en un schéma Oracle.• R2: Chaque table de dimension du schéma ROLAP est transformée en une vue mat-

érialisée. Les colonnes et la clé primaire de la table correspondent respectivement auxcolonnes et à la clé primaire de la vue matérialisée.

• R3: Chaque table de fait est transformée en une vue matérialisée. Les colonnes de latable sont transformées en colonnes de la nouvelle vue. La clé primaire et les clés

Figure 6. Relation de transformation des expressions ETL-OCL en requête algébrique.

40 F. Atigui et al.

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13

étrangères sont transformées en clé primaire et clés étrangères référençant la vue mat-érialisée appropriée.

• R4: Chaque dimension du modèle conceptuel est transformée en une dimension Oracle.Ses hiérarchies, ses paramètres et ses attributs faibles sont respectivement transformésen hiérarchies, niveaux et attributs de la nouvelle dimension.

Nous présentons la formalisation de ces règles en utilisant la syntaxe graphique QVTcomme suit.

Relation «Main». Cette relation permet de fusionner deux modèles sources en un modèlecible. La partie gauche de la figure suivante montre deux domaines différents, le premier faitpartie du PIM logique (drolap: ROLAP), le second domaine fait partie du modèle conceptuelPIM (md: MD). La partie droite de la figure explicite le modèle en sortie composé de vuesmatérialisées et de dimensions. La clause «Where» indiquent que les tables ROLAP sonttransformées en vues matérialisées et que les dimensions de la constellation sont transforméesen dimensions Oracle.

Figure 7. Relation de transformation des opérations d’agrégation conceptuelle en fonction logique.

Figure 8. Relation de transformation des sélections conceptuelles en restrictions logiques.

Journal of Decision Systems 41

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13

Relation «Table dimension en vue matérialisée». Chaque table de dimension du modèleROLAP est transformée en une vue matérialisée ayant le même nom. La clause «Where»identifie les relations de transformation des colonnes et des clés primaires.

«Dimension multidimensionnelle en dimensionOracle». Cette relation permet de trans-former chaque dimension conceptuelle en une dimension Oracle ayant le même nom préfixépar « _dim». La clause «When» permet de préciser que les tables ROLAP appropriées doiventêtre déjà transformées en vues matérialisées. Alors que, la clause «Where» montre que leshiérarchies, les paramètres et attributs faibles sont respectivement convertis en hiérarchies,niveaux et attributs Oracle.

5.2.2. Transformation des processus ETL

Au niveau physique, le modèle dépend d’une plateforme d’implantation, dans ce qui suit nousprésentons les règles de transformation des requêtes algébriques en requêtes SQL conforme àla plateforme Oracle 11g.

Relation «Requête algébrique en requête SQL». Cette relation montre la transformationdes opérations relationnelles du niveau logique relatives à une table relationnelle et à ses col-onnes en des clauses de la requête SQL permettant la définition de la vue matérialisée appro-priée. La clause «When» indique que les tables de dimension et de fait sont converties envues matérialisées. La clause «Where» présente les différentes relations de correspondanceentre les éléments d’une requête algébrique et les éléments d’une requête SQL.

Relation «Agrégation algébrique en agrégation SQL». Cette relation permet la transforma-tion de l’agrégation relationnelle à la clause correspondante du langage SQL: «Group By».L’attribut source «si» présente l’attribut agrégé du «Select» alors que l’attribut «rasj» présentel’attribut selon lequel se fait l’agrégation. Le prédicat présente une éventuelle condition défi-nie sur les attributs d’agrégation. Il est ainsi converti en une clause «Having» qui peut faireappel à une fonction SQL.

Figure 9. Relation «Main».

42 F. Atigui et al.

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13

Relation «Restriction algébrique en clause Where». Cette relation permet la transforma-tion de la restriction du niveau logique relationnel en un prédicat de la clause «Where». Lesdifférents éléments du prédicat relationnel sont transformés en leurs équivalents du prédicatSQL.

5.2.3. Transformation du modèle physique (PSM) en code

Le modèle physique (PSM) est généré en appliquant une succession de transformation demodèles vers modèles utilisant le langage QVT. Le code de création des vues matérialiséescompatible avec la plateforme Oracle 11g est généré en appliquant un ensemble de règles detransformation de modèle vers texte. Ceci se fait en utilisant le langage MOF-M2T standar-disé par l’OMG6. Ce dernier permet de générer automatiquement du code source en appli-quant les règles de transformation des éléments appartenant à un ou plusieurs modèle(s). Leprocessus de transformation d’un modèle en texte prend en entrée le modèle physique (PSM)exprimé selon la syntaxe Oracle 11g et fournit en sortie le ou les fichier(s) du code source(SQL) permettant la création et l’alimentation des structures de l’entrepôt (dimensions et vuesmatérialisées).

Exemple 3. Le code SQL présenté par la Figure 15 correspond au résultat de la transfor-mation du schéma en constellation des «Ventes» présenté dans l’exemple 1. Ce résultat estobtenu suite à une succession de transformation de modèles vers modèles permettant d’abou-tir au modèle physique (PSM) ainsi que des transformations de modèle vers texte permettantde convertir le PSM en code SQL.

6. Implantation

La Figure 16 présente l’architecture du prototype implanté. A partir d’un schéma multidimen-sionnel et des expressions ETL-OCL entrés par le concepteur, ce prototype permet de restituerle code SQL de création et d’alimentation de l’entrepôt de données. Pour ce faire l’ensemble

Figure 10. Relation de transformation de table dimension en vue matérialisée.

Journal of Decision Systems 43

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13

des règles de transformation de modèles vers modèles (QVT) et de modèles vers texte (MOFM2T) sont implantés au préalable. Ces transformations font appel à un ensemble de méta-modèles stockés en amont sous forme de fichier «Ecore». Les étapes suivantes présententl’ordre de création des différents composants du système:

Figure 11. Relation dimension multidimensionnelle en dimension Oracle.

Figure 12. Relation de transformation des requêtes algébriques en requêtes SQL.

44 F. Atigui et al.

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13

• Etape 1: création des méta-modèles unifiés (structure et processus) sous forme defichier ‘Ecore’:a Métamodèle conceptuel des structures multidimensionnelles et des expressions

ETL-OCL.b Métamodèle logique des structures relationnelles et des expressions algébriques.c Métamodèle physique des structures physiques Oracle (vues matérialisées) et des

requêtes SQL.

• Etape 2: création des règles de transformation de modèles vers modèles (QVT text-uel):a Règles de transformation du modèle conceptuel en modèle logique: des structures

MD et des expressions ETL-OCL vers les structures relationnelles et les expres-sions algébriques.

b Règles de fusion des modèles conceptuel et logique en modèle physique: des struc-tures relationnelles et des expressions algébriques vers les structures Oracle, et desdimensions et hiérarchies conceptuelles vers les dimensions Oracle.

Figure 13. Relation de transformation de l’agrégation relationnelle en agrégation SQL.

Figure 14. Relation de transformation des restrictions algébriques en prédicats de la clause «Where».

Journal of Decision Systems 45

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13

• Etape 3: Création des règles de transformation de modèles vers texte (MOF M2T)’:du modèle physique Oracle vers le code SQL.

Les règles de transformation et de fusion de modèles ont été implantées en utilisant Medi-ni-QVT7. Ce dernier est un plug-in Eclipse8 qui permet d’implanter les règles de transforma-tion modèles-à-modèles en utilisant la syntaxe textuelle de QVT. L’ensemble de règles detransformation de modèle-vers-texte est exécuté en utilisant le plugin Eclipse MOFScript quipermet d’implanter les règles de transformation modèles-vers-texte en utilisant le langageMOF M2T.

Figure 15. Extrait du code SQL de création de d’alimentation d’ED MD (Oracle 11g).

46 F. Atigui et al.

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13

Le concepteur utilise le métamodèle conceptuel pour (1) créer une instance duschéma MD et des expressions ETL-OCL sous forme d’un fichier XMI9, l’entrée du système,«Ventes.xmi» qui correspond à l’exemple 1 présenté précédemment. Ensuite, ce modèle (2)est transformé en un modèle logique relationnel: le schéma relationnel qui correspond auschéma conceptuel des ventes et aux expressions ETL-OCL (Schéma ROLAP_Ventes.xmi).Par la suite, les deux modèles conceptuel et logique (3) sont fusionnés pour aboutir aumodèle physique Oracle. Enfin, ce dernier (4) est converti au code SQL en appliquant unensemble de règles MOF M2T pour être restitué au concepteur.

7. Conclusion

Dans cet article nous avons présenté une approche dirigée par les modèles pour la conceptionet le développement conjoint des ED et des processus ETL. L’utilisation d’une approcheMDA permet de générer les modèles logique et physique de manière automatique. En effet,chaque phase de modélisation (analyse des exigences, modélisation conceptuelle, logique etphysique) est décrite par un ou plusieurs modèles. La démarche applique une série de trans-formations en vue de générer automatiquement le code final. Nous avons présenté le modèleconceptuel unifié qui réutilise et adapte les schémas en constellation et le langage OCL. Ensu-ite, nous avons détaillé les règles QVT permettant de transformer les PIMs conceptuel et logi-ques en PSM. Par ailleurs, nous avons implanté les transformations modèle-à-modèleformalisées en syntaxe textuelle de QVT en utilisant MediniQVT. Nous avons utilisé le lan-gage MOF-M2T pour transformer le dernier modèle (PSM) en code SQL.

Dans les futurs travaux, nous envisageons, dans un premier temps, de travailler les phasesamont aux processus présentés dans cet article. Plus particulièrement nous aborderons la for-malisation des exigences (CIM) et de transition entre le CIM et le PIM conceptuel en utilisantun ensemble de règles QVT. Dans un second temps, nous aborderons un ensemble d’exten-sions relatif aux processus présenté dans cet article. Notamment, nous traiterons la prise encompte de plusieurs sources en adaptant les processus ETL avec des espaces de stockageintermédiaires pour écrire les requêtes de traitement.

Figure 16. Architecture du prototype.

Journal of Decision Systems 47

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13

Nous avons l’intention de développer l’outil via une interface graphique qui permet auconcepteur de saisir l’entrée du système. Nous envisageons également d’étendre notre méth-ode en considérant d’autres plates-formes de déploiement. En outre, nous envisageonsd’appliquer l’approche sur des cas d’études du monde réel et de l’évaluer par différents utilis-ateurs (consultants dans une société de service).

Notes1. http://www.omg.org/cgi-bin/doc?omg/03-06-012. http://www.omg.org/spec/OCL/2.2/PDF3. Common Warehouse Metamodel: http://www.omg.org/spec/CWM/4. http://www.omg.org/spec/QVT/1.1/PDF/5. Relational On Line Analytical Processing6. http://www.omg.org/spec/MOFM2T/1.0/PDF7. http://projects.ikv.de/qvt8. http://www.eclipse.org/9. XMI: XML MetadataInterchange: standard créé par l’OMG pour l’échange d’information de méta-

données UML basé sur XML

RéférencesAtigui, F., Ravat, F., Teste, O., et Zurfluh, G. (2010), «Démarche dirigée par les modèles pour la con-

ception d’entrepôts de données multidimensionnelles», 26ème journées des Bases de Données Avan-cées (BDA).

Atigui, F., Ravat, F., Tournier, T., et Zurfluh, G. (2011), «A Unified Model Driven Methodology forData Warehouses and ETL Design», in International Conference on Enterprise Information Systems(ICEIS), 1, 247–252.

Barateiro, J., et Galhardas, H. (2005), «A Survey of Data Quality Tools», Datenbank-Spektrum, 14, 15–21.

Bejaoui, L., Pinet, F., Schneider, M., et Bédard, Y. (2010), «OCL for Formal Modelling of TopologicalConstraints Involving Regions with Broad Boundaries», GeoInformatica, 14, 353–378.

Blanc, X., et Salvatori, O. (2005), MDA en action: Ingénierie logicielle guidée par les modèles, Paris:Eyrolles éditions.

Carmè, A., Mazón, J.-N., et Rizzi S. (2010), «A Model-Driven Heuristic Approach for Detecting Multi-dimensional Facts in Relational Data Sources», in International Conference on Data Warehousingand Knowledge Discovery (DaWak), pp. 13–24.

El Akkaoui, Z.E., et Zimányi, E. (2009), «Defining ETL Workflows using BPMN and BPEL», in Inter-national Workshop on Data Warehousing and OLAP, pp. 41–48.

Essaidi, M., et Osmani, A. (2009), «Data Warehouse Development Using MDA and 2TUP», in Interna-tional Conference on Software Engineering and Data Engineering (SEDE), pp. 138–143.

Golfarelli, M., Maio, D., et Rizzi, S. (1998), «The Dimensional Fact Model: A Conceptual Model forData Warehouses», International Journal of Cooperative Information Systems, 7, 215–247.

Golfarelli, M., et Rizzi, S. (1998), «Methodological Framework for Data Warehouse Design», in Inter-national Workshop on Data Warehousing and OLAP, pp. 3–9.

Hüsemann, B., Lechtenbörger, J., et Vossen, G. (2000), «Conceptual Data Warehouse Modeling», inInternational Workshop on Design and Management of Data Warehouses (DMDW), pp. 3–9.

Kimball, R. (1996), The Data Warehouse Toolkit: Practical Techniques for Building Dimensional DataWarehouses, New York: John Wiley & Sons, Inc.

Kleppe, A.G., Warmer, J., et Bast, W. (2003), MDA Explained: The Model Driven Architecture: Practiceand Promise, Boston: Addison-Wesley Longman Publishing Company Inc.

Luján-Mora, S., Vassiliadis, P., et Trujillo J. (2004), «Data Mapping Diagrams for Data WarehouseDesign with UML», in International Conference on Conceptual Modeling, (ER), pp. 191–204.

Mazón, J.-N., et Trujillo, J. (2008), «An MDA Approach for the Development of Data Warehouses»,Decision Support Systems, 45, 41–58.

Mazón, J.-N., et Trujillo, J. (2009), «A Hybrid Model Driven Development Framework for the Multidi-mensional Modeling of DW», SIGMOD Rec., 38, 12–17.

48 F. Atigui et al.

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13

Muñoz, L., Mazón, J.-N., Pardillo, J., et Trujillo, J. (2008), «Modelling ETL Processes of DataWare-houses with UML Activity Diagrams», in On the Move to Meaningful Internet Systems Workshops,(OTM), pp. 44–53.

Muñoz, L., Mazón, J.-N., et Trujillo, J. (2009), «Automatic Generation of ETL Processes from Concep-tual Models», in International Workshop on Data Warehousing and OLAP, pp. 33–40.

Pardillo, J., Mazón, J.-N., et Trujillo, J. (2010), «Extending OCL for OLAP Querying on ConceptualMultidimensional Models of Data Warehouses», Information Sciences, 180(5), 584–601.

Prat, N., Akoka, J., et Comyn-Wattiau, I. (2006), «A UML-based Data Warehouse Design Method»,Decision Support Systems, 42, 1449–1473.

Ravat, F., Teste, O., Tournier, R., et Zurfluh, G. (2008), «Algebraic and Graphic Languages for OLAPManipulations», International Journal of Data Warehousing and Mining, 4, 17–46.

Rizzi, S., Abelló, A., Lechtenbörger, J., et Trujillo, J. (2006), «Research in Data Warehouse Modelingand Design: Dead or Alive?», in International Workshop on Data Warehousing and OLAP, pp. 3–10.

Romero, O., et Abelló, A. (2009), «A Survey of Multidimensional Modeling Methodologies», Interna-tional Journal of Data Warehousing and Mining, 5, 1–23.

Romero, O., et Abelló, A. (2010), «Automatic Validation of Requirements to Support MultidimensionalDesign», Data & Knowledge Engineering, 69, 917–942.

Sen, A., et Sinha, A.P. (2005), «A Comparison of Data Warehousing Methodologies», Communicationsof the ACM, 48, 79–84.

Simitsis, A., Skoutas, D., et Castellanos, M. (2010), «Representation of Conceptual ETL Designs in Nat-ural Language Using Semantic Web Technology», Data & Knowledge Engineering, 69, 96–115.

Simitsis, A., et Vassiliadis, P. (2003), «A Methodology for the Conceptual Modeling of ETL Processes»,in International Conference on Advanced Information System Engineering (CAiSE) Workshops.

Trujillo, J., et Luján-Mora, S. (2003), «A UML Based Approach for Modeling ETL Processes in DataWarehouses», in International Conference on Conceptual Modeling, (ER), pp. 307–320.

Tsois, A., Karayannidis, N., et Sellis, T.K. (2001), «MAC: Conceptual Data Modeling for OLAP», inInternational Workshop on Design and Management of Data Warehouses (DMDW), p. 5.

Vassiliadis, P. (2009), «A Survey of Extract-Transform-Load Technology», International Journal of DataWarehousing and Mining, 5, 1–27.

Warmer, J., et Kleppe, A. (2003), The Object Constraint Language: Getting Your Models Ready forMDA (2nd ed.), Boston: Addison-Wesley Longman Publishing Co.

Zepeda, L., Celma, M., et Zatarain, R. (2008), «A Mixed Approach for Data Warehouse ConceptualDesign with MDA», Computational Science and Its Applications ICCSA, 2, 1204–1217.

Journal of Decision Systems 49

Dow

nloa

ded

by [

The

Uni

vers

ity o

f B

ritis

h C

olum

bia]

at 1

1:41

19

Apr

il 20

13