Slowly Changing Dimensions
As of 2026-10-10
Every BW-to-Datasphere migration hits the same wall: an analyst asks what a customer's region was at order time, and the SCD design decides whether the answer is right or silently wrong. This module gives the Type 1/2/6 decision with its HANA cost trade-offs, a working idempotent SCD2 load pattern, and the two-model SAC split (current-state vs historical) that keeps dimension pickers clean. Consultants who can defend this design and validate it against a HANA execution plan routinely turn it into a Principal/Senior Architect rate conversation in DACH and Benelux, because the client already knows the risk and is paying to avoid it.
What you will learn
- Select the correct SCD type (Type 1, Type 2, Type 6, or a hybrid within a single dimension entity) for a given set of SAP dimension attributes, with written rationale covering business query requirements, HANA performance implications, and maintenance cost at scale
- Implement a complete, idempotent SCD Type 2 load process for a Datasphere local dimension table using a two-phase Data Flow (close-old then insert-new), including change detection via attribute hash comparison and surrogate key assignment at fact load time
- Diagnose and resolve the three most common SCD production failures in BW-to-Datasphere migrations: non-idempotent load processes generating duplicate versions, BW surrogate key dependencies leaking into Datasphere models, and SAC dimension member pickers showing multiple entries per business entity
- Design two Datasphere analytic model configurations from the same SCD2 dimension table — one current-state (filtered to IS_CURRENT = TRUE for operational SAC dashboards) and one historical (with date-range join for period-close reporting) — and validate both with an HANA EXPLAIN PLAN to confirm equality-join surrogate key usage
The Deceptively Hard Problem of Slowly Changing Dimensions
Slowly Changing Dimensions (SCD) appear conceptually simple — a customer moves, you update the record — but they contain more production failure modes than almost any other dimensional modelling pattern. In SAP analytics landscapes undergoing migration from BW/4HANA to Datasphere, or consolidating legacy BW InfoProviders into Datasphere analytic models, SCD handling is consistently one of the two or three topics where architectural decisions made in month one generate costly rework in month twelve. The reason: SCD correctness is invisible until an analyst asks "what region was this customer in when they placed this order?" and the answer is wrong.
This module is about the engineering judgement — not the textbook definitions — that separates a correctly operating SCD from one that silently corrupts historical reporting.
Prerequisites
- Intermediate hands-on experience on SAP analytics projects
- Review core concepts first: C087, C083, C047
Outcomes
- Work through a realistic scenario: A DACH automotive Tier-1 supplier is migrating its BW/4HANA customer and material master — versioned today through time-dependent InfoObjects.
- Recognize and avoid the anti-pattern: Non-idempotent SCD2 load — Re-running the load on an unchanged extract creates duplicate effective-dated rows.
- Apply the module's core decision: Type 1 vs Type 2 vs Type 6 for a given dimension attribute — choose Type 2 for any attribute a financial or compliance report must reproduce as-of a date.
- Track mastery with the KPI: SCD2 load idempotency (target: Zero duplicate versions created by a repeated extract or backfill; red flag: Any new row appears from an unchanged snapshot).
Full module available to members. The full module adds: the decision framework · the end-to-end scenario walkthrough · the KPI scorecard · the anti-patterns · the code blocks · the knowledge check · the diagrams.