Le chargement incrémental de données

L’entrepôt de données ou “datawarehouse” est un élément central de l’informatique décisionnelle. Afin de conserver la traçabilité des informations et des décisions prises, les informations stockées dans l’entrepôt ne devraient, dans la mesure du possible, ne jamais disparaître : il faut donc conserver les différentes évolutions des données.

En étudiant la question, on trouve rapidement une méthode appelée Slowly Changing Dimension : celle-ci vise à effectuer un versionnement des données qui changent lentement (rarement).
Comme son nom l’indique, elle concerne avant tout le rechargement des tables de dimensions.

Différentes approches sont possibles, chacune avec leurs avantages et inconvénients :

• Ecraser par la version la plus récente : la plus facile à maintenir, mais on ne garde pas de trace des anciennes versions des données.


• Créer des enregistrements dans la même table avec des clés distinctes : ajouter à l’identifiant de la dimension une date de début d’enregistrement ou un numéro de révision, l’ensemble formant la clé primaire. L’historique est alors illimité, mais on doit alors « migrer » la date ou le numéro de révision dans chacune des tables de fait.


• Table "historique" : même schéma que la table de dimension, on garde toutes les anciennes versions. Cela oblige à garder deux exemplaires de la « même » table, et peut complexifier les requêtes de calcul.

L’algorithme du SCD consiste alors à comparer directement les données de l’entrepôt avec les données opérationnelles, puis de créer une nouvelle version et mettre à jour l’ancienne en cas de changement.

Le rechargement des tables de fait apporte d’autres problématiques.

D’une part, la quantité de données est bien plus importante, et d’autre part, les changements effectués à posteriori par les utilisateurs de la base opérationnelle sont plus difficile à prendre en compte : utiliser une détection "enregistrement par enregistrement, colonne par colonne" comme dans l’algorithme du SCD n’est plus envisageable pour des raisons de vitesse d’exécution, et le versionnement ne peut pas être réalisé de la même manière.

Pour gérer ce problème, on peut procéder au rechargement périodique de la totalité des enregistrements, en tant que nouvelle version de données. Ceci ne semble pas une solution viable à long terme, aussi bien en terme de stockage que de rapidité de chargement.

On envisage alors un chargement incrémental : charger uniquement les nouvelles données et mettre à jour les données modifiées.

Le cas idéal se présente lorsque des clôtures sont effectuées régulièrement : on peut alors mettre en phase le rechargement de l’entrepôt avec la date de la dernière clôture, et se contenter de recharger le “delta” puisqu’on est assuré qu’aucun enregistrement datant d’avant le précédent rechargement n’a pu être modifié.

Lorsqu’il est possible d’avoir la main sur la base opérationnelle, il est également possible de mettre en place un système pour "mettre de coté" les enregistrements modifiés (ou ajoutés) depuis le dernier rechargement (ajouter un “flag” sur chaque enregistrement, une date de dernière mise à jour, un fichier de log...)

Mais comment faire lorsqu’il n’y a ni clôture ni possibilité d’adapter la base opérationnelle ?

On doit alors trouver des méthodes pour rendre la détection des modifications plus rapide. Une solution pourrait être de compter les enregistrements (si les nombres sont identiques, alors on a de fortes chances que les données n’aient pas été modifiées) ; ou encore d’effectuer des agrégations (somme, moyenne) à un niveau plus global, et de comparer ces valeurs. Mais ceci ne peut fonctionner que pour des changements portants sur des montants (heures, euros...). Dans tous les cas, ce n’est pas aussi précis que de comparer chaque enregistrement. Il faut peut être alors envisager de réaliser un compromis entre vitesse d’exécution, lourdeur de stockage et précision, en ajoutant une “marge d’erreur acceptable”.

Une fois toutes ces options étudiées, on peut se rendre compte que ce problème qui peut sembler trivial au premier abord, est finalement une des composantes complexes de la gestion d’un entrepôt de données.

Sources :
http://en.wikipedia.org/wiki/Slowly_changing_dimension http://www.dmreview.com/issues/19980501/609-1.html http://www.intelligententerprise.com/info_centers/data_warehousing/showArticle.jhtml ?articleID=59301280