Topic 3:

Database Development
Lifecycle

TS6024 : Information Modelling and

Databases

1
Database Lifecycle
 Definition
 The process of designing, developing,

implementing, and maintaining a

database system.

2
Database Lifecycle – contd.
 Divided into separate stages:
 Requirements specification

 Design

 Prototyping

 Implementation

 Testing

 Operational Maintenance

3
 Requirements
Specification

Database Design
Conceptual Design
DBMS
Application
Selection
Logical Design Design

Physical Design

Prototyping Implementation

Testing

Operational
Maintenance 4
Requirements Specification
 The main activity of this stage is fact-
finding
 Facts are found through the following sample
activities:
 Organizational situation analysis
 Organizational problem specification
 Identify the objective, scope, and the boundaries
of system to be developed
 Specify user and system requirements
 Perform a system definition.

5
System Definition
 An activity for defining the scope of the
database system, its users, and its
applications (views), in the form of
‘requirements’

 Requirements are outlined in a more ordered

form with the aid of various tools/techniques:
 SAD (Structured Analysis and Design)

 DFD (Data Flow Diagrams)

6
System Definition Activities
1. Identifying the main applications of the
user group that will be using the
database
 The primary representative from each
user group will be directly involved in the
subsequent steps.

2. Research and analyse documentation

regarding the existing applications
7
System Definition Activities –
contd.
3. Research the current operational environment and
intended information usage plans
 Analyse each transaction type, and the
transaction’s frequency, within the current system
boundary
 Analyse information flow within the system
 Specify the input and output (I/O) data from each
transaction

4. Interview users (including ‘ground-level’ and ‘front-

line’ users to gather information and identify further
requirements
8
Database Design
 The process of creating a design that
will support the enterprise’s mission
statement and mission objectives for
the required database system

 Is the most important stage of the

database development lifecycle

9
Design Objectives
 The main objectives of database design are to:
 Represent the data and the relationships between
data that are needed by each application and user
group

 Produce a data model that supports all data

transactions

 Specify the design that will achieve the desired

system performance

10
Approaches to Database
Design
 There are two main approaches to
design:

 The top-down approach

 The bottom-up approach

11
Top-Down Approach
 Start by building a data model that
contains a few high-level entities and
relationship between entities
 Refine each item in the data model to
identify lower-level entities,
relationships, and the necessary
attributes
 Illustrated using the concepts of the
Entity-Relationship (E-R) model
 Suitable for complex databases
12
Bottom-Up Approach
 Starts with fundamental-level attributes and
through the analysis of the relationships
between each attribute
 Method: Initially produce a few large tables to
contain sample data, and later reduce to
many smaller tables of entities with the same
dependencies
 Normalization is an example of this
approach
 Suitable for smaller and less complex
databases
13
Design Phases
 The 3 main design phases are:

1. Conceptual design
2. Logical design
3. Physical design

14
Conceptual design
 The process of constructing a model of
the data used in the organization
 The result of this activity is a conceptual
model that is independent of all physical
considerations (system hardware, data
model, or DBMS package)
 E-R modelling is the most popular
technique used in this phase

15
Logical Design
 The process of constructing a model of
the data used in an organization, based
on a specific data model, but still
independent of particular DBMS and
other physical considerations.

16
Logical Design – contd.
 Involves the mapping between the
conceptual model and the logical model

 Normalization is also used at this stage

to ensure that the data model is not
subject to redundancy problems later.

17
Conceptual design and Logical
design differences
 In the logical model, the data model of the
DBMS must be known
 In the conceptual model, entities relate directly
(e.g. a CUSTOMER orders PRODUCTS), but in
the logical model the representation of the
relationship data must be specific (e.g. a
CUSTOMER can make many ORDERS, each
ORDER can only come from one CUSTOMER,
an ORDER can contain one or many
PRODUCTS, a product may or may not be
ordered)
18
Physical Design
 The process of producing a description
of the implementation of the database
in secondary storage

 It describes the tablespace structure

and size, retrieval method, and indexing
technique for achieving optimum
system performance

19
Prototyping
 Building a working model of the database system

 A prototype is a model that tests specific

functions, but does not have the full system
functionality

 Purpose: To allow users to use the prototype for

evaluation of specific system functions
(applications) and suggest improvements or new
features.

20
Implementation
 The physical realization of the database and
application designs

 Requires a complete (and preferably finalized)

specification of the data and relationship
models and the application (view) layouts and
I/O.

 Runs parallel with prototyping activities

21
Implementation Activities
1. Set-up the chosen DBMS
2. Develop the database (database schema)
using DDL
3. Build the applications using 3GL or 4GL.
Database transactions are written using DML
and are later inserted in host languages
such as Visual Basic, C++, Java and others
4. Insert data into the tables, or transfer the
data from the existing (old) system

22
Testing
 The process of running the database system
with the intent of finding errors
 Database stability is monitored, and
application errors/issues are noted and fixed
 Common testing activities:
 Test the database from the point of view of

data, application performance, software

and hardware performance, and security
 Refine and rectify issues with the logical

and physical design of the database

23
Operational Maintenance
 Begins when the completed information
system is operational and used in the live
environment

 The complete information system consists of:

 Organization management (stakeholders)

 Users

 Applications and database

24
Approaches to Operation
 A new system can be delivered into
operation using any of the followinng
approaches:

1. Direct (complete) migration plan

2. Parallel migration plan
3. Pilot (pioneer) migration plan
4. Staged (staggered) migration plan

25
 Direct Migration Plan
Existing system New system

 Operation that involves immediate

abandonment of the existing system
and adoption of the new system

26
 Parallel Migration Plan
Existing system

New system

 Both systems are operational for a

period of time
 Transactions (data I/O) are duplicated
on both the old and existing systems
27
Parallel Migration Plan –
contd.
 Outputs from the new system is
compared to the old system throughout
this period
 The old existing system is stopped
(taken offline) once management is
satisfied with the performance of the
new system

28
 Pilot Migration Plan

New system
Existing system

 The new system is used in only one

department (section) of the
organization
 The section is called the pilot site
29
Pilot Migration Plan – contd.
 The existing system (old) is still operational in
all other departments at the same time
 When the new system is verified to perform
as expected, the new system will be
implemented and adopted at all remaining
departments.
 The old system is abandoned at the end of
the pilot phase

30
 Staged Migration Plan
Existing system New system

 The new system is implemented in

phases or different stages
 Implementation occurs throughout the
organization
31
Staged Migration Plan – contd.
 Only specific subsystems are implemented
first:

 Management subsystem
 Control subsystem

 When each subsystem is verified to work as

expected, the function of the existing system
that it replaces is abandoned
32
Operational Maintenance
 Activities involved after the system is
implemented and fully operational are:

 Monitor system performance

 Maintain and upgrade aplications if

needed

 Maintenance is performed continuously

during the operation phase
33
Operational Maintenance –
contd.
 The process must consider
improvements to the software and
applications, and requirements that
might be added later, or changed

 Changes during maintenance should not

disrupt the operation of other users of
the database system
34
Maintenance Objectives
 Maintenance is performed by the DBA from
time to time for the following reasons:

1. Recover
 There are errors in the system

 The system is performing poorly

 Some problems/events may not have

been considered during the analysis

stage, and only realized later

35
Maintenance Objectives –
contd.
2. Adaptation
 The system is changed to conform to
external requirements
 Example : government policy changes

3. Increase Value
 Specification change as requested by
the system’s own users

36
 The End.

Thank you!

Topic for the next lecture:

Topic 4-1 : Entity Relationship
Model (Part 1)

37