12.5 Transparency
Ideally, the distribution in a DDBS should be transparent to the user, whose interaction with the database should be like that provided by a single, centralized database. Forms of transparency that are desirable are as follows:
Data distribution transparency. This type of transparency can take several forms. The user should not have to know how the data is fragmented, which is a property called fragmentation transparency. Users should be unaware of the actual location of the data items they access, which is a property called location transparency. If data is replicated, users should also be unaware of the fact that multiple copies exist, which is a property called replication transparency. To support these properties, it is essential that data item names be unique. In a centralized system, it is easy to verify uniqueness. However, in a distributed system, it can be difficult to ensure that no two sites use the same name for different data items. It is possible to guarantee systemwide uniqueness of names if each data item name has a prefix that is the identifier of the site where the item originated, called the birth site. Often the URL of the site is used. However, this technique compromises location transparency. The problem can be solved by using aliases for data items, which the system can then map to the composite name. Another approach is to have a name server where all names are checked for uniqueness and registered. However, the server might become a bottleneck, compromising performance. Furthermore, if the server fails, the entire system is affected.
DBMS heterogeneity transparency. Users who need to access data from a remote site with a different DBMS from their local one should not know they are using a different DBMS. Their queries should be submitted in the language that they normally use. For example, if users of an Oracle relational database also need to access an InterSystems Iris object database at a remote site, they should be able to express SQL queries for the remote data. The distributed system should take care of any translations needed.
Transaction transparency. The system must guarantee concurrency transparency, which ensures that concurrent transactions do not interfere with one another. It must also provide recovery transparency, handling systemwide database recovery. Traditional databases use the ACID properties as criteria for transaction management. The essential characteristics of the ACID properties must be enforced for distributed transactions. These issues will be examined further in Section 12.6. The ACID properties of transactions are discussed in Chapter 11.
Performance transparency. A DDBS should deliver performance that is comparable to one using a centralized architecture. For example, a query optimizer should be used to minimize response time for distributed queries, so that users do not have to wait too long for results. This issue will be discussed in Section 12.7.