CHAPTER 2:

The DATABASE
Environment

Modern Database Management

1
OBJECTIVES
 Define terms
 Database Environment
 Explain the Three – Level ANSI SPARC Architecture
 Relational Model
 The DBMS Schema
 The Entity Relationship Diagram
 Describe database system development life cycle
 Explain prototyping and agile development approaches
 Explain roles of individuals
 Explain the three-schema architecture for databases

2
 WHAT IS A DATABASE ENVIRONMENT?

Is a collective system of components that

comprises and regulates the group of data,
management and use of data which consist of
software, hardware, people, techniques of handling
database and the data also.

3
4
 THREE-LEVEL ANSI-SPARC ARCHITECTURE

 An early proposal for a standard terminology and

general architecture for database systems was
produced in 1971 by the DBTG (Data Base Task
Group) appointed by the Conference on Data
Systems and Languages (CODASYL, 1971). The
DBTG recognized the need for a two-level
approach with a system view called the schema
and user views called sub-schemas.

American National Standard Institute (ANSI)-

Standards Planning and Requirements Committee (SPARC) 5
 THREE-LEVEL ANSI-SPARC ARCHITECTURE
The way users recognize the data
is called the external level.

The conceptual level offers both the

mapping and the desired
independence between the external
and internal levels.

The way the DBMS and the

operating system distinguish the
data is the internal level, where
the data is actually stored using
the data structures and file.

6
The Database
Architecture

7
WHAT IS DATABASE ARCHITECTURE?
A DBMS architecture is depending on its design and can be
of the following types:
 Centralized

 Decentralized

 Hierarchical

 DBMS architecture can be seen as either single tier or

multi-tier. An architecture having n-tier splits the entire
system into related but independent n modules that can
be independently customized, changed, altered, or
replaced.

8
Two-tier database with local
area network

9
The Three Tier Architecture

A 3-tier application is an application program that is structured into three major

parts; each of them is distributed to a different place or places in a network.
These 3 divisions are as follows:
 The workstation or presentation layer
 The business or application logic layer
 The database and programming related to managing layer

10
Three-tiered client/server database architecture

11
 THE RANGE OF DATABASE
APPLICATIONS
 Personal databases
 Two-tier and N-tier Client/Server databases
 Enterprise applications
 Enterprise resource planning (ERP) systems
 Data warehousing implementations

12
Database architectures

13
 FILE SERVER ARCHITECTURE
Workstation 2 A Large amount of network
Workstation 1 traffic
Workstation 3
A full copy of DBMS is
LAN required on each workstation
Concurrency, recovery and
Request for data
integrity control are more
database complex
File Server

Client Server architecture

Client 2
Client 1

Client 3
LAN
Request for data Selected data returned
database
Server (with
DBMS)
ALTERNATE CLIENT-SERVER TOPOLOGIES

client Single Client -

Server Single Server

Client 1
Server Multiple Client
Client 2 - Single Server

Client 1 Multiple Client -

Server 1 Multiple Server
Client 2

Server 2
Client 3
 SUMMARY OF CLIENT SERVER
APPLICATIONS
Server
Client
• Accepts and processes database
 Manages the user requests from clients
interface
• Checks authorization
 Accepts and check
• Ensures integrity constraints not
syntax of user input
violated
 Process application
• Performs query/ update
 Generates database processing and transmits
requests and response to client
transmits to the
• Maintains system catalog
server
• provides concurrent database
 Passes response
access
back to user
• Provides recovery control
Relational Model

17
WHAT IS RELATIONAL MODEL?
The relational model is the theoretical basis of
relational databases which is a technique or way of
structuring data using relations, which are grid-like
mathematical structures consisting of columns and rows.

The Relational Database Management System (RDBMS) has

become the leading data-processing software in use now-a-
days with approximated new license sales of between US$6
billion and US$10 billion per year. This software signifies the
second generation of DBMSs and is based on the relational
data model proposed by Mr. E. F. Codd in the year 1970. You
might be very familiar with the physical demonstration of a
relation in a database – which is known as table.
18
OBJECTIVES OF RELATIONAL MODEL
The relational model’s objectives were specified as follows:
 To allow a high degree of data independence; application
programs must not be affected by alterations to the internal
data representation, mostly by changes to file organizations or
access paths.
 To provide considerable grounds for dealing with data
semantics, reliability, and redundancy problems. In particular,
Codd’s theory for relational model introduced the concept of
normalized relations, where relations that have no repeating
groups and the process is called normalization.
 To allow the expansion of set-oriented data manipulation
languages.

19
Sample relationship Model: Student table with 3 columns and four records.

Stu_Id Stu_Name Stu_Age

111 Ashish 23

123 Saurav 22

169 Lester 24

234 Lou 26

20
The DBMS
Schema

21
DATABASE SCHEMA
 The concept of a relation corresponds to the programming
language notion of a variable, while the concept of a relation
schema corresponds to the programming languages’ notion
of type definition. In other words, a database schema is the
skeletal structure which represents the logical view of the
complete database. It describes how the data is organized
and how the relations among them are associated and
formulates all the constraints that are to be applied on the
data.

22
 Some Common Relational Model Terms

Domain: A domain is the set of

allowable values for one or more
attributes.

Tuple: A tuple is a row of a relation.

Relation: A relation is a table with

columns and rows.

Attribute: An attribute is a named

column of a relation.

23
 WHAT IS SCHEMA IN
DATABASE MANAGEMENT SYSTEM?
Schema can be defined as the design of a database. The overall
description of the database is called the database schema. It
can be categorized into three parts.
View schema can be defined as the design
of database at view level which generally
describes end-user interaction with
database systems.

Logical schema can be defined as the design of

database at logical level. In this level, the
programmers as well as the database administrator
(DBA) work. At this level data can be described as
certain types of data records which can be stored in
the form of data structures. However, the internal
details (such as implementation of data structure)
will be remaining hidden at this level.

Physical schema can be defined as the

design of a database at its physical level. In
this level, it is expressed how data is stored in
blocks of storage.

24
OBJECTIVE FOR THE THREE-LEVEL ARCHITECTURE
 Is to provide data independence, which means that upper
levels are unaffected by changes to lower levels.

There are two kinds of data independence:

Logical Data Independence
Logical data independence can be defined as the
immunity of the external schemas to changes in the conceptual
schema.

Physical data independence

Physical data independence can be defined as the
immunity of the conceptual schema to changes in the internal
schema.
25
ENTITY RELATIONSHIP DIAGRAM
(ER-Diagram)

26
WHAT IS ENTITY RELATIONSHIP DIAGRAM
ER-Diagram is a pictorial representation of
data that describes how data is communicated
and related to each other. Any object, such as
entities, attributes of an entity, sets of
relationship and other attributes of relationship
can be characterized with the help of the ER
diagram.

27
 Entities: They are represented using the
rectangle shape box. These rectangles are
named with the entity set they represent.

ER modeling is a top-down structure to database design that begins with

identifying the important data called entities and relationships in combination
between the data that must be characterized in the model.

28
 Entity type: A person, organization, object type, or
concept about which information is stored.
Ex. STUDENT table is an entity type
 Entity occurrence: A uniquely identifiable object of an
entity type.
Ex. John of the HNC course is the entity occurrence of the
entity type Student

29
Diagrammatic Representation of Entity Types
Each entity type is shown as a rectangle labeled with the name of the entity,
which is normally a singular noun.

30
What is Relationship Type?

A relationship type is a set of associations between

one or more participating entity types. Each relationship type
is given a name that describes its function.

Here is a diagram showing how relationships are formed in a

database.

31
What is degree of Relationship?

The entities occupied in a particular relationship type are

referred to as participants in that relationship. The
number of participants involved in a relationship type is
termed as the degree of that relationship.

In the above figured example “Branch has staff”, there is a

relationship between two participating entities. A
relationship of degree two is called binary degree
(relationship).
32
What are Attributes?

Attributes are the properties of entities that are

represented by means of ellipse shaped figures. Every
elliptical figure represents one attribute and is directly
connected to its entity (which is represented as rectangle).

It is to be noted that multi-valued

attributes are represented using double
ellipse like this:

33
One customer
may place many
orders, but each
order is placed by
a single customer
 One-to-many
relationship

34
One order has many
order lines; each order
line is associated with
a single order
 One-to-many
relationship

35
One product can
be in many
order lines, each
order line refers
to a single
product
 One-to-many
relationship

36
Therefore, one
order involves
many products
and one product is
involved in many
orders

 Many-to-many
relationship

37
 COMPONENTS OF THE
DATABASE ENVIRONMENT
 CASE Tools–computer-aided software engineering
 Repository–centralized storehouse of metadata
 Database Management System (DBMS) –software for
managing the database
 Database–storehouse of the data
 Application Programs–software using the data
 User Interface–text and graphical displays to users
 Data/Database Administrators–personnel responsible for
maintaining the database
 System Developers–personnel responsible for designing
databases and software
 End Users–people who use the applications and
databases

39
 ENHANCED ENTITY-
RELATIONSHIP (EER) MODEL.
The ER model supported with additional semantic
concepts is called the Enhanced Entity-Relationship
(EER) model.

There are three of the most important and useful

added concepts of the EER model:
 specialization/generalization

 aggregation

 composition

40
 WHAT ARE GENERALIZATION /
SPECIALIZATION?
The concept of generalization (specialization) is
associated with special types of entities known as
super classes and subclasses, and the process of
attribute inheritance.

ER Model has the capability of articulating database entities

in a conceptual hierarchical manner. As the hierarchy goes
up, it generalizes the view of entities and as you go deep in
the hierarchy, it will provide with the detail of every entity
included. Going up in this structure is called generalization,
where entities are associated together to represent a more
generalized view. Generalization is a bottom-up approach.
41
EXAMPLE

In generalization, a number of entities are accommodated together

into one generalized entity or category based on their similar
characteristics. In the below mentioned figure, whale, shark and
dolphin are generalized as fish, i.e. they have been categorized as the
fish.

 Super-class: An entity type that includes one or more dissimilar

sub-groupings of its occurrences that is required to be represented
in a data model.
 Sub-class: A distinct sub-grouping of occurrences of an entity type
that require to be represented in a data model.

42
Super-class/Subclass Relationships

Each member of a sub class is also a member of

the super class i.e. the entity in the sub class is the
same entity in the super class, but has a different
role. The relationship between a super class and a sub
class is one-to-one (1:1) and is termed as a super-
class/sub-class relationship.

43
What is Aggregation?

A relationship represents a connection between two entity

types that are conceptually at the same level.

Sometimes you may want to model a ‘has-a’, ‘is-a’ or ‘is-

part-of’ relationship, in which one entity represents a
larger entity (the ‘whole’) that will consist of smaller
entities (the ‘parts’).

This special kind of relationship is termed as an

aggregation.

44
An example of an aggregation is the ‘Teacher’ entity
following the ‘syllabus’ entity act as a single entity
in the relationship. In simple words, aggregation is
a process where the relation between two entities is
treated as a single entity.
45
DATABASE
System Development Life Cycle

46
TWO APPROACHES TO DATABASE
AND IS DEVELOPMENT
 SDLC
 System Development Life Cycle
 Detailed, well-planned development process
 Time-consuming, but comprehensive
 Long development cycle
 Prototyping
 Rapid application development (RAD)
 Cursory attempt at conceptual data modeling
 Define database during development of initial prototype
 Repeat implementation and maintenance activities with
new prototype versions
47
 SYSTEMS DEVELOPMENT LIFE CYCLE

Planning

Analysis

Logical Design

Physical Design

Implementation

Maintenance

Chapter 1 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 48

 SYSTEMS DEVELOPMENT LIFE CYCLE

Planning
Planning Purpose–preliminary understanding
Deliverable–request for study
Analysis

Logical Design

Physical Design

Database activity– Implementation

enterprise modeling and
early conceptual data
Maintenance
modeling

Chapter 1 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 49

 SYSTEMS DEVELOPMENT LIFE CYCLE

Purpose–thorough requirements analysis and

Planning structuring
Deliverable–functional system specifications
Analysis
Analysis

Logical Design

Physical Design

Database activity–thorough Implementation

and integrated conceptual
data modeling
Maintenance

Chapter 1 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 50

 SYSTEMS DEVELOPMENT LIFE CYCLE

Purpose–information requirements elicitation

Planning and structure
Deliverable–detailed design specifications
Analysis

Logical Design
Logical Design

Physical Design

Database activity– Implementation

logical database design
(transactions, forms,
Maintenance
displays, views, data
integrity and security)
Chapter 1 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 51
 SYSTEMS DEVELOPMENT LIFE CYCLE

Purpose–develop technology and

Planning organizational specifications

Analysis
Deliverable–program/data
structures, technology purchases,
organization redesigns
Logical Design

Physical Design
Physical Design

Database activity– Implementation

physical database design (define
database to DBMS, physical
Maintenance
data organization, database
processing programs)
Chapter 1 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 52
 SYSTEMS DEVELOPMENT LIFE CYCLE

Purpose–programming, testing,
Planning training, installation, documenting

Analysis Deliverable–operational programs,

documentation, training materials
Logical Design

Physical Design

Database activity–
database implementation, Implementation
Implementation
including coded programs,
documentation, Maintenance
installation and conversion

Chapter 1 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 53

 SYSTEMS DEVELOPMENT LIFE CYCLE

Planning Purpose–monitor, repair, enhance

Deliverable–periodic audits
Analysis

Logical Design

Physical Design

Database activity–
database maintenance, Implementation
performance analysis
and tuning, error Maintenance
Maintenance
corrections

Chapter 1 © 2013 Pearson Education, Inc. Publishing as Prentice Hall 54