A key element in the effective management of data is an overall map for business data-a data model. A manufacturing company would never think about building a new product without developing a detailed design and using common components and parts from existing products where appropriate. The same is true for data. Data entities, such as customer, order, product, vendor, market, and employee, are analogous to the components of a detailed design for a product. Just as the detailed blueprint for a product shows the relationships among components, the data model shows the relationships among the data entities.
A data model shows rules by which the organization operates, such as whether a customer order must be associated with a salesperson, an employee must have a social security number, or the maximum number of direct reports for a supervisor.
Data modeling involves both a methodology and a notation. The methodology includes the steps that are followed to identify and describe organizational data entities, and the notation is a way to show these findings, usually graphically. Managers must be integrally involved in these methodologies to insure that the data you need are planned for inclusion in organizational databases and that the data captured and stored have the required business meaning. Several possible methodologies are introduced in the following paragraphs, but the reader is referred to texts on database management for a detailed discussion of data modeling notations.
The entity-relationship model is the most commonly accepted notation for representing the data needs in an organization. It consists of entities, or the things about which data are collected; attributes, the actual elements of data that are to be collected; and relationships, the relevant associations between organizational entities. The model could have the attributes of customer last name, customer first name, customer street, customer city, and so on to represent the data that would be captured about each customer. Because of its nontechnical nature, the ERD is a very useful tool for facilitating communication between end users who need the data and database designers and developers who will create and maintain the database. However, an ERD is not sufficient for documenting data needs.
An ERD is only part of metadata, or data about data, needed to unambiguously describe data for the enterprise. Metadata documents the meaning and all the business rules that govern data. For example, some metadata about an attribute of customer name would define this term, state its properties such as maximum length and the type of data (alphanumeric characters) that a value of this attribute might have, whether every customer has to have a name to be stored in the database, whether the name can change in value over time, whether there can be multiple instances of the name, and who has rights to enter and change the name. These metadata rules come from the nature of the organization, so business managers are typically the source of the knowledge to develop these rules. You can purchase business rules and metadata repository software systems to help you manage the typically thousands of elements of metadata in an organization. Business rule software usually covers more rules than just those that address data (e.g., rules that govern when certain business processes must be used or which govern how processes