Table of Contents
1. The Data Warehouse.
Business Intelligence. The Data Warehouse. Decision Support Systems. Summary. Glossary.
2. Object-Oriented Design. The Development Process. Metadata. The Objective of Objects. Summary. Glossary.
3. Analysis and Design. The Definition Phase. The Analysis Phase. The Design Phase. Summary. Glossary.
4. The Implementation Model. Dimensionality. Dimensionality and Information Systems. Star Schema. Summary. Glossary.
5. Dimension Tables-the Nouns of the Data Warehouse. Dimension-Table Characteristics. Slowly Changing Dimensions. Constellations and Conforming Dimensions. Snowflakes. Dimension of Time. The Dimensions of BBBC. Summary. Glossary.
6. Fact Tables—The Verbs of the Data Warehouse. Fact Tables. Factless Fact Tables. Degenerate Dimensions. Degenerate Facts. Heterogeneous Fact Tables. BBBC Fact Tables. Summary. Glossary.
7. Implementation Considerations. Parallel Processing. Bitmapped Indexing. Star Query Optimization. Summation Tables. Web-Enabled Data Warehousing. The BBBC Data Warehouse. Summary. Glossary.
Appendix A: The Spacially Enabled Data Warehouse. Analyzing Patient Needs.
Appendix B: Extraction, Transformation, and Loading. The ETL Strategy.
Appendix C: Metadata Standards. The Open Information Model. Common Warehouse Metadata.
Appendix D: Conventional Wisdom, Tips, Hints, and General Advice. Glossary. Index.
Preface
Foreword
In the beginning were applications. Users thought that applications would provide them with information. And insofar as the stated requirements of the applications were concerned, the applications sufficed. But over time the business requirements changed. Keeping the applications in sync with the changing business requirements was a difficult thing to do.
Along the way in trying to keep up with changing requirements, the end users encountered some other limitations to the world of applications. Those limitations were the need for
- ointegration, and
- ohistorical data.
The applications that the corporation had created or otherwise acquired had no notion of integration. One application thought a customer was one thing. Another application thought a customer was something else. And a third application had yet another interpretation of what a customer was. When it came to the corporate understanding of data, there was-simply stated-no corporate understanding. From a corporate perspective the manager could not answer such basic questions as
- owho is a customer?
- owhat is a product?
- owhat is a transaction?
In short, the different applications were never designed to work together in an integrated manner.
The second issue was that applications focused inevitably on very current data. Applications could reveal
- ohow much money a customer had in the bank right now,
- owhere a shipment was right now,
- owhat the status of an insurance policy was right now,
- owhat the quota of a salesperson was right now, and so on.
The applications were designed to keep track of what is going on right now. But when it came to a sense of the need and importance of historical information, the applications treated historical data with no respect at all.
Unfortunately, integration and history represent a very important component of information. And applications simply did not measure up.
The end user's first reaction was to rewrite the applications of yesterday. But this idea quickly fell by the wayside. The end user found that-as far as applications were concerned-the clock could not be turned back. There were simply too many applications, too much undocumented code, too much fragile code, too much complexity to even attempt to roll back the tide of applications.
Thus was born the notion of a data warehouse, an alternative to the dilemma of the end user who needed information but could not impose change on the legacy applications environment.
Like all radical and fresh concepts, the notion of a data warehouse was derided and scorned by the academics and theoreticians. Since the idea of data warehousing had not risen among their ranks, it could not possibly be a valid concept. Today data warehousing is no longer a theory. It is conventional wisdom, and corporations around the world recognize that the road forward leads through the data warehouse.
Data warehousing forms the center of a wide universe. From the corporate data warehouse, with its granular, corporate integrated data, spring many different kinds of decision support activity. The data warehouse forms the basis for such DSS processing as
- odata mart, departmental processing,
- osimple reporting of corporate information,
- oexploration processing,
- odata mining,
- ooperational data stores,
- oproject warehousing, and so forth.
But data warehousing did not happen all at once. Like a giant jigsaw puzzle, data warehousing has been put together a piece at a time. The world of data warehousing has been led by writers and by practitioners who became writers. These leaders have described from their experience what works and what does not.
Into this realm falls Bill Giovinazzo's book. Its really interesting aspect is that it is
- opractical,
- owritten in language comprehensible to a wide audience, and
- ocomprehensive.
Based on the reality of data warehousing, Bill Giovinazzo's book is a modern rendition of what you need to know about data warehousing in order to be successful. It strikes a fine balance between theory and practicality. Theories are explained in the cloth of practicality. Rules of thumb and practical realities always have a touch of theory to explain the underlying philosophy.
If you care about success in warehousing, this is the book that belongs on your bookshelf.
W. H. Inmon