The data model is a critical tool for managing the data as an enterprise asset. It is to data as a chart of accounts is to the financial assets. The model, when represented as an entity relationship (ER) diagram, represents business rules pertaining to the data using a format that facilitates the creation of the physical tables for storing the data. Model creation is a collaborative effort. The business data stewards provide the input (e.g., data elements, relationships, definitions) and the data modeler represents these in the business data model.

Subject Area Model

The highest-level model is a subject area model. This model identifies the 10 to 20 major groupings of data for the company. Typical subject areas include customers, products, locations and human resources. The subject area model is useful for assigning data stewardship responsibilities and for organizing the business data model. The data stewardship responsibilities are often aligned with subject areas, and with this model, the steward(s) responsible for a specific entity can be quickly identified. This further minimizes the potential for the same data being addressed by multiple data stewards. Grouping entities within a subject area provides a more readable model because relationships within subject areas are more common than relationships between subject areas. The presentation can be further aided by color coding the entities based on the subject area.

Business Data Model

The business data model is a third normal form ER model that portrays the data of interest to the enterprise. There is only one business data model within an enterprise, and this model is completely independent of technological, functional and organizational constraints. A business data model that is used as the foundation for all data stores and applications within an enterprise contributes to data quality management in several ways.

Definitions. A step in the development of the business data model is the creation of a business-oriented definition for each entity and attribute. When the business data model drives development activities, this definition is cascaded into the applications and provides a common terminology for all the business users. This avoids different interpretations of data by different people.

Business rules. The relationships in the model reflect the business rules. These are provided by business representatives and should be applicable across applications. With the model as the foundation, enforcement of the business rules is facilitated. Differences can exist due to the specific role of each system. For example, the business data model contains the data and relationships generalized for all customers. In an application dealing exclusively with consumers, a subset of the rules is appropriate. This subset creates documented and easily explainable differences.

Consistency. Data often needs to be stored in multiple places. When the definition is consistent among the data stores, the content of the data is consistent as well or the differences are explainable. An example of explainable differences is the lifecycle position of the data. For example, with human resource data, the employment date does not apply (and would be null) until the person is hired.

Data validation and cleansing. The edit rules created in application systems are based on the business rules. When the business rules are derived from a common model, consistency of the validation criteria and error-handling routines among application systems can be maintained. With common validation rules, consistency of the quality of the data among the data stores is possible.

Ultimately, in the data warehouse (DW) world, we are faced with integrating data from multiple sources. This is one of the most time-consuming tasks in DW development, and its complexity is largely due to the different rules that apply to data within the various corporate application systems. With a common business data model, this situation would not exist. The data would be fairly consistent among systems, with any differences being explainable through documented deviations from the base model. The integration task would then become significantly easier, and the DW development effort would be substantially reduced.

While the data model is extremely important, if one does not exist in your company, I do not recommend developing it in its entirety before using it. The model can be developed incrementally to support DW (or other) project needs, with each project extending the model. Even though the model is developed to support individual projects, the model must maintain an enterprise perspective; hence, the definitions and relationships must address the entire organization and not just the needs of the single project.

System Model

The system model is the logical representation of the database schema. With a data modeling tool, its consistency with the business data model can be maintained, and it can be used to electronically create the database schema.

The data model is a critical part of the infrastructure needed to manage data as an enterprise asset. The business data model describes the business and is a cornerstone for the development of the DW and application systems. When the business data model serves as the foundation, quality is enhanced, development time is reduced and access is improved. 

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

Don't have an account? Register for Free Unlimited Access