Slowly changing dimensions: overwrite, add a row or add a column

What it is

Dimension attributes change slowly and irregularly, and a warehouse must decide whether a fact recorded last year should be reported under last year's attribute value or today's. The Kimball Group technique pages (cited) define the basic responses. Type 1: the old attribute value in the dimension row is overwritten with the new value, so the attribute always reflects the latest assignment and history is destroyed; aggregates built on the old value must be recomputed. Type 2: a new dimension row is added with the updated values and a new surrogate primary key, which fact rows reference from the moment of the change onward; the page requires at least three extra columns, a row effective date, a row expiration date and a current-row indicator. Type 3 adds an attribute that preserves the old value while the main attribute is overwritten, so reports can group by either the current value or the old one; the page describes the technique as used relatively infrequently. dbt snapshots (cited) implement type 2 over mutable source tables, adding dbt_valid_from and dbt_valid_to to each version; a timestamp strategy detects change through an updated_at column, a check strategy by comparing a list of columns, and a configuration decides whether rows deleted at the source are ignored, invalidated or recorded as a new version.

Why it matters

Without a policy, the same report gives different answers depending on when it runs, and nobody can say whether "sales by region" uses the customer's region at purchase or now. Type 2 answers both questions but multiplies dimension rows and requires every fact load to look up the surrogate key valid at the event time.

How to apply

• Decide per attribute, not per table: corrections of data-entry errors are type 1; real-world changes that reports must attribute historically are type 2.
• Keep the natural key on every type 2 row and index (natural key, valid_from) for as-of lookups; use an open-ended sentinel or NULL for the current row consistently and document which.
• Run snapshots at least as often as the finest reporting period; changes between two snapshots collapse into one version.
• Load facts by joining on the natural key with the validity range that contains the event timestamp, not on the current row.

Pitfalls

Late-arriving dimension changes require re-keying facts already loaded. Type 2 on high-churn attributes (last login) makes the dimension larger than the facts; move such attributes to the fact table or a separate mini-dimension.