CSE2005 – Database

Management
Systems
Module 1: Fundamental Concepts &
Architecture
Module 1
Module:1 Fundamental Concepts and Architecture:
Introduction to database system, Characteristics of the
Database Approach, Actors on the Scene, Workers behind
the Scene, Advantages of Using the DBMS Approach, Data
Models, Schemas, and Instances, Three-Schema Architecture
and Data Independence, Database Languages and Interfaces,
The Database System Environment, Classification of
Database Management Systems
Book(s)
 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
 Database Users
 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

 Actors on the Scene

 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

Image Source: https://www.dataversity.net/so-you-want-to-be-a-database-administrator/

 Actors on the Scene
 Database Designers:
 Responsible to define the content,
the structure, the constraints, and
functions or transactions against the
database.
 communicate with the end-users and
understand their needs.

Image Source: https://www.cybertec-postgresql.com/en/services/postgresql-design/

postgresql-database-modeling/
 Actors on the Scene
 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 of operations.

Image Source: http://dinesql.blogspot.com/2015/10/types-of-database-end-users.html

 Actors on the Scene
 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
database.

Image Source: https://knowyourmeme.com/photos/1698903-computer-reaction-faces

 Actors on the Scene
 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 address book.

Image Source: https://www.yourdictionary.com/stand-alone-pc

 Workers behind the
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
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
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
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
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
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
 Data Model: A set of

 Components of requirements
 Structure of DB
 Planning of DB
 Helps us to put real world
requirements to a design

Image Source: https://powerpivotpro.com/2016/02/data-modeling-power-pivot-power-bi/

 Data Model -
Categories
 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.)
 Physical (low-level, internal) data models:
 Provide concepts that describe details of how
data is stored in the computer.
 Implementation (representational) data models:
 Provide concepts that fall between the above
two, used by many commercial DBMS
implementations.
 Data Models
Types:
 Object based(data at user and Application level),
 Physical based(how data stored in memory, each tables are built and related),
 Record based(data at user and Application level)
Three types:
 Hierarchical(parent-child relationship drawback :duplication)
 Relational(developed for long storage of data, large scale application,uses of
relation of set theory. information stored in tables-attributes and tuples)
 Network data model(drawback of hierarchical model is overcome)

Image Source: https://powerpivotpro.com/2016/02/data-modeling-power-pivot-power-bi/

Schema vs Instances
 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.
Schema vs Instances
 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.
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.
Database Schema vs
State
 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.
 Database Schema -
Example

Image Source: Ramez Elmasri and Shamkant B. Navathe

 Database State -
Example

Image Source: Ramez Elmasri and Shamkant B. Navathe

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.
 1- Tier Architecture

 In this architecture, the database is directly

accessed by the user.
 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.

Image Source: guru99.com

 2 - Tier Architecture

 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

 3 - Tier Architecture

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

Image Source: guru99.com

Comparing 2 - Tier &
3 - Tier Architecture
Three-Schema Architecture
 Proposed to support DBMS characteristics of:
 Program-data independence.
 Support of multiple views of the data.

 Not explicitly used in commercial DBMS products, but has been useful in
explaining database system organization
Three-Schema Architecture
 Defines DBMS schemas at three levels:
 Internal schema at the internal level to describe physical storage structures
and access paths (e.g indexes).
 Typically uses a physical data model.
 Conceptual schema at the conceptual level to describe the structure and
constraints for the whole database for a community of users.
 Uses a conceptual or an implementation data model.
 External schemas at the external level to describe the various user views.
 Usually uses the same data model as the conceptual schema.
The three-schema architecture
Three-Schema Architecture
 Mappings among schema levels are needed to transform requests and
data.
 Programs refer to an external schema, and are mapped by the DBMS to
the internal schema for execution.
 Data extracted from the internal DBMS level is reformatted to match
the user’s external view (e.g. formatting the results of an SQL query for
display in a Web page)
Data Independence
 Logical Data Independence:
 The capacity to change the conceptual schema without having to change the
external schemas and their associated application programs.

 Physical Data Independence:

 The capacity to change the internal schema without having to change the
conceptual schema.
 For example, the internal schema may be changed when certain file
structures are reorganized or new indexes are created to improve database
performance
Data Independence (continued)
 When a schema at a lower level is changed, only the mappings between
this schema and higher-level schemas need to be changed in a DBMS that
fully supports data independence.
 The higher-level schemas themselves are unchanged.
 Hence, the application programs need not be changed since they refer
to the external schemas.
History of Data
Models
 Relational Model: proposed in 1970 by E.F. Codd (IBM), first
commercial system in 1981-82.
 Eg.(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.)
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.
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.
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.
 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.
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.
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.
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.
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.
DBMS Interfaces
 Stand-alone query language interfaces.
 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.
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.
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.
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.
 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
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.
 Flexibiltiy – New Technology can be easily integrated
into the system.
 Interoperabilty – All components work together.
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.