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.