The document provides an introduction to relational database design and concepts. It discusses how relational databases organize data in tables made up of rows and columns. It also discusses functional dependencies, which specify relationships between attributes, and how relational decomposition breaks tables into multiple tables to eliminate problems from bad design like anomalies and redundancy. Decomposition must be lossless, preserve dependencies, and eliminate data redundancy.

1. Relational Database design

2. Introduction to relational Databases Design
A relational database organizes data in tables (or relations). A table is made
up of rows and columns. A row is also called a record (or tuple). A column is
also called a field (or attribute). A database table is similar to a spreadsheet.
However, the relationships that can be created among the tables enable a
relational database to efficiently store huge amount of data, and effectively
retrieve selected data.
A language called SQL (Structured Query Language) was developed to work
with relational databases.
Database design is more art than science, as you have to make many
decisions. Databases are usually customized to suit a particular application.
No two customized applications are alike, and hence, no two database are
alike.

3. Functional Dependency
A functional dependency is a constraint that specifies the relationship
between two sets of attributes where one set can accurately determine
the value of other sets. It is denoted as X → Y, where X is a set of
attributes that is capable of determining the value of Y. The attribute
set on the left side of the arrow, X is called Determinant, while on the
right side, Y is called the Dependent. Functional dependencies are used
to mathematically express relations among database entities and are
very important to understand advanced concepts in Relational
Database System and understanding problems in competitive exams
like Gate.

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

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

6. 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, For 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.

7. Types of Functional dependencies in DBMS:
1. Trivial functional dependency
2. Non-Trivial functional dependency
3. Multivalued functional dependency
4. Transitive functional dependency

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

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

10. Multivalued Functional Dependency
In Multivalued functional dependency, entities of the dependent set
are not dependent on each other.
i.e. If a → {b, c} and there exists no functional dependency between b
and c, then it is called a multivalued functional dependency. Here,
roll_no → {name, age} is a multivalued functional dependency, since
the dependents name & age are not dependent on each other(i.e.
name → age or age → name doesn’t exist !)
roll_no name age
42 abc 17
43 pqr 18
44 xyz 18
45 abc 19

11. Transitive Functional Dependency
In transitive functional dependency, dependent is indirectly dependent
on determinant.
i.e. If a → b & b → c, then according to axiom of transitivity, a → c. This
is a transitive functional dependency
For example, Here, enrol_no → dept and dept → building_no,
Hence, according to the axiom of transitivity, enrol_no → building_no is
a valid functional dependency. This is an indirect functional
dependency, hence called Transitive functional dependency.
enrol_no name dept building_no
42 abc CO 4
43 pqr EC 2
44 xyz IT 1
45 abc EC 2

12. Relational Decomposition
When a relation in the relational model is not in appropriate normal
form then the decomposition of a relation is required.
In a database, it breaks the table into multiple tables.
If the relation has no proper decomposition, then it may lead to
problems like loss of information.
Decomposition is used to eliminate some of the problems of bad
design like anomalies, inconsistencies, and redundancy.

13. Properties of Decomposition
• Following are the properties of Decomposition,
1. Lossless Decomposition
2. Dependency Preservation
3. Lack of Data Redundancy

14. Lossless Decomposition
• Decomposition must be lossless. It means that the information should
not get lost from the relation that is decomposed.
• It gives a guarantee that the join will result in the same relation as it
was decomposed.
Example:
Let's take 'E' is the Relational Schema, With instance 'e'; is decomposed
into: E1, E2, E3, . . . . En; With instance: e1, e2, e3, . . . . en, If e1 ⋈ e2 ⋈
e3 . . . . ⋈ en, then it is called as 'Lossless Join Decomposition'.

15. In the above example, it means that, if natural joins of all the decomposition
give the original relation, then it is said to be lossless join decomposition.
Example: <Employee_Department> Table
• Decompose the above relation into two relations to check whether a
decomposition is lossless or lossy.
• Now, we have decomposed the relation that is Employee and Department.
Eid Ename Age City Salary Deptid DeptName
E001 ABC 29 Pune 20000 D001 Finance
E002 PQR 30 Pune 30000 D002 Production
E003 LMN 25 Mumbai 5000 D003 Sales
E004 XYZ 24 Mumbai 4000 D004 Marketing
E005 STU 32 Bangalore 25000 D005 Human
Resource

16. Department Schema contains (Deptid, DeptName).
Employee Schema contains (Eid,Deptid, Ename, Age, City, Salary).
So, the above decomposition is a Lossless Join Decomposition, because the two
relations contains one common field that is ‘Deptid' and therefore join is possible.
• Now apply natural join on the decomposed relations.
Employee ⋈ Department
Eid Ename Age City Salary Deptid DeptName
E001 ABC 29 Pune 20000 D001 Finance
E002 PQR 30 Pune 30000 D002 Production
E003 LMN 25 Mumbai 5000 D003 Sales
E004 XYZ 24 Mumbai 4000 D004 Marketing
E005 STU 32 Bangalore 25000 D005 Human
Resource
Hence, the decomposition is Lossless Join Decomposition.

17. Lossy Decomposition
• As the name suggests, when a relation is decomposed into two or
more relational schemas, the loss of information is unavoidable when
the original relation is retrieved.
• Let us see an example −
• <EmpInfo>
Emp_ID Emp_Name Emp_Age Emp_Location Dept_ID Dept_Name
E001 Jacob 29 Alabama Dpt1 Operations
E002 Henry 32 Alabama Dpt2 HR
E003 Tom 22 Texas Dpt3 Finance

18. Dept_ID Dept_Name
Dpt1 Operations
Dpt2 HR
Dpt3 Finance
Decompose the above table into two tables −
<EmpDetails>
<DeptDetails>
Emp_ID Emp_Name Emp_Age Emp_Location
E001 Jacob 29 Alabama
E002 Henry 32 Alabama
E003 Tom 22 Texas

19. Now, you won’t be able to join the above tables, since Emp_ID isn’t
part of the DeptDetails relation.
Therefore, the above relation has lossy decomposition.

20. Dependency Preservation
It is an important constraint of the database.
In the dependency preservation, at least one decomposed table must
satisfy every dependency.
If a relation R is decomposed into relation R1 and R2, then the
dependencies of R either must be a part of R1 or R2 or must be
derivable from the combination of functional dependencies of R1 and
R2.
For example, suppose there is a relation R (A, B, C, D) with functional
dependency set (A->BC). The relational R is decomposed into R1(ABC)
and R2(AD) which is dependency preserving because FD A->BC is a part
of relation R1(ABC).