Distributed Database

System

BY: MADIHA HAMEED

Ch.1/1
 Outline
• Introduction
• Background
• Distributed Database Design
• Database Integration
• Semantic Data Control
• View Management
• Data Security
• Semantic Integrity Control

• Distributed Query Processing

Ch.1/2
Distributed Access Control
• Additional problems in a distributed environment
• Remote user authentication
• Typically using a directory service
• Should be replicated at some sites for availability
• Management of DAC rules
• Problem if users’ group can span multiple sites
• Rules stored at some directory based on user groups location
• Accessing rules may incur remote queries
• Covert channels in MAC

Ch.1/3
Covert Channels
• Indirect means to access unauthorized data
• Example
• Consider a simple DDB with 2 sites: C (confidential) and S (secret)
• Following the “no write down” rule, an update from a subject with secret
clearance can only be sent to S
• Following the “no read up” rule, a read query from the same subject can
be sent to both C and S
• But the query may contain secret information (e.g. in a select predicate),
so is a potential covert channel
• Solution: replicate part of the DB
• So that a site at security level L contains all data that a subject at level L
can access (e.g. S above would replicate the confidential data so it can
entirely process secret queries)

Ch.1/4
Semantic Integrity Control
Maintain database consistency by enforcing a set of constraints
defined on the database.
• Structural constraints
• basic semantic properties inherent to a data model e.g., unique key
constraint in relational model
• Behavioral constraints
• regulate application behavior, e.g., dependencies in the relational model
• Two components
• Integrity constraint specification
• Integrity constraint enforcement

Ch.1/5
Semantic Integrity Control
• Procedural

control embedded in each application program

assertions in predicate calculus

Ch.1/6
Constraint Specification Language
Predefined constraints
specify the more common constraints of the relational model
• Not-null attribute
ENO NOT NULL IN EMP
• Unique key
(ENO, PNO) UNIQUE IN ASG
• Foreign key
A key in a relation R is a foreign key if it is a primary key of another relation S and the
existence of any of its values in R is dependent upon the existence of the same value in S
PNO IN ASG REFERENCES PNO IN PROJ
• Functional dependency
ENO IN EMP DETERMINES ENAME

Ch.1/7
Constraint Specification Language
Precompiled constraints
Express preconditions that must be satisfied by all tuples in a relation for a
given update type
(INSERT, DELETE, MODIFY)
NEW - ranges over new tuples to be inserted
OLD - ranges over old tuples to be deleted
General Form
CHECK ON <relation> [WHEN <update type>] <qualification>

Ch.1/8
Constraint Specification Language
Precompiled constraints
• Domain constraint

CHECK ON PROJ (BUDGET≥500000 AND BUDGET≤1000000)

• Domain constraint on deletion

CHECK ON PROJ WHEN DELETE (BUDGET = 0)

• Transition constraint

CHECK ON PROJ (NEW.BUDGET > OLD.BUDGET AND NEW.PNO

Ch.1/9
Constraint Specification Language
General constraints
Constraints that must always be true. Formulae of tuple relational
calculus where all variables are quantified.
General Form
CHECK ON <variable>:<relation>,(<qualification>)
• Functional dependency
CHECK ON e1:EMP, e2:EMP
(e1.ENAME = e2.ENAME IF e1.ENO = e2.ENO)
• Constraint with aggregate function
CHECK ON g:ASG, j:PROJ
(SUM(g.DUR WHERE g.PNO = j.PNO) < 100 IF
j.PNAME = “CAD/CAM”)

Ch.1/10
Integrity Enforcement
Two methods
• Detection
Execute update u: D  Du
If Du is inconsistent then
if possible: compensate Du  Du’
else
undo Du  D
• Preventive
Execute u: D  Du only if Du will be consistent
• Determine valid programs
• Determine valid states

Ch.1/11
Query Modification
• Preventive
• Add the assertion qualification to the update query
• Only applicable to tuple calculus formulae with universally
quantified variables
UPDATE PROJ
SET BUDGET = BUDGET*1.1
WHERE PNAME = "CAD/CAM"

UPDATE PROJ
SET BUDGET = BUDGET*1.1
WHERE PNAME = "CAD/CAM"
AND NEW.BUDGET ≥ 500000
AND NEW.BUDGET ≤ 1000000

Ch.1/12
 Compiled Assertions
Triple (R,T,C) where
R relation
T update type (insert, delete, modify)
C assertion on differential relations
Example: Foreign key assertion
g  ASG, j  PROJ : g.PNO = j.PNO
Compiled assertions:
(ASG, INSERT, C1), (PROJ, DELETE, C2), (PROJ, MODIFY, C3)
where
C1:NEW  ASG+ j  PROJ: NEW.PNO = j.PNO
C2:g  ASG, OLD  PROJ- : g.PNO ≠ OLD.PNO
C3:g  ASG, OLD  PROJ- NEW  PROJ+:
g.PNO ≠OLD.PNO OR OLD.PNO = NEW.PNO

Ch.1/13
Differential Relations
Given relation R and update u
R+ contains tuples inserted by u
R- contains tuples deleted by u

Type of u
insert R- empty
delete R+ empty
modify R+  (R – R-)

Ch.1/14
Differential Relations
Algorithm:
Input: Relation R, update u, compiled assertion Ci
Step 1: Generate differential relations R+ and R–
Step 2: Retrieve the tuples of R+ and R– which do not satisfy Ci
Step 3: If retrieval is not successful, then the assertion is valid.
Example :
u is delete on J. Enforcing (EMP, DELETE, C2) :
retrieve all tuples of EMP-
into RESULT
where not(C2)
If RESULT = {}, the assertion is verified

Ch.1/15
Distributed Integrity Control
• Problems:

• Definition of constraints
• consideration for fragments

• Where to store
• replication
• non-replicated : fragments

• Enforcement
• minimize costs

Ch.1/16
Types of Distributed Assertions
• Individual assertions
• single relation, single variable
• domain constraint
• Set oriented assertions
• single relation, multi-variable
• functional dependency
• multi-relation, multi-variable
• foreign key

• Assertions involving aggregates

Ch.1/17
 Distributed Integrity Control
• Assertion Definition
• similar to the centralized techniques
• transform the assertions to compiled assertions

• Assertion Storage
• Individual assertions
• one relation, only fragments
• at each fragment site, check for compatibility
• if compatible, store; otherwise reject
• if all the sites reject, globally reject
• Set-oriented assertions
• involves joins (between fragments or relations)
• maybe necessary to perform joins to check for compatibility
• store if compatible

Ch.1/18
Distributed Integrity Control
• Assertion Enforcement
• Where to enforce each assertion depends on
• type of assertion
• type of update and where update is issued
• Individual Assertions
• update = insert
• enforce at the site where the update is issued
• update = qualified
• send the assertions to all the sites involved
• execute the qualification to obtain R+ and R-
• each site enforce its own assertion
• Set-oriented Assertions
• single relation
• similar to individual assertions with qualified updates
• multi-relation
• move data between sites to perform joins; then send the result to the query master site

Ch.1/19
Question ?

20

Ch.1/20