Building the Data Warehouse

Скачать в pdf «Building the Data Warehouse»

Note that the spider web seems to have reappeared in a larger, more grandiose form. Such is not the case at all, although the explanation is rather complex. Refer to “The Cabinet Effect,” in the May 1991 edition of Data Base Programming Design, for an in-depth explanation of why the architected environment is not merely a recreation of the spider web environment.

The day 1-day n phenomenon described here is the ideal way to get to the data warehouse. There are many other paths. One such path is through the building of data marts first. This path is short sighted and leads to a great deal of waste.


The single most important aspect of design of a data warehouse is the issue of granularity. Indeed, the issue of granularity permeates the entire architecture that surrounds the data warehouse environment. Granularity refers to the level of detail or summarization of the units of data in the data warehouse. The more detail there is, the lower the level of granularity. The less detail there is, the higher the level of granularity.

For example, a simple transaction would be at a low level of granularity. A summary of all transactions for the month would be at a high level of granularity.

Granularity of data has always been a major design issue. In early operational systems, granularity was taken for granted. When detailed data is being updated, it is almost a given that data be stored at the lowest level of granularity. In the data warehouse environment, though, granularity is not assumed. Figure 2.11 illustrates the issues of granularity.

Скачать в pdf «Building the Data Warehouse»