Tâche: Définition de la migration de données
Cette tâche décrit comment migrer une source de données existante vers une base de données cible.
Objet
  • L'objectif de cette tâche est de spécifier la migration des données en définissant sa portée, son profil de données et le mappage entre les sources de données et la base de données cible.
Relations
RôlesPrincipal: Complémentaire: Auxiliaire:
EntréesObligatoire: Facultatif: Externe:
  • Aucun
Sorties
Etapes
Définir la portée de la migration
Objectif :  Définir la portée de la migration

La première tâche à effectuer lorsque vous prévoyez de migrer des données vers une nouvelle base de données est de définir la portée de la migration. Voici quelques éléments spécifiques :

  • Identification des sources de données à migrer et de leur emplacement.
  • Identification des systèmes utilisant les sources de données actuelles et des systèmes qui utiliseront la nouvelle base de données.
  • Identification des données qui ne sont pas au format électronique et de la façon de les saisir dans le nouveau système.
  • Choix de la suppression ou nom de la source de données après la migration. Si la source de données doit continuer à être utilisée, la maintenance des données dans la source originale et la nouvelle base de données peut poser des problèmes.

De plus, vous devez identifier le sous-ensemble pertinent de la source de données. Les projets de migration de données ne se déroulent pas de façon indépendante. Ils sont plutôt le fruit d'autres efforts de développement, comme des projets visant à faire évoluer ou remplacer un système en vigueur. Le volume des données existantes devant être migrées dépend des besoins de ces efforts de développement car il est rarement pertinent de migrer toutes les données du système existant. Vous trouverez ci-dessous des exemples d'éléments pouvant vous aider à déterminer la portée :

  • Les données existantes de l'ancien système peuvent ne pas pouvoir être converties au format du nouveau système. Par exemple, elles peuvent ne plus avoir la même signification car la structure des données est modifiée.
  • Les données historiques des années précédentes peuvent n'être conservées qu'à un niveau résumé.
  • Des dispositions fiscales obligatoires peuvent nécessiter de conserver pendant un certain temps des données historiques détaillées mais pas nécessairement leur conversion

Idéalement, la fin de la migration des données doit immédiatement être suivie de l'exécution de production du nouveau système. Cependant, lorsque les données sont très volatiles ou volumineuses ou lorsque la validation de la migration est un processus très long, il peut être nécessaire de corriger les données migrées. C'est particulièrement le cas lorsque des données manuelles doivent être collectées, vérifiées puis saisies dans le système automatisé. Dans ces conditions, l'enregistrement des données peut prendre de nombreux mois.

Dans ce cas-là, il peut être nécessaire de prévoir et de définir des procédures de maintenance permettant de garder à jour les données migrées pendant la période comprise entre la fin de la migration des donnée et le lancement de l'exécution de production. Ces procédures doivent trouver le juste équilibre entre économie (elles ne seront normalement pas utilisées longtemps) et fiabilité (elles ne doivent pas générer d'erreurs dans les données converties). Elles doivent également intégrer des contrôles et de traces de contrôle, si nécessaire.

Comprendre les sources de données grâce aux profils de données
Objectif :  Etablir le profil de données des différentes sources de données

Maintenant que vous avez identifié les différentes sources de données, vous pouvez commencer à les analyser afin de déterminer leur profil de données. Le profil de données est un ensemble d'informations relatives au contenu, à la structure et à la qualité des données. Il sera enregistré dans la spécification sur la migration des données.

Voici la procédure détaillée permettant d'établir le profil de données :

Rassembler les informations

La première étape pour établir le profil de données est de rassembler les métadonnées décrivant les sources de données. Cela peut inclure des programmes source, des descriptions de référentiel ou de dictionnaire, des informations relatives à un catalogue relationnel, la documentation d'un projet précédent et toute autre information pouvant permettre de comprendre les données. Si le système a été développé avec le processus RUP, vous pouvez utiliser le modèle de données, les cas d'utilisation et les réalisations de cas d'utilisation comme sources pour comprendre la façon dont le système utilise les données. Il peut également être utile d'interroger les développeurs d'origine ou l'administrateur de base de données qui gère les données.

Cependant, la documentation (autre que les informations automatiquement gérées dans le cadre du système ou obtenues par génération de code) doit être considérée avec circonspection. Elle a été valide à un certain moment mais elle perd en fiabilité avec le temps. Les systèmes en vigueur sont souvent peu documentés lors de leur création et la documentation est rarement mise à jour lorsque des modifications sont effectuées. Même si les métadonnées existantes ne sont pas à jour, elles souvent les seules informations disponibles à propos des sources et sémantiques de données. Le processus de définition de profil expose les discordances entre les métadonnées et les données réelles et complète les parties importantes des informations manquantes.

Analyser les sources de données

La deuxième étape de l'identification d'un profil de données est le développement d'un plan des sources de données. Ce plan indique comment les zones de données sont enregistrées et détermine des règles pour les redéfinitions et les groupes de données qui se répètent dans les structures de données.

Si la source de données est relationnelle, le plan peut être extrait directement du schéma de la base de données. Dans la mesure où ces structures sont appliquées par le système de gestion de base de données, il n'est pas nécessaire de mettre en doute leur validité.

Si la source de données n'est pas relationnelle, vous devez utiliser les métadonnées en conjonction avec les données pour obtenir les données de façon normalisée. Vous devez porter une attention toute particulière aux attributs de surcharge. La surcharge est le processus d'enregistrement de faits multiples dans le même attribut.

Une fois cette étape de l'identification du profil de données terminée, vous pouvez procéder à une extraction échantillon des sources de données, dans le format normalisé, afin de poursuivre le processus d'identification du profil. Généralement cette extraction se fait avec les scripts d'extraction des composants de migration car c'est également une bonne façon de les tester.

Etablir le profil des attributs de sources de données

La troisième étape de l'identification du profil de données consiste à déterminer le contenu, le domaine et la qualité des données de chaque attribut et d'établir la sémantique de chaque attribut. Il est important d'effectuer cette opération sur la source de données elle-même car les métadonnées documentées peuvent être incorrectes.

Cette opération vous permet d'identifier :

  • Les attributs documentés pour une utilisation mais utilisés pour une autre
  • Les attributs documentés mais non utilisés
  • Les incohérences entre le contenu des données d'un attribut et sa signification sémantique
  • La cardinalité de l'attribut afin d'identifier les attributs morts (ceux ne contenant qu'une valeur)

Les systèmes en vigueur et même les systèmes relationnels utilisent généralement la "dénormalisation" et les doublons de données en raison de leurs tentatives d'amélioration des performances. Le support de clé principale et de clé externe est également souvent déficient. Cela signifie que vous devez analyser les tables source pour déterminer les dépendances fonctionnelles entre les attributs et pour identifier les clés principales et externes.

Une fois le profil établi, vous devez le revoir à deux différents niveaux. Le premier niveau consiste à décider si l'attribut doit être migré ou non. Vous pouvez décider de ne pas migrer un attribut s'il ne contient aucune information utile ou si la qualité des données est tellement médiocre que celles-ci ne peuvent pas être migrées sans corrompre la cible. Le second niveau consiste à déterminer si les attributs doivent être vérifiés au cours de la migration.

Lorsque des problèmes de qualité sont découvert lors de l'identification du profil, vous devez nettoyer les données, en supprimant ou modifiant les données incorrectes, en double, au format incorrect ou incomplètes. Cette opération est généralement appelée vérification de données.

Définir le mappage entre les sources de données et la base de données cible
Objectif :  Décrire le mappage entre les éléments de la base de données source et les éléments correspondants de la base de données cible

Les deux principales entrées de cette étape sont le profil de données établi dans l'étape précédente et le modèle de données physiques de la base de données cible.

De nombreuses personnes pensent, à tort, que le mappage des données peut être effectué sur des modèles de données logiques. Cependant, dans la mesure où les données source sont au format de données physiques et que nous devons migrer ces données dans le nouveau modèle de données physiques, il est plus pratique de mapper ces deux formes de données physiques que de procéder à un mappage indirect via un modèle de données logique.

Les considérations suivantes doivent être prises en compte :

  • Gestion des conflits lorsqu'il existe de nombreuses sources pour un même attribut cible.
  • Méthode d'obtention des données lorsqu'il n'y a aucune source pour un attribut.

Pour effectuer correctement cette étape, rup_database_designer_legacy doit être associé à un concepteur métier ayant une connaissance approfondie des données à migrer et à un analyste système connaissant à la fois le système source et le système cible.

Le mappage doit être enregistré dans les Spécifications sur la migration de données.

Les deux principales entrées de cette étape sont le profil de données établi dans l'étape précédente et le modèle de données physiques de la base de données cible.

Identifier la migration de données manuelle et automatique
Objectif :  Identifier quelle partie des sources de données doit être migrée automatiquement et celle qui doit être migrée manuellement.

Une fois les profils de données définis et le mappage des différentes sources de données effectué, vous devez identifier quelle partie de la migration de données peut être effectuée automatiquement et quelle partie des données doit être migrée avec des procédures manuelles.

La Technique : Conception de sous-système de migration de données donne des indications sur la façon de concevoir les composants pour effectuer une migration automatique des données.

Dans la mesure du possible, l'entrée de données converties manuellement doit se faire en utilisant les processus standard d'entrée de données du nouveau système. Parfois, il est inévitable de recourir à des processus de conversion conçus spécifiquement. C'est le cas par exemple pour une grande quantité de données entrées par lots, normalement de façon interactive mais les volumes sont parfois trop importants et rendent l'entrée interactive peu pratique.

Les données migrées manuellement peuvent être identifiées dans la table de mappage des données qui se trouve dans les Spécifications de migration de données.

Propriétés
Plusieurs occurrences
Commandé par les événements
En cours
Facultatif
Planifié
Réitérable