Scribd
Upload
26 views24 pages

550 Lecture13

The document discusses functional dependencies (FDs) in relational schemas, emphasizing their importance in identifying and eliminating redundancy and anomalies in database design. It provides formal definitions, examples, and reasoning techniques for FDs, including Armstrong's Axioms and closure of attributes. The document also highlights the implications of FDs on schema design and the necessity of understanding them for effective database management.

Uploaded by

penukonda.akhila31
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
26 views24 pages

550 Lecture13

The document discusses functional dependencies (FDs) in relational schemas, emphasizing their importance in identifying and eliminating redundancy and anomalies in database design. It provides formal definitions, examples, and reasoning techniques for FDs, including Armstrong's Axioms and closure of attributes. The document also highlights the implications of FDs on schema design and the necessity of understanding them for effective database management.

Uploaded by

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

Lecture 13

Functional Dependencies
The Evils of Redundancy
• Redundancy is at the root of several
problems associated with relational
schemas:
– Redundant storage, insert/delete/update
anomalies
• Functional dependencies can be used to
identify schemas with such problems and
to suggest refinements
Functional Dependencies
• Most important kind of constraint in the
relational model
• Knowledge about functional dependencies
is vital for redesign of database schemas
to eliminate anomalies & redundancies
Functional Dependencies (FDs)
• A functional dependency X ® Y holds over
relation R, if for every allowable instance r
of R:
– t1Îr, t2 Îr, t1[X]= t2[X] implies t1[Y] = t2[Y]
– i.e., given two tuples in r, if the X values agree,
then the Y values must also agree (X and Y
are sets of attributes)
Formal Definition
• Formally: A ® B
– “A functionally determines B”
– “B is functionally dependent on A”
– A is called the left-hand side (LHS) of the FD
– B is called the right-hand side (RHS) of the FD
• If two tuples of r(R) agree on a set of attributes A
of R, then they must also agree on another set of
attribute B
– i.e., the tuples have the same values in their respective
components for each of these attributes
Pictorially Speaking...
• Assume A ® B
R A’s B’s

u
If t and u then they must
agree on A’s agree on B’s

• A FD tells us about any two tuples t and u in relation R


Example 1
Movies
title year length filmType studioName starName
Star Wars 1977 124 color Fox Carrie Fisher
Star Wars 1977 124 color Fox Mark Hamill
Star Wars 1977 124 color Fox Harrison Ford
Mighty
1991 104 color Disney Emilio Estevez
Ducks
Wayne’s
1992 95 color Paramount Dana Carvey
World
Wayne’s
1992 95 color Paramount Mike Myers
World

FDs that should hold: FD that doesn’t hold:


{title, year} ® length {title, year} ® starName
{title, year} ® filmType
{title, year} ® studioName
Example 2
• Consider relation obtained from Hourly_Emps:
– Hourly_Emps (ssn, name, lot, rating, hrly_wages,
hrs_worked)
• We will denote this relation schema by listing the
attributes as SNLRWH, which is the set of
attributes {S,N,L,R,W,H}
• Some FDs on Hourly_Emps:
– ssn is the key: S ® SNLRWH
– rating determines hrly_wages: R ® W
Example 2 (Cont.)
• Problems due to R ® W :
– Update anomaly: Can we change W in just the
1st tuple of SNLRWH?
S N L R W H
123-22-3666 Attishoo 48 8 10 40
231-31-5368 Smiley 22 8 10 30
131-24-3650 Smethurst 35 5 7 30
434-26-3751 Guldu 35 5 7 32
612-67-4134 Madayan 35 8 10 40
Example 2 (Cont.)
– Insertion anomaly: If we insert an employee with R=5,
we must enter the values of W correctly
– Deletion anomaly: If we delete all employees with
rating 5, we lose the information about the wage for
rating 5!
Hourly_Emps1 Hourly_Emps2
S N L R H R W
123-22-3666 Attishoo 48 8 40 8 10
231-31-5368 Smiley 22 8 30 5 7
131-24-3650 Smethurst 35 5 30
434-26-3751 Guldu 35 5 32
612-67-4134 Madayan 35 8 40
FDs and Schema
• FDs are assertions about the schema of a
relation, NOT about a particular instance
– Must be identified based on semantics of application
– All data must conform
– Given some allowable instance r1 of R, we can check
if it violates some FD f, but we cannot tell if f holds
over R!
• Relation extensions r(R) that satisfy the
FD constraints are called legal relation
states or legal extensions
FDs and Keys
• K={A1, A2,…, An} is a candidate key for
relation R if:
– K functionally determines ALL other attributes
of R
AND
– No proper subset of K functionally determines
all other attributes of R
Trivial Dependencies
• A functional dependency {A1,A2,…,An} ® B is
trivial if B is one of the A’s
– E.g., {title, year} ® title
• Every trivial dependency holds in every relation
• We may assume trivial dependencies without
having to justify them
– Trivial: B is a subset of A’s
– Nontrivial: at least one of the B’s is not among A’s
– Completely nontrivial: none of the B’s is part of A’s
Reasoning About FDs
• Given some FDs, we can usually infer
additional FDs:
– {ssn ® did, did ® lot} implies {ssn ® lot}
• An FD f is implied by a set of FDs F if f
holds whenever all FDs in F hold
+
– The closure of F ( F ): the set of all FDs that
are implied by F
Inference Rules
• Armstrong’s Axioms (X, Y, Z are sets of
attributes):
– Reflexive rule: If Y is a subset of X, then X ® Y
– Augmentation rule: If X ® Y, then XZ ® YZ for any Z
– Transitive rule: If X ® Y and Y ® Z, then X ® Z
• These are sound and complete inference rules
for FDs
Additional Inference Rules
• Union rule: If X ® Y and X ® Z, then X ®
YZ
• Decomposition rule: If X ® YZ, then X ®
Y and X ® Z
• Pseudotransitive rule: If X ®Y and WY ®Z,
then WX ®Z
Closure of Attributes
• Given a relation R, a set of FDs for R
(denoted by F), and a set of attributes {A1,
A2, ..., Am} of R (denoted by X):
– Find all attributes B in R such that {A1, A2, ...,
Am} ® B
– B is called the closure of X under F and is
denoted by {A1, A2, ..., Am}+
Algorithm for Computing Closure of
Attributes
• Start with {A1, A2, ..., Am}
• Repeat until no change:
– If current set of attributes includes LHS of a
dependency, add RHS attributes to the set
Example: Calculating Attribute Closure

• R=(A, B, C, D, E, G)
• F: {AB ® C, BC ® AD, D ® E, CE ® B}
• How to compute the closure of {A, B} under F,
i.e., {A, B}+?
– Start with X={A, B}
– Add C to X due to AB ® C; X={A, B, C}
– Add A,D to X due to BC ® AD; X={A, B, C, D}
– Add E to X due to D ® E; X={A, B, C, D, E}
– No more attributes can be added to X
– {A, B}+ = {A, B, C, D, E}
Attribute Closure Usage
• If we can compute closure of any set of attributes,
we can test whether any given functional
dependency {A1, A2,…, An} ® B follows from a
set of dependencies F
– Compute closure of {A1, A2, …, An}+ using F
– If B is in {A1, A2, …, An}+, then {A1, A2, …, An} ® B does
follow from F
• We can also test if K={A1, A2,…, An} is a
candidate key for relation R
– If {A1, A2,…, An}+ is the set of all attributes in R and if K
is minimal
Specifying FDs for a Relation
• Let F be set of FDs specified on R
• Must be able to reason about FDs in F
– Designer usually explicitly states only FDs which are
obvious
– Without knowing exactly what all tuples are, must be
able to deduce other/all FDs that hold on R
– Essential when we discuss design of “good” relational
schemas
• How can we tell if one FD follows from others?
– Use Armstrong’s axioms and reason it out
– OR use attribute closure algorithm

You might also like