Date's Twelve Rules for Distributed Database Systems - Fragmentation independence

Date's Twelve Rules for Distributed Database Systems - Fragmentation independence / Fragmentation Transparency

5. Fragmentation independence (Fragmentation Transparency)

Data fragmentation is transparent to the user. The user does not need to know the name of the database fragment in order to retrieve them.

For example, assume that the table Emp is fragmented into three fragments and stored in Chennai, Mumbai, and New Delhi sites. Assume a user query that demands for data from Chennai site Emp table. The name of the Emp table at Chennai site may be Chennai.Emp, at Mumbai site may be Mumbai.Emp, and at New Delhi site may be Newdelhi.Emp. According to the fragmentation independence rule, the name of the table at different sites should be hidden from the end user. Hence, user needs to request data differently from what does the system interprets.

User view. [What does the user see?]

In figure 1, user request for data from Emp table with certain conditions;

The user query : SELECT * FROM Emp WHERE condition;

Figure 1 - User view

System view. [How does the system interpret?]

The DDBS should interpret the query and find the exact fragment and location of data, accordingly it will translate the query as follows;

System translated query : SELECT * FROM Chennai.Emp WHERE condition;

Figure 2 shows the system translated query reaching the right fragment at the right site.

 

Figure 2 - System interpretation

Date's Twelve Rules for Distributed Database Systems - Continuous operation

Date's Twelve Rules for Distributed Database Systems - Continuous operation

3. Continuous operation

• The whole system should be able to continue function even in the case of a node/site failure. The major advantage of a distributed database system is the reliability and availability. The continuous operation objective is much needed to attain this advantage.

• The failure of any site should not disturb the function of other alive sites.

Date's Twelve Rules for Distributed Database Systems - Location independence

Date's Twelve Rules for Distributed Database Systems - Location independence

4. Location independence (Location Transparency)

The end users and even application programmers need not know where the data are physically stored. Location independence objective insists the hiding of location detail of the data from the end users. This provides the security to the data. Also, this should give a feeling to the users that all data were stored at a local central site.

For example, consider the figures given below;

According to figure 1, the data are available at Chennai, Mumbai, and New Delhi (different locations). User A, who is near to Mumbai site, is trying to access data. Assume that the requested data is available at Chennai site. For user A, the data access should give a feel like the figure 2. That is, the data available centrally at user’s location (say, Mumbai site, in our case). Observe the difference between two images.

Figure 1 - Actual request of user A reaches Mumbai site

Figure 2 - For User A, the site details are hidden. User does not aware of multiple sites.

Date's Twelve Rules for Distributed Database Systems - No reliance on a central site

Date's Twelve Rules for Distributed Database Systems - No reliance on a central site rule

2. No reliance on a central site

There should not be a central site concept for some central service. The major drawbacks of central server concept are Bottleneck and Single Point of Failure. Both are vulnerable for a system to continue to function. These can be avoided if we insist ‘No reliance on a central site’.

For example, the sites/servers at different locations Chennai, Mumbai, and New Delhi are capable of handling transactions, handling locks, coordinating transactions initiated at that site. That means, all the sites having the components Transaction manager and transaction coordinator to handle transactions efficiently without depend on other single site as central site.

Distributed database on several sites over the network