It is always possible to obtain a 3NF design without sacrificing
lossless-join or dependency-preservation.
If we do not eliminate all transitive dependencies, we may need to
use null values to represent some of the meaningful relationships.
Repetition of information occurs.
These problems can be illustrated with Banker-schema.
As banker-name bname , we may want to express
relationships between a banker and his or her branch.
Figure 7.4: An instance of Banker-schema.
Figure 7.4 shows how we must either have a
corresponding value for customer name, or include a null.
Repetition of information also occurs.
Every occurrence of the banker's name must be accompanied by the branch
name.
If we must choose between BCNF and dependency preservation, it is generally
better to opt for 3NF.
If we cannot check for dependency preservation efficiently, we either
pay a high price in system performance or risk the integrity of the data.
The limited amount of redundancy in 3NF is then a lesser evil.
To summarize, our goal for a relational database design is
BCNF.
Lossless-join.
Dependency-preservation.
If we cannot achieve this, we accept
3NF
Lossless-join.
Dependency-preservation.
A final point: there is a price to pay for decomposition.
When we decompose a relation, we have to use natural joins or
Cartesian products to put the pieces back together.
This takes computational time.
bname , we may want to express
relationships between a banker and his or her branch.
