CHAPTER 1

INTRODUCTION TO
DATABASE
(PART 2)
 Objectives
2

At the end of this sub-chapter, students should be able to:

 Explain the phases in database system development

lifecycle
 Elaborate on the database design strategy and phases
 Describe database administration
 Software Depression/Crisis
3

 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.
 Information System (IS)
4

Resources that enable collection, management, control,

and dissemination of information throughout an
organization.

 Database is fundamental component of I.S., and its

development/usage should be viewed from perspective
of the wider requirements of the organization.
 Database Application Lifecycle
5
 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
Stages of the Database Application
Lifecycle
 Database Planning
7

Management activities that allow stages of database

application lifecycle to be realized as efficiently and
effectively, as possible.

 Must be integrated with overall IS strategy of the

organization. Issues on IS strategy:
 identification of enterprise plans and goals with
subsequent determination of IS needs
 evaluation of current IS to determine existing strengths and
weaknesses
 appraisal of IT opportunities that might yield competitive
advantage
 Database Planning
8

 Steps:
1. Mission statement

2. Mission objectives

3. Development of standards
 Database Planning – Mission Statement
9

 Mission statement for the database project

defines major aims of database application.

 Those driving database project normally define

the mission statement (e.g. director or owner)
 Mission statement helps clarify purpose of the
database project and provides clearer path
towards the efficient and effective creation of
required database application.
 Database Planning – Mission Objectives
10

 Once mission statement is defined, mission

objectives are defined.

 Each objective should identify a particular task

that the database must support.
 May be accompanied with 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.
Database Planning – Development of Standards
11

 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.

 A well designed standard can provides a basis for

training staff/measuring quality control and can
ensure that work conforms to a pattern.
 System Definition
12

Describes scope and boundaries of database

application and the major user views.

 User view defines what is required of a database

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

 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 application.

 User views also help in development of complex

database application allowing requirements to
be broken down into manageable pieces.
Representation of a database application with
multiple user views
14
 Requirements Collection and Analysis
15

Process of collecting and analyzing information

about the part of organization to be supported by
the database application, and using this
information to identify users’ requirements of new
system.
 Requirements Collection and Analysis
16

 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 application.
 Information is analyzed to identify requirements
specifications to be included in new database
application.
 Information is converted into structured statement
through requirements specifications techniques (e.g.
SAD, DFD & HIPO)
 Requirements Collection and Analysis
17

 Another important activity is deciding how to

manage database application with multiple user
views.
 Three main approaches:
 centralized approach
 view integration approach
 combination of both approaches
 Requirements Collection and Analysis
18

 Centralized approach
 Requirements for each user view are merged into a
single set of requirements.

 A global data model is created based on the merged

requirements (which represents all user views) which
consists of diagrams and documentation on the
requirements of the d/b users.

 This approach is preferred when there is a significant

overlap requirements for each user and the d/b
application is not overly complex.
Centralized approach to managing multiple user
views
19
 Requirements Collection and Analysis
20

 View integration approach

 Requirements for each user view are used to build a
separate data model.

 Data model representing single user view is called a

local data model, composed of diagrams and
documentation describing requirements of a particular
user view of database.
 Local data models are then merged to produce a global
data model, which represents all user views for the
database.
View integration approach to managing
multiple user views
21
 View integration approach
22

 This approach is preferred when there are significant

differences between user views and the d/b application
is sufficiently complex to justify dividing the work into
more manageable parts.
 Database Design
23

Process of creating a design for a database that

will support the enterprise’s operations and
objectives.
 Database Design
24

 Major aims:
 Represent data and relationships between data
required by all major application areas and user
groups.
 Provide data model that supports any transactions
required on the data.
 Specify a minimal design that is appropriately
structured to achieve stated performance
requirements for the system (such as response times).
 Database Design - approach
25

 Approaches include:
 Top-down: starts with the development of data models
using the Entity-Relationship (ER) model
 Bottom-up : begins at the fundamental level of
attributes
 Inside-out: identify major entities first and then
consider its other entities, relationship and attributes
 Mixed : both top-down and bottom-up
 Database Design - Data Modeling
26

 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.
 Database Design - Data Modeling
27

 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.
Criteria to produce an optimal data model
28
 Database Design - phases
29

 Three phases of database design:

 Conceptual database design

 Logical database design
 Physical database design.
 Conceptual Database Design
30

Process of constructing a model of the

information used in an enterprise, independent
of all physical considerations.

 Data model is built using the information in

users’ requirements specification.

 Source of information for logical design phase.

 Logical Database Design
31

Process of constructing a model of the

information 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.
 Physical Database Design
32

Process of producing a description of the database

implementation on secondary storage.

 Describes storage structures and access methods

used to achieve efficient access to data.

 Tailored to a specific DBMS system because in

developing the physical d/b design, the target d.b
system must be identified.
Three-level ANSI-SPARC architecture and phases of
database design
33
 DBMS Selection
34

Selection of an appropriate DBMS to support the

database application.

 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.
DBMS Evaluation Features
35
DBMS Evaluation Features
36
Example - Evaluation of DBMS Product
37
 Application Design
38

Design of user interface and application

programs that use and process the database.

 Database and application design are parallel

activities.

 Includes two important activities:

 transaction design;
 user interface design.
 Application Design – Transaction Design
39

An action, or series of actions, carried out by a

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

 Purpose to define and document the high-level

characteristics of the transactions required.
 Application Design - Transaction Design
40

 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.
Application Design – User Interface Design
41
 User Interface Design Guidelines:
 Meaningful title
 Comprehensible instructions
 Logical grouping and sequencing of fields
 Visually appealing layout of the form/report
 Familiar field labels
 Consistent terminology and abbreviations
 Consistent use of colour
 Visible space and boundaries for data-entry fields
 Convenient cursor movement
 Error correction for individual characters and entire fields
 Error messages for unacceptable values
 Optional fields marked clearly
 Explanatory messages for fields
 Completion signal
 Prototyping
42

Building working model of a database application.

 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.

 Implementation
43

 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 application programs, including

database transactions, created using DML possibly
embedded in a host programming language.
 Data Conversion and Loading
44

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.
 Testing
45

Process of executing application programs 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.
 Operational Maintenance
46

Process of monitoring and maintaining 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.
 Database Administration
47

 Database are corporate resources : must be managed like

any other resources

 Database administration is the management and control

of a DBMS and its data.
Data Administration and Database Administration
48

 Data Administrator (DA) and Database

Administrator (DBA) are responsible for managing
and controlling activities associated with corporate
data and corporate database, respectively.

 DA is more concerned with early stages of lifecycle

and DBA is more concerned with later stages.
 Data Administration
49

 Management of data resource including:

 database planning,

 development and maintenance of standards, policies and

procedures, and conceptual and logical database design.
 Database Administration
50

 Management of physical realization of a database

application including:
 physical database design and implementation,
 setting security and integrity controls,

 monitoring system performance, and reorganizing

the database.
 Exercises
51

 Discuss each of the following terms:

a) data
b) database
c) database management system
d) data independence
e) view
 Describe the five components of the DBMS
environment
 Exercises
52

 Discuss what a user view represents in the context of

a database application.
 Discuss the main approaches for managing the design
of a database application that has multiple user views.
 What are the purposes of data modeling?
 Exercises
53

 Compare between logical and global data model.

 Describe the phases of database design
 What is the different between prototyping and
implementation stage?
 Define the tasks associated with data administration
and database administration.