0% found this document useful (0 votes)
80 views39 pages

Unctional Ependencies: CS 564-Fall 2020

This document provides an overview of functional dependencies and database normalization. It begins by introducing functional dependencies and how they can be used to express constraints on data. Armstrong's axioms are presented as a way to infer new functional dependencies from existing ones. The closure of a set of functional dependencies and attribute sets is defined as the set of all functional dependencies and attributes logically implied by the original sets. Examples are provided to illustrate functional dependencies and how Armstrong's axioms can be applied. The document concludes by noting how functional dependencies can help identify redundancies in a database schema to guide normalization.

Uploaded by

Jaden
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
0% found this document useful (0 votes)
80 views39 pages

Unctional Ependencies: CS 564-Fall 2020

This document provides an overview of functional dependencies and database normalization. It begins by introducing functional dependencies and how they can be used to express constraints on data. Armstrong's axioms are presented as a way to infer new functional dependencies from existing ones. The closure of a set of functional dependencies and attribute sets is defined as the set of all functional dependencies and attributes logically implied by the original sets. Examples are provided to illustrate functional dependencies and how Armstrong's axioms can be applied. The document concludes by noting how functional dependencies can help identify redundancies in a database schema to guide normalization.

Uploaded by

Jaden
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/ 39

FUNCTIONAL DEPENDENCIES

CS 564- Fall 2020

ACKs: Dan Suciu, Jignesh Patel, AnHai Doan


WHAT IS THIS LECTURE ABOUT?

Database Design Theory:

• Functional Dependencies
• Armstrong’s rules
• The Closure Algorithm
• Keys and Superkeys

CS 564 [Fall 2020] - Paris Koutris 2


HOW TO BUILD A DB APPLICATION

• Pick an application
• Figure out what to model (ER model)
– Output: ER diagram
• Transform the ER diagram to a relational schema

• Refine the relational schema (normalization)

• Now ready to implement the schema and load the


data!

CS 564 [Fall 2020] - Paris Koutris 3


DB DESIGN THEORY

• Helps us identify the “bad” schemas and improve them


1. express constraints on the data: functional
dependencies (FDs)
2. use the FDs to decompose the relations

• The process, called normalization, obtains a schema in a


“normal form” that guarantees certain properties
– examples of normal forms: BCNF, 3NF, …

CS 564 [Fall 2020] - Paris Koutris 4


MOTIVATING EXAMPLE
SSN name age phoneNumber
934729837 Paris 24 608-374-8422
934729837 Paris 24 603-534-8399
123123645 John 30 608-321-1163
384475687 Arun 20 206-473-8221

• What is the primary key?


– (SSN, PhoneNumber)
• What is the problem with this schema?
– Age and name are stored redundantly

CS 564 [Fall 2020] - Paris Koutris 5


MOTIVATING EXAMPLE
SSN name age phoneNumber
934729837 Paris 24 608-374-8422
934729837 Paris 24 603-534-8399
123123645 John 30 608-321-1163
384475687 Arun 20 206-473-8221

Problems:
• redundant storage
• update: change the age of Paris?
• insert: what if a person has no phone number?
• delete: what if Arun deletes his phone number?

CS 564 [Fall 2020] - Paris Koutris 6


SOLUTION: DECOMPOSITION

SSN name age phoneNumber


934729837 Paris 24 608-374-8422
934729837 Paris 24 603-534-8399
123123645 John 30 608-321-1163
384475687 Arun 20 206-473-8221

SSN name age SSN phoneNumber


934729837 Paris 24 934729837 608-374-8422
123123645 John 30 934729837 603-534-8399
384475687 Arun 20 123123645 608-321-1163
384475687 206-473-8221

CS 564 [Fall 2020] - Paris Koutris 7


FUNCTIONAL DEPENDENCIES

CS 564 [Fall 2020] - Paris Koutris 8


FD: DEFINITION

• Functional dependencies (FDs) are a form of constraint


• they generalize the concept of keys

If two tuples agree on the attributes


𝐴 = 𝐴 1, 𝐴 2, … , 𝐴 !
then they must agree on the attributes
𝐵 = 𝐵", 𝐵#, …, 𝐵$
Formally:
𝐴", 𝐴#, … , 𝐴! ⟶ 𝐵", 𝐵#, …, 𝐵$

We then say that A functionally determines B


CS 564 [Fall 2020] - Paris Koutris 9
FD: EXAMPLE 1
SSN name age phoneNumber
934729837 Paris 24 608-374-8422
934729837 Paris 24 603-534-8399
123123645 John 30 608-321-1163
384475687 Arun 20 206-473-8221

• 𝑆𝑆𝑁 ⟶ 𝑛𝑎𝑚𝑒, 𝑎𝑔𝑒


• 𝑆𝑆𝑁, 𝑎𝑔𝑒 ⟶ 𝑛𝑎𝑚𝑒

CS 564 [Fall 2020] - Paris Koutris 10


FD: EXAMPLE 2
studentID semester courseNo section instructor
124434 4 CS 564 1 Paris
546364 4 CS 564 2 Arun
999492 6 CS 764 1 Anhai
183349 6 CS 784 1 Jeff

• 𝑐𝑜𝑢𝑟𝑠𝑒𝑁𝑜, 𝑠𝑒𝑐𝑡𝑖𝑜𝑛 ⟶ 𝑖𝑛𝑠𝑡𝑟𝑢𝑐𝑡𝑜𝑟


• 𝑠𝑡𝑢𝑑𝑒𝑛𝑡𝐼𝐷 ⟶ 𝑠𝑒𝑚𝑒𝑠𝑡𝑒𝑟

CS 564 [Fall 2020] - Paris Koutris 11


SPLITTING AN FD

• Consider the FD: 𝐴, 𝐵 ⟶ 𝐶, 𝐷

• The attributes on the right are independently


determined by A, B so we can split the FD into:
– 𝐴, 𝐵 ⟶ 𝐶 and 𝐴, 𝐵 ⟶ 𝐷

• We can not do the same with attributes on the left!


– writing 𝐴 ⟶ 𝐶, 𝐷 and 𝐵 ⟶ 𝐶, 𝐷 does not express the
same constraint!

CS 564 [Fall 2020] - Paris Koutris 12


TRIVIAL FDS

• Not all FDs are informative:


• 𝐴 ⟶ 𝐴 holds for any relation
• 𝐴, 𝐵, 𝐶 ⟶ 𝐶 also holds for any relation

• An FD 𝑋 ⟶ 𝐴 is called trivial if the attribute A


belongs in the attribute set X
– a trivial FD always holds!

CS 564 [Fall 2020] - Paris Koutris 13


HOW TO IDENTIFY FDS

• An FD is domain knowledge:
– an inherent property of the application & data
– not something we can infer from a set of tuples

• Given a table with a set of tuples


– we can confirm that a FD seems to be valid
– to infer that a FD is definitely invalid
– we can never prove that a FD is valid

CS 564 [Fall 2020] - Paris Koutris 14


EXAMPLE 3

name category color department price


Gizmo Gadget Green Toys 49
Tweaker Gadget Black Toys 99
Gizmo Stationary Green Office-supplies 59

Q1: Is 𝑛𝑎𝑚𝑒 ⟶ 𝑑𝑒𝑝𝑎𝑟𝑡𝑚𝑒𝑛𝑡 an FD?


– not possible!
Q2: Is 𝑛𝑎𝑚𝑒, 𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦 ⟶ 𝑑𝑒𝑝𝑎𝑟𝑡𝑚𝑒𝑛𝑡 an FD ?
– we don’t know!

CS 564 [Fall 2020] - Paris Koutris 15


WHY FDS?

1. keys are special cases of FDs


2. more integrity constraints for the application
3. having FDs will help us detect that a schema has
redundancies and tell us how to normalize it

CS 564 [Fall 2020] - Paris Koutris 16


MORE ON FDS

• If the following FDs hold:


–𝐴 ⟶𝐵
–𝐵⟶𝐶
then the following FD is also true:
–𝐴⟶𝐶
• We can find more FDs like that using what we call
Armstrong’s Axioms

CS 564 [Fall 2020] - Paris Koutris 17


ARMSTRONG’S AXIOMS: 1

Reflexivity
For any subset 𝑋 ⊆ 𝐴! , . . , 𝐴" :
𝐴! , 𝐴# , … , 𝐴" ⟶ 𝑋

• Examples
– 𝐴, 𝐵 ⟶ 𝐵
– 𝐴, 𝐵, 𝐶 ⟶ 𝐴, 𝐵
– 𝐴, 𝐵, 𝐶 ⟶ 𝐴, 𝐵, 𝐶

CS 564 [Fall 2020] - Paris Koutris 18


ARMSTRONG’S AXIOMS: 2

Augmentation
For any attribute sets X, Y, Z :
if 𝑋 ⟶ 𝑌 then 𝑋, 𝑍 ⟶ 𝑌, 𝑍

• Examples
– 𝐴 ⟶ 𝐵 implies 𝐴, 𝐶 ⟶ 𝐵, 𝐶
– 𝐴, 𝐵 ⟶ 𝐶 implies 𝐴, 𝐵, 𝐶 ⟶ 𝐶

CS 564 [Fall 2020] - Paris Koutris 19


ARMSTRONG’S AXIOMS: 3

Transitivity
For any attribute sets X, Y, Z :
if 𝑋 ⟶ 𝑌 and 𝑌 ⟶ 𝑍 then 𝑋 ⟶ 𝑍

• Examples
– 𝐴 ⟶ 𝐵 and 𝐵 ⟶ 𝐶 imply 𝐴 ⟶ 𝐶
– 𝐴 ⟶ 𝐶, 𝐷 and 𝐶, 𝐷 ⟶ 𝐸 imply 𝐴 ⟶ 𝐸

CS 564 [Fall 2020] - Paris Koutris 20


APPLYING ARMSTRONG’S AXIOMS

Product(name, category, color, department, price)


1. 𝑛𝑎𝑚𝑒 ⟶ 𝑐𝑜𝑙𝑜𝑟
2. 𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦 ⟶ 𝑑𝑒𝑝𝑎𝑟𝑡𝑚𝑒𝑛𝑡
3. 𝑐𝑜𝑙𝑜𝑟, 𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦 ⟶ 𝑝𝑟𝑖𝑐𝑒

• Infer: 𝑛𝑎𝑚𝑒, 𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦 ⟶ 𝑝𝑟𝑖𝑐𝑒


1. We apply the augmentation axiom to (1) to obtain
(4) 𝑛𝑎𝑚𝑒, 𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦 ⟶ 𝑐𝑜𝑙𝑜𝑟, 𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦
2. We apply the transitivity axiom to (4), (3) to obtain
𝑛𝑎𝑚𝑒, 𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦 ⟶ 𝑝𝑟𝑖𝑐𝑒

CS 564 [Fall 2020] - Paris Koutris 21


APPLYING ARMSTRONG’S AXIOMS

Product(name, category, color, department, price)


1. 𝑛𝑎𝑚𝑒 ⟶ 𝑐𝑜𝑙𝑜𝑟
2. 𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦 ⟶ 𝑑𝑒𝑝𝑎𝑟𝑡𝑚𝑒𝑛𝑡
3. 𝑐𝑜𝑙𝑜𝑟, 𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦 ⟶ 𝑝𝑟𝑖𝑐𝑒

• Infer: 𝑛𝑎𝑚𝑒, 𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦 ⟶ 𝑐𝑜𝑙𝑜𝑟


1. We apply the reflexivity axiom to obtain
(5) 𝑛𝑎𝑚𝑒, 𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦 ⟶ 𝑛𝑎𝑚𝑒
2. We apply the transitivity axiom to (5), (1) to obtain
𝑛𝑎𝑚𝑒, 𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦 ⟶ 𝑐𝑜𝑙𝑜𝑟

CS 564 [Fall 2020] - Paris Koutris 22


FD CLOSURE

FD Closure
If F is a set of FDs, the closure 𝐹 3 is the set of
all FDs logically implied by F

Armstrong’s axioms are:


• sound: any FD generated by an axiom belongs in 𝐹 %
• complete: repeated application of the axioms will generate
all FDs in 𝐹 %

CS 564 [Fall 2020] - Paris Koutris 23


CLOSURE OF ATTRIBUTE SETS

Attribute Closure
If X is an attribute set, the closure 𝑋 3 is the
set of all attributes B such that:
𝑋 ⟶𝐵

In other words, 𝑋 3 includes all attributes that are


functionally determined from X

CS 564 [Fall 2020] - Paris Koutris 24


EXAMPLE

Product(name, category, color, department, price)


• 𝑛𝑎𝑚𝑒 ⟶ 𝑐𝑜𝑙𝑜𝑟
• 𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦 ⟶ 𝑑𝑒𝑝𝑎𝑟𝑡𝑚𝑒𝑛𝑡
• 𝑐𝑜𝑙𝑜𝑟, 𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦 ⟶ 𝑝𝑟𝑖𝑐𝑒

Attribute Closure:
• {𝑛𝑎𝑚𝑒}% = {𝑛𝑎𝑚𝑒, 𝑐𝑜𝑙𝑜𝑟}
• 𝑛𝑎𝑚𝑒, 𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦 % =
{𝑛𝑎𝑚𝑒, 𝑐𝑜𝑙𝑜𝑟, 𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦, 𝑑𝑒𝑝𝑎𝑟𝑡𝑚𝑒𝑛𝑡, 𝑝𝑟𝑖𝑐𝑒}

CS 564 [Fall 2020] - Paris Koutris 25


THE CLOSURE ALGORITHM

• Let 𝑋 = {𝐴! , 𝐴# , … , 𝐴" }


• UNTIL X doesn’t change REPEAT:
IF 𝐵! , 𝐵# , … , 𝐵4 ⟶ 𝐶 is an FD AND
𝐵! , 𝐵# , … , 𝐵4 are all in X
THEN add C to X
• Output X

CS 564 [Fall 2020] - Paris Koutris 26


EXAMPLE

R(A, B, C, D, E, F)
• 𝐴, 𝐵 ⟶ 𝐶
• 𝐴, 𝐷 ⟶ 𝐸
• 𝐵⟶𝐷
• 𝐴, 𝐹 ⟶ 𝐵

Compute the attribute closures:


• {𝐴, 𝐵}%= {𝐴, 𝐵, 𝐶, 𝐷, 𝐸}
• {𝐴, 𝐹}%= {𝐴, 𝐹, 𝐵, 𝐷, 𝐸, 𝐶}

CS 564 [Fall 2020] - Paris Koutris 27


WHY IS CLOSURE NEEDED?

1. Does 𝑋 ⟶ 𝑌 hold?
– we can check if Y ⊆ 𝑋 3
2. To compute the closure 𝐹 3 of FDs
– for each subset of attributes X, compute 𝑋 3
– for each subset of attributes Y ⊆ 𝑋 3 , output the
FD 𝑋 ⟶ 𝑌

CS 564 [Fall 2020] - Paris Koutris 28


KEYS & SUPERKEYS
superkey: a set of attributes 𝐴1, 𝐴2, … , 𝐴" such that
for any other attribute B in the relation:
𝐴1, 𝐴2, … , 𝐴" ⟶ 𝐵
key (or candidate key): a minimal superkey
– none of its subsets functionally determines all
attributes of the relation

If a relation has multiple keys, we specify one to be


the primary key

CS 564 [Fall 2020] - Paris Koutris 29


COMPUTING KEYS & SUPERKEYS

• Compute 𝑋 3 for all sets of attributes X


• If 𝑋 3 = 𝑎𝑙𝑙 𝑎𝑡𝑡𝑟𝑖𝑏𝑢𝑡𝑒𝑠, then X is a superkey
• If no subset of X is a superkey, then X is also a key

CS 564 [Fall 2020] - Paris Koutris 30


EXAMPLE

Product(name, category, price, color)


• 𝑛𝑎𝑚𝑒 ⟶ 𝑐𝑜𝑙𝑜𝑟
• 𝑐𝑜𝑙𝑜𝑟, 𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦 ⟶ 𝑝𝑟𝑖𝑐𝑒

Superkeys:
• 𝑛𝑎𝑚𝑒, 𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦 , 𝑛𝑎𝑚𝑒, 𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦, 𝑝𝑟𝑖𝑐𝑒
𝑛𝑎𝑚𝑒, 𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦, 𝑐𝑜𝑙𝑜𝑟 , {𝑛𝑎𝑚𝑒, 𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦, 𝑝𝑟𝑖𝑐𝑒, 𝑐𝑜𝑙𝑜𝑟}
Keys:
• 𝑛𝑎𝑚𝑒, 𝑐𝑎𝑡𝑒𝑔𝑜𝑟𝑦

CS 564 [Fall 2020] - Paris Koutris 31


HOW MANY KEYS?

Q: Is it possible to have many keys in a relation R ?

YES!! Take relation R(A, B, C)with FDs


• 𝐴, 𝐵 ⟶ 𝐶
• 𝐴, 𝐶 ⟶ 𝐵

CS 564 [Fall 2020] - Paris Koutris 32


MINIMAL BASIS FOR FDS

• Given a set F of FDs, we know how to compute the


closure F+
• A minimal basis of F is the opposite of closure
• S is a minimal basis for a set F if FDs if:
– S+ = F+
– every FD in S has one attribute on the right side
– if we remove any FD from S, the closure is not F+
– if for any FD in S we remove one or more attributes
from the left side, the closure is not F+

CS 564 [Fall 2020] - Paris Koutris 33


EXAMPLE: MINIMAL BASIS

Example:

• 𝐴 ⟶ 𝐵
• 𝐴, 𝐵, 𝐶, 𝐷 ⟶ 𝐸
• 𝐸, 𝐹 ⟶ 𝐺, 𝐻
• 𝐴, 𝐶, 𝐷, 𝐹 ⟶ 𝐸, 𝐺

CS 564 [Fall 2020] - Paris Koutris 34


STEP 1: SPLIT THE RIGHT HAND SIDE

• 𝐴 ⟶ 𝐵
• 𝐴, 𝐵, 𝐶, 𝐷 ⟶ 𝐸
• 𝐸, 𝐹 ⟶ 𝐺
• 𝐸, 𝐹 ⟶ 𝐻
• 𝐴, 𝐶, 𝐷, 𝐹 ⟶ 𝐸
• 𝐴, 𝐶, 𝐷, 𝐹 ⟶ 𝐺

CS 564 [Fall 2020] - Paris Koutris 35


STEP 2: REMOVE REDUNDANT FDS

• 𝐴 ⟶ 𝐵
• 𝐴, 𝐵, 𝐶, 𝐷 ⟶ 𝐸
• 𝐸, 𝐹 ⟶ 𝐺 can be removed, since these
• 𝐸, 𝐹 ⟶ 𝐻 FDs are logically implied
by the remaining FDs
• 𝐴, 𝐶, 𝐷, 𝐹 ⟶ 𝐸
• 𝐴, 𝐶, 𝐷, 𝐹 ⟶ 𝐺

CS 564 [Fall 2020] - Paris Koutris 36


STEP 3: CLEAN UP THE LEFT HAND SIDE

• 𝐴 ⟶ 𝐵
• 𝐴, 𝐵, 𝐶, 𝐷 ⟶ 𝐸
• 𝐸, 𝐹 ⟶ 𝐺 B can be safely removed
because of the first FD
• 𝐸, 𝐹 ⟶ 𝐻

CS 564 [Fall 2020] - Paris Koutris 37


EXAMPLE: FINAL RESULT

• 𝐴 ⟶ 𝐵
• 𝐴, 𝐶, 𝐷 ⟶ 𝐸
• 𝐸, 𝐹 ⟶ 𝐺
• 𝐸, 𝐹 ⟶ 𝐻

CS 564 [Fall 2020] - Paris Koutris 38


RECAP

• FDs and (super)keys


• Reasoning with FDs:
– given a set of FDs, infer all implied FDs
– given a set of attributes X, infer all attributes
that are functionally determined by X
• Next we will look at how to use them to detect that
a table is “bad”

CS 564 [Fall 2020] - Paris Koutris 39

You might also like