Transaction Transparency

Transaction transparency is a DDBMS property that ensures that database transactions will maintain the distributed database’s integrity and consistency. A distributed transaction accesses data stored at more than one location. Transaction transparency ensures that the transaction will be completed only when all database sites involved in the transaction complete their part of the transaction. Two further aspects of transaction transparency: concurrency transparency and failure transparency.

1. Concurrency Transparency

Concurrency transparency is provided by the DDBMS if the results of all concurrent transactions (distributed and non-distributed) execute independently and are logically consistent with the results that are obtained if the transactions are executed one at a time, in some arbitrary serial order. Concurrency transparency requires that concurrent processes can share objects without interference. It allows multiple users of a distributed system to compete for access to a resource and perform actions concurrently on the resource without any of the users knowing about it.

2. Failure Transparency

Given all of the things that a distributed system must hide from its users, there is one aspect that is just sometimes beyond anyone’s control: parts of a system failing. Even in a single system, failure is possibility; in a distributed system — which has so many more moving parts working together as once — failure is just a reality.

Failure transparency allows for an end user of a distributed system to continue using the system and accessing any resource without noticing that part of the system has failed. The failures in a distributed system are also referred to as the faults of the system.

12 Rule’s For a DDBMS

1. Local Autonomy

The sites in a distributed system should be autonomous. In this context, autonomy means that:

· With local autonomy, each site has the capability to control local data, administer security, and log transactions and recover when local failures occur and to provide full access to local data to local users when any central or coordinating site cannot operate. Data at local sites are owned by that site itself.

· local data is locally owned and managed;

· local operations remain purely local;

· all operations at a given site are controlled by that site.

2. No reliance on a central site

There should be no one site without which the system cannot operate. This implies that there should be no central servers for services such as transaction management, deadlock detection, query optimization, and management of the global system catalog.

3. Continuous operation

Ideally, there should never be a need for a planned system shutdown, for operations such as: n adding or removing a site from the system; n the dynamic creation and deletion of fragments at one or more sites.

4. Location independence

Location independence is equivalent to location transparency. The user should be able to access the database from any site. Furthermore, the user should be able to access all data as if it were stored at the user’s site, no matter where it is physically stored.

5. Fragmentation independence

Data fragmentation is transparent to the user. The user should be able to access the data, no matter how it is fragmented. The user does not need to know the name of the database fragment in order to retrieve them. But from system view, the DDBS should interpret the query and find the exact fragment and location of data.

6. Replication independence

The user should be unaware that data has been replicated. Thus, the user should not be able to access a particular copy of a data item directly, nor should the user have to specifically update all copies of a data item.

7. Distributed query processing

The system should be capable of processing queries that reference data at more than one site.

8. Distributed transaction processing

The system should support the transaction as the unit of recovery. The system should ensure that both global and local transactions conform to the ACID rules for transactions, namely: atomicity, consistency, isolation, and durability.

9. Hardware independence

It should be possible to run the DDBMS on a variety of hardware platforms.

10. Operating system independence

As a corollary to the previous rule, it should be possible to run the DDBMS on a variety of operating systems.

11. Network independence

Again, it should be possible to run the DDBMS on a variety of disparate communication networks.

12. Database independence

It should be possible to have a DDBMS made up of different local DBMSs, perhaps supporting different underlying data models. In other words, the system should support heterogeneity. The last four rules are ideals. As the rules are so general, and as there is a lack of stand- ards in computer and network architectures, we can expect only partial compliance from vendors in the foreseeable future.

Reference

Connolly, T.M. and Begg, C.E. (2005) Database Systems: A Practical Approach to Design, Implementation, and Management. 4th Edition, Pearson Education, Harlow.