1. We have seen BCNF and 3NF.

• It is always possible to obtain a 3NF design without sacri cing 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-schema.

• As banker-name ! bname , we may want to express relationships between a banker and his or her branch.
• 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.

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 eciently, we either pay a high price in system performance or risk the integrity of the data.
  

  cname	banker-name	bname
  Bill Tom Mary null	John John John Tim	SFU SFU SFU Austin

  Figure 7.4: An instance of Banker-schema.

• 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.