UNIT-III PART-II

INTRODUCTION TO SCHEMA REFINEMENT

 Normalization or Schema Refinement is a technique of organizing the data in the database. It is a
systematic approach of decomposing tables to eliminate data redundancy and undesirable characteristics
like Insertion, Update and Deletion Anomalies.
 The Schema Refinement refers to refine the schema by using some technique. The best technique of
schema refinement is decomposition.
 Identifying and clearing the future problems in the database is called schema refinement. In this refinement
main problem is data redundancy. It is avoided by normalization technique.
 The Basic Goal of Normalization is used to eliminate redundancy.
 Redundancy refers to repetition of same data or duplicate copies of same data stored in different locations.

Problems Caused by redundancy

Storing the same information redundantly, can lead to several problems

 Redundant Storage: Some information is stored repeatedly.

 Update Anomalies: If one copy of such repeated data is updated, an inconsistency is
Created unless all copies are similarly updated.
 Insertion Anomalies: It may not be possible to store certain information unless some other,
unrelated, information is stored as well.
 Deletion Anomalies: It may not be possible to delete certain information without losing some
other, unrelated, information as well.
Decomposition: Decomposition means replacing a relation with a collection of smaller relations. or the
process of breaking down the relation into smaller relations is called Decomposition.

 Decomposition is the process of breaking down in parts or elements.

 It replaces a relation with a collection of smaller relations.
 It breaks the table into multiple tables in a database.
 It should always be lossless, because it confirms that the information in the original relation can be
accurately reconstructed based on the decomposed relations.
 If there is no proper decomposition of the relation, then it may lead to problems like loss of information.
 Properties of Decomposition

Following are the properties of Decomposition,

1. Lossless Decomposition
2. Dependency Preservation
3. Lack of Data Redundancy

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

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

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

 Decompose the above relation into two relations to check whether decomposition is lossless or lossy.
 Now, we have decomposed the relation that is Employee and Department.

Relation 1 : <Employee> Table

 Eid Ename Age City Salary
E001 ABC 29 Pune 20000
E002 PQR 30 Pune 30000
E003 LMN 25 Mumbai 5000
E004 XYZ 24 Mumbai 4000
E005 STU 32 Bangalore 25000

 Employee Schema contains (Eid, Ename, Age, City, Salary).

Relation 2: <Department> Table

Deptid Eid DeptName

D001 E001 Finance

D002 E002 Production

D003 E003 Sales

D004 E004 Marketing

D005 E005 Human Resource

 Department Schema contains (Deptid, Eid, DeptName).

 So, the above decomposition is a Lossless Join Decomposition, because the two relations contains one
common field that is 'Eid' 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.
 If the <Employee> table contains (Eid, Ename, Age, City, Salary) and <Department> table contains
(Deptid and DeptName), then it is not possible to join the two tables or relations, because there is no
common column between them. And it becomes Lossy Join Decomposition.
2. Dependency Preservation

 Dependency is an important constraint on the database.

 Every dependency must be satisfied by at least one decomposed table.
 If {A → B} holds, then two sets are functional dependent. And, it becomes more useful for checking the
dependency easily if both sets in a same relation.
 This decomposition property can only be done by maintaining the functional dependency.
 In this property, it allows to check the updates without computing the natural join of the database
structure.
3. Lack of Data Redundancy

 Lack of Data Redundancy is also known as a Repetition of Information.

 The proper decomposition should not suffer from any data redundancy.
 The careless decomposition may cause a problem with the data.
 The lack of data redundancy property may be achieved by Normalization process.

Functional Dependencies

 Functional dependency is a constraint between two sets of attributes in a relation from a database.
In other words, functional dependency is a constraint that describes the relationship between
attributes, typically between the primary key and other non key attributes with in a table.
 For any relation R, attribute Y is functionally dependent on attribute X , if for every valid instance
of X, that value of X uniquely determines the value of Y.
 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.
Example:

dept_nam
roll_no name e dept_building

42 abc CO A4

43 pqr IT A3

44 xyz CO A4

45 xyz IT A3
 dept_nam
roll_no name e dept_building

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
3. Multivalued functional dependency
4. Transitive 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:
 nam
roll_no e 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:
nam
roll_no e 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}

3.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.
For example,

nam
roll_no e age

42 abc 17

43 pqr 18

44 xyz 18

45 abc 19
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 !)

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

enrol_n nam building_n

o e dept o

C
42 abc 4
O

43 pqr EC 2

44 xyz IT 1

45 abc EC 2

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.

5. Fully Functional Dependency

In full functional dependency an attribute or a set of attributes uniquely determines another attribute or
set of attributes. If a relation R has attributes X, Y, Z with the dependencies X->Y and X->Z which states
that those dependencies are fully functional.
6. Partial Functional Dependency
In partial functional dependency a non key attribute depends on a part of the composite key, rather than
the whole key. If a relation R has attributes X, Y, Z where X and Y are the composite key and Z is non
key attribute. Then X->Z is a partial functional dependency in RBDMS.
Advantages of Functional Dependencies
Functional dependencies having numerous applications in the field of database management system.
Here are some applications listed below:

1. Data Normalization

Data normalization is the process of organizing data in a database in order to minimize redundancy and
increase data integrity. Functional dependencies play an important part in data normalization. With the
help of functional dependencies we are able to identify the primary key, candidate key in a table which in
turns helps in normalization.

2. Query Optimization

With the help of functional dependencies we are able to decide the connectivity between the tables and
the necessary attributes need to be projected to retrieve the required data from the tables. This helps in
query optimization and improves performance.
3. Consistency of Data

Functional dependencies ensures the consistency of the data by removing any redundancies or
inconsistencies that may exist in the data. Functional dependency ensures that the changes made in one
attribute does not affect inconsistency in another set of attributes thus it maintains the consistency of the
data in database.

4. Data Quality Improvement

Functional dependencies ensure that the data in the database to be accurate, complete and updated. This
helps to improve the overall quality of the data, as well as it eliminates errors and inaccuracies that might
occur during data analysis and decision making, thus functional dependency helps in improving the
quality of data in database.
Normal Forms
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.
There are several levels of normalization, each with its own set of guidelines, known as normal
forms.
 First Normal Form (1NF)
 Second Normal Form (2NF)
 Third Normal Form (3NF)
 Boyce-Codd Normal Form (BCNF)
 Fourth Normal Form (4NF)
 Fifth Normal Form (5NF)

1. First Normal Form –

If a relation contain composite or multi-valued attribute, it violates first normal form or a relation is in
first normal form if it does not contain any composite or multi-valued attribute. A relation is in first
normal form if every attribute in that relation is singled valued attribute.

Example 1 – Relation STUDENT in table 1 is not in 1NF because of multi-valued attribute

STUD_PHONE. Its decomposition into 1NF has been shown in table 2.
 2. Second Normal Form –

To be in second normal form, a relation must be in first normal form and relation must not contain any
partial dependency. A relation is in 2NF if it has No Partial Dependency, i.e., no non-prime attribute
(attributes which are not part of any candidate key) is dependent on any proper subset of any candidate
key of the table.
Partial Dependency – If the proper subset of candidate key determines non-prime attribute, it is called
partial dependency.
 Example 1 – Consider table-3 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
 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

Table 1 Table 2
STUD_NO COURSE_NO COURSE_NO COURSE_FEE
1 C1 C1 1000
2 C2 C2 1500
1 C4 C3 1000
4 C3 C4 2000
4 C1 C5 2000

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.
A relation is in 3NF if at least one of the following condition holds in every non-trivial function
dependency X –> Y:
1. X is a super key.
2. Y is a prime attribute (each element of Y is part of some candidate key).
In other words,
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).

The normalization of 2NF relations to 3NF involves the removal of transitive dependencies. If a
transitive dependency exists, we remove the transitively dependent attribute(s) from the relation by
placing the attribute(s) in a new relation along with a copy of the determinant.
Consider the examples given below.
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_STATE, STUD_COUNTRY_STUD_AGE) as:
STUDENT (STUD_NO, STUD_NAME, STUD_STATE, STUD_AGE)
STATE_COUNTRY (STATE, COUNTRY);

Boyce Codd normal form (BCNF)

It is an advance version of 3NF that’s why it is also referred as 3.5NF. BCNF is stricter than 3NF.

Rules for BCNF

Rule 1: The table should be in the 3rd Normal Form.
Rule 2: X should be a superkey for every functional dependency (FD) X−>Y in a given relation.

Example: Suppose there is a company wherein employees work in more than one department. They
store the data like this:
emp_id emp_nationality emp_dept dept_type dept_no_of_emp

1001 Austrian Production and planning D001 200

1001 Austrian Stores D001 250

1002 American design and technical support D134 100

1002 American Purchasing department D134 600

Functional dependencies in the table above:

emp_id -> emp_nationality
emp_dept -> {dept_type, dept_no_of_emp}

Candidate key: {emp_id, emp_dept}

The table is not in BCNF as neither emp_id nor emp_dept alone are keys.

To make the table comply with BCNF we can break the table in three tables like this:
emp_nationality table:

emp_id emp_nationality

1001 Austrian

1002 American

emp_dept table:

emp_dept dept_type dept_no_of_emp

Production and planning D001 200

stores D001 250

design and technical support D134 100

Purchasing department D134 600

emp_dept_mapping table:

emp_id emp_dept

1001 Production and planning

1001 stores

1002 design and technical support

1002 Purchasing department

Example 2

Let us consider the student database, in which data of the student are mentioned.

Stu_I
D Stu_Branch Stu_Course Branch_NumberStu_Course_No

101 Computer Science & Engineering DBMS B_001 201

101 Computer Science & Engineering Computer Networks B_001 202

Electronics & Communication

102 VLSI Technology B_003 401
Engineering

Electronics & Communication Mobile

102 B_003 402
Engineering Communication

Functional Dependency of the above is as mentioned:

Stu_ID −> Stu_Branch
Stu_Course −> {Branch_Number, Stu_Course_No}
Candidate Keys of the above table are: {Stu_ID, Stu_Course}

For satisfying this table in BCNF, we have to decompose it into further tables. Here is the full procedure
through which we transform this table into BCNF.
Let us first divide this main table into two tables Stu_Branch and Stu_Course Table.
Stu_Branch Table

Stu_ID Stu_Branch

101 Computer Science & Engineering

Electronics & Communication

102
Engineering

Candidate Key for this table: Stu_ID.

Stu_Course Table

Stu_Course Branch_Number Stu_Course_No

DBMS B_001 201

Computer Networks B_001 202

VLSI Technology B_003 401

Mobile
B_003 402
Communication

Candidate Key for this table: Stu_Course.

Stu_ID to Stu_Course_No Table

Stu_I
D Stu_Course_No

101 201

101 202

102 401

102 402

Candidate Key for this table: {Stu_ID, Stu_Course_No}.

After decomposing into further tables, now it is in BCNF, as it is passing the condition of Super Key,
that in functional dependency X−>Y, X is a Super Key.
Fourth Normal Form:

If two or more independent relations are kept in a single relation or we can say multivalue
dependency occurs when the presence of one or more rows in a table implies the presence of one or more
other rows in that same table. Put another way, two attributes (or columns) in a table are independent of
one another, but both depend on a third attribute.

A multivalued dependency always requires at least three attributes because it consists of at least two
attributes that are dependent on a third.

For a dependency A -> B, if for a single value of A, multiple values of B exist, then the table may have a
multi-valued dependency. The table should have at least 3 attributes and B and C should be independent
for A ->> B multivalued dependency.

Properties
A relation R is in 4NF if and only if the following conditions are satisfied:
1. It should be in the Boyce-Codd Normal Form (BCNF).
2. The table should not have any Multi-valued Dependency.

For a dependency A → B, if for a single value of A, multiple values of B exists, then the relation will be a
multi-valued dependency.

Example

STUDENT

STU_ID COURSE HOBBY

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.

In the STUDENT relation, a student with STU_ID, 21 contains two courses, Computer and Math and two
hobbies, Dancing and Singing. So there is a Multi-valued dependency on STU_ID, which leads to
unnecessary repetition of data.

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
Fifth normal form (5NF)
o A relation is in 5NF if it is in 4NF and not contains any join dependency and joining should be
lossless.
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
SUBJECT LECTURER SEMESTER

Computer Anshika Semester 1

Computer John Semester 1

Math John Semester 1

Math Akash Semester 2

Chemistry Praveen Semester 1

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

Closure of an Attribute Set

 The set of all those attributes which can be functionally determined from an attribute set is called as a
closure of that attribute set.

● Closure of attribute set {X} is denoted as {X}+

Steps to Find Closure of an Attribute Set

Following steps are followed to find the closure of an attribute set

Step-01: Add the attributes contained in the attribute set for which closure is being calculated to the result
set.

Step-02: Recursively add the attributes to the result set which can be functionally determined from the
attributes already contained in the result set.

Example:

Consider a relation R ( A , B , C , D , E , F , G ) with the functional dependencies

A → BC

BC → DE

D→F

CF → G
Now, let us find the closure of some attributes and attribute sets

Closure of attribute A

A+={A}

={A,B,C} ( Using A → BC )

= {A, B , C , D , E } ( Using BC → DE )

={A,B,C,D,E,F} ( Using D → F )

={A,B,C,D,E,F,G} ( Using CF → G )

Thus, A + = { A , B , C , D , E , F , G }

Closure of attribute D

D+={D}

= { D , F } ( Using D → F )

We cannot determine any other attribute using attributes D and F contained in the result set.

Thus, D + = { D , F }

Closure of attribute set {B, C}

{ B , C }+ = { B , C }

= { B , C , D , E } ( Using BC → DE )

= { B , C , D , E , F } ( Using D → F )

= { B , C , D , E , F , G } ( Using CF → G )

Thus, { B , C }+ = { B , C , D , E , F , G }

Candidate Key-
● If there exists no subset of an attribute set whose closure contains all the attributes of the relation, then
that attribute set is called as a candidate key of that relation.

Finding Candidate Keys

We can determine the candidate keys of a given relation using the following steps

Step-01:

● Determine all essential attributes of the given relation.

● Essential attributes are those attributes which are not present on RHS of any functional dependency.
● Essential attributes are always a part of every candidate key.

● This is because they cannot be determined by other attributes

Example

Let R(A, B, C, D, E, F) be a relation scheme with the following functional dependencies

A→B

C→D

D→E

Here, the attributes which are not present on RHS of any functional dependency are A, C and F.

So, essential attributes are- A, C and F

Step-02:

● The remaining attributes of the relation are non-essential attributes.

● This is because they can be determined by using essential attributes.

Now, following two cases are possible-

Case-01:

If all essential attributes together can determine all remaining non-essential attributes, then-

● The combination of essential attributes is the candidate key.

● It is the only possible candidate key.

Case-02:

If all essential attributes together can not determine all remaining non-essential attributes, then-

● The set of essential attributes and some non-essential attributes will be the candidate key(s).

● In this case, multiple candidate keys are possible.

● To find the candidate keys, we check different combinations of essential and non-essential attributes.

Let R = (A, B, C, D, E, F) be a relation scheme with the following dependencies

C→F

E→A

EC → D

A→B
Which of the following is a key for R?

1. CD

2. EC

3. AE

4. AC

Determine the total number of candidate keys

Step-01:

● Determine all essential attributes of the given relation.

● Essential attributes of the relation are- C and E.

● So, attributes C and E will definitely be a part of every candidate key.

Step-02:

Now,

● We will check if the essential attributes together can determine all remaining non-essential attributes.

● To check, we find the closure of CE. So, we have-

{ CE }+ = { C , E }

= { C , E , F } ( Using C → F )

= { A , C , E , F } ( Using E → A )

= { A , C , D , E , F } ( Using EC → D )

= { A , B , C , D , E , F } ( Using A → B )

We conclude that CE can determine all the attributes of the given relation. So, CE is the only possible
candidate key of the relation.

Dependency Preserving Decomposition

Dependency Preservation: A Decomposition D = { R1, R2, R3…Rn } of R is dependency preserving
wrt a set F of Functional dependency if
(F1 ∪ F2 ∪ … ∪ Fm)+ = F+.
Consider a relation R
R ---> F{...with some functional dependency(FD)....}

R is decomposed or divided into R1 with FD { f1 } and R2 with { f2 }, then

there can be three cases:
f1 U f2 = F -----> Decomposition is dependency preserving.
f1 U f2 is a subset of F -----> Not Dependency preserving.
f1 U f2 is a super set of F -----> This case is not possible.

Problem:
Let a relation R (A, B, C, D ) and functional dependency {AB –> C, C –> D, D –> A}. Relation
R is decomposed into R1( A, B, C) and R2(C, D). Check whether decomposition is dependency
preserving or not.
Solution:

R1(A, B, C) and R2(C, D)

Let us find closure of F1 and F2

To find closure of F1, consider all combination of
ABC. i.e., find closure of A, B, C, AB, BC and AC
Note ABC is not considered as it is always ABC

closure(A) = { A } // Trivial
closure(B) = { B } // Trivial
closure(C) = {C, A, D} but D can't be in closure as D is not present R1.
= {C, A}
C--> A // Removing C from right side as it is trivial attribute

closure(AB) = {A, B, C, D}
= {A, B, C}
AB --> C // Removing AB from right side as these are trivial attributes

closure(BC) = {B, C, D, A}
= {A, B, C}
BC --> A // Removing BC from right side as these are trivial attributes

closure(AC) = {A, C, D}
NULL SET
F1 {C--> A, AB --> C, BC --> A}.
To find closure of F2, consider all combination of CD
closure(C) = { C }
{ C,D}
C--> D // Removing C from right side as it is trivial attribute

closure(D) = { D } // Trivial

closure(CD) = { CD }
= {CDA} but A can't be in closure as A is not present R2.
= {CD}
NULL SET // Removing CD from right side as it is trivial attribute
F2 = { C--> D }

In the original Relation Dependency { AB --> C , C --> D , D --> A}.

AB --> C is present in F1.
C --> D is present in F2.
D --> A is not preserved.

F1 U F2 is a subset of F. So given decomposition is not dependency preserving.