CLIENT/SERVER DATABASE AND DISTRIBUTED DATABASE - Fundamentals of Database Management Systems - page 323

ASIA

Tokyo

EUROPE

ARCTIC
OCEAN D E

F

GREENLAND
(DEN.)

U.K. Paris

AFRICA

CANADA

NORTH AMERICA

A B

PACIFIC
OCEAN

ATLANTIC
OCEAN

New York

UNITED STATES

Los Angeles

C

Memphis

Gulf of
Mexico

MEXICO

Caribbean
Sea

SOUTH AMERICA

F I G U R E 12.6
Distributed database with no data
replication

Clearly, the simple dispersal of database tables as shown in Figure 12.6 is of limited
benefit.
Let's introduce a new option into the mix. Suppose that we allow database
tables to be duplicated—the term used with distributed database is ''replicated''—at
two or more sites on the network. There are several clear advantages to this idea,
as well as, unfortunately, a couple of disadvantages. On the plus side, the first
advantage is availability. If a table is replicated at two or more sites and one of
those sites goes down, everyone everywhere else on the network can still access the
table at the other site(s). Also, if more than one site requires frequent access to a
particular table, the table can be replicated at each of those sites, again minimizing
telecommunications costs during data access. And copies of a table can be located
at sites having tables with which it may have to be joined, allowing the joins to take
place at those sites without the complexity of having to join tables across multiple
sites. On the down side, if a table is replicated at several sites, it becomes more of
a security risk. But the biggest problem that data replication introduces is that of
concurrency control. As we have already seen, concurrency control is an issue even
without replicated tables. With replicated tables, it becomes even more complex.
How do you keep data consistent when it is replicated in tables on three continents?
More about this issue later.
Assuming, then, that data replication has some advantages and that we are
willing to deal with the disadvantages, what are the options for where to place the