Comparison of BCNF and 3NF

1. We have seen BCNF and 3NF.
   • 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.
2. These problems can be illustrated with Banker-scheme.
   • As banker bname , we may want to express relationships between a banker and his or her branch.
   • Figure 6.9 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.
3. 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.
4. To summarize, our goal for a relational database design is
   • BCNF.
   • Lossless-join.
   • Dependency-preservation.
5. If we cannot achieve this, we accept
   • 3NF
   • Lossless-join.
   • Dependency-preservation.
6. 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.