Data Vault Database schema

Would like to seek guidance on how do you go about separating different layers of data vault in database schemas?

Schema names such as
STG.<> for staging tables
RV.<> for raw vault
BV.<> for business vault
IM.<> for info mart

  1. Is above a good strategy?
  2. Has anyone separated the data in raw vault based on the data domains, e.g. schemas such as customer, employee, asset etc ? If yes, how has been your experience of doing so?

Depends on the version of Data Vault

Thanks @patrickcuba

Is splitting database schemas based on data domains an acceptable practice?

Hey Nic

Why not?

I actually put RV and BV in the same schema; both are links and sats and hubs being RV only.

But of course this can be extended like in this image.


Maybe i wasn’t clear on my question.

by data domains, i am not referring to the data vault layers like Raw vault , business vault

my question is
Is it an acceptable practice to split the tables according to their data domains in the raw vault?

Customer domain, location domain, finance domain etc.
So , have schema and tables such as below in raw vault.

Instead of schema as RV.tablename

Have schema as below


Reason to do this is to be able to segregate the tables according the different data domains.

You could, but I wouldn’t split the DV in that way.

The above image shows business domains across a DV – extending an enterprise DV with private BVs. You could build data domain views over that contact but I think that should live in the IM layer

1 Like

I personally would hold all Data Vault objects in one database, and the reporting / mart layer in another. It’s less noise and end users shouldn’t be able to view any of the data vault objects anyways.

You could even have a DB/mart per department if you’d like. It really depends on your organization needs.

1 Like