Managing Information Technology

348 Part III • Acquiring Information Systems

Logical Data

Modeling Terms

Physical Data Terms

Data Store

Entity

Entity Instance

Data Element

Database or File

File or Table

Record or Row

Field or Column

Example

Accounts Payable Database

Purchase Order (D1)

All information on purchase order

number C07321

PO Number

FIGURE 8.16 Key Terms for Logical Data Modeling

In summary, creating a Logical To-Be model requires
the abstraction of existing business processes from the As-Is
model into representations that separate data flows from
processes and entities, accurately identify business rules,
and capture the relationships among data. Though a
demanding effort, the creation of a complete To-Be model
for complex systems is our best assurance that the new
system will improve upon the existing one.
The next step is to develop a physical model based
on the Logical To-Be model—including all the decisions
necessary to determine how the logical requirements can
be met. In preparation for the following Physical To-Be
model discussion, Figure 8.16 identifies relational
database terminology (as used in a physical model) that
corresponds to the various logical data modeling terms
from DFDs and ERD. For each pair of terms, a correspon-
ding example from the accounts payable system is also
provided.

TO-BE PATTERNS Recall that in Chapter 4 we introduced
the notion of universal, or packaged, data models. Such
database patterns provide reusable starting points for new
To-Be logical data modeling. Few new information
systems are so unique that we need to start with a clean
sheet of paper. It is likely that some similar system has
been developed before, so we can learn from past
experience by starting from a pattern that is considered
best practice for the type of system we are developing. For
a systems development team unfamiliar with the type of
system they are developing, patterns can greatly assist in
communication of potential requirements. We can then
customize the pattern with local terminology and unique
requirements. Patterns can also be used to evaluate the
capabilities of purchased software.
For many years, IT organizations have maintained
libraries of documentation and computer code so that these
artifacts can be reused and adapted for new needs. Today,
such analysis and design libraries can be purchased from
consulting firms and software companies so best and

proven practices can be shared across organizations.

Patterns might exist of a data model for a manufacturing

company or data flow diagrams for credit card application

processing. Purchased patterns for the physical To-Be

system descriptions are also available.

These patterns are abstractions that address all

aspects of a domain; that is, they are comprehensive and

cover the most general of circumstances. Several patterns

may need to be combined to cover the design of a new

information system. These patterns then need to be adapted

to use terminology for data and processes in the specific

organization. Special business rules may need to be added

to accommodate industry regulations or organizational cus-

toms. Kodaganallur and Shim (2006) provide a taxonomy

of To-Be patterns.

Techniques for Documenting the Physical

To-Be System

The end deliverables from the Logical To-Be modeling

process are called the system requirements. Requirements

are embodied in the kinds of diagrams illustrated in the

prior section along with metadata contained in the DD/D.

Other textual documents, which may or may not be

contained in the DD/D, contain business rules and other

narrative explanations of agreed-upon expectations. Any

proposed system design must address the need for each

requirement, provide a substitute, or justify its exclusion. Of

course, the objective is to meet as many of the requirements

as possible without jeopardizing project scheduling and

budget constraints. For this reason, often requirements are

categorized into mandatory (has to be handled exactly as

specified), required (may be handled in an alternative way),

and desired (can be delayed to a later maintenance phase or

could be rejected as infeasible). Any physical design that

does not satisfy mandatory and required features should not

be proposed. Alternative physical designs may be proposed

(e.g., an internally developed solution versus a purchased

package) and a comparison of the pros and cons of each