Creating your first model in dbt - Try It Yourself

Creating your first model

📖 Scenario: You are working as a data analyst at a retail company. You want to create a simple dbt model that selects customer data from a source table and prepares it for analysis.

🎯 Goal: Build a basic dbt model that selects customer names and their total purchase amounts from the source table raw.customers.

📋 What You'll Learn

Create a dbt model SQL file named customer_purchases.sql

Select the columns customer_id, customer_name, and total_purchases from raw.customers

Filter to include only customers with total_purchases greater than 100

Order the results by total_purchases in descending order

💡 Why This Matters

🌍 Real World

Creating dbt models helps organize and transform raw data into clean, usable datasets for business analysis.

💼 Career

Data analysts and engineers use dbt models to build reliable data pipelines and prepare data for reporting and machine learning.

1

Create the initial dbt model file

Create a dbt model SQL file named customer_purchases.sql that selects the columns customer_id, customer_name, and total_purchases from the source table raw.customers.

dbt

-- Your SQL code here
SELECT customer_id, customer_name, total_purchases
FROM raw.customers

Hint

Use a SELECT statement to choose the columns and FROM to specify the source table.

2

Add a filter for total purchases

Add a WHERE clause to the existing model to include only customers with total_purchases greater than 100.

dbt

SELECT customer_id, customer_name, total_purchases
FROM raw.customers
-- Add a WHERE clause to filter total_purchases > 100

Hint

Use WHERE total_purchases > 100 to filter the rows.

3

Order the results by total purchases

Add an ORDER BY clause to the model to sort the results by total_purchases in descending order.

dbt

SELECT customer_id, customer_name, total_purchases
FROM raw.customers
WHERE total_purchases > 100
-- Add ORDER BY total_purchases DESC

Hint

Use ORDER BY total_purchases DESC to sort from highest to lowest.

4

Display the final model output

Print the final SQL query for the dbt model customer_purchases.sql.

dbt

-- Print the final SQL query
print("SELECT customer_id, customer_name, total_purchases FROM raw.customers WHERE total_purchases > 100 ORDER BY total_purchases DESC")

Hint

Use a print statement to show the final SQL query as a string.

Practice

1. What is the main purpose of a dbt model?

easy

A. To write Python scripts for data analysis

B. To store raw data without changes

C. To create visual dashboards

D. To transform raw data into clean, usable tables

Solution

1. Step 1: Understand the role of dbt models

   dbt models are SQL files that transform raw data into clean tables for analysis.

2. Step 2: Compare options with this role

   Only To transform raw data into clean, usable tables describes transforming raw data into clean tables, which matches the purpose of dbt models.

3. Final Answer:

   To transform raw data into clean, usable tables -> Option D

4. Quick Check:

   dbt model purpose = transform raw data [OK]

Hint: Remember: dbt models clean and transform data [OK]

Common Mistakes:

• Confusing models with dashboards
• Thinking models store raw data unchanged
• Assuming models are Python scripts

2. Which of the following is the correct way to define a simple dbt model SQL file?

easy

A. SELECT * FROM raw_data

B. CREATE MODEL my_model AS SELECT * FROM raw_data

C. dbt run SELECT * FROM raw_data

D. INSERT INTO model SELECT * FROM raw_data

Solution

1. Step 1: Recall dbt model syntax

   A dbt model is a SQL SELECT statement saved as a .sql file in the models folder.

2. Step 2: Evaluate each option

   SELECT * FROM raw_data is a simple SELECT statement, which is the correct way to define a model. Options B, C, and D use incorrect syntax or commands not used in dbt model files.

3. Final Answer:

   SELECT * FROM raw_data -> Option A

4. Quick Check:

   dbt model = simple SELECT statement [OK]

Hint: dbt models are just SELECT queries saved as files [OK]

Common Mistakes:

• Using CREATE MODEL syntax (not valid in dbt)
• Trying to run dbt commands inside SQL files
• Using INSERT statements instead of SELECT

3. Given the following dbt model SQL code saved as models/my_first_model.sql:

SELECT id, name FROM raw_customers WHERE active = true

What will be the output when you run dbt run?

medium

A. Nothing happens because dbt run does not create models

B. An error because of missing CREATE TABLE statement

C. A new table or view named my_first_model with active customers only

D. The raw_customers table will be deleted

Solution

1. Step 1: Understand what dbt run does

   Running dbt run executes model SQL files and creates tables or views with the model name.

2. Step 2: Analyze the model SQL

   The model selects id and name from raw_customers where active is true, so the output table will contain only active customers.

3. Final Answer:

   A new table or view named my_first_model with active customers only -> Option C

4. Quick Check:

   dbt run creates model tables = filtered active customers [OK]

Hint: dbt run creates tables from your SELECT queries [OK]

Common Mistakes:

• Expecting CREATE TABLE in model SQL
• Thinking dbt deletes source tables
• Believing dbt run does nothing

4. You wrote this dbt model SQL file named models/customer_summary.sql:

SELECT customer_id, order_id, COUNT(*) AS orders_count
FROM orders
GROUP BY customer_id

When you run dbt run, you get an error. What is the most likely cause?

medium

A. Missing a semicolon at the end of the SQL statement

B. The GROUP BY column does not match the SELECT columns

C. The SELECT statement is missing a FROM clause

D. The model file is not saved in the models folder

Solution

1. Step 1: Recall GROUP BY rules

   When using GROUP BY, all non-aggregated columns in SELECT must either be aggregated or included in GROUP BY.

2. Step 2: Analyze the SELECT and GROUP BY columns

   SELECT has customer_id (in GROUP BY), order_id (neither aggregated nor grouped), COUNT(*) (aggregated). Thus, GROUP BY does not match SELECT columns.

3. Final Answer:

   The GROUP BY column does not match the SELECT columns -> Option B

4. Quick Check:

   GROUP BY must include all non-aggregated SELECT columns [OK]

Hint: Ensure all non-aggregated SELECT columns are in GROUP BY [OK]

Common Mistakes:

• Forgetting to include non-aggregated columns in GROUP BY
• Assuming semicolon is required
• Saving model outside models folder

5. You want to create a dbt model that shows the total sales per product category, but only for categories with total sales above 1000. Which SQL code correctly implements this in your model file?

hard

A. SELECT category, SUM(sales) AS total_sales FROM sales_data GROUP BY category HAVING SUM(sales) > 1000

B. SELECT category, SUM(sales) AS total_sales FROM sales_data WHERE total_sales > 1000 GROUP BY category

C. SELECT category, SUM(sales) AS total_sales FROM sales_data GROUP BY category HAVING total_sales > 1000

D. SELECT category, SUM(sales) AS total_sales FROM sales_data WHERE SUM(sales) > 1000 GROUP BY category

Solution

1. Step 1: Understand filtering on aggregated values

   To filter groups by aggregated values, use HAVING with the aggregate function, not WHERE.

2. Step 2: Analyze each option

   SELECT category, SUM(sales) AS total_sales FROM sales_data GROUP BY category HAVING total_sales > 1000 uses HAVING total_sales > 1000, but total_sales is an alias and cannot be used directly in HAVING in many SQL dialects. SELECT category, SUM(sales) AS total_sales FROM sales_data GROUP BY category HAVING SUM(sales) > 1000 uses HAVING SUM(sales) > 1000, which is correct. Options B and D incorrectly use WHERE with aggregate functions, which is invalid.

3. Final Answer:

   SELECT category, SUM(sales) AS total_sales FROM sales_data GROUP BY category HAVING SUM(sales) > 1000 -> Option A

4. Quick Check:

   Use HAVING with aggregate functions to filter groups [OK]

Hint: Use HAVING with aggregate functions, not WHERE [OK]

Common Mistakes:

• Using WHERE to filter aggregated results
• Using alias names in HAVING clause
• Forgetting GROUP BY when aggregating