Discussion of Normalization Algorithms and Alternative Relational Designs

16.4.2 Discussion of Normalization Algorithms and Alternative Relational Designs

One of the problems with the normalization algorithms we described is that the

566 Chapter 16 Relational Database Design Algorithms and Further Dependencies

the database attributes. This is not a simple task for a large database with hundreds of attributes. Failure to specify one or two important dependencies may result in an undesirable design. Another problem is that these algorithms are not deterministic in general. For example, the synthesis algorithms (Algorithms 16.4 and 16.6) require the specification of a minimal cover G for the set of functional dependencies F. Because there may be in general many minimal covers corresponding to F, as we illustrated in Example 2 of Algorithm 16.6 above, the algorithm can give different designs depending on the particular minimal cover used. Some of these designs may not be desirable. The decomposition algorithm to achieve BCNF (Algorithm 16.5) depends on the order in which the functional dependencies are supplied to the algo- rithm to check for BCNF violation. Again, it is possible that many different designs may arise corresponding to the same set of functional dependencies, depending on the order in which such dependencies are considered for violation of BCNF. Some of the designs may be preferred, whereas others may be undesirable.

It is not always possible to find a decomposition into relation schemas that pre- serves dependencies and allows each relation schema in the decomposition to be in BCNF (instead of 3NF as in Algorithm 16.6). We can check the 3NF relation schemas in the decomposition individually to see whether each satisfies BCNF. If some relation schema R i is not in BCNF, we can choose to decompose it further or to leave it as it is in 3NF (with some possible update anomalies).

To illustrate the above points, let us revisit the LOTS1A relation in Figure 15.13(a). It is a relation in 3NF, which is not in BCNF as was shown in Section 15.5. We also showed that starting with the functional dependencies (FD1, FD2, and FD5 in Figure 15.13(a)), using the bottom-up approach to design and applying Algorithm

16.6, it is possible to either come up with the LOTS1A relation as the 3NF design (which was called design X previously), or an alternate design Y which consists of three relations S 1 ,S 2 ,S 3 (design Y), each of which is a 3NF relation. Note that if we test design Y further for BCNF, each of S 1 ,S 2 , and S 3 turn out to be individually in BCNF. The design X, however, when tested for BCNF, fails the test. It yields the two relations S 1 and S 3 by applying Algorithm 16.5 (because of the violating functional dependency A → C ). Thus, the bottom-up design procedure of applying Algorithm

16.6 to design 3NF relations to achieve both properties and then applying Algorithm 16.5 to achieve BCNF with the nonadditive join property (and sacrific- ing functional dependency preservation) yields S 1 ,S 2 ,S 3 as the final BCNF design by one route (Y design route) and S 1 ,S 3 by the other route (X design route). This happens due to the multiple minimal covers for the original set of functional dependencies. Note that S 2 is a redundant relation in the Y design; however, it does not violate the nonadditive join constraint. It is easy to see that S 2 is a valid and meaningful relation that has the two candidate keys ( L , C ), and P placed side-by- side.

Table 16.1 summarizes the properties of the algorithms discussed in this chapter so far.

16.5 Futher Discussion of Multivalued Dependencies and 4NF 567

Table 16.1 Summary of the Algorithms Discussed in This Chapter Algorithm Input

Output

Properties/Purpose

Remarks

16.1 An attribute or a set

The closure of a key of attributes X, and a the closure of X with attributes that can be is the entire relation set of FDs F

A set of attrbutes in Determine all the

respect to F

functionally deter- mined from X

Multiple minimal dependencies F

16.2 A set of functional

The minimal cover

To determine the

of functional

minimal cover of a

covers may exist—

dependencies

set of dependencies F depends on the order of selecting function- al dependencies

16.2a Relation schema R

The entire relation R with a set of func-

Key K of R

To find a key K

(that is a subset of R) is always a default tional dependencies

superkey

16.3 A decomposition D Boolean result: yes or Testing for nonaddi- See a simpler test of R and a set F of

tive join decomposi- NJB in Section 16.2.4 functional depen-

no for nonadditive

for binary decompo- dencies

join property

tion

sitions

A set of relations in Dependency preser- No guarantee of sat- set of functional

16.4 A relation R and a

isfying lossless join dependencies F

No guarantee of set of functional

16.5 A relation R and a

A set of relations in Nonadditive join

dependency preser- dependencies F

May not achieve set of functional

16.6 A relation R and a

A set of relations in Nonadditive join

BCNF, but achieves dependencies F

3NF

and dependency-

preserving decompo- all desirable proper- sition

ties and 3NF

No guarantee of set of functional and 4NF

16.7 A relation R and a

A set of relations in Nonadditive join

dependency preser- multivalued depen-

decomposition

vation dencies