SEN235 Introduction to Database Systems

(Fall 2022)
Database System Development
Lifecycle
Asst.Prof.Dr. Hasan ÇİFCİ
 Agenda
▪ Software Depression
▪ Database System Development Lifecycle
▪ Database Planning
▪ System Definition
▪ Requirements Collection and Analysis
▪ Database Design
▪ DBMS Selection
▪ Application Design
▪ Prototyping
▪ Implementation
▪ Data Conversion and Loading
▪ Testing
▪ Operational Maintenance
▪ CASE (Computer Aided Software Engineering) Tools
▪ Data Administration and Database Administration
2/48
 Software Depression

• Last few decades have seen proliferation of software applications,

many requiring constant maintenance involving:
• correcting faults,
• implementing new user requirements,
• modifying software to run on new or upgraded platforms.
• Effort spent on maintenance began to absorb resources at an
alarming rate.
• As a result, many major software projects were
• late,
• over budget,
• unreliable,
• difficult to maintain,
• performed poorly.
• In late 1960s, led to ‘software crisis’, now refer to as the ‘software
depression’.
3/48
 Software Depression

• Major reasons for failure of software projects includes:

- lack of a complete requirements specification;
- lack of appropriate development methodology;
- poor decomposition of design into manageable
components.

• Structured approach to development was proposed called

Information Systems Lifecycle (ISLC) or Software Development
Lifecycle (SDLC).

4/48
 Information System (IS)

▪ Resources that enable collection, management, control, and

dissemination of information throughout an organization.

▪ Database is fundamental component of IS, and its

development/usage should be viewed from perspective of
the wider requirements of the organization.

5/48
 Database System Development
Lifecycle
• Database planning

• System definition

• Requirements collection and analysis

• Database design

• DBMS selection (optional)

• Application design
• Prototyping (optional)
• Implementation
• Data conversion and loading
• Testing
• Operational maintenance 6/48
Stages of the Database System
Development Lifecycle

7/48
 Database Planning

• Management activities that allow stages of database system

development lifecycle to be realized as efficiently and effectively
as possible.

• Must be integrated with overall IS strategy of the organization.

8/48
 Database Planning – Mission Statement

• Mission statement for the database project defines major aims

of database application.

• Those driving database project normally define the mission

statement.

• Mission statement helps clarify purpose of the database project

and provides clearer path towards the efficient and effective
creation of required database system.

9/48
 Database Planning – Mission Objectives

• Once mission statement is defined, mission objectives are

defined.

• Each objective should identify a particular task that the database

must support.

• May be accompanied by some additional information that

specifies the work to be done, the resources with which to do it,
and the money to pay for it all.

10/48
 Database Planning

• Database planning should also include development of

standards that govern:
• how data will be collected,
• how the format should be specified,
• what necessary documentation will be needed,
• how design and implementation should proceed.

11/48
 System Definition

• Describes scope and boundaries of database system and

the major user views.

• User view defines what is required of a database system

from perspective of:
• a particular job role (such as Manager or Supervisor) or
• enterprise application area (such as marketing,
personnel, or stock control).

12/48
 System Definition

• Database application may have one or more user views.

• Identifying user views helps ensure that no major users of the

database are forgotten when developing requirements for new
system.

• User views also help in development of complex database

system allowing requirements to be broken down into
manageable pieces.

13/48
Representation of a Database System with
Multiple User Views

14/48
 Requirements Collection and Analysis

• Process of collecting and analysing information about the part of

organization to be supported by the database system and using this
information to identify users’ requirements of new system.

• Information is gathered for each major user view including:

• a description of data used or generated;
• details of how data is to be used/generated;
• any additional requirements for new database system.

• Information is analyzed to identify requirements to be included in

new database system. Described in the requirements specification.

15/48
 Requirements Collection and Analysis

• Another important activity is deciding how to manage the

requirements for a database system with multiple user views.
• Three main approaches:
• centralized approach;
• view integration approach;
• combination of both approaches.

16/48
 Requirements Collection and Analysis

• Centralized approach
• Requirements for each user view are merged into a
single set of requirements.
• A data model is created representing all user views
during the database design stage.

17/48
Centralized Approach to Managing Multiple
User Views

18/48
 Requirements Collection and Analysis

• View integration approach

• Requirements for each user view remain as separate lists.
• Data models representing each user view are created and then
merged later during the database design stage.
• Data model representing single user view (or a subset of all user
views) is called a local data model.
• Each model includes diagrams and documentation describing
requirements for one or more but not all user views of database.
• Local data models are then merged at a later stage during database
design to produce a global data model, which represents all user
views for the database.

19/48
View Integration Approach to Managing
Multiple User Views

20/48
 Database Design

• Process of creating a design for a database that will support the

enterprise’s mission statement and mission objectives for the
required database system.
• Main approaches include:
• Top-down
• Bottom-up
• Inside-out
• Mixed

21/48
 Database Design

• Main purposes of data modeling include:

• to assist in understanding the meaning (semantics) of the
data;
• to facilitate communication about the information
requirements.

• Building data model requires answering questions about entities,

relationships, and attributes.

22/48
 Database Design

• A data model ensures we understand:

- each user’s perspective of the data;
- nature of the data itself, independent of its physical
representations;
- use of data across user views.

23/48
Criteria to Produce an Optimal Data
Model

24/48
 Database Design

• Three phases of database design:

• Conceptual database design

• Logical database design
• Physical database design.

25/48
 Conceptual Database Design

• Process of constructing a model of the data used in an

enterprise, independent of all physical considerations.

• Data model is built using the information in users’

requirements specification.

• Conceptual data model is source of information for logical

design phase.

26/48
 Logical Database Design

• Process of constructing a model of the data used in an

enterprise based on a specific data model (e.g. relational), but
independent of a particular DBMS and other physical
considerations.

• Conceptual data model is refined and mapped on to a logical

data model.

27/48
 Physical Database Design

• Process of producing a description of the database

implementation on secondary storage.

• Describes base relations, file organizations, and indexes used to

achieve efficient access to data.

• Also describes any associated integrity constraints and security

measures.

• Tailored to a specific DBMS system.

28/48
Three-Level ANSI-SPARC Architecture and
Phases of Database Design

29/48
 DBMS Selection

• Selection of an appropriate DBMS to support the database system.

• Undertaken at any time prior to logical design provided sufficient
information is available regarding system requirements.
• Main steps to selecting a DBMS:
• define Terms of Reference of study;
• shortlist two or three products;
• evaluate products;
• recommend selection and produce report.

30/48
DBMS Evaluation Features

31/48
DBMS Evaluation Features

32/48
Example - Evaluation of DBMS Product

33/48
 Application Design

• Design of user interface and application programs that use and

process the database.

• Database design and application design are parallel activities.

• Includes two important activities:

• transaction design;
• user interface design.

34/48
 Application Design - Transactions

• An action, or series of actions, carried out by a single user

or application program, which accesses or changes content
of the database.

• Should define and document the high-level characteristics

of the transactions required.

35/48
 Application Design - Transactions

• Important characteristics of transactions:

• data to be used by the transaction;
• functional characteristics of the transaction;
• output of the transaction;
• importance to the users;
• expected rate of usage.

• Three main types of transactions: retrieval, update, and mixed.

36/48
 Prototyping

• Building working model of a database system.

• Purpose
• to identify features of a system that work well, or are
inadequate;
• to suggest improvements or even new features;
• to clarify the users’ requirements;
• to evaluate feasibility of a particular system design.

37/48
 Implementation

• Physical realization of the database and application designs.

• Use DDL to create database schemas and empty database
files.
• Use DDL to create any specified user views.
• Use 3GL or 4GL to create the application programs. This will
include the database transactions implemented using the
DML, possibly embedded in a host programming language.

▪ 1GL and 2GL are low-level languages that are machine language.
▪ 3GL, are high-level languages, such as C, C++, Java, JavaScript, and Visual Basic.
▪ 4GL, are languages that consist of statements similar to statements in a human
language. 4GL are commonly used in database programming and scripts examples
include Perl, PHP, Python, Ruby, and SQL.
▪ 5GL, are programming languages that contain visual tools to help develop a program.
Examples include Mercury, OPS5, and Prolog.

38/48
 Data Conversion and Loading

• Transferring any existing data into new database and converting

any existing applications to run on new database.

• Only required when new database system is replacing an old

system.
• DBMS normally has utility that loads existing files into new
database.
• May be possible to convert and use application programs from old
system for use by new system.

39/48
 Testing

• Process of running the database system with intent of finding

errors.
• Use carefully planned test strategies and realistic data.
• Testing cannot show absence of faults; it can show only that
software faults are present.
• Demonstrates that database and application programs appear to
be working according to requirements.

40/48
 Testing

• Should also test usability of system.

• Evaluation conducted against a usability specification.

• Examples of criteria include:

• Learnability;
• Performance;
• Robustness;
• Recoverability;
• Adaptability.

41/48
 Operational Maintenance

• Process of monitoring and maintaining database system following

installation.

• Monitoring performance of system.

• if performance falls, may require tuning or reorganization of
the database.

• Maintaining and upgrading database application (when required).

• Incorporating new requirements into database application.

42/48
 CASE (Computer Aided Software
Engineering) Tools
• Support provided by CASE tools include:
- data dictionary to store information about database system’s
data;
- design tools to support data analysis;
- tools to permit development of corporate data model, and
conceptual and logical data models;
- tools to enable prototyping of applications.

43/48
 CASE Tools

• Provide following benefits:

• Standards;
• Integration;
• Support for standard methods;
• Consistency;
• Automation.

44/48
CASE Tools and Database System
Development Lifecycle

45/48
 Data Administration and Database
Administration
• The Data Administrator (DA) and Database Administrator (DBA)
are responsible for managing and controlling the corporate data
and corporate database, respectively.

• DA is more concerned with early stages of database system

development lifecycle and DBA is more concerned with later
stages.

46/48
 Data Administration and Database
Administration
Data Administrator Database Administrator
• Management of data resource • Management of physical
including: realization of a database
• database planning, system including:
• development and • physical database design
maintenance of and implementation,
standards, policies and • setting security and
procedures, and integrity controls,
conceptual and logical • monitoring system
database design. performance and
reorganizing the database.

47/48
Thank you…
Hasan ÇİFCİ