Decomposition using Functional Dependency

19,737 views 23 slides Nov 23, 2016
Slide 1
Slide 1 of 23
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8
Slide 9
9
Slide 10
10
Slide 11
11
Slide 12
12
Slide 13
13
Slide 14
14
Slide 15
15
Slide 16
16
Slide 17
17
Slide 18
18
Slide 19
19
Slide 20
20
Slide 21
21
Slide 22
22
Slide 23
23

About This Presentation

Dependency preservation


Slide Content

Prepared by: RAJ NAIK SY CE-1 150410107053 Decomposition using FD- dependency preservation

Fuctional dependencies play a key role in differentiating good database designs from bad database designs. Let R be a relation schema, α  R and β  R The functional dependency α  β holds on R if and only if for any legal relations r(R), whenever any two tuples t1 and t2 of R agree on the attributes α , they also agree on the attributes β . That is, t1 [ α ] = t2 [ α ]  t1 [ β ] = t2 [ β ] Functional Dependencies

Example: Consider r(A,B) with the following instance of r. On this instance, A  B does NOT hold, but B  A does hold. A functional dependency is a generalization of the notion of a key Functional Dependencies 1 4 1 7 4 6

K is a superkey or for relation schema R if and only if K  R K is a candidate key for R if and only if K  R, and for no α  K, α  R Functional dependencies allow us to express constraints that cannot be expressed using superkeys . Functional Dependencies

Consider the schema: inst_dept (ID, name, salary, dept_name , building, budget ) We expect these functional dependencies to hold: dept_name  building ID  building but would not expect the following to hold: dept_name  salary Functional Dependencies

A functional dependency is trivial if it is satisfied by all instances of a relation Example: ID, name  ID name  name In general, α  β is trivial if β  α Functional Dependencies

The most important properties are Armstrong's axioms, which are used in database normalization: Subset Property If Y is a subset of X , then X → Y Augmentation If X → Y , then XZ → YZ Transitivity If X → Y and Y → Z , then X → Z Properties of functional dependencies

From these rules, we can derive these secondary rules: Union : If X → Y and X → Z , then X → YZ Decomposition : If X → YZ , then X → Y and X → Z Pseudotransitivity : f X → Y and WY → Z , then XW → Z Properties of functional dependencies

We can avoid update anomalies by decomposition of the original relation. The relation scema R is decomposed into relation schemas: {R1,R2,R3,……., Rn } in such a way that R 1  R2  …  R n = R Introduction to Decomposition

Lending_schema = ( Branch_name , Branch_city , Assets, Cusomer_name , Loan_number , Amount) The Lending schema is decomposed into following two relations: 1) Branch_customer_schema = ( Branch_name , Branch_city , Assets, Cusomer_name ) 2) Customer_loan_schema = ( Cusomer_name , Loan_number , Amount ) Example

Branch_Name Branch_City Assets Customer_Name Downtown Brooklyn 90000 Jones Redwood Palo Alto 21000 Smith Perryridge Horseneck 90000 Jackson Mianus Horseneck 80000 Jones Northtown Rye 37000 Hayes Customer_Name Loan_No Amount Jones L-17 10000 Smith L-23 2000 Jackson L-14 1500 Jones L-11 900 Hayes L-16 1300 The Branch_customer Relation The Customer_loan Relation

Branch_Name Branch_City Assets Customer_Name Loan_No Amount Downtown Brooklyn 90000 Jones L-17 10000 Downtown Brooklyn 90000 Jones L-11 9000 Redwood Palo Alto 21000 Smith L-23 2000 Perryridge Horseneck 90000 Jackson L-14 1500 Mianus Horseneck 80000 Jones L-11 900 Mianus Horseneck 80000 Jones L-17 1000 Northtown Rye 37000 Hayes L-16 1300 The result of this join is shown below: The relation Branch_customer Customer_loan

If the relation Branch_customer and Customer_loan is compared with the original lending relation, we observe that: Every tuple in lending relation is in Branch_customer and Customer_loan relation. The relation Branch_customer and Customer_loan contain following additional tuples: (Downtown,Brooklyn,90000,Jones,L-11,9000) (Mianus,Horseneck,80000,Jones,L-17,1000)

2. Consider the query: “Find all the branches that have made a loan in an amount less than Rs . 1000.” The result of this query using the lending relation is : Mianus . The result of the same query using the relation Branch_customer and Customer_loan is: Downtown and Mianus .

From the above two cases we can say that the decomposition of lending relation into Branch_customer and Customer_loan results in bad database design. It results in loss of information and repetition of information. Because of loss of i nformation, we call the decomposition of lending relation into Branch_customer and Customer_loan a lossy decomposition or a lossy -join decomposition.

Decomposition help us eliminate redundancy, root of data anomalies. There are two important properties associated with decomposition: 1. Lossless join 2. Dependency Preservation Desirable Properties of Decomposition

This property ensures that any instance of the original relation can be identifies from the corresponding instances in the smaller relation. Let R be a relational schema, and let F be a s et of functional dependencies on R. Let R1 and R2 form a decomposition of R. This decomposition is a lossless-join decomposition of R if at least one of the following functional dependencies is in F + R1  R2  R1 R1  R2  R2 In other word, if R1  R2 forms a superkey of either R1 or R2, the decomposition of R is a lossless-join decomposition. Lossless join

Question: Let R(A,B,C) and F=(A B ).Check the decomposition of R into R1(A,B) and R2(A,C) . R1  R2 is A which is comman attribute. A B is the FD in F. (augmentation rule) A AB which is relation R1. Thus, R1  R2 is satisfie s. Hence, above decomposition is lossless-join decomposition. Example of Lossless-join

Question : Let R(A,B,C) and F=(A B ).Check the decomposition of R into R1(A,B) and R2(B,C) . R1  R2 is B which is comman attribute. But B is not a superkey of either R1 or R2. Hence this decomposition is not a lossless-join decomposition. Example of Lossless-join

This property ensures that a constraint on the original relation can be maintained by simply enforcing some constraint on each of the smaller relation. Given a relational schema R and set of fuctional dependencies associated with it is F. R is decomposed into the relation schema R1,R2,… Rn with functional dependencies F1,F2,…Fn. Dependency Preservation

Then the decomposition is dependency preserving if the closure of F’ (where F’=F1,F2,…. Fn ) is identical to F +. F’ + =F + Getting lossless decomposition is necessary. Dependency Preservation

Question : R=(A, B, C), F={A  B, B  C} Decomposition of R: R1=(A, C) R2=(B, C) Does this decomposition preserve the given dependencies? In R1 the following dependencies hold: F1’={A  A, C  C, A  C, AC  AC} In R2 the following dependencies hold: F2’= {B  B, C  C, B  C, BC  BC} The set of nontrivial dependencies hold on R1 and R2: F‘ = {B  C, A  C} A  B can not be derived from F’, so this decomposition is NOT dependency preserving. Example of Dependency Preservation

Question : R=(A, B, C), F={A  B, B  C} Decomposition of R: R1=(A, B) R2=(B, C) Does this decomposition preserve the given dependencies? In R1 the following dependencies hold: F1={A  B, A  A, B  B, AB  AB} In R2 the following dependencies hold: F2= {B  B, C  C, B  C, BC  BC} F’= F1’ U F2’ = {A  B, B  C, trivial dependencies} In F’ all the original dependencies occur, so this decomposition preserves dependencies. Example of Dependency Preservation
Tags