---
title: "slowly changing dimensions | Skills We Assign For | Azendo"
description: "Slowly changing dimensions — type 1 versus type 2, and the Azendo roles assigned for it."
url: "https://azendo.co/skills/slowly-changing-dimensions/"
---

[Skills](https://azendo.co/skills/) Data pipelines 

# slowly changing dimensions.

Slowly changing dimensions are the patterns for handling attributes that change over time. Type 1 overwrites and keeps no history; type 2 adds a new row with validity dates and preserves it. The choice decides what historical reports can say.

## Where slowly changing dimensions fits on a long engagement.

The distinction matters more than its dry name suggests. If a customer moves from the small-business segment to enterprise, type 1 makes every historical order appear as enterprise; type 2 keeps last year's orders attributed to small business. Both answer a legitimate question, and reporting built on the wrong one is wrong in a way that is very hard to notice.

Type 2 costs more than the pattern suggests. Dimension tables grow with every change, queries must join on the validity window rather than just the key, and loading logic has to detect changes and close the previous row correctly. It is the right choice often, but not by default.

## What an assigned team does with slowly changing dimensions.

This is a business decision that is routinely made by whoever implemented the table. The result is a warehouse where some dimensions keep history and some do not, with no stated reason, and reports that disagree depending on which they touched.

Making it an explicit, recorded decision per dimension is what prevents that, and it is the sort of standard the assigned specialists hold as described in [how an assignment runs](https://azendo.co/how-it-works/).

## What we use slowly changing dimensions for.

* Historical reporting that stays true Type 2 where facts must reflect attributes as they were at the time.
* Current-state reporting kept simple Type 1 where only the present value matters, without paying for history.
* A consistent, recorded policy Each dimension's treatment decided and documented, so reports cannot disagree silently.

## How slowly changing dimensions capacity is assigned.

Dimension design is assigned under [data engineering outsourcing](https://azendo.co/services/data-engineering/), with history requirements taken from the business rather than chosen by the implementer.

## Roles we assign slowly changing dimensions for

* [ETL Developer Data engineering](https://azendo.co/services/data-engineering/etl-developer/)

## Service lines it sits in

* [Data engineering](https://azendo.co/services/data-engineering/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in data pipelines

* [Spark — skill we assign for](https://azendo.co/skills/spark/)
* [Flink — skill we assign for](https://azendo.co/skills/flink/)
* [Dagster — skill we assign for](https://azendo.co/skills/dagster/)
* [Prefect — skill we assign for](https://azendo.co/skills/prefect/)
* [Airbyte — skill we assign for](https://azendo.co/skills/airbyte/)
* [Informatica — skill we assign for](https://azendo.co/skills/informatica/)
* [Talend — skill we assign for](https://azendo.co/skills/talend/)
* [SSIS — skill we assign for](https://azendo.co/skills/ssis/)

## Tell us what your roadmap needs slowly changing dimensions for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)
