La programmation des règles

La phase de réalisation doit permettre de développer les programmes (ou requêtes) et les outils nécessaires pour effectuer la migration des données du système source vers le système cible.

On rappelle le schéma simplifié de la démarche :

Les déchargements

Cette étape permet de réaliser la mise à plat de tous les fichiers (ou tables) du Système d’Information source, fichiers qui vont être repris par les programmes de migration.

Ces programmes sont réalisés par des experts du système source.

Suivant le type de SGBD, il est possible d’utiliser des utilitaires systèmes qui génèrent les fichiers à plat.

Il est préférable d’utiliser le plus possible ce type d’outils, car l’écriture de programmes spécifiques de déchargement est beaucoup plus coûteuse.

Plusieurs points sont à prendre en compte lors de ces opérations :

Être exhaustif dans la liste des tables à décharger.

Même si les données à décharger ne sont spécifiées que lors des spécifications des règles de migration, il est toujours possible de définir par avance les fichiers à produire.

Une demande tardive de déchargement de données provoque systématiquement un retard dans le processus de reprise.

Anticiper le plus tôt possible ces déchargements.

Disposer rapidement des données source permet de vérifier qu’elles correspondent bien aux formats qui ont été donnés par les experts (voir la section suivante sur l’audit des données)....

Audit des données source

On entend par audit l’analyse des données source.

Lors des spécifications des règles, on a vu que l’on commençait par prendre en compte la description des données cible et source.

L’audit consiste à décharger les tables ou fichiers du système source et de vérifier si les descriptions et le contenu des données sont conformes à ce qui a été indiqué lors des spécifications.

1. Anomalies de description

Dans tous les projets de migration de données, il existe des décalages de description entre celle qui a été donnée par les experts du système source et la table qui a été déchargée.

Les anomalies les plus courantes interviennent sur :

des décalages de longueur de zones, voire de lignes ;
des différences sur le format des données ;

Une zone peut être décrite en numérique alors qu’en réalité elle peut contenir des caractères.

Une zone va être packée, alors que ce n’était pas indiqué dans la description.

des zones sont décrites comme des « fillers » (zones neutres) alors qu’elles contiennent des valeurs.

2. Anomalies sur le contenu des données

Le contrôle effectué sur la conformité de la description des données par rapport à la réalité est important, mais l’analyse du contenu l’est encore plus.

En effet, c’est lors de ces audits que l’on constate que les valeurs récupérées dans les tables déchargées ne sont pas conformes aux valeurs attendues, définies par l’utilisateur lors des spécifications de règles.

Par exemple, on va constater que de nombreuses lignes ont un code à blanc, alors qu’il devrait être systématiquement renseigné, car c’est une clé des données du système cible.

Les incohérences détectées à l’occasion de ces audits ont toujours une influence sur les spécifications des règles.

On voit donc tout l’intérêt d’effectuer ces audits le plus tôt possible, en parallèle des spécifications de règles, plutôt...

Les rechargements

Cette étape permet de charger les fichiers issus de la migration de données dans les tables du Système d’Information cible.

Les programmes effectuant cette opération doivent être des utilitaires standards du système cible, différents suivant le type de système de gestion de bases de données (SGBD) implémenté.

On rappelle qu’il est préférable que les programmes de migration ne chargent pas directement les données dans les bases cible, afin d’avoir une certaine indépendance vis-à-vis des environnements techniques cible.

Lorsque ce principe est mis en œuvre, il faut s’assurer que les programmes de rechargement des données cible se sont bien déroulés et que le nombre d’enregistrements chargés est bien égal au nombre d’enregistrements du fichier en sortie de la migration.

Conseils pour la réalisation des programmes

L’expérience acquise lors de plusieurs projets de migration de données amène quelques conseils :

Choix des outils de développement

Il est évident, mais pas inutile, de rappeler que les outils de développement doivent être performants et surtout maîtrisés.

On peut être tenté de vouloir utiliser des AGL (ateliers de génie logiciel) qui existent sur le marché et qui proposent des fonctionnalités intéressantes et qui sont très souvent performants.

Mais encore faut-il s’assurer que le produit utilisé :

soit référencé dans d’autres entreprises ;
soit maintenu au cas où on rencontrerait des bugs ;
soit facilement utilisable, avec un langage connu ;
et qu’il existe des ressources suffisantes et disponibles pour l’utiliser.

Sauvegarde des sources

Les programmes réalisés pour la migration de données évoluent régulièrement en fonction des nouvelles règles de migration.

Ces programmes doivent faire l’objet d’une sauvegarde journalière, garantissant la stabilité des développements.

Gestion des versions

Les programmes doivent pouvoir être versionnés, car la base de données cible évolue en même temps que les programmes et on doit s’assurer de la cohérence...

Réalisation