Scribd
Upload
14 views

Cosc411 M5.2 2023

The document discusses the concepts of fourth normal form and multivalued dependencies, which involve eliminating relationships where two attributes depend on a third attribute. It also covers fifth normal form and join dependencies, which involve decomposing a table if it can be recreated by joining subtables.

Uploaded by

Saleem Ahmad bello
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
14 views

Cosc411 M5.2 2023

The document discusses the concepts of fourth normal form and multivalued dependencies, which involve eliminating relationships where two attributes depend on a third attribute. It also covers fifth normal form and join dependencies, which involve decomposing a table if it can be recreated by joining subtables.

Uploaded by

Saleem Ahmad bello
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

COSC 411: DATABASE SYSTEMS II 2022/2023 SESSION

CONCEPT OF FUNCTIONAL DEPENDENCIES


(MODULE 5.2)
Fourth Normal Form and Multivalued Dependency
The Fourth Normal Form (4NF) is based on the elimination of Multivalued Dependencies
(MVDs). MVD is a database normalization where there are two attributes or columns in a table
that are independent of one another, but both depend on another attribute or column. This type of
dependency always requires at least three attributes or columns, because it consists of at least two
attributes that depend on another attribute. A table or relation with a multivalued dependency
violates the normalization standard of 4NF hence, it is necessary to break it into two tables. A
relation schema is in 4NF if and only if the following conditions are satisfied:
 It should be in 3NF (No transitive dependency).
 The relation should not have any multivalued dependency.
Condition for Multivalued Dependency
If X → Y, and for a single value of X there exists multiple values of Y that are independent on one
another, then the table has multivalued dependencies.
For example, consider the following table called Employees in (a). A tuple in this relation
represents the fact that an employee whose name is Emp_Name works on the project whose name
is Proj_Name and has a dependent whose name is Depd_Name. 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 combination of an employee’s dependent and an employee’s project. In the relation state
shown in (a), the employee with Emp_Name Anas works on two projects ‘EE’ and ‘GG’ and has
two dependents ‘ABL’ and ‘AMR’, and therefore there are four tuples to represent these facts
together. We can see that there is an obvious redundancy in the relation Employees—the dependent
information is repeated for every project and the project information is repeated for every
dependent.
(a) Employees: The Employees Relation with Two MVDs
Emp_Name Proj_Name Depd_Name
Anas EE ABL
Anas GG AMR
Anas EE AMR
Anas GG ABL

Page 1 of 4
COSC 411: DATABASE SYSTEMS II 2022/2023 SESSION

From the above table (Employees), the Multivalued Dependencies (MVDs) are as follows:
 Emp_Name →→ Proj_Name: The Emp_Name attribute multi-determines Proj_Name.
 Emp_Name →→ Depd_Name: The Emp_Name attribute multi-determines Depd_Name.
 Proj_Name and Depd_Name attributes are independent.
(b) To address this situation of MVDs, the concept of 4NF was proposed. Achieving 4NF typically
involves eliminating MVDs by repeated binary decompositions. Now we eliminate the
multivalued dependencies by decomposing the Employees table into Emp_Proj and Emp_Depd
tables, as shown in (i) and (ii) as follows:
i. Emp_Proj Table without MVDs:
Emp_Name Proj_Name
Anas EE
Anas GG

ii. Emp_Depd Table without MVDs:


Emp_Name Depd_Name
Anas ABL
Anas AMR

Therefore, the Employees relation is now in 4NF, because the multivalued dependencies have
been completely eliminated.

Fifth Normal Form Join Dependency


The 5NF is based on the elimination of Join Dependencies (JDs). Join Dependency (JD) occurs
when a relation can be recreated by joining multiple sub relations, and each of these sub relations
has a subset of the attributes of the original relation. This kind of dependency is related to Fifth
Normal Form (5NF). The 5NF is also called Project-Join Normal Form (PJNF). It is a level of
database normalization designed to reduce or eliminate redundancy in databases. If a JD is present
in a relation, carry out a multi-way decomposition into 5NF. It is important to note that such a
dependency is a peculiar semantic constraint that is difficult to detect in practice; therefore,
normalization into 5NF is rarely done in practice. For a relation to be in 5NF, it must satisfy the
following conditions:
 The relation must be in 4NF (No multivalued dependency).
 The relation cannot be decomposed further (No join dependency).

Page 2 of 4
COSC 411: DATABASE SYSTEMS II 2022/2023 SESSION

Condition for Join Dependency


A relation R satisfies a join dependency if R is equal to the join of sub relations R1 and R2 over X
where R1 and R2 are the decomposition R1 (X, Y) and R2 (Y, Z) of a given relation R (X, Y, Z).
The X, Y and Z are the attributes of the relation R. The sub relations R1 and R2 are a lossless
decomposition of the original relation R.
For example, consider our relation in (a) called Supplier. Suppose that the following additional
constraint always holds: Whenever a supplier s supplies part p, and a project j uses part p, and the
supplier s supplies at least one part to project j, then supplier s will also be supplying part p to
project j. This constraint can be restated in other ways and specifies a join dependency JD(R1, R2,
R3) among the three projections R1 (Sup_Name, Part_Name), R2 (Sup_Name, Proj_Name), and R3
(Part_Name, Proj_Name) of Supply.

(a) Supply: The relation Supply with no MVDs is in 4NF but not in 5NF because it has the JD(R1,
R2, R3).
Sup_Name Part_Name Proj_Name
AA HDD Project X
AA RAM Project Y
BB HDD Project Y
CC RAM Project Z
BB CPU Project X
BB HDD Project X
AA HDD Project Y

Therefore, the above relation Supply with the join dependency is decomposed into three relations
R1, R2, and R3 that are each in 5NF as shown in (b), because there are no multivalued dependencies
and no join dependency exists. Notice that applying a natural join to any two of these relations
produces spurious tuples, but applying a natural join to all three together does not. When R1, R2,
and R3 are combined together, will produce the original relation R, but that might not be true in all
cases. If the resultant relation is not equivalent to the original relation, then the original relation is
said to be in 5NF, provided it already satisfied the 4NF condition.

Page 3 of 4
COSC 411: DATABASE SYSTEMS II 2022/2023 SESSION

(b) Decomposing the relation Supply into the 5NF relations R1, R2, R3.
(i) R1 (Sup_Name, Part_Name)
Sup_Name Part_Name
AA HDD
AA RAM
BB HDD
CC RAM
BB CPU

(ii) R2 (Sup_Name, Proj_Name)


Sup_Name Proj_Name
AA Project X
AA Project Y
BB Project Y
CC Project Z
BB Project X

(iii) R3 (Part_Name, Proj_Name)


Part_Name Proj_Name
HDD Project X
RAM Project Y
HDD Project Y
RAM Project Z
CPU Project X

However, discovering Join Dependencies in practical databases with hundreds of attributes is next
to impossible. It can be done only with a great degree of intuition about the data on the part of the
designer. Therefore, the current practice of database design pays scant attention to them, and the
aspect remains limited to the theoretical concepts.

Page 4 of 4

You might also like