Transparencies in DBMS

Transparencies in DBMS means a DBMS system should offers a transparent distribution to the user. In other words, it hides implementation detail from the user. There are 4 kinds of transparency: distribution transparency, transaction transparency, performance transparency, and the DBMS transparency itself. A DBMS transparency is heterogenous, which means it is only applicable to any heterogenous DBMS which allows user integration in a global schema. It is one of the most difficult transaprencies to apply as a generalization.

The distribution transparency consists of five classifications:

1. Fragmentation transparency

This is the highest level in distribution transparency. It enables user to query upon any tables as if they’re already fragmented. It hides the fact that the tables queried is actually a fragment or a union of some fragments. In other words, the user doesn’t know whether the tables are fragmented or not. As a result, database accesses are all based on global schema, so the user doesn’t need to specify fragment names or data locations.

2. Location transparency

Location transparency is the middle level in distribution transparency. It ensures the user to query on any tables or fragments as if they were stored on the user’s site locally. With this kind of transparency, the user must know how the data has been fragmented. However, they don’t know the location of the data. In order to incorporate location transparency, a DBMS should have access to update date dictionary and have a directory which contains the details of data location.

3. Replication transparency

In replication transparency, the user is unaware of the fragments replication. It enables users to query upon a table as if only a single copy of the table exists. Replication transparency is associated with concurrency transparency and failure transparency. When a user updates a data item, the update is reflected in all copies of the table. Replication transparency is also implied by location transparency.

4. Local mapping transparency

The lowest level in distribution transparency. In this kind of transparency, a user needs to specify both fragment names and the location of data items, taking into consideration in any replication that may exists.

5. Naming transparency

In naming transparency, each item in a database should have an unique name. A DBMS must ensure that no two sites create a databse with a same name. But if that’s not necessary, there is one solution: to create central name server. However, this can be results in loss of some local autonomy, central site may

become a bottleneck, and if a central site fails, remaining sites can’t create any new objects. In order to reduce those problems, there’s an alternative solution: prefix objects with identifier that created it. For example, Branch created at site S1 should be named as S1.BRANCH.

Also, we need to identify each fragment and its copies. If there is copy 2 of fragment 3 of Branch created at site S1, it should be named as S1.BRANCH.F3.C2. Thus, this name can be known as LocalBranch by user at S1, by using aliases on each database object.

Transaction transparency in a DBMS ensures that all distributed transactions maintain distributed databases’ integrity and consistency. Distributed transaction accesses data stored at more than one location. Each transaction is divided into a number of subtransactions, one for each site that has to be accessed, and a sub-transaction is represented an agent. The DBMS must also ensure the indivisibility of both the global transactions and each of the sub-transactions. Transaction transparency in distributed DBMS is complicated by the fragmentation, allocation, and replication schemas.

Lastly, the performance transparency requires a DBMS to perform as if it were a centralized DBMS. This allows the system to reconfigured in a migration and replication transparency. In a distributed environment, the system should suffer any performance degradation due to its distributed architecture. In performance transparency, a transaction must display durability, which are all changes that have been stored permanently in a database, but must not be lost in the event of any type of failure. Distributed transactions have to add the complexity of having access and update data storages in many different location. All sites involved in the transaction must complete their component before the transaction results can be stored permanently.

Source:

http://ecomputernotes.com/database-system/adv-database/transparences-in-ddbms https://www.tutorialspoint.com/distributed_dbms/distributed_dbms_distribution_transparency.htm https://www.ques10.com/p/5098/transparencies-in-distributed-data-base-1/?