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

Unit 1.4 - Database System Architecture

Uploaded by

RashmiRavi Naik
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
28 views

Unit 1.4 - Database System Architecture

Uploaded by

RashmiRavi Naik
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

CHAPTER

17
Database-System Architectures
The architecture of a database system is greatly influenced by the underlying
computer system on which it runs, in particular by such aspects of computer
architecture as networking, parallelism, and distribution:

• Networking of computers allows some tasks to be executed on a server system


and some tasks to be executed on client systems. This division of work has
led to client–server database systems.
• Parallel processing within a computer system allows database-system activi-
ties to be speeded up, allowing faster response to transactions, as well as more
transactions per second. Queries can be processed in a way that exploits the
parallelism offered by the underlying computer system. The need for parallel
query processing has led to parallel database systems.
• Distributing data across sites in an organization allows those data to reside
where they are generated or most needed, but still to be accessible from other
sites and from other departments. Keeping multiple copies of the database
across different sites also allows large organizations to continue their database
operations even when one site is affected by a natural disaster, such as flood,
fire, or earthquake. Distributed database systems handle geographically or ad-
ministratively distributed data spread across multiple database systems.

We study the architecture of database systems in this chapter, starting with


the traditional centralized systems, and covering client–server, parallel, and dis-
tributed database systems.

17.1 Centralized and Client– Server Architectures


Centralized database systems are those that run on a single computer system
and do not interact with other computer systems. Such database systems span
a range from single-user database systems running on personal computers to
high-performance database systems running on high-end server systems. Client
Chapter 17 Database-System Architectures

–server systems, on the other hand, have functionality split between a server
system and multiple client systems.

17.1.1 Centralized Systems


A modern, general-purpose computer system consists of one to a few processors
and a number of device controllers that are connected through a common bus that
provides access to shared memory (Figure 17.1). The processors have local cache
memories that store local copies of parts of the memory, to speed up access to data.
Each processor may have several independent cores, each of which can execute
a separate instruction stream. Each device controller is in charge of a specific
type of device (for example, a disk drive, an audio device, or a video display).
The processors and the device controllers can execute concurrently, competing
for memory access. Cache memory reduces the contention for memory access,
since it reduces the number of times that the processor needs to access the shared
memory.
We distinguish two ways in which computers are used: as single-user systems
and as multiuser systems. Personal computers and workstations fall into the first
category. A typical single-user system is a desktop unit used by a single person,
usually with only one processor and one or two hard disks, and usually only one
person using the machine at a time. A typical multiuser system, on the other
hand, has more disks and more memory and may have multiple processors. It
serves a large number of users who are connected to the system remotely.
Database systems designed for use by single users usually do not provide
many of the facilities that a multiuser database provides. In particular, they may
not support concurrency control, which is not required when only a single user
can generate updates. Provisions for crash recovery in such systems are either
absent or primitive—for example, they may consist of simply making a backup
of the database before any update. Some such systems do not support SQL, and
they provide a simpler query language, such as a variant of QBE. In contrast,

mouse keyboard printer monitor


disks on-line

disk graphics
CPU USB controller
controller adapter

memory

Figure 17.1 A centralized computer system.


17.1 Centralized and Client – Server Architectures

database systems designed for multiuser systems support the full transactional
features that we have studied earlier.
Although most general-purpose computer systems in use today have multiple
processors, they have coarse-granularity parallelism, with only a few processors
(about two to four, typically), all sharing the main memory. Databases running
on such machines usually do not attempt to partition a single query among the
processors; instead, they run each query on a single processor, allowing multiple
queries to run concurrently. Thus, such systems support a higher throughput;
that is, they allow a greater number of transactions to run per second, although
individual transactions do not run any faster.
Databases designed for single-processor machines already provide multitask-
ing, allowing multiple processes to run on the same processor in a time-shared
manner, giving a view to the user of multiple processes running in parallel. Thus,
coarse-granularity parallel machines logically appear to be identical to single-
processor machines, and database systems designed for time-shared machines
can be easily adapted to run on them.
In contrast, machines with fine-granularity parallelism have a large num-
ber of processors, and database systems running on such machines attempt to
parallelize single tasks (queries, for example) submitted by users. We study the
architecture of parallel database systems in Section 17.3.
Parallelism is emerging as a critical issue in the future design of database
systems. Whereas today those computer systems with multicore processors have
only a few cores, future processors will have large numbers of cores.1 As a re-
sult, parallel database systems, which once were specialized systems running on
specially designed hardware, will become the norm.

17.1.2 Client– Server Systems


As personal computers became faster, more powerful, and cheaper, there was
a shift away from the centralized system architecture. Personal computers sup-
planted terminals connected to centralized systems. Correspondingly, personal
computers assumed the user-interface functionality that used to be handled di-
rectly by the centralized systems. As a result, centralized systems today act as
server systems that satisfy requests generated by client systems. Figure 17.2 shows
the general structure of a client–server system.
Functionality provided by database systems can be broadly divided into two
parts—the front end and the back end. The back end manages access structures,
query evaluation and optimization, concurrency control, and recovery. The front
end of a database system consists of tools such as the SQL user interface, forms
interfaces, report generation tools, and data mining and analysis tools (see Fig-
ure 17.3). The interface between the front end and the back end is through SQL,
or through an application program.

1 The reasons for this pertain to issues in computer architecture related to heat generation and power consumption.

Rather than make processors significantly faster, computer architects are using advances in chip design to put more
cores on a single chip, a trend likely to continue for some time.
Chapter 17 Database-System Architectures

client client client client

network

server

Figure 17.2 General structure of a client– server system.

Standards such as ODBC and JDBC, which we saw in Chapter 3, were developed
to interface clients with servers. Any client that uses the ODBC or JDBC interface
can connect to any server that provides the interface.
Certain application programs, such as spreadsheets and statistical-analysis
packages, use the client–server interface directly to access data from a back-end
server. In effect, they provide front ends specialized for particular tasks.
Systems that deal with large numbers of users adopt a three-tier architecture,
which we saw earlier in Figure 1.6 (Chapter 1), where the front end is a Web
browser that talks to an application server. The application server, in effect, acts
as a client to the database server.
Some transaction-processing systems provide a transactional remote proce-
dure call interface to connect clients with a server. These calls appear like ordi-
nary procedure calls to the programmer, but all the remote procedure calls from a
client are enclosed in a single transaction at the server end. Thus, if the transaction
aborts, the server can undo the effects of the individual remote procedure calls.

You might also like