12
Functional Dependencies (Part 3) Presented by Nash Raghavan All page numbers are in reference to Database System Concepts (5 th Edition)

Functional Dependencies (Part 3)

  • Upload
    bao

  • View
    86

  • Download
    0

Embed Size (px)

DESCRIPTION

All page numbers are in reference to Database System Concepts (5 th Edition). Functional Dependencies (Part 3). Presented by Nash Raghavan. Agenda. Quick Review What is a functional dependency Different normal forms Functional Dependency Theory Closure of a Set of Dependencies - PowerPoint PPT Presentation

Citation preview

Page 1: Functional Dependencies (Part 3)

Functional Dependencies(Part 3)

Presented by Nash Raghavan

All page numbers are in reference toDatabase System Concepts (5th Edition)

Page 2: Functional Dependencies (Part 3)

Agenda

Quick Review What is a functional dependency Different normal forms

Functional Dependency Theory Closure of a Set of Dependencies Decomposition using F.D. Multivalued dependencies

Page 3: Functional Dependencies (Part 3)

Quick Review

What is a functional dependency? SSN → Name “Name is functionally dependent on

SSN” Given a relation R, if , then must be the same

whenever is the same for all tuples in R

First Normal Form Domains of all attributes in relation R are atomic Page 269

Boyce-Codd Normal Form For all functional dependencies , is a

superkey Page 272

Page 4: Functional Dependencies (Part 3)

Functional Dependency Theory Armstrong’s axioms (page 279)

Reflexivity rule: If , then holds Example: A A , BCD BC

Augmentation rule: If , then

Example: A B, therefore AC BC

Transitivity: If and then Example: A B and B C then A C

Page 5: Functional Dependencies (Part 3)

Functional Dependency Theory Additional rules (page 280)

Union rule: If and then

Example: If A B and A C then A BC

Decomposition rule: If , then and

Example: A BC, then A B and A C

Pseudo-transitivity: If and then

Example: A B and BD C then AD C

Page 6: Functional Dependencies (Part 3)

The Closure of a Set Why do we care about the axioms? Given a set of functional

dependencies denoted by F { A B, A C, CG H, CG I, B H }

We can now determine logically implied functional dependencies such as A H

The set of all functional dependencies implied by F is denoted by F+ and is called the closure of F

See page 279 for more details

Page 7: Functional Dependencies (Part 3)

Decomposition The ability to compute F+ enables us

to convert a relation R into any normal form

Example: BCNF Decomposition See pages 289 – 290

lending = ( branch_name, branch_city, assets, customer_name, loan_number, amount )

Candidate Key: { loan_number, customer_name }Functional Dependencies:

branch_name assets branch_city

loan_number amount branch_name

Page 8: Functional Dependencies (Part 3)

Decomposition The problem

branch_name assets branch_city

Valid but branch_name is not a superkey, therefore it is not in BCNF!

The solution – decomposition!lending = ( branch_name, branch_city, assets,

customer_name, loan_number, amount )

Decomposes to multiple relations:branch = ( branch_name, branch_city, assets )loan_info = ( branch_name, customer_name, loan_number, amount )

Page 9: Functional Dependencies (Part 3)

Decomposition branch relation is now in BCNF but loan_info is

not because loan_number is not a superkey given the following dependency:loan_number amount branch_name

Solution is to iteratively decompose relations until all relations are in desired form.

To complete solution, decompose loan_info to:loanb = ( loan_number, branch_name, amount )borrower = ( customer_name, loan_number )

Page 10: Functional Dependencies (Part 3)

Decomposition The beginning:

lending = ( branch_name, branch_city, assets, customer_name, loan_number, amount )

The end result:branch = ( branch_name, branch_city, assets )

loanb = ( loan_number, branch_name, amount )borrower = ( customer_name, loan_number )

The Original Functional Dependencies:

branch_name assets branch_city

loan_number amount branch_name

Everything is now in BCNF!

Page 11: Functional Dependencies (Part 3)

Multivalued Dependencies A multivalued dependency, denoted:

Means a tuple must exist for every value in

Example: class booksClass = { CS 157, CS 46 }Books = { Manual, Solution }

CID class books

10 CS 46 Manual

10 CS 46 Solution

20 CS 157 Manual

20 CS 157 SolutionMultivalued dependencies result in duplicate

data and are considered “tuple-generating dependencies”.

Formal definition – see page 295

Page 12: Functional Dependencies (Part 3)

The End

This information will become relevant … eventually.

Makes more sense when we study: Database design/creation Normalization

BCNF, 1NF, 2NF, 3NF, 4NF Decomposition Denormalization