This document discusses database normalization and removing redundancy from database designs. It covers the concepts of functional dependencies, normal forms including first normal form, and decomposition. The key points covered are: - Normalization aims to remove redundancy from database designs to avoid issues like update anomalies. - Functional dependencies specify constraints on attribute values and are used to test for redundancy. - First normal form requires attributes to be atomic and indivisible. - Decomposition can break relations into smaller relations to remove redundancy, but it must be a lossless join decomposition to avoid loss of information.

1. 01/09/15
1
Normalization
IF-2213 Pemrograman Basis Data
Tahun Ajaran 2012-2013

2. 01/09/15
2
Introductory
ER Model
Relational Model
ER-to-
Relational
SQL
DB Programming
Normalization
Sumber: Fundamentals of Database Systems, Elmasri, Navathe

3. 01/09/15
3
Database Design
Relational
Schema DBMS
Requirement
Analysis
ER
Diagram

4. 01/09/15
4
Motivation
• How do we tell if a design is bad (or good)?
• This design has redundancy, because the name of a department
is recorded multiple times, once for each staff member

5. 01/09/15
5
Motivation
• Storing the same information redundantly, that is, in more than
one place within a database, 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 some
information unless some other information is stored as well.
– Deletion anomalies: It may not be possible to delete some
information without losing some other information as well.
• How about a systematic approach to detecting and removing
redundancy in designs?
– Dependencies, decompositions, and normal forms

6. 01/09/15
6
First Normal Form
• Domain is atomic if its elements are considered to be indivisible
units
– Examples of non-atomic domains:
• Set of names, composite attributes
• Identification numbers like CS101 that can be broken up
into parts
• A relational schema R is in first normal form if the domains of all
attributes of R are atomic
• Non-atomic values complicate storage and encourage redundant
(repeated) storage of data
– Example: Set of dependents stored with each employee
– We assume all relations are in first normal form

7. 01/09/15
7
• EMPLOYEE table is not normal
– It has cells with non-atomic value
– dep-ID value for the first row could be 3274 or 7846
• This table has no primary key.
– no-employee can not determined dep-ID or dep-name.
– If no-employee is 46072, dep-ID could be 4907 or 6203
EMPLOYEE

8. 01/09/15
8
• EMPLOYEE table above shown the same data as the previous
slide. It has been re-arrange.
• But this form becomes unusable as relasional model
– dep-ID and dep-name is a repeating attribute set
EMPLOYEE

9. 01/09/15
9
EMPLOYEE
EMPLOYEE DEPENDENT
First Normal Form

10. 01/09/15
10
First Normal Form (Cont.)
• Atomicity is actually a property of how the elements of the domain
are used.
– Example: Strings would normally be considered indivisible
– Suppose that students are given roll numbers which are
strings of the form CS0012 or EE1127
– If the first two characters are extracted to find the department,
the domain of roll numbers is not atomic.
– Doing so is a bad idea: leads to encoding of information in
application program rather than in the database.

11. 01/09/15
11
Motivation
• Storing the same information redundantly, that is, in more than
one place within a database, 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 some
information unless some other information is stored as well.
– Deletion anomalies: It may not be possible to delete some
information without losing some other information as well.
• How about a systematic approach to detecting and removing
redundancy in designs?
– Dependencies, decompositions, and normal forms

12. 01/09/15
12
Functional Dependencies
• Constraints on the set of legal relations.
• Require that the value for a certain set of attributes determines
uniquely the value for another set of attributes.

13. 01/09/15
13
Functional Dependencies (Cont.)
• Let R be a relation schema
α ⊆ R and β ⊆ R
• The functional dependency
α → β
holds on R if and only if for any legal relations r(R), whenever
any two tuples t1 and t2 of r agree on the attributes α, they also
agree on the attributes β. That is,
t1[α] = t2 [α] ⇒ t1[β ] = t2 [β ]
• Example: Consider r(A,B ) with the following instance of r.
• On this instance, A → B does NOT hold, but B → A does hold.
1 4
1 5
3 7

14. 01/09/15
14
Functional Dependencies (Cont.)
• K is a superkey for relation schema R if and only if K → R
• K is a candidate key for R if and only if
– K → R, and
– for no α ⊂ K, α → R

15. 01/09/15
15
Example of Functional Dependencies
• A → C is satisfied
– There are two tuples that have an
A value of a1. These tuples have
the same C value—namely, c1.
– Similarly, the two tuples with an A
value of a2 have the same C
value, c2.
– There are no other pairs of distinct
tuples that have the same A value.
• The functional dependency C → A is
not satisfied.
• Many other functional dependencies
are satisfied by r, including, for
example, the functional dependency
AB → D

16. 01/09/15
16
Functional Dependencies (Cont.)
• A functional dependency is trivial if it is satisfied by all instances
of a relation
– Example:
• ID, name → ID
• name → name
– In general, α → β is trivial if β ⊆ α

17. 01/09/15
17
Use of Functional Dependencies
• We use functional dependencies to:
– test relations to see if they are legal under a given set of
functional dependencies.
• If a relation r is legal under a set F of functional
dependencies, we say that r satisfies F.
– specify constraints on the set of legal relations
• We say that F holds on R if all legal relations on R satisfy
the set of functional dependencies F.
• Note: A specific instance of a relation schema may satisfy a
functional dependency even if the functional dependency does
not hold on all legal instances.
– For example, a specific instance of instructor may, by chance,
satisfy
name → ID.

18. 01/09/15
18
Functional Dependencies vs. Real World

19. 01/09/15
19
Reasoning
• Given a relation R and a set of FD’s F
– Does another FD follow from F?
– Are some of the FD’s in F redundant (i.e., they follow from the
others)?
• Is K a key of R?
– What are all the keys of R?

20. 01/09/15
20
Closure of Attribute Sets
• Given a set of attributes α, define the closure of α under F
(denoted by α+
) as the set of attributes that are functionally
determined by α under F
• Algorithm to compute α+
, the closure of α under F
result := α;
while (changes to result) do
for each β → γ in F do
begin
if β ⊆ result then result := result ∪ γ
end

21. 01/09/15
21
Example of Attribute Set Closure
• R = (A, B, C, G, H, I)
• F = {A → B
A → C
CG → H
CG → I
B → H}
• (AG)+
1. result = AG
2. result = ABCG (A → C and A → B)
3. result = ABCGH (CG → H and CG ⊆ AGBC)
4. result = ABCGHI (CG → I and CG ⊆ AGBCH)
• Is AG a candidate key?
1. Is AG a super key?
1. Does AG → R? == Is (AG)+
⊇ R
2. Is any subset of AG a superkey?
1. Does A → R? == Is (A)+
⊇ R
2. Does G → R? == Is (G)+
⊇ R

22. 01/09/15
22
Uses of Attribute Closure
There are several uses of the attribute closure algorithm:
• Testing for superkey:
– To test if α is a superkey, we compute α+,
and check if α+
contains all attributes of R.
• Testing functional dependencies
– To check if a functional dependency α → β holds, just check if
β ⊆ α+
.
– That is, we compute α+
by using attribute closure, and then
check if it contains β.
– Is a simple and cheap test, and very useful

23. 01/09/15
23
Using rules of FD’s
• Given a relation R and set of FD’s F
– Does another FD α → β follow from F?

24. 01/09/15
24
Closure of a Set of Functional
Dependencies
• Given a set F of functional dependencies, there are certain other
functional dependencies that are logically implied by F.
– For example: If A → B and B → C, then we can infer that A
→ C
• The set of all functional dependencies logically implied by F is the
closure of F.
• We denote the closure of F by F+
.
• F+
is a superset of F.

25. 01/09/15
25
Closure of a Set of Functional
Dependencies
• We can find F+,
the closure of F, by repeatedly applying
Armstrong’s Axioms:
– if β ⊆ α, then α → β (reflexivity)
– if α → β, then γ α → γ β (augmentation)
– if α → β, and β → γ, then α → γ (transitivity)
• These rules are
– sound (generate only functional dependencies that actually
hold), and
– complete (generate all functional dependencies that hold).

26. 01/09/15
26
Closure of Functional Dependencies
(Cont.)
• Additional rules:
– If α → β holds and α → γ holds, then α → β γ holds (union)
– If α → β γ holds, then α → β holds and α → γ holds
(decomposition)
– If α → β holds and γ β → δ holds, then α γ → δ holds
(pseudotransitivity)
The above rules can be inferred from Armstrong’s axioms.

27. 01/09/15
27
Procedure for Computing F+
• To compute the closure of a set of functional dependencies F:
F +
= F
repeat
for each functional dependency f in F+
apply reflexivity and augmentation rules on f
add the resulting functional dependencies to F +
for each pair of functional dependencies f1and f2 in F +
if f1 and f2 can be combined using transitivity
then add the resulting functional dependency to F +
until F +
does not change any further

28. 01/09/15
28
Example
• R = (A, B, C, G, H, I)
F = { A → B
A → C
CG → H
CG → I
B → H}
• some members of F+
– A → H
• by transitivity from A → B and B → H
– AG → I
• by augmenting A → C with G, to get AG → CG
and then transitivity with CG → I
– CG → HI
• by augmenting CG → I to infer CG → CGI,
and augmenting of CG → H to infer CGI → HI,
and then transitivity

29. 01/09/15
29
Example of redundancy
• StudentGrade (SID, name, email, CID, grade)
• SID → name, email

30. 01/09/15
30
Decomposition
• Eliminates redundancy
– To get back to the original relation:

31. 01/09/15
31
Unnecessary decomposition
• Fine: join returns the original relation
• Unnecessary: no redundancy is removed, and now SID is stored
twice!

32. 01/09/15
32
Bad decomposition
• Association between CID and grade is lost
• Join returns more rows than the original relation

33. 01/09/15
33
Lossless join decomposition
• Decompose relation R into relations S and T
– attrs(R) = attrs(S) attrs(T)∪
• The decomposition is a lossless join decomposition if, given
known constraints such as FD’s, we can guarantee that R = S
T
• Any decomposition gives R S T⊆
– A lossy decomposition is one with R S T⊂

34. 01/09/15
34
Loss? But I got more rows!
• “Loss” refers not to the loss of tuples, but to the loss of
information
• Or, the ability to distinguish different original relations

35. 01/09/15
35
Goals of Normalization
• Let R be a relation scheme with a set F of functional
dependencies.
• Decide whether a relation scheme R is in “good” form.
• In the case that a relation scheme R is not in “good” form,
decompose it into a set of relation scheme {R1, R2, ..., Rn} such
that
– each relation scheme is in good form
– the decomposition is a lossless-join decomposition
– Preferably, the decomposition should be dependency
preserving.

36. 01/09/15
36
Example
• R = (A, B, C)
F = {A → B, B → C)
– Can be decomposed in two different ways
• R1 = (A, B), R2 = (B, C)
– Lossless-join decomposition:
R1 ∩ R2 = {B} and B → BC
– Dependency preserving
• R1 = (A, B), R2 = (A, C)
– Lossless-join decomposition:
R1 ∩ R2 = {A} and A → AB
– Not dependency preserving
(cannot check B → C without computing R1 R2)

37. 01/09/15
37
Normalization
• The normal forms based on FDs are
– first normal form (1NF),
– second normal form (2NF),
– third normal form (3NF), and
– Boyce-Codd normal form (BCNF).
• These forms have increasingly restrictive requirements:
– Every relation in BCNF is also in 3NF,
– every relation in 3NF is also in 2NF, and
– every relation in 2NF is in 1NF.
• 2NF is mainly of historical interest.
• 3NF and BCNF are important from a database design standpoint.

38. 01/09/15
38
Boyce-Codd Normal Form
• A relation schema R is in BCNF with respect to a set F of
functional dependencies if for all functional dependencies in F+
of
the form α→ β where α ⊆ R and β ⊆ R, at least one of the
following holds:
– α → β is trivial (i.e., β ⊆ α)
– α is a superkey for R
• Example schema not in BCNF:
instr_dept (ID, name, salary, dept_name, building, budget )
– because dept_name→ building, budget holds on instr_dept,
but dept_name is not a superkey

39. 01/09/15
39
Decomposing a Schema into BCNF
• Suppose we have a schema R and a non-trivial dependency
α→β causes a violation of BCNF.
• We decompose R into:
– (αU β )
– ( R - ( β - α ) )
• In our example,
– α = dept_name
– β = building, budget
and inst_dept is replaced by
– (αU β ) = ( dept_name, building, budget )
– ( R - ( β - α ) ) = ( ID, name, salary, dept_name )

40. 01/09/15
40
BCNF Decomposition Algorithm
result := {R };
done := false;
compute F +
;
while (not done) do
if (there is a schema Ri in result that is not in BCNF)
then begin
let α → β be a nontrivial functional dependency that
holds on Ri such that α → Ri is not in F +
,
and α ∩ β = ∅;
result := (result – Ri) ∪ (Ri – β) ∪ (α, β );
end
else done := true;
Note: each Ri is in BCNF, and decomposition is lossless-join.

41. 01/09/15
41
Example of BCNF Decomposition
• R = (A, B, C )
F = {A → B
B → C}
Key = {A}
• R is not in BCNF (B → C but B is not superkey)
• Decomposition
– R1 = (B, C)
– R2 = (A,B)

42. 01/09/15
42
Example of BCNF Decomposition
• class (course_id, title, dept_name, credits, sec_id, semester,
year, building, room_number, capacity, time_slot_id)
• Functional dependencies:
– course_id→ title, dept_name, credits
– building, room_number→capacity
– course_id, sec_id, semester, year→building, room_number,
time_slot_id
• A candidate key {course_id, sec_id, semester, year}.
• BCNF Decomposition:
– course_id→ title, dept_name, credits holds
• but course_id is not a superkey.
– We replace class by:
• course(course_id, title, dept_name, credits)
• class-1 (course_id, sec_id, semester, year, building,
room_number, capacity, time_slot_id)

43. 01/09/15
43
BCNF Decomposition (Cont.)
• course is in BCNF
– How do we know this?
• building, room_number→capacity holds on class-1
– but {building, room_number} is not a superkey for class-1.
– We replace class-1 by:
• classroom (building, room_number, capacity)
• section (course_id, sec_id, semester, year, building,
room_number, time_slot_id)
• classroom and section are in BCNF.

44. 01/09/15
44
Third Normal Form
• A relation schema R is in third normal form (3NF) if for all:
α → β in F+
at least one of the following holds:
– α → β is trivial (i.e., β ∈ α)
– α is a superkey for R
– Each attribute A in β – α is contained in a candidate key for R.
(NOTE: each attribute may be in a different candidate key)
• If a relation is in BCNF it is in 3NF (since in BCNF one of the first
two conditions above must hold).
• Third condition is a minimal relaxation of BCNF to ensure
dependency preservation

45. 01/09/15
45
3NF Example
• Relation dept_advisor:
– dept_advisor (s_ID, i_ID, dept_name)
F = {s_ID, dept_name → i_ID, i_ID → dept_name}
– Two candidate keys: s_ID, dept_name, and i_ID, s_ID
– R is in 3NF
• s_ID, dept_name → i_ID
– s_ID, dept_name is a superkey
• i_ID → dept_name
– dept_name is contained in a candidate key

46. 01/09/15
46
Testing for 3NF
• Optimization: Need to check only FDs in F, need not check all
FDs in F+
.
• Use attribute closure to check for each dependency α → β, if α is
a superkey.
• If α is not a superkey, we have to verify if each attribute in β is
contained in a candidate key of R
– this test is rather more expensive, since it involve finding
candidate keys
– testing for 3NF has been shown to be NP-hard
– Interestingly, decomposition into third normal form (described
shortly) can be done in polynomial time

47. 01/09/15
47
3NF Decomposition Algorithm
i := 0;
for each functional dependency α → β in F do
if none of the schemas Rj, 1 ≤ j ≤ i contains α β
then begin
i := i + 1;
Ri := α β
end
if none of the schemas Rj, 1 ≤ j ≤ i contains a candidate key for R
then begin
i := i + 1;
Ri := any candidate key for R;
end
/* Optionally, remove redundant relations */
repeat
if any schema Rj is contained in another schema Rk
then /* delete Rj */
Rj = Rk;
i=i-1;
return (R1, R2, ..., Ri)

48. 01/09/15
48
3NF Decomposition Algorithm (Cont.)
• Above algorithm ensures:
– each relation schema Ri is in 3NF
– decomposition is dependency preserving and lossless-join

49. 01/09/15
49
• Relation schema:
timetable = (course#, section#, room, instructor, course-title, credit-
hours)
• The functional dependencies for this relation schema are:
1. course#, section# → room, instructor
2. course# → course-title, credit-hours
• course# → course-title, credit-hours is called partial dependency (where
a set of attribute has dependency to part of a candidate key)

50. 01/09/15
50
3NF Decomposition Example (Cont.)
• The for loop generates following 3NF schema:
(course#, section#, room, instructor)
(course#, course-title, credit-hours)
– Observe that (course#, section#, room, instructor) contains a
candidate key of the original schema, so no further relation
schema needs be added
• At end of for loop, detect and delete schemas, which are subsets
of other schemas
– In this example, no relation are deleted
– result will not depend on the order in which FDs are
considered
• The resultant simplified 3NF schema is:
(course#, section#, room, instructor)
(course#, course-title, credit-hours)

51. 01/09/15
51
• Relation schema:
acedemic-staff = (prof#, prof-name, dept-code, office#, dept-
aide, dept-fax#)
• The functional dependencies for this relation schema are:
1. prof# → prof-name, dept-code, office#
2. dept-code → dept-aide, dept-fax#
• dept-code → dept-aide, dept-fax# is called transitive dependency
(where a set of attribute has dependency to another attribute that
is not a candidate key)

52. 01/09/15
52
3NF Decomposition Example (Cont.)
• The for loop generates following 3NF schema:
(prof#, prof-name, dept-code, office#)
(dept-code, dept-aide, dept-fax#)
– Observe that (prof#, prof-name, dept-code, office#) contains a
candidate key of the original schema, so no further relation
schema needs be added
• At end of for loop, detect and delete schemas, which are subsets
of other schemas
– In this example, no relation are deleted
• The resultant simplified 3NF schema is:
(prof#, prof-name, dept-code, office#)
(dept-code, dept-aide, dept-fax#)

53. 01/09/15
53
• Relation schema:
empoyee-productivity= (emp#, date, emp-name, hours-worked,
emp-class, wages-rate, units-produced)
• What are the functional dependencies for this relation schema?
• Decompose into 3NF

54. 01/09/15
54
3NF Decomposition: An Example
• Relation schema:
cust_banker_branch = (customer_id, employee_id,
branch_name, type )
• The functional dependencies for this relation schema are:
1. customer_id, employee_id → type
2. employee_id → branch_name
3. customer_id, branch_name → employee_id

55. 01/09/15
55
3NF Decompsition Example (Cont.)
• The for loop generates following 3NF schema:
(customer_id, employee_id, type )
(employee_id, branch_name)
(customer_id, branch_name, employee_id)
– Observe that (customer_id, employee_id, type ) contains a
candidate key of the original schema, so no further relation
schema needs be added
• At end of for loop, detect and delete schemas, such as
(employee_id, branch_name), which are subsets of other
schemas
• The resultant simplified 3NF schema is:
(customer_id, employee_id, type)
(customer_id, branch_name, employee_id)

56. 01/09/15
56
Design Goals
• Goal for a relational database design is:
– BCNF.
– Lossless join.
– Dependency preservation.
• If we cannot achieve this, we accept one of
– Lack of dependency preservation
– Redundancy due to use of 3NF
• Interestingly, SQL does not provide a direct way of specifying
functional dependencies other than superkeys.
Can specify FDs using assertions, but they are expensive to test,
(and currently not supported by any of the widely used databases!)
• Even if we had a dependency preserving decomposition, using SQL
we would not be able to efficiently test a functional dependency
whose left hand side is not a key.

57. 01/09/15
57
Overall Database Design Process
• We have assumed schema R is given
– R could have been generated when converting E-R diagram to
a set of tables.
– R could have been a single relation containing all attributes
that are of interest (called universal relation).
– Normalization breaks R into smaller relations.
– R could have been the result of some ad hoc design of
relations, which we then test/convert to normal form.

58. 01/09/15
58
ER Model and Normalization
• When an E-R diagram is carefully designed, identifying all entities
correctly, the tables generated from the E-R diagram should not
need further normalization.
• However, in a real (imperfect) design, there can be functional
dependencies from non-key attributes of an entity to other
attributes of the entity
– Example: an employee entity with attributes
department_name and building,
and a functional dependency
department_name→ building
– Good design would have made department an entity
• Functional dependencies from non-key attributes of a relationship
set possible, but rare --- most relationships are binary

59. 01/09/15
59
Denormalization for Performance
• May want to use non-normalized schema for performance
• For example, displaying prereqs along with course_id, and title
requires join of course with prereq
• Alternative 1: Use denormalized relation containing attributes of
course as well as prereq with all above attributes
– faster lookup
– extra space and extra execution time for updates
– extra coding work for programmer and possibility of error in
extra code
• Alternative 2: use a materialized view defined as
course prereq
– Benefits and drawbacks same as above, except no extra
coding work for programmer and avoids possible errors

60. 01/09/15
60
Other Design Issues
• Some aspects of database design are not caught by
normalization
• Examples of bad database design, to be avoided:
Instead of earnings (company_id, year, amount ), use
– earnings_2004, earnings_2005, earnings_2006, etc., all on
the schema (company_id, earnings).
• Above are in BCNF, but make querying across years
difficult and needs new table each year
– company_year (company_id, earnings_2004, earnings_2005,
earnings_2006)
• Also in BCNF, but also makes querying across years
difficult and requires new attribute each year.
• Is an example of a crosstab, where values for one
attribute become column names
• Used in spreadsheets, and in data analysis tools

61. 01/09/15
61
Questions
IF-2305 Pemrograman Basis Data
Tahun Ajaran 2010-2011

62. 01/09/15
62
Question 1
• Show the anomalies that we encounter in this relation
• List all functional dependencies satisfied by the relation

63. 01/09/15
63
Question 2
• List all functional dependencies satisfied by the relation

64. 01/09/15
64
Question 3
• List all functional dependencies satisfied by the relation

65. 01/09/15
65
Question 4
• Compute the closure of the following set F of functional
dependencies for relation schema R = (A, B, C, D, E).
A →B
BC →E
ED → A
• Using the functional dependencies, compute BC+
.
• List the candidate keys for R.

66. 01/09/15
66
Question 5
• Compute the closure of the following set F of functional
dependencies for relation schema R = (A, B, C, D, E).
A →BC
CD →E
B → D
E → A
• Using the functional dependencies, compute B+
.
• List the candidate keys for R.

67. 01/09/15
67
Question 6
• Consider the following instance of a relation R:
• The functional dependencies of R, not including trivial ones, are:
– saleID → salesman regNo make office
– salesman → office
– regNo → make
• Decompose the relation into BCNF. For each step of the decomposition
procedure, state what functional dependency it is based on, and give the
relation schemas after the step has been carried out.
• State the relation instances in your BCNF schema corresponding to the
above instance of R. Give an example of an update anomaly of the original
relation schema that has been eliminated in the BCNF schema.

68. 01/09/15
68
Question 7
• We consider the following relation:
Articles(ID,title,journal,issue,year,startpage,endpage,TR-ID)
• It contains information on articles published in scientific journals.
Each article has a unique ID, a title, and information on where to
find it (name of journal, what issue, and on which pages). Also, if
results of an article previously appeared in a “technical report”
(TR), the ID of this technical report can be specified. We have the
following information on the attributes:
– For each journal, an issue with a given number is published in
a single year.
– The endpage of an article is never smaller than the startpage.
– There is never (part of) more than one article on a single
page.
• The following is an instance of the relation:

69. 01/09/15
69
Question 7 (Cont.)
• The following is an instance of the relation:
• Based on the above, indicate for each of the following sets of
attributes whether it is a key for Articles or not.
1. {ID}; 2. {ID,TR-ID}; 3. {ID,title,TR-ID}
4. {title}; 5. {title,year}; 6. {startpage,journal,issue}

70. 01/09/15
70
Question 7 (Cont.)
• Based on the above, indicate for each of the following potential
functional dependencies, whether it is indeed an FD or not.
1. ID → title; 2. startpage → endpage; 3. journal issue → year
4. title → ID; 5. ID → startpage ,endpage, journal,issue;
6. TR-ID → ID
• Based on a) and b), perform normalization into BCNF, and state
the resulting relations.

71. 01/09/15
71
Question 8
• Given is the following set of functional dependencies F for the
universal relation U:
U= {A, B, C, D, E, G}
F= {E → D, C → B, CE → G, B → A}
• What is the Key of U?
• Use the 3NF Decomposition Algorithm to normalize U.

72. 01/09/15
72
Question 9
• Consider the following relational schema:
U = {A,B,C,D,E, F},
F = {A → BE,AE → BD, F → CD,CD → BEF,CF → B}
• Find all candidate keys of R.
• Apply the decompotition algorithm to derive a schema in third
normal form.