Unit II

Database Design
ER Diagrams – Functional Dependencies – Non-Loss Decomposition Functional
Dependencies – First Normal Form – Second Normal Form – Third Normal Form –
Dependency Preservation – Boyce/Codd Normal Form – Multi-Valued Dependencies and
Fourth Normal Form – Join Dependencies and Fifth Normal Form

ER Diagram

Functional Dependencies
Functional dependency in DBMS, as the name suggests is a relationship between attributes of
a table dependent on each other.
A→B
This means that if you know the value of A, you can figure out the value of B.
 Student Id Name Email
1 Alice [email protected]
2 Bob [email protected]
3 Charlie [email protected]

StudentID → Name: If you know the StudentID, you can uniquely determine the Name.
StudentID → Email: If you know the StudentID, you can uniquely determine the Email.
In other words, knowing the StudentID is enough to find out both the Name and the Email.
Types of Functional dependencies
1. Trivial Functional Dependency
A functional dependency is trivial when the right-hand side (dependent attribute) is a subset
of the left-hand side (determinant attribute). In other words, it's a dependency where the
attribute(s) on the right are already part of the attribute(s) on the left.
Example: A → A
Here, A determines A, which is trivially true because any attribute always determines itself. It
doesn’t provide any useful information.
Another Example: StudentID, Name → Name
This is also trivial because the attribute Name is part of the left-hand side (the combination of
StudentID and Name), so StudentID, Name → Name is trivially true.
2. Non-Trivial Functional Dependency
A non-trivial functional dependency is one where the right-hand side is not a subset of the
left-hand side. This means that the dependency gives us some useful information because the
attribute on the right depends on the attributes on the left.
Example: StudentID → Name
In this case, StudentID determines Name, and Name is not a part of StudentID, so it's a non-
trivial functional dependency.
Another Example: StudentID → Email
Here, StudentID determines Email, and Email is not part of StudentID, making it a non-trivial
dependency.
3. Completely Non-Trivial Functional Dependency
A completely non-trivial functional dependency is a stronger form of non-trivial dependency.
In this case, the left-hand side of the functional dependency is not a superset of the right-hand
side, and the dependency is more "non-obvious." In simple terms, it's a dependency that can’t
be simplified and is not trivial in any way.
Example: StudentID, Course → Teacher
In this case, StudentID and Course together decide Teacher, but Teacher is completely
different from them. Since there is no common attribute, this is completely non-trivial.

Non-Loss Decomposition Functional Dependencies

Lossless decomposition in DBMS is a technique used in database management systems to
break down a large table into smaller tables while preserving all the information contained in
the original table. This means that no data is lost during the decomposition process. The goal
of lossless decomposition is to eliminate redundancy and improve the efficiency of the
database. It involves identifying and separating out functional dependencies within the table
so that each smaller table contains only the relevant information for a particular purpose.
To ensure a lossless decomposition, the following conditions must be met:
Dependency Preservation: The dependencies between the attributes of the original relation
must be preserved in the decomposed relations. In other words, all functional dependencies in
the original relation must be represented in the decomposed relations.
Join Preservation: The decomposition should not result in the loss of any information that
could be obtained by joining the decomposed relations back together. This means that the
original relation should be reconstructed without any loss of data.
Minimal Redundancy: The decomposed relations should not contain any redundant data.
This means that each attribute should be represented in only one relationship and that there
should be no unnecessary duplication of information.
Lossless-join Property: The decomposed relations should have the property that when joined
together, they produce the original relation. This means that there should be no loss of
information when the relations are joined back together.
Example:
Main Table:
EmpID EmpName EmpAddress DeptID DeptName Salary
1 John Nagercoil 101 101 20000
2 Jane Marthandam 102 102 50000
3 Bob Kerala 103 103 55000

Sub Table 1: EmployeeDetails (EmpID, EmpName, EmpAddress, DeptID)

EmpID EmpName EmpAddress DeptID
1 John Nagercoil 101
2 Jane Marthandam 102
3 Bob Kerala 103

Sub Table 2: DepartmentDetails (DeptID, DeptName, Salary)

DeptID DeptName Salary
101 Sales 20000
 102 Marketing 50000
103 CSE 55000

In the above example, we have an Employee table with six attributes: EmpID, EmpName,
EmpAddress, DeptID, DeptName, and Salary. We have identified the functional dependencies
in this table and found that EmpID determines EmpName and EmpAddress, while DeptID
determines DeptName and Salary. Using lossless decomposition, we have broken down the
Employee table into two smaller tables: EmployeeDetails and DepartmentDetails. The
EmployeeDetails table contains the attributes EmpID, EmpName, EmpAddress, and DeptID,
while the DepartmentDetails table contains the attributes DeptID, DeptName, and Salary.
Both tables are now free of any data redundancy and any updates or modifications can be
made to the smaller tables rather than the entire original table. We can also combine these
tables using the Natural join with common attribute DeptID, to retrieve the original Employee
table. Thus, lossless decomposition has preserved all the information in the original table
while improving efficiency and reducing redundancy.
Advantages of Non-Loss Decomposition
Preservation of Information: The primary advantage of non-loss decomposition is that no
information is lost during the decomposition process. When the decomposed tables are joined
back, they should represent the original data without any discrepancies.
Avoidance of Redundancy: By decomposing a relation into smaller relations, redundancy
(repetition of data) can be reduced. This helps in saving storage space and can enhance
performance when handling large datasets.
Improved Data Integrity: Decomposing tables into smaller, more manageable relations can
help enforce data integrity constraints more easily. For example, separating data that is
updated infrequently from data that is updated more frequently can reduce the risk of
anomalies.
Disadvantages of Non-Loss Decomposition
Increased Complexity in Joins: While the decomposition helps reduce redundancy, it can
also lead to more complex joins. After decomposing the data, you may need to join multiple
tables to get the same result that would have been achievable with a single, non-decomposed
table. This can increase the computational cost.
Potential for Performance Overhead: If queries frequently require joins across multiple
decomposed tables, it could result in a performance overhead, especially if the tables are
large and the joins are complex. This can slow down query performance.
Challenges in Maintaining Relationships: Sometimes, maintaining relationships (like
foreign keys) across decomposed relations can be cumbersome. You need to ensure that the
relationships between the tables are properly managed to avoid inconsistencies.