There are three key parameters for distributed database management system (DDBMS) architectures: distribution of data, autonomy of control, and heterogeneity of components. Common architectural models include client-server, peer-to-peer, and multi-DBMS. Client-server models divide functionality between servers for data management and clients for user interfaces. Peer-to-peer systems have peers that act as both clients and servers. Multi-DBMS combines multiple autonomous database systems.
There are three key parameters for distributed database management system (DDBMS) architectures: distribution of data, autonomy of control, and heterogeneity of components. Common architectural models include client-server, peer-to-peer, and multi-DBMS. Client-server models divide functionality between servers for data management and clients for user interfaces. Peer-to-peer systems have peers that act as both clients and servers. Multi-DBMS combines multiple autonomous database systems.
There are three key parameters for distributed database management system (DDBMS) architectures: distribution of data, autonomy of control, and heterogeneity of components. Common architectural models include client-server, peer-to-peer, and multi-DBMS. Client-server models divide functionality between servers for data management and clients for user interfaces. Peer-to-peer systems have peers that act as both clients and servers. Multi-DBMS combines multiple autonomous database systems.
There are three key parameters for distributed database management system (DDBMS) architectures: distribution of data, autonomy of control, and heterogeneity of components. Common architectural models include client-server, peer-to-peer, and multi-DBMS. Client-server models divide functionality between servers for data management and clients for user interfaces. Peer-to-peer systems have peers that act as both clients and servers. Multi-DBMS combines multiple autonomous database systems.
Download as DOCX, PDF, TXT or read online from Scribd
Download as docx, pdf, or txt
You are on page 1/ 9
Distributed DBMS Architectures
DDBMS architectures are generally developed depending on three
parameters
Distribution It states the physical distribution of data across the different
sites.
Autonomy It indicates the distribution of control of the database system 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 a two-level architecture where the functionality is divided into servers and clients. The server functions primarily encompass data management, query processing, optimization and transaction management. Client functions include mainly user interface. However, they have some functions like consistency checking and transaction management.
The two different client - server architecture are
Single Server Multiple Client
Multiple Server Multiple Client (shown in the following diagram)
Peer- to-Peer Architecture for DDBMS In these systems, each peer acts both as a client and a server for imparting database services. The peers share their resource with other peers and co- ordinate their activities.
This architecture generally has four levels of schemas
Global Conceptual Schema Depicts the global logical view of data.
Local Conceptual Schema Depicts logical data organization at each site.
Local Internal Schema Depicts physical data organization at each site.
External Schema Depicts user view of data.
Multi - DBMS Architectures This is an integrated database system formed by a collection of two or more autonomous database systems.
Multi-DBMS can be expressed through six levels of schemas
Multi-database View Level Depicts multiple user views comprising of
subsets of the integrated distributed database.
Multi-database Conceptual Level Depicts integrated multi-database that
comprises of global logical multi-database structure definitions.
Multi-database Internal Level Depicts the data distribution across different
sites and multi-database to local data mapping.
Local database View Level Depicts public view of local data.
Local database Conceptual Level Depicts local data organization at each
site. Local database Internal Level Depicts physical data organization at each site.
There are two design alternatives for multi-DBMS
Model with multi-database conceptual level.
Model without multi-database conceptual level.
Transactions Processing in DDBMS Transection : A transaction is a program including a collection of database operations, executed as a logical unit of data processing. The operations performed in a transaction include one or more of database operations like insert, delete, update or retrieve data. It is an atomic process that is either performed into completion entirely or is not performed at all. A transaction involving only data retrieval without any data update is called read-only transaction. Each high level operation can be divided into a number of low level tasks or operations. For example, a data update operation can be divided into three tasks
read_item() reads data item from storage to main memory.
modify_item() change value of item in the main memory.
write_item() write the modified value from main memory to storage.
Database access is restricted to read_item() and write_item() operations.
Likewise, for all transactions, read and write forms the basic database operations.
Transaction Operations The low level operations performed in a transaction are
begin_transaction A marker that specifies start of transaction execution.
read_item or write_item Database operations that may be interleaved with
main memory operations as a part of transaction.
end_transaction A marker that specifies end of transaction.
commit A signal to specify that the transaction has been successfully
completed in its entirety and will not be undone.
rollback A signal to specify that the transaction has been unsuccessful and so all temporary changes in the database are undone. A committed transaction cannot be rolled back.
Transaction States A transaction may go through a subset of five states, active, partially committed, committed, failed and aborted.
Active The initial state where the transaction enters is the active state. The transaction remains in this state while it is executing read, write or other operations. Partially Committed The transaction enters this state after the last statement of the transaction has been executed.
Committed The transaction enters this state after successful completion of
the transaction and system checks have issued commit signal.
Failed The transaction goes from partially committed state or active state to failed state when it is discovered that normal execution can no longer proceed or system checks fail.
Aborted This is the state after the transaction has been rolled back after failure and the database has been restored to its state that was before the transaction began.
The following state transition diagram depicts the states in the transaction and the low level transaction operations that causes change in states.
Desirable Properties of Transactions
Any transaction must maintain the ACID properties, viz. Atomicity, Consistency, Isolation, and Durability.
Atomicity This property states that a transaction is an atomic unit of
processing, that is, either it is performed in its entirety or not performed at all. No partial update should exist. Consistency A transaction should take the database from one consistent state to another consistent state. It should not adversely affect any data item in the database.
Isolation A transaction should be executed as if it is the only one in the
system. There should not be any interference from the other concurrent transactions that are simultaneously running.
Durability If a committed transaction brings about a change, that change
should be durable in the database and not lost in case of any failure.
