0% found this document useful (0 votes)
0 views

Module1

Module 1 of the Database Management Systems course covers fundamental concepts and architecture, including the characteristics of database systems, types of databases, and the roles of various database users. It discusses the advantages of using DBMS, data models, and the three-schema architecture that separates user applications from the physical database. The module also outlines the basic definitions related to databases and provides insights into database functionalities and architectures.

Uploaded by

justice.chitra.v
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
0 views

Module1

Module 1 of the Database Management Systems course covers fundamental concepts and architecture, including the characteristics of database systems, types of databases, and the roles of various database users. It discusses the advantages of using DBMS, data models, and the three-schema architecture that separates user applications from the physical database. The module also outlines the basic definitions related to databases and provides insights into database functionalities and architectures.

Uploaded by

justice.chitra.v
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 89

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
Acknowledgement

 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

 Database
 Data
 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
Basic Definitions

 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

 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

 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

 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

 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
Types of Databases
and Database
Applications

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


Types of Databases
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
Typical Database
Functionalities
Example of a
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
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
Example of a
Database

Image Source: Ramez Elmasri and Shamkant B. Navathe


Example of a
Database

Image Source: Ramez Elmasri and Shamkant B. Navathe


Characteristics of
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.
 This allows the DBMS software to work with
Image Source: https://www.quora.com/How-should-I-write-my-self-description-in-
SSB-interviews different database applications.
Characteristics of
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
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
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.
Characteristics of
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.
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
efficiency of operations.
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. They must
communicate with the end-users and
Image Source: https://www.cybertec-postgresql.com/en/services/postgresql-design/ understand their needs.
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
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
Image Source: https://knowyourmeme.com/photos/1698903-computer-reaction-faces
database.
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
Image Source: https://www.yourdictionary.com/stand-alone-pc address book.
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 concepts to describe the
structure of a database, the operations
for manipulating these structures, and
certain constraints that the database
should obey.
Image Source: https://powerpivotpro.com/2016/02/data-modeling-power-pivot-power-bi/
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
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).
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.
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
 It is also called ANSI/SPARC architecture or 3-level architecture.
 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: Actual PHYSICAL storage structure and access
paths.
 Conceptual or Logical Level: Structure and constraints for the
entire database
 External or View level: Describes various user views
Three Schema
Architecture
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 theform 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.
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.
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.
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.
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.
DBMS Components
DBMS Components
 DML : DML processor must interact with the query processor to
generate the appropriate code
 DDL interacts with Data Dictionary/ System Catalog
 System Catalog : It is a collection of tables and views that contain
important information about a database. It is available for each
database. It defines the structure of the database.
 For example, the DDL (data dictionary language) for all tables in the
database is stored in the system catalog.
 Query processor : It transforms user queries into a series of low level
instructions. It is used to interpret the online user’s query and convert
it into an efficient series of operations in a form capable of being sent
to the run time data manager for execution.
DBMS Components
 It uses the data dictionary to find the structure of the
relevant portion of the database and uses this
information in modifying the query and preparing and
optimal plan to access the database.
 Data Dictionary : It contains all the information about
the database. As the name suggests, it is the dictionary
of all the data items. It contains description of all the
tables, view, materialized views, constraints, indexes,
triggers etc.
DBMS – Data Models
 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 Models - 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, balancing user
views with some computer storage details.
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
Levels of Database
Levels of Database
Physical Data Independence
 Physical Data Independence : Change 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.
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
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.
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.
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.
Physical vs. Logical Data
Independence
Physical vs. Logical Data
Independence
DBMS Languages
 Data Definition Language (DDL) allows the DBA or user to describe and name
entities, attributes, and relationships required for the application plus any
associated integrity and security constraints.
 Data Manipulation Language (DML) provides basic data manipulation
operations on data held in the database.
 Data Control Language (DCL) defines activities that are not in the categories of
those for the DDL and DML, such as granting privileges to users, and defining
when proposed changes to a databases should be irrevocably made.
 Low Level or Procedural DML: allow user to tell system exactly how to
manipulate data (e.g., Network and hierarchical DMLs).
 High Level or Non-procedural DML(declarative language): allow user to state
what data is needed rather than how it is to be retrieved (e.g., SQL, QBE).
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.)
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.

You might also like