Assignment No 1

Topic: Distributed Database Management System Architecture

Submitted By : Muhammad SAAD AWAN

Submitted To : Madam Hina

Date of Submission : Nov 18 2019

 Distributed Database Management SYSTEM Architecture
There are 3 types of architectures of Distributed Database Management SYSTEM with their
sub architectures these are

 Client Server Architecture For Distributed Database Management System

o Single server Multi Client database
o Multiple Server Multiple Client
 Peer to Peer Architecture For Distributed Database Management System
o Global Conceptual Schema
o Local Conceptual Schema
o Local Internal Schema
o External Schema
 Multi Architecture For Distributed Database Management System
o Multi-database View Level
o Multi-database Conceptual Level
o Multi-database Internal Level
o Local database View Level
o Local database Conceptual Level
o Local database Internal Level
 Middleware architecture

Client Server Architecture For Distributed Database

Management System: 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.

.
 In Single server Multi Client database the database is stored on only one machine (the server) that also
hosts the software to manage it. However, there are some (important) differences from centralized systems
in the way transactions are executed and caches are managed. We do not consider such issues at this point.
In Multiple Server Multiple Client two alternative management strategies are possible: either each client
manages its own connection to the appropriate server or each client knows of only its “home server” which
then communicates with other servers as required. The former approach simplifies server code, but loads
the client machines with additional responsibilities. This leads to what has been called “heavy client”
systems.

Multiple Server Multiple Client Single server Multi Client database

Middleware Architecture: Middleware architectures are designed in such a way that single query is executed
on multiple servers. This system needs only one server which is capable of managing queries and transactions
from multiple servers. Middleware architecture uses local servers to handle local queries and transactions. The
software’s are used for execution of queries and transactions across one or more independent database servers,
this type of software is called as middleware e.g. SOAP, web services, REST, JSON.

Peer to Peer Architecture For Distributed Database Management System: 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.

Local Internal Schema: The physical data organization on each machine may be, and probably
is, different. This means that there needs to be an individual internal schema definition at each
site, which we call the local internal schema (LIS).
Global Conceptual Schema: The enterprise view of the data is described by the global
conceptual schema (GCS), which is global because it describes the logical structure of the data
at all the sites.
Local Conceptual Schema: Is to handle data fragmentation and replication, the logical
organization of data at each site needs to be described. Therefore, there needs to be a third layer
in the architecture, the local conceptual schema (LCS).
External Schema: User applications and user access to the database is supported by external
schemas (ESs),

Peer-to-Peer Component Architecture

Multi Architecture For Distributed Database Management System:
 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.

Models Using a Global Conceptual Schema (GSA)

The GCS is defined by integration either the external schemas of local autonomous database or
parts of their local conceptual schemas. If heterogeneity exists in the system, then two
implementation alternative exist unilingual and multilingual.

Models without a Global Conceptual Schema (GSA)

The existing of a Global Conceptual Schema in a multi database system is a controversial issue.
There are researches who even define a multi database management system as one that manages
“several databases” without the global schema.

Multi database using GSA

Models Using a Global Conceptual Schema (GSA)

 A unilingual multi-DBMS requires the users to utilize possibly different data models and
languages when both a local database and the global database are accessed
 Any application that accesses data from multiple databases must do so by means of an
external view that is defined on the global conceptual schema.
 One application may have a local external schema (LES) defined on the local conceptual
schema as well as a global external schema (GES) defined on the global conceptual
schema.
 An alternative is multilingual architecture, where the basic philosophy is to permit each
user to access the global database (i.e., data from other databases) by means of an external
schema, defined using the language of the user’s local DBMS.
 The Multilingual approach obviously makes querying the database easier from the user
perspective. However, it is more complicated because we must deal with translation of
queries at runtime.

A popular implementation architecture for MDBSs is the mediator/wrapper approach. A mediator

“is a software module that exploits encoded knowledge about certain sets or subsets of data to
create information for a higher layer of applications.” Thus, each mediator performs a particular
function with clearly defined interfaces. Using this architecture to implement a MDBS, each
module in the multi-DBMS layer of is realized as a mediator. Since mediators can be built on top
of other mediators, it is possible to construct a layered implementation. In mapping this
architecture to the data logical view of Figure 1.16, the mediator level implements the GCS. It is
this level that handles user queries over the GCS and performs the MDBS functionality.

The mediators typically operate using a common data model and interface language. To deal with
potential heterogeneities of the source DBMSs, wrappers are implemented whose task is to provide
a mapping between a source DBMSs view and the mediators’ view. For example, if the source
DBMS is a relational one, but the mediator implementations are object oriented, the required
mappings are established by the wrappers. The exact role and function of mediators differ from
one implementation to another. In some cases, thin mediators have been implemented who do
nothing more than translation. In other cases, wrappers take over the execution of some of the
query functionality. One can view the collection of mediators as a middleware layer that provides
services above the source systems. Middleware is a topic that has been the subject of significant
study in the past decade and very sophisticated middleware systems have been developed that
provide advanced services for development of distributed applications. The mediators that we
discuss only represent a subset of the functionality provided by these systems.