I am working on structuring a data system for a German bank that needs a data warehouse that will allow access by different departments in the bank. The architecture needs to support the potential for a merger or acquisition. I'm looking for information about the capability and efficiency of a data warehouse that will support the integration of data requirements from multiple departments and from more than one organization. Are there any resources that address this topic?
Larissa Moss' Answer: A data warehouse is a decision support environment with one or more databases that support multiple different tactical and/or strategic decision support applications. These databases can be designed for specific multidimensional report requirements or as entity relationship-based normalized, relational structures that reflect the operational nature of the business. Often a combination of both types of databases is the most flexible solution for a company that will have to accommodate future expansion needs, such as acquisitions. The ETL (extract/transform/load) process will do the transformations from the various sources to fit into the design of the DW databases. I would recommend to start each DW project with creating/expanding an integrated enterprise entity relationship model, which is a logical business data model based on the bank's business policies and business rules. Regardless whether or not you will implement this model as a database (you probably will if you build an ODS or EDW, and you probably won't if you only build multidimensional data marts), it will be your vehicle for future data integration from newly acquired sources. Don't create this logical business data model all at once or all up front. It can be built slowly over time as you are developing the types of DW databases and decision support applications that are most appropriate to support the known requirements of the bank at that time. When future acquisitions occur, use the logical business data model to integrate the acquired data with the bank's data according to the bank's business policies and business rules as captured in that logical business data model. Then use this logical business data model to guide you on where and how to expand or add to the physical databases and applications in the DW environment. Here are some references for general information about data warehouse architectures and development methods: Inmon, William H., Claudia Imhoff, and Ryan Sousa. Corporate Information Factory. New York: John Wiley & Sons, 1997. Moss, Larissa T. and Shaku Atre. Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications. Boston, MA: Addison-Wesley, 2003.
Clay Rehm's Answer: No matter how much you plan ahead, you will be faced with design decisions. Since you don't know the architecture of the organization that may acquire you or that you may acquire, the best thing you can do is to make sure your data model and data dictionary is "open" and flexible as possible. The one thing that you can count on is change and your environment and people must be ready for that.
Object oriented (OO) and software engineering topics cover this quite well. I would suggest reviewing the new SWEBOK (Guide to the Software Engineering Body of Knowledge) available at www.swebok.org.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access