Traitement dans l’ETL

pour gérer ces cas.

Nous allons donc nous appuyer sur notre package d’intégration pour les traiter. Le principe de base est de générer soit même le membre par défaut et de l’affecter quand on détecte l’anomalie. Cela permet d’être plus fin ou plus précis sur l’absence de valeur. On peut distinguer des cas spéciaux par exemple ou ajouter des règles métier.

Côté entrepôt de données, il va falloir créer un ou plusieurs membres inconnus. On peut le faire statiquement à la création des tables en les remplissant avec des enregistrements « statiques » ou bien le faire dans le processus de remplissage.

INSERT INTO dbo.DimProduct(ProductKey, FrenchProductName) VALUES (0, 'PRODUIT NON DETERMINE')

On peut utiliser des valeurs de clé spécifiques pour les identifier comme 0 ou des valeurs négatives.

Ensuite, il suffit juste de faire le rapprochement dans le flux de données avec des branchements conditionnels. Le plus simple étant d’utiliser la sortie « No Match » du composant Lookup (Recherche en français) vers laquelle sont redirigés les enregistrements pour lesquels la jointure n’a rien ramené. Voir figure 19. Dans cette branche, on applique sa règle métier comme ici l’attribution de notre membre factice récemment créé. Puis on réunit les branches. Voir figure 20.

On peut évidemment aller très loin dans le retraitement de ces données anormales. On peut imaginer une simple trace avec un rapport d’anomalie, une interface de ressaisie (forcément asynchrone) pour une réinjection ultérieure, un algorithme de scoring pour rechercher le membre le plus approchant, etc. Il n’y a pas vraiment de contrainte ou de limitation à ce type de traitement car on est dans un « développement » spécifique.

Nous avons toutes les libertés et la seule limite sera votre imagination. Mais attention, cette solution, même si elle est simple à comprendre, n’est pas anodine dans son adoption. Il faut en effet faire des choix fonctionnels ce qui oblige à anticiper et à discuter de votre solution avec les utilisateurs de votre projet décisionnel.

En effet, il n’y a rien de plus dangereux que des chiffres mal interprétés ou mal compris. Imaginez un responsable de service qui verrait ses chiffres basculer automatiquement dans le service du voisin parce qu’il aurait une information mal saisie ou manquante. Il faut donc connaître parfaitement vos sources de données pour faire le choix le plus adéquat, correspondant à la vision métier des utilisateurs.