IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Mettre en place un entrepôt de données multidimensionnel

Mettre en place un entrepôt de données multidimensionnel


précédentsommairesuivant

3-C. Maintenance d'un entrepôt de données multidimensionnel

La maintenance et l'évolution des dimensions à  long terme est un processus délicat. Dans une approche multidimensionnelle, vos dimensions étant communes à  l'ensemble des tables de fait, une simple erreur de maintenance sur une dimension aura un impact sur l'ensemble de votre système décisionnel. Vous marchez donc sur des oeufs...

La bonne nouvelle, c'est qu'il n'existe pas « trente-six » façons de maintenir une dimension. Si vous respectez les quelques conseils prodigués dans la partie  « les tables de dimensions » lors de la conception de vos dimensions, vous pourrez mettre en place ces conseils de maintenance sans grande difficulté.

3-C-1. Opérations de maintenance liées aux dimensions

3-C-1-A. Ajout

Avant d'ajouter une nouvelle occurrence de dimension, posez-vous les questions suivantes : cette occurrence a-t-elle sa place dans la structure hiérarchique de ma dimension ? Les catégories parentes de celle-ci sont-elles réellement adéquates ? Un chargement rétroactif de certaines tables de fait est-il nécessaire ?

L'ajout d'une feuille dans un arbre de dimension est rarement problématique, il faut juste veiller à  conserver une cohérence hiérarchique et logique dans toute la hauteur de l'arbre.

3-C-1-B. Suppression

Votre arbre de dimension évoluant, les utilisateurs ont maintenant accès à  des valeurs d'occurrence obsolètes. Vous souhaitez supprimer l'accès à  ses occurrences, pour cela deux méthodes possibles :

  • première méthode (conseillée) : mettez en place un champ « visibilité de l'utilisateur » dans vos tables de dimensions et changez la valeur de ce champs lorsque l'occurrence est obsolète ;
    - avantage : méthode simple à  mettre en oeuvre, aucune opération de mise à  jour des tables de fait n'est nécessaire,
    - inconvénient : des valeurs de dimension étant masquées à  l'utilisateur et les tables de fait n'ayant subit aucune modification, il se peut que l'agrégat d'un rapport puisse ne pas représenter la somme des valeurs après un « drill-down » sur la dimension ;
  • seconde méthode : vous décidez de supprimer l'occurrence de votre table de dimension. Dès lors, l'ensemble des occurrences dans vos tables de fait qui font référence à  cette valeur de dimension seront obsolètes. Vous devez alors mettre à  jour l'ensemble des tables de fait, en remplaçant la référence de la dimension supprimée par une référence de dimension « valeur non applicable » que vous aurez créée au préalable dans votre dimension.

Quelle méthode utiliser ?

Si l'occurrence de dimension à  supprimer n'est plus référencée par vos tables de fait depuis longtemps (exemple, une référence de produits qui n'existe plus depuis plusieurs mois), la méthode via un champ « flag » semble être la plus pertinente.

3-C-1-C. Mise à  jour

La modification d'une dimension est l'opération la plus délicate. Comme pour la suppression nous pouvons distinguer deux méthodes :

  • première méthode : vous remplacez simplement l'ancienne valeur par la nouvelle ;
    - avantage : méthode est simple à  mettre en oeuvre et il n'y a aucun processus de traçage d'évolution à  mettre en oeuvre,
    - inconvénient : il y a un impact sur l'ensemble des rapports programmés avant la modification ;
  • seconde méthode (conseillée) : en cas d'évolution, vous ajoutez la nouvelle valeur sans supprimer l'ancienne que vous marquez comme « non applicable » à  partir d'un champ « flag » prévu à  cet effet. Ainsi lors du processus d'alimentation de la table de fait, c'est bien la nouvelle valeur qui est référencée et non l'ancienne. Ici le nombre d'occurrences de la table de dimension augmente à  chaque modification.
    - avantage : aucun rapport n'est impacté,
    - inconvénient : le processus de maintenance est un peu plus complexe.

Les opérations d'ajout, de suppression et de mise à  jour de vos dimensions sont moins triviales qu'il ni paraît. J'espère que cette courte présentation vous permettra de cerner rapidement la problématique de maintenance des dimensions dans un entrepôt de données multidimensionnel.

3-C-2. Opérations de maintenance liées aux mesures

Hormis les tables de fait de type récapitulatif, les seules opérations effectuées sur vos tables de fait seront des insertions (sauf erreur de chargement...). Toutefois, vous pourrez rencontrer des difficultés de maintenance liée à  vos tables de fait, celles-ci peuvent provenir :

3-C-2-A. Du volume de données traitées :

Une granularité très fine dans une table de faits peut amener à  avoir à  traiter des millions d'occurrences. Les gros volumes sont toujours délicats à  traiter, si l'alimentation de cette table est en dépendance avec d'autres tables (des bases métiers par exemple) c'est l'ensemble de vos traitements de nuit qui seront retardés... (Une nuit de traitement à  une durée maximum de 12 heures). Vous devez absolument garder un oeil sur le temps de traitement de chacune de vos tables et sur les différentes dépendances de votre nuit batch.

3-C-2-B. De la complexité du calcul des  mesures :

Des calculs de mesure complexes peuvent devenir problématiques, exemple : les calculs de délais ou les calculs qui doivent tenir compte de l'état d'autres occurrences de tables opérationnelles. Hélas, ici, les compromis avec les analystes ne seront probablement pas possibles. Une définition de mesure ne doit pas être changée pour cause de problème technique de mise en oeuvre. Essayez de mettre en place des vues des tables opérationnelle réduites et divisez la complexité du calcul en différentes étapes plus simples : « break it and make it easier ».

3-C-2-C. Des jointures avec les tables de dimensions :

Pour déterminer le contexte des occurrences de vos tables de fait, vous allez devoir d'une manière ou d'une autre, déterminer quels sont vos clés de dimension pour chaque occurrence traitée. Or, il arrive que pour diverses raisons (évolution des tables opérationnelles ; erreur de chargement de vos dimensions ; problème de qualité des données)  que vos lignes de mesure ne trouvent pas de correspondance dans vos dimensions. Ici attention,  il ne faut surtout pas perdre ces enregistrements ! Ces occurrences existent, elles doivent donc être prises en compte dans le calcul de votre mesure. Pour cela, je vous conseille de mettre en place une catégorie « Non Applicable » dans chacune de vos dimensions. Si votre enregistrement ne trouve pas de correspondance, il doit tomber par défaut dans cette catégorie « Non Applicable ». Vous serez ensuite apte à  isoler les enregistrements problématiques pour les corriger.

D'après ma propre expérience, ces trois points sont des problématiques récurrentes liées aux tables de fait. Cette courte présentation vous permettra sans doute de mettre en place un système plus robuste.


précédentsommairesuivant

Copyright © 2011 Carlos Da Costa. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.