Professional Documents
Culture Documents
Database System Concepts - 6th Edition 8.2 ©Silberschatz, Korth and Sudarshan
Combine Schemas?
Suppose instead of instructor and department we combine them into
in_dep
instructor (ID, name, salary,dept_name); department (dept_name,
building, budget)
Result is possible repetition of information
Database System Concepts - 6th Edition 8.3 ©Silberschatz, Korth and Sudarshan
Combine Schemas ? Cont.
Possible null values
A new department is created, no instructors yet. (Null required for
id, name, salary)
The schema department can handle this
Database System Concepts - 6th Edition 8.4 ©Silberschatz, Korth and Sudarshan
What About Smaller Schemas?
Suppose we had started with in_dep. How would we know to split up
(decompose) it into instructor and department?
Write a rule “if there were a schema (dept_name, building, budget), then
dept_name would be a candidate key”
Denote as a functional dependency:
dept_name building, budget
dept_name determines building,budget
In in_dep, because dept_name is not a candidate key, the building and
budget of a department may have to be repeated.
This indicates the need to decompose in_dep
Database System Concepts - 6th Edition 8.5 ©Silberschatz, Korth and Sudarshan
Lossy decompositions
Not all decompositions are good. Suppose we decompose
employee(ID, name, street, city, salary) into
employee1 (ID, name)
employee2 (name, street, city, salary)
What is the consequence ?
Database System Concepts - 6th Edition 8.6 ©Silberschatz, Korth and Sudarshan
A Lossy Decomposition
Database System Concepts - 6th Edition 8.7 ©Silberschatz, Korth and Sudarshan
Lossy decomposition cont.
We lose information
we cannot reconstruct the original employee relation
so, this is a lossy decomposition.
Database System Concepts - 6th Edition 8.8 ©Silberschatz, Korth and Sudarshan
Example of Lossless-Join Decomposition
Lossless join decomposition
Decomposition of R = (A, B, C)
R1 = (A, B) R2 = (B, C)
A B C A B B C
1 A 1 1 A
2 B 2 2 B
r A,B(r) B,C(r)
A B C
A,B (r) B,C (r)
1 A
2 B
Database System Concepts - 6th Edition 8.9 ©Silberschatz, Korth and Sudarshan
Lossless-Join Decomposition
Database System Concepts - 6th Edition 8.10 ©Silberschatz, Korth and Sudarshan
First Normal Form
Domain is atomic if its elements are considered to be indivisible units
Examples of non-atomic domains:
Set of names (children of an employee), composite attributes
Employee Identification numbers like CS0022 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 accounts stored with each customer, and set of
owners stored with each account as separate relations
If an account is to be added, needs addition in two places
Enough if only one relation is stored
– but which one ?
– Complicates queries if only one is stored
Database System Concepts - 6th Edition 8.11 ©Silberschatz, Korth and Sudarshan
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 programs
rather than in the database.
– A student changing department will require changes to roll
number; if roll numbers are primary keys, changes in multiple
places
We assume all relations are in first normal form
Database System Concepts - 6th Edition 8.12 ©Silberschatz, Korth and Sudarshan
Goal — Devise a Theory for the Following
Database System Concepts - 6th Edition 8.13 ©Silberschatz, Korth and Sudarshan
Functional Dependencies
An instance of a relation that satisfies all real-life constraints is a legal
relation
Examples of some constraints on a university database:
1. Students and instructors are uniquely identified by their ID.
2. Each student and instructor has only one name
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.
Generalization of the notion of a key.
Database System Concepts - 6th Edition 8.14 ©Silberschatz, Korth and Sudarshan
Notations
Greek letter – set of attributes eg.
May or may not be a schema
Uppercase Roman letter - relation schema eg. R
Lowercase Roman letter – relation eg. r
r(R) thus refers to the relation r with schema R
When a set of attributes is a superkey, we may denote it by K
Database System Concepts - 6th Edition 8.15 ©Silberschatz, Korth and Sudarshan
Functional Dependencies (Cont.)
Let r(R ) be a relation schema (R denotes the set of attributes)
R and R
The functional dependency
holds on R
if and only if for any legal relation 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.
1 4
1 5
3 7
Database System Concepts - 6th Edition 8.16 ©Silberschatz, Korth and Sudarshan
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
Functional dependencies allow us to express constraints that cannot be
expressed using superkeys. Consider the schema:
in_dep (ID, name, salary, dept_name, building, budget ).
We expect these functional dependencies to hold:
dept_name building
and dept_name budget
but would not expect the following to hold:
dept_name salary
Database System Concepts - 6th Edition 8.17 ©Silberschatz, Korth and Sudarshan
Use of Functional Dependencies
Database System Concepts - 6th Edition 8.18 ©Silberschatz, Korth and Sudarshan
Functional Dependencies (Cont.)
A functional dependency is trivial if
Examples:
ID, name ID
name name
Database System Concepts - 6th Edition 8.19 ©Silberschatz, Korth and Sudarshan
Closure of a Set of Functional
Dependencies
Database System Concepts - 6th Edition 8.20 ©Silberschatz, Korth and Sudarshan
Boyce-Codd Normal Form
is trivial (i.e., )
is a superkey for R
In other words: “R is in BCNF if the only non-trivial FDs over R
are key constraints.”
Example schema not in BCNF:
Database System Concepts - 6th Edition 8.22 ©Silberschatz, Korth and Sudarshan
Decomposing a Schema into BCNF
Database System Concepts - 6th Edition 8.23 ©Silberschatz, Korth and Sudarshan
Decompose into BCNF
Database System Concepts - 6th Edition 8.24 ©Silberschatz, Korth and Sudarshan
Dependency preservation
instructor student
s_id
i_id dept_advisor name
name tot_cred
salary
department
dept_name
building
budget
Database System Concepts - 6th Edition 8.25 ©Silberschatz, Korth and Sudarshan
Dependency preservation cont.
Database System Concepts - 6th Edition 8.27 ©Silberschatz, Korth and Sudarshan
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.
The third condition is a minimal relaxation of BCNF to ensure
dependency preservation (will see why later).
A relation in 3NF may have redundancies due to FDs
Database System Concepts - 6th Edition 8.28 ©Silberschatz, Korth and Sudarshan
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
Database System Concepts - 6th Edition 8.29 ©Silberschatz, Korth and Sudarshan
Redundancy in 3NF
There is some redundancy in this schema
Example of problems due to redundancy in 3NF
R = (J, K, L)
F = {JK L, L K } J L K
j1 l1 k1
j2 l1 k1
j3 l1 k1
null l2 k2
Database System Concepts - 6th Edition 8.30 ©Silberschatz, Korth and Sudarshan
Goals of Normalization
Database System Concepts - 6th Edition 8.31 ©Silberschatz, Korth and Sudarshan
How good is BCNF?
There are database schemas in BCNF that do not seem to be
sufficiently normalized
Consider a relation
inst_info (ID, child_name, phone)
where an instructor may have more than one phone and can have
multiple children
ID child_name phone
99999 512-555-1234
David
512-555-4321
99999 David
512-555-1234
99999 William
512-555-4321
99999 Willian
inst_info
Database System Concepts - 6th Edition 8.32 ©Silberschatz, Korth and Sudarshan
How good is BCNF? (Cont.)
Database System Concepts - 6th Edition 8.33 ©Silberschatz, Korth and Sudarshan
How good is BCNF? (Cont.)
ID phone
This suggests the need for higher normal forms, such as Fourth
Normal Form (4NF), which is more restrictive than BCNF.
Database System Concepts - 6th Edition 8.34 ©Silberschatz, Korth and Sudarshan
Functional-Dependency Theory
We now consider the formal theory that tells us
which functional dependencies are implied logically by a given set
of functional dependencies.
We then develop algorithms to generate lossless decompositions into
BCNF and 3NF
We then develop algorithms to test if a decomposition is dependency-
preserving
Database System Concepts - 6th Edition 8.35 ©Silberschatz, Korth and Sudarshan
Closure of a Set of Functional
Dependencies
Database System Concepts - 6th Edition 8.36 ©Silberschatz, Korth and Sudarshan
Closure of a Set of Functional
Dependencies
Database System Concepts - 6th Edition 8.37 ©Silberschatz, Korth and Sudarshan
Example
R = (A, B, C, G, H, I)
F={ AB
AC
CG H
CG I
B H}
some members of F+
AH
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
Database System Concepts - 6th Edition 8.38 ©Silberschatz, Korth and Sudarshan
Procedure for Computing F+
To compute the closure of a set of functional dependencies F:
F+=F
apply the reflexivity rule /* generates trivial FDs */
repeat
for each functional dependency f in F+
apply 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
Database System Concepts - 6th Edition 8.39 ©Silberschatz, Korth and Sudarshan
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.
The above rules are sound. Proof ?
Database System Concepts - 6th Edition 8.40 ©Silberschatz, Korth and Sudarshan
Testing whether a set is a superkey
An attribute B is functionally determined by a set of attributes if
To test whether is a superkey
Compute a set of attributes functionally determined by
For this,
1. Compute F+
2. Take all FDs with as the LHS
3. Take the union of the RHS of each such FD
Expensive, as F+ can be large.
Database System Concepts - 6th Edition 8.41 ©Silberschatz, Korth and Sudarshan
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
result := ;
repeat
for each in F do
begin
if result then result := result
end
until (no change to result)
Database System Concepts - 6th Edition 8.42 ©Silberschatz, Korth and Sudarshan
Example of Attribute Set Closure
R = (A, B, C, G, H, I)
F = {A B
AC
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 ABCG)
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
Database System Concepts - 6th Edition 8.43 ©Silberschatz, Korth and Sudarshan
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 (or, in other
words, is in F+), 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
Computing closure of F
For each R, we find the closure +, and for each S +, we
output a functional dependency S such that Ո S = Ø
Database System Concepts - 6th Edition 8.44 ©Silberschatz, Korth and Sudarshan
Computing F+ using attribute closure
F= { AB -> C, AD -> B, B -> D }
Database System Concepts - 6th Edition 8.45 ©Silberschatz, Korth and Sudarshan
Proof of algorithm for attribute closure of under F
1 result := ;
2 repeat
3 for each in F do
4 begin
5 if result then result := result
6 end
7 until (no change to result)
Database System Concepts - 6th Edition 8.46 ©Silberschatz, Korth and Sudarshan
The algorithm finds all of
We need to prove that the algorithm is complete. That is, if A ε R-
result, then resultA does not hold on R
We construct an instance r of R with two tuples such that
F holds on r
resultA does not hold on R for A ε R –result
This is possible because if held on R, if result , then is
added to result
What is the complexity of the algorithm ?
Database System Concepts - 6th Edition 8.47 ©Silberschatz, Korth and Sudarshan
Canonical Cover
Sets of functional dependencies may have redundant dependencies
that can be inferred from the others
For example: A C is redundant in: {A B, B C, A C}
Parts of a functional dependency may be redundant
E.g.: {A B, B C, A CD} can be simplified to
{A B, B C, A D}
Intuitively, a canonical cover of F is a “minimal” set of functional
dependencies equivalent to F, having no redundant dependencies or
redundant parts of dependencies
Database System Concepts - 6th Edition 8.48 ©Silberschatz, Korth and Sudarshan
Why find the canonical cover ?
When a relation is updated, the DBMS must check that there are no
FD violations
Checking with the canonical cover of F is efficient
Database System Concepts - 6th Edition 8.49 ©Silberschatz, Korth and Sudarshan
Extraneous Attributes
Consider a set F of functional dependencies and the functional
dependency in F.
Attribute A is extraneous in if A
and F logically implies (F – { }) {( – A) }.
(Now a smaller set of attributes determine .The FD has become
“stronger”)
F = {AB → C, A → D, D → C} implies F = {A → C, A → D, D → C}
Database System Concepts - 6th Edition 8.50 ©Silberschatz, Korth and Sudarshan
Extraneous Attributes
Consider a set F of functional dependencies and the functional
dependency in F.
Attribute A is extraneous in if A
and the set of functional dependencies
(F – { }) { ( – A)} logically implies F.
(Now determines lesser number of attributes. The FD has
become “weaker”)
F = {AB → D, A → C} logically implies F = {AB → CD, A → C}
AB->CD, therefore AB->C and AB->D
Since A->C, we can drop AB->C
Note: implication in the opposite direction is trivial above, since a
“stronger” functional dependency always implies a weaker one
E.g. F always implies (F – { }) { ( – A)}
Database System Concepts - 6th Edition 8.51 ©Silberschatz, Korth and Sudarshan
Testing if an Attribute is Extraneous
Database System Concepts - 6th Edition 8.52 ©Silberschatz, Korth and Sudarshan
Canonical Cover
Database System Concepts - 6th Edition 8.53 ©Silberschatz, Korth and Sudarshan
Computing a Canonical Cover
R = (A, B, C)
F = {A BC
BC
AB
AB C}
Combine A BC and A B into A BC
Set is now {A BC, B C, AB C}
A is extraneous in AB C
as F logically implies (F-{AB->C}) υ {B->C} as B C already exists
Set is now {A BC, B C}
C is extraneous in A BC as
A BC is A B, A C.
Now A B and B C are sufficient to imply A C
Therefore C is dropped from A BC
– Can use attribute closure of A in more complex cases
The canonical cover is: AB
BC
Database System Concepts - 6th Edition 8.54 ©Silberschatz, Korth and Sudarshan
Lossless-join Decomposition
For the case of R = (R1, R2), we require that for all possible relations r
on schema R
r = R1 (r ) R2 (r )
A decomposition of R into R1 and R2 is lossless join if at least one of
the following dependencies is in F+:
R1 R2 R1
R1 R2 R2
In other words, R1 R2 forms a superkey of R1 or R2
Database System Concepts - 6th Edition 8.56 ©Silberschatz, Korth and Sudarshan
Example cont.
instr_dept (ID, name, salary, dept_name, building, budget )
instructor (ID, name, salary, dept_name)
department(dept_name, building, budget )
dept_name building, budget
Database System Concepts - 6th Edition 8.57 ©Silberschatz, Korth and Sudarshan
Dependency Preservation
Database System Concepts - 6th Edition 8.58 ©Silberschatz, Korth and Sudarshan
Caveats : dependency preservation
If each member of F can be tested on one of the relations of the
decomposition, then the decomposition is dependency preserving.
This is an easy way to show dependency preservation; however, it
does not always work.
There are cases where, even though the decomposition is dependency
preserving,
there is a dependency in F that cannot be tested in any one
relation in the decomposition.
Thus, this alternative test can be used only as a sufficient condition
that is easy to check;
if it fails we cannot conclude that the decomposition is not
dependency preserving;
instead we will have to apply the general test.
Database System Concepts - 6th Edition 8.59 ©Silberschatz, Korth and Sudarshan
Testing for Dependency Preservation
Database System Concepts - 6th Edition 8.60 ©Silberschatz, Korth and Sudarshan
Example
R = (A, B, C )
F = {A B
B C}
Key = {A}
R is not in BCNF
Decomposition R1 = (A, B), R2 = (B, C)
R1 and R2 in BCNF
Lossless-join decomposition
Dependency preserving
Database System Concepts - 6th Edition 8.61 ©Silberschatz, Korth and Sudarshan
Testing for BCNF
To check if a non-trivial dependency causes a violation of BCNF
1. compute + (the attribute closure of ), and
2. verify that it includes all attributes of R, that is, it is a superkey of R.
Database System Concepts - 6th Edition 8.62 ©Silberschatz, Korth and Sudarshan
Testing for BCNF
However, simplified test using only F is incorrect when testing a
relation in a decomposition of R
Consider R = (A, B, C, D, E), with F = { A B, BC D}
Decompose R into R1 = (A,B) and R2 = (A,C,D, E)
Neither of the dependencies in F contain only attributes from
(A,C,D,E) so we might be misled into thinking R2 satisfies
BCNF.
In fact, dependency AC D in F+ shows R2 is not in BCNF.
So we need to check with all dependencies in F+ to check if a
decomposition is in BCNF.
Database System Concepts - 6th Edition 8.63 ©Silberschatz, Korth and Sudarshan
Easier :Testing Decomposition for BCNF
Database System Concepts - 6th Edition 8.64 ©Silberschatz, Korth and Sudarshan
BCNF Decomposition Algorithm
result := {R };
done := false;
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 does not contain Ri
and = ;
result := (result – Ri ) (Ri – ) (, );
end
else done := true;
Database System Concepts - 6th Edition 8.65 ©Silberschatz, Korth and Sudarshan
Example of BCNF Decomposition
R = (A, B, C )
F = {B C , A B}
Key = {A}
R is not in BCNF (B C but B is not a superkey)
B C is an FD such that B+=BC does not contain ABC and B C =
So remove ABC, add AB and BC
Decomposition
R1 = (B, C)
R2 = (A,B)
Database System Concepts - 6th Edition 8.66 ©Silberschatz, Korth and Sudarshan
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. class is not in BCNF
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)
Database System Concepts - 6th Edition 8.67 ©Silberschatz, Korth and Sudarshan
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.
Database System Concepts - 6th Edition 8.68 ©Silberschatz, Korth and Sudarshan
BCNF and Dependency Preservation
R = (J, K, L )
F = {JK L
LK}
Candidate keys?
Two candidate keys = JK and JL
R is not in BCNF
Any decomposition of R will fail to preserve
JK L
This implies that testing for JK L requires a join
Database System Concepts - 6th Edition 8.69 ©Silberschatz, Korth and Sudarshan
Third Normal Form: Motivation
There are some situations where
BCNF is not dependency preserving, and
efficient checking for FD violation on updates is important
Solution: define a weaker normal form, called Third
Normal Form (3NF)
Allows some redundancy (with resultant problems; we will
see examples later)
But functional dependencies can be checked on individual
relations without computing a join.
There is always a lossless-join, dependency-preserving
decomposition into 3NF.
Database System Concepts - 6th Edition 8.70 ©Silberschatz, Korth and Sudarshan
3NF Example
Relation dept_advisor:
dept_advisor (s_ID, i_ID, dept_name)
F = {s_ID, dept_name i_ID, i_ID dept_name}
Candidate keys?
Two candidate keys: s_ID, dept_name, and i_ID, s_ID
Is R in 3NF?
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
Database System Concepts - 6th Edition 8.71 ©Silberschatz, Korth and Sudarshan
Redundancy in 3NF
There is some redundancy in this schema
Example of problems due to redundancy in 3NF
R = (J, K, L)
F = {JK L, L K } J L K
j1 l1 k1
j2 l1 k1
j3 l1 k1
null l2 k2
Database System Concepts - 6th Edition 8.72 ©Silberschatz, Korth and Sudarshan
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 ) whether
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 involves 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
Database System Concepts - 6th Edition 8.73 ©Silberschatz, Korth and Sudarshan
3NF Decomposition Algorithm
Database System Concepts - 6th Edition 8.74 ©Silberschatz, Korth and Sudarshan
3NF Decomposition Algorithm (Cont.)
Above algorithm ensures:
each relation schema Ri is in 3NF
decomposition is dependency preserving and lossless-join
Example: Consider R(A, B, C, D, E, F ) with the following functional
dependencies:
A → D, B → C, B → D, D → E
Database System Concepts - 6th Edition 8.75 ©Silberschatz, Korth and Sudarshan
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 branch_name, type
2. employee_id branch_name
3. customer_id, branch_name employee_id
We first compute a canonical cover
branch_name is extraneous in the r.h.s. of the 1st dependency
1. compute + using only the dependencies in
F’ = (F – { }) { ( – A)},
2. check that + contains A; if it does, A is extraneous in
No other attribute is extraneous, so we get FC =
customer_id, employee_id type
employee_id branch_name
customer_id, branch_name employee_id
Database System Concepts - 6th Edition 8.76 ©Silberschatz, Korth and Sudarshan
3NF Decomposition 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
result will not depend on the order in which FDs are considered
The resultant 3NF schema is:
(customer_id, employee_id, type)
(customer_id, branch_name, employee_id)
Database System Concepts - 6th Edition 8.77 ©Silberschatz, Korth and Sudarshan
Comparison of BCNF and 3NF
It is always possible to decompose a relation into a set of relations
that are in 3NF such that:
the decomposition is lossless
the dependencies are preserved
It is always possible to decompose a relation into a set of relations
that are in BCNF :
such that the decomposition is lossless
the dependencies may not be preserved
Database System Concepts - 6th Edition 8.78 ©Silberschatz, Korth and Sudarshan
Design Goals
Goal for a relational database design is:
Relations that are in BCNF.
Relations that have a Lossless join.
Dependency preservation in relations.
If we cannot achieve this, we accept one of
Lack of dependency preservation
Redundancy due to use of 3NF
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.
Database System Concepts - 6th Edition 8.79 ©Silberschatz, Korth and Sudarshan
Properties preserved by normal forms
Database System Concepts - 6th Edition 8.80 ©Silberschatz, Korth and Sudarshan
4NF implies BCNF implies 3NF
Database System Concepts - 6th Edition 8.81 ©Silberschatz, Korth and Sudarshan
Overall Database Design Process
Database System Concepts - 6th Edition 8.82 ©Silberschatz, Korth and Sudarshan
ER Model and Normalization
Database System Concepts - 6th Edition 8.83 ©Silberschatz, Korth and Sudarshan
Denormalization for Performance
Database System Concepts - 6th Edition 8.84 ©Silberschatz, Korth and Sudarshan
Denormalization for Performance cont.
Alternative 1: Use denormalized relation containing attributes of
course as well as prereq with all above attributes (info for course is
repeated for every prereq)
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
Database System Concepts - 6th Edition 8.85 ©Silberschatz, Korth and Sudarshan
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
Database System Concepts - 6th Edition 8.86 ©Silberschatz, Korth and Sudarshan
End of Chapter
R=ABCD
F={AB->C, C->D}
Consider F’= {AB->C, AC->AD}
Decompose R into R1= ABCD-AD = BC and R2= AC U AD = ACD
R1 R2 -> R1 or R1 R2 -> R2 for a lossless join decomposition
R1 R2 = C
C does not determine R1 or R2.
Therefore the decomposition is not lossless.
This is due to the addition of A in AC->AD. Therefore = is a
requirement.