Dimensions à évolution lente (SCD)
À jour au 2026-08-16
Toute migration BW vers Datasphere se heurte au même mur : un analyste demande quelle était la région d'un client au moment de la commande, et c'est la conception SCD qui décide si la réponse est juste ou silencieusement fausse. Ce module transmet le choix Type 1/2/6 avec ses arbitrages de coût HANA, un pattern de chargement SCD2 idempotent qui fonctionne réellement, et le découpage SAC en deux modèles (état courant vs historique) qui garde les sélecteurs de dimension propres. Les consultants capables de défendre ce design et de le valider sur un plan d'exécution HANA en font régulièrement un argument de négociation de TJM Principal/Senior Architect en DACH et au Benelux, parce que le client connaît déjà le risque et paie pour ne pas le subir.
Ce que vous apprendrez
- Sélectionner le type SCD correct (Type 1, Type 2, Type 6, ou un hybride au sein d'une seule entité de dimension) pour un ensemble donné d'attributs de dimension SAP, avec une justification écrite couvrant les exigences de requête métier, les implications de performance HANA, et le coût de maintenance à l'échelle
- Implémenter un processus de chargement SCD Type 2 complet et idempotent pour une table de dimension locale Datasphere via un Data Flow en deux phases (clôturer-ancienne puis insérer-nouvelle), incluant la détection de changements via comparaison de hash d'attributs et l'attribution de clé de substitution au moment du chargement des faits
- Diagnostiquer et résoudre les trois échecs SCD en production les plus courants dans les migrations BW vers Datasphere : processus de chargement non idempotents générant des versions en double, dépendances de clé de substitution BW s'infiltrant dans les modèles Datasphere, et sélecteurs de membres de dimension SAC affichant plusieurs entrées par entité métier
- Concevoir deux configurations de modèle analytique Datasphere à partir de la même table de dimension SCD2 — une d'état courant (filtrée à EST_COURANT = VRAI pour les tableaux de bord SAC opérationnels) et une historique (avec jointure sur plage de dates pour le reporting de clôture de période) — et valider les deux avec un EXPLAIN PLAN HANA pour confirmer l'utilisation d'une jointure d'égalité sur la clé de substitution
Le problème trompeusement difficile des Slowly Changing Dimensions
Les Slowly Changing Dimensions (SCD) paraissent conceptuellement simples — un client déménage, vous mettez à jour l'enregistrement — mais elles contiennent plus de modes d'échec en production que presque tout autre pattern de modélisation dimensionnelle. Dans les paysages analytiques SAP en cours de migration de BW/4HANA vers Datasphere, ou en cours de consolidation d'InfoProviders BW legacy dans des modèles analytiques Datasphere, la gestion des SCD est systématiquement l'un des deux ou trois sujets où les décisions architecturales prises en mois un génèrent des retravaux coûteux en mois douze. La raison : la correction des SCD est invisible jusqu'à ce qu'un analyste demande « dans quelle région était ce client lorsqu'il a passé cette commande ? » et que la réponse soit fausse.
Ce module traite du jugement d'ingénierie — pas des définitions du manuel — qui sépare une SCD fonctionnant correctement d'une qui corrompt silencieusement le reporting historique.
Type 1 vs Type 2 vs Type 6 : choisir sous incertitude
Module complet réservé aux abonnés. Le module complet ajoute : le cadre de décision · le cas guidé de bout en bout · la grille de KPI · les anti-patterns · les blocs de code · le contrôle de connaissances · les schémas.