Les idées reçues du décisionnel : la modélisation

Une idée reçue est un lieu commun qui ressemble à une vérité établie et donne l'illusion d'une connaissance à celui qui l'énonce ou l'entend. Même si elle n'est pas toujours fausse, une idée reçue est dangereuse dès lors que, par naïveté ou par paresse, nous l'appliquons au lieu de réfléchir. Il s'agit ici de remettre en question deux idées reçues parmi les plus courantes sur la modélisation des données en Business intelligence. 

 

« Un modèle décisionnel, c'est un modèle dimensionnel »

>> De moins en moins souvent vrai.

Les modèles en étoile (en flocon, en constellation, …) sont apparus il y a quelques dizaines d'années, lorsque les limites technologiques ne permettaient pas aux systèmes décisionnels de délivrer autre chose que des données agrégées.

Avec les progrès techniques et l'évolution des besoins, les données sont maintenant collectées et exploitées à une maille élémentaire (tiers, contrat, événement, …) à laquelle la distinction entre modèle dimensionnel et relationnel est beaucoup moins pertinente.

Si les modèles dimensionnels restent adaptés à certains besoins de reporting (navigation dans les données : drill down/up/across) ils ne le sont pas, par exemple, pour du datamining. Et, même lorsque la présentation d'un modèle dimensionnel est adaptée, les performances des bases en "mode colonne" ou "in memory" peuvent permettre d'éviter un stockage en mode dimensionnel.

Dans de très nombreux cas, le modèle de données implémenté  dans le cadre d'un projet BI est donc maintenant purement relationnel.

Enfin, et quoi qu'il en soit, on ne saurait que trop recommander à quiconque conçoit un modèle, de commencer par la question "Quels sont les objets concernés et comment se rattachent-ils les uns aux autres ?" plutôt que par "Quels sont mes indicateurs et axes d'analyse ?".

 

« Le modèle du DW doit être indépendant de celui des sources »

>> Vrai. Mais pas si simple...

Voilà bien qui semble une évidence : Les modèles des systèmes source sont contraints, par exemple par les progiciels, les exigences de la maintenance ou les performances. Les modèles décisionnels, eux, seraient plus proche du métier et donc "agnostiques" de la source de données.

Il est effectivement fort utile d'introduire un découplage entre les composants source et les composants décisionnels, pour permettre aux uns d'évoluer sans impacter les autres. Mais attention, il ne faut pas décréter trop vite que "les modèles des composants source ne sont pas assez métier".

Rappelons, s'il est besoin, que les systèmes opérationnels sont utilisés par le métier. Par conséquent, les choix de modélisation qui y sont fait influencent les utilisateurs. Lorsqu'un SO fusionne deux notions théoriquement distinctes (par exemple "tiers" et "relation commerciale" ou encore "OPCVM et "Mandat de gestion"), alors, même si c'est à tort, les métiers prennent l'habitude de les confondre.

Dans ce cas, vouloir à tout prix, renormaliser dans un modèle décisionnel "pur" c'est prendre le risque :

• d'être "plus royaliste que le roi" en assurant au métier que les notions qu'il manipule ne sont pas métier

• d'un écart structurel entre les différentes visions : les utilisateurs risquent de ne pas reconnaitre leurs données

• d'un blocage face à une renormalisation impossible

Il s'agit donc de ne pas être condescendant vis-à-vis des systèmes sources. Leurs choix de modélisation ne doivent pas être repris sans être chalengés mais ils ne doivent pas non plus être écartés sans une analyse approfondie. C'est une des raisons pour lesquelles il est difficile de mettre en place un DW multi entité, lorsque les SO des différentes entités ne sont pas homogènes. C'est également une des raisons pour lesquelles la modélisation de données est affaire d'experts.

 

Prochaine publication de déconstruction des idées reçues "les systèmes financiers, ce n'est pas du décisionnel".

David F.