CSI2004 - Advanced Database

Management Systems
Centralized Architecture for DBMS
Centralized Architecture for DBMS
 Centralized Architecture for DBMS
 Centralized DBMS: All the DBMS functionality,
application program execution, and user interface
processing were carried out on one machine
 Most users accessed central database systems via
computer terminals that did not have processing
Power and only provided display capabilities.
 Therefore, all processing was performed remotely
on the computer system, and only display
information and controls were sent from the
computer to the display terminals, which were
connected to the central computer via various
types of communications networks
 Centralized Architecture for DBMS

Gradually, DBMS systems started to

exploit the available processing power at
the user side, which led to client/server
DBMS architectures
Client Server Architecture for DBMS
 Client Server Architecture for DBMS

 Client : User machine that provides user interface

capabilities and local processing.
 When a client requires access to additional
functionality—such as database access—that does
not exist at that machine, it connects to a server that
provides the needed functionality.
 Server : System containing both hardware and
software that can provide services to the client
machines, such as file access, printing, archiving,
or database access.
 Client Server Architecture for DBMS

 The client/server architecture was developed

to deal with computing environments in which
a large number of PCs, workstations, file
servers, printers, database servers, Web servers,
e-mail servers, and other software and
equipment are connected via a network
Client Server Architecture for DBMS
 Application Architecture for
DBMS

 Two-tier Architecture

 Three-tier Architecture
 Two-tier Architecture

 In the two-tier architecture, 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
 Two-tier Architecture
 When DBMS access is required, the program
establishes a connection to the DBMS (which is on
the server side);
 Once the connection is created, the client program
can communicate with the DBMS.
 A standard called Open Database Connectivity
(ODBC) provides an application programming
interface (API), which allows client-side programs
to call the DBMS, as long as both client and server
machines have the necessary software installed.
 Two-tier Architecture
 Most DBMS vendors provide ODBC drivers for
their systems. A client program can actually
connect to several RDBMSs and send query and
transaction requests using the ODBC API, which
are then processed at the server sites.
 Any query results are sent back to the client
program, which can process and display the results
as needed.
 A related standard for the Java programming
language, called JDBC, has also been defined.
 This allows Java client programs to access one or
more DBMSs through a standard interface
 Two-tier Architecture
 Two-tier architecture:
E.g. client programs using
ODBC/JDBC to communicate with a database
 Three-tier Architecture

 Clients contain GUI interfaces and some

additional application-specific business rules.
 The intermediate server accepts requests from
the client, processes the request and sends
database queries and commands to the
database server, and then acts as a conduit for
passing (partially) processed data from the
database server to the clients, where it may be
processed further and filtered to be presented
to users in GUI format.
 Three-tier Architecture

 When a bank customer accesses online

banking services with a web browser (the
client), the client initiates a request to the
bank's web server.
 The customer's login credentials may be
stored in a database, and the webserver
accesses the database server as a client.
 Three-tier Architecture

 Three-tier architecture: E.g. web-based

applications, and applications built using
“middleware”
Two-tier and three-tier architectures
Three-tier Architecture
 Three-tier Architecture

 The intermediate layer or middle tier is called

the application server or the Web server,
depending on the application.
 This server plays an intermediary role by
running application programs and storing
business rules (procedures or constraints) that
are used to access data from the database
server.
 It can also improve database security by
checking a client’s credentials before
forwarding a request to the database server.
Server System Architecture
 Server System Architecture

 Server systems can be broadly categorized into two

kinds:
 Transaction servers which are widely used in
relational database systems
 Data servers, used in object-oriented database
systems
 Transaction Servers
 Also called query server systems or SQL server systems
 Clients send requests to the server
 Transactions are executed at the server
 Results are shipped back to the client.
 Requests are specified in SQL, and communicated to the
server through a remote procedure call (RPC) mechanism.
 Transactional RPC allows many RPC calls to form a
transaction.
 Open Database Connectivity (ODBC) is a C language
application program interface standard from Microsoft for
connecting to a server, sending SQL requests, and receiving
results.
 JDBC standard is similar to ODBC, for Java
 Transaction Server Process Structure

 A typical transaction server consists of multiple processes

accessing data in shared memory.
 Server processes
 These receive user queries (transactions), execute them
and send results back
 Processes may be multithreaded, allowing a single
process to execute several user queries concurrently
 Typically multiple multithreaded server processes
 Lock manager process
 Database writer process
 Output modified buffer blocks to disks continually
 Transaction Server Processes (Cont.)
 Log writer process
 Server processes simply add log records to log record
buffer
 Log writer process outputs log records to stable storage.
 Checkpoint process
 Performs periodic checkpoints
 Process monitor process
 Monitors other processes, and takes recovery actions if
any of the other processes fail
E.g., aborting any transactions being executed by a
server process and restarting it
Transaction System Processes (Cont.)
 Transaction System Processes (Cont.)
 Shared memory contains shared data
 Buffer pool
 Lock table
 Log buffer
 Cached query plans (reused if same query submitted again)
 All database processes can access shared memory
 To ensure that no two processes are accessing the same data
structure at the same time, databases systems implement mutual
exclusion using either
 Operating system semaphores
 Atomic instructions such as test-and-set
 To avoid overhead of interprocess communication for lock
request/grant, each database process operates directly on the lock
table
 instead of sending requests to lock manager process
 Lock manager process still used for deadlock detection
 Data Servers
 Used in high-speed LANs, in cases where
 The clients are comparable in processing power to the
server
 The tasks to be executed are compute intensive.
 Data are shipped to clients where processing is performed,
and then shipped results back to the server.
 This architecture requires full back-end functionality at the
clients.
 Used in many object-oriented database systems
 Issues:
 Page-Shipping versus Item-Shipping
 Locking
 Data Caching
 Lock Caching
 Data Servers (Cont.)
 Page-shipping versus item-shipping
 Smaller unit of shipping  more messages
 Worth prefetching related items along with requested
item
 Page shipping can be thought of as a form of prefetching
 Locking
 Overhead of requesting and getting locks from server is
high due to message delays
 Can grant locks on requested and prefetched items; with
page shipping, transaction is granted lock on whole page.
 Locks on a prefetched item can be P{called back} by the
server, and returned by client transaction if the prefetched
item has not been used.
 Locks on the page can be deescalated to locks on items in
the page when there are lock conflicts. Locks on unused
items can then be returned to server.
 Data Servers (Cont.)
 Data Caching
 Data can be cached at client even in between transactions
 But check that data is up-to-date before it is used (cache
coherency)
 Check can be done when requesting lock on data item
 Lock Caching
 Locks can be retained by client system even in between
transactions
 Transactions can acquire cached locks locally, without
contacting server
 Server calls back locks from clients when it receives
conflicting lock request. Client returns lock once no local
transaction is using it.
 Similar to deescalation, but across transactions.