In the data vault approach to modelling a data warehouse, things are done a little differently. It starts with the business, not with the data.
Now, that doesn’t mean it starts with the business problem, which is already defined (it would be pointless to create a data warehouse with any model if there wasn’t a problem to be solved). Instead, it starts with sitting down and talking with the business users about their processes and systems without even looking at the data.
That may seem an odd thing for data specialists to do (more regularly, the developers will go straight to the data and get to work with it). But it goes to the heart of the ‘data vault difference’.
In the data vault model, the developers will engage with the business first, to understand it’s operations and processes, which then gives context to the data. This gives the developer a clearer idea of what is important to the company: where and how it creates value, in other words.
The insights taken from understanding the operations and processes are known as the ‘business keys’ (for example, using customer numbers rather than the source system ID as the unique identifier or key) – and the success of the data vault model rests in getting the business keys right. It also underpins the ability of the data vault model to deliver on its core promise of being able to cater for (inevitable) change.
Think of the business keys as a foundation. A regular foundation for a single level building is constructed to hold just that one level; this is analogous to a standard data warehouse implementation. With data vault, the foundation is designed in such a way that more floors can later be added to the building – so long as the design (the business keys) stay true to what the company does, the data warehouse is able to flexibly expand and change to meet different requirements.
Just like a foundation, the business keys are structural. They are the basis of the data model and will only change if and when the business changes. This means the business keys are the most stable elements on which to build the structure of a historical database.
Using the business processes to create the backbone for the data warehouse means the model can easily absorb data from a new source, regardless of structure, or deal with changes to existing sources. Unlike traditional data warehouses which need more effort as it can mean having to rewrite significant portions of the model or downstream processing. This enables the data vault to deal effectively with change, because the model relates to the business and it’s processes, not the underlying structure of the data sources.
It may sound a little odd – weird even – but this is why data vault modelling differs. It isn’t for every business, but it provides an alternative approach that deals more easily with change for organisations where data sources change regularly, such as a company who has a lot of subsidiaries who wants to create a single company view, the data vault model is an excellent alternative.
Perhaps though, starting with the business isn’t just pertinent for data vaults.