CHAPTER 1

INTRODUCTION TO
DATABASE
 Objectives
2

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

Differentiate data and information

Differentiate file processing and database system
Explain database structure and the three-level
architecture
Explain the evolution of database and the database
system environment
 DATA VS INFORMATION
3

1) STID3013 – A
2) CGPA – 3.42
3) Height – 1.70 m
4) Name – Jack
5) Average Marks for STID3013 – 70.5
6) 24/8/2010 - The date of your mid sem
exam.
Differences between Data and Information
4

Data are raw facts, i.e. telephone number, birth

date, name, etc.
Data : building blocks of information
Information is produced by processing data
Information is used to reveal the meaning of data
Data vs. Information
5

SIRIUS SATELLITE RADIO INC.

Data

Stock Price
 6.34
 6.45
 6.39
 6.62
 6.57
 6.64
 6.71
 6.82
 7.12
 7.06 Last 10 Days
DATA vs INFO - Conclusion
6
 Examples of Database Applications
7

Purchases from the supermarket

Purchases using your credit card
Booking a holiday at the travel agents
Using the local library
Taking out insurance
Using the Internet
Studying at university
 Database
8

Shared collection of logically related data (and

a description of this data), designed to meet
the information needs of an organization.
Logically related data comprises entities,
attributes, and relationships of an
organization's information.
Description of data known as System catalog
(metadata or data dictionary) provides
program–data independence.
 Logically Related Data
9

Entity – a distinct object in the organization, i.e. a

person, place, thing, concept, or event.
Attribute – a property that describes some aspect of
entity.
Relationship – an association between entities
 File-based Systems
10

Collection of application programs that perform

services for the end users (e.g. reports).

Each program defines and manages its own

data.
File-based Processing
11
 Limitations of File-based Approach
12

Separation and isolation of data

 Each program maintains its own set of data.
 Users of one program may be unaware of
potentially useful data held by other programs.

Duplication of data
 Same data is held by different programs.
 Wasted space and potentially different values
and/or different formats for the same item.
 Limitations of File-based Approach
13

Data dependence
 File structure is defined in the program code.

Incompatible file formats

 Programs are written in different languages, and so cannot
easily access each others files.

Fixed Queries/Proliferation of application programs

 Programs are written to satisfy particular functions. Any
new requirement needs a new program.
 Limitations of File-based Approach
14

Definition of data was embedded in application

programs, rather than being stored separately and
independently.

No control over access and manipulation of data

beyond that imposed by application programs.
ANSI-SPARC Three-level Architecture
15
ANSI-SPARC Three-level Architecture
16

External Level
Users' view of the database.
 Describes that part of database that is relevant to a particular
user.
Conceptual Level
Community view of the database.
 Describes what data is stored in database and relationships
among the data.
Internal Level
 Physical representation of the database on the computer.
 Describes how the data is stored in the database.
Differences between Three Levels of ANSI-SPARC Architecture
17
 Objectives of Three-Level Architecture
18

All users should be able to access same data.

A user's view is immune to changes made in other

views.

Users should not need to know physical database

storage details.
 Objectives of Three-Level Architecture
19

DBA should be able to change database storage

structures without affecting the users' views.

Internal structure of database should be unaffected by

changes to physical aspects of storage.

DBA should be able to change conceptual structure of

database without affecting all users.
Major objective of Three-Level Architecture:Data Independence
20

 means: the upper levels are unaffected by

changes to lower levels

1. Logical Data Independence

2. Physical Data Independence
 Data Independence
21

Logical Data Independence

 Refers to immunity of external schemas to changes in conceptual
schema.
 Conceptual schema changes (e.g. addition/removal of entities).
 Should not require changes to external schema or rewrites of
application programs.
 Data Independence
22

Physical Data Independence

 Refers to immunity of conceptual schema to changes in
the internal schema.
 Internal schema changes (e.g. using different file
organizations, storage structures/devices).
 Should not require change to conceptual or external
schemas.
Data Independence and the ANSI-SPARC Three-level Architecture
23
 Evolution of Database Systems
24

First-generation
Hierarchical and Network
 disadvantages: - complex programs
- minimal data independence
- no accepted theoretical foundation
Second generation
Relational
 problems: limited modeling capabilities

Third generation
 Object Relational
 Object-Oriented
The Database System Environment
25
 The Database System Environment
26

Hardware
 Can range from a PC to a network of computers.

Software
 DBMS, operating system, network software (if necessary) and also
the application programs.

Data
 Used by the organization and consists of operational data and the
meta-data.
The Database System Environment
27

Procedures
 Instructions and rules that should be applied to the design
and use of the DBMS.

People (Roles in DBMS Environment)

 Data Administrator (DA)
 Database Administrator (DBA)
 Database Designers (Logical and Physical)
 Application Programmers
 End Users (naive and sophisticated)
The Database System Environment

Database Systems: Design,

Implementation, & Management,
6th Edition, Rob28
& Coronel
 Database Management System (DBMS)
29

A software system that enables users to define,

create, and maintain the database and which
provides controlled access to this database.
 Database Management System (DBMS)
30

The DBMS Manages the Interaction Between the End User

and the Database
 DBMS Facilities
31

Data definition language (DDL)

 Permits specification of data types, structures and
any data constraints.
 All specifications are stored in the database.

Data manipulation language (DML)

 General enquiry facility (query language) of the
data.
 DBMS Facilities
32

Controlled access to database may include:

 A security system – prevents unauthorized users accessing the
d/b.
 An integrity system – maintains the consistency of stored data.
 A concurrency control system – allows shared access of the
d/b.
 A recovery control system – restores the d/b to a previous
consistent state following a hardware or software failure.
 A user-accessible catalog – contains descriptions of the data in
the d/b.
 DBMS Facilities
33

 A view mechanism.
 Provides users with only the data they want or need to use.
 Views
34

Allows each user to have his or her own view of

the database.

A view is essentially some subset of the

database.
 Views
35

Benefits include:
 Reduce complexity;
 Provide a level of security;

 Provide a mechanism to customize the appearance

of the database;
 Present a consistent, unchanging picture of the
structure of the database, even if the underlying
database is changed.
 Advantages of DBMS
36

Control of data redundancy

 File-based systems waste space by storing same info in more than one file
Data consistency
 Reduced the risk by eliminating/controlling Data Redundancy – update once
More information from the same amount of data.
 Possible to derive additional information from the same data
Sharing of data
 Authorized user can share the same data
Improved data integrity
 Validity, rules enforcement  integrity  constraint
 Advantages of DBMS (continue...)
37

 Improved security
 Protection from unauthorized user
 Enforcement of standards
 Allow DBA to define and the DBMS to enforce necessary standards
 Economy of scale
 Cost saving
 Balanced conflicting requirements
 Each user has needs that may be conflict with the needs of other users – DBA can design database
that provide best use of resources for the organization as a whole
 Improved data accessibility and responsiveness
 Through query – list certain data
 Advantages of DBMS (continue...)
38

Increased productivity
 DBMSs provide standard functions that programmer have to write on their own
Improved maintenance through data
independence
 DBMS separates the data descriptions from the application, thereby making
applications immune to changes in data descriptions
Increased concurrency
 Two or more users allowed to access the same file/data simultaneously
Improved backup and recovery services
 DBMSs provide facilities to minimize the amount of processing that is lost/failure.
 Disadvantages of DBMS
39

Complexity
 Functionality  makes DBMSs complex – must understand the functionalities to
make full use of DBMS
Size
 Requiring substantial amounts of memory to run efficiently
Cost of DBMS
 License/memberships/single;multiple users/maintenance

Additional hardware costs

 Storage space etc
Disadvantages of DBMS (continue..)
40

Cost of conversion
 Converting existing applications to run the new DBMS & hardware

Performance
 Many applications/high load/peak time
Higher impact of a failure
 Failure of certain components can bring operations to a halt
 Objectives
41

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
42

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)
43

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
44
 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
 45

Stages
of the
Databas
e
Applica
tion
Lifecycl
e
 Database Planning
46

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
47

Steps:
1. Mission statement
2. Mission objectives
3. Development of standards
 Database Planning – Mission Statement
48

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

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

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

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
52

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
53
 Requirements Collection and Analysis
54

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
55

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

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

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
58
 Requirements Collection and Analysis
59

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
60
 View integration approach
61

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

Process of creating a design for a database that

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

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

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

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

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
67
 Database Design - phases
68

Three phases of database design:

 Conceptual database design

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

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
70

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
71

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
72
 DBMS Selection
73

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
74
DBMS Evaluation Features
75
Example - Evaluation of DBMS Product
76
 Application Design
77

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
78

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
79

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
80
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
81

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
82

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

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
84

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
85

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
86

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

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

Management of data resource including:

 database planning,
 development and maintenance of standards, policies and
procedures, and conceptual and logical database design.
 Database Administration
89

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

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

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

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