L’informatique Décisionnelle est plutôt récente (une trentaine d’année) si l’on considère qu’avant cela l’informatique été essentiellement transactionnelle et que les données étaient donc stockées essentiellement à des fin de sauvegarde sans réelle préoccupation de leur capacité à être analysées, c’est donc pourquoi il peut régner une certaine confusion dans le monde de l’informatique décisionnelle entre les exploitants/développeurs applicatifs gérant des bases de données transactionnelles et nous développeurs B.I.

Je vais donc mettre en défaut certaines idées reçues et très bien ancrées dans le monde des développeurs B.I.
Cet article est basé sur l’approche de Ralph Kimball de la modélisation des DataWarehouse, il pourrait certainement être différent en se basant sur l’approche de Bill Inmon, toutefois, la majorité de ces légendes urbaines sont démenties par les deux auteurs.

Les problèmes d’une approche basée sur le reporting.

Légende : L’organisation de mes dimensions doit être construite pour répondre aux besoins spécifiques du Reporting. Quand un nouveau rapport est nécessaire, il est nécessaire de construire un nouveau modèle.

Dans les faits : Il est préférable de centrer son analyse autour des mesures et / ou des évènements plutôt que de partir du reporting existant ou nécessaire, ainsi, pour chaque nouveau rapport il sera probablement déjà possible de répondre à ce nouveau besoin. En résumé, le modèle des dimensions doit être construit à partir des process métier et non à partir des besoins à un instant T.

Légende : L’organisation de mes dimensions est propre à un service au sein de l’entreprise, lorsqu’un nouveau service à besoin des données, il est nécessaire de créer un nouveau modèle de Dimensions afin d’utiliser le vocabulaire qui leur est propre. (Entre le département Marketing et le département Finance par exemple).

Dans les faits : Il faudrait éviter ce genre de réplications qui font généralement légion au sein des grosses entreprise, en effet notre schéma dimensionnel doit refléter les processus de l’entreprise en s’axant sur les mesures et évènements, un processus de vente par exemple ne devrait pas être représenté de manière différente que cela soit pour le marketing ou la finance, une réplication des données va mener vers une réplication de chaque analyse.

Les risques d’une agrégation prématurée des données.

En effet, un des objectifs majeur du DW/DM est de ne pas trainer toutes les informations du système transactionnel afin de garder uniquement les éléments qui ont sens pour les analyses, toutefois, il ne faut pas tomber dans l’excès.

Légende : Utiliser les concepts de modélisation comme les « Dimensions Conformes » (Conformed Dimensions, je suis preneur d’une meilleur traduction?)  ajoute un effort inutile dans l’ETL.

Dans les faits : Mettons toutes les données dans une seule table sans aucune relations c’est plus simple ! En effet d’un point de vue externe ça peut être valable, du point de vue d’un vrai système d’information décisionnel, il faut absolument éviter ce genre de considération (même si cela peut fonctionner, etc.). Encore une fois, avoir pré-calculé ou agrégé les données pour répondre à des besoins spécifiques n’est pas la bonne approche, il est nécessaire de garder l’approche la plus atomique possible.

Légende : Le point précédent nous mène directement à cette autre légende, avoir un niveau de granularité assez fin, pénalise les performances.

Dans les faits : Une table de fait peut contenir des millions de lignes sans problèmes de performance, les infrastructures d’aujourd’hui sont suffisamment évoluées pour permettre ce genre de pratique, les performances seront plus sur l’utilisation de vos schémas que sur eux même.

Légende : Il est nécessaire d’éliminer les relations Many-to-Many (0,N) des schémas dimensionnels car ils ne peuvent le supporter.

Dans les faits : Les tables de fait sont par nature l’expression de ce besoin de relation Many-to-Many tandis que les dimensions représenterons les relations 1-N.

Ne surévaluons pas l’effort nécessaire pour la normalisation dans la construction de schémas dimensionnels.

Légende : Les changements d’attributs sont systématiquement un problème pour un schéma Dimensionnel.

Dans les faits : La nature d’un DataWarehouse ou Datamart est d’évoluer, en effet les processus d’une entreprise change très souvent (tous les ans ? ) et ceci est pris en compte lors de l’utilisation de Dimension à variation lente qui vont historiser (type 2) et modifier les données.

Conclusion :

Ces légendes et leurs potentielles explications n’ont valeur que dans certains contextes, c’est certainement ce qui fait qu’elles ont la vie dure. Mais dans la majorité des cas, éviter de tomber dans ces pièges même si cela semble coûteux de prime abord et vous complique la vie. Vous verrez forcement l’impact positif à un moment donné.