Conseil 9: Traiter les dimensions à évolution lente durant un chargement initial de données

L’article précédent a clairement défini la technique des dimensions à évolution lente de type 2 et la bonne utilisation des clés de substitution. Ce mois-ci nous abordons la question épineuse du traitement des dimensions à évolution lente lors du chargement initial d'un nouveau domaine au sein d'un entrepôt de données. Cela peut se produire lorsque vous introduisez une nouvelle mesure (fait) dans un entrepôt de données existant par exemple. Des dimensions tels que Produit, Client, et Temps sont probablement déjà définies et possèdent un riche historique reflétant de nombreuses évolutions lentes.

Tout d’abord, je vais décrire le traitement ETL classique tel qu’il se passerait chaque nuit:

Les dimensions sont traitées en premier. Les nouveaux enregistrements provenant de la source de données sont insérées dans les tables de dimension en leur affectant une nouvelle clé de substitution. Les enregistrements déjà présents dans la dimension et qui ont changés depuis le dernier chargement de l'entrepôt sont repérés et la nature de leur changement examinée. Une politique de traitement des dimensions à évolution lente décidera, sur la base des champs qui ont changé, si l’enregistrement actuel dans la dimension devra être mis à jour en écrasant celui existant et perdre ainsi les anciennes valeurs (type 1) ou bien si ce nouvel enregistrement, possédant le même identifiant naturel, devrait être créé en utilisant une nouvelle clé de substitution (type 2).

Après avoir traité toutes les dimensions, il est temps de passer au chargement en masse des faits. Ici la vitesse est la clé. Les identifiants naturels doivent être supprimé de la table de faits et remplacés par les bonnes clés de substitution aussi rapidement que possible. Idéalement, nous voulons tirer profit du traitement en mémoire offert par la plupart des outils ETL moderne. Ainsi, de petites tables de conversion qui, pour chaque dimension, traduisent l‘identifiant naturel en clé de substitution sont crées à partir des tables de dimensions présentes dans l'entrepôt en utilisant des instructions similaires à celles ci-dessous:

Client_TableTemp:

SELECT Client_ID, max(Client_Clé) 
FROM Client

GROUP BY Client_ID

ou

Client_TableTemp:
SELECT Client_ID, Client_Clé 
FROM Client

WHERE Enreg_Actuel = 'Y'

En faisant cela, les tables de conversion contiendront les clés de substitution correspondantes aux nouveaux faits.

Cependant, cette technique simple et efficace ne sera pas suffisante si nous voulons charger une quantité considérable de faits lors d'un premier chargement. Par exemple, imaginez la situation où nous voulons commencer par charger deux années de transactions et que nous avons la "chance" d'avoir les deux mêmes années d'historique dans le fichier des Clients. Les transactions et les clients n'ont peut-être jamais été croisés dans un rapport auparavant, mais nous tenons à les faire correspondre parfaitement dans le nouveau datamart. Nous souhaitons également partitionner correctement l'historique.

La table de conversion de la dimension Client devrait contenir l’historique des clés de substitution de chaque changement ayant eu lieu durant ces deux ans. La requête SQL pour une recherche simple qui devait ressembler à celle-ci

SELECT Client_Clé
FROM Client_TableTemp CL

WHERE CL.Client_ID = Transaction.Client_ID

doit être remplacée par:

SELECT Client_Clé
FROM Client_TableTemp CL

WHERE Client_ID = Transaction.Client_ID 
       AND Transaction.Transaction_Date BETWEEN CL.Date_Debut AND CL.Date_Fin

Le problème est que l’instruction "BETWEEN" ralentira le traitement si nous devons charger quelques centaines de millions de lignes de faits associées à une dizaine de dimensions. Ajouté à cela que vous avez maintenant deux traitements d'alimentation de la table de faits très différents. Si jamais vous utilisez ce type de traitement pour un chargement initial, vous devez vous en débarrassez pour construire, tester et maintenir une version plus simple qui charge progressivement la table de faits à partir de maintenant.

Bien qu’étant une sorte de compromis, la réponse à ce problème est d’une séduisante simplicité. Ne créez pas de chargement en masse, créez uniquement le chargement incrémental. Cette technique fournit une version beaucoup plus réaliste de l'histoire que d'attacher simplement tous les faits passés aux valeurs actuelles des dimensions et promettre qu'à partir de maintenant les évolutions lentes se feront; ce qui est souvent la stratégie adoptée lors d'un chargement de masse initial. Voici donc ce que je vous suggère de faire:

Prenez les deux années à charger et divisez les en cent quatre traitements, chacun représentant une semaine de transactions, et exécutez les les uns après les autres par ordre chronologique. Commencez chaque traitement en chargeant uniquement l'historique des dimensions de la semaine concernée, c'est à dire, les enregistrements où le champ Date_Début est inférieur ou égal à la date de transaction minimum. Même si cela signifie un peu de travail supplémentaire dans les phases de maintenance des dimensions, le chargement des faits peut fonctionner sans modification. Cela peut se faire parce que les tables de conversion contenant les clés de substitution possèdent les dernières clés valables pour la période à charger. Vous venez juste de lancer 104 chargements incrémentaux. Le compromis est que certains enregistrements de la table de faits seront joint à des enregistrements de dimension de la semaine précédente. Dans la plupart des cas, cela représente une faible marge d'erreur parce que les dimensions changent lentement.

Source originale: www.kimballgroup.com

Article original "Kimball Design Tip #9: Processing slowly changing dimensions during initial data", publié le 22 juin 2000.