DAG best practice = arrow. What about the exception?

[yvesgroenen]

Hi,

I’m busy with a migration of an existing piece of technical debt.
While browsing through the best practices documentation of dbt labs I see the following passage:
Intermediate: Purpose-built transformation steps | dbt Developer Hub (getdbt.com)
" One rule of thumb to ensure you’re following this pattern on an individual model level is allowing multiple inputs to a model, but not multiple outputs ."

Basically that is my plan:

So I have single entities only in my staging layer.
My intermediate layer will contain re-usable transformed/joined entities.
A split up will happen on the business mart/process level.

But as you can see instead of having a pure arrow like recommended, I could have a mirrored arrow or horizontal hour glass implying multiple outputs.
Why? Because the end user is a technical user and would also query some of the intermediate tables directly for diagnostics purposes = getting the details of logs/events/… which sits in the OBT. But this OBT could then serve multiple marts as an input since it’s a consolidated source.

FYI: I know star schema modeling, even some of the staging entities come from our star schema lakehouse

What do you think? Thanks

[drudel_el]

I think this caveat refers to intermediate models with multiple outputs to other intermediate models, not to Marts models.

The start of the paragraph says Until we get to the marts layer and start building our various outputs…

I think the expectation is that multiple marts might need to make use of the same component intermediate model.

[yvesgroenen]

Aha that makes sense
Ok thanks