A slowly changing dimension of Type 2 keeps the full history of a record. When a tracked attribute changes, the current row is closed with an end date and a new row is added with a new start date, so every version stays queryable. Each version usually has its own surrogate key and a flag for the current row. Reports can then show the value that was true at the time of each fact.
For example, customer 42 lives in Munich until June 30 and moves to Hamburg on July 1. The dimension then holds two rows for customer 42: one with the city Munich, valid from the customer's first load until June 30 and flagged as not current, and one with the city Hamburg, valid from July 1 with an open end date and flagged as current. A sale on June 15 joins to the Munich row through its surrogate key, so a report of sales by city still shows that sale in Munich.
The pipeline compares each incoming record with the current row for its key, usually by a hash of the tracked columns. If nothing changed, it does nothing; if a tracked column changed, it closes the current row and inserts a new one in the same transaction; if only an overwrite column changed, it updates in place. Edge cases need rules: two changes to one key in a single batch, a change that arrives out of order, and a record deleted at the source, which is often closed rather than removed.
Type 2 tables grow with every change, so tracking a column that changes daily can make a dimension larger than its facts; choose the tracked columns deliberately. See also natural key, merge and late-arriving records.
In Emolysis, SCD Type 2 is one of the ten pipeline shapes, with a template and golden tests for Databricks, Snowflake and Microsoft Fabric. The template lets you mark which columns keep history and which are simply updated, as in SCD Type 1.