Le problème général est toute une sous-zone de programmation appelée nettoyage des données, qui fait partie d'une plus grande sous-zone appelée intégration de données . Éviter ce genre de problèmes est probablement une des raisons principales de la migration des feuilles Excel et des raisons pour lesquelles le développeur senior ne veut pas laisser un champ devenir nul. Je ne pense pas qu'il soit déraisonnable de dire que c'est l'une des plus grandes sources de complexité des migrations de données.
Le simple fait d'utiliser NULL chaque fois que vous le pouvez est probablement une mauvaise chose à faire, sans parler de changer le modèle de données pour rendre encore plus de champs nuls. La vérification de l’intégrité d’Excel est faible ou inexistante, ce qui est probablement à l’origine de bon nombre de ces problèmes. La mauvaise chose à faire est de supprimer la vérification d'intégrité dans la nouvelle base de données et d'y déposer des déchets. Cela ne fait que perpétuer le problème et ajoute une complexité considérable aux intégrations futures, qui devront en quelque sorte traiter des données insensées.
Une partie de la différence est probablement due à l'inadéquation du modèle de données. Il s’agit en grande partie de connaître (intimement) les deux modèles de données et de savoir comment mapper l’ancien avec le nouveau. Tant que le nouveau est capable de capturer l'ancien. (Sinon, votre équipe a probablement un très gros problème.) Cela peut facilement nécessiter plus de travail que la simple copie de colonnes. Darkwing en donne un excellent exemple (ainsi que la raison pour laquelle insérer aveuglément des NULL est une mauvaise chose à faire). Si l’ancien modèle a un ReceivedDateet un InProgresspeu et que le nouveau modèle a un StartDateet ProcessingEndTime, vous devrez décider si et comment définir le fichier ProcessingEndTime. En fonction de la manière dont il est utilisé, un choix raisonnable (mais arbitraire) peut être de le régler de la même manière que leStartDate (ou peu de temps après si cela pose problème).
Cependant, une partie de la différence est probablement due à des données qui "devraient" être manquantes ou corrompues. (Probablement d'erreurs de saisie de données, de migrations antérieures ou de bogues dans les systèmes de traitement de données.) Si personne dans votre équipe ne s'y attendait, alors vous vous êtes (ensemble) engagé à consacrer 20% de votre temps au projet " presque fini. (C'était un numéro inventé, mais ça peut être loinpire que cela, ou mieux. Cela dépend de la quantité de données incorrectes, de son importance, de sa complexité, de la facilité avec laquelle les responsables des données peuvent intervenir, et d'autres facteurs.) Une fois que vous avez déterminé que les données sont "supposées être "là mais manque. Généralement, vous essayez de déterminer l'étendue du problème en interrogeant les anciennes sources de données. S'il s'agit de dizaines ou de centaines d'entrées, il s'agit probablement d'erreurs de saisie de données et les clients responsables des données doivent les résoudre manuellement (c'est-à-dire vous indiquer quelles valeurs doivent être.) S'il s'agit de millions d'entrées (ou d'une fraction significative des données) , alors vous devrez peut-être reconsidérer si vous avez correctement identifié qu'il "devrait être" là. Cela pourrait indiquer une erreur de modélisation dans le nouveau système.
Par exemple, imaginons une facture comportant des quantités et des totaux par article (mais pas le prix unitaire), sauf que certaines des quantités manquaient inexplicablement. Parler à la personne qui traite de telles factures peut produire un (ou plusieurs) des scénarios suivants: 1) "oh, une quantité en blanc signifie une quantité de 1", 2) "oh, je sais que ces articles coûtent environ 1 000 $ alors, il s'agit clairement d'un ordre pour 2 ", 3)" quand cela se produit, je recherche le prix dans cet autre système et divise et arrondit ", 4)" je le recherche dans un autre système ", 5)" il ne s'agit pas de données réelles ", 6)" jamais vu ça avant ".
Comme suggéré, cela peut indiquer certaines manières de résoudre automatiquement la situation, mais vous devez faire attention à ce que la solution s'applique à tous les cas. Il est fréquent que d’autres systèmes impliqués puissent recouper les données et c’est une bonne chose. Cependant, c’est souvent une mauvaise chose dans la mesure où il peut être difficile d’avoir accès à ces systèmes et de s’intégrer à ceux-ci pour effectuer la vérification croisée, et il est souvent évident que les systèmes entrent en conflit les uns avec les autres, pas seulement par manque de données. Certaines interventions manuelles sont souvent nécessaires et, en fonction de l’échelle, peuvent nécessiter un outillage et la création d’interfaces spécifiques à la tâche de nettoyage des données. Ce qui est souvent fait, c'est que les données sont partiellement importées, mais les lignes contenant des données manquantes sont envoyées dans une table séparée où elles peuvent être révisées.