---
title: "star schema and dimensional modelling | Skills We Assign For | Azendo"
description: "Star schemas in the warehouse — denormalisation, snowflaking and query performance, plus the Azendo roles assigned for it."
url: "https://azendo.co/skills/star-schema-and-dimensional-modelling/"
---

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

# star schema and dimensional modelling.

A star schema is the canonical dimensional layout: a central fact table joined directly to denormalised dimension tables. Its shape makes queries simple to write and easy for a warehouse optimiser to plan.

## Where star schema and dimensional modelling fits on a long engagement.

Denormalising dimensions is a deliberate trade. Storage is repeated, which costs almost nothing in a columnar warehouse, in exchange for fewer joins, simpler queries and better optimiser behaviour. The instinct to normalise is correct for transactional systems and wrong here.

Snowflaking — normalising dimensions into further tables — is usually a mistake made for tidiness. It adds joins to every query and complexity to every analyst's mental model, and it saves storage that was not scarce. There are narrow cases where it is right, and they are narrower than the frequency with which it appears.

## What an assigned team does with star schema and dimensional modelling.

Slowly changing dimensions are the part that requires an actual decision from the business. Whether historical facts should reflect the customer's segment at the time or their current segment is not a technical question, and both answers are correct for different reporting purposes.

Getting that stated explicitly rather than inferred from an implementation is what prevents a whole class of later argument, and it is settled at scoping as part of [how the monthly fee is built](https://azendo.co/pricing/).

## What we use star schema and dimensional modelling for.

* Queries an analyst writes without help A fact joined directly to its dimensions, with no intermediate tables to learn.
* Optimiser-friendly shape A layout warehouse engines plan well, rather than a normalised graph they struggle with.
* History handled by explicit decision A stated rule on whether facts carry attributes as they were or as they are.

## How star schema and dimensional modelling capacity is assigned.

Schema design is assigned inside data engineering capacity, with history-handling decisions taken by the business and implemented rather than assumed.

## Roles we assign star schema and dimensional modelling for

* [BI Developer Data science](https://azendo.co/services/data-science/bi-developer/)

## Service lines it sits in

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

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

## Related in data pipelines

* [Talend — skill we assign for](https://azendo.co/skills/talend/)
* [SSIS — skill we assign for](https://azendo.co/skills/ssis/)
* [Change data capture — skill we assign for](https://azendo.co/skills/change-data-capture/)
* [incremental loads — skill we assign for](https://azendo.co/skills/incremental-loads/)
* [data modelling — skill we assign for](https://azendo.co/skills/data-modelling/)
* [dimensional design — skill we assign for](https://azendo.co/skills/dimensional-design/)
* [slowly changing dimensions — skill we assign for](https://azendo.co/skills/slowly-changing-dimensions/)
* [version-controlled transformations — skill we assign for](https://azendo.co/skills/version-controlled-transformations/)

## Tell us what your roadmap needs star schema and dimensional modelling 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/)