Conseil 11: Compter correctement dans une dimension

Les tables de dimension qui possèdent de nombreux attributs descriptifs deviennent souvent la cible de requêtes directes indépendantes de toute table de faits. Par exemple, nous faisons quotidiennement différents calculs sur notre dimension Client pour répondre à des questions telles que le nombre de clients par type de paiement, par région, ou par sexe, etc. Ces calculs sur une dimension statique sont faciles, mais cela devient plus intéressant lorsque nous essayons d’effectuer ces calculs sur une dimension à évolution lente.

Conseil 10: Vos données sont-elles correctes?

Un problème courant lié à la maintenance de l’entrepôt de données est de vérifier que les données qu'il contient soient correctes. L'entrepôt est-il une image exacte du système source? Le chargement de ce matin c'est-il correctement terminé? Des identifiants sont-ils erronés?

Il n'existe pas de technique unique pour valider un chargement de données, car les sources des données sont bien trop variées. Si vous chargez une image d'une source de production, tout en préservant sa granularité d'origine, alors vous pouvez probablement créer un rapport simple sur le système de production avec des totaux jusqu’à la minute, et vous pouvez utilisez ce même rapport avec l'entrepôt de données. Dans ce cas, vous connaissez la réponse à l'avance et les deux résultats doivent correspondre jusqu’à la dernière décimale.

Mais il est plus habituel de ne pas avoir de point de comparaison connu. Peut-être recevez-vous le détail des ventes de 600 magasins chaque nuit. Dans ce cas, vous pouvez certainement compter le nombre de magasins qui vont ont envoyé des données, mais comment pouvez-vous obtenir un meilleur avis et dire si les données sont "probablement correctes"?

Conseil 9: Traiter les dimensions à évolution lente durant un chargement initial de données

L’article précédent a clairement défini la technique des dimensions à évolution lente de type 2 et la bonne utilisation des clés de substitution. Ce mois-ci nous abordons la question épineuse du traitement des dimensions à évolution lente lors du chargement initial d'un nouveau domaine au sein d'un entrepôt de données. Cela peut se produire lorsque vous introduisez une nouvelle mesure (fait) dans un entrepôt de données existant par exemple. Des dimensions tels que Produit, Client, et Temps sont probablement déjà définies et possèdent un riche historique reflétant de nombreuses évolutions lentes.

Conseil 8: Partitionner un historique avec une dimension à évolution lente de type 2

Une dimension à évolution lente de type 2 fournit un autre type de partitionnement. On pourrait appeler cela une partition logique de l'historique. Dans l'approche de type 2, chaque fois que nous rencontrons un changement dans un enregistrement de la dimension, nous publions un nouvel enregistrement, et l'ajoutons à la table de dimension existante. Un exemple simple peut être est la description d'un produit, ou une autre caractéristique du produit tels que le type d'emballage, qui change mais que le numéro d'identification de celui-ci (par exemple, le code à barres) ne change pas. En tant que gardiens de l'entrepôt de données, nous avons pris l'engagement de suivre parfaitement les évolutions et nous devons donc suivre à la fois la nouvelle description du produit ainsi que l'ancienne.

Conseil 7: Remettre son entrepôt de données sur de bons rails

Durant l'année écoulée, nous avons observé à plusieurs reprises un problème avec les entrepôts de données matures: malgré des effort et des investissements considérables, des entrepôts de données se détériorent avec le temps. Les équipes techniques (ou leurs utilisateurs) ne sont pas satisfaits avec les livrables de l’entrepôt: les données sont trop confuses, il n'est pas conforme, les requêtes sont trop lentes, etc. Les équipes ont lus tous les best-sellers et les articles sur les entrepôts de données, mais ne savent toujours pas comment améliorer la situation (certains quittent même le navire et vont chercher un nouvel emploi).

Si cette situation vous semble familière, considérez attentivement chacune des questions suivantes pour déterminer si l'un - ou plusieurs - de ces facteurs fragilise votre entrepôt de données. En termes de mesures correctives, nous vous recommandons de faire face à ces préoccupations fondamentales dans l'ordre, si possible.

Conseil 6: Montrer les corrélations entre les dimensions

Voici une question que l'on me pose souvent: "comment puis-je représenter la corrélation entre deux dimensions sans passer par la table de faits?" Souvent, le concepteur poursuit avec la question "puis-je créer une petite table de jointure avec seulement les clés des deux dimensions et puis connectez cette table à la table de faits?"

Conseil 5: Clé de substitution dans une dimension Temps

Voici la modélisation d'une dimension Temps qu'un consultant nous a récemment proposé. Celle-ci semble assez différente de celles que nous concevons habituellement.

La structure de cette dimension Temps est la suivante :

Date_Clé           varchar2 (8)

Date_Début      date ou datetime

Date_Fin           date ou datetime

Et voici un exemple de son contenu :

Date_Clé         Date_Début               Date_Fin

xmas99            25Nov99                     06Jan00

1qtr99               01Jan99                     31Mar99

newyrsdy          01Jan00                     01Jan00

01Jan00           01Jan00                     01Jan00

Quel est votre point de vue sur cette structure? Pour quel type de scénario l'envisageriez vous comme une bonne solution et une alternative viable?

Conseil 4: Mettre à jour rapidement une dimension Client complexe

Beaucoup de concepteurs d'entrepôt de données ont à traiter avec une dimension Client compliquée, qui est à la fois large et profonde. Une dimension Client peut avoir 100 ou plus attributs descriptifs, et peut avoir des millions de lignes. Parfois, les «Clients» sont des demandeurs d'assurance-maladie, et d'autres fois ce sont des propriétaires de véhicules automobiles.Mais les questions de conception sont les mêmes.

Souvent, dans ces situations, l'entrepôt de données reçoit quotidiennement une copie complète mise à jour de la dimension Client. Bien sûr, ce serait merveilleux si seulement les delta (les enregistrements modifiés) étaient délivrés à l'entrepôt de données, mais le plus souvent c’est à l'entrepôt de données de trouver les enregistrements modifiés en recherchant méthodiquement dans l'ensemble de la table. Cette étape de comparaison enregistrement par enregistrement et champ par champ sur l'ensemble de la table entre la version d'hier et celle d'aujourd'hui est lente et inadéquat.

Conseil 3: Concentrez-vous sur les processus

Une des erreurs les plus répandues dans notre métier est que les datamarts sont souvent définis par service. Nous avons vu d'innombrables schémas d’entrepôts de données  étiquetés "Datamart marketing", "Datamart vente", et "Datamart finance". Après avoir examiné les exigences opérationnelles de ces services, vous découvrirez inévitablement que ces trois services souhaitent les mêmes informations de base, telles que les données des commandes. Plutôt que de construire un datamart "Marketing" qui comprend les commandes, puis un datamart "Vente" avec ces mêmes commandes, etc, vous devez construire un seul datamart "Commandes", détaillé, avec un accès pour les différents services.

Conseil 2: Représenter plusieurs dates à partir d'une seule dimension

La question la plus fréquente dans mes cours et e-mails est de savoir comment gérer plusieurs timestamp sur un enregistrement d'une table de faits. Bien que la réponse correcte et immédiate est « faites de chaque timestamp, une dimension Temps », il est utile de décrire cette approche avec précaution car elle illustre bien tout un ensemble de techniques modernes de conception d'entrepôt, sur lesquels je mettrais l'accent en MAJUSCULES.