Best Practices for Liquibase Folder Structure with Data Vault Modeling

Data Vault 2.0
1

I’m working on a Data Vault project and using Liquibase for version control. As Data Vault requires a significant number of tables, views, and other database objects, I’m trying to establish a clean and scalable folder structure for my Liquibase change sets.

Currently, I’m considering a structure like this:

changes/
    tables/
    views/
    sprocs/
    functions/

Within each folder, I would have individual change sets for each database object. However, given the sheer number of tables in a Data Vault model, this approach could quickly lead to an overwhelming number of scripts in each folder.

Does anyone have experience with Liquibase and Data Vault modeling who can share insights or best practices on organizing the folder structure? Specifically:

Should each database object have its own change set file, or is it better to combine similar objects (like multiple tables) into a single change set? How can I keep the folder structure manageable, especially for larger models? Are there alternative structures or naming conventions that have worked well for others in similar scenarios?

Any tips on organizing Liquibase for large, complex data models like Data Vault would be greatly appreciated!

2

You’re looking to declutter?

If so then under tables you could decide to split by source-system, we do that anyway as in having raw vault satellite tables be source based and therefore you could break that up even further depending on the segregation you want even within the source.
For business vault i’d align those sats to business case or subject area.
Hubs and link would be shared though.

1 Like
3

Thanks for your help. I’m thinking of doing it in layers, 3 folders (staging, raw data vault, business data vault) and within each of these folders dividing by hubs, satellites, links. What do you think?

4

staging is just staging — why would you split that?
rv = hub, link and sat — rv sats are sourced by source-system
bv = link and sats
im (information marts) or qa (query assistance) = pits & bridges