Week 9: Refactoring and auditing practice + DAG best practices
We had some refactoring fun this week!
Part of the “Mastering dbt” series. Access to the full Study Guide. Let’s connect on LinkedIn!
We are back after skipping a week for a quick country move!
This week, we approached one of my favourite topics of the guide: refactoring SQL.
In the practice post below, you will have access to a very confusing traditional script full of unnecessary functions, nested selects, and even some incorrect logic. This should help you practice refactoring the code and auditing the output.
The audit is more fiddly than it looks. I found that more than checking the results, you need to ensure your new model(s) fit the existing DAG without breaking the best practices that we will review below.
Study notes added:
Our B2B company now needs to import a script that generates invoices for the Finance department. The analyst who built it used some unnecessary functions, and some of the logic was incorrect. Let’s refactor it!
A full list of the study notes is available in the study guide.
Keep Your DAG Untangled:
A well-structured DAG (Directed Acyclic Graph) keeps your data models clean, efficient, and easy to maintain. Here are key principles to follow:
Respect model layers: Only base or staging models should connect directly to raw sources.
Follow one source → one staging model: If multiple sources must be joined, handle it in a dedicated base model.
Avoid cross-layer joins: Staging models shouldn’t join with intermediates; add another intermediate layer instead.
No “bending connections”: Models in the same layer shouldn’t depend on each other—restructure or add a new layer if needed.
Define a clear endpoint: Limit the number of
dimandfactlayers. Push extra transformations upstream or to your BI tool.
Have the study notes been useful to you so far? How are you getting on with your self-paced learning journey? I would love to hear from you here or on LinkedIn!