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 andasynchronous 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.

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 in a distributed network means each database is like that one friend who insists on doing everything themselves. They're part of the group, but they've got their own thing going on. Each site in the network has its own data, its own rules, and it manages its own little world without asking anyone else's permission. This means that if one site is down for maintenance or having a bad day, the rest of the network can still function independently. It's like a group of friends who can hang out together, but also have their own hobbies and interests. Each site in the network is responsible for its own data integrity, security, and management. So, in a nutshell, local autonomy is all about each site in the network doing its own thing, while still being part of the gang.

• 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.