Eight basic guidelines for establishing a data warehouse

Data Warehouse applications have the ability to capture large amounts of shared information from multiple decentralized departmental systems. They can effectively transform the original data of the organization into useful knowledge information, so the knowledge information can be used for strategic decision support to improve the enterprise benefit. With the help of an advanced Data Warehouse application, enterprise decision-makers can track the performance of the enterprise from the fundamentals of quality, regional revenue and output, and take swift and sensible action based on these reliable information.

This article describes the eight rules for building a data warehouse, especially how to build the first Data warehouse. In fact, for how to build a successful data warehouse, the reality does not exist and there is no way to exist in a myriad, universal "scroll." Almost certainly, it is inevitable that the user will make a mistake when building the first Data warehouse. The purpose of this article is simply to help the user avoid some known flaws. And for those inevitable mistakes, these rules will help users mitigate possible hazards as much as possible.

Rule one: Start small

Do not come up with a massive enterprise-wide data warehouse, which can cause users to fall into the mire of logic, administration, and finance.

A data warehouse is not as large as it is effective, and the value of a smaller system can be significant to the organization. For example, a user can position the implementation of the first Data warehouse in a specific department and application or line of business. Starting with a data mart with a scale down can reduce development costs, shorten the implementation cycle, and help train IT staff for future data Warehouse development.

Rule number two: Consider the big place

Even when building the first Data mart for a particular department or application, it is important to ensure that the data model currently in use can be extended to future enterprise-wide data storage for future implementations of other data marts and strategic data warehouses.

A consistent data definition must be made between departments, and everyone should comply. For example, how to form a "sales system"? Is it an appointment, a invoicing or a payment? The consistency agreement on these definitions will make the joint of departmental data feasible and effective.

Rule three: Define goals and quantify benefits

Before the project is implemented, users must answer a few questions explicitly. Why do we have to build a data warehouse? Is the purpose of the project consistent with the mission of our organization? What are the issues that we are committed to solving? Should we consider factors such as market, quality and customer satisfaction in time?

After you have identified the objectives, you should identify the key factors that affect success so that you can track them in the implementation process of your solution. For example, income and transport units (units shipped) may be two factors that have an effect on the loss of market share.

After these key success factors are established, users can set up "automatic water mark or alert" in the application. These alerts guarantee that the most important data that has a direct impact on the bottom is clearly visible and facilitates timely action. Once you have defined the impact factors of success, you can detect the factors that threaten success when you use the Data Warehouse.