MIGRATION DE DONNÉES

Transcription

1 Les contenus de ce document sont la propriété exclusive de la société REVER. Ils ne sont transmis qu à titre d information et ne peuvent en aucun cas être considérés comme un engagement de la société REVER. Toutes utilisations, en ce compris le référencement, de la totalité ou d une partie de ce document, ne sont autorisées qu avec l accord formel et écrit de REVER.

2 TABLE DES MATIÈRES Contenu 1 SYNTHESE DU DOCUMENT DEFINITIONS LA PROBLEMATIQUE DES MIGRATIONS DE DONNEES LA DEMARCHE METHODOLOGIQUE PROPOSEE PHASE D EXECUTION LE PROCESSUS GENERAL DE LA MIGRATION LA MIGRATION LES PROCESSUS DE SECURISATION LES PROCESSUS SPECIFIQUES SECURISATION DES DONNEES SOURCE MIGRATION COMPLETE PHASE DE DEVELOPPEMENT ANALYSE DES SYSTEMES D INFORMATION ANALYSE DU SYSTEME D INFORMATION SOURCE ANALYSE DU SYSTEME D INFORMATION CIBLE SPECIFICATIONS DE LA MIGRATION DEFINITION DES REGLES D EXTRACTION DEFINITION DES CORRESPONDANCES REGLES DE TRANSFORMATIONS IDENTIFICATION DES «INCOMPATIBILITES» SUIVI DES SPECIFICATIONS PRODUCTION DES PROGRAMMES PRODUCTION DES PROGRAMMES DU PROCESSUS DE MIGRATION PRODUCTION DES PROGRAMMES DU PROCESSUS DE SECURISATION TESTS DE LA MIGRATION MISE EN PLACE DES PROCESSUS OPTIMISATION DES PROCESSUS AUTOMATISATION ET LIVRABLES Page 2

3 1 Synthèse du document La méthodologie décrite dans ce document permet de réaliser la migration de données depuis un environnement technique SOURCE vers un autre environnement technique CIBLE. En la matière, la démarche adoptée par REVER est celui des GPS. La précision d un chemin entre deux points dépend du niveau de connaissance des points de départ et d arrivé : le risque d un mauvais chemin diminue avec l augmentation de la précision de la connaissance des deux points situés aux extrémités du chemin et réciproquement le risque augmente lorsque la précision d un de ces deux points diminue. Une fois la connaissance des extrémités établie, il est alors possible de choisir le chemin «optimal» en fonction des critères du projet : le plus rapide, le plus sûr, etc Cette approche, appliquée à la migration de données, garanti : l exhaustivité de la migration c est-à-dire que l ensemble des données qui doivent être transférées le sont effectivement ; la complétude de la migration, c est-à-dire que le processus de migration a pris en compte tous les cas ; l exactitude de la migration, c est-à-dire que le processus de migration a produit les résultats attendus. La démarche proposée par REVER présente les avantages : de ne nécessiter aucune itération entre phases ; d être très fortement outillée réduisant au maximum les interventions humaines, en particulier, grâce à des automates qui permettent : o de «reconstruire» les règles des S.I. source et cible ; o de «comparer» : les structures des S.I. source et cible ; les règles des S.I. source et cible ; les contenus des S.I. source et cible. Les technologies de REVER, permettent en fonction des besoins et des impératifs de performance soit de migrer les données directement depuis la base SOURCE vers la base CIBLE sans passer par des «fichiers plats» intermédiaires, soit plus classiquement de décharger les données SOURCE dans des fichiers plats prêt à être rechargés dans la base CIBLE. Par ailleurs, elles sont utilisables pour de nombreux environnements techniques et SGBD tels qu IMS, ADABAS, IDS2, les SGBD relationnels (ORACLE, DB2, SQL SERVER, ). 1.1 Définitions Afin d éviter toute ambiguïté par la suite, les explications contenues dans ce document sont basées sur les définitions suivantes : la base «source» désigne l ensemble des données «origine» de la migration. Cette définition n impose pas que les données soient toutes stockées dans la même base physique ; la base «cible» désigne l ensemble des données «destination» de la migration. Cette définition n impose pas que les données seront toutes stockées dans la même base physique ; les «descriptions» définissent les concepts (les entités), leurs propriétés (les attributs) du S.I. ainsi que leur «sémantique»; les «règles de gestion des données» (ou «règles données») précisent les «contraintes» qui doivent être respectées par l application pour tous les concepts et toutes les propriétés du S.I. Le terme «contrainte» est ici utilisé dans son acception la plus large et recouvre à la fois les limites de longueur, les obligations de présence, les listes de «valeurs acceptables, les dépendances entre propriétés ou entre concepts, etc (voir schéma 1) ; Page 3

4 les «structures et règles SGBD» (appelés également «règles imposées par le SGBD» ou contraintes explicites) désignent les éléments «techniques» conséquence d une implémentation du S.I. qui : o permettent de «stocker» les valeurs des données ; o assurent les contrôles de tout ou d une partie des «règles données» ; les contraintes implicites : ce sont les contraintes non vérifiées par le SGDB ; les «règles de transformation» désignent les algorithmes qui doivent être appliqués à chacune des valeurs d une propriété de la base «source» avant d être stockée dans la base «cible». Au sein d un système technique (une application informatique) les descriptions et les règles données sont implémentées sous forme de structures et de codes soit dans le SGBD, soit dans les programmes, soit encore dans le SGBD et les programmes. Cette répartition dépend des choix faits par les développeurs qui prennent en compte notamment les contraintes imposées par l environnement technique (SGBD, langage de programmation) mis à leur disposition. Ainsi à titre d exemple, une donnée «date» peut être définie de type «DATE» dans un SGBD relationnel (ce qui n est pas le cas dans des fichiers COBOL par exemple) ou comme un champ de type «char(10)». Dans le premier cas, c est le SGBD qui assure la validité de la date, dans le second ce sont les programmes qui doivent le faire. De manière plus générale, du point de vue des règles un système d information peut être représenté par le schéma 2. On y retrouve les structures et les règles gérées par l application informatique à savoir le SGBD et les programmes et les règles gérées par les utilisateurs. 1.2 La problématique des migrations de données Une migration de données consiste à transférer tout ou une partie des données d un ensemble de données origine «SOURCE» vers un autre ensemble de données «CIBLE». Comme l illustre le schéma 3 les S.I. SOURCE et CIBLE peuvent être : identiques ou différents quant à leurs environnements techniques. C est le cas notamment lors des réécritures d application, des changements de plateformes technologiques ainsi que lors des changements de types de SGBD (par exemple : IMS vers DB2) ; identiques ou différents quant aux règles de gestion des données ; identiques ou différents quant aux structures et règles SGBD. Page 4

5 Pour qu une «migration de données» soit correcte, quatre points majeurs doivent être garantis : 1) il faut que les données migrées respectent 100% des structures et des règles SGBD CIBLE. Cette condition est remplie par les contrôles effectués par le SGBD lui-même : toute valeur de donnée nonconforme à une règle définie dans le SGBD est rejetée lors du chargement. Ce rejet oblige les intervenants à effectuer une nouvelle itération, qui risque à son tour d avoir un nouveau rejet, etc Le risque de ce processus réside dès lors dans le nombre d itération nécessaire pour réaliser la migration ; 2) il faut que les données migrées respectent 100% des règles de gestion du système CIBLE. Ces règles de gestion sont celles qui sont (ou qui seront dans le cas de développement) respectées par l application informatique et les utilisateurs; 3) il faut que le transfert de la totalité des données qui doivent migrées depuis la base SOURCE vers la base CIBLE soit effectif (exhaustivité de la migration) ; 4) il faut que le transfert respecte la sémantique des données SOURCE (maintien de la cohérence des données). 1.3 La démarche méthodologique proposée Un projet de migration comporte deux phases principales : une phase «de développement» d un processus de migration et d un processus de sécurisation de la migration. Cette phase comprend les étapes d analyses, de spécifications, de production, de tests et de mises en place des processus ; une phase «d exécution» des deux processus mis en place qui assure le transfert effectif des données et le contrôle des résultats. La suite de ce document décrit en détail chacune de ces deux phases. Cependant, pour des raisons de lisibilité, la phase d exécution sera explicité avant la celle d élaboration. En effet, certaines explications pourraient paraître confuses si le lecteur n a pas une vision claire et précise des résultats à obtenir. Page 5

6 2 Phase d exécution 2.1 Le processus général de la migration Dans sa généralité, et comme l illustre le schéma 5, le processus de migration comprend principalement trois étapes : l extraction des données à migrer de la base SOURCE; la migration proprement dit ; le chargement de la base CIBLE. A ce processus de migration s ajoute un processus complémentaire dont l objectif est de s assurer de la validité des résultats produits par la migration. Ce processus dit de «sécurisation» comprend : le «contrôle de la migration» qui à pour objet de vérifier o que toutes les données à migrer l ont bien été ; o que la cohérence initiale des données à été maintenue au cours de la migration ; le «contrôle des données» qui a pour but de vérifier que les données migrées sont conformes aux règles de gestion de l application CIBLE La migration Extraction des données Dans cette étape il s agit simplement d extraire de la base SOURCE les données à migrer pour les stocker dans une base intermédiaire dont les structures et règles sont strictement identiques à celles de la base SOURCE. L objectif poursuivi est d utiliser pour la migration une base SOURCE qui ne contient que les données à migrer. Les critères de sélection des données et les règles d extraction sont définis à l étape de spécifications de la phase de développement. Les critères d extraction peuvent être fonctionnels ou techniques. Dans les deux cas, les technologies de REVER garantissent la cohérence fonctionnelle des données extraites : en effet, le programme d extraction parcours la base de données suivant la logique indiquée par le modèle SOURCE. On notera que cette étape n est pas utile lorsque la migration porte sur l ensemble des données de la base SOURCE Migration des données Dans cette étape, il s agit d exécuter un programme qui va assurer le transfert effectif depuis «la base des données à migrer» vers une base intermédiaire, appelée «base des données migrées», dont les structures et règles sont strictement identiques à celles de la base CIBLE. L objectif poursuivi est de construire une base contenant les données migrées prêtes à être chargées dans la base CIBLE. Page 6

7 Le principe de fonctionnement du programme de migration est : de lire les données de la «base des données à migrer», de les transformer suivant les règles spécifiées, de vérifier la conformité des données transformées par rapport aux règles du SGBD CIBLE, d écrire les données dans la «base des données migrées». Ces 4 fonctions sont intégrées un seul programme. L objectif de la migration étant de peupler la base CIBLE, la logique de lecture-écriture du programme de migration est celle qui est définie par les structures de la base CIBLE. Autrement dit, les tables de la base CIBLE sont peuplées les unes après les autres dans l ordre déterminée par le modèle de la base CIBLE. Pour des raisons d optimisation, ce processus peut être scindé en plusieurs programmes exécutés en parallèle, les écritures se faisant alors soit dans des fichiers plats prêt à être chargés, soit dans une base intermédiaire dont les contraintes inter-tables ont été levées momentanément Chargement des données L objectif de cette étape est de recopier dans la base CIBLE les données contenues dans la «base des données migrées». Cette copie peut être réalisée soit au moyen d utilitaires de déchargement/rechargement, soit dans le cas où il existe des contraintes de temps réels au moyen de programmes spécifiques qui effectuent le processus de lecture-écriture sous forme de transaction Les processus de sécurisation Pour «sécuriser» les résultats produits par la migration, la méthode proposée par REVER consiste à exécuter deux processus distincts et complémentaires. Le premier consiste à «contrôler» la migration elle-même, le second à contrôler la conformité des «données» résultats de la migration par rapport aux règles de l application CIBLE Contrôles de la migration A ce niveau, deux types de contrôles sont effectués : un contrôle de l exhaustivité de la migration qui vise à s assurer que l ensemble des données qui doivent être migrées l ont bien été ; un contrôle du maintien de la cohérence des données qui vise à s assurer que les données n ont pas «perdues» leur cohérence initiale au cours de la migration (p.ex. : toutes les commandes du client X doivent lui être restées liées après migration) Contrôles de l exhaustivité Le contrôle est réalisé par des automates qui : assurent pour la base «des données à migrer» o le comptage du nombre d occurrence des attributs à migrer ; o un «checksum» sur les valeurs des attributs à migrer ; assurent pour la base «des données migrées» o le comptage du nombre d occurrence des attributs migrés ; o un «checksum» sur les valeurs des attributs migrés ; effectuent la comparaison des différents compteurs et la visualisation des résultats. Page 7

8 Le rapport de comparaison est produit sous forme de pages HTML indiquant de manière simple les éventuelles différences rencontrées entre le système SOURCE et le système CIBLE. On notera toutefois, que ce type de contrôle porte sur les attributs qui n ont pas été «trop» transformées par la migration. En effet, les données qui ont subies des transformations importantes ne sont pas comparables. Malgré cette restriction, ce contrôle est néanmoins significatif dans la mesure où le nombre d attributs non transformés est souvent important Contrôles de la cohérence L objectif poursuivi, ici, est de s assurer que la migration a gardé la cohérence initiale des données. Pour cela les bases SOURCE et CIBLE sont lues en utilisant un modèle commun. Les données lues sont comparées ce qui permet : o de détecter les occurrences (les «lignes») manquantes ou en trop; o de détecter les différences de valeurs dans les données. L exécution du processus produit un rapport sous forme de pages HTML en 2 parties distinctes : la première indique de manière simple les éventuelles différences entre le système SOURCE et le système CIBLE en suivant la logique des arborescences ; Page 8

9 la seconde indique de manière simple les éventuelles différences dans les valeurs entre le système SOURCE et le système CIBLE. Page 9

10 De même que pour le contrôle de l exhaustivité, et pour les mêmes raisons, le contrôle de la cohérence ne porte que sur les données qui n ont pas subies de trop fortes transformations. Par ailleurs, pour des raisons de performance, ce processus est généralement appliqué sur un échantillon «représentatif» de la migration de données. Bien entendu, il peut s appliquer à l entièreté des données migrées si nécessaire Contrôles des données Ce contrôle a pour objectif de vérifier que les données migrées respectent les règles de gestion du S.I. CIBLE. Ce contrôle est complémentaire à celui qui est intégré au programme de migration qui lui assure le contrôle des données transformées par rapport au SGBD CIBLE et qui vise donc à garantir que les données migrées peuvent être chargées dans le SGBD CIBLE. Le contrôle qui est effectué dans cet étape vise, lui, à vérifier que les données migrées respectent règles gérées par les programmes. L exécution des processus de contrôle des données fournit un rapport sous forme de pages HTML en trois parties, chacune d elles étant accessible via un onglet : la première partie fournit des statistiques générales ; la deuxième reprend la liste des tables dans lesquelles des données «non-conformes» ont été trouvées. Pour chacune de ces tables le résultat des contrôles pour chacun des attributs est indiqué. Les attributs pour lesquels il y a des valeurs non-conformes sont mis en évidence : le détail de ces valeurs est directement accessible (dans l exemple ci-dessous l attribut ACTV_DT_END de type DATE contient des valeurs « ») ; Page 10

11 la troisième non illustré ici reprend les résultats pour la totalité des tables. 2.2 Les processus spécifiques La description du processus de migration décrit précédemment est générique. En fonction des besoins des projets de migration des adaptations du processus sont possibles. Il n entre pas dans l intention de décrire toutes les variantes possibles : ne sont reprises ici que les principales Sécurisation des données SOURCE Cette première variante consiste à contrôler les données du S.I. SOURCE. Il va de soi que ce contrôle ne peut porter que sur un contrôle des données par rapport aux règles de gestion du S.I. SOURCE. Si à première vue ce contrôle semble inutile (puisque ce sont les données transformées qui doivent être conformes aux règles de gestion du S.I. CIBLE) en pratique il est d une grande utilité puisqu il permet de s assurer que les données sur lesquelles les transformations vont être effectuées n ont pas des valeurs rendant les fonctions de transformations inopérantes ou erronées. Dans la chaîne de traitement ce contrôle peut se situer à deux moments distincts : en tout début de projet afin d une part de mesurer la qualité globale des données qui seront à migrer et d autre part d avoir le temps d apporter des corrections aux données «non-conformes». En outre, lorsque la base source n est pas une base relationnelle «native», il peut être créé à cette occasion une base «staging» permettant aux analystes métiers de faire les études nécessaires. Si des Page 11

12 erreurs sont détectées, soit le modèle doit être corrigé, soit les données. Après correction, une nouvelle vérification doit être effectuée afin de s assurer que toutes les données sont conformes ; en début de chacune des exécutions du processus de migration pour s assurer que les «données à migrer» n ont pas été «corrompues» depuis le dernier contrôle Migration complète Il arrive régulièrement que la migration des données soit effectuée en une seule fois et non en plusieurs lots comme décrit dans le processus général. Dans ce cas, il va de soi : qu il n y a pas d extraction à effectuer la base «des données à migrer» étant la base SOURCE ; qu il n y a pas de chargement à effectuer la base «des données «migrées» étant la base CIBLE. Il existe toutefois l exception des bases CIBLE qui contiennent déjà des données. Dans ce cas il est prudent de charger une base «intermédiaire» afin de permettre l exécution du processus de sécurisation. On notera également, le cas des migrations dites «à chaud», qui concerne les migrations pour lesquelles la base SOURCE continue à être mises à jour pendant la durée de la migration. Dans ce cas, il convient d effectuer une copie de la base SOURCE pour produire une base SOURCE(1) ; de réaliser la migration des données de la base SOURCE(1) vers la base CIBLE ; à la fin du processus de migration, il faut identifier dans la base SOURCE les données qui ont évoluées depuis la copie : cela peut se faire soit par un dispositif spécifique, soit par comparaison des contenus ; dans la mesure où il y a des données qui ont été modifiées il faut extraire ces données et réitérer le processus. Page 12

13 3 Phase de développement Le développement du processus de migration et du processus de sécurisation est constitué de quatre étapes principales : la première est l analyse des systèmes SOURCE et CIBLE. Elle a pour objectif de s assurer de la connaissance approfondie des règles de gestion des S.I. SOURCE et CIBLE. En particulier, pour le système SOURCE il est nécessaire de connaître : o les structures détaillées des données ; o les règles de gestion des données à migrer : ces règles peuvent être gérées par le SGBD, ou par les programmes. Le même niveau de connaissance est requis pour l application CIBLE. Toutefois, dans la plupart des cas, le système CIBLE est en cours de mise en place et donc sa définition et sa connaissance approfondie est maitrisée. On notera toutefois l exception notable du cas de fusion d application pour laquelle il est nécessaire de faire pour le système CIBLE une analyse approfondie analogue à celle effectuée pour le système SOURCE. la deuxième étape est la spécification de la migration. Son objectif est de définir : o les règles d extractions ; o les correspondances SOURCE -CIBLE : pour chacune des données du système CIBLE il est nécessaire de préciser la ou les données origines ; o les règles de transformation qui doivent être exécutées, etc. la troisième étape est la production des programmes qui seront exécutés ultérieurement ; enfin la quatrième étape est le test et la validation des programmes produits : il est souvent appelé «bascule à blanc». Page 13

14 3.1 Analyse des Systèmes d Information L objectif de cette étape est d acquérir une connaissance approfondie des systèmes SOURCE et CIBLE afin de garantir la maîtrise des systèmes pour une migration sans risques : dans un premier temps, il s agit d analyser le S.I. SOURCE ; dans un seconde temps, il convient d acquérir les connaissances du S.I. CIBLE Analyse du Système d Information SOURCE L objectif des activités décrites dans ce point est de reconstituer la connaissance des contraintes et exigences pour autant que cette connaissance des descriptions et des règles ne soit pas certaine. Dans ce cas la démarche consiste : à «récupérer» les structures définies dans le SGBD et éventuellement dans les programmes; à «récupérer» les règles définies dans le SGBD et dans les programmes Récupération des structures Les structures sont obtenues par rétro-ingénierie de la base SOURCE. Il s agit d obtenir la description physique des tables, des colonnes déclarées explicitement dans le SGBD. Le processus de rétro-ingénierie de l application est poussé plus loin lorsqu il est nécessaire d affiner le découpage et le typage des structures (cas des «redefines» COBOL). Une analyse des codes sources de programmes permet de récupérer les définitions explicites et implicites des structures Récupération des règles de gestion des données Les règles de gestion explicites (liens entre les tables) sont obtenues par rétro-ingénierie de la base SOURCE. D autres règles définies dans le SGBD (dbprocedure, triggers, etc.) sont également récupérées. L analyse des codes sources des programmes permet d identifier et «récupérer» les règles de gestion des données définies dans les programmes L ensemble des résultats sont intégrés en un tout cohérent dans le référentiel DB-MAIN, plateforme de modélisation des S.I Analyse du Système d Information CIBLE Récupération des structures La récupération des structures et des règles gérées par le SGBD CIBLE est réalisée selon des modalités différentes suivant les situations : soit les structures et les règles sont définies dans un outil de modélisation : dans ce cas elles peuvent être récupérées par un processus d exportation-importation ; soit les structures et les règles sont implémentées dans une base CIBLE existante (éventuellement vide) : dans ce cas elles peuvent être récupérées par une simple analyse de scripts de création de la base ou par rétro-ingénierie Définition des règles de gestion des données Par définition les données migrées doivent répondre aux contraintes et exigences du S.I. CIBLE (règles de gestion, structures et règles SGBD), ce qui impose la connaissance de ces éléments indispensable pour valider la migration. Page 14

15 Dans le cas où l application CIBLE existe, la récupération des règles de gestion peut être réalisée par rétro-ingénierie de la même manière que pour le système SOURCE. Dans le cas des réécritures d application, les programmes n existant pas encore, il convient de partir des spécifications fonctionnelles pour définir les règles de gestion. Ces règles doivent être respectées par toutes les données de la base CIBLE, ce qui comprend bien entendu les données provenant directement de la base SOURCE mais également les autres données, inexistantes dans le S.I. SOURCE, nécessaires à la migration et qui doivent être créées au préalable ou au cours de la migration par des traitements spécifiques. Ces règles sont les mêmes que celles que les programmes doivent ou devront respecter et en conséquence sont en principe disponibles ou à tout le moins connues des intervenants métiers. La description de ces règles peut prendre différentes formes, telles que celles illustrées dans le schéma 9. Page 15

16 3.2 Spécifications de la migration Pour effectuer une migration il y a lieu de spécifier : les règles d extraction ; les correspondances SOURCE CIBLE ; les règles de transformation. MIGRATION DE DONNÉES Afin de faciliter au maximum le travail important de ces spécifications, des fonctions d aides performantes sont mises à la disposition des intervenants : la détection automatique des «incompatibilités» SOURCE CIBLE ; le suivi des spécifications Définition des règles d extraction Il n est pas rare qu une migration de données soit réalisée par lot : c est le cas en particulier des réécritures d application qui sont mises en œuvre au fur et à mesure de la disponibilité des programmes. Les technologies proposées par REVER permettent d identifier les «adhérences» entre données : ce sont les données qui doivent migrées ensemble ; d identifier les «adhérences» entre données et programmes : ce sont les programmes qui effectuent les mises à jour des données. Outre son intérêt pour identifier les risques techniques de la migration, cette fonctionnalité est particulièrement utile pour l établissement des synchronisations de données entre les systèmes SOURCE et CIBLE. Sur base de ces informations complétées par les informations de types métiers et organisationnelles, il est alors possible de définir une stratégie de migration par lot minimisant les risques techniques de la migration. La définition des règles d extraction permet alors d effectuer, en fonction des besoins du projet : des découpages fonctionnels (p.ex. : tous les «clients» et «commandes» relatives à un pays) des découpages techniques (p.ex. : les tables «clients» et «commandes») Définition des correspondances Les intervenants indiquent quelles sont les données à migrer : il s agit simplement de définir du point de vue «métier» les correspondances entre concepts (entités) et/ou propriétés (attributs) des bases source et cible. À ce niveau il s agit d établir les correspondances : toutefois, si les règles de transformation sont connues d un point de vue fonctionnel elles peuvent également être indiquées. L établissement des correspondances, est réalisé par les intervenants soit à partir de la description du S.I. SOURCE, soit à partir de la description du S.I. CIBLE. L expérience montre que pour un projet de migration les intervenants utilisent l un et l autre en fonction des problématiques abordées. Pour la déclaration des correspondances deux types d outils sont mis à disposition des intervenants métiers. Le choix entre l un ou l autre des outils est fait à la mise en place du projet : Page 16

17 soit il s agit de tableur de type «Excel» (dont le format exact du fichier est défini de commun accord) pré-encodé par les outils de REVER. Le schéma 16 montre un exemple d une telle correspondance : on y retrouve les rubriques de la base SOURCE et celles de la base CIBLE. On notera qu une rubrique CIBLE peut être alimentée par plusieurs rubriques SOURCE et inversement une rubrique SOURCE peut alimenter plusieurs rubriques CIBLE. Une fois les correspondances définies celles-ci sont intégrées dans les outils de REVER par des automates. Ce processus peut se faire de manière incrémentale, au fur et à mesure des définitions. s il s agit des outils de REVER, la correspondance est établie au moyen d un outil interactif permettant de relier une entité et/ou un attribut de la base SOURCE à une entité et/ou un attribut de la base CIBLE. Un exemple d utilisation de cet outil est fourni par le schéma 17. lorsqu une ligne est en jaune, cela signifie qu il y a un attribut SOURCE qui «correspond» à un attribut CIBLE présent dans l autre partie de la fenêtre. (la ligne en bleu étant la ligne sélectionnée) ; si l on sélectionne une ligne jaune, la ligne correspondante est sélectionnée dans l autre partie de la fenêtre ; les lignes rouges représentent les objets qui ont un correspondant dans une autre table du schéma ; si l on sélectionne une ligne rouge et que l on clique sur le bouton «Find», la table qui contient une ligne qui «correspond» est affichée dans l autre partie de la fenêtre ; les lignes en blanc représentent les objets qui n ont pas de correspondant ; Page 17

18 la colonne «Nbrmap» indique le nombre de «correspondances» d un attribut. L outil de «correspondance» illustré ci-dessus, permet de créer des correspondances entre des éléments des modèles source et cible. L outil supporte des correspondances de type N M, c est-à-dire qu une zone «source» peut correspondre à N zones «cible» et réciproquement Règles de transformations Outre l établissement des correspondances SOURCE CIBLE il convient de définir les règles de transformations qu une donnée «source» devra subir pour être «compatible» avec les exigences du S.I. CIBLE. Dans la suite, le terme «incompatibilité» est utilisé chaque fois qu une donnée CIBLE n est pas strictement identique à la définition de la donnée SOURCE correspondante (voir le point suivant au sujet de la détection des incompatibilités). Pour chacune des incompatibilités détectées, il convient au niveau fonctionnel et technique de définir des règles de transformation afin de pouvoir réaliser la migration de données. Les «incompatibilités» peuvent être classées en deux types principaux : les incompatibilités provenant des «containers» (p.ex. : les liens) les incompatibilités provenant des «contenus» Ce dernier type d incompatibilité ne présente guère de difficulté majeure et est généralement résolu au moyen de modules spécifiques de transcodage. Pour résoudre les incompatibilités de «containers» la méthode utilisée par REVER consiste à utiliser un «schéma de transformation» dont le but est de formaliser les règles de transformation. Le principe de fonctionnement est assez simple : 1. le point de départ est constitué du modèle SOURCE, du modèle CIBLE et de la correspondance SOURCE-CIBLE ; 2. un modèle dit de «transformation» strictement égal au modèle CIBLE est créé. Il y a alors deux types de correspondances : a. les correspondances modèle SOURCE modèle de transformation qui sont identiques à celles qui ont été définies pour la migration ; b. les correspondances modèle de transformation modèle CIBLE qui sont des correspondances «simples» : chacune des colonnes du modèle de transformation correspond à une colonne du modèle CIBLE ; 3. pour chacune des incompatibilités liées aux containers, le modèle de transformation est modifié au moyen des fonctions de transformation de modèle incluse dans l outil de modélisation DB-MAIN. Ces fonctions de transformation de modèle permettent de faire évoluer un modèle tout en garantissant le maintien de sa sémantique. Ces transformations sont répétées jusqu à ce qu il n y ait plus d incompatibilités entre le modèle SOURCE et le modèle de transformation. Par ailleurs, les correspondances modèle de transformation - modèle CIBLE sont maintenues ce qui permet d avoir, in fine, un continuum entre le modèle SOURCE et le modèle CIBLE. Cette approche est illustrée par l exemple du schéma 18. Page 18

19 La comparaison des modèles SOURCE et CIBLE à détecté une «incompatibilité» concernant les «adresses». En effet, dans la base SOURCE les «adresse de facturation» et «adresse de livraison» sont deux «colonnes» de la table «commande» alors que dans la base «CIBLE» elles doivent être deux lignes de la table «adresse». Pour permettre ce changement de structures la méthode consiste à définir dans le modèle de transformation une entité «adresse de facturation» et une entité «adresse de livraison». D un point de vue conceptuel, cette construction permet de considérer que la table «adresse» est le résultat du cumul de deux tables intermédiaires. Attention! Le modèle de transformation ne sert qu à la définition et à la génération des programmes de migration. Une fois généré, les programmes de migration lisent les données de la base SOURCE, effectuent les transformations, assurent les contrôles et écrivent les données dans la base CIBLE Identification des «incompatibilités» La définition des correspondances est intégrée dans les outils de REVER. Sur base de ces correspondances un outil de comparaison des schémas permet d identifier les «incompatibilités» entre les définitions des bases SOURCE et CIBLE. Le tableau ci-dessous indique les types principaux d incompatibilités détectées par l outil de comparaison. Page 19

20 Le schéma 20 illustre la démarche sur un exemple : la migration des données décrivant un «sinistre» n est pas possible sans l adjonction d une règle permettant de «rattacher» le «sinistre» à un «avenants». L outil de détection signale cette «incompatibilité» de liens par une «croix rouge» dans la colonne «calc». D autres «incompatibilités» concernant la longueur des attributs ont également été détectées : «point d exclamation orange» indiquant un «point d attention». Enfin, les «V» vert indiquent les «compatibilités» entre attributs et/ou entités. Page 20

21 3.2.5 Suivi des spécifications Outre l indicateur d incompatibilité, le rapport des «incompatibilités» comporte deux autres indicateurs dont l objectif est de permettre un suivi de l avancement des travaux. Le premier indicateur (colonne «Fct») signale si la règle de transformation nécessaire pour la résolution de l incompatibilité a été définie du point de vue fonctionnel. Le deuxième indicateur (colonne «Tech») signale si la règle de transformation nécessaire pour la résolution de l incompatibilité a été codée techniquement. Ces indicateurs n on que deux positions : Page 21

22 «rouge» : déclaré non résolues (valeur par défaut) «vert» : déclarées résolues. Chacun de ces indicateurs doit être positionné manuellement par un intervenant une fois que l incompatibilité est déclarée résolue «fonctionnellement» et/ou «techniquement». Pour les caractéristiques détectées «compatibles» (signe vert dans la colonne «calc» le positionnement «par défaut» des indicateurs «Fct» et «Tech» est un choix du projet : «rouge» oblige à valider le processus pour chacun des attributs. Enfin, il n est pas rare qu au moment de la définition des correspondances, il s avère plus «simple» de préciser une «règle» fonctionnelle que de définir explicitement les correspondances au moyen des outils(p.ex. : le champ adresse est la concaténation des champs «ligne adresse», «code postal», «commune»). Dans ce cas, il conviendra : d expliciter la règle ; de positionner l indicateur fonctionnel à et l indicateur technique à «X». Par la suite, la règle explicitée devra être codée techniquement et l indicateur technique positionné à. Le rapport «d incompatibilité» peut être demandé à tout moment et être établi : soit entre le modèle SOURCE et le modèle de transformation (point de contrôle A) : dans ce cas il identifie l état d avancement de la définition et du codage de la migration ; soit entre le modèle de transformation et le modèle CIBLE (point de contrôle B) : dans ce cas il permet de s assurer que les transformations de modèle n ont pas modifié la compatibilité des deux modèles. Page 22

23 3.3 Production des programmes Cette étape a pour objectif de produire l ensemble des programmes qui permettent que la migration puisse effectivement avoir lieu. Cette production concerne : les programmes qui composent le processus de migration les programmes qui composent le processus de sécurisation de la migration Production des programmes du processus de migration Génération des programmes d extraction Le but des programmes générés lors de cette étape est de constituer une base des données «à migrer». Cette base est strictement conforme à la base SOURCE en termes de structures et de règles mais ne contient que les données qui doivent être migrées. À partir des schémas SOURCE et des règles d extraction, les outils de REVER génèrent : les structures de la base «à migrer» ; les programmes d extraction des données de la base SOURCE et de chargement de la base «à migrer» Génération des programmes de migration À partir des modèles SOURCE, CIBLE et de TRANSFORMATION contenus dans DB-MAIN, les technologies de REVER permettent de générer automatiquement le programme de migration : on notera que les modules o de «lecture», o de «transformation» en ce compris les règles spécifiques, o de «contrôle» des données par rapport aux règles gérées par le SGBD, o d écriture sont intégrés en un programme cohérent qui permet de migrer les données vers chacune des tables de la base CIBLE. Page 23

24 L écriture elle peut, en fonction des choix du projet, être effectuée dans une base de données «migrées» dont les structures et les règles sont strictement identiques à la base CIBLE ; dans des fichiers «plats» qui sont chargés soit dans la base «migrées» soit dans la base CIBLE par les utilitaires standards du SGBD ; être effectuée directement dans la base CIBLE. Comme le montre le schéma 24, la migration s appuie sur l utilisation des MAM (Modules d Accès Métier) tant pour la lecture de la base SOURCE que l écriture dans la base CIBLE. Les MAM sont des modules d accès qui s appuie sur une «vue métier». Ils sont générés à partir de DB-MAIN selon les principes suivants : 1. premier principe : les MAM s appuient sur la connaissance du S.I. décrite dans un modèle appelé «vue métier» pour permettre la gestion (lecture, écriture, modification, suppression) de l ensemble des entités et/ou attributs appartenant à la «vue métier». Dans le cas de l exemple cicontre la «vue métier» est constitué par les données des entités «VUE CLIENT», «VUE COMMANDE», «VUE FACTURATION», «VUE LIVRAISON». Les entités et les attributs d une «vue métier» peuvent être ou non les mêmes que ceux de la base relationnelle ; 2. deuxième principe : les données à gérées sont indiquées par les «correspondances» entre la «vue métier» et la base relationnelle. Ces correspondances sont gérées par DB-MAIN. (dans l exemple : la donnée «adresse» de «vue facturation» correspond à la donnée «adresse facturation» de la table «commande» : c est donc celle-ci qui sera accédée et non la donnée «adresse» d une table «vue facturation». En d autre termes, pour un MAM il doit exister une «correspondance» entre un attribut de la «vue métier» et un attribut de la base relationnelle : cette correspondance peut-être «directe» («nom attribut» et «nom table» de la vue «métier» = «nom attribut» et «nom table» de la base relationnelle) ou Page 24

25 indirecte («adresse» de l entité «vue facturation» correspond à la colonne «adresse facturation» de la table «commande») ; 3. troisième principe : les MAM permettent de parcourir la «vue métier» en suivant les liens qui y sont définis (dans la vue métier il est possible d accéder aux «vue commandes» à partir d une occurrence de «vue client» et réciproquement il est possible d obtenir l occurrence de «vue client» à partir d une occurrence de «vue commande»). Il n est pas nécessaire que les liens aient été définis dans la base relationnelle comme «foreign key». Cette fonctionnalité permet de naviguer au sein d une base relationnelle en suivant des liens explicites ou implicites : en particulier elle permet de «passer» d une table appartenant à une BD physique à une autre table d une autre BD physique implémentées dans un autre SGBD. Le principe adoptée pour réaliser la migration consiste à considérer le modèle de transformation comme une «vue métier» commune à la base SOURCE et à la base CIBLE. A partir de cette «vue métier», il est alors possible de générer deux MAM : un qui assure la lecture des données dans la base SOURCE ; l autre qui assure l écriture dans la base CIBLE. Outre leur fonction de lecture, les MAM de lecture font appellent aux modules de transformation spécifiques (dans l exemple : le peuplement de l attribut «code adresse») Ces deux MAM sont appelés par un module «superviseur» qui assure l enchaînement des lectures (ce qui inclus les transformations), le contrôle des données et les écritures Codage des règles spécifiques de transformation Par défaut, les outils de REVER effectuent, pour les données à migrer, le transfert des données depuis la SOURCE vers la CIBLE en assurant les changements de codification (EBCDIC vers ASCII), de type de données, de format et de longueur. Dans les autres cas il est nécessaire de définir et de coder une règle «spécifique» de «transformation» de la donnée SOURCE : c est le cas, par exemple, pour une date exprimée au format «JJMMAAAA» dans un champ char(10) qui doit être migrée vers un champ de type DATE qui exige que la date soit exprimée au format «AAAAMMJJ». Pour les données qui nécessitent des règles de transformations, le codage est réalisé par les intervenants techniques sous la forme de modules «unitaires» écrit dans le langage de programmation produit par les générateurs de code source des processus de migration. Une fois écrit, chacun des codes unitaires est associé dans DB-MAIN à la donnée du schéma de transformation correspondante. Ces modules unitaires seront appelés par le programme de migration. Le tableau ci-dessous indique les transformations a effectuées en fonction du type d incompatibilités. On notera que dans ce tableau les tables et les colonnes n existant pas dans la base SOURCE sont considérées comme devant restées «vides». Il va de soi que si ce n est pas le cas il est nécessaire de développer des modules spécifiques. Page 25

26 Génération du processus de chargement de la base CIBLE Lorsque la base de données CIBLE contient déjà des données, la démarche préconisée par REVER consiste à effectuer la migration dans un premier temps, vers une base de données «intermédiaires» (base des «données migrées») vide dont les structures et les règles sont strictement identiques à la base CIBLE ; dans un second temps, «à recopier» la base «migrée» dans la base CIBLE finale. Ce phasage en deux temps permet d effectuer les contrôles de sécurisation de la migration et des données en ce concentrant uniquement sur les données migrées. Le transfert des données «migrées» vers la base CIBLE peut se faire soit par un processus de «déchargement-rechargement» classique au moyen d utilitaire du SGBD, soit au moyen de programmes de lecture-écriture générés automatiquement par les outils de REVER. Dans ce cas, les mises à jour de la base CIBLE sont effectuées en suivant une logique «métier» et non une logique «table» Production des programmes du processus de sécurisation La sécurisation de la migration a pour objectif de garantir la migration des données indépendamment des contrôles fait par les applications. Deux niveaux distincts de contrôles : un contrôle du processus de migration qui permet de garantir o l exhaustivité de la migration ; o le maintien de la cohérence des données ; un contrôle de la qualité des données après migration Génération des programmes de sécurisation de la migration Génération des programmes de contrôle de l exhaustivité Il s agit de mettre en place les processus qui permettront de garantir l exhaustivité de la migration, c est-à-dire que toutes les données qui doivent être migrées l ont bien été. Ces contrôles sont réalisés par une génération automatique : dans l environnement de la base SOURCE de programmes de comptage o du nombre d occurrence des attributs à migrer ; o de «checksum» sur les valeurs des attributs à migrer ; dans l environnement de la base CIBLE de programmes de comptage o du nombre d occurrence des attributs migrés ; Page 26

27 o de «checksum» sur les valeurs des attributs migrés ; des processus de comparaison des différents compteurs et de la visualisation des résultats Génération des programmes de contrôle du maintien de la cohérence Il s agit de mettre en place les processus qui permettront de garantir le maintien de la cohérence de la migration, c est-à-dire que tous les liens fonctionnels existants entre les occurrences de données ont bien été conservés dans le processus de migration : en d autres termes ce processus permet de vérifier que «les commandes de Monsieur Dupont» n ont pas été «attribuées à Monsieur Durand». Le comparateur est généré et effectue des lectures logiques de la base SOURCE. Pour chacune d elles le programme effectue une lecture équivalente dans la base CIBLE selon la logique de la base cible. Le contenu des deux lectures doit être identique si on ne tient pas compte des transformations. Par cette méthode et en utilisant les MAM le comparateur permet d identifier les différences dans le nombre d occurrence et les différences de valeurs Génération des programmes de sécurisation des données Cette étape a pour but de mettre en place les processus qui permettent de vérifier et de valider la totalité des valeurs des données d une base de données par rapport à des règles de gestion. En tant que tel il est directement applicable aux données de la base SOURCE par rapport aux règles de gestion SOURCE et aux données CIBLE par rapport aux règles de gestion CIBLE. Les contrôles effectués sont des contrôles exhaustifs par rapport l ensemble des règles que chacune des valeurs de la base de données est sensée respecter. Cette identification exhaustive des données «nonconformes» par rapport aux règles de gestion des données vise un double objectif : Le processus de sécurisation est réalisée sur une base de données «temporaire neutre» constituée des mêmes tables et des mêmes attributs que la base à contrôler : toutefois tous les attributs sont déclarés de type varchar et les autres contraintes sont également supprimés. La construction des structures de cette base, son chargement ainsi que l exécution des contrôles sont entièrement automatisé. Page 27

28 Les contrôles de données sont générés automatiquement par les outils de REVER à partir des modèles, ce qui inclut les contrôles de format, de cardinalité (facultatif ou obligatoire), de valeur par défaut des liens entre entités définis dans le modèle des contraintes de dépendances entre colonnes d une même table ou de tables différentes. Des règles de gestion complémentaires, non définies dans le modèle, peuvent être ajoutées manuellement dans l outil et sont pris en compte à l exécution. Une fois mis en place ce processus peut être exécuté autant de fois que cela s avère nécessaire. En pratique il est exécuté une première fois en début de projet pour vérifier l état général de la base de données SOURCE afin de pouvoir avoir le temps de corriger les anomalies détectées. Il est exécuté après la migration pour s assurer que les données migrées sont conformes aux règles de gestion de l application CIBLE. Ce processus de contrôle peut être également exécuté sur les données «à migrer» au moment de leur migration. Cela permet de s assurer que des données incorrectes n ont pas été introduites entre le moment du contrôle général et le moment de la migration. Page 28

29 3.4 Tests de la migration Cette étape a pour objectifs : de mettre en place, d exécuter et de valider les processus produit à l étape précédente ; d optimiser les processus afin de permettre une exécution optimale de la migration Mise en place des processus Le but de cette étape est de s assurer que l ensemble des processus produit au cours de la phase précédente fonctionne correctement et s enchaînent sans heurts. Outre le contrôle de la validité de chacun des processus techniques, cette étape permet de vérifier et de valider les consignes organisationnelles liées aux processus mis en place : ordonnancement des processus, parallélisassions possibles, etc. A l issue de cette étape un «manuel» de la migration est fourni Optimisation des processus Pour autant que cela soit nécessaire, cette étape a pour objectif d optimiser la performance des différents processus participant à la migration. Le but recherché est de réduire le plus possible le temps de la migration afin de permettre une bascule en production la plus rapide possible. L optimisation globale peut être réalisée par l intégration d un certain nombre de processus : par exemple le processus d extraction peut être intégré dans le processus de migration. En fonction des projets, d autres optimisation sont envisageables telles que la parallélisassions des migrations par des choix d extraction de sous-ensembles de données : ainsi, par exemple, si l application l autorise, la migration des «clients et commandes» peut être parallélisées en plusieurs migrations de «clients et commandes» par pays. Le processus de comparaison basé sur les compteurs techniques et fonctionnels est rapide. Le processus de comparaison des contenus est lui plus lourd et peut nécessiter une réduction des charges. Si telle est le cas la méthode la plus simple consiste à n effectuer ces comparaisons que sur une partie des données migrées. Le temps d exécution du processus de sécurisation est essentiellement dépendant de la volumétrie des données qui doivent être comparées pour garantir la cohérence de la migration. Un choix judicieux des données à comparer permet de minimiser le temps d exécution de cette activité. Page 29