Surrogate Sequence Keys in the source system really hold no meaning to the actual business user or real world. They CHANGE when: a) the data is moved from one source application to another, b) the source application is upgraded, c) the surrogate “rolls over” and is then reassigned in the future to new data d) data is exported then re-imported / restored at a later date. Sequence keys in the source system are meaningless generated numbers. Now, there are times when this is the only option, and we do teach how, when and why this happens in our CDVP2 classes – BUT this should be the exception and not the rule!! If the Data Vault model is built this way it means: a) the implementation team is lazy, b) the team leveraged a generation tool that doesn’t work properly, or c) they don’t truly understand what a Data Vault is.
Integration by Source Sequence Surrogate Key is Wrong! You can have the BEST data model in the world, but if you don’t back it with the right approach, and the right methodology, it will not serve your business purposes, it will NOT produce a success – rather, it will simply fail (under volume, under real-time, under complexity – take your pick). Do NOT, I repeat do NOT go to production with an SSDV. Now, that said: SSDV’s HOLD NO BUSINESS VALUE (I know I’m repeating myself). I’d be happy to put you in contact with these folks. If you want to speak with customers all over the world that have gone “SSDV route”, then corrected their actions to achieve success, please let me know. It means: your implementation team does not understand what they are doing, and should attend CDVP2 training before going further. SSDV’s cause all kinds of problems, from maintenance issues, to join performance issues, to sheer numbers of tables. Generators that produce SSDV’s are a dime a dozen, cheap – free, homegrown, easy to write, and very quickly can run your data vault efforts off the rails and down the drain!!
All it does is apply a ratio: 1 source table creates 2 to 3 Data Vault tables, and leverages source system primary and foreign keys to accomplish this.
It’s wrong because it holds no business value, does not integrate any data by the real business key. What is a Source System Data Vault (SSDV) and Why is that Wrong?Īn SSDV is quite simply: A restructuring of your source system in to Data Vault styled objects. Therefore, they cannot ever hope to achieve the successes that we announce with Data Vault that we do have. They are not exercising the best practices, the principles, or the rigor found in the Data Vault methodology (ie: information engineering). Many consultancies (turns out) are building something I call Source System Data Vault. Let us help you get your course corrected and your Data Vault on track for future success. For a bit of assessment now, it can save you a lot of pain later. If this is the case, or you’ve heard this on your Data Vault projects, then please contact us. If your team, or your consultancy or your experts don’t understand this, and they think that “reading the book is enough”, then we need to help you get that corrected as soon as possible. First off, Data Vault is far more than just a data model. If “Enterprise integration and Enterprise Data Warehousing” were easy, then we wouldn’t need Data Vault to help us along the way. When I dig deeper I often hear: “We read the book, and this should be easy!!” When I dig deeper, I discover that the implementation team a) hasn’t been to training or certification, b) that the consultancy whom claimed Data Vault 2.0 practices has no clue, no idea what they are doing or only has 1 expert in the entire company, and they are on a different project – not working at all for your implementation or you efforts. These are all bad things – and if you have a consultancy or people who say these things, then it’s time to bring in an authorized CDVP2 trainer for an assessment of what went wrong, and to take corrective action to turn your Data Vault in to a proper success story as it should be. I also hear things like: Data Vault has no value, or we don’t have any business keys, or we don’t know why we have to model by business key. Far too often I hear a tale about Data Vault not performing, or Data Vault is too complex, or the ever popular: Data Vault has too many tables.
0 kommentar(er)
