What is Transparences in DDBMs?

The definition of and DDBMS defines that the system should make the distribution transparent to the user. Transparent hides implementation details from the user. For example, in a centralized DBMS, data independence is a form of transparency it hides changes in the definition and organization of the data from the user. A DDBMS may provide a various· levels of transparency. However, they all participate in the same overall objective: to make the use of the distributed database, equivalent to that of a centralized database.

We can identify four main types of transparency in a DDBMS:

• Distribution transparency

• Transaction transparency

• Performance transparency;

• DBMS transparency.

Distribution transparency

Distribution transparency allows the user to perceive the database as a single, logical entity. If add BMS exhibits distribution transparency, then the user does not need· to know the data is fragrances (fragmentation transparency) or the location of data items (Local transparency).

Distribution transparency can be classified into:

• Fragmentation transparency

• Location transparency

• Replication transparency

• Local Mapping transparency

• Naming transparency

Fragmentation transparency

Fragmentation is the highest level of distribution transparency. If fragmentation transparency is provided by the DDBMS, then the user does not need to know that the data is fragmented, As a result, database accesses are based on the global schema,. so the user does not need to specify fragment names or data locations.

Location transparency

Location is the middle level of distribution transparency. With location transparency, the user must know how the data has been fragmented but still does not have to know the location of the data.

Replication transparency

Closely related to location transparency is replication transparency, which means that the user is unaware of the replication of fragments. Replication transparency is implied’ by location transparency.

Local mapping transparency

This is the lowest level of distribution transparency. With local mapping transparency, user needs to specify both fragment names and the location of data items, taking into consideration any replication that may exists.

Clearly, this is a more complex and time-consuming query for the user to enter than the first. It is unlikely that a system that provides only this level of trasparency would be acceptable to end-users.

Naming transparency

As a corollary to the above distribution transparencies, we have naming transparency.

As in a centralized database, each item in a distributed database must. have a unique name. Therefore, the DDBMS must ensure that no two sites create a database object with the same name. One solution to this problem is to create a central name server, which has the responsibility for ensure uniqueness of all names in the system. However, this approach results in:

• Loss of some local autonomy;

• Perfoffi1ance problems, if the central site becomes a bottleneck;

• Low availability; .if the central site fails the remaining sites cannot create any .new database objects.

An alternatively solution is to prefix an object , with the identifier of the site that created it For example, the relation branch created at site S1 might be named S1.Branch. Similarly, we need to be able to identify each fragment and each of its copies. ·Thus, copy 2 of fragment 3 of the Branch relation created at site 81 might be referred to as SI.Branch.F3.C2. However, this results in loss of distribution transparency.

An approach that resolves the problems with both these solution uses aliases (sometimes called synonyms) for each database object. Thus, S I.Brauch.F3 .C2 might be known as Local Branch by the user at site 51. The DDBMS has the task of mapping an alias to the appropriate database object.

Transaction Transparency

Transaction transparency in a DDBMS environment ensures that all distributed transactions maintain the· distributed database’s integrity and consistency. A distributed transaction accesses data stored at· mote than one location. Each transaction is divided into a number of sub transactions one for each site that has to be accessed; a sub transaction is represented by an agent.

The DDBMS must also ensure the atomicity of each sub transaction. Transaction transparency in a distributed DBMS is complicated by the fragmentation, allocation and replication schemas.

Performance Transparency

Performance transparency requires a DDBMS to perform as if it were a centralized DBMS. In a distributed environment, the system should suffer any performance degradation due to the distributed architecture, for example the presence of the network Performance transparency also requires the DDBMS to determine the most cost-effective strategy to execute a request.

In a centralized DBMS, the query processor (QP) must evaluate every data request and find an optimal execution strategy, consisting of an ordered sequence of operations on the database. In a distributed environment, the distributed query processor (DQP) maps a data request into an ordered sequence of operations on the local databases. It has the added complexity of taking into account the fragmentation, replication and allocation schemas. The DQP has to decide:

• Which fragment to access?

• Which copy of fragment to use, if the fragment is replicated?

• Which location to use.

The DQP produces an execution strategy that is optimized with respect to some cost function. Typically, the costs associated with a distributed request include:

• The access time (I/O) cost involved in accessing the physical data on disk;

• The CPU time cost incurred when performing operations on data in main memory;

• The communication cost associated with the transmission of data across the network.

The first two factors are the only ones considered in a centralized system. In· a distributes environment, the DDBMS must take account of the communication cost, which may be the most dominant factor in WANs with a bandwidth of a few kilobytes per second. In such cases, optimization may ignore I/O and CPU costs. However, LANs have a bandwidth comparable to that of disks, so in such cases optimization should not ignore I/O and CPU costs entirely.

DBMS Transparency

DBMS transparency hides the knowledge that the local DBMSs may be different, and is therefore only applicable to heterogeneous DDBMSs. It is one of the most difficult transparencies to provide as a generalization.