Historiser les données

1. Une évolution de la réalité métier

L’historisation des dimensions traduit techniquement l’évolution du contexte métier. En effet, bien qu’il puisse s’agir d’une correction (mauvaise saisie d’une adresse, d’un nom…), ces évolutions correspondent la plupart du temps à une réalité métier : le client a réellement changé d’adresse, changé de salaire…

D’un point de vue technique, on distingue deux types d’évolutions :

L’identification de l’évolution d’une dimension comme "rapide" ou "lente" ne repose pas sur une valeur cartésienne car elle dépend de la granularité et de la période de l’entrepôt de données. Le tout est d’éviter d’avoir à la fois une dimension qui soit trop importante mais surtout qui grandisse trop vite : si les changements concernent une dizaine d’évolutions par sujet sur la durée de rétention de l’entrepôt de données (par exemple, une entreprise cliente change en moyenne une fois de dénomination commerciale durant la période étudiée), on peut alors considérer qu’il s’agit d’évolution lente. A contrario, si le nombre de changements est de l’ordre de la centaine ou plus, on passera alors sur des modèles d’évolution rapide.

Il ne faut pas oublier que tout le but du décisionnel est de permettre des analyses rapides : le temps de requêtage se retrouverait grevé...

1. Identification des faits

L’historisation des faits n’est possible que si un fait en particulier peut être identifié, afin de le distinguer de sa valeur d’origine, et désactiver cette dernière. Cependant, comme évoqué de nombreuses fois depuis le début de l’ouvrage, les faits ne sont pas censés être identifiés, puisqu’ils ne sont pas censés faire l’objet d’opérations uniques.

On a cependant évoqué le fait qu’une clé fonctionnelle pouvait être conservée et renseignée comme attribut de la table de faits du datawarehouse. Cette hypothèse avait initialement été évoquée afin de faciliter le débogage et la maintenance en permettant de lier une ligne dans le datawarehouse à celle d’origine dans l’ODS. Mais la présence de cette clé permet dorénavant d’historiser les faits, grâce à la possibilité de définir des périodes de validité pour chaque fait.

2. Problématique et historisation des faits

L’historisation des faits relève d’une autre problématique que celle de l’historisation des dimensions. Si ces dernières évoluent techniquement pour être en accord avec une évolution métier, la correction d’un fait ne relève a priori que de la correction. En effet, un fait représentant une transaction, celle-ci a toujours une unique valeur, quelle que soit son époque d’analyse.

La solution la plus...

1. Identification du contexte analytique de la donnée

Compte tenu des impacts de l’historisation des données, tant en termes de volumétrie que de complexité de mise en œuvre, il convient de n’historiser que le strict nécessaire. Ainsi, il peut être choisi de n’historiser qu’une partie des tables du datawarehouse, ou, de manière plus affinée, de n’historiser qu’une partie des attributs d’une table.

Comme évoqué précédemment, l’intérêt de l’historisation est de replacer une donnée dans un contexte historique : on peut donc déduire que tout attribut ne contextualisant pas la donnée n’a pas vocation à être historisé. Exemple : numéro de facture, nom et prénom d’un individu... L’identification du "caractère analytique" d’un attribut peut s’évaluer dans sa capacité à apparaître comme axe d’analyse d’un rapport.

On peut ainsi catégoriser chaque attribut selon quatre types. Cela permet de déduire si un attribut doit être historisé ou non, selon la catégorie à laquelle il se rattache. Ces types d’attributs sont :

Exemple

La date de naissance d’un client permet d’analyser une donnée par tranche d’âges...

1. Des données historiques mais non historisées

En plus des complexités propres à la mise en place de l’historisation évoquées depuis le début de ce chapitre, s’ajoute une problématique, et non des moindres, quant au chargement initial des données et à la reprise des données.

En effet, dans le cas où c’est le système d’information décisionnel, et non le système opérationnel source, qui assure l’historisation des données, comment gérer les données antérieures au démarrage du décisionnel ? Contraints par des objectifs de réactivité, la plupart des SIO ne conservent que les événements mais non les référentiels. Dans ce cas, il est totalement impossible donc de recontextualiser les données générées avant le démarrage du décisionnel en l’absence pure et simple de données.

Quelle que soit la méthode qui sera choisie, il faudra informer les utilisateurs (ou au moins la maîtrise d’ouvrage) que les données antérieures au lancement du SID seront potentiellement mal recontextualisées.

2. Utiliser le contexte initial du SID

La manière la plus simple de traiter le cas est donc de contextualiser les données antérieures...

1. Entre contrainte technique et utilité métier

La période d’historisation et de rétention des données du système décisionnel est souvent limitée dans le temps, pour des problématiques évidentes de volumétrie. Au-delà des simples contraintes techniques, l’analyse sur une période trop longue n’est pas forcément jugée nécessaire, voire pertinente, par le métier. En effet, des entreprises dans des secteurs dont l’environnement évolue très vite pourraient ne pas trouver d’utilité à analyser des données trop anciennes tant les contextes ne seraient alors pas comparables.

La granularité du problème ne se limite ni à l’entreprise ni au projet, mais le besoin et les contraintes peuvent différer au sein d’un même système décisionnel. En effet, une partie des données peut nécessiter du métier une plus longue période d’historisation et être sujette à des volumétries plus réduites, quand le reste du système décisionnel ne le nécessite pas ou ne le permet pas. Le système décisionnel peut alors être découpé en plusieurs domaines fonctionnels, dont il faudra étudier la faisabilité et le besoin d’historisation qui est propre à chacun d’eux.

La manière la plus évidente est de traiter chaque étoile indépendamment des autres. Ce choix s’explique...

1. Reconsidérer le problème

Comme le montre ce chapitre, l’historisation est une problématique lourde à gérer tant pour le métier, de par les nombreuses questions à trancher, que techniquement, avec une mise en application assez lourde.

Il est donc recommandé de prendre du temps en amont avec les utilisateurs sur la nécessité d’historiser ou non le modèle, quitte à n’historiser qu’une partie des dimensions. Toutes les dimensions doivent-elles être historisées ? Tous les attributs d’une dimension doivent-ils être historisés ?

Il est légitime de se demander si une dimension évoluant trop rapidement apportera une vraie valeur ajoutée à l’analyse finale.

2. Calcul sur une période

L’historisation pose une nouvelle problématique en cas de calcul de mesures sur une période : sur quelle valeur ventiler un sujet si celui-ci a changé de valeur entre le début et la fin de la période ?

Deux alternatives, que devra trancher une nouvelle fois le métier :

Exemple...