USING THE ENTERPRISE DATA MODEL TO MAXIMIZE
RETURN ON DATA WAREHOUSE INVESTMENT: PART I
by Kathy Long
A friend once commented to me, "I can't justify the investment of developing an enterprise data model to support a warehousing effort. Warehousing is focused on dealing with data at the physical level. I need to move data from a physical source to a physical target. A conceptual enterprise data model is not going to help me in that effort".
I can't argue that source to target data migration analysis and design deals with detailed column domain definitions that are not addressed at the conceptual level. However, I think the enterprise data model (EDM) plays a critical role in the planning, design and future success of the enterprise data warehouse. It is precisely because the information sourced to the warehouse is constrained by the type of implementation design issues we wrestle with in column mapping, that we need the EDM. The EDM is a key tool that will help us make sure that the warehouse delivers its promised return on investment. It is the component of data architecture that supports the mission of the data warehouse, to provide business intelligence and enable analysts to form tomorrow's profit making strategies. This article will examine the role of the enterprise data model in a warehousing initiative and provide the rationale for its development.
Enterprise Data Model Definition
In a general sense, a data model defines the objects that are of interest to the business and the rules that describe and govern those objects. John Zachman's Framework for Information Systems Architecture provides a taxonomy for relating the concepts that describe business objects and the concepts that describe an information system and its implementation. Each cell in the Framework represents a model. The rows of the Framework represent the functional purpose and use of the model. The columns represent the who (people), what (data), when (timing/events), where (network), how(process) and why(mission).
Zachman's Framework is introduced here for two reasons. First, to illustrate that the data model satisfies only one perspective of information systems architecture, the "what" column. Second, primarily to distinguish between different types of data models:
The owners model (Row 2) is the enterprise data model discussed here. This model defines the common terms and strategic business rules for corporate entities without technology constraints. In this model, Customer and Product are defined as conceptual enterprise-wide entities. The critical business rules that govern the management of each entity are defined with a common corporate viewpoint.
The EDM is an entity relationship model with primary entities, common supertypes, important subtypes, and important attributes defined. Many-to-many relationships are not resolved. The scope of the EDM should cross-functional and organizational boundaries. There is no such thing as a Sales and Marketing 'enterprise data model'. In this case, the model is a conceptual data model drawn from a functional perspective, not an EDM.
Benefits of the enterprise data model to a warehousing initiative
Some familiar data architecture challenges:
The above list of challenges looks familiar to anyone who has worked on defining the data architecture for a data warehouse. Ironically, this list is not from current warehousing literature, but from an old slide on data modeling challenges and its review shows that the enterprise data model seeks to conquer the same challenges that we face in data warehousing.
---
The concluding portion of this commentary will appear in the next edition of D S * .
---
For more information, see http://www.spectrumtech.com