0% found this document useful (0 votes)
39 views31 pages

CP 224 LECT - 2 - 2 - Relational Database Design

Uploaded by

Paul Programmer
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
39 views31 pages

CP 224 LECT - 2 - 2 - Relational Database Design

Uploaded by

Paul Programmer
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 31

Lecture 2: Relational Database

Design
 Features of Good Relational Design
 Atomic Domain and First Normal Form
 Function Dependency and Inferencing
 Normalization
 Functional Dependency Theory
 Closure of a Set of Functional Dependencies
 Lossless join decomposition
 Algorithms for Functional Dependencies
 Decomposition Algorithms Using Functional
Dependencies
 Decomposition Using Multivalued Dependencies
 Database-Design Process
 Modeling Temporal Data
Decomposition Using Functional
Dependencies
 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 .
 Example: Consider R(A,B, C, D ) with the following instance of
r.

 On this instance, A  C is satisfied, but C  A is not satisfied.


Decomposition Using Functional
Dependencies (Cont.)
 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 classroom may, by
chance, satisfy
room_number  capacity.

 We usually use functional dependencies to specify


constraints on all legal relations
 We say that F holds on R if all legal relations on R satisfy
the set of functional dependencies F.
Practice
inst_dept (ID, name, salary, dept_name, building, budget ).
 For each constraint, write the corresponding functional
dependency
 Every instructor (ID) has only one name and one salary.
Ans:
 Every department (dept_name) is located in only one building
and has only one budget.
Ans:
 Every instructor belongs to only one department.
Ans:
 Explain why each of the following functional dependency
doesn’t make sense.
 dept_name  ID
Ans:
 building  dept_name
Ans:
Decomposition Using Functional
Dependencies (Cont.)
 Functional dependencies allow us to express constraints
that cannot be expressed using superkeys.

 K is a superkey for relation schema R if and only if K  R


 Example: employee = (ID, name, street, city, salary),

{ID} is a superkey iff ID-> ID, name, street, city, salary


{ID, name} is a superkey
iff ID, name -> ID, name, street, city, salary

 K is a candidate key for R if and only if


 K  R, and
 for no   K,   R

In other words, K is a minimal set of attributes


Example: {ID} is a candidate key, but {ID, name} is NOT.
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
Decomposition Using Functional
Dependencies (Cont.)
 A functional dependency is trivial if it is satisfied by all instances of a
relation
 Example: (see examples)
 dept_name, building  dept_name
 In general,    is trivial if   

 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
(see examples)

 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.
Closure of a Set of Functional
Dependencies
 Given a set F set of functional dependencies,
there are certain other functional
dependencies that are logically implied by F.
 For e.g.: 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+ .


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).
Closure of a Set of Functional
Dependencies
 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
Closure of a Set of Functional
Dependencies

 Procedure for Computing F


 To compute the closure of a set of functional dependencies
F:
F+ = Frepeat
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 f1 and 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

 NOTE: We shall see an alternative procedure for this task later


Closure of a Set of Functional
Dependencies
 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.
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

 PS:   result, result  ,    =>   


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? (see definition)
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
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.
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.: on RHS: {A  B, B  C, A  CD} can be
simplified to
{ A  B , B  C, A  D}
 E.g.: on LHS: {A  B, B  C, AC  D} 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
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)  }.
 Attribute A is extraneous in  if A  
and the set of functional dependencies
(F – {  })  { ( – A)} logically implies F.

 Note: implication in the opposite direction is trivial in each of the


cases above, since a “stronger” functional dependency always implies
a weaker one

 Example: Given F = {A  C, AB  C }
 B is extraneous in AB  C because {A  C, AB  C} logically
implies A  C (I.e. the result of dropping B from AB  C).

 Example: Given F = {A  C, AB  CD}


 C is extraneous in AB  CD since AB  C can be inferred even
after deleting C
Testing if an Attribute is
Extraneous
 Consider a set F of functional dependencies and the
functional dependency    in F.

 To test if attribute A   is extraneous in 


1. compute ({} – A)+ using the dependencies in F
2. check that ({} – A)+ contains ; if it does, A is
extraneous in 

 To test if attribute A   is extraneous in 


1. compute + using only the dependencies in
F’ = (F – {  })  { ( – A)},
2. check that + contains A; if it does, A is extraneous
in 
Canonical Cover
 A canonical cover for F is a set of dependencies Fc such that
 F logically implies all dependencies in Fc, and
 Fc logically implies all dependencies in F, and
 No functional dependency in Fc contains an extraneous attribute,
and
 Each left side of functional dependency in Fc is unique.

 To compute a canonical cover for F:


repeat
Use the union rule to replace any dependencies in F
1  1 and 1  2 with 1  1 2
Find a functional dependency    with an
extraneous attribute either in  or in 
/* Note: test for extraneous attributes done using Fc, not
F*/
If an extraneous attribute is found, delete it from   
until F does not change

 Note: Union rule may become applicable after some extraneous


attributes have been deleted, so it has to be re-applied
Computing a Canonical Cover
 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!
 Set is now {A  BC, B  C}
 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.
– Can use attribute closure of A in more complex cases
 The canonical cover is: AB
BC
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 + : (see
examples)
 R1  R2  R1
 R1  R2  R2

 In other words, if R1  R2 forms a superkey of either R1


or R2, the decomposition of R is a lossless
decomposition.
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
 it may not be possible to preserve
dependencies.
Comparison of BCNF and 3NF
 Goal for a relational database design is:
 3NF, or BCNF.
 Lossless join.
 Dependency preservation.

 If we cannot achieve this, we accept one of


 Lack of dependency preservation
 Redundancy due to use of 3NF
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
Dependency Preservation
 Let Fi be the set of dependencies F+ that include only
attributes in Ri .
 A decomposition is dependency preserving, if (F1 𝖴 F2 𝖴 … 𝖴
Fn ) = F+
 If it is not, then checking updates for violation of functional
dependencies may require computing joins, which is expensive.

 Testing for Dependency Preservation


 To check if a dependency α → β is preserved in a decomposition
of R into R1 , R2 , …, Rn we apply the following test (with
attribute closure done with respect to F)
Dependency Preservation
 result = α
while (changes to result) do
for each Ri in the decomposition
t = (result ∩ Ri+ ) ∩ Ri
result = result 𝖴 t
 If result contains all attributes in β, then the functional dependency α → β
is preserved.

 We apply the test on all dependencies in F to check if a


decomposition is dependency preserving

 This procedure takes polynomial time, instead of the exponential


time required to compute F+ and (F1 𝖴 F2 𝖴 … 𝖴 Fn+ )
Dependency Preservation

 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
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).
 R could have been the result of some ad hoc
design of relations.

 Normalization breaks R into smaller relations.


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
ID, department_name and building,
and a functional dependency
department_name building
 The schema is employee( ID, department_name,
building), which is not in 3NF or BCNF.
 Good design would have made department an entity
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
Other Design Issues
 Some aspects of database design are not caught by
normalization
 Examples of bad database design, to be avoided:
Instead of total_inst (dept_name, year, size ), use
 total_inst _2007(dept_name, size ), total_inst
_2008(dept_name, size ), total_inst _2009(dept_name, size ),
etc.,
 Above are in BCNF, but make querying across years
difficult and needs new table each year
 dept_year (dept_name, total_inst _2007, total_inst _2008,
total_inst _2009)
 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

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy