DDBMS Architecture DDBMS Architecture
Session-9
Data Management for Decision Support
ANSI ArchitectureANSI Architecture
ExternalView
ExternalView
ExternalView
ConceptualView
InternalView
External
Schema
Users
Conceptual
Schema
Internal
Schema
The Classical  DDBMS ArchitectureThe Classical  DDBMS Architecture
Site 1
Other sites
Site Independent
Schemas
Global Schema
Fragmentation Schema
Allocation Schema
LOCAL
 DB  1
Local Mapping Schema
DBMS 1
LOCAL
 DB  2
Local Mapping Schema
DBMS 2
Site 2
DDBMS SchemasDDBMS Schemas
Global Schema: a set of global relations as if database werenot distributed at all
Fragmentation Schema: global relation is split into “non-overlapping” (logical) fragments. 1:n mapping from relation Rto fragments Ri.
Allocation Schema: 1:1 or 1:n (redundant) mapping fromfragments to sites. All fragments corresponding to the samerelation R at a site j constitute the physical image Rj. A copyof a fragment is denoted by Rji.
Local Mapping Schema: a mapping from physical images tophysical objects, which are manipulated by local DBMSs.
Global Relations, Fragments and Physical ImagesGlobal Relations, Fragments and Physical Images
R
Global
Relation
R33
R32
R22
R21
R12
R11
R3
R2
R1
R2
(Site2)
R1
(Site 1)
R3
(Site3)
Physical Images
Fragments
Motivation for this ArchitectureMotivation for this Architecture
Separating the concept of data fragmentation fromthe concept of data allocation
fragmentation transparency
location transparency
Explicit control of redundancy
Independence from local databases: allows localmapping transparency
Rules for Data FragmentationRules for Data Fragmentation
Completeness
All the data of the global relation must be mappedinto the fragments
Reconstruction
It must always be possible to reconstruct eachglobal relation from its fragments
Disjointedness
it is convenient that fragments be disjoint, so thatthe replication of data can be controlled explicitly atthe allocation level
Types of Data FragmentationTypes of Data Fragmentation
Vertical Fragmentation
•Projection on relation (subset ofattributes)
•Reconstruction by join
•Updates require no tuplemigration
Horizontal Fragmentation
•Selection on relation (subset oftuples)
•Reconstruction by union
•Updates may requires tuplemigration
Mixed Fragmentation
•A fragment is a Select-Projectquery on relation.
Horizontal FragmentationHorizontal Fragmentation
Partitioning the tuples of a global relation intosubsets
Example:
Supplier(SNum, Name, City)
Horizontal Fragmentation can be:
Supplier 1 =  City = ``SFO'' Supplier
Supplier2 =  City != “SFO” Supplier
Reconstruction is possible:
Supplier = Supplier1  Supplier2
The set of predicates defining all the fragmentsmust be complete, and mutually exclusive
Derived Horizontal FragmentationDerived Horizontal Fragmentation
The horizontal fragmentation is derived from thehorizontal fragmentation of another relation
Example:
Supply (SNum, PNum, DeptNum, Quan)
SNum is a supplier number
Supply1 = Supply       SNum=SNum Supplier1
Supply2 = Supply       SNum=SNum Supplier2
The predicates defining derived horizontal fragments are:
Supply.SNum = Supplier.SNum and Supplier. City = ``SFO''
Supply.SNum = Supplier.SNum and Supplier. City != ``SFO''
       is thesemi­joinoperation.
Vertical FragmentationVertical Fragmentation
The vertical fragmentation of a global relation isthe subdivision of its attributes into groups;fragments are obtained by projecting the globalrelation over each group
Example
EMP (ENum,Name,Sal,Tax,MNum,DNum)
A vertical fragmentation can be
EMP1 =  ENum, Name, MNum, DNum EMP
EMP2 =  ENum, Sal, Tax EMP
Reconstruction:
ENum = ENum
EMP = EMP1                          EMP2
Distribution TransparencyDistribution Transparency
We analyze the different levels of distributiontransparency which can be provided by DDBMS forapplications.
A Simple Application
Supplier(SNum, Name, City)
Horizontally fragmented into:
Supplier 1 =  City = ``SFO'' Supplier  at Site1
Supplier2 =  City != “SFO” Supplier at Site2, Site3
Application:
Read the supplier number from the terminal and return the name ofthe supplier with that number
Level 1 of Distribution TransparencyLevel 1 of Distribution Transparency
Fragmentation transparency:
The DDBMS interprets the database operation by accessing thedatabases at different sites in a way which is completely determinedby the system
Supplier2
Supplier2
Supplier1
DDBMS
read(terminal, $SNum);
Select Name into $Name
from Supplier
where SNum = $SNum;
write(terminal, $Name).
S3
S2
S1
Level 2 of Distribution TransparencyLevel 2 of Distribution Transparency
Location Transparency
The application is independent from changes in allocationschema, but not from changes to fragmentation schema
Supplier2
Supplier2
Supplier1
DDBMS
read(terminal, $SNum);
Select Name into $Name
from Supplier1
where SNum = $SNum;
 If not FOUND then
Select Name into $Name
from Supplier2
where SNum = $SNum;
write(terminal, $Name).
S3
S2
S1
Level 3 of Distribution TransparencyLevel 3 of Distribution Transparency
Local Mapping Transparency
The applications have to specify both the fragment names and the siteswhere they are located. The mapping of database operations specified inapplications to those in DBMSs at sites is transparent
Supplier2
Supplier2
Supplier1
DDBMS
read(terminal, $SNum);
Select Name into $Name
from S1.Supplier1
where SNum = $SNum;
 If not FOUND then
Select Name into $Name
from S3.Supplier2
where SNum = $SNum;
write(terminal, $Name).
S3
S2
S1
Level 4 of Distribution TransparencyLevel 4 of Distribution Transparency
No Transparency
read(terminal, $SNum);
$SupIMS($Snum,$Name,$Found) at S1;
 If not FOUND then
$SupCODASYL($Snum,$Name,$Found) at S3;
write(terminal, $Name).
S1
Supplier1
IMS
DDBMS
S3
Supplier2
Codasyl
Distribution Transparency for UpdatesDistribution Transparency for Updates
EMP1 = ENum,Name,Sal,TaxDNum10 (EMP)
EMP2 = ENum,MNum,DNumDNum10 (EMP)
EMP3 = ENum,Name,DNumDnum>10 (EMP)
EMP4 = ENum,MNum,Sal,TaxDnum>10 (EMP)
Update Dnum=15for Employee withEnum=100
EMP1
EMP3
EMP4
EMP2
Difficult
•broadcastingupdates to allcopies
•migration oftuples becauseof change offragment­definingattributes
An Update ApplicationAn Update Application
UPDATE Emp
SET DNum = 15
WHERE ENum = 100;
Select Name, Tax, Sal into $Name, $Sal, $Tax
From EMP 1
Where ENum = 100;
Select MNum into $MNum
From Emp 2
Where ENum = 100;
Insert into EMP 3 (ENum, Name, DNum)
(100, $Name, 15);
Insert into EMP 4 (ENum, Sal, Tax, MNum)
(100, $Sal, $Tax, $MNum);
Delete EMP 1 where ENum = 100;
Delete EMP 2 where ENum = 100;
With Level 1FragmentationTransparency
With Level 2LocationTransparency only
Levels of Distribution TransparencyLevels of Distribution Transparency
Fragmentation Transparency
Just like using global relations.
Location Transparency
Need to know fragmentation schema; but no need not know wherefragments are located
 Applications access fragments (no need to specify sites wherefragments are located).
Local Mapping Transparency
Need to know both fragmentation and allocation schema; no need toknow what the underlying local DBMSs are.
Applications access fragments explicitly specifying where thefragments are located.
No Transparency
Need to know local DBMS query languages, and write applicationsusing functionality provided by the Local DBMS
On Distribution TransparencyOn Distribution Transparency
Higher levels of distribution transparency requireappropriate DDBMS support, but makes end-application developers work easy.
Less distribution transparency the more the end-application developer needs to know aboutfragmentation and allocation schemes, and how tomaintain database consistency.
Complex issues - query optimization and transactionmanagement
Some Aspects of the Classical ArchitectureSome Aspects of the Classical Architecture
Distributed database technology is an “add-on”technology, most users already have populatedcentralized DBMSs. Whereas top down designassumes implementation of new DDBMS fromscratch.
Current relational DBMS products provide for someform of location transparency (such as, by usingnicknames).
Bottom Up Architecture - Present & FutureBottom Up Architecture - Present & Future
Possible ways in which multiple databases may be put togetherfor sharing by multiple DBMSs, which are characterizedaccording to
Autonomy (A)  degree to which individual DBMSs canoperate independently.
0 - Tightly coupled - integrated (A0),
1 - Semiautonomous - federated (A1),
2- Total Isolation - multidatabase systems(A2)
Distribution (D)
0- no distribution - single site (D0),
1 - client-server - distribution of DBMS functionality (D1),
2- full distribution - peer to peer distributed architecture(D2)
Heterogeneity (H)
0 - homogeneous (H0)
1 - heterogeneous (H1)
AutonomyAutonomy
Autonomy refers to the distribution of control, not ofdata.
Degree of independence of  operations of individualDBMSs
Requirements of an autonomous system
Local operations of the individual DBMSs are not affected
Local query processing and optimization unaffected
System consistency or operation should not becompromised
Taxonomy of Distributed DatabasesTaxonomy of Distributed Databases
Composite DBMSs  -tight integration
single image of entire database is available to any user
can be single or multiple sites
can be homogeneous or heterogeneous
Federated DBMSs - semiautonomous
DBMSs that can operate independently, but have decided to makesome parts of their local data shareable
can be single or multiple sites.
they need to be modified to enable them to exchange information
Multidatabase Systems - total isolation
individual systems are stand alone DBMSs, which know neither theexistence of other databases or how to communicate with them
no global control over the execution of individual DBMSs.
can be single or multiple sites
homogeneous or heterogeneous
DDBMSs Implementation AlternativesDDBMSs Implementation Alternatives
D
Distributed
heterogeneous
multidatabase
system
Logically integrated
and homogeneous
DBMSs
Distributed
heterogeneous
DBMS
Distributed
homogeneous
multidatabase
system
Heterogeneous
Integrated DBMS
Multidatabase
System
Single site
homogeneous
federated DBMS
Distributed
homogeneous
federated system
Distributed
homogeneous
DBMS
Heterogeneous
multidatabase
system
Single Site
heterogeneous
federated
DBMS
Distributed
Heterogeneous
federated
 DBMS
A
H
Components of Client/Server SystemComponents of Client/Server System
UI
Application Program
Client DBMS
Communication software
OperatingSystem
System
Recovery Manager
Transaction Manager
Query Optimizer
Semantic Data Controller
Communication software
Operating
Runtime Support Processor
SQL Queries
Result Relation
Database
Components of DDBMSComponents of DDBMS
Local Query
Processor
Local Recovery
Manager
Runtime
Support
User Interface
Handler
Semantic Data
Controller
Global Query
Optimizer
Global
Execution
Monitor
External
Schema
Global
Schema
Local
Conceptual
Schema
Local
Internal
Schema
GD/D
log
USER PROCESSOR
DATA PROCESSOR
Global DirectoryGlobal Directory
Directory is itself a database that contains meta-dataabout the actual data stored in the database. Itincludes the support for fragmentation transparencyfor the classical DDBMS architecture.
Directory can be local or distributed.
Directory can be replicated and/or partitioned.
Directory issues are very important for large multi-database applications, such as digital libraries.