Unit: 6 Data Normalization

Functional Dependency
The functional dependency is a relationship that exists between two attributes.

It typically exists between the primary key and non-key attribute within a table.

Key Terms

 Determinant: The attribute on the left side of the dependency (in X → Y, X

is the determinant).
 Dependent: The attribute on the right side of the dependency (in X → Y, Y
is the dependent).

Examples of Functional Dependency

Consider a table Students with columns StudentID, Name, and DOB:

 StudentID → Name: The StudentID uniquely identifies a student’s name.

Each StudentID corresponds to one Name.
 StudentID → DOB: The StudentID uniquely identifies the date of birth of
each student.

Armstrong’s axioms/properties of functional dependencies:

Reflexivity: If Y is a subset of X, then X→Y holds by reflexivity rule

Example, {roll_no, name} → name is valid.

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

Multivalued Dependency
o Multivalued dependency occurs when two attributes in a table are
independent of each other but, both depend on a third attribute.
o A multivalued dependency consists of at least two attributes that are
dependent on a third attribute that's why it always requires at least three
attributes.
Example:

Suppose there is a bike manufacturer company which produces two colors(white

and black) of each model every year.

BIKE_MODEL MANUF_YEAR COLOR

M2011 2008 White

M2001 2008 Black

M3001 2013 White

M3001 2013 Black

M4006 2017 White

M4006 2017 Black

Here columns COLOR and MANUF_YEAR are dependent on BIKE_MODEL and
independent of each other.

In this case, these two columns can be called as multivalued dependent on

BIKE_MODEL.

The representation of these dependencies is shown below:

BIKE_MODEL → → MANUF_YEAR

BIKE_MODEL → → COLOR

Join dependency:
A join dependency in a database occurs when a table can be divided into multiple
smaller tables, and those smaller tables can be joined back together to recreate the
original table without losing any information.

Example:
Student Course Instructor
John Math Dr. Smith
John Math Dr. Brown
John Science Dr. White
Mary Math Dr. Smith
Mary Science Dr. White

Split into Two Tables to Resolve Join Dependency

Table 1: Student-Course

Student Course
John Math
John Science
Mary Math
Mary Science

Table 2: Course-Instructor

Course Instructor
Math Dr. Smith
Math Dr. Brown
Science Dr. White

Types of Functional Dependencies

Trivial Functional Dependency

A functional dependency is trivial if the dependent attribute is already a subset of

the determinant.

 Notation: A→AA → AA→A or {A,B}→A\{A, B\} → A{A,B}→A

 Example: In a table with attributes StudentID and Name, StudentID →
StudentID is trivial because StudentID is already a part of the determinant.

Non-Trivial Functional Dependency

A functional dependency is non-trivial if the dependent attribute is not a subset of

the determinant.

 Notation: A→BA → BA→B (where B is not a subset of A)

  Example: In a table with StudentID and DOB, if StudentID → DOB, this is
non-trivial because DOB is not part of the StudentID.

Full Functional Dependency

A functional dependency is full if an attribute is dependent on an entire set of

attributes and not on any subset of that set.

 Notation: {A,B}→C\{A, B\} → C{A,B}→C, where C depends on both A

and B, and neither A → C nor B → C.

 Example: In a table with StudentID, CourseID, and Grade, if {StudentID,

CourseID} → Grade, then Grade is fully functionally dependent on both
StudentID and CourseID.

Partial Functional Dependency

A functional dependency is partial if an attribute depends on part of a composite

key (not the whole key).

Partial dependencies are eliminated in the second normal form (2NF).

 Notation: A→CA → CA→C, where C depends on only part of a composite

key A.
 Example: In a table with a composite key {StudentID, CourseID} and
attribute StudentName, if StudentID → StudentName, this is a partial
dependency because StudentName depends only on StudentID and not on
CourseID.

Transitive Functional Dependency

A transitive dependency exists when one attribute is indirectly dependent on

another attribute through a third attribute.

 Notation: If A→BA → BA→B and B→CB → CB→C, then A→CA →

CA→C is a transitive dependency.
 Example: In a table with StudentID, AdvisorID, and AdvisorName, if
StudentID → AdvisorID and AdvisorID → AdvisorName, then there is a
transitive dependency StudentID → AdvisorName.
Anomalies in RDBMS
An anomaly refers to a problem or inconsistency that arises when data isn’t
structured or managed properly.

Anomalies can cause issues with data accuracy, consistency, and integrity.

In databases, some common anomalies include:

 Insertion Anomaly: Problems when adding new data.

 Deletion Anomaly: Problems when deleting data.
 Update Anomaly: Problems when updating data.

Insertion Anomaly: You can’t add new data unless other data is also added.

Example: Can’t add a course unless it’s linked to a student.

Deletion Anomaly: Deleting some data also removes other important information.

Example: Removing a student accidentally removes course info.

Update Anomaly: Changing data in one place requires changing it in multiple

places.

Example: Updating a professor’s contact info in many records.

Redundancy: Storing duplicate data, which wastes space and can cause mistakes.

Normalization:
Normalization in a Database Management System (DBMS) is the process of
organizing data to reduce redundancy (duplicate data) and improve data integrity.
Advantages of Normalization

o Normalization helps to minimize data redundancy.

o Greater overall database organization.
o Data consistency within the database.
Disadvantages of Normalization

1. Complex to apply on large databases.

2. Requires combining rules for useful results.
3. Needs strong database theory knowledge.

First Normal Form (1NF):

o A relation will be 1NF if it contains an atomic value.

o It states that an attribute of a table cannot hold multiple values. It must hold
only single-valued attribute.
o First normal form disallows the multi-valued attribute, composite attribute,
and their combinations.

Example: Not in 1NF:

Student_ID Name Subjects

1 John Doe Math, Science
2 Jane Smith English, Math

In 1NF (separate rows for each subject):

Student_ID Name Subject

1 John Doe Math
1 John Doe Science
2 Jane Smith English
2 Jane Smith Math
Second Normal Form (2NF):

It must be in 1NF, and all non-key attributes must depend fully on the
primary key (eliminates partial dependencies).

 Example: Suppose we have a composite key (Student_ID, Course_ID).

 Not in 2NF:

Student_ID Course_ID Course_Name Instructor

1 101 Math Mr. Brown
1 102 Science Dr. Smith

Here, Course_Name and Instructor only depend on Course_ID, not the whole
composite key.

In 2NF (split into two tables):

Table 1 (Student-Course):

Student_ID Course_ID
1 101
1 102

Table 2 (Course-Details):

Course_ID Course_Name Instructor

101 Math Mr. Brown
102 Science Dr. Smith

Third Normal Form (3NF)

 o A relation will be in 3NF if it is in 2NF and not contain any transitive partial
dependency.
o 3NF is used to reduce the data duplication. It is also used to achieve the data
integrity.
o If there is no transitive dependency for non-prime attributes, then the
relation must be in third normal form.

Example:

Not in 3NF:

Student_ID Name Course_ID Instructor Department

1 John Doe 101 Mr. Brown Science

Here, Department depends on Instructor, not directly on the primary key

Student_ID.

In 3NF (split tables to eliminate transitive dependency):

Table 1 (Student-Course):

Student_ID Name Course_ID

1 John Doe 101

Table 2 (Instructor-Department):

Instructor Department
Mr. Brown Science

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.

Example

Student_ID Course Instructor

1 Math Mr. Brown
2 Math Mr. Brown
3 Science Dr. Smith
4 Science Dr. Smith

Functional Dependencies:

Course → Instructor (Each course is taught by one instructor)

Student_ID, Course → Instructor (A student-course pair uniquely determines

the instructor)

Here, Course is not a superkey, but it determines Instructor. This violates BCNF
because every determinant must be a superkey.

Converting to BCNF

Split the table into two:

Course-Instructor Table:

Course Instructor
Math Mr. Brown
Science Dr. Smith

Student-Course Table:
 Student_ID Course
1 Math
2 Math
3 Science
4 Science

Transaction & Concurrency Control:

Transaction
The transaction is a set of logically related operation. It contains a group of tasks.

A transaction is an action or series of actions. It is performed by a single user to

perform operations for accessing the contents of the database.
transaction access data using two operations –
Read
Write
Properties of transaction –
Transaction have 4 basic properties which are called ACID.

Atomicity: Every transaction is treated as a single unit, meaning it either

completes entirely or not at all. If any part of the transaction fails, the whole
transaction is canceled to prevent incomplete changes.

Consistency: A transaction ensures that the database remains in a valid state,

maintaining all predefined rules and constraints. The system ensures that any data
changes follow the correct format and business rules.

Isolation: Each transaction operates independently, so multiple transactions

happening simultaneously don’t interfere with each other. This ensures data
accuracy even when many users access the system at once.

Durability: Once a transaction is completed, its results are permanently saved,

even if there’s a system failure right afterward. This guarantees that completed
changes are never lost.
States of Transaction

A transaction state refers to the different stages a transaction goes through during
its execution.

These stages help track its progress and determine if it’s completed successfully or
if it needs to be rolled back.

There are usually four key states:

Active: The transaction is being processed, and actions are still being performed.

Partially Committed: The transaction has finished its operations, but the changes
are not yet final.

Committed: The transaction is successful, and all changes are saved permanently
to the database.

Aborted: Something went wrong, and the transaction is canceled. All changes are
undone.