What do you think?
Rate this book
Building the Data Warehouse
The data warehousing bible updated for the new millenniumUpdated and expanded to reflect the many technological advances occurring since the previous edition, this latest edition of the data warehousing "bible" provides a comprehensive introduction to building data marts, operational data stores, the Corporate Information Factory, exploration warehouses, and Web-enabled warehouses. Written by the father of the data warehouse concept, the book also reviews the unique requirements for supporting e-business and explores various ways in which the traditional data warehouse can be integrated with new technologies to provide enhanced customer service, sales, and support-both online and offline-including near-line data storage techniques.
272 pages, Hardcover
First published November 30, 1991
11 people are currently reading
201 people want to read
About the author
William H. Inmon
48 books5 followersWilliam H. Inmon is an American computer scientist, recognized by many as the father of the data warehouse. Inmon wrote the first book, held the first conference (with Arnie Barnett), wrote the first column in a magazine and was the first to offer classes in data warehousing. Inmon created the accepted definition of what a data warehouse is - a subject-oriented, non-volatile, integrated, time-variant collection of data in support of management's decisions. Compared with the approach of the other pioneering architect of data warehousing, Ralph Kimball, Inmon's approach is often characterized as a top-down approach.
source: Wikipedia
source: Wikipedia
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 10 of 10 reviews
June 26, 2019
3.5/5
I read this cover to cover, which was A Choice, and it was pretty good with a few caveats:
* Inmon loves himself some absolutely useless diagrams
* certain chapters had vastly different audiences
* some of the book felt much more outdated than other parts
Overall though, I think if you've got a relational data warehouse, this is the best book I've come across to help you wrangle it and figure out where to go and what to do. I read this over time, mostly in the morning or while waiting for large processes to run, taking notes so that I can review them later and then turn that into actionable items.
I read this cover to cover, which was A Choice, and it was pretty good with a few caveats:
* Inmon loves himself some absolutely useless diagrams
* certain chapters had vastly different audiences
* some of the book felt much more outdated than other parts
Overall though, I think if you've got a relational data warehouse, this is the best book I've come across to help you wrangle it and figure out where to go and what to do. I read this over time, mostly in the morning or while waiting for large processes to run, taking notes so that I can review them later and then turn that into actionable items.
May 28, 2015
The book covers the data warehousing field completely - giving a 360 degree view to a reader. However it is not very readable. The ideas are expressed in a difficult way and you can not figure out the author's higher level of flow of thought while going through one specific chapter.
There are too many diagrams. Nearly all are useless. They do not add any further clarity to the topic or the situation . If the topic will mention about a simple data flow from A to B then it will refer to a diagram which will have two rectangle boxes connected with an arrow and that is it. A mention of a slight modification in the same date flow will result in referring to a new diagram. This way of explanation frustrates the reader especially because mostly the diagrams are not placed on the same page where they are being referred to. You generally have to flip 2-3 pages to reach to the diagram page then you flip back to the topic page to discover that another reference is being made to another diagram 4-5 pages away. This frustrated me so much that I later skipped noticing the diagrams.
The book does explains a lot of things around data warehousing but it lacks the tactic to mesmerize a reader .It is definitely not for a newbie as it requires good knowledge of the field to be able to grasp the abstractness of the ideas.
If you can somehow remove the repetitive mentioning of differences between OLTP and DWH and the statement that DWH can not be build in one cycle, the book will literally shrink to half of its current size.
There are too many diagrams. Nearly all are useless. They do not add any further clarity to the topic or the situation . If the topic will mention about a simple data flow from A to B then it will refer to a diagram which will have two rectangle boxes connected with an arrow and that is it. A mention of a slight modification in the same date flow will result in referring to a new diagram. This way of explanation frustrates the reader especially because mostly the diagrams are not placed on the same page where they are being referred to. You generally have to flip 2-3 pages to reach to the diagram page then you flip back to the topic page to discover that another reference is being made to another diagram 4-5 pages away. This frustrated me so much that I later skipped noticing the diagrams.
The book does explains a lot of things around data warehousing but it lacks the tactic to mesmerize a reader .It is definitely not for a newbie as it requires good knowledge of the field to be able to grasp the abstractness of the ideas.
If you can somehow remove the repetitive mentioning of differences between OLTP and DWH and the statement that DWH can not be build in one cycle, the book will literally shrink to half of its current size.
December 2, 2025
Imagine a priest that never read the Bible. You would expect him to be filled with remorse, wouldn't you? I spent almost a decade in the data warehousing industry without having read the foundational book that started it for most people*: Bill Inmon's 'Building the Data Warehouse.' So finally I decided to end my pangs of conscience. Was it worth it?
The author begins with the history of decision support systems. That's in order to show that data warehousing was made possible by technical advances and that it was an answer to specific problems of the industry. He goes on to define what a data warehouse (DWH) is and how it fits into what he calls the 'corporate information factory'. While doing so, he constantly stresses the difference between the DWH and the operational systems. The book continues with the development cycle of the DWH and its relation to data modeling. Some fundamental subjects like normalization, grain, metadata, events or data marts appear and are explained. As the DWH is not only a concept, but also a real application, there is a whole chapter devoted to requirements that any technology supporting the DWH must meet.
After laying the groundwork for data warehousing, the book expands on various subjects related to it. He tells the story of how the DWH ate the, now defunct, Executive Information Systems. It also covers the relation to external data and recommendations on migrating to the DWH. The reader will also find a sketch of the relation between the DWH and the internet. This is followed by a chapter about how unstructured data fits into the DWH and another on the rapid growth of data. Close to the end we find chapters about justifying the investment in the DWH, compliance and the end-user community. The work closes with a design review checklist supposed to help anyone willing to start their own DWH project.
An important thread in the book is the reaction to the star schema model proposed by Ralph Kimball, the other founding father of the business intelligence (BI) industry. In 'Building the Data Warehouse' the star schema model and other Kimball's ideas appear many times, and although they are mainly criticized, they also get a fair share of positive appraisal. We can find a whole chapter comparing Kimball's approach versus the author's.
So is it a good book? Its first five chapters, where the author lays the basis of the data warehousing industry, are great. For example, it was eye-opening for me how the history of data storage naturally led to data warehousing. The definition of the data warehouse is another strong point: it stands till today and so are the definitions of grain, metadata and other fundamental concepts. While reading the first part of the book, I was surprised by how much of my work during the last decade had been described here. Especially in the parts devoted to the development of the DWH. The peculiar aspects of having to work with a broader picture of a company's data model while at the same time having to struggle with the realities of the data at hand are exactly the kind of stuff I have seen on many projects. Same goes to the iterative aspect of development and of the end-user's demands, which Inmon aptly defined as "give me what I say I want, and then I can tell you what I really want.' Inmon accurately stresses the huge effort needed for ETL and integration, calling it '80 percent of the the effort required'. So true. I also liked Inmon's treatement of Kimball's views. The book rarely distorts them and defends the author's point of view in a structured manner that can be roughly summarized as: 'The star schema is a modeling technique for data marts, not a data warehouse model.'
The book is far less successful when it tries to encompass a myriad of subjects related to data warehousing. It's worth mentioning that 'Building the Data Warehouse' has had four editions (1992, 1995, 2002 and 2005). Contents have grown significantly, especially between the 3rd (12 chapters, 412 pages) and 4th editions (19 chapters, 543 pages). The author clearly wanted to keep the book up to date with the latest trends. In doing so he ended up adding weaker chapters about less interesting topics, like compliance, cost justification and a shallow classification of end-users. Those chapters don't bring a lot of added value and even worse, they seem superfluous and they dilute the strong message of the first part of the book. This leads to another major weak point: the book is too long. It is also filled with a lot of useless and simplistic drawings, further increasing the length of the book. Time has also played its part, as some of the remarks are obsolete today, such as the inclusion of the pompous Zachman's framework. In what illustrates the passing of time best, the word 'Amazon' appears only once. As a river.
All in all: this venerable classic was worth the time. The first 200 pages are compulsory reading for anyone working with data warehouses, along with the Kimball-Inmon comparison. That part is a cornerstone of the whole data warehousing industry and this on its own makes it a good book. The rest is subpar, and can be optional, or simply ignored.
I once had a conversation with a manager from a major consulting company where he called the data warehouse a 'legacy system', meaning that on one hand, it definitely wasn't the hype of the moment and new talent tends to go elsewhere. On the other hand, the data warehouse has become an essential system. As Bill Inmon wrote in the book's fourth edition: 'data warehousing has achieved the status of conventional wisdom.'
*I am aware of Barry Devlin's article from 1988, but Inmon's book gained a much bigger audience.
The author begins with the history of decision support systems. That's in order to show that data warehousing was made possible by technical advances and that it was an answer to specific problems of the industry. He goes on to define what a data warehouse (DWH) is and how it fits into what he calls the 'corporate information factory'. While doing so, he constantly stresses the difference between the DWH and the operational systems. The book continues with the development cycle of the DWH and its relation to data modeling. Some fundamental subjects like normalization, grain, metadata, events or data marts appear and are explained. As the DWH is not only a concept, but also a real application, there is a whole chapter devoted to requirements that any technology supporting the DWH must meet.
After laying the groundwork for data warehousing, the book expands on various subjects related to it. He tells the story of how the DWH ate the, now defunct, Executive Information Systems. It also covers the relation to external data and recommendations on migrating to the DWH. The reader will also find a sketch of the relation between the DWH and the internet. This is followed by a chapter about how unstructured data fits into the DWH and another on the rapid growth of data. Close to the end we find chapters about justifying the investment in the DWH, compliance and the end-user community. The work closes with a design review checklist supposed to help anyone willing to start their own DWH project.
An important thread in the book is the reaction to the star schema model proposed by Ralph Kimball, the other founding father of the business intelligence (BI) industry. In 'Building the Data Warehouse' the star schema model and other Kimball's ideas appear many times, and although they are mainly criticized, they also get a fair share of positive appraisal. We can find a whole chapter comparing Kimball's approach versus the author's.
So is it a good book? Its first five chapters, where the author lays the basis of the data warehousing industry, are great. For example, it was eye-opening for me how the history of data storage naturally led to data warehousing. The definition of the data warehouse is another strong point: it stands till today and so are the definitions of grain, metadata and other fundamental concepts. While reading the first part of the book, I was surprised by how much of my work during the last decade had been described here. Especially in the parts devoted to the development of the DWH. The peculiar aspects of having to work with a broader picture of a company's data model while at the same time having to struggle with the realities of the data at hand are exactly the kind of stuff I have seen on many projects. Same goes to the iterative aspect of development and of the end-user's demands, which Inmon aptly defined as "give me what I say I want, and then I can tell you what I really want.' Inmon accurately stresses the huge effort needed for ETL and integration, calling it '80 percent of the the effort required'. So true. I also liked Inmon's treatement of Kimball's views. The book rarely distorts them and defends the author's point of view in a structured manner that can be roughly summarized as: 'The star schema is a modeling technique for data marts, not a data warehouse model.'
The book is far less successful when it tries to encompass a myriad of subjects related to data warehousing. It's worth mentioning that 'Building the Data Warehouse' has had four editions (1992, 1995, 2002 and 2005). Contents have grown significantly, especially between the 3rd (12 chapters, 412 pages) and 4th editions (19 chapters, 543 pages). The author clearly wanted to keep the book up to date with the latest trends. In doing so he ended up adding weaker chapters about less interesting topics, like compliance, cost justification and a shallow classification of end-users. Those chapters don't bring a lot of added value and even worse, they seem superfluous and they dilute the strong message of the first part of the book. This leads to another major weak point: the book is too long. It is also filled with a lot of useless and simplistic drawings, further increasing the length of the book. Time has also played its part, as some of the remarks are obsolete today, such as the inclusion of the pompous Zachman's framework. In what illustrates the passing of time best, the word 'Amazon' appears only once. As a river.
All in all: this venerable classic was worth the time. The first 200 pages are compulsory reading for anyone working with data warehouses, along with the Kimball-Inmon comparison. That part is a cornerstone of the whole data warehousing industry and this on its own makes it a good book. The rest is subpar, and can be optional, or simply ignored.
I once had a conversation with a manager from a major consulting company where he called the data warehouse a 'legacy system', meaning that on one hand, it definitely wasn't the hype of the moment and new talent tends to go elsewhere. On the other hand, the data warehouse has become an essential system. As Bill Inmon wrote in the book's fourth edition: 'data warehousing has achieved the status of conventional wisdom.'
*I am aware of Barry Devlin's article from 1988, but Inmon's book gained a much bigger audience.
September 15, 2020
A very thorough look at data warehousing from both the technologist as well the end user’s point of view. I found that the diagrams and pictures help to illustrate points and ideas. Unlike other authors in this space Inmon does not constantly try to sell other products or his consulting services (it is rather sad that I even have to mention this). Being a typical corporate application developer that continually finds himself working on “data” solutions to problems, I wish I had read this years ago.
April 14, 2025
A lot of the content from this 2 decade old book is still relevant. I found it easy to follow. The downside being redundancy in the concepts, the book could easily have been 50% shorter and still elaborate. If someone is looking for the hands-on experience, this book is not for them. In that case, they need to complement it with another practical book as this book shares a lot of good ideas, but doesn't go into the implementation.
December 19, 2018
Gives wide perspecitve insight to relational data warehouse.
June 21, 2013
It is unfair to blame Inmon for all the ills of the Big Bang approach especially since he clearly states on several occasions that iterations are the way to go. Seriously outdated and discredited approach? Well perhaps. Certainly, I'm not a convert. A useful read for latent background but nothing more.
May 3, 2018
Certainly a book to read, even if I am a fan of the Kimball approach. At least now I understand why in the past I have disagreed with very competent persons on the meaning of the simple term "Data warehouse"! I found interesting the chapter about how to manage unstructured data. The book contains also information about what is an ODS and when to use it.
September 13, 2012
This needs to be your starting point if you want to understand data warehousing; everything you need to know from the fundamental principles onwards is contained within its pages!
Read
May 11, 2010Creating Web Pages for Dummies
Displaying 1 - 10 of 10 reviews