Mise à jour de l'entrepôt de données

Cette dernière section du chapitre décrit la stratégie de mise à jour qui a été conçue et employée pour rafraîchir les données contenues dans l'entrepôt géo-décisionnel. Plusieurs méthodes ont été décrites dans la section 1.3.3 en faisant ressortir les principaux avantages/désavantages de chacune. Théoriquement, en suivant la littérature, la méthode de Mémoire externe cache temps-réel nous semblera d'abord comme étant la meilleure stratégie due à sa rapidité et ses performances accrues pour mettre à jour efficacement un entrepôt contenant des données temps-réelles. Par contre, même posséder deux instances d'une même base de données n'est pas un problème en soi; remplacer les fichiers de la base sur laquelle les utilisateurs font leurs analyses par les nouveaux fichiers maintenant à jour a toutefois constitué un obstacle majeur. En aucun cas un SGBD permettra la copie d'un fichier en cours d'utilisation. Il faudrait donc mettre hors tension le SGBD, copier les fichiers et redémarrer ensuite, faisant perdre un temps considérable aux utilisateurs. D'autre part, il est rare pour un SGBD de ne contenir qu'une seule base de données; le mettre hors tension rendrait inaccessibles toutes les bases de données contenues dans le SGBD.

76 Il nous a donc fallu adapter une méthode similaire, la méthode de peuplement progressif dans laquelle seule la table de faits est copiée, pour éviter d'avoir à copier tous les fichiers de l'entrepôt de données.

La figure suivante nous illustre cette approche:

Figure 2.4. Stratégie de mise à jour de l'entrepôt géo-décisionnel.

Une première copie de la table de faits (copie temporaire) est d'abord mise à jour. C'est dans cette table que les données seront envoyées par l'ETL. À une fréquence élevée, par exemple à toutes les minutes, l'ETL récupère les données du flux SensorGeoRSS, les transforme et les charge dans cette table.

La deuxième table de faits (copie) est ensuite mise à jour en fonction du temps écoulé pour insérer les données dans la copie temporaire. La période de mise à jour de cette table

77 doit impérativement être inférieure au temps de chargement de la copie temporaire. Supposons que la mise à jour dans la copie temporaire dure N secondes, en incluant toutes les étapes qui y sont reliées (l'extraction des données depuis un SOS, la restructuration de celles-ci vers un format conforme à celui de données de l'entrepôt et leur chargement dans celui-ci), et que cette mise à jour est effectuée à toutes les 30 secondes, la période entre les mises à jour de la copie ne devrait pas être inférieure à 30 + N secondes pour éviter tout conflit potentiel. De manière plus explicite, si P représente la période de mises à jour, on obtient la formule suivante.

Formule 2.1. Relation entre la période de mise à jour des tables.

Suite à chaque nouvelle mise à jour, les données contenues dans la copie temporaire sont supprimées pour éviter les doublons et pour alléger les traitements futurs.

La période de mise à jour de la table de faits originale doit également minimalement respecter la formule démontrée précédemment. Cependant, comme ces mises à jour seront plus volumineuses, une perte de performances pourrait être observée lors de chaque mise à jour. Donc, pendant une période moins achalandée, comme par exemple la nuit, les données de la copie seront ajoutées à la table de faits originale et ensuite supprimées de la copie, encore une fois pour alléger les traitements futurs. De cette manière, des mises à jour de petit volume se produisent durant les périodes actives de l'entrepôt, et les plus volumineuses durant les périodes mortes.

Afin d'obtenir un résultat incluant toutes les données, les nouvelles données et les données historiques, les requêtes doivent interroger les deux tables de faits (originale et copie). Toutefois, des jointures de tables et autres requêtes complexes incluant plus d'une table sont beaucoup plus coûteuses en termes de performances et de temps. Afin d'interroger simultanément tous les faits contenus dans les deux tables, une vue a été créée pointant vers toutes les dimensions, la table de faits et la copie. Les tables

78 représentant les dimensions sont alors raccrochées à la vue et non à une table de faits classique.

Limites de l'approche

Cette méthode qui vise à éviter la mise hors tension du SGBD comporte toutefois un désavantage. Certains utilisateurs tirent profit de la mémoire cache pour garder en mémoire les cubes de données et certaines requêtes qui sont gérées par l'outil SOLAP [32], accélérant ainsi l'exploration des données. Hors, en employant cette approche, la copie de la table de faits incluse dans la vue nécessite des mises à jours à toutes les N minutes. Suite à ces mises à jour, les nouvelles données ne sont pas prises en compte puisque la mémoire cache ne contient que les données présentes dans la table lors du dernier démarrage de l'outil. Afin de les ajouter aux analyses, la mémoire cache doit être réinitialisée en redémarrant le serveur qui contient le SOLAP. Ce redémarrage est nécessaire et peut durer deux ou trois secondes, rajoutant un peu plus de temps à la durée de la mise à jour. Si le temps de redémarrage du serveur est représenté par Tredémarrage, la

formule 2.1 doit alors prendre en compte ce paramètre et devient alors la suivante:

Formule 2.2. Relation entre la période de mise à jour des tables en incluant le temps de redémarrage du serveur.

Certains outils SOLAP permettent de désactiver la mise en mémoire cache, et même si faire de la sorte règlerait le problème, les performances seraient beaucoup affectées et les requêtes pour former les cubes de données seraient beaucoup plus longues à exécuter. D'autre part, le redémarrage du serveur n'affecte que le seul entrepôt de données qu'il contient, les autres bases de données possiblement contenues dans le SGBD demeurent ainsi opérationnelles et les performances associées aux requêtes qui les interrogent restent

79 indemnes. Cette approche demeure donc tout de même la méthode la plus optimale pour mettre à jour un entrepôt de données.