Suppose that the tables instructor
and department
are combined via natural join.
This relation design is not good because:
- There are repetitions of information.
- Null values must be used when a new
department
with noinstructor
is added.
However, not all combined schemas result in repetitions of information.
Decomposition
The only way to avoid the repetition-of-information problem in the previous example is to decompose it into two schemas: instructor
and department
.
However, not all decompositions are good. Consider the decomposition
Relation | Attributes |
---|---|
employee | ID, name, street, city, salary |
into
Relation | Attributes |
---|---|
employee1 | ID, name |
employee2 | name, street, city, salary |
The problem arises when there are multiple employees with the same name.
Such decomposition is unable to represent certain important facts about the relation before the decomposition. This kind of decomposition is referred to as a lossy decomposition. Conversely, those that are not are referred to as lossless decomposition.
Lossless decomposition
Let be a relation, be a relation schema of and let form a decomposition of . In other words, .
The decomposition is said to be lossless if there is no loss of information by replacing with . Or equivalently,
Conversely, a decomposition is said to be lossy if
Definitions with functional dependencies
Functional dependencies can be used to show when certain decompositions are lossless.
Consider the decomposition of into . The sufficient condtion for it to be a lossless decomposition is that at least one of the following dependencies is in :
Design goals of relational database
The primary goal for a relational database design is:
However, if all three of the goals cannot be achieved, then one of the followings is accepted:
- Lossless BCNF: Lack of dependency preservation
- 3NF: More redundancy