Functional dependenciesCMSC 461Michael Wilson

Designing tables Now we have all the tools to build our

databases How should we actually go about doing

this? First thing’s first

Functional dependencies Going back to relational algebra and the

relational model Identifying functional dependencies in

relations help us to identify keys in a relation

What is a functional dependency (FD)? Take a relation R

A set of attributes X = A1,A2,…An in R A set of attributes Y = B1,B2,…Bm in R X functionally determines Y if there’s only one X

value per Y value Every unique tuple in πA1,A2,…An maps to exactly one

unique tuple in πB1,B2,…,Bm

Can also say that if a tuple has the values (a1,a2,…an), it will also have the values (b1,b2,…bm)

Relation R then satisfies the functional dependency X→Y

What is a functional dependency (FD)? Tuples that have equal values for

attributes in X will have equal values for attributes in Y

Let’s look at some examples

Functional dependencies Tuples with the same values in (A1,A2,…An)

will always be paired with the same values in (B1,B2,…Bm)

Functional dependency examplestitle year length genre studio Star

Star Wars 1977 124 SciFi Fox Carrie Fisher

Star Wars 1977 124 SciFi Fox Mark Hamill

Star Wars 1977 124 SciFi Fox Harrison Ford

Gone With the Wind

1992 231 Drama MGM Vivien Leigh

Wayne’s World

1992 95 Comedy Paramount Dana Carvey

Wayne’s World

1992 95 Comedy Paramount Mike Myers

Functional dependency examples title year → length genre studio

Does this work? Why does it work?

Yes, this functional dependency holds Assumption that a movie with the same title

will not come out within the same year Every unique movie will have the same

length, genre, and studio name

More examples studio → title studio genre → title studio genre → title year title → year title year → studio title year → genre title year → star

Functional dependency reasoning Certain rules hold for functional

dependencies that help us to reason about them

You’ve seen these rules in math classes and logic courses

Transitivity Functional dependencies

A → B B → C

It can be shown that, because of these two dependencies, A → C

Splitting/combining A functional dependency

A1,A2,…An → B1,B2,…Bm This can be split into

A1,A2,…An → B1 A1,A2,…An → B2 A1,A2,…An → Bm

Similarly, we can combine the aforementioned dependencies back into the original dependency

Trivial dependencies Trivial dependencies are functional

dependencies where the right side is a subset of the left Taking A1,A2,…An → B1,B2,…Bm If B1,B2,…Bm is some subset of A1,A2,…An

These dependencies always hold Therefore, they are called trivial

Trivial dependencies Intermediate situation:

A1,A2,…An → B1,B2,…Bm Only some of the elements of B1,B2,…Bm

are in A1,A2,…An Can simply remove the elements of B1,B2,

…Bm that are in A1,A2,…An to get a nontrivial dependency

Closures Closures are a way of determining

possible functional dependencies given a starting set of attributes and a few functional dependencies You can use these to verify proposed

functional dependencies Notation for the closure of attributes A

and B: {A, B}+

Closures In other words:

Say I have a relation R with attributes A, B, C, D, E, F, AB → C BC → AD D → E

I want to know if AB → D will hold In order to do this, I need to calculate {A,

B}+

Calculating closures In order to calculate a closure, you need a set

of attributes to calculate a closure on and a set of functional dependencies to test for If we have no existing functional dependencies,

we can’t calculate closures In calculating a closure, we’re essentially trying

to see what attributes we can “jump” to given a starting set and some other dependencies If we have no dependencies, there’s nowhere to

go

Calculating closures Input: a set of attributes {A1,A2,…An}, a

set S of functional dependencies For this example

Attributes A, B

S AB → C BC → AD D → E CF → B

Calculating closures: Step 1 Step 1: Split dependencies in S

We want to reduce all of the dependencies in S such that they are as simple as possible

Single attributes on the right side of the dependency

Why? Makes things way easier, as we’ll see

Calculating closures: step 1 AB → C BC → AD D → E CF → B

Calculating closures: step 1 AB → C BC → A BC → D D → E CF → B

Calculating closures: step 2 Step 2: Let X be your input attributes

X = {A, B} X will eventually be your closure

Calculating closures: step 3 Step 3: Go through the functional

dependencies in S. If the left side of a dependency can is satisfied by some subset of the current set of X, and the right side is not currently in X, add the right side to X Repeat until there’s nothing left to add

Calculating closures: step 3 Iteration 1

X = {A, B} Possible subsets: A, B, AB

S AB → C BC → A BC → D D → E CF → B

Calculating closures: step 3 Iteration 2

X = {A, B, C} Possible subsets: A, B, C, AB, AC, BC, ABC

S AB → C BC → A BC → D D → E CF → B

Calculating closures: step 3 Iteration 3

X = {A, B, C, D} Possible subsets

A, B, C, D, AB, AC, AD, BC, BD, CD, ABC, ABD, ACD, BCD, ABCD

S D → E CF → B

Calculating closures: step 3 Iteration 4

X = {A, B, C, D, E} S

CF → B This doesn’t match any subset of X

Done!

Calculating closures: step 4 Step 4: Enjoy your closure

{A, B}+ = {A, B, C, D, E} F was not a part of the closure because

at no point during the algorithm was there anything that “lead” to F How could we modify S to include F?

Using closures to determine superkeys Calculating a closure of a set of

attributes If the closure includes all attributes in the

relation, then it is a superkey of the relation Not necessarily a candidate key