0% found this document useful (0 votes)
17 views

Unit 2

Uploaded by

arjabkhadka93
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
17 views

Unit 2

Uploaded by

arjabkhadka93
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 16

Distributed Database Architectures

• The architecture of a system defines its structure


• Architecture consists of components of systems,
• Function of different components.
• Interrelationship and interactions among the components are identified.

• present the issues that need to be addressed at design


• present a framework within which the design and implementation
issues can be discussed
Standardization of DBMS architecture
DDBMS might be implemented as homogeneous or heterogeneous DDBMS
• Homogeneous DDBMS
– All sites use same DBMS product
– It is much easier to design and manage
– The approach provides incremental growth and allows increased
performance
• Heterogeneous DDBMS
– Sites may run different DBMS products, with possibly different underlying
data models
– This occurs when sites have implemented their own databases first, and
integration is considered later
– Translations are required to allow for different hardware and/or different
DBMS
products
– Typical solution is to use gateways
DBMS architecture
DDBMS might be implemented as homogeneous or heterogeneous DDBMS
• Homogeneous DDBMS
– All sites use same DBMS product
– It is much easier to design and manage
– The approach provides incremental growth and allows increased
performance
• Heterogeneous DDBMS
– Sites may run different DBMS products, with possibly different underlying
data models
– This occurs when sites have implemented their own databases first, and
integration is considered later
– Translations are required to allow for different hardware and/or different
DBMS
products
– Typical solution is to use gateways
Standardization

• The standardization efforts in databases developed reference models of


DBMS.
• Reference Model: A conceptual framework whose purpose is to divide
standardization work into manageable pieces and to show at a general level how these
pieces are related to each other.
• A reference model can be thought of as an idealized architectural model of the
system.
• Commercial systems might deviate from reference model, still they are useful for the
standardization process
• A reference model can be described according to 3 different approaches:
– component-based
– function-based
– data-based
Standardization

Components-based

– Components of the system are defined together with the


interrelationships between the components

– Good for design and implementation of the system

– It might be difficult to determine the functionality of the system from its


components
Standardization

Function-based
– Classes of users are identified together with the functionality
that the system will provide for each class

– Typically a hierarchical system with clearly defined


interfaces between different layers

– The objectives of the system are clearly identified.


Standardization

Data-based
– Identify the different types of the data and specify the
functional units that will realize and/or use data according to
these views
– Gives central importance to data (which is also the central
resource of any DBMS)
->Claimed to be the preferable choice for standardization of DBMS
– The full architecture of the system is not clear without the
description of functional modules.
– Example: ANSI/SPARC architecture of DBMS
Architectural Models for DDBMSs

• Architectural Models for DDBMSs (or more generally for multiple DBMSs) can
be classified along three dimensions:

– Autonomy

– Distribution

– Heterogeneity
Architectural Models for DDBMSs

• Autonomy: Refers to the distribution of control (not of data) and indicates


the degree to which individual DBMSs can operate independently.

– Tight integration: a single-image of the entire database is available to


any user who wants to share the information (which may reside in multiple
DBs); realized such that one data manager is in control of the processing of
each user request.

– Semiautonomous systems: individual DBMSs can operate


independently, but have decided to participate in a federation to make
some of their local data sharable.

– Total isolation: the individual systems are stand-alone DBMSs, which


know neither of the existence of other DBMSs nor how to communicate with
them; there is no global control.
Architectural Models for DDBMSs

• Distribution: Refers to the physical distribution of data over multiple sites.


– No distribution: No distribution of data at all
– Client/Server distribution:
Data are concentrated on the server, while clients provide
application environment/user interface First attempt to distribution
– Peer-to-peer distribution (also called full distribution):
No distinction between client and server machine
Each machine has full DBMS functionality
Architectural Models for DDBMSs

• Heterogeneity: Refers to heterogeneity of the components at various levels

– hardware

– communications

– operating system

– DB components (e.g., data model, query language, transaction management


algorithms)
Different Types of architecture

• Client Server Architecture

• Peer to Peer Architecture

• Multi DBMSArchitecture
Client-Server Architecture for DDBMS

• Distinguish the functionality that needs to be provided


and divide these functions into two classes.
• Focus on what software should run on server and
what software should run on client.
1)server functions
-server does of data management work.
-meaning all of query processing and optimization,
transaction management and storage management is
done at server.
–2)client functions
-The client in addition to the application and the
user interface, has a DBMS client module that is
responsible for managing the data that is cached to
the client.
-Also it checks consistency of user queries.
Communication software on both side is
responsible to create consistent communication.
Client-Server Architecture for DDBMS

Types of client server architecture


a) Multiple Client – Single Server
b) Multiple Client- Multiple Server
Peer-to-Peer Architecture for DDBMS

• Local internal schema (LIS)


– Describes the local physical data organization
(which might be different
on each machine)
• Local conceptual schema (LCS)
– Describes logical data organization
at each site
– Required since the data are fragmented
and replicated
• Global conceptual schema (GCS)
– Describes the global logical view of
the data
– Union of the LCSs
• External schema (ES)
– Describes the user/application view
on the data
Distributed Multi DBMS Architecture

• Fundamental difference to peer-to-peer DBMS is in the


definition of the global conceptual schema (GCS)
– In a MDBMS the GCS represents only the
collection of some of the local databases
that each local DBMS want to share.

You might also like