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

Transcription

1 C.C.I. DE LA HAUTE-SAVOIE 5 rue du 27ème BCA - BP Annecy CEDEX VIRGINIE QUESNAY Master OTSI Année 03/04 MÉMOIRE PROFESSIONNEL Étude d une migration de Sybase vers PostgreSQL Enseignant tuteur : Christian BRAESCH Maître de stage : Christophe POLLIER INSTITUT UNIVERSITAIRE PROFESSIONNALISÉ DE GÉNIE DES SYSTÈMES INDUSTRIELS Génie des systèmes d information

2 C.C.I. DE LA HAUTE-SAVOIE 5 rue du 27ème BCA - BP Annecy CEDEX VIRGINIE QUESNAY Master OTSI Année 03/04 MÉMOIRE PROFESSIONNEL Étude d une migration de Sybase vers PostgreSQL Maître de stage : Christophe POLLIER Enseignant tuteur : Christian BRAESCH

3 C.C.I. DE LA HAUTE-SAVOIE 5 rue du 27ème BCA - BP Annecy CEDEX VIRGINIE QUESNAY Master OTSI Année 03/04 RÉSUMÉ : Ce mémoire a été réalisé lors de mon stage de fin d études de Master à l IUP-GSI d Annecy le Vieux. Celui-ci s est déroulé au sein de la Chambre de Commerce et d Industrie de la Haute- Savoie du 8 mars au 25 juin Le but de ce stage était d étudier les possibilités de migration d une base de données de Sybase vers PostgreSQL. Ce mémoire est donc composé de trois parties : Le contexte du stage (l existant) ; La problématique de migration de base de données ; L illustration de cette problématique par le cas concret qu était mon étude. MOTS-CLEFS : PostgreSQL, Sybase, Perl, SQL, Migration, Traduction

4 Remerciements Je tiens tout d abord à remercier mon maître de stage et chef de projet Mr Christophe POLLIER, pour m avoir proposé un sujet aussi interressant et formateur et de m avoir guidée dans mon travail tout en me laissant un maximum de libertés et d initiatives. Je tiens également à remercier tous les collaborateurs de la CCI et tout particulièrement ceux du services TIC dans lequel j ai travaillé : Grégory BENOIST, Vincent AUGIER- MICOU, Laurence BOQUET et Laurent POSSETY pour leur accueil sympathique et chaleureux. Enfin, je remercie Christian BRAESCH, mon tuteur de l IUP GSI. Virginie QUESNAY - Master OTSI - 25 juin 2004 i

5 Table des matières Remerciements i Liste des illustrations v Liste des tableaux vi Liste des codes sources vii Introduction I L existant 2 1 Présentation de la C.C.I Son Histoire Son implantation Sa mission et ses objectifs Son organisation Les élus Les collaborateurs Le service TIC Ses missions Ses acteurs Sujet et Objectifs Présentation du contexte Le Système d Information de la CCI Caractéristiques techniques du Système d Information Présentation du projet La problématique Système d Information II Étude de la problématique de migration de base de données 11 4 Les approches possibles L approche "systématique" L approche "empirique" Combinaison de l approche "systématique" et de l approche "empirique" 15 Virginie QUESNAY - Master OTSI - 25 juin 2004 ii

6 TABLE DES MATIÈRES 5 Les outils et technologies applicables Utilisation d une interlangue Traduction "manuelle" Traduction automatique "monotraducteur" Utilisation d outils de "reverse-engenering" Les méthodes de gestion de projet informatique Méthode non formelle XP : extreme Programing RUP : Rational Unified Process DSDN (RAD) Combinaison des approches, des technologies et des méthodes Proposition d une démarche et de "bonnes pratiques" Déterminer la nature du problème Vérifier s il existe des solutions Effectuer la Migration Si une solution existante a été trouvée Si aucune solution existante ne convient III Application au contexte du stage 27 9 Les choix managériaux et technologiques La gestion de projet La démarche suivie Les technologies utilisées PostgreSQL RedHat Database Perl Le travail réalisé Évaluation de l état de la base de données existante Découverte du fonctionnement et des spécificités Quelques chiffres Étude des différentes techniques de migration Écriture d un traducteur en Perl L approche utilisée Fonctionnement de l application Estimation du travail restant à effectuer Méthode d estimation Réalisation des mesures Résultats de l estimation Bilan du stage Évaluation du travail réalisé Problèmes rencontrés Les problèmes techniques Virginie QUESNAY - Master OTSI - 25 juin 2004 iii

7 TABLE DES MATIÈRES Les problèmes liés à l organisation Les problèmes liés au manque de connaissance Conclusion Annexes 41 A Les CCI en France B La CCI de la Haute-Savoie C Les Chiffres de la CCI de la Haute-Savoie D Organigramme E La licence BSD (Berkeley Software Distribution) F Limitations de PostgreSQL G Phases pour réaliser l ensemble de la migration H Options pour l utilisation de sybase2postgresql I Documentation de sybase2postgresql J Problèmes spécifiques à chaque type d information à migrer K Mesures pour les indicateurs de complexité des procédures L Installation de modules supplémentaires pour Perl M Enregistrement d un fichier en UTF-8 sous Emacs N Webographie Bibliographie 74 Glossaire 76 Virginie QUESNAY - Master OTSI - 25 juin 2004 iv

8 Liste des illustrations 1.1 Nouveau bâtiment de la CCI dans le quartier Galbert Implantations de la C.C.I. en Haute-Savoie Organisation globale de la CCI Utilisation d une méthode systématique pour la traduction de textes Utilisation d une méthode empirique pour la traduction de textes Méthode de traduction avec une interlangue Méthode de traduction sans interlangue Méthode de traduction automatique Corrélation entre les approches, les technologies, les méthodes et la taille de l équipe Exemple de mauvaise corrélation entre les approches, les technologies, les méthodes et la taille de l équipe Exemple de bonne corrélation entre les approches, les technologies, les méthodes et la taille de l équipe A.1 Positionnement des CCI entre privé et public A.2 Une organisation pyramidale mais non hiérarchisée C.1 Répartition des ressources de la CCI ( Me) C.2 Part de l IATP dans le budget de la CCI C.3 Répartition des ressortissants par secteur d activité en D.1 Organigramme simplifié de la CCI de la Haute-Savoie K.1 Nombre de lignes par procédure K.2 Nombre d instructions SQL par procédure K.3 Nombre de structures if ou while par procédure K.4 Nombre de curseurs par procédure K.5 Répartition des procédures par type Virginie QUESNAY - Master OTSI - 25 juin 2004 v

9 Liste des tableaux 10.1 Dénombrement du contenu des bases de données Catégories de procédures Estimation du temps de développement par catégorie de procédures.. 37 C.1 Répartition de la taxe professionelle départementale F.1 Limitations of PostgreSQL Virginie QUESNAY - Master OTSI - 25 juin 2004 vi

10 Liste des codes sources H.1 Options de sybase2postgresql affichées grâce à l option -h H.2 Exemple de fichier de configuration de sybase2postgresql J.1 Création des fonctions suser_id() et suser_id(username) J.2 Création d une fonction de conversion de type (varchar vers int) J.3 Création d une fonction de conversion de type (smallint vers bit) L.1 Fichier de configuration du module MCPAN Virginie QUESNAY - Master OTSI - 25 juin 2004 vii

11 Introduction Afin de valider l année de master de la formation OTSI de l IUP GSI, chaque étudiant doit effectuer un stage de quatre mois en entreprise. Ce stage est une étape importante pour un étudiant, non seulement du point de vue de la scolarité, mais aussi d un point de vue personnel. La vie en entreprise est en effet nécessaire à la mise en pratique de l enseignement reçu à l IUP. Ce rapport présente l ensemble des travaux que j ai effectués au cours de mon stage au siège de la CCI (Chambre de Commerce et d Industrie) de la Haute Savoie à Annecy. Durant ces 16 semaines, l activité du stagiaire doit se partager entre une activité d apprentissage "fondamental" (on pourrait dire "théorique") et une activité d apprentissage "professionnel". L objectif de notre recherche est d arriver à une réflexion théorique sur la migration de bases de données en se basant sur une expérience concrète qu est la migration de bases sous Sybase vers PostgreSQL. Cette réflexion a pour but de faire ressortir les approches et solutions possibles pour la résolution de cette problématique. Ce mémoire s articulera donc autour de trois axes : Tout d abord, nous présenterons le cadre du stage, la CCI, le sujet proposé et la problématique posée. Ensuite, nous examinerons cette problématique et tenterons de lui apporter des solutions. Enfin, le reste du mémoire portera sur l ensemble du travail effectué : la méthodologie, les choix effectués, les résultats obtenus, leur analyse et les perspectives envisageables. Ce rapport, produit avec L A TEX 2ε, a été compilé le 25 juin Virginie QUESNAY - Master OTSI - 25 juin

12 Première partie L existant Virginie QUESNAY - Master OTSI - 25 juin

13 Chapitre 1 Présentation de la C.C.I. 1.1 Son Histoire C est en 1899 (soit 39 ans après l annexion de la Savoie par la France) qu un décret du Président Félix Faure institue une Chambre de Commerce à Annecy. Elle rejoint ainsi la vingtaine de Chambre de Commerces réparties sur l ensemble du territoire (voir Annexe A, page 42). À l origine, la Chambre naissante est hébergée au rez-de-chaussée de la mairie d Annecy puis dans l ancien évêché. En 1932, elle emménage dans des nouveaux locaux qu elle a fait construire rue du lac sur le terrain de l ancienne caserne du 50ème Régiment d Infanterie. Depuis juillet 2003, la Chambre de Commerce se trouve dans de nouveaux locaux (voir Annexe B, page 47), construits eux aussi à l emplacement d une ancienne caserne (celle du 27ème BCA). FIG. 1.1 Nouveau bâtiment de la CCI dans le quartier Galbert 1.2 Son implantation Le département regroupe 4 pôles économiques distincts, dotés chacun d une spécificité et d une problématique propre (Annecy, Genevois, Vallée de l Arve et Chablais). Dès 1992, la C.C.I. décide d ouvrir des antennes permanentes dans ces différent bassins d emploi. Aujourd hui, la C.C.I. dispose d un siège à Annecy et de trois antennes permanentes à Archamps, Marin et Scionzier. Virginie QUESNAY - Master OTSI - 25 juin

14 Présentation de la C.C.I. 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 commerçants, industriels et prestataires de services du département. Sa mission est d optimiser les performances des entreprises haut-savoyardes à travers une stratégie fondée sur la dynamique commerciale des entreprises et des territoires. Plusieurs actions phares concrétisent cet objectif : Faciliter la création et la reprise d entreprises Pérenniser les jeunes entreprises Accompagner les chefs d entreprises dans leur parcours d entrepreneur Préparer la transmission d entreprises Dynamiser l environnement local Gérer les infrastructures indispensables au développement des entreprises (Aéroport d Annecy Haute-Savoie, Gares routières d Annecy, Annemasse et Cluses, Centre Régional de Douanes et de Transports d Epagny) Pour l année 2004, la CCI a établi différents objectifs qui lui permettront de poursuivre la mise en œuvre de son Projet d Entreprise : Offrir à ses clients (les entreprises) des prestations déclinées dans un catalogue produits, Développer des projets avec ses partenaires 1 par un renforcement de la démarche partenariale, Organiser des évènements destinés aux entrepreneurs et aux entreprises. 1 Collectivités territoriales et entreprises participant à la création, la pérennisation, l animation et la transmission des entreprises. Virginie QUESNAY - Master OTSI - 25 juin

15 Présentation de la C.C.I. La création d un catalogue produits a également pour but de rendre la CCI beaucoup plus indépendante de l Impôt Additionnel à la Taxe Professionnelle (voir Annexe C, page 49) en vendant de nouveaux types de prestations à ses clients. 1.4 Son organisation Les élus FIG. 1.3 Organisation globale de la CCI Tous les 3 ans, les chefs d entreprises de la Haute-Savoie sont appelés à désigner, à l occasion des élections Consulaires leurs représentants à la CCI qui sont répartis en différents collèges : 34 membres titulaires : Ils forment l Assemblée Générale qui est l instance souveraine. Les présidents, les membres du bureau et les présidents de commissions, sont élus parmi eux et par eux. Ils votent le budget annuel qui est ensuite soumis à l approbation des ministères de tutelle. 33 membres associés : Au côté des 34 membres titulaires, ils sont désignés après chaque élection et ils participent aux Assemblées Générales avec une voix consultative. 106 délégués consulaires : Ils sont élus et représentent la CCI dans les 33 cantons du département. Virginie QUESNAY - Master OTSI - 25 juin

16 Présentation de la C.C.I Les collaborateurs Les employés de la chambre de commerce sont répartis en 13 services, plus l accueil (voir Annexe D, page 51) et répartis sur 6 "plateaux" (chaque plateau étant un étage du bâtiment). 1.5 Le service TIC Ses missions Le service TIC a en charge les choix stratégiques à court et moyen terme dans le domaine de l informatique et des nouvelles technologies de l information et de la communication. Les principaux axes d intervention sont : La surveillance et l intervention sur les équipements informatiques (serveurs, postes clients,...). La mise en place et la maintenance du réseau informatique. L identification, l évaluation et la quantification des besoins exprimés par les services. La proposition de solutions adaptées (techniques, logiciels, formations) en conservant au maximum une cohérence avec le système d information existant. La maintenance des applications propres à la CCI de la Haute-Savoie. La veille technologique au sens large dans le secteur de l informatique et des TIC. Les formations spécifiques à la CCI 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) Virginie QUESNAY - Master OTSI - 25 juin

17 Chapitre 2 Sujet et Objectifs 2.1 Présentation du contexte Le Système d Information de la CCI La Chambre de Commerce et d industrie de la Haute-Savoie s est dotée, au fur et à mesure de sa croissance de différents outils informatiques. Certains de ces outils sont des applications courantes et ont un fonctionnement "imposé" (Xerox Docushare, Microsoft Exchange,...). D autres applications sont quant à elles développées au sein de la CCI et continuent donc d évoluer parallèlement aux besoins. L application la plus importante est BEE (Base Économique Événementielle), une application métier développée sous 4D 1 associée à une base de données Sybase. C est un 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 : contact avec un ressortissant, courrier postal et électronique, contact téléphonique ou Caractéristiques techniques du Système d Information Le serveur Sybase contient plusieurs bases de données utilisées par les différentes applications de la CCI : base cci : Elle stocke les données concernant la CRM (BEE), la taxe d apprentissage, les formations et l aéroport (statistiques des vols). base consulaire : Elle stocke les fichiers "officiels" des entreprises ainsi que les formalités d export (ATA-VISA). base cfe : Elle stocke les données du centre de formalités des entreprises. Elle n est utilisée que pour conserver l historique car l application traitant ce type de données est maintenant nationale. base personnel : Elle stocke les données des Ressources Humaines (principalement utilisée pour le trombinoscope et la gestion des entretiens annuels). Il y a actuellement 3 serveurs Sybase 2 : 2 serveurs en production (1 serveur principal 1 4D (4ème Dimension) est un atelier logiciel de développement et de déploiement d applications multipostes crossplate-forme. 2 Sybase version /P en production et version en test Virginie QUESNAY - Master OTSI - 25 juin

18 Sujet et Objectifs et 1 serveur avec une réplication 3 quotidienne) et 1 serveur en test. 2.2 Présentation du projet Les applications métier de la CCI s appuient, comme nous l avons précédemment indiqué (voir 2.1.2, page 7), sur différentes bases de données fonctionnant sur un serveur Sybase. La version de Sybase utilisée étant relativement ancienne, la CCI doit envisager une évolution importante, que ce soit la migration vers une version plus récente de Sybase ou vers un autre moteur de base de données. Les collaborateurs de la CCI utilisent déjà avec succès différents logiciels libres. Il a donc été décidé d évaluer l opportunité d effectuer cette migration vers une base de données libre. Cependant, les applications reposant sur cette base de données étant critiques pour le fonctionnement de la CCI, une migration de cette ampleur ne peut se décider à la légère. Suite à ces différentes réflexions, il a été décidé d effectuer une étude poussée afin de déterminer si cette migration était possible. Cette étude devait donc porter sur les points suivants : Étude des différentes techniques de migration ; Choix de la méthodologie à employer ; Migration des structures (tables, séquences, index, vues) ; Migration des données ; Migration des traitements (Triggers, Procédures) ; Mesure de l efficacité du nouveau moteur de base de données. 3 Le serveur de réplication est un serveur accessible depuis les applications clientes et dont le but est d éviter les surcharges du serveur principal (pour ne pas trop ralentir le serveur principal avec de grosses requêtes ne nécessitant pas des données ayant moins de 24 heures, celles-ci sont réalisées sur le serveur de réplication). Virginie QUESNAY - Master OTSI - 25 juin

19 Chapitre 3 La problématique Système d Information Le problème de migration d un SGBD à un autre, lorsqu on y regarde d un peu plus prè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 finalement assez logique car les langages dits artificiels possèdent un grand nombre de caractéristiques communes avec les langages naturels. Les travaux de Noam Chomsky [11] sur l approche de la linguistique générative ont fait ressortir des similitudes entre les langages naturels et les langages informatiques. On peut en effet y trouver des problématiques liées au lexique (vocabulaire), à la syntaxe et à la sémantique. Ce rapprochement est d autant plus évident lorsqu on se base sur les travaux de recherche faits sur les compilateurs informatiques [12] qui utilisent de façon importante les travaux effectués en linguistique et sont des traducteurs (ils traduisent un langage écrit par un humain vers un langage compréhensible par un ordinateur). Bien évidemment, la complexité des problèmes liés aux langages informatiques est moindre que celle liée à l étude des langages naturels car certains aspects de la linguistique comme l étude du langage parlé (phonétique, phonologie) ne sont pas présents et que le lexique employé est généralement moins conséquent. Cependant, on peut tout de même retrouver, dans l étude des langages informatiques, certains des problèmes les plus complexes de la linguistique et notamment les problèmes de pragmatique (variation du sens en fonction du contexte), voire même se trouver confronté à des situations où le contexte n est pas exprimé explicitement (il dépend de l état du système ou d autres données accédées directement en interne par le SGBD par exemple). De plus, l écriture dans un langage informatique est normalement plus rigoureuse, mais, tout comme les langages naturels, les langages artificiels, assez simples lors de leur création, ont évolué en gardant trace de leur histoire (on peut par exemple utiliser plusieurs syntaxes ou un vocabulaire totalement différent pour effectuer une même action). Enfin, même si, comme nous l avons dit, la problématique de la traduction dans le cadre des langages artificiels est beaucoup plus simple que pour les langages naturels, on peut rappeler que, pour cette dernière, de nombreuses recherches sont encore en cours. La traduction automatique est un problème qui a longtemps été sous-estimé Virginie QUESNAY - Master OTSI - 25 juin

20 La problématique Système d Information mais qui est en fait l un des plus délicats à effectuer pour un ordinateur. Aux phases lexicales et syntaxiques, à peu près maîtrisées, s ajoutent une analyse sémantique, puis pragmatique, qui tentent de déterminer le sens particulier d un mot, dans le contexte où il apparaît. Le contexte lui-même pouvant s étendre à l ensemble du texte traduit. Nous allons donc étudier les différentes approches et méthodologies issues de la linguistique informatique pour mener à bien un travail de traduction afin de déterminer quelles solutions peuvent être envisagées lorsqu on se trouve confronté à un problème de migration de bases de données. Virginie QUESNAY - Master OTSI - 25 juin

21 Deuxième partie Étude de la problématique de migration de base de données Virginie QUESNAY - Master OTSI - 25 juin

22 Chapitre 4 Les approches possibles 4.1 L approche "systématique" Comme la migration d un gestionnaire de base de données à un autre est assez semblable à la traduction d un langage (naturel ou artificiel) vers un autre, il est possible d utiliser une démarche proche de celles employées en ingénierie linguistique. FIG. 4.1 Utilisation d une méthode systématique pour la traduction de textes Virginie QUESNAY - Master OTSI - 25 juin

23 Les approches possibles Cette démarche passe tout d abord par l élaboration d un corpus [13]. Dans notre cas, le corpus créé peut être composé des définitions du langage utilisé par le SGBD, généralement fournies dans les documentations techniques, et complétées par des exemples de cas complexes. Lorsque le corpus est assez complet, il est alors possible d en extraire le lexique, la syntaxe et la sémantique du langage. Dans notre cas, nous cherchons à réaliser une traduction d un langage vers un autre, il faut donc effectuer ces opérations pour les deux langages afin de pouvoir les comparer et déterminer quels sont les éléments qui les différencient et obtenir des règles de traduction. Enfin, il est possible d appliquer ces règles à un document écrit dans un des langages pour obtenir sa traduction dans l autre. Lorsqu on applique une approche systématique au traitement informatique d une migration, on pourra assimiler cette démarche à une approche descendante (également appelée approche top-down ). Cette approche est à privilégier lorsqu on se trouve confronté à la traduction d un grand nombre de documents très hétérogènes ou à de nouveaux types de documents. Cette approche est longue à mettre à place, non seulement à cause de la nécessité de rassembler un corpus de documents suffisamment vaste pour couvrir tous les aspects d un langage, mais aussi par la complexité d extraction du lexique et de la grammaire de ce corpus. Cependant, dans les cas complexes, on préférera ce type de cheminement car il permet d obtenir un traducteur "générique", capable de faire face à un nouveau document sans rencontrer de problèmes. Grâce à cela, il est également possible d obtenir assez facilement un traducteur pour un langage "proche" (pour les langages informatiques comme pour les langages naturels, il existe des "familles de langues" 1 qui ont les mêmes origines et donc un grand nombre de règles communes. Suite à ces réflexions, on peut voir que l approche systématique est destinée à réaliser un traducteur complet et flexible. 4.2 L approche "empirique" L approche empirique, contrairement à l approche systématique, se base sur le document ou l ensemble de documents qui doivent être traduits et non sur un ensemble de documents de référence. Cette démarche passe tout d abord par la traduction "manuelle" de parties du document pour déterminer les règles de traduction. On traduit ainsi des parties dont le lexique, la sémantique et la syntaxe sont différents jusqu à obtenir des règles permettant de traiter l ensemble du document. Une fois ces règles écrites, il est alors possible de les appliquer au document afin d en obtenir une traduction complète. 1 Pour les langages naturels, on peut par exemple citer le français, l espagnol et l italien qui sont des langues latines. Pour l informatique, on peut citer le C++ et la java qui ont des origines dans le C ou Sybase et MS-SQL qui sont partis tous les deux d une ancienne version de Sybase Virginie QUESNAY - Master OTSI - 25 juin

24 Les approches possibles FIG. 4.2 Utilisation d une méthode empirique pour la traduction de textes Ici, cette approche peut être assimilée à un approche montante (également appelée bottom-up ) car on part de "problèmes spécifiques" à un document jusqu à obtenir un traducteur par agrégation de ces problèmes. Si on possède suffisamment de documents différents et qu ils couvrent tous les cas existants, on peut, par empirisme, obtenir un traducteur aussi complet que celui qu on obtiendrait par une approche systématique mais cela nécessiterait une quantité de travail bien supérieure. De plus, la complexité non linéaire de cette approche est un problème car chaque "cas particulier" résolu risque de rentrer en conflit avec les cas résolus précédemment ce qui implique que plus le nombre de règles de traduction augmente, plus le nombre de contradictions possibles augmente. En fait, cette approche n est rapide à mettre en place que si on a un nombre limité de "problèmes" de traduction et que l on veut obtenir un traducteur pour un faible nombre de documents (ou si ces documents utilisent exactement les mêmes règles de traduction). Cependant, cette démarche est limitée par le fait que l écriture des règles passe par une phase de traduction manuelle. Si on doit traduire des documents très différents ou si les schémas linguistiques ne se trouvent pas assez souvent répétés, l ensemble du travail de traduction sera finalement réalisé manuellement. Par exemple, si on se trouve dans le cas d un document trop court, chaque élément traduit manuellement créera une nouvelle règle mais celle-ci ne sera utilisée que pour cet élément. Comme les approches de type bottom-up ont une relation très forte avec l existant, elles sont beaucoup plus adaptées dans le cas où on ne veut pas faire un outil généraliste mais spécifique à une situation. L approche empirique sera donc réservée à la Virginie QUESNAY - Master OTSI - 25 juin

25 Les approches possibles résolution de problèmes ponctuels et à une traduction unidirectionelle (car les problèmes liés à la traduction ne sont pas forcément bijectifs). 4.3 Combinaison de l approche "systématique" et de l approche "empirique" Cette approche n est généralement pas possible à mettre en place car, si elle apporte une bien plus grande fiabilité (il y a de grandes chances qu aucun cas "spécifique" et qu aucune exception ne soit oubliés), apporte également une bien plus grande complexité et un temps de mise en œuvre beaucoup plus grand car il faut effectuer chacune des deux méthodes puis mettre en relation les résultats obtenus pour obtenir un seul ensemble de règles de traduction. La combinaison de modules en vue d obtenir une solution cohérente est d ailleurs, à elle seule, un sujet complexe nécessitant des études poussées [14] car l efficacité de l analyse lexicale dépend directement dont les différentes parties de l analyseur fonctionnent en corrélation et non en opposition. Virginie QUESNAY - Master OTSI - 25 juin

26 Chapitre 5 Les outils et technologies applicables Les deux approches décrites précédemment (voir Chapitre 4, page 12) détaillent la démarche qui peut être suivie afin d obtenir un traducteur. Leur mise en œuvre nécessite des outils dont une partie va être présentée ci-dessous. 5.1 Utilisation d une interlangue Les interlangues (ou langages pivots) sont fréquemment utilisées dans le domaine de la traduction automatique. Une interlangue est une langue artificielle qui sert d intermédaire entre une langue source et une langue cible. FIG. 5.1 Méthode de traduction avec une interlangue Virginie QUESNAY - Master OTSI - 25 juin

27 Les outils et technologies applicables Les interlangues sont généralement utilisées lorsqu on doit effectuer des traductions entre plusieurs langages. Un grand nombre de travaux de recherche en linguistique se sont penchés sur les interlangues. On peut notamment parler du projet Traduction de Langues Distribuée (en anglais : Distributed Language Translation, en espéranto Distribuita Lingvo-Tradukado, en abrégé DLT) qui était un projet de traduction de langues de la Commission européenne 1. Le projet avait pour but la traduction automatique depuis et vers 12 langues européennes par le biais d une interlangue interne basée sur l Espéranto, qu on nommait ILO (Internacia Lingvo = Langue Internationale). En informatique, on utilise ce type d outil dans la mise en place d EAI. Dans ce cas, l EAI se sert d une interlangue (par exemple le XML) et se sert de traducteurs, appelés connecteurs, pour faire communiquer des systèmes hétérogènes entre eux. Les interlangues sont habituellement utilisées avec une approche de type systématique car elles sont destinées à obtenir des traducteurs généralistes et assez exhaustifs entre plusieurs langages. Elles n ont d ailleurs d intérêt que si on est en présence de plus de trois langages. FIG. 5.2 Méthode de traduction sans interlangue 1 Dans la sphère de la traduction technique (ex : entre le français et l anglais, avec une traduction intermédiaire en ILO -Internacia LingvO = Langue Internationale- et retour) on atteignait 95% de précision sur les phrases traduites. Dans la sphère de textes très généraux (ex : comptes-rendus d assemblées de l UNESCO) la précision de la traduction se situait entre 50 et 60 %. Virginie QUESNAY - Master OTSI - 25 juin

28 Les outils et technologies applicables En effet, lorsqu on veut effectuer une traduction entre deux langages, le passage par une interlangue nécessite plus de travail (deux traducteurs au lieu d un), mais, si on dépasse trois langages, on peut voir que l utilisation d une interlangue (voir Figure 5.1, page 16) permet de ne créer qu un seul connecteur lors de l ajout d un quatrième langage alors qu il faut trois connecteurs lorsqu on n utilise pas d interlangue (voir Figure 5.2, page 17). Cette solution, est donc très coûteuse pour un petit nombre de langages alors qu elle est beaucoup plus économique lorsqu on dépasse le seuil de trois langues. C est pourquoi, dans le cadre d une migration entre "seulement" deux systèmes, il est assez improbable que cette méthode soit la plus intéressante à utiliser (à moins de déjà disposer de traducteurs fiables vers une même interlangue). 5.2 Traduction "manuelle" La traduction manuelle, comme son nom l indique, ne fait appel à aucun mécanisme d automatisation. Dans ce cas, la traduction de tout le document est effectuée par un traducteur humain. Bien que cela ne soit généralement pas formalisé, les traducteurs utilisent habituellement une approche de type empirique car, lorsqu ils rencontrent un problème et qu ils le résolvent une première fois, ils sauront comment le résoudre s ils s y trouvent confrontés une seconde fois. 5.3 Traduction automatique "monotraducteur" Aussi bien dans le cadre d une approche systématique que par l application d une approche empirique, on obtient un ensemble de règles de traduction qui permettent ensuite d effectuer automatiquement la traduction de documents. La traduction est réalisée par un logiciel chargé d appliquer les règles de traduction de façon systématique. Mais, avant d utiliser un logiciel de traduction automatique, il faut avoir préalablement définit ces règles et cela est complexe et nécessite un fort investissement. FIG. 5.3 Méthode de traduction automatique Virginie QUESNAY - Master OTSI - 25 juin

29 Les outils et technologies applicables 5.4 Utilisation d outils de "reverse-engenering" Généralement basés sur une approche systématique, ce sont des outils dont le fonctionnement est proche de celui de l interlangue. Toutefois, le langage utilisé est souvent proche de l UML et ce sont des outils intégrés et fournis "tels-quels". Ces outils vendus ou mis à disposition par des entreprises d édition de logiciels, ce sont des solutions de type "clefs en main". Cependant, comme l import ou l export depuis ou vers un SGBD se fait par un traducteur spécifique, il faut que les connecteurs existent (malheureusement si on utilise un ou des systèmes peu courants, il est assez difficile de trouver un atelier de reverse-engenering proposant les traducteurs nécessaires). Virginie QUESNAY - Master OTSI - 25 juin

30 Chapitre 6 Les méthodes de gestion de projet informatique Comme tout autre projet informatique, et même généralement comme tout projet, la migration de bases de données doit être programmée, suivie, 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 du projet en dépendra fortement. 6.1 Méthode non formelle Dans le cadre de projets avec peu de ressources (1 ou deux personnes au maximum), l affectation de temps à la gestion de projet peut entraîner des surcoûts importants. Comme le nombre de personnel est très faible, leur coordination et leur affectation ne pose pas de problème et l ordonnancement des tâches est très simple (on ne peut faire qu une seule chose à la fois). De plus, des comptes-rendus réguliers au client lors de réunions d avancement et à la hiérarchie lors de réunions de service ou de façon informelle, permettent de piloter de façon assez fiable le projet et de réagir rapidement en cas de dérive. 6.2 XP : extreme Programing XP propose un ensemble de "Bests Practices" de développement (travail en équipes, transfert de compétences,...), c est une méthode itérative, simple à mettre en œuvre destinée à des équipes de petite taille composées de membres autonomes, c est une méthode très réactive mais qui demande une forte implication du client. Gestion des livraisons : L équipe fournit des livraisons fréquentes au client. Le contenu de ces livraisons est décidé par le client lui-même, à partir des estimations fournies par les développeurs. Gestion des itérations : Les livraisons sont réalisées en une suite d itérations de 2 semaines environ, au sein desquelles le projet est géré à un niveau de détail plus fin. Virginie QUESNAY - Master OTSI - 25 juin

31 Les méthodes de gestion de projet informatique Suivi du projet : L avancement du projet est mesuré de manière concrète par une batterie de tests de recette automatiques. Le rythme de progression est réévalué à chaque itération, et le plan de développement lui-même est revu fréquemment pour tirer parti de l expérience acquise au cours du projet. Qualité du design et du code : Des pratiques strictes permettent de garder une vitesse de développement élevée tout au long du projet, tout en gardant une ouverture maximale au changement. La conception reste toujours le plus simple possible, le code est nettoyé en permanence et des tests unitaires de non-régression sont écrits pour chaque classe. Travail en équipe : L équipe travaille réellement en équipe. Le code est partagé par tous, les développeurs travaillent systématiquement en binômes, et l intégration est quasiment continue." 6.3 RUP : Rational Unified Process RUP est à la fois une méthodologie et un outil prêt à l emploi (documents types partagés dans un référentiel Web). C est est un processus de développement logiciel itératif et incrémental, centré sur l architecture, conduit par les cas d utilisation et piloté par les risques. Il est destiné aux projets nécessitant un grand nombre de ressources humaines. Il n est d ailleurs utilisable que si une personne est affectée à temps complet (ou presque) à la gestion de projet car il y a beaucoup d étapes à suivre et de documents à réaliser. De plus, il faut commencer par adapter RUP à son projet, ce qui le rend intéressant à utiliser uniquement dans le cadre d une équipe qui travaille toujours sur le même type de projet et toujours avec RUP. RUP présente un certain nombre de caractéristiques, il est : Itératif et incrémental : le projet est découpé en itérations de courte durée (environ 1 mois) qui permettent de mieux suivre l avancement global. A la fin de chaque itération, une partie exécutable du système final est produite, de façon incrémentale. Directif : Spécifie le dialogue entre les différents intervenants du projet (les livrables, les plannings, les prototypes,...) et propose des modèles de documents, et des canevas pour des projets types. Centré sur l architecture : tout système complexe doit être décomposé en parties modulaires afin de garantir une maintenance et une évolution facilitées. Cette architecture (fonctionnelle, logique, matérielle, etc.) doit être modélisée en UML et pas seulement documentée en texte. Piloté par les risques : les risques majeurs du projet doivent être identifiés au plus tôt mais surtout levés le plus rapidement possible. Les mesures à prendre dans ce cadre déterminent l ordre des itérations. Conduit par les cas d utilisation : le projet est mené en tenant compte des besoins et des exigences des utilisateurs. Les cas d utilisation du futur système sont identifiés, décrits avec précision et priorisés. Virginie QUESNAY - Master OTSI - 25 juin

32 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 principe fondamental : 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 dans un environnement de développement rapide (RAD). DSDM fournit un canevas couvrant l ensemble du cycle de développement et un grand nombre de principes à suivre afin d assurer le succès du projet. Virginie QUESNAY - Master OTSI - 25 juin

33 Chapitre 7 Combinaison des approches, des technologies et des méthodes FIG. 7.1 Corrélation entre les approches, les technologies, les méthodes et la taille de l é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. Virginie QUESNAY - Master OTSI - 25 juin

34 Combinaison des approches, des technologies et des méthodes FIG. 7.2 Exemple de mauvaise corrélation entre les approches, les technologies, les méthodes et la taille de l équipe Par exemple, un projet suivant une approche systématique, pour réaliser un outil basé sur une interlangue, avec une gestion de projet non formelle et une grosse équipe a de grande chance de foncer droit dans le mur. FIG. 7.3 Exemple de bonne corrélation entre les approches, les technologies, les méthodes et la taille de l équipe À l opposé, un projet de traduction automatique monotraducteur, employant une approche empirique, et gérant une équipe projet grâce à une méthode non formelle démontre une vision cohérente du projet. La cohérence de cet ensemble de choix ne fera donc pas obstacle au bon déroulement du projet. Lors du lancement du projet, on veillera donc tout particulièrement à ce que les différents éléments (même si chacun pris séparément semble être le meilleur choix) puissent être utilisés ensembles. Virginie QUESNAY - Master OTSI - 25 juin

35 Chapitre 8 Proposition d une démarche et de "bonnes pratiques" Lors d un projet de migration de base de données comme dans tout autre projet informatique, il n existe bien évidemment pas de "solution miracle" pour réussir à coup sûr mais il est possible de suivre une démarche et des bonnes pratiques (appelée aussi best practices) qui permettront d augmenter les chances de réussite. Cette démarche peut être découpée en trois grandes étapes. Après chacune d elle, il est nécessaire de déterminer si le projet de migration est réaliste et réalisable afin de ne pas effectuer d investissements inutiles. 8.1 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, traitements ou les trois)? Une migration partielle est bien entendu plus simple à réaliser. De quelles "familles" sont la base de données origine et destination? Si les bases de données sont de la même "famille" (par exemple Sybase et MS-SQL ou deux versions d une même base de données), une migration nécessitera beaucoup moins de travail que pour des bases de données d origine totalement différente. 8.2 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 évidemment déterminer si les technologies utilisées sont applicables mais aussi si leur coût est acceptable. Les outils de migration les plus courants sont basés sur le principe de reverse-engenering. Ils sont peu nombreux et particulièrement liés à une seule famille de base de données (le nombre de connecteurs vers d autres bases de données est généralement limité). On peut également trouver des solutions entièrement externalisées : une société de Virginie QUESNAY - Master OTSI - 25 juin

36 Proposition d une démarche et de "bonnes pratiques" services se charge d effectuer toute la migration grâce à des outils qu elle développe elle-même. 8.3 Effectuer la Migration 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 on utilise) et que son prix est acceptable, la solution doit être utilisée en n oubliant pas de continuer à 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 de vérifier que tout s est bien passé et affiner le paramètrage de la base de données afin d en améliorer les performances Si aucune solution existante ne convient Si aucune solution existante n est adaptée à notre problème et que l on souhaite poursuivre le projet, il convient de déterminer quelle approche et quelle solution doivent être adoptées (en fonction de la nature de la migration et du type de traducteur que l on souhaite obtenir). Virginie QUESNAY - Master OTSI - 25 juin

37 Troisième partie Application au contexte du stage Virginie QUESNAY - Master OTSI - 25 juin

38 Chapitre 9 Les choix managériaux et technologiques 9.1 La gestion de projet Ce stage était un projet informatique "comme un autre". On peut donc supposer que l utilisation d une méthodologie de gestion de projet informatique aurait été logique. Cependant, l utilisation d une méthode "stricte" était en fait peu adaptée à ce cas pour différents motifs : Le retour d expérience sur ce genre de projet est assez rare (aussi bien au niveau personnel que dans les documentations disponibles), il n y a donc pas d indications sur le fonctionnement d anciens projets du même type. Dans le cadre de projets menés par une seule personne (comme c était le cas ici), la mise en place de mécanismes complets de management de projet peut s avérer complexe et nécessiter plus de temps quelle n en fait gagner. Nous avons donc adopté une gestion de projet minimale, essentiellement basée sur les comptes-rendus hebdomadaires lors des réunions de service. Enfin, comme l approche employée est de type empirique, son évolution est par essence difficile à prévoir (car on traite les problèmes au fur et à mesure de leur découverte). Une prévision trop précise et un planning décidé trop tôt seraient remis en 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 les chapitres suivants : Recherche et évaluation des solutions existantes (voir Section 10.2, page 33) ; Choix d une solution (voir Section 9.3, page 29) ; Mise en œuvre de la solution (voir Section 10.3, page 33) ; Évaluation du travail à venir (voir Section 10.4, page 34). Virginie QUESNAY - Master OTSI - 25 juin

39 Les choix managériaux et technologiques 9.3 Les technologies utilisées PostgreSQL Présentation PostgreSQL 1 est un Système de Gestion de Base de Données Relationnelle (SGBDR) open source 2. Il a été initialement développé à l Université de Berkeley sous le nom de Ingres ( ). Il a été amélioré régulièrement au cours de ses premières années par les sociétés Rational Technologies et Ingres Corp.. Ces sociétés ont été rachetées par la société nommée maintenant Informix. Le projet a ensuite continué indépendamment à Berkeley sous le nom de Postgres ( ). Après l apparition des premières normes du langage SQL, le langage de requête de Postgres a été remplacé par le langage SQL. En 1995, le projet a ensuite été repris par des développeurs indépendants de l Université de Berkeley et renommé Postgres95. Là, le projet s est étoffé et transformé à partir de 1997 en PostgreSQL lorsque l ensemble des fonctionnalités SQL a été intégré au serveur. Avantages PostgreSQL est un logiciel libre, il possède donc tous les avantages qui en découlent, entre autre : La gratuité ; Le nombre de déploiements 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çon autonome).... PostgreSQL respecte la quasi totalité de la norme SQL et propose la plupart des fonctionnalités présentes dans les autres "grands" SGBD (gestion des transactions, procédures stockées, gestion des droits d accès aux données,...). Dans le monde du logiciel libre, (mis à part SAPDB qui est actuellement en pleine mutation due à son rapprochement de MySQL) PostgreSQL est certainement actuellement le seul SGBD permettant de gérer des bases de données à gros volume et avec un grand nombre de connexions notamment grâce à son haut degré de scalabilité. Les concurrents libres de PostgreSQL ne sont pas aussi aboutis, tant pour la tenue en charge que pour le nombre de fonctionnalités disponibles, c est pourquoi le choix en terme de bases de données assez limité. Inconvénients PosgreSQL n est pas disponible nativement pour Windows, il utilise une couche d émulation (CygWin). Seules les prochaines versions à partir de la numéro 8 (à venir) seront développées pour Windows. 1 Version utilisée : RH 2 Sous licence BSD (voir Annexe E, page 52) Virginie QUESNAY - Master OTSI - 25 juin

40 Les choix managériaux et technologiques PostgreSQL, s il est connu pour sa robustesse, a également la réputation d être relativement lent (même si chaque nouvelle version amène des progrès notables). Cela est dû au grand nombre de mécanismes de préservation et de protection des données qui sont activés par défaut mais qui peuvent pour la plupart être désactivés après une étude détaillée des besoins RedHat Database Présentation RedHat Database 3 est une version de PostgreSQL optimisée pour fonctionner avec un serveur Red Hat Linux 4 et qui bénéficie du back-portage des améliorations apparues avec la version 7.4. Avantages Rhdb 5 est librement téléchargeable sur le serveur ftp de RedHat. Il est également possible 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 Hat Enterprise Linux ES". En cas de problèmes non spécifiques à la base de données, il est donc possible de profiter du contrat de support souscrit. Inconvénients Red Hat n a pas une politique très claire en ce qui concerne le support de ce produit. Certes, une équipe Red Hat travaille en permanence sur ce projet et une offre de services est proposée mais le site de vente de RedHat reste peu clair sur ses avantages : le contenu de l offre n est pas très détaillé et la version actuellement proposée est la alors la version 3 existe depuis plusieurs mois Perl Présentation Crée en 1986 par Larry Wall, Perl (Practical Extraction and Report Language) est un langage de programmation interprété (avec une phase interne de pré-compilation). Sa syntaxe dérive des scripts shell, et d autres langages comme C, awk, sed. 3 Aussi appelé : PostgreSQL - Red Hat Edition ou RhDb 4 version 9 ou Fedora Core 1 5 Version utilisée : 3.0 (sortie le 16 janvier 2004) 6 optimisé Red Hat Linux 7.1 et PostgreSQL Virginie QUESNAY - Master OTSI - 25 juin

41 Les choix managériaux et technologiques Avantages Pour tous ceux qui connaissent ces langages, notamment pour ceux qui viennent du monde Unix, Perl est relativement facile à apprendre. Perl a été conçu selon un concept de langage naturel : on écrit du Perl comme on pense. Cette caractéristique de Perl se retrouve dans son slogan "there is more than one way to do it". La puissance de Perl pour la manipulation de chaînes de caractères et de fichiers lui donne des atouts considérables pour écrire des applications nécessitant des expressions régulières, par exemple le traitement de texte avec la création de pages à la volée. L allocation de mémoire est prise en charge par l interpréteur, il n y a donc pas de gestion de mémoire, pas de limite de buffer. Perl existe depuis plus de 15 ans, beaucoup de bibliothèques et de modules d extensions sont donc déjà disponibles. L application première de Perl est l administration Unix (manipulation de textes, de fichiers et de processus), une personne ayant ce type de compétences aura donc certainement des connaissances du langage Perl et pourra ainsi reprendre, maintenir et modifier le code source si cela est nécessaire. Inconvénients Perl possède certains inconvénients notamment des soucis de sécurité intrinsèques à son statut de langage interprété. Toutefois, il existe un mode "secure" qui vérifie pour chaque variable si elle est sécurisée ou non. Comme ce mode ralentit l application, il est réservé au débuggage. Perl n est pas efficace pour le calcul scientifique. C est un langage très permissif qui laisse les programmeurs libres de coder selon leurs méthodes. Cependant, la diversité des méthodes de codage qui est un gros avantage pour la simplicité d apprentissage du Perl est aussi un des principaux inconvénients du langage : il est souvent difficile de reprendre le code d un autre développeur, surtout s il n est pas correctement documenté. Virginie QUESNAY - Master OTSI - 25 juin

42 Chapitre 10 Le travail réalisé 10.1 Évaluation de l état de la base de données existante Découverte du fonctionnement et des spécificités Avant de pouvoir commencer tout autre travail, il faut commencer par se familiariser avec l environnement de travail. Ici, les principales applications à connaître sont : BEE : l application de CRM ; Sybase et les outils qui permettent de s y connecter (DbDK et DBArtisan) ; Les bases de données présentes sur le serveur Sybase Quelques chiffres Pour réaliser la migration, il a tout d abord fallu étudier les bases un peu plus précisément afin de déterminer dans quelles catégories les classer (base principalement axée sur les données, sur les structures ou sur les traitements) et quel type d outil utiliser. cci cfe consulaire personnel TOTAL Groups Indexes Segments Tables Triggers User messages Users Views Procedures Nb de lignes de code TAB Dénombrement du contenu des bases de données De plus, il faut savoir que les plus grosses tables approchent les enregistrements et que le volume actuel des bases de données est d environ 18 Go. Grâce à ces information, il est facile de s apercevoir que la base cci, en plus d être la plus importante au niveau utilisation est également celle contenant le plus d éléments à migrer. 1 nombre de lignes de code de la totalité des procédures (commentaires compris) Virginie QUESNAY - Master OTSI - 25 juin

43 Le travail réalisé Durant le projet, c est donc sur cette base que doit se focaliser la majorité du travail Étude des différentes techniques de migration Toute étude doit commencer par l inventaire des solutions existantes de manière à ne pas se lancer dans un développement coûteux si un produit répond déjà à nos attentes. La première piste explorée a été celle du site internet de PostgreSQL qui répertorie une large gamme de moyens pour migrer vers ce système. On peut trouver dans cette catégorie nommée "Converting from other Databases to PostgreSQL", des outils et des conseils pour transformer des bases au format Dbase, FileMaker Pro, Interbase, MS-Access, MySQL et Oracle. En ce qui concerne Sybase, on peut utiliser les conseils donnés pour MS-SQL mais ceux-ci sont très pauvres et ne donnent que quelques idées pour réaliser une migration manuelle. La seconde possibilité pour trouver des outils de migration était de rechercher des outils ou des solutions "clefs en main" pour la migration de Sybase vers PostgreSQL. Force est de constater que même s il existe des outils traitant chacune des bases de données, il n en existe pas qui posséde des connecteurs pour les deux systèmes. Aucune solution n existant pour cette migration, la seule méthode possible est de réaliser soi-même un outil qui effectuera cette transformation Écriture d un traducteur en Perl L approche utilisée En vu de structurer la démarche du projet, la solution la plus simple était de le découper en plusieurs phases. Les choix Nous avons tout d abord du déterminer l approche, la technologie, la méthodologie et l équipe employés. Ces choix furent assez rapidement faits : Aucun salarié de la CCI n étant disponible pour ce projet, l équipe ne pouvait être composée que d une seule personne. Après avoir effectué des recherches sur les solutions existantes, il est apparu qu aucun outil ne permettait de réaliser une telle migration (voir 10.2, page 33) et que très peu d information était disponible pour utiliser une approche systématique. C est donc l utilisation d une méthode empirique qui s est imposée. La technologie utilisée devait permettre de reproduire cette migration même si quelques modifications apparaissaient dans le base (ce qui exclut une traduction manuelle) mais devait être compatible avec les choix déjà faits et le délai imparti. La technique d un traducteur automatique a donc été retenue. Virginie QUESNAY - Master OTSI - 25 juin

44 Le travail réalisé Enfin, ayant très peu de ressources à gérer et beaucoup d autonomie quant au fonctionnement du traducteur, une méthodologie de gestion de projet "lourde" n aurait apporté aucun bénéfice par rapport à l utilisation d une méthode non formelle. L organisation Le choix d une approche de type empirique ne dispense pas de structurer la démarche du projet. C est pourquoi chaque type d élément de la base (tables, index, données,...) a été traité indépendamment. En outre, le fonctionnement même des bases de données a imposé un certain ordre de traitement. Il faut réaliser tout d abord la transformation de la structure puis des données et enfin des traitements. Les itérations Pour chacun des types d élément, une approche empirique peut se traduire par une suite d itérations comprenant : La tentative d utiliser le Script SQL "tel-quel" ; La recherche des problèmes empêchant le bon fonctionnement ; L écriture en Perl d un programme permettant de régler le problème. Une fois toutes les itérations effectuées pour tous les types d éléments, on dispose d un programme Perl permettant de résoudre tous les problèmes et d effectuer la migration Fonctionnement de l application L un des ojectifs de ce projet était de réaliser un outil de migration de la base de données qui soit facilement réutilisable. Il fallait donc que son uilisation soit simple et que son fonctionnement soit aisément compréhensible et modifiable par une autre équipe. Le traducteur appelé sybase2postrgesql propose donc plusieurs modes de fonctionnement (voir Annexe J, page 60) : Utilisation avec passage de paramètres en ligne de commande ou par un fichier de configuration. Possibilité de traduire chaque fichier individuellement ou d automatiser l ensemble du fonctionnement. Par ailleurs, le programme a été documenté (voir Annexe I, page 58) et le code commenté afin de rendre leur réutilisation plus simple Estimation du travail restant à effectuer La migration qui semblait relativement simple à ses débuts s est révélée beaucoup plus complexe que prévue et la charge de travail sous-estimée. En cours de projet, les délais ont donc du être réévalués et il s est avéré que la migration des procédures ne pouvait être réalisée dans le temps restant. Suite à ce constat, nous avons déterminé qu il était préférable de réaliser un ensemble de mesures afin d estimer le temps nécessaire à l achèvement du projet. Virginie QUESNAY - Master OTSI - 25 juin

45 Le travail réalisé Méthode d estimation Comme l approche que nous avons employé est de type empirique, il est difficile d avoir, avant d avoir effectuer le traducteur, des indicateurs fiables concernant les points bloquants de la migration. Cependant, certains problèmes sont proches de ceux rencontrés lors de la migration de la structure de la base (et tout particulièrement des vues) et d autres peuvent être assez facilement repérés (nombre de lignes de code, nombre de structures de boucles et de choix,...). Ainsi, il n est pas réellement possible de mesurer précisément la complexité de la migration mais on peut en faire une estimation. Le travail à effectué ici s apparente à une mesure de complexité informatique [35] hormis que le but n est pas d évaluer la performance d un algorithme mais la difficulté à le comprendre et le traduire et que les indicateurs disponibles sont un peu plus "approximatifs". Les outils de mesure de complexité sont assez rares et ne permettent généralement de réaliser des tests que pour des langages courants (C, java,...). Il était donc très improbable de trouver un outil répondant à nos attentes (fonctionnant pour du Transac SQL et réalisant des mesures permettant d évaluer la complexité de "compréhension"). Il a donc fallu mettre au point une méthode assez proche d une mesure de complexité. Cette dernière peut être décomposée en trois grandes phases : la planification, la réalisation et l analyse. Et même si la méthode est généralement présentée sous forme d étapes, en réalité, celles-ci ne sont pas forcément effectuées séquentiellement et il y a habituellement plusieurs itérations avant d obtenir des résultats probants. Nous allons donc suivre les points suivants : 1. Planification (déterminer quelles mesures vont être réalisées) : Sélectionner les variables qui vont être observées. Indiquer la signification des plages de valeurs dans lesquelles vont se trouver les variables. Spécifier le modèle qui va être observé. Définir un ensemble de données d entraînement et de test pour évaluer le modèle. 2. Réalisation (effectuer les mesures) : Tester le modèle sur les données de test et les comparer aux résultats attendus. Obtenir les valeurs des différents indicateurs sur des données réelles et complètes. Regrouper et présenter ces valeurs de manière à ce qu elles soient exploitables. 3. Analyse (traitement et interprétation des résultats) : Traitement des données afin de les rendre compréhensibles. Recoupement des informations afin de faire ressortir les éléments importants. Interprétation et analyse des résultats obtenus Réalisation des mesures Afin d effectuer les mesures permettant d évaluer le travail restant, la première étape a été de définir un ensemble d indicateurs : nombre de lignes de codes par procédure Virginie QUESNAY - Master OTSI - 25 juin

46 Le travail réalisé nombre d instructions SQL par procédure nombre de conditions et de boucles par procédure Il a ensuite fallu développer une application en Perl pour effectuer les mesures qui correspondent à ces indicateurs. En observant les résultats, il a été possible d ajouter quelques indicateurs pour affiner les mesures : nombre de curseurs par procédures nombre d exécutions d autres procédures par procédure De ces résultats, il a également été possible de déterminer des catégories dans lesquelles se trouvent les procédures. Moins de 10 lignes simple Une seule instruction SQL, pas de curseur, pas de 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 que des 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 lignes Entre 40 et 150 lignes simples Pas de condition, pas de boucle et pas de curseur complexe Celles qui n entrent pas dans la catégorie précédente Plus de 150 lignes Transformation manuelle (estimation du temps en fonction du nombre de lignes : 150 lignes par jour/homme) TAB 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 Résultats de l estimation Estimation grossière pour une traduction manuelle Afin d évaluer la charge de travail que représenterait la traduction manuelle des procédures, il convient tout d abord de mesurer le volume d information à traiter. Nous avons donc mesuré le nombre de lignes de code total que représentent les procédures (environ hors commentaires). Une évaluation approximative permet d atteindre un volume de travail d environ 1000 jours/homme (en comptant environ 150 lignes écrites par jour/homme). Virginie QUESNAY - Master OTSI - 25 juin

47 Le travail réalisé La conversion manuelle des procédures n est donc que difficilement envisageable. C est pourquoi, il serait nécessaire de disposer d un outil permettant la migration automatique de la plus grande partie des procédures. Estimation affinée À l aide de l ensemble des indicateurs, il est possible de répartir les procédures en différents niveaux de complexité et de calculer le nombre de jours de développement nécessaires pour terminer l application. Moins de 10 lignes De 10 à 40 lignes De 40 à 150 lignes Plus de 150 lignes Nombre de jours par Nb. de % du niveau de complexité Nb. total % du procs. volume Simple Moyen Complexe de jours temps total , , , , , , ,94 Nb. total de lignes : ,17 71,37 TAB Estimation du temps de développement par catégorie de procédures On peut constater que, comme dans la plupart des projets, 80% du volume des procédures peuvent être migrées pour 20% du temps de travail. Pour les procédures les plus difficiles à migrer (celles qui prennent 80% du temps de développement), il faut s assurer de la pertinence et de l utilité de chacune d elle afin de ne pas perdre de temps inutilement. Virginie QUESNAY - Master OTSI - 25 juin

48 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 on pouvait s attendre : la migration paraissait simple mais elle s est avérée beaucoup plus complexe que prévue 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 Les problèmes techniques Les fonctions Sybase inexistantes sous PostgreSQL Comme toutes les bases de données, Sybase et PostgreSQL possédent des fonctions internes conçues afin de faciliter le travail des développeurs. Néanmoins, leur nom et parfois même leur utilisation différe d un sytème à l autre. Lors de la migration des vues et des procédures, il arrive que ce type de fonctions necessite une intervention pour déterminer la solution à adopter. Lorsque des fonctions de Sybase n existent pas sous PostgreSQL, la solution la plus simple serait de créer des fonctions en pl/sql portant le même nom que la fonction Sybase et donnant le même résultat. Mais cela crée une surcouche et a un impact néfaste sur les performances (une fonction externe utilisant une ou plusieurs fonctions internes sera toujours moins rapide qu une seule fonction interne). Lors de l écriture du programme de migration, nous avons donc utilisé autant que possible, des fonctions internes de PostgreSQL, même si cela nécessitait parfois de remanier les scripts SQL. Cependant, dans quelques rares cas, aucune fonction existante ne pouvant être utilisée, il a fallu en créer des nouvelles (par exemple voir Source J.1, page 62). Virginie QUESNAY - Master OTSI - 25 juin

49 Bilan du stage Les différences d encodage Le passage successif par différents systèmes met en lumière les différences de normes d encodage et d affichage (UTF8, ASCII, Latin1,...) : passage de Sybase à un fichier texte en utilisant un logiciel tiers (soit bcp soit DbDk) sous Windows, transformation par un script Perl sous Linux, intégration à PostgreSQL, affichage sous les outils RedHat (qui préfère utiliser l UTF8). Ceci nécessite de modifier l encodage par défaut ou de forcer celui qui sert à l affichage, voire même de modifier l encodage d un fichier dans un éditeur de texte (voir Annexe M, page 71) sous peine d obtenir des retours à la ligne fantaisistes et de perdre tous les caractères accentués qui se trouvent dans les documents. Les problèmes de casse Windows et Sybase ne gèrent pas les différences de casse ("E" sera considéré de la même façon que "e") tandis que Linux et PostgreSQL font cette différenciation. Pour éviter des problèmes d appel (par exemple lors de l utilisation d une table ou d une procédure) il faut uniformiser les noms. L ancienneté de la base de données Sybase La création de base de donnée sous Sybase a commencé en De nombreuses personnes avec des connaissances et des techniques de programmation différentes ont donc participé à sa gestion et à l écriture de nouvelles fonctions. De plus, les technologies ont évolué : augmentation des capacités du moteur de base de données, évolution de la syntaxe utilisée pour la création de vues et des procédures. Lors de l écriture des scripts Perl, il a donc fallu tenir compte des différents types d écriture afin que toutes les possibilités soient traitées Les problèmes liés à l organisation Peu de problèmes se sont posés en ce qui concerne l organisation propre mais les objectifs proposés au départ ont dû être modifiés. La plannification a été constament réévaluée afin de tenir compte des problèmes rencontrés et de l approche empirique 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ès peu de documentation est disponible au sujet de Sybase (et la plupart de sont prévues pour des versions plus récentes de Sybase). Les informations concernant les migrations de base de données (et tout particulièrement les migrations à partir de Sybase ou de MS-SQL) sont rares et peu complètes : les seules indications fournies n apportent quasiment aucune aide. Virginie QUESNAY - Master OTSI - 25 juin

50 Conclusion Les objectifs d un stage professionnel sont multiples : le stagiaire doit tirer une double expérience (immersion dans le monde du travail et acquisition de nouvelles connaissances sur les activités en entreprise) et pouvoir apporter à l entreprise un bénéfice aussi bien sous forme de nouvelles compétences liées à sa formation qu à sa personnalité. Ce stage a été enrichissant, aussi bien au niveau humain que professionel et sera un atout pour mon entrée dans la vie active. Il m a apporté de nouvelles connaissances tant organisationnelles que techniques et m a permis d appronfondir les compétences que j ai acquises tout au long de ma scolarité. Le projet a mis en évidence que la méthodologie à mettre en œuvre pour la migration de bases de données varie beaucoup selon les systèmes en jeu. Elle varie également beaucoup en fonction du "type" de migration désirée : migration "unitaire" ou migration "reproductible". Les possibilités d une migration de Sybase vers PostgreSQL était très mal connues et ce stage permet de se rendre compte qu elle n est pas simple à pratiquer et permet de mieux les connaître et les maitriser. J espère donc que l ensemble formé par ce rapport et le programme de migration sybase2postgresql pourra constituer une première étape vers une migration définitive en direction de Sybase. Virginie QUESNAY - Master OTSI - 25 juin

51 Liste des annexes A Les CCI en France B La CCI de la Haute-Savoie C Les Chiffres de la CCI de la Haute-Savoie D Organigramme E La licence BSD (Berkeley Software Distribution) F Limitations de PostgreSQL G Phases pour réaliser l ensemble de la migration H Options pour l utilisation de sybase2postgresql I Documentation de sybase2postgresql J Problèmes spécifiques à chaque type d information à migrer K Mesures pour les indicateurs de complexité des procédures L Installation de modules supplémentaires pour Perl M Enregistrement d un fichier en UTF-8 sous Emacs N Webographie Virginie QUESNAY - Master OTSI - 25 juin

52 Annexe A Les CCI en France A.1 Historique La première Chambre naît à Marseille en Le conseil de la ville décide de choisir, parmi ses membres, des députés du commerce "chargés d accroître la prospérité de la ville". La raison d être des Chambres de Commerce est exprimée. Henri IV officialise l institution et en profite pour demander aux députés "des recommandations pour relever l économie du royaume". La fonction traditionnelle de consultation fait sa première apparition. Le nombre de Chambres de Commerce s accroît. Louis XIV crée un conseil du Commerce : le Roi veut recevoir des propositions pour "augmenter le commerce en France et en dehors du royaume". La mission des Chambres de Commerce est tracée. La Révolution les supprime. Elles sont rétablies sous le consulat par Bonaparte. Vingt deux nouvelles chambres sont créées en France et dans l Empire. Elles s implantent partout où l économie locale a besoin de leur structure et de leurs services. Elles vont se développer pendant tout le XIXè siècle. Le réseau se met en place. En 1898, la loi vient formaliser leur rôle et crée un statut original, celui d Etablissement Public représentant les intérêts généraux du commerce et de l industrie auprès des pouvoirs publics. Le cadre juridique est fixé. Durant le XXè siècle le visage contemporain des Chambres de Commerce se dessine définitivement. On les appelle depuis 1960, Chambre de Commerce et d Industrie (CCI) ; en 1964, le législateur achève l édifice en créant les Chambres Régionales de Commerce et d Industrie (CRCI), établissements publics, qui fédèrent les CCI locales. Simultanément, la création de l Assemblée Permanente des Chambres de Commerce et d Industrie (APCCI) couronne le réseau en fournissant aux instances nationales un interlocuteur privilégié. Depuis 1990, I APCCI s est transformée en Assemblée des Chambres Françaises de Commerce et d Industrie (ACFCI). A.2 Nature des CCI Les Chambres de Commerce et d Industrie sont à la fois des organismes publics et professionnels puisque : elles sont régies par une loi et sous tutelle d un ministère représenté aux Assemblées Générales par le Préfet du Département ; elles sont composées et dirigées par des chefs d entreprise élus par leurs pairs, ressortissants de la CCI. Il convient de ne pas les confondre avec les administrations d État (les CCI ne sont soumises à aucune autorité dans le cadre de leur mission bien qu ayant une tutelle mi- Virginie QUESNAY - Master OTSI - 25 juin

53 Les CCI en France nistérielle pour leur budget), ni avec les syndicats professionnels et les associations de commerçants de statut privé. Les CCI sont des organismes interprofessionnels dans la mesure où elles regroupent systématiquement toutes les entreprises inscrites au Registre du Commerce industriels, commerçants, hôteliers, restaurateurs, transporteurs... 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 accompagnant, 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 exercice, fixe le cadre d action de la Chambre en faveur de ses entreprises et de leur environnement. Approuvé par les Ministères de l Industrie et du Commerce, le budget fait l objet d un contrôle à posteriori des Pouvoirs Publics qui s assurent ainsi de la régularité des opérations et de leur conformité avec les décisions de l Assemblée. Les Chambres 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 effectuent directement ou indirectement en faveur de leurs ressortissants (droits de scolarité, de ports, d aéroports, frais d études et de conseil...). Virginie QUESNAY - Master OTSI - 25 juin

54 Les CCI en France Des emprunts : les Chambres sont autorisées à recourir à l emprunt pour financer les é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 Pouvoirs Publics, les collectivités locales ou régionales, les Chambres reçoivent des concours financiers pour accompagner des initiatives spécifiques, réaliser des études de projets ou encourager des actions pilotes... Des ressources fiscales : la loi a donné aux Chambres le droit de voter l impôt qui complète le financement de leurs actions. Cet impôt collecté simultanément avec la 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ésente moins 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 principales missions : une mission d animation et de développement de leurs espaces économiques locaux, 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, formation. Les CCI sont la maison des entreprises. Elles s appliquent à leur fournir les conditions optimales de leur développement. C est dans le cadre de cette mission du 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 sont les interlocutrices et les partenaires naturels des pouvoirs publics et des collectivités locales ainsi que de tous les acteurs économiques qu elles contribuent à éclairer sur les choix des priorités et des investissements de leur Région. Elles sont aussi un lieu de concertation et de coordination des Chambres locales avec 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 Commerce et d Industrie. Virginie QUESNAY - Master OTSI - 25 juin

55 Les CCI en France AFCCI national, européen 20 CRCCI régional 160 CCI local FIG. A.2 Une organisation pyramidale mais non hiérarchisée Cette activité est prolongée au niveau international par 85 Chambres de Commerce et 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 des entreprises et collaborateurs répartis sur l ensemble du territoire, reliés par Intranet. Le budget global des CCI représente 3.4 milliards d Euros, dont près de 1 milliard provenant de l IATP (soit 0,15% des prélèvements obligatoires). A.6.1 Les moyens humains chefs d entreprise élus (membres des CCI) et salariés 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 milliard d euros d IATP). A.6.3 Création d entreprises 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 ; porteurs de projets accueillis et conseillés. A.6.4 La formation (2ème acteur après l Education nationale) 540 établissements de formation personnes formées chaque année contrats d apprentissage signés par an Virginie QUESNAY - Master OTSI - 25 juin

56 Les CCI en France A.6.5 La gestion des équipements 121 aéroports ; 180 ports (commerce, pêche, plaisance,...), les criées 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) Virginie QUESNAY - Master OTSI - 25 juin

57 Annexe B La CCI de la Haute-Savoie B.1 Coordonnées Chambre de Commerce et d Industrie de Haute-Savoie 5 rue du 27ème BCA BP ANNECY Cedex Tél. : Fax. : B.2 Heures d ouverture CCI Du lundi au jeudi de 8h00 à 12h00 et de 13h00 à 17h00 Le 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 à 16h30 Le vendredi uniquement sur rendez-vous de 9h00 à 12h00 B.2.2 Espace Entreprises Du lundi au jeudi de 8h30 à 12h00 et de 13h30 à 17h00 Le vendredi de 8h30 à 12h00 B.3 Plan d acces Virginie QUESNAY - Master OTSI - 25 juin

58 BD. DECOUZ BD. DU LYCÉE CHAMBRE DE COMMERCE ET D'INDUSTRIE DE LA HAUTE-SAVOIE 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 1 er tunnel, prendre la direction de la Roche 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. A41 SORTIE ANNECY-NORD A41 SORTIE ANNECY-SUD BOULEVARD DE LA ROCADE BOULEVARD DE LA ROCADE Av. des Romains Fins sud AV. DE CRAN PLACE DES ROMAINS Av. des Romains Rue E. Romanet Chemins des URSSAF Rue des chasseurs AVENUE DE GENEVE R. de l'intendance Avenue Joseph Dessaix Rue du 27 ème BCA Rue des alpins AVENUE DE BROGNY CCI 5, rue du 27 ème BCA Annecy GARE SNCF Chambre de Commerce et d Industrie de la Haute-Savoie 5, rue du 27 ème BCA - BP Annecy Cedex Tél.:

59 Annexe C Les Chiffres de la CCI de la Haute-Savoie FIG. C.1 Répartition des ressources de la CCI ( 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 Virginie QUESNAY - Master OTSI - 25 juin

60 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 Virginie QUESNAY - Master OTSI - 25 juin

61 Annexe D Organigramme FIG. D.1 Organigramme simplifié de la CCI de la Haute-Savoie Virginie QUESNAY - Master OTSI - 25 juin

62 Annexe E La licence BSD (Berkeley Software Distribution) La licence BSD modifiée (flexible BSD licence) est une licence de logiciel libre simple et 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 but visé, qu il soit privé, commercial ou académique. Dans sa version initiale (la license BSD originale), elle incluait une clause obligeant les programmeurs qui l utilisaient à mentionner dans tous leurs documents publicitaires la citation suivante : "This product includes software developed by the University of California, Berkeley and its contributors" (Ce produit contient des logiciels développés par l Université de Californie, Berkeley et ses collaborateurs). Virginie QUESNAY - Master OTSI - 25 juin

63 Annexe F Limitations de PostgreSQL Les données fournies ci-dessous sont celles officiellement annoncées sur le site de PostgreSQL 1. Maximum size for a database Maximum size for a table Maximum size for a row Maximum size for a field Maximum number of rows in a table Maximum number of columns in a table Maximum number of indexes on a table unlimited (4 TB databases exist) 16 TB on all operating systems 1.6 TB 1 GB unlimited depending on column types unlimited TAB. F.1 Limitations of PostgreSQL Of course, these are not actually unlimited, but limited to available disk space and memory/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 operating system. Large tables are stored as multiple 1 GB files so file system size limits are not important. The maximum table size and maximum number of columns can be increased if the default block size is increased to 32k. 1 Sources : Virginie QUESNAY - Master OTSI - 25 juin

64 Annexe G Phases pour réaliser l ensemble de la migration Afin de réaliser l ensemble du processus de migration de façon manuelle, il faut respecter une chronologie dans les actions effectuées. Lors de l utilisation automatisée du processus, l ensemble des opérations sera également 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 sous PostgreSQL) $psql -c \i PATCH_pour_postgresSQL ma_base Créer les tables $psql -c \i postgres_mes_tables ma_base Créer les index Virginie QUESNAY - Master OTSI - 25 juin

65 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 Virginie QUESNAY - Master OTSI - 25 juin

66 Annexe H Options pour l utilisation de sybase2postgresql Afin de permettre une utilisation souple du programme, il est possible de le lancer avec différentes options. Ces dernières peuvent être transmises soit directement en ligne de commande, soit par l instermédiaire d un fichier de configuration (lui même précisé en ligne de commande). Voici les options disponibles en ligne de commande : Source H.1 Options de sybase2postgresql affichées grâce à l option -h 1 Usage : sybase2postgresql [ h ] [ a ] [ b nom_base ] [ t f 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 ] [ g f i c h i e r _ t r i g g e r ] [ d fichier_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 aide 3 a s i l e s t o u t e s l e s options 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 informations ), 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 donnees car 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 a transformation 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 base 6 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 base 7 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 base 8 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 base 9 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 base 11 S nom ( ou adresse ) du serveur Sybase de l a base o r i g i n e 12 U nom d u t i l i s a t e u r pour l a base Sybase 13 P mot de passe pour l a base Sybase 14 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 options : permet de ne pas s p e c i f i e r chacune des options c i dessus Virginie QUESNAY - Master OTSI - 25 juin

67 Options pour l utilisation de sybase2postgresql Dans le fichier de configuration, il est possible d utilliser les mêmes options qu en ligne 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 les lignes vides seront ignorées. Pour les options précisant des noms de fichiers, il est possible de préciser plusieurs fichiers pour une même options (alors que ça n est pas possible par un appel en ligne de 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 1 2 a 3 b = c c i 1 4 t = monrepertoire/mes_tables1. s q l 5 t = monrepertoire/mes_tables2. s q l 6 i = mes_indexs. s q l 7 f = mes_fonctions. s q l 8 9 # S e r v e u r Sybase 10 S = monserveur 11 U = u t i l i s a t e u r 12 P = mot_de_passe Virginie QUESNAY - Master OTSI - 25 juin

68 Annexe I Documentation de sybase2postgresql 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 vers une 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 reprenne apres le dernier enregistrement cree) qui devra etre execute apres l insertion des donnees dans la base Le programme peut être appele en lignes de commandes avec les options ou avec un 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 fonction de son contenu. automatique Automatise le fonctionnement du script : toutes les actions sont effectuees automatiquement (a condition que tous les renseignements necessaires soient fournis) Virginie QUESNAY - Master OTSI - 25 juin

69 Documentation de sybase2postgresql clear_line Netoie une ligne passee en parametres en enlevant le retour chariot, remplacant les lettres 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 (detectees par 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 PostgreSQL lors du COPY I.4 VOIR AUSSI Documentation PostgreSQL, documentation BCP,... Virginie QUESNAY - Master OTSI - 25 juin

70 Annexe J Problèmes spécifiques à chaque type d information à migrer J.1 Les tables J.1.1 J.1.2 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 majuscules) 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 correctement exportées par DbDk. 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 (CREATE SEQUENCE). 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 la séquence grâce à la commande setval(). 3. Pour la casse, PostgreSQL étant "casse sensitive" alors que Sybase ne l est pas, il est plus prudent et rationnel de transformer tous les noms afin qu ils soient tous en 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 des schémas, soit utiliser une nouvelle version de DbDk (les noms étant tronqués dans le fichier texte, il n est pas possible de gérer le problème à posteriori). Virginie QUESNAY - Master OTSI - 25 juin

71 Problèmes spécifiques à chaque type d information à migrer J.2 Les index J.2.1 J.2.2 Problèmes rencontrés 1. Certains index, sur des tables différentes, portent des noms identiques. 2. Certains index sont de type CLUSTERED. Ceci signifie que les enregistrements de la table sont classés physiquement en fonction du champ sur lequel porte l index. Solutions possibles 1. La solution la plus simple et logique à mettre en place est la modification de la politique de nommage pour ces index (le choix qui a été fait est celui d accoler le nom de la table et le nom de l index). 2. Ce type de contraintes n existe pas réellement sous PostgreSQL. Il est cependant possible d utiliser la fonction CLUSTER qui "range" à un instant donné la table selon le champ indiqué. Si on perçoit la nécessité de classer cette table (démontrée par des tests de performance significatifs), il serait possible de déclencher de manière régulière (par exemple par l utilisation de Cron) l utilisation de la fonction CLUSTER. Le choix d utiliser ou non CLUSTER devra être fait en fonction des performences et non de l existence de CLUSTERED sous Sybase (leur présence n est pas/plus forcément judicieuse) ; J.3 Les vues J.3.1 J.3.2 Problèmes rencontrés 1. Les vues de la bases ne sont pas crées avec la même syntaxe (=> difficile de faire une 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 PostgreSQL comme un champ de texte. 5. Les jointures externes ne sont pas représentées de la même façon sous Sybase et sous 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) Solutions possibles 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 pas indispensable, ils peuvent être supprimés. Virginie QUESNAY - Master OTSI - 25 juin

72 Problèmes spécifiques à chaque type d information à migrer 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 place du nom de champ et qui sont parfois répartis sur plusieurs lignes (elles rendent la 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ême faç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 est né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 est pas possible d automatiser cette transformation : elle devra donc être réalisée manuellement. 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. Cependant, 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 possible de la remplacer la la fonction lpad. Les fonctions suser_id n existent pas sous Sybase (et aucune fonction correspondante n existe). Il a donc faullu créer ces fonctions de toute pièce grâce à pl/pgsql : 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 integer AS 2 DECLARE 3 nom a l i a s f o r $1 ; 4 uid i n t e g e r ; 5 BEGIN 6 SELECT INTO uid 7 usesysid 8 from pg_catalog. pg_shadow 9 where usename=nom; RETURN uid ; 12 END; 13 language plpgsql ; / * * / Virginie QUESNAY - Master OTSI - 25 juin

73 Problèmes spécifiques à chaque type d information à migrer CREATE OR REPLACE FUNCTION suser_id ( ) RETURNS integer AS 18 DECLARE 19 uid i n t e g e r ; 20 BEGIN 21 SELECT INTO uid 22 usesysid 23 from pg_catalog. pg_shadow 24 where usename=session_user ; RETURN uid ; 27 END; 28 language plpgsql ; 7. En ce qui concerne la conversion de varchar en int, il est possible de passer par un text (les conversions "varchar vers text" et "text vers int" exitent toutes les deux. Il est alors possible, soit de modifier le code source de la vue (mais cette solution n est pas très "propre" car elle nécessite une intervention manuelle), soit de 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 DECLARE 3 input a l i a s f o r $1 ; 4 BEGIN 5 return ( 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 alors que les autres types d entiers possèdent cette conversion. Tout comme pour la transformation à partir du varchar, on peut donc créer une conversion passant par 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 DECLARE 3 input a l i a s f o r $1 ; 4 BEGIN 5 return ( 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 ) ; Virginie QUESNAY - Master OTSI - 25 juin

74 Problèmes spécifiques à chaque type d information à migrer J.4 Les données J.4.1 J.4.2 Problèmes rencontrés 1. Le format d export des dates par BCP n est pas compatible avec l import dans PostgreSQL Solutions possibles 1. Pour les dates, il n y a pas moyen de modifier par une option le format d export de 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 supporte l export de vues). Cette solution est assez lourde et implique la création d autant de vue qu il y a de tables contenant des dates avant de pouvoir effectuer la moindre extraction (qui sera ralentie par la "surcouche" qu amène la vue 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 solution permet une modification "invisible" pour l export mais nécessite de créer les fichiers de format (et également de décrire les colonnes qui ne sont pas de format date) ce qui est fastidieux. Créer un script Perl qui modifiera les données de type date (elles ont un "aspect" 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 à mettre en 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 est pas possible de lister de manière exhaustive les problèmes rencontrés et les solutions apportées. Cependant, lors de la phase d évaluation du temps restant, il a fallu déterminer quels problèmes pourraient se poser lors de la migration et l impact qu ils pourraient avoir sur la difficulté de "traduction". 1. La déclaration des variables sous Sybase est réalisées aussi bien avant que après le 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 utilisation de DECLARE, BEGIN et END. 3. Dans les structures de boucles ou de choix, l utilisation du BEGIN et du END est courrante 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ère réellement explicite (par exemple avec un ;) ce qui rend la détection plus complexe. Virginie QUESNAY - Master OTSI - 25 juin

75 Problèmes spécifiques à chaque type d information à migrer 5. La nature du résultat envoyé par une procédure n est pas explicite et peut poser des problèmes dans le cas d un résultats composé de plusieurs "colonnes" et plusieurs "lignes" en comparaison d une seule valeur. 6. Certaines fonctions internes à Sybase n existent pas sous PostgreSQL. Mais cet aspet 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 être identique sous PostgreSQL. Virginie QUESNAY - Master OTSI - 25 juin

76 Annexe K Mesures pour les indicateurs de complexité des procédures FIG. K.1 Nombre de lignes par procédure Virginie QUESNAY - Master OTSI - 25 juin

77 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 Virginie QUESNAY - Master OTSI - 25 juin