Properties of Decompositions
4.6 Properties of Decompositions
We revisit Decomposition in this section to review its desirable properties. Decomposition is breaking up a relational schema into smaller relations such that each of
the attributes is present in at least one of the new relations, and has a more optimized design. The underlying goal is to remove redundancy.
Database Fundamentals 102
4.6.1 Lossless and Lossy Decompositions
Decomposition of a relation R into relations X and Y is lossless if no information from the original relation is lost after the decomposition. In other words, the original relation can be constructed back from the decomposed relations and no spurious rows of information are added as data to the resulting rows.
It follows then, that if a decomposition results in loss of information from the original relation R then the decomposition is lossy and is obviously not a desirable property.
Let R be a relation with functional dependency F that is decomposed into R 1 and R 2 . Then the decomposition is lossless if one of the following FDs is true for the decomposed
relations R 1 and R 2 :
R 1 ∩R 2 → R 1 or R 1 ∩R 2 → R 2
More simply if the common attributes in R 1 and R 2 (i.e. R 1 ∩R 2 ) form a super key for either R 1 or R 2 , then the original relation R has undergone a lossless decomposition into R 1 and R 2 .
An essential property of decomposition in relational database design is that they should be lossless. A lossless join of decomposed relation X and Y into R results in no information loss and no addition of extra misguiding information when joining X and Y to get back the original relation R.
Example
Consider the relation employee as follows:
EMP_ID EMP_NAME WORK_EXP DEPT_ID
DEPT_NAME
A desired lossless decomposition for the above relation employee is as follows:
DEPT_ID DEPT_NAME EMP_ID EMP_NAME WORK_EXP DEPT_ID Department relation
Employee relation
In the above, (Department) ∩ (Employee) = DEPT_ID and DEPT_ID → { DEPT_ID , DEPT_NAME}, that is, DEPT_ID is a super key for the Department relation and the decomposition is lossless.
A lossy decomposition for the above would be:
DEPT_ID DEPT_NAME EMP_NAME EMP_ID EMP_NAME WORK_EXP Department relation
Employee relation
In the above, (Department) ∩ (Employee) = EMP_NAME which is not a super key for department or employee table hence the decomposition is lossy.
Chapter 4 – Relational Database Design 103 From the above example, an EMP_NAME is not guaranteed to be unique and hence we
cannot say for sure which employee works for which department. This shows the result of information loss.
4.6.2 Dependency-Preserving Decompositions
Decomposition of a relation R into relations X and Y is dependency-preserving when all the FDs that hold on X and Y separately, when put together correspond to all the FDs that exist
in the closure of functional dependency F + that hold on the original relation, R. On a projection of a set of FD of relation R, F is a set of its attributes, X is the set of FDs
of the form C → D where C and D both are in X. This is denoted as F x . Thus a decomposition of a relation R into X and Y is dependency-preserving if the union of
the closure set of FDs on X and Y is equivalent to the closure of set of functional
dependencies F + that holds on R. That is, F x UF y implies F where F x are the set of FDs in F + that can be checked in only X, and F y are the set of FDs that can be checked only in
Y . It follows from the above that given a dependency preserving decomposition, if we can
check all the constraints against the decomposed table only, we need not check it against the original table.
Dependency-preserving decomposition does not imply a lossless join decomposition and vice versa. While lossless join is a must during decomposition, dependency-preservation may not be achieved every time.