---
title: "data modelling | Skills We Assign For | Azendo"
description: "Data modelling for warehouses and applications — grain, keys and why models matter, plus the Azendo roles assigned for it."
url: "https://azendo.co/skills/data-modelling/"
---

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

# data modelling.

Data modelling is the design of how data is structured for its purpose: entities, relationships, grain and keys. Transactional models optimise for correct writes; analytical models optimise for comprehensible, fast reads.

## Where data modelling fits on a long engagement.

Grain is the decision everything else follows from. What one row represents — an order, an order line, a daily summary — determines which questions the table can answer and which aggregations are correct. A table whose grain is unclear produces double-counted numbers that are very hard to trace back to their cause.

Analytical and transactional models are genuinely different and should not be reconciled. A normalised schema is right for transactional correctness and wrong for analysts writing queries; a dimensional model is the reverse. Warehouses that expose the application schema directly push that mismatch onto every analyst, permanently.

## What an assigned team does with data modelling.

Models outlive the systems that produce them. A warehouse model built well remains usable across several source-system replacements, which is why the modelling deserves more design attention than the pipeline moving the data.

That long horizon is the argument for the same people holding the model over years rather than each project extending it locally, which is what a [dedicated development team](https://azendo.co/services/dedicated-development-team/) is for.

## What we use data modelling for.

* Grain stated and enforced Every table with a documented meaning for one row, so aggregations cannot double count.
* An analytical layer separate from the source Models built for the questions, rather than the application schema exposed to analysts.
* Keys that survive source changes Surrogate keys, so replacing a source system does not break every downstream reference.

## How data modelling capacity is assigned.

Modelling capacity is assigned under [data engineering outsourcing](https://azendo.co/services/data-engineering/), with the model treated as a long-lived asset rather than a by-product of a pipeline.

## Roles we assign data modelling for

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

## 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

* [dbt — skill we assign for](https://azendo.co/skills/dbt/)
* [Fivetran — skill we assign for](https://azendo.co/skills/fivetran/)
* [Databricks — skill we assign for](https://azendo.co/skills/databricks/)
* [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/)

## Tell us what your roadmap needs data 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/)