5 exercises on dbt fundamentals — materializations, ref(), source(), tests, and ephemeral models.
0 / 5 completed
1 / 5
What does it mean for a dbt model to be materialised as incremental?
Incremental materialisation: on first run dbt creates the table. Subsequent runs apply a filter (e.g. where event_time > max(event_time)) to process only new data. This dramatically reduces compute cost for large, append-only tables.
2 / 5
What does the ref() function do in a dbt model?
ref():select * from {{ ref('stg_orders') }} tells dbt that this model depends on stg_orders. dbt builds a DAG from all ref() calls, determines build order, and resolves the correct fully-qualified table name for any target environment.
3 / 5
What is the purpose of source() in dbt?
source():{{ source('stripe', 'payments') }} references a raw table. Defining sources in schema.yml enables dbt's source freshness checks (dbt source freshness), documentation, and lineage visibility from raw tables through to marts.
4 / 5
What is an ephemeral materialisation in dbt?
Ephemeral: ephemeral models are like reusable CTEs. They do not create database objects — dbt inlines them wherever they are referenced. They reduce intermediate table clutter but cannot be queried directly or incrementally materialised.
5 / 5
What do dbt tests in schema.yml validate?
dbt tests: generic tests like not_null and unique are one-liners in YAML. Singular tests are custom SQL files that return rows when the assertion fails. Running dbt test catches data quality issues before downstream consumers are affected.