Étude D’une Migration De Sybase Vers...

C.C.I. DE LA

HAUTE-SAVOIE5 rue du 27ème BCA - BP 2072

74011 Annecy CEDEX

VIRGINIE QUESNAYMaster OTSIAnnée 03/04

MÉMOIRE PROFESSIONNELÉtude d’une migration de Sybase vers PostgreSQL

Enseignant tuteur : Christian BRAESCHMaître de stage : Christophe POLLIER INSTITUT UNIVERSITAIRE PROFESSIONNALISÉ

DE GÉNIE DES SYSTÈMES INDUSTRIELS

Génie des systèmes d’information

C.C.I. DE LA


74011 Annecy CEDEX


MÉMOIRE PROFESSIONNELÉtude d’une migration de Sybase vers PostgreSQL

Maître de stage : Christophe POLLIER Enseignant tuteur : Christian BRAESCH

C.C.I. DE LA


74011 Annecy CEDEX


'

&

$

%

RÉSUMÉ :Ce mémoire a été réalisé lors de mon stage de fin d’études deMaster à l’IUP-GSI d’Annecy le Vieux. Celui-ci s’est déroulé ausein 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 migrationd’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 ChristophePOLLIER, pour m’avoir proposé un sujet aussi interressant et formateur et de m’avoirguidé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èrementceux du services TIC dans lequel j’ai travaillé : Grégory BENOIST, Vincent AUGIER-MICOU, Laurence BOQUET et Laurent POSSETY pour leur accueil sympathique etchaleureux.

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

Virginie QUESNAY - Master OTSI - 25 juin 2004 i

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 Présentation de la C.C.I. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1 Son Histoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Son implantation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Sa mission et ses objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Son organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.1 Les élus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4.2 Les collaborateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5 Le service TIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.5.1 Ses missions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.5.2 Ses acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Sujet et Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1 Présentation du contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Le Système d’Information de la CCI . . . . . . . . . . . . . . . . . 72.1.2 Caractéristiques techniques du Système d’Information . . . . . . 7

2.2 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 La problématique Système d’Information . . . . . . . . . . . . . . . . . . . . 9

II Étude de la problématique de migration de base de données 11

4 Les approches possibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.1 L’approche "systématique" . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2 L’approche "empirique" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.3 Combinaison de l’approche "systématique" et de l’approche "empirique" 15

Virginie QUESNAY - Master OTSI - 25 juin 2004 ii

TABLE DES MATIÈRES

5 Les outils et technologies applicables . . . . . . . . . . . . . . . . . . . . . . . 165.1 Utilisation d’une interlangue . . . . . . . . . . . . . . . . . . . . . . . . . 165.2 Traduction "manuelle" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.3 Traduction automatique "monotraducteur" . . . . . . . . . . . . . . . . . 185.4 Utilisation d’outils de "reverse-engenering" . . . . . . . . . . . . . . . . . 19

6 Les méthodes de gestion de projet informatique . . . . . . . . . . . . . . . . 206.1 Méthode non formelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206.2 XP : eXtreme Programing . . . . . . . . . . . . . . . . . . . . . . . . . . . 206.3 RUP : Rational Unified Process . . . . . . . . . . . . . . . . . . . . . . . . 216.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" . . . . . . . . . . . . . 258.1 Déterminer la nature du problème . . . . . . . . . . . . . . . . . . . . . . 258.2 Vérifier s’il existe des solutions . . . . . . . . . . . . . . . . . . . . . . . . 258.3 Effectuer la Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

8.3.1 Si une solution existante a été trouvée . . . . . . . . . . . . . . . . 268.3.2 Si aucune solution existante ne convient . . . . . . . . . . . . . . . 26

III Application au contexte du stage 27

9 Les choix managériaux et technologiques . . . . . . . . . . . . . . . . . . . . 289.1 La gestion de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289.2 La démarche suivie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289.3 Les technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

9.3.1 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299.3.2 RedHat Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309.3.3 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

10 Le travail réalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3210.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 . . . . . . . . . 3210.1.2 Quelques chiffres . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

10.2 Étude des différentes techniques de migration . . . . . . . . . . . . . . . 3310.3 Écriture d’un traducteur en Perl . . . . . . . . . . . . . . . . . . . . . . . . 33

10.3.1 L’approche utilisée . . . . . . . . . . . . . . . . . . . . . . . . . . . 3310.3.2 Fonctionnement de l’application . . . . . . . . . . . . . . . . . . . 34

10.4 Estimation du travail restant à effectuer . . . . . . . . . . . . . . . . . . . 3410.4.1 Méthode d’estimation . . . . . . . . . . . . . . . . . . . . . . . . . 3510.4.2 Réalisation des mesures . . . . . . . . . . . . . . . . . . . . . . . . 3510.4.3 Résultats de l’estimation . . . . . . . . . . . . . . . . . . . . . . . . 36

11 Bilan du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3811.1 Évaluation du travail réalisé . . . . . . . . . . . . . . . . . . . . . . . . . . 3811.2 Problèmes rencontrés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

11.2.1 Les problèmes techniques . . . . . . . . . . . . . . . . . . . . . . . 38

Virginie QUESNAY - Master OTSI - 25 juin 2004 iii

TABLE DES MATIÈRES

11.2.2 Les problèmes liés à l’organisation . . . . . . . . . . . . . . . . . . 3911.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 à chaque type d’information à 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

Virginie QUESNAY - Master OTSI - 25 juin 2004 iv

Liste des illustrations

1.1 Nouveau bâtiment de la CCI dans le quartier Galbert . . . . . . . . . . . 31.2 Implantations de la C.C.I. en Haute-Savoie . . . . . . . . . . . . . . . . . 41.3 Organisation globale de la CCI . . . . . . . . . . . . . . . . . . . . . . . . 5

4.1 Utilisation d’une méthode systématique pour la traduction de textes . . 124.2 Utilisation d’une méthode empirique pour la traduction de textes . . . . 14

5.1 Méthode de traduction avec une interlangue . . . . . . . . . . . . . . . . 165.2 Méthode de traduction sans interlangue . . . . . . . . . . . . . . . . . . . 175.3 Méthode de traduction automatique . . . . . . . . . . . . . . . . . . . . . 18

7.1 Corrélation entre les approches, les technologies, les méthodes et lataille 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, lesméthodes et la taille de l’équipe . . . . . . . . . . . . . . . . . . . . . . . . 24

A.1 Positionnement des CCI entre privé et public . . . . . . . . . . . . . . . . 43A.2 Une organisation pyramidale mais non hiérarchisée . . . . . . . . . . . . 45

C.1 Répartition des ressources de la CCI (13 328 Me) . . . . . . . . . . . . . . 49C.2 Part de l’IATP dans le budget de la CCI . . . . . . . . . . . . . . . . . . . 50C.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 . . . . . . . . . . . . . . . . . . . . . . . 66K.2 Nombre d’instructions SQL par procédure . . . . . . . . . . . . . . . . . . 67K.3 Nombre de structures if ou while par procédure . . . . . . . . . . . . . . 67K.4 Nombre de curseurs par procédure . . . . . . . . . . . . . . . . . . . . . . 68K.5 Répartition des procédures par type . . . . . . . . . . . . . . . . . . . . . 68

Virginie QUESNAY - Master OTSI - 25 juin 2004 v

Liste des tableaux

10.1 Dénombrement du contenu des bases de données . . . . . . . . . . . . . 3210.2 Catégories de procédures . . . . . . . . . . . . . . . . . . . . . . . . . . . 3610.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

Virginie QUESNAY - Master OTSI - 25 juin 2004 vi

Liste des codes sources

H.1 Options de sybase2postgresql affichées grâce à l’option -h . . . . . . . . 56H.2 Exemple de fichier de configuration de sybase2postgresql . . . . . . . . . 57J.1 Création des fonctions suser_id() et suser_id(username) . . . . . . . . . . 62J.2 Création d’une fonction de conversion de type (varchar vers int) . . . . . 63J.3 Création d’une fonction de conversion de type (smallint vers bit) . . . . 63L.1 Fichier de configuration du module MCPAN . . . . . . . . . . . . . . . . 69

Virginie QUESNAY - Master OTSI - 25 juin 2004 vii

Introduction

Afin de valider l’année de master de la formation OTSI de l’IUP GSI, chaque étudiantdoit effectuer un stage de quatre mois en entreprise.Ce stage est une étape importante pour un étudiant, non seulement du point de vuede la scolarité, mais aussi d’un point de vue personnel. La vie en entreprise est en effetné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 ausiè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’ap-prentissage "fondamental" (on pourrait dire "théorique") et une activité d’apprentis-sage "professionnel".

L’objectif de notre recherche est d’arriver à une réflexion théorique sur la migrationde bases de données en se basant sur une expérience concrète qu’est la migration debases sous Sybase vers PostgreSQL.Cette réflexion a pour but de faire ressortir les approches et solutions possibles pourla 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 pro-blématique posée.Ensuite, nous examinerons cette problématique et tenterons de lui apporter des solu-tions.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 LATEX 2ε, a été compilé le 25 juin 2004.

Virginie QUESNAY - Master OTSI - 25 juin 2004 1

Première 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 duPrésident Félix Faure institue une Chambre de Commerce à Annecy. Elle rejoint ainsila vingtaine de Chambre de Commerces réparties sur l’ensemble du territoire (voirAnnexe A, page 42).À l’origine, la Chambre naissante est hébergée au rez-de-chaussée de la mairie d’An-necy puis dans l’ancien évêché. En 1932, elle emménage dans des nouveaux locauxqu’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 denouveaux locaux (voir Annexe B, page 47), construits eux aussi à l’emplacement d’uneancienne 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 pôles économiques distincts, dotés chacun d’une spécifi-cité 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 à Annecy et de trois antennes permanentesà 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 pres-tataires de services du département. Sa mission est d’optimiser les performances desentreprises haut-savoyardes à travers une stratégie fondée sur la dynamique commer-ciale des entreprises et des territoires. Plusieurs actions phares concrétisent cet objec-tif :– 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éro-

port d’Annecy Haute-Savoie, Gares routières d’Annecy, Annemasse et Cluses, CentreRégional de Douanes et de Transports d’Epagny)

Pour l’année 2004, la CCI a établi différents objectifs qui lui permettront de poursuivrela mise en œuvre de son Projet d’Entreprise :– Offrir à ses clients (les entreprises) des prestations déclinées dans un catalogue pro-

duits,– Développer des projets avec ses partenaires1 par un renforcement de la démarche

partenariale,– Organiser des évènements destinés aux entrepreneurs et aux entreprises.

1Collectivités territoriales et entreprises participant à la création, la pérennisation, l’animation et latransmission des entreprises.



La création d’un catalogue produits a également pour but de rendre la CCI beaucoupplus 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 endifférents collèges :– 34 membres titulaires :

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

– 33 membres associés :Au côté des 34 membres titulaires, ils sont désignés après chaque élection et ilsparticipent 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 étagedu 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 do-maine de l’informatique et des nouvelles technologies de l’information et de la com-munication.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 ser-

vices.– La proposition de solutions adaptées (techniques, logiciels, formations) en conser-

vant 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 Présentation 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 "im-posé" (Xerox Docushare, Microsoft Exchange, . . .).

D’autres applications sont quant à elles développées au sein de la CCI et continuentdonc d’évoluer parallèlement aux besoins.L’application la plus importante est BEE (Base Économique Événementielle), une ap-plication métier développée sous 4D1 associée à une base de données Sybase. C’estun outil de CRM qui constitue le cœur 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 : contactavec un ressortissant, courrier postal et électronique, contact téléphonique ou email . . .

2.1.2 Caractéristiques techniques du Système d’Information

Le serveur Sybase contient plusieurs bases de données utilisées par les différentesapplications 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 for-

malité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éesest maintenant nationale.

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

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

14D (4ème Dimension) est un atelier logiciel de développement et de déploiement d’applicationsmultipostes crossplate-forme.

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


Sujet et Objectifs

et 1 serveur avec une réplication3 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 in-diqué (voir § 2.1.2, page 7), sur différentes bases de données fonctionnant sur un ser-veur 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 Sybaseou vers un autre moteur de base de données.Les collaborateurs de la CCI utilisent déjà avec succès différents logiciels libres. Il adonc été décidé d’évaluer l’opportunité d’effectuer cette migration vers une base dedonnées libre. Cependant, les applications reposant sur cette base de données étantcritiques pour le fonctionnement de la CCI, une migration de cette ampleur ne peut sedécider à la légère.Suite à ces différentes réflexions, il a été décidé d’effectuer une étude poussée afin dedé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.

3Le serveur de réplication est un serveur accessible depuis les applications clientes et dont le but estd’éviter les surcharges du serveur principal (pour ne pas trop ralentir le serveur principal avec de grossesrequêtes ne nécessitant pas des données ayant moins de 24 heures, celles-ci sont réalisées sur le serveurde réplication).


Chapitre 3

La problématique Systèmed’Information

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

Ce rapprochement, même s’il peut paraître incongru à première vue, est finalementassez 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 leslangages naturels et les langages informatiques. On peut en effet y trouver des problé-matiques liées au lexique (vocabulaire), à la syntaxe et à la sémantique.Ce rapprochement est d’autant plus évident lorsqu’on se base sur les travaux de re-cherche faits sur les compilateurs informatiques [12] qui utilisent de façon importanteles 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 estmoindre que celle liée à l’étude des langages naturels car certains aspects de la linguis-tique comme l’étude du langage parlé (phonétique, phonologie) ne sont pas présentset 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 pro-blèmes de pragmatique (variation du sens en fonction du contexte), voire même setrouver confronté à des situations où le contexte n’est pas exprimé explicitement (ildépend de l’état du système ou d’autres données accédées directement en interne parle 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 deleur création, ont évolué en gardant trace de leur histoire (on peut par exemple utiliserplusieurs syntaxes ou un vocabulaire totalement différent pour effectuer une mêmeaction).

Enfin, même si, comme nous l’avons dit, la problématique de la traduction dans lecadre 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 encours. La traduction automatique est un problème qui a longtemps été sous-estimé


La problématique Système d’Information

mais qui est en fait l’un des plus délicats à effectuer pour un ordinateur. Aux phaseslexicales et syntaxiques, à peu près maîtrisées, s’ajoutent une analyse sémantique, puispragmatique, qui tentent de déterminer le sens particulier d’un mot, dans le contexteoù 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 lin-guistique informatique pour mener à bien un travail de traduction afin de déterminerquelles solutions peuvent être envisagées lorsqu’on se trouve confronté à un problèmede migration de bases de données.


Deuxième partie

Étude de la problématique demigration 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 sem-blable à la traduction d’un langage (naturel ou artificiel) vers un autre, il est possibled’utiliser une démarche proche de celles employées en ingénierie linguistique.

FIG. 4.1 – Utilisation 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 desexemples de cas complexes.Lorsque le corpus est assez complet, il est alors possible d’en extraire le lexique, lasyntaxe et la sémantique du langage.Dans notre cas, nous cherchons à réaliser une traduction d’un langage vers un autre, ilfaut donc effectuer ces opérations pour les deux langages afin de pouvoir les compareret déterminer quels sont les éléments qui les différencient et obtenir des règles detraduction.Enfin, il est possible d’appliquer ces règles à un document écrit dans un des langagespour obtenir sa traduction dans l’autre.Lorsqu’on applique une approche systématique au traitement informatique d’une mi-gration, on pourra assimiler cette démarche à une approche descendante (égalementappelée approche ’top-down’).

Cette approche est à privilégier lorsqu’on se trouve confronté à la traduction d’ungrand 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é derassembler un corpus de documents suffisamment vaste pour couvrir tous les aspectsd’un langage, mais aussi par la complexité d’extraction du lexique et de la grammairede 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 docu-ment sans rencontrer de problèmes. Grâce à cela, il est également possible d’obtenirassez facilement un traducteur pour un langage "proche" (pour les langages informa-tiques comme pour les langages naturels, il existe des "familles de langues"1 qui ontles 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éaliserun traducteur complet et flexible.

4.2 L’approche "empirique"

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

Cette démarche passe tout d’abord par la traduction "manuelle" de parties du docu-ment pour déterminer les règles de traduction.On traduit ainsi des parties dont le lexique, la sémantique et la syntaxe sont différentsjusqu’à 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’enobtenir une traduction complète.

1Pour les langages naturels, on peut par exemple citer le français, l’espagnol et l’italien qui sont deslangues latines. Pour l’informatique, on peut citer le C++ et la java qui ont des origines dans le C ouSybase 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 untraducteur par agrégation de ces problèmes.

Si on possède suffisamment de documents différents et qu’ils couvrent tous les casexistants, on peut, par empirisme, obtenir un traducteur aussi complet que celui qu’onobtiendrait par une approche systématique mais cela nécessiterait une quantité detravail bien supérieure.De plus, la complexité non linéaire de cette approche est un problème car chaque "casparticulier" résolu risque de rentrer en conflit avec les cas résolus précédemment cequi implique que plus le nombre de règles de traduction augmente, plus le nombre decontradictions 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 faiblenombre de documents (ou si ces documents utilisent exactement les mêmes règles detraduction).Cependant, cette démarche est limitée par le fait que l’écriture des règles passe parune phase de traduction manuelle. Si on doit traduire des documents très différentsou si les schémas linguistiques ne se trouvent pas assez souvent répétés, l’ensembledu travail de traduction sera finalement réalisé manuellement. Par exemple, si on setrouve dans le cas d’un document trop court, chaque élément traduit manuellementcré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 pro-blè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 apporteune bien plus grande fiabilité (il y a de grandes chances qu’aucun cas "spécifique" etqu’aucune exception ne soit oubliés), apporte également une bien plus grande com-plexité et un temps de mise en œuvre beaucoup plus grand car il faut effectuer chacunedes deux méthodes puis mettre en relation les résultats obtenus pour obtenir un seulensemble 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é del’analyse lexicale dépend directement dont les différentes parties de l’analyseur fonc-tionnent en corrélation et non en opposition.


Chapitre 5

Les outils et technologiesapplicables

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 œuvre nécessitedes 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 dela traduction automatique. Une interlangue est une langue artificielle qui sert d’inter-médaire entre une langue source et une langue cible.

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


Les outils et technologies applicables

Les interlangues sont généralement utilisées lorsqu’on doit effectuer des traductionsentre plusieurs langages.

Un grand nombre de travaux de recherche en linguistique se sont penchés sur les in-terlangues. On peut notamment parler du projet Traduction de Langues Distribuée (enanglais : Distributed Language Translation, en espéranto Distribuita Lingvo-Tradukado,en abrégé DLT) qui était un projet de traduction de langues de la Commission euro-péenne1. Le projet avait pour but la traduction automatique depuis et vers 12 langueseuropéennes par le biais d’une interlangue interne basée sur l’Espéranto, qu’on nom-mait 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ésconnecteurs, pour faire communiquer des systèmes hétérogènes entre eux.

Les interlangues sont habituellement utilisées avec une approche de type systéma-tique car elles sont destinées à obtenir des traducteurs généralistes et assez exhaustifsentre plusieurs langages. Elles n’ont d’ailleurs d’intérêt que si on est en présence deplus de trois langages.

FIG. 5.2 – Méthode de traduction sans interlangue

1Dans la sphère de la traduction technique (ex : entre le français et l’anglais, avec une traduction in-termédiaire en ILO -Internacia LingvO = Langue Internationale- et retour) on atteignait 95% de précisionsur les phrases traduites. Dans la sphère de textes très généraux (ex : comptes-rendus d’assemblées del’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 parune interlangue nécessite plus de travail (deux traducteurs au lieu d’un), mais, si ondépasse trois langages, on peut voir que l’utilisation d’une interlangue (voir Figure5.1, page 16) permet de ne créer qu’un seul connecteur lors de l’ajout d’un quatrièmelangage alors qu’il faut trois connecteurs lorsqu’on n’utilise pas d’interlangue (voirFigure 5.2, page 17).

Cette solution, est donc très coûteuse pour un petit nombre de langages alors qu’elleest 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 estassez 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écanismed’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 habituel-lement une approche de type empirique car, lorsqu’ils rencontrent un problème etqu’ils le résolvent une première fois, ils sauront comment le résoudre s’ils s’y trouventconfrontés une seconde fois.

5.3 Traduction automatique "monotraducteur"

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

La traduction est réalisée par un logiciel chargé d’appliquer les règles de traductionde façon systématique.Mais, avant d’utiliser un logiciel de traduction automatique, il faut avoir préalable-ment 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 fonc-tionnement est proche de celui de l’interlangue. Toutefois, le langage utilisé 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, cesont des solutions de type "clefs en main". Cependant, comme l’import ou l’exportdepuis ou vers un SGBD se fait par un traducteur spécifique, il faut que les connec-teurs existent (malheureusement si on utilise un ou des systèmes peu courants, il estassez difficile de trouver un atelier de reverse-engenering proposant les traducteursnécessaires).


Chapitre 6

Les méthodes de gestion de projetinformatique

Comme tout autre projet informatique, et même généralement comme tout projet, lamigration de bases de données doit être programmée, suivie, piloté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 duprojet 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 nepose pas de problème et l’ordonnancement des tâches est très simple (on ne peut fairequ’une seule chose à la fois).

De plus, des comptes-rendus réguliers au client lors de réunions d’avancement et à lahiérarchie lors de réunions de service ou de façon informelle, permettent de piloter defaç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 œuvredestinée à des équipes de petite taille composées de membres autonomes, c’est unemé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 contenude ces livraisons est décidé par le client lui-même, à partir des estimations fourniespar les développeurs.

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


Les méthodes de gestion de projet informatique

– Suivi du projet : L’avancement du projet est mesuré de manière concrète par unebatterie 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 pourtirer parti de l’expérience acquise au cours du projet.

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

– Travail en équipe : L’équipe travaille réellement en équipe. Le code est partagé partous, les développeurs travaillent systématiquement en binômes, et l’intégration estquasiment continue."

6.3 RUP : Rational Unified Process

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

C’est est un processus de développement logiciel itératif et incrémental, centré surl’architecture, conduit par les cas d’utilisation et piloté par les risques. Il est destinéaux projets nécessitant un grand nombre de ressources humaines. Il n’est d’ailleursutilisable que si une personne est affectée à temps complet (ou presque) à la gestionde 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êmetype 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 chaqueité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 ca-nevas pour des projets types.

– Centré sur l’architecture : tout système complexe doit être décomposé en partiesmodulaires afin de garantir une maintenance et une évolution facilitées. Cette ar-chitecture (fonctionnelle, logique, matérielle, etc.) doit être modélisée en UML etpas seulement documentée en texte.

– Piloté par les risques : les risques majeurs du projet doivent être identifiés au plustôt mais surtout levés le plus rapidement possible. Les mesures à prendre dans cecadre déterminent l’ordre des itérations.

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


Les méthodes de gestion de projet informatique

6.4 DSDN (RAD)

L’organisation d’un projet par une méthode de type RAD s’appuie sur un principefondamental : la séparation des rôles et des responsabilités entre maîtrise d’ouvrage(MOA) et maîtrise d’œuvre (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 pilote.

La méthode DSDM propose une approche globale du développement de logiciel dansun environnement de développement rapide (RAD). DSDM fournit un canevas cou-vrant l’ensemble du cycle de développement et un grand nombre de principes à suivreafin d’assurer le succès du projet.


Chapitre 7

Combinaison des approches, destechnologies et des méthodes

FIG. 7.1 – Corrélation entre les approches, les technologies, les méthodes et la taille del’équipe

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.


Combinaison des approches, des technologies et des méthodes

FIG. 7.2 – Exemple de mauvaise corrélation entre les approches, les technologies, lesmé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 degrande 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 ap-proche 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 feradonc 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 in-formatique, il n’existe bien évidemment pas de "solution miracle" pour réussir à coupsûr mais il est possible de suivre une démarche et des bonnes pratiques (appelée aussibest 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, ilest nécessaire de déterminer si le projet de migration est réaliste et réalisable afin dene pas effectuer d’investissements inutiles.

8.1 Déterminer 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, traite-ments 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 oudeux versions d’une même base de données), une migration nécessitera beaucoupmoins de travail que pour des bases de données d’origine totalement différente.

8.2 Vérifier 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 évidem-ment déterminer si les technologies utilisées sont applicables mais aussi si leur coûtest 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


Proposition d’une démarche et de "bonnes pratiques"

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

8.3 Effectuer la Migration

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

Si une solution existante est utilisable (l’outil a été conçu pour les systèmes que l’onutilise) et que son prix est acceptable, la solution doit être utilisée en n’oubliant pas decontinuer à piloter 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 devérifier que tout s’est bien passé et affiner le paramètrage de la base de données afind’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 pour-suivre 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 quel’on souhaite obtenir).


Troisième partie

Application au contexte du stage


Chapitre 9

Les choix managériaux ettechnologiques

9.1 La gestion de projet

Ce stage était un projet informatique "comme un autre". On peut donc supposer quel’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 à ce cas pourdiffé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’indicationssur 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érercomplexe et nécessiter plus de temps quelle n’en fait gagner.Nous avons donc adopté une gestion de projet minimale, essentiellement basée surles comptes-rendus hebdomadaires lors des réunions de service.

– Enfin, comme l’approche employée est de type empirique, son évolution est paressence difficile à prévoir (car on traite les problèmes au fur et à mesure de leurdécouverte). Une prévision trop précise et un planning décidé trop tôt seraient remisen cause à 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 leschapitres 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 œuvre de la solution (voir Section 10.3, page 33) ;– Évaluation du travail à venir (voir Section 10.4, page 34).


Les choix managériaux et technologiques

9.3 Les technologies utilisées

9.3.1 PostgreSQL

Présentation

PostgreSQL1 est un Système de Gestion de Base de Données Relationnelle (SGBDR)open source2.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ésRational 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 à Ber-keley sous le nom de Postgres (1986-1994). Après l’apparition des premières normesdu 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’Univer-sité de Berkeley et renommé Postgres95. Là, le projet s’est étoffé et transformé à partirde 1997 en PostgreSQL lorsque l’ensemble des fonctionnalités SQL a été intégré auserveur.

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 illimité ;– La communauté de développement active et réactive ;– Les possibilité d’extension à volonté (le code source étant disponible gratuitement,

il est possible de modifier ou d’étendre les fonctionnalités de PostgreSQL de façonautonome).

– . . .PostgreSQL respecte la quasi totalité de la norme SQL et propose la plupart des fonc-tionnalité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 pleinemutation due à son rapprochement de MySQL) PostgreSQL est certainement actuel-lement le seul SGBD permettant de gérer des bases de données à gros volume et avecun 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 encharge que pour le nombre de fonctionnalités disponibles, c’est pourquoi le choix enterme de bases de données assez limité.

Inconvénients

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

1Version utilisée : 7.3.4-RH2Sous licence BSD (voir Annexe E, page 52)



PostgreSQL, s’il est connu pour sa robustesse, a également la réputation d’être rela-tivement lent (même si chaque nouvelle version amène des progrès notables). Celaest dû au grand nombre de mécanismes de préservation et de protection des donnéesqui 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 Database3 est une version de PostgreSQL 7.3.4. optimisée pour fonctionneravec un serveur Red Hat Linux4 et qui bénéficie du back-portage des améliorationsapparues avec la version 7.4.

Avantages

Rhdb5 est librement téléchargeable sur le serveur ftp de RedHat. Il est également pos-sible d’acquérir un contrat de service (3267e) 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 HatEnterprise Linux ES". En cas de problèmes non spécifiques à la base de données, il estdonc 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 ser-vices est proposée mais le site de vente de RedHat reste peu clair sur ses avantages : lecontenu de l’offre n’est pas très détaillé et la version actuellement proposée est la 2.16

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 unlangage de programmation interprété (avec une phase interne de pré-compilation). Sasyntaxe dérive des scripts shell, et d’autres langages comme C, awk, sed.

3Aussi appelé : PostgreSQL - Red Hat Edition ou RhDb4version 9 ou Fedora Core 15Version utilisée : 3.0 (sortie le 16 janvier 2004)6optimisé Red Hat Linux 7.1 et PostgreSQL 7.1.2



Avantages

Pour tous ceux qui connaissent ces langages, notamment pour ceux qui viennent dumonde 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 wayto do it".La puissance de Perl pour la manipulation de chaînes de caractères et de fichiers luidonne des atouts considérables pour écrire des applications nécessitant des expres-sions 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 degestion de mémoire, pas de limite de buffer.Perl existe depuis plus de 15 ans, beaucoup de bibliothèques et de modules d’exten-sions sont donc déjà disponibles.L’application première de Perl est l’administration Unix (manipulation de textes, defichiers et de processus), une personne ayant ce type de compétences aura donc cer-tainement des connaissances du langage Perl et pourra ainsi reprendre, maintenir etmodifier 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 pourchaque variable si elle est sécurisée ou non. Comme ce mode ralentit l’application, ilest 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 leursméthodes. Cependant, la diversité des méthodes de codage qui est un gros avantagepour la simplicité d’apprentissage du Perl est aussi un des principaux inconvénientsdu langage : il est souvent difficile de reprendre le code d’un autre développeur, sur-tout s’il n’est pas correctement documenté.


Chapitre 10

Le travail réalisé

10.1 Évaluation 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 familiariseravec 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éesur les données, sur les structures ou sur les traitements) et quel type d’outil utiliser.

cci cfe consulaire personnel TOTALGroups 1 1 1 1 4Indexes 528 354 232 23 1137Segments 5 3 5 3 16Tables 284 141 118 51 594Triggers 280 0 0 0 280User messages 19 0 19 49 87Users 254 34 243 0 531Views 130 58 83 1 272Procedures 2431 1134 794 0 4359Nb de lignes de code1 104296 34798 37396 0 176490

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 enregistre-ments 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 laplus importante au niveau utilisation est également celle contenant le plus d’élémentsà migrer.

1nombre 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 à nepas 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épertorieune large gamme de moyens pour migrer vers ce système.On peut trouver dans cette catégorie nommée "Converting from other Databases toPostgreSQL", 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 utiliser les conseils donnés pour MS-SQL maisceux-ci sont très pauvres et ne donnent que quelques idées pour réaliser une migrationmanuelle.

La seconde possibilité pour trouver des outils de migration était de rechercher desoutils 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 dedonné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éa-liser 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écou-per en plusieurs phases.

Les choix

Nous avons tout d’abord du déterminer l’approche, la technologie, la méthodologieet 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’au-

cun outil ne permettait de réaliser une telle migration (voir § 10.2, page 33) et quetrè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 quelquesmodifications 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 techniqued’un traducteur automatique a donc été retenue.



– Enfin, ayant très peu de ressources à gérer et beaucoup d’autonomie quant au fonc-tionnement du traducteur, une méthodologie de gestion de projet "lourde" n’auraitapporté aucun bénéfice par rapport à l’utilisation d’une méthode non formelle.

L’organisation

Le choix d’une approche de type empirique ne dispense pas de structurer la démarchedu 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 ordrede traitement. Il faut réaliser tout d’abord la transformation de la structure puis desdonnées et enfin des traitements.

Les itérations

Pour chacun des types d’élément, une approche empirique peut se traduire par unesuite 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’unprogramme 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 don-nées qui soit facilement réutilisable. Il fallait donc que son uilisation soit simple et queson fonctionnement soit aisément compréhensible et modifiable par une autre équipe.

Le traducteur appelé sybase2postrgesql propose donc plusieurs modes de fonctionne-ment (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 com-menté afin de rendre leur réutilisation plus simple.

10.4 Estimation du travail restant à effectuer

La migration qui semblait relativement simple à ses débuts s’est révélée beaucoupplus complexe que prévue et la charge de travail sous-estimée. En cours de projet, lesdélais ont donc du être réévalués et il s’est avéré que la migration des procédures nepouvait ê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 ensemblede 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 difficiled’avoir, avant d’avoir effectuer le traducteur, des indicateurs fiables concernant lespoints bloquants de la migration. Cependant, certains problèmes sont proches de ceuxrencontrés lors de la migration de la structure de la base (et tout particulièrement desvues) 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 mi-gration 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 deréaliser des tests que pour des langages courants (C, java, . . .). Il était donc très impro-bable de trouver un outil répondant à nos attentes (fonctionnant pour du Transac SQLet 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éa-lisation et l’analyse. Et même si la méthode est généralement présentée sous formed’étapes, en réalité, celles-ci ne sont pas forcément effectuées séquentiellement et il ya 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 mo-

dè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 com-

plè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 étapea é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 quicorrespondent à ces indicateurs.

En observant les résultats, il a été possible d’ajouter quelques indicateurs pour affinerles 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 les-quelles se trouvent les procédures.

Moins de 10 lignes simple Une seule instruction SQL, pas de curseur, pasde condition, pas de boucle, pas d’instruction"exec"OU que des instructions "exec" (et rien d’autre)

moyenne Un seul type d’instruction (par exemple quedes updates), pas de curseur, pas de condition,pas de boucle, pas d’instruction "exec"

complexe Celles qui n’entrent pas dans les catégories pré-cédentes

Entre 10 et 40 lignes Mêmes catégories que moins de 10 lignesEntre 40 et 150 lignes simples Pas de condition, pas de boucle et pas de cur-

seurcomplexe Celles qui n’entrent pas dans la catégorie pré-

cédentePlus de 150 lignes Transformation manuelle (estimation du temps en fonction

du nombre de lignes : 150 lignes par jour/homme)

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 pro-cé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 pro-cédures (environ 150 000 hors commentaires).

Une évaluation approximative permet d’atteindre un volume de travail d’environ1000 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 au-tomatique 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 endifférents niveaux de complexité et de calculer le nombre de jours de développementnécessaires pour terminer l’application.

Nombre de jours parNb. de % du niveau de complexité Nb. total % duprocs. volume Simple Moyen Complexe de jours temps total

Moins de10 lignes

1379 31,61 10 12 15 37 8,54

De 10 à 40lignes

2103 48,2 12 15 20 47 10,85

De 40 à 150lignes

709 16,25 15 25 40 9,23

Plus de 150lignes

172 3,94 Nb. total de lignes : 46376 309,17 71,37

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 dedéveloppement), il faut s’assurer de la pertinence et de l’utilité de chacune d’elle afinde ne pas perdre de temps inutilement.


Chapitre 11

Bilan du stage

11.1 Évaluation 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 onpouvait s’attendre : la migration paraissait simple mais elle s’est avérée beaucoup pluscomplexe 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 fonctionsinternes conçues afin de faciliter le travail des développeurs. Néanmoins, leur nom etparfois 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 fonctionsnecessite une intervention pour déterminer la solution à adopter.

Lorsque des fonctions de Sybase n’existent pas sous PostgreSQL, la solution la plussimple serait de créer des fonctions en pl/sql portant le même nom que la fonctionSybase et donnant le même résultat.Mais cela crée une surcouche et a un impact néfaste sur les performances (une fonc-tion externe utilisant une ou plusieurs fonctions internes sera toujours moins rapidequ’une seule fonction interne).

Lors de l’écriture du programme de migration, nous avons donc utilisé autant quepossible, des fonctions internes de PostgreSQL, même si cela nécessitait parfois deremanier les scripts SQL.Cependant, dans quelques rares cas, aucune fonction existante ne pouvant être utili-sée, il a fallu en créer des nouvelles (par exemple voir Source J.1, page 62).


Bilan du stage

Les différences d’encodage

Le passage successif par différents systèmes met en lumière les différences de normesd’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’affi-chage, voire même de modifier l’encodage d’un fichier dans un éditeur de texte (voirAnnexe M, page 71) sous peine d’obtenir des retours à la ligne fantaisistes et de perdretous 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 lamê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’utilisation d’une table ou d’uneprocé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 per-sonnes avec des connaissances et des techniques de programmation différentes ontdonc participé à sa gestion et à l’écriture de nouvelles fonctions. De plus, les technolo-gies ont évolué : augmentation des capacités du moteur de base de données, évolutionde la syntaxe utilisée pour la création de vues et des procédures. Lors de l’écriture desscripts Perl, il a donc fallu tenir compte des différents types d’écriture afin que toutesles possibilités soient traitées.

11.2.2 Les problèmes liés à l’organisation

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

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

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

Les informations concernant les migrations de base de données (et tout particulière-ment 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 doubleexpérience (immersion dans le monde du travail et acquisition de nouvelles connais-sances sur les activités en entreprise) et pouvoir apporter à l’entreprise un bénéficeaussi bien sous forme de nouvelles compétences liées à sa formation qu’à sa person-nalité.

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

Le projet a mis en évidence que la méthodologie à mettre en œuvre pour la migrationde bases de données varie beaucoup selon les systèmes en jeu. Elle varie égalementbeaucoup en fonction du "type" de migration désirée : migration "unitaire" ou migra-tion "reproductible".Les possibilités d’une migration de Sybase vers PostgreSQL était très mal connues etce stage permet de se rendre compte qu’elle n’est pas simple à pratiquer et permet demieux les connaître et les maitriser.

J’espère donc que l’ensemble formé par ce rapport et le programme de migration sy-base2postgresql pourra constituer une première étape vers une migration définitiveen 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 à chaque type d’information à 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 ville décide de choi-sir, 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 of-ficialise l’institution et en profite pour demander aux députés "des recommandationspour relever l’économie du royaume". La fonction traditionnelle de consultation faitsa première apparition.Le nombre de Chambres de Commerce s’accroît. Louis XIV crée un conseil du Com-merce : le Roi veut recevoir des propositions pour "augmenter le commerce en Franceet 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. Vingtdeux nouvelles chambres sont créées en France et dans l’Empire. Elles s’implantentpartout où l’économie locale a besoin de leur structure et de leurs services. Elles vontse développer pendant tout le XIXè siècle. Le réseau se met en place. En 1898, la loivient formaliser leur rôle et crée un statut original, celui d’Etablissement Public re-présentant les intérêts généraux du commerce et de l’industrie auprès des pouvoirspublics. Le cadre juridique est fixé.Durant le XXè siècle le visage contemporain des Chambres de Commerce se dessinedé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 deCommerce 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 Commerceet d’Industrie (APCCI) couronne le réseau en fournissant aux instances nationales uninterlocuteur privilégié. Depuis 1990, I’APCCI s’est transformée en Assemblée desChambres 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 etprofessionnels 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, res-

sortissants de la CCI.Il convient de ne pas les confondre avec les administrations d’État (les CCI ne sontsoumises à aucune autorité dans le cadre de leur mission bien qu’ayant une tutelle mi-


Les CCI en France

nistérielle pour leur budget), ni avec les syndicats professionnels et les associations decommerçants de statut privé. Les CCI sont des organismes interprofessionnels dansla mesure où elles regroupent systématiquement toutes les entreprises inscrites auRegistre du Commerce industriels, commerçants, hôteliers, restaurateurs, transpor-teurs...

FIG. A.1 – Positionnement des CCI entre privé et public

A.3 Les missions

Les missions des CCI s’organisent autour de 3 principaux axes :– Elles représentent toutes les entreprises imatriculées au RCS (Registre du Commerce

et de Sociétés)– elles veillent à la prise en compte de leurs intérêts,– elles facilitent les rapports avec les administrations,– elles participent à la définition des politiques de transport, d’équipement et d’amé-

nagement.– Elles accompagnent les entreprises dans leur phase de développement en accompa-

gnant, informant et conseillant les créateurs et repreneurs d’entreprise ;– Elles conçoivent, réalisent et gérent des équipements collectifs comme les aéroports,

ports et gares routières.

A.4 Les moyens

Tous les ans, l’Assemblée Générale de chaque CCI vote son budget qui, pour un exer-cice, fixe le cadre d’action de la Chambre en faveur de ses entreprises et de leur en-vironnement. Approuvé par les Ministères de l’Industrie et du Commerce, le budgetfait l’objet d’un contrôle à posteriori des Pouvoirs Publics qui s’assurent ainsi de larégularité des opérations et de leur conformité avec les décisions de l’Assemblée. LesChambres jouissent ainsi d’une large autonomie pour organiser leurs missions.

Ces missions peuvent être financées par :– Des ressources propres : il s’agit des recettes provenant des prestations qu’elles ef-

fectuent directement ou indirectement en faveur de leurs ressortissants (droits descolarité, de ports, d’aéroports, frais d’études et de conseil...).


Les CCI en France

– Des emprunts : les Chambres sont autorisées à recourir à l’emprunt pour financerles équipements collectifs d’intérêt général qu’elles gèrent.

– Des contributions publiques : dans le cadre d’actions de partenariat avec les Pou-voirs Publics, les collectivités locales ou régionales, les Chambres reçoivent desconcours financiers pour accompagner des initiatives spécifiques, réaliser des étudesde projets ou encourager des actions pilotes. . .

– Des ressources fiscales : la loi a donné aux Chambres le droit de voter l’impôt quicomplète le financement de leurs actions. Cet impôt collecté simultanément avecla Taxe Professionnelle (ce qui lui a donné son nom d’Imposition Additionnelle àla Taxe Professionnelle "IATP") n’assure que 27% de leurs ressources et représentemoins de 4% de la Taxe Professionnelle elle-même.

L’I.A.T.P. est votée par les chefs d’entreprise qui siègent à la CCI.

A.5 L’organisation

L’organisation des Chambres de Commerce et d’Industrie découle de leurs principalesmissions :– une mission d’animation et de développement de leurs espaces économiques lo-

caux, ce qui implique une structure très décentralisée ;– une mission de représentation et de consultation auprès des pouvoirs publics, ce

qui nécessite d’être leur interlocuteur à tous les niveaux (local, régional, national).Il en résulte une structure à trois niveaux :– 160 Chambres de Commerce et d’Industrie locales (les CCI).

Chacune est dotée d’un ensemble de services : information, études et conseil, for-mation. Les CCI sont la maison des entreprises. Elles s’appliquent à leur fournir lesconditions optimales de leur développement. C’est dans le cadre de cette missiondu service public qu’elles sont traditionnellement amenées à créer et à exploiter deséquipements collectifs d’intérêt général.

– 20 Chambres Régionales de Commerce et d’Industrie (les CRCI).Elles représentent au niveau de la Région les CCI de leur circonscription. Elles sontles interlocutrices et les partenaires naturels des pouvoirs publics et des collectivitéslocales ainsi que de tous les acteurs économiques qu’elles contribuent à éclairer surles choix des priorités et des investissements de leur Région.Elles sont aussi un lieu de concertation et de coordination des Chambres localesavec lesquelles elles peuvent mener des actions communes spécifiques.

– L’ Assemblée des Chambres Françaises de Commerce et d’Industrie (l’ACFCI).C’est l’établissement national fédérateur et animateur des Chambres de Commerceet d’Industrie.


Les CCI en France

AFCCI

160 CCI

local

20 CRCCI

regional

national, europeen

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

Cette activité est prolongée au niveau international par 85 Chambres de Commerceet d’Industrie Françaises à l’Étranger (CCIFE) dont la mission est de développer deséchanges France-Etranger.

A.6 les chiffres

Le réseau des CCI comporte 4500 membres titulaires élus au suffrage universel desentreprises et 26 000 collaborateurs répartis sur l’ensemble du territoire, reliés parIntranet. Le budget global des CCI représente 3.4 milliards d’Euros, dont près de 1milliard provenant de l’IATP (soit 0,15% des prélèvements obligatoires).

A.6.1 Les moyens humains

– 4 500 chefs d’entreprise élus (membres des CCI) et 26 000 salariés– 1 800 000 entreprises bénéficiaires et électrices.

A.6.2 Les moyens financiers

– Le budget global des Chambres représente 3,39 milliards d’euros(dont 0,97 milliardd’euros d’IATP).

A.6.3 Création d’entreprises

– 780 000 formalités liées à la création, reprise ou transmission d’entreprise ont étéeffectuées dans les centres de formalités d’entreprises (CFE) des CCI ;

– 150 000 porteurs de projets accueillis et conseillés.

A.6.4 La formation (2ème acteur après l’Education nationale)

– 540 établissements de formation– 500 000 personnes formées chaque année– 80 000 contrats d’apprentissage signés par an


Les CCI en France

A.6.5 La gestion des équipements

– 121 aéroports ;– 180 ports (commerce, pêche, plaisance, . . .), les criées...– 36 plates-formes multimodales– 18 complexes routiers– 28 entrepôts ou parcs à vocation logistique– 55 palais des congrès et parcs d’expositions– 2 ponts (Normandie, Tancarville)


Annexe B

La CCI de la Haute-Savoie

B.1 Coordonnées

Chambre de Commerce et d’Industrie de Haute-Savoie5 rue du 27ème BCABP 207274011 ANNECY CedexTél. : 04 50 33 72 00Fax. : 04 50 52 89 95

B.2 Heures d’ouverture CCI

Du lundi au jeudi de 8h00 à 12h00 et de 13h00 à 17h00Le vendredi de 8h00 à 12h00

B.2.1 C.F.E. (Centre de Formalités des Entreprises)

Du lundi au jeudi de 9h00 à 12h00 et de 13h30 à 16h30Le vendredi uniquement sur rendez-vous de 9h00 à 12h00

B.2.2 Espace Entreprises

Du lundi au jeudi de 8h30 à 12h00 et de 13h30 à 17h00Le vendredi de 8h30 à 12h00

B.3 Plan d’acces


CHAMBRE DE COMMERCE ET D'INDUSTRIEDE LA HAUTE-SAVOIE

AVEN

UE

DE

GEN

EVE

Rue du 27 ème BCA

BOULEVARD DE LA ROCADEBOULEVARD DE LA ROCADE

BD. DU LYCÉE

BD. DECOUZ

AV. DE CRAN

PLACEDES

ROMAINS

R. de l'Intendance

Rue E. Romanet

Rue des chasseurs

Av. d

es R

omain

s

Rue d

es al

pins

Av. des Romains

AVEN

UE

DE

BR

OG

NYChe

mins

des

Fins

sud

A41 SORTIE

ANNECY-NORD

A41 SORTIE

ANNECY-SUD

GARESNCF

Av

enue

Jose

ph D

essa

ix

URSS

AF

CCI5, rue du 27ème BCAAnnecy

Chambre de Commerce et d’Industrie de la Haute-Savoie5, rue du 27ème BCA - BP2072 - 74011 Annecy Cedex

Tél.: 04 50 33 72 00www.haute-savoie.cci.fr

Accès en voiture• Depuis l’autouroute / sortie Annecy-Nord : prendre direction Annecy-centre / Avenue de Genève.

Suivre l’Avenue de Genève, puis tourner à gauche rue des Chasseurs, tourner ensuite à gauche rue Joseph Dessaix et 2ème à droite rue du 27ème BCA.

• Depuis l’autouroute / sortie Annecy-Sud : prendre direction Annecy-le-Vieux / Thônes.Entrer dans Annecy, continuer sur le boulevard de la Rocade. Après le 1er tunnel, prendre la direction de laRoche sur Foron-Les Fins. Prendre à droite Avenue de Genève. Sur l’Avenue de Genève, prendre à gauche rue des Chasseurs, tourner ensuite à gauche rue Joseph Dessaix et 2ème à droite rue du 27ème BCA.

Annexe C

Les Chiffres de la CCI de laHaute-Savoie

FIG. C.1 – Répartition des ressources de la CCI (13 328 Me)

COMMUNES 34,56%DEPARTEMENT 25,39%REGION 7,04%INTERCOMMUNALITE 20,67%CCI 1,87%CHAMBRE DES METIERS 0,83%FONDS PEREQUATION 2,20%ETAT 7,44%

Montant global = 358,8 Me

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


Les Chiffres de la CCI de la Haute-Savoie

FIG. C.2 – Part de l’IATP dans le budget de la CCI

FIG. C.3 – Répartition des ressortissants par secteur d’activité en 2003


Annexe D

Organigramme

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


Annexe E

La licence BSD (Berkeley SoftwareDistribution)

La licence BSD modifiée (flexible BSD licence) est une licence de logiciel libre simpleet permissive, sans gauche d’auteur, compatible avec la GPL de GNU.

Elle ne met pas de conditions sur l’utilisation et la rediffusion du logiciel qui peut ainsiêtre installé, modifié et distribué par tout le monde gratuitement quelque soit le butvisé, qu’il soit privé, commercial ou académique.

Dans sa version initiale (la license BSD originale), elle incluait une clause obligeant lesprogrammeurs qui l’utilisaient à mentionner dans tous leurs documents publicitairesla citation suivante : "This product includes software developed by the University ofCalifornia, Berkeley and its contributors" (Ce produit contient des logiciels développéspar l’Université de Californie, Berkeley et ses collaborateurs).


Annexe F

Limitations de PostgreSQL

Les données fournies ci-dessous sont celles officiellement annoncées sur le site dePostgreSQL1.

Maximum size for a database unlimited (4 TB databases exist)Maximum size for a table 16 TB on all operating systemsMaximum size for a row 1.6 TBMaximum size for a field 1 GBMaximum number of rows in a table unlimitedMaximum number of columns in a table 250 - 1600 depending on column typesMaximum number of indexes on a table unlimited

TAB. F.1 – Limitations of PostgreSQL

Of course, these are not actually unlimited, but limited to available disk space andmemory/swap space. Performance may suffer when these values get unusually large.

The maximum table size of 16 TB does not require large file support from the operatingsystem. Large tables are stored as multiple 1 GB files so file system size limits are notimportant.

The maximum table size and maximum number of columns can be increased if thedefault block size is increased to 32k.

1Sources : http://www.postgresql.org/users-lounge/limitations.html


http://www.postgresql.org/users-lounge/limitations.html

Annexe G

Phases pour réaliser l’ensemble dela migration

Afin de réaliser l’ensemble du processus de migration de façon manuelle, il faut res-pecter une chronologie dans les actions effectuées.Lors de l’utilisation automatisée du processus, l’ensemble des opérations sera égale-ment réalisé dans ce même ordre par le programme Perl.

Traiter le fichier des tables$sybase2postgresql -b ma_base -t mes_tables -S mon_serveur-U utilisateur -P mot_de_passe

Traiter le fichier des index$sybase2postgresql -b ma_base -i mes_index

Traiter le fichier des vues$sybase2postgresql -b ma_base -v mes_vues

Traiter le fichier des triggers$sybase2postgresql -b ma_base -g mes_trigger

Traiter le fichier des procédures$sybase2postgresql -b ma_base -f mes_fonctions

Créer la base$createdb -E LATIN1 ma_base

Créer le langage plpgsql$createlang plpgsql ma_base

Appliquer les "patch" sur la base (création des fonctions de Sybase n’existant pas sousPostgreSQL)$psql -c ’ \i PATCH_pour_postgresSQL’ ma_base

Créer les tables$psql -c ’ \i postgres_mes_tables ’ ma_base

Créer les index


Phases pour réaliser l’ensemble de la migration

$psql -c ’ \i postgres_mes_index ’ ma_base

Créer les vues$psql -c ’ \i postgres_mes_vue ’ ma_base

Exécuter le bcp des données$bcp_mes_tables

Traiter les fichiers des données (pour chacun des fichiers listé dans bcp_out_mes_tables$sybase2postgresql -b ma_base -g mes_données

Intégrer les données$psql -c ’COPY ma_table FROM "mon_fichier " USING DELIMITER "|"’

Mettre à jour les séquences$sybase2postgresql -b ma_base -g postgres_sequence_mes_tables

Créer les triggers$sybase2postgresql -b ma_base -t mes_triggers

Créer les procédures$sybase2postgresql -b ma_base -t mes_fonctions


Annexe H

Options pour l’utilisation desybase2postgresql

Afin de permettre une utilisation souple du programme, il est possible de le lanceravec différentes options.Ces dernières peuvent être transmises soit directement en ligne de commande, soitpar l’instermédiaire d’un fichier de configuration (lui même précisé en ligne de com-mande).Voici les options disponibles en ligne de commande :

Source H.1 – Options de sybase2postgresql affichées grâce à l’option -h

1 Usage : sybase2postgresq l [−h ] [−a ] [−b nom_base ] [− tf i c h i e r _ t a b l e ] [− i f i c h i e r _ i n d e x ] [−v f i c h i e r _ v u e ] [−gf i c h i e r _ t r i g g e r ] [−d f i ch ier_donnees ] [− f f i c h i e r _ f o n c t i o n ][−S serveur_sybase ] [−U u t i l i s a t e u r _ s y b a s e ] [−P

mot_de_passe_sybase ] [−c f i c h i e r _ c o n f i g u r a t i o n ]2 −h a f f i c h e l ’ aide3 −a s i l e s t o u t e s l e s opt ions n e c e s s a i r e s sont d e f i n i e s ( ou

s i l e f i c h i e r de c o n f i g u r a t i o n c o n t i e n t l e s informat ions ) ,tout l e t r a i t e m e n t peut e t r e automatique ( i l n ’ e s t pas

n e c e s s a i r e de donner de nom de f i c h i e r pour l e s donneescar c e l u i−c i e s t genere automatiquement )

4 −b nom de l a base de donnees sur l a q u e l l e porte l at ransformat ion

5 −t f i c h i e r contenant l a d e s c r i p t i o n des t a b l e s de l a base6 − i f i c h i e r contenant l a d e s c r i p t i o n des index de l a base7 −v f i c h i e r contenant l a d e s c r i p t i o n des vues de l a base8 −g f i c h i e r contenant l a d e s c r i p t i o n des t r i g g e r s de l a base9 −d f i c h i e r contenant l e s donnees d ’ une t a b l e

10 −f f i c h i e r contenant l e s f o n c t i o n s ( procedures ) d ’ une base11 −S nom ( ou adresse ) du serveur Sybase de l a base o r i g i n e12 −U nom d ’ u t i l i s a t e u r pour l a base Sybase13 −P mot de passe pour l a base Sybase14 −c f i c h i e r de c o n f i g u r a t i o n contenant l e s opt ions : permet

de ne pas s p e c i f i e r chacune des opt ions c i dessus


Options pour l’utilisation de sybase2postgresql

Dans le fichier de configuration, il est possible d’utilliser les mêmes options qu’enligne de commande mais sans les faire précéder d’un tiret.Chaque option doit se trouver sur une ligne distincte de la forme :

option = valeur

L’option a n’a pas besoin de valeur car elle est de type booléenne.Il est possible d’insérer des commentaires en les faisant précéder du signe # et leslignes vides seront ignorées.Pour les options précisant des noms de fichiers, il est possible de préciser plusieursfichiers pour une même options (alors que ça n’est pas possible par un appel en lignede commande) en indiquant le nom de chaque fichier sur une ligne différente.

On aura donc un fichier de configuration du type :

Source H.2 – Exemple de fichier de configuration de sybase2postgresql

1 # F i c h i e r de c o n f i g u r a t i o n de l a m i g r a t i o n de l a b a s e c c i 12 a3 b = c c i 14 t = monrepertoire/mes_tables1 . s q l5 t = monrepertoire/mes_tables2 . s q l6 i = mes_indexs . s q l7 f = mes_fonctions . s q l8

9 # S e r v e u r Sybase10 S = monServeur11 U = u t i l i s a t e u r12 P = mot_de_passe


Annexe I

Documentation desybase2postgresql

I.1 NOM

Convertisseur de base de donnee Sybase vers Postgresql

I.2 SYNOPSIS

Outils permettant de transformer (a partir de fichier scripts SQL) une base Sybase versune base PostgreSQL.– Pour voir les options disponibles, tapper sybase2postgresql -h– La plupart des options permettent d’indiquer l’emplacement de scripts SQL qui

seront transformes pour etre utilisables par PostgreSQL.– A partir du ficher SQL de creation des tables, sybase2postregresql va produire les

scripts de creation des tables, des commandes pour bcp (recuperation des donnees),de mise a jour des sequences (pour que l’incerementation automatique reprenneapres le dernier enregistrement cree) qui devra etre execute apres l’insertion desdonnees dans la base

– Le programme peut Ãªtre appele en lignes de commandes avec les options ou avecun fichier de configuration

– L’ensemble des operations peut etre automatise grace a l’option -a

I.3 DESCRIPTION

Les Methodes "outils"

configuration

Va lire le fichier de configuration passe en parametre et initialise les variables en fonc-tion de son contenu.

automatique

Automatise le fonctionnement du script : toutes les actions sont effectuees automati-quement (a condition que tous les renseignements necessaires soient fournis)


Documentation de sybase2postgresql

clear_line

Netoie une ligne passee en parametres en enlevant le retour chariot, remplacant leslettres accentuees par des lettres "normales" et en passant tout le texte en minuscules.

convert2cast

Transforme les fonction convert(type, variable) en fonction CAST(variable AS type)

right2lpad

Transforme les fonction right(’remplissage’ + chaine, longueur) en fonction lpad(chaine,longueur, ’remplissage’)Permet de palier au manque de booleen (renvoie 0)Permet de palier au manque de booleen (renvoie 1)

decommente_fichier

Permet d’enlever les commentaires d’un fichier et de remettre les fonctions (detecteespar leurs parentheses) sur une seule ligne

Les Methodes "de transformation"

traite_table

Traite le fichier de script SQL de creation des tables.

traite_index

Traite le fichier de script SQL de creation des index.

traite_vue

Traite le fichier de script SQL de creation des vues

traite_procedure

Traite le fichier contenant les procedures afin de les rendre utilisables par PostgreSQL.

traite_trigger

Traite le fichier contenant les procedures afin de les rendre utilisables par PostgreSQL.

traite_donnee

Traite le fichier de donnees afin de modifier les rendre assimilables par PostgreSQLlors du COPY

I.4 VOIR AUSSI

Documentation PostgreSQL, documentation BCP, ...


Annexe J

Problèmes spécifiques à chaquetype d’information à migrer

J.1 Les tables

J.1.1 Problèmes rencontrés

1. Certains types n’existent pas sous PostgreSQL (datetime, image, tinyint, binary)

2. Dans certaines tables, le champ servant de clef est de type "identity"

3. La casse des noms de tables n’est pas uniforme (complètement en majuscules,complètement en minuscules ou une partie en minuscules et une partie en ma-juscules)

4. Une table porte un nom avec un caractère accentué (Paramètre)

5. Certaines colonnes ont des noms trop longs (>23 caractères) pour être correcte-ment exportées par DbDk.

J.1.2 Solutions possibles

1. Pour les types inexistants, il y a deux possibilités :– Utiliser un autre type compatible (datetime transformé en timestamp, image

en bytea, tinyint en smallint et binary en bytea)– Créer de nouveaux types de données (CREATE TYPE)

2. Pour le champ identity, il est possible de le transformer en séquence (CREATESEQUENCE). Il faut noter que cette solution impose la récupération des "bons"identifiants lors de l’import des données et ensuite, de mettre à jour l’état de laséquence grâce à la commande setval().

3. Pour la casse, PostgreSQL étant "casse sensitive" alors que Sybase ne l’est pas, ilest plus prudent et rationnel de transformer tous les noms afin qu’ils soient tousen minuscules et que les appels se fassent toujours de la même manière.

4. Les accents n’étant pas admis, il faut absolument remplacer la lettre accentuée (èdeviendra e)

5. Pour la longueur des colonnes, il faut soit utiliser un autre outil pour l’export desschémas, soit utiliser une nouvelle version de DbDk (les noms étant tronquésdans le fichier texte, il n’est pas possible de gérer le problème à posteriori).


Problèmes spécifiques à chaque type d’information à migrer

J.2 Les index


1. Certains index, sur des tables différentes, portent des noms identiques.

2. Certains index sont de type CLUSTERED. Ceci signifie que les enregistrementsde la table sont classés physiquement en fonction du champ sur lequel portel’index.


1. La solution la plus simple et logique à mettre en place est la modification de lapolitique de nommage pour ces index (le choix qui a été fait est celui d’accoler lenom de la table et le nom de l’index).

2. Ce type de contraintes n’existe pas réellement sous PostgreSQL. Il est cependantpossible d’utiliser la fonction CLUSTER qui "range" à un instant donné la tableselon le champ indiqué. Si on perçoit la nécessité de classer cette table (démon-trée par des tests de performance significatifs), il serait possible de déclencherde manière régulière (par exemple par l’utilisation de Cron) l’utilisation de lafonction CLUSTER. Le choix d’utiliser ou non CLUSTER devra être fait en fonc-tion des performences et non de l’existence de CLUSTERED sous Sybase (leurprésence n’est pas/plus forcément judicieuse) ;

J.3 Les vues


1. Les vues de la bases ne sont pas crées avec la même syntaxe (=> difficile de faireune règle unique de traitement) :– Utilisation de ", de ’ ou rien pour les noms de colonne– Utilisation ponctuelle de syntaxe du type "cci.." pour les noms de table

2. Utilisation de caractères spéciaux (accents, °, majuscules)

3. Les colonnes ne sont pas systématiquement renommées

4. L’utilisation de " dans la clause WHERE n’est pas interprétée par PostgreSQLcomme un champ de texte.

5. Les jointures externes ne sont pas représentées de la même façon sous Sybase etsous PostgeSQL.

6. Certaines fonction internes à Sybase (convert, isnull, datepart, right, suser_id)n’existent pas sous PostgreSQL.

7. Certaines conversions de types existent sous Sybase mais pas sous PostgreSQL(transformation de varchar en int et transformation de smallint vers bit)


1. L’utilisation des ’ ou " ainsi que l’utilisation du nom de la base pour les tables(puisqu’on ne peut pas gérer de vue "interbase" sous PostgreSQL) n’étant pasindispensable, ils peuvent être supprimés.



2. Les caractères spéciaux doivent, comme pour les tables, être remplacés par leuréquivalent "simple".

3. il faut détecter le renomage (utilisation d’un alias) grâce à la structure alias =nom_champ afin de le remplacer par la structure nom_champ AS alias valide

sous PostgreSQL.Il faut cependant prendre garde au fonctions qui peuvent être utilisées à la placedu nom de champ et qui sont parfois répartis sur plusieurs lignes (elles rendentla détection de la fin de "nom_champ" plus difficile).

4. Remplacement des " par des ’

5. Sous postgreSQL, la fonction de jointure ne s’utilise pas totalement de la mêmefaçon que sous Sybase. Alors que sous Sybase l’utilisation de "*=" ou de "=*"entre deux champs dans la clause "where" est suffisante, sous PostgreSQL, il estnécessaire d’utiliser fonction "left" ou "right outer join" entre les deux tables àjoindre et de préciser les champs dans une clause "on".Certaines informations (comme la correspondance entre un champ et la table àlaquelle il appartient) n’étant pas disponibles pour le programme Perl, il n’estpas possible d’automatiser cette transformation : elle devra donc être réaliséemanuellement.

6. Il est souvent possible d’utiliser les fonctions correspondantes sous PostgreSQL :– "convert" est remplacé par "cast"– "isnull" est remplacé par "coalesce"– "datepart" est emplacé par "date_part"– pour "right", il n’y a pas de fonction correspondante sous PostgreSQL. Ce-

pendant, comme cette fonction est ici utilisée uniquement pour compléter àgauche une chaine de caractère de ’0’ pour qu’elle ait une taille fixe, il est pos-sible de la remplacer la la fonction lpad.

Les fonctions suser_id n’existent pas sous Sybase (et aucune fonction correspon-dante n’existe). Il a donc faullu créer ces fonctions de toute pièce grâce à pl/pg-sql :

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

1 CREATE OR REPLACE FUNCTION suser_ id ( t e x t ) RETURNS in tegerAS ’

2 DECLARE3 nom a l i a s f o r $1 ;4 uid i n t e g e r ;5 BEGIN6 SELECT INTO uid7 usesysid8 from pg_catalog . pg_shadow9 where usename=nom;

10

11 RETURN uid ;12 END;13 ’ language ’ plpgsql ’ ;14

15 / *−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−* /



16

17 CREATE OR REPLACE FUNCTION suser_ id ( ) RETURNS in teger AS ’18 DECLARE19 uid i n t e g e r ;20 BEGIN21 SELECT INTO uid22 usesysid23 from pg_catalog . pg_shadow24 where usename=SESSION_USER ;25

26 RETURN uid ;27 END;28 ’ language ’ plpgsql ’ ;

7. En ce qui concerne la conversion de varchar en int, il est possible de passer parun text (les conversions "varchar vers text" et "text vers int" exitent toutes lesdeux. Il est alors possible, soit de modifier le code source de la vue (mais cettesolution n’est pas très "propre" car elle nécessite une intervention manuelle), soitde créer un nouveau type de conversion (CAST) dans PostgreSQL.

Source J.2 – Création d’une fonction de conversion de type (varchar vers int)1 CREATE OR REPLACE FUNCTION v a r c h a r _ t o _ i n t ( c h a r a c t e r

varying ) RETURNS i n t 2 AS ’2 DECLARE3 input a l i a s f o r $1 ;4 BEGIN5 re turn ( input : : t e x t : : i n t 2 ) ;6 END;7 ’ language ’ plpgsql ’ ;8 CREATE CAST ( varchar AS i n t 2 ) WITH FUNCTION v a r c h a r _ t o _ i n t

( varchar ) ;

Les smallint (aussi appelés int2) ne possédent pas de conversion vers les bit alorsque les autres types d’entiers possèdent cette conversion. Tout comme pour latransformation à partir du varchar, on peut donc créer une conversion passantpar un type intermédiaire (ici le int4).

Source J.3 – Création d’une fonction de conversion de type (smallint vers bit)1 CREATE OR REPLACE FUNCTION s m a l l i n t _ t o _ b i t ( i n t 2 ) RETURNS

b i t AS ’2 DECLARE3 input a l i a s f o r $1 ;4 BEGIN5 re turn ( input : : i n t 4 : : b i t ) ;6 END;7 ’ language ’ plpgsql ’ ;8 CREATE CAST ( i n t 2 AS b i t ) WITH FUNCTION s m a l l i n t _ t o _ b i t (

i n t 2 ) ;



J.4 Les données


1. Le format d’export des dates par BCP n’est pas compatible avec l’import dansPostgreSQL


1. Pour les dates, il n’y a pas moyen de modifier par une option le format d’exportde BCP.Plusieurs solutions sont alors possibles :– Utiliser une vue où la date serait convertie au bon format et stockée au format

texte (mais il faut alors également utiliser une version récente de BCP qui sup-porte l’export de vues). Cette solution est assez lourde et implique la créationd’autant de vue qu’il y a de tables contenant des dates avant de pouvoir ef-fectuer la moindre extraction (qui sera ralentie par la "surcouche" qu’amène lavue et les fonctions utilisées).

– Utiliser un fichier format (formatfile) donné en paramètre à BCP (option -f)et qui contient la description de tous les champs de la table. Cette solutionpermet une modification "invisible" pour l’export mais nécessite de créer lesfichiers de format (et également de décrire les colonnes qui ne sont pas deformat date) ce qui est fastidieux.

– Créer un script Perl qui modifiera les données de type date (elles ont un "as-pect" facilement repérable dans un fichier (Mmm JJ AAAA HH :MM :SS :sss{AM ou PM} ). Après quelques tests, cette solution parait la plus facile à mettreen place et à utiliser.

J.5 Les procédures et les triggers

Ces éléments n’ayant pas été traités durant le stage (pas de migration effective), il n’estpas possible de lister de manière exhaustive les problèmes rencontrés et les solutionsapportées.Cependant, lors de la phase d’évaluation du temps restant, il a fallu déterminer quelsproblèmes pourraient se poser lors de la migration et l’impact qu’ils pourraient avoirsur la difficulté de "traduction".

1. La déclaration des variables sous Sybase est réalisées aussi bien avant que aprèsle BEGIN alors que sous PostgreSQL, elle doit être réalisée dans le DECLARE.

2. La structure des procédure n’est pas toujours clairement établie avec l’utilisationde DECLARE, BEGIN et END.

3. Dans les structures de boucles ou de choix, l’utilisation du BEGIN et du END estcourrante mais n’est pas généralisée.

4. Sous Sybase, la fin d’une instruction n’est pas forcément indiquée de manièreréellement explicite (par exemple avec un ;) ce qui rend la détection plus com-plexe.



5. La nature du résultat envoyé par une procédure n’est pas explicite et peut poserdes problèmes dans le cas d’un résultats composé de plusieurs "colonnes" etplusieurs "lignes" en comparaison d’une seule valeur.

6. Certaines fonctions internes à Sybase n’existent pas sous PostgreSQL. Mais cetaspet peut être traité de la même façon que lors qu traitement des vues.

7. L’utilisation de raiserror pour traiter les erreurs sous Sybase ne peut pas êtreidentique sous PostgreSQL.


Annexe K

Mesures pour les indicateurs decomplexité des procédures

FIG. K.1 – Nombre de lignes par procédure


Mesures pour les indicateurs de complexité des procédures

FIG. K.2 – Nombre d’instructions SQL par procédure

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


Mesures pour les indicateurs de complexité des procédures

FIG. K.4 – Nombre de curseurs par procédure

FIG. K.5 – Répartition des procédures par type


Annexe L

Installation de modulessupplémentaires pour Perl

Lors de mes développements, il m’a été nécessaire d’installer de nouveaux modulespour Perl.Ceux-ci peuvent être installés de deux manières différentes : en récupérant et en com-pilant le module manuellement, ou en utillisant le module MCPAN.

L’utilisation du module MCPAN facilite de façon très importante l’installation de mo-dules mais elle nécessite une phase de configuration qui peut être grandement simpli-fiée en créant directement le fichier de configuration :/root/.cpan/CPAN/MyConfig.pm

Source L.1 – Fichier de configuration du module MCPAN1 $CPAN : : Config = {2 ’ bui ld_cache ’ => q [ 1 0 ] ,3 ’ bu i ld _d i r ’ => q[/ root /. cpan/build ] ,4 ’ cache_metadata ’ => q [ 1 ] ,5 ’ cpan_home ’ => q[/ root /. cpan ] ,6 ’ dontload_hash ’ => { } ,7 ’ f t p ’ => q[/ usr/kerberos/bin/ f t p ] ,8 ’ f tp_proxy ’ => q [ proxy . c c i . net : 8 0 8 0 ] ,9 ’ getcwd ’ => q [cwd ] ,

10 ’ gzip ’ => q[/ usr/bin/gzip ] ,11 ’ http_proxy ’ => q [ proxy . c c i . net : 8 0 8 0 ] ,12 ’ i n a c t i v i t y _ t i m e o u t ’ => q [ 0 ] ,13 ’ index_expire ’ => q [ 1 ] ,14 ’ inh ib i t_s tar tup_message ’ => q [ 0 ] ,15 ’ keep_source_where ’ => q[/ root /. cpan/sources ] ,16 ’ l i n k s ’ => q[/ usr/bin/ l i n k s ] ,17 ’make ’ => q[/ usr/bin/make ] ,18 ’ make_arg ’ => q [ ] ,19 ’ make_ins ta l l_arg ’ => q [ ] ,20 ’ makepl_arg ’ => q [ ] ,21 ’ nc f tp ’ => q [ ] ,22 ’ n c f t p g e t ’ => q [ ] ,


Installation de modules supplémentaires pour Perl

23 ’ no_proxy ’ => q [ ] ,24 ’ pager ’ => q[/ usr/bin/ l e s s ] ,25 ’ p r e r e q u i s i t e s _ p o l i c y ’ => q [ ask ] ,26 ’ proxy_pass ’ => q[ <mot de passe >] ,27 ’ proxy_user ’ => q[ < u t i l i s a t e u r >] ,28 ’ scan_cache ’ => q [ a t s t a r t ] ,29 ’ s h e l l ’ => q[/ bin/bash ] ,30 ’ t a r ’ => q[/ bin/ t a r ] ,31 ’ t e r m _ i s _ l a t i n ’ => q [ 1 ] ,32 ’ unzip ’ => q[/ usr/bin/unzip ] ,33 ’ u r l l i s t ’ => [ q [ f t p :// f t p . l i p 6 . f r /pub/p e r l/CPAN/ ] ] ,34 ’ w a i t _ l i s t ’ => [ q [ wait :// ls6−www. informat ik . uni−dortmund . de

: 1 4 0 4 ] ] ,35 ’ wget ’ => q[/ usr/bin/wget ] ,36 } ;37 1 ;38 __END__

Ensuite, pour installer un nouveau module, il suffit de se loguer en administrateur etde lancer la commande :

$per l −MCPAN −e s h e l l

Puis sous le prompt qui apparait, utiliser la commande :

$ i n s t a l l Appconfig


Annexe M

Enregistrement d’un fichier enUTF-8 sous Emacs

Lorsque certains fichiers ont été crées sous Windows, une partie des caractères ne sontpas compatibles avec l’UTF-8, il faut alors les transformer pour qu’ils soient utilisablespar les scripts Perl sous Linux.Pour cela, Emacs possède un certain nombre de fonctions permettant de réaliser assezsimplement cette opération.

Il faut tout d’abord ouvrir le ficher sous Emacs

Il faut ensuite remplacer tous les retour chariot (saut de ligne) typiques de Windows(visibles avec Emacs sous la forme ˆM) par leur équivalent Unix. Pour cela :

Alt S h i f t %M

" Entree "" Entree "!" Entree "

Remarque : le " !" sert à effectuer tous les remplacement sans poser de question.

Il faut ensuite enregister le fichier en forçant l’encodage UTF-8 Unix :

C t r l x" Entree "cutf−8−unix" Entree "C t r l xC t r l s

Convention d’écriture :"Entree" représente la touche de retour à la ligne du clavier.Lorsque plusieurs touches sont indiquées sur la même ligne, cela signifie qu’ellesdoivent être appuyées en même temps.


Annexe N

Webographie

N.1 CCI

CCI de la Haute-Savoie :http://www.haute-savoie.cci.fr/

CRCI Rhône-Alpes :http://www.rhone-alpes.cci.fr/

Portail fraçais des chambres de commerce et d’industrie :http://www.cci.fr/HomePage_CCIFR

AFCCI :http://www.acfci.cci.fr/

N.2 PostgreSQL

http://www.postgresql.org/

Site français des utilisateurs de PostgreSQL :http://postgresqlfr.org/drupal/

Installation de PostgreSQL - Club d’entraide des développeurs francophones :http://stessy.developpez.com/postgresql/installation/

Newsgroup des utilisateurs et développeurs de PostgreSQL :comp.databases.postgresql.*

Outil d’administration PGAdmin :http://www.pgadmin.org/pgadmin3/index.php?locale=fr_FR

N.3 Sybase

http://www.sybase.com/home

Manuels Sybase :http://www.sybase.com/support/manuals


http://www.haute-savoie.cci.fr/

http://www.rhone-alpes.cci.fr/

http://www.cci.fr/HomePage_CCIFR

http://www.acfci.cci.fr/

http://www.postgresql.org/

http://postgresqlfr.org/drupal/

http://stessy.developpez.com/postgresql/installation/

comp.databases.postgresql.*

http://www.pgadmin.org/pgadmin3/index.php?locale=fr_FR

http://www.sybase.com/home

http://www.sybase.com/support/manuals

Webographie

Newsgroup des utilisateurs de Sybase :comp.databases.sybase

N.4 Perl

http://www.perl.com/

Les mongueurs de Perl :http://paris.mongueurs.net/indexfr.html

Foire aux questions Perl :http://www.bribes.org/perl/docfr/perlfaq.html

Introduction à Perl :http://lea-linux.org/dev/perl.php3

Newsgroup français des utilisateurs de Perl :fr.comp.lang.perl

N.5 RedHat DataBase

http://sources.redhat.com/rhdb/

Manuels RHDB :http://www.redhat.com/docs/manuals/database/

RedHat Network :https://rhn.redhat.com/index.pxt

N.6 Sources d’informations généralistes

Forums de discution axés programmation et/ou base de données :http://www.developpez.net/forums/index.phphttp://forum.hardware.fr/hardwarefr/Programmation/SGBD/liste_sujet.htmhttp://www.dbforums.com/index.php

Wikipédia :http://fr.wikipedia.org/wiki/Accueil

Glossaire du jargon informatique :http://www.linux-france.org/prj/jargonf/general/bgfrm.html


comp.databases.sybase

http://www.perl.com/

http://paris.mongueurs.net/indexfr.html

http://www.bribes.org/perl/docfr/perlfaq.html

http://lea-linux.org/dev/perl.php3

fr.comp.lang.perl

http://sources.redhat.com/rhdb/

http://www.redhat.com/docs/manuals/database/

https://rhn.redhat.com/index.pxt

http://www.developpez.net/forums/index.php

http://forum.hardware.fr/hardwarefr/Programmation/SGBD/liste_sujet.htm

http://www.dbforums.com/index.php

http://fr.wikipedia.org/wiki/Accueil

http://www.linux-france.org/prj/jargonf/general/bgfrm.html

Bibliographie

[1] Guy Achard-Bayle. « Éléments pour une description linguistique du mémoireprofessionnel universitaire ». Texte rédigé dans le cadre du groupe de travail surle mémoire professionnel, février 2002.

[2] Françoise Demaizière et Jean Uebersfeld. « Approche du mémoire professionneluniversitaire ». Texte rédigé dans le cadre du groupe de travail sur le mémoireprofessionnel, 2002-2003.

[3] Michel Goossens, Frank Mittelbach, et Alexander Samarin, Latex Companion.Campus Press, juin 2001.

[4] Vincent Seguin, Aide-Mémoire Latex, septembre 2000.

[5] C. Willems et F. Geraerds, Aide Mémoire pour Latex, juillet 1996.

[6] Eddie Saudrais, Le petit typographe rationnel, mars 2000.

[7] Sybase, Utility Guide.

[8] Sybase, Sybase Adaptive Server Enterprise - Manuel de référence - Volume 1 : Elémentssyntaxiques.

[9] Microsoft, Manuel de Référence Transact - SQL. pour Miscrosoft SQL Server version6.0.

[10] Sybase, Transact-SQL User’s Guide.

[11] Noam Chomsky. http://web.mit.edu/linguistics/www/bibliography/noam.html.

[12] Luc Maranget, Cours de compilation. École Polytechnique.

[13] Jean-Philippe Dalbera, « Le corpus entre données, analyse et théorie », Corpus etrecherches linguistiques, novembre 2002.

[14] Peter D. Turney, Michael L. Littman, Jeffrey Bigham, et Victor Shnayder, « Com-bining independent modules to solve multiple-choice synonym and analogy pro-blems (combinaison de modules indépendants pour la résolution de problèmesde synonymie et d’analogie à choix multiples) », dans Proceedings of the Interna-tional Conference on Recent Advances in Natural Language Processing (RANLP-03),p. 482–389. Conseil National de Recherches Canada & Institut de Technologie del’Information, septembre 2003. Numéro de publication du CNRC : NRC 46506.

[15] Pankaj Jalote, Gestion de projet informatique en pratique. Campus Press, 2002.

[16] Cyrille Chartier-Kastler, Précis de conduite de projet informatique. Les Éditions d’or-ganisation, 1995.

[17] Project Management Institute, éditeur, A guide to the Project Management Body ofKnowledge. Project Management Institute, 2000.

[18] Rational Unified Process, éditeur, Rational Unified Process Best Practices for SoftwareDevelopment Teams. Rational Software Corporation, 1998.

[19] Pierre-Yves Cloux, RUP, XP Architectures et outils. Dunod, 2003.


http://web.mit.edu/linguistics/www/bibliography/noam.html

BIBLIOGRAPHIE

[20] « Extreme programming - méthodes agiles : L’état des lieux », 2001.

[21] Stève Sfartz, Processus de développement Objet : Best Practices. Improve, 2001.

[22] John C. Worsley et Joshua D. Drake, PostGreSQL par la pratique. O’Reilly, 1re édi-tion, octobre 2002.

[23] Bruce Momjian, PostgreSQL Introduction and Concepts. Addison & Wesley, 2001.

[24] Alavoor Vasudevan et Albert-Paul Bouillot, Database-SQL-RDBMS HOW-TO pourLinux (PostgreSQL Object Relational Database System), v13.0 édition, octobre 1999.version française.

[25] Red Hat, Red Hat Database, janvier 2002. Whitepaper.

[26] Red Hat, PostgreSQL - Red Hat Edition Graphical Tools Guide, 2003.

[27] Randal L. Schwartz et Tom Phoenix, Introduction à Perl. O’Reilly, 3e édition, jan-vier 2002.

[28] Larry Wall, Tom Christiansen, et Jon Orwant, Programmation en Perl. O’Reilly, 3e

édition, décembre 2001.

[29] Sylvain Lhullier, Introduction à la programmation en Perl, mars 2004. Version 1.0.1.

[30] Paul Gaborit, Documentation Perl, mai 2004.

[31] François Dagorn et Olivier Salaun, Débuter en Perl, mai 2002.

[32] Laboratoire d’Informatique Médicale de la faculté de médecine de Rennes, Intro-duction au langage Perl, novembre 2003.

[33] « Hors-série login n°22 - spécial perl », janvier - mars 2004.

[34] Jeffrey E.F. Friedl, Mastering Regular Expressions. O’Reilly, décembre 1998. Power-ful Techniques for Perl and Other Tools.

[35] K. El-Emam, « A methodology for validating software product metrics (métho-dologie de validation de systèmes de mesure de logiciels) ». Rapport technique,Conseil National de Recherches Canada & Institut de Technologie de l’Informa-tion, Juin 2000. Numéro de publication du CNRC : NRC 44142.

[36] MySQL, Database Server Feature Comparisons. Comparaison dynamique dispo-nible sur http://dev.mysql.com/tech-resources/crash-me.php.

[37] Oracle, Migrating Applications from Microsoft SQL Server to Oracle9i Database, no-vembre 2003.

[38] Oracle, Reference Guide for Microsoft SQL Server and Sybase Adaptive Server Migra-tions, mars 2002. Release 9.2.0 for Microsoft Windows 98/2000 and MicrosoftWindows NT.

[39] Marina Marina Greenstein, Sybase and Oracle Migration Sybase and Oracle Migra-tion to DB2 UDB to DB2 UDB. IBM, 2001.

[40] IBM, Migration Success Factors.


http://dev.mysql.com/tech-resources/crash-me.php

Glossaire

AACFCI : Assemblée des Chambres Françaises de Commerce et d’Industrie.

AG : Assemblée Générale.

APCCI : Assemblée Permanente des Chambres de Commerce et d’Industrie.

Application métier : Progiciel qui intègre les règles de gestion du métier pour lequelelle a été conçue, sans imposer de fonctions superflues.

Approche descendante : (en anglais, top-down). Le fait de concevoir un système enallant du général au particulier, en passant par des étapes d’affinage.

Approche montante : (en anglais, bottom-up). Approche inverse de l’approche des-cendante. On conçoit donc le système en allant du détail vers le général, enpassant par des étapes d’agrégation.

ASCII : (American Standard Code for Information Interchange). Ensemble de carac-tères non accentués (les 128 premières valeurs des codages ISO-8859-X).

ATA-VISA : Documents nécessaires aux procédures douanières d’exportation tempo-raire.

BBack-porter : Le fait de porter de nouveaux développements d’une application depuis

une version récente vers une version plus ancienne. L’idée est de faire profiterdes corrections de bug (principalement) les utilisateurs qui ne veulent pas fairede mise à jour.

BCP : (BulkCoPy). Logiciel permettant l’extraction de données d’une base Sybase.

BEE : (Base Economique Evènementielle). Application métier de CRM, développéesous 4D.

Benchmark : Banc d’essai, permettant de mesurer les performances d’un système pourle comparer à d’autres.

BSD : (Berkeley Software Distribution). L’université de Berkeley est connue dans lemonde Unix pour les nombreux logiciels qu’elle a développé puis mis dans ledomaine public.

CCCIFE : Chambres de Commerce et d’Industrie Françaises à l’Étranger.

CCI : Chambre de Commerce et d’industrie.


BIBLIOGRAPHIE

CFE : Centre de Formalité des Entreprises.

CODIR : (COmité de DIRection). Il est composé de la Direction Générale et de tousles responsables de service de la CCI.

Copyleft : Le copyleft est la possibilité donnée par l’auteur d’utiliser, copier, étudier,modifier et distribuer son œuvre à l’utilisateur, avec la restriction que celui-cidevra laisser l’œuvre sous les mêmes conditions d’utilisation, y compris dansles versions modifiées ou étendues.Le copyleft (traduit humoristiquement par gauche d’auteur) a été inventé parRichard Stallman de la Free Software Foundation en 1984.Le fondement juridique du copyleft est le copyright (ou le droit d’auteur, selonla juridiction où il est exprimé) avec un contrat d’utilisation qui prend la formed’une licence.

Corpus : En linguistique, ce terme désigne un recueil de pièces ou de documents quiconcernent une certaine unité de genre ou bien d’époque.

CRCI : Chambre Régionale de Commerce et d’Industrie.

CRM : (Customer Relationship Management). Gestion de la relation avec la clientèle.

DDBMS : (Data Base Management System - Système de Gestion de Base de Données).

voir SGBD

EEAI : (Enterprise Application Integration). Intégration des applications dans l’entre-

prise. Le but d’un EAI est de faire fonctionner ensemble (en particulier en ma-tière d’échange transparent de données) les programmes existant dans une en-treprise, en vérifiant leur interopérabilité, et gérer l’hétérogénéité générale.

Encodage : Le codage des caractères par l’intermédiaire de tables de correspondancepermet d’associer à chaque caractère (visible ou de contrôle), un code numé-rique.

eXtreme Programing : voir XP.

FFSF : (Free Software Foundation). Créé par Richard Stallman, la FSF a pour but de

promouvoir et développer l’utilisation des logiciels et documentations libres.

GGauche d’auteur : voir Copyleft.

GNU : GNU est un acronyme récursif pour GNU’s Not UNIX

GPL : (General Public License). Aussi appelée, licence publique générale GNU. Lestatut juridique d’une partie des logiciels distribués librement, à l’origine utilisépour le projet GNU de la FSF.


BIBLIOGRAPHIE

Grammaire formelle : Formalisme permettant de définir une syntaxe et donc un lan-gage formel, c’est-à-dire un ensemble de mots sur un alphabet donné.

Grammaire : Étude des règles qui régissent une langue. Elle comporte plusieurs dis-ciplines dont la phonétique, la phonologie, la morphologie, la syntaxe et la sé-mantique.

IIATP : Impôt Additionnel à la Taxe Professionnelle.

Interlangue : Dans le domaine de la traduction automatique, une interlangue est unelangue artificielle qui sert d’intermédaire entre la langue source et la languecible

LLangage naturel : Le langage que vont utiliser deux êtres humains pour se parler.

Langage pivot : Terme généralement utilisé en informatique pour désigner une inter-langue.

LaTeX : Lamport TeX. Système de composition générique de texte qui utilise TeX commemoteur de formatage. Après avoir écrit un texte et l’avoir structuré à l’aide debalises, une compilation permet d’obtenir le rendu final du texte.

Latin1 : Norme ISO correspondant à une sorte d’ASCII étendu sur 8 bits et permettantde coder la plupart des caractères accentués de l’alphabet latin (notre alphabet).voir encodage.

Lemme : (ou encore lexie) Est l’unité autonome constituante du lexique d’une langue.Dans le langage courant, on utilise souvent le terme mot.

Lexique : En linguistique, le lexique d’une langue constitue l’ensemble de ses lemmesou, d’une manière plus courante mais moins précise, l’ensemble de ses mots.Dans les usages courants, on utilise plus facilement le terme de vocabulaire.

Logiciel libre : Le logiciel libre rassemble les applications livrées avec leurs sources,que l’on peut donc modifier à volonté pour l’adapter à ses besoins, par opposi-tion aux programmes fermés et copyrightés. Cependant, il faut bien noter quelibre ne signifie pas forcément gratuit.

OODBC : (Open DataBase Connectivity). Spécification reconnue pour l’échange d’in-

formations entre applications et base de données relationnelles, mettant enœuvre le langage SQL.

Open Source : Principe selon lequel le code source du logiciel est libre d’accès, auto-risant ainsi la création de communautés qui développeront de nouvelles fonc-tionnalités. C’est une notion proche de celle de logiciel libre.

OS : (Operating System - Système d’Exploitation). Un système d’exploitation est unensemble cohérent de logiciels permettant d’utiliser un ordinateur et tous seséléments (ou périphériques). Il assure le démarrage de celui-ci et fournit auxprogrammes applicatifs les interfaces pour contrôler les éléments de l’ordina-teur.


BIBLIOGRAPHIE

PPerl : (Practical Extraction and Report Language). Langage de programmation de

haut niveau avec un héritage éclectique écrit par Larry Wall et un bon millierde développeurs. Il dérive du langage C et, dans une moindre mesure, de Sed,Awk, du shell Unix et d’au moins une douzaine d’autres langages et outils.

Phonologie : Branche de la linguistique qui étudie les phonèmes, c’est-à-dire com-ment s’organisent les sons d’une langue afin de former des énoncés.

Phonétique : Branche de la linguistique qui étudie les sons des langues.

POD : (Plain Old Documentation - bonne vieille documentation). Langage qui permetd’insérer la documentation dans du code sans qu’elle soit lue par l’interpréteurPerl mais qui peut être extraite sous différents formats grâce à des outils commepod2html ou pod2man.

Pragmatique : En tant que partie de la linguistique, elle s’intéresse aux unités linguis-tiques dont la signification ne peut être comprise qu’en contexte. C’est un desaspect de la sémantique.

RRAD : (Rapid Application Development). Méthode de développement de logiciels

par itérations où l’on réalise, teste et fournit des morceaux de l’application àintervalles réguliers sans attendre que l’ensemble soit achevé.La méthode re-pose sur l’utilisation d’outils de programmation à interface graphique, qui per-mettent d’obtenir rapidement des prototypes.

RCS : Registre du Commerce et de Sociétés.

RHDB : (RedHat Database). Projet de RedHat regroupant PostgreSQL et des outilsd’installation et d’administration supplémentaires.

RHEL : (RedHat Entreprise Linux). Distribution de Linux proposée par RedHat des-tinée aux entreprises et accompagnée de différents niveaux de support et demaintenance.

RHN : (Red Hat Network). Site Internet réservé aux personnes bénéficiant du supportRedHat. L’inscription y est gratuite mais version complète nécessite la cotisa-tion aux services de support.

RH : Ressources Humaines.

RUP : (Rational Unified Process). Processus de développement logiciel itératif et in-crémental proposé par Rational.

SScalabilité : (de l’anglais scalability : extensibilité). Capacité d’un système à faire face

à des charges d’utilisation variables, la consommation de ressources étant laplus linéaire possible (donc la plus prévisible).


BIBLIOGRAPHIE

Sel syntaxique : Par opposition au sucre syntaxique, est une fonctionnalité conçuepour rendre plus difficile d’écrire du mauvais code. En pratique, le sel syn-taxique est comme un passage obligé par lequel le programmeur doit passerpour prouver qu’il sait ce qu’il fait, sans que le code écrit pour cela n’exprimeune action particulière du logiciel.

SE : (Système d’Exploitation). voir OS.

SGBDR : (Système de Gestion de Base de Données Relationnel). Les données sont en-registrées dans des tableaux à deux dimensions (lignes et colonnes). La mani-pulation de ces données se fait selon la théorie mathématique des relations.

SGBD : (Système de Gestion de Base de Données). Système permettant de contrôlerles données ainsi que les utilisateurs d’une base de données.

SI : (Système d’Information). Ensemble des moyens techniques et humains permet-tant à une organisation de traiter son information.

SQL : (Structured Query Language). Langage relationel de requêtes permettant d’in-terragir avec des bases de données.

Sucre syntaxique : (en anglais, syntactic sugar). Terme imaginé par Peter J. Landinpour des ajouts à la syntaxe d’un langage de programmation qui ne modifientpas son expressivité mais le rendent plus agréable à utiliser pour les humains.

Syntaxe : Notion désignant l’étude de la façon dont sont formées les propositions quielles-même forment ensuite des phrases. C’est un des aspects de la grammaire.

Sémantique : Notion désignant l’étude des signifiés. C’est un des aspects de la gram-maire.

TT-SQL : Le T-SQL (abréviation de Transaction-SQL), est une extension de SQL qui

permet entre autres la déclaration de variables, le contrôle des transactions,des erreurs et l’utilisation de fonctions SQL existantes. Les bases de donnéesMSSQL et Sybase utilisent des procédures en T-SQL.

TIC : (Technologies de l’Information et de la Communication). Acronyme désignantl’ensemble des technologies modernes permettant de gérer l’information et lacommunication au sein d’une organisation.

Trigger : Dans une base de données, un trigger est une procédure SQL qui déclencheune action lorsqu’un événement (INSERT, DELETE ou UPDATE) se produit.

UUCS : (Universal Character Set). Jeu de caractères universel, défini par la norme ISO

10646, aussi connue sous le nom d’Unicode.

UML (Unified Modeling Language). Langage normalisé par l’OMG début 1997, per-mettant de décrire une application en fonction des méthodes objet avec les-quelles elle a été construite.

Unicode : voir UCS.


BIBLIOGRAPHIE

UTF8 : (UCS Transformation Format sur 8 bits). UTF utilisant 8 bits pour coder lescaractères. voir UTF et encodage.

UTF : (UCS Transformation Format). Codage de l’UCS (ISO 10646) défini pour per-mettre son utilisation sur les réseaux.

XXP : (eXtreme Programing). Méthode de gestion de projets proposant un ensemble

de Bests Practices de développement.


Étude D’une Migration De Sybase Vers...

Documents

Transcript of Étude D’une Migration De Sybase Vers...