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İ
