Enrichir le modèle

1. Limiter le découpage des objets

"Le mieux est l’ennemi du bien" : ce vieil adage s’applique également au décisionnel. Transformer un modèle de données technique en modèle de données objet est un objectif, mais on ne doit pas tomber dans la frénésie, à vouloir éclater le modèle en une multitude d’objets jusqu’à que ceux-ci soient indivisibles : il faut garder en tête que ces objets doivent avoir un sens pour l’analyse. On a toujours moyen de décrire un objet en un autre objet et ainsi de suite… On arrive alors à un moment où la complexité du modèle dépasse sa valeur ajoutée. Cette fuite en avant s’accompagnant au fur et à mesure d’une difficulté à transposer la donnée dans la modélisation décisionnelle en étoile/flocon, ces difficultés doivent être perçues comme des alertes et amener le concepteur à se demander si cet objet est pertinent au sein d’une analyse.

Exemple

Une chaîne de grande distribution met en place son système décisionnel. Les données reçues des systèmes sources concernant les heures d’ouverture sont sur ce format :

Ainsi, les [OUVERTURES], niveau fin du référentiel, pourraient potentiellement être agrégées sous des objets [HORAIRES SEMAINE], [HORAIRES SAMEDI] et [HORAIRES DIMANCHE ET FÉRIES]. Ceux-ci pourraient également être regroupés sous un objet [HEURE].

Au-delà des difficultés conceptuelles d’une telle modélisation (des plages telles que [8-18] et [10-16] se superposent par exemple), la simple question est : une ventilation par tranche horaire est-elle pertinente ? Peut-être que seule la ventilation par [OUVERTURE] suffit.

2. Les plages de dates dans les faits

1. Les valeurs par défaut sur la dimension temps

Dans le chapitre précédent a été expliquée la création d’éléments par défaut dans les dimensions afin de permettre la ventilation des faits étant mal ou non renseignés sur ces axes. Pour cela, on utilisait alors des valeurs distinctives des identifiants car ceux-ci avaient uniquement un rôle technique.

Dans la dimension temps, la date joue à la fois le rôle d’identifiant technique et celui de code fonctionnel puisqu’elle permet à la fois de décrire l’entité mais également, l’identifie de manière unique : on ne peut donc pas utiliser une date qui désigne explicitement une valeur par défaut !

Tout d’abord, concernant le cas des valeurs "mal renseignées", c’est-à-dire renseignées avec une valeur non présente dans la dimension temps. Cela peut correspondre à deux cas en théorie qui, en pratique, ne seront pas traités :

Reste donc uniquement le cas des valeurs "non renseignées" qui peuvent être traitées de deux manières :

1. Description du problème

Lorsqu’il a été évoqué, dans le chapitre précédent, le sujet de la granularité idéale des données dans l’entrepôt de données, deux cas n’ont pas été abordés :

Une des caractéristiques du décisionnel étant la réunion au sein d’un même système des données issues de plusieurs systèmes d’information, voire de plusieurs entreprises, au-delà du format hétérogène des données, ces données à réunir peuvent être de granularités inégales.

Le traitement à suivre dépendra alors du contexte :

2. Des données opérationnelles trop fines

Le premier cas est bien évidemment le plus simple à traiter : il suffit de rattacher les données reçues sur un agrégat lorsque celles-ci sont plus fines qu’attendu. À ce moment-là, on ne parle pas d’agrégat de données, mais bien de simple rattachement de données...

1. Stratégies de rejet

Après avoir constaté qu’il était nécessaire de mettre en place un contrôle référentiel (modèle en flocon) ou un contrôle dimensionnel (modèle en étoile) pour pouvoir ventiler correctement les faits, la réflexion porte à présent sur la stratégie à adopter pour les faits n’ayant pas validé ledit contrôle.

Que faut-il faire de ces faits ? Exclure ces faits n’est pas forcément la meilleure solution. Puisque les données du décisionnel sont regardées à un niveau global, il peut être préférable de conserver la valeur de mesure pour connaître la valeur consolidée d’un indicateur, quitte à ne pas connaître sa ventilation.

On distingue alors trois choix :

Exemples d’application de stratégies de rejet

On dispose du référentiel suivant ainsi que des transactions suivantes à intégrer :

Dans le cas où l’on choisit de stopper l’intégration en cas de contrôle référentiel erroné, les transactions ne sont pas intégrées car la quatrième ligne de transaction ne passe pas le contrôle.

Dans le cas où on décide de continuer...

1. Création d’un flux de correction

La section précédente s’est intéressée à l’aspect technique liée à la ventilation d’un fait. Si dorénavant, pour des raisons techniques ou métier, on désire corriger manuellement la valeur d’un fait dans le décisionnel, on peut au choix :