BlueAdmiral.com |
![]() |
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. Peer-to-peer 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 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
|