DISTRIBUTED DATABASE SYSTEMS - Database Design and Development: An Essential Guide for IT Professionals - page 553

Functions and Features As a starting point, a DDBMS must have the features
and functions of a regular database management system. In addition, a DDBMS is
responsible for keeping track of the data allocations, routing data access requests
to appropriate sites, and transmitting results correctly to the requesting sites.
Here is a summary of the additional functions and features of a DDBMS:
• Enable data fragmentation and allocation to different sites
• Extend system catalog or data dictionary functions to keep track of how data
are distributed
• Manage distributed query processing including query optimization, translation
of data access requests between sites, and routing of requests and results
• Manage distributed transaction processing including translation of data
access requests between sites, routing of requests, and processing of database
operations
• Provide concurrency control to maintain consistency of data replicated in
multiple locations
• Provide locking and resolve deadlocks in a multisite database system
• Provide distributed database recovery from failures of individual sites and data
communication links
Catalog Management As you know, the data dictionary, also known as the system
catalog or system directory, holds information for the system to translate high-level
requests for database objects from queries and transactions into appropriate low-
level operations to be executed on physical data items. Usually, the system catalog
in a DBMS contains the usual schema information, security authorizations, statisti-
cal data, programs, integrity constraints, and so on.
This type of information in a system catalog, although useful, is hardly sufficient
in a distributed database environment. The system ought to know how database
relations are fragmented and which parts of the relations reside where. For a given
database object, the system catalog must record at which site or multiple sites the
object is stored. The catalog must also enable the system to refer to the object using
the correct name, taking into consideration the site where it was created and where
it is stored now.
We will consider two fundamental issues about catalog management: where to
keep the catalog and how to name the database objects. First, about the placement
of the catalog, a few possible approaches are indicated:
At a central site. Only one copy exists in the system, and that is held at a single
central site. All sites other than where the catalog is kept do not have full auton-
omy. Each site will have to inform the central site of any schema changes relating
to local data at the site. Even for referring to local data at the sites, they have to go
to the central site. Another more serious concern: What happens when the central-
ized site goes down? The catalog will become unavailable, virtually halting all data-
base operations.
Full catalog at all sites. A full copy of the catalog is kept at every site. This approach
addresses the vulnerability of losing the whole catalog when the central site goes