Blog ENI : Toute la veille numérique !
En raison d'une opération de maintenance, le site Editions ENI sera inaccessible le mardi 10 décembre, en début de journée. Nous vous invitons à anticiper vos achats. Nous nous excusons pour la gêne occasionnée
En raison d'une opération de maintenance, le site Editions ENI sera inaccessible le mardi 10 décembre, en début de journée. Nous vous invitons à anticiper vos achats. Nous nous excusons pour la gêne occasionnée
  1. Livres et vidéos
  2. Modélisation décisionnelle
  3. Repenser la donnée
Extrait - Modélisation décisionnelle Concevoir la base de données pour les traitements OLAP
Extraits du livre
Modélisation décisionnelle Concevoir la base de données pour les traitements OLAP Revenir à la page d'achat du livre

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.

  • Vision source : l’objet est présent de manière distincte dans plusieurs applications.

  • Vision cible : l’objet est unique et embarque les différentes valeurs des applications sources.

images/3-0.png

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…

images/3-1.png

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 ?"

images/3-2.png

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…).

Du transactionnel à l’analyse

L’instantanéité guide le système transactionnel : la modification d’une valeur dans le système doit être répercutée de suite dans les modules afférents. Dans le système décisionnel, les valeurs des données sont chargées en différé à une fréquence généralement quotidienne, voire hebdomadaire ou mensuelle. Ce retard entre la génération d’une transaction et sa présence dans le SID n’est pas ou peu problématique :

  • Les besoins d’analyse portent essentiellement sur des périodes passées.

  • Le périmètre d’étude est assez large et comprend un nombre important de transactions, l’impact de quelques transactions est donc relativement négligeable.

Ces données n’étant qu’à des fins d’analyse, les accès à la base de données sont en lecture uniquement ! En cas d’erreur détectée dans les données - et c’est souvent le cas lors de l’émergence du décisionnel - la correction ne doit pas être effectuée dans le système transactionnel par une action du décisionnel. Soit la correction sera prise en charge par les personnes responsables du décisionnel, soit le décisionnel comportera...

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 :

  • Nuit à la lisibilité du modèle et sa simplicité d’utilisation.

  • Nuit aux performances de calcul déporté et de requêtage.

Il faut donc veiller à choisir :

  • La bonne granularité : ne pas avoir des données trop fines.

  • Le bon périmètre : ne pas ajouter d’axes ou indicateurs inutiles.

  • La bonne durée de rétention des données : ne pas conserver des données trop anciennes.

  • Homogénéisation des données.

  • Identification propre au modèle.