Problématique de conception des objets

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

a. Périodes basiques

Lorsque l’on veut étudier une plage de dates, il est fort à parier que la valeur n’existe pas en tant que telle dans les systèmes sources. La durée étant une donnée plus analytique qu’opérationnelle, la donnée reçue donnera une date de début et une date de fin, sur deux faits, voire deux flux...

Problématiques de la dimension temps

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 :

Le format de la date est faux : cas impossible dans la pratique, puisque le moteur de base de données ne permet pas de renseigner une date incohérente ou sous un mauvais format dans un champ de type date.
La date est hors scope : la dimension temps est limitée puisqu’il s’agit d’une plage limitée de dates avec un début et une fin. Dans ce cas, la transaction est en dehors du périmètre d’étude et ne doit pas être intégrée dans la table de faits.

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

Ne pas inclure de valeur spécifique dans la table de dimension et laisser la valeur nulle dans la table de faits. Cela implique cependant que la gestion des valeurs nulles dans les axes de la table de faits soit autorisée et gérable dans la solution OLAP retenue, ce qui n’est pas systématique.
Choisir une date dans la dimension sur laquelle positionner les données de la table de faits : le problème évident de cette solution est qu’il sera impossible de distinguer les faits non renseignés positionnés sur une date et les données effectivement...

Problèmes de granularité des transactions reçues

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 granularité différente entre les différentes sources de données.
Une granularité analytique plus fine que celle des données reçues.

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 :

La granularité la moins fine des données reçues correspond au moins à la granularité attendue dans l’entrepôt.
Tout ou une partie des données reçues a une granularité moins fine que celle attendue dans l’entrepôt.

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

Problématiques des référentiels

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 :

Stopper le traitement d’intégration : la non-validation de l’intégrité référentielle est considérée comme critique et anormale et nécessite absolument une correction avant intégration.
Rejeter la ligne : elle ne sera pas intégrée dans la table de faits. Il faut idéalement la réorienter dans une table dédiée pour identifier les lignes non insérées.
L’insérer sur une valeur par défaut : elle sera intégrée à la table de faits et rattachée à une valeur par défaut. Elle participera donc à la valorisation consolidée et sera visible sur l’élément par défaut.

Il n’y a pas forcément une solution unique pour tout le modèle : chaque référentiel doit faire l’objet d’une réflexion pour savoir quelle stratégie sera à adopter pour celui-ci.

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

Problématiques de correction des faits

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 :

Corriger la valeur dans le système source : nécessite d’avoir la main sur le système source (ou que le SI responsable accepte de faire les modifications). Suivant la méthodologie d’historisation retenue, aucune action ne sera nécessaire (dans le cas d’une historisation des modifications des faits) ou bien un rechargement en Annule et Remplace sur la partition sera nécessaire pour mettre à jour les valeurs.
Corriger la valeur dans le système décisionnel : car on désire pouvoir corriger les valeurs sans répercuter (par choix ou contrainte) cette correction dans les systèmes sources.

Il n’y a pas de problème à corriger une donnée uniquement dans le décisionnel ! Le décisionnel n’a pas vocation à être en adéquation avec les systèmes opérationnels… Au contraire, il a justement vocation à s’en émanciper pour en améliorer et valoriser les données...