SQL 116 🛢️ Slowly Changing Dimensions (SCD Types 1, 2, 3, and 6)
Dimension data changes slowly and unpredictably. A customer moves to a new city, a product is recategorized, a salesperson transfers to a different region. A data warehouse that overwrites the old value on every change cannot answer the question “what region was this salesperson assigned to when the sale was made?” Slowly Changing Dimensions (SCD) are the patterns that determine how a dimensional model responds to these changes. The choice of pattern is not technical preference; it is a statement about which historical questions the warehouse must be able to answer .
This chapter covers the four SCD types that appear most often in dimensional modeling: Type 1 (overwrite), Type 2 (add row), Type 3 (add column), and Type 6 (hybrid). It examines the table structures, the SQL patterns for loading each type, and the analytical consequences of choosing one over another. Type 0 and Type 4 are mentioned where they clarify the contrast, but the focus is on the types that require active change-management logic.
Key point: Type 1 destroys history by design. Type 2 preserves it by adding rows. Type 3 preserves only the previous value by adding columns. Type 6 combines all three so that every row carries both its historical and current context. The choice depends on which historical questions the business actually needs to answer.
Why SCD types exist
The historical accuracy problem. A fact table records events at a point in time. An order placed in January is associated with the salesperson’s region as it existed in January. If the salesperson moves to a new region in June and the dimension table is overwritten, the January order now appears under the June region. The fact has not changed, but the context used to analyze it has. Type 2 exists to prevent this by preserving the version of the dimension that was active when the fact occurred .
The correction problem. Not every change is a business event. A customer’s email address was entered with a typo and corrected the next day. The old value was never true; it does not deserve a historical row. Type 1 exists for this case: overwrite the incorrect value and move on. Tracking a typo as a historical version adds storage and query complexity for no analytical benefit .
The storage and complexity trade-off. Type 2 dimensions grow with every change. A customer who moves three times has four rows. A product whose price changes weekly has fifty-two rows per year. Joins against Type 2 dimensions require matching on effective dates or a current flag, which adds query complexity . Type 3 exists as a compromise: it tracks only the previous value, which is enough for “current versus previous” comparisons without unbounded growth. Type 6 exists when the business needs both the full history and the current value visible on every row, accepting the ETL complexity that comes with maintaining both .
The hybrid reporting problem. Some reports need to group historical facts by the dimension’s current value, while other reports need to group the same facts by the value at the time of the event. Type 6 allows both from a single dimension table: the historical_* columns preserve the event-time value, and the current_* columns are overwritten on every row to reflect the latest value .
a. Type 1 — Overwrite
Type 1 is the simplest SCD pattern. When a tracked attribute changes in the source, the corresponding column in the dimension table is updated in place. No new row is inserted, no history is retained. The dimension table always reflects the current state of the source system .
The table structure is the same as a non-SCD dimension, with no validity dates or current flags. The load pattern uses MERGE (or an equivalent upsert) to update matching rows and insert new ones.
-- Type 1 dimension: no history columns
CREATE TABLE dim_customer_type1 (
customer_id STRING NOT NULL,
customer_name STRING,
email STRING,
city STRING,
updated_at TIMESTAMP
);
-- MERGE overwrites changed attributes in place
MERGE INTO dim_customer_type1 AS target
USING staging_customers AS source
ON target.customer_id = source.customer_id
WHEN MATCHED AND (
target.customer_name <> source.customer_name
OR target.email <> source.email
OR target.city <> source.city
) THEN UPDATE SET
customer_name = source.customer_name,
email = source.email,
city = source.city,
updated_at = CURRENT_TIMESTAMP()
WHEN NOT MATCHED THEN INSERT (
customer_id, customer_name, email, city, updated_at
) VALUES (
source.customer_id, source.customer_name, source.email,
source.city, CURRENT_TIMESTAMP()
);The analytical consequence is significant. If a customer lived in Seattle and made purchases, and then moves to Portland and the Type 1 update runs, every historical fact associated with that customer now groups under Portland. The Seattle period is invisible. This is acceptable for contact information and error corrections; it is not acceptable for attributes that drive historical reporting .
b. Type 2 — Add Row
Type 2 is the most common SCD pattern for attributes where history matters. Every change inserts a new row, and the previous row is marked as expired. The two rows share the same natural key (the source system identifier) but have different surrogate keys. The fact table references the surrogate key, which means historical facts remain tied to the dimension version that was active when the fact occurred .
A Type 2 dimension requires at least three additional columns: a validity start date, a validity end date, and a current flag. The current row uses a far-future end date (9999-12-31) or a NULL end date, depending on the implementation convention .
-- Type 2 dimension: versioned rows
CREATE TABLE dim_customer_type2 (
customer_sk BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
customer_id STRING NOT NULL, -- natural key
customer_name STRING,
city STRING,
valid_from TIMESTAMP NOT NULL,
valid_to TIMESTAMP NOT NULL,
is_current BOOLEAN NOT NULL
);
-- Step 1: expire the current row when a tracked attribute changes
MERGE INTO dim_customer_type2 AS target
USING staging_customers AS source
ON target.customer_id = source.customer_id AND target.is_current = TRUE
WHEN MATCHED AND (
target.customer_name <> source.customer_name
OR target.city <> source.city
) THEN UPDATE SET
valid_to = CURRENT_TIMESTAMP(),
is_current = FALSE;
-- Step 2: insert a new current row for changed records
INSERT INTO dim_customer_type2 (
customer_id, customer_name, city, valid_from, valid_to, is_current
)
SELECT
s.customer_id, s.customer_name, s.city,
CURRENT_TIMESTAMP(),
CAST('9999-12-31' AS TIMESTAMP),
TRUE
FROM staging_customers s
JOIN dim_customer_type2 t
ON s.customer_id = t.customer_id
AND t.is_current = FALSE
AND t.valid_to = (SELECT MAX(valid_to) FROM dim_customer_type2
WHERE customer_id = s.customer_id);The two-step pattern is standard because a single MERGE cannot both update the existing row and insert its replacement. Some platforms support a single statement with multiple WHEN clauses, but the two-step approach is portable and easier to reason about .
The query cost is the trade-off. Joining a fact table to a Type 2 dimension requires matching on the surrogate key (if the fact was loaded with the correct version) or on the natural key and a date range (if the fact is being retroactively assigned). The second pattern is more expensive, which is why the current flag and the surrogate key exist: they allow the ETL process to resolve the correct version at load time rather than at query time .
c. Type 3 — Add Column
Type 3 tracks limited history by adding columns for the previous value alongside the current value. When an attribute changes, the current value is shifted into the previous column and the new value becomes current. No new row is inserted. The dimension table keeps one row per entity, regardless of how many times the attribute changes .
-- Type 3 dimension: current and previous values in the same row
CREATE TABLE dim_customer_type3 (
customer_id STRING PRIMARY KEY,
customer_name STRING,
current_city STRING,
previous_city STRING,
last_change_date DATE,
updated_at TIMESTAMP
);
-- MERGE shifts current to previous before updating
MERGE INTO dim_customer_type3 AS target
USING staging_customers AS source
ON target.customer_id = source.customer_id
WHEN MATCHED AND target.current_city <> source.city THEN UPDATE SET
previous_city = target.current_city, -- shift old current to previous
current_city = source.city, -- new value becomes current
last_change_date = CURRENT_DATE(),
updated_at = CURRENT_TIMESTAMP()
WHEN NOT MATCHED THEN INSERT (
customer_id, customer_name, current_city, previous_city,
last_change_date, updated_at
) VALUES (
source.customer_id, source.customer_name, source.city,
NULL, CURRENT_DATE(), CURRENT_TIMESTAMP()
);The limitation is structural. Once the value changes a second time, the first previous value is overwritten by the second. Only the most recent change is retained. This is sufficient for “current versus previous” comparisons—for example, reporting sales by current region alongside sales by previous region—but it cannot answer questions that require the full sequence of changes . Type 3 is rarely used as a standalone pattern for this reason, but it appears as a component of Type 6.
d. Type 6 — Hybrid
Type 6 combines Type 1, Type 2, and Type 3 in a single table. It preserves full version history through Type 2 row insertion. It stores the current value on every historical row through a Type 1 overwrite applied to a set of current_* columns. It stores the previous value on the current row through Type 3 columns. The result is a table where every row carries three layers of context: the value as of that row’s validity period, the value that preceded it, and the value as of today .
-- Type 6 dimension: history + current + previous
CREATE TABLE dim_customer_type6 (
customer_sk BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
customer_id STRING NOT NULL,
-- Historical values (Type 2: fixed per row)
historical_name STRING,
historical_city STRING,
-- Current values (Type 1: overwritten on ALL rows)
current_name STRING,
current_city STRING,
-- Previous value (Type 3: only meaningful on the current row)
previous_city STRING,
valid_from TIMESTAMP NOT NULL,
valid_to TIMESTAMP NOT NULL,
is_current BOOLEAN NOT NULL
);The load procedure has three steps. First, expire the current row and insert a new version with the new historical values, the new current values, and the old current value shifted into the previous column. Second, update the current_* columns on all rows for that customer, not just the current row. Third, mark the new row as current.
-- Step 1: expire current and insert new version
UPDATE dim_customer_type6
SET valid_to = CURRENT_TIMESTAMP(), is_current = FALSE
WHERE customer_id = :id AND is_current = TRUE;
INSERT INTO dim_customer_type6 (
customer_id, historical_name, historical_city,
current_name, current_city, previous_city,
valid_from, valid_to, is_current
)
SELECT
:id, :new_name, :new_city,
:new_name, :new_city,
(SELECT current_city FROM dim_customer_type6
WHERE customer_id = :id AND is_current = FALSE
ORDER BY valid_to DESC LIMIT 1),
CURRENT_TIMESTAMP(), '9999-12-31', TRUE;
-- Step 2: update current_* on ALL rows for this customer (Type 1 behavior)
UPDATE dim_customer_type6
SET current_name = :new_name,
current_city = :new_city
WHERE customer_id = :id;The analytical payoff is that a single join against the dimension can produce two different groupings without a self-join or a subquery. Grouping by historical_city answers “where were they when the sale happened?” Grouping by current_city answers “where are they now?” Both are available on the same row .
The cost is ETL complexity. Every change requires updating every historical row for that customer, not just the current one. On a customer with many versions, this is a small write amplification per change, but across a large dimension it adds up. The benefit is query simplicity and the ability to compare current and historical context without additional joins.
Complete Example Session
-- ============================================
-- PART 1: SOURCE DATA
-- ============================================
-- staging_customers holds the current state from the source system
-- customer_id is the natural key; it does not change
-- ============================================
-- PART 2: TYPE 1 — OVERWRITE
-- ============================================
CREATE TABLE dim_customer_type1 (
customer_id STRING PRIMARY KEY,
customer_name STRING,
city STRING,
updated_at TIMESTAMP
);
MERGE INTO dim_customer_type1 AS t
USING staging_customers AS s
ON t.customer_id = s.customer_id
WHEN MATCHED AND t.city <> s.city THEN UPDATE SET
city = s.city, updated_at = CURRENT_TIMESTAMP()
WHEN NOT MATCHED THEN INSERT VALUES (
s.customer_id, s.customer_name, s.city, CURRENT_TIMESTAMP()
);
-- ============================================
-- PART 3: TYPE 2 — ADD ROW
-- ============================================
CREATE TABLE dim_customer_type2 (
customer_sk BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
customer_id STRING NOT NULL,
customer_name STRING,
city STRING,
valid_from TIMESTAMP NOT NULL,
valid_to TIMESTAMP NOT NULL,
is_current BOOLEAN NOT NULL
);
-- Expire changed current rows
MERGE INTO dim_customer_type2 AS t
USING staging_customers AS s
ON t.customer_id = s.customer_id AND t.is_current = TRUE
WHEN MATCHED AND t.city <> s.city THEN UPDATE SET
valid_to = CURRENT_TIMESTAMP(), is_current = FALSE;
-- Insert new current rows for changed records
INSERT INTO dim_customer_type2 (
customer_id, customer_name, city,
valid_from, valid_to, is_current
)
SELECT s.customer_id, s.customer_name, s.city,
CURRENT_TIMESTAMP(), '9999-12-31', TRUE
FROM staging_customers s
JOIN dim_customer_type2 t
ON s.customer_id = t.customer_id
AND t.is_current = FALSE
AND t.valid_to = (SELECT MAX(valid_to) FROM dim_customer_type2
WHERE customer_id = s.customer_id);
-- ============================================
-- PART 4: TYPE 3 — ADD COLUMN
-- ============================================
CREATE TABLE dim_customer_type3 (
customer_id STRING PRIMARY KEY,
customer_name STRING,
current_city STRING,
previous_city STRING,
last_change_date DATE
);
MERGE INTO dim_customer_type3 AS t
USING staging_customers AS s
ON t.customer_id = s.customer_id
WHEN MATCHED AND t.current_city <> s.city THEN UPDATE SET
previous_city = t.current_city,
current_city = s.city,
last_change_date = CURRENT_DATE()
WHEN NOT MATCHED THEN INSERT VALUES (
s.customer_id, s.customer_name, s.city, NULL, CURRENT_DATE()
);
-- ============================================
-- PART 5: TYPE 6 — HYBRID
-- ============================================
CREATE TABLE dim_customer_type6 (
customer_sk BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
customer_id STRING NOT NULL,
historical_name STRING,
historical_city STRING,
current_name STRING,
current_city STRING,
previous_city STRING,
valid_from TIMESTAMP NOT NULL,
valid_to TIMESTAMP NOT NULL,
is_current BOOLEAN NOT NULL
);
-- Expire current and insert new version
UPDATE dim_customer_type6
SET valid_to = CURRENT_TIMESTAMP(), is_current = FALSE
WHERE customer_id = :id AND is_current = TRUE;
INSERT INTO dim_customer_type6 (
customer_id, historical_name, historical_city,
current_name, current_city, previous_city,
valid_from, valid_to, is_current
)
SELECT :id, :new_name, :new_city,
:new_name, :new_city,
(SELECT current_city FROM dim_customer_type6
WHERE customer_id = :id AND is_current = FALSE
ORDER BY valid_to DESC LIMIT 1),
CURRENT_TIMESTAMP(), '9999-12-31', TRUE;
-- Overwrite current_* on every row for this customer
UPDATE dim_customer_type6
SET current_name = :new_name, current_city = :new_city
WHERE customer_id = :id;
-- ============================================
-- PART 6: QUERYING TYPE 2 — AS-OF JOIN
-- ============================================
-- Join facts to the dimension version active at fact time
SELECT f.order_id, f.amount, d.city AS city_at_order_time
FROM facts_orders f
JOIN dim_customer_type2 d
ON f.customer_id = d.customer_id
AND f.order_ts >= d.valid_from
AND f.order_ts < d.valid_to;
-- ============================================
-- PART 7: QUERYING TYPE 2 — CURRENT STATE
-- ============================================
SELECT f.order_id, f.amount, d.city AS current_city
FROM facts_orders f
JOIN dim_customer_type2 d
ON f.customer_id = d.customer_id AND d.is_current = TRUE;
-- ============================================
-- PART 8: QUERYING TYPE 6 — BOTH VIEWS
-- ============================================
-- Historical grouping and current grouping from the same join
SELECT
d.historical_city AS city_at_order,
d.current_city AS city_now,
SUM(f.amount) AS total
FROM facts_orders f
JOIN dim_customer_type6 d
ON f.customer_id = d.customer_id
AND f.order_ts >= d.valid_from
AND f.order_ts < d.valid_to
GROUP BY d.historical_city, d.current_city;
-- ============================================
-- PART 9: TYPE 2 WITH DATERANGE (POSTGRES)
-- ============================================
-- Postgres can enforce non-overlapping ranges with an exclusion constraint
CREATE TABLE dim_customer_type2_pg (
customer_id STRING NOT NULL,
city STRING,
validity DATERANGE,
current BOOLEAN,
EXCLUDE USING GIST (customer_id WITH =, validity WITH &&)
);
-- The exclusion constraint prevents overlapping versions for the same customer
-- ============================================
-- PART 10: TYPE SELECTION GUIDE
-- ============================================
-- Corrections only, no history needed → Type 1
-- Full history required for reporting → Type 2
-- Only current vs previous comparison → Type 3
-- Both history and current on every row → Type 6The ten parts trace the table structures and load patterns for each type, then show how the choice affects querying. Part 6 and Part 7 demonstrate the central consequence of Type 2: the same fact table can be joined to produce historical or current groupings depending on the join condition. Part 8 shows Type 6 producing both from a single join.
Quick Reference
SCD Type Comparison
| Type | Mechanism | History | Table Growth | Query Complexity |
|---|---|---|---|---|
| 1 | Overwrite | None | None | Low |
| 2 | Add row | Full | Linear with changes | Medium (date join) |
| 3 | Add column | Previous only | None | Low |
| 6 | Hybrid | Full + current + previous | Linear with changes | Low (single join) |
Required Columns
| Type | Required Columns |
|---|---|
| 1 | None beyond attributes |
| 2 | Surrogate key, valid_from, valid_to, is_current |
| 3 | current_*, previous_*, last_change_date |
| 6 | Surrogate key, historical_*, current_*, previous_*, valid_from, valid_to, is_current |
Load Pattern
| Type | Pattern |
|---|---|
| 1 | MERGE with UPDATE on change |
| 2 | Expire current (UPDATE), insert new (INSERT) |
| 3 | MERGE with shift (previous = current; current = new) |
| 6 | Expire, insert new, then update current_* on all rows |
Best Practices
✅ Do This:
-- Use Type 2 when historical facts must retain their event-time context
valid_from, valid_to, is_current -- ✅-- Use the natural key for matching and a surrogate key for fact joins
customer_id (natural), customer_sk (surrogate) -- ✅-- Use a far-future end date for current rows
'9999-12-31' -- ✅-- In Postgres, use DATERANGE with an exclusion constraint
EXCLUDE USING GIST (customer_id WITH =, validity WITH &&) -- ✅-- For Type 6, update current_* on all rows for the entity
UPDATE ... SET current_city = :new WHERE customer_id = :id -- ✅❌ Don’t Do This:
-- Use Type 1 for attributes that drive historical reporting
UPDATE dim SET region = 'New' WHERE id = 1 -- ❌ (erases history)-- Allow overlapping Type 2 validity ranges
-- (no constraint or check) -- ❌-- Use Type 3 when more than one prior value is needed
-- Only the most recent previous value is retained -- ❌-- Forget to update current_* on historical rows in Type 6
-- Historical rows show stale current values -- ❌Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| Historical facts group under new region | Type 1 overwrite on a Type 2 attribute | Use Type 2 with surrogate key join |
| Type 2 validity ranges overlap | No constraint on (natural_key, range) | Add exclusion constraint or ETL validation |
Current row has no is_current = TRUE | ETL failure between expire and insert | Wrap in transaction; verify after load |
| Type 6 current columns are stale | Only updated new row, not all rows | UPDATE ... WHERE customer_id = :id |
| Type 3 loses second change | Previous column overwritten | Use Type 2 or Type 6 |
Real-World Examples
1. Type 1 Overwrite
MERGE INTO dim SET email = s.email WHEN MATCHED2. Type 2 Expire Current
UPDATE dim SET valid_to = NOW(), is_current = FALSE WHERE id = :id AND is_current = TRUE3. Type 2 Insert New Version
INSERT INTO dim (id, city, valid_from, valid_to, is_current) VALUES (:id, :city, NOW(), '9999-12-31', TRUE)4. Type 2 As-Of Join
JOIN dim d ON f.id = d.id AND f.ts >= d.valid_from AND f.ts < d.valid_to5. Type 3 Shift Previous
UPDATE dim SET previous_city = current_city, current_city = :new WHERE id = :id6. Type 6 Update Current on All Rows
UPDATE dim SET current_city = :new WHERE customer_id = :id7. Postgres DATERANGE
validity DATERANGE, EXCLUDE USING GIST (customer_id WITH =, validity WITH &&)8. Current Row Lookup
SELECT * FROM dim WHERE id = :id AND is_current = TRUE9. Type 2 Current-Only Query
JOIN dim d ON f.id = d.id AND d.is_current = TRUE10. Type Selection
Correction → Type 1. History → Type 2. Current+Previous → Type 3. Both → Type 6.Visual
Type 1: Overwrite
┌──────────────────────────────────────────────────────────────┐
│ BEFORE AFTER │
│ │
│ id=1, city=Seattle id=1, city=Portland │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Jan: $100 │ │ Jan: $100 │ │
│ │ grouped under │ │ grouped under │ │
│ │ Seattle │ │ Portland │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ Seattle is gone. January sales now appear under Portland. │
│ Use when history does not matter (email, typos). │
│ │
└──────────────────────────────────────────────────────────────┘Type 2: Add Row
┌──────────────────────────────────────────────────────────────┐
│ SK ID CITY VALID_FROM VALID_TO CURRENT │
│ │
│ 100 C1 Seattle 2020-01-01 2024-03-01 FALSE │
│ 101 C1 Portland 2024-03-01 9999-12-31 TRUE │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Jan 2024 order │ │ Jun 2024 order │ │
│ │ joins SK=100 │ │ joins SK=101 │ │
│ │ Seattle │ │ Portland │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ Each fact retains the dimension version from its time. │
│ Full history, but table grows with every change. │
│ │
└──────────────────────────────────────────────────────────────┘Type 3: Add Column
┌──────────────────────────────────────────────────────────────┐
│ ID CURRENT_CITY PREVIOUS_CITY LAST_CHANGE │
│ │
│ C1 Portland Seattle 2024-03-01 │
│ │
│ One row per entity. Previous value is available. │
│ A second move overwrites "Seattle" with "Portland". │
│ Only the most recent change is retained. │
│ │
└──────────────────────────────────────────────────────────────┘Type 6: Hybrid
┌──────────────────────────────────────────────────────────────┐
│ SK ID HIST_CITY CUR_CITY PREV_CITY VALID_FROM │
│ │
│ 100 C1 Seattle Portland NULL 2020-01-01 │
│ 101 C1 Portland Portland Seattle 2024-03-01 │
│ │
│ HIST_CITY: value at that row's time (Type 2) │
│ CUR_CITY: value today, same on every row (Type 1) │
│ PREV_CITY: value before current, on current row (Type 3) │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Group by │ │ Group by │ │
│ │ HIST_CITY │ │ CUR_CITY │ │
│ │ = as-of view │ │ = current view │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ Both views from a single join. No self-join needed. │
│ Cost: every change updates current_* on all rows. │
│ │
└──────────────────────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| Type 1 | Overwrite; no history; corrections only |
| Type 2 | Add row; full history; valid_from/valid_to/is_current |
| Type 3 | Add column; previous value only; one row per entity |
| Type 6 | Hybrid; history + current + previous; all in one table |
| Type 2 join | Match on surrogate key or date range |
| Type 6 current columns | Updated on all rows per entity |
| Postgres optimization | DATERANGE with exclusion constraint |
| Type selection | Driven by which historical questions must be answered |
Key takeaways:
- Type 1 is a deliberate amnesia. It overwrites the old value and makes every historical fact associated with that entity appear under the new value. This is correct for corrections and contact information, and wrong for any attribute that drives historical reporting .
- Type 2 is the standard for historical accuracy. Each change creates a new row with its own surrogate key and validity range. Facts loaded with the surrogate key remain tied to the dimension version active when the fact occurred .
- Type 3 tracks only the previous value. It is useful for “current versus previous” comparisons but cannot answer questions that require the full sequence of changes. A second change overwrites the first previous value .
- Type 6 combines all three. Every row carries the historical value (Type 2), the current value (Type 1 overwrite on
current_*), and the previous value (Type 3). The cost is that every change updates all rows for that entity, not just the current one . - The choice is analytical, not technical. The question is not “which type is best” but “which historical questions must this warehouse answer?” If the answer is “where was the customer when they bought?” Type 2 or Type 6 is required. If the answer is “where is the customer now, and what was the previous value?” Type 3 may suffice.
Remember: Slowly Changing Dimensions are the mechanism by which a dimensional model either preserves or destroys the context of historical facts. Type 1 destroys it deliberately for attributes where the old value was never meaningful. Type 2 preserves it at the cost of table growth and query complexity. Type 3 preserves a single step backward at minimal cost. Type 6 preserves everything at the cost of ETL complexity. The pattern that is chosen for a given attribute determines which reports can be produced accurately and which reports will silently mislead. The decision belongs to the business requirement, not to the data engineer’s preference.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!