Layers and schemas
🎯You'll be able to
Organise a warehouse into raw, staging and mart layers in separate schemas, and say what belongs in each.
🏠The everyday picture
A restaurant kitchen has a store room (ingredients as delivered), a prep counter (washed and cut) and the pass (plated dishes). The waiter takes only from the pass.
📘What it really is
-
Raw or landing: data as it arrived, kept for re-running. SabziSathi keeps raw files in
raw/; some teams load them into arawschema unchanged. -
Clean: rows checked and typed by the loader:
clean.order_lines, with quarantine inclean.quarantineand the run log inops. -
Staging: one model per source table, renamed and tidied, nothing joined yet:
staging.stg_order_lines. Personal data is cut down here, before it spreads (Lesson 5). -
Marts: tables built for questions: facts and dimensions (DT6) and summaries such as
marts.mart_daily_sales. Dashboards and analysts read only from marts. -
Schemas separate the layers and make permissions simple: analysts can read
marts; only the pipeline can writeclean. - Names that say what things are:
stg_for staging,dim_for dimensions,fct_for facts,mart_for summaries.
📝A worked example
Input: in the solution, cd warehouse and run dbt ls --profiles-dir . (with SABZI_KEY_SALT set).
Expected output: models under sabzisathi.staging (four stg_ models) and sabzisathi.marts (dimensions, the fact table and three
marts), plus the tests. Built tables appear in the schemas staging (as views) and marts (as tables).
🌍Where it's used
- dbt projects: the staging and marts pattern is dbt's own recommendation.
- Lakehouses: the same idea is often called bronze, silver and gold.
- Regulated companies: separate schemas let auditors see exactly which layer a report reads.
📝Case scenario
A fintech's analysts built reports straight from staging tables. When a source system renamed a column, 40 reports broke at once. Moving reports to marts, with staging absorbing the rename, meant one model changed and every report kept working.
🖱️Try it
Open the starter's warehouse/models folder and list what's missing compared with this lesson's layers. Success: you notice there's no
area history, no tests and that personal data passes straight into a mart.
⚠️Common mistakes
- Reports on staging or raw tables. Sign: source changes break dashboards. Fix: reports read marts only.
- Joining in staging. Sign: staging models depend on each other in a tangle. Fix: one source table per staging model; join in marts.
- One schema for everything. Sign: you can't give analysts access without giving them everything. Fix: a schema per layer.
🛠️For your project
Project 3 test 1 builds the dashboard from a copy of the warehouse with every layer but the marts removed.
✅Quick check
What goes in a staging model?
Show the answer
One source table, renamed and tidied, with nothing joined.
Why do dashboards read only from marts?
Show the answer
So source changes are absorbed in earlier layers instead of breaking reports.