This is an entry I posted on Kimball University in 2009, about Data Vault and Dimensional Modeling. I challenged the posters to respond to my questions about their claims, but no-one took the challenge. On the other hand, it’s an interesting discussion, and begs to be reposted here. Everything from System of record, to use of the Data Warehouse is addressed, so here goes…
I appreciate the thoughts – and yes, you are right to mention that there is not enough published on the subject. Please remember that Dr. Kimball has published more information than I have to date, and he also has had many more years of marketing, speaking, and sharing than I have. I published the first article/paper on Data Vault in 2001 on www.TDAN.com – it’s a technique that’s only been known to the EDW / BI world for 9/10 years now. However, it is a strange phenomenon that people are not discussing the Data Vault Model as freely as the Kimball Star Schema.
Anyhow, In case you were wondering: I agree with Nick G in some areas – any good enterprise data warehouse should be accountable and auditable, able to pass audits – regardless of the data modeling technique used. Yes, the Data Vault Modeling techniques are a hub and spoke design – a mix of normalized modeling components with type 2 dimensional properties in the Satellites. It is in fact a hybrid data model – spanning some of the flexibility of 3NF and combining it with some of the techniques of dimensional modelling. But that’s where the similarities stop. Too often people confuse the data model implementation aspects with the “approach” of building a Data Warehouse or the Framework so it were. The framework that the Data Vault Modeling components rely on include a staging area, an enterprise data warehouse (physical not logical), followed by Star Schemas, cubes, and other data release mechanisms to properly push the data to the end-users or business. This framework is different than that of a “logical EDW” made up of loosely affiliated Star Schemas combined with a staging area.
Another difference is where the business rules occur. Nick G hit it on the head, again – the Data Warehouse should be accountable and auditable – which by default means pushing business rules of changing/altering data downstream to “between the data warehouse and the data marts”. This is definately a principle I agree with.
I can’t speak for why people are not writing about it, but let me weigh in for a minute: DOD, US Navy, US Army, Edmonton Police, SNS Bank, World Bank, ABN-AMRO, UBS, Central Bank of Indonesia, Monash University, Central Bureau of Statistics (Netherlands), Denver University, City & County of Denver, USDA, Diamler Motors, Air France, Nutreco, Microsoft, JP Morgan Chase, Lockheed Martin, and the list goes on – these companies are using/building or have used the Data Vault successfully over the past several years. There must be something new / different that the data model and standards bring to the table, or it wouldn’t be accepted / used by so many companies.
Ok that said: let’s talk about the definition of system of record: Here is where I disagree with Nick G. I would argue that the definition of what a data warehouse IS, and it’s purpose has changed over the years. In particular, when it comes to being the ONLY place that real-time information is stored historically, or integrated with the other data. In this case, it becomes the ONLY place where an auditor can actually perform an audit of how and what the data was that was collected along the way, hence it becomes a system of record.
It’s changing again – with a concept called “Operational Data Warehousing” where the principles of a data warehouse are being pushed and re-defined by the business. The business actually builds an operational application right on top of the Data Warehouse, and edits the data set directly, creates new records directly – writing the history back to the warehouse in real time. In this case, also – it becomes a system of record. We have three different companies that have built systems like this and are functioning today. One is ING Real Estate HQ, One is a congressional effort for medical records management of the armed forces, one is Cendant Timeshare Resource Group. Like it or not, the introduction of “real-time data” flowing in to and being captured by the Data Warehouse makes it (by default) a system of record. More often than not the source data (after delivery to the EDW) is destroyed on the machine that performed capture… especially if it’s a capture machine outside the EDW.
Anyhow, the point being that data warehouses also frequently house data from “old/retired” often dismantled legacy systems. Even if the auditor wanted to, they couldn’t audit the source system because it’s been scrapped or junk-heaped somewhere. So in this case, the auditor treats the EDW as a system of record, like it or not. I’ve actually been in this situation several times, and passed audits because of the manner in which I treat the data warehouse.
Now, all of that is separate from the data modeling constructs used to build your EDW. I’ve simply chosen to use the Data Vault for flexibility and scalability of the systems design. Let’s talk about that for a minute…
Would you agree that the most scalable architecture (between NUMA, MPP, SMP, etc…) is MPP? Massively Parallel Processing… Or would you tend to say that some other architecture is more suitable to economies of scale? It seems to me that MPP is the clear winner over all these others. Actually a Hybrid is used these days to support cloud based systems. Massive SMP (symmetrical multi-processing) (ie: clustered machines) combined with MPP shared nothing architecture, to create a scale-out scale free cloud. Anyhow, if the mathematics behind MPP have proven to be true (for example divide and conquer) then why not utilize this type of architecture within database engines? Why not take MPP mathematics and apply them to the basics of data modeling by dividing and conquering or parallelizing the database operations?
A fist shot at this is called partitioning of the tables, but it has to go deeper – to where the joins live. There are age-old arguments about more joins/less joins and which is better, but at the end of the day it has to do with a balanced approach – how many joins can your hardware /RDBMS software execute in parallel effectively? How much data can your machine access in parallel and independent processes? Can you effectively make use of both types of partitioning (vertical and horizontal)? Can you apply compression across the board and enhance performance? Vertical partitioning is what the column based appliances / databases have been doing for massive performance increases in the query side.
The Data Vault Model makes use of some of the basic ideas buried within the MPP realm – divide and conquer, apply compression to columns where redundancy lives, and apply unique high speed 100% coverage to indexes where possible. Hence the hub & spoke design. The larger the system (or the larger the number of tables), the more I can split the tables/system up across multiple independent machines. It’s a pure fit for virtualized computing/cloud computing resources. It’s also a scale free architecture, because I don’t need to store ALL my data in a single geographical place to get at it quickly. Any how, the hub and link structures enable the model to join in 100% parallel across MPP hardware / RDBMS that is configured properly, and at economies of scale – the MPP query will always win over a serialized join (once the machine and database are tuned appropriately).
Anyhow, there’s a lot more to this than meets the eye, it may look like a simple data model – but it’s the reasons why we do what we do that make it powerful. It’s the purpose behind the architecture that is currently driving companies like the Netherlands Tax Authority and the DOD to select the Data Vault for use in some of it’s largest (data set wise) projects.
Now folks might ask: well, isn’t it overkill for small datawarehouses? Maybe, maybe not – depends on the COST of modifying a “stage/star schema” architecture down the road, vs weighing the cost of modifications to a Data Vault. Hence a company like Phillips Electronics also undertaking a Data Vault effort to consolidate or centralize raw data feeds from all across their divisions.
What I would say is this: If you’re happy building Star Schemas as your data warehouse, great – if it’s working for you, wonderful – don’t change. But if you run into situations that require heavy re-engineering, cause your project to “stop & restart” or be completely rebuilt every 2 to 3 years, then you might want to look at the Data Vault as an alternative. Again, if you have little to no pain in the current architecture you are using, then don’t change – don’t fix what’s not broken….
I hope this helps, as always – take what you like, use the good things that are there. Take the time to investigate new ideas, throw away the rest. After all, this is just more information. And remember: the world NEEDS Star Schemas, Cubes, and alternative release mechanisms – we couldn’t feed the business needs without them! I’m merely proposing the Data Vault Model as an Enterprise Data Warehouse layer, NOT as a data delivery layer… Leave that to the expert: Dr. Ralph Kimball.
Please feel free to contact me directly if you wish.
I appreciate your thoughts on these ideas, and hope that you will comment on these posts with your experiences. I really want you to succeed, and I’d love to help you succeed, but I can’t do that if I don’t hear from you! So if you’re stuck, or feeling your implementation of the Data Vault hasn’t gone as well as you’d hoped or expected, then please – contact me today, let’s see if we can’t get it back on track and working for you instead of against you.
Hope this helps,