Copyright (c) Virginie QUESNAY

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation;

with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU

Free Documentation License".

MEMOIRE PROFESSIONNEL

Étude d'une migration de Sybase vers PostgreSQL

Enseignant tuteur : Christian BRAESCH

Maître de stage : Christophe POLLIER INSTITUT UNIVERSITAIRE PROFESSIONNALISE

DE GENIE DES SYSTEMES INDUSTRIELS

Genie des systèmes d'information

MÉMOIRE PROFESSIONNEL

Étude d'une migration de Sybase vers PostgreSQL

?

RÉSUMÉ:

Ce mémoire a été réalisé lors de mon stage de fin d'études de Master a l'IUP-GSI d'Annecy le Vieux. Celui-ci s'est déroulé au sein de la Chambre de Commerce et d'Industrie de la Haute-Savoie du 8 mars au 25 juin 2004.

Le but de ce stage était d'étudier les possibilités de migration d'une base de données de Sybase vers PostgreSQL.

Ce mémoire est donc composé de trois parties:

- Le contexte du stage (l'existant);

- La problématique de migration de base de données;

- L'illustration de cette problématique par le cas concret qu'était mon étude.

MOTS-CLEFS:

PostgreSQL, Sybase, Perl, SQL, Migration, Traduction

Remerciements

Je tiens tout d'abord à remercier mon maître de stage et chef de projet Mr Christophe POLLIER, pour m'avoir proposé un sujet aussi interressant et formateur et de m'avoir guidée dans mon travail tout en me laissant un maximum de libertés et d'initiatives.

Je tiens également à remercier tous les collaborateurs de la CCI et tout particulièrement ceux du services TIC dans lequel j'ai travailé : Grégory BENOIST, Vincent AUGIERMICOU, Laurence BOQUET et Laurent POSSETY pour leur accueil sympathique et chaleureux.

Enfin, je remercie Christian BRAESCH, mon tuteur de l'IUP GSI.

Table des matières

Remerciements i

Liste des illustrations v

Liste des tableaux vi

Liste des codes sources vii

Introduction 1

I L'existant 2

1 Presentation de la C.C.I 3

1.1 Son Histoire 3

1.2 Son implantation 3

1.3 Sa mission et ses objectifs 4

1.4 Son organisation 5

1.4.1 Les élus 5

1.4.2 Les collaborateurs 6

1.5 Le service TIC 6

1.5.1 Ses missions 6

1.5.2 Ses acteurs 6

2 Sujet et Objectifs 7

2.1 Presentation du contexte 7

2.1.1 Le Système d'Information de la CCI 7

2.1.2 Caracteristiques techniques du Système d'Information 7

2.2 Presentation du projet 8

3 La problematique Système d'Information 9

II Étude de la problematique de migration de base de données 11

4 Les approches possibles 12

4.1 L'approche "systematique" 12

4.2 L'approche "empirique" 13

4.3 Combinaison de l'approche "systematique" et de l'approche "empirique" 15

5 Les outils et technologies applicables 16

5.1 Utiisation d'une interlangue 16

5.2 Traduction "manuelle" 18

5.3 Traduction automatique "monotraducteur" 18

5.4 Utiisation d'outils de "reverse-engenering" 19

6 Les méthodes de gestion de projet informatique 20

6.1 Méthode non formelle 20

6.2 XP : eXtreme Programing 20

6.3 RUP : Rational Unified Process 21

6.4 DSDN (RAD) 22

7 Combinaison des approches, des technologies et des méthodes 23

8 Proposition d'une démarche et de "bonnes pratiques" 25

8.1 Déterminer la nature du problème 25

8.2 Vérifier s'il existe des solutions 25

8.3 Effectuer la Migration 26

8.3.1 Si une solution existante a été trouvée 26

8.3.2 Si aucune solution existante ne convient 26

III Application au contexte du stage 27

9 Les choix managériaux et technologiques 28

9.1 La gestion de projet 28

9.2 La démarche suivie 28

9.3 Les technologies utilisées 29

9.3.1 PostgreSQL 29

9.3.2 RedHat Database 30

9.3.3 Perl 30

10 Le travail réalisé 32

10.1 Évaluation de l'état de la base de données existante 32

10.1.1 Découverte du fonctionnement et des spécificités 32

10.1.2 Quelques chiffres 32

10.2 Étude des différentes techniques de migration 33

10.3 Écriture d'un traducteur en Perl 33

10.3.1 L'approche utiisée 33

10.3.2 Fonctionnement de l'application 34

10.4 Estimation du travail restant à effectuer 34

10.4.1 Méthode d'estimation 35

10.4.2 Réalisation des mesures 35

10.4.3 Résultats de l'estimation 36

11 Bilan du stage 38

11.1 Évaluation du travail réalisé 38

11.2 Problèmes rencontrés 38

11.2.1 Les problèmes techniques 38

11.2.2 Les problèmes liés à l'organisation 39

11.2.3 Les problèmes liés au manque de connaissance 39

Conclusion 40

Annexes 41

A Les CCI en France 42

B La CCI de la Haute-Savoie 47

C Les Chiffres de la CCI de la Haute-Savoie 49

D Organigramme 51

E La licence BSD (Berkeley Software Distribution) 52

F Limitations de PostgreSQL 53

G Phases pour réaliser l'ensemble de la migration 54

H Options pour l'utilisation de sybase2postgresql 56

I Documentation de sybase2postgresql 58

J Problèmes spécifiques a chaque type d'information a migrer 60

K Mesures pour les indicateurs de complexité des procédures 66

L Installation de modules supplémentaires pour Perl 69

M Enregistrement d'un fichier en UTF-8 sous Emacs 71

N Webographie 72

Bibliographie 74

Glossaire 76

Liste des illustrations

1.1 Nouveau bâtiment de la CCI dans le quartier Galbert 3

1.2 Implantations de la C.C.I. en Haute-Savoie 4

1.3 Organisation globale de la CCI 5

4.1 Utiisation d'une méthode systématique pour la traduction de textes . . 12 4.2 Utiisation d'une méthode empirique pour la traduction de textes . . . . 14

5.1 Méthode de traduction avec une interlangue 16

5.2 Méthode de traduction sans interlangue 17

5.3 Méthode de traduction automatique 18

7.1 Corrélation entre les approches, les technologies, les méthodes et la

taille de l'équipe 23
7.2 Exemple de mauvaise corrélation entre les approches, les technologies,

les méthodes et la taille de l'équipe 24
7.3 Exemple de bonne corrélation entre les approches, les technologies, les

méthodes et la taile de l'équipe 24

A.1 Positionnement des CCI entre privé et public 43

A.2 Une organisation pyramidale mais non hiérarchisée 45

C.1 Répartition des ressources de la CCI (13 328 M€) 49

C.2 Part de l'IATP dans le budget de la CCI 50

C.3 Répartition des ressortissants par secteur d'activité en 2003 50

D.1 Organigramme simplifié de la CCI de la Haute-Savoie 51

K.1 Nombre de lignes par procédure 66

K.2 Nombre d'instructions SQL par procédure 67

K.3 Nombre de structures if ou while par procédure 67

K.4 Nombre de curseurs par procédure 68

K.5 Répartition des procédures par type 68

Liste des tableaux

10.1 Dénombrement du contenu des bases de données 32

10.2 Catégories de procédures 36

10.3 Estimation du temps de développement par catégorie de procédures . 37

C.1 Répartition de la taxe professionelle départementale 49

F.1 Limitations of PostgreSQL 53

Liste des codes sources

H.1 Options de sybase2postgresql affichées grâce à l'option -h 56

H.2 Exemple de fichier de configuration de sybase2postgresql 57

J.1 Création des fonctions suser_id() et suser_id(username) 62

J.2 Création d'une fonction de conversion de type (varchar vers int) 63

J.3 Création d'une fonction de conversion de type (smallint vers bit) 63

L.1 Fichier de configuration du module MCPAN 69

Introduction

Afin de valider l'année de master de la formation OTSI de l'IUP GSI, chaque étudiant doit effectuer un stage de quatre mois en entreprise.

Ce stage est une étape importante pour un étudiant, non seulement du point de vue de la scolarité, mais aussi d'un point de vue personnel. La vie en entreprise est en effet nécessaire à la mise en pratique de l'enseignement reçu à l'IUP.

Ce rapport présente l'ensemble des travaux que j'ai effectués au cours de mon stage au siège de la CCI (Chambre de Commerce et d'Industrie) de la Haute Savoie à Annecy.

Durant ces 16 semaines, l'activité du stagiaire doit se partager entre une activité d'apprentissage "fondamental" (on pourrait dire "théorique") et une activité d'apprentissage "professionnel".

L'objectif de notre recherche est d'arriver à une réflexion théorique sur la migration de bases de données en se basant sur une expérience concrète qu'est la migration de bases sous Sybase vers PostgreSQL.

Cette réflexion a pour but de faire ressortir les approches et solutions possibles pour la résolution de cette problématique.

Ce mémoire s'articulera donc autour de trois axes:

Tout d'abord, nous présenterons le cadre du stage, la CCI, le sujet proposé et la problématique posée.

Ensuite, nous examinerons cette problématique et tenterons de lui apporter des solutions.

Enfin, le reste du mémoire portera sur l'ensemble du travail effectué : la méthodologie, les choix effectués, les résultats obtenus, leur analyse et les perspectives envisageables.

Ce rapport, produit avec L^ATEX2å, a été compilé le 25 juin 2004.

Premiere partie

L'existant

Chapitre 1

Présentation de la C.C.I.

1.1 Son Histoire

C'est en 1899 (soit 39 ans après l'annexion de la Savoie par la France) qu'un décret du Président Félix Faure institue une Chambre de Commerce a Annecy. Elle rejoint ainsi la vingtaine de Chambre de Commerces réparties sur l'ensemble du territoire (voir Annexe A, page 42).

A l'origine, la Chambre naissante est hébergée au rez-de-chaussée de la mairie d'Annecy puis dans l'ancien évêché. En 1932, elle emménage dans des nouveaux locaux qu'elle a fait construire rue du lac sur le terrain de l'ancienne caserne du 50ème Régiment d'Infanterie. Depuis juillet 2003, la Chambre de Commerce se trouve dans de nouveaux locaux (voir Annexe B, page 47), construits eux aussi a l'emplacement d'une ancienne caserne (celle du 27ème BCA).

FIG. 1.1 - Nouveau bâtiment de la CCI dans le quartier Galbert

1.2 Son implantation

Le département regroupe 4 poles économiques distincts, dotés chacun d'une spécificité et d'une problématique propre (Annecy, Genevois, Vallée de l'Arve et Chablais). Dès 1992, la C.C.I. décide d'ouvrir des antennes permanentes dans ces différent bas-sins d'emploi.

Aujourd'hui, la C.C.I. dispose d'un siège a Annecy et de trois antennes permanentes a Archamps, Marin et Scionzier.

FIG. 1.2 - Implantations de la C.C.I. en Haute-Savoie

1.3 Sa mission et ses objectifs

La CCI de la Haute-Savoie a élaboré un projet d'entreprise dont l'objectif est de détecter, répondre et anticiper les besoins des 26 227 commerçants, industriels et prestataires de services du département. Sa mission est d'optimiser les performances des entreprises haut-savoyardes a travers une stratégie fondée sur la dynamique commerciale des entreprises et des territoires. Plusieurs actions phares concrétisent cet objectif :

- Faciliter la création et la reprise d'entreprises

- Pérenniser les jeunes entreprises

- Accompagner les chefs d'entreprises dans leur parcours d'entrepreneur

- Préparer la transmission d'entreprises

- Dynamiser l'environnement local

- Gérer les infrastructures indispensables au développement des entreprises (Aéroport d'Annecy Haute-Savoie, Gares routières d'Annecy, Annemasse et Cluses, Centre Régional de Douanes et de Transports d'Epagny)

Pour l'année 2004, la CCI a établi différents objectifs qui lui permettront de poursuivre la mise en cuvre de son Projet d'Entreprise:

- Offrir a ses clients (les entreprises) des prestations déclinées dans un catalogue produits,

- Développer des projets avec ses partenaires¹ par un renforcement de la démarche partenariale,

- Organiser des évènements destinés aux entrepreneurs et aux entreprises.

¹Collectivités territoriales et entreprises participant a la création, la pérennisation, l'animation et la transmission des entreprises.

La création d'un catalogue produits a également pour but de rendre la CCI beaucoup plus indépendante de l'Impôt Additionnel à la Taxe Professionnelle (voir Annexe C, page 49) en vendant de nouveaux types de prestations à ses clients.

1.4 Son organisation

FIG. 1.3 - Organisation globale de la CCI

1.4.1 Les élus

Tous les 3 ans, les chefs d'entreprises de la Haute-Savoie sont appelés à désigner, à l'occasion des élections Consulaires leurs représentants à la CCI qui sont répartis en différents collèges:

- 34 membres titulaires:

Ils forment l'Assemblée Générale qui est l'instance souveraine. Les présidents, les membres du bureau et les présidents de commissions, sont élus parmi eux et par eux. Ils votent le budget annuel qui est ensuite soumis à l'approbation des ministères de tutelle.

- 33 membres associés:

Au côté des 34 membres titulaires, ils sont désignés après chaque élection et ils participent aux Assemblées Générales avec une voix consultative.

- 106 délégués consulaires:

Ils sont élus et représentent la CCI dans les 33 cantons du département.

1.4.2 Les collaborateurs

Les employés de la chambre de commerce sont répartis en 13 services, plus l'accueil (voir Annexe D, page 51) et répartis sur 6 "plateaux" (chaque plateau étant un étage du bâtiment).

1.5 Le service TIC

1.5.1 Ses missions

Le service TIC a en charge les choix stratégiques à court et moyen terme dans le domaine de l'informatique et des nouvelles technologies de l'information et de la communication.

Les principaux axes d'intervention sont:

- La surveillance et l'intervention sur les équipements informatiques (serveurs, postes clients, . . .).

- La mise en place et la maintenance du réseau informatique.

- L'identification, l'évaluation et la quantification des besoins exprimés par les services.

- La proposition de solutions adaptées (techniques, logiciels, formations) en conservant au maximum une cohérence avec le système d'information existant.

- La maintenance des applications propres à la CCI de la Haute-Savoie.

- La veille technologique au sens large dans le secteur de l'informatique et des TIC.

- Les formations spécifiques à la CCI.

1.5.2 Ses acteurs

- Christophe Pollier (Directeur)

- Grégory Benoist (Technicien administrateur réseau)

- Vincent Augier-Micou (Développement et maintenance SGBD)

- Laurence Boquet (Support utilisateur - Formation)

- Laurent Possety (Maintenance du parc informatique)

Chapitre 2

Sujet et Objectifs

2.1 Presentation du contexte

2.1.1 Le Système d'Information de la CCI

La Chambre de Commerce et d'industrie de la Haute-Savoie s'est dotée, au fur et à mesure de sa croissance de différents outils informatiques.

Certains de ces outils sont des applications courantes et ont un fonctionnement "imposé" (Xerox Docushare, Microsoft Exchange, . . .).

D'autres applications sont quant à elles développées au sein de la CCI et continuent donc d'évoluer parallèlement aux besoins.

L'application la plus importante est BEE (Base Économique Événementielle), une application métier développée sous 4D¹ associée à une base de données Sybase. C'est un outil de CRM qui constitue le coeur du système d'information de la CCI puisque, comme son nom l'indique, son but est de recenser tous les événements réalisés : contact avec un ressortissant, courrier postal et électronique, contact téléphonique ou email . . .

2.1.2 Caracteristiques techniques du Système d'Information

Le serveur Sybase contient plusieurs bases de données utilisées par les différentes applications de la CCI:

- base cci: Elle stocke les données concernant la CRM (BEE), la taxe d'apprentissage, les formations et l'aéroport (statistiques des vols).

- base consulaire : Elle stocke les fichiers "officiels" des entreprises ainsi que les formalités d'export (ATA-VISA).

- base cfe : Elle stocke les données du centre de formalités des entreprises. Elle n'est utilisée que pour conserver l'historique car l'application traitant ce type de données est maintenant nationale.

- base personnel: Elle stocke les données des Ressources Humaines (principalement utilisée pour le trombinoscope et la gestion des entretiens annuels).

Il y a actuellement 3 serveurs Sybase² : 2 serveurs en production (1 serveur principal

¹4D (4ème Dimension) est un atelier logiciel de développement et de déploiement d'applications multipostes crossplate-forme.

²Sybase version 11.0.2/P en production et version 11.0.3.3 en test

et 1 serveur avec une réplication³ quotidienne) et 1 serveur en test.

2.2 Présentation du projet

Les applications métier de la CCI s'appuient, comme nous l'avons précédemment indiqué (voir § 2.1.2, page 7), sur différentes bases de données fonctionnant sur un serveur Sybase.

La version de Sybase utilisée étant relativement ancienne, la CCI doit envisager une évolution importante, que ce soit la migration vers une version plus récente de Sybase ou vers un autre moteur de base de données.

Les collaborateurs de la CCI utiisent déjà avec succès différents logiciels libres. Il a donc été décidé d'évaluer l'opportunité d'effectuer cette migration vers une base de données libre. Cependant, les applications reposant sur cette base de données étant critiques pour le fonctionnement de la CCI, une migration de cette ampleur ne peut se décider à la légère.

Suite à ces différentes réflexions, il a été décidé d'effectuer une étude poussée afin de déterminer si cette migration était possible.

Cette étude devait donc porter sur les points suivants:

- Étude des différentes techniques de migration;

- Choix de la méthodologie à employer;

- Migration des structures (tables, séquences, index, vues);

- Migration des données;

- Migration des traitements (Triggers, Procédures);

- Mesure de l'efficacité du nouveau moteur de base de données.

³Le serveur de réplication est un serveur accessible depuis les applications cientes et dont le but est d'éviter les surcharges du serveur principal (pour ne pas trop ralentir le serveur principal avec de grosses requêtes ne nécessitant pas des données ayant moins de 24 heures, celles-ci sont réalisées sur le serveur de réplication).

Chapitre 3

La problematique Système

d'Information

Le problème de migration d'un SGBD a un autre, lorsqu'on y regarde d'un peu plus près, est en fait, le passage d'un langage a un autre. Or, lorsqu'on parle de traduction, on pense plus généralement a la linguistique et a l'étude du langage naturel.

Ce rapprochement, même s'il peut paraltre incongru a première vue, est finalement assez logique car les langages dits artificiels possèdent un grand nombre de caractéristiques communes avec les langages naturels. Les travaux de Noam Chomsky [11] sur l'approche de la linguistique générative ont fait ressortir des similitudes entre les langages naturels et les langages informatiques. On peut en effet y trouver des problématiques liées au lexique (vocabulaire), a la syntaxe et a la sémantique.

Ce rapprochement est d'autant plus évident lorsqu'on se base sur les travaux de recherche faits sur les compilateurs informatiques [12] qui utiisent de facon importante les travaux effectués en linguistique et sont des traducteurs (ils traduisent un langage écrit par un humain vers un langage compréhensible par un ordinateur).

Bien évidemment, la complexité des problèmes liés aux langages informatiques est moindre que celle liée a l'étude des langages naturels car certains aspects de la linguistique comme l'étude du langage parlé (phonétique, phonologie) ne sont pas présents et que le lexique employé est généralement moins conséquent.

Cependant, on peut tout de même retrouver, dans l'étude des langages informatiques, certains des problèmes les plus complexes de la linguistique et notamment les problèmes de pragmatique (variation du sens en fonction du contexte), voire même se trouver confronté a des situations oü le contexte n'est pas exprimé explicitement (il dépend de l'état du système ou d'autres données accédées directement en interne par le SGBD par exemple).

De plus, l'écriture dans un langage informatique est normalement plus rigoureuse, mais, tout comme les langages naturels, les langages artificiels, assez simples lors de leur création, ont évolué en gardant trace de leur histoire (on peut par exemple utiiser plusieurs syntaxes ou un vocabulaire totalement différent pour effectuer une même action).

Enfin, même si, comme nous l'avons dit, la problématique de la traduction dans le cadre des langages artificiels est beaucoup plus simple que pour les langages naturels, on peut rappeler que, pour cette dernière, de nombreuses recherches sont encore en cours. La traduction automatique est un problème qui a longtemps été sous-estimé

mais qui est en fait l'un des plus délicats à effectuer pour un ordinateur. Aux phases lexicales et syntaxiques, à peu près maîtrisées, s'ajoutent une analyse sémantique, puis pragmatique, qui tentent de déterminer le sens particulier d'un mot, dans le contexte oü il apparaît. Le contexte lui-même pouvant s'étendre à l'ensemble du texte traduit.

Nous allons donc étudier les différentes approches et méthodologies issues de la linguistique informatique pour mener à bien un travail de traduction afin de déterminer quelles solutions peuvent être envisagées lorsqu'on se trouve confronté à un problème de migration de bases de données.

Deuxième partie

Étude de la problématique de

migration de base de données

Chapitre 4

Les approches possibles

4.1 L'approche "systématique"

Comme la migration d'un gestionnaire de base de données à un autre est assez semblable à la traduction d'un langage (naturel ou artificiel) vers un autre, il est possible d'utiliser une démarche proche de celles employées en ingénierie linguistique.

FIG. 4.1 - Utiisation d'une méthode systématique pour la traduction de textes

Cette démarche passe tout d'abord par l'élaboration d'un corpus [13]. Dans notre cas, le corpus créé peut être composé des définitions du langage utilisé par le SGBD, généralement fournies dans les documentations techniques, et complétées par des exemples de cas complexes.

Lorsque le corpus est assez complet, il est alors possible d'en extraire le lexique, la syntaxe et la sémantique du langage.

Dans notre cas, nous cherchons à réaliser une traduction d'un langage vers un autre, il faut donc effectuer ces opérations pour les deux langages afin de pouvoir les comparer et déterminer quels sont les éléments qui les différencient et obtenir des règles de traduction.

Enfin, il est possible d'appliquer ces règles à un document écrit dans un des langages pour obtenir sa traduction dans l'autre.

Lorsqu'on applique une approche systématique au traitement informatique d'une migration, on pourra assimiler cette démarche à une approche descendante (également appelée approche 'top-down').

Cette approche est à privilégier lorsqu'on se trouve confronté à la traduction d'un grand nombre de documents très hétérogènes ou à de nouveaux types de documents. Cette approche est longue à mettre à place, non seulement à cause de la nécessité de rassembler un corpus de documents suffisamment vaste pour couvrir tous les aspects d'un langage, mais aussi par la complexité d'extraction du lexique et de la grammaire de ce corpus.

Cependant, dans les cas complexes, on préférera ce type de cheminement car il per-met d'obtenir un traducteur "générique", capable de faire face à un nouveau document sans rencontrer de problèmes. Grâce à cela, il est également possible d'obtenir assez facilement un traducteur pour un langage "proche" (pour les langages informatiques comme pour les langages naturels, il existe des "familles de langues"¹ qui ont les mêmes origines et donc un grand nombre de règles communes.

Suite à ces réflexions, on peut voir que l'approche systématique est destinée à réaliser un traducteur complet et flexible.

4.2 L'approche "empirique"

L'approche empirique, contrairement à l'approche systématique, se base sur le document ou l'ensemble de documents qui doivent être traduits et non sur un ensemble de documents de référence.

Cette démarche passe tout d'abord par la traduction "manuelle" de parties du document pour déterminer les règles de traduction.

On traduit ainsi des parties dont le lexique, la sémantique et la syntaxe sont différents jusqu'à obtenir des règles permettant de traiter l'ensemble du document. Une fois ces règles écrites, il est alors possible de les appliquer au document afin d'en obtenir une traduction complète.

¹Pour les langages naturels, on peut par exemple citer le français, l'espagnol et l'italien qui sont des langues latines. Pour l'informatique, on peut citer le C++ et la java qui ont des origines dans le C ou Sybase et MS-SQL qui sont partis tous les deux d'une ancienne version de Sybase

FIG. 4.2 - Utilisation d'une méthode empirique pour la traduction de textes

Ici, cette approche peut être assimilée à un approche montante (également appelée 'bottom-up') car on part de "problèmes spécifiques" à un document jusqu'à obtenir un traducteur par agrégation de ces problèmes.

Si on possède suffisamment de documents différents et qu'ils couvrent tous les cas existants, on peut, par empirisme, obtenir un traducteur aussi complet que celui qu'on obtiendrait par une approche systématique mais cela nécessiterait une quantité de travail bien supérieure.

De plus, la complexité non linéaire de cette approche est un problème car chaque "cas particulier" résolu risque de rentrer en conflit avec les cas résolus précédemment ce qui implique que plus le nombre de règles de traduction augmente, plus le nombre de contradictions possibles augmente.

En fait, cette approche n'est rapide à mettre en place que si on a un nombre limité de "problèmes" de traduction et que l'on veut obtenir un traducteur pour un faible nombre de documents (ou si ces documents utilisent exactement les mêmes règles de traduction).

Cependant, cette démarche est limitée par le fait que l'écriture des règles passe par une phase de traduction manuelle. Si on doit traduire des documents très différents ou si les schémas linguistiques ne se trouvent pas assez souvent répétés, l'ensemble du travail de traduction sera finalement réalisé manuellement. Par exemple, si on se trouve dans le cas d'un document trop court, chaque élément traduit manuellement créera une nouvelle règle mais celle-ci ne sera utilisée que pour cet élément.

Comme les approches de type bottom-up ont une relation très forte avec l'existant, elles sont beaucoup plus adaptées dans le cas où on ne veut pas faire un outil généraliste mais spécifique à une situation. L'approche empirique sera donc réservée à la

résolution de problèmes ponctuels et à une traduction unidirectionelle (car les problèmes liés à la traduction ne sont pas forcément bijectifs).

4.3 Combinaison de l'approche "systématique" et de l'approche "empirique"

Cette approche n'est généralement pas possible à mettre en place car, si elle apporte une bien plus grande fiabilité (il y a de grandes chances qu'aucun cas "spécifique" et qu'aucune exception ne soit oubliés), apporte également une bien plus grande complexité et un temps demise en oeuvre beaucoup plus grand car il faut effectuer chacune des deux méthodes puis mettre en relation les résultats obtenus pour obtenir un seul ensemble de règles de traduction.

La combinaison de modules en vue d'obtenir une solution cohérente est d'ailleurs, à elle seule, un sujet complexe nécessitant des études poussées [14] car l'efficacité de l'analyse lexicale dépend directement dont les différentes parties de l'analyseur fonctionnent en corrélation et non en opposition.

Chapitre 5

Les outils et technologies

applicables

Les deux approches décrites précédemment (voir Chapitre 4, page 12) détaillent la démarche qui peut être suivie afin d'obtenir un traducteur. Leur mise en oeuvre nécessite des outils dont une partie va être présentée ci-dessous.

5.1 Utilisation d'une interlangue

Les interlangues (ou langages pivots) sont fréquemment utilisées dans le domaine de la traduction automatique. Une interlangue est une langue artificielle qui sert d'intermédaire entre une langue source et une langue cible.

FIG. 5.1 - Méthode de traduction avec une interlangue

Les interlangues sont généralement utilisées lorsqu'on doit effectuer des traductions entre plusieurs langages.

Un grand nombre de travaux de recherche en linguistique se sont penchés sur les interlangues. On peut notamment parler du projet Traduction de Langues Distribuée (en anglais : Distributed Language Translation, en espéranto Distribuita Lingvo-Tradukado, en abrégé DLT) qui était un projet de traduction de langues de la Commission européenne¹. Le projet avait pour but la traduction automatique depuis et vers 12 langues européennes par le biais d'une interlangue interne basée sur l'Espéranto, qu'on nommait ILO (Internacia Lingvo = Langue Internationale).

En informatique, on utilise ce type d'outil dans la mise en place d'EAI. Dans ce cas, l'EAI se sert d'une interlangue (par exemple le XML) et se sert de traducteurs, appelés connecteurs, pour faire communiquer des systèmes hétérogènes entre eux.

Les interlangues sont habituellement utiisées avec une approche de type systématique car elles sont destinées à obtenir des traducteurs généralistes et assez exhaustifs entre plusieurs langages. Elles n'ont d'ailleurs d'intérêt que si on est en présence de plus de trois langages.

FIG. 5.2 - Méthode de traduction sans interlangue

¹Dans la sphère de la traduction technique (ex: entre le français et l'anglais, avec une traduction intermédiaire en ILO -Internacia LingvO = Langue Internationale- et retour) on atteignait 95% de précision sur les phrases traduites. Dans la sphère de textes très généraux (ex: comptes-rendus d'assemblées de l'UNESCO) la précision de la traduction se situait entre 50 et 60 %.

En effet, lorsqu'on veut effectuer une traduction entre deux langages, le passage par une interlangue nécessite plus de travail (deux traducteurs au lieu d'un), mais, si on dépasse trois langages, on peut voir que l'utilisation d'une interlangue (voir Figure 5.1, page 16) permet de ne créer qu'un seul connecteur lors de l'ajout d'un quatrième langage alors qu'il faut trois connecteurs lorsqu'on n'utilise pas d'interlangue (voir Figure 5.2, page 17).

Cette solution, est donc très coûteuse pour un petit nombre de langages alors qu'elle est beaucoup plus économique lorsqu'on dépasse le seuil de trois langues.

C'est pourquoi, dans le cadre d'une migration entre "seulement" deux systèmes, il est assez improbable que cette méthode soit la plus intéressante à utiliser (à moins de déjà disposer de traducteurs fiables vers une même interlangue).

5.2 Traduction "manuelle"

La traduction manuelle, comme son nom l'indique, ne fait appel à aucun mécanisme d'automatisation.

Dans ce cas, la traduction de tout le document est effectuée par un traducteur humain. Bien que cela ne soit généralement pas formalisé, les traducteurs utilisent habituellement une approche de type empirique car, lorsqu'ils rencontrent un problème et qu'ils le résolvent une première fois, ils sauront comment le résoudre s'ils s'y trouvent confrontés une seconde fois.

5.3 Traduction automatique "monotraducteur"

Aussi bien dans le cadre d'une approche systématique que par l'application d'une approche empirique, on obtient un ensemble de règles de traduction qui permettent ensuite d'effectuer automatiquement la traduction de documents.

La traduction est réalisée par un logiciel chargé d'appliquer les règles de traduction de façon systématique.

Mais, avant d'utiiser un logiciel de traduction automatique, il faut avoir préalablement définit ces règles et cela est complexe et nécessite un fort investissement.

FIG. 5.3 - Méthode de traduction automatique

5.4 Utilisation d'outils de "reverse-engenering"

Généralement basés sur une approche systématique, ce sont des outils dont le fonctionnement est proche de celui de l'interlangue. Toutefois, le langage utiisé est sou-vent proche de l'UML et ce sont des outils intégrés et fournis "tels-quels".

Ces outils vendus ou mis à disposition par des entreprises d'édition de logiciels, ce sont des solutions de type "clefs en main". Cependant, comme l'import ou l'export depuis ou vers un SGBD se fait par un traducteur spécifique, il faut que les connecteurs existent (malheureusement si on utilise un ou des systèmes peu courants, il est assez difficile de trouver un atelier de reverse-engenering proposant les traducteurs nécessaires).

Chapitre 6

Les méthodes de gestion de projet

informatique

Comme tout autre projet informatique, et même généralement comme tout projet, la migration de bases de données doit être programmée, suivie, piotée et analysée. Ces fonctions, remplies par le chef de projet, peuvent s'appuyer sur différentes méthodologies couramment employées.

La méthode employée ne doit pas être choisie à la légère car la réussite ou non du projet en dépendra fortement.

6.1 Méthode non formelle

Dans le cadre de projets avec peu de ressources (1 ou deux personnes au maximum), l'affectation de temps à la gestion de projet peut entraîner des surcoûts importants. Comme le nombre de personnel est très faible, leur coordination et leur affectation ne pose pas de problème et l'ordonnancement des tâches est très simple (on ne peut faire qu'une seule chose à la fois).

De plus, des comptes-rendus réguliers au client lors de réunions d'avancement et à la hiérarchie lors de réunions de service ou de façon informelle, permettent de pioter de façon assez fiable le projet et de réagir rapidement en cas de dérive.

6.2 XP: eXtreme Programing

XP propose un ensemble de "Bests Practices" de développement (travail en équipes, transfert de compétences, . . .), c'est une méthode itérative, simple à mettre en oeuvre destinée à des équipes de petite taille composées de membres autonomes, c'est une méthode très réactive mais qui demande une forte implication du client.

- Gestion des livraisons : L'équipe fournit des livraisons fréquentes au client. Le contenu de ces livraisons est décidé par le client lui-même, à partir des estimations fournies par les développeurs.

- Gestion des itérations : Les livraisons sont réalisées en une suite d'itérations de 2 semaines environ, au sein desquelles le projet est géré à un niveau de détail plus fin.

- Suivi du projet : L'avancement du projet est mesuré de manière concrète par une batterie de tests de recette automatiques. Le rythme de progression est réévalué à chaque itération, et le plan de développement lui-même est revu fréquemment pour tirer parti de l'expérience acquise au cours du projet.

- Qualité du design et du code : Des pratiques strictes permettent de garder une vitesse de développement élevée tout au long du projet, tout en gardant une ouverture maximale au changement. La conception reste toujours le plus simple possible, le code est nettoyé en permanence et des tests unitaires de non-régression sont écrits pour chaque classe.

- Travail en équipe : L'équipe travaille réellement en équipe. Le code est partagé par tous, les développeurs travaillent systématiquement en binômes, et l'intégration est quasiment continue."

6.3 RUP: Rational Unified Process

RUP est à la fois une méthodologie et un outil prêt à l'emploi (documents types partagés dans un référentiel Web).

C'est est un processus de développement logiciel itératif et incrémental, centré sur l'architecture, conduit par les cas d'utiisation et pioté par les risques. Il est destiné aux projets nécessitant un grand nombre de ressources humaines. Il n'est d'ailleurs utilisable que si une personne est affectée à temps complet (ou presque) à la gestion de projet car il y a beaucoup d'étapes à suivre et de documents à réaliser.

De plus, il faut commencer par adapter RUP à son projet, ce qui le rend intéressant à utiliser uniquement dans le cadre d'une équipe qui travaille toujours sur le même type de projet et toujours avec RUP.

RUP présente un certain nombre de caractéristiques, il est:

- Itératif et incrémental : le projet est découpé en itérations de courte durée (environ 1 mois) qui permettent de mieux suivre l'avancement global. A la fin de chaque itération, une partie exécutable du système final est produite, de façon incrémentale.

- Directif: Spécifie le dialogue entre les différents intervenants du projet (les livrables, les plannings, les prototypes, ...) et propose des modèles de documents, et des canevas pour des projets types.

- Centré sur l'architecture : tout système complexe doit être décomposé en parties modulaires afin de garantir une maintenance et une évolution faciitées. Cette architecture (fonctionnelle, logique, matérielle, etc.) doit être modélisée en UML et pas seulement documentée en texte.

- Pioté par les risques : les risques majeurs du projet doivent être identifiés au plus tôt mais surtout levés le plus rapidement possible. Les mesures à prendre dans ce cadre déterminent l'ordre des itérations.

- Conduit par les cas d'utilisation : le projet est mené en tenant compte des besoins et des exigences des utiisateurs. Les cas d'utilisation du futur système sont identifiés, décrits avec précision et priorisés.

6.4 DSDN (RAD)

L'organisation d'un projet par une méthode de type RAD s'appuie sur un principe fondamental : la séparation des rôles et des responsabilités entre maîtrise d'ouvrage (MOA) et maîtrise d'oeuvre (MOE).

La méthode RAD structure le cycle de vie du projet en 5 phases:

- L'initialisation définit l'organisation, le périmètre et le plan de communication.

- Le Cadrage définit un espace d'objectifs, de solutions et de moyens.

- Le Design modélise la solution et valide sa cohérence systémique.

- La Construction réalise en prototypage actif (validation permanente).

- La Finalisation est un contrôle final de qualité en site piote.

La méthode DSDM propose une approche globale du développement de logiciel dans un environnement de développement rapide (RAD). DSDM fournit un canevas couvrant l'ensemble du cycle de développement et un grand nombre de principes à suivre afin d'assurer le succès du projet.

Chapitre 7

Combinaison des approches, des

technologies et des méthodes

Lors de la mise en place du projet, il est essentiel de choisir les différents éléments (approche employée, technologies utilisées, méthodologie suivie et taille de l'équipe) de façon cohérente.

FIG. 7.2 - Exemple de mauvaise corrélation entre les approches, les technologies, les méthodes et la taille de l'équipe

Par exemple, un projet suivant une approche systématique, pour réaliser un outil basé sur une interlangue, avec une gestion de projet non formelle et une grosse équipe a de grande chance de foncer droit dans le mur.

FIG. 7.3 - Exemple de bonne corrélation entre les approches, les technologies, les méthodes et la taille de l'équipe

À l'opposé, un projet de traduction automatique monotraducteur, employant une approche empirique, et gérant une équipe projet grâce à une méthode non formelle démontre une vision cohérente du projet. La cohérence de cet ensemble de choix ne fera donc pas obstacle au bon déroulement du projet.

Lors du lancement du projet, on veillera donc tout particulièrement à ce que les différents éléments (même si chacun pris séparément semble être le meilleur choix) puissent être utilisés ensembles.

Chapitre 8

Proposition d'une démarche et de

"bonnes pratiques"

Lors d'un projet de migration de base de données comme dans tout autre projet informatique, il n'existe bien évidemment pas de "solution miracle" pour réussir à coup sûr mais il est possible de suivre une démarche et des bonnes pratiques (appelée aussi best practices) qui permettront d'augmenter les chances de réussite.

Cette démarche peut être découpée en trois grandes étapes. Après chacune d'elle, il est nécessaire de déterminer si le projet de migration est réaliste et réalisable afin de ne pas effectuer d'investissements inutiles.

8.1 Determiner la nature du problème

Dans un premier temps, l'étude doit porter sur la nature du travail à effectuer:

- Quelles sont les informations qui doivent être migrées (structure, données, traitements ou les trois)?

Une migration partielle est bien entendu plus simple à réaliser.

- De quelles "familles" sont la base de données origine et destination?

Si les bases de données sont de la même "famille" (par exemple Sybase et MS-SQL ou deux versions d'une même base de données), une migration nécessitera beaucoup moins de travail que pour des bases de données d'origine totalement différente.

8.2 Verifier s'il existe des solutions

Après avoir déterminé de quel type était le problème à traiter, la seconde étape consiste à rechercher si des solutions existantes peuvent être utilisées. Pour cela, il faut évidemment déterminer si les technologies utilisées sont applicables mais aussi si leur coût est acceptable.

Les outils de migration les plus courants sont basés sur le principe de reverse-engenering. Ils sont peu nombreux et particulièrement liés à une seule famille de base de données (le nombre de connecteurs vers d'autres bases de données est généralement limité).

On peut également trouver des solutions entièrement externalisées : une société de

services se charge d'effectuer toute la migration grâce à des outils qu'elle développe elle-même.

8.3 Effectuer la Migration

8.3.1 Si une solution existante a été trouvée

Si une solution existante est utiisable (l'outil a été conçu pour les systèmes que l'on utilise) et que son prix est acceptable, la solution doit être utiisée en n'oubliant pas de continuer à pioter le projet de migration et à éviter les dérives.

Une fois la migration réalisée, il ne reste qu'à effectuer un ensemble de tests afin de vérifier que tout s'est bien passé et affiner le paramètrage de la base de données afin d'en améliorer les performances.

8.3.2 Si aucune solution existante ne convient

Si aucune solution existante n'est adaptée à notre problème et que l'on souhaite poursuivre le projet, il convient de déterminer quelle approche et quelle solution doivent être adoptées (en fonction de la nature de la migration et du type de traducteur que l'on souhaite obtenir).

Troisième partie

Application au contexte du stage

Chapitre 9

Les choix managériaux et

technologiques

9.1 La gestion de projet

Ce stage était un projet informatique "comme un autre". On peut donc supposer que l'utilisation d'une méthodologie de gestion de projet informatique aurait été logique. Cependant, l'utilisation d'une méthode "stricte" était en fait peu adaptée a ce cas pour différents motifs:

- Le retour d'expérience sur ce genre de projet est assez rare (aussi bien au niveau personnel que dans les documentations disponibles), il n'y a donc pas d'indications sur le fonctionnement d'anciens projets du même type.

- Dans le cadre de projets menés par une seule personne (comme c'était le cas ici), la mise en place de mécanismes complets de management de projet peut s'avérer complexe et nécessiter plus de temps quelle n'en fait gagner.

Nous avons donc adopté une gestion de projet minimale, essentiellement basée sur les comptes-rendus hebdomadaires lors des réunions de service.

- Enfin, comme l'approche employée est de type empirique, son évolution est par essence difcile a prévoir (car on traite les problèmes au fur et a mesure de leur découverte). Une prévision trop précise et un planning décidé trop tot seraient remis en cause a chaque nouveau problème.

9.2 La démarche suivie

Ce projet a été découpé en quatres grandes "étapes" qui seront développées dans les chapitres suivants:

- Recherche et évaluation des solutions existantes (voir Section 10.2, page 33);

- Choix d'une solution (voir Section 9.3, page 29);

- Mise en cuvre de la solution (voir Section 10.3, page 33);

- Evaluation du travail a venir (voir Section 10.4, page 34).

9.3 Les technologies utilisées

9.3.1 PostgreSQL

Présentation

PostgreSQL¹ est un Système de Gestion de Base de Données Relationnelle (SGBDR) open source².

Il a été initialement développé à l'Université de Berkeley sous le nom de Ingres (1977- 1985). Il a été amélioré régulièrement au cours de ses premières années par les sociétés Rational Technologies et Ingres Corp.. Ces sociétés ont été rachetées par la société nommée maintenant Informix. Le projet a ensuite continué indépendamment à Berkeley sous le nom de Postgres (1986-1994). Après l'apparition des premières normes du langage SQL, le langage de requête de Postgres a été remplacé par le langage SQL. En 1995, le projet a ensuite été repris par des développeurs indépendants de l'Université de Berkeley et renommé Postgres95. Là, le projet s'est étoffé et transformé à partir de 1997 en PostgreSQL lorsque l'ensemble des fonctionnalités SQL a été intégré au serveur.

Avantages

PostgreSQL est un logiciel libre, il possède donc tous les avantages qui en découlent, entre autre:

- La gratuité;

- Le nombre de déploiements ilimité;

- La communauté de développement active et réactive;

- Les possibiité d'extension à volonté (le code source étant disponible gratuitement, il est possible de modifier ou d'étendre les fonctionnalités de PostgreSQL de façon autonome).

- . . .

PostgreSQL respecte la quasi totalité de la norme SQL et propose la plupart des fonctionnalités présentes dans les autres "grands" SGBD (gestion des transactions, procédures stockées, gestion des droits d'accès aux données, . . .).

Dans le monde du logiciel libre, (mis à part SAPDB qui est actuellement en pleine mutation due à son rapprochement de MySQL) PostgreSQL est certainement actuellement le seul SGBD permettant de gérer des bases de données à gros volume et avec un grand nombre de connexions notamment grâce à son haut degré de scalabilité.

Les concurrents libres de PostgreSQL ne sont pas aussi aboutis, tant pour la tenue en charge que pour le nombre de fonctionnalités disponibles, c'est pourquoi le choix en terme de bases de données assez limité.

Inconvénients

PosgreSQL n'est pas disponible nativement pour Windows, il utilise une couche d'émulation (CygWin). Seules les prochaines versions à partir de la numéro 8 (à venir) seront développées pour Windows.

¹Version utilisée : 7.3.4-RH

²Sous licence BSD (voir Annexe E, page 52)

PostgreSQL, s'il est connu pour sa robustesse, a également la réputation d'être relativement lent (même si chaque nouvelle version amène des progrès notables). Cela est dû au grand nombre de mécanismes de préservation et de protection des données qui sont activés par défaut mais qui peuvent pour la plupart être désactivés après une étude détaillée des besoins.

9.3.2 RedHat Database Présentation

RedHat Database³ est une version de PostgreSQL 7.3.4. optimisée pour fonctionner avec un serveur Red Hat Linux⁴ et qui bénéficie du back-portage des améliorations apparues avec la version 7.4.

Avantages

Rhdb⁵ est librement téléchargeable sur le serveur ftp de RedHat. Il est également possible d'acquérir un contrat de service (3267€) chez RedHat contenant:

- Red Hat Database (intégré, testé et optimisé Red Hat Linux)

- L'installeur Red Hat

- La documentation complète de RhDb et des outils graphiques

- Le support par le web et téléphonique

- Une inscription mensuelle fournissant des mises à jour régulières

La CCI possède actuellement un serveur sous RedHat et un contrat de type "Red Hat Enterprise Linux ES". En cas de problèmes non spécifiques à la base de données, il est donc possible de profiter du contrat de support souscrit.

Inconvénients

Red Hat n'a pas une politique très claire en ce qui concerne le support de ce produit. Certes, une équipe Red Hat travaille en permanence sur ce projet et une offre de services est proposée mais le site de vente de RedHat reste peu clair sur ses avantages : le contenu de l'offre n'est pas très détaillé et la version actuellement proposée est la 2.1⁶ alors la version 3 existe depuis plusieurs mois.

9.3.3 Perl Présentation

Crée en 1986 par Larry Wall, Perl (Practical Extraction and Report Language) est un langage de programmation interprété (avec une phase interne de pré-compilation). Sa syntaxe dérive des scripts shell, et d'autres langages comme C, awk, sed.

³Aussi appelé : PostgreSQL - Red Hat Edition ou RhDb ⁴version 9 ou Fedora Core 1

⁵Version utilisée : 3.0 (sortie le 16 janvier 2004) ⁶optimisé Red Hat Linux 7.1 et PostgreSQL 7.1.2

Avantages

Pour tous ceux qui connaissent ces langages, notamment pour ceux qui viennent du monde Unix, Perl est relativement facile à apprendre.

Perl a été conçu selon un concept de langage naturel : on écrit du Perl comme on pense. Cette caractéristique de Perl se retrouve dans son slogan "there is more than one way to do it".

La puissance de Perl pour la manipulation de chaînes de caractères et de fichiers lui donne des atouts considérables pour écrire des applications nécessitant des expressions régulières, par exemple le traitement de texte avec la création de pages à la volée. L'allocation de mémoire est prise en charge par l'interpréteur, il n'y a donc pas de gestion de mémoire, pas de limite de buffer.

Perl existe depuis plus de 15 ans, beaucoup de bibliothèques et de modules d'extensions sont donc déjà disponibles.

L'application première de Perl est l'administration Unix (manipulation de textes, de fichiers et de processus), une personne ayant ce type de compétences aura donc certainement des connaissances du langage Perl et pourra ainsi reprendre, maintenir et modifier le code source si cela est nécessaire.

Inconvénients

Perl possède certains inconvénients notamment des soucis de sécurité intrinsèques à son statut de langage interprété. Toutefois, il existe un mode "secure" qui vérifie pour chaque variable si elle est sécurisée ou non. Comme ce mode ralentit l'application, il est réservé au débuggage.

Perl n'est pas efficace pour le calcul scientifique.

C'est un langage très permissif qui laisse les programmeurs libres de coder selon leurs méthodes. Cependant, la diversité des méthodes de codage qui est un gros avantage pour la simplicité d'apprentissage du Perl est aussi un des principaux inconvénients du langage : il est souvent difficile de reprendre le code d'un autre développeur, surtout s'il n'est pas correctement documenté.

Chapitre 10

Le travail réalisé

10.1 Evaluation de l'état de la base de données existante

10.1.1 Découverte du fonctionnement et des spécificités

Avant de pouvoir commencer tout autre travail, il faut commencer par se familiariser avec l'environnement de travail. Ici, les principales applications à connaître sont:

- BEE : l'application de CRM;

- Sybase et les outils qui permettent de s'y connecter (DbDK et DBArtisan);

- Les bases de données présentes sur le serveur Sybase.

10.1.2 Quelques chiffres

Pour réaliser la migration, il a tout d'abord fallu étudier les bases un peu plus précisément afin de déterminer dans quelles catégories les classer (base principalement axée sur les données, sur les structures ou sur les traitements) et quel type d'outil utiliser.

TAB. 10.1 - Dénombrement du contenu des bases de données

De plus, il faut savoir que les plus grosses tables approchent les 390 000 enregistrements et que le volume actuel des bases de données est d'environ 18 Go.

Grâce à ces information, il est facile de s'apercevoir que la base cci, en plus d'être la plus importante au niveau utilisation est également celle contenant le plus d'éléments à migrer.

¹nombre de lignes de code de la totalité des procédures (commentaires compris)

Durant le projet, c'est donc sur cette base que doit se focaliser la majorité du travail.

10.2 Étude des différentes techniques de migration

Toute étude doit commencer par l'inventaire des solutions existantes de manière à ne pas se lancer dans un développement coûteux si un produit répond déjà à nos attentes.

La première piste explorée a été celle du site internet de PostgreSQL qui répertorie une large gamme de moyens pour migrer vers ce système.

On peut trouver dans cette catégorie nommée "Converting from other Databases to PostgreSQL", des outils et des conseils pour transformer des bases au format Dbase, FileMaker Pro, Interbase, MS-Access, MySQL et Oracle.

En ce qui concerne Sybase, on peut utiiser les conseils donnés pour MS-SQL mais ceux-ci sont très pauvres et ne donnent que quelques idées pour réaliser une migration manuelle.

La seconde possibilité pour trouver des outils de migration était de rechercher des outils ou des solutions "clefs en main" pour la migration de Sybase vers PostgreSQL. Force est de constater que même s'il existe des outils traitant chacune des bases de données, il n'en existe pas qui posséde des connecteurs pour les deux systèmes.

Aucune solution n'existant pour cette migration, la seule méthode possible est de réaliser soi-même un outil qui effectuera cette transformation.

10.3 Écriture d'un traducteur en Perl

10.3.1 L'approche utilisée

En vu de structurer la démarche du projet, la solution la plus simple était de le découper en plusieurs phases.

Les choix

Nous avons tout d'abord du déterminer l'approche, la technologie, la méthodologie et l'équipe employés.

Ces choix furent assez rapidement faits:

- Aucun salarié de la CCI n'étant disponible pour ce projet, l'équipe ne pouvait être composée que d'une seule personne.

- Après avoir effectué des recherches sur les solutions existantes, il est apparu qu'aucun outil ne permettait de réaliser une telle migration (voir § 10.2, page 33) et que très peu d'information était disponible pour utiliser une approche systématique. C'est donc l'utilisation d'une méthode empirique qui s'est imposée.

- La technologie utilisée devait permettre de reproduire cette migration même si quelques modifications apparaissaient dans le base (ce qui exclut une traduction manuelle) mais devait être compatible avec les choix déjà faits et le délai imparti. La technique d'un traducteur automatique a donc été retenue.

-

Enfin, ayant très peu de ressources à gérer et beaucoup d'autonomie quant au fonctionnement du traducteur, une méthodologie de gestion de projet "lourde" n'aurait apporté aucun bénéfice par rapport à l'utiisation d'une méthode non formelle.

L'organisation

Le choix d'une approche de type empirique ne dispense pas de structurer la démarche du projet. C'est pourquoi chaque type d'élément de la base (tables, index, données,...) a été traité indépendamment.

En outre, le fonctionnement même des bases de données a imposé un certain ordre de traitement. Il faut réaliser tout d'abord la transformation de la structure puis des données et enfin des traitements.

Les iterations

Pour chacun des types d'élément, une approche empirique peut se traduire par une suite d'itérations comprenant:

- La tentative d'utiliser le Script SQL "tel-quel";

- La recherche des problèmes empêchant le bon fonctionnement;

- L'écriture en Perl d'un programme permettant de régler le problème.

Une fois toutes les itérations effectuées pour tous les types d'éléments, on dispose d'un programme Perl permettant de résoudre tous les problèmes et d'effectuer la migration.

10.3.2 Fonctionnement de l'application

L'un des ojectifs de ce projet était de réaliser un outil de migration de la base de données qui soit facilement réutilisable. Il fallait donc que son uilisation soit simple et que son fonctionnement soit aisément compréhensible et modifiable par une autre équipe.

Le traducteur appelé sybase2postrgesql propose donc plusieurs modes de fonctionnement (voir Annexe J, page 60):

- Utilisation avec passage de paramètres en ligne de commande ou par un fichier de configuration.

- Possibilité de traduire chaque fichier individuellement ou d'automatiser l'ensemble du fonctionnement.

Par ailleurs, le programme a été documenté (voir Annexe I, page 58) et le code commenté afin de rendre leur réutilisation plus simple.

10.4 Estimation du travail restant a effectuer

La migration qui semblait relativement simple à ses débuts s'est révélée beaucoup plus complexe que prévue et la charge de travail sous-estimée. En cours de projet, les délais ont donc du être réévalués et il s'est avéré que la migration des procédures ne pouvait être réalisée dans le temps restant.

Suite à ce constat, nous avons déterminé qu'il était préférable de réaliser un ensemble de mesures afin d'estimer le temps nécessaire à l'achèvement du projet.

10.4.1 Méthode d'estimation

Comme l'approche que nous avons employé est de type empirique, il est difficile d'avoir, avant d'avoir effectuer le traducteur, des indicateurs fiables concernant les points bloquants de la migration. Cependant, certains problèmes sont proches de ceux rencontrés lors de la migration de la structure de la base (et tout particulièrement des vues) et d'autres peuvent être assez facilement repérés (nombre de lignes de code, nombre de structures de boucles et de choix, . . .).

Ainsi, il n'est pas réellement possible de mesurer précisément la complexité de la migration mais on peut en faire une estimation.

Le travail à effectué ici s'apparente à une mesure de complexité informatique [35] hormis que le but n'est pas d'évaluer la performance d'un algorithme mais la difficulté à le comprendre et le traduire et que les indicateurs disponibles sont un peu plus "approximatifs".

Les outils de mesure de complexité sont assez rares et ne permettent généralement de réaliser des tests que pour des langages courants (C, java, .. .). Il était donc très improbable de trouver un outil répondant à nos attentes (fonctionnant pour du Transac SQL et réalisant des mesures permettant d'évaluer la complexité de "compréhension").

Il a donc fallu mettre au point une méthode assez proche d'une mesure de complexité. Cette dernière peut être décomposée en trois grandes phases : la planification, la réalisation et l'analyse. Et même si la méthode est généralement présentée sous forme d'étapes, en réalité, celles-ci ne sont pas forcément effectuées séquentiellement et il y a habituellement plusieurs itérations avant d'obtenir des résultats probants.

Nous allons donc suivre les points suivants:

1. Planification (déterminer quelles mesures vont être réalisées):

- Sélectionner les variables qui vont être observées.

- Indiquer la signification des plages de valeurs dans lesquelles vont se trouver les variables.

- Spécifier le modèle qui va être observé.

- Définir un ensemble de données d'entraînement et de test pour évaluer le modèle.

2. Réalisation (effectuer les mesures):

- Tester le modèle sur les données de test et les comparer aux résultats attendus.

- Obtenir les valeurs des différents indicateurs sur des données réelles et complètes.

- Regrouper et présenter ces valeurs de manière à ce qu'elles soient exploitables.

3. Analyse (traitement et interprétation des résultats):

- Traitement des données afin de les rendre compréhensibles.

- Recoupement des informations afin de faire ressortir les éléments importants.

- Interprétation et analyse des résultats obtenus.

10.4.2 Réalisation des mesures

Afin d'effectuer les mesures permettant d'évaluer le travail restant, la première étape a été de définir un ensemble d'indicateurs:

- nombre de lignes de codes par procédure

-

nombre d'instructions SQL par procédure

- nombre de conditions et de boucles par procédure

Il a ensuite fallu développer une application en Perl pour effectuer les mesures qui correspondent à ces indicateurs.

En observant les résultats, il a été possible d'ajouter quelques indicateurs pour affiner les mesures:

- nombre de curseurs par procédures

- nombre d'exécutions d'autres procédures par procédure

De ces résultats, il a également été possible de déterminer des catégories dans lesquelles se trouvent les procédures.

TAB. 10.2 - Catégories de procédures

Enfin, il a été possible de réaliser les mesures définitives (voir Annexe K, page 66) qui seront exploitables pour donner une évaluation du temps de travail nécessaire à l'achèvement de la migration.

10.4.3 Résultats de l'estimation

Estimation grossière pour une traduction manuelle

Afin d'évaluer la charge de travail que représenterait la traduction manuelle des procédures, il convient tout d'abord de mesurer le volume d'information à traiter. Nous avons donc mesuré le nombre de lignes de code total que représentent les procédures (environ 150 000 hors commentaires).

Une évaluation approximative permet d'atteindre un volume de travail d'environ 1000 jours/homme (en comptant environ 150 lignes écrites par jour/homme).

La conversion manuelle des procédures n'est donc que difficilement envisageable. C'est pourquoi, il serait nécessaire de disposer d'un outil permettant la migration automatique de la plus grande partie des procédures.

Estimation affinée

À l'aide de l'ensemble des indicateurs, il est possible de répartir les procédures en différents niveaux de complexité et de calculer le nombre de jours de développement nécessaires pour terminer l'application.

TAB. 10.3 - Estimation du temps de développement par catégorie de procédures

On peut constater que, comme dans la plupart des projets, 80% du volume des procédures peuvent être migrées pour 20% du temps de travail.

Pour les procédures les plus difficiles à migrer (celles qui prennent 80% du temps de développement), il faut s'assurer de la pertinence et de l'utiité de chacune d'elle afin de ne pas perdre de temps inutilement.

Chapitre 11

Bilan du stage

11.1 Evaluation du travail réalisé

L'objectif principal : évaluer si une migration de Sybase vers PostgreSQL était possible, a été atteint.

En revanche, la réponse qui y a été apportée n'est pas exactement celle à laquelle on pouvait s'attendre : la migration paraissait simple mais elle s'est avérée beaucoup plus complexe que prévue.

11.2 Problèmes rencontrés

L'ensemble du stage s'est bien déroulé. Mais, comme dans tout projet, nous avons dû faire face à des problèmes : ceux-ci ont été principalement de nature technique, mais également organisationnels et au niveau des connaissances acquises.

11.2.1 Les problèmes techniques

Les fonctions Sybase inexistantes sous PostgreSQL

Comme toutes les bases de données, Sybase et PostgreSQL possédent des fonctions internes conçues afin de faciliter le travail des développeurs. Néanmoins, leur nom et parfois même leur utilisation différe d'un sytème à l'autre.

Lors de la migration des vues et des procédures, il arrive que ce type de fonctions necessite une intervention pour déterminer la solution à adopter.

Lorsque des fonctions de Sybase n'existent pas sous PostgreSQL, la solution la plus simple serait de créer des fonctions en pl/sql portant le même nom que la fonction Sybase et donnant le même résultat.

Mais cela crée une surcouche et a un impact néfaste sur les performances (une fonction externe utiisant une ou plusieurs fonctions internes sera touj ours moins rapide qu'une seule fonction interne).

Lors de l'écriture du programme de migration, nous avons donc utilisé autant que possible, des fonctions internes de PostgreSQL, même si cela nécessitait parfois de remanier les scripts SQL.

Cependant, dans quelques rares cas, aucune fonction existante ne pouvant être utiisée, il a fallu en créer des nouvelles (par exemple voir Source J.1, page 62).

Les differences d'encodage

Le passage successif par différents systèmes met en lumière les différences de normes d'encodage et d'affichage (UTF8, ASCII, Latin1,...):

- passage de Sybase à un fichier texte en utilisant un logiciel tiers (soit bcp soit DbDk) sous Windows,

- transformation par un script Perl sous Linux,

- intégration à PostgreSQL,

- affichage sous les outils RedHat (qui préfère utiliser l'UTF8).

Ceci nécessite de modifier l'encodage par défaut ou de forcer celui qui sert à l'affichage, voire même de modifier l'encodage d'un fichier dans un éditeur de texte (voir Annexe M, page 71) sous peine d'obtenir des retours à la ligne fantaisistes et de perdre tous les caractères accentués qui se trouvent dans les documents.

Les problèmes de casse

Windows et Sybase ne gèrent pas les différences de casse ("E" sera considéré de la même façon que "e") tandis que Linux et PostgreSQL font cette différenciation. Pour éviter des problèmes d'appel (par exemple lors de l'utiisation d'une table ou d'une procédure) il faut uniformiser les noms.

L'ancienneté de la base de données Sybase

La création de base de donnée sous Sybase a commencé en 1994. De nombreuses personnes avec des connaissances et des techniques de programmation différentes ont donc participé à sa gestion et à l'écriture de nouvelles fonctions. De plus, les technologies ont évolué : augmentation des capacités du moteur debase de données, évolution de la syntaxe utilisée pour la création de vues et des procédures. Lors de l'écriture des scripts Perl, il a donc fallu tenir compte des différents types d'écriture afin que toutes les possibilités soient traitées.

11.2.2 Les problèmes lies a l'organisation

Peu de problèmes se sont posés en ce qui concerne l'organisation propre mais les objectifs proposés au départ ont dû être modifiés. La plannification a été constament réévaluée afin de tenir compte des problèmes rencontrés et de l'approche empirique.

11.2.3 Les problèmes lies au manque de connaissance

Le manque d'informations disponibles, s'est révélé être un problème important: très peu de documentation est disponible au sujet de Sybase (et la plupart de sont prévues pour des versions plus récentes de Sybase).

Les informations concernant les migrations de base de données (et tout particulièrement les migrations à partir de Sybase ou de MS-SQL) sont rares et peu complètes: les seules indications fournies n'apportent quasiment aucune aide.

Conclusion

Les objectifs d'un stage professionnel sont multiples : le stagiaire doit tirer une double expérience (immersion dans le monde du travail et acquisition de nouvelles connaissances sur les activités en entreprise) et pouvoir apporter à l'entreprise un bénéfice aussi bien sous forme de nouvelles compétences liées à sa formation qu'à sa personnalité.

Ce stage a été enrichissant, aussi bien au niveau humain que professionel et sera un atout pour mon entrée dans la vie active. Il m'a apporté de nouvelles connaissances tant organisationnelles que techniques et m'a permis d'appronfondir les compétences que j'ai acquises tout au long de ma scolarité.

Le projet a mis en évidence que la méthodologie à mettre en oeuvre pour la migration de bases de données varie beaucoup selon les systèmes en jeu. Elle varie également beaucoup en fonction du "type" de migration désirée : migration "unitaire" ou migration "reproductible".

Les possibiités d'une migration de Sybase vers PostgreSQL était très mal connues et ce stage permet de se rendre compte qu'elle n'est pas simple à pratiquer et permet de mieux les connaître et les maitriser.

J'espère donc que l'ensemble formé par ce rapport et le programme de migration sybase2postgresql pourra constituer une première étape vers une migration définitive en direction de Sybase.

Liste des annexes

A Les CCI en France 42

B La CCI de la Haute-Savoie 47

C Les Chiffres de la CCI de la Haute-Savoie 49

D Organigramme 51

E La licence BSD (Berkeley Software Distribution) 52

F Limitations de PostgreSQL 53

G Phases pour réaliser l'ensemble de la migration 54

H Options pour l'utilisation de sybase2postgresql 56

I Documentation de sybase2postgresql 58

J Problèmes spécifiques a chaque type d'information a migrer 60

K Mesures pour les indicateurs de complexité des procédures 66

L Installation de modules supplémentaires pour Perl 69

M Enregistrement d'un fichier en UTF-8 sous Emacs 71

N Webographie 72

Annexe A

Les CCI en France

A.1 Historique

La première Chambre naît à Marseille en 1599. Le conseil de la vile décide de choisir, parmi ses membres, des députés du commerce "chargés d'accroître la prospérité de la ville". La raison d'être des Chambres de Commerce est exprimée. Henri IV officialise l'institution et en profite pour demander aux députés "des recommandations pour relever l'économie du royaume". La fonction traditionnelle de consultation fait sa première apparition.

Le nombre de Chambres de Commerce s'accroît. Louis XIV crée un conseil du Commerce : le Roi veut recevoir des propositions pour "augmenter le commerce en France et en dehors du royaume". La mission des Chambres de Commerce est tracée.

La Révolution les supprime. Elles sont rétablies sous le consulat par Bonaparte. Vingt deux nouvelles chambres sont créées en France et dans l'Empire. Elles s'implantent partout où l'économie locale a besoin de leur structure et de leurs services. Elles vont se développer pendant tout le XIXè siècle. Le réseau se met en place. En 1898, la loi vient formaliser leur rôle et crée un statut original, celui d'Etablissement Public représentant les intérêts généraux du commerce et de l'industrie auprès des pouvoirs publics. Le cadre juridique est fixé.

Durant le XXè siècle le visage contemporain des Chambres de Commerce se dessine définitivement. On les appelle depuis 1960, Chambre de Commerce et d'Industrie (CCI); en 1964, le législateur achève l'édifice en créant les Chambres Régionales de Commerce et d'Industrie (CRCI), établissements publics, qui fédèrent les CCI locales. Simultanément, la création de l'Assemblée Permanente des Chambres de Commerce et d'Industrie (APCCI) couronne le réseau en fournissant aux instances nationales un interlocuteur privilégié. Depuis 1990, I'APCCI s'est transformée en Assemblée des Chambres Françaises de Commerce et d'Industrie (ACFCI).

A.2 Nature des CCI

Les Chambres de Commerce et d'Industrie sont à la fois des organismes publics et professionnels puisque:

- elles sont régies par une loi et sous tutelle d'un ministère représenté aux Assemblées Générales par le Préfet du Département;

- elles sont composées et dirigées par des chefs d'entreprise élus par leurs pairs, ressortissants de la CCI.

Il convient de ne pas les confondre avec les administrations d'État (les CCI ne sont soumises à aucune autorité dans le cadre de leur mission bien qu'ayant une tutelle mi-