0% found this document useful (0 votes)
36 views

Lecture Notes For DBMS: Decomposition

The document discusses decomposing a database table called "Lending" to address issues like data redundancy and integrity. It proposes decomposing the table into two new tables "Branch-customer" and "Customer-loan" but shows this results in information loss. An ideal decomposition would be lossless-join and dependency preserving, meaning the original and decomposed tables can be rejoined without information loss and functional dependencies are preserved.
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
36 views

Lecture Notes For DBMS: Decomposition

The document discusses decomposing a database table called "Lending" to address issues like data redundancy and integrity. It proposes decomposing the table into two new tables "Branch-customer" and "Customer-loan" but shows this results in information loss. An ideal decomposition would be lossless-join and dependency preserving, meaning the original and decomposed tables can be rejoined without information loss and functional dependencies are preserved.
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

Lecture Notes For DBMS

Consider the following table:


Lending
branch-name branch-city assets customer-name loan-number amount
Sadar Agra 200000 Ram L-12 12000
Sanjay-place Agra 100000 Ram L-13 13000
This table stores the information regarding loans. This table has following problems:
Since every branch is going to have several loans, the table will have one row for each
loan taken from a branch all of which will have same value for the columns branch-name,
branch-city and assets, repetition of data.
Updating the branch-city or assets of a particular branch will require updating each row
of this table and hence the operation will be costly.
If we miss any row without updating then there will be more than one value for a branch
city or assets of a branch, which means breaching the data integrity.
If there is a branch having no loans then we will not have any entry in this table and we
will not be able represent the complete information.
Decomposition
The above problem can be solved by decomposing the above table. The set of relations
R1, R2,Rn is a decomposition of relation R if R = R1 R2 Rn . It should be
noted that every pair Ri and Ri+1 of this set should have at least one common attribute so
that they can be combined back again using join operation.
But all decompositions of this table will not be free from problem.
Consider for example if we form two new tables out of our Lending table as follows
Branch-customer-schema = (branch-name, branch-city, assets, customer name)
Customer-loan-schema = (customer-name, loan-number, amount)
Then the resulting tables with data will be as follows:
Branch-customer
branch-name branch-city assets customer-name
Sadar Agra 200000 Ram
Sanjay-place Agra 100000 Ram

Customer-loan
customer-name loan-number amount
Ram L-12 12000
Ram L-13 13000

Now suppose to know the branch for loan L-12 we try to form join of these two we will
a table as follows:

Branch-customer Customer-loan =
branch-name branch-city assets customer-name loan-number amount
Sadar Agra 200000 Ram L-12 12000
Sadar Agra 200000 Ram L-13 13000
Sanjay-place Agra 100000 Ram L-12 12000
Sanjay-place Agra 100000 Ram L-13 13000

Department of Computer Science By: Dipendra Air


Lecture Notes For DBMS

According to this join both of the loans are taken from both of the branches. This is an
example of information loss. This occurred because the choice of Column to be kept
common in two tables after decomposition is wrong.
Lossless-Join Decomposition: A decomposition { R1, R2,Rn } of relation schema R is
lossless join decomposition if for all legal relations r on schema R,
r = R1 (r) R1 (r) Rn (r)
In other words after decomposition, when we join all of the decomposed tables with data
it should result in the original table with data as was before decomposition.
Otherwise it is called Lossy-join decomposition.
Dependency preservation: This is another desirable property of a decomposition.
Suppose it is given that a set F of functional dependencies holds on any relation based on
schema R. Then set of functional dependencies that holds on any relation subschema R1
is F1 that contains all the functional dependencies of F which contains attributes of only
R1. So if decomposition of R is { R1, R2,Rn } such that corresponding functional
dependencies which holds on them are { F1, F2,Fn } then following should be true.
F+ = {F1 F2 Fn}+.
Such a decomposition is called dependency preserving decomposition.
For example:
Consider the schema R = {A, B, C, D} such that following functional dependency holds
on it F = {AB, A BC, C D}.
Now suppose the decomposition of this R is R1= {A,B} and R2 = {B,C,D}, so the
functional dependencies which holds on R1 are F1= {AB} (Note: F1 should contain all
the functional dependencies in F which have only attributes of R1) and those on R2 are F2
={CD}. If we union F1 F2 is {AB, C D} which doesnt contain the A BC , so
it is not a dependency preserving decomposition.
If we decompose R into these relation schemas R1 ={A,B,C} and R2={C,D} then
F1={AB, A BC} and F2 ={CD} so F1 F2 is {AB, A BC, C D}.

Department of Computer Science By: Dipendra Air

You might also like