Functional dependencies in DBMS

In a relational database management, functional dependency is a

concept that specifies the relationship between two sets of attributes
where one attribute determines the value of another attribute. It is
denoted as X → Y, where the attribute set on the left side of the
arrow, X is called Determinant, and Y is called the Dependent.

roll_no name dept_name dept_building

42 abc CO A4

43 pqr IT A3

44 xyz CO A4

45 xyz IT A3

46 mno EC B2

47 jkl ME B2

From the above table we can conclude some valid functional

dependencies:
 roll_no → { name, dept_name, dept_building },→ Here, roll_no can
determine values of fields name, dept_name and dept_building, hence
a valid Functional dependency
 roll_no → dept_name , Since, roll_no can determine whole set of
{name, dept_name, dept_building}, it can determine its subset
dept_name also.
 dept_name → dept_building , Dept_name can identify the
dept_building accurately, since departments with different dept_name
will also have a different dept_building
 More valid functional dependencies: roll_no → name, {roll_no, name}
⇢ {dept_name, dept_building}, etc.

Here are some invalid functional dependencies:

 name → dept_name Students with the same name can have different
dept_name, hence this is not a valid functional dependency.
 dept_building → dept_name There can be multiple departments in
the same building. Example, in the above table departments ME and
 EC are in the same building B2, hence dept_building → dept_name is
an invalid functional dependency.
 More invalid functional dependencies: name → roll_no, {name,
dept_name} → roll_no, dept_building → roll_no, etc.

Armstrong’s axioms/properties of functional dependencies:

1. Reflexivity: If Y is a subset of X, then X→Y holds by reflexivity rule
Example, {roll_no, name} → name is valid.
2. Augmentation: If X → Y is a valid dependency, then XZ → YZ is also
valid by the augmentation rule.
Example, {roll_no, name} → dept_building is valid, hence {roll_no,
name, dept_name} → {dept_building, dept_name} is also valid.
3. Transitivity: If X → Y and Y → Z are both valid dependencies, then
X→Z is also valid by the Transitivity rule.
Example, roll_no → dept_name & dept_name → dept_building, then
roll_no → dept_building is also valid.

Types of Functional Dependencies in DBMS

1. Trivial functional dependency
2. Non-Trivial functional dependency

1. Trivial Functional Dependency

In Trivial Functional Dependency, a dependent is always a subset of
the determinant. i.e. If X → Y and Y is the subset of X, then it is called
trivial functional dependency
Example:
roll_no name age

42 abc 17

43 pqr 18

44 xyz 18

Here, {roll_no, name} → name is a trivial functional dependency, since

the dependent name is a subset of determinant set {roll_no,
name}. Similarly, roll_no → roll_no is also an example of trivial
functional dependency.

2. Non-trivial Functional Dependency

In Non-trivial functional dependency, the dependent is strictly not a
subset of the determinant. i.e. If X → Y and Y is not a subset of X, then
it is called Non-trivial functional dependency.
Example:
roll_no name age

42 abc 17

43 pqr 18

44 xyz 18

Here, roll_no → name is a non-trivial functional dependency, since the

dependent name is not a subset
of determinant roll_no. Similarly, {roll_no, name} → age is also a non-
trivial functional dependency, since age is not a subset of {roll_no,
name}

Introduction of Database
Normalization
Normalization is the process of minimizing redundancy from a relation or
set of relations. Redundancy in relation may cause insertion, deletion, and
update anomalies. So, it helps to minimize the redundancy in
relations. Normal forms are used to eliminate or reduce redundancy in
database tables.

Data modification anomalies can be categorized into three types:

o Insertion Anomaly: Insertion Anomaly refers to when one cannot insert a

new tuple into a relationship due to lack of data.
o Deletion Anomaly: The delete anomaly refers to the situation where the
deletion of data results in the unintended loss of some other important
data.
o Updatation Anomaly: The update anomaly is when an update of a single
data value requires multiple rows of data to be updated.

Normal Description
Form

1NF A relation is in 1NF if it contains an atomic value.

2NF A relation will be in 2NF if it is in 1NF and all non-key attributes are fully
functional dependent on the primary key.

3NF A relation will be in 3NF if it is in 2NF and no transition dependency exists.

BCNF A stronger definition of 3NF is known as Boyce Codd's normal form.

4NF A relation will be in 4NF if it is in Boyce Codd's normal form and has no
multi-valued dependency.

5NF A relation is in 5NF. If it is in 4NF and does not contain any join
dependency, joining should be lossless.

First Normal Form

First Normal Form is defined in the definition of relations (tables) itself. This rule
defines that all the attributes in a relation must have atomic domains. The values
in an atomic domain are indivisible units.
1. First Normal Form (1NF): This is the most basic level of normalization.
In 1NF, each table cell should contain only a single value, and each
 column should have a unique name. The first normal form helps to
eliminate duplicate data and simplify queries.

Example :
ID Name Courses
------------------
1 A c1, c2
2 E c3
3 M C2, c3
In the above table, Course is a multi-valued attribute so it is not in 1NF.
Below Table is in 1NF as there is no multi-valued attribute:
ID Name Course
------------------
1 A c1
1 A c2
2 E c3
3 M c2
3 M c3

Second Normal Form (2NF)

A relation that is in First Normal Form and every non-primary-key
attribute is fully functionally dependent on the primary key, then the
relation is in Second Normal Form (2NF).
Second Normal Form (2NF): 2NF eliminates redundant data by requiring
that each non-key attribute be dependent on the primary key. This means
that each column should be directly related to the primary key, and not to
other columns.
Example-1: Consider table as following below.

STUD_NO COURSE_NO COURSE_FEE

1 C1 1000
2 C2 1500
1 C4 2000
4 C3 1000
4 C1 1000
2 C5 2000

{Note that, there are many courses having the same course fee. } Here,
COURSE_FEE cannot alone decide the value of COURSE_NO or
STUD_NO; COURSE_FEE together with STUD_NO cannot decide the
value of COURSE_NO; COURSE_FEE together with COURSE_NO
cannot decide the value of STUD_NO; Hence, COURSE_FEE would be a
non-prime attribute, as it does not belong to the one only candidate key
{STUD_NO, COURSE_NO} ; But, COURSE_NO -> COURSE_FEE, i.e.,
COURSE_FEE is dependent on COURSE_NO, which is a proper subset
of the candidate key. Non-prime attribute COURSE_FEE is dependent on
a proper subset of the candidate key, which is a partial dependency and
so this relation is not in 2NF. To convert the above relation to 2NF, we
need to split the table into two tables such as : Table 1: STUD_NO,
COURSE_NO Table 2: COURSE_NO, COURSE_FEE

Third Normal Form (3NF)

A relation that is in First and Second Normal Form and in which no non-
primary-key attribute is transitively dependent on the primary key, then it
is in Third Normal Form (3NF).
A relation is in third normal form, if there is no transitive dependency for
non-prime attributes as well as it is in second normal form.
Note – If A->B and B->C are two FDs then A->C is called transitive
dependency.
Example-1:
In relation STUDENT given in Table 4,
FD set:
{STUD_NO -> STUD_NAME, STUD_NO -> STUD_STATE,
STUD_STATE -> STUD_COUNTRY, STUD_NO -> STUD_AGE}

Candidate Key:
{STUD_NO}
For this relation in table 4, STUD_NO -> STUD_STATE and
STUD_STATE -> STUD_COUNTRY are true. So STUD_COUNTRY is
transitively dependent on STUD_NO. It violates the third normal form. To
convert it in third normal form, we will decompose the relation STUDENT
(STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE,
STUD_COUNTRY_STUD_AGE) as:
STUDENT (STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE, STUD_AGE)
STATE_COUNTRY (STATE, COUNTRY)

Boyce Codd normal form (BCNF)

o BCNF is the advance version of 3NF. It is stricter than 3NF.
o A table is in BCNF if every functional dependency X → Y, X is the super key
of the table.
o For BCNF, the table should be in 3NF, and for every FD, LHS is super key.
Advantages of Normalization
o Normalization helps to minimize data redundancy.
o Greater overall database organization.
o Data consistency within the database.
o Much more flexible database design.
o Enforces the concept of relational integrity

What is Inclusion Dependency?

In a database management system (DBMS), an inclusion dependency
(IND) is a type of constraint which specifies that the values in one column
or set of columns (the dependent set) must be a subset of the values in
another column or set of columns (the referenced set).

Here is an example of an inclusion dependency in a hypothetical database:

Suppose we have two tables, "Orders" and "Customers". The "Orders"
table has columns "order_id", "customer_id", and "order_date". The
"Customers" table has columns "customer_id", "customer_name", and
"customer_email".
We can say that the "customer_id" column in the "Orders" table is a
dependent set, and the "customer_id" column in the "Customers" table is a
referenced set. We can then express an inclusion dependency as follows:
Orders[customer_id] ⊆ Customers[customer_id]

Multivalued Dependency (MVD) in DBMS

MVD or multivalued dependency means that for a single value of attribute
‘a’ multiple values of attribute ‘b’ exist. We write it as,
a --> --> b
It is read as: a is multi-valued dependent on b.
Suppose a person named Geeks is working on 2 projects Microsoft and
Oracle and has 2 hobbies namely Reading and Music. This can be
expressed in a tabular format in the following way.
Project and Hobby are multivalued attributes as they have more than one
value for a single person i.e., Geeks.

Lossless Decomposition in DBMS

Decomposition of a relation is done when a relation in relational model is
not in appropriate normal form. Relation R is decomposed into two or
more relations if decomposition is lossless join as well as dependency
preserving.
Lossless Join Decomposition
If we decompose a relation R into relations R1 and R2,
 Decomposition is lossy if R1 ⋈ R2 ⊃ R
 Decomposition is lossless if R1 ⋈ R2 = R

The original relation and relation reconstructed from joining decomposed

relations must contain same number of tuples if number is increased or
decreased then it is Losssy Join decomposition.
Lossless join decomposition ensures that never get the situation where
spurious tuple are generated in relation, for every value on the join
attributes there will be a unique tuple in one of the relations.
Lossless join decomposition is a decomposition of a relation R into
relations R1, R2 such that if we perform a natural join of relation R1 and
R2, it will return the original relation R. This is effective in removing
redundancy from databases while preserving the original data.
In other words by lossless decomposition, it becomes feasible to
reconstruct the relation R from decomposed tables R1 and R2 by using
Joins.