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

down. However, this does not solve the local autonomy problem. Every change to
a local catalog must be broadcast to all sites.

Partial catalog at every site. Each site is responsible for its own data; each site
maintains its own catalog for the local data. In this case, the total catalog is the union
of all partial catalogs maintained at all the sites. This option provides site autonomy.
For operations on local data, it works well. However, for requests for global data,
the system must go to other sites to get the catalog entries.

Optimal approach. This is a combined approach that removes the vulnerability of
a central site and also ensures site autonomy. Each site maintains the catalog for
the local data. The catalog at the birth site of a relation, that is, where the relation
was created, keeps track of where copies of the relation are held and also precise
details of what parts of the relation are held at these other sites.
Now, let us look at the issue of naming database objects. Consider a relation
called CUSTOMER. In a centralized database, there can be only one relation with
that name. However, in a distributed database system, it is possible for two or more
sites to have objects called CUSTOMER whose contents and purpose may not be
same. If the CUSTOMER relation at a given site is kept purely local and private,
then no other site will be referring to that relation. However, as you can imagine,
in a distributed environment users in many sites would want to share the informa-
tion contained in the CUSTOMER relation. So how do you name business objects?
How does the DDBMS know which CUSTOMER table is required?
Database objects are assigned names with four components:

Creator Id ID of user who created the database object (user ID unique

within the site)

Creator Site Id ID of site at which object was created (sites have unique IDs

across entire system)

Local Name name of object assigned by creator (unique within objects of

this type created by this user at the birth site)

Birth Site Id ID of site at which object is initially stored (sites have unique

IDs across entire system)

Here is an example of an object following these principles:

MILLER @ MUNICH - ORDER @ PARIS

The name refers to the database object with the local name ORDER created
by MILLER of the MUNICH site, with ORDER stored initially at the PARIS
site.
How does a user refer to this object in a query? The user at a given site may refer
to the object using the global name with all four of its components. As you know,
this is cumbersome; you cannot expect users to refer to objects by their global
names. The general practice is to define a synonym for the global name of the object.
Each site will maintain a set of synonym tables for users at that site. If MARY at
the LONDON site needs to refer to the above ORDER relation, an entry will be