Bird
Raised Fist0
dbtdata~15 mins

Naming conventions at scale in dbt - Mini Project: Build & Apply

Choose your learning style10 modes available
Naming conventions at scale
📖 Scenario: You work in a company where many data tables are created daily. To keep things clear and easy to find, you need to follow a naming rule for these tables.Imagine you have a list of raw data table names, and you want to create new names for cleaned tables by adding a prefix and suffix.
🎯 Goal: You will create a dictionary of raw table names, set a prefix and suffix, then generate new cleaned table names using these rules.
📋 What You'll Learn
Create a dictionary called raw_tables with exact keys and values
Create two variables called prefix and suffix with exact string values
Use a dictionary comprehension to create a new dictionary called cleaned_tables with new names
Print the cleaned_tables dictionary
💡 Why This Matters
🌍 Real World
In companies, consistent naming helps teams find and understand data tables quickly, especially when many tables exist.
💼 Career
Data engineers and analysts often apply naming conventions to keep data organized and maintainable at scale.
Progress0 / 4 steps
1
Create the raw tables dictionary
Create a dictionary called raw_tables with these exact entries: 'sales': 'sales_data', 'customers': 'customer_info', 'products': 'product_list'.
dbt
Hint

Use curly braces {} to create a dictionary with keys and values separated by colons.

2
Set prefix and suffix variables
Create a variable called prefix and set it to the string 'cleaned_'. Then create a variable called suffix and set it to the string '_v1'.
dbt
Hint

Use simple assignment with = to set string values.

3
Create cleaned table names with dictionary comprehension
Use a dictionary comprehension to create a new dictionary called cleaned_tables. For each key and value in raw_tables.items(), the new value should be the prefix plus the original value plus the suffix.
dbt
Hint

Use {key: value for key, value in dict.items()} format for dictionary comprehension.

4
Print the cleaned tables dictionary
Write a print statement to display the cleaned_tables dictionary.
dbt
Hint

Use print(cleaned_tables) to show the dictionary.

Practice

(1/5)
1. Why is it important to use consistent prefixes like stg_, int_, and fct_ in dbt projects?
easy
A. They make the SQL code run faster.
B. They help organize models by their role, making the project easier to understand.
C. They automatically create indexes in the database.
D. They allow dbt to skip testing models.

Solution

  1. Step 1: Understand the purpose of prefixes in dbt

    Prefixes like stg_ (staging), int_ (intermediate), and fct_ (fact) indicate the role of each model.
  2. Step 2: Recognize how prefixes help in large projects

    Using these prefixes organizes models logically, making it easier to find and maintain them.
  3. Final Answer:

    They help organize models by their role, making the project easier to understand. -> Option B
  4. Quick Check:

    Consistent prefixes = better organization [OK]
Hint: Remember: prefixes show model roles clearly [OK]
Common Mistakes:
  • Thinking prefixes affect performance
  • Assuming prefixes create database indexes
  • Believing prefixes skip tests
2. Which of the following is the correct way to name a staging model for customer data in dbt?
easy
A. stgCustomerData
B. StgCustomerData
C. STG_CUSTOMER_DATA
D. stg_customer_data

Solution

  1. Step 1: Recall dbt naming style guidelines

    dbt recommends lowercase letters and underscores to separate words for readability.
  2. Step 2: Evaluate each option

    stg_customer_data uses lowercase and underscores, matching the recommended style.
  3. Final Answer:

    stg_customer_data -> Option D
  4. Quick Check:

    Lowercase + underscores = correct naming [OK]
Hint: Use lowercase and underscores for dbt model names [OK]
Common Mistakes:
  • Using uppercase letters
  • Using camelCase instead of underscores
  • Starting with uppercase letters
3. Given the following dbt model names, which one is a fact table according to naming conventions?
stg_orders
int_customer_info
fct_sales_summary
stg_products
medium
A. stg_orders
B. int_customer_info
C. fct_sales_summary
D. stg_products

Solution

  1. Step 1: Identify prefixes and their meanings

    stg_ means staging, int_ means intermediate, fct_ means fact table.
  2. Step 2: Match the prefix to the fact table

    Only fct_sales_summary starts with fct_, indicating a fact table.
  3. Final Answer:

    fct_sales_summary -> Option C
  4. Quick Check:

    Prefix fct_ = fact table [OK]
Hint: Fact tables start with fct_ prefix [OK]
Common Mistakes:
  • Confusing staging and fact prefixes
  • Ignoring prefix meanings
  • Choosing intermediate models as fact tables
4. You see a dbt model named fct_customer_orders but it contains only raw data loading logic without aggregations. What is the likely issue?
medium
A. The model name prefix fct_ is incorrect for raw data; it should be stg_.
B. The model should be renamed to int_customer_orders because it is intermediate.
C. The model name is fine; raw data can be in fact tables.
D. The model should be deleted because it is redundant.

Solution

  1. Step 1: Understand prefix meanings

    fct_ is for fact tables, which usually contain aggregated or transactional data, not raw loads.
  2. Step 2: Match model content to prefix

    Since the model only loads raw data, stg_ (staging) prefix is more appropriate.
  3. Final Answer:

    The model name prefix fct_ is incorrect for raw data; it should be stg_. -> Option A
  4. Quick Check:

    Raw data = stg_ prefix [OK]
Hint: Match prefix to model content type [OK]
Common Mistakes:
  • Assuming any prefix works for any model
  • Thinking raw data belongs in fact tables
  • Renaming without checking model logic
5. In a large dbt project, you want to create a naming convention that helps new team members quickly identify model types and their dependencies. Which approach best supports this goal?
hard
A. Use consistent prefixes like stg_, int_, fct_, keep names lowercase with underscores, and document the naming rules.
B. Use random prefixes for variety, mix uppercase and lowercase, and avoid documentation to encourage exploration.
C. Name all models with the project name prefix only, ignoring model roles and dependencies.
D. Use only numbers as prefixes to indicate model order, without descriptive names.

Solution

  1. Step 1: Identify best practices for naming at scale

    Consistent prefixes and lowercase with underscores improve clarity and readability.
  2. Step 2: Recognize importance of documentation

    Documenting naming rules helps new team members understand conventions and dependencies quickly.
  3. Final Answer:

    Use consistent prefixes like stg_, int_, fct_, keep names lowercase with underscores, and document the naming rules. -> Option A
  4. Quick Check:

    Consistency + documentation = easier onboarding [OK]
Hint: Combine clear prefixes with documentation [OK]
Common Mistakes:
  • Ignoring documentation
  • Using inconsistent naming styles
  • Choosing unclear or numeric-only prefixes
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard