DDBMS Architecture Models for Distributed Systems

Distributed DBMS Architecture
Ali Samad
Architecture
Defines the structure of the system

– Defines the structure of the system
– components identified
– functions of each component defined
– interrelationships and interactions between
components defined
Ali Samad
Tahir Rashid DDBMS Architecture 2
Architecture
• Goal:
– present the issues that need to be addressed at
design
– present a framework within which the design and
implementation issues can be discussed
• The ISO/OSI 7-layered reference model
for computer networks
Ali Samad
Standardization
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 one another.
A reference model can be described according to three
different approaches:
• Based on components
• Based on functions
• Based on data
Ali Samad
DBMS STANDARDIZATION
• Based on components.
The components of the system are defined together with the
interrelationships between components. A DBMS consists of a
number of components, each of which provides some functionality.
• Based on functions.
The different classes of users are identified and the functions that
the system will perform for each class are defined. The system
specifications within this category typically specify a hierarchical
structure for the user classes. The ISO/OSI architecture fall in this
category.
Ali Samad
• Based on data.
The different types of data are identified, and an architectural
framework is specified which defines the functional units that will
realize or use data according to these different views. This approach
(also referred as the data logical approach) is claimed to be the
preferable choice for standardization activities.
Ali Samad
ANSI / SPARC ARCHITECTURE
The ANSI / SPARC architecture is claimed to be based
on the data organization. It recognizes three views of
data:
the external view, which is that of the user, who might be
a programmer; the internal view, that of the system or
machine; and the conceptual view, that of the enterprise.
For each of these views, an appropriate schema

definition is required.
Ali Samad
Ali Samad
• At the lowest level of the architecture is the internal view,
which deals with the physical definition and organization
of data.
• At the other extreme is the external view, which is

concerned with how users view the database.
• Between these two ends is the conceptual schema,

which is an abstract definition of the database. It is the
„real world” view of the enterprise being modeled in the
database.
Ali Samad
Conceptual Schema Definition
RELATION EMP [
KEY = {ENO}
ATTRIBUTES = {
ENO : CHARACTER(9)
ENAME : CHARACTER(15)
TITLE : CHARACTER(10)
}
]
RELATION PAY [
KEY = {TITLE}
ATTRIBUTES = {
SAL : NUMERIC(6)
}
]
Ali Samad
Conceptual Schema Definition
RELATION PROJ [
KEY = {PNO}
ATTRIBUTES = {
PNO : CHARACTER(7)
PNAME : CHARACTER(20)
BUDGET: NUMERIC(7)
}
]
RELATION ASG [
KEY = {ENO,PNO}
ATTRIBUTES = {
ENO : CHARACTER(9)
PNO : CHARACTER(7)
RESP : CHARACTER(10)
DUR : NUMERIC(3)
}
Ali ]
Samad
Internal Schema Definition
RELATION EMP [
KEY = {ENO}
ATTRIBUTES = {
ENO : CHARACTER(9)
ENAME : CHARACTER(15)
}
]
⇓
INTERNAL_REL EMPL [
INDEX ON E# CALL EMINX
FIELD = {
HEADER : BYTE(1)
E# : BYTE(9)
ENAME : BYTE(15)
TIT : BYTE(10)
}
]
Ali Samad
External View Definition –
Example 1
Create a BUDGET view from the PROJ relation
CREATE VIEW BUDGET(PNAME, BUD)

AS SELECT PNAME, BUDGET
FROM PROJ
Ali Samad
External View Definition –
Example 2
Create a Payroll view from relations EMP and TITLE_SALARY
CREATE VIEW PAYROLL (ENO, ENAME, SAL)

AS SELECT EMP.ENO,EMP.ENAME,PAY.SAL
FROM EMP, PAY
WHERE EMP.TITLE = PAY.TITLE
Ali Samad
Ali Samad
• The square boxes represent processing functions, whereas the

hexagons are administrative roles.
• The arrows indicate data, command, program, and description
flow, whereas the „I”-shaped bars on them represent interfaces.
• The major component that permits mapping between different
data organizational views is the data dictionary / directory
(depicted as a triangle), which is a meta-database.
• The database administrator is responsible for defining the
internal schema definition.
• The enterprise administrator’s role is to prepare the conceptual
schema definition.
• The application administrator is responsible for preparing the
external schema for applications.
Ali Samad
• Two more users:
– Application programmer
– System programmer
• Two user classes:
– Casual user
• Retrieve database and possible update
• Added in external schema
– Novice user
• Typically have no knowledge of data base
• Example (banking machine)
Ali Samad
ARCHITECTURAL MODELS FOR
DISTRIBUTED DBMSs
The systems are characterized with respect to:

(1) the autonomy of the local systems,
(2) their distribution,
(3) their heterogeneity.
Ali Samad
Architectural models for Distributed
DBMSs
Ali Samad
Autonomy
• Distribution of control (and not data) - the degree of
independence
– The local operations of the individual DBMSs are not
affected by their participation in the multidatabase system
– The manner in which individual DBMSs process queries
and optimize them should not be affected by the
execution of global queries
– System consistency should not be compromised when
individual DBMSs join or leave the multidatabase system
Ali Samad
Autonomy
• On the other hand specifies the dimension
of autonomy as:
• Design autonomy: Ability of a component DBMS
to decide on issues related to its own design.
• Communication autonomy: Ability of a
component DBMS to decide whether and how to
communicate with other DBMSs.
• Execution autonomy: Ability of a component
DBMS to execute local operations in any manner it
wants to.
Ali Samad
Autonomy
• Possibilities:
– 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
databases.
– Semiautonomous system – consist of DBMSs that
can operate independently, but have decided to
participate in a federation to make 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.
Ali Samad
DISTRIBUTED DBMSs - DISTRIBUTION
Distributions refers to the distributions of data. Of course,
we are considering the physical distribution of data over
multiple sites; the user sees the data as one logical pool.
Two alternatives:
– client / server distribution
– peer-to-peer distribution (full distribution)
Ali Samad
Client / server distribution.
The client / server distribution concentrates data management
duties at servers while the clients focus on providing the application
environment including the user interface. The communication duties
are shared between the client machines and servers. Client / server
DBMSs represent the first attempt at distributing functionality.
Peer-to-peer distribution.
There is no distinction of client machines versus servers. Each
machine has full DBMS functionality and can communicate with
other machines to execute queries and transactions.
Ali Samad
Client / server distribution.
The client / server distribution concentrates data management
duties at servers while the clients focus on providing the application
environment including the user interface. The communication duties
are shared between the client machines and servers. Client / server
DBMSs represent the first attempt at distributing functionality.
Peer-to-peer distribution.
There is no distinction of client machines versus servers. Each
machine has full DBMS functionality and can communicate with
other machines to execute queries and transactions.
Ali Samad
DISTRIBUTED DBMSs - HETEROGENEITY
Heterogeneity may occur in various forms in distributed
systems, ranging form hardware heterogeneity and
differences in networking protocols to variations in data
managers.
Representing data with different modeling tools creates
heterogeneity because of the inherent expressive powers
and limitations of individual data models. Heterogeneity in
query languages not only involves the use of completely
different data access paradigms in different data models,
but also covers differences in languages even when the
individual systems use the same data model.
Ali Samad
DISTRIBUTED DBMSs -
HETEROGENEITY
• Various levels (hardware,
communications, operating system)
• DBMS important one – data model, query
language, transaction management algorithms
• Representing data with different modeling tools
creates heterogeneity because of the inherent
expressive power and limitations of individual data
models.
Ali Samad
DISTRIBUTED DBMSs - ALTERNATIVES
The dimensions are identified as:
A (autonomy),
D (distribution) and
H (heterogeneity).
The alternatives along each dimension are

identified by numbers as: 0, 1 or 2.
Ali Samad
ARCHITECTURAL MODELS FOR DISTRIBUTED
DBMSs - ALTERNATIVES
A0 - tight integration
A1 - semiautonomous systems
A2 - total isolation
H0 - homogeneous systems
H1 - heterogeneous systems
D0 - no distribution
D1 - client / server systems
D2 - peer-to-peer systems
Ali Samad
DISTRIBUTED DBMSs
Ali Samad
Alternatives in Distributed Database
Systems
Distribution
Distributed
Peer-to-peer
multi-DBMS
Distributed DBMS
Client/server
Autonomy
Multi-DBMS
Federated DBMS
Heterogeneity
Tahir
Ali Rashid
Samad DDBMS Architecture 31
ARCHITECTURAL MODELS FOR DISTRIBUTED
DBMSs - ALTERNATIVES
• In figure 4.3 , two alternative architectures that

are focus of this book:
• (A0, D2, H0)
• (A2, D2, H1)
• Not all the architectures that are identified
by this design space are meaningful.
Ali Samad
(A0, D0, H0)
If there is no distribution or heterogeneity, the system is a set of
multiple DBMSs that are logically integrated. Such systems can be
given generic name composite systems. Not such examples but
they may be suitable for shared everything multiprocessor systems.
(A0, D0, H1)
If heterogeneity is introduced, one has multiple data managers that
are heterogeneous but provide an integrated view to the user.
(A0, D1, H0)
The more interesting case is where the database is distributed even
though an integrated view of the data is provided to users (client /
server distribution). Mentioned earlier and will discuss further.
Ali Samad
(A0, D2, H0)
The same type of transparency is provided to the user in a fully
distributed environment. There is no distinction among clients and
servers, each site providing identical functionality.
(A1, D0, H0)
These are semiautonomous systems, which are commonly termed
federated DBMS. The component systems in a federated
environment have significant autonomy in their execution, but their
participation in the federation indicate that they are willing to
cooperate with other in executing user requests that access multiple
databases. An example may be multiple installations of an DBMS.
Ali Samad
(A1, D0, H1)

These are systems that introduce heterogeneity as well as autonomy,
what we might call a heterogeneous federated DBMS.
(A1, D1, H1)
System of this type introduce distribution by placing component
systems on different machines. They may be referred to as distributed,
heterogeneous federated DBMS.
(A2, D0, H0)
Now we have full autonomy. These are multidatabase systems
(MDBS). The components have no concept of cooperation. Without
heterogeneity and distribution, an MDBS is an interconnected
collection of autonomous databases.
Ali Samad
(A2, D0, H1)
These case is realistic, maybe even more so than (A1, D0, H1), in
that we always want to built applications which access data from
multiple storage systems with different characteristics.
(A2, D1, H1) and (A2, D2, H1)
These two cases are together, because of the similarity of the
problem. They both represent the case where component
databases that make up the MDBS are distributed over a number of
sites - we call this the distributed MDBS.
Ali Samad
Data logical Distributed DBMS
Architecture
ES1 ES2 ... ESn
ES: External Schema

GCS: Global Conceptual Schema
GCS LCS: Local Conceptual Schema
LIS: Local Internal Schema
LCS1 LCS2 ... LCSn
LIS1 LIS2 ... LISn
Ali Samad
Datalogical Multi-DBMS Architecture
GES1 GES2 ... GESn
LES11 … LES1n GCS LESn1 … LESnm
LCS1 LCS2 … LCSn
LIS1 LIS2 … LISn
• GES: Global External Schema • LCS: Local Conceptual Schema

• LES: Local External Schema • LIS: Local Internal Schema
Ali Samad
Distributed DBMS
• Distributed database requires distributed DBMS
• Functions of a distributed DBMS:
– Locate data with a distributed data dictionary
– Determine location from which to retrieve data and process
query components
– DBMS translation between nodes with different local DBMSs
(using middleware)
– Data consistency (via multiphase commit protocols)
– Global primary key control
– Scalability
– Security, concurrency, query optimization, failure recovery
Ali Samad
Figure 13-10 – Distributed DBMS architecture
Ali Samad
Local Transaction Steps
1. Application makes request to distributed
DBMS
2. Distributed DBMS checks distributed data
repository for location of data. Finds that it is
local
3. Distributed DBMS sends request to local
DBMS
4. Local DBMS processes request
5. Local DBMS sends results to application
Ali Samad
Figure 13-10: Distributed DBMS Architecture (cont.)
(showing local transaction steps)
3 5
4
Local transaction –
all data stored locally
Ali Samad
Global Transaction Steps
1. Application makes request to distributed DBMS
2. Distributed DBMS checks distributed data repository for location of data.
Finds that it is remote
3. Distributed DBMS routes request to remote site
4. Distributed DBMS at remote site translates request for its local DBMS if
necessary, and sends request to local DBMS
5. Local DBMS at remote site processes request
6. Local DBMS at remote site sends results to distributed DBMS at remote
site
7. Remote distributed DBMS sends results back to originating site
8. Distributed DBMS at originating site sends results to application
Ali Samad
Figure 13-10: Distributed DBMS architecture (cont.)
(showing global transaction steps)
2
3
1
7 6
8
4
Global transaction – some

data is at remote site(s)
Ali Samad
DISTRIBUTED DBMS ARCHITECTURE
• Client / server systems - (Ax, D1, Hy)
• Distributed databases - (A0, D2, H0)
• Multidatabase systems - (A2, Dx, Hy)
Ali Samad
The Client/Server Database
Environment
Ali Samad
Client/Server Systems
• Networked computing model
• Processes distributed between clients and
servers
• Client – Workstation (usually a PC) that requests
and uses a service
• Server – Computer (PC/mini/mainframe) that
provides a service
• For DBMS, server is a database server
Ali Samad
Application Logic in C/S
Systems
• Presentation Logic
– Input – keyboard/mouse
– Output – monitor/printer
GUI Interface
• Processing Logic
– I/O processing
– Business rules Procedures, functions,
– Data management programs
• Storage Logic
– Data storage/retrieval DBMS activities
Ali Samad
Client/Server Architectures
• File Server Architecture
• Database Server Architecture
• Three-tier Architecture
Ali Samad
File Server Architecture
• All processing is done at the PC that requested the data

• Entire files are transferred from the server to the client
for processing.
• Problems:
– Huge amount of data transfer on the network
– Each client must contain full DBMS
• Heavy resource demand on clients
• Client DBMSs must recognize shared locks, integrity checks, etc.
Ali Samad
File Server Architecture
Ali Samad
Database Server Architectures
• 2-tiered approach
• Client is responsible for
– I/O processing logic
– Some business rules logic
• Server performs all data storage and access processing
 DBMS is only on server
• Advantages
– Clients do not have to be as powerful
– Greatly reduces data traffic on the network
– Improved data integrity since it is all processed centrally
– Stored procedures  some business rules done on server
Ali Samad
Advantages of Stored Procedures
• Compiled SQL statements

• Reduced network traffic
• Improved security
• Improved data integrity
Ali Samad
Database server architecture
DBMS only
on server
Ali Samad
Three-Tier Architectures
• Three layers: GUI interface
– Client (I/O processing) Browser
– Application server Business rules Web Server
– Database server Data storage
DBMS
 Thin Client
 PC just for user interface and a little application
processing. Limited or no data storage (sometimes no
hard drive)
Ali Samad
Three-tier architecture
Thinnest
clients
Business
rules on
separate
server
DBMS only on
DB server
Ali Samad
CLIENT / SERVER SYSTEMS
• This provides two-level architecture which make it easier

to manage the complexity of modern DBMSs and the
complexity of distribution.
• The server does most of the data management work

(query processing and optimization, transaction
management, storage management).
• The client is the application and the user interface

(management the data that is cached to the client,
management the transaction locks).
Ali Samad
• This architecture is
quite common in
relational systems
where the
communication
between the clients and
the server(s) is at the
level of SQL
statements.
Ali Samad
Ali Samad
Multiple client - single server

From a data management perspective, this is not much different
from centralized databases since the database is stored on only one
machine (the server) which also hosts the software to manage it.
However, there are some differences from centralized systems in
the way transactions are executed and caches are managed.
Multiple client - multiple server

In this case, 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.
Ali Samad
Multiple Clients/Single Server
Applications Applications Applications
Client Client Client

Services Services Services
Communications Communications Communications
LAN
High-level Filtered
requests data only
Communications
DBMS Services
Database
Ali Samad
Task Distribution
Application
QL Programmatic
Interface … Interface
Communications Manager
SQL result
query table
Communications Manager
Query Optimizer
Lock Manager
Storage Manager
Page & Cache Manager
Database
Ali Samad
Advantages of Client-Server
Architectures
• More efficient division of labor
• Better price/performance on client machines
• Ability to use familiar tools on client machines
• Client access to remote data (via standards)
• Full DBMS functionality provided to client workstations
• Overall better system price/performance
Ali Samad
Problems With Multiple-
Client/Single Server
• Server forms bottleneck

• Server forms single point of failure
• Database scaling difficult
Ali Samad
Multiple Clients/Multiple Servers
• directory Applications
• caching Client
Services
• query decomposition
Communications
• commit protocols
LAN
Communications Communications
DBMS Services DBMS Services
Database Database
Ali Samad
Server-to-Server
• SQL interface Applications

• programmatic interface
Client
• other application Services
support environments
Communications
LAN
Communications Communications
DBMS Services DBMS Services
Database Database
Ali Samad
PEER-TO-PEER DISTRIBUTED SYSTEMS
• The physical data organization on each machine may be

different.
• Local internal scheme (LIS) - is an individual internal
schema definition at each site.
• Global conceptual schema (GCS) - describes the
enterprise view of the data.
• Local conceptual schema (LCS) - describes the logical
organization of data at each site.
• External schemas (ESs) - support user applications and
user access to the database.
Ali Samad
Ali Samad
In these case, the ANSI/SPARC

model is extended by the addition of
global directory / dictionary (GD/D)
to permits the required global
mappings. The local mappings are
still performed by local directory /
dictionary (LD/D). The local
database management components
are integrated by means of global
DBMS functions. Local conceptual
schemas are mappings of global
schema onto each site.
Tahir
Ali Rashid
Samad DDBMS Architecture 69
Ali Samad
The detailed
components of a
distributed
DBMS.
Two major
components:
– user processor
– data processor
Ali Samad
Ali Samad
User processor
• user interface handler - is responsible for interpreting user
commands as they come in, and formatting the result data as it is
sent to the user,
• semantic data controller - uses the integrity constraints and
authorizations that are defined as part of the global conceptual
schema to check if the user query can be processed,
• global query optimizer and decomposer - determines an
execution strategy to minimize a cost function, and translates the
global queries in local ones using the global and local conceptual
schemas as well as global directory,
• distributed execution monitor - coordinates the distributed
execution of the user request.
Ali Samad
Data processor
• local query optimizer - is responsible for choosing the best
access path to access any data item,
• local recovery manager - is responsible for making sure that the
local database remains consistent even when failures occur,
• run-time support processor - physically accesses the database
according to the physical commands in the schedule generated by
the query optimizer. This is the interface to the operating system
and contains the database buffer (or cache) manager, which is
responsible for maintaining the main memory buffers and managing
the data accesses.
Ali Samad
Peer-to-Peer
Component Architecture
USER PROCESSOR DATA PROCESSOR
Global Local System Local

External Conceptual Conceptual Log Internal
Schema Schema GD/D Schema Schema
User
requests
Semantic Data
User Interface
Local Recovery
Database
Global Query
Local Query
Controller
Execution
Processor
Optimizer
Processor
Handler
Manager
Runtime
Monitor
Support
USER Global
System
responses
Ali Samad

DDBMS Architecture Models for Distributed Systems

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

DDBMS Architecture Models for Distributed Systems

Enviado por

Direitos autorais:

Formatos disponíveis

Distributed DBMS Architecture

Defines the structure of the system

For each of these views, an appropriate schema

• At the other extreme is the external view, which is

• Between these two ends is the conceptual schema,

Create a BUDGET view from the PROJ relation

CREATE VIEW BUDGET(PNAME, BUD)

CREATE VIEW PAYROLL (ENO, ENAME, SAL)

• The square boxes represent processing functions, whereas the

The systems are characterized with respect to:

The alternatives along each dimension are

• In figure 4.3 , two alternative architectures that

(A1, D0, H1)

ES1 ES2 ... ESn

ES: External Schema

LCS1 LCS2 ... LCSn

LIS1 LIS2 ... LISn

LES11 … LES1n GCS LESn1 … LESnm

LCS1 LCS2 … LCSn

LIS1 LIS2 … LISn

• GES: Global External Schema • LCS: Local Conceptual Schema

Global transaction – some

• Client / server systems - (Ax, D1, Hy)

• Distributed databases - (A0, D2, H0)

• Multidatabase systems - (A2, Dx, Hy)

• File Server Architecture

• Database Server Architecture

• All processing is done at the PC that requested the data

• Compiled SQL statements

• This provides two-level architecture which make it easier

• The server does most of the data management work

• The client is the application and the user interface

Multiple client - single server

Multiple client - multiple server

Applications Applications Applications

Client Client Client

• Server forms bottleneck

DBMS Services DBMS Services

• SQL interface Applications

DBMS Services DBMS Services

• The physical data organization on each machine may be

In these case, the ANSI/SPARC

Global Local System Local

Você também pode gostar