Home | | **Database Management Systems** | | **FUNDAMENTALS OF Database Systems** | | **Database Management Systems** | Multivalued Dependency and Fourth Normal Form

Formal Definition of Multivalued Dependency

**Multivalued Dependency and Fourth Normal Form**

So far we have discussed the concept of functional dependency, which is
by far the most important type of dependency in relational database design
theory, and normal forms based on functional dependencies. However, in many
cases relations have constraints that cannot be specified as functional
dependencies. In this section, we discuss the concept of *multivalued dependency* (MVD) and define *fourth normal* *form, *which
is based on this dependency. A more formal discussion of MVDs and* *their properties is deferred to Chapter
16. Multivalued dependencies are a consequence of first normal form (1NF) (see
Section 15.3.4), which disallows an attribute in a tuple to have a *set of values*, and the accompanying
process of converting an unnormalized relation into 1NF*.* If we have two or more multivalued *independent* attributes in the same relation schema, we get into a
problem of having to repeat every value of one of the attributes with every value
of the other attribute to keep the relation state consistent and to maintain
the independence among the attributes involved. This constraint is specified by
a multivalued dependency.

For example, consider the relation EMP shown in
Figure 15.15(a). A tuple in this EMP relation
represents the fact that an employee whose name is Ename works on
the project whose name is Pname and has a dependent whose name is Dname. An
employee may work on several projects and may have several dependents, and the
employee’s projects and dependents are independent of one another. To keep the relation state
consistent, and to avoid any spurious relationship between the two independent
attributes, we must have a separate tuple to represent every combina-tion of an
employee’s dependent and an employee’s project. This constraint is spec

ified as a multivalued dependency on the EMP
relation, which we define in this section. Informally, whenever two *independent* 1:N relationships *A*:*B*
and *A*:*C* are mixed in the same relation, *R*(*A*, *B*, *C*), an MVD may arise.

**Formal Definition of
Multivalued Dependency**

**Definition. **A multivalued dependency** ***X*** **→→** ***Y*** **specified on relation schema** ***R*,** **where *X* and *Y* are both subsets
of *R*, specifies the following
constraint on any relation state *r* of
*R*: If two tuples *t*_{1} and *t*_{2}
exist in *r* such that *t*_{1}[X] = *t*_{2}[X], then

two
tuples *t*_{3} and *t*_{4} should also exist in *r* with the following properties,^{15}
where we use *Z* to denote (*R* – (*X*
∪ Y)):^{16}

*t*_{3}[*X*] =*
t*_{4}[*X*] =* t*_{1}[*X*] =* t*_{2}[*X*].

*t*_{3}[*Y*] =*
t*_{1}[*Y*] and* t*_{4}[*Y*] =* t*_{2}[*Y*].

*t*_{3}[*Z*] =*
t*_{2}[*Z*] and* t*_{4}[*Z*] =* t*_{1}[*Z*].

Whenever *X* →→ *Y* holds, we say that *X* **multidetermines**
*Y*. Because of the symme-try in the definition,
whenever *X* →→ *Y* holds in *R*, so does *X* →→ *Z*. Hence, *X* →→ *Y* implies *X* →→ *Z*, and therefore it is sometimes written
as *X* →→ *Y*|*Z*.

An MVD X →→ Y in R is called a **trivial MVD** if (a) *Y* is a subset of *X*, or
(b) *X* ∪ Y = *R*. For example, the relation EMP_PROJECTS in Figure 15.15(b) has the
trivial MVD Ename →→ Pname. An MVD that satisfies neither (a) nor (b) is called a **nontrivial MVD**. A trivial MVD will hold
in** ***any*** **relation state** ***r*** **of**
***R*; it is called triv-ial because
it does not specify any significant or meaningful constraint on *R*.

If we
have a *nontrivial MVD* in a relation,
we may have to repeat values redundantly in the tuples. In the EMP relation of Figure 15.15(a), the
values ‘X’ and ‘Y’ of Pname are
repeated with each value of Dname (or, by
symmetry, the values ‘John’ and ‘Anna’ of Dname are
repeated with each value of Pname). This
redundancy is clearly undesirable. However, the EMP schema is in BCNF because *no*
functional dependencies hold in EMP.
Therefore, we need to define a fourth normal form that is stronger than BCNF
and disallows relation schemas such as EMP. Notice
that relations con-taining nontrivial MVDs tend to be **all-key relations**—that is, their key is all their attributes taken
together. Furthermore, it is rare that such all-key relations with a
combinatorial occurrence of repeated values would be designed in practice.
However, recognition of MVDs as a potential problematic dependency is essential
in relational design.

We now
present the definition of **fourth normal
form (4NF)**, which is violated when a relation has undesirable multivalued
dependencies, and hence can be used to identify and decompose such relations.

**Definition. **A relation schema** ***R*** **is in 4**NF **with respect to a set of dependencies** ***F *(that includes
functional dependencies and multivalued dependencies) if, for* *every *nontrivial* multivalued dependency *X* →→ *Y* in *F*^{+17} *X* is a superkey for *R*.

We can
state the following points:

An all-key relation is always in BCNF since it has
no FDs.

An all-key relation such as the EMP relation in Figure 15.15(a),
which has no FDs but has the MVD Ename →→ Pname | Dname, is not in 4NF.

A relation that is not in 4NF due to a nontrivial
MVD must be decomposed to convert it into a set of relations in 4NF.

The decomposition removes the redundancy caused by
the MVD.

The
process of normalizing a relation involving the nontrivial MVDs that is not in
4NF consists of decomposing it so that each MVD is represented by a separate
rela-tion where it becomes a trivial MVD. Consider the EMP relation in Figure 15.15(a). EMP is not in 4NF because in the
nontrivial MVDs Ename →→ Pname
and Ename

Dname, and Ename is not a superkey of EMP. We decompose EMP into EMP_PROJECTS and EMP_DEPENDENTS, shown in Figure 15.15(b). Both EMP_PROJECTS and EMP_DEPENDENTS are in 4NF, because the MVDs Ename Pname in EMP_PROJECTS and Ename →→ Dname in EMP_DEPENDENTS are trivial MVDs. No other nontrivial MVDs hold in either EMP_PROJECTS or EMP_DEPENDENTS. No FDs hold in these relation schemas either.

Study Material, Lecturing Notes, Assignment, Reference, Wiki description explanation, brief detail

**Related Topics **

Copyright © 2018-2020 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.