A free to use dbt package for creating and loading Data Vault 2.0 compliant Data Warehouses (powered by dbt, an open source data engineering tool, registered trademark of dbt Labs)
At the moment you can alias a hashdiff in dbtvault satellite macros. This is so that you may have a standardised name for your hashdiff in every satellite, even if they share the same primed staging area.
This use case is not isolated to hashdiffs however, for example for a Link Primary key we may want to always call them LINK_HK fo simplicity of joins later on, or just so we have uniform links.
Being able to do this for any parameter in any macro would be ideal, and would make it much easier to standardise across our raw vault.
Something like the following would be very useful:
On the topic of standardised naming, we plan to make this configuration centralised. Some day wuldn't it be cool if you could do the following in dbt_project.yml:
vars:
hash: MD5
hashdiff_name: HASHDIFF
This would ensure the hashdiff of every satellite would be named HASHDIFF
At the moment you can alias a hashdiff in dbtvault satellite macros. This is so that you may have a standardised name for your hashdiff in every satellite, even if they share the same primed staging area.
This use case is not isolated to hashdiffs however, for example for a Link Primary key we may want to always call them
LINK_HK
fo simplicity of joins later on, or just so we have uniform links.Being able to do this for any parameter in any macro would be ideal, and would make it much easier to standardise across our raw vault.
Something like the following would be very useful:
Resulting in a table like:
The future
On the topic of standardised naming, we plan to make this configuration centralised. Some day wuldn't it be cool if you could do the following in
dbt_project.yml
:This would ensure the hashdiff of every satellite would be named
HASHDIFF
AB#5370