I recently received an email from a future Data Vault Consultant, he had some questions that he’d like answered – so I will do my best to answer these questions here and now. If you have your own sets of questions, please let me know what I can do to answer them. I feel that some questions are better blogged for free – and other questions may be best (due to time needed to correctly answer them) if left for subscriptions (yes, subscriptions for Data Vault support is coming soon).
**Please note** Please don’t mistake my enthusiasm for sarcasm here, I can be a bit blunt sometimes – I don’t mean any offense by this posting.
1. Question 1: old Articles
The TDAN.com articles – there are 5 total. They were written in 2001/2002 – many years ago. They also reference a company I worked for many years ago – which is now defunct (bought out really) and has been changed to another company. Apparently the articles on TDAN.com are still driving interest after all these years; it’s good to see. However, for those struggling to find Data Vault resources – LinkedIn.com “Data Vault Discussions” – and over 800 subscribers to the free discussion group (although the postings are a bit “slow” on the uptake). Still, a lot of good information there. Also, as you now have discovered – you can read about Data Vault here!
Yes, this blog is enabled with a mobile skin – so you can use iPod, iPhone, Androids, and others to read it. You can also subscribe via RSS.
2. Question 2: I really buy into the DV architecture approach, though it seems excessive to break every business/surrogate key out into a separate Link table. Otherwise simple tables are split into two: one for content and one for FK relationships. I can see this making sense for high-volatility data, but not for financial transactions (for example) that are generally static.
This individual has not yet been through the certification training. In the training class we explain a notion called a transactional link (for example: a financial transaction) that is static in nature. The “transactional link” acts just like a FACT table – because the data cannot / should not ever be updated (legally), it can reside directly within the link structure. The caveat? NO SATELLITES CAN HANG OFF THIS TYPE OF LINK STRUCTURE without breaking it apart again.
Also, keep in mind: that for MPP reasons, separation is one of the keys to scalability (read my previous blog entry on the subject).
3: Question 3: Question #2 is amplified when we have a relationship that is essentially immutable. For example a Policy has one-to-many Policy Terms. There is no way that a Policy Term will every apply to a different Policy; this is a matter of composition rather than assignment. Does it make sense in these cases to include Policy ID (SK) as part of the Policy Term Satellite rather than creating a new Link table?
NO NO NO! Relationships are NEVER immutable over time. Every time I hear that a “relationship is immutable” it makes my skin crawl – because what that translates to is: “the Business NEVER changes it’s mind about how data interacts with each other.” It also translates to: “The business never retires old systems” or “The business never brings in new data to integrate in to the warehouse.” By the way: NO relationship is EVER immutable, why? Because to make that claim would be to say: “My data is always perfectly in line with the relationship, we don’t have data quality problems.” I’ve yet to see a system where data quality is _not_ an issue. Anyone else like to chime in to this?
Now, POLICY ID in a Satellite? No, we don’t move business keys to Satellites – this is a huge break in the flexibility of the Data Vault. I’ve got some posts, and a few blog entries that describe what happens when the Architecture is “changed.”
4: Question 4: Are there cases where a Link table could have content? Consider the AdventureWorks example of the LNK_ORDERDETAIL which has ORDERID and PRODUCTID as the primary key. I would like to keep UNITPRICE, DISCOUNT, QUANTITY in that Link table rather than creating a Link Sat. What is the argument against this? And how would one relate LNK_ORDERDETAIL to LNK_SAT_ORDERDETAIL with creating an ORDERDETAILID surrogate key? Would you suggest joining on PRODUCTID/ORDERID?
Again, Transactional Links – but these are merely stop-gap solutions. In Very Large data warehouses with high degrees of parallelism (in a shared-nothing environment), dividing and conquering (separating descriptive data from the associative keys) is the ONLY way to make it scale. There are hundreds more arguments against this, and this is a discussion I’m currently writing into the Data Vault Modeling book. It will also appear in the membership support section of this site.
All link tables carry surrogate ID’s or as I like to call them: SQN (sequence numbers). Why Sequence numbers instead of ID’s? Because the term ID means too many different things to too many different people. we must standardize on terminology if we are to optimize the EDW building process and succeed.
5: Question 5: You mentioned that the DV is intended for insert-only essentially making all data Type II. This makes querying in any normal RDBMS completely impractical. Multiple SELECT MAX subqueries would kill the best of servers. A few thoughts on this:
a. Many DWs don’t need this level of historical detail; I’m considering updates in cases where historical data cannot be justified.
b. Another approach to this is having separate tables that hold “closed” dates for surrogate keys on the historical table. This allows us to continue with Insert-Only while still articulating end-dates on historical records. The current-state query is basicall SELECT * FROM historical WHERE surrogate_key NOT IN (SELECT surrogate_key FROM historical_closed). MPP databases such as Netezza perform magnificently with this approach.
c. Any other thoughts on this would be appreciated.
The Satellites are Type II (insert only), the Links and Hubs are insert only of NEW keys and NEW relationships – they don’t qualify as a Type II dimensional definition. Now, the article for Satellites is 7 years old and getting older every day. When I wrote the article I can’t remember if I discussed Satellites having start and end dates – but I do know that in the certification class, this is something we cover. Specifically to remove multiple SELECT MAX subqueries, believe me – it does the trick. In the certification course we also talk about WHY an update can be run against a System Managed field such as Start and End dates, and why this does NOT break auditability.
5a. Any time a user tells me “they don’t need this level of historical detail” I ask them: “When was your business audited last?” Will it be audited in the future? Does the business user realize that by “not needing this level of historical detail” that they run the risk of FAILING an audit? Which is by the way, really-really bad – and can kill Data Warehousing in that company for a very long time. Just ask some of the companies who only recently decided to try it one-last-time, and went the Data Vault route (they are very happy today as I understand it).
5b. Closed dates for surrogate keys – ok, only in the Satellites. And I call them “Load End Dates.” By the way, since you brought it up – we have our first successful test case of a Data Vault on Netezza today! And it screams!
5c. other thoughts, hmmm – anyone else care to chime in? Always love suggestions 🙂
I think actually – without too much, we made it through all the questions. I really hope this helps some of you folks out there struggling to find answers. Hang in there, a “technical Data Vault Modeling” book is coming as I’ve indicated in a previous post.