Conseil 29: Modifier des dimensions ou des tables de faits existantes

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?

La symétrie prévisible de nos modèles dimensionnels vient à notre secours. Les modèles dimensionnels sont capables d'absorber d'importants changements dans les données de base et dans nos hypothèses de modélisation sans invalider les applications existantes. Listons autant de changements que nous le pouvons, en commençant par le plus simple.

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. 

6. Ajout d'une nouvelle source de données impliquant les dimensions existantes ainsi que de nouvelles dimensions. Presque toujours, une nouvelle source de données a sa propre granularité et ses propres dimensions. Tous les concepteurs d'entrepôts de données connaissent la réponse à celle-ci. Nous créons une nouvelle table de faits. Puisque les tables de faits et les dimensions existantes sont inchangées, par définition, toutes les applications existantes continuent cahin-caha. Bien que ce cas semble presque banal, le point ici est d'éviter d'insérer les nouvelles mesures dans les tables de faits existantes. Une table de faits possède toujours un seul type de mesure exprimé dans un grain uniforme.

Source originale: www.kimballgroup.com

Article original "Kimball Design Tip #29: Graceful modifications to existing fact and dimension tables", publié le 15 octobre 2001.

Conseil 28: Eviter les catastrophes à votre entrepôt de données

Les tragiques événements du 11 septembre nous font revoir nos hypothèses et nos priorités. Nous sommes obligés de remettre en question notre sécurité et la sécurité d'une manière qui aurait été impensable il y a quelques semaines.

Nous avons été habitués à penser que nos buildings et ordinateurs sont intrinsèquement sûr, juste parce qu'ils sont gros, importants et visibles. Ce mythe a été brisé. Si quoi que ce soit survient, ces types de bâtiments et d'ordinateurs sont les plus vulnérables.

L'assaut dévastateur sur notre infrastructure est également venu à un moment où l'entrepôt de données a évolué vers un état ​​proche de la production dans beaucoup de nos sociétés. L'entrepôt de données est aujourd'hui le moteur de la gestion de la relation client, et fournit presque en temps réel le suivi des commandes, des livraisons et des paiements. L'entrepôt de données est souvent le seul endroit où une vue des clients et de la rentabilité des produits peut être assemblé. L'entrepôt de données est devenu un outil indispensable pour la bonne marche de nombreuses entreprises.

Est-il possible de mieux protéger nos entrepôts de données? Existe-t-il une sorte d'entrepôt de données qui est sûr et moins vulnérables aux catastrophes?

Conseil 27: Soyez déconnecté le moins souvent possible

Si vous mettez à jour votre entrepôt de données chaque jour, vous avez un état particulier lorsque vous remplacez les données d'hier par les données d'aujourd'hui. Au cours de cette étape, votre entrepôt de données est probablement indisponible. Si tous vos utilisateurs sont dans le même fuseau horaire, vous ne ressentez aucune pression, aussi longtemps que vous pouvez lancer la mise à jour entre 3 et 5 heures du matin. Mais si vos utilisateurs sont dispersés à travers le monde, vous voulez être déconnecté le moins longtemps possible, parce que dans ce cas, le soleil ne se couche jamais sur l'entrepôt de données. Alors, comment pouvez-vous réduire ce temps d'arrêt au strict minimum?

Dans cet article, nous allons décrire un ensemble de techniques qui fonctionnent pour tous les principaux SGBD relationnels qui prennent en charge le partitionnement. Les détails exacts d'administration des partitions varient un peu d'un SGBD à un autre, mais vous saurez quelles questions poser.

Conseil 26: Ajouter une dimension Audit pour suivre la traçabilité et la confiance des données

Chaque fois que nous construisons une table de faits contenant des mesures de notre entreprise, nous entourons la table de faits avec "tout ce que nous savons être vrai". Dans un modèle dimensionnel, ce "tout-ce-que-nous-savons" est emballé dans un ensemble de dimensions. Concrètement, nous insérons les clés étrangères, une par dimension, dans notre table de faits, et relions ces clés étrangères aux clés primaires correspondantes de chaque dimension. Chaque dimension (comme produit ou client) contient un ensemble détaillé d'attributs textuels fortement corrélés représentant des membres individuels de la dimension (comme des produits individuels ou des clients).

Nous pouvons étendre cette approche "tout-ce-que-nous-savons" à la conception de la table de faits en incluant des éléments clés de métadonnées qui sont connus pour être vrai quand un fait relevé individuel est créé. Par exemple, lorsque nous créons un enregistrement de la table de fait, nous devrions connaître des choses telles que

1. quel système source a fourni les données de faits (plusieurs attributs si plusieurs systèmes sources).
2. quelle version du logiciel d'extraction à créé l'enregistrement.
3. quelle logique d'allocation (le cas échéant) a été utilisé pour créer l'enregistrement.
4. si un champ de la table de fait comportant la valeur "code NA" est effectivement inconnu, impossible, corrompu, ou non-disponible pour le moment.
5. si un fait précis a été modifié après le chargement initial, et si oui, pourquoi.
6. si l'enregistrement contient des faits de plus de 2, 3 ou 4 fois l'écart-type de la moyenne, ou de manière équivalente, en dehors de diverses limites de confiance provenant d'une autre analyse statistique.

Conseil 25: Concevoir des modèles dimensionnels pour les applications parent-enfant

La relation de données parent-enfant est l'une des structures fondamentales de base dans le monde des affaires. Une facture (le parent) a beaucoup de lignes d'articles (les enfants). D'autres exemples évidents en dehors des factures comprennent les commandes, les ordres de livraison, les polices d'assurance, et les tickets de caisses. Fondamentalement, tout document professionnel possédant des éléments qui se répètent est considéré comme une application parent-enfant, surtout quand ces éléments comportent des mesures numériques intéressantes comme des montants ou des unités physiques.

Les applications parent-enfant sont d'une extrême importance pour les entrepôts de données, car la plupart des documents de contrôle qui transfèrent de l'argent et des biens (ou des services) d'un endroit à un autre prend la forme parent-enfant.

Mais une source de données parent-enfant, comme les factures, pose un dilemme de conception. Certaines de ces données sont seulement disponibles au niveau de la société mère et certains ne sont disponibles qu'au niveau de l'enfant. Avons-nous besoin de deux tables de fait dans notre modèle dimensionnel ou pouvons-nous tout faire avec une seule? Et que faisons-nous avec les données qui sont disponibles uniquement au niveau de la société mère quand nous voulons descendre au niveau de l'enfant?