Building the Data Warehouse

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

■    It produces flexibility.

■    It fits well with very granular data.

■    It is not optimized for any given set of processing requirements.

■■ It fits very nicely with the data model.

Of course, some small accommodations can be made away from the normalized model when the entire organization views the data in the same way. For example, suppose that monthly data is kept and when the organization looks at the monthly data, it looks at all monthly data. In this case, storing all months together makes sense.

A different approach to database design sometimes mentioned in the context of data warehousing is the multidimensional approach. This approach entails star joins, fact tables, and dimensions. The multidimensional approach applies exclusively to data marts, not data warehouses. Unlike data warehouses, data marts are very much shaped by requirements. To build a data mart, you have to

know a lot about the processing requirements that surround the data mart. Once those requirements are known, the data mart can be shaped into an optimal star join structure. But data warehouses are essentially different because they serve a very large community, and as such, they are not optimized for the convenience or performance of any one set of requirements. Data warehouses are shaped around the corporate requirements for information, not the departmental requirements for information. Therefore, creating a star join for the data warehouse is a mistake because the end result will be a data warehouse optimized for one community at the expense of all other communities.

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