The Client/Server Database

Environment

CS263 Lecture 12
 Client/Server systems
• Operate in a networked environment
• Processing of an application distributed between front-end clients and
back-end servers
• Generally the client process requires some resource, which the server
provides to the client
• Clients and servers can reside in the same computer, or they can be on
different computers that are networked together, usually:
• Client – Workstation (usually a PC) that requests and uses a service
• Server – Computer (PC/mini/mainframe) that provides a service. For
DBMS, server is a database server
 Three components of
application logic
 1. Input – output or presentation logic component –
responsible for formatting and presenting data on the user’s
screen (or other output device) and managing user input from
keyboard (or other input device)
 2. Processing component logic – handles data processing
logic (validation and identification of processing errors),
business rules logic, and data management logic (identifies
the data necessary for processing the transaction or query)
 3. Storage component logic – responsible for data storage and
retrieval from the physical storage devices – DBMS activities
occur here
 Client/Server architectures

 File Server Architecture Client does

extensive processing
 Database Server Architecture

 Three-tier Architecture
Client does little
processing
 File server architecture
 The first client/server architectures developed
 All processing is done at the PC that requested the data, I.e. the client
handles the presentation logic, the processing logic and much of the
storage logic
 A file server is a device that manages file operations and is shared by each
of the client PCs attached to the LAN
 Each file server acts as an additional hard disk for each of the client PCs
 Each PC may be called a FAT CLIENT (most processing occurs on the
client)
 Entire files are transferred from the server to the client for processing.
 Three problems with file
server architecture
 1. Huge amount of data transfer on the network, because
when client wants to access data whole table(s) transferred to
PC – so server is doing very little work, network is
transferring large blocks of data and client is busy with
extensive data manipulation
 2. Each client is authorised to use the DBMS when a database
application program runs on that PC. Thus there is one
database but many concurrently running copies of the DBMS
(one on each active PC) – so heavy resource demand on
clients
 Three problems with file
server architecture
 3. The DBMS copy in each client PC must manage the
shared database integrity, I.e. Client DBMSs must
recognize shared locks, integrity checks, etc. So
programmers must be sophisticated to recognise various
subtle conditions that can arise in a multiple-user database
environment, as have to understand overview of
concurrency, recovery and security controls and build
these into their application
File Server Architecture

FAT
CLIENT
 Database server architectures
 After the file-server approach came two-tiered approaches
 Client is responsible for managing user interface, I/O processing logic, data
processing logic and some business rules logic (front-end programs)
 Database server performs all data storage and access processing (back-end
functions) – DBMS is only on server
 Advantages include:Clients do not have to be as powerful, only the database
server requires processing power adequate to handle the database – therefore the
server can be tuned to optimise data processing performance
 Greatly reduces data traffic on the network, as only those records (rather than
tables) that match the requested criteria are transmitted to the client
 Improved data integrity since it is all processed centrally
 Stored procedures
 These are modules of code that implement application
logic, which are included on the database server. They
have the following advantages:
 Performance improves for compiled SQL statements
 Reduced network traffic as processing moves from the
client to the server
 Improved security if the stored procedure is accessed
rather than the data and code being moved to the server
 Improved data integrity as multiple applications access the
same stored procedure
 Thinner clients (and a fatter database server)
 Stored procedures
 Have some disadvantages:
 Writing stored procedures takes more time than using
something like VB
 Proprietary nature reduces portability
 Performance degrades as number of on-line users increases

 Database server architecture

Thinn
er
client
s

DBMS only
on server
 Three-tier architectures
 In general, these include another server layer in addition to the client and database server
 This additional server may be used for different purposes
 Often application programs reside on the additional server (the application server)
 Or additional server may hold a local database whilst another server holds the enterprise database
 Often a thin client - PC just for user interface and a little application processing. Limited or no data
storage (sometimes no hard drive)
 Three-tier architecture

Thinnest
clients

Business
rules on
separate
server
DBMS only on
DB server
 Advantages of three-tier
architectures
 Scalability – middle tier can be used to reduce the load on a database
sever by using a transaction processing (TP) monitor to reduce the
number of connections to a server, and additional application servers
can be added to distribute application processing
 Technological flexibility – easier to change DBMS engines – middle
tier can be moved to a different platform. Simplified presentation
interfaces make it easier to implement new interfaces
 Long-term cost reduction – use of off-the-shelf components or services
in the middle tier can reduce costs, as can substitution of modules
within an application rather than a whole application
 Advantages of three-tier
architectures
 Better match of systems to business needs – new modules
can be built to support specific business needs rather than
building more general, complete applications
 Improved customer service – multiple interfaces on
different clients can access the same business process
 Competitive advantage – ability to react to business
changes quickly by changing small modules of code rather
than entire applications
 Challenges of three-tier
architectures
 High short-term costs – presentation component must be split
from process component – this requires more programming
 Tools, training and experience– currently lack of development
tools and training programmes, and people experienced in the
technology
 Incompatible standards – few standards yet proposed
 Lack of compatible end-user tools – many end-user tools such
as spreadsheets and report generators do not yet work through
middle-tier services (see later discussion on middleware)
 Application partitioning
 Placing portions of the application code in different locations
(client vs. server) AFTER it is written. Has the following
advantages:
 Improved performance
 Improved interoperability
 Balanced workloads across the tiers
 OO development very suitable for this
 Necessary in the Web environment, in order to achieve
desired performance in an unpredictable distributed
environment
 Parallel computer
architectures
 The ability to handle high transaction volumes, complex
queries and new data types has proven problematic in many
uniprocessor environments. But RDBMS and SQL lend
themselves to a parallel environment in 2 ways (see following
Fig.):
 1. In most queries, SQL acts as a nonprocedural set
processing language – this means that queries can be divided
into parts, each of which can then be run on a different
processor simultaneously
 2. Multiple queries can be run in parallel on parallel
processors
Query processing with parallel
processors

Parallel transactions

Parallel query
 Parallel computer
architectures
 Tightly Coupled multiprocessor systems have a common shared
memory (RAM) among all processors, and are often called
Symmetric Multiprocessing (SMP) architectures. Have some
advantages:
 Single copy of the operating system resides in the shared memory
 Bottlenecks are lessened compared to uniprocessor systems because
all processors share all tasks
 Useful for situations where data must remain in memory during
processing to achieve the desired performance level – but potential
problems of contention for the shared memory
 Parallel computer
architectures
 Loosely Coupled architectures, also called Massively Parallel
Processing (MPP) are where each CPU has its own RAM
space
 Require a copy of the operating system to be resident in each
dedicated memory
 Less problems with memory contention, allows more
scalability – easier to add nodes incrementally than SMP
 Basically applications that have large tasks that can be divided
up and worked on simultaneously that are best suited to MPP
architectures, rather than applications that can benefit from the
use of shared memory
 Parallel Computer Architectures

Tightly-coupled – CPUs share

common memory space

Loosely-coupled – CPUs each

have their own memory space
 Middleware
 Software which allows an application to interoperate with
other software, without requiring the user to understand and
code the low-level operations required to achieve
interoperability
With Synchronous systems, the requesting system waits for a
response to the request in real time
Asynchronous systems send a request but do not wait for a
response in real time – the response is accepted whenever it
is received .

The “glue” that holds client/server applications together

 Six types of middleware
 1. Asynchronous Remote Procedure Calls (RPC) - client makes calls to procedures
running on remote computers but does not wait for a response. If connection is lost,
client must re-establish the connection and send request again. High scalability but
low recovery, largely replaced by type 2
 2. Synchronous RPC – distributed program using this may call services available
on different computers – makes it possible to achieve this without undertaking
detailed coding (e.g. RMI in Java)
 3. Publish/Subscribe – often called push technology, here server monitors activity
and sends information to client when available. It is asynchronous, the clients
(subscribers) perform other activities between notifications from the server. Useful
for monitoring situations where actions need to be taken when particular events
occur.
 Six types of middleware
 4. Message-Oriented Middleware (MOM) - asynchronous – sends
messages that are collected and stored until they are acted upon,
while the client continues with other processing.
 5. Object Request Broker (ORB) - object-oriented management of
communications between clients and servers. ORB tracks the
location of each object and routes requests to each object.
 6. SQL-oriented Data Access - middleware between applications
and database servers. Has the capability to translate generic SQL
into the SQL specific to the database
 Database middleware
 ODBC – Open Database Connectivity - most DB vendors
support this
 OLE-DB - Microsoft enhancement of ODBC
 JDBC – Java Database Connectivity - Special Java classes
that allow Java applications/applets to connect to databases
 CORBA – Common Object Request Broker Architecture –
specification of object-oriented middleware
 DCOM – Microsoft’s version of CORBA – not as robust
as CORBA over multiple platforms
 Client/Server security
 Network environment has complex security issues. Networks
susceptible to breaches of security through eavesdropping,
unauthorised connections or unauthorised retrieval of packets of
information flowing round the network. Specific security issues
include:
 System-level password security – user names and passwords for
allowing access to the system. Password management utilities
 Database-level password security - for determining access privileges
to tables; read/update/insert/delete privileges
 Secure client/server communication - via encryption – but
encryption can negatively affect performance
 Database access from client
applications
 Partitioning the environment to create a two, three or n-tier
architecture means that decisions must be made about the
placement of the processing logic
 In each case, storage logic (the database engine) is handled
by the server, and presentation logic is handled by the
client
 Part a) of the following Fig. depicts some possible 2-tier
systems, placing the processing logic on the client (fat
client), on the server (thin client) or partitioned across both
the server and the client (a distributed environment)
 Database access from client
applications
 Part b) of the following Fig. Depicts a typical 3-tier
architecture and an n-tier architecture
 Some processing logic could be placed on the client if
desired
 But a typical client in a Web enabled environment will be
a thin client, using a browser for its presentation logic
 The middle tiers are typically coded in a portable language
such as Java
Processing logic distributions
a) 2-tier
Processing logic could be
at client, server, or both

Processing logic will be at

application server or Web
server

b) 3 and n-tier
 Query-by-example (QBE)
 Is the most widely available direct-manipulation database query
language
 Graphical approach, both data retrieval and data modification
can be done by entering keywords, constants and example data
into the cells of a table layout
 Available in MS Access - MS Access translates QBE to SQL and
vice versa
 Useful for end-user database programming
 Good for ad hoc processing and prototyping – but lacks
flexibility of directly coding in SQL
 Using ODBC to link external databases
stored on a database server
 Open Database Connectivity (ODBC) is an API that provides a common
language for application programs to access and process SQL databases
independent of the particular RDBMS that is accessed

Required parameters:
ODBC driver needed
Back-end server name
Database name
User id and password
 Using ODBC to link external databases
stored on a database server

 Following Fig. Shows generic ODBC architecture

 Client application requests that a connection is established
with a data source
 Driver manager identifies appropriate ODBC driver to use
 Driver selected will process the requests received from the
client and submit queries to the RDBMS in the required
version of SQL
 Java Database Connectivity (JDBC) is similar to ODBC –
built specifically for Java applications
 ODBC Architecture

Client does not need

to know anything
about the DBMS
Application Program
Interface (API) provides
common interface to all
DBMSs

Each DBMS has its own ODBC-compliant driver