RelationalDBDesign 





Network Topology   «Prev 

Local Database Autonomy

Local autonomy means that all the data in the distributed network is owned and managed locally. For example, a site in New York might have a remote database that participates in a national distributed system. While functioning as a part of the distributed network, the New York database continues to process local operations independently from the overall distributed system, and does not rely on the distributed system to function. Oracle enables this feature in Net8 by allowing each database to function independently from other "linked" databases.
Various other distributed database methods and implementation techniques exist. Some of these methods are local autonomy, synchronous and asynchronous distributed database technologies where the technology behind them does not depend on the business needs or confidentiality of the data which will be placed inside the database.

Database Autonomy
Distributed Database
To satisfy the local autonomy rule, a database that participates in a distributed system must be fully functional regardless of whether it is able to contact remote database locations. In addition, the data that resides with each participating database belongs to that database, in the sense that
  1. data integrity,
  2. security, and
  3. management
are independent of the other sites that may be accessing or supplying the data.


Local autonomy requires that an individual database be fully functional even if it cannot contact other systems in the distributed environment and that each site be responsible for its own data integrity, security, and management. Unfortunately, it is not possible to attain both local autonomy and location transparency, because the latter goal requires 100% availability of data at a remote location.
Location transparency implies reliance on a network connection and the availability of a remote database. Oracle introduced snapshots in Oracle7 as a way to make remote data accessible in the local database. A snapshot is essentially a local copy of a remote table, which (in theory) can be refreshed as often as once per second. (This frequency is only in theory because, for one thing, it may take more than one second to refresh the snapshot.) As an example, the database administrator at the sales site of the fictitious Bigwheel Bicycle company could make a snapshot of the PRODUCTS table from the headquarters site as follows:
CREATE SNAPSHOT products
REFRESH FAST
START WITH SYSDATE
NEXT TRUNC(sysdate+1)
AS
SELECT product_id, product_name
FROM products@PHQS.BIGWHEEL.COM;

This snapshot stores the contents of the headquarters PRODUCTS table in the local sales database and refreshes the contents of the table every day at midnight.