# Decomposition

Decomposition is the important topic of the Database Management System. Moreover, Freestudy9 has all kind of important topic and information about the subject.

- Decomposition is the process of breaking down given relation to two or more relations.
- Here, relation R replaced by two or more relations in such a way that –
- Each new relation contains a subset of the attributes of R, and
- Together, they all include all tuples and attributes of R.

- Relational database design process starts with a universal relation schema R = {A1, A2, A3,…, An), which includes all the attributes of the database. The universal relation states that every attribute name is unique.
- Also, Using functional dependencies, this universal relation schema decomposed into a set of relation schemas D = {R1, R2, R3,…, Rm}.
- Now, D becomes the relational database schema and D referred as decomposition of R.
- Generally, decomposition used to eliminate the pitfalls of the poor database design during the normalization process.
- So, For example, consider the relation Account_Branch given in figure:

- This relation can be divided into two different relations
- Account (
__Ano__, Balance, Bname) - Branch (
__Bname__, Baddress)

- Account (
- These two relations are shown in below figure

- Moreover, A decomposition of relation can be either lossy decomposition or lossless decomposition.
- Also, There are two types of decomposition
- lossy decomposition
- lossless decomposition (non-loss decomposition)

**Lossy Decomposition**

- The decomposition of relation R into R1 and R2 is lossy when the join of R1 and R2 does not yield the same relation as in R.
- This also referred as lossy-join de composition.
- The disadvantage of such kind of descomposition is that some information is lost during retrieval of original relation. And so, such kind of de-composition referred as lossy decomposition.
- From the practical point of view, decompositions should not be lossy decomposition.

*Example of ***Lossy Decomposition**

- A figure shows a relation Account. This relation decomposed into two relations Acc_Bal and Bal_Branch.
- Now, when these two relations joined on the common attributeBalance, the resultant relation will look like Acct_Joined. This Acct_Joined relation contains rows in addition to those in original relation Account.
- Here, it is not possible to specify that in which branch account A01 or A02 belongs.
- So, information has lost by this decompositions and then join operation.

- In other words, decompositions is lossy if decompose into R1 and R2 and again combine (join) R1 and R2 we cannot get the original table as R1, over X, where R is an original relation, R1 and R2 decomposed relations, and X is a common attribute between these two relations.

### Lossless (Non-loss) Decomposition

- The decompositions of relation R into R1 and R2 is lossless when the join of R1 and R2 produces the same relation as in R.
- This also referred as a non-additive (non-loss) de-composition.
- All de-compositions must be lossless.

*Example *

- Again, the same relation Account decomposed into two relations Acct_Bal and Acct_Branch.
- Now, when these two relations joined on the common column Ano, the resultant relation will look like Acc_Joined relation. This relation exactly same as that of original relation Account.
- In other words, all the information of original relation preserved here.
- Moreover, In lossless de-composition, no any fake tuples generated when a natural join applied to the relations in the decomposition.
- In other words, de-composition is lossy if R = join of R1 and R2, over X, where R is an original relation, R1 an R2 decomposed relations, and x is a common attribute between these two relations.

**Related Terms**

DBMS Short Note, Functional Dependency Closure, Armstrong’s axioms, Engineering Study.

## Leave a Reply