Distributed DBMS - Database Environments

Distributed DBMS - Database Environments

We will research the different aspects that help in developing distributed database environments in this part of the tutorial. The types of distributed databases begin in this chapter. Distributed databases can be classified into homogeneous and heterogeneous databases having further divisions. The next section of this chapter identifies client-server, peer-to - peer and multi-DBMS distributed architectures. Finally, it incorporates various design alternatives such as replication and fragmentation.

Types of Distributed Databases

As seen in the following example, distributed databases can be divided generally into homogeneous and heterogeneous distributed database environments, each with further sub-divisions.

Homogeneous Distributed Databases

All of the sites use similar DBMS and operating systems in a homogeneous distributed database. Its features are −

• The sites use software which is very similar.
• The sites use the same DBMS or DBMS from the same provider.
• In order to process user requests, each site is aware of all other sites and cooperates with other sites.
• The database is accessed via a single interface as if it is a single database.

Types of Homogeneous Distributed Database

There are two types of distributed homogeneous database −

• Autonomous:Each database operates on its own and is autonomous. A controlling application integrates them and uses message passing to share data updates.
• Non-autonomous:Data is distributed across homogeneous nodes and data updates are organised across the sites by a central or master DBMS.

Heterogeneous Distributed Databases

Different sites include various operating systems, DBMS products and data models in a heterogeneous distributed database. Its features are −

• Similar schemas and software are used by various sites.
• A variety of DBMSs such as relational, network, hierarchical or object-oriented may comprise the system.
• Due to dissimilar schemas, query processing is complex.
• Due to dissimilar software, transaction processing is complex.
• A site may not be aware of other sites, so there is limited cooperation in the processing of requests from users.

Types of Heterogeneous Distributed Databases

• Federated-Heterogeneous database systems are independent nature and integrated together to function as a single system of databases.
• Un-federated-The database systems use a central coordinating module from which the databases are accessed.

Distributed DBMS Architectures

Depending on three parameters, DDBMS architectures are generally developed -

• Distribution-Specifies the physical distribution of data across various sites.
• Autonomy-It shows the distribution of database system control and the degree to which each constituent DBMS can operate independently.
• Heterogeneity −It refers to the uniformity or dissimilarity of the data models, system components and databases.

Architectural Models

Some of the common architectural models are −

• Client - Server Architecture for DDBMS
• Peer - to - Peer Architecture for DDBMS
• Multi - DBMS Architecture

Client - Server Architecture for DDBMS

This is an architecture with two levels where the functionality is split into servers and clients. Data management, query processing, optimization and transaction management are mainly part of the server functions. Client features primarily include the user interface. They have certain functions, however, such as consistency checking and transaction management.

The server architecture of the two different clients is-

• Single Server Multiple Client
• Multiple Server Multiple Client

Peer- to-Peer Architecture for DDBMS

Each peer acts both as a client and a server in these systems for the provision of database services. Peers share their resources and coordinate their activities with other peers.

Generally, this architecture has four schemas levels.

• Global Conceptual Schema-Depicts the logical global view of information.
• Local Conceptual Schema-Represents the organization of logical data at each site.
• Local Internal Schema- Represents the organization of physical data at each site.
• External Schema − Represents the data view of the user.

Multi - DBMS Architectures

This is an integrated system of databases formed by a collection of two or more autonomous systems of databases.

Six levels of schemas can express Multi-DBMS-

• Multi-database View Level − Represents multiple user views that consist of subsets of the distributed integrated database.
• Multi-database Conceptual Level- Reflects an integrated multi-database containing global concepts of the logical multi-database structure.
• Multi-database Internal Level- Represents the distribution of data to local data mapping across different sites and multi-database.
• View Level Local Database− Represents the public view of local data.
• Local database Conceptual Level- Reflects the organization of local data site
• Internal Level of the local database- Reflects the organization of physical data at each site.

There are two design alternatives for multi-DBMS −

• Model with multi-database conceptual level.
• Model without multi-database conceptual level.

Design Alternatives

The alternatives for distribution design for the tables in a DDBMS are as follows-

• Non-replicated and non-fragmented
• Fully replicated
• Partially replicated
• Fragmented
• Mixed

Non-replicated & Non-fragmented

In this design alternative, different tables are placed at different sites. Data is placed in such a way that it is close to the site where it is used most. For database systems where the percentage of queries necessary to enter data in tables placed at different sites is low, it is most suitable. If an appropriate distribution strategy is adopted, then during data processing, this design alternative helps to reduce the cost of communication.

Fully Replicated

In this design alternative, one copy of all the database tables is stored at each site. Because each site has its own copy of the entire database, queries require negligible communication costs to be very quick. On the contrary, during update operations, the massive redundancy in data requires huge costs. Hence, this is suitable for systems where a large number of queries is required to be handled whereas the number of database updates is low.

Partially Replicated

At different sites, copies of tables or parts of tables are stored. The distribution of the tables is carried out in accordance with the access frequency. This relates to the fact that the frequency of access to the tables varies greatly from site to site. The number of copies of tables (or parts) depends on the frequency of execution of access queries and the site that generates access queries.

Fragmented

A table is divided into two or more parts in this design, referred to as fragments or partitions, and each fragment may be stored at various locations. This takes into account the fact that it rarely happens that at a given site all the data stored in a table is required. In addition, fragmentation enhances parallelism and provides greater recovery from disasters. There is only one copy, i.e. no redundant data, of each fragment in the system here.

The three techniques for fragmentation are –

• Vertical fragmentation
• Horizontal fragmentation
• Hybrid fragmentation

Mixed Distribution

This is a combination of fragmentation and partial replications. Here, the tables are initially fragmented in either form (horizontal or vertical) and then, according to the frequency of access to the fragments, these fragments are partly replicated throughout the various sites.