Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Migration de données
  3. Quelques principes avant de commencer
Extrait - Migration de données D'un Système d'Information à l'autre : la démarche complète (2e édition)
Extraits du livre
Migration de données D'un Système d'Information à l'autre : la démarche complète (2e édition) Revenir à la page d'achat du livre

Quelques principes avant de commencer

Analyse des données source/cible dans la phase de spécifications

Une des premières phases de la migration de données est la spécification des règles de migration. Lors de cette phase, on doit s’intéresser à la description des données source et à celle des données cible.

Question : Faut-il commencer par la cible ou par la source ?

Premier principe : il faut toujours partir du système cible pour ensuite s’intéresser au système source.

C’est-à-dire qu’il faut commencer par comprendre le fonctionnement du système cible et comment sont organisées les données, pour ensuite identifier dans la source les données qui permettront de les alimenter.

Ce point est primordial, car il ne faut pas oublier que l’objectif final est de faire fonctionner correctement le système cible. De ce fait, il faut vérifier que toutes les données cible sont bien alimentées, ou si elles ne le sont pas, que cela soit en connaissance de cause.

Cette approche est souvent difficile à mettre en œuvre, car lors de la construction d’un nouveau système, le modèle de données cible évolue et n’est stabilisé que peu de temps avant la bascule.

Il est courant de voir des projets de migration dont l’analyse débute par le système source, et où...

Lotissement du projet

Deuxième principe : un projet de migration doit être organisé par lots de migration

Il est recommandé de définir un premier lot sur un périmètre restreint. Ce lot va servir de lot pilote qui permet de dérouler tout le process de reprise des données en avance de phase par rapport au reste du périmètre.

On peut ainsi valider très rapidement la démarche et détecter des problèmes en fin de process, en Certification Statique par exemple, qui engendreraient des modifications de l’organisation et/ou de la démarche en amont. Mieux vaut s’en rendre compte au plus vite...

Pour effectuer le lotissement, il faut partir du modèle de données cible et définir des groupes de tables cohérentes entre elles d’un point de vue fonctionnel.

Si le lotissement est effectué à partir du modèle source, on risque de ne pas pouvoir dérouler tout le process de migration, jusqu’au chargement des données cible.

En effet, l’alimentation d’une table cible peut nécessiter des données de plusieurs tables source. De ce fait, cette table ne pourra être chargée et contrôlée que lorsque toutes les tables source contenant des données nécessaires à sa migration auront été étudiées....

Déchargement des données source et rechargement des données cible

Pour illustrer notre démarche, il faut décomposer le process de migration des données en suivant ce schéma :

images/DP02-02.png

Les données source sont déchargées dans des fichiers à plat. Ce sont ces fichiers qui sont en entrée de la migration.

Troisième principe : réaliser les programmes de migration sur des données déchargées du système source et non directement sur les données source.

De même, la migration génère les données cible dans des fichiers à plat qui sont ensuite chargés sur le système cible. Les programmes de reprise ne chargent pas directement les données dans les tables cible.

Quatrième principe : les programmes de migration génèrent les données cibles dans des fichiers à plat et non directement sur les données cible. Les fichiers à plat sont chargés ensuite dans les tables cible.

Cette approche permet :

  • de travailler sur une image des données source assurant une indépendance vis-à-vis des environnements techniques sur lesquels sont stockées les données. Il en est de même pour la génération des données cible. La migration peut être complètement autonome.

  • d’initialiser les données source...

Rejets ou anomalies

Lors de la formalisation de spécifications des règles, on est amené à effectuer des contrôles sur les données source qui vont permettre d’alimenter les données cible.

Ces contrôles peuvent faire l’objet de rejets ou d’anomalies.

Ces notions de rejets et d’anomalies sont à définir clairement.

1. Rejet

Lors du traitement de reprise d’une table source, on va devoir, ligne par ligne, effectuer des contrôles sur les données source, pour ensuite les mapper avec une donnée cible.

Si le contrôle détecte une erreur, on peut décider de mettre en rejet la ligne complète en cours de traitement et de continuer le process de reprise sur les autres lignes.

2. Anomalie

La différence avec un rejet est que la ligne en cours de traitement est prise en compte dans le process de reprise.

Afin que les données chargées permettent le fonctionnement normal du système cible, on spécifie une valeur par défaut qui sera systématiquement chargée en remplacement de la valeur source en anomalie.

Cinquième principe : proscrire les rejets.

En effet :

  • L’expérience montre que générer des rejets bloque le process de migration. Rejeter tout un enregistrement nécessite de corriger les anomalies, ce qui prend nécessairement du temps avant...

Documentation projet

Le cinquième principe concerne la documentation projet.

Il est essentiel que soit organisé l’ensemble des informations utilisées dans le process de migration, à savoir :

  • la description des données source ;

  • la description des données cible ;

  • les dossiers de spécifications des règles de migration ;

  • les tables de paramétrage ;

  • les tables de transcodification, qui permettent d’attribuer une nouvelle valeur à certaines données.

L’expérience montre très souvent des données cible et source dont les formats de description sont différents. Certaines sont sous forme de fichiers Word et d’autres sous forme de fichier Excel.

Une bonne démarche consiste à centraliser toutes ces informations dans un même espace de stockage, de façon cohérente.

On verra par la suite que l’idéal est de disposer d’un outil (par exemple sous Access) permettant d’intégrer l’ensemble des informations recensées.

Avec un tel outil :

  • l’équipe projet accède aux informations à un seul endroit ;

  • les recherches de correspondance entre données cible et source sont grandement facilitées ;

  • les règles de migration sont plus facilement exprimées ;

  • les tables de paramétrage et de transcodification sont centralisées ;

  • il est plus...