Mémoire de Fin d’Etudes - univ-oran1.dz

Mémoire de Fin d’Etudes

Pour l’Obtention du Diplôme de Magister

en Informatique

Présenté par :

KAHLOULA BOUBAKER

Option : Informatique & Automatique

THEME

Chargement de données XML dans un DataWarehouse : Approches pour l'automatisation

du Schema Matching

Jury

Pr BELDJILALI Bouziane Président Université d’OranDr BOUAMRANE Karim Encadreur Université d’OranDr NAIT BAHLOUL Safia Examinatrice Université d’OranDr ATMANI Baghdad Examinateur Université d’Oran

Année universitaire 2009/2010

A Meriem, à mes enfants et à toute ma famillepour tout ce qu’ils me donnent

A Mouradpour m’avoir encouragé à entreprendre ce travail

et soutenu en bien d’autres circonstances

Aux Prof. Norbert Krier, Prof. Hans Scholz, Prof. Axel Schmidtet à tous mes autres professeurs retraités de la Hochschule Darmstadt

pour l’enseignement qu’ils m’ont prodigué

A mes collègues de Sonatrach Avalet à ceux de la Dresdner Bank Frankfurt

pour la confiance qu’ils m’ont toujours accordée

Je veux en cette place dire toute ma gratitude auDocteur Bouamrane Karim, qui a accepté sanshésitation de m’encadrer dans ce travail, et leremercier vivement pour la disponibilité et la patiencedont il a fait preuve en m’accompagnant tout le long decette tâche.

Ma reconnaissance va aussi aux très honorablesmembres du jury, qui ont bien voulu juger ce travail :au Professeur Beldjilali Bouziane, président, ainsiqu’aux Docteurs Nait Bahloul Safia et AtmaniBaghdad, examinateurs.

« Chacun se trompe ici-bas :On voit courir après l'ombreTant de fous qu'on ne sait pas,La plupart du temps, le nombre. »

Jean de La Fontaine, extrait des Fables

Chargement de données XML dans un Data warehouse

6

RésuméLes systèmes d'information sont souvent caractérisés par unehétérogénéité et une distribution qui prennent de plus en plusd’ampleur au fil du temps. Des données sont exportées etimportées en permanence d’un système vers l’autre pour leurpermettre de communiquer entre eux. Les données proviennentfréquemment aussi du monde extérieur. Les données sont trèssouvent contenues dans un fichier XML et le système cible esten général une base de données relationnelle, ou plusparticulièrement un Data warehouse. Les données existantesdans les fichiers XML sous un nom et un format donnés doiventêtre quelquefois renommées ou reformatées pour pouvoir êtrestockées puis exploitées à un niveau local. Ce travailfastidieux de Matching se fait encore couramment de façonmanuelle.

Il s’agit, dans le cadre de ce mémoire de Magister, d’unepart, de la conception et du développement d’un système globalde chargement de données XML dans un Data warehouse, d’autrepart de donner un aperçu des techniques et prototypes qui ontété proposés jusqu’ici pour l’automatisation du SchemaMatching et en relever les spécificités. La conception dusystème - auquel nous avons donné le nom de OpenX2DW - dechargement de données XML dans la base de données cible, tientcompte par ailleurs de cette automatisation.

AbstractInformation systems are often characterized by heterogeneityand distribution witch are becoming increasingly widespreadover time. Data are exported and imported continuously fromone system to another to enable them to communicate. The datacome also frequently from outside the enterprise. The data areoften contained in an XML file and the target system istypically a relational database, or more particularly a datawarehouse. Existing data in XML files with a given name andformat should be reformatted or sometimes renamed to be storedand operated on a local level. The tedious work of Matching isstill commonly manually.

It is, in the context of this Magister thesis, first, designan develop a global system to load XML data into a datawarehouse, the other to give an overview of techniques andprototypes have been proposed so far for the automation ofSchema Matching and identify their features. The design of thesystem - which we gave the name of OpenX2DW - to load XML datainto the target database, also considers this automation.


7

TABLE DES MATIERES

TABLE DES GRAPHIQUES......................................................................................9

LEXIQUE DES TERMES LINGUISTIQUES ET ISSUS DE LA THEORIE DESGRAPHES UTILISES DANS CE MEMOIRE ...........................................................10

INTRODUCTION GENERALE .................................................................................12

1 DESCRIPTION DU SYSTEME......................................................................15

1.1 Architecture globale .................................................................................................. 15

1.2 Les composants du système ...................................................................................... 181.2.1 Le Trigger ............................................................................................................ 201.2.2 Le Matcher........................................................................................................... 231.2.3 Le Loader............................................................................................................. 251.2.4 Le Archiver.......................................................................................................... 341.2.5 La Rules engine ................................................................................................... 361.2.6 Environnement de développement et de test ....................................................... 40

1.3 Conclusion.................................................................................................................. 43

2 LE SYSTEME DANS UN PROCEDE ETL ET DANS UN« ENVIRONNEMENT DISTRIBUE »........................................................................44

2.1 Data warehouse, définition et concepts ................................................................... 44

2.2 OpenX2DW dans un procédé ETL.......................................................................... 44

2.3 OpenX2DW dans un « environnement distribué » ................................................ 49

2.4 Conclusion.................................................................................................................. 51

3 SCHEMA MATCHING...................................................................................52

3.1 «Matching» et «Mapping», définition...................................................................... 52

3.2 Domaines d’application du Matching...................................................................... 52

3.3 Traitement manuel du Matching ............................................................................. 54

3.4 Difficultés rencontrées lors d’un Matching manuel ............................................... 543.4.1 Dimension des schémas....................................................................................... 543.4.2 Complexité des schémas...................................................................................... 553.4.3 Problèmes linguistiques....................................................................................... 553.4.4 Cardinalité ........................................................................................................... 553.4.5 Redondance ......................................................................................................... 563.4.6 Absence d’information ........................................................................................ 56


8

3.5 Matching automatique .............................................................................................. 563.5.1 Les différentes sources d’information ................................................................. 563.5.2 Représentation interne ......................................................................................... 603.5.3 Mode de fonctionnement d’un opérateur de Matching ....................................... 603.5.4 Les différents types de Matcher .......................................................................... 613.5.5 Prototypes existants ............................................................................................. 62

3.6 Conclusion.................................................................................................................. 68

CONCLUSION GENERALE ET PERSPECTIVES ..................................................69

BIBLIOGRAPHIE.....................................................................................................71

ANNEXE 1 : SCRIPTS POUR LA GENERATION DE LA TABLE «RULES» .........74

ANNEXE 2 : EXEMPLE DE SCRIPT POUR L’INSERTION DE RULES .................75

ANNEXE 3: EXEMPLE DE FICHIER MAPPING .....................................................76

ANNEXE 4: EXEMPLE DE TRIGGER.....................................................................77

ANNEXE 5 : PROGRAMMES SOURCES ...............................................................78


9

TABLE DES GRAPHIQUES

FIG. 1 : ARCHITECTURE GLOBALE .....................................................................17

FIG. 2 : LES TROIS COUCHES DU SYSTEME ......................................................22

FIG. 3 : EXEMPLE DE STRUCTURE HIERARCHIQUE CONSTRUITE PAR UNPARSEUR DOM ......................................................................................................27

FIG. 4 : OPENX2DW DANS UN PROCESSUS ETL ...............................................48

FIG. 5 : OPENX2DW DANS UN « ENVIRONNEMENT DISTRIBUE »....................50

FIG. 6 : EXEMPLE DE MATCHING.........................................................................53

FIG. 7 : XMLSPY DE LA SOCIETE ALTOVA .........................................................54

FIG. 8 : CLASSIFICATION DES APPROCHES POUR UN SCHEMA MATCHING 59

FIG. 9 : DIFFERENTS ASPECTS D’UN MATCHER ...............................................59

FIG. 10 : DEUX SCHEMAS XML «COMMANDE» ..................................................66


10

LEXIQUE DES TERMES LINGUISTIQUES ET ISSUS DE LA THEORIEDES GRAPHES UTILISES DANS CE MEMOIRE

1. Termes linguistiques

Abréviation Raccourcissement d'un mot, représenté par unelettre ou un groupe de lettres issues de ce mot.

Acronyme Abréviation d’un groupe de mots, formée par lespremières lettres de ces, se prononçant comme unmot normal.

Homonyme Mot qui a la même forme orale ou écrite qu’unautre mot, mais un sens différent. Il en estl’homonyme.

Hyperonyme Mot, dans le sens est superordonné par rapport àun second. Le premier est l’hyperonyme dusecond.

Synonyme Mot qui a une signification très semblable à unautre mot. Il en est le synonyme.

2. Termes issus de la théorie des graphes

Arbre Structure de données représentant un arbre ausens mathématique. Cas particulier de graphequi n'a qu'une seule source et aucun cycle.

Arête Les nœuds (les pères avec leurs fils) sontreliés entre eux par une arête.

Feuille Elément ne possédant pas de fils dans l'arbre.

Nœud Un nœud est, suivant le contexte, interne ouexterne.


11

Nœud externe Synonyme de feuille.

Nœud interne Elément possédant des fils (sous-branches).

Racine L'unique nœud ne possédant pas de parent.


12

Introduction Générale

Les systèmes d’information au sein des grandes entreprisessont caractérisés par une hétérogénéité, une distribution etune ouverture sur le monde extérieur, qui prennent au fil dutemps de plus en plus d’ampleur. D’innombrables imports etexports ont lieu quotidiennement, ceux-ci étant senséspermettre aux différents systèmes implantés de communiquerentre eux. Les fichiers dits «plats», utilisés dans le passépour ce genre d’échange, ont cédé la place au format XML(Extensible Markup Language). La base de données cible esttrès souvent une base de données relationnelle.

Des statistiques récentes estiment qu’un tiers du budget, dansdes projets informatiques nouveaux, est utilisé pourl’intégration d’applications. Jusqu’à 60% du budget consacré àl’informatique dans des petites et moyennes entreprisesindustrielles, va à la maintenance des interfaces entre lesdifférents systèmes [ERPM] et [CSPC].

Le système, auquel nous avons donné le nom de « OpenX2DW »,conçu et développé dans le cadre de ce Magister enInformatique, sert d’interface entre des systèmes échangeantdes données. Des données d’entrée, contenues dans un fichierXML sont chargées, grâce à ce système, dans une base dedonnées relationnelle.

Les avantages de ce système sont :

Les données d’entrée sont contenues dans un fichier XML,XML étant la base d’échanges des services web. Il suffitque le fichier XML soit simplement « well-formed ». Iln’est pas nécessaire qu’il soit accompagné d’un DTD(Document Type Definition) ou d’un XSD (XML SchemaDefinition).

La base de données cible est une base de donnéesrelationnelle. Les bases de données relationnelles sontles plus répandues. Il existe bien des bases de donnéesXML natives, mais elles ne sont pas aussi performantesque les bases de données relationnelles quand il s’agitd’une grande quantité de données à charger. L’expériencen’est pas non plus très grande en ce qui concerne lesbases de données XML natives, qui ne sont pas aussi«mures» que les bases de données relationnelles [WIKI].

Il s’agit d’un outil ETL (Extract, Transform, Load). Ildispose aussi bien d’une composante «Extraction», que descomposantes «Transformation» et «Chargement».


13

Utilisation de commandes SQL (Structured Query Language)pour les opérations de transformation et chargement. Lesystème permet à l’utilisateur de réaliser simplement uneinterface entre deux systèmes en utilisant des commandesSQL de divers degrés de complexité et de pouvoir àtravers des actions déterminées (commit, rollback,utilisation d’une règle alternative) de parer àl’éventualité de la non-exécution pour des raisonsd’intégrité, d’une de ces commandes

Matching automatique : La structure des données XMLd’entrée, qui proviennent souvent du monde extérieur, necorrespond pas toujours à la structure de la tabletransitoire. Le Matching, qui se fait ici manuellement,peut être fastidieux. Nous avons donc réservé la placedans l’architecture globale du système à un Matcherautomatique basé sur un algorithme qui fera l’objet derecherches futures. Nous avons recensé dans ce mémoireles approches existantes pour un Schema Matchingautomatique ou semi-automatique et présenté lesprototypes de Schema Matching les plus connus.

La portabilité du système sur une autre plateforme(Système d’exploitation et base de données) est assuréedu fait que les programmes aient été écrits en Java etque la construction des requêtes SQL à l’intérieur desprogrammes (« hardcoded ») pour la lecture et l’exécutiondes Rules réponde au SQL Standard (SQL’92) [Date99].OpenX2DW peut donc être implanté sur toute machine et ilest compatible avec tout RDBMS, JDBC étant utilisé commecomposant assurant la communication entre le système etle SGBD (Middelware).

Notre but a donc été de développer un système de chargement dedonnées XML dans un Data Warehouse, dont la portabilité estassurée et qui, par rapport aux outils existant :

Intègre une « Rules engine » permettant d’utiliser lelangage SQL dans les opérations de chargement et detransformation

prévoit un module de Matching dynamique

Ceci a été motivé par le fait que :

Les systèmes de chargement de données XML de fournisseursindépendants ou open source tels que le Hibernate [HIBE],ne permettent pas l’utilisation du langage SQL. Parmi lesinconvénients de Hibernate, cités par par Phutela dans«Hibernate vs JDBC» [PHUT], nous relèverons :


14

« Use of Hibernate is an overhead for the applicationswhich are:

- simple and use one database that never change

- need to put data to database tables, no further SQLqueries

- there are no objects which are mapped to twodifferent tables

- Hibernate increases extra layers and complexity. Sofor these types of applications JDBC is the bestchoice. »

OpenX2DW utilise Hibernate et compense les inconvénientsénumérés ci-dessus.

Les systèmes opérationnels connus, propriétaires ou opensource, ne prévoient pas de Matching automatique, cetaspect, encore à l’état de la recherche, n’étant encoreque partiellement traitée par des prototypes tels queceux présentés dans le troisième chapitre de ce mémoire.

Les outils ETL existant sur le marché, proposés par desfournisseurs tels que Oracle (Oracle Warehouse BuilderOWB [Dijc04]), vont de pair avec le SGBD proposé par lemême fournisseur. De cette manière, la dépendance del’utilisateur vis-à-vis du fournisseur est renforcée.

N.B.:

Les citations à partir de la littérature allemande qu’ontrouvera dans ce mémoire ont été traduites au Français, cellesen Anglais ont été reproduites en l’état.


15

1 Description du système

1.1 Architecture globale

L’architecture globale du système est donnée dans la fig. 1.Les modules qui le constituent sont :

Le Matcher, dont la fonction est de créer un fichierMapping.

Le Loader, dont la tâche est de charger le fichier XMLdans une table transitoire. Pour ce, le Loader utiliseles librairies du Framework Hibernate [HIBE]. Le Loaderse basera sur le fichier Mapping, précédemment créé parle Matcher, pour charger les données XML dans lescolonnes correspondantes de la table transitoire.

L’Archiver, dont le rôle est d’archiver un fichier déjàtraité par le Loader

La «Rules engine», qui, sur la base de règles bienprécises («Rules»), données sous forme de commandes SQL,insère les données contenues dans la table transitoiredans la base de données cible.

Des données contenues dans un fichier au format XML, provenantd’un serveur tiers ou du monde extérieur, par exemple dans lecadre d’un service web, est mis à la disposition d’un client.Le fichier XML est simplement « well formed » (les tagsouverts sont refermés); il n’est pas nécessaire qu’il soitaccompagné d’une description DTD ou XSD. Le fichier apparaîtrasur un serveur, dans un répertoire prévu à cet effet. Un «job»(Trigger), qui détectera l’arrivée d’un fichier sur lerépertoire d’accueil, que nous appellerons «Scan directory»,est exécuté en permanence, avec une fréquence déterminée, surce serveur. Le traitement est lancé aussitôt que la présenced’un fichier est détectée dans la Scan directory.

Dans le cas où le fichier de données est un fichier comprimé,il devra d’abord être décomprimé. Cette action peut êtreconfiée à un programme de compression/décompression standard(zip, flam, winrar, etc.). Une conversion doit aussi avoirlieu si les normes utilisées par l’expéditeur et ledestinataire sont différentes (EBCDIC, ASCII).

Le fichier XML est tout d’abord chargé par un premierprogramme, appelé ici «Loader», dans une table ditetransitoire. Cette appellation est due au fait que les donnéesne résident que de façon temporaire dans cette table. Lechargement se fait selon un Mapping généré par un programme,


16

appelé ici «Matcher» sur la base d’un algorithme de Matchingautomatique qui fera l’objet de recherches futures. Dans lefichier Mapping, créé pour le moment manuellement, est décritela correspondance entre la structure du fichier XML et celle,connue, de la table transitoire.

Un programme appelé «Archiver» renommera alors le fichier XML(le nom du fichier portera un «Timestamp») et l’archivera dansun répertoire donné.

Les données seront ensuite lues dans la table transitoire estréparties sur la base de données cible. Cette action estaccomplie par le programme appelé «Rules engine». Cetterépartition a lieu suivant des règles, qui ne sont autres quedes commandes SQL, elles même auparavant saisies dans unetable. La syntaxe SQL devra être celle du SQL correspondant àla base de données exploitée (Oracle, MySQL, Sybase, DB2,etc.).

Pendant tout le processus, des informations et/ou messagesd’erreur sont consignés dans un fichier Log.

Dans le cadre d’une extension future, une interface graphique(GUI), qu’on appellera «Designer», offrira plus de confortdans la saisie des Rules, la programmation du Trigger et lacréation des tables transitoires, voire de la base de donnéescible.

Un programme d’installation permettra aussi de copier lesdifférents programmes sur le poste client et de créer leursfichiers de paramètres (.ini).

Chargement de données XML dans un data warehouse

17

1

Mapping(cataLog.hbm.XML)

Base dedonnéesexterne

Fichier XML

MAPPINGGENERATOR

(generateMapping.java)

Algorithme α

FichierArchive

LOADER(loadXMLFile.java)

TRIGGER(x2dw.bat/.sh)

Tabletransitoire

Base de donnéescible

Rules

RULESENGINE

(applyRule.java)

Fichier Log

ARCHIVER(archivFile.java)

Fig.1: Architecture globale


18

1.2 Les composants du système

La fig. 2 décrit les composants du système, en les situant surdes plans fonctionnels. OpenX2DW possède une entrée, unfichier au format XML envoyé par un système source, et unesortie, qui pourrait être par exemple le résultat d’unerequête lancée à la base de données cible par le biais d’unoutil de Reporting ou de Queriying ou un Tool de BusinessIntelligence.

OpenX2DW est constitué de trois couches: la couche supérieureest nommée «contrôle du processus». C’est ici que se trouve leTrigger, donc le Job sensé démarré le processus, ainsi que lesfichiers Log contenant les messages d’informations oud’erreurs.

La couche du milieu est l’environnement «Runtime». Cettecouche contient les éléments qui constituent la fonctionvéritable du système, qui est de charger des données XML dansune base de données relationnelle.

La dernière des couches contient le Designer, qui prodigueraaux gestionnaires du système (le team ETL) plus deconvivialité dans la saisie des Rules, la programmation duTrigger et la création des tables transitoires, voire de labase de données cible.

Tous les programmes, que ce soit le Loader, le Matcher,l’Archiver ou la Rules engine sont des programmes Java.

Des commandes SQL sont incorporées dans la Rules engine. Cescommandes s’adressent à la table contenant les Rules, auxtables transitoires ou à la base de données cible.

Ces commandes sont strictement conformes au SQL-Standard ANSI.Ceci permet à l’utilisateur du système d’utiliser une base dedonnées d’un fournisseur quelconque. Les normes SQL existantesjusqu’ici sont SQL-92, SQL-99 et SQL-2003. Nous avons utiliséici le SQL-92, comme recommandé dans les Collected JavaPractices [CJAP]: «Almost all relational databases extend thestandard set of SQL commands. If these extensions are used,then portability rapidly degrades.In some applications, such portability may not be a concern.However, if portability is important, then it is clearly anadvantage to use only the standard SQL-92 commands. »

Ainsi, une table transitoire, est effacée dans le Loader de lamanière suivante:

DELETE FROM <table_name>;


19

Cette commande SQL est envoyée à la base de données contenantles tables transitoires, par le biais de JDBC, avec :

executeUpdate(Commande) ;

La Rules engine lit les Rules en vue de les exécuter avec :

SELECT Rule_code, Rule_text, alternative_Rule, if_Rulefailure,if_alternativefailure, error_level, active_status FROM Rules WHERERule_code='"+args[0]+ +"'"

Cette commande SQL est envoyée à la base de données contenantles Rules, par le biais de JDBC, avec :

executeQuery(Commande)

args[0] est ici le code de la règle à appliquer, passé commeparamètre à la Rules engine. La règle est ensuite elle-même(c'est-à-dire ici le texte de la règle) exécutée commecommande SQL.

executeUpdate(Rule_text);

Ceci est aussi valable pour la règle alternative, dans le casoù celle-ci doit être exécutée en cas d’échec de la règle.


20

1.2.1 Le Trigger

Le Trigger permet d’automatiser l’ensemble du processus.Suivant le système d’exploitation de la machine sur laquelleest installé le runtime OpenX2DW, il consiste en un «job» ou«daemon» et en une shell ou en un fichier de commandes Windows(.bat).

On dispose sous Windows, par exemple, d’un composant systèmeappelé planificateur de tâches, qui permet de lancerl’exécution d’un programme avec une fréquence prédéfinie.

Sous Windows, le système d’exploitation de la machine surlaquelle a été installé le runtime OpenX2DW, le Trigger estcomposé d’une tâche planifiée qui lance l’exécution d’unfichier de commandes (.bat). Le fichier de commandes .batrépond à la description suivante :

IF EXIST <File name> (

ECHO generating Mapping file <File name>...Appel(s) du Matcher

ECHO loading table <Table name>...Appel(s) du Loader

ECHO archiving file <File name>...Appel(s) de l’Archiver

ECHO applying Rule <Rule code>...Appel(s) de la Rules engine

)

La tâche planifiée lancera suivant la fréquence désirée lefichier .bat. La fréquence est choisie suivant les besoins. Lefichier .bat peut être exécuté plusieurs fois par jour commeil peut être exécuté une fois par mois. Matcher, Loader,Archiver et Rules engine ne sont exécutés que si vraiment lefichier <File name> est présent dans la Scan directory.

Le fichier de données au format XML ayant atterri dans la Scandirectory, c’est d’abord le Matcher qui est appelé. Le Loader,se basant sur le fichier Mapping généré par le Matcher, vaensuite être exécuté et charger les données dans les tablestransitoires. L’Archiver, qui déplacera le fichier traité versun répertoire prévu à cet effet, puis la Rules engine, quilira les données dans les tables transitoires et lesdistribuera sur la base de données cible, seront ensuiteexécutés. L’ordre suivant lequel l’Archiver et la Rules engine


21

sont exécutés n’est pas important, puisqu’au moment del’exécution de l’Archiver, les données ont déjà été chargéesdans les tables transitoires.

Pour un fichier XML à charger, le Loader est exécuté une seulefois. La Rules engine par contre peut être exécutée plusieursfois. Le nombre de fois pendant lequel elle est exécutéedépend du modèle de données de la banque de données cible etde la formulation des commandes SQL que sont les Rules.L’administrateur de bases de données peut décider, pour desraisons techniques, de rassembler plusieurs Rules en une seuleou inversement d’éclater une Rule en plusieurs. Pour la bonnelecture des Rules et la maintenance du système, il est mêmesouhaitable que soit appliqué ce dernier cas de figure.


22

Fig. 2: Les trois couches du système


TRIGGER(x2dw.bat/.sh)

DESIGN CLIENT(GUI)

Fichier XML

Mapping(cataLog.hbm.XML

)


Tabletransitoire

Fichier Log

Base dedonnées cible

Rules

RULESENGINE

(applyRule.java)

Contrôle du processus

Environnement RuntimeUmgebung

Design et paramétrage

ARCHIVER(archivFile.java)Fichier

Archive

MAPPINGGENERATOR



23

1.2.2 Le Matcher

Le rôle du Matcher est de créer, sur la base d’un algorithmede Matching automatique, le fichier Mapping. Le Loader sebasera sur ce fichier Mapping, lui-même au format XML, pourcharger les données XML dans les colonnes correspondantes dela table transitoire.

La création automatique du fichier Mapping, dont un exempleest donné ci-dessous, bien que prévue dans l’architectureglobale du système, a encore lieu manuellement.

<?XML version="1.0"?><!DOCTYPE hibernate-Mapping PUBLIC"-//Hibernate/Hibernate Mapping DTD 3.0//EN""http://hibernate.sourceforge.net/hibernate-Mapping-3.0.dtd"><hibernate-Mapping><class entity-name="catalog" node="catalog" table="CATALOG">

<id name="catalogId" node="catalogId" column="CATALOGID" type="string"/><property name="journal" node="journal" column="JOURNAL" type="string"/><property name="publisher" node="publisher" column="PUBLISHER" type="string"/><property name="edition" node="edition" column="EDITION" type="string"/><property name="title" node="title" column="TITLE" type="string"/><property name="author" node="author" column="AUTHOR" type="string"/>

</class></hibernate-Mapping>

La syntaxe pour l’appel du Matcher est la suivante:

ECHO generate Mapping file ...java -jar generateMapping.jar <File_name> <MappingFile_name>

où:

<File_name> est le nom du fichier XML à charger.

<MappingFile_name> est le nom du fichier Mapping généré par le Matcher.

Le Matcher est un programme Java qui a été packagé en unfichier Jar. generateMapping.jar est le nom de ce fichier.

Le Matcher requiert le renseignement de certains paramètrescontenus dans un fichier de configuration (fichier .ini).Cette action a lieu lors du lancement du programmed’installation, sur la base des informations fournies par leteam ETL. Parmi ces paramètres figurent le chemin pour la ScanDirectory, le chemin pour le fichier Mapping généré par leMatcher ainsi que le nom, le chemin et la dimension maximaledu fichier Log.

Un exemple de fichier de configuration pour le Matcher estdonné ci-dessous :


24

[Data File]Directory=C:\OpenX2DW\production\dataExtension=XML

[Mapping File]Directory=C:\OpenX2DW\production\MappingExtension=XML

[Log]Directory=C:\OpenX2DW\productionName=OpenX2DW.logSize=1000

[Mail]Server = mail.kit-consulting.netAddress = [email protected] = SUser = w006131bPassword = xlGlsNu09pQ=

Un protocole de l’exécution du Matcher est tenu à traversl’enregistrement de messages dans le fichier Log. On pourratrouver dans ce fichier des informations telles que le nom dufichier XML ainsi que le nom du fichier Mapping généré. Desmessages d’erreurs éventuelles sont écrits dans le fichierLog. Un enregistrement dans le fichier Log a la structuresuivante :

<Date> <Heure> <Type de message> <Texte du Message>

Le type de message est = ”I” pour Information= ”S” pour sévère

L’exécution du Matcher a lieu suivant le schéma suivant:

- Début de programme; Initialisation des variables;- Lecture des paramètres à partir du fichier .ini;- Ouverture du fichier Log s’il existe, création d’un fichier Log sinon;- Analyse du fichier XML;- Génération du fichier Mapping ;- Fermeture des fichiers ouverts; Fin de programme;


25

1.2.3 Le Loader

La fonction du Loader est de charger des données XML dans unetable transitoire d’une base de données relationnelle d’unfournisseur quelconque (Oracle, SQL-Server, DB2, mySQL, etc.).

1.2.3.1 Hibernate

Le Loader conçu et développé dans le cadre de ce travail estbasé sur le Framework open source Hibernate et utilise deslibrairies mises à la disposition des utilisateurs de cesystème.

Hibernate et sa capacité à charger des données XML dans unetable est décrite par Deepak Vohra [JABO] comme suit :«Hibernate is an open source object/relational persistence andquery service for Java. Hibernate's latest version, 3.x,introduces a new feature: XML-to-database Mapping, whichallows you to map data representation in an XML document to adatabase (of which Hibernate supports several - including DB2,MySQL, Oracle, and PostgreSQL). With Hibernate, you map yourXML document nodes to database columns. Only an XML Mappingfile is required to map an XML document to a database table; aPOJO is not required. Hibernate generates the required SQL tocreate, update, and delete database tables. You can also useit to generate tables from a Hibernate configuration file andadd data to a database table from an XML document. You canretrieve database table data as an XML document and update itfrom that XML document. Further, Hibernate 3.x supports dom4jAPI for XML processing. Hibernate also provides classes forAnt build tasks.».

Nous retiendrons donc de la citation ci-dessus qu’avec leFramework Hibernate, seul est nécessaire, pour le chargementdes données, un fichier Mapping, établissant la correspondanceentre la structure du fichier XML d’entrée et celle de latable destinée à recevoir les données (pour nous, la tabletransitoire).

Un chargement de données XML vers une base de donnéesrelationnelle sans persistance nécessite un programmespécifique au fournisseur de la base de données tel que XMLExtender ou une API telle que XML SQL Utility. JDBC 4.0 aintroduit un nouveau type de données SQLXML pour charger undocument XML dans la colonne de type XML. JDBC 4.0 n’existemalheureusement pas encore pour l’ensemble des bases dedonnées. Hibernate’s XML persistance offre cette possibilité.

Les avantages de Hibernate par rapport à JDBC dans ce contextesont énoncés par Phutela dans «Hibernate vs JDBC» [PHUT] :


26

«Working with both Object-Oriented software and RelationalDatabase is complicated task with JDBC because there ismismatch between how data is represented in objects versusrelational database. So with JDBC, developer has to write codeto map an object model's data representation to a relationaldata model and its corresponding database schema. Hibernate isflexible and powerful ORM solution to map Java classes todatabase tables. Hibernate itself takes care of this mappingusing XML files so developer does not need to write code forthis.»

1.2.3.2 Simple API for XML (SAX)

Pour l’analyse du document XML, Hibernate utilise un parseurSAX. SAX (Simple API for XML) est un standard de fait quidécrit une API (Application Programming Interface) pourl’analyse de données XML. Un SAX-Parseur lit les données XMLcomme flux de données séquentiel et appelle des fonctionsprédéfinies callback (callback function) pour les évènementsdéfinis dans le standard. Une application qui utilise SAX peutenregistrer ses propres sous-programmes comme fonctionscallback et exploiter de cette manière les données XML. SAX, àl’inverse de DOM, est évènementiel.

SAX travaille suivant la notion de pipeline. Il définit unensemble d’évènements, qui peuvent apparaître lors de lalecture séquentielle du document XML. En reconnaissant unestructure syntaxique, l’analyseur syntaxique (parseur) lanceune routine de traitement, qui exécute, le cas échéant uneroutine individuelle de l’évènement.

Ainsi l’exploitation des données peut commencer dès la lecturedes premiers caractères. Ceci a pour conséquence d’écourterles temps d’accès. SAX minimise en même temps les besoins encapacité de stockage, puisque en mémoire ne figurent, à cotéde l’élément lu, que les données explicitement sélectionnéespar la routine de traitement. Les évènements sont injectésdans le parseur parallèlement à la lecture du document.

Considérons le document suivant:

<?XML version="1.0"?><seminaire>

<titre>DOM, SAX et SOAP</titre><contenu>

<chapitre value="1">Introduction</chapitre><chapitre value="2">Sujet</chapitre><chapitre value="3">Conclusion</chapitre>

</contenu></seminaire>


27

Les évènements générés par un parseur SAX seront, à la lecturedu document ci-dessous, les suivants :

startDocument()startElement("seminaire",[])startElement("titre",[])

character("DOM, SAX et SOAP")endElement("titre")startElement("contenu",[])startElement("chapitre", ["value="1""])character("introduction")endElement("chapitre")

...

Le parseur interrompt son travail à chaque évènement et attendque le programme appelant lui redonne la main. Celui-ci peutpendant ce temps lancer un traitement.

DOM (Document Object Model), contrairement à SAX utilisé dansle Framework Hibernate, utilise une approche hiérarchique. Unparseur DOM construit une structure hiérarchique contenant desobjets représentant les éléments du document. Le documentdonné ci-dessous serait décomposé suivant l’arbre suivant :

1.2.3.3 Utilisation du Framework Hibernate dans le Loader

La première action à entreprendre est de préciser dans lefichier de paramètres de Hibernate (hibernate.properties) labase de données, le driver JDBC et l’URL de connexionutilisés.

Dans l’exemple ci-dessous, Hibernate est configuré pourutiliser une base de données Oracle 10g et charger les donnéesdans une table du schéma «Scott» dont le mot de passe est

seminaire

titre contenu

chapitre

Fig. 3: Exemple de structure hiérarchique construite par un parseur DOM


28

«tiger». Le nom de la base de données est «orcl», et elle estconfigurée pour recevoir les requêtes sur le port 1521.

## MySQL

##hibernate.dialect org.hibernate.dialect.MySQLDialect#hibernate.dialect org.hibernate.dialect.MySQLInnoDBDialect##hibernate.dialect org.hibernate.dialect.MySQLMyISAMDialect#hibernate.connection.driver_class com.mysql.jdbc.Driver#hibernate.connection.url jdbc:mysql://poire:3306/x2dw#hibernate.connection.username root#hibernate.connection.password Amadeus

## Oracle

#hibernate.dialect org.hibernate.dialect.OracleDialecthibernate.dialect org.hibernate.dialect.Oracle10gDialecthibernate.connection.driver_class oracle.jdbc.driver.OracleDriverhibernate.connection.username scotthibernate.connection.password tigerhibernate.connection.url jdbc:oracle:thin:@poire:1521:orcl

L’utilisation de MySQL est donnée en commentaire. Le nom del’utilisateur aurait été «root» et le mot de passe «Amadeus».La base de donnée est x2dw et elle est configurée pourrecevoir des données sur le port 3306.

Pour pouvoir charger les données XML dans la tabletransitoire, Hibernate nécessite le fichier Mapping auparavantcréé par le Matcher. Un exemple de fichier Mapping est donnépage 24.

Les packages jar de Hibernate nécessaires sont les suivants :

JAR/Zip File Description

<Hibernate3.1>/hibernate3.jar

Classes API Hibernate, y comprisla classeorg.hibernate.tool.hbm2ddl.SchemaExport

<Hibernate3.1>/lib/dom4j-1.6.1.jar<Hibernate3.1>/lib/commons-logging-1.0.4.jar<Hibernate3.1>/lib/commons-collections-2.1.1.jar<Hibernate3.1>/lib/ehcache-1.1.jar<Hibernate3.1>/lib/cglib-2.1.3.jar<Hibernate3.1>/lib/jta.jar<Hibernate3.1>/lib/asm.jar<Hibernate3.1>/lib/antlr-2.7.6rc1.jar<Hibernate3.1>/lib/jaxen-1.1-beta-7.jar

Classes Hibernate auxiliaires

A ceci il faut rajouter le JDBC pour l’accès à la base dedonnées. Dans le cas d’Oracle :


29

<Oracle10g>/jdbc/lib/ojdbc14.jar


30

La syntaxe pour l’appel du Loader est la suivante:

ECHO loading table CATALOG ...java -jar loadXMLFile.jar <File_name> <MappingFile_name>

Où:

<File_name> est le nom du fichier XML à charger.

<MappingFile_name> est le nom du fichier Mapping généré par leMatcher.

Le Loader est un programme Java qui a été packagé en unfichier Jar. LoadXMLFile.jar est le nom de ce fichier.

Un fichier Mapping est nécessaire pour pouvoir charger lesdonnées contenues dans le fichier XML dans une tabletransitoire. Le fichier Mapping porte le même nom que la tabletransitoire.

Le Loader, tout comme les autres modules du système, requiertle renseignement de certains paramètres contenus dans unfichier de configuration (fichier .ini). Cette action a lieulors du lancement du programme d’installation, sur la base desinformations fournies par le team ETL. Parmi ces paramètresfigurent le chemin pour la Scan Directory, le chemin pour lefichier Mapping généré par le Matcher, les informations pourl’accès à la base de données contenant les tablestransitoires, le nom, le chemin et la dimension maximale dufichier Log.

Le mot de passe pour l’accès à la base de données est crypté.Le cryptage est pris en charge par le programmed’installation. Le mot de passe est lu par le Loader dans lefichier de configuration et décrypté. Un exemple de fichier deconfiguration pour le Loader est donné ci-dessous :


[Configuration File]Directory=C:\OpenX2DW\production\MappingExtension=XML

[Transient Database]Database=mysqlHost=poirePort=3306SID=x2dw


31

User=rootPassword=6LMVoJ+x9QvWsSXArQ0ziw==



Un protocole de l’exécution du Loader est porté dans lefichier Log. On pourra trouver dans ce fichier desinformations telles que le nom du fichier XML, le nom dufichier Mapping, et le nom de la table transitoire traités parle Loader. Des messages d’erreurs éventuelles sont écrits dansle fichier Log, ainsi que les actions entreprises dans ce cas.Un enregistrement dans le fichier Log a la structuresuivante :

<Date> <Heure> <Type de message> <Texte du Message>

Le type de message est = ”I” pour Information= ”S” pour sévère

Le déroulement du programme a lieu suivant le schéma suivant:

- Début de programme ; Initialisation des variables;- Lire des paramètres à partir du fichier .ini;- Ouvrir le fichier Log s’il existe, création d’un fichier Logsinon;- Décrypter le mot de passé pour l’accès à la base de données;- Connexion à la base de données;- Supprimer le contenu de la table transitoire (DELETE et non pasDROP Table) ;- Appeler la classe Hibernate3.saveXMLDocument pour le chargementdes données XML dans la table transitoire; Les deux paramètrespassées à cette classe sont le nom du fichier XML à charger ainsique le nom du fichier Mapping ;- Fermer les fichiers ouverts; Fin de programme;

L’appel de la classe Hibernate.saveXMLDocument se déroulesuivant les étapes suivantes :


32

La création d’un objet Configuration a d’abord lieu. La classeorg.hibernate.cfg.Configuration est utilisée pour spécifier lespropriétés de la configuration et les fichiers Mapping en vuede la création d’une SessionFactory.

Configuration config=new Configuration();

Le fichier Mapping, auparavant créé par le Matcher est ensuiteajouté à la configuration:

config.addFile("<Fichier_Mapping>");

org.hibernate.Session est l’interface principale entre uneapplication Java et Hibernate. Un objet Session est obtenuavec l’appel de SessionFactory. L’interface SessionFactory offre lamethode openSession() pour la création d’une connexion à la basede données et ouvre une session dans la connexion.

SessionFactory sessionFactory=config.buildSessioFactory();Session sess =sessionFactory.openSession();

Un objet Transaction est obtenu à partir de la Session en vued’insérer des données dans la table transitoire:

org.hibernate.Transaction tx = sess.beginTransaction();

Une session est ouverte avec comme entity mode DOM4J. Lasession secondaire a la même connexion, transaction que lasession primaire. DOM4J (DOM for Java) est une API Javapermettant de travailler avec des documents XML. DOM4J estcompatible avec les standards SAX, DOM et JAXP.

Session dom4jSession = session.getSession(EntityMode.DOM4J);

Un SAXReader est créé pour analyser (parse) le document XMLqui doit être «persisté» à la base de données. L’analyse dudocument XML a lieu à travers l’utilisation de la méthode

read(File):


33

SAXReader saxReader = new SAXReader();Document document = saxReader.read(newFile("c:/Hibernate/catalog.XML"));

Une liste des noeuds de l’objet document est obtenue, puis estcréé un objet Iterator pour l’objet List:

List list = document.selectNodes("//catalog");Iterator iter = list.iterator();

L’objet List est parcouru dans une itération dans le but derécupérer les objets noeuds. Ceux-ci sont sauvegardés dans la

base de données à travers l’utilisation de la méthode save(String

entityName, Object object). La méthode flush() est utilisée pour la

synchronisation de la base de données avec les nœuds du

document XML dans l’objet Session:

while (iter.hasNext()) {Object catalog = iter.next();dom4jSession.save("catalog", catalog);

}

Un flush de la session a finalement lieu, ainsi qu’un commitde la transaction. Après quoi la session est fermée:

session.flush();tx.commit();session.close();


34

1.2.4 Le Archiver

La fonction de l’Archiver est d’archiver un fichier XML, déjàtraité par le Loader, dans un répertoire prévu à cet effet. Lenom du fichier archivé porte un Timestamp.

La syntaxe pour l’appel de l’Archiver est la suivante:

java -jar archivFile.jar ARCHIV FILE <File_name>

où:

<File_name> est le nom du fichier XML à archiver.

archivFile.jar est le nom du programme Java compacté, que nousavons appelé Archiver.

Ici aussi des données de configuration sont stockées dans unfichier .ini qui sera créé par le programme d’installation surla base des informations fournies par le team ETL durantl’installation. Parmi ces paramètres figurent: Chemin d’accèsà la Scan directory, chemin du répertoire d’archivage, cheminet volume maximal autorisé du fichier Log.


[Archiv]Directory=C:\OpenX2DW\production\backupExtension=bak



L’archivage des fichiers de données a lieu, après leurtraitement par le Matcher et le Loader, suivant le schémasuivant:


35

- Début de programme ; Initialisation des variables;- Lire les paramètres de configuration à partir du fichier .ini;- Ouvrir le fichier Log s’il existe, créer un fichier Log sinon;- Déterminer le Timestamp;- Renommer le fichier XML: Le nouveau nom contient le Timestamp;- Copier le fichier XML renommé dans le répertoire archive;- Supprimer le fichier XML original;

Dans le fichier Log, les étapes suivantes sont portées dans leprotocole: Changement de nom du fichier, copie du fichier,suppression du fichier. La structure du fichier Log estidentique à celle du fichier Log du Matcher ou du Loader. Letype de message est «I», si l’action a abouti ou «E» dans lecas contraire.


36

1.2.5 La Rules engine

Les données XML étant chargées dans les tables transitoires,les Rules peuvent être aussitôt exécutées.

Une Rule est exécutée à travers l’appel de la Rules Engine, àlaquelle est transmis le code d’une Rule:

java -jar applyRule.jar <être code>

où

<être code> étant le code de la être à exécuter

La Rule, c’est à dire le texte de la commande SQL, est stockéedans la table des Rules. La structure de cette table est lasuivante:

Nom de colonne Type Longueur Valeurs possibles Default

RULE_CODE Character 5

RULE_TEXT TextLONGTEXT/CLOB

ALTERNATIVE_RULE TextLONGTEXT/CLOB

IF_RULEFAILURE Character 1

”R” pour Rollback”C” pour Commit”A” pour Applyalternative être

”R”

IF_ALTERNATIVEFAILURE Character 1”R” pour Rollback”C” pour Commit

”R”

ERROR_LEVEL Character 1

”I” pourInformation”W” pour Warning”E” pour Error”S” pour Severe

”S”

COMMENTS Character 255

ACTIVE_STATUS Character 1”Y” pour Yes”N” pour No

”N”

Le script de création de cette table pour Oracle 10g parexemple, est le suivant:

CREATE TABLE rules (rule_code VARCHAR2(5) NOT NULL,rule_text CLOB,alternative_rule CLOB,if_rulefailure CHAR(1) DEFAULT 'R',if_alternativefailure CHAR(1) DEFAULT 'R',error_level CHAR(1) DEFAULT 'S',


37

date_created DATE DEFAULT NULL,comments VARCHAR2(255) DEFAULT NULL,active_status CHAR(1) DEFAULT 'N',PRIMARY KEY(rule_code)

);

Rule-Code est ici un identifiant (Primary key).

Une Rule peut consister en une commande DML (Data ManipulationLanguage) quelconque. Le team ETL est responsable de saformulation. C’est à lui à veiller à sa logique, c'est-à-direà ce que les informations soient écrites au bon endroit dansla base de données cible et dans la forme requise. Comme pourtoute base de données relationnelle, les clés primaires(primary keys), les clés étrangères (foreign keys) ainsi queles autres contraintes d’intégrité (check constraints) doiventêtre prévues partout où la nécessité s’impose. Dans le cas oùun enregistrement ne répond pas aux contraintes existantes, laRules engine interceptera le message d’erreur émis par la basede données et le transmettra au team ETL en l’enregistrantdans le fichier Log.

Aussi le team ETL doit s’assurer du bon ordre d’exécution desRules. Dans le cas où une tentative d’insertion d’unenregistrement «fils» a lieu avant que ne le soitl’enregistrement «parent», l’insertion échoue.

Il peut être indiqué, à titre d’exemple, d’utiliser lorsqu’ils’agit d’une base de données MySQL la commande «REPLACE» aulieu de la commande «INSERT». Un «REPLACE» peut correspondreau désir des utilisateurs, d’«écraser» (mettre à jour) unenregistrement existant déjà dans la base de données par unnouvel enregistrement comportant la même clé primaire quel’enregistrement existant. Essayer dans ce cas là d’insérer unenregistrement avec une commande «INSERT» mènerait à uneerreur.

Comme pour les autres éléments du système, les paramètres deconfiguration de la Rules engine sont stockés dans un fichier.ini, parmi ceux-ci les informations pour l’accès à la base dedonnées contenant la table Rules, et à celle contenant lestables transitoires et la base de données cible, sontrenseignées Le fichier .ini sera créé par le programmed’installation à partir des données fournies par le team ETLlors de l’installation. Le mot de passe sera écrit dans lefichier .ini sous forme crypté.


38

[Target Database]Database=oracleHost=localhostPort=1521SID=orclUser=scottPassword=NJDBxORWkzY=

[Rules Database]Database=oracleHost=localhostPort=1521SID=orclUser=scottPassword=NJDBxORWkzY=

[Log]Directory=C:\OpenX2DW\productionName=OpenX2DW.LogSize=1000


Une Rule peut être désactivée. Sa mise en oeuvre n’aura paslieu, même si le code de cette Rule est transmis à la Rulesengine pour exécution. Un message d’erreur sera simplementécrit dans le fichier Log. Le team ETL a aussi la possibilitéde préciser, dans le cas où l’exécution de la Rule échoue, siun «Commit», un «Rollback» ou une Rule alternative doit êtreexécuté. Un «Commit» ou un «Rollback» pourront être de nouveauexécutés si la Rule alternative, n’a pas pu être mise en œuvreà son tour. Le Pseudocode suivant décrit le déroulement del’exécution du programme.


39

- Début de programme; Initialisation des variables;- Lecture des paramètres de configuration à partir du fichier .ini;- Décryptage du mot de passe pour l’accès à la base de donnéescontenant la table Rules;- Connexion à la base de données contenant la table Rules;- Lecture de la table Rules pour le code Rule donné;- Fermeture de la connexion;- Décryptage du mot de passe pour l’accès à la base de donnéescible;- Connexion à la base de données cible;- Désactivation de l’option «Autocommit»;- Si la Rule est désactivée : Ecrire l’information dans le fichierLog et quitter le programme;- Exécuter la Rule;- Si l’exécution de la Rule est réussie {

- Commit;- Quitter le programme;

} - Si l’exécution de la Rule n’est pas réussie {- Si un ”Commit” doit avoir lieu {


} - Si un ”Rollback” doit avoir lieu {- Rollback;- Quitter le programme;

} - Si la Rule alternative doit être exécutée {- Rollback;- Exécuter la Rule Alternative;- Si l’exécution de la Rule alternative est réussie {


} - Si l’exécution de la Rule alternative n’est pasréussie {

- Si un ”Commit” doit avoir lieu {- Commit;- Quitter le programme;

}- Si un ”Rollback” doit avoir lieu {- Rollback;- Quitter le programme;

}}

}}


40

1.2.6 Environnement de développement et de test

OpenX2DW a été développé sous Windows XP Pro et testé sousWindows XP Pro et Windows Server 2003.

Le Trigger est ce qui est appelé sous Windows une «tâcheplanifiée» qui lance l’exécution d’un fichier de commandes MS-DOS (.bat). Ceci correspond sous Unix/Linux à un Dämon et uneShell.

OpenX2DW est constitué de plusieurs programmes Java qui ontété packagé en fichiers Jar. Un environnement runtime j2re-1.4.2 ou postérieur doit être installé Sur le poste client.

Une classe Java pour la lecture/écriture de fichiers deparamètres (.ini), mise à la disposition comme freeware, desdéveloppeurs Java par son auteur [KHAN], a été téléchargée àpartir de l’Internet et utilisée.

Les mots de passe pour la connexion aux bases de données cibleet contenant les tables transitoires et les Rules sont stockésdans les fichiers de paramètres .ini. Ces mots de passe sontécrits par le programme d’installation qui les crypteauparavant. Ils sont lus par les différents programmes etdécryptés. Une classe du Java Developers Almanac 1.4 [TJDA] aété utilisée pour leur cryptage et décryptage. Le cryptage estbasé sur le Data Encryption Standard (DES) avec utilisationd’une « Pass Phrase ».

Parallèlement à l’écriture des messages d’informations oud’erreurs dans le fichier Log, OpenX2DW offre la possibilitéde les envoyer à une adresse Mail donnée. L’utilisateur peutsaisir, lors du processus d’installation, les informationspermettant la connexion à un Serveur SMTP. Cette option a étéréalisée à travers l’importation des packages Java javax.mailet javax.mail.internet. Les paramètres mail.smtp.host etmail.smtp.auth étant définis, une Mail Session est ouverte, àl’intérieur de laquelle un message est instancié. L’ensembledes caractéristiques du message sont complétées avec lesméthodes setRecipient, setContent et setSubject. Le messageest envoyé avec Transport.send(<myMessage>). Les paramètres deMailing sont à donner lors de l’installation des programmes ;ils figurent sur les fichiers de configuration créés par leprogramme d’installation. Les paramètres de Mailing sont : lenom du serveur SMTP, l’adresse mail du destinataire desmessages, le type de messages qui doivent être envoyés (sévères ou moins sévères) ainsi que le code-utilisateur et lemot de passe pour l’accès au serveur SMTP.


41


NetBeans [NETB] a été utilisé comme environnement dedéveloppement Java. NetBeans est un produit distribué à titrebénévole par Sun Microsystems. Sun ONE Studio est une versionpayante de ce même produit.

Les différents tests ont d’abord eu lieu sur une base dedonnées MySQL 5.0 puis sur une base de données Oracle 10g.

MySQL dispose d’une licence GPL ou commerciale [MYSD]. MySQLpeut être exploité sous Windows, sur la plupart des variantesUnix, sur Mac OS X et OS/2. Pour la gestion des bases dedonnées MySQL il est possible d’utiliser l’interpréteur decommandes (Commandes mysql et mysqladmin). Une alternative à celaest d’utiliser l’application Open Source phpMyAdmin. Celle-cinécessite l’installation d’un serveur Web et de PHP. Une autrealternative encore serait d’utiliser les outils MySQLAdministrator et MySQL Query Browser de la société MySQL AB[MSQA]. MySQL dispose de différents types de tables: MyISAM,InnoDB, Berkeley DB. Un procédé transactionnel n’est possiblequ’avec des tables du type InnoDB. Etant donné que la Rulesengine déclenche un COMMIT ou un ROLLBACK dans le cas del’échec de l’application d’une Rule, c’est bien ce type detable qui a été choisi. Le texte des rules est stocké dans unecolonne de type LONGTEXT.

C’est le JDBC MySQL de la société MySQL AB [MSQA] qui a étéutilisé comme Middleware. Celui-ci est sous licence GPL. Laconnexion a lieu de la manière suivante:

String url="jdbc:mysql://localhost:3306/X2DW_target?user=root&password=bonjour";/*** Connection to MySQL DB**/

try {Class.forName("com.mysql.jdbc.Driver").newInstance();

} catch (Exception e) {System.out.println ("ClassNotFoundException: ");System.out.println (e.getMessage());

}try {connect = DriverManager.getConnection(url);System.out.println ("Connection to DB successfull");


42

} catch(SQLException e) {System.out.println("SQLException: " + e.getMessage());

}

Le Driver est tout d’abord chargé avecClass.forName("com.mysql.jdbc.Driver").newInstance().L’instanciation du Driver a lieu avec l’appel de Class.forNameautomatiquement. Le Driver se connecte ensuite avecDriverManager.getConnection(url) à l’URL donnée. L’URLcontient les informations de connexion: Host, Port, User etPassword. La connexion aux bases de données a été renduepossible grâce à l’importation des packages Java java.net etsql.net.

Oracle 10g, l’autre base de données sur laquelle le système aété testé, soumis à une licence commerciale, existe aussi sousnombre de systèmes d’exploitation, y compris sous Linux. Ilest possible d’utiliser pour la gestion de la base de donnéesOEM (Oracle Enterprise Manager) ou des outils tiers, tels queToad for Oracle de Quest Software. Le texte des Rules eststocké dans une colonne de type CLOB.

Le JDBC est fourni par Oracle sous forme de .jar(ojdbc14.jar). Les classes permettant de charger le driversont importés en début de programme. Comme donné ci-dessous,l’instanciation de la source de données a lieuavec: OracleDataSource ods = new OracleDataSource(). Laconnection à la source de données a lieu avec : connect =ods.getConnection(). L’URL contient les informations deconnexion Host, Port et SID. Le nom d’utilisateur et le mot depasse sont envoyés à la source de données comme paramètresavec les méthodes setUser et setPassword.

String url="jdbc:"+dbDatabase+":thin:@"+dbHost+":"+dbPort+":"+dbSID;try {OracleDataSource ods = new OracleDataSource();ods = new OracleDataSource();ods.setURL(url);ods.setUser(dbUser);ods.setPassword(decryptedPass);connect = ods.getConnection();System.out.println("connected to Oracle DB ...");

} catch (ExceptionInInitializerError eie) {System.out.println eie.getMessage()+"\n")) {

return;}


43

1.3 Conclusion

Le système décrit ci-dessus est donc prêt à être implémenté.Des données XML peuvent être chargées dans un Data warehouseutilisant un SGBD Oracle 10g ou MySQL 5.0. Notre intentionétant de faire de ce système un produit Open Source, le driverd’un autre SGBD (SQL Server, Sybase, etc.) peut êtrefacilement inclus dans les modules du système qui accèdent àla base de données, en l’occurrence le Loader et la RulesEngine.

Le fichier Mapping étant créé manuellement, le système ne peuttoutefois être utilisé que si la structure des données XML enentrée est connue. Ceci est valable dans le cas par exempled’un abonnement à un service web externe fournissant unfichier XML dont la structure est invariable (éléments ayanttoujours le même nom et le même type).


44

2 Le système dans un procédé ETL et dans un « environnementdistribué »

2.1 Data warehouse, définition et concepts

Un entrepôt de données (ou Data warehouse) « désigne une basede données utilisée pour collecter et stocker de manièredéfinitive des informations volatiles provenant d'autres basesde données (…). Les informations collectées serviront à fairedes statistiques, des recherches et des rapports. Lesentrepôts de données sont utilisés notamment en informatiquedécisionnelle » [WIKI].

Les données contenues dans un Data warehouse sont,contrairement aux données d’un système de production :

non volatiles : elles ne peuvent être ni modifiées nieffacées

intégrées, dans la mesure où elles proviennent dediverses sources hétérogènes

datées. Ceci permet une historisation de l’information etoffre la possibilité de suivi de l’évolution desindicateurs à analyser.

« En amont de l'entrepôt de données se place toute lalogistique d'alimentation des données de l'entrepôt :extraction des données de production, transformationséventuelles et chargement de l'entrepôt (c'est l'ETL ouExtract, Transform and Load ou encore datapumping) » [WIKI]alors qu’ « en aval de l'entrepôt de données (…) se place toutl'outillage de restitution et d'analyse des données (enanglais : Business Intelligence) : outils de requêtage ou dereporting, cubes ou hypercubes multidimensionnels, datamining » [WIKI].

2.2 OpenX2DW dans un procédé ETL

Comme on peut le voir sur la Fig. 4, OpenX2DW possède, dupoint de vue du Data Warehousing, une composante d’extraction,une de transformation et une de chargement. Les utilisateursdu système sont le team ETL, comme désigné dans la littérature[Kimb04].

«La découverte et l’indication de modifications dans lesdifférentes sources qui alimentent le Data Warehouse»,désignées par Bauer et Günzel [Baue04] par «Monitoring», estconfié ici aux systèmes sources.

Ce que nous avons appelé dans OpenX2DW Loader, est un«Extractor». Les extracteurs sélectionnent et transportent les


45

données à partir des sources dans la zone de travail»[Baue04]. La zone de travail (Staging area) correspond dansX2DW aux tables transitoires.

Le Loader sélectionne les données dans le fichier de donnéesXML sur la base du fichier Mapping généré par le Matcher pourles transporter vers les tables transitoires correspondantes.Le Loader contribue ainsi au transport des données vers lazone de travail.

La Rules engine est Transformator, puisqu’elle intervient dansle traitement des clés primaires. «Le traitement des clés estune tâche importante. Des clés peuvent, lors du transfert dedonnées à partir de plusieurs sources de données vers un Data-Warehouse, ne pas être prises en charge, étant donné qu’ellesdoivent être uniques. Dans le cadre des transformations, desersatz aux clés sources sont créées artificiellement»[Baue04]. La création d’ersatz est confiée ici à la Rulesengine. Une même pièce de rechange pouvant être stockée dansdeux magasins différents, il sera tout indiqué de combiner lecode de la pièce de rechange avec le code du magasin etconstruire ainsi pour la pièce de rechange un code unique. Decette manière l’information concernant un même article etprovenant d’un même magasin (c'est-à-dire d’une même source)sera reconnue et rejetée ou traitée. OpenX2DW devient ainsimulti-sites, dans ce cas donc multi-magasins.

Une adaptation du format des données de type date, lors dutransfert de données des tables transitoires vers la base dedonnées cible est très souvent inévitable. La donnée issued’une colonne de type caractères d’une table transitoire doitêtre transformée en une donnée de type date avant de pouvoirêtre stockée dans une colonne du même type dans une table dela base de données cible.

Aussi des chiffres sont chargés à partir du fichier XML dansdes colonnes des tables transitoires de type caractères. Ceschiffres peuvent contenir un point ou une virgule commeséparateur de décimales. Une transformation adéquate de lachaîne de caractères pour son stockage dans une colonne detype décimal, doit avoir lieu dans la Rule. D’autrestransformations peuvent avoir lieu : conversion de monnaie,conversion de mesures, mises à l’échelle, agrégation. Touttype de commande SQL est permis pour cela, à condition que lacommande SQL réponde à la syntaxe autorisé par le RDBMS enplace et à la sémantique du modèle de données. La logiqueapplicative doit être naturellement aussi observée.Contrairement aux erreurs syntaxiques et sémantiques, aucuneerreur n’est signalée dans ce cas là.


46

La Rules engine, qui est, suivant la définition précédente,Transformator, est en même temps un composant Loader duprocessus ETL. Les composants Loader «chargent des donnéestransformées après achèvement du processus d’acquisition, àpartir de la zone de travail dans le Data Warehouse» [Baue04].

La composante analytique dans OpenX2DW consisterait en desoutils externes standard de reporting et d’analyse. Lescomposants analytiques «sont qualifiés pour l’analyse et laprésentation des données contenues dans le Data warehouse».

Dans «Das Data Warehouse-Konzept» Mucksch et Behme [Muck00]recommandent : «Les règles résultant des processusd’extraction, transformation, de correspondance et dedéfinition doivent être stockées sous forme de Meta Data ; encas de modification ou d’extension des données sources, il nesera pas nécessaire de modifier les programmes d’interface,mais simplement d’adapter les Meta Data » [Muck00].

Cette recommandation est prise en compte avec OpenX2DW étantdonné qu’en cas de changement dans la structure des donnéessources, les structures des tables transitoires ainsi que lesRules doivent être modifiées mais en aucun cas les programmes.En effet, la Rules engine se limite à « lire » les Rules -qui doivent tenir compte quand à elles des modifications destructure - et à les appliquer.

Plus loin sont présentées les techniques et méthodes enrapport avec l’extraction de données. Une différence est faiteentre un Data refresh et un Data update. «S’agissant d’un Datarefresh, les données du Data warehouse sont simplement«écrasées» par les données du système source, indépendammentdu fait que celles-ci aient changées ou pas» [Muck00]. ParData update «il s’agit d’un processus automatisé transportantdes données à partir de l’environnement source versl’environnement cible à des intervalles prédéfini. Il s’agitde ne transporter que les données qui ont été modifiées dansle système source depuis le dernier Update» [Muck00].

Un Refresh peut avoir lieu dans OpenX2DW simplement à traversun INSERT ou un REPLACE. On peut imaginer un scénario danslequel les enregistrements dans le fichier XML porteraient unTimestamp. Cette information existerait donc dans les fichierstransitoires. La Rule pour la sélection des données dans lestables transitoires et leur chargement dans le Data warehouseconsisterait en une commande SQL comportant une clause WHERE:


47

WHERE <timestamp dans enregistrement de la table transitoire> ><timestamp dans enregistrement dans la base de données cible>

«Des défauts aussi bien syntaxiques que sémantiques peuventêtre reconnus dans le cadre de l’assainissement de données»[Muck00]. Leur découverte et leur correction peuvent êtreautomatisées ou manuelles. Ceci peut être réalisé dansOpenX2DW dans la formulation de la Rule. Il est concevableaussi que soient développés dans ce but des Triggers base dedonnée réagissant à l’insertion d’enregistrements dans lestables transitoires. Les Triggers sont maintenant prévus danstous les SGBD, y compris dans MySQL.

Il est question dans «The Data Warehouse ETL Toolkit» [Kimb04]de renoncer aux tables transitoires (staging area). Lesdonnées contenues dans le document XML seraient écritesdirectement dans la base de données cible. Mais il estremarqué, dans un paragraphe intitulé «Arguments in favor ofrelational tables»: «When you read from a staging table in theETL system, database storage is superior when filtering isanticipated and when joins between tables are performed”. Dansnotre conception du système OpenX2DW, nous utilisons cetavantage, étant donné qu’une Rule en SQL peut avoir autant dejoins que nécessaire.

Dans OpenX2DW, comme il est dit dans Kimball und Caserta[Kimb04], «the data-staging area must be owned by the ETL-Team», les utilisateurs finaux ne sont pas autorisés à accéderaux tables transitoires. Il n’est pas permis d’établir desétats ou rapports à partir de ces tables. Seul le processusETL a le droit de lire ou écrire à partir de ces tables oudans ces tables.


48

Fig.4: OpenX2DW dans un processus ETL

RULESENGINE

(applyRule.java)


Fichier XML

Mapping(cataLog.hbm.XML

)


Tabletransitoire

Base dedonnées cible

Rules

Extract Transform Load

MAPPINGGENERATOR



49

2.3 OpenX2DW dans un « environnement distribué »

Matcher, Loader, Archiver et Rules engine sont installés dansle même répertoire, étant donné qu’ils sont tous lancés àpartir du Trigger (cf. 1.2.1). Le répertoire est donné lors del’installation. Les bases de données contenant les Rules, lestables transitoires et la base de données cible peuvent êtreindépendantes l’une de l’autre (cf. Fig. 5). Nous utiliseronsla terminologie « environnement distribué » dans le sens oùles ressources – les données en particulier - ne se trouventpas au même endroit ou sur la même machine.

Dans [Kimb04] les teams ETL sont avertis que le réseau peutêtre éventuellement encombré si le transfert de données entreles différentes composantes est volumineux : «Whenever youhave to move data accross wires, the process is vulnerable tobootlenecking and performance degradation». Il est recommandé:«Depending on your infrastructure, it sometimes makes sense torun the ETL engine on the Data warehouse server to eliminatenetwork traffic».

La Rules engine n’atteint les tables transitoires qu’à traversla base de données cible. Les Rules sont exécutées commeunités encapsulées. Le Team ETL ou l’administrateur base dedonnées (DBA) doit prévoir les différents liens (DatabaseLinks) pour l’accès aux tables transitoires et des synonymes(Synonyms) éventuels pour cela dans la base de données cible.


50

Fig. 5: OpenX2DW dans un « environnement distribué » (exemple)

Base de données cible

Scan directory

Tablestransitoires

Rules

Client OpenX2DWBase de données source


51

2.4 Conclusion

Nous avons vu dans ce chapitre que le système est un bienoutil ETL, dans le sens où il est apte à charger des donnéesdans un Data warehouse. La Rules Engine permet de transformeret répartir les données sur les nombreuses tables que peutcomporter un Data Warehouse et tenir compte des contrainteséventuelles liées à ces tables. La formulation des Rulesrevient au team ETL, qui est garant de la cohérence de la basede données. L’utilisateur du Data warehouse ne doit avoir enaucun cas accès aux tables transitoires, celles-cireprésentant un espace de travail temporaire (stagging area)et n’étant destinées en aucun cas à être une base pourl’établissement d’états ou de rapports.

Etant donné que nous avons généralement affaire en entrepriseà un « environnement distribué », le système a aussi été conçude manière à fonctionner dans un tel environnement. Chacun desmodules dispose d’un fichier de paramètres (.ini), qui luipermet de cibler et accéder aux fichiers et tables de base dedonnées à traiter.


52

3 Schema Matching

3.1 «Matching» et «Mapping», définition

Bien que les mots Matching et Mapping soient quelquefoisconfondus, la définition la plus courante dans la littératureest la suivante: le Matching est un processus de comparaisonentre deux schémas et son résultat est un Mapping, c'est-à-dire une correspondance faite entre les nœuds du premierschéma et ceux du deuxième schéma. Ce résultat est inscritdans un fichier qu’on appellera « Fichier Mapping ». Ainsi ladéfinition donnée par Madhavan, Bernstein et Rahm [MBR] estformulée de cette manière : «A schema consists of a set ofrelated elements, such as tables, columns, classes, or XMLelements or attributes. The result of a Match operation is amapping. A mapping consists of a set of mapping elements, eachof which indicates that certain elements of schema S1 arerelated to certain elements of schema S2».

Il s’agit dans notre cas d’un Matching XML vers une base dedonnées relationnelle, c'est-à-dire de tenter d’effectuer unrapprochement entre les nœuds d’un fichier XML de données etles colonnes d’une table, en l’occurrence la tabletransitoire, dans le but de charger les données contenues dansle fichier XML dans la table transitoire.

3.2 Domaines d’application du Matching

La problématique du Matching se pose d’ailleurs dans biend’autres domaines que celui du Data warehousing. On laretrouve :

Dans l’intégration de schémas ; Lors de la construction d’unevue globale d’un ensemble de schémas de structures etterminologies différentes, un Matching a lieu pour pouvoirretrouver des relations entre les concepts dans les différentsschémas et les unifier.

Aussi dans le E-commerce, l’échange de messages entre despartenaires commerciaux peut nécessiter un Matching si lesmessages échangés sont de formats différents.

Dans le Query processing, les termes utilisés par unutilisateur dans la formulation de sa requête peuvent êtredifférents de ceux de la base de données. Un Matching estutilisé dans ce cas là pour «mapper» les concepts spécifiéspar l’utilisateur avec les éléments du schéma de la base dedonnées.


53

Matcher

Fig. 6: Exemple de Matching


54

3.3 Traitement manuel du Matching

Le Matching a encore souvent lieu manuellement. Des outilsconviviaux, disposant d’interfaces graphiques, existent surle marché. On peut voir ci-dessous un écran de l’un de cesoutils, XMLspy d’Altova [ALTO].

3.4 Difficultés rencontrées lors d’un Matching manuel

Le travail manuel de Matching peut être très fastidieux,exiger beaucoup de temps et donner lieu à des erreurs du faitdes différents problèmes qui peuvent se poser dans ce cas:

3.4.1 Dimension des schémas

Les tables des bases de données peuvent être nombreuses etcontenir un grand nombre d’attributs (dans notre cas le nombredes tables transitoires et le nombre de colonnes que chacunepeut avoir). Pour établir une correspondance entre les nœudsdes fichiers XML et les attributs des tables de la base dedonnées, il est nécessaire de connaître parfaitement lasignification de tous les nœuds et de tous les attributs.

Fig. 7: XMLspy de la société Altova


55

3.4.2 Complexité des schémas

Dans tous les schémas, une partie de la sémantique estdissimulée dans la structure. Dans une base de donnéerelationnelle, des clés primaires ou secondaires peuventdonner des indications sur la sémantique du schéma. Ceci estencore plus accentué dans un fichier XML, étant donné que deséléments sémantiques sont donnés dans la structure même dufichier (tags).

3.4.3 Problèmes linguistiques

En essayant d’établir des correspondances entre les schémas,les utilisateurs peuvent être confrontés par ailleurs à desproblèmes linguistiques :

Certains éléments, bien que correspondants, ne sont pasreconnus du fait de l’utilisation de synonymes etd’homonymes

Des éléments, bien que correspondants, ne sont pasreconnus car leurs appellations diffèrent; des synonymessont utilisés pour les désigner

Des homonymes peuvent induire en erreur. Unecorrespondance peut être établie entre des élémentsportant le même nom, mais de contenus différents

Une appellation en une langue différente du langage localpeut être utilisée dans le fichier XML d’entrée

Des désignations abrégées rendent le Matching encore plusdifficile

3.4.4 Cardinalité

La cardinalité est aussi un point important du Matching. Parcardinalité on entend le rapport entre un élément du premierschéma avec le nombre d’éléments du second schéma. Ondistingue sur ce plan là la cardinalité dite locale de lacardinalité globale :

Cardinalité locale : Il arrive qu’on ne puisse pasétablir de correspondance 1:1 entre les éléments duschéma S1 et S2. Le nom d’un client, par exemple, donnédans l’un des schémas comme un seul élément, est éclatédans l’autre schéma en nom et prénom. On doit doncreconnaître, lors du Matching, qu’un élément de l’un desschémas correspondant à plusieurs éléments de l’autre


56

schéma. La cardinalité locale peut avoir les 4 formestypiques connues 1:1, 1:n, n:1, n:m.

Cardinalité globale: A un élément du premier schémapeuvent correspondre en même temps plusieurs éléments dudeuxième schéma et inversement. A titre d’exemple, à unélément « size » du premier schéma peuvent correspondreles éléments « size min » et « size max » du deuxièmeschéma. Ici aussi les 4 formes sont possibles.

3.4.5 Redondance

Une redondance de l’information peut apparaître quand on aaffaire à plusieurs sources de données. Il s’agit ici, en casde conflit, de se décider pour l’une ou l’autre des sources dedonnées.

3.4.6 Absence d’information

Une source de données ne contient pas toujours toutes lesdonnées prévues dans le schéma cible. On peut dans ce cas làutiliser pour les données qui manquent, des valeurs pardéfaut, la valeur « null » ou déduire la valeur cible enprocédant à des calculs à partir des données sources.

Certains des points ci-dessus peuvent être résolus postMatching par la Rules engine. Nous avons vu que du point devue du Data warehousing, la Rules engine a aussi unecomposante «Transform» qui peut résoudre les problèmes deredondance ou d’absence d’information

3.5 Matching automatique

Du fait des difficultés décrites dans 3.4, il est tout indiquéd’avoir recours à un Matching automatique, ou du moins semi-automatique.

Un support automatique du Schéma Matching suppose un opérateurde Matching générique indépendant des applications produisantou exploitant les données sources ou cible. Il utilise deuxschémas en entrée et, en sortie, un ensemble decorrespondances entre les éléments des deux schémas. Pour êtreen mesure de décider d’une correspondance entre deuxéléments, l’opérateur de Matching doit pouvoir accéder,suivant le cas, de façon autonome aux sources de renseignementdisponibles.

3.5.1 Les différentes sources d’information


57

Pour pouvoir établir une correspondance entre les éléments desdeux Schémas S1 et S2, différentes sources d’information sontutilisées.

3.5.1.1 Sur le plan Schéma (Intension, Meta données)

Nous retrouvons sur le plan schéma toutes les informationsréunies, qui ne résultent d’aucune valeur concrète d’uneinstance du schéma. Ces informations ne découlent que de ladéfinition du schéma lui-même. Elles peuvent être répartiescomme suit:

Les renseignements linguistiques sont tous ceux quidécoulent de comparaisons linguistiques, telles que demêmes noms pour les éléments

Aux restrictions appartiennent toutes les analyses dutype de données, ou qui prennent en compte les propriétésde la clé ou autres conditions telles que « not null »,« unique », etc.

Les Informations structurelles sont celles qui résultentde comparaisons des positions hiérarchiques d’élémentsdes deux schémas, du genre (dans un modèle entité-relation par exemple : entité, relation ou attribut) oud’informations en rapport avec des éléments voisins, danslesquelles peuvent être contenues d’importantesinformations sémantiques.

3.5.1.2 Sur le plan Instance (Extension, données)

Les données contenues dans une instance concrète du schémapeuvent donner de précieux renseignements sur la significationdes éléments d’un schéma. Ceci est particulièrement utile sile schéma ne contient en soi que des informations trèslimitées, comme c’est souvent le cas pour les données semistructurées. Il existe même des approches pour la déductionautomatique d’un schéma à partir d’un document XML sur le plande l’instance [WYW]. Même si de nombreuses informationsconcernant le Schéma sont présentes, l’analyse des instancesconcrètes peut aider à éviter de fausses interprétations deséléments du schéma ou à se décider dans le cas d’ambiguïtés.Les approches pour l’obtention d’informations à partir desdonnées d’une instance peuvent être réparties en :

Informations linguistiques. Dans des éléments textes nonstructurés, des techniques de l’Information Retrievalpeuvent être appliquées pour pouvoir extraire des mots


58

clés ou des sujets. (Examens des fréquences d’apparitionsd’un même mot, combinaison de mots, etc.)

Restrictions. les plages de valeurs des données contenuesdans les instances peuvent être analysées dans le cas dedonnées structurées (nombre, String). Des calculsstatistiques (valeurs moyennes, dispersion) sont aussienvisageables.

3.5.1.3 Information auxiliaire (indépendante du cas concret)

Des sources de renseignements auxiliaires peuvent êtreutilisées pour le rapprochement entre les deux schémasd’entrée :

Les thesaurus, pour la recherche de synonymes, homonymeset la résolution d’ambiguïtés

Les dictionnaires de langues, en particulier dans lesprojets internationaux ou dans des entreprisesmultinationales, pour la reconnaissance de termesspécifiques ou locaux, lors d’analyses linguistiques

L’historique des décisions de Mapping prises. Se référerà des décisions prises dans le passé accélère leprocessus de Matching. On peut imaginer que ce soit mêmela seule manière de prendre des décisions de Mappingjustes. Exemple: La valeur «Informatique» a été souventaffectée dans le passé à l’élément «Département». Si unélément du Schéma S1 contient cette valeur et un élémentdu Schéma S2 a le nom «Département», il pourrait s’agird’une correspondance entre les deux éléments, si on n’apas pu trouver d’autre correspondance.

Le contexte global. Il peut arriver que le Mapping decertains éléments ait lieu à travers le contexte global,sans qu’une analyse détaillée du Schéma soit faite.

Une classification est donnée dans l’arborescence ci-dessouspar Rahm et Bernstein dans leur article «A survey ofapproaches to automatic schema matching» [RB].


59

Les différents aspects d’un Matcher sont présentés dans lafig. 10, tirée de l’article «A Unified Schema MatchingFramework» de Algergawy, Schallehn et Saake [ASS].

Pour être en mesure de définir l’opérateur de Matching, ilest tout d’abord nécessaire de procéder au choix d’unereprésentation adaptée des Schémas d’entrée S1 et S2 et du

Fig. 8: Classification des approches pour un Schema Matching [RB]

Fig. 9: Différents aspects d’un Matcher [ASS]


60

résultat du Matching, qui, dans notre cas, est le fichierMapping.

3.5.2 Représentation interne

La représentation interne, comme énoncé plus haut, concerneaussi bien les schémas d’entrée que le résultat du Matching.

Schémas d’entrée: La forme de la représentation internedes Schémas d’entrée doit être suffisamment bonne pourque soient prises en compte toutes les données qu’unMatcher peut utiliser. Les prototypes de Matcherprésentés dans 8.5.5 diffèrent considérablement dansl’utilisation des représentations internes desinformations des Schémas : graphes orientés, modèleentité-relation, modèle orienté objet, etc. Rahm etBernstein [RB] définissent un Schéma, pour leur examendes différents prototypes existants, comme un ensembled’éléments liés par une structure.

Résultat du Matching : Pour ne pas limiter le résultat,le choix d’une forme de représentation mathématiquementexacte s’impose. Rahm et Bernstein [RB] définissent lerésultat d’un Matching comme un ensemble d’éléments duMapping. Chaque élément du Mapping est composé d’un ouplusieurs éléments des deux schémas d’entrée, une«Mapping expression» définissant exactement leurappartenance sémantique.

3.5.3 Mode de fonctionnement d’un opérateur de Matching

Le fonctionnement d’un opérateur de Matching est similaire àcelui d’un Join dans une base de données relationnelle. Unopérateur de Matching, comme un Join, représente une opérationbinaire qui définit, à partir des sources d’entrée, des pairesd’éléments correspondants. Une approche intuitive dans le casdu Matching serait donc un «Nested loop Match». Unecorrespondance est recherchée pour chaque élément du schéma S1avec chaque élément du schéma S2. Join et Matching diffèrentpourtant, étant donné que :

Contrairement au Join, qui peut donner une correspondancesure, un opérateur de Matching ne donne qu’uneprobabilité de correspondance

Un opérateur de Matching devrait utiliser autant desources d’information (cf. 8.5.1) que possible, alorsqu’un opérateur de Join ne considère que les donnéescontenues dans l’instance


61

La cardinalité doit être prise en compte dans le cas d’unopérateur de Matching, alors que dans celui du Join, unélément du schéma S1 n’est lié qu’à un élément du schémaS2

L’expression de comparaison («Mapping expression» dans lecas du Matching) est constante dans le cas du Join alorsqu’elle peut être différente pour chaque paire dans lecas du Matching

La sémantique dans une opération de Join est,contrairement à une opération de Matching, clairementdéfinie. Dans le cas du Matching, la probabilité aveclaquelle une correspondance a été établie, divergesuivant les différentes implémentations.

3.5.4 Les différents types de Matcher

Toutes les implémentations présentées dans 3.5.5 utilisent,pour décider du Mapping d’éléments, de plusieurs sourcesd’information. A coté de la question : quel est l’algorithmequi doit permettre de déterminer concrètement l’information ets’il doit tenir compte de l’appellation de l’élément (Labelidentity) ou d’autres critères, il faut répondre aussi à laquestion : comment rapprocher les informations obtenues àpartir de plusieurs sources et comment résoudre les conflitséventuels en cas de divergence de ces dernières. Deuxapproches existent dans ce domaine :

Matcher hybrides. Les algorithmes de Matching hybridescontiennent des critères de Matching qui mènent à unedécision de Matching commune. Le résultat est plusfiable, étant donné que plusieurs informations sontutilisées. Un Matching basé, par exemple, surl’appellation des éléments et sur la compatibilité dutype de données mène à de meilleurs résultats qu’unMatching basé sur un seul critère.

Matcher composites. Les algorithmes de Matching sontappliqués indépendamment les uns des autres; L’élément leplus probable est ensuite donné comme résultat duMatching en fonction d’un processus de pondération.

On relève toutefois dans l’article de Rahm et Bernstein [RB]que : «A hybrid matcher can offer better performance than theexecution of multiple matchers by reducing the number ofpasses over the schema. For instance, with element-levelmatching hybrid matchers can test multiple criteria at a timeon each S2 element before continuing with the next S2element».


62

3.5.5 Prototypes existants

Plusieurs prototypes de Schema Matching sont décrits dans lalittérature. Ainsi Rahm et Bernstein [RB] ont en étudié sept,qu’ils ont par ailleurs classés suivant une taxonomie propre(cf. fig. 8). Les principales caractéristiques de ces systèmessont exposées dans ce chapitre, la description donnée endernier, plus détaillée, concernant le système CUPID deMicrosoft, qui s’est inspiré de certains de ces systèmes dansla conception du sien.

3.5.5.1 SemInt (Northwestern University)

Le Tool de Clifton et Li, développé à l’aide de réseau deneurones artificiels, découvre les correspondances entreattributs dans des bases de données hétérogènes. Saflexibilité permet de choisir jusqu’à une vingtaine decritères de Matching, utilisés dans une approche hybride.SemInt peut exploiter jusqu’à quinze critères sur le planSchema (Meta données) mais en renonçant aux critères basés surles Label (noms d’attributs). Semint peut aussi exploiterjusqu’à cinq critères différents sur le plan instance. Ilconstruit un vecteur N-dimensionnel pour l’ensemble desattributs des schémas à Matcher, N étant le nombre descritères utilisés. Une fonction associe chaque valeur possible(le «degré de correspondance») à une valeur comprise entrezéro et un. Le résultat en est un vecteur N-dimensionneld’éléments compris entre zéro et un, qui serait une «Matchsignature». L’ensemble des signatures peut être utilisé dansdeux modes de SemInt :

Attributs identiques dans les deux schémas. Dans cetteapproche, qui est l’approche principale de SemInt, lesattributs identiques sont regroupés dans des Cluster. Leréseau de neurones est alors entraîné aux signatures descentres des Cluster, les signatures du deuxième schémaétant assignées, dans la phase de classification, à unCluster.

Attributs presque identiques. La distance euclidienne,qui servira de mesure de similitude à tous les attributsdu deuxième schéma est calculée pour tous les éléments dupremier schéma. SemInt produit ainsi une liste decandidats au Matching.


63

3.5.5.2 Learning Source Description (LSD)

LSD a été développé par Doan, Domingos et Levy en 2000. Ilutilise des techniques de l’apprentissage automatique pourfaire correspondre une nouvelle source XML à un schéma globaldéjà défini. LSD ne travaille que sur des schémas XML. Ils’agit pour ce prototype d’une approche basée principalementsur l’instance mais qui peut tenir compte des appellations(Label) et d’informations structurelles. L’utilisateur donneau système, lors de la période d’apprentissage, certainsMapping à apprendre. D’autres Mappings sont produits à partirde ces derniers à travers une méthode d’apprentissage deBayes. La combinaison des critères a lieu dans un processuscomposite automatique.

Selon Algergawy, Schallehn et Saake [ASS], l’inconvénient desapproches basées sur l’apprentissage «is the computationalcost related to analyzing instance data».

3.5.5.3 Semantic Knowledge Articulation Tool (SKAT, Stanford University)

Le système développé par Mitra, Wiederhold et Jannink en 1999adopte une approche basée sur des règles pour produire demanière semi automatique un Mapping entre deux schémas. LesRules, données par l’utilisateur, contiennent des relations deMatching et de Mismatching à partir desquels le système enextrait d’autres. SKAT se base sur une analyse pure desschémas. Il utilise, tout en considérant les synonymes, leshomonymes et les hyperonymes (le mot «arbre» par exemple, estun hyperonyme de «pommier»), aussi bien des critères basés surles Labels que des critères basés sur des informationsstructurelles.

3.5.5.4 TranScm

Le système TranScm a été rendu public par Milo et Zohar [MZ]en 1998. Le but de ce prototype est la traduction automatiquede données provenant de sources ayant la même structure. Destechniques du Schema Matching ont été utilisées dans cetobjectif. Comme pour SKAT, seules des données sur le planSchema ont servi pour des décisions de Matching. Cecis’explique par les types de schémas choisis pour TranScm(SGML, OO). Plusieurs informations pouvant servir dans ladécision de Matching sont dissimulées dans la structure et legenre des composants. Celles-ci sont transposées dans ungraphe. Les nœuds du graphe correspondent aux composants avecleurs propriétés (Nom, #fils, option). Les arêtes décriventdes relations existantes entre les composants (is a...).Plusieurs algorithmes de Matching sont utilisés dans un ordredonné pour identifier un Matching (approche hybride).L’intervention de l’utilisateur est requise si un algorithmene peut pas identifier de paires de nœuds sans équivoque


64

(choix manuel d’un candidat au Matching ou détermination denouvelles règles de Matching).

3.5.5.5 DIKE (Université Calabria)

Le noyau du système DIKE est basé sur les algorithmes dePalopoli, Sacca et Ursino [PSU] relatifs à la reconnaissancesemi automatique des propriétés sémantiques d’un schéma. Cesalgorithmes aussi n’exploitent que les informations sur leplan Schema et ne prennent pas en considération les instances.L’idée adoptée par les auteurs de ce prototype est de luifaire reconnaître seul des synonymes et homonymes des Labels.A coté du schéma d’entrée S1, des synonymes ainsi que deshomonymes et des inclusions sont mis à la disposition dusystème. A ceux-ci est attribuée une pondération quicorrespond à la probabilité qu’une telle relation existevraiment. Tous les objets (type d’entité, type de relation,attribut) des deux schémas d’entrée sont, dans un deuxièmetemps, comparé un à un dans le but de détecter dessimilitudes. Le but est de trouver des paires d’objets quisont similaires, mais qui sont de types différents (typed’entité, type de relation, attribut). Si le degré desimilitude dépasse une Threshold Value et si un Matching estainsi reconnu, les conflits de types sont considérés commeayant un sens.

3.5.5.6 Artemis (Université de Milan)

Ce prototype de Castano et Antonellis, destiné à l’intégrationde schémas, a été publié en 1999. Artemis peut traiter desschémas d’entrée du type entité-relation, orientés objet et dumodèle relationnel. Artemis aussi ne traite que lesinformations du plan Schema. Noms, types de données etstructures des éléments du Schema sont pris en considérationlors du Matching. Artemis est utilisé par le système MOMIS(Mediator envirOnment for Multiple Information Sources). MOMISintègre de façon semi automatique des schémas développésindépendamment dans un schéma virtuel global.

3.5.5.7 Cupid (Microsoft Research)

Chacun des systèmes décrits ci-dessus n’a exploitésimultanément que quelques unes des techniques de Matchingconnues, décrites dans 3.5.4. Madhavan, Berstein et Rahm[MBR] écrivent: «… each of them is an incomplete solution,exploiting at most a few of the techniques in our taxonomy.This is not really a criticism. Each of them was either a testof one particular approach or was not designed to solve theschema matching problem per se, and therefore made matchingcompromises in pursuit of its primary mission (usually schemaintegration). However, the fact remains that none of themprovide a complete general-purpose schema matching component.


65

We believe that the problem of schema matching is so hard, andthe useful approaches so diverse, that only by combining manyapproaches can we hope to produce truly robust functionality.»

Certains des systèmes décrits ci-dessus ont donc servi, avecleurs algorithmes, de base à la conception du prototypedéveloppé par Microsoft Research, Cupid. Celui-ci essaye àtravers la combinaison de différentes approches d’arriver dansson Matching à un résultat plus consistant. Cupid est uneapproche générique pour le rapprochement entre différentsschémas, qui a été testé en particulier sur des schémas XML etRM. Les informations ne sont traitées que sur un plan Schema.Les informations basées sur les Labels sont, avec l’aide deglossaires et de Thesaurus, très exactement analysées pour quesoient pris en considération les synonymes, les homonymes, leshyperonymes et les abréviations.

L’algorithme est constitué de trois phases, la troisième desphases étant spécifique à l’application et n’ayant aucunimpact sur la définition de l’algorithme.

1. Lors de la première phase, les éléments du schéma sontcatégorisés tout prenant en considération les noms, lestypes de données et le domaine (approche hybride). Uncoefficient de similitude est calculé pour toutes lespaires d’éléments des deux schémas.

2. Lors de la deuxième phase, le schéma d’origine esttransformé en un arbre qui codifie les conditionssecondaires du schéma aussi bien que la structure, lesnœuds de l’arbre représentant les éléments du schéma.

3. La troisième phase décide de Mappings concretsd’éléments sur la base de coefficients de similitudecalculés.


66

L’exemple ci-dessous donne un aperçu du mode de fonctionnementde l’algorithme :

La fig. 10, donnée comme exemple par Madhavan, Bernstein etRahm dans «Generic Schema Matching with Cupid» [MBR] est lareprésentation graphique de deux schémas XML du domaine desachats (procurment). Les nœuds représentent les éléments desschémas. Bien que les deux schémas correspondent à la mêmefonction (commandes), ils diffèrent sensiblement quand àl’appellation des éléments et leurs structures, ce qui renddifficile un Schema Matching automatique.

Pour trouver des éléments correspondants, un coefficient desimilitude est tout d’abord affecté à toutes les pairesd’éléments des deux schémas.

Lors de la première phase, le coefficient est déterminé àtravers une analyse linguistique des deux éléments desschémas. Aussi bien les noms que les domaines de valeurs sontpris ici en considération. Le coefficient est appelé«linguistic similarity coefficient» (lsim).

Lors de la deuxième phase, ce sont des relations structurellesdans le voisinage d’un élément du schéma qui sont analysées.Le lsim déterminé lors de la première phase est exploité dansle but de faire correspondre entre eux des éléments qui setrouvent dans un même contexte structurel. Ainsi dans lafigure 11, l’élément Line et ItemNumber sont reconnus commeidentiques puisque leurs noeuds parents correspondent et queles autres noeuds jumeaux ont été aussi reconnus commecorrespondants. Lors de cette deuxième phase, c’est un«structural similarity coefficient» (ssim) pour chaque paired’éléments des schémas qui est calculé.

Fig. 10 : Deux schémas XML « Commande »


67

Grâce au ssim et au lsim, ce sont ensuite les similitudes quisont pondérées et un Mapping déterminé.

3.5.5.7.1 Matching linguistique

La première phase du Schema Matcher Cupid utiliseprincipalement les noms des éléments des schémas pourdéterminer les correspondances. Le calcul des du coefficientde similitude linguistique (lsim) se déroule en trois étapes :

Normalisation. Les éléments des schémas diffèrent souventles uns des autres du fait de l’utilisationd’abréviations, d’acronymes, ou de certaines combinaisonsde caractères. Les noms des éléments des schémas sont,lors de l’étape de normalisation, analysés (parsed),complétés ou abrégés. Ceci a lieu grâce à l’utilisationde Thesaurus qui contiennent aussi bien des abréviationsde la langue générale que des détails relatifs au domained’utilisation.

Clustering (constitution de catégories). Les éléments desdeux schémas sont répartis dans des catégories sur labase d’une analyse linguistique des types de données etde la situation dans la hiérarchie (exemple : unecatégorie pour des valeurs simples, une autre pour desvaleurs fonctions du taux de change des devises). Unélément d’un schéma peut aussi appartenir à plusieurscatégories. Le but du Clustering est de réduire le nombred’éléments candidats au Matching, étant donné que le lsimn’est calculé que pour les éléments se trouvant dans unmême Cluster.

Comparaison. Le calcul du coefficient de similitudelinguistique se fait à partir d’une comparaison dessuites de caractères extraites des noms. Un Thesaurus estutilisé pour le remplacement des synonymes ethyperonymes. Les Substrings contenus dans la suite decaractères sont aussi comparés. Le résultat de cettephase sera un tableau de coefficient de similitude pourtoutes les correspondances potentielles.

3.5.5.7.2 Matching structurel

Le coefficient de similitude structurel (ssim) est une mesurepour le contexte structurel dans lequel se trouvent deséléments dans les deux schémas. Les hiérarchies, qui peuventêtre représentées sous forme d’arbres, sont analysées.L’algorithme présenté dans [MBR], permettant de définir cettesimilitude structurelle, est basé sur les hypothèsesintuitives suivantes :


68

Des éléments dans les feuilles des arbres sont identiquess’ils sont similaires du point de vue linguistique et parrapport au type de données, et si les éléments dans leursvoisinages immédiats (nœuds parents, nœuds jumeaux) sontidentiques.

Deux noeuds internes sont identiques s’ils sontsimilaires et si les parties d’arbres dont ils sont lesracines sont similaires.

Deux noeuds internes sont structurellement identiquesquand leurs feuilles sont très similaires, même si leursnoeuds fils ne sont pas similaires.

3.6 Conclusion

Comme énoncé dans 1.2.2, le rôle du Matcher est d’établir unMapping. Le Mapping est le résultat de la comparaison de deuxschémas : un premier schéma, qui est celui des donnéesentrantes, avec un deuxième, qui n’est autre dans notre casque celui la table transitoire. Le fichier Mapping est unfichier texte, lui-même au format XML, dans lequel est décritle Mapping (voir l’exemple de fichier Mapping donné en annexe3).

Il s’agit donc d’établir une correspondance entre les élémentsd’un fichier XML et les colonnes d’une table d’une base dedonnées relationnelle. Le résultat est le fichier Mapping dontse servira le Loader pour charger les données à partir desfichiers XML dans les tables transitoires. La figure 6 est uneillustration de l’énoncé de ce problème.

Nous avons présenté dans ce chapitre différentes approchespour la résolution de ce problème ainsi que certainsprototypes développés jusqu’ici, basés sur ces approches.


69

CONCLUSION GENERALE ET PERSPECTIVES

L’enrichissement de OpenX2DW consisterait en un développementd’une interface graphique (GUI) qui offrira plus deconvivialité dans la saisie des Rules, la programmation duTrigger et la création des tables transitoires, voire de labase de données cible. Un programme d’installation permettraaussi de copier les différents programmes sur le poste clientet de créer leurs fichiers de paramètres (.ini).

La particularité de ce système de chargement de données XMLdans un Data warehouse est qu’il prévoit par ailleurs unegénération automatique du fichier Mapping.

Concernant les prototypes de Matching présentés, plusieursremarques s’imposent :

une validation par l’utilisateur des résultats duMatching est toujours nécessaire

un travail préalable est en outre indispensable :apprentissage préliminaire, valeur de seuil pour lasimilitude

aucun des systèmes ne prend en considération dans sonMatching des décisions de Mapping déjà prises par lui-même dans le passé

dans la majorité d’entre eux, des informationsauxiliaires sont utilisées

plusieurs critères ont été utilisés pour les décisions deMapping, mais seulement chez un seul Matcher composite

la plupart des systèmes permettent non seulement lareconnaissance de noms d’éléments (Labels) mais aussileur niveau de hiérarchie dans la structure du schéma,mais deux systèmes seulement utilisent des informationsrelatives à l’instance

à l’exception de LSD (XML) et DIKE (ER) les systèmessupportent plusieurs types de schémas

tous les systèmes étudiés ne peuvent reconnaître que deséléments avec un Mapping de cardinalité 1:1.

la plupart des prototypes ont été construits pour desdomaines d’application spécifiques à l’exception de Cupidqui utilise une approche générique


70

De Cupid, dont on a vu qu’il est le plus «riche», Madhavan,Bernstein et Rahm écrivent dans leur article «Generic SchemaMatching with Cupid» [MBR] :«A truly robust solution needs toinclude other techniques, such as machine learning applied toinstances, natural language technology, and pattern matchingto reuse known matches. Some of the immediate challenges forfurther work include: integrating Cupid transparently with anoff-the-shelf thesaurus; using schema annotations (textualdescriptions of schema elements in the data dictionary) forthe linguistic matching; and automatic tuning of the controlparameters. Scalability analysis and testing are necessary tostudy the performance on large-sized schemas. And much morecomparative analysis of algorithms is needed. Our long-termgoal is to make Cupid be a truly general-purpose schemamatching component that can be used in systems for schemaintegration, data migration, etc. The work reported here isjust one step along what we expect will be a very longresearch path»

Etant donné que très souvent une sémantique est dissimuléedans le schéma d’entrée et que celle-ci n’est ni formellementexprimée ni documentée, on dispose sans nul doute d’un grandpotentiel de recherche dans ce domaine, qui se situerait parexemple dans l’utilisation de décisions de Matching prisesdans la passé pour l’amélioration de l’efficacité desalgorithmes.


71

Bibliographie

Livres:

[Baue04] Andreas Bauer, Holger Günzel: Data-Warehouse-Systeme,Dpunkt Verlag, August 2004, ISBN: 3898642518

[Date99] Chris J. Date, Hugh Darwen: SQL – Der Standard,Addison-Wesley-Longman, 1999, ISBN 3-8273-1345-7

[Dijc04] Jean-Pierre Dijcks: Oracle Warehouse Builder 10g –Helping you save time and money anytime you move data, OracleCorporation, February 2004

[Dijc04] Jean-Pierre Dijcks: Oracle Warehouse Builder –Architecture white paper, Oracle Corporation, February 2004

[Kimb04] Ralph Kimball, Joe Caserta: The Data Warehouse ETLToolkit, John Wiley & Sons, Oktober 2004, ISBN: 0764567578

[Muck00] Harry Mucksch/Wolfgang Behme (Hrsg.): Das DataWarehouse – Konzept, Architektur – Datenmodelle – Anwendungen,4. Auflage, Betriebswirtschaftlicher Verlag Dr. Th. GablerGmbH, Wiesbaden, 2000. ISBN 3409422161

Articles:

[ASS] Alsayed Algergawy, Eike Schallehn and Gunter Saake(2007): A Unified Schema Matching Framework, Post-Proceedingsof the 19. GI-Workshop on Foundations of Databases, Bretten,Baden-Württemberg, Germany, May 29 - June 1, 2007.

[MBR] Jayant Madhavan, Philip A. Bernstein, Erhard Rahm(2001): Generic Schema Matching with Cupid, In Proc 27th VLDBConference CD Rom 2001.

[MZ] Milo T, Zohar S (1998): Using schema matching to simplifyheterogeneous data translation, In Proc 24th InternationalConference On Very Large Data Bases, pp. 122–133.

[PSU] Palopoli L, Sacca D, Ursino D (1998): Semi-automatic,semantic discovery of properties from database schemas. In:Proc Int. Database Engineering and Applications Symp.(IDEAS),IEEE Comput, pp. 244–253.

[RB] Erhard Rahm, Philip A. Bernstein (2001): A survey ofapproaches to automatic schema matching, In The VLDB Journal10: pp. 334–350.


72

[WYW] Wang Q, Yu J, Wong K (2000): Approximate graph schemaextraction for semi-structured data, In: Proc ExtendingDataBase Technologies, Lecture Notes in Computer Science, vol.1777. Springer, Berlin Heidelberg NewYork, pp. 302–316

Mémoire:

[Kahl06] Boubaker Kahloula (2006): Konzeption und Entwicklungeiner Rules engines, Février 2006, University of AppliedSciences, Prof. Christoph Wenzel, Darmstadt.

URLs:

[ALTO] Altovahttp://www.altova.com/mapforce/database-mapping.html

[CJAP] Collected Java Practiceshttp://www.javapractices.com/Topic172.cjp

[ERPM] erpmanager.de. Das Enterprise Ressource Planing Portalhttp://www.erpmanager.de/infopac/download/1774/download_017741495356.pdf

[HIBE] Hibernatehttps://www.hibernate.org/

[JABO] Java Boutiquehttp://javaboutique.internet.com/tutorials/mapping/

[KHAN] Prasad Khandekar: The Code Project - An enhanced INIFile class for javahttp://www.codeproject.com/useritems/INIFile.asp

[MSQA] MySQL AB: Connector/J 3.1http://dev.mysql.com/downloads/connector/j/3.1.html

[MYSD] MySQL Databasehttp://dev.mysql.com/downloads/mysql/5.0.html

[NETB] NetBeanshttp://www.netbeans.org/

[ORAC] Oracle Technology Networkhttp://www.oracle.com/

[PHUT] Dipti Phutela, Mindfire Solutions : Hibernate Vs JDBC,http://www.mindfiresolutions.com/mindfire/Java_Hibernate_JDBC.pdf pp.7.

[TJDA] Java Language Examples from The Java Developers Almanac1.4http://javaalmanac.com/egs/


73

[WIKI] Wikipedia, l’encyclopédie librehttp://fr.wikipedia.org/wiki/


74

Annexe 1 : Scripts pour la génération de la table «Rules»

############################################################# Database MySQL 5.0## version 1.0############################################################### Rules table#############################################################DROP TABLE IF EXISTS rules;CREATE TABLE rules (

rule_code VARCHAR(5) NOT NULL,rule_text LONGTEXT,alternative_rule LONGTEXT,if_rulefailure CHAR(1) DEFAULT 'R',if_alternativefailure CHAR(1) DEFAULT 'R',error_level CHAR(1) DEFAULT 'S',date_created DATE DEFAULT NULL,comments VARCHAR(255) DEFAULT NULL,active_status CHAR(1) DEFAULT 'N',PRIMARY KEY(rule_code)

) TYPE=InnoDB;

############################################################# Database Oracle 10g## version 1.0############################################################### Rules table#############################################################DROP TABLE rules;CREATE TABLE rules (

rule_code VARCHAR2(5) NOT NULL,rule_text CLOB,alternative_rule CLOB,if_rulefailure CHAR(1) DEFAULT 'R',if_alternativefailure CHAR(1) DEFAULT 'R',error_level CHAR(1) DEFAULT 'S',date_created DATE DEFAULT NULL,comments VARCHAR2(255) DEFAULT NULL,active_status CHAR(1) DEFAULT 'N',PRIMARY KEY(rule_code)

);


75

Annexe 2 : Exemple de script pour l’insertion de Rules

############################################################# Database Database MySQL 5.0 et Oracle 10g## version 1.0############################################################### Insert Rules#############################################################

INSERT INTO rules (rule_code,rule_text,comments) VALUES('R001','INSERT INTO AUTHOR (AUTHOR)SELECT DISTINCT AUTHOR FROM CATALOG;','Table: Auteurs');

INSERT INTO rules (rule_code,rule_text,comments) VALUES('R002','INSERT INTO PUBLICATION AUTHOR,CATALOGID,JOURNAL,PUBLISHER,EDITION,TITLE)SELECT AUTHOR,CATALOGID,JOURNAL,PUBLISHER,EDITION,TITLEFROM CATALOG;', 'Table: publications');

UPDATE rules SET alternative_rule=rule_text;UPDATE rules SET if_rulefailure='R';UPDATE rules SET if_alternativefailure='R';UPDATE rules SET error_level='S';UPDATE rules SET date_created='20090722';UPDATE rules SET active_status='Y';


76

Annexe 3: Exemple de fichier Mapping

<?XML version="1.0"?><!DOCTYPE hibernate-Mapping PUBLIC"-//Hibernate/Hibernate Mapping DTD 3.0//EN""http://hibernate.sourceforge.net/hibernate-Mapping-3.0.dtd"><hibernate-Mapping><class entity-name="catalog" node="catalog" table="CATALOG">

<id name="catalogId" node="catalogId" column="CATALOGID" type="string"/><property name="journal" node="journal" column="JOURNAL" type="string"/><property name="publisher" node="publisher" column="PUBLISHER" type="string"/><property name="edition" node="edition" column="EDITION" type="string"/><property name="title" node="title" column="TITLE" type="string"/><property name="author" node="author" column="AUTHOR" type="string"/>

</class></hibernate-Mapping>


77

Annexe 4: Exemple de Trigger

REM X2DW.bat est un exemple de trigger pour WindowsECHO OFFIF EXIST catalog.xml (

ECHO generate Mapping file ...java -jar generateMapping.jar catalog catalog.hbm

ECHO loading table CATALOG ...java -jar loadXMLFile.jar catalog catalog.hbm

ECHO archiving file CATALOG ...java -jar archivFile.jar ARCHIV FILE catalog

ECHO Rule R001 (Author) ...java -jar applyRule.jar R001

ECHO Rule R002 (Publication) ...java -jar applyRule.jar R002

)


78

Annexe 5 : Programmes sources

L’annexe 5 se trouve sur le CD ci-joint.

Mémoire de Fin d’Etudes - univ-oran1.dz

Documents

Transcript of Mémoire de Fin d’Etudes - univ-oran1.dz