0% found this document useful (0 votes)
33 views5 pages

Unit 3

FD-A functional dependency is a constraint that specifies the relationship between two sets of attributes where one set can determine the value of the other set. It is denoted as X → Y, where X is the determinant set that determines the value of Y, the dependent set. Functional dependencies are used to mathematically express relations among database entities and are important for understanding relational database concepts. There are different types of functional dependencies including trivial, non-trivial, multivalued, and transitive FDs. The closure of a functional dependency is the complete set of attributes that can be functionally derived from the given FD using Armstrong's rules. Database keys like primary keys, super keys, candidate keys, alternate keys, and

Uploaded by

Anushka Gadge
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
33 views5 pages

Unit 3

FD-A functional dependency is a constraint that specifies the relationship between two sets of attributes where one set can determine the value of the other set. It is denoted as X → Y, where X is the determinant set that determines the value of Y, the dependent set. Functional dependencies are used to mathematically express relations among database entities and are important for understanding relational database concepts. There are different types of functional dependencies including trivial, non-trivial, multivalued, and transitive FDs. The closure of a functional dependency is the complete set of attributes that can be functionally derived from the given FD using Armstrong's rules. Database keys like primary keys, super keys, candidate keys, alternate keys, and

Uploaded by

Anushka Gadge
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

FD-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 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.
For example:Assume we have an employee table with attributes: Emp_Id, Emp_Name,
Emp_Address.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.Functional dependency can be written as-Emp_Id → Emp_Name .We can say that
Emp_Name is functionally dependent on Emp_Id.

TYPES OF FD-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 dependencyFor example(diagram) 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.For example,(DIAGRAM) 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,(diagram) 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,(diagram) 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.

CLOSURE SET OF FD-The Closure Of Functional Dependency means the complete set of all
possible attributes that can be functionally derived from given functional dependency using
the inference rules known as Armstrong’s Rules.If 1)“F” is a functional dependency then
closure of functional dependency can be denoted using “{F}+”.2)There are three steps to
calculate closure of functional dependency. These are:Step-1 : Add the attributes which are
present on Left Hand Side in the original functional dependency.Step-2 : Now, add the
attributes present on the Right Hand Side of the functional dependency.Step-3 : With the help
of attributes present on Right Hand Side, check the other attributes that can be derived from
the other given functional dependencies. Repeat this process until all the possible attributes
which can be derived are added in the closure.

TYPES OF KEY-1. Primary Key-The primary key refers to a column or a set of columns of a
table that helps us identify all the records uniquely present in that table. A table can consist of
just one primary key. Also, this primary key cannot consist of the same values
reappearing/repeating for any of its rows. All the values of a primary key have to be different,
and there should be no repetitions.The PK (PRIMARY KEY) constraint that we put on a
column/set of columns won’t allow these to have a null value or a duplicate. Any table can
consist of only a single primary key constraint. A foreign key (explained below) that refers to it
can never change the values present in the primary key.

2. Super Key-A super key refers to the set of all those keys that help us uniquely identify all
the rows present in a table. It means that all of these columns present in a table that can
identify the columns of that table uniquely act as the super keys.A super key is a candidate
key’s superset (candidate key has been explained below). We need to pick the primary key of
any table from the super key’s set so as to make it the table’s identity attribute.3. Candidate
KeY-The candidate keys refer to those attributes that identify rows uniquely in a table. In a
table, we select the primary key from a candidate key. Thus, a candidate key has similar
properties as that of the primary keys that we have explained above. In a table, there can be
multiple candidate keys.4. Alternate Key-As we have stated above, any table can consist of
multiple choices for the primary key. But, it can only choose one. Thus, all those keys that did
not become a primary key are known as alternate keys.5. Foreign Key-We use a foreign key to
establish relationships between two available tables. The foreign key would require every
value present in a column/set of columns to match the referential table’s primary key. A
foreign key helps us to maintain data as well as referential integrity. 6. Composite Key-The
composite key refers to a set of multiple attributes that help us uniquely identify every tuple
present in a table. The attributes present in a set may not be unique whenever we consider
them separately. Thus, when we take them all together, it will ensure total uniqueness.7.
Unique Key-A unique key refers to a column/a set of columns that identify every record
uniquely in a table. All the values in this key would have to be unique. Remember that a unique
key is different from a primary key. It is because it is only capable of having one null value. A
primary key, on the other hand, cannot have a null value.

1NF-If a relation contains a composite or multi-valued attribute, it violates the first normal
form, or the 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. 
A table is in 1 NF iff: 1)There are only Single Valued Attributes.2)Attribute Domain does not
change.3)There is a unique name for every Attribute/Column.4)The order in which data is
stored does not matter. 
 Consider the examples given below. 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. (DIAGRAM)
2NF-Second Normal Form (2NF) is based on the concept of full functional dependency.
Second Normal Form applies to relations with composite keys, that is, relations with a
primary key composed of two or more attributes. A relation with a single-attribute primary
key is automatically in at least 2NF. A relation that is not in 2NF may suffer from the update
anomalies.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. Note – If the proper
subset of candidate key determines non-prime attribute, it is called partial
dependency.The normalization of 1NF relations to 2NF involves the removal of partial
dependencies. If a partial dependency exists, we remove the partially dependent attribute(s)
from the relation by placing them in a new relation along with a copy of their determinant.
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(DIAGRAM)
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). If A->B and B-
>C are two FDs then A->C is called transitive dependency.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 (DIAGRAM) 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_PHONE, STUD_STATE, STUD_COUNTRY_STUD_AGE) as:
STUDENT (STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE, STUD_AGE)
STATE_COUNTRY (STATE, COUNTRY)
BCNF-Boyce–Codd Normal Form (BCNF) is based on functional dependencies  that take into
account all candidate keys in a relation; however, BCNF also has additional constraints
compared with the general definition of 3NF. A relation is in BCNF, if and only if, every
determinant is a Form (BCNF) candidate key.Note – To test whether a relation is in BCNF, we
identify all the determinants and make sure that they are candidate keys. You came across a
similar hierarchy known as Chomsky Normal Form in Theory of Computation. Now, carefully
study the hierarchy above. It can be inferred that every relation in BCNF is also in 3NF. To
put it another way, a relation in 3NF need not to be in BCNF. Ponder over this statement for a
while.To determine the highest normal form of a given relation R with functional
dependencies, the first step is to check whether the BCNF condition holds. If R is found to
be in BCNF, it can be safely deduced that the relation is also in 3NF, 2NF and 1NF as the
hierarchy shows. The 1NF has the least restrictive constraint – it only requires a relation R to
have atomic values in each tuple. The 2NF has a slightly more restrictive
constraint.Example-2:For example consider relation R(A, B, C)
A -> BC,
B -> A
A and B both are super keys so above relation is in BCNF.
Note –BCNF decomposition may always not possible with dependency preserving, however,
it always satisfies lossless join condition. For example, relation R (V, W, X, Y, Z), with
functional dependencies:
V, W -> X
Y, Z -> X
W -> Y
It would not satisfy dependency preserving BCNF decomposition.
Note -:Redundancies are sometimes still present in a BCNF relation as it is not always
possible to eliminate them completely.

4NF-Fourth normal form (4NF) is a level of database normalization where there are no non-
trivial multivalued dependencies other than a candidate key. It builds on the first three
normal forms (1NF, 2NF and 3NF) and the Boyce-Codd Normal Form (BCNF). It states that, in
addition to a database meeting the requirements of BCNF, it must not contain more than one
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..A table with a multivalued dependency
violates the normalization standard of Fourth Normal Form (4NK) because it creates
unnecessary redundancies and can contribute to inconsistent data. To bring this up to 4NF,
it is necessary to break this information into two tables. Example – Consider the database
table of a class which has two relations R1 contains student ID(SID) and student name
(SNAME) and R2 contains course id(CID) and course name (CNAME). 

DECOMPOSITION-The term decomposition refers to the process in which we break down a


table in a database into various elements or parts. Thus, decomposition replaces a given
relation with a collection of various smaller relations. Thus, in a database, we can make any
table break down into multiple tables when we want to collect a particular set of
data.Decomposition must always be lossless. This way, we can rest assured that the
data/information that was there in the original relation can be reconstructed accurately on the
basis of the decomposed relations. In case the relation is not decomposed properly, then it
may eventually lead to problems such as information loss. Properties of Decomposition-1.
Decomposition Must be Lossless-Decomposition must always be lossless, which means the
information must never get lost from a decomposed relation. This way, we get a guarantee that
when joining the relations, the join would eventually lead to the same relation in the result as it
was actually decomposed.2. 2)Dependency Preservation-Dependency is a crucial constraint
on a database, and a minimum of one decomposed table must satisfy every dependency. If {P
→ Q} holds, then two sets happen to be dependent functionally. Thus, it becomes more useful
when checking the dependency if both of these are set in the very same relation. This property
of decomposition can be done only when we maintain the functional dependency. Added to
this, this property allows us to check various updates without having to compute the database
structure’s natural join.3. Lack of Data Redundancy-It is also commonly termed as a repetition
of data/information. According to this property, decomposition must not suffer from data
redundancy. When decomposition is careless, it may cause issues with the overall data in the
database. When we perform normalization, we can easily achieve the property of lack of data
redundancy.TYPEES OF DECOMPOSITION-1)Lossless DecompositionIf the information is not
lost from the relation that is decomposed, then the decomposition will be lossless.The
lossless decomposition guarantees that the join of relations will result in the same relation as
it was decomposed.The relation is said to be lossless decomposition if natural joins of all the
decomposition give the original relation.2) Dependency Preserving-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)
1NF

2NF

3NF

4NF

TYPES OF FD-1) TRIVAL 2)NONTRIVL

3)multi 4)

You might also like