ER diagram-

ER diagram or Entity Relationship diagram is

a conceptual model that gives the graphical
representation of the logical structure of the
database.
It shows all the constraints and relationships that
exist among the diff erent components.
Components of ER diagram-
 An ER diagram is mainly composed of following three components-
 Entity Sets
 Attributes
 Relationship Set
 Example-
Consider the following Student table-

Roll_no Name Age

1 Akshay 20
2 Rahul 19
3 Pooja 20
4 Aarti 19

This complete table is referred to as “Student Entity Set” and each row
represents an “entity”.
Representation as ER Diagram-

 The above table may be represented as ER diagram as-

 Here,
 Roll_no is a primary key that can identify each entity uniquely.
 Thus, by using student’s roll number, a student can be identified uniquely.
ER Diagram Symbols-

An ER diagram is composed of several

components and each component in ER diagram
is represented using a specific symbol.
ER diagram symbols are discussed below-
1. For Entity Sets-
An entity set is a set of same type of entities.
An entity refers to any object having-
Either a physical existence such as a particular
person, office, house or car.
Or a conceptual existence such as a school or a
company.
 An entity set may be of the following two types-
 Strong entity set
 Weak entity set

 1. Strong Entity Set-

 A strong entity set possess its own primary key.
 It is represented using a single rectangle.

2. Weak Entity Set-

 A weak entity set do not possess its own primary key.

 It is represented using a double rectangle.
 Relationship defines an association among
several entities.
2.ForRelationshipSets-

A relationship set is a set of same type of

relationships.
A relationship set may be of the following two
types-
 Strong relationship set
 Weak relationship set
1. Strong Relationship Set-
 A strong relationship exists between two strong
entity sets.
 It is represented using a diamond symbol.

2. Weak Relationship Set-

 A weak or identifying relationship exists between the
strong and weak entity set.
 It is represented using a double diamond symbol.
3. For Attributes-
Attributes are the properties which describes
the entities of an entity set.
There are several types of attributes.
4. For Participation Constraints-

Participation constraint defines the least

number of relationship instances in which an
entity has to necessarily participate.
There are two types of participation
constraints-

1. Partial participation
2. Total participation
1. Partial Participation-
Partial participation is represented using a
single line between the entity set and
relationship set.
2. Total Participation-
Total participation is represented using a
double line between the entity set and
relationship set.
5. For Specialization and
Generalization-
Generalization is a process of forming a
generalized super class by extracting the
common characteristics from two or more
classes.
Specialization is a reverse process of
generalization where a super class is divided
into sub classes by assigning the specific
characteristics of sub classes to them.
Generalization is the process of extracting common
properties from a set of entities and create a generalized entity from
it. It is a bottom-up approach in which two or more entities can be
generalized to a higher level entity if they have some attributes in
common.
For Example, STUDENT and FACULTY can be generalized to a higher
level entity called PERSON as shown in Figure . In this case, common
attributes like P_NAME, P_ADD become part of higher entity
(PERSON) and specialized attributes like S_FEE become part of
specialized entity (STUDENT).
In specialization, an entity is divided into sub-entities based on their
characteristics. It is a top-down approach where higher level entity is
specialized into two or more lower level entities.

For Example, EMPLOYEE entity in an Employee management system can

be specialized into DEVELOPER, TESTER etc. as shown in Figure . In this
case, common attributes like E_NAME, E_SAL etc. become part of higher
entity (EMPLOYEE) and specialized attributes like TES_TYPE become part
of specialized entity (TESTER).
Aggregation –
An ER diagram is not capable of representing relationship between
an entity and a relationship which may be required in some
scenarios. In those cases, a relationship with its corresponding
entities is aggregated into a higher level entity.

For Example, Employee working for a project may require some

machinery. So, REQUIRE relationship is needed between
relationship WORKS_FOR and entity MACHINERY. Using
aggregation, WORKS_FOR relationship with its entities EMPLOYEE
and PROJECT is aggregated into single entity and relationship
REQUIRE is created between aggregated entity and MACHINERY.
6. For Cardinality Constraints / Ratios-

Cardinality constraint defines the maximum

number of relationship instances in which an
entity can participate.
There are 4 types of cardinality ratios-
 1. Strong Entity Set-
 A strong entity set is an entity set that contains sufficient
attributes to uniquely identify all its entities.
 In other words, a primary key exists for a strong entity set.
 Primary key of a strong entity set is represented by
underlining it.
Symbols Used-

 A single rectangle is used for representing a strong entity set.

 A diamond symbol is used for representing the relationship
that exists between two strong entity sets.
 A single line is used for representing the connection of the
strong entity set with the relationship set.
 A double line is used for representing the total participation
of an entity set with the relationship set.
 Total participation may or may not exist in the relationship.
 Example-
Consider the following ER diagram-

In this ER diagram,

Two strong entity sets “Student” and “Course” are related to each other.
Student ID and Student name are the attributes of entity set “Student”.
Student ID is the primary key using which any student can be identified
uniquely.
Course ID and Course name are the attributes of entity set “Course”.
Course ID is the primary key using which any course can be identified
uniquely.
Double line between Student and relationship set signifies total
participation.
It suggests that each student must be enrolled in at least one course.
Single line between Course and relationship set signifies partial
2. Weak Entity Set-
 A weak entity set is an entity set that does not contain sufficient attributes to uniquely
identify its entities.
 In other words, a primary key does not exist for a weak entity set.
 However, it contains a partial key called as a discriminator.
 Discriminator can identify a group of entities from the entity set.
 Discriminator is represented by underlining with a dashed line.

 NOTE-

 The combination of discriminator and primary key of the strong entity set makes it
possible to uniquely identify all entities of the weak entity set.
 Thus, this combination serves as a primary key for the weak entity set.
 Clearly, this primary key is not formed by the weak entity set completely.

 Symbols Used-

 A double rectangle is used for representing a weak entity set.
 A double diamond symbol is used for representing the relationship that exists between
the strong and weak entity sets and this relationship is known as identifying
relationship.
 A double line is used for representing the connection of the weak entity set with the
relationship set.
 Total participation always exists in the identifying relationship.
Example-
Consider the following ER diagram-

n this ER diagram,

One strong entity set “Building” and one weak entity set “Apartment”
are related to each other.
Strong entity set “Building” has building number as its primary key.
Door number is the discriminator of the weak entity set “Apartment”.
This is because door number alone can not identify an apartment
uniquely as there may be several other buildings having the same door
number.
Double line between Apartment and relationship set signifies total
participation.
It suggests that each apartment must be present in at least one building.
Single line between Building and relationship set signifies partial
participation.
Differences between Strong
entity set and Weak entity set-
Strong entity set Weak entity set
A single rectangle is used for the A double rectangle is used for
representation of a strong entity the representation of a weak
set. entity set.
It contains sufficient attributes to It does not contain sufficient
form its primary key. attributes to form its primary key.
A diamond symbol is used for the A double diamond symbol is used
representation of the relationship for the representation of the
that exists between the two identifying relationship that
strong entity sets exists between the strong and
weak entity set.
A single line is used for the A double line is used for the
representation of the connection representation of the connection
between the strong entity set and between the weak entity set and
the relationship. the relationship set.
Total participation may or may Total participation always exists
not exist in the relationship. in the identifying relationship.
Relationship in DBMS-
A relationship is defined as an association
among several entities.
Example-
 ‘Enrolled in’ is a relationship that exists
between entities Student and Course.

Relationship Set-

A relationship set is a set of relationships of

same type.
Example-
Types of Relationship Sets-
Set representation of above ER
On the basis of degree of a
diagram is-
relationship set, a
relationship set can be
classified into the following
types-

Degree of a Relationship Set-

The number of entity sets that

participate in a relationship set is
termed as the degree of that
relationship set. Thus,

Degree of a relationship set =

Number of entity sets
participating in a relationship set
1. Unary Relationship Set- 2. Binary Relationship Set-

Unary relationship set is a Binary relationship set is a

relationship set where only one relationship set where two entity sets
entity set participates in a participate in a relationship set.
relationship set. Example-
Example- Student is enrolled in a Course
One person is married to only one
person

3. Ternary Relationship Set-

Ternary relationship set is a

relationship set where three entity
sets participate in a relationship set.
Participation Constraints-
Types of Participation
Constraints-

There are two types of participation

constraints-
Example-

Double line between the entity

1. Total Participation- set “Student” and relationship
set “Enrolled in” signifies total
It specifies that each entity in the participation.
entity set must compulsorily It specifies that each student
participate in at least one must be enrolled in at least one
relationship instance in that course.
relationship set.
That is why, it is also called
as mandatory participation.
Total participation is represented
using a double line between the
 Example-
. Partial Participation-

It specifies that each entity in the

entity set may or may not participate
in the relationship instance in that
relationship set. Here,
That is why, it is also called Single line between the entity set
as optional participation. “Course” and relationship set
Partial participation is represented “Enrolled in” signifies partial
using a single line between the entity participation.
Example-
set and relationship set. It specifies that there might exist
some courses for which no
enrollments are made.
Relationship between Cardinality and
Participation Constraints-
Minimum cardinality tells whether the
participation is partial or total.
If minimum cardinality = 0, then it
signifies partial participation.
If minimum cardinality = 1, then it
signifies total participation.
Maximum cardinality tells the maximum
number of entities that participates in a
relationship set.
Attributes in ER Diagram- 1. Simple Attributes-

Attributes are the descriptive Simple attributes are those

properties which are owned by attributes which can not be
each entity of an Entity Set. divided further.
Example-
There exist a specific domain or
set of values for each attribute
from where the attribute can
take its values.
Types of Attributes-

In ER diagram, attributes associated

Here, all the attributes are
with an entity set may be of the
simple attributes as they can
following types-
not be divided further.
2. Composite Attributes- 3. Single Valued Attributes-

Composite attributes are those Single valued attributes are

attributes which are composed of those attributes which can take
many other simple attributes. only one value for a given entity
from an entity set.

Here, all the attributes are

Here, the attributes “Name” and
single valued attributes as
“Address” are composite attributes as
they can take only one
they are composed of many other
specific value for each
simple attributes.
entity.
4. Multi Valued Attributes- 5. Derived Attributes-

Multi valued attributes are those Derived attributes are those

attributes which can take more than attributes which can be derived
one value for a given entity from an from other attribute(s).
entity set.

Here, the attributes “Mob_no” and

“Email_id” are multi valued Here, the attribute “Age” is
attributes as they can take more than a derived attribute as it can
one values for a given entity. be derived from the
6. Key Attributes- attribute “DOB”.
Key attributes are those
attributes which can
identify an entity uniquely
in an entity set.
Here, the attribute “Roll_no” is a key
attribute as it can identify any
 Converting ER Diagrams to Tables-

ER diagram is converted into the

tables in relational model.
This is because relational models can
be easily implemented by RDBMS
like MySQL , Oracle etc.

Following rules are used for

converting an ER diagram into the
tables- Roll_no Name Sex
Rule-01: For Strong Entity Set
With Only Simple Attributes-

A strong entity set with only simple attributes

will require only one table in relational model. Schema : Student
•Attributes of the table will be the attributes
( Roll_no , Name , Sex )
of the entity set.
•The primary key of the table will be the key
attribute of the entity set.
Rule-02: For Strong Entity Set
With Composite Attributes-

1.A strong entity set with any number

of composite attributes will require
only one table in relational model.
2. While conversion, simple attributes
of the composite attributes are taken
into account and not the composite
attribute itself. Roll_n First_na Last_nam House_n Stre Cit
o me e o et y

Schema : Student ( Roll_no , First_name

, Last_name , House_no , Street , City )
Rule-03: For Strong Entity Set
With Multi Valued Attributes-

A strong entity set with any number

of multi valued attributes will require
two tables in relational model.
One table will contain all the simple
attributes with the primary key.
Other table will contain the primary Mobile
Roll_no
key and all the multi valued _no
attributes.

Roll_no City
 NOTE-
Rule-04: Translating Relationship
Set into a Table- If we consider the overall ER
diagram, three tables will be
A relationship set will require one required in relational model-
table in the relational model. One table for the entity set
Attributes of the table are- “Employee”
1.Primary key attributes of the One table for the entity set
participating entity sets “Department”
2. Its own descriptive attributes if One table for the relationship
any. set “Works in”
Set of non-descriptive attributes will
be the primary key.

Emp_n Dept_i
since
o d
 Rule-05: For Binary Relationships Case-01: For Binary Relationship
With Cardinality Ratios- With Cardinality Ratio m:n

The following four cases are possible-

Case-01: Binary relationship with

cardinality ratio m:n
Case-02: Binary relationship with
cardinality ratio 1:n
Case-03: Binary relationship with
cardinality ratio m:1 Here, three tables will be required-
Case-04: Binary relationship with A ( a1 , a2 )
cardinality ratio 1:1 R ( a1 , b1 )
B ( b1 , b2 )NOTE- Here,
combined table will
Case-02: For Binary Relationship be drawn for the
With Cardinality Ratio 1:n entity set B and
relationship set R.

Here, two tables will be

required-
A ( a1 , a2 )
BR ( a1 , b1 , b2 )
Case-03: For Binary Relationship Case-04: For Binary Relationship
With Cardinality Ratio m:1 With Cardinality Ratio 1:1

Here, two tables will be required.

Here, two tables will be required-
Either combine ‘R’ with ‘A’ or ‘B’
AR ( a1 , a2 , b1 )
B ( b1 , b2 )
Way-01:
AR ( a1 , a2 , b1 )
NOTE- Here, combined table will
B ( b1 , b2 )
be drawn for the entity set A and
relationship set R.
Way-02:
A ( a1 , a2 )
BR ( a1 , b1 , b2 )
 Thumb Rules to Remember

 While determining the minimum number of tables
required for binary relationships with given
cardinality ratios, following thumb rules must be kept
in mind-
 For binary relationship with cardinality ration m : n ,
separate and individual tables will be drawn for each
entity set and relationship.
 For binary relationship with cardinality ratio either
m : 1 or 1 : n , always remember “many side will
consume the relationship” i.e. a combined table will
be drawn for many side entity set and relationship set.
 For binary relationship with cardinality ratio 1 : 1 ,
two tables will be required. You can combine the
relationship set with any one of the entity sets.
Rule-06: For Binary Relationship Because cardinality ratio = 1 : n
With Both Cardinality Constraints , so we will combine the entity
and Participation Constraints- set B and relationship set R.
Then, two tables will be
Cardinality constraints will be required-
implemented as discussed in Rule-05. A ( a1 , a2 )
Because of the total participation BR ( a1 , b1 , b2 )
constraint, foreign key acquires NOT Because of total participation,
NULL constraint i.e. now foreign key foreign key a1 has acquired
can not be null. NOT NULL constraint, so it
can’t be null now.
Case-01: For Binary Relationship
With Cardinality Constraint and
Total Participation Constraint
From One Side-
Case-02: For Binary Relationship Rule-07: For Binary Relationship
With Cardinality Constraint and With Weak Entity Set-
Total Participation Constraint
Weak entity set always appears
From Both Sides-
in association with identifying
relationship with total
If there is a key constraint from both
participation constraint.
the sides of an entity set with total
participation, then that binary
relationship is represented using Here, two tables will be
only single table. required-
A ( a1 , a2 )
BR ( a1 , b1 , b2 )

Here, Only one table is required.

ARB ( a1 , a2 , b1 , b2 )
 PRACTICE PROBLEMS BASED ON CONVERTING ER DIAGRAM
TO TABLES-
Problem-01:
Find the minimum number of tables required for the following ER
diagram in relational model-

Problem-02:
Find the minimum number of tables required to represent the given
ER diagram in relational model-
 Solution-1
Applying the rules, minimum 3 tables will be required-
MR1 (M1 , M2 , M3 , P1) ,P (P1 , P2) ,NR2 (P1 , N1 , N2)
Solution-2
Applying the rules, minimum 4 tables will be
required-
AR1R2 (a1 , a2 , b1 , c1) ,B (b1 , b2), C (c1 , c2), R3
(b1 , c1)
Problem-03:
Find the minimum
number of tables
required to represent
the given ER diagram
in relational model
Solution-
Applying the rules that we have
learnt, minimum 6 tables will be
required-
Account (Ac_no , Balance , b_name)
Branch (b_name , b_city , Assets)
Loan (L_no , Amt , b_name)
Borrower (C_name , L_no)
Customer(C_name ,C_street , c_city)
Depositor (C_name , Ac_no)
Constraints in DBMS-
Relational constraints are the restrictions imposed on the database
contents and operations.
They ensure the correctness of data in the database.
Types of Constraints in DBMS-
In DBMS, there are following 5 different types of relational constraints-
1. Domain Constraint- 2. Tuple Uniqueness
Constraint-
Domain constraint defines the
domain or set of values for an Tuple Uniqueness constraint
attribute. specifies that all the tuples must
It specifies that the value taken by be necessarily unique in any
Example-01: Consider the following
the attribute must be the atomic relation.
Student table
value from its domain.
Example- Consider the following Student STU_I
Name Age
D
table-
STU_
ID
Name Age S00
Akshay 20
1
S00
Akshay 20 S00
1 Abhishek 21
2
S00 Abhishe
21 S00 Shashan
2 k 20
3
This relation k
satisfies the tuple
S00 Shasha uniqueness constraint since here
20 S00
3 nk all the tuplesRahul
are unique.20
Here, value ‘A’ is not allowed since 4
S00
only integerRahul
values canA be taken by
4
the age attribute.
Example-02: Consider the following 3. Key Constraint-
Student table- Key constraint specifies that in any
STU_I
relation-
Name Age
D 1.All the values of primary key must
be unique.
S00
Akshay 20 2.The value of primary key must not
1
be null.
Example-
S00 Consider the following Student
Akshay 20
1 table- STU_I
Name Age
D
S00 Shashan
20
3 k S00
This relation does not satisfy Akshay 20
1
the
S00tuple uniqueness
Rahul 20
4
constraint since here all the S00 Abhishe
21
tuples are not unique. 1 k
S00 Shashan
20
3 k
This relation does not satisfy the key
constraint
S00as here all the values of
Rahul 20
primary 4key are not unique
4. Entity Integrity Constraint- 5. Referential Integrity
Constraint-
Entity integrity constraint specifies
that no attribute of primary key must This constraint is enforced when a
contain a null value in any relation. foreign key references the primary
This is because the presence of null key of a relation.
value in the primary key violates the It specifies that all the values
uniqueness property. taken by the foreign key must
either be available in the relation
Example- of the primary key or be null.
Consider the following Student Important Results-
table-
STU_I
Name Age
D The following two important results
S00 emerges out due to referential
Akshay 20 integrity constraint-
1
1.We can not insert a record into a
S00 Abhishe referencing relation if the
21
2 k corresponding record does not exist
in the referenced relation.
S00 Shashan
20 2.We can not delete or update a
This3relationkdoes not satisfy the
record of the referenced relation if
entity integrity constraint as here the
Rahul 20 the corresponding record exists in
primary key contains a NULL value.
the referencing relation.
 Here,
Example- The relation ‘Student’ does
Consider the following two relations- not satisfy the referential
‘Student’ and ‘Department’. integrity constraint.
Here, relation ‘Student’ references This is because in relation
the relation ‘Department’. ‘Department’, no value of
primary key specifies
department no. 14.
Thus, referential integrity
constraint is violated.

STU_I Dept_na
Name Dept_no Dept_no
D me

S00 D10 ASET

Akshay D10
1
D11 ALS
S00
Abhishek D10 D12 ASFL
2
D13 ASHS
S00 Shashan
Student D11 Department
3 k
 Referential Integrity Constraint Violation-

There are following three possible causes of violation of

referential integrity constraint-
Cause-01: Insertion in a referencing relation
Cause-02: Deletion from a referenced relation
Cause-03: Updating in a referenced relation

Cause-01: Insertion in a Referencing Relation-

It is allowed to insert only those values in the referencing attribute which

are already present in the value of the referenced attribute.
Inserting a value in the referencing attribute which is not present in the
value of the referenced attribute violates the referential integrity
constraint. Here, relation “Student” references the
Example- Consider the following two schemas- relation “Branch”.
 Branch
Student
Branch
Roll_n Branch_Name
Name Age Branch_Code _Code
o

CS Computer Science
1 Rahul 22 CS
EE Electronics Engineering
2 Anjali 21 CS
IT Information Technology

3 Teena 20 IT
CE Civil Engineering

Here,
In relation “Student”, we can not insert any student having branch code
ME (Mechanical Engineering).
This is because branch code ME is not present in the relation “Branch”.
Cause-02: Deletion from a Referenced Relation-

It is not allowed to delete a row from the referenced relation if the

referencing attribute uses the value of the referenced attribute of
that row.
Such a deletion violates the referential integrity constraint.

Example-

Consider the above two relations,

We can not delete a tuple from the relation “Branch” having branch
code ‘CS’.
This is because the referencing attribute “Branch_Code” of the
referencing relation “Student” references the value ‘CS’.
However, we can safely delete a tuple from the relation “Branch”
having branch code ‘CE’.
This is because the referencing attribute “Branch_Code” of the
referencing relation “Student” does not uses this value.
Handling the Violation-

The violation caused due to a deletion from the referenced relation can
be handled in the following three ways-

Method-01:

This method involves simultaneously deleting those tuples from the

referencing relation where the referencing attribute uses the value of
referenced attribute being deleted.
This method of handling the violation is called as On Delete Cascade.
Method-02:
This method involves aborting or deleting the request for a deletion from
the referenced relation if the value is used by the referencing relation.

Method-03:
This method involves setting the value being deleted from the
referenced relation to NULL or some other value in the referencing
relation if the referencing attribute uses that value.
use-03: Updation in a Referenced Relation-

It is not allowed to update a row of the referenced relation if the

referencing attribute uses the value of the referenced attribute of that
row.
Such an updation violates the referential integrity constraint.
Example-
Consider the above relation.
We can not update a tuple in the relation “Branch” having branch
code ‘CS’ to the branch code ‘CSE’.
This is because referencing attribute “Branch_Code” of the
referencing relation “Student” references the value ‘CS’.
Handling the Violation-

The violation caused due to an updation in the referenced relation can

be handled in the following three ways-

Method-01:

This method involves simultaneously updating those tuples of the

referencing relation where the referencing attribute uses the referenced
attribute value being updated.
This method of handling the violation is called as On Update Cascade.

Method-02:

This method involves aborting or deleting the request for an updation of

the referenced relation if the value is used by the referencing relation.

Method-03:

This method involves setting the value being updated in the referenced
relation to NULL or some other value in the referencing relation if the
referencing attribute uses that value.
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 Example-

the closure of an attribute set-
Step-01: Consider a relation R ( A , B , C , D , E , F , G
) with the functional dependencies-
A → BC
Add the attributes contained in the BC → DE
attribute set for which closure is D→F
CF → G
being calculated to the result set.
Now, let us find the closure of some
Step-02: attributes and attribute sets-

Recursively add the attributes to the

result set which can be functionally
determined from the attributes
already contained in the result set.
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 can not 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 ,
Finding the Keys Using Closure-

Super Key-
If the closure result of an attribute set contains all the attributes of the
relation, then that attribute set is called as a super key of that relation.
Thus, we can say-
“The closure of a super key is the entire relation schema.”
Example-
In the above example,
The closure of attribute A is the entire relation schema.
Thus, attribute A is a super key for that relation.

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.

Example-
In the above example,
No subset of attribute A contains all the attributes of the relation.
Thus, attribute A is also a candidate key for that relation.
PRACTICE PROBLEM BASED ON FINDING CLOSURE OF
AN ATTRIBUTE SET-

Problem-

Consider the given functional dependencies-

AB → CD
AF → D
DE → F
C→G
F→E
G→A

Which of the following options is false?

(A) { CF }+ = { A , C , D , E , F , G }
(B) { BG }+ = { A , B , C , D , G }
(C) { AF }+ = { A , C , D , E , F , G }
(D) { AB }+ = { A , C , D , F ,G }
Solution-

Let us check each option one by one-

Option-(A):

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

Since, our obtained result set is same as the given result set, so, it means it is correctly given.

Option-(B):

{ BG }+ = { B , G }
={A,B,G } ( Using G → A )
={A,B,C,D,G } ( Using AB → CD )

Since, our obtained result set is same as the given result set, so, it means it is correctly given.

Option-(C):

{ AF }+ = { A , F }
={A,D,F} ( Using AF → D )
={A,D,E,F} ( Using F → E )

Since, our obtained result set is different from the given result set, so,it means it is not correctly given.

Option-(D):

{ AB }+ = { A , B }
={A,B,C,D} ( Using AB → CD )
={A,B,C,D,G } ( Using C → G )

Since, our obtained result set is different from the given result set, so,it means it is not correctly given.
Thus,
Option (C) and Option (D) are correct.
Different Types Of Keys in The terms ‘relation’ and ‘table’ are used
DBMS- interchangeably.
There are following 10 important The terms ‘tuple’ and ‘record’ are used
keys in DBMS- interchangeably.
1. Super Key- 2. Candidate Key-
A super key is a set of attributes that A minimal super key is called as a
can identify each tuple uniquely in the candidate key.
given relation.
A super key is not restricted to have A set of minimal attribute(s) that
any specific number of attributes. can identify each tuple uniquely
Thus, a super key may consist of any in the given relation is called as a
number of attributes. candidate key.
Example-
Example-
Consider the following Student Consider the following Student
schema- schema-
Student ( roll , name , sex , age , Student ( roll , name , sex , age
address , class , section ) , address , class , section )

Given below are the examples of super Given below are the examples of
keys since each set can uniquely candidate keys since each set
identify each student in the Student consists of minimal
table- attributes required to identify
( roll , name , sex , age , address , each student uniquely in the
class , section ) Student table-
( class , section , roll ) All the attributes in a( class
super, key
section , roll )
are definitely
sufficient
(class , section , roll , sex ) to identify (each
name , address
tuple ) in the
uniquely
( name , address ) given relation but all of them may not be
NOTES-

All the attributes in a candidate key are sufficient as well as necessary to

identify each tuple uniquely.
Removing any attribute from the candidate key fails in identifying each tuple
uniquely.
The value of candidate key must always be unique.
The value of candidate key can never be NULL.
It is possible to have multiple candidate keys in a relation.
Those attributes which appears in some candidate key are called as prime
attributes.
3. Primary Key-

A primary key is a candidate key that the database designer selects while
designing the database.
OR
Candidate key that the database designer implements is called as a
primary key.

NOTES-

The value of primary key can never be NULL.

The value of primary key must always be unique.
The values of primary key can never be changed i.e. no updation is
possible.
The value of primary key must be assigned when inserting a record.
4. Alternate Key-

Candidate keys that are left unimplemented or unused after implementing

the primary key are called as alternate keys.
OR
Unimplemented candidate keys are called as alternate keys.

5. Foreign Key-

An attribute ‘X’ is called as a foreign key to some other attribute ‘Y’ when
its values are dependent on the values of attribute ‘Y’.
The attribute ‘X’ can assume only those values which are assumed by the
attribute ‘Y’.
Here, the relation in which attribute ‘Y’ is present is called as
the referenced relation.
The relation in which attribute ‘X’ is present is called as the referencing
relation.
Example- Consider the following
two schemas-

Here, t_dept can take only those values which are present in dept_no in
Department table since only those departments actually exist.

NOTES-

Foreign key references the primary key of the table.

Foreign key can take only those values which are present in the primary
key of the referenced relation.
Foreign key may have a name other than that of a primary key.
Foreign key can take the NULL value.
There is no restriction on a foreign key to be unique.
In fact, foreign key is not unique most of the time.
Referenced relation may also be called as the master table or primary
table.
 6. Partial Key-
Partial key is a key using which all the records of the table can not be
identified uniquely.
However, a bunch of related tuples can be selected from the table using
Example-
the partial
Consider key. schema-
the following
Department ( Emp_no , Dependent_name , Relation )
Here, using partial key Emp_no, we can not identify a tuple uniquely but we can select a bunch of
tuples from the table.

Dependent_na
Emp_no Relation
me

E1 Suman Mother

E1 Ajay Father

E2 Vijay Father
E2 Ankush Son
7. Composite Key-

A primary key comprising of multiple attributes and not just a single attribute is called as a
composite key.

8. Unique Key-

Unique key is a key with the following properties-

•It is unique for all the records of the table.
•Once assigned, its value can not be changed i.e. it is non-updatable.
•It may have a NULL value.

Example-

The best example of unique key is Adhaar Card Numbers.

•The Adhaar Card Number is unique for all the citizens (tuples) of India (table).
•If it gets lost and another duplicate copy is issued, then the duplicate copy always has the
same number as before.
•Thus, it is non-updatable.
•Few citizens may not have got their Adhaar cards, so for them its value is NULL.
9. Surrogate Key-

Surrogate key is a key with the following properties-

•It is unique for all the records of the table.
•It is updatable.
•It can not be NULL i.e. it must have some value.

Example-

Mobile Number of students in a class where every student owns a mobile phone.

10. Secondary Key-

Secondary key is required for the indexing purpose for better and faster searching.
 Functional Dependency-

In any relation, a functional dependency α → β holds if-

Two tuples having same value of attribute α also have same value for
attribute β.

If α and β are the two sets of attributes in a relational table R where-

•α ⊆ R
•β ⊆ R
Then, for a functional dependency to exist from α to β,
If t1[α] = t2[α], then t1[β] = t2[β]

α β

t1[α] t1[β]
t2[α] t2[β]
……. …….

fd : α → β
 Types Of Functional Dependencies-
There are two types of functional dependencies-

1. Trivial Functional 2. Non-Trivial Functional

Dependencies- Dependencies-

A functional dependency X → Y is A functional dependency X → Y is

said to be trivial if and only if Y ⊆ X. said to be non-trivial if and only if
Thus, if RHS of a functional Y ⊄ X.
dependency is a subset of LHS, then Thus, if there exists at least one
it is called as a trivial functional attribute in the RHS of a functional
dependency. dependency that is not a part of LHS,
then it is called as a non-trivial
Examples- functional dependency.

The examples of trivial functional Examples-

dependencies are-
AB → A The examples of non-trivial
AB → B functional dependencies are-
Inference Rules-

Reflexivity-
If B is a subset of A, then A → B always holds.

Transitivity-
If A → B and B → C, then A → C always holds.

Augmentation-
If A → B, then AC → BC always holds.

Decomposition-
If A → BC, then A → B and A → C always holds.

Composition-
If A → B and C → D, then AC → BD always holds.

Additive-
If A → B and A → C, then A → BC always holds.