> For the complete documentation index, see [llms.txt](https://docs.mediarithmics.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mediarithmics.io/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/map-your-warehouse-tables-to-a-schema.md).

# Map your warehouse tables to a schema

Expose the subset of your warehouse that your use cases need, as objects of your datamart schema.

## Your goal

Choose which of your warehouse tables become part of your data model, and map them onto the objects of your datamart [schema](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/schema-definition.md) - so the platform can query and segment on them without you moving the data.

## Expected outcome

A published schema whose objects are backed by named tables in your warehouse, carrying exactly the data your use cases need and nothing else.

{% hint style="info" %}
This feature is in Alpha. Contact your account manager to learn more.
{% endhint %}

## Why this step exists

A warehouse that is the source of truth for a whole organisation holds far more than marketing needs, in shapes that were designed for other consumers. Exposing all of it to the platform would be expensive to query and hard to reason about.

The schema is where you draw the line. It is the same decision as in a [Hosted deployment](/setup-and-monitor/plan-and-integrate/choose-your-deployment-mode.md#the-three-modes) - what must be queryable - taken against tables you already have rather than against data you are about to send.

## What does not change

* The schema is still what decides **what is queryable**. Indexed fields can be used in queries and to build segments; the rest cannot. See [Schema definition](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/schema-definition.md).
* `UserPoint` is still the root of the model, and identifiers still decide who data belongs to. See [User identity](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/user-identity.md).
* You still write the schema against your **use cases**, not against your source system's field list.

## What changes

An object of your model no longer takes its data from platform storage. It takes it from a table you name in your warehouse. You declare that binding in **Schema Builder**, the interface where each object of your schema is mapped to the table behind it.

Two questions therefore arrive with every object you declare:

| Question                          | Why it matters                                                                                                                                                                                          |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Which table backs this object** | The mapping is what makes the object queryable. An object with no source table is a declaration with nothing behind it.                                                                                 |
| **How the table is shaped**       | A structure that is natural for your warehouse can be expensive to query object by object. A nested structure scanned in full for every user is the common case worth checking before you commit to it. |

## Work through it in this order

{% stepper %}
{% step %}

### Connect the warehouse first

The mapping needs a declared warehouse connection and the access that goes with it.

[Warehouse compatibilities](/setup-and-monitor/collect-and-manage-your-data/sync-with-your-data-warehouse/warehouse-compatibilities.md) - [Data warehouse sync](/setup-and-monitor/collect-and-manage-your-data/sync-with-your-data-warehouse/data-warehouse-sync.md)
{% endstep %}

{% step %}

### List the questions your use cases ask, then find the tables that answer them

Work from the question to the table, never the other way round. "Users who bought category X in the last 30 days" tells you which table, which column, and whether that column has to be indexed.
{% endstep %}

{% step %}

### Declare the identifiers before the content

Identifiers are what let the platform tie a row to a user. An object mapped without the identifier columns its rows carry cannot be attached to anyone.

[User identifiers](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/user-identity/user-identifiers.md)
{% endstep %}

{% step %}

### Map the objects in Schema Builder, and index only what you will filter on

Bind each object to its table, then index deliberately: every indexed property has a cost on every query that touches the table behind it. Index the properties your `WHERE` clauses actually use.
{% endstep %}

{% step %}

### Publish, and check the result against a real question

Run one of the questions from step two as an [OTQL](/setup-and-monitor/operate-and-monitor/query-your-datamart/otql.md) query and compare the count with what you can obtain directly in your warehouse.
{% endstep %}
{% endstepper %}

## Two rules that save rework

{% hint style="warning" %}
**A table you expose keeps your retention rules, not the platform's.** [Cleaning rules](/setup-and-monitor/collect-and-manage-your-data/clean-and-delete-data/cleaning-rules.md) govern what the platform writes. Data that stays in your warehouse is deleted when you delete it, so the deletion obligations you owe your users remain yours to meet on those tables.
{% endhint %}

{% hint style="warning" %}
**The tables the platform maintains in your warehouse are an interface.** Once your own reporting or downstream applications read them, a change to your schema changes their structure too. Treat a schema change on a mapped object as a change to a contract you share with those consumers, and coordinate it with them.
{% endhint %}

## Verify

* Every object you declared names a table the service account can read.
* A test query returns a count you can reproduce against the same tables in your warehouse.
* Segments built on the new objects compute, and their sizes are plausible.
* You know, per exposed table, whether retention is yours or the platform's.

## Related pages

<table data-view="cards" data-search="false"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Schema definition</strong></td><td>The language, the directives, and the publication workflow.</td><td><a href="/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/schema-definition.md">Schema definition</a></td></tr><tr><td><strong>Choose your deployment mode</strong></td><td>Why the warehouse holds the source of truth in this deployment.</td><td><a href="/setup-and-monitor/plan-and-integrate/choose-your-deployment-mode.md">Choose your deployment mode</a></td></tr><tr><td><strong>Run your computation in the warehouse</strong></td><td>What the platform does with the objects you mapped.</td><td><a href="/setup-and-monitor/collect-and-manage-your-data/sync-with-your-data-warehouse/run-your-computation-in-the-warehouse.md">Run your computation in the warehouse</a></td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.mediarithmics.io/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/map-your-warehouse-tables-to-a-schema.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.