Malgré les meilleurs plans et les meilleures intentions, le concepteur de l'entrepôt de données doit souvent ajouter de nouveaux types de données ou modifier les relations entre les données alors que l'entrepôt de données est en marche. Dans un monde idéal, nous aimerions que ces changements soient "propres" de sorte que les outils de requêtage et de reporting existants continuent de fonctionner sans être modifiés, et que les interfaces utilisateurs existantes affichent les nouvelles données et permettent aux données d'être ajoutés aux requêtes et rapports.
Évidemment, il y a certains changements qui ne peuvent jamais être effectués avec élégance. Si une source de données cesse d'être disponible et qu'il n'existe pas d'autre source compatible pour la remplacer, alors les applications dépendantes de cette source cesseront de fonctionner.
Mais peut-on décrire un ensemble de situations où l'on pourrait effectuer des changements dans notre environnement de données avec élégance?
1. De nouveaux attributs dans une dimension. Si, par exemple, nous découvrons de nouveaux descripteurs textuels pour un produit ou un client, nous ajoutons ces attributs dans la dimension en tant que nouveaux champs. Les applications existantes ne seront pas conscientes des nouveaux attributs et continueront à fonctionner normalement. La plupart des interfaces utilisateurs ne devraient pas remarquer les nouveaux attributs lors de leur exécution. Conceptuellement, la liste des attributs disponibles pour filtrer et faire des regroupements doit être affiché dans un outil de requêtage ou un outil de reporting via une requête sous-jacente du type SELECT NOM_COLONNE FROM SYS_TABLES WHERE NOM_TABLE = "Produit". Ce genre d'interface utilisateur sera continuellement "ajusté" lorsque de nouveaux attributs de dimension seront ajoutés au schéma. Dans une dimension à évolution lente, où les petits changements de versions de la dimension sont maintenus, il faudra prendre soin d'attribuer correctement les valeurs des nouveaux attributs aux différentes versions des enregistrements. Si les nouveaux attributs ne sont disponibles qu'après un point spécifique dans le temps, alors la valeur "NA" (non disponible) ou son équivalent doit être attribuée aux anciens enregistrements de la dimension.
2. De nouvelles mesures dans une table de faits. De même, si de nouvelles mesures sont disponibles, nous pouvons les ajouter à la table de faits avec élégance. Le cas le plus simple, c'est quand les nouveaux faits sont disponibles pour le même évènement et dans le même grain que les faits existants. Dans ce cas, la table de faits est modifiée pour ajouter les nouveaux champs, et les valeurs sont remplies dans la table directement. Dans un monde idéal, une instruction ALTER TABLE peut être utilisée sur la table de faits existante pour y ajouter les nouveaux champs. Si cela n'est pas possible, alors une deuxième table de fait doit être créée avec les nouveaux champs et les enregistrements issus de la première table. Pour les très grosses tables de faits, de grands blocs d'enregistrements peuvent être déplacés d'une table à l'autre pour éviter de stocker la table géante dans son intégralité une deuxième fois. Si les nouveaux faits sont disponibles uniquement à partir d'un point dans le temps, alors la valeur nulle doit être placée dans les enregistrements précédents. Si nous faisons cela correctement, alors les anciennes applications continueront à fonctionner tranquillement. Et de nouvelles applications utilisant les nouveaux faits devraient se comporter correctement même si elles rencontrent des valeurs nulles. Les utilisateurs pourront être informés que les nouveaux faits ne sont disponibles qu'à partir d'un point précis dans le temps.
Une situation plus complexe se pose lorsque de nouveaux faits ne sont pas disponibles pour le même évènement que les anciens faits, ou s'ils sont à un grain différent. Si les nouveaux faits ne peuvent pas être alloués ou attribués au même grain que la table de faits d'origine, il est très probable qu'ils doivent appartenir à leur propre table de faits. C'est presque toujours une erreur de mélanger des granularités ou des types de mesures différentes dans une même table de faits. Si vous avez cette situation, vous devez serrer les dents et trouver un outil de requêtage ou de reporting qui soit capable d'exécuter plusieurs requêtes SQL afin qu'il puisse accéder à plusieurs tables de fait dans la même demande de l'utilisateur. Des outils tels que Cognos, Business Objects, et Microstrategy sont tout à fait capable de gérer ce type de traitement.
3. De nouvelles dimensions. Une dimension peut être ajoutée à une table de fait existante en ajoutant un nouveau champ de clé étrangère et en le remplissant correctement avec les valeurs de la clé primaire de la nouvelle dimension. Par exemple, une dimension Météo peut être ajoutée à une table de faits retraçant les ventes de détail si une source décrivant la météo est disponible, par exemple, à chaque point de vente chaque jour. Notez que nous ne changeons pas le grain de la table de faits. Si l'information météorologique est disponible uniquement à partir d'un point dans le temps, alors la valeur de clé étrangère pour la dimension Météo doit pointer vers un enregistrement dont la description est "Météo indisponible".
4. Une dimension devenant plus fine. Parfois, il est souhaitable d'augmenter la granularité d'une dimension. Par exemple, une table de faits des ventes de détail avec une dimension Magasin pourrait être modifiée pour remplacer la dimension Magasin par une dimension Caisse Enregistreuse. Si nous avions 100 magasins, chacun avec une moyenne de 10 caisses enregistreuses, la nouvelle dimension aurait 1000 enregistrements. Tous les attributs des magasins d'origines seraient inclus dans la dimension Caisse Enregistreuse parce que les caisses enregistreuses ont une relation de type 1-à-plusieurs avec les magasins. Les attributs des magasins peuvent également être modélisés physiquement comme une dimension en flocons reliée à la dimension Caisse Enregistreuse. Remarquez que quand on augmente la granularité du magasin ==> dimension Caisse Enregistreuse, il faut augmenter la granularité de la table de faits. La table de faits sera alors 10 fois plus grande, dans notre exemple. Il n'y a probablement pas d'autre choix que de supprimer la table de faits existante et de la reconstruire. Bien que ce changement soit un changement complexe, il est propre et toutes les applications initiales ne seront pas affectées. Les totaux au magasin resteront identiques et toutes les requêtes retourneront les mêmes résultats. Toutefois, elles pourraient s'exécuter plus lentement puisqu'il y a dix fois plus d'enregistrements dans la table de faits, mais nous aurions probablement envie de construire une table de faits agrégée aux magasins de toute façon! Cela correspondrait à la table de faits d'origine, qui jouerait désormais le rôle de table de faits agrégée.
5. Ajout d'une hiérarchie en rapport avec deux dimensions. Nous pouvons avoir une situation où deux dimensions se révèlent avoir une structure hiérarchique de type 1-à-plusieurs, mais pour diverses raisons, nous préférons les garder séparées. Normalement, nous devrions combiner des entités hiérarchiquement liées dans une même dimension, mais si l'une ou l'autre des dimensions existe dans son bon droit comme une dimension indépendante "conforme", on peut vouloir les garder séparées. Par exemple, dans l'assurance, nous pouvons avoir une dimension Police et une dimension Client. Si chaque police a exactement un client, alors la police pourrait être fusionnée avec le client. Cependant, nous ne souhaiterions probablement pas inclure les informations du client dans la dimension Police parce que la dimension Client sera certainement une dimension importante dans notre architecture de l'entrepôt de données global. La dimension Client pourra se connecter à de nombreuses autres tables de faits, où dans de nombreux cas la dimension Police n'a aucun sens. En dépit de cette nécessité de conserver les dimensions séparées, certains concepteurs ajoutent une clé ClientPolice très utile pour certaines de leurs tables de faits où la nouvelle dimension ClientPolice est le mariage exact entre le Client et la Police. Cette dimension contient la combinaison des clients et des polices et peut être interrogé de manière fiable pour explorer cette relation, indépendamment de toute table de faits. L'ajout de cette nouvelle clé de dimension combinée pose les mêmes questions d'administration que l'ajout d'une nouvelle dimension, décrite au paragraphe 3 ci-dessus.
Source originale: www.kimballgroup.com
Article original "Kimball Design Tip #29: Graceful modifications to existing fact and dimension tables", publié le 15 octobre 2001.
Aucun commentaire:
Enregistrer un commentaire