Chapter Three The Database Life Cycle

Chapter Three: The Database Life Cycle

42


42

Chapter Three

The Database Life Cycle

3.1 The Traditional Life Cycle

The traditional method for developing computer systems follows a

process called the system development life cycle (SDLC), which divides

the work into the phases shown in Figure 3-1. There are perhaps as

many variations of the SDLC as there are authors, project management

software vendors, and companies that have elected to create their own

methodologies. However, they all have the basic components, and in that

sense, are all cut from the same cloth. A good textbook on systems

analysis can provide greater detail should you need it. Figure 3-1 shows

the traditional SDLC steps in the left column, the basic project activities

in the middle column, and the database steps that support the project

activities in the right column.


42

Figure 3-1 Traditional system development life cycle (SDLC)


42

1- Planning

During the planning phase, the organization must reach a high-level

understanding of where they currently are, where they want to be, and a

reasonable approach or plan for getting from one place to the other.

Planning often occurs over a longer time period than any one individual

project, and the overall information systems plan for the organization

forms the basis from which projects should be launched to achieve the

overall objectives.

Once a particular project is proposed, a feasibility study is usually

launched to determine whether the project can be reasonably expected

to achieve (or help achieve) the objective and whether preliminary

estimates of time, staff, and materials required for the project fit within

the required timeframe and available budget. The composition of the

project team will change over the life of the project, with people added

and released as particular skill and staffing levels are needed. The one

consistent member of the project team will be the project manager (or

project leader), who is responsible for the overall management and

execution of the project.

Many organizations assign a database specialist (database

administrator or data modeler) to projects at their inception, as shown

in Figure 3-1. In a data-driven approach, where the emphasis is on

studying the data in order to discover the processing that must take

place to transform the data as required by the project, early assignment

of someone skilled at analyzing the data is essential. In a process-driven

approach, where the emphasis is on studying the processes required to


42

discover what the data should be, a database specialist is less essential

during the earliest phases of the project.

The database activities in this phase involve reviewing DBMS options

and determining whether the technologies currently in use meet the

overall needs of the project. Most organizations settle on one, or perhaps

two, standard DBMS products that they use for all projects. At this point,

the goals of the project should be compared with the current technology

to ensure that the project can reasonably be expected to be successful

using that technology. If a newer version of the DBMS is required, or if a

completely different DBMS is required, the planning phase is the time to

find out, so the acquisition and installation of the DBMS can be started.

2- Requirements Gathering

During the requirements-gathering phase, the project team must

gather and document a high-level, yet precise, description of what the

project is to accomplish. The focus must be on what rather than how; the

how is developed during the subsequent design phases. It is important

for the requirements to include as much as can be known about the

existing and expected business processes, business rules, and entities.

The more work that is done in the early stages of a project, the more

smoothly the subsequent stages will proceed.

From a database design perspective, the items of most interest

during requirements gathering are user views. Recall that a user view is

the method employed for presenting a set of data to the database user in

a manner tailored to the needs of that person or application. At this

phase of development, user views take the form of existing or proposed

reports, forms, screens, web pages, and the like.


42

Many techniques can be used in gathering requirements. The more

commonly used techniques are compared and contrasted here: conduct

interviews, conduct survey, observation, and document review. No

particular technique is clearly superior to another, and it is best to find a

blend of techniques that works well for the particular organization

rather than rely on one over the others.

3- Conceptual Design

The conceptual design phase involves designing the externals of the

application(s) and database(s). In fact, many methodologies use the

term external design for this project phase. The layout of reports,

screens, forms, web pages, and other data entry and presentation

vehicles are finalized during this phase. In addition, the flow of the

external application is documented in the form of a flow chart,

storyboard, or screen flow diagram. This helps the project team

understand the logical flow of the system.

During this phase, the database specialist (DBA or data modeler)

assigned to the project updates the enterprise conceptual data model,

which is usually maintained in the form of an entity-relationship

diagram (ERD). New or changed entities discovered are added to the

ERD, and any additional or changed business rules are also noted. The

user views, entities, and business rules are essential for the successful

logical database design that follows in the next phase.

Sadco

Highlight

Sadco

Highlight

Sadco

Highlight

Sadco

Highlight

Sadco

Highlight

Sadco

Highlight

Sadco

Highlight


03

4- Logical Design

During logical design, the bulk of the technical design of the

application(s) and database(s) included in the project is carried out.

Many methodologies call this phase internal design, because it

involves the design of the internals of the project that the business users

will never see.

From the database perspective, the major effort in this phase is

normalization, a technique developed by E.F. (Ted) Codd for designing

relational database tables that are best for transaction-based systems

(that is, those that insert, update, and delete data in the relational

database tables).

5- Physical Design

During the physical design phase, the logical design is mapped or

converted to the actual hardware and systems software that will be used

to implement the application(s) and database(s). From the process side,

little or nothing needs to be done if the application specifications were

written in a manner that can be directly implemented. However, much

work is required to specify the hardware on which the application(s)

and database(s) will be installed, including capacity estimates for the

processors, disk devices, and network bandwidth on which the system

will run.

On the database side, the normalized relations that were designed in

the prior logical design phase are implemented in the relational

DBMS(s) to be used. In particular, Data Definition Language (DDL) is

Sadco

Highlight


03

coded or generated to define the database objects, including the SQL

clauses that define the physical storage of the tables and indexes.

6- Construction

During the construction phase, the application developers code and

test the individual programming units. Tested program units are

promoted to a system test environment, where the entire application

and database system is assembled and tested from end to end. Figure 3-

2 shows the environments that are typically used as an application

system is developed, tested, and implemented. Each environment is a

complete hardware and software environment that includes all the

components necessary to run the application system.

Figure 3-2: Development hardware/software environments

7- Implementation and Rollout

Implementation is the process of installing the new application

system’s components (application programs, forms or web pages,

reports, database objects, and so on) into the live system and carrying

out any required data conversions. Rollout is the process of placing

groups of business users on the new application.


04

8- Ongoing Support

Once a new application system and database have been implemented

in a production environment, support of the application is often turned

over to a production support team. This team must be prepared to

isolate and respond to any issues that may arise, which could include

performance issues, abnormal or unexpected results, complete failures,

or the inevitable requests for enhancements.

With enhancements, it is best to categorize and prioritize them and

then fold them into future projects. However, genuine errors found in

the existing application or database (called bugs in IT slang) must be

fixed more immediately. Each bug fix becomes a mini-project, where all

the SDLC phases must be revisited. At the very least, documentation

must be updated as changes are made.

3.2 Nontraditional Life Cycles

In response to the belief that SDLC projects take too much time and

consume too many resources, some nontraditional methods have come

into routine use in some organizations. The two most prevalent of these

are prototyping and Rapid Application Development (RAD).

Prototyping

Prototyping involves rapid development of the application using

iterative sets of design, development, and implementation steps as a

method of determining user requirements. Extensive business user

involvement is required throughout the development process. In its

extreme form, the prototyping process starts with a meeting conducted

during the business day to review the latest iteration of the application,


00

followed by the development team working through the evening and

often late into the night. The next iteration is then reviewed during the

following workday.

Rapid Application Development

Rapid Application Development (RAD) is a software development

process that allows functioning application systems to be built in as little

as 60 to 90 days. Compromises are often made using the 80/20 rule,

which assumes that 80 percent of the required work can be completed

in 20 percent of the time. Complicated exception handling.

RAD is not useful in controlling project schedules or budgets, and in

fact it requires a project manager who is highly skilled at managing

schedules and controlling costs. It is most useful in situations for which

a rapid schedule is more important than product quality (measured in

terms of conforming to all known requirements).

3.3 The Project Triangle

The motivation behind the growth of nontraditional development

processes is pressure from business management to develop better

business applications more quickly and at less expense. Said simply,

they want fast delivery of high quality and inexpensive application

software systems. However, despite the claims of some of the vendors

selling development tools and methodologies, all three objectives simply

cannot be maximized.


02

Figure 3-3: The project triangle

Figure 3-3 shows a graphical representation of the dilemma using

the project triangle. The three points of the triangle represent the three

objectives: quality, delivery time, and cost (often known as good, fast,

and cheap).

The lines between the points remind us that the objectives are

interrelated. In fact, most experts agree only two of the objectives can be

optimized, and when they are, the third objective always suffers. The

commonly understood rule is that you must pick two and optimize your

project accordingly. It has also been generally proven that the rule

applies to human endeavors and not to matters of pure technology. For

example, you can create a new video format that renders higher quality

images faster and less expensively. However, if you launched a project to

design such a new format, the project tasks could not be optimized for

all three objectives.

Chapter Three The Database Life Cycle

Documents