Notifications
Clear all

The many ways you could build your BV


Posts: 743
Topic starter
(@patrick-cuba)
Honorable Member
Joined: 2 years ago

Business Vault is an unfortunate name because when clients hear the name Business VAULT they assume this is a separate entity to the Raw Vault when in truth it is just an extension of the Raw Vault by reusing the same RV patterns (hubs, links and satellites) to store the output of business rules. 

Yes you can have derived hubs, a business key that is formed as the output of business rules, although extremely rare unless you consider concatenating composite keys into a conformed column for an existing hub table.

Links as BV = absolutely. A scenario we encountered was solving a problem that a certain credit card database did not have a concept of: an account. To solve it we picked the first issued card as the account number for the collection of related cards. The number of related cards is unlimited, every time a card is stolen or lost a new card is issued. Or if the customer chooses to take advantage of a different credit card product then a new card is issued. 

Satellites as BV. This is what we usually think of when discussing BV. It is source system agnostic and utilized to trace the history of the applied rules ++ that means that the business rule itself should be carefully managed and contain version numbers themselves. After all business rules change as the business matures or new regulatory requirements means that either a new rule is issued or the old one is matured. Keeping track of both the outcome of the business rule, the version applied and the mechanics of what the business rule looked like forms a part of the audit. One of the keys of DV.

BV is based on RV as this means the data lineage of is maintained through a well defined audit trail. This also means that BV requires an additional hop to be delivered. 

1. Load RV from source

2. Load BV from RV

What if BV is loaded directly from source?

If you could guarantee that the staged data is never deleted but instead archived in something like AWS Glacier then you have maintained the audit trail. This in turn resembles a Persistent Staging Area (PSA) and there has been quite a bit of documentation produced showing a preference of building a PSA and virtualizing the data vault. It does make the DV extremely flexible but at what cost?

Can virtualizing technology right now support trillion record PSA with Data Vault views?

The major consideration in my view (no pun intended) is performance.

 

What are your VIEWs on BV from source? PSA and virtualizing DV? And if all of RV&BV are persisted physically what about the views created on top of those?

Reply
3 Replies