605.

741 David Silberberg

D. Silberberg

Distributed Database Systems - Distributed Database Design

Computer Architectures
The conceptual design and fundamental operational structure of a

computer system It is the functional description

Requirements (especially speeds and interconnections)
Design implementations for the various parts of a system Focuses largely on the way by which the system performs

Architecture typically refers to the internal structure of the system that

enables logical operations Architecture design issues revolve around:

Tradeoffs between cost and performance Reliability Feature set Expandability
D. Silberberg Distributed Database Systems - Distributed Database Design 2

DBMS Architectures
Architecture
The structure of a computer system Usually based on a reference model, which is an idealized

architecture model Conceptual framework that divides system into manageable pieces Demonstrates how the pieces are related

There are 3 types of architecture standards bases

Component architecture Functional architecture Data architecture

D. Silberberg

Distributed Database Systems - Distributed Database Design

Component Architectures
Describes components of a system and their

interrelationships Each component provides functionality Their interaction provides overall system functionality This is best decomposition if you want to build a system Not best for conceptually understanding the system Usually, multiple components form a function

D. Silberberg

Distributed Database Systems - Distributed Database Design

Functional Architectures
Different classes of users are defined A Functional Architecture defines the functions that users can perform Usually, user classes are decomposed hierarchically ANSI/SPARC architecture is an example

Does not help you build the system

Does not help you understand the complexity of the

system

D. Silberberg

Distributed Database Systems - Distributed Database Design

Data Architectures
Data representations and views are defined Architecture framework helps understand how they

are realized Since data is central DBMS resource, this is the representation of choice However, to fully define system, you need functions and components

D. Silberberg

Distributed Database Systems - Distributed Database Design

ANSI/X3/SPARC Committee DBMS Reference Architecture

User and Data views

External View

External View

Conceptual View

Internal View

D. Silberberg

Distributed Database Systems - Distributed Database Design

ANSI/X3/SPARC Committee DBMS Reference Architecture (cont.)

External views are views of the data shared by end users and apps
CREATE AS SELECT VIEW DISTINCT FROM WHERE GOOD_CUST cust_name, cust_address CUST, ORDER CUST.cust_no = ORDER.cust_no AND ORDER.quantity > 10

Conceptual view is the entire world view of the data environment

CUST(cust_no, cust_name, cust_address) key is cust_no

Internal view is how the database views the structure of the data
CUST( index on C#; C# : 4 bytes, C-name: 30 bytes, C-addr : 100 bytes )
Distributed Database Systems - Distributed Database Design

D. Silberberg

Partial Schematic of ANSI/SPARC Architecture

All the different representations are integrated in the data

dictionary/directory (not necessarily located in one place) Enterprise administrator takes care of Conceptual DB DB administrator
Takes care of Internal DB Affects/uses Conceptual DB

Application administrator
Takes care of External DB Affects/uses Conceptual DB

Data dictionary/directory
Enables schema integration Transforms different representations Defines internal and external database structures for applications
D. Silberberg Distributed Database Systems - Distributed Database Design 9

Partial Schematic of ANSI/SPARC Architecture

Enterprise Administrator Database Administrator Conceptual database schema processor Application System Administrator

Internal database schema processor

Schema Integration

External database schema processor

Internal storage/ database transform

Internal database/ conceptual transform

Conceptual/external database transform

Internal database application program Application System Programmer Distributed Database Systems - Distributed Database Design

External database application program

Application Programmer

D. Silberberg

10

Architecture Models for Distributed DBs

Three categories: Autonomy Type of data independence Distribution Level of distribution Heterogeneity Differences in supported systems

D. Silberberg

Distributed Database Systems - Distributed Database Design

11

Definitions of Autonomy
Different definitions Gligor and Popescu-Zeletin
Local operations not affected by participation in global multi-database

systems Query processing and optimization not affected by global query access System consistency not compromised when DBs are added to/removed from global databases

Du and Elmagarmid
Design autonomy: DBs use data models and transaction management they

want Communication autonomy: DBs decide which data to provide to other DBs or applications Execution autonomy: each DB executes queries that are presented to it in its own way
D. Silberberg Distributed Database Systems - Distributed Database Design 12

Ozsus Definition of Autonomy

Classes of autonomy 0. Tight integration -- single image of DB available 1. Semi-autonomous

Databases determine what parts of database they want to share Must be modified to exchange information with each other

2. Total isolation - stand-alone databases

D. Silberberg

Distributed Database Systems - Distributed Database Design

13

Database Distribution
0. None 1. Client/Server -- distributes functionality of DB

2. Peer-to-peer Fully distributed Act in concert with each other

D. Silberberg

Distributed Database Systems - Distributed Database Design

14

Heterogeneity
0. Homogeneous 1. Heterogeneous Different hardware Different data models Different query languages Different transaction models

D. Silberberg

Distributed Database Systems - Distributed Database Design

15

Examples
A0,D2,H0
Tightly integrated system DBMSs located peer-to-peer Same access, platforms, etc.

A1,D0,H1
Semiautonomous -- different type of data (video & text) No distribution Heterogeneous access

Heterogeneous, federated DBMS

A2, D1, H1
Autonomous database systems Client/server architecture

Heterogeneous access
Functionality in middleware three-layer architecture
Distributed Database Systems - Distributed Database Design

D. Silberberg

16

Client/Server Architecture (A*, D1, H*)

Multiple-client/single-server
Like a single DBMS available on one machine Some differences with respect to transaction management

Multiple-client/multiple-server
Two options

Application manages data access Application accesses one server, and it manages requests for information that reside on other servers

First loads burden on client Second loads burden on server -- "light clients"

From user perspective, client/server and peer-to-peer appear the same

Differences are in architecture

Distributed Database Systems - Distributed Database Design

D. Silberberg

17

Client/Server Architecture
Op Sys UI Client DBMS App Prog

Comm Software
SQL Query Op Sys Comm Software Semantic Data Controller Query Optimizer Transaction Manager Results

Recovery Manager
Runtime Support Proc Operating System

D. Silberberg

Distributed Database Systems - Distributed Database Design

18

Peer-to-Peer Architecture (A0, D2, H*)

Features Data independence Network transparency - supported by global schemas & mapping Users query independent of location Global mapping taken care of at GCS level Local mapping taken care of at LCS/LIS level

D. Silberberg

Distributed Database Systems - Distributed Database Design

19

Peer-to-Peer Architecture (High-Level)

ES1 ES2 ES3

GCS

LCS1

LCS2

LCS3

- for replication, etc.

LIS1

LIS2

LIS3

D. Silberberg

Distributed Database Systems - Distributed Database Design

20

Peer-to-Peer Architecture
User UI handler Semantic Data Controller Global Query Optimizer Global Execution Monitor External Schema

GCS
GD/D

Local Query Proc Local Recovery Mgr Runtime Support Proc

LCS Sys log LIS

D. Silberberg

Distributed Database Systems - Distributed Database Design

21

Peer-to-Peer Architecture Elements

UIF handler - interprets user commands Semantic data controller - checks integrity constraints, authorizations,

syntax, etc. Global query optimizer and decomposer - minimizes cost of global query, finds best strategy, etc. Distributed execution monitor - coordinates distributed execution of the request, distributed transaction manager, etc. Local query processor - chooses best access path, minimizes cost of query, finds best strategy, etc. Local recovery manager - maintains the database consistency Run-time support - O/S routines that interact with database data files

D. Silberberg

Distributed Database Systems - Distributed Database Design

22

Multiple Database Architecture (A2, D*, H*)

Difference between MDBMS and distributed DBMS MDBMS

Bottom-up design GCS describes some of the databases GCS is subset of the databases Top-down design GCS describes all of the databases GCS is union of the databases

Distributed DBMSs

D. Silberberg

Distributed Database Systems - Distributed Database Design

23

Multiple Database Architecture

GES1 GES2 GES3 LES1 LES1 LES1 GCS LES1 LES1 LES1

LCS1

LCS1

LIS1

LIS1

D. Silberberg

Distributed Database Systems - Distributed Database Design

24

Unilingual vs. Multilingual

Unilingual MDBMS for local and global data Users need to use different data models Users may need to use different access languages Burden is on the user Multilingual MDBMS for local and global data GSC must understand many query languages Users use one data model through external schema Users use one (their own) access language Burden is on the MDBMS
D. Silberberg Distributed Database Systems - Distributed Database Design 25

Models Without GCS

Manages several databases without a local schema Responsibility for providing access to multiple

databases lies with each of the applications They must provide the mappings between ESs and LCSs Different than a distributed database
Each local system has a DBMS MDBMS provides a layer of software that runs on top of

DBMSs and allows applications to access them

D. Silberberg Distributed Database Systems - Distributed Database Design 26

Models Without GCS (cont.)

Multi DB Layer ES1 ES2 ES3

LCS1 Local System Layer LIS1

LCS2

LCS3

LIS2

LIS3

D. Silberberg

Distributed Database Systems - Distributed Database Design

27

Conclusion
Data architectures provide a framework for distributed

database systems Data architectures focus on

User views Data views Levels of autonomy

Levels of distribution
Levels of heterogeneity

The tradeoff of these issues will drive

Distributed data design Distributed query processing algorithms
D. Silberberg Distributed Database Systems - Distributed Database Design 28