/

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 1

Chapter 10
Functional Dependencies and
Normalization for Relational
Databases

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Chapter Outline
■ 1 Informal Design Guidelines for Relational Databases
■ 1.1Semantics of the Relation Attributes
■ 1.2 Redundant Information in Tuples and Update Anomalies
■ 1.3 Null Values in Tuples
■ 1.4 Spurious Tuples

■ 2 Functional Dependencies (FDs)

■ 2.1 Definition of FD
■ 2.2 Inference Rules for FDs
■ 2.3 Equivalence of Sets of FDs
■ 2.4 Minimal Sets of FDs

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 3

Chapter Outline
■ 3 Normal Forms Based on Primary Keys
■ 3.1 Normalization of Relations
■ 3.2 Practical Use of Normal Forms
■ 3.3 Definitions of Keys and Attributes Participating in Keys
■ 3.4 First Normal Form
■ 3.5 Second Normal Form
■ 3.6 Third Normal Form

■ 4 General Normal Form Definitions (4NF For Multiple

Keys)

■ 5 BCNF (Boyce-Codd Normal Form)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 4

1 Informal Design Guidelines for
Relational Databases (1)

■ What is relational database design?

■ The grouping of attributes to form "good" relation
schemas
■ Two levels of relation schemas
■ The logical "user view" level
■ The storage "base relation" level
■ Design is concerned mainly with base relations
■ What are the criteria for "good" base relations?

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 5

Informal Design Guidelines for Relational
Databases (2)
■ We first discuss informal guidelines for good relational
design
■ Then we discuss formal concepts of functional
dependencies and normal forms
■ - 1NF (First Normal Form)
■ - 2NF (Second Normal Form)
■ - 3NF (Third Normal Form)
■ - BCNF (Boyce-Codd Normal Form)
■ Additional types of dependencies, further normal forms,
relational design algorithms by synthesis are discussed in
Chapter 11

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 6

1.1 Semantics of the Relation Attributes
■ GUIDELINE 1: Informally, each tuple in a relation should
represent one entity or relationship instance. (Applies to
individual relations and their attributes).
■ Attributes of different entities (EMPLOYEEs,
DEPARTMENTs, PROJECTs) should not be mixed in the
same relation
■ Only foreign keys should be used to refer to other entities
■ Entity and relationship attributes should be kept apart as
much as possible.
■ Bottom Line: Design a schema that can be explained
easily relation by relation. The semantics of attributes
should be easy to interpret.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 7

Figure 10.1 A simplified COMPANY
relational database schema

Slide 10- 8
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
1.2 Redundant Information in Tuples and
Update Anomalies

■ Information is stored redundantly

■ Wastes storage
■ Causes problems with update anomalies
■ Insertion anomalies
■ Deletion anomalies
■ Modification anomalies

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 9

EXAMPLE OF AN UPDATE ANOMALY

■ Consider the relation:

■ EMP_PROJ(Emp#, Proj#, Ename, Pname,
No_hours)
■ Update Anomaly:
■ Changing the name of project number P1 from
“Billing” to “Customer-Accounting” may cause this
update to be made for all 100 employees working
on project P1.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 10

EXAMPLE OF AN INSERT ANOMALY

■ Consider the relation:

■ EMP_PROJ(Emp#, Proj#, Ename, Pname,
No_hours)
■ Insert Anomaly:
■ Cannot insert a project unless an employee is
assigned to it.
■ Conversely
■ Cannot insert an employee unless an he/she is
assigned to a project.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 11

EXAMPLE OF AN DELETE ANOMALY

■ Consider the relation:

■ EMP_PROJ(Emp#, Proj#, Ename, Pname,
No_hours)
■ Delete Anomaly:
■ When a project is deleted, it will result in deleting
all the employees who work on that project.
■ Alternately, if an employee is the sole employee on
a project, deleting that employee would result in
deleting the corresponding project.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 12

Example of Anomalies

• Insertion anomaly:
• If a tuple is inserted in
referencing relation and
referencing attribute
value is not present in
referenced attribute, it
will not allow inserting in
referencing relation.
• For Example, If we try to
insert a record in
STUDENT_COURSE
with STUD_NO =7, it will
not allow.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

• Deletion and Update anomaly:
• If a tuple is deleted or updated from referenced
relation and referenced attribute value is used by
referencing attribute in referencing relation, it will
not allow deleting the tuple from referenced
relation.
• For Example, If we try to delete a record from
STUDENT with STUD_NO =1, it will not allow.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 14

Figure 10.3 Two relation schemas
suffering from update anomalies

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 15

Figure 10.4 Example States for
EMP_DEPT and EMP_PROJ

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 16

Guideline to Redundant Information in
Tuples and Update Anomalies

■ GUIDELINE 2:
■ Design a schema that does not suffer from the
insertion, deletion and update anomalies.
■ If there are any anomalies present, then note them
so that applications can be made to take them into
account.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 17

1.3 Null Values in Tuples
■ GUIDELINE 3:
■ Relations should be designed such that their
tuples will have as few NULL values as possible
■ Attributes that are NULL frequently could be
placed in separate relations (with the primary key)
■ It causes confusion in COUNT and SUM
operation.
■ If NULL value comes in comparision with SELECT
or JOIN operation, the result will unpredictable.
■

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 18

■ Reasons for nulls:
■ Attribute not applicable or invalid
■ Attribute value unknown (may
exist)
■ Value known to exist, but
unavailable

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 19

1.4 Spurious Tuples
■ Bad designs for a relational database may result in
erroneous results for certain JOIN operations
■ The "lossless join" property is used to guarantee
meaningful results for join operations(LOS

■ GUIDELINE 4:
■ The relations should be designed to satisfy the
lossless join condition i.means No spurious tuples
should be generated by doing a natural-join of any
relations.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 20

Spurious Tuples (2)
■ There are two important properties of decompositions:
a) Non-additive or losslessness of the corresponding join
b) Preservation of the functional dependencies.

■ Note that:
■ Property (a) is extremely important and cannot be
sacrificed.
■ Property (b) is less stringent and may be sacrificed. (See
Chapter 11).

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 21

Example:

■ The relation EMP_PROJ is decomposed into two

relations: EMP_LOCS and EMP_PROJ1.
■ by re-joining of these two relations will generate some
spurious tuples.
■ So the join operation will not get original EMP_Proj
relation.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 22

Example

• Spurious Tuples Example

• Consider the poorly designed relations
EMP_PROJ1

• This poorly designed table is split on the basis

of ploc(non PK)We get EMP-LOC AND
EMP-PROJ

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

•

• NOW IF EMP-LOC AND EMP-PROJ JOINED ON THE

BASIS OF PLOC, will not get proper output
• We will not get original
table.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

2.1 Functional Dependencies (1)
■ Functional dependencies (FDs)
■ Are used to specify formal measures of the
"goodness" of relational designs
■ And keys are used to define normal forms for
relations
■ Are constraints that are derived from the meaning
and interrelationships of the data attributes
■ A set of attributes X functionally determines a set
of attributes Y if the value of X determines a
unique value for Y

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 25

Keys:
■ 1. Superkey:
■ All possible combination of keys are called
superkeys.
■ Uniquely identify record.
■ Superkey is a superset, we can derive other keys
from superkey.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 26

■ {ID},{SSN},
■ {ID,Name},{Name,SSN}
■ {ID,SSN},{ID,phone},
■ ID,email
■ Name,email
■ Name,ssn,email
■ Id,SSN,Phone
■ {Name,Salary}
■ Here, {Name,Salary} can’t become a
superkey.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 27

Candidate key
■ Minimal set of superkey.
■ From the following set of superkeys:
{ID},{SSN},{ID,Name},{Name,SSN},{ID,SSN},{ID,phone},
{ID,email},{Name,email},{Name,ssn,email},{Id,SSN,Phone},
{Name,Salary}
■ We can select candidate key (minimal set)
■ Such as,
■ {ID} and {SSN} can be a separate candidate
keys.
■ {email}, {Name,Phone}
■ {ID,Name} cant be candidate key, bcz ID is a
part of another candidate key. Slide 10- 28
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Primary key
■ Primary key should be unique and not null
■ Example:
Candidate keys in above examples are:
{ID},{SSN},{Email},{Name,phone}
Primary key is :{ID} or {SSN}
Not both.
{ID} is preferred.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 29

Alternate Keys
The candidate key other than primary key are
called alternate keys.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Unique key & Composite key
■ It should contain ■ Composite key:
unique values, but ■ Combination of Two
accept NULL values. or More attribute
■ Example: ■ Example:
■ {Name,Phone} and ■ {Name,Phone}
{email} can be a ■ {ID,Phone}
unique keys.
■ {ID,Name}.. etc.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 31

Foreign key
■ A foreign key in DBMS is a field that establishes and
maintains a link between two separate tables.
■ It acts as a constraint ensuring data and referential
integrity within relational databases.
■ Using foreign keys ensures that the data stored in
different tables are consistent, helping maintain the
relationship between the two tables while preventing any
unauthorized modifications.
■ In addition, they can also be used to create connections
among multiple entities to organize information for better
retrieval from the database.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 32

Example
■ This foreign key relationship ensures referential integrity between the
two tables.
■ It means that every value in the Stud_id column of the Department
table must correspond to a valid Stud_id in the Student table.
■ For example, you can't insert a record into the Department table with
a Stud_id that doesn't exist in the Courses table. This helps to
maintain consistency

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 33

Proper subset:
• A proper subset of a set A is a subset of A that is not equal to A.
• In other words, if B is a proper subset of A, then all elements of B are in A but A
contains at least one element that is not in B.
• if A={1,3,5} then B={1,5} is a proper subset of A.
• The set C={1,3,5} is a subset of A, but it is not a proper subset of A since C=A.
• Example:
• Let us consider in relation R(A,B,C,D),
• If {A,B,C} is a super key, then proper subset of this super key are:
• {A},
• {B}
• {C}
• {A,B}
• {A,C}
• {B,C}

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Functional Dependencies (2)
■ X -> Y holds if whenever two tuples have the same value
for X, they must have the same value for Y
■ For any two tuples t1 and t2 in any relation instance r(R): If
t1[X]=t2[X], then t1[Y]=t2[Y]
■ X -> Y in R specifies a constraint on all relation instances
r(R)
■ Written as X -> Y; can be displayed graphically on a
relation schema as in Figures. ( denoted by the arrow: ).
■ FDs are derived from the real-world constraints on the
attributes

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 35

Examples of FD constraints (1)
■ Social security number determines employee
name
■ SSN -> ENAME
■ Project number determines project name and
location
■ PNUMBER -> {PNAME, PLOCATION}
■ Employee ssn and project number determines the
hours per week that the employee works on the
project
■ {SSN, PNUMBER} -> HOURS

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 36

Examples of FD constraints (2)
■ An FD is a property of the attributes in the
schema R
■ The constraint must hold on every relation
instance r(R)
■ If K is a key of R, then K functionally determines
all attributes in R
■ (since we never have two distinct tuples with
t1[K]=t2[K])

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 37

functional dependency

• The functional dependency is a relationship that

exists between two 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.
• X is called Determinant, while on the right
side, Y is called the Dependent.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

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.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Example
• In this example,
• FD: X -> Y

• FD: if t1.X = t2.X

• then t1.Y = t2.Y • if t1.x= 2 t2.x = 2
true
• Here,
• if t1.x= 1 t2.x = 2 • Then t1.Y=1 t2.Y =5
false false

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

• Consider the following table:

• RNO -> Name

• FD
• Name -> RNO
• FD doesn’t exist
• RNO -> Marks
• FD exist
• Name –Marks
• FD exist
• Dept -> Course
• FD doesn’t exist
• Marks -> Dept
• FD doesn’t exist
• {RNO, Name} -> Marks
• FD exist
• {Name, Marks} -> Dept
• FD doesn’t exist

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

2.3 Equivalence of Sets of FDs
■ Two sets of FDs F and G are equivalent if:
■ Every FD in F can be inferred from G, and
■ Every FD in G can be inferred from F
■ Hence, F and G are equivalent if F+ =G+
■ Definition (Covers):
■ F covers G if every FD in G can be inferred from F
■ (i.e., if G+ subset-of F+)
■ F and G are equivalent if F covers G and G covers F
■ There is an algorithm for checking equivalence of sets of
FDs

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 42

2.4 Minimal Sets of FDs (1)
■ A set of FDs is minimal if it satisfies the
following conditions:
1. Every dependency in F has a single attribute for
its RHS.
2. We cannot remove any dependency from F and
have a set of dependencies that is equivalent to
F.
3. We cannot replace any dependency X -> A in F
with a dependency Y -> A, where Y
proper-subset-of X ( Y subset-of X) and still have
a set of dependencies that is equivalent to F.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 43

Minimal Sets of FDs (2)
■ Every set of FDs has an equivalent minimal set
■ There can be several equivalent minimal sets
■ There is no simple algorithm for computing a
minimal set of FDs that is equivalent to a set F of
FDs
■ To synthesize a set of relations, we assume that
we start with a set of dependencies that is a
minimal set
■ E.g., see algorithms 11.2 and 11.4

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 44

2.2 Inference Rules for FDs (1)
■ Given a set of FDs F, we can infer additional FDs that
hold whenever the FDs in F hold
■ Armstrong's inference rules:
■ IR1. (Reflexive) If Y subset-of X, then X -> Y
If X ⊆ Y then X → Y
• Example:
{Rno,Name} -> Name
Here , name is a subset of {rno, name}

■ IR2. (Augmentation) If X -> Y, then XZ -> YZ

■ (Notation: XZ stands for X U Z)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 45

 ■ IR3. (Transitive) If X -> Y and Y -> Z, then X -> Z

■ IR1, IR2, IR3 form a sound and complete set of

inference rules
■ These are rules hold and all other rules that hold can be
deduced from these

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 46

Inference Rules for FDs (2)
■ Some additional inference rules that are useful:
■ Decomposition: If X -> YZ, then X -> Y and X ->
Z
■ Union: If X -> Y and X -> Z, then X -> YZ
■ Psuedotransitivity: If X -> Y and WY -> Z, then
WX -> Z

■ The last three inference rules, as well as any

other inference rules, can be deduced from IR1,
IR2, and IR3 (completeness property)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 47

Inference Rules for FDs (3)
■ Closure of a set F of FDs is the set F+ of all FDs
that can be inferred from F

■ Closure of a set of attributes X with respect to F

is the set X+ of all attributes that are functionally
determined by X

■ X+ can be calculated by repeatedly applying IR1,

IR2, IR3 using the FDs in F

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 48

Types of Functional dependencies

1. Full dependency
2. Partial dependancy
3. Trivial functional dependency
4. Non-Trivial functional dependency
5. Multivalued functional dependency
6. Transitive functional dependency

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Fully functional dependency

• An attribute is fully ■ Here, Eid -> Dept and

functional dependent E_name ->Dept,
on X and if Y is FD on these 2 functional
X but not FD on any dependencies doesn’t
proper subset of X. exist.

■ Hence ,
■ Dept is completely
depend on
{Eid,Ename}.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Partial functional dependency
• An attribute is fully ■ Here, Eid -> Dept and
functional dependent E_name ->Dept,
on X and if Y is FD on these 2 functional
X but not FD on any dependencies exist
proper subset of X. (individually).
■ That means either Eid
or Ename can
determine Dept.
■ Hence ,
■ Dept is partially
depend on
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Trivial Functional Dependency:

• In , a dependent is always a subset of the

determinant.
i.e. If X → Y and Y is the subset of X, then it
is called trivial functional dependency
• For example,
• 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.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

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,
• 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}

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Multivalued Functional
Dependency
• In Multivalued functional dependency, attributes
of the dependent set are not dependent on each
other.
• i.e. If a → {b, c} and there exists no functional
dependency between b and c, then it is called
a multivalued functional dependency.
• Here, roll_no → {name, age} is a multivalued
functional dependency, since the
dependents name & age are not dependent on
• each other(i.e. name → age or age → name doesn’t exist
!)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

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
• Example:
• Here, enrol_no → dept and dept → building_no,

• Hence, according to the axiom of transitivity, enrol_no

→ building_no is a valid functional dependency.
• This is an indirect functional dependency, hence called
Transitive functional dependency.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Find superkeys
■ If we have ‘N’ attributes with one candidate key
then the number of possible superkeys is 2(N – 1).
■ Example:
■ Let's say we have a relation R with attributes {a1,
a2, a3} and a1 is the candidate key.
■ Then, any superset of a1 is the super key.
■ Here n=3, thus, we can have 2(3– 1)= 2^2= 4 ,
■ four possible super keys: {a1, a1 a2, a1 a3, a1
a2 a3}.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 56

Examples
■ Steps to Find the Attribute Closure:
■ Given the FD set of a Relation R, The attribute
closure set S is the set of Attribute Closure A.
■ Add A to S.
■ Recursively add attributes that can be functionally

determined from attributes of the set S until done .

■ From Table 1, FDs are

■ Given R (E-ID, E-NAME, E-CITY, E-STATE)
FDs = { E-ID->E-NAME, E-ID->E-CITY, E-ID->E-STATE,
E-CITY->E-STATE }

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 57

■ The attribute closure of E-ID can be calculated
as:
■ Add E-ID to the set {E-ID}
■ Add Attributes that can be derived from any
attribute of the set.
■ As there is one other attribute remaining in
relation to be derived from E-ID.
■ So the result is:
■ (E-ID)+ = {E-ID, E-NAME, E-CITY, E-STATE }

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 58

■ Similarly,
■ (E-NAME)+ = {E-NAME}

■ (E-CITY)+ = {E-CITY, E_STATE}

■ (E-STATE)+ = { E_STATE}

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 59

Example
■ Find the attribute closures of (B)+ ,given
FDs R(ABCDE) = {AB->C, B->D, C->E, D->A}.
■ (B)+ = {B}
= {B,D}
={ B,D,A}
={B,D,A,C}
={B,D,A,C,E}

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 60

 Closure of FD EXAMPLE’S
Ex1. To find Candidate keys
• PRIME ATTRIBUTE:
• R(ABCD)
• FD: {A B,B C,C D} The set of attributes
• Ans: makes candidate key are
• Closure of A means what A
determines.
called prime attributes.
• Find closure of all attributes: Here,
• A+= {A,B,C,D} S.K
• B+={B,C,D} Prime attributes are : {A}
• C+={C,D} Non –prime: {B,C,D}
• D+={D}
• AB+={ABCD} S.K
• AC+ = {ABCD} S.K Hence, candidate key is
• AD+ = ABC+ = ABD+ = ACD+ . . . S.K
A.
• CK={A}

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Example
• Given Relation R(A,B,C,D,E) & FD: {A B, D E}

• ABCDE+ = {A,B,C,D,E} S.K

• ACDE+ = {A,B,C,D,E} S.K
• ACD+ = {A,B,C,D,E} S.K
• How to check ACD is only the candidate key.
• Prime attributes: {A,C,D}
• Check any of the prime attribute is available in
R.H.S of Functional Dependency i.e A,C & D
• No any prime attribute is present in RHS. So we can
say that is the only candidate key {ACD}.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe