une démarche et un outil

This article was downloaded by: [Dokuz Eylul University ]On: 05 November 2014, At: 20:10Publisher: Taylor & FrancisInforma Ltd Registered in England and Wales Registered Number: 1072954 Registered office: MortimerHouse, 37-41 Mortimer Street, London W1T 3JH, UK

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

Une démarche et un outilJamel Feki a & Yasser Hachaichi aa Laboratoire MIRACL , Faculté des Sciences Economiques et de Gestion de Sfax , Routede l’Aérodrome km 4, B.P. 1088, 3018 , Sfax , TunisiePublished online: 18 Apr 2012.

To cite this article: Jamel Feki & Yasser Hachaichi (2007) Une démarche et un outil, Journal of Decision Systems, 16:3,303-333, DOI: 10.3166/jds.16.303-333

To link to this article: http://dx.doi.org/10.3166/jds.16.303-333

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all the information (the “Content”) containedin the publications on our platform. However, Taylor & Francis, our agents, and our licensors make norepresentations or warranties whatsoever as to the accuracy, completeness, or suitability for any purpose ofthe Content. Any opinions and views expressed in this publication are the opinions and views of the authors,and are not the views of or endorsed by Taylor & Francis. The accuracy of the Content should not be reliedupon and should be independently verified with primary sources of information. Taylor and Francis shallnot be liable for any losses, actions, claims, proceedings, demands, costs, expenses, damages, and otherliabilities whatsoever or howsoever caused arising directly or indirectly in connection with, in relation to orarising out of the use of the Content.

This article may be used for research, teaching, and private study purposes. Any substantial or systematicreproduction, redistribution, reselling, loan, sub-licensing, systematic supply, or distribution in anyform to anyone is expressly forbidden. Terms & Conditions of access and use can be found at http://www.tandfonline.com/page/terms-and-conditions

http://www.tandfonline.com/loi/tjds20

http://www.tandfonline.com/action/showCitFormats?doi=10.3166/jds.16.303-333

http://dx.doi.org/10.3166/jds.16.303-333

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

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

Journal of Decision Systems. Volume 16 – No. 3/2007, pages 303 à 333

Conception assistée de MDUne démarche et un outil

Jamel Feki — Yasser Hachaichi

Laboratoire MIRACLFaculté des Sciences Economiques et de Gestion de SfaxRoute de l’Aérodrome km 4, B.P. 1088, 3018 Sfax, [email protected]@yahoo.fr

RÉSUMÉ. Pour assister le concepteur décisionnel dans la construction des schémas demagasins de données en étoile à partir d’une source de données relationnelle, nousproposons une démarche et un outil indépendants de la sémantique de tout systèmed’information source. Notre démarche procède à une classification des relations en relation-entité et relation-association et, se base sur la sémantique structurelle des relationsdisséminée à travers les clés primaires et contraintes référentielles. Elle extrait, par le biaisd’un ensemble d’heuristiques appropriées, des faits, des dimensions et des hiérarchies, et lesclasse par niveau de pertinence. Un outil logiciel baptisé CAME (Construction assistée deschémas de magasins de données en étoile) est développé pour supporter la démarcheproposée.ABSTRACT. To assist the decisional designer in building data mart star schemes relying on arelational data source, we propose an approach supported by a tool. Our approach isindependent of the semantic of any source information system; it classifies the relations in R-entities and R-associations and, is based on the structural semantics of the relations which isdisseminated through the primary keys and referential constraints. This approach extractsfacts, dimensions and hierarchies using a set of appropriate heuristics. A software toolbaptized CAME is developed to support our proposed method; it constructs automatically starscheme data marts.MOTS-CLÉS : conception assistée, magasins de données, schéma en étoile, source relationnelle,système d’aide à la décision.KEYWORDS: Computer Aided Design, Data Mart, Star Schema, Relational Data Source,Decision Support System.

DOI:10.3166/JDS.16.303-333 2007 Lavoisier, Paris

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14

304 Journal of Decision Systems. Volume 16 – No. 3/2007

1. Introduction

Un système d’information décisionnel (SID) a pour fonction première de faciliterla prise de décisions stratégiques. Il extrait les données utiles à la prise de décision àpartir de sources internes (base opérationnelle de l’entreprise) et externes (bases destiers…) et, les organise en deux espaces de stockage : l’entrepôt de données (ED)regroupant toute l’information décisionnelle et les magasins de données (MD).Chaque MD est un extrait de l’entrepôt ; c’est une base de données décisionnellestructurée en fonction d’un métier précis ou d’un usage particulier. L’information yest préparée sous une forme adaptée, dite multidimensionnelle, pour être directementet facilement accessible par les décideurs (applications OLAP « On Line AnalyticalProcessing » ou fouille de données « data mining »). Parfois, l’architecture du SIDest réduite à des MD qui seront dits indépendants car ils sont alimentés directementà partir de la source. Cette architecture simplifiée convient pour des petitesentreprises qui souhaitent réduire les coûts de leur projet décisionnel, réduire lesdélais de réalisation, etc.

Habituellement, la modélisation d’un ED/MD s’effectue à trois niveauxd’abstraction (Calvanese et al., 2006) :

– le niveau conceptuel qui correspond à une représentation conceptuelle desdonnées à incorporer dans l’ED,

– le niveau logique qui fournit une représentation en termes de modèle logiquedes données stockées dans l’ED et,

– le niveau physique qui détaille les spécifications des données stockées et lesmédiateurs pour charger le MD.

Dans cet article nous nous intéressons à la modélisation conceptuelle etparticulièrement à son automatisation. En effet, nous développons un environnementde construction assistée de schéma de MD en étoile à partir d’une source OLTP(« On-Line Transaction Processing ») relationnelle. Pour cet environnement i) nousprésentons une démarche basée sur des heuristiques d’extraction des conceptsmultidimensionnels pour construire des schémas de MD en étoile et ii) nousdéveloppons un outil logiciel appelé CAME (Conception assistée de magasin dedonnées en étoile) qui supporte notre démarche.

Le présent article est organisé en cinq sections. La section 2 étudie l’état de l’artdes méthodes de conception de MD et établit le bilan, ensuite elle explicite lesmotivations de cette recherche et enfin, décrit brièvement notre démarche deconstruction de schéma de MD. La section 3 détaille notre démarche : définit laclasse conceptuelle d’une relation, nos heuristiques d’extraction de conceptsmultidimensionnels et, introduit un exemple de schéma relationnel pour lesillustrations. La section 4 présente notre outil logiciel CAME (Conception assistéede magasin de données en étoile) d’aide à la conception de schémas de MD, décritses fonctionnalités et évalue ses résultats. Finalement, et en guise de conclusion, la

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14

Conception assistée de MD 305

section 5 établit le bilan des résultats obtenus et énumère quelques perspectives denos travaux futurs.

2. Etat de l’art, motivations et proposition

Dans la littérature des SID, il existe trois approches principales de conception deMD : descendante, ascendante et mixte. Une approche par réutilisation de patronsmultidimensionnels est récemment proposée dans (Feki et al., 2006a).

2.1. Etat de l’art et motivations

L’approche descendante (« Top-Down ») : initialement proposée dans (Kimball,1997 ; Kimball et al., 2005) où l’auteur se base sur l’étude des besoins analytiquesexprimés par les futurs utilisateurs décisionnels pour construire un ensemble deschémas de MD. Malheureusement, les schémas construits sont fortement liés auxbesoins collectés qui risquent d’être incomplets ou qui peuvent évoluer avec letemps.

L’approche ascendante (« Bottom-Up ») : construit des schémas de MD en sebasant sur le modèle informatique du système d’information (SI) de l’entreprise. Leconcepteur peut donc bénéficier des relations existantes entre les entités et suivreune méthode plus structurée pour concevoir la base de données décisionnelle. Cetype d’approche a été adopté dans (Golfarelli et al., 1998a ; Cabbibo et Torlone,1998 ; Moody et Kortink, 2000 et Husemann et al., 2000). Malgré que les auteurs decette approche ont suivi des démarches différentes pour construire les MD nousconstatons qu’ils partent tous d’une source E/A.

L’approche mixte (« Mixed ») : combine les deux approches précédentes pourbénéficier de leurs avantages. Elle a été d’abord adoptée par (Böhnlein et al., 1999)qui construit un modèle entité relation structuré (SERM) (Sinz, 1992) à partir d’undiagramme E/A. Ce modèle identifie les dimensions et les hiérarchies associées à unfait déduit suite à une étude des besoins analytiques et des objectifs. Ensuite, adoptépar Phipps et Davis (2002) qui appliquent un algorithme de génération partant dumodèle de données E/A de l’entreprise pour produire des schémas de MD candidats.Pour déterminer les solutions qui satisfont au mieux les besoins des décideurs, cesschémas candidats sont ensuite évalués en se basant sur des requêtes décisionnellestypes. Cette approche est également adoptée par Bonifati et al. (2001) qui effectuentune analyse descendante et une analyse ascendante suivie d’une intégration. Elle estaussi reprise par (Soussi et al., 2005) qui génèrent des schémas idéaux par fusion debesoins analytiques puis valide ces schémas idéaux obtenus par projection sur unesource d’alimentation relationnelle. La méthode de (Prat et al., 2006) se base surUML pour modéliser les trois niveaux conceptuels, logiques et physiques et, définitdes transformations entre ces niveaux. Elle collecte les besoins des décideurs, les

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


représente sous forme de digramme de classes UML qu’elle enrichie pour concevoirles structures décisionnelles. Ces structures seront confrontées avec la source pourgarantir ultérieurement leur chargement.

L’approche par réutilisation de patrons multidimensionnels se situe dans ledomaine de l’ingénierie des besoins décisionnels. Selon ses auteurs (Feki et al.,2006 ; Ben-Abdalah et al., 2006 ; Feki et Ben-Abdallah, 2007), « Un patronmultidimensionnel est un schéma en étoile type complet et générique, dans undomaine d’activité de l’entreprise, construit à partir d’entités standard du monde réel(e.g. facture, fiche client, etc.) ». Ce schéma est réutilisé en deux phases :i) instanciation logique où l’utilisateur décisionnel adapte le patron à ses besoins(opérations pruning, cut-back, etc.) puis associe les entités du patron à celles du SIde son entreprise pour dériver un schéma de MD exprimant ses besoins propres ;ii) instanciation physique effectuée par le concepteur décisionnel et permettent unmapping du schéma dérivé avec les tables du SI cible.

Le bilan de l’état de l’art dégage les constatations suivantes :– les approches descendantes et mixtes produisent des schémas candidats qui

répondent aux besoins exprimés par les utilisateurs décisionnels ; néanmoins, ellesprésentent en pratique quelques problèmes : d’une part, elles exigent du concepteurdécisionnel une compétence en SI opérationnel (pour comprendre les relations entreles données de la source) et d’autres part, elles sont difficilement automatisables. Eneffet, ces approches sont présentées à travers des exemples au lieu de procéduresexplicites de conception ;

– les approches ascendantes actuelles, bien qu’elles soient automatisables, sebasent sur des diagrammes E/A que les entreprises ne disposent pas toujours ou desversions obsolètes ;

– ces dernières approches considèrent que les schémas candidats construits sontéquipertinents alors que certains sont peu utiles à la prise de décision ;

– Aucune des approches ne définit un ensemble de transformations formellespour : i) dériver automatiquement et univoquement les représentations logiquespossibles d’un modèle conceptuel de MD développé ; ou ii) aider le concepteur àsélectionner la plus appropriée (Mazón et al., 2006) ;

– les dimensions se construisent à partir d’entités et parfois sur les attributstemporels (Golfarelli et al., 1998a ; Cabibbo et al., 1998 ; Moody et al., 2000,Soussi et al., 2005), or nous montrons que nous pouvons aussi les construire sur desattributs ;

– les faits se construisent principalement sur les associations n-aire (Kimball,1997 ; Golfarelli et al., 1998a ; Cabibbo et al., 1998 ; Soussi et al., 2005) etrarement sur des entités (Moody et al., 2000 ; Bonifati et al., 2001) et (Phipps et al.,2002).

D’autre part, à travers notre examen des travaux de la littérature nous confirmonsl’hypothèse de construction des faits à partir d’association et nous constatons que les

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


entités ayant générées des faits sont réellement des associations ; en effet, leformalisme E/A permet de représenter une association par le symbole d’entité quandelle possède un identifiant (différent de la concaténation des clés de ses entitésliées). Le tableau 1 donne, pour quelques exemples de faits, l’origine conceptuelle.Notons que dans (Golfarelli et al., 1998a) l’entité ADMISSION (tableau 1, ligne 4)est en réalité une association entre les entités DIAGNOSIS, WARD, D.R.G. etPHYSICIAN ; mais du fait qu’elle possède un identifiant (numéro séquentiel) elle aété modélisée comme entité.

Source E/A Fait extrait et validé Représentationconceptuelle

Activité commerciale(Golfarelli et al., 1998b) VENTE Association ternaire

ENCADREMENT Association quaternaireRépartition des charges desEnseignants (Soussi et al., 2005) ENSEIGNEMENT Association quaternaire

« Flight reservation system »(Böhnlein et al., 1999) “BOOKING” Association binaire

« Hospital »(Golfarelli et al., 1998a) “ADMISSION” Entité1

Tableau 1. Origines des faits extraits de sources E/A

Tenant compte des insuffisances citées dans ce bilan, nous proposons unedémarche ascendante de construction de schéma de MD partant du schéma logiqued’une base de données relationnelle. En fait, le schéma logique d’une sourceopérationnelle est toujours accessible par interrogation du référentiel du SGBD cequi permet de contourner les problèmes d’absence de la documentation classique(i.e. diagramme E/A) et essentiellement de son obsolescence. Par ailleurs, nousoptons pour le relationnel parce qu’il constitue le noyau fondamental pourla majorité des systèmes OLTP.

2.2. Présentation de notre approche

Pour atteindre notre objectif de construction quasi automatique de schémas deMD candidats à partir d’une source de données relationnelle nous comptonsexploiter au mieux la « sémantique structurelle des relations » disséminéeessentiellement dans les définitions des clés primaires et contraintes référentielles.Nous proposons alors une démarche qui adhère aux points suivants : 1. Association conceptuellement représentée sous forme d’entité.

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


– est indépendante de la sémantique du SI et de celle de son schéma dans lamesure où aucune signification des relations, ni de leurs attributs ou des liens inter-relations n’est nécessaire,

– se base sur une distinction des relations du SI en : relation-entité et relation-association décrivant respectivement des entités et des associations ; ceci nous aconduit à examiner minutieusement les structures des relations (cf. section 4.1),

– exploite les liens structurels interrelations exprimés par les clés primaires et lescontraintes référentielles,

– distingue les concepts multidimensionnels en affectant à chacun un degré depertinence,

– assiste le concepteur décisionnel.

Notre démarche se compose de trois étapes i) Pré-construction, ii) Constructionsdes schémas de MD, et iii) Validation. La figure 1 illustre l’enchaînement de cesétapes détaillées ci-après.

Figure 1. Approche quasi automatique de construction de schéma de MD

Pré-construction. C’est une étape de préparation à la construction des schémasde MD. Elle extrait le schéma de la source (noms des tables, noms des colonnes etleur type, contraintes de clés primaires et référentielles) à partir du dictionnaire duSGBD. Aussi, elle attribue à chaque relation sa classe conceptuelle (entité ouassociation) ; ceci optimise ultérieurement le processus d’identification des faits etdes dimensions. La pré-construction est présentée à travers la description de notreoutil CAME (cf. section 4).

Construction automatique des schémas de MD. Cette étape extrait lesconcepts multidimensionnels (i.e., faits et leurs mesures ainsi que les dimensionsavec leurs attributs organisés en hiérarchies) dans les relations classées puis,construit des schémas de MD candidats. Pour cela, nous définissons pour chaqueconcept un ensemble de règles d’extraction. Nos règles associent à chaque conceptextrait sa relation source et tiennent compte de la finesse (i.e. dépendance des

Pré-construction Construction des schémas de MD Validation

Concepteur décisionnel

ENSEIGNEMENT_ASSURE

NBR_GRP_ENSNBRE_GRPVOL_HOR_ENS_MATNBRE_ETUDVOL_HOR_MATNUM_TEL_F (ENSEIGNANT)NUM_TEL_M (ENSEIGNANT)

ENSEIGNANTCOD_ENS

NOM_ENSPRE_ENS

TYP_ENS

E_MAIL

GRAD_ENSMATIERE

COD_AUDCOD_MATCOD_SEC

INT_SEC

INT_AUD

NUM_CYC

INT_MAT

DCS AN_UNIVAN_UNIV

DCS NAT_ENSMTNAT_ENSMT

DCS NUM_SEMNUM_SEM

ENSEIGNEMENT_ASSURE


ENSEIGNANTCOD_ENS

NOM_ENS

PRE_ENSTYP_ENS

E_MAIL

GRAD_ENSMATIERE


INT_SEC

INT_AUD

NUM_CYC

INT_MAT

DCS AN_UNIVAN_UNIV


DCS NUM_SEMNUM_SEM

MD candidats

Sourcerelationnelle

Interventions optionnelles

Enchaînement automatique

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


mesures par rapport aux dimensions) des attributs identifiés comme mesurescandidates. L’association concept-source prépare le passage vers le niveau logiqueen garantissant la faisabilité des opérations ultérieures de mapping et de chargement.Également, notre méthode a le mérite d’agréger les mesures lorsque ces dernièressont enregistrées de façon plus détaillée dans le système opérationnel que dans leurfait (cf. section 3).

Validation. C’est une étape où le concepteur peut intervenir pour valider lesschémas en étoile candidats construits, c’est-à-dire, adapter ces schémas candidatsaux besoins analytiques du système de pilotage (e.g. supprimer ou renommer desschémas, des éléments… tout en préservant l’origine de l’élément dans la source).

La section suivante est réservée à la génération automatique de schémas de MD,c’est-à-dire, aux deux premières étapes de notre démarche : la pré-construction et laconstruction.

3. Génération automatique de schémas de MD en étoiles

A partir d’une source relationnelle, cette génération construit des schémas deMD candidats présentés par niveau de pertinence ; ensuite, le concepteur du SIDpourra les adapter. Cette génération nécessite l’identification de la classeconceptuelle de chaque relation.

3.1. Identification de la classe conceptuelle d’une relation source

Durant l’extraction du schéma relationnel (structures des relations, contraintes declés primaires et étrangères) de la source depuis la méta-base du SGBD nousidentifions la classe conceptuelle de chacune de ses relations.

Classe conceptuelle d’une relation. Rappelons que dans la littérature de laconception multidimensionnelle, les dimensions se construisent à partir d’entités (oud’attributs temporels) alors que les faits se construisent principalement sur lesassociations n-aire et rarement sur des entités matérialisant réellement desassociations (cf. section 2.1 et tableau 1).

Puisque notre démarche est guidée par une source relationnelle d’une part, et queen relationnel « tout est relation » d’autre part, il se pose alors le problème dedéterminer la classe conceptuelle d’une relation c’est-à-dire de savoir si une relationdécrit une entité (pour en déduire une dimension) ou une association (pour enconstruire un fait). La détermination de la classe conceptuelle nous a amené àeffectuer un examen des structures des relations et notamment de leurs clés pourrépartir l’ensemble S des relations d’un SI en deux sous-ensembles :

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


– Sa : les relations de S décrivant des associations ; nous les appelons relation-association (R-a). En général, une relation-association est reconnue par sa cléprimaire composée d’au moins une clé étrangère ;

– Se : les relations de S décrivant des entités ; nous les appelons relation-entité(R-e). En général, une relation-entité est reconnue par sa clé primaire ne contenantaucune clé étrangère.

Naturellement, la qualité du résultat de l’étape de construction dépendra de laqualité de cette classification, c’est-à-dire, de la bonne formation des deux sous-ensembles Sa et Se qui doivent vérifier les trois propriétés suivantes :

– Disjonction : Sa ∩ Se= ∅ ; aucune relation ne peut avoir le double rôled’entité et d’association,

– Complétude : Sa ∪ Se = S ; toute relation doit être classée, exclusivemententité ou association,

– Exactitude : ∀ sa ∈ Sa, sa n’est pas une entité et, ∀ se ∈ Se, se n’est pas uneassociation ; toute relation doit être correctement classée.

Pratiquement, la propriété d’exactitude n’est pas garantie lorsque la clé primaired’une association :

a) n’est pas la concaténation de ses clés étrangères ; cette clé primaire peut êtreun attribut artificiel tel qu’un numéro séquentiel (e.g. l’association ADMISSION dutableau 1), ou

b) est la concaténation d’attributs venant d’entités vides : Ces attributs ne sontpas des clés étrangères puisqu’une entité vide ne se transforme pas en une relation.Pour ce cas nous avons traité un exemple détaillé que le lecteur intéressé pourratrouvé dans Hachaichi et Fekin (2007).

Dans notre approche nous proposons d’identifier automatiquement la classeconceptuelle d’une relation. Dans les deux situations (a) et (b), une relationassociation sera incorrectement identifiée comme relation-entité. Pour pallier à cetteinexactitude, notre approche i) construit aussi des faits sur des entités et lesconsidère moins pertinents, et ii) permet au concepteur de rectifier la classeconceptuelle d’une relation, identifiée automatiquement comme entité, de R-e à R-a.

En fait, pour la situation (a) la règle suivante peut assister le concepteur : « Sipour une relation r ∈ Se une clé candidate, un index unique ou une contrainte uniqueest définissable sur ses clés étrangères alors r est une association ».

Afin d’illustrer notre démarche, nous l’appliquons au schéma relationnel degestion de crédits bancaires. Ce schéma décrit les données relatives aux opérationsfinancières d’évolution des paramètres de crédits ainsi que l’étude et le suivi desprojets et de leur résultat d’exploitation. Dans cet article nous utilisons un extrait dece schéma (figure 2) où Les clés primaires sont soulignées et pour chaque cléétrangère la relation référencée est reportée en gras. Les indices N, C et T des attributsdésignent respectivement les types numérique, textuel et temporel.

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


La colonne gauche de la figure 2, indique la classe conceptuelle (R-a, R-e)affectée à chaque relation de ce schéma.

R-e GOUVERNORAT (COD_GOUVERN, LIB_GOUVER

C)

R-e NATURE (COD_NATN, LIB_NAT

C)

R-e SECTEUR (NUM_SEC_ACTN, LIB_SEC_ACT

C)

R-e CATEG_CLI (COD_CATEGN, LIB_CATEG

C)

R-e TYP_CL (NUM_TYPN, LIB_TYP

C)

R-e DELEGATION (COD_DELEGN, LIB_DELEG

C, COD_GOUVER

N :

GOUVERNORAT)

R-e CLIENT (NUM_CLIN, NOM_CLI

C, PRE_CLI

C, ADR_CLI

C, VILLE_CLI

T,

NUM_TELN, COD_PTT

N, NUM_TYP

N : TYPE_CL, NUM_SEC_ACT

N :

SECTEUR)

R-e COMPTE (NUM_CPTN, TYP_CPT

C, SOL_CPT

N, NUM_CLI

N:CLIENT)

R-e PROJET (COD_PROJN, FORM_JUR_PROJ

C, LIEU_PROJ

C, NUM_REG_COM

N,

EFFECT_SALN, POURC_CH_SC

N, SAL_MOY

N, MTT_INVEST

N, MAT_FISC

N,

DAT_DEB_ETUDT, DAT_LANC_REALIT, DAT_LANC_PRODUCTT,COD_NAT

N : NATURE, NUM_SEC_ACT

N : SECTEUR, COD_DELEG

N :

DELEGATION, NUM_CLIN : CLIENT)

R-e CREDIT (REF_CREN, MT_CRE_ACC

N, DAT_SIGT, DUREE

N, NBR_TRN,

DAT_DEB_VERT, TAUX_INTN, NUM_CPT

N : COMPTE, DAT_DEM_CRET,

DAT_ACCT)

R-a REMBOURSEMENT (REF_CREN : CREDIT, DAT_REMBT, MT_REMB

N,

JOUR_VAL_RETN)

R-a REMB_ECH (REF_CREDITN : CREDIT, DAT_REMBT, DAT_ECHT,

MT_INT_REMBN, MT_PRINC_REMB

N)

R-a INT_RETARD (REF_CREN : CREDIT, DAT_INT_RETT, MT_INT_RET

N,

JOUR_VAL_INT_RETN)

R-a REMB_RETARD (REF_CREN : CREDIT, DAT_REMT, DAT_INT_RETP,

MT_INT_RET_REMBN)

R-e TYPE_COMMISSION (COD_TYP_COMN, LIB_TYP_COMC, TAUX_COM

N)

R-a COMMISSON (COD_TYP_COMN : TYPE_COMMISSION, REF_CRE

N :

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


CREDIT, DAT_COMMT, MT_COMN)

R-a REM_COMM (REF_CREN : CREDIT, DAT_REMBT, COD_TYP_COM

N :

TYPE_COMMISSION, DAT_COMT, MT_COM_REMBN)

R-e RUBRIQUE_EVOL (NUM_RUBN, TYP_RUB)

R-e SOUS_RUBRIQUE_EVOL (NUM_SOUS_RUBN, TYP_SOUS_RUBC,

NUM_RUBN : RUBRIQUE_EVOL)

R-a EVOLUTION_CRE (REF_CREN : CREDIT, DAT_EVO_CREP, MT_RUB

N,

NUM_RUBN : RUBRIQUE_EVOL, NUM_SOUS_RUB

N :

SOUS_RUBRIQUE_EVOL)

R-a SUIVI_RES_EXP (COD_PRJ : PROJET, AN_SUIVI_RES_EXPN,ECA_RES_EXP

N, ECA_RES_NET

N, ECA_DEP

N, ECA_CA

N)

Figure 2. S1 extrait du schéma relationnel de la gestion de crédits bancaires

Une fois la classe conceptuelle de chaque relation est identifiée nous passons àl’extraction des concepts multidimensionnels en commençant par les faits.

3.2. Extraction des faits

Le fait représente un centre d’intérêt pour la prise de décision (Kimball, 1997 ;Golfarelli et al., 1998b ; Ravat et al., 1999). En effet, il modélise un sujet d’analysereprésentant un événement qui se produit au sein d’une organisation.

Pour extraire les faits, le critère de (Kimball, 1997 ; Bonifati et al., 2001),amélioré par (Soussi et al., 2005) construit un ensemble composé desreprésentations conceptuelles (entités ou associations) possédant au moins unattribut numérique non clé (primaire ou étrangère) et considère que les éléments decet ensemble sont tous équipertinents. Pour une source relationnelle, nousdéfinissons deux heuristiques (Hf1 et Hf2) qui construisent deux ensembles de faitsde deux niveaux de pertinence. La première identifie les faits issus des relation-associations et la deuxième identifie les faits issus des relation-entités.

Etant construits sur des associations, nous considérons que les faits obtenus parHf1 sont plus pertinents que ceux obtenus par Hf2 (cf. section 2.1). Cette distinction,absente dans la littérature, assiste le concepteur lors de la sélection des faits.

Hf1. Toute relation-association R contenant au moins un attribut numérique nonclé (primaire ou étrangère) est un fait candidat pertinent nommé R.

Hf2. Toute relation-entité R contenant au moins un attribut numérique non clé(primaire ou étrangère) est un fait candidat de faible pertinence nommé R.

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


Tout au long de cet article nous adoptons les notations suivantes pour formulernos règles d’extraction :

– S : une source relationnelle en troisième forme normale,– R : une relation appartenant à S,– ΩR : l’ensemble des attributs de R,– ΩR/NUM : le sous-ensemble des attributs numériques de ΩR,– ΩR/BOL : le sous-ensemble des attributs booléens de ΩR,– ΩR/TEM : le sous-ensemble des attributs temporels (date ou temps) de ΩR,– PkR : l’ensemble des attributs formant la clé primaire de R (PkR ⊆ ΩR) et,– FkR : l’ensemble des attributs clés étrangères de R (FkR ⊆ ΩR).

Formulation. Selon cette notation, les faits candidats extraits à partir de S sont :Hf1 détermine ( )( ) φ≠∪−Ω∈ RRNUMR FkPkSaR /:Hf2 détermine ( )( ) φ≠∪−Ω∈ RRNUMR FkPkSeR /:

Illustration. La figure 3 montre les faits candidats extraits de la source S1.

REMBOURCEMENT

REMB_ECH

INT_RETARD

REMB_RETARD

COMMISSON

REM_COMM

EVOLUTION_CRE

SUIVI_RES_EXP

CLIENT

COMPTE

CREDIT

PROJET

TYPE_COMMISSION

Faits pertinents (Hf1) Faits moins pertinents (Hf2)

Figure 3. Faits candidats extraits de la source S1 classés par niveau de pertinence

Pour poursuivre notre démarche, nous enchaînons l’extraction des faits par celledes mesures.

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


3.3. Extraction des mesures

Un fait comporte un nombre fini de mesures qui sont généralement des attributsnumériques. Ils proviennent de deux origines : d’une relation-fait2 ou de relationsparallèles3.

Extraction de mesures à partir d’une relation-fait. Ces mesures sont extraitespar l’heuristique suivante :

Hm1. Les attributs numériques non clés appartenant à une relation-fait F etn’appartenant pas à d’autres relations sont des mesures candidates pour F.

Nous écartons de l’ensemble des mesures candidates les clés car elles sont desinformations artificielles, redondantes qui ne tracent pas l’activité de l’entreprise.Egalement, nous écartons les attributs non clés de F appartenant à d’autres relationscar ils sont réellement des clés d’entités vides. Par exemple, si nous supposons queles relations REMBOURSEMENT, REMB_RETARD, REMB_COMM etREMB_ECH contiennent l’attribut numérique NAT_REM alors nous écartons cetattribut des mesures candidates du fait construit sur REMBOURSEMENT. En effet,dans ce cas NAT_REM représente la clé d’une entité vide(NATURE_REMBOURSEMENT).

Extraction de mesures à partir d’une relation-parallèle. Rappelons que dansun schéma E/A, les mesures peuvent provenir des associations parallèles (Soussi etal., 2005). Une association A1 m-aire est dite parallèle à une association A2 n-aire(m≤n) si et seulement si toutes les entités reliées par A1 sont aussi reliées par A2. Parexemple, dans la figure 4a, l’association COMMISSION est parallèle à l’associationREM_COMM.

Nous identifions une relation-association R1 parallèle à une autre relation-association R2 par le fait que l’ensemble des attributs de la clé primaire de R1 soitinclus ou égal à celui de R2 (PkR1 ⊆ PkR2). Par exemple, dans la figure 4-b larelation-association COMMISSION est parallèle à la relation-associationREM_COMM.

Soient R1 et R2 deux relation-faits. A travers l’heuristique Hm1 nous identifionsdes mesures dans R1 et dans R2. En outre, si R1 est parallèle à R2 alors le fait bâtisur R1 peut recevoir d’autres mesures provenant de R2 à condition de préserver leurdépendance par rapport aux dimensions de R1. Ainsi, si les dimensions de R1 sontincluses dans celles de R2 alors nous agrégeons les mesures de R2 avant de lesajouter à R1. Nous distinguons deux cas selon que ces deux ensembles dedimensions sont strictement inclus, ou égaux.

2. Relation-fait est une relation identifiée comme fait.3. Relation-parallèle est une relation transformée d'une association parallèle.

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


COMMISSON (COD_TYP_COM : TYPE_COMMISSION, REF_CRE :CREDIT, DAT_COMM, MT_COM)

REM_COMM (REF_CRE : CREDIT, DAT_REMB, COD_TYP_COM :TYPE_COMMISSION, DAT_COM, MT_COM_REMB)

Figure 4. Exemple d’associations parallèles et leur transformation en relationnel

Cas 1 : Dimension (R1) ⊂ Dimension (R2)

Pour ce cas, les mesures de R2 sont enregistrées dans la source de façon plusdétaillée que celles de R1 ; ainsi pour les ajouter à R1, ces mesures doivent êtreagrégées sur l’ensemble de dimensions Dimension (R2) - Dimension (R1), d’oùl’heuristique suivante :

Hm2.1. Si une relation-fait R1 de classe R-a est parallèle à une autre relation-faitde classe R2 et si l’ensemble des dimensions de R1 est strictement inclus dans celuide R2 alors les mesures déduites par Hm1 à partir de R2 s’ajoutent comme mesuresagrégées à R1.

Dans notre méthode, les mesures à agréger ainsi que les dimensions de leuragrégation sont automatiquement identifiées. Cependant, la fonction d’agrégation està la charge du concepteur puisque son choix dépend de la sémantique d’analyse.

Exemple. Dans la relation-fait REM_COMM, la mesure MT_COM_REMB estenregistrée par rapport à quatre variables : référence du crédit (REF_CRE), type decommission (COD_TYP_COMM), date de la commission (DAT_COMM) et date8du remboursement (DAT_REMB). Pour inclure cette mesure dans la relation-faitCOMMISSION (parallèle à REM_COM), il faut l’agréger sur la dimension date deremboursement (DCA_DAT_REMB) absente dans le fait COMMISSION.

Cas 2 : Dimension (R1) = Dimension (R2)

A égalité de dimensions, R1 est alors parallèle à R2 et réciproquement. Enconséquence, les mesures de R1 et de R2 ont le même niveau de détail. L’heuristiquesuivante illustre ce cas :

(a)

0,nDAT_REMB

0,nDAT_COM

0,n0,n

0,nDAT_COMM

0,n

0,nTYPE_COMMISSION

COD_TY P_COMLIB_TYP_COMTAUX_COM

CREDITREF_CREMT_CRE_ACCDUREE

DATEDATE

COMMISSIONMT_COM

REM_COMMMT_COM_REMB

...

(b)

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


Hm2.2. Si deux relation-faits R1 et R2 (de même classe Ra) sont parallèles etpossèdent les mêmes dimensions alors les mesures de R1 (respectivement de R2)extraites par Hm1 s’ajoutent à R2 (respectivement à R1).

Nous avons remarqué que les règles présentées génèrent des mesures avec undegré de pertinence décroissant à chaque fois qu’on s’éloigne de la relation-fait(application successive de Hm1 et (Hm2.1 ; Hm2.2)). Nous considérons alors queHm1 est plus pertinente que Hm2.1 et Hm2.2.

NOTE — Les relation-associations parallèles représentant des faits candidats peuventformer un bon schéma en constellation.

Fait Mesure extraite m Heuristique Formule d’extractionNUM_TELCLIENT COD_PTT Hm1 -

COMPTE SOL_CPT Hm1 -NUM_REG_COMPOURC_CH_SCEFFECT_SAL

SAL_MOYMTT_INVEST

PROJET

MAT_FISC

Hm1 -

MT_CRE_ACC -DUREE -

NBR_TR -CREDIT

TAUX_INT

Hm1

-MT_REMB -

JOUR_VAL_RET -MT_PRINC_REMB

MT_INT_REMB Agr(m, DCA_DAT_ECH)

MT_INT_RET_REMB Agr(m, DCA_DAT_INT_RET)REMBOURCEMENT

MT_COMM_REMB

Hm2.1Agr(m, TYPE_COMMISSION,

DCA_DAT_COMM)MT_PRINC_REMBREMB_ECH MT_INT_REMB HM1 -

MT_INT_RET -JOUR_VAL_INT_RET Hm1 -INT_RETARDMT_INT_RET_REMB Hm2.1 Agr(m, DCA_DAT_REMB)

REMB_RETARD MT_INT_RET_REMB Hm1 -TYPE_COMMISSION TAUX_COM Hm1 -

MT_COM Hm1 -COMMISSION MT_COMM_REMB Hm2.1 Agr(m, DCA_DAT_REMB,

DCA_DAT_COMM)REM_COMM MT_COMM_REMB Hm1 -

EVOLUTION_CRE MT_RUB Hm1 -ECA_RES_EXPECA_RES_NET

ECA_DEPSUIVI_RES_EXP

ECA_CA

Hm1 -

Tableau 2. Mesures extraites pour chaque fait de la figure 3

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


Formulation. Si R1 est une relation-fait de S alors l’ensemble de ses mesurescandidates est l’union des trois ensembles obtenus par :

Hm1 :

∪∪−Ω

≠∈Ω∪1,

11/1

RRjSRj

RjRRNUMR FkPk

Hm2.1 : ( ) ( )( ) ∪ ∪

)2()1(2//1

22

21

21,

RDRDRRSaR Mm

RRHm

RDRDmAgr

⊂

∈ ∈

−Ω avec :

RHmM 1 : Mesures de R extraites par Hm1.

( )1RD : Dimensions de la relation-fait R1.

( )dnddmAgr ,...,2,1, : Agrégation de la mesure m sur les dimensions di.

Hm2.2 : ∪ ∪

)2()1(2//1

22

21

RDRDRRSaR Mm

RRHm

m

=

∈ ∈

Ω

Illustration. Le tableau 2 énumère pour chaque fait de la figure 3 l’ensemble deses mesures candidates extraites.

Nous complétons la construction des schémas en étoile par l’extraction desdimensions pour chaque fait identifié.

3.4. Extraction des dimensions

Naturellement, un fait est lié à un nombre n (n>1) fini de dimensionsreprésentant les axes d’analyses. Une dimension est caractérisée par un nom etpossède une liste d’attributs dont un identifiant. L’ensemble des dimensionscandidates d’un fait F est construit soit à partir de relations (celles référencées par F)soit à partir d’attributs (Hachaichi et Feki, 2006). Pour construire cet ensemble nousdéfinissons cinq heuristiques.

3.4.1. Dimension construite à partir d’une relation

Hd1. Toute relation-entité R directement référencée par une relation-fait F estune dimension candidate pour F. Le nom de cette dimension est celui de R, sonidentifiant est la clé primaire de R.

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


Exemple. La relation CREDIT est une dimension pour le faitREMBOURSEMENT, son identifiant est REF_CRE.

Nous appelons une relation identifiée comme dimension une relation-dimension.

3.4.2. Dimension construite à partir d’un attribut

Cas d’un attribut booléen. Un attribut booléen appartenant à une relation-faitrépartit ses tuples en deux sous ensembles et peut donc constituer un axe d’analyse.D’où l’heuristique suivante :

Hd2. Tout attribut booléen appartenant à une relation-fait F donne naissance àune dimension candidate pour F dont il est l’identifiant.

Cas d’un attribut temporel. Dans le modèle dimensionnel, la dimension tempsfigure systématiquement dans tout entrepôt (Kimball, 1997) considéré comme unesérie temporelle. Nous construisons une dimension à partir d’un attribut temporelpar la règle suivante :

Hd3. Tout attribut temporel (date ou temps) appartenant à une relation-fait Festampille le fait F, il construit alors une dimension temporelle dont il estl’identifiant.

Exemple. L’attribut DAT_REMB est identifié comme dimension pour le faitREMBOURSEMENT.

Cas d’un attribut représentant une entité vide. Généralement latransformation d’une entité vide (i.e. réduite à sa clé) en relationnel n’engendre pasune relation mais se traduit par migration de sa clé vers une autre relation. Cette clépeut jouer le rôle d’une dimension. Afin de localiser cette dimension dans unesource relationnelle, nous avons distingué deux cas. Pour chacun nous présentons unexemple de motivation suivi de son heuristique :

Cas 1. Entité vide liée par une association multivaluée porteuse de données

Entité vide

(a) (b)

Figure 5. Entité vide liée et sa représentation relationnelle

Dans un contexte E/A (figure 5a), si l’attribut A7 est numérique alors Assoc_1sera un fait candidat. Ce fait doit avoir l’entité Ent_1 comme dimension candidate.Or, Ent_1 ne se transforme pas en une relation (figure 5b) ; en effet, seul sonidentifiant participe à la clé de la relation Assoc_1. Ce cas type nous a permis dedéfinir l’heuristique suivante :

1,n1,n

Ent_1A1

Ent_2A4A5

Assoc_1A7

Ent_2 (A4, A5)

Assoc_1 (A4#, A1, A7)Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


Hd4. Si un attribut de la clé primaire d’une relation-fait F de classe Ra n’est pasune clé étrangère alors cet attribut construit une dimension candidate dont il estl’identifiant.

Exemple. Dans la figure 6a, l’attribut AN_SUIVI_RES_EXP est identifiécomme dimension associée au fait SUIVI_RES_EXP. En réalité, cet attributreprésente l’entité vide ANNEE_EXP de la figure 6b.

SUIVI_RES_EXP (COD_PRJ : PROJET, AN_SUIVI_RES_EXP,ECA_RES_EXP, ECA_RES_NET, ECA_DEP, ECA_CA)

PROJET (COD_PROJ, LIEU_PROJ, NUM_REG_COM, EFFECT_SAL,…)

Figure 6. Entité ANNEE_EXP vide

Cas 2. Entité vide liée par une association CIF

1,n1,1

Ent_1A1A2

Ent_2A4Assoc_1

Figure 7. Entité vide liée par une association CIF

Pour ce cas, si l’attribut A2 est numérique alors l’entité Ent_1 sera un faitcandidat ayant comme dimension candidate l’entité Ent_2. Mais ce diagramme setransforme en une seule relation : Ent_1 (A1, A2, A4). Ceci nous fait perdre la méta-donnée « A4 décrit l’entité ENT_2 ». En conséquence il serait malheureusementimpossible de définir une heuristique permettant de déduire que A4 est l’identifiantd’une dimension candidate.

Exemple. Dans la figure 8, l’attribut FORM_JUR_PROJ de l’entité videFORME_JURIDIQUE a migré vers la relation PROJET comme attribut simple :

PROJET (COD_PROJ, FORM_JUR_PROJ, LIEU_PROJ, NUM_REG_COM,…).

Figure 8. Exemple de l’entité FORME_JURIDIQUE ne pouvant pas être identifiéecomme dimension

0,n1,1

PROJETCOD_PROJLIEU_PROJNUM_REG_COM

...

FORME_JURIDIQUEFORM_JUR_PROJ

FORM_JUR_PRJ

(a)

(b) 0,n0,nANNEE_EXPAN_SUIVI_RES_EXP

PROJETCOD_PROJLIEU_PROJNUM_REG_COMEFFECT_SAL

SUIVI_RES_EXPECA_RES_EXPECA_RES_NETECA_DEPECA_CA ...

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


Cependant, nous pouvons définir l’attribut A4 comme une dimension si sonentité Ent_2 est liée à au moins une autre entité (cf. figure 9). En effet, dans ce casl’attribut A4 sera présent dans une autre relation en plus de sa présence dans Ent_1c’est-à-dire :

– soit dans la relation Ent_3 (A7,…, A4) si la cardinalité maximale y = 1,– soit dans la relation Assoc_2 (A4, A7) si la cardinalité maximale y > 1.

Figure 9. Entité vide liée par une association CIF et à d’autres associations

Ce cas type nous a permis de définir l’heuristique suivante :Hd5. Tout attribut a non clé (primaire ou étrangère) appartenant à une relation-

fait F et à d’autre(s) relation(s) est un identifiant candidat d’une dimension de Fconstruite sur a.

Exemple. Pour la source S1 si nous supposons que l’attribut NAT_REMBappartient aux relations REMBOURCEMENT, REMB_ECH, REMB_RETARD etREM_COM alors ce premier est un identifiant pour une dimension définie sur lesfaits REMBOURCEMENT, REMB_ECH, REMB_RETARD et REM_COM.

REMARQUE.— Nous considérons que les dimensions obtenues par Hd1 à Hd3 sontplus pertinentes que celles déduites par Hd4 et Hd5. En effet, ces dernières définissentcomme dimension la transformé d’une entité réduite à sa clé primaire. Or ce typed’entité est parfois particulier et ne mérite pas d’être un axe d’analyse comme parexemple une entité COMPTEUR générant des numéros séquentiels.

Nous convenons de nommer une dimension construite sur un attribut a parDCA_a (concaténation du préfixe DCA_ et du nom de l’attribut). Elle correspond enfait à une dimension dégénérée (Kimball et al., 2003).

Formulation. Si R1 est une relation-fait d’une source S alors l’ensemble de sesdimensions candidates est l’union des cinq ensembles obtenus par :

Hd1 : φ≠∩∈ 1: RR FkPkSeR ; l’identifiant de la dimension bâtie sur R estPkR,

Hd2 : ∪BOLRa

aDCA/1

_Ω∈

; l’identifiant de la dimension aDCA_ est a,

Hd3 : ∪TEMRa

aDCA/1

_Ω∈

; l’identifiant de la dimension aDCA_ est a,

1,n1,1

Ent_1A1A2

Ent_2A4Assoc_1

Ent_3A7

Assoc_2

......

?,y?,n

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


Hd4 : ( )∪

11

_RR FkPka

aDCA−∈

; l’identifiant de la dimension aDCA_ est a.

Hd5 : ( ) ( )∪

111

1111:_RRR FkPka

RRR RFkPkRSRaDCA∪−Ω∈

⊆∪−Ω−∈∃ ∧ ;

l’identifiant de la dimension ._ aDCA

Illustration. L’application de ces heuristiques sur les faits candidats de la sourceS1 produit l’ensemble des dimensions candidates du tableau 3.

Fait Dimensions extraites Identifiant de dimension Heuristique

CREDIT REF_CRE Hd1DCA_DAT_REMB DAT_REMB Hd3, Hd4REMB_ECHDCA_DAT_ECH DAT_ECH Hd3, Hd4

CREDIT REF_CRE Hd1REMBOURCEMENTDCA_DAT_REMB DAT_REMB Hd3, Hd4

CREDIT REF_CRE Hd1INT_RETARDDCA_DAT_INT_RET DAT_INT_RET Hd3, Hd4

CREDIT REF_CRE Hd1DCA_DAT_REMB DAT_REMB Hd3, Hd4REMB_RETARD

DCA_DAT_INT_RET DAT_INT_RET Hd3, Hd4TYPE_COMMISSION COD_TYP_COM Hd1

CREDIT REF_CRE Hd1COMMISSIONDCA_DAT_COMM DAT_COMM Hd3, Hd4

TYPE_COMMISSION COD_TYP_COM Hd1CREDIT REF_CRE Hd1

DCA_DAT_COMM DAT_COMM Hd3, Hd4REM_COMM

DCA_DAT_REMB DAT_REMB Hd3, Hd4CREDIT REF_CRE Hd1

RUBRIQUE_EVOL NUM_REB Hd1SOUS_RUBRIQUE_EVOL NUM_SOUS_REB Hd1EVOLUTION_CRE

DCA_DAT_EVO_CRE DAT_EVO_CRE Hd3, Hd4PROJET COD_PROJ Hd1SUIVI_RES_EXP DCA_AN_SUIV_RES_EXP AN_SUIV_RES_EXP Hd4NATURE COD_NATSECTEUR NUM_SEC_ACT

DELEGATION COD_DELEGCLIENT NUM_CLI

Hd1

DCA_DAT_DEB_ETUD DAT_DEB_ETUDDCA_DAT_LANC_REM DAT_LANC_REM

PROJET

DCA_DAT_REM_CRE_PRJ DAT_REM_CRE_PRJHd3

DCA_DAT_SIG DAT_SIGDCA_DAT_ACC DAT_ACC

DCA_DAT_DEB_VER DAT_DEB_VERDCA_DAT_DEM_CRE DAT_DEM_CRE

Hd3CREDIT

COMPTE NUM_CPT Hd1TYPE_CL NUM_TYPCLIENT SECTEUR NUM_SEC_ACT Hd1

COMPTE CLIENT NUM_CLI Hd1

Tableau 3. Dimensions extraites pour les faits du tableau 2

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


Notons que certains des faits construits sur les entités (c’est-à-dire faits de faiblepertinence) n’auront pas de dimensions, nous les considérons alors « douteux » etnous les éliminons systématiquement. Par exemple, le fait TYPE_COMMISSIONde faible pertinence (figure 3) n’est associé à aucune dimension, il est supprimé.

Pour compléter les dimensions nous déterminons leurs paramètres et nousconstruisons leurs hiérarchies.

3.5. Extraction des hiérarchies

Une hiérarchie organise les paramètres d’une dimension selon une relation« est_plus_fin » conformément à leur niveau de détail (Teste, 2000). Par ailleurs,toute hiérarchie d’une dimension d part de l’identifiant de d qui est le paramètre leplus fin (de rang 1) déjà extrait avec la dimension. Nous continuons alors à extraireles paramètres de rang supérieur à 1 pour construire les hiérarchies de d.

Notons que les identifiants trouvés pour une dimension candidate proviennentsoit d’une relation (par Hd1) soit d’un attribut (par Hd2 à Hd5). En réalité, unedimension construite sur un attribut ne peut s’étendre à d’autres niveaux deparamètres. Par contre, une dimension d construite sur une relation pourraitréférencer d’autres relations ; ces dernières fourniront éventuellement des niveauxhiérarchiques pour d.

D’abord nous présentons quatre heuristiques d’extraction des paramètres derang 2, ensuite nous traitons l’extraction des paramètres de rang supérieur à 2. Nousnommons un paramètre extrait par le nom de son attribut correspondant.

Hh1. La clé primaire d’une relation de classe R-e directement référencée par unerelation-dimension d est un paramètre candidat de rang 2 d’une hiérarchie de d.

Par analogie à l’extraction des dimensions, un attribut booléen ou temporel,présent dans une relation-dimension peut constituer une hiérarchie.

Hh2. Tout attribut booléen ou temporel appartenant à une relation-dimension estun paramètre candidat terminal de rang 2 d’une hiérarchie définie sur cettedimension.

Pour prendre en considération la transformation des entités vides liées par uneassociation CIF (cf. figure 8) lors de l’extraction des paramètres nous définissonsl’heuristique Hh3 :

Hh3. Tout attribut non clé (primaire ou étrangère) appartenant simultanément àune relation-dimension d et à d’autre(s) relation(s) est un paramètre candidat derang 2 d’une hiérarchie définie sur d.

Plus généralement, l’application récursive des heuristiques Hh1 à Hh3 sur lesrelations obtenues par Hh1 produit des paramètres de rang>2.

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


Formulation. Si R1∈ S est une relation-dimension (resp. une relation dont la cléest un paramètre de rang i>1) alors les paramètres de rang 2 (resp. de rang i+1)extraits sont définis par l’union des ensembles obtenus par :

Hh1 : φ≠∩∈ 1: RR FkPkSeR

Hh2 : ∪TEMRBOLRa

a/1/1 Ω∪Ω∈

Hh3 : ( ) ( )∪

111

1111:RRR FKPKa

RRR RFKPKRSRa∪−Ω∈

⊆∪−Ω∧−∈∃

Illustration. Le tableau 4 présente pour chaque dimension du tableau 3, déduitepar Hd1, les paramètres de ses hiérarchies.

Dimension Paramètres Rang Heuristique

TYPE_CL ∅ ∅ ∅SECTEUR ∅ ∅ ∅

NUM_TYP 2CLIENT NUM_SEC_ACT 2 Hh1

NATURE ∅ ∅ ∅DELEGATION COD_GOUVER 2 Hh1

NUM_CLI 2NUM_TYP 3COMPTE

NUM_SEC_ACT 3Hh1

COD_NAT 2NUM_SEC_ACT 2

COD_DELEG 2COD_GOUVER 3

NUM_CLI 2NUM_TYP 3

NUM_SEC_ACT 3

Hh1

DAT_DEB_ETUD 2DAT_LANC_REM 2

PROJET

DAT_DEM_CRE_PRJ 2Hh3

NUM_CPT 2NUM_CLI 3NUM_TYP 4

NUM_SEC_ACT 4

Hh1

DAT_SIG 2DAT_DEB_VER 2DAT_DEM_CRE 2

CREDIT

DAT_ACC 2

Hh3

TYPE_COMMISSION ∅ ∅ ∅RUBRIQUE_EVOL ∅ ∅ ∅

SOUS_RUBRIQUE_EVOL NUM_RUB 2

Tableau 4. Hiérarchies extraites pour les dimensions du tableau 3

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


3.6. Extraction des attributs faibles

Un attribut faible dépend fonctionnellement du paramètre qu’il décrit. Enconséquence il se trouve dans la même relation que son paramètre.

Vu que les attributs faibles sont descriptifs (Hüsemann, et al., 2000) souventutilisés pour des fins informatifs (Golfarelli, et al., 1998a), nous considérons que lesattributs textuels sont plus significatifs que ceux numériques. Ainsi, nous définissonsune heuristique pour l’identification des attributs faibles textuels (Haf1) et unedeuxième pour les attributs faibles numériques (Haf2).

Haf1. Les attributs textuels non clés appartenant à une relation fournissant unparamètre p (de rang quelconque) et n’appartenant pas à d’autres relations sont desattributs faibles pour p.

Haf2. Les attributs numériques non clés appartenant à une relation fournissantun paramètre p (de rang quelconque) et n’appartenant pas à d’autres relations sontdes attributs faibles pour p.

Paramètres Attributs faibles HeuristiqueNUM_TYP LIB_TYP Haf1

NUM_SECT_ACT LIB_SEC_ACT Haf1COD_GOUVER LIB_GOUVER Haf1

NOM_CLIPRE_CLIADR_CLI

VILLE_CLI

Haf1

NUM_TEL

NUM_CLI

COD_PTT Haf2

COD_DELEG LIB_DELEG Haf1FORM_JUR_PRJ

LIEU_PRJ Haf1

NUM_REG_COMPOURC_CH_SCEFFECT_SAL

SAL_MOYMTT_INVEST

COD_PROJ

MAT_FISC

Haf2

NBR_ANNUITNUM_CPTSOL_CPT

Haf2

NUM_RUB TYP_RUB Haf1MT_CRE_ACC

DUREENBR_TR

REF_CRE

TAUX_INT

Haf2

LIB_TYP_COM Haf1COD_TYP_COMTAUX_COM Haf2

NUM_REB TYP_RUB Haf1NUM_SOUS_REB TYP_SOUS_RUB Haf1

Tableau 5. Attributs faibles des dimensions de la source S1

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


Formulation. Si R1∈ S est une relation ayant sa clé un paramètre p alorsl’ensemble de tous les attributs faibles de p est déterminé à partir de R1 par l’uniondes deux ensembles obtenus par :

Haf 1: ∪∪

∪∪−Ω∈

≠∈Ω

1,

11/1

RRjSRj RjRRTEXR FKPKa

a (Attributs faibles pertinents)

Haf 2: ∪∪

∪∪−Ω∈

≠∈Ω

1,

11/1

RRjSRj RjRRNUMR FKPKa

a (Attributs faibles moins pertinents)

Illustration. Le tableau 5 montre pour chaque identifiant de dimension obtenuepar Hd1 et pour chaque paramètre extrait par Hh1 ses attributs faibles extraits.

La figure 10 montre le schéma en étoile, centré sur le fait CREDIT, obtenu selonnotre démarche.

Figure 10. Schéma en étoile construit sur le fait CREDIT

4. L’outil CAME

Pour montrer la faisabilité de nos propos, nous avons développé un outil logicielappelé CAME (conception assistée de magasin de données en étoile). Cet outil estdéveloppé avec JBuilder X et gère une Meta-base créée sous Oracle9i. Cette sectionprésente l’architecture de CAME, ses fonctionnalités et évalue ses résultats produits.

MT_CRE_ACCDUREENBR_TRTAUX_INT

DCA_DAT_SIG

DAT_SIG

DCA_DAT_DEB_VER

DAT_DEB_VER

DCA_DAT_DEM_CRE

DAT_DEM_CRE

COMPTENUM_CPT

TYP_CPT

SOL_CPT

NUM_CLI

NUM_SEC_ACT

LIB_SEC_ACT

NOM_CLI

ADR_CLI

VILLE_CLI

NUM_TELCOD_PTTDCA_DAT_ACCEPT

DAT_ACCEPT

LIB_TYPNUM_TYP

PRE_CLI

CREDIT

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


4.1. Présentation de CAME

CAME implante les trois étapes de notre approche : pré-construction,construction et validation. Chacune de ses étapes comporte un ensemble de modulesassurant l’automatisation de l’approche, l’interaction avec le concepteur, quandnécessaire, ainsi que le chargement et l’interrogation des référentiels dédiés. Lafigure 11 décrit l’architecture fonctionnelle de l’outil CAME.

Figure 11. Architecture fonctionnelle de CAME

La phase de pré-construction alimente la méta-base de la figure 12a en exécutantun package que nous avons développé en PL/SQL. Ce package accède au référentielOracle par le biais des vues systèmes all_tab_columns et all_constraints, extrait leschéma d’une source de données relationnelle sélectionnée par le concepteur et affecteautomatiquement à chaque relation sa classe conceptuelle (R-e ou R-a).

La figure 13 visualise le schéma de la source crédits bancaires récupéré parCAME ; elle montre la classe conceptuelle attribuée automatiquement à chaquerelation et permet au concepteur de :

– désélectionner les relations qu’il juge inutiles d’impliquer dans le processus deconstruction de MD ; ceci lui permettra de maintenir tout ou partie des tablessources,

– consulter la structure d’une table et changer sa classe conceptuelle de R-a enR-e, s’il la juge incorrectement identifiée,

– lancer le processus d’extraction des concepts multidimensionnels.

Pré-constructionPré-construction Construction des schémas de MD

Construction des schémas de MD

ValidationValidation

Sélection des relations concernés

&Modification des classes

conceptuelles

Référentiel des schémas de MD

Validation des schémas en étoiles

Concepteur décisionnel

ENSEIGNEMENT_ASSURE


ENSEIGNANTCO D_ENS

NOM_ENSPRE_ENS

TYP_ENS

E_MAIL

GRAD_ENSMATIERE

CO D_AUDCOD_MATCOD_SEC

INT_SEC

INT_AUD

NUM_CYC

INT_MAT

DCS AN_UNIVAN_UNIV


DCS NUM_SEMNUM_SEM

ENSEIGNEMEN T_ASSURE


ENSEIGNANTCOD_ENS

NOM_ENSPRE_ENS

TYP_ENS

E_MAIL

GRAD_ENSMATIERE


INT_SEC

INT_AUD

NUM_CYC

INT_MAT

DCS AN_UNIVAN_UNIV


DCS NUM_SEMNUM_SEM

MD candidats

Identification des concepts multidimensionnels

&association de la pertinence

Modification des concepts extraits

Sourcerelationnelle

Éditeur graphique des schémas

multidimensionnels

Référentiel des schémas relationnels

extraits

Interventions optionnelles du concepteur

Enchaînement automatique Extraction du schéma de la

source&

attribution de la classe conceptuelle

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


Figure 12. Méta-modèle des deux référentiels de CAME

Figure 13. Interface d’affichage et validation du schéma de la source

La phase de construction de MD, enchaîne sur le lancement du processusd’extraction qui identifie les faits, les mesures, les dimensions, les paramètres etleurs attributs faibles puis, exécute une procédure de nettoyage qui supprimeautomatiquement les faits sans dimensions.

(b) Méta-modèle des MD

Structure d'une table courante

Sélection/désélection de relationsLance l'extraction des concepts multidimensionnels.

Classe conceptuelle

Relations de la source

(a) Méta-modèledu schéma relationnel

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


L’interface de la figure 14 affiche les faits extraits avec leur degré de pertinence,relation source et règle d’extraction (visualisable avec le bouton détail). Leconcepteur peut alors :

– modifier les noms et les désignations attribués par défaut aux faits, sans impactsur leur attachement à la source ;

– éliminer des faits qui ne correspondent pas aux besoins analytiques demandéspar les décideurs ;

– sélectionner un fait pour afficher ses mesures ou ses dimensions.

Afin de valider les résultats obtenus, CAME donne la main au concepteur pourmodifier les noms et désignations des mesures, dimensions ou attributs forts etfaibles des hiérarchies affichées. Aussi, il permet d’éliminer sur demande expliciteles éléments dont la pertinence est au dessous d’un certain seuil choisi par leconcepteur.

Figure 14. Interface de visualisation et manipulation des faits extraits

Finalement, les schémas en étoile résultats sont visualisables de deux façons :comme indiqué par la figure 15, ou bien selon le formalisme graphique de(Golfarelli et al., 1998b) en utilisant notre éditeur MPI_Editor (BenAbdallah et al.,2006) afin de pouvoir les manipuler graphiquement. La figure 16 montre unaffichage graphique de deux schémas en étoiles pour notre source de gestion descrédits bancaires : CREDIT et REMB_ECH.

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


Figure 15. Schéma en étoile du fait REMBOURSEMENT construit avec CAME.

Figure 16. Exemples de deux schémas en étoiles construits automatiquement avecCAME et visualisés avec MPI-Editor

Volets des MDs construitsavec CAME

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


4.2. Evaluation de CAME

Pour évaluer les performances de CAME, nous l’avons appliqué en plus surquatre sources choisies dans la littérature des systèmes décisionnels pour lesquellesles schémas en étoiles sont construits manuellement par leurs auteurs. L’analysecomparative entre, d’une part les résultats obtenus avec CAME et, d’autre part lesschémas pertinents construits par les auteurs de ces cas, est récapitulée dans letableau 6. Cette étude nous a mené au constat suivant :

– CAME est capable d’identifier automatiquement tous les faits qu’une analyseascendante manuelle peut définir (taux de couverture 100 %),

– à l’exception des mesures calculables sur les attributs de la source, toutes lesmesures sont identifiées,

– CAME génère des hiérarchies avec des niveaux très détaillés, et tient comptedes hiérarchies construites sur des attributs booléens,

– il génère tous les schémas pertinents y compris ceux qui ne correspondent pasà des besoins projetés par les décideurs (cas des analyses descendantes),

– à l’exception des dimensions construites sur des clés d’entités vides non liées àdes entités autres que le fait (figures 7 et 8), les dimensions extraites par CAMEcouvrent toutes les dimensions possibles pour un fait donné,

– rarement, nous obtenons certaines hiérarchies avec des niveaux très profonds ;elles méritent d’être taillées d’une dimension pour être greffées sur une autremoyennant des opérateurs spécifiques comme le « pruning » et le « grafting »(Golfarelli et al., 1998 ; Feki et al., 2007) ; cette décision dépend de la sémantique etincombe donc au concepteur décisionnel qui peut exécuter ces opérateurs au niveaudu module de validation.

Pert

inen

ce d

es M

Dob

tenu

s et n

onen

visa

gées

Tau

x de

cou

vert

ure

des m

esur

es e

t des

dim

ensi

ons d

es M

Dco

uver

ts

Critère

Cas

Nom

bre

de M

D p

our

lebe

soin

env

isag

é da

nsle

cas

i

Nom

bre

de M

D e

xtra

itspa

r C

AM

E

Tau

x de

cou

vert

ure

des M

D

E* F* Mes Dim

Activité commerciale(Golfarelli et al., 1998b) 1 3 1/1 0 2 2/2 3/3

« Flight reservation system »(Böhnlein et al., 1999) 1 3 1/1 2 0 1/2 4/4

« Hospital »(Golfarelli et al., 1998a) 1 1 1/1 0 0 2/4 7/10

Répartition des charges desEnseignants (Soussi et al., 2005) 2 9 2/2 3 4 2/4 6/6

Tableau 6. Evaluation des résultats de CAME (* E : Elevé ; F : Faible)

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


Enfin, l’étude de la complétude de nos heuristiques mérite d’être étudiée ;cependant, elle dépasse l’objectif de ce papier. Toutefois, nous estimons que nosheuristiques tendent vers cette complétude. En effet, nous les avons appliquées surdes cas traités par des experts du domaine décisionnel et nous avons constaté que lesMD générés couvrent ceux construits par les experts (cf. tableau 4 donne unéchantillon) et ceci du point de vue faits, mesures, dimensions et hiérarchies,exception faite des faits vides (i.e., sans mesures) et des mesures calculableshypothétiquement négligés.

5. Conclusion et perspectives

Dans cet article nous avons présenté une démarche et un outil logiciel deconstruction assistée de schémas de magasins de données (MD) en étoile à partird’une source relationnelle. Pour cette démarche, nous avons procédé à un examenminutieux des structures des relations et de leurs clés pour les classer en : i) desrelations décrivant des associations et, ii) des relations décrivant des entités. Cetteclassification optimise la localisation des faits et celle des dimensions dans unesource relationnelle. Ensuite, pour l’extraction de chaque concept multidimensionnel(fait, mesure, dimension et attribut), nous avons défini un ensemble d’heuristiquesapproprié. Ces heuristiques sont indépendantes de la sémantique et exploitent lesliens interrelations (clé primaire/étrangère). Par ailleurs, nos heuristiques classent lesconcepts multidimensionnels extraits d’un même type (e.g. faits, mesures, etc.) parniveau de pertinence. Cette classification assiste le concepteur décisionnel quant auchoix des schémas les plus intéressants.

Sur le plan pratique, nous avons développé en Java et pour une source Oraclel’outil CAME (Conception Assistée de Magasin de données en Étoile) qui supportela méthode et qui autorise le concepteur à intervenir dans les différentes étapes degénération et de validation des schémas de MD.

Sur le plan expérimental, nous avons testé notre méthode sur plusieurs cas typede sources relationnelles et nous avons obtenus de bons résultats ; cet article aprésenté un de ces cas. De plus nous avons effectué une analyse comparative entre,d’une part, les résultats obtenus automatiquement avec CAME (i.e., sans aucuneintervention du concepteur) et, d’autre part, les schémas pertinents construits par lesauteurs de quatre cas types pris de la littérature des systèmes décisionnels. Cetteanalyse a montré expérimentalement l’efficacité de notre outil.

Les perspectives de ce travail sont multiples. Nous comptons finaliser CAMEpour aboutir à un produit qui aide les petites et moyennes entreprises à se doter deleur propre système décisionnel avec des coûts de conception raisonnables ; cecinécessite une réflexion sur l’introduction des mesures calculées dans les schémasgénérés, la garantie de leur élémentarité/granularité, l’additivité par rapport auxdimensions ainsi que la définition de contraintes et la génération automatique desprocédures ETL pour la mise en œuvre de ces MD. A long terme, la diversité des

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


sources pour la construction automatique de schémas de MD nous préoccupe. Nouscomptons également aligner nos travaux avec les standards MDA (« Model DrivenArchitecture ») (OMG, 2001) et CWM (« Common Warehouse Metamodel »)(OMG, 2002) pour garantir la portabilité de nos résultats.

Remerciements

Les auteurs remercient vivement Madame Hanêne Ben-Abdallah, maître deconférences au département d’informatique de la faculté des sciences Economiqueset de Gestion de Sfax (FSEGS) pour sa lecture de l’article et ses remarquesconstructives.

6. Bibliographie

Ben Abdallah M., Feki J., Ben-Abdallah H., « MPI-EDITOR : un outil de spécification debesoins OLAP par réutilisation logique de patrons multidimensionnels », Atelier desSystèmes décisionnels (ASD’06), Maroc, décembre 2006.

Ben-Abdallah M., Feki J., Ben-Abdallah H., “Designing Multidimensional Patterns fromStandardized Real World Entities”, International Conference on Computer &Communication Engineering (ICCCE’06), Malysia, May 2006.

Böhnlein M., Ulbrich-vom Ende A., “Deriving Initial Data Warehouse Structures from theConceptual Data Models of the Underlying Operational Information Systems”, Proc. Int.Workshop on Data Warehousing and OLAP, Kansas City, MO, USA, 1999, p. 15-21.

Bonifati A., Cattaneo F., Ceri S., Fuggetta A., Paraboschi S., “Designing Data Marts for DataWarehouse”, ACM Transaction on Software Engineering and Methodology, vol. 10,October 2001, p. 452-483.

Cabibbo L., Torlone R., “A Logical Approach to Multidimensional Databases”, Conferenceon Extended Database Technology, Valencia-Spain, 1998, p. 187-197.

Calvanese D., Dragone L., Nardi D., Rosati R., Trisolini S., “Enterprise modeling and DataWarehousing in Telecom Italia”, Information Systems, vol. 31, n° 1, 2006.

Feki J., Ben-Abdallah H., “Star-patterns for data mart design: definition and logical reuseoperators”, International Conference on Control, Modelling and Diagnosis (ICCMD’06),Algérie, May 2006.

Feki J., Ben-Abdallah H., Ben-Abdallah M., « Réutilisation des patrons en étoile »,24e Congrès INFORSID’06, Hammamet, Tunisie, 1-3 juin 2006, p. 687-701.

Feki J., Ben-Abdallah H., “Multidimensional Pattern Construction and Logical Reuse for theDesign of Data Marts”, International Review on Computers and Software (IRECOS),vol. 2, n° 2, mars 2007, p. 124-134.

Golfarelli M., Maio D., Rizzi, S., “Conceptual Design of Data Warehouses from E/RSchemas”, Conference on System Sciences, Kona, Hawaii, vol. VII, 1998.

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14


Golfarelli M., Maio D., Rizzi S., “The dimensional fact model: a conceptual model for datawarehouses”, International Journal of Cooperative Information Systems, 1998, p. 215-247.

Hachaichi Y., Feki J., « Heuristiques de construction de MD à partir d’une source OLTPrelationnelle », Atelier des Systèmes Décisionnels (ASD’06), Agadir, Maroc, 2006.

Hachaichi Y., Feki J., « Vers un outil de construction de schémas en étoile sur une sourcerelationnelle », Journées Jeunes Chercheurs en Génie électrique et informatique(GEI’07), Monastir, Tunisie, 2007.

Hüsemann B., Lechtenbörger J., Vossen G., “Conceptual Data Warehouse Design”, Proc. ofthe International Workshop on Design and Management of Data Warehouses, Stockholm-Sweden, 2000, p. 6.1-6.11.

Kimball R., The Data Warehouse Toolkit, John Wiley and Sons Inc, 1997.http://kimballgroup.com/html/designtipsPDF/DesignTips2003/KimballDT46AnotherLook.pdf

Kimball R., Revues L., Ross M., Thornthwaite W., Le data warehouse : Guide de conduite deprojet, Eyrolles, 2005.

Mazón J.-N., Trujillo J., “An MDA approach for the development of data warehouses”,Decisional Support System, 2007.

Moody L.D., Kortink M.A.R., “From Enterprise Models to Dimensional Models:A Methodology for Data Warehouses and Data Mart Design”, Proc. of the InternationalWorkshop on Design and Management of Data Warehouses, Stockholm, Sweden, 2000.

OMG, Object Management Group (OMG), MDA Guide 1.0.1. http://www.omg.org/cgi-bin/doc?omg/03-06-01.

OMG-CWM, Object Management Group (OMG), Common Warehouse Metamodel (CWM)Specification 1.1. http://www.omg.org/cgibin/doc?formal/03-03-02.

Prat N., Akoka J., Comyn-Wattiau I., “A UML-based data warehouse design method”,Decision Support Systems, vol. 42, n° 3, décembre 2006, p. 1449-1473.

Phipps C., Davis K., “Automating data warehouse conceptual schema design and evaluation”,DMDW’02, Canada, 2002.

Ravat F., Teste O., Zurfluh G., “Modélisation multidimensionnelle des systèmesdécisionnels”, Revue ECA, vol. 1, n° 1-2, 1999, p. 201-212.

Sinz E.J., “Datenmodellierung im Strukturierten Entity-Relationship-Modell (SERM)”,Fachliche Analyse von Informations systemen, Addison-Wesley, Bonn, 1992.

Soussi A., Feki J., Gargouri F., « Approche semi-automatisée de conception de schémasmultidimensionnels valides », Entrepôt de Données et Analyses en lignes, Revue RNTIvol. B-1, 2005, p. 71-90.

Teste O., Modélisation et manipulation d’entrepôts de données complexes et historisées,Thèse de l’Université Paul Sabatier (Toulouse III), décembre 2000.

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14

Dow

nloa

ded

by [

Dok

uz E

ylul

Uni

vers

ity ]

at 2

0:10

05

Nov

embe

r 20

14

une démarche et un outil

Documents