A Data Warehouse (DW), among other things, can be an important step in establishing a holistic Business Intelligence program. But, even by itself, there are some very good reasons to implement a DW, as cited below.
Due to unacceptable transaction processing times in server/disk bound tasks, many firms find that processing their reports and queries from a data warehouse, which can use separate disks and servers for these purposes, enables them to reduce expense and complexity, and increase overall efficiency.
Another way to speed up querying and reporting is to use data models (e.g., a star schema) that would not be appropriate for transaction processing because the modeling technique will slow down and complicate transaction processing. There are also server technologies that that may speed up query and reporting processing, but may slow down transaction processing (e.g., bit-mapped indexing), and server technologies that may speed up transaction processing, but slow down query and report processing (e.g., technology for transaction recovery). Of course, the benefits of these processes will vary from shop to shop, but for many firms, using these techniques from a data warehouse is the answer.
Another advantage of the using the DW is that simpler queries and reports can be written by less technically knowledgeable personnel in this environment. And, even when those less knowledgeable personnel need IS help, IS is often also more quickly able to write and maintain queries and reports written against DW data, due to the lack of bureaucracy usually associated with establishing reports and queries in the DW.
Many firms that need reports with data from multiple transaction processing systems (and/or external sources) have had to write data extracts, run sort/merge logic to combine the extracted data. and then, run reports against the sort/merged data. However, if a company has large amounts of data that need to be sort/merged frequently, if data purged from transaction processing systems needs to be reported upon, and/or if the data need to be “cleaned”, then a DW is often the most efficient way to do it.
Often, to improve response time, the oldest data may be purged from transaction processing systems so the expected can be better controlled. To retain the data for future querying and reporting, this purged data, along with the current data may be stored in the DW, where there the tolerance for higher response time would be much greater. There may also be cases where there is a need to generate a report based on a characteristic of some historical data. Through a DW, a shop would have the older data available to handle this.
Where, for security reasons, a firm may want to prevent certain persons from accessing the transaction processing system database and the (associated maintenance logic), a DW would allow those persons to perform their queries and reporting from the Internet.
It is probably obvious that many of the reasons cited above relate to the limitations of transaction processing systems. Some shops may need to address all of these issues; others, only some. Regardless, solving even one of these problems can justify the establishment of a DW.
It should also be noted that a firm should not expect to automatically get business intelligence, improved decision making, greater familiarity with its customers, and a significant competitive advantage all by the single step of implementation of a DW alone. But, in concert with other elements of a solid BI implementation plan, it can begin the process toward that goal.
(The primary source for the above was the “Data Warehousing Information Center”.)
Good common sense article, though as closing paragraph suggests, not the whole picture. It would be good to see how to assess whether the costs of building EDW outweigh benefits or vica versa.