L’historisation des données ne consiste pas à conserver toutes les lignes sans règle. Elle impose de choisir quels attributs changent, à quelle date ils prennent effet et comment les faits restent rattachés à la bonne version. Le SCD Type 2 répond à ce besoin, mais une reprise mal cadrée fabrique des historiques incohérents.
- Le SCD Type 1 remplace une valeur et supprime l’état antérieur, ce qui convient aux corrections sans portée analytique.
- Le SCD Type 2 crée une version supplémentaire, avec une clé substitutive et des bornes temporelles, afin de conserver le contexte historique.
- La reprise initiale est le point de fragilité principal, car les dates anciennes, les doublons et les clés métiers instables peuvent rendre l’historique inutilisable.
- La recette doit vérifier les périodes de validité, les jointures avec les faits et la cohérence des règles de changement avant la bascule.
Le propos porte sur la gestion des historiques dans un Data Warehouse, les flux ETL et la reprise de données depuis un socle décisionnel existant. Il ne traite ni de protection des données personnelles ni de règles juridiques de conservation, qui relèvent de votre DPO et de votre direction juridique.
Quels changements doivent réellement déclencher une historisation des données ?
Une dimension ne mérite pas automatiquement un historique complet. Le premier travail consiste à identifier les attributs dont l’évolution change le sens d’un indicateur dans le temps. L’adresse d’expédition d’un client, son segment commercial, son rattachement à une agence ou la catégorie d’un produit peuvent modifier une lecture historique. À l’inverse, la correction d’une faute de frappe dans un nom ne justifie pas forcément une nouvelle version.
Cette distinction doit être formalisée avant de configurer le moindre composant ETL. Lorsqu’elle ne l’est pas, le flux traite tous les écarts de la même façon. Une modification de casse dans une ville crée alors une ligne supplémentaire, au même titre qu’un changement de région commerciale. Après plusieurs années, la dimension grossit sans que l’historique apporte une information exploitable.
Dans une dimension Client, un statut comme « actif », « suspendu » ou « résilié » peut nécessiter une Gestion des historiques si les rapports doivent expliquer la répartition du portefeuille à une date donnée. En revanche, un numéro de téléphone peut être conservé en Type 1 si aucun rapport ne reconstruit les coordonnées utilisées lors d’une transaction. Le choix dépend du besoin de restitution, pas de la capacité technique de la base.
La première erreur consiste à confondre source opérationnelle et modèle décisionnel. La source peut écraser une adresse dès qu’un client déménage. Le Data Warehouse doit, lui, permettre d’interpréter les commandes réalisées avant et après ce changement. Sans règle explicite, les ventes historiques seront rattachées à l’adresse actuelle, et non à celle qui était connue lors de la commande.
Définir une matrice d’attributs avant le développement ETL
Une matrice de décision rend ce choix vérifiable. Elle liste chaque attribut de la dimension, son comportement attendu, la source de référence et la conséquence d’un changement. Cette matrice doit être relue par les responsables de domaine avant que les mappings soient figés. Elle évite que le développeur ETL porte seul une règle métier implicite.
| Attribut de dimension | Traitement recommandé | Raison analytique | Contrôle de recette |
|---|---|---|---|
| Segment commercial | SCD Type 2 | Le segment modifie les analyses de portefeuille et de marge dans le temps. | Comparer le segment attaché aux faits avant et après la date de changement. |
| Adresse de livraison | SCD Type 2 selon le besoin de reporting géographique | Les analyses territoriales historiques peuvent dépendre de l’adresse alors connue. | Vérifier la borne de validité de chaque version client. |
| Orthographe du nom | SCD Type 1 | Une correction typographique ne modifie pas le sens d’un fait passé. | Contrôler l’absence de nouvelle clé substitutive. |
| Code interne de chargement | Hors dimension métier | Cette donnée relève de la traçabilité technique, pas de l’analyse métier. | Contrôler le journal de batch. |
Le tableau doit être conservé avec le dictionnaire de données du socle décisionnel. Un dictionnaire de données exploitable ne décrit pas seulement le nom d’une colonne. Il précise aussi si elle est historisée, quelle source la porte et quelle règle déclenche une nouvelle version.
Une reprise de données rend ce travail encore plus nécessaire. Les systèmes anciens contiennent souvent des attributs recyclés, des codes métiers modifiés sans date de début, ou des valeurs absentes remplacées par des libellés techniques. Reprendre ces lignes sans qualification revient à figer des défauts de source dans une structure qui sera ensuite présentée comme historique.
La question utile n’est donc pas « peut-on conserver ce champ ? ». Elle est « quelle décision serait fausse si cette valeur était projetée dans le passé ? ». Quand aucune réponse métier précise n’existe, une historisation Type 2 crée surtout du volume, de la maintenance et des écarts de restitution difficiles à expliquer.
Comment choisir entre les méthodes SCD Type 1, Type 2 et Type 3 ?
Les Méthodes SCD répondent à des besoins distincts. Les mélanger sans convention rend les dimensions imprévisibles pour les auteurs de rapports et pour les équipes de recette. Le Type 1 écrase, le Type 2 versionne, et le Type 3 conserve un historique limité dans des colonnes séparées. Le bon choix dépend du niveau de preuve attendu dans les restitutions historiques.
Le SCD Type 1 est adapté lorsqu’une valeur ancienne n’a pas de signification pour l’analyse. Une correction de format, une normalisation de libellé ou le remplacement d’un code obsolète peuvent être appliqués directement sur la ligne courante. Cette méthode limite le volume de la dimension et allège les chargements, mais elle interdit toute reconstitution de la valeur précédente.
Le SCD Type 2 est plus exigeant. Chaque évolution retenue ferme la version active puis insère une nouvelle ligne. La clé métier reste stable, tandis que la clé substitutive change. Les tables de faits doivent référencer cette clé substitutive pour rattacher chaque événement à la version correcte de la dimension.
Le Type 3 a un usage plus étroit. Il conserve par exemple une colonne « région actuelle » et une colonne « région précédente ». Cette approche peut répondre à une comparaison limitée entre l’état courant et l’état antérieur. Elle devient insuffisante dès qu’un client a connu plusieurs changements ou qu’une analyse doit remonter sur plusieurs exercices.
Le SCD Type 2 ne doit pas devenir une règle par défaut
Le Type 2 est souvent choisi par prudence, puis appliqué à tous les attributs. Cette décision est coûteuse dans un parc ancien. Une dimension Produit de 80 000 références peut générer plusieurs centaines de milliers de versions si le flux historise le prix, le libellé marketing, le fournisseur, la disponibilité et des indicateurs techniques sans distinction.
Le volume n’est pas le seul problème. Les rapports doivent savoir quelle version utiliser. Une analyse des ventes par famille produit peut vouloir la famille connue au jour de la vente. Un rapport de portefeuille actuel peut au contraire vouloir la famille actuelle, appliquée à l’ensemble de l’historique. Ces deux besoins sont légitimes, mais ils ne s’appuient pas sur la même jointure.
Le modèle doit donc exposer clairement les deux lectures. Une relation sur la clé substitutive donne le contexte historique de l’événement. Une relation sur la clé métier, maîtrisée et explicitement nommée, permet une lecture recalculée selon l’état actuel. Dans un univers ou un modèle sémantique, masquer cette différence derrière un objet générique produit des chiffres contradictoires.
Le Type 2 est pertinent lorsqu’un changement modifie la qualification d’un fait au moment où ce fait a été enregistré. Un changement de catégorie de produit, de responsable commercial ou de secteur géographique entre dans cette logique. À l’inverse, il faut conserver un Type 1 lorsque l’ancienne valeur n’a aucune portée de gestion et ne doit jamais apparaître dans une restitution.
Une dimension peut aussi combiner les approches. Le nom normalisé d’un client peut être traité en Type 1, tandis que son segment, son réseau commercial et son statut contractuel suivent une logique Type 2. Ce modèle hybride est plus lisible qu’une dimension où chaque colonne crée une nouvelle version, y compris lorsque l’écart ne porte que sur un accent ou un espace.
Un socle décisionnel maintenable ne se juge pas au nombre de lignes historisées. Il se juge à la capacité d’expliquer, dans un rapport, pourquoi une vente de janvier est rattachée à une catégorie, une agence ou un segment donné.
Quelle structure de dimension SCD Type 2 permet de relier correctement les faits ?
Une Slowly Changing Dimension Type 2 repose sur une séparation nette entre la clé métier et la clé substitutive. La clé métier identifie l’entité dans le système source. Elle peut être un code client, une référence produit ou un identifiant salarié. La clé substitutive identifie une version précise de cette entité dans le Data Warehouse.
Cette différence paraît technique, mais elle conditionne les résultats de restitution. Un même client peut posséder le code métier C-1045 pendant dix ans. S’il change de segment commercial trois fois, la dimension contient quatre versions. Chacune a sa propre clé substitutive, mais toutes partagent la même clé métier C-1045.
Les colonnes de début et de fin de validité encadrent chaque version. Une colonne de type effective_from indique le premier instant de validité. Une colonne effective_to porte la fin de validité, ou une valeur conventionnelle lorsque la ligne reste active. Un indicateur is_current facilite l’accès à la version courante sans remplacer les contrôles de période.
Les colonnes qui doivent être documentées dans la dimension
Une dimension Client Type 2 comprend habituellement une clé substitutive, une clé métier, les attributs historisés, les dates de validité et les éléments d’audit. Le hash d’attributs peut compléter le dispositif. Il représente une empreinte calculée sur les champs retenus pour la détection des changements.
Le hash réduit les comparaisons colonne à colonne dans certains flux ETL, mais il ne décide pas de la règle métier. Si la composition de l’empreinte inclut un champ technique volatile, chaque chargement détectera un changement artificiel. Si elle exclut un attribut qui devait être historisé, le changement passera inaperçu.
Un modèle de dimension bien tenu comporte aussi des informations de chargement. La date du batch, l’identifiant de flux et la source d’origine rendent les corrections traçables. Ces colonnes ne remplacent pas les périodes métier. Une ligne peut être chargée aujourd’hui pour refléter un changement qui a pris effet il y a plusieurs semaines.
Ce dernier cas est fréquent dans les reprises. Une direction commerciale peut régulariser tardivement le rattachement d’un client. Si le flux utilise la date de chargement comme date d’effet, le modèle raconte que le changement s’est produit à la date de correction. Il faut distinguer la date de connaissance technique de la date de validité métier.
Le schéma en étoile reste généralement le plus lisible pour cette mécanique. Les faits portent la clé substitutive de la version au moment de leur chargement. Les dimensions portent le contexte descriptif. Les principes de structuration d’un Data Warehouse aident à séparer ces responsabilités, plutôt qu’à faire porter l’historique par des colonnes éparses dans les tables de faits.
Les cas tardifs demandent une décision explicite. Si un fait de février arrive en avril, il doit être rattaché à la version active en février, pas à la version active au jour du chargement. Cette recherche temporelle doit être testée dans le mapping. Elle ne peut pas être laissée à l’interprétation d’un rapport Webi ou d’une mesure calculée.
La structure devient fragile lorsque la clé métier elle-même est réutilisée par la source. Certains progiciels recyclent un code client après clôture. Dans ce cas, une simple recherche sur la clé métier fusionne deux entités distinctes. Il faut alors intégrer un identifiant source plus fiable, une période de validité ou une règle de rupture documentée dans le flux.
La clé substitutive ne protège pas, à elle seule, contre les ambiguïtés de la source. Elle garantit seulement qu’une version reconnue comme distincte possède un identifiant distinct dans le modèle décisionnel.
Comment construire un flux ETL SCD Type 2 sans créer de périodes incohérentes ?
Un flux ETL d’historisation doit exécuter les opérations dans un ordre contrôlé. Il reçoit la donnée source, normalise les attributs, identifie la version courante, détecte les écarts retenus, ferme l’ancienne version puis crée la nouvelle. Une inversion de ces étapes peut créer deux lignes actives pour la même clé métier ou des périodes qui se chevauchent.
La zone de préparation est utile pour isoler les données avant leur intégration. Elle permet de dédoublonner les arrivées, de contrôler les clés absentes et de comparer la source à la version actuelle de la dimension. Sans cette étape, le traitement mélange souvent anomalies source et règles de chargement dans une même requête difficile à auditer.
Les attributs doivent être normalisés avant comparaison. Un espace en fin de libellé, une casse différente ou un format de téléphone variable ne doit pas provoquer une nouvelle version. La normalisation doit toutefois rester documentée. Transformer « SAS » et « SA » en une même valeur n’est plus un nettoyage technique, c’est une règle métier qui peut modifier la lecture d’un portefeuille.
Fermer une version et ouvrir la suivante dans une même opération
Lorsqu’un changement est validé, l’ancienne ligne est clôturée avec une date de fin cohérente. La nouvelle version reprend la clé métier, reçoit une nouvelle clé substitutive et devient la seule ligne courante. Si la granularité est journalière, une convention claire doit définir si la date de fin est incluse ou exclue. Cette convention doit être identique dans tous les flux.
Une convention fréquente consiste à considérer que la date de début est incluse et que la date de fin est exclue. Une version ouverte le 1er mars et fermée le 15 mars couvre alors les faits du 1er au 14 mars. La version suivante commence le 15 mars. Cette approche évite les chevauchements, à condition que les jointures temporelles utilisent les mêmes opérateurs.
Une transaction atomique est nécessaire lorsque le moteur de données le permet. La fermeture de la version précédente et l’insertion de la suivante doivent réussir ensemble ou être annulées ensemble. Sinon, une interruption entre les deux opérations peut laisser un client sans version active, ou produire une seule version courante alors que l’attribut a déjà changé dans la source.
Les composants dédiés à la Gestion des historiques dans Talend ou Informatica peuvent accélérer le paramétrage, mais ils ne remplacent pas la conception. Un composant SCD ne sait pas si un attribut doit être suivi en Type 1 ou Type 2 sans convention donnée par le projet. Il ne sait pas non plus interpréter une date d’effet métier absente de la source.
Les charges parallèles exigent une vigilance particulière. Deux flux qui mettent à jour la même dimension avec des fenêtres différentes peuvent chacun identifier une version comme courante. Le contrôle final doit vérifier qu’il n’existe qu’une ligne is_current = 1 par clé métier, sauf exception formalisée.
La journalisation de batch doit enregistrer le volume reçu, les lignes rejetées, les insertions de nouvelles versions, les clôtures et les anomalies de clé. Ces chiffres servent à la recette. Ils permettent aussi d’identifier une dérive, par exemple lorsque le nombre de versions créées double après une modification de format dans le système source.
Un flux SCD fiable ne se limite pas à détecter les différences. Il doit démontrer que chaque différence a produit une période valide, une seule version active et une trace de chargement permettant de remonter à la source.
Quels pièges de reprise de données compromettent un historique déjà en production ?
Les Pièges de reprise apparaissent souvent lorsque le projet tente de reconstituer plusieurs années d’évolution à partir d’une source qui ne conserve que son état courant. Dans ce cas, charger la photographie disponible dans une dimension Type 2 ne recrée pas le passé. Cela crée une première version datée de manière conventionnelle, et cette convention doit être visible dans la documentation.
Attribuer arbitrairement une date de début ancienne à toutes les lignes donne l’impression d’un historique complet. Pourtant, cette date ne prouve rien sur l’état réel des attributs à l’époque. Dans les rapports, les utilisateurs peuvent ensuite interpréter cette ligne comme une valeur historiquement certaine. Cette confusion est l’une des causes les plus fréquentes de contestation en recette.
Une reprise de données doit séparer trois catégories. La première contient les périodes prouvées par des archives ou des journaux source. La deuxième contient les données connues à la date d’extraction initiale. La troisième contient les zones inconnues, pour lesquelles aucune reconstitution fiable n’est possible. Ces trois catégories ne doivent pas être présentées sous le même statut.
Les doublons et les changements rétroactifs doivent être traités avant le chargement
Les doublons de clés métiers constituent un risque immédiat. Deux lignes source portant le même identifiant client, avec des attributs divergents, ne peuvent pas être chargées mécaniquement dans une même version active. Il faut identifier la règle de priorité, la source de référence et la date à laquelle chaque information a été validée.
Les changements rétroactifs posent un autre problème. Une correction peut indiquer qu’un client a changé de segment le 1er février, alors que l’information est reçue le 20 mars. Si des faits existent entre ces deux dates, le flux doit savoir s’il recalcule les rattachements historiques ou s’il conserve la clé attribuée au moment du chargement. Ce choix doit être arbitré avant la bascule.
Dans un socle ancien, les rapports peuvent aussi contenir des règles invisibles dans les tables. Un filtre de statut client posé au niveau d’une condition d’objet dans un univers BusinessObjects peut exclure des versions historiques sans apparaître dans le Webi. Reprendre seulement les tables et les rapports visibles ne suffit pas. Les conditions, contextes de requête et objets calculés doivent être inventoriés.
Un infocentre conserve parfois des extractions qui ne sont plus disponibles dans le système transactionnel. Ces jeux peuvent aider à établir un état de référence, mais ils doivent être qualifiés. Une extraction mensuelle ne permet pas de dater un changement intervenu entre deux arrêtés. Elle atteste seulement l’état observé à chaque date d’extraction.
La reprise doit aussi traiter les suppressions. Une absence dans la source ne signifie pas toujours qu’une entité doit être fermée dans la dimension. Il peut s’agir d’un filtre, d’un incident de chargement ou d’un périmètre source réduit. Fermer automatiquement toutes les lignes absentes transforme une anomalie temporaire en historique métier erroné.
Un protocole de reprise utilisable comporte au minimum les contrôles suivants.
- Comparer le nombre de clés métiers distinctes entre l’extraction source, la zone de préparation et la dimension cible.
- Vérifier qu’une clé métier ne possède qu’une version courante après chaque chargement.
- Identifier les périodes qui se chevauchent ou présentent une date de fin antérieure à la date de début.
- Isoler les lignes chargées avec une date d’effet conventionnelle, afin qu’elles ne soient pas confondues avec des périodes prouvées.
- Tester les faits arrivés tardivement sur des dates où la dimension possède plusieurs versions.
Une reprise ne devient pas fiable parce que toutes les lignes ont été chargées. Elle devient défendable lorsque le projet distingue ce qu’il sait reconstituer, ce qu’il suppose et ce qu’il ne peut pas prouver.
Comment organiser la recette des dimensions historiques avant la bascule ?
La recette d’une dimension SCD ne doit pas se limiter à compter les lignes insérées. Un volume identique peut masquer des périodes invalides, des rattachements de faits erronés ou des changements de Type 1 traités comme du Type 2. Le contrôle doit porter sur les versions, les dates d’effet et les restitutions produites par les rapports.
Le premier jeu de tests couvre la création initiale. Une nouvelle clé métier doit générer une seule version courante, avec des attributs conformes à la source et une date de début attendue. Le second couvre l’absence de changement. Une ligne strictement identique ne doit pas créer une version supplémentaire, même si elle est rechargée plusieurs fois.
Le troisième jeu de tests couvre une modification sur un attribut historisé. L’ancienne version doit être fermée selon la convention définie. La nouvelle doit recevoir une clé substitutive différente. Les faits antérieurs et postérieurs à la date d’effet doivent être rapprochés de la bonne version, avec des résultats expliqués et acceptés par les métiers.
Mettre en place un double run limité mais utile
Le double run consiste à produire pendant une période définie les restitutions depuis l’ancien socle et depuis le nouveau. L’objectif n’est pas de promettre des chiffres identiques. Les modèles, les calendriers, les règles de filtrage et les données reprises peuvent différer. L’objectif est de mesurer les écarts, de les expliquer et de décider lesquels sont acceptables.
Un contrôle utile compare les indicateurs à une granularité suffisante. Une comparaison globale du chiffre d’affaires peut être rassurante tout en masquant un mauvais rattachement par segment ou par région. Il faut croiser au moins une période, une dimension historisée et une mesure de fait. Le résultat doit distinguer les écarts de données source, les écarts de règle et les défauts techniques.
Les responsables de recette doivent conserver la trace des écarts acceptés. Un écart lié à une correction de clé métier peut être légitime. Un écart causé par une jointure effectuée sur la version actuelle au lieu de la version historique ne l’est pas. Sans registre d’écarts, les mêmes discussions reviennent à chaque comité de validation.
Les rapports critiques doivent être classés selon leur utilisation réelle. Un rapport financier mensuel et un rapport ouvert deux fois par an ne portent pas le même risque de bascule. Les logs d’audit doivent couvrir une période assez longue pour inclure les rapports trimestriels et annuels. Une fenêtre de consultation trop courte exclut précisément les restitutions qui ressortent lors des clôtures.
La documentation de recette doit préciser les limites de l’historique repris. Si les versions antérieures à une date donnée proviennent d’une photographie initiale, ce point doit figurer dans les règles de restitution. Un utilisateur ne doit pas découvrir, après la bascule, que les analyses de plusieurs exercices reposent sur un état reconstruit et non sur des événements source datés.
La bascule devient raisonnable lorsque les écarts significatifs sont identifiés, que les périodes de validité sont contrôlées et que les rapports de pilotage utilisent explicitement la lecture historique ou la lecture courante attendue.
Quelle différence existe entre une clé métier et une clé substitutive dans un SCD Type 2 ?
La clé métier identifie l’entité dans le système source, par exemple un code client. La clé substitutive identifie une version précise de cette entité dans le Data Warehouse. Plusieurs clés substitutives peuvent donc correspondre à une seule clé métier lorsque les attributs historisés changent.
Un SCD Type 2 doit-il historiser toutes les colonnes d’une dimension ?
Non. Seuls les attributs dont l’évolution modifie l’interprétation d’un fait passé doivent créer une nouvelle version. Les corrections techniques, les normalisations de forme ou les informations sans usage historique peuvent rester en Type 1.
Comment traiter une donnée source dont la date de changement est inconnue ?
La ligne peut être chargée comme état initial à la date de reprise, avec un statut documentaire explicite. Il ne faut pas lui attribuer une date ancienne présentée comme certaine si aucune archive ne permet de la prouver.
Pourquoi des faits historiques peuvent-ils être rattachés à une mauvaise version de dimension ?
Cette erreur survient lorsqu’une jointure utilise la version courante plutôt que la clé substitutive enregistrée avec le fait, ou lorsqu’un fait arrivé tardivement n’est pas recherché dans la plage de validité correspondant à sa date métier.
Le dossier complet Chantiers de migration : chiffrer la charge et sécuriser la bascule
