|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:
There are various possible combinations
of these three but probably the most important are:
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.
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.
Global directory issues
- 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