Managing Information Technology

Chapter 4 • The Data Resource 97

Customer Submits Order Includes Product

FIGURE 4.1 Entity-Relationship Diagram

accessible to those with a need to know, and maintained
with high quality, the data and the programs that capture
and maintain them cannot be reused.
There are both technical and managerial issues
regarding the data resource. The next section examines the
technical aspects of managing the data resource that were
not already covered in Chapter 2. It provides an overview
of the most common tools used by database administrators
(DBAs) and systems analysts for describing and managing
data. As responsibilities for managing the data resource are
distributed to the business units, these topics also become
important to all managers.

Technical Aspects of Managing the Data Resource

The Data Model and Metadata

A key element in the effective management of data is an
overall map for business data—a data model. A manufac-
turing 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 enti-
ties. A data model shows rules by which the organization
operates, such as whether a customer order must be associ-
ated 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 fol-
lowed 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 fol-
lowing paragraphs, but the reader is referred to texts on
database management for a detailed discussion of data
modeling notations. Figure 4.1 shows a sample data model.
Specifically, it is an entity-relationship diagram (ERD)

that captures entities (i.e., customer, order, product) and

their relationships (i.e., submits, includes).

The entity-relationship diagram is the most com-

monly 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 in

Figure 4.1 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 meta-

data 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 typi-

cally 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 thou-

sands 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

are done).

Creating and maintaining high-quality metadata

takes dedication, yet we cannot insure quality data without

quality metadata. For example, unless everyone in the

organization knows exactly what is meant by the attribute

employee salary, different people might interpret values

for this attribute differently. One of the authors of this text

once worked in an organization that had 17 different defi-

nitions of the term customer, each relevant to different

parts of the organization (e.g., billing, retail sales, and

commercial sales). There were good business reasons to

have 17 different interpretations, but it was confusing

when people thought they were working off the same defi-

nition but were not. What this organization needed were 17

different, yet related, entities (e.g., retail customer,

business customer, bill-to-customer). Eventually the