Distributed DBMS architecture
Multiple databases may be put together in several ways so that they are shared by multiple DBMSs. The three major characteristics that need to be considered are:
  • autonomy
  • distribution
  • heterogeneity

There are various possible combinations of these three but probably the most important are:
o the client/server system, where there is little autonomy or heterogeneity and only some degree of distribution,
o the homogeneous peer-to-peer system, where there is more distribution than with the client/server system
o the heterogeneous peer-to-peer system
o the multi-database systems where there is much more autonomy than in the others.

Note that in saying there is little autonomy in these systems we are considering tightly integrated systems where the user has a single image of the entire database and in which the data managers do not typically operate as independent DBMSs even though they may have the functionality to do so.

The architecture of these has already been considered - there is usually a global
conceptual schema, local conceptual schemas and a global dictionary/directory.
These systems are logically integrated and provide a single image of the database.

More difficult to set up are systems which provide interoperability between among a set of different DBMSs. There is no space to consider this fully here but a few points are worth mentioning. If several DBMSs are to be conceptually integrated to form a single definition of a multidatabase, it will be necessary to start from the bottom and translate the component database schemas into a common representation. Problems that will arise include differences in the meaning and naming of data items -particularly synonyms and homonyms. There may also be structural conflicts such as type conflicts - where an object may be represented by an attribute in one schema and by an entity in another - or key conflicts, where different candidate keys are available and different primary keys are selected in different schemas.

Multi-database systems
These systems typically have full autonomy and some distribution and heterogeneity. The component databases that make up the MDBS are distributed over a number of sites. The multidatabase management system (multi-DBMS) is the sofiware that provides for the management of this collection of autonomous databases and transparent access to it. The organisation and management of a distributed MDBS is quite different from that of a distributed DBMS. The global conceptual schema represents only the collection of some of the local databases that each local DBMS wants to share, instead of being a conceptual view of the entire database. Thus, the global DB is only a subset of the union of local databases. There may not even be a global schema for a MDBS.
An example of an MDBS is Multibase, which is now quite old. However, research into multidatabase systems is relatively new and many problems remain to be sorted out.

Global directory issues
For those distributed databases with a global schema, a global directory is necessary.
It may be maintained centrally at one site or it may be distributed over a number of
Problems with a central directory include:

- Bottle Necks

Problems with a distributed directory include:

- Loss of access if a communications link goes down.

Replication is typically the answer Advantages:

- Greater reliability

Disadvantages include the difficulty of maintaining the directory up-to-date.

- Data integrity