Repenser la donnée

De la technique au métier

Dans les systèmes sources, la donnée a été pensée à fin d’optimisation technique : utilisation d’identifiants, absence de redondance, normalisation… Le modèle décisionnel, lui, doit permettre de répondre à une optimisation métier : comprendre et analyser la donnée au plus vite.

La construction d’un modèle de données spécifique permet de travailler dans un environnement conçu exclusivement pour l’analyse. Sa mise en place permet non pas de "bricoler" la donnée source mais de se l’approprier et ainsi la modeler indépendamment de la source : créer ses propres objets, sa propre codification.

Des "applications" aux "objets"

Chaque système source dispose de son propre référentiel et son propre écosystème de données. "Bouchers et jockeys parlent tous de cheval" : il s’agit bien d’un même et unique cheval mais décliné dans chaque application de manière indépendante et différente.

Exemples de visions applications et visions objets

Une chaîne de grande distribution met en place un SID. La vision "applicative" éclate ses données selon ses applications informatiques : son module de gestion des stocks, le module marketing, module RH…

La vision "objet" éclate cette même donnée selon des entités qui feront, à la suite, l’objet d’une étude. Les objets représentent des objets concrets tels qu’un magasin, un client ou un employé. Cette vision permet de répondre à des questions comme "Quel est le chiffre d’affaires de chaque magasin ?" ou "Quel est le montant du panier moyen de mes clients ?"

De l’événement à la période

Si les applications sources s’articulent autour des événements afin de pouvoir les créer ou les modifier, le besoin d’analyse dans une entreprise se porte sur un périmètre plus large et l’analyse se porte sur une période temporelle comportant plusieurs événements.

Par conséquent, il n’y a pas d’intérêt à identifier un événement en particulier (un unique achat, une seule transaction bancaire). La modélisation décisionnelle peut donc s’accompagner d’une absence d’identifiant pour les événements, puisqu’ils sont amenés à être agrégés pour être étudiés dans un contexte plus large.

C’est une conséquence du point précédent : l’intérêt n’est plus d’étudier un événement qui correspond à une action du système applicatif (une vente est enregistrée dans le module de vente, un nouveau client est ajouté…) mais bien à l’étude autour d’un objet (nombre de ventes d’un produit, nombre de clients dans une certaine région…).

De l’exhaustivité à la simplicité

Le système décisionnel n’est pas un infocentre et son but n’est pas de dupliquer et d’historiser toutes les données du système transactionnel. Les données sont choisies en fonction des besoins, et non l’inverse.

Comme vu précédemment, le but est de s’approcher au maximum de la granularité 1:1 entre le besoin et le modèle de données. "Trop de données tuent la donnée" serait un bon adage, car trop de données :

Il faut donc veiller à choisir :