1

CSE2004 – Database Management

Systems
MODULE 1: DATABASE SYSTEMS
CONCEPTS AND ARCHITECTURE

Dr. S.L.Jayalakshmi
SCOPE
Chennai
Book(s)
2

 Text Book:
 Fundamentals of Database Systems by Ramez Elmasri and
Shamkant B.Navathe Pearson Education,2013.
 Reference Books:
 Database Management Systems by Raghu Rama Krishnan,
Tata Mcgraw Hill, 2010.
 Database System Concepts by Abraham Silberschatz, Henry
F.Korth and S.Sudarshan, Tata Mc Graw Hill, 2011
 Database System Design and Implementation by Rob
Cornell,cennage learning, 2011
 3

MODULE 1: DATABASE SYSTEMS CONCEPTS AND ARCHITECTURE

 History and motivation for database systems -characteristics of

database approach - Actors on the scene - Workers behind the
scene - Advantages of using DBMS approach– Data Models,
Schemas, and Instances– Three-Schema Architecture and Data
Independence– The Database System Environment– Centralized
and Client/Server Architectures for DBMSs– Classification of
database management systems
 Acknowledgement
4

 Profound thanks to the authors of the book:

Fundamentals of Database Systems by Ramez
Elmasri and Shamkant B.Navathe Pearson
Education,2013. as the content of the book
were helpful in preparing this presentation.
 Basic Definitions 5

 Data
 Database
 Mini-world
 Database management System (DBMS)
 Database System
Image Source: https://www.theteflcentre.com/news/skills-reading-6-tasks-for-
reading-activities-matching-words-to-definitions
Definitions 6

 Data are facts that are known and that can be recorded and that
have implicit meaning.
 Database:The collection of data, usually referred to as the
database, contains information relevant to an enterprise.
 Miniworld: It represents some aspect of the real (or an imagined)
world, called the miniworld or universe of discourse
 A database-management system (DBMS) is a collection of
interrelated data and a set of programs to access those data.
 The primary goal of a DBMS is to provide a way to store and retrieve
database information that is both convenient and efficient.
 Database system : Database together with the DBMS software is
referred to as a database system
 Basic Definitions 7

 Database
A collection of related data.

Image Source: https://tdwi.org/articles/2019/03/11/dtw-all-five-database-

requirements-for-digital-transformation.aspx
 Basic Definitions 8

 Data
Known facts that can be recorded and
have an implicit meaning.
Image Source: https://analyticsindiamag.com/10-best-data-cleaning-tools-get-data/
 Basic Definitions 9

 Mini-World
Some part of the real world about which data
is stored in a database. For example, student
grades and transcripts at a university.
Image Source: https://store.steampowered.com/app/814480/Mini_World_Block_Art/
 Basic Definitions 10

 Database Management System

A software package/ system to facilitate the
creation and maintenance of a computerized
database.
Image Source: https://www.webinhindi.com/2019/04/what-is-dbms-in-hindi.html
 Basic Definitions 11

 Database System
The DBMS software together with the data
itself. Sometimes, the applications are also
included.
Image Source: https://www.quora.com/What-is-database-system
 Basics
12

 More specifically, a DBMS is a general purpose software system facilitating

each of the following (with respect to a database):
 definition: specifying data types (and other constraints to which the data must
conform) and data organization
 construction: the process of storing the data on some medium (e.g., magnetic
disk) that is controlled by the DBMS
 manipulation: querying, updating, report generation
 sharing: allowing multiple users and programs to access the database
"simultaneously"
 system protection: preventing database from becoming corrupted when
hardware or software failures occur
 security protection: preventing unauthorized or malicious access to database.
 Types of Databases
13

and Database
Applications

Image Source: https://www.slideshare.net/PAQUIAAIZEL/types-of-databases

Types of Databases 14

and Database
Applications
 Traditional Applications:
 Numeric and Textual Databases
 More Recent Applications:
 Multimedia Databases
 Geographic Information Systems (GIS)
 Data Warehouses
 Real-time and Active Databases
 Many other applications
Traditional applications 15

 Banking: For customer information, accounts, and loans, and banking transactions.
 
 Airlines: For reservations and schedule information. Airlines were among the first to use databases in a
geographically distributed manner—terminals situated around the world accessed the central database system
through phone lines and other data networks.
 
 Universities: For student information, course registrations, and grades.
 
 Credit card transactions: For purchases on credit cards and generation of monthly statements.
 
 Telecommunication: For keeping records of calls made, generating monthly bills, maintaining balances on prepaid
calling cards, and storing information about the communication networks.
 
 Finance: For storing information about holdings, sales, and purchases of financial instruments such as stocks and
bonds.
 
 Sales: For customer, product, and purchase information.
 
 Manufacturing: For management of supply chain and for tracking production of items in factories, inventories of
items in warehouses/stores, and orders for items.
 
Drawbacks of using file systems to store data:
16

 Data redundancy and inconsistency - Due to availability of multiple file

formats, storage in files may cause duplication of information in different files.

 Difficulty in accessing data - In order to retrieve, access and use stored data,
need to write a new program to carry out each new task.

 Data isolation - To isolate data we need to store them in multiple files and
different formats.

 Integrity problems - Integrity constraints (E.g. account balance > 0) become

part of program code which has to be written every time. It is hard to add new
constraints or to change existing ones.

 Atomicity of updates - Failures of files may leave database in an inconsistent

state with partial updates carried out.

E.g. transfer of funds from one account to another should either complete or
not happen at all
Typical Database 17

Functionalities
 18
 More specifically, a DBMS is a general purpose software system
facilitating each of the following (with respect to a database):
 Definition: specifying data types (and other constraints to which the
data must conform) and data organization
 Construction: the process of storing the data on some medium (e.g.,
magnetic disk) that is controlled by the DBMS
 Manipulation: querying, updating, report generation
 Sharing: allowing multiple users and programs to access the database
"simultaneously"
 System protection: preventing database from becoming corrupted
when hardware or software failures occur
 Security protection: preventing unauthorized or malicious access to
database
Example of a 19

Database
 Mini-world for the example:
 Part of a UNIVERSITY environment.
 Some mini-world entities:
 STUDENTs
 COURSEs
 SECTIONs (of COURSEs)
 (academic) DEPARTMENTs
 INSTRUCTORs
Example of a 20

Database
 Some mini-world relationships:
 SECTIONs are of specific COURSEs
 STUDENTs take SECTIONs
 COURSEs have prerequisite COURSEs
 INSTRUCTORs teach SECTIONs
 COURSEs are offered by DEPARTMENTs
 STUDENTs major in DEPARTMENTs
 21

Example of a Database

Image Source: Ramez Elmasri and Shamkant B. Navathe

 Example of a 22

Database

Image Source: Ramez Elmasri and Shamkant B. Navathe

 Characteristics of 23

Database Approach

 Self-describing nature of a database system:

 A DBMS catalog stores the description of a
particular database (e.g. data structures, types,
and constraints)
 The description is called meta-data (Data
Dictionary).
Image Source: https://www.quora.com/How-should-I-write-my-self-description-in-
SSB-interviews
 This allows the DBMS software to work with
 Characteristics of 24

Database Approach

 Insulation between programs and data:

 Called program-data independence.
 Allows changing data structures and
storage organization without having to
change the DBMS access programs.
Image Source: https://www.indiamart.com/proddetail/insulation-tape-
19584466491.html
 Characteristics of 25

Database Approach

 Data Abstraction:
 A data model is used to hide storage details
and present the users with a conceptual view
of the database.
 Programs refer to the data model constructs
rather than data storage details.
Image Source: https://www.hitechnectar.com/blogs/data-abstraction-level/
Characteristics of 26

Database Approach

 Support of multiple views of the data:

 Each user may see a different view of the
database, which describes only the data
of interest to that user.
 Database Users 27

 Users may be divided into

 Those who actually use and control the database content, and those who design,
develop and maintain database applications (called “Actors on the Scene”)
 Those who design and develop the DBMS software and related tools, and the
computer systems operators -called “Workers Behind the Scene”.

Image Source: https://www.iconfinder.com/icons/85409/users_icon

Characteristics of 28

Database Approach
 Sharing of data and multi-user transaction
processing:
 Allowing a set of concurrent users to retrieve from
and to update the database.
 Concurrency control within the DBMS guarantees
that each transaction is correctly executed or
aborted
 Recovery subsystem ensures each completed
transaction has its effect permanently recorded in
the database
 OLTP (Online Transaction Processing) is a major
part of database applications. This allows hundreds
of concurrent transactions to execute per second.
 Actors

 Database Administrator
 DB designers
 End users
 Casual end user
 Naïve or parametric end user
 Sophisticated end user
 Standalone user
 System Analysts and application programmers
 Actors on the Scene 30

 Database administrators:
 Responsible for authorizing access to the
database, for coordinating and monitoring its
use, acquiring software and hardware
resources, controlling its use and monitoring
efficiency of operations.
Image Source: https://www.dataversity.net/so-you-want-to-be-a-database-administrator/
 Actors on the Scene 31

 Database Designers:
 Responsible to define the content, the
structure, the constraints, and functions or
transactions against the database. They must
communicate with the end-users and
Image Source: https://www.cybertec-postgresql.com/en/services/postgresql-design/postgresql- understand their needs.
database-modeling/
 Actors on the Scene 32

 End-users: They use the data for queries, reports

and some of them update the database content.
End-users can be categorized into:
 Casual: access database occasionally when
needed
 Naive or Parametric: they make up a large
section of the end-user population.
 Examples are bank-tellers or reservation
clerks who do this activity for an entire shift
Image Source: http://dinesql.blogspot.com/2015/10/types-of-database-end-users.html
of operations.
 Actors on the Scene 33

 Sophisticated:
 These include business analysts, scientists,
engineers, others thoroughly familiar with
the system capabilities.
 Many use tools in the form of software
packages that work closely with the stored
Image Source: https://knowyourmeme.com/photos/1698903-computer-reaction-faces database.
 Actors on the Scene 34

 Stand-alone:
 Mostly maintain personal databases using
ready-to-use packaged applications.
 An example is a tax program user that creates its
own internal database.
 Another example is a user that maintains an
Image Source: https://www.yourdictionary.com/stand-alone-pc address book.
 Workers behind the scene
Those who work to maintain the database system environment

 DBMS system designers and implementers

 Tool developers
 Operators and maintenance personnel (System Admin)
 Workers behind the 36

Scene

 DBMS System Designers and Implementers

 Design and implement DBMS modules and interfaces as a
software package.
 Tool Developers
 They design and implement tools which include software
packages that facilitate database modelling and design,
database system design and improved performance.
Image Source: https://www.yourdictionary.com/stand-alone-pc
 Workers behind the 37

Scene

 Operators and Maintenance Personnel

 Responsible for actual running and maintenance of the
hardware and software environment for the database
system.
Image Source: https://www.yourdictionary.com/stand-alone-pc
 Advantages of 38

Database Approach

 Controlling redundancy in data storage and in

development and maintenance efforts.
 Sharing of data among multiple users.
 Restricting unauthorized access to data.
 Providing persistent storage for program Objects
Image Source: https://www.ringlead.com/blog/the-benefits-of-using-database-management-systems
 Advantages of 39

Database Approach

 Providing Storage Structures (e.g. indexes) for

efficient Query Processing.
 Providing backup and recovery services.
 Providing multiple interfaces to different classes of
users.
 Representing complex relationships among data.
Image Source: https://www.ringlead.com/blog/the-benefits-of-using-database-management-systems
 Advantages of 40

Database Approach

 Enforcing integrity constraints on the database.

 Drawing inferences and actions from the stored
data using deductive and active rules.
 Potential for enforcing standards.
 Reduced application development time.

Image Source: https://www.ringlead.com/blog/the-benefits-of-using-database-management-systems

 Advantages of 41

Database Approach

 Flexibility to change data structures.

 Availability of current information.
 Economies of scale:
 Wasteful overlap of resources and personnel
can be avoided by consolidating data and
applications across departments
Image Source: https://www.ringlead.com/blog/the-benefits-of-using-database-management-systems
 Data models
 One fundamental characteristic of the database approach - data abstraction.
 Data abstraction generally refers to the suppression of details of data
organization and storage, and the highlighting of the essential features
 To achieve this abstraction, data models are used
 A data model—A set of concepts to describe the structure of a database, the
operations for manipulating these structures, and certain constraints that the
database should obey.
 The structure of a database means the data types, relationships, and
constraints that apply to the data
 43

Data Model Structure and

Constraints
 Constructs are used to define the database structure
 Constructs typically include elements (and their data types) as well as groups of
elements (e.g. entity, record, table), and relationships among such groups
 Constraints specify some restrictions on valid data; these constraints must be
enforced at all times
 44

Data Model Operations

 These operations are used for specifying database retrievals and updates by
referring to the constructs of the data model.
 Operations on the data model may include basic model operations (e.g.
generic insert, delete, update) and user-defined operations (e.g.
compute_student_gpa, update_inventory).
 DBMS – Data Models 45

 Data Models define how the logical structure of a database is modeled.

 They are fundamental entities to introduce abstraction in a DBMS.
 They define how data is connected to each other and how they are processed and stored inside
the system.
 The very first data model could be flat data-models, where all the data used are to be kept in the
same plane.
 Earlier data models were not so scientific, hence they were prone to introduce lots of duplication
and update anomalies.
Data Model - Categories 46

 Conceptual (high-level, semantic) data models:

 Provide concepts that are close to the way many users perceive data.
 (Also called entity-based or object-based data models.)
 Eg:ER model
 Physical (low-level, internal) data models:
 Provide concepts that describe details of how data is stored in the computer.
 meant for computer specialists, not for end users.

 Implementation (representational) data models:

 Provide concepts that fall between the above two, used by many commercial DBMS
implementations(record based model). Hides many details of data storage on disk
 E.g: Relational data model
 Other models:
 Object-oriented model
 Older models-Network and Hierarchical model
 47

History of Data Models

 Relational Model: proposed in 1970 by E.F. Codd (IBM), first commercial system in 1981-
82. Now in several commercial products (DB2, ORACLE, SQL Server, SYBASE, INFORMIX).
 Network Model: the first one to be implemented by Honeywell in 1964-65 (IDS System).
Adopted heavily due to the support by CODASYL (CODASYL - DBTG report of 1971). Later
implemented in a large variety of systems - IDMS (Cullinet - now CA), DMS 1100 (Unisys),
IMAGE (H.P.), VAX -DBMS (Digital Equipment Corp.).
 Hierarchical Data Model: implemented in a joint effort by IBM and North American
Rockwell around 1965. Resulted in the IMS family of systems. The most popular model.
Other system based on this model: System 2k (SAS inc.)
 48

History of Data Models

 Object-oriented Data Model(s):
 Several models have been proposed for implementing in a database system. One set comprises
models of persistent O-O Programming Languages such as C++ (e.g., in OBJECTSTORE or
VERSANT), and Smalltalk (e.g., in GEMSTONE).
 Additionally, systems like O 2, ORION (at MCC - then ITASCA), IRIS (at H.P.- used in Open OODB).
 Object-Relational Models:
 Most Recent Trend. Started with Informix Universal Server. Exemplified in the latest versions of
Oracle-10i, DB2, and SQL Server etc. systems.
 49

Hierarchical Data Model

 In Hierarchical Model, a hierarchical relation is formed by collection of relations and forms

a tree-like structure.
 The relationship can be defined in the form of parent child type.
 One of the first and most popular Hierarchical Model is Information Management System
(IMS), developed by IBM.
 50

Hierarchical Data Model - Merits and Demerits

 Merits
 The design of the hierarchical model is simple.
 Provides Data Integrity since it is based on parent/ child relationship
 Data sharing is feasible since the data is stored in a single database.
 Even for large volumes of data, this model works perfectly.
 De-Merits
 Implementation is complex.
 This model has to deal with anomalies like Insert, Update and Delete.
 Maintenance is difficult since changes done in the database may want you to do changes in
the entire database structure.
 51
Network Data Model

 The Hierarchical Model creates hierarchical tree with parent/ child relationship, whereas the
Network Model has graph and links.
 The relationship can be defined in the form of links and it handles many-to-many relations. This
itself states that a record can have more than one parent.
 52

Network Data Model - Merits and Demerits

 Merits
 Easy to design the Network Model
 The model can handle one-one, one-to-many, many-to-many relationships.
 It isolates the program from other details.
 Based on standards and conventions.
 De-Merits
 Pointers bring complexity since the records are based on pointers and graphs.
 Changes in the database isn’t easy that makes it hard to achieve structural independence.
 53
Relational Data Model

 A Relational model groups data into one or more tables. These tables are related to each
other using common records.
 The data is represented in the form of rows and columns i.e. tables.
 54
Relational Data Model

 Example : Let us see an example of two relations <Employee> and

<Department> linked to each other, with DepartmentID, which is
Foreign Key of <Employee> table and Primary key of
<Department> table.
 55

Relational Data Model - Merits and Demerits

 Merits
 It does not have any issues that we saw in the previous two models i.e. update, insert and
delete anomalies have nothing to do in this model.
 Changes in the database do not require you to affect the complete database.
 Implementation of a Relational Model is easy.
 To maintain a Relational Model is not a tiresome task.
 De-Merits
 Database inefficiencies hide and arise when the model has large volumes of data.
 The overheads of using relational data model come with the cost of using powerful
hardware and devices.
Schema vs Instances 56

 Database Schema:
 The description of a database.
 Includes descriptions of the database structure, data types, and the
constraints on the database.
 Schema Diagram:
 An illustrative display of (most aspects of) a database schema.
 Schema Construct:
 A component of the schema or an object within the schema, e.g., STUDENT,
COURSE.
 57

Database Schema - Example

Image Source: Ramez Elmasri and Shamkant B. Navathe

 Schema vs Instances 58

 Database State:
 The actual data stored in a database at a particular moment in time. This
includes the collection of all the data in the database.
 Also called database instance (or occurrence or snapshot).
 The term instance is also applied to individual database components, e.g.
record instance, table instance, entity instance.
 59

Database Schema vs State

 Database State:
 Refers to the content of a database at a moment in time.
 Initial Database State:
 Refers to the database state when it is initially loaded into the system.
 Valid State:
 A state that satisfies the structure and constraints of the database.
 Distinction
 The database schema changes very infrequently.
 The database state changes every time the database is updated.
 Schema is also called intension.
 State is also called extension.
 60

Database State - Example

Image Source: Ramez Elmasri and Shamkant B. Navathe

Three Schema Architecture 61

 It is also called ANSI/SPARC architecture or 3-level

architecture.
 The goal is to separate the user applications and physical
database.
 It is used to describe the structure of a specific database
system.
 It is also used to separate the user applications and
physical database.
 It contains 3-levels. It breaks the database down into three
different categories.
 Internal Level/schema: Actual PHYSICAL storage
structure and access paths.
 Conceptual or Logical Level/schema: Structure and
constraints for the entire database
 External or View level/schema: Describes various user
views
 62
Three Schema Architecture – Internal
Schema
 Internal level/Schema : It defines the physical storage structure of the database. It is a very low-
level representation of the entire database.
 It contains multiple occurrences of multiple types of internal records. In the ANSI term, it is also
called "stored record".
 Facts about Internal schema:
 The internal schema is the lowest level of data abstraction.
 It helps you to keep information about the actual representation of the entire database. It is
similar to the actual storage of the data on the disk in the form of records
 The internal view tells us what data is stored in the database and how its stored.
 It never deals with the physical devices. Instead, internal schema views a physical device as a
collection of physical pages.
 63
Three Schema Architecture – Conceptual
Schema
 Conceptual Schema/Level :
 It describes the Database structure of the whole database for the community of users.
 It hides information about the physical storage structures and focuses on describing data types, entities,
relationships, etc.
 This logical level comes between the user level and physical storage view.
 However, there is only single conceptual view of a single database.
 Facts about Conceptual schema:
 Defines all database entities, their attributes, and their relationships.
 Security and integrity information.
 In the conceptual level, the data available to a user must be contained in or derivable from the physical level.
 64
Three Schema Architecture – External
Schema
 External Schema/Level :
 It describes the part of the database which specific user is interested in & hides the
unrelated details of the database from the user.
 There may be "n" number of external views for each database.
 Each external view is defined using an external schema, which consists of definitions of
various types of external record of that specific view.
 An external view is just the content of the database as it is seen by some specific particular
user.
 For example, a user from the sales department will see only sales related data.
 65

Objectives of Three Schema Architecture

 An external level is only related to the data which is viewed by specific end
users.
 This level includes some external schemas.
 External schema level is nearest to the user.
 The external schema describes the segment of the database which is needed
for a certain user group and hides the remaining details from the database
from the specific user group.
 66
Levels of Database
 67
Levels of Database
 68
Data Independence

 Data Independence is defined as a property of DBMS that helps the user to change the
Database schema at one level of a database system without requiring to change the schema
at the next higher level.
 Data independence helps the user to keep data separated from all programs that make use of
it.
 Types of Data Independence
 Physical Data Independence
 Logical Data Independence
 69
Physical Data Independence
 Physical Data Independence : Changes internal schema without having to
change conceptual schema. i.e can easily change the physical storage structures
or devices with an effect on the conceptual schema.
 It helps user to separate conceptual levels from the Internal/Physical levels.
 It allows user to provide a logical description of the database without the need
to specify physical structures.
 It is achieved by the presence of the internal level of the database and then the
transformation from the conceptual level of the database to the internal level.
 70

Benefits of Physical Data Independence

 Due to Physical independence, any of the below changes will not affect the conceptual
layer:
 Using a new storage device like Hard Drive or Magnetic Tapes
 Modifying the file organization technique in the Database
 Switching to different data structures.
 Changing the access method. Modifying indexes.
 Changes to compression techniques or hashing algorithms.
 Change of Location of Database from say C drive to D Drive
 71
Logical Data Independence
 Logical Data Independence is the ability to change the conceptual scheme without changing :
 External views
 External API or programs
 Any change made will be absorbed by the mapping between external and conceptual levels.
 When compared to Physical Data independence, it is challenging to achieve logical data independence.
 Due to Logical independence, any of the below change will not affect the external layer.
 Add/Modify/Delete a new attribute, entity or relationship is possible without a rewrite of existing
application programs.
 Merging two records into one.
 Breaking an existing record into two or more records.
 72

Benefits of Logical Data Independence

 Helps user to improve the quality of the data.
 Database system maintenance becomes affordable.
 Enforcement of standards and improvement in database security.
 User does not need to alter data structure in application programs.
 Permits developer to focus on the general structure of the Database rather than
worrying about the internal implementation.
 It allows user to improve state which is undamaged or undivided.
 Database incongruity is vastly reduced.
 Easily make modifications in the physical level is needed to improve the
performance of the system.
 73

Benefits of Logical Data Independence

 Helps user to improve the quality of the data.
 Database system maintenance becomes affordable.
 Enforcement of standards and improvement in database security.
 User does not need to alter data structure in application programs.
 Permits developer to focus on the general structure of the Database rather than worrying
about the internal implementation.
 It allows user to improve state which is undamaged or undivided.
 Database incongruity is vastly reduced.
 Easily make modifications in the physical level is needed to improve the performance of
the system.
 74

Physical vs. Logical Data Independence

 75

Physical vs. Logical Data Independence

 Database Languages

 Data definition language (DDL) - used by the DBA and by database designers to
define schemas
 DDL compiler - processes DDL statements and stores the schema description in the DBMS
catalog

 Data manipulation language (DML)– used for retrieval, insertion, deletion, and
modification of the data.
 Procedural DMLs require a user to specify what data are needed and how to get those data.
 Declarative DMLs (also referred to as nonprocedural DMLs) require a user to specify what
data are needed without specifying how to get those data.
 Database Languages

 Data Control Language (DCL) - used for granting and revoking user access
on a database
 Grant: To grant access to user
 Revoke: To revoke access from user
.
 Transaction Control Language (TCL)– The changes in the database that we
made using DML commands are either performed or rollbacked using TCL
 Commit: It is used to save the transaction on the database.
 Rollback: It is used to restore the database to original since the last Commit.
 DBMS
 Stand-alone query language interfaces.
Interfaces 78

 Programmer interfaces for embedding DML in programming languages:

 Pre-compiler Approach.
 Procedure (Subroutine) Call Approach.
 User-friendly interfaces:
 Menu-based, popular for browsing on the web
 Forms-based, designed for users.
 Graphics-based (Point and Click, Drag and Drop etc.).
 Natural language: requests in written English.
 Combinations of the above.
 Interfaces for the DBA:
 Creating accounts, granting authorizations.
 Setting system parameters.
 Changing schema’s or access path.
DBMS System Environment/structure-
DBMS Components
 DBMS Component Modules

 The functional components of a database system can be broadly divided into

 Storage manager component
 Query processor component

Storage Manager
 provides the interface between the low-level data stored in the database and
the application programs/queries submitted to the system
 translates the various DML statements into low-level file-system commands
 responsible for storing, retrieving, and updating data in the database
 DBMS Component Modules (contd..)
The storage manager components include:
Authorization and integrity manager
tests for integrity constraints and checks user’s access rights on data
Transaction manager
ensures the consistency of database despite system failures
ensures that the concurrent transaction executions proceed without conflicts
File manager
manages the allocation of storage space and the data structures used to represent information stored on
disk.
Buffer manager
fetching data from disk storage into main memory, and deciding what data to cache in main memory

The storage manager implements several data structures as part of the physical system implementation:
Data files, Data dictionary, Indices
 DBMS Component Modules (contd..)
The query processor components include:
 DDL interpreter
 interprets DDL statements and records the definitions in the data dictionary
 DML compiler
 translates DML statements in a query language into evaluation plan consisting of low-
level instructions that the query evaluation engine understands
 also performs query optimization; that is, it picks the lowest cost evaluation plan from
among the alternatives
 Query evaluation engine
 executes low-level instructions generated by the DML compiler
 Database Architecture

 The architecture of a database system is greatly

influenced by the underlying computer system on
which the database system runs.
 Database systems can be centralized, or distributed
 Centralized, or client-server - server machine executes work on behalf of multiple
client machines.
 Distributed databases span multiple geographically separated machines.
 Centralized and Client/Server Architectures
for DBMSs
 The client/server architecture was developed to deal with computing
environments in which a large number of PCs, workstations, file servers, printers,
data base servers, Web servers, e-mail servers, and other software and
equipment are connected via a network.
 The idea is to define specialized servers with specific functionalities
 A client is typically a user machine that provides user interface capabilities and
local processing. When it requires access to additional functionality— it connects
to a server that provides the needed functionality.
 A server is a system containing both hardware and software that can provide
services to the client machines, such as file access, printing, archiving, or
database access.
 Centralized and Client/Server
Architectures
for DBMSs
Two main types of basic DBMS architectures were created on this
underlying client/server framework:
 two-tier
 three-tier
 86

Centralized Database Management System

 A centralized database is stored at a single location such as a mainframe computer.

 It is maintained and modified from that location only and usually accessed using an internet
connection such as a LAN or WAN.
 The centralized database is used by organizations such as colleges, companies, banks etc.
 87

Merits and De-merits of Centralized DBMS

 Advantages :
 The Data Integrity is maximized as the whole database is stored at a single physical
location. It is easier to coordinate the data and it is as accurate and consistent as
possible.
 The Data Redundancy is minimal in the centralized database. All the data is stored
together and not scattered across different locations. So, there is no redundant data
available.
 Since all the data is in one place, there can be stronger security measures around it.
So, It is much more secure.
 Data is easily portable because it is stored at the same place.
 It is cheaper than other types of databases as it requires less power and
maintenance.
 All the information can be easily accessed from the same location and at the same
time.
 88

Merits and De-merits of Centralized DBMS

 Disadvantages :
 Since all the data is at one location, it takes more time to search and
access it. If the network is slow, this process takes even more time.
 There is a lot of data access traffic for the centralized database. This may
create a bottleneck situation.
 Since all the data is at the same location, if multiple users try to access it
simultaneously it creates a problem. This may reduce the efficiency of the
system.
 If there are no database recovery measures in place and a system failure
occurs, then all the data in the database will be destroyed.
 89

Client-Server Database Management System

 A client does not share any of its resources, but requests a server’s content or service function.
 Clients therefore initiate communication sessions with servers which await incoming requests.
 Examples of computer applications that use the client–server model are Email, network printing, and the
World Wide Web.

Image Source: guru99.com

 90
DBMS Architecture

 DBMS design depends upon its architecture.

 Client/server architecture is used to deal with a large number of PCs, web servers, database
servers and other components that are connected with networks.
 Client/server architecture consists of many PCs and a workstation which are connected via the
network.
 91
1- Tier Architecture

 In this architecture, the database is directly accessed by the user(in which the client, server, and
Database all reside on the same machine).
 Any changes will be performed over the database itself.
 Used for development of the local application, where programmers can directly communicate with
the database for the quick response.
 A simple one tier architecture example would be anytime you install a Database in your system
and access it to practice SQL queries

Image Source: guru99.com

 Two-tier Architecture
 Application resides at the client machine
and it invokes database system
functionality at the server machine
through query language statements.

 API standards like ODBC and JDBC are

used for client – server interaction
 TWO - Tier Architecture 93

 It is basic client-server. But Applications on the

client end can directly communicate with the
database at the server side.
 For this interaction, API’s like: ODBC, JDBC are used.
The user interfaces and application programs are run
on the client-side.
 The server side is responsible to provide the
functionalities like: query processing and transaction
management.
 To communicate with the DBMS, client-side
application establishes a connection with the server
side.
Image Source: guru99.com
 Three - Tier Architecture 94

 The 3-Tier architecture contains another layer between the client and server.
 In this architecture, client can’t directly communicate with the server.
 The application on the client-end interacts with an application server which further communicates with the
database system.
 End user has no idea about the existence of the database beyond the application server and the database
also has no idea about any other user beyond the application.
 The 3-Tier architecture is used in case of large web application(Any large website on the internet, including
google.com).

Image Source: guru99.com

 Three-tier Architecture
 Client machine acts as a front end and does not contain any direct database
calls
 Instead, the client end communicates with an application server, usually
through a forms interface
 The application server in turn communicates with a database system to
access data
 The business logic of the application, which says what actions to carry out
under what conditions, is embedded in the application server instead of
being distributed across multiple clients
 Three-tier applications are more appropriate for large applications, and for
applications that run on the World Wide Web
Three-tier Architecture
Comparing 2 - Tier & 3 - Tier97
Architecture
 98

Merits and De-merits of Client-Server DDBMS

 Advantages :
 Centralization – Access, Resources, and Data Security are controlled
through server.
 Scalability – Any element can be upgraded when needed.
 Flexibility – New Technology can be easily integrated into the system.
 Interoperability – All components work together.
 99

Merits and De-merits of Client-Server DDBMS

 Disadvantages :
 Dependability – When Servers goes down, operations will cease.
 Lack of Mature Tools - To administrate.
 Lack of Scalability – Network OS are not vary scalable.
 Higher than anticipated Cost.
 Network Congestion.
 Classification of DBMS
 Classification based on data model
 Relational
 Hierarchical
 Network
 Object oriented
 XML

 Classification based on the number of users

 Single user
 Multiuser

 Classification based on database distribution

 Centralized database system
 Distributed database system
 Homogeneous
 Heterogeneous
 References
1. Fundamentals of Database Systems by Ramez Elmasri and
Shamkant B.Navathe Pearson Education,2013
2. Database System Concepts by Abraham Silberschatz, Henry
F.Korth and S.Sudarshan, Tata Mc Graw Hill, 2011
102