Prise en charge des évolutions temporelles

Les données d’un entrepôt évoluent, parfois lentement, parfois de manière irrégulière. Pour un cube OLAP, cela ne se limite pas à simplement ajouter une date : il s’agit de concevoir des structures et des règles qui reflètent la période de validité d’une information, le moment où elle a été constatée et le moment où elle est devenue vraie côté métier.

C’est ce qui nous amène à distinguer trois notions de temps :

Le temps métier (valid time) : c’est la période pendant laquelle une information est valide dans le monde réel. Par exemple, une promotion sur un produit qui commence le 1er mars et se termine le 31 mars.
Le temps de transaction (transaction time) : c’est le moment où l’information a été enregistrée dans le système. C’est la date à laquelle la donnée a été créée ou modifiée.
Le temps de chargement : c’est la date et l’heure à laquelle l’information a été importée dans l’entrepôt de données. Contrairement aux deux notions précédentes, cette information technique est rarement exposée dans le modèle analytique final ; elle est généralement conservée dans les métadonnées des flux d’intégration (ETL) à des fins de traçabilité.

Cette granularité triple peut sembler théorique ; elle devient pourtant très concrète dès qu’un prix est rétroactivement corrigé, qu’un client change d’adresse à la fin du mois mais que l’ERP n’est mis à jour que le 2 du mois suivant, ou qu’un produit est renommé sans effet sur le passé. Un modèle bi-temporel répond aux deux cas (temps métier et temps de transaction).

Exemple bi-temporel minimal (SQL Server)

CREATE TABLE dim_client_bitemp ( 
    cle_client_surrogat_sk BIGINT IDENTITY(1,1) PRIMARY KEY,  
-- Clé de substitution auto-incrémentée 
    cle_client_naturelle_nk NVARCHAR(255) NOT NULL, 
-- Clé métier...

Stratégies avancées pour les Slowly Changing Dimensions

Les trois principaux types de SCD (type 1 (Ecraser), type 2 (Historiser) ou type 3 (garder l’ancienne valeur)), vus dans le chapitre Modélisation des dimensions et hiérarchies, ne suffisent pas toujours. Il arrive que certains attributs d’une même dimension n’évoluent pas à la même vitesse (chapitre Modélisation des dimensions et hiérarchies - Gestion des Slowly Changing Dimensions (SCD).

Par exemple :

Le nom d’un client change rarement (il peut être historisé en type 2).
Son segment marketing change plus souvent (historisation en type 2 également).
Son score d’appétence, lui, peut changer presque tous les jours. Une historisation en type 2 serait ici un désastre, car la table gonflerait de manière explosive.

Pour gérer cette complexité, l’approche hybride type 6 combine plusieurs techniques : une historisation complète, un écrasement des attributs non critiques, et le stockage de la valeur précédente pour les analyses avant/après. Cette méthode évite de créer une multitude de dimensions.

1. La mini-dimension pour les attributs volatils

Pour les attributs qui changent très fréquemment (comme les scores ou les codes promotionnels), la mini-dimension est une solution efficace. Il s’agit d’une petite table séparée qui contient ces attributs volatils et est liée à la dimension principale.

Les faits peuvent alors référencer :

La mini-dimension, pour obtenir une vue précise et exacte au moment de la transaction.
La dimension principale, si la mini-dimension sert plus pour le contexte d’analyse que pour les rapports finaux.

Cette approche présente plusieurs avantages pour le cube : une cardinalité (le nombre de valeurs uniques) plus faible dans la dimension principale, des agrégations plus rapides et des hiérarchies plus stables.

2. Gérer les relations complexes dans le temps

Les relations de type plusieurs-à-plusieurs prennent une nouvelle dimension avec l’historisation. Un produit peut appartenir à plusieurs familles, ou un client à plusieurs segments, et cela peut changer dans le temps.

Une table de pont (bridge table) historisée...

Cas spécifique des cubes temporels

Un cube qui gère le temps ne se contente pas d’une simple dimension Date. Il doit pouvoir restituer les informations selon différents points de vue temporels :

As of : l’état des données à une date précise.
As was : l’état des données tel qu’il était connu à une date donnée.
As corrected : l’état après que des corrections ont été appliquées.

Cette approche, connue sous le nom de bi-temporalité (temps métier vs. temps de transaction), est une fonctionnalité puissante mais exigeante. Elle implique l’utilisation de paires de colonnes pour les dates de validité et les dates système. Plutôt que d’exposer des tables complexes directement, une bonne pratique consiste à préparer en amont des vues matérialisées ou des tables dénormalisées adaptées à chaque type de lecture. Le cube expose alors des groupes de mesures dédiés à chaque usage, ce qui simplifie grandement l’expérience de l’utilisateur.

1. La dimension Temps et ses rôles

La dimension Temps est la colonne vertébrale de l’analyse. Elle doit inclure des attributs variés (jour ouvré, semaine ISO, jours fériés, etc.) et jouer différents rôles...