Data Model for Inmon Data Warehouse In his book, Building The Data Warehouse, Bill Inmon wrote about the data model for a data warehouse. True, the data model is relational in the format of Entity Relationship Diagram (ERD), then middle level (called Data Item Set) and low-level modelling (physical data model). But immediately after that he wrote about normalisation and denormalisation. "Another important physical design technique that is especially relevant to the data warehouse environment is the deliberate introduction of redundant data", said Inmon. He gave an example of "Description" field which is deliberately placed in many tables redundantly. "In doing so, the access of data is more efficent, and the update of data is not optimal." But "in a data warehouse is no concern whatsoever about update." He then explained about "Snapshots" in a data warehouse at great length. And in the following chapter he spent a lot of time talking about "star join", fact and dimension tables. With clear examples on order fact table, product and customer dimensions, etc. So it is clear to me that Inmon data model is relational (ERD, i.e. Entity Relationship) but he clearly advocates that in a data warehouse we need to do denormalisation, and creating fact and dimension tables. So next time people asked you about the data model for Inmon data warehouse, do not forget the star schema part. The fact and dimension part. Don't forget that Bill Inmon wrote that book in 1996. Can you imagine what data warehousing was like 28 years ago?
Can you imagine how the people like myself who were building data warehouses 28 years ago are still shocked that todays set of people still haven’t learned the basic fundamentals of data warehousing. Bill Inmon and Ralph Kimball were not rivals or enemies, they both understood that there is different set of criteria for each area of a data warehouse and therefor a different modeling methodology for each. Bill Inmon never said not to use a dimensional model, he advocated for it on the reporting layer where it made the most sense. The data vault methodology uses both Inmon and Kimball in its design patterns and methodology. The medallion architecture has the same philosophy.
Relational model versus Dimensional model versus Data vault model versus other dwh models. The is no single true data model for a data warehouse. I guess that's why we like to have data areas, layers or zones because each area can have it's own data warehouse model to shape and suit business users needs. Understand business processes I think is still important but sometimes not high priority.
What both Inmon and Kimball contributed to is the notion of separating technology issues from business analytics issues. The main benefit of the star join model is not a technical one; it lies in enabling dimensional analysis of business processes. As I interpret it, in Inmon’s earlier works, he discusses technical solutions for structured data through physical design techniques, while in his later works, he addresses physical design solutions for semi-structured and unstructured data - such as in Turning text into gold which discusses text based data using NLPs and text mining techniques - as well. His emphasis is on the need for governance, metadata, and a structured approach to make these data sources analytics-ready.
A datamart is optimised for read... its a mart model applicable to rdbms Use the model appropriate to the engine fir the purpose yoj need.
Data Integration
2w"Building The Data Warehouse" is from 1992, not 1996. And I think you're confusing and conflating Bill Inmon with Ralph Kimball.