Professional Documents
Culture Documents
Database Design
Combine Schemas?
3
Database Design
A Combined Schema Without Repetition
4
Database Design
What About Smaller Schemas?
5
Suppose we had started with inst_dept. 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
In inst_dept, 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 inst_dept
Not all decompositions are good. Suppose we decompose
employee(ID, name, street, city, salary) into
employee1 (ID, name)
employee2 (name, street, city, salary)
The next slide shows how we lose information -- we cannot
reconstruct the original employee relation -- and so, this is a lossy
decomposition.
Database Design
A Lossy Decomposition
6
Database Design
Example of 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 Design
First Normal Form
8
Database Design
Goal — Devise a Theory for the Following
9
Database Design
Functional Dependencies
10
Database Design
Functional Dependencies (Cont.)
11
Database Design
Closure of a Set of Functional Dependencies
15
Database Design
Boyce-Codd Normal Form
16
is trivial (i.e., )
is a superkey for R
Database Design
Decomposing a Schema into BCNF
17
Database Design
BCNF and Dependency Preservation
18
Database Design
Third Normal Form
19
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.
Database Design
Goals of Normalization
20
Database Design
Functional-Dependency Theory
21
Database Design
Closure of a Set of Functional Dependencies
22
Database Design
Closure of a Set of Functional Dependencies
23
Database Design
Example
24
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 Design
Closure of Functional Dependencies (Cont.)
25
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.
Database Design
Closure of Attribute Sets
26
result := ;
while (changes to result) do
for each in F do
begin
if result then result := result
end
Database Design
Example of Attribute Set Closure
27
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 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
Database Design
Uses of Attribute Closure
28
Database Design
Canonical Cover
29
Database Design
Canonical Cover
32
Database Design
Computing Canonical Cover
33
Database Design
Computing a Canonical Cover (Example)
34
R = (A, B, C)
F = {A BC B C A B 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
Check if the result of deleting A from AB C is implied by the other
dependencies
Yes: in fact, B C is already present!
C is extraneous in A BC
Check if A C is logically implied by A B and the other dependencies
Yes: using transitivity on A B and B C.
Database Design
Example
36
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
Database Design
Dependency Preservation
37
Database Design
Testing for Dependency Preservation
38
Database Design
Example
39
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 Design
Testing for BCNF
40
Database Design
BCNF Decomposition Algorithm
42
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;
Database Design
Example of BCNF Decomposition
43
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)
Database Design
Example of BCNF Decomposition
44
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)
Database Design
BCNF Decomposition (Cont.)
45
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.
Database Design
BCNF and Dependency Preservation
46
Database Design
Third Normal Form: Motivation
47
Database Design
3NF Example
48
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 Design
Redundancy in 3NF
49
j2 l1 k1
j3 l1 k1
repetition of information (e.g., the relationship l1, k1)
null l2 k2
(i_ID, dept_name)
need to use null values (e.g., to represent the relationship
l2, k2 where there is no corresponding value for J).
(i_ID, dept_nameI) if there is no separate relation mapping
instructors to departments
Database Design
Testing for 3NF
50
Database Design
3NF Decomposition Algorithm
51
Database Design
3NF Decompsition Example (Cont.)
53
Database Design
Comparison of BCNF and 3NF
54
Database Design
Design Goals
55
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.
Database Design
Determining Dependency Preservation
56
Problem:
Let a relation, R = (A, B, C, D )
Functional dependency, F = {AB –> C, C –> D, D –> A}.
Relation R is decomposed into R1 = ( A, B, C)
R2 = (C, D)
# Check whether decomposition is dependency
preserving or not.
Database Design
Solution
57
consider all combination of ABC. i.e., find closure of A, B, C, AB, BC and AC
Note ABC is not considered as it is always ABC
closure(A) = { A } // Trivial
closure(B) = { B } // Trivial
closure(C) = {C, A, D} but D can't be in closure as D is not present R1.
= {C, A}
C--> A // Removing C from right side as it is trivial attribute
closure(AB) = {A, B, C, D}
= {A, B, C}
AB --> C // Removing AB from right side as these are trivial attributes
closure(BC) = {B, C, D, A}
= {A, B, C}
BC --> A // Removing BC from right side as these are trivial attributes
closure(AC) = {A, C, D}
AC --> D // Removing AC from right side as these are trivial attributes
F1 = {C--> A, AB --> C, BC --> A}.
Similarly, F2 = { C--> D }
In the original Relation F, Dependency = { AB --> C , C --> D , D --> A}.
AB --> C is present in F1.
C --> D is present in F2.
D --> A is not preserved.
F1 U F2 is a subset of F.
So, given decomposition is not dependency preserving.
Database Design