Upload
charlotte-maxwell
View
221
Download
0
Tags:
Embed Size (px)
Citation preview
Database Management Systems
Chapter 3 The Relational Data Model (II)
Instructor: Li Ma
Department of Computer ScienceTexas Southern University, Houston
September, 2007
Functional Dependencies
Meaning of FD’sKeys and Superkeys
Rules about FD’s
Jeffrey Ullman 3
Functional Dependencies
X -> A is an assertion about a relation R that whenever two tuples of R agree on all the attributes of X, then they must also agree on the attribute A. Say “X -> A holds in R.” Convention: …, X, Y, Z represent sets of
attributes; A, B, C,… represent single attributes.
Convention: no set formers in sets of attributes, just ABC, rather than {A,B,C }.
Jeffrey Ullman 4
Example
Drinkers(name, addr, beersLiked, manf, favBeer)
Reasonable FD’s to assert:1. name -> addr2. name -> favBeer3. beersLiked -> manf
Jeffrey Ullman 5
Example Data
name addr beersLiked manf favBeerJaneway Voyager Bud A.B. WickedAleJaneway Voyager WickedAle Pete’s WickedAleSpock Enterprise Bud A.B. Bud
Because name -> addr Because name -> favBeer
Because beersLiked -> manf
Jeffrey Ullman 6
FD’s With Multiple Attributes
No need for FD’s with > 1 attribute on right. But sometimes convenient to combine
FD’s as a shorthand. Example: name -> addr and
name -> favBeer become name -> addr favBeer
> 1 attribute on left may be essential. Example: bar beer -> price
Jeffrey Ullman 7
Keys of Relations
K is a superkey for relation R if K functionally determines all of R.
K is a key for R if K is a superkey, but no proper subset of K is a superkey.
Jeffrey Ullman 8
Example
Drinkers(name, addr, beersLiked, manf, favBeer)
{name, beersLiked} is a superkey because together these attributes determine all the other attributes. name -> addr favBeer beersLiked -> manf
Jeffrey Ullman 9
Example, Cont.
{name, beersLiked} is a key because neither {name} nor {beersLiked} is a superkey. name doesn’t -> manf; beersLiked
doesn’t -> addr. There are no other keys, but lots of
superkeys. Any superset of {name, beersLiked}.
Jeffrey Ullman 10
E/R and Relational Keys
Keys in E/R concern entities. Keys in relations concern tuples. Usually, one tuple corresponds to
one entity, so the ideas are the same.
But --- in poor relational designs, one entity can become several tuples, so E/R keys and Relational keys are different.
Jeffrey Ullman 11
Example Data
name addr beersLiked manf favBeerJaneway Voyager Bud A.B. WickedAleJaneway Voyager WickedAle Pete’s WickedAleSpock Enterprise Bud A.B. Bud
Relational key = {name beersLiked}But in E/R, name is a key for Drinkers, and beersLiked is a key
for Beers.Note: 2 tuples for Janeway entity and 2 tuples for Bud entity.
Jeffrey Ullman 12
Where Do Keys Come From?
1. Just assert a key K. The only FD’s are K -> A for all
attributes A.
2. Assert FD’s and deduce the keys by systematic exploration.
E/R model gives us FD’s from entity-set keys and from many-one relationships.
Jeffrey Ullman 13
More FD’s From “Physics”
Example: “no two courses can meet in the same room at the same time” tells us: hour room -> course.
Jeffrey Ullman 14
Inferring FD’s
We are given FD’s X1 -> A1, X2 -> A2,…, Xn -> An , and we want to know whether an FD Y -> B must hold in any relation that satisfies the given FD’s. Example: If A -> B and B -> C hold, surely
A -> C holds, even if we don’t say so. Important for design of good relation
schemas.
Jeffrey Ullman 15
About Two FD’s Set
Two sets of FD’s are equivalent: they are satisfied by exactly the same set of relation instances
If every relation instance that satisfies all the FD’s in set T also satisfies all the FD’s in set S, then we say S follows from T
Jeffrey Ullman 16
Splitting/Combining Rule
X -> B1B2...Bn is the shorthand for the set of FD’s
X -> B1
X -> B2
…X -> Bn
Jeffrey Ullman 17
Trivial-Dependency Rule
A FD X -> B is trivial if B is in the attribute set X Example: AB -> A
We can always remove from the right side of a FD those attributes that appear on the left ABC –> AD is equivalent to ABC -> D
Jeffrey Ullman 18
Transitive Rule
If X -> Y and Y -> Z hold in relation R, then X -> Z also holds in R Similar as the transitive rule in
Arithmetic We can use either inference test or
closure test to prove this rule
Jeffrey Ullman 19
Inference Test
To test if Y -> B, start by assuming two tuples agree in all attributes of Y.
Y B0000000. . . 0000000? . . . ?
Jeffrey Ullman 20
Example Given a relation R with attributes A, B,
and C satisfies the FD’s A -> B and B -> C, test if R also satisfies the FD A -> C Assume two tuples agree on A: (a,b1,c1) and
(a,b2,c2) Since R satisfies A -> B, they also agree on
B: (a,b,c1) and (a,b,c2) Similarly, since R satisfies B -> C, they also
agree on C: (a,b,c) and (a,b,c) So we proved any two tuples of R that agree
on A also agree on C
Jeffrey Ullman 21
Closure of Attribute Set
The closure of an attribute set X under the FD’s in S is the attribute set Y such that every relation that satisfies all the FD’s in S also satisfies X -> Y X -> Y follows from the FD’s in S We denote X+ = Y
Jeffrey Ullman 22
Closure Algorithm
An easier way to test is to compute the closure of Y, denoted Y +.
Basis: Y + = Y. Induction: Look for an FD’s left side
X that is a subset of the current Y +. If the FD is X -> A, add A to Y +.
Jeffrey Ullman 23
Y+new Y+
X A
Jeffrey Ullman 24
Closure Algorithm (2)
Repeat the induction step until no more attribute can be added to Y +. Y + is the closure of Y.
The closure algorithm claims only true FD’s
The closure algorithm discovers all true FD’s
Jeffrey Ullman 25
Closure Test
For the transitive rule If X -> Y and Y -> Z hold in relation R,
then X -> Z also holds in R If we can compute the closure of X
(X+) and Z is a subset of X+, then the rule is proved Need to use the trivial-dependency
rule