Introduction - Database Processing: Fundamentals, Design, and Implementation - page 19

Figure 1-21
Databases Originating
from New Systems
Development

Forms
Forms
Forms
Forms

Reports

Data
Model

Data Model
Transformation

Database
Design

User
Requirement
Statements

Use Cases and
Other Systems
Development
Documents

Systems Requirements

reports, user requirements statements, use cases, and other requirements, are analyzed to cre-
ate the database design.
In all but the simplest system development projects, the step from user requirements to
database design is too big. Accordingly, the development team proceeds in two steps. First,
the team creates a data model from the requirements statements and then transforms that
data model into a database design. You can think of a data model as a blueprint that is used as
a design aid on the way to a database design , which is the basis for constructing the actual
database in a DBMS product.
Note that we have have just given a second meaning to the term database design —previously
we used it to mean the process of designing a database , and now we are using it to mean the anno-
tated diagram that is the result of that process . The term is used both ways , so be careful that you
understand how it is being used in a particular context!
In Chapter 5, you will learn about the most popular data modeling technique—
entity-relationship (ER) data modeling . You also will see how to use the entity-relationship
model to represent a variety of common form and report patterns. Then, in Chapter 6, you will
learn how to transform entity-relationship data models into database designs.

Database Redesign
Database redesign also requires that databases are designed. As shown in Figure 1-22, there
are two common types of database redesign.
In the first, a database is adapted to new or changing requirements. This process some-
times is called database migration . In the migration process, tables may be created, modified,
or removed; relationships may be altered; data constraints may be changed; and so forth.
The second type of database redesign involves the integration of two or more databases.
This type of redesign is common when adapting or removing legacy systems. It is also com-
mon for enterprise application integration, when two or more previously separate information
systems are adapted to work with each other.
Database redesign is complicated. There is no getting around that fact. If this is your first
exposure to database design, your instructor may skip this topic. If this is the case, after you
have gained more experience, you should reread this material. In spite of its difficulty, database
redesign is important.
To understand database redesign, you need to know SQL statements for defining data-
base structures and more advanced SQL statements for querying and updating a database.
Consequently, we will not address database redesign until Chapter 8, after we present SQL state-
ments and techniques for creating and altering the tables that make up a database in Chapter 7.