Centralized and Client/Server Architectures in DBMS

 

Centralized and Client/Server Architectures in DBMS

Database system architectures have evolved alongside general computer system architectures. The transition has moved from large monolithic centralized systems to distributed client/server systems, and later to multi-tier web-based architectures.

2.5.1 Centralized DBMS Architecture

1. What is a Centralized DBMS?

A centralized database system is one where:

  • The entire DBMS (all its components),

  • The application logic,

  • And the user interface programs
    all run on a single machine—typically a powerful mainframe or server.

All users connect to this single machine through terminals or thin clients.

2. Why was this architecture used earlier?

Historically:

  • Users accessed computers using dumb terminals (simple devices with only display and keyboard capability).

  • These terminals had no processing power.

  • Thus, all processing—query execution, application logic, user interface processing—was performed by the central computer.

The terminals only displayed results and sent user commands.

3. Centralized Architecture Components 

A typical centralized DBMS machine contains:

  • CPU

  • Memory

  • Disk storage

  • I/O devices (printers, tape drives)

  • DBMS software

  • Application programs

  • Compilers and editors

  • Display control software to handle terminal connections

Terminals are connected via a communication network but perform no local computation.

4. Evolution

As hardware prices fell:

  • Terminals were replaced by PCs, workstations, and later mobile devices.

  • Initially, these PCs still acted like dumb terminals: all DBMS operations remained centralized.

Over time, DBMSs began to make use of the processing power on these client machines.
This shift led to the rise of client/server architectures.


Basic Client/Server Architecture 

Client/server architecture was introduced to efficiently utilize networks that connected:

  • PCs

  • Workstations

  • File servers

  • Printers

  • Database servers

  • Web servers

  • Email servers

The idea is to distribute functionalities across specialized servers while client machines provide the user interface and some local processing.

Key Concepts

Client

A client is a user machine that provides:

  • Input/output interface for users

  • Local processing power

  • Ability to request more powerful services from servers

Server

A server is a machine that provides specialized services, such as:

  • File storage → file server

  • Printing → print server

  • Website hosting → web server

  • Database access → database server

Clients and servers are connected via LANs, wireless networks, or other communication systems.

Logical vs Physical Architecture

  • Logical architecture (Figure 2.5): Shows the conceptual relationship (clients interacting with multiple servers).

  • Physical architecture (Figure 2.6): Shows real machines—some running only client software, some only server software, and some running both.






Framework Assumptions

Client/server architecture assumes:

  • Many client machines

  • Fewer server machines

  • All connected through networks
    Clients request services that they cannot perform locally; servers respond to those requests.

Two-Tier Client/Server Architecture for DBMSs

This is the earliest and simplest DBMS client/server model.

⭐ How two-tier DBMS architecture works

  1. Client Tier (Tier 1)
    Runs:

    • User interface programs

    • Application programs

    • Local logic

  2. Server Tier (Tier 2)
    Runs:

    • The actual DBMS

    • SQL query processor

    • Transaction manager

    • Data storage services

Hence, in RDBMS, the server is often called:

  • SQL Server

  • Query Server

  • Transaction Server

⭐ Why did two-tier architectures emerge?

Because SQL provided a standardized interface.
This allowed:

  • Application logic → move to client

  • Query processing → remain on server

⭐ Connectivity Standards: ODBC and JDBC

To allow communication between client applications and DBMS servers:

1. ODBC (Open Database Connectivity)

  • A standard API

  • Allows any client program to connect to any DBMS with the appropriate driver

2. JDBC (Java Database Connectivity)

  • Similar to ODBC but designed for Java applications

Clients can even connect to multiple database servers simultaneously.

⭐ Advantages of Two-Tier Architecture

  • Simple and easy to implement

  • Efficient for small- to medium-scale systems

  • Direct communication between client and server

⭐ Limitations

  • Clients must be “fat clients” (more software installed locally)

  • Scalability issues when number of users grows

  • Difficult to maintain and update client software on thousands of machines

  • Security concerns: clients may interact directly with the DBMS

This paved the way for three-tier architectures.

 Three-Tier and n-Tier Architectures

Three-tier architecture is widely used in modern web applications.

⭐ Layers in a Three-Tier Architecture

Tier 1: Client / Presentation Layer

  • User interface (GUI or Web browser)

  • Input handling and display

Tier 2: Application Server / Middle Tier

  • Contains business logic and application rules

  • Validates client requests

  • Interprets business rules before reaching the database

  • Acts as a security layer (checks authentication & authorization)

  • Generates dynamic web pages

Tier 3: Database Server

  • Runs DBMS

  • Executes SQL queries / transactions

  • Manages storage and data access

⭐ Why use an intermediate tier?

Reasons include:

  • Better scalability

  • Improved security

  • Simplifies maintenance (thin clients)

  • Supports large web applications with many concurrent users

  • Allows business logic to be updated without modifying client software


⭐ n-Tier Architecture

This extends the three-tier model into 4, 5, or more tiers by further splitting:

  • Business logic layer

  • Middleware

  • Services

Used by modern:

  • ERP systems

  • CRM systems

  • Cloud-based applications

🎯 Summary: Centralized vs Client/Server Architectures

FeatureCentralized DBMSClient/Server DBMS
Processing LocationEntirely on one machineDistributed between clients & servers
Client RoleDumb terminals (no processing)Smart clients with local processing
ScalabilityLowHigh
MaintenanceSimple (one system)More complex (distributed systems)
Network LoadLow (simple terminal communication)Higher (client/server interactions)
Modern UseLegacy systemsMost modern systems (2-tier, 3-tier, web apps)

Comments

Post a Comment

Popular posts from this blog

Database Management Systems DBMS PCCST402 Scheme and Syllabus

  DATABASE MANAGEMENT  SYSTEMS (Common to  CS/CD/CA/CR/AD/AI/CB/CN/CC/CU/CI/CG)   Course  Code PCCST402 CIE Marks 40 Teaching  Hours/Week (L:T:P: R) 3:1:0:0 ESE Marks 60 Credits 4 Exam Hours 2Hrs.30 Min. Prerequisites(if  any) PCCST303 Course Type Theory Course Objectives:   1.        Equip the students with a comprehensive understanding of fundamental DBMS concepts as well as the principles and applications of NoSQL databases 2.        Enable students to design,implement,and manage both relational and NoSQL databases SYLLABUS   Module No. Syllabus  Description Contact Hours         1 Introduction to Databases...
Read more

Database System vs. Traditional File Processing

  1. Self-Describing Nature of the Database System Database System A DBMS stores both : The actual data, and A complete description of the data (metadata) in a catalog . Metadata includes structure of files, types of data items, constraints, etc. DBMS software reads definitions from the catalog, so it can work with any database. Traditional File Processing Data description is embedded inside application programs . Each program contains its own file structure definitions (e.g., C++ structs). Programs are tied to a single specific file format and cannot work with other data files. No central catalog or metadata repository. 2. Insulation Between Programs and Data (Program-Data Independence) Database System Data structure is separated from application programs. If the structure changes (e.g., adding Birth_date to STUDENT), only the catalog changes. Programs continue to work without modification. Achieved through data abstraction pr...
Read more