Skip to content
Data Modeling

03.04 · Concept

Slowly Changing Dimensions

Model changing attributes using Type 1 and Type 2 slowly changing dimensions for point-in-time feature correctness.

Slowly changing dimensions control whether changing entity attributes are overwritten or versioned. Type 1 keeps the current value only, while Type 2 records historical versions with validity windows. Choosing correctly prevents historical facts, features and backtests from being joined to attribute values that were not true at the event time.

What this lesson answers

  • when should I use Type 1 dimensions
  • how do Type 2 dimension joins work
  • how to avoid point in time leakage

Notes

Slowly changing dimensions are a way to model attributes that change over time, such as a customer’s address, a merchant’s risk tier, a user’s subscription plan, or a product’s category. The key question is whether you care only about the latest value or whether you need to know what the value was at the time an event occurred. This matters a lot in feature engineering and analytics because joining today’s dimension value onto historical facts can create incorrect results or data leakage.

Common questions

What is a slowly changing dimension?
A slowly changing dimension is a dimension table design for attributes that can change after an entity is created. Common examples include customer segment, subscription plan, product category or risk tier. The design choice is whether to replace the old value or retain past versions so historical facts can be interpreted correctly.
When is Type 1 the right choice?
Type 1 is right when the previous value has no analytical meaning or should be treated as wrong. Fixing a spelling error, normalising a label or maintaining a current operational view are typical cases. It is risky for feature pipelines if historical events need the attribute value that was true at the time.
How does Type 2 prevent data leakage?
Type 2 stores separate rows for different versions of an entity, with effective time ranges. A fact row is joined to the version whose range contains the event timestamp. That stops a model or analysis from using a later segment, plan or risk value for an earlier transaction or prediction point.