UNIT-3 Functional Dependency
UNIT-3 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.
1. X → Y
The left side of FD is known as a determinant, the right side of the production is known as a
dependent.
For example:
Here Emp_Id attribute can uniquely identify the Emp_Name attribute of employee table
because if we know the Emp_Id, we can tell that employee name associated with it.
1. Emp_Id → Emp_Name
We can say that Emp_Name is functionally dependent on Emp_Id.
1. ID → Name,
2. Name → DOB
1. If X ⊇ Y then X → Y
Example:
1. X = {a, b, c, d, e}
2. Y = {a, b, c}
Example:
1. If X → Y and Y → Z then X → Z
1. If X → Y and X → Z then X → YZ
Proof:
1. X → Y (given)
2. X → Z (given)
3. X → XY (using IR2 on 1 by augmentation with X. Where XX = X)
4. XY → YZ (using IR2 on 2 by augmentation with Y)
5. X → YZ (using IR3 on 3 and 4)
Decomposition rule is also known as project rule. It is the reverse of union rule.
1. If X → YZ then X → Y and X → Z
Proof:
1. X → YZ (given)
2. YZ → Y (using IR1 Rule)
3. X → Y (using IR3 on 1 and 2)
1. If X → Y and YZ → W then XZ → W
Proof:
1. X → Y (given)
2. WY → Z (given)
3. WX → WY (using IR2 on 1 by augmenting with W)
4. WX → Z (using IR3 on 3 and 2)
Normalization
A large database defined as a single relation may result in data duplication. This repetition of
data may result in:
o It isn't easy to maintain and update data as it would involve searching many records in
relation.
What is Normalization?
o Normalization divides the larger table into smaller and links them using relationships.
o The normal form is used to reduce redundancy from the database table.
Why do we need Normalization?
The main reason for normalizing the relations is removing these anomalies. Failure to
eliminate anomalies leads to data redundancy and can cause data integrity and other problems
as the database grows. Normalization consists of a series of guidelines that helps to guide you
in creating a good database structure.
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.
Normalization works through a series of stages called Normal forms. The normal forms apply
to individual relations. The relation is said to be in particular normal form if it satisfies
constraints.
Advantages of Normalization
Disadvantages of Normalization
o You cannot start building the database before knowing what the user needs.
o The performance degrades when normalizing the relations to higher normal forms,
i.e., 4NF, 5NF.
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: Relation EMPLOYEE is not in 1NF because of multi-valued attribute
EMP_PHONE.
EMPLOYEE table:
7272826385,
14 John UP
9064738238
7390372389,
12 Sam Punjab
8589830302
The decomposition of the EMPLOYEE table into 1NF has been shown below:
14 John 7272826385 UP
14 John 9064738238 UP
o In the second normal form, all non-key attributes are fully functional dependent on the
primary key
Example: Let's assume, a school can store the data of teachers and the subjects they teach. In
a school, a teacher can teach more than one subject.
TEACHER table
25 Chemistry 30
25 Biology 30
47 English 35
83 Math 38
83 Computer 38
In the given table, non-prime attribute TEACHER_AGE is dependent on TEACHER_ID
which is a proper subset of a candidate key. That's why it violates the rule for 2NF.
To convert the given table into 2NF, we decompose it into two tables:
TEACHER_DETAIL table:
TEACHER_ID TEACHER_AGE
25 30
47 35
83 38
TEACHER_SUBJECT table:
TEACHER_ID SUBJECT
25 Chemistry
25 Biology
47 English
83 Math
83 Computer
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.
A relation is in third normal form if it holds atleast one of the following conditions for every
non-trivial function dependency X → Y.
1. X is a super key.
2. Y is a prime attribute, i.e., each element of Y is part of some candidate key.
Example:
EMPLOYEE_DETAIL table:
Non-prime attributes: In the given table, all attributes except EMP_ID are non-
prime.
That's why we need to move the EMP_CITY and EMP_STATE to the new
<EMPLOYEE_ZIP> table, with EMP_ZIP as a Primary key.
EMPLOYEE table:
EMP_ID EMP_NAME EMP_ZIP
EMPLOYEE_ZIP table:
201010 UP Noida
02228 US Boston
60007 US Chicago
06389 UK Norwich
462007 MP Bhopal
o For BCNF, the table should be in 3NF, and for every FD, LHS is super key.
Example: Let's assume there is a company where employees work in more than one
department.
EMPLOYEE table:
1. EMP_ID → EMP_COUNTRY
2. EMP_DEPT → {DEPT_TYPE, EMP_DEPT_NO}
Candidate key: {EMP-ID, EMP-DEPT}
The table is not in BCNF because neither EMP_DEPT nor EMP_ID alone are keys.
To convert the given table into BCNF, we decompose it into three tables:
EMP_COUNTRY table:
EMP_ID EMP_COUNTRY
264 India
264 India
EMP_DEPT table:
EMP_DEPT_MAPPING table:
EMP_ID EMP_DEPT
D394 283
D394 300
D283 232
D283 549
Functional dependencies:
1. EMP_ID → EMP_COUNTRY
2. EMP_DEPT → {DEPT_TYPE, EMP_DEPT_NO}
Candidate keys:
For the first table: EMP_ID
For the second table: EMP_DEPT
For the third table: {EMP_ID, EMP_DEPT}
Now, this is in BCNF because left side part of both the functional dependencies is a key.
o A relation will be in 4NF if it is in Boyce Codd normal form and has no multi-valued
dependency.
Example
STUDENT
21 Computer Dancing
21 Math Singing
34 Chemistry Dancing
74 Biology Cricket
59 Physics Hockey
The given STUDENT table is in 3NF, but the COURSE and HOBBY are two independent
entity. Hence, there is no relationship between COURSE and HOBBY.
So to make the above table into 4NF, we can decompose it into two tables:
STUDENT_COURSE
STU_ID COURSE
21 Computer
21 Math
34 Chemistry
74 Biology
59 Physics
STUDENT_HOBBY
STU_ID HOBBY
21 Dancing
21 Singing
34 Dancing
74 Cricket
59 Hockey
o 5NF is satisfied when all the tables are broken into as many tables as
possible in order to avoid redundancy.
o 5NF is also known as Project-join normal form (PJ/NF).
Example
In the above table, John takes both Computer and Math class for Semester 1 but
he doesn't take Math class for Semester 2. In this case, combination of all these
fields required to identify a valid data.
Suppose we add a new Semester as Semester 3 but do not know about the
subject and who will be taking that subject so we leave Lecturer and Subject as
NULL. But all three columns together acts as a primary key, so we can't leave
other two columns blank.
So to make the above table into 5NF, we can decompose it into three relations
P1, P2 & P3:
P1
SEMESTER SUBJECT
Semester 1 Computer
Semester 1 Math
Semester 1 Chemistry
Semester 2 Math
P2
SUBJECT LECTURER
Computer Anshika
Computer John
Math John
Math Akash
Chemistry Praveen
P3
SEMSTER LECTURER
Semester 1 Anshika
Semester 1 John
Semester 1 John
Semester 2 Akash
Semester 1 Praveen
Inclusion Dependency
o Multivalued dependency and join dependency can be used to guide database design
although they both are less common than functional dependencies.
o Inclusion dependencies are quite common. They typically show little influence on
designing of the database.
o The example of inclusion dependency is a foreign key. In one relation, the referring
relation is contained in the primary key column(s) of the referenced relation.
o Suppose we have two relations R and S which was obtained by translating two entity
sets such that every R entity is also an S entity.
o In practice, most inclusion dependencies are key-based that is involved only keys.
Relational Decomposition
o When a relation in the relational model is not in appropriate normal form then the
decomposition of a relation is required.
o If the relation has no proper decomposition, then it may lead to problems like loss of
information.
Types of Decomposition
Lossless Decomposition
o If the information is not lost from the relation that is decomposed, then the
decomposition will be lossless.
o The lossless decomposition guarantees that the join of relations will result in the same
relation as it was decomposed.
EMPLOYEE_DEPARTMENT table:
EMPLOYEE table:
22 Denim 28 Mumbai
33 Alina 25 Delhi
46 Stephan 30 Bangalore
52 Katherine 36 Mumbai
60 Jack 40 Noida
DEPARTMENT table
827 22 Sales
438 33 Marketing
869 46 Finance
575 52 Production
678 60 Testing
Now, when these two relations are joined on the common column "EMP_ID",
then the resultant relation will look like:
Employee ⋈ Department
Dependency Preserving
o In the dependency preservation, at least one decomposed table must satisfy every
dependency.
Multivalued Dependency
o Multivalued dependency occurs when two attributes in a table are independent of each
other but, both depend on a third attribute.
In this case, these two columns can be called as multivalued dependent on BIKE_MODEL.
The representation of these dependencies is shown below:
1. BIKE_MODEL → → MANUF_YEAR
2. BIKE_MODEL → → COLOR
This can be read as "BIKE_MODEL multidetermined MANUF_YEAR" and
"BIKE_MODEL multidetermined COLOR".
Join Dependency
o If the join of R1 and R2 over C is equal to relation R, then we can say that a join
dependency (JD) exists.
o Here, *(R1, R2, R3) is used to indicate that relation R1, R2, R3 and so on are a JD of
R.
Canonical Cover
In the case of updating the database, the responsibility of the system is to check whether the
existing functional dependencies are getting violated during the process of updating. In case
of a violation of functional dependencies in the new database state, the rollback of the system
must take place.
Extraneous attributes
1. B→A
2. AD → B ( using decomposition inference rule on AD → BC)
3. AD → C ( using decomposition inference rule on AD → BC)
4. C → A ( using decomposition inference rule on C → ABD)
5. C → B ( using decomposition inference rule on C → ABD)
6. C → D ( using decomposition inference rule on C → ABD)
Now set of FD = { B → A, AD → B, AD → C, C → A, C → B, C → D }
The next step is to find closure of the left side of each of the given FD by including that FD
and excluding that FD, if closure in both cases are same then that FD is redundant and we
remove that FD from the given set, otherwise if both the closures are different then we do not
exclude that FD.
From 2 a and 2 b, we found that both the Closure (by including AD → B and excluding AD
→ B) are equivalent, hence FD AD → B is not important and can be removed from the set of
FD.
Hence resultant FD = { B → A, AD → C, C → A, C → B, C → D }
Advertisement
From 3 a and 3 b, we found that both the Closure (by including AD → C and excluding AD
→ C ) are not equivalent, hence FD AD → C is important and cannot be removed from the
set of FD.
Hence resultant FD = { B → A, AD → C, C → A, C → B, C → D }
Advertisement
4 b. Closure C+ = CBDA using FD = { B → A, AD → C, C → B, C → D }
From 4 a and 4 b, we found that both the Closure (by including C → A and excluding C →
A) are equivalent, hence FD C → A is not important and can be removed from the set of FD.
Hence resultant FD = { B → A, AD → C, C → B, C → D }
5 b. Closure C+ = CD using FD = { B → A, AD → C, C → D }
From 5 a and 5 b, we found that both the Closure (by including C → B and excluding C →
B) are not equivalent, hence FD C → B is important and cannot be removed from the set of
FD.
Hence resultant FD = { B → A, AD → C, C → B, C → D }
From 6 a and 6 b, we found that both the Closure( by including C → D and excluding C →
D) are not equivalent, hence FD C → D is important and cannot be removed from the set of
FD.
Hence resultant FD = { B → A, AD → C, C → B, C → D }
Since the closure of AD+, A+, D+ that we found are not all equivalent, hence in FD AD →
C, both A and D are important attributes and cannot be removed.
1. W→X
2. Y→X
3. Z → W ( using decomposition inference rule on Z → WXY )
4. Z → X ( using decomposition inference rule on Z → WXY )
5. Z → Y ( using decomposition inference rule on Z → WXY )
6. WY → Z
Now set of FD = { W → X, Y → X, WY → Z, Z → W, Z → X, Z → Y }
The next step is to find closure of the left side of each of the given FD by including that FD
and excluding that FD, if closure in both cases are same then that FD is redundant and we
remove that FD from the given set, otherwise if both the closures are different then we do not
exclude that FD.
Calculating closure of all FD { W → X, Y → X, Z → W, Z → X, Z → Y, WY → Z }
1 a. Closure W+ = WX using FD = { W → X, Y → X, Z → W, Z → X, Z → Y, WY → Z }
1 b. Closure W+ = W using FD = { Y → X, Z → W, Z → X, Z → Y, WY → Z }
From 1 a and 1 b, we found that both the Closure (by including W → X and excluding W →
X ) are not equivalent, hence FD W → X is important and cannot be removed from the set of
FD.
Hence resultant FD = { W → X, Y → X, Z → W, Z → X, Z → Y, WY → Z }
2 a. Closure Y+ = YX using FD = { W → X, Y → X, Z → W, Z → X, Z → Y, WY → Z }
2 b. Closure Y+ = Y using FD = { W → X, Z → W, Z → X, Z → Y, WY → Z }
From 2 a and 2 b we found that both the Closure (by including Y → X and excluding Y →
X ) are not equivalent, hence FD Y → X is important and cannot be removed from the set of
FD.
Hence resultant FD = { W → X, Y → X, Z → W, Z → X, Z → Y, WY → Z }
From 3 a and 3 b, we found that both the Closure (by including Z → W and excluding Z →
W ) are not equivalent, hence FD Z → W is important and cannot be removed from the set of
FD.
Hence resultant FD = { W → X, Y → X, Z → W, Z → X, Z → Y, WY → Z }
From 4 a and 4 b, we found that both the Closure (by including Z → X and excluding Z →
X ) are equivalent, hence FD Z → X is not important and can be removed from the set of FD.
Hence resultant FD = { W → X, Y → X, Z → W, Z → Y, WY → Z }
From 5 a and 5 b, we found that both the Closure (by including Z → Y and excluding Z →
Y ) are not equivalent, hence FD Z → X is important and cannot be removed from the set of
FD.
Hence resultant FD = { W → X, Y → X, Z → W, Z → Y, WY → Z }
From 6 a and 6 b, we found that both the Closure (by including WY → Z and excluding WY
→ Z) are not equivalent, hence FD WY → Z is important and cannot be removed from the
set of FD.
Hence resultant FD = { W → X, Y → X, Z → W, Z → Y, WY → Z }
Closure W+ = WX using FD = { W → X, Y → X, Z → W, Z → Y, WY → Z }
Closure Y+ = YX using FD = { W → X, Y → X, Z → W, Z → Y, WY → Z }
Since the closure of WY+, W+, Y+ that we found are not all equivalent, hence in FD WY →
Z, both W and Y are important attributes and cannot be removed.
1. V→W
2. VW → X
3. Y → V ( using decomposition inference rule on Y → VXZ )
4. Y → X ( using decomposition inference rule on Y → VXZ )
5. Y → Z ( using decomposition inference rule on Y → VXZ )
Now set of FD = { V → W, VW → X, Y → V, Y → X, Y → Z }.
The next step is to find closure of the left side of each of the given FD by including that FD
and excluding that FD, if closure in both cases are same then that FD is redundant and we
remove that FD from the given set, otherwise if both the closures are different then we do not
exclude that FD.
From 1 a and 1 b, we found that both the Closure( by including V → W and excluding V →
W ) are not equivalent, hence FD V → W is important and cannot be removed from the set of
FD.
Hence resultant FD = { V → W, VW → X, Y → V, Y → X, Y → Z }.
From 2 a and 2 b, we found that both the Closure( by including VW → X and excluding VW
→ X ) are not equivalent, hence FD VW → X is important and cannot be removed from the
set of FD.
Hence resultant FD = { V → W, VW → X, Y → V, Y → X, Y → Z }.
From 3 a and 3 b, we found that both the Closure( by including Y → V and excluding Y →
V ) are not equivalent, hence FD Y → V is important and cannot be removed from the set of
FD.
Hence resultant FD = { V → W, VW → X, Y → V, Y → X, Y → Z }.
From 4 a and 4 b, we found that both the Closure( by including Y → X and excluding Y →
X ) are equivalent, hence FD Y → X is not important and can be removed from the set of FD.
Hence resultant FD = { V → W, VW → X, Y → V, Y → Z }.
From 5 a and 5 b, we found that both the Closure( by including Y → Z and excluding Y →
Z ) are not equivalent, hence FD Y → Z is important and cannot be removed from the set of
FD.
Hence resultant FD = { V → W, VW → X, Y → V, Y → Z }.
Since FD = { V → W, VW → X, Y → V, Y → Z } is resultant FD now, we have checked the
redundancy of attribute, since the left side of FD VW → X has two attributes at its left, let's
check their importance, i.e. whether they both are important or only one.
Closure W+ = W using FD = { V → W, VW → X, Y → V, Y → Z }
Since the closure of VW+, V+, W+ we found that all the Closures of VW and V are
equivalent, hence in FD VW → X, W is not at all an important attribute and can be removed.
CONCLUSION: From the above three examples we conclude that canonical cover /
irreducible set of functional dependency follows the following steps, which we need to follow
while calculating Canonical Cover.
STEP 1: For a given set of FD, decompose each FD using decomposition rule (Armstrong
Axiom) if the right side of any FD has more than one attribute.
STEP 3: Find closure of the left side of each of the given FD by including that FD and
excluding that FD, if closure in both cases are same then that FD is redundant and we remove
that FD from the given set, otherwise if both the closures are different then we do not exclude
that FD.
STEP 4: Repeat step 4 till all the FDs in FD set are complete.
STEP 6: Check redundancy of attribute, by selecting those FD's from FD sets which are
having more than one attribute on its left, let's an FD AD → C has two attributes at its left,
let's check their importance, i.e. whether they both are important or only one.
Compare Closure of STEP (6a, 6b, 6c) if the closure of AD+, A+, D+ are not equivalent,
hence in FD AD → C, both A and D are important attributes and cannot be removed,
otherwise, we remove the redundant attribute.