One model per source table rule in dbt - Step-by-Step Execution

Concept Flow - One model per source table rule

Identify source tables

↓

Create one model per source table

↓

Write SQL SELECT for each model

↓

Run dbt to build models

↓

Models reflect source tables individually

↓

Use models for downstream analysis

This flow shows how for each source table, you create one dbt model that selects from it, keeping models simple and focused.

Execution Sample

dbt

select * from raw.customers;

select * from raw.orders;

Two simple dbt models each selecting all data from one source table.

Execution Table

Step	Action	Model Created	SQL Query	Result
1	Identify source table 'customers'	None	N/A	Source table found
2	Create model 'customers'	customers.sql	select * from raw.customers;	Model ready
3	Identify source table 'orders'	None	N/A	Source table found
4	Create model 'orders'	orders.sql	select * from raw.orders;	Model ready
5	Run dbt build	customers.sql, orders.sql	Run both queries	Models built separately
6	Use models in analysis	customers, orders	select * from {{ ref('customers') }};	Data from customers model
7	Exit	N/A	N/A	All models created and ready

💡 All source tables have one corresponding model; dbt run completes successfully.

Variable Tracker

Variable	Start	After Step 2	After Step 4	After Step 5	Final
models_created	[]	['customers']	['customers', 'orders']	['customers', 'orders']	['customers', 'orders']
dbt_run_status	Not run	Not run	Not run	Success	Success

Key Moments - 2 Insights

Why do we create one model per source table instead of combining multiple tables in one model?

Creating one model per source table keeps models simple and easier to maintain, as shown in execution_table steps 2 and 4 where each model selects from only one source.

What happens if you forget to create a model for a source table?

That source table won't have a corresponding model, so downstream analysis can't use it. Execution_table step 7 shows all models created; missing one would stop here.

Visual Quiz - 3 Questions

Look at the execution table, after which step is the 'orders' model created?

A Step 4

B Step 5

C Step 2

D Step 3

💡 Hint

Check the 'Model Created' column in execution_table rows.

According to variable_tracker, what is the status of dbt_run_status after step 5?

A Not run

B Success

C Failed

D Running

💡 Hint

Look at the 'dbt_run_status' row and the 'After Step 5' column.

If you combined both source tables into one model, how would the execution_table change?

A The dbt run would fail

B There would be more steps for each source table

C There would be only one model creation step instead of two

D No change in the table

💡 Hint

Refer to the number of model creation steps in execution_table.

Concept Snapshot

One model per source table rule:
- Create one dbt model for each source table
- Each model contains a simple SELECT from its source
- Keeps models clear and maintainable
- Run dbt to build all models separately
- Use models for downstream analysis

Full Transcript

In dbt, the 'One model per source table' rule means you create a separate model for each source table you want to use. For example, if you have source tables named 'customers' and 'orders', you write one model selecting from 'customers' and another selecting from 'orders'. This keeps your models simple and easy to manage. The execution flow starts by identifying each source table, then creating a model for it, running dbt to build these models, and finally using these models in your analysis. The execution table shows each step, including model creation and running dbt. The variable tracker shows how the list of models grows and the dbt run status changes from not run to success. Key moments include understanding why one model per source table is better and what happens if a model is missing. The visual quiz tests your understanding of when models are created and the dbt run status. Remember, this rule helps keep your data transformations organized and clear.