Un data mart dimensionnel se construit autour d'un processus de mesure physique ou d'un événement. Pas autour d'un rapport à produire, ni autour d'un service qui le réclame.
Cette définition, qui vient des auteurs ayant créé la notion, a une conséquence immédiate et très pratique : si le métier demande un nouveau rapport sur le même processus de mesure, il n'y a aucune raison de construire un nouveau data mart.
C'est déjà l'inverse du réflexe le plus répandu en informatique décisionnelle, qui consiste à créer un data mart chaque fois qu'une direction formule un besoin.
Sa place dans la chaîne
Dans la chaîne classique de l'entrepôt de données, les data marts sont interrogés en aval, après la préparation et après le stockage.
L'ordre compte plus qu'il n'y paraît, car c'est lui qui sépare deux familles d'architecture. Dans un entrepôt classique, le stockage persistant intervient après la préparation des données. C'est ce qui distingue radicalement le data mart du lac de données, où l'on stocke d'abord et prépare ensuite.
Les types de data marts, et ce que cette typologie ne dit pas
Les présentations du sujet distinguent presque toutes trois types de data marts : dépendant, indépendant, hybride. Cette grille décrit un mode d'alimentation : depuis un entrepôt existant, depuis les sources directement, ou les deux.
Elle est exacte sur ce point, mais elle ne dit rien du seul choix qui compte vraiment, celui du périmètre. Et sur ce terrain-là, la source fondatrice est catégorique.
L'idée qu'un modèle dimensionnel soit une solution départementale y est désignée comme une fable. Non pas une simplification, ni une pratique discutable : une fable.
Pourquoi un data mart par service ne tient pas
La raison est structurelle. Une table de faits qui représente un processus de mesure fondamental n'a besoin que d'une seule instance physique, partagée entre les directions.
Dupliquer cette table pour donner à chaque service la sienne ne crée donc aucune valeur, et l'approche par département expose à des solutions ponctuelles incohérentes et non intégrées.
Voici ce que cela donne concrètement. Une PME de négoce qui monte un data mart Ventes et un data mart Achats sans dimension Produit commune finit avec 3 400 références côté ventes et 3 610 côté achats, et aucune requête ne peut rapprocher la marge par produit tant que les deux référentiels ne sont pas conformes.
Deux ans de travail, deux outils qui fonctionnent, et la question la plus élémentaire du métier reste sans réponse.
La colle, ce sont les dimensions conformes
Un réflexe fréquent consiste à chercher la solution du côté de la modélisation, en normalisant davantage. C'est une impasse : normaliser les données n'apporte rien à l'intégration, qui est un processus distinct de tout choix de modélisation.
Ce qui intègre réellement porte un nom. Dans la bus architecture, ce sont les dimensions conformes qui jouent le rôle de colle entre les processus métier. Elles sont gérées une seule fois dans l'ETL, puis réutilisées par plusieurs tables de faits.
L'avantage le plus tangible d'un data mart bien découpé tient d'ailleurs là : réutiliser des dimensions conformes raccourcit le délai de mise en service, en supprimant les travaux de conception redondants. Le deuxième data mart coûte moins cher que le premier, ce qui n'arrive jamais avec des silos.
Cette architecture a été introduite dans les années 1990, et elle permet un développement incrémental indépendamment de la technologie et de la base. C'est aussi la réponse à la question du data mart « en nuage » : le sujet est une question d'hébergement, pas d'architecture.
Comment interroger deux data marts ensemble
La conformité des dimensions n'est pas un idéal de propreté, elle a une conséquence technique très concrète. Interroger deux data marts ensemble se fait par requêtes séparées, dont les en-têtes de lignes sont des attributs conformes identiques.
On ne joint donc pas deux tables de faits entre elles. On interroge chacune de son côté, puis on aligne les résultats sur des libellés qui sont, littéralement, les mêmes. Sans cet alignement, l'opération n'a pas de sens.
Deux idées reçues sur le contenu
La première concerne le niveau de détail. Un data mart doit contenir la donnée atomique : les agrégats ne sont qu'un complément de performance, jamais un remplacement. Un data mart qui ne stocke que des totaux mensuels ferme la porte à toute question qu'on n'avait pas prévue.
La seconde concerne la profondeur. L'idée qu'un data mart ne contiendrait que de l'historique récent est fausse : les tables de faits modernes atteignent couramment le milliard de lignes.
Ce que cela demande à l'outil
Tout ce qui précède désigne une capacité précise, et une seule : gérer un référentiel de dimensions partagé, réutilisable d'un jeu de données à l'autre.
Sur les 26 solutions de business intelligence référencées chez nous, 21 sont facturées au mois, de 11 € à 1 925 € HT.
La question à leur poser découle directement de la bus architecture, et notre comparateur donne les éléments pour y répondre : l'outil sait-il partager une même dimension entre plusieurs modèles, ou chaque tableau de bord recrée-t-il son propre référentiel produit ?
