Distributed Database Architecture in DBMS

Distributed Database System:

A Distributed Database System is a kind of database that is present or divided in more than one location, which means it is not limited to any single computer system. It is divided over the network of various systems. The Distributed Database System is physically present on the different systems in different locations. This can be necessary when different users from all over the world need to access a specific database. For a user, it should be handled in such a way that it seems like a single database.

Parameters of Distributed Database Systems:

Distribution:

It describes how data is physically distributed among the several sites.

Autonomy:

It reveals the division of power inside the Database System and the degree of autonomy enjoyed by each individual DBMS.

Heterogeneity:

It speaks of the similarity or differences between the databases, system parts, and data models.

Common Architecture Models of Distributed Database Systems:

Client-Server Architecture of DDBMS:

This architecture is two level architecture where clients and servers are the points or levels where the main functionality is divided. There is various functionality provided by the server, like managing the transaction, managing the data, processing the queries, and optimization.

Peer-to-peer Architecture of DDBMS:

In this architecture, each node or peer is considered as a server as well as a client, and it performs its database services as both (server and client). The peers coordinate their efforts and share their resources with one another.

Multi DBMS Architecture of DDBMS:

This is an amalgam of two or more independent Database Systems that functions as a single integrated Database System.

Types of Distributed Database Systems:

Homogeneous Database System:

Each site stores the same database in a Homogenous Database. Since each site has the same database stored, so all the data management schemes, operating system, and data structures will be the same across all sites. They are, therefore, simple to handle.

Heterogeneous Database System:

In this type of Database System, different sites are used to store the data and relational tables, which makes it difficult for database administrators to do the transactions and run the queries into the database. Additionally, one site might not even be aware of the existence of the other sites. Different operating systems and database applications may be used by various computers. Since each system has its own database model to store the data, therefore it is required there should be translation schemes to establish the connections between different sites to transfer the data.

Distributed Data Storage:

There are two methods by which we can store the data on different sites:

Replication:

This method involves redundantly storing the full relationship at two or more locations. Since a complete database can be accessed from each site, it becomes a redundant database. Systems preserve copies of the data as a result of replication.

This has advantages because it makes more data accessible at many locations. Additionally, query requests can now be handled in parallel.

However, there are some drawbacks as well. Data must be updated frequently. Any changes performed at one site must be documented at every site where that relation is stored in order to avoid inconsistent results. There is a tonne of overhead here. Additionally, since concurrent access must now be monitored across several sites, concurrency control becomes far more complicated.

Fragmentation:

According to this method, the relationships are divided (i.e., broken up into smaller pieces), and each fragment is stored at the many locations where it is needed. To ensure there is no data loss, the pieces must be created in a way that allows for the reconstruction of the original relation.

Since Fragmentation doesn't result in duplicate data, consistency is not a concern.

Ways of fragmentation:

Horizontal Fragmentation:

In Horizontal Fragmentation, the relational table or schema is broken down into a group of one and more rows, and each row gets one fragment of the schema. It is also called splitting by rows.

Vertical Fragmentation:

In this fragmentation, a relational table or schema is divided into some more schemas of smaller sizes. A common candidate key must be present in each fragment in order to guarantee a lossless join. This is also called splitting by columns.