[ACCEPTED]-Differences between Data Vault and Dimensional modeling?-data-vault

Dimensional modelling is in my opinion still 17 the best practise for analysis & reporting 16 and as a visible model best understand by 15 business users.

Data Vault is more suitable 14 for large Enterprise Data Warehousing, also 13 recommended by Bill Inmon, but not that 12 suitable for analysis & reporting, for 11 that you still might need dimensional modelling 10 for creating you "virtual" Data marts. Take 9 a peak at some blogs like those from Martijn 8 Evers, Hennie de Nooijer or Ronald Damhof.

Data 7 Vault is more flexible, easier to add new 6 sources, more audit able and keeps all data 5 all the time so you will be able to always 4 recreate you DM's.

So a conclusion might 3 be that the ideal situation is to use Data 2 Vault for your Enterprise Data Warehouse 1 and Dimensional Modelling for you Datamarts.

I think a combination of the two would best 11 serve most large organizations. Vault would 10 be a good choice for an intermediate enterprise 9 ODS where less structure would facilitate 8 flexibility and performance. Data can then 7 be pulled from the Vault Db to feed context 6 specific dimensional data marts that support 5 reporting and analysis. In that scenario 4 the vault Db can also be used to support 3 more big-data types of mining and analysis 2 that require a more mature understanding 1 of data relationships.

@Danny Shaw this is also my experience (though 68 I am relatively new in this field - coming 67 from ETL, so curious to input from others 66 on my post).

I believe that it is important, to 65 respect that your Clients' demands are evolving 64 with their 'maturity', and that different 63 models may fit better at different times.

My 62 feeling is that Data Vault delivers operational 61 flexibility, whereas existing discussion 60 (Kimball/Inmon) revolves more around 'business 59 flexibility' (for lack of better terminology).

Data 58 Vault allows you to stay close to the source 57 in terms of its granular objects. This makes 56 the model 'auditable' and scalable. It helps 55 with flexibility on SOURCE specifications.

Therefore 54 it is a useful in-between in e.g. migration 53 projects, serving as a base from where to 52 feed more business-oriented DWH/Datamarts 51 that require an integrated view of both 50 old and new. My experience however is that 49 if you start populating Datamarts directly 48 from this model you end up with lots of 47 joins and especially also recursions simply 46 because you are far from the business concepts. Not 45 entirely bad on certain databases so the 44 choice is partly influenced by the software 43 (e.g. Teradata likes joining much more so 42 than Oracle). However generally my feeling 41 is that if you need flexibility in TARGET 40 (business) side, you end up in the inmon-kimball 39 discussion and it would not be a bad start 38 to consider dimensional modeling instead 37 of data vault on that side.

So part of the 36 input in your evaluation should also be: how 35 standardised are business concepts? Is the 34 whole company using the same KPIs and Data 33 concepts? If this is not the case, staying 32 close to the source (especially if there 31 are many) somewhere in your data warehouse 30 seems like a safe bet to me. If more mature, prepare 29 for more flexibility in reporting demands 28 - and shift the performance of your datamodel 27 to the reporting side.

This is not to say 26 that business cannot be evolving - just 25 that it has to be evolving as a whole. I 24 consider this a more 'mature' customer, that 23 knows what it can do with their data, has 22 a very integrated and standardised view 21 on their business, with more and more complex 20 requirements in terms of reporting. So if 19 you need to model for flexibility in feeding 18 datamarts, AND you have a strong ETL toolset, you 17 might as well directly set up your datamodel 16 to resemble business a bit more.

To summarise, I 15 would argue that as the BI environment becomes 14 more 'mature', business has learnt what 13 it can do with the data and the demands 12 on that side become more complex. Data Vault 11 would not be the way to go on that side.

However 10 if you are in a migration (especially with 9 years-long parallel phases), or in a younger 8 organisation where not all departments look 7 at their business through the same eyes, but 6 (in your advantage) the reports requirements 5 are rather overseeable, it would be an option 4 to use data vault up front and try to see 3 if you can feed your datamarts directly 2 from that - possibly adding a taste of Kimball's 1 dimensions somewhere in between.

Favouring any approach is usually a matter 14 of balancing experience and opinion with 13 the needs and requirements for the system. Each 12 modelling approach has certain advantages 11 when related to different situations, so 10 you must evaluate the environment your model 9 will interact with when figuring out which 8 approach to take.

Highly transactional systems 7 that add data frequently and uniformly usually 6 suit a dimensional modelling approach. Common 5 examples used to describe it normally focus 4 on Retail and Financial organisations, as 3 the number of sales or monetary transactions 2 being added over time suits the Fact and 1 Dimension concepts.

Why do you feel you need either of them? They 12 are mostly jargon-heavy design patterns 11 used to sell books and training courses. Millions 10 of people find they can get on just fine 9 without them. What you really need to design 8 a data warehouse is the same good analysis 7 and modelling skills you need for any database.

If 6 you are seeking useful advice on building 5 a data warehouse then check out Bill Inmon's 4 books. If this is your first Business Intelligence 3 project then get some help from someone 2 with experience in the field so that you 1 can avoid some of the common pitfalls.