Data Mapping

Objectif

Le data mapping établit la correspondance, attribut par attribut, entre un référentiel de données source et un référentiel cible. Un système hérité stocke un montant en centimes dans un entier quand la plateforme qui le remplace attend des francs dans un décimal; il encode l'absence de date par une date impossible là où la cible accepte la valeur nulle. Chacun de ces écarts appelle une décision.

Pour chaque attribut cible, la spécification de data mapping consigne deux choses: si la valeur arrive inchangée et, sinon, quelle règle la transforme. Elle est seule à les porter, puisque le programme de chargement applique la règle sans l'énoncer. La spécification sert de contrat entre l'analyse et l'équipe qui écrira le chargement. Elle devient plus tard la trace pour qui doit expliquer d'où vient une valeur.

L'exercice rend un second service, signalé par le guide de l'IIBA: il fait apparaître les défauts de qualité de la source et de la cible. Écrire la règle d'un attribut oblige à regarder ce que le champ contient. C'est là que se découvrent le champ jamais validé, la codification abandonnée dont trois valeurs subsistent, la colonne remplie par la moitié des utilisateurs. La découverte coûte peu tant qu'elle précède le premier chargement.

Usage

Quand l'utiliser

• Reprise de données vers un nouveau système: aucun lot ne part avant que la correspondance ne soit écrite et validée.
• Intégration dans un référentiel existant: fusion de portefeuilles, consolidation après rachat, alimentation d'un entrepôt commun.
• Formats hétérogènes des deux côtés: types, longueurs et codifications divergent.
• Attribut cible sans équivalent direct: calcul ou concaténation à définir.
• Traçabilité exigée: un régulateur ou un réviseur demandera d'où vient chaque valeur du système cible.
• Qualité de la source douteuse: l'exercice la mesure champ par champ, avant que les défauts n'atteignent la production.
• Chargement confié à une autre équipe ou à un prestataire: la spécification est la seule forme sous laquelle l'attente du métier parvient à qui écrit le chargement.

Quand ne pas l'utiliser

• Schéma identique des deux côtés: clonage d'environnement ou restauration, une comparaison de schémas suffit.
• Modèles de données incompatibles: le modèle cible ne prévoit aucune place pour ce que porte la source, reprendre la modélisation des données.

Description

Ce que la technique produit

Le livrable est un registre, tenu le plus souvent dans un tableur, avec une ligne par attribut cible. Le guide de l'IIBA en fixe les colonnes: entité cible, attribut cible, type de données cible, attribut ou attributs source, correspondance directe, règle de transformation.

La colonne de correspondance directe est la plus maltraitée du registre. Elle ne vaut oui que si la valeur arrive inchangée, format et unité compris. Un montant qui change d'unité, une date qui change de format, un identifiant qui reçoit des séparateurs sont des correspondances indirectes, quelle que soit l'évidence de la transformation. Un oui posé par confort laisse la règle nulle part: ni dans la spécification, ni dans la tête de qui écrira le chargement.

La source et la cible

Du côté source, l'analyse porte sur trois points: le format du référentiel (fichier délimité, tableur, entité de base de données, service), les attributs d'intérêt actuel ou potentiel, puis le type et la taille de chacun. Le troisième point demande de dépasser la déclaration du schéma: une colonne déclarée varchar(50) dont la plus longue valeur fait 18 caractères et une colonne de même déclaration remplie à ras bord posent des problèmes différents.

Du côté cible, l'analyse porte sur les attributs à créer pour recevoir la source, le type et la taille à leur donner, les attributs source à transformer avec leur règle et les champs à construire par calcul, concaténation ou mise en forme. La règle de dimensionnement est explicite dans le guide: la taille de l'attribut cible n'est jamais inférieure à celle de la source. L'égalité est le cas normal; une taille supérieure est une réserve de croissance décidée en connaissance de cause. Une taille inférieure produit une perte de données que la plupart des outils de chargement opèrent sans avertissement. Cette règle vaut pour un attribut alimenté par un seul attribut source. Un attribut construit par concaténation ou par calcul se dimensionne sur le pire cas de ses entrées, mesuré sur les données réelles.

Migration ou intégration

Le guide distingue deux usages qui n'exigent pas le même travail. La migration déplace les données source vers un référentiel neuf: la cible se dessine en partie pour les accueillir, et les conflits se limitent aux formats. L'intégration fait entrer les données source dans un référentiel déjà peuplé.

Elle suppose d'abord que les modèles de données des deux côtés coïncident, même si les schémas diffèrent. Deux schémas différents décrivent la même réalité de deux façons, et une correspondance les réconcilie. Deux modèles différents décrivent deux réalités: si la source tient un contrat par personne et la cible un contrat par ménage, aucune règle de transformation ne comble l'écart, et la question remonte à la modélisation.

Elle demande ensuite d'analyser les attributs communs aux deux référentiels et la cardinalité de leur relation, un pour un ou zéro à plusieurs selon les exemples du guide. Lorsque plusieurs enregistrements source correspondent à un seul enregistrement cible, il faut désigner celui qui l'emporte attribut par attribut, décider du sort des enregistrements liés et prévoir la table qui gardera trace de l'ancienne clé. Aucune de ces trois décisions ne se déduit des données: elles se prennent avec le métier, dans la spécification.

Conduire l'exercice

1. Inventorier les deux référentiels. Format, volumétrie, schéma, propriétaire. Obtenir le dictionnaire de données de chaque côté ou l'établir pour les attributs concernés.
2. Lister les attributs cibles à alimenter, y compris ceux qui restent à créer. Cette liste est arrêtée avant qu'on ne cherche les sources.
3. Rattacher chaque attribut cible à sa source. Un attribut, plusieurs attributs ou aucun. Le cas « aucun » est légitime et doit s'écrire: valeur constante, valeur calculée, champ laissé vide à la reprise puis complété par le métier.
4. Comparer type, taille et domaine de valeurs. Relever tout rétrécissement, toute différence de codification, toute unité divergente. Ce passage produit la plupart des lignes non directes.
5. Écrire la règle de transformation. Elle doit être assez précise pour être exécutée sans question et assez lisible pour être validée par le propriétaire métier de la donnée. Les deux exigences tiennent ensemble si la règle nomme les valeurs concrètes plutôt qu'une intention.
6. Faire valider les règles par le métier. Les codes hérités, les valeurs sentinelles, les catégories « divers » et les exceptions historiques sont connus de quelques personnes, rarement documentés et jamais déductibles du schéma.
7. Profiler la source contre la règle écrite. Compter les valeurs qui ne s'y conforment pas, avant le premier essai de chargement. Une règle qui couvre 99,4% des enregistrements laisse un reliquat dont le traitement se décide maintenant.
8. Geler une version, puis la tenir. Le guide signale la limite: la spécification doit être mise à jour dès qu'un changement survient d'un côté ou de l'autre.

La frontière avec l'ETL, le dictionnaire et le diagramme de flux

Le data mapping déclare, l'ETL exécute. La spécification énonce la correspondance et la règle; le traitement les applique aux enregistrements, avec sa planification, sa reprise sur erreur et ses journaux. La frontière se lit au livrable: un document que le métier lit et valide d'un côté, un traitement qui tourne de l'autre. Le guide situe dans l'étape de chargement de l'ETL la production des pistes d'audit des données modifiées ou remplacées, ce qui place du côté du traitement les contrôles menés après le chargement.

Le dictionnaire de données intervient en amont. Il fixe le nom, les alias, le sens, le format et les valeurs admises de chaque élément, et le guide le désigne comme une aide à la conduite du data mapping. Le dictionnaire dit ce qu'est le champ; la spécification dit ce qu'il devient. Sans le premier, la correspondance s'écrit sur des noms de colonnes.

Le diagramme de flux de données répond à une autre question: quel processus déplace quelle donnée entre quels magasins, à quel niveau de décomposition. Il montre que les données de l'assuré vont du système hérité vers la plateforme cible. La spécification de data mapping dit ce qui arrive à la date de sortie en chemin.

Ce qui fait échouer l'exercice

La valeur sentinelle recopiée telle quelle. Un système hérité qui n'accepte pas la valeur nulle encode l'absence par une valeur impossible: une date au 31.12.2099, un montant à 0, un code à 999. Copiée sans règle, la sentinelle devient une donnée plausible. Un contrat de travail se termine en 2099 dans les rapports, un salaire nul entre dans un calcul de cotisation. Le repérage se fait au profilage, en regardant les valeurs les plus fréquentes de chaque champ.

La correspondance écrite sur le nom de la colonne. Deux champs nommés client désignent le ménage dans un système et le payeur dans l'autre; deux champs date_debut désignent la signature dans l'un et la prise d'effet dans l'autre. La similitude des noms est une hypothèse à vérifier auprès de qui remplit le champ.

La règle qui vit dans le code du chargement. Une transformation décidée en séance et implantée dans le traitement, sans retour dans le registre, cesse d'être auditable le jour où son auteur change de mandat. La traçabilité champ à champ suppose que la déclaration existe ailleurs que dans le code qui l'applique.

La cardinalité découverte au chargement. Un rejet pour violation de contrainte d'unicité, la veille de la bascule, signale une analyse d'intégration non faite. Désigner l'enregistrement qui l'emporte est une décision de gestion; la prendre sous pression, une nuit de reprise, revient à la laisser prendre par la personne de garde.

La spécification périmée. Une reprise dure des mois, pendant lesquels les deux systèmes évoluent. Sans un point de contrôle à chaque changement de schéma, le registre décrit un état passé et le chargement échoue sur des colonnes qui ont bougé. Rattacher la spécification au contrôle des changements des deux systèmes coûte peu et se fait au début.

Considérations IA

Les outils d'intégration proposent des correspondances candidates par similarité de nom, de type et de contenu échantillonné; un modèle de langage fait de même sur deux listes de colonnes, en reconnaissant les abréviations et les conventions de nommage hétérogènes. Sur un schéma de quatre cents colonnes, ce rapprochement automatique retire la part mécanique du travail et laisse à l'analyste les lignes qui demandent un arbitrage.

Traduire « date au format jj.mm.aaaa vers ISO, valeur 31.12.2099 vers nul » en expression SQL ou en transformation d'outil est un travail de code répétitif, décrit de bout en bout par sa spécification, dont un premier jet se relit vite. Les jeux d'essai couvrant les cas limites de la règle s'obtiennent de la même façon. Le profilage relève du même usage: décrire un champ inconnu par ses valeurs distinctes, ses longueurs, son taux de nullité et ses valeurs hors domaine se demande en langage courant, et le résultat sert à confronter la règle écrite au contenu réel.

Le rapprochement se fonde sur des noms et des types, et l'outil livre ses propositions avec la même assurance qu'elles soient justes ou fausses. Ce qu'un champ signifie dans l'organisation, à partir de quand il a été rempli, quelle codification il portait auparavant, ne se trouve pas dans le schéma. Une correspondance acceptée sans relecture métier produit une erreur par enregistrement. Les décisions de regroupement échappent aussi à l'outil: choisir quelle succursale d'un employeur fusionné devient l'enregistrement de référence est un arbitrage de gestion.

Reste la donnée elle-même. Un extrait de production fourni à un service tiers pour « l'aider à comprendre le champ » contient des numéros AVS, des salaires et des dates de naissance, donc des données personnelles au sens de la loi fédérale sur la protection des données (LPD). La communication à un tiers est un traitement: elle demande un motif justificatif, l'information des personnes concernées et, si le tiers agit pour le compte de la caisse, un contrat de sous-traitance. Le schéma seul, ou un extrait masqué, répond à la même question.

Exemples

Une caisse de pension migre ses enregistrements d'assurés d'un système d'administration hérité vers une nouvelle plateforme.

Une ligne sur six est directe. Les cinq autres portent chacune un type de règle différent: mise en forme, concaténation, changement d'unité, valeur sentinelle, regroupement. La troisième montre la limite de la règle de dimensionnement: deux sources de 40 caractères et une espace donnent 81 caractères pour une cible de 80, donc une troncature décidée et journalisée. La dernière ne se déduit d'aucune donnée du système hérité: elle repose sur une table de correspondance que le métier construit à partir de l'historique des fusions d'employeurs. Cette table est un livrable du data mapping au même titre que le registre lui-même.

Visualisations

La spécification se rend en tableau: en faire une image lui ferait perdre la sélection, le tri et la comparaison d'une version à l'autre. Ce qui se dessine, c'est la place de la technique parmi ses voisines: qui définit, qui déclare, qui exécute.

Un registre rempli se relit par sa colonne de correspondance directe. On y retient d'abord les lignes portant « non », et on vérifie sur chacune deux points: que la règle nomme des valeurs concrètes plutôt qu'une intention et que la taille cible couvre celle de la source. Restent les lignes sans attribut source, dont chacune doit porter une disposition écrite, valeur constante, valeur calculée ou champ laissé vide à la reprise. Le chemin qui mène un attribut cible à sa ligne de registre tient en trois questions posées dans l'ordre.

Coût

Outils

Le tableur est le format d'origine de la technique et il suffit à la plupart des reprises: une feuille par entité cible, une ligne par attribut, les six colonnes du registre. Ses faiblesses apparaissent à l'échelle, quand plusieurs centaines de lignes évoluent en parallèle sans contrôle de cohérence ni historique lisible des versions. Le versionner dans le dépôt du projet, en format texte, corrige la seconde faiblesse à peu de frais.

Les outils d'intégration et d'ETL (Talend, Azure Data Factory, SQL Server Integration Services, Informatica, dbt) portent la correspondance dans l'objet même qui l'exécute, ce qui supprime l'écart entre la règle déclarée et la règle appliquée. Le prix est la lisibilité: une transformation exprimée dans l'outil se valide mal par le propriétaire métier, dont l'accord conditionne pourtant la règle. La pratique qui tient consiste à garder un export lisible du mapping, généré depuis l'outil, plutôt qu'un second document tenu à la main.

Les catalogues de données et outils de lignage tiennent la correspondance comme une métadonnée réutilisable, avec la trace du parcours de chaque champ entre systèmes. Le DMBOK traite cette traçabilité sous la gestion des métadonnées. Cette option se justifie quand plusieurs projets successifs mappent les mêmes systèmes.

Les outils de profilage de données rendent visibles en quelques minutes les sentinelles et les codifications abandonnées qu'aucune lecture de schéma ne révèle.

Sources

• IIBA, Guide to Business Data Analytics, §3.6 Data Mapping: la source des deux usages migration et intégration, du travail au niveau de l'attribut, de la règle de dimensionnement de l'attribut cible, des colonnes de la spécification, ainsi que des forces et limites de la technique.
• IIBA, Guide to Business Data Analytics, §3.10 Extract, Transform, and Load (ETL): les étapes d'extraction, de transformation et de chargement, ainsi que la production des pistes d'audit des données modifiées ou remplacées lors du chargement.
• IIBA, Guide to Business Data Analytics, §3.4 Data Dictionary: le dictionnaire de données comme aide à la conduite du data mapping.
• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, 2^e édition, chapitre 12 Metadata Management: le lignage des données, origine d'un élément et transformations subies, comme objet de la gestion des métadonnées.
• Loi fédérale sur la protection des données (LPD), RS 235.1: art. 9 sur la sous-traitance, art. 19 sur le devoir d'informer et art. 31 sur les motifs justificatifs, cités pour la communication d'extraits de production contenant des données personnelles.