Lecture 09: Functional Dependencies

Slides:



Advertisements
Similar presentations
Lecture 6: Design Constraints and Functional Dependencies January 21st, 2004.
Advertisements

Lossless Decomposition Prof. Sin-Min Lee Department of Computer Science San Jose State University.
1 Lecture 10: Database Design XML Wednesday, October 20, 2004.
Functional Dependencies Definition: If two tuples agree on the attributes A, A, … A 12n then they must also agree on the attributes B, B, … B 12m Formally:
1 Introduction to Database Systems CSE 444 Lectures 8 & 9 Database Design April 16 & 18, 2008.
Lecture #3 Functional Dependencies Normalization Relational Algebra Thursday, October 12, 2000.
Lossless Decomposition Prof. Sin-Min Lee Department of Computer Science San Jose State University.
1 Lecture 06 The Relational Data Model. 2 Outline Relational Data Model Functional Dependencies FDs in ER Logical Schema Design Reading Chapter 8.
M.P. Johnson, DBMS, Stern/NYU, Spring C : Database Management Systems Lecture #7 Matthew P. Johnson Stern School of Business, NYU Spring,
Boyce-Codd NF & Lossless Decomposition Professor Sin-Min Lee.
M.P. Johnson, DBMS, Stern/NYU, Sp20041 C : Database Management Systems Lecture #6 Matthew P. Johnson Stern School of Business, NYU Spring, 2004.
Relation Decomposition A, A, … A 12n Given a relation R with attributes Create two relations R1 and R2 with attributes B, B, … B 12m C, C, … C 12l Such.
Functional Dependencies and Relational Schema Design.
CS143 Review: Normalization Theory Q: Is it a good table design? We can start with an ER diagram or with a large relation that contain a sample of the.
Lecture 09: Functional Dependencies. Outline Functional dependencies (3.4) Rules about FDs (3.5) Design of a Relational schema (3.6)
Functional Dependencies. FarkasCSCE 5202 Reading and Exercises Database Systems- The Complete Book: Chapter 3.1, 3.2, 3.3., 3.4 Following lecture slides.
Functional Dependencies. Outline Functional dependencies (3.4) Rules about FDs (3.5) Design of a Relational schema (3.6)
1 Lecture 7: Normal Forms, Relational Algebra Monday, 10/15/2001.
1 Lecture 10: Database Design Wednesday, January 26, 2005.
Functional Dependencies and Relational Schema Design.
Lecture 3: Conceptual Database Design and Schema Design April 12 th, 2004.
Lecture 13: Relational Decomposition and Relational Algebra February 5 th, 2003.
1 Lecture 10: Database Design and Relational Algebra Monday, October 20, 2003.
CS411 Database Systems Kazuhiro Minami 04: Relational Schema Design.
© D. Wong Functional Dependencies (FD)  Given: relation schema R(A1, …, An), and X and Y be subsets of (A1, … An). FD : X  Y means X functionally.
1 Lecture 9: Database Design Wednesday, January 25, 2006.
CSC 411/511: DBMS Design Dr. Nan Wang 1 Schema Refinement and Normal Forms Chapter 19.
Formal definition of a key A key is a set of attributes A 1,..., A n such that for any other attribute B: A 1,..., A n  B A minimal key is a set of attributes.
Lecture 11: Functional Dependencies
Design Theory for Relational Databases
CS422 Principles of Database Systems Normalization
Schedule Today: Next After that Normal Forms. Section 3.6.
COP4710 Database Systems Relational Design.
Module 5: Overview of Database Design -- Normalization
CS422 Principles of Database Systems Normalization
CPSC-310 Database Systems
Lecture 4 Database design IV Normal Forms: Summary.
Chapter 8: Relational Database Design
3.1 Functional Dependencies
Handout 4 Functional Dependencies
Problems in Designing Schema
Cse 344 May 18th – Loss and views.
Lecture 6: Design Theory
Normalization Murali Mani.
Functional Dependencies and Normalization
Lecture 2: Database Modeling (end) The Relational Data Model
Cse 344 May 16th – Normalization.
Functional Dependencies and Relational Schema Design
Introduction to Database Systems CSE 444 Lectures 8 & 9 Database Design October 12 & 15, 2007.
Lecture 09: Functional Dependencies, Database Design
Chapter 15 Basics of Functional Dependencies and Normalization for Relational Databases.
Lecture 8: Database Design
Lectures 12: Design Theory I
Functional Dependencies
Lecture 07: E/R Diagrams and Functional Dependencies
Normalization cs3431.
CS 405G: Introduction to Database Systems
Instructor: Mohamed Eltabakh
CSE544 Data Modeling, Conceptual Design
CS4433 Database Systems Relational Design.
Relational Database Design
Terminology Product Attribute names Name Price Category Manufacturer
Lecture 08: E/R Diagrams and Functional Dependencies
Lecture 6: Functional Dependencies
Lecture 11: Functional Dependencies
Chapter 3: Design theory for relational Databases
Chapter 7a: Overview of Database Design -- Normalization
CS4222 Principles of Database System
Design Theory for Relational Databases
Presentation transcript:

Lecture 09: Functional Dependencies

Outline Functional dependencies (3.4) Rules about FDs (3.5) Design of a Relational schema (3.6)

Relational Schema Design Person buys Product name price ssn date Conceptual Model: Relational Model: plus FD’s Normalization: Eliminates anomalies

Functional Dependencies Definition: A1, ..., Am → B1, ..., Bn holds in R if: t, t’  R, (t.A1=t’.A1  ...  t.Am=t’.Am  t.B1=t’.B1  ...  t.Bm=t’.Bm ) R A1 ... Am B1 Bm t if t, t’ agree here then t, t’ agree here t’

Important Point! Functional dependencies are part of the schema! They constrain the possible legal data instances. At any point in time, the actual database may satisfy additional FD’s.

Examples EmpID → Name, Phone, Position Position → Phone John Smith 2376 HR E1847 Zheng Li QA E3123 Lucy Larsen 1264 Developer E9923 EmpID → Name, Phone, Position Position → Phone but Phone → Position

Formal definition of a key A key is a set of attributes A1, ..., An s.t. for any other attribute B, A1, ..., An → B A minimal key is a set of attributes which is a key and for which no subset is a key Note: book calls them superkey and key

Examples of Keys Product(name, price, category, color) name, category → price category → color Keys are: {name, category} and all supersets Enrollment(student, address, course, room, time) student → address room, time → course student, course → room, time Keys are: [in class] Keys: {student, room, time}, {student, course} and all supersets

Inference Rules for FD’s A1 , A2 , … An→B1, B2, … Bm Splitting rule and Combing rule Is equivalent to A1 , A2 , … An →B1 A1 , A2 , … An →B2 A1 , A2 , … An →Bm … A1 ... Am B1 Bm AND

Inference Rules for FD’s (continued) A1 , A2 , … An → Ai Trivial Rule where i = 1, 2, ..., n A1 ... Am Why ?

Inference Rules for FD’s (continued) Transitive Closure Rule If A1 , A2 , … An → B1, B2, … Bm and B1, B2, … Bm → C1 , C2 , … Ck then A1 , A2 , … An → C1 , C2 , … Ck Why?

A1 ... Am B1 Bm C1 Ck

Enrollment(student, major, course, room, time) course → time What else can we infer ? [in class]

Closure of a set of Attributes Given a set of attributes {A1, …, An} and a set of dependencies S. Problem: find all attributes B such that: any relation which satisfies S also satisfies: A1 , A2 , … An → B The closure of {A1, …, An}, denoted {A1, …, An}+, is the set of all such attributes B

Closure Algorithm Start with X={A1, …, An}. Until X doesn’t change do: if B1, B2, … Bm → C is in S, and B1, B2, … Bm are all in X and C is not in X then add C to X

Example The schema - R(A,B,C,D,E,F) A, B → C A,D → E B → D A,F → B Closure of {A,B}: X = {A, B, } Closure of {A, F}: X = {A, F, }

Why Is the Algorithm Correct ? Show the following by induction: For every B in X: A1 , A2 , … An → B Initially X = {A1 , A2 , … An } holds Induction step: B1, …, Bm in X Implies A1 , A2 , … An → B1, B2, … Bm We also have B1, B2, … Bm → C By transitivity we have A1 , A2 , … An → C This shows that the algorithm is sound; need to show it is complete

Relational Schema Design (or Logical Design) Main idea: Start with some relational schema Find out its FD’s Use them to design a better relational schema

Relational Schema Design Recall set attributes (persons with several phones): Name SSN PhoneNumber City Fred 123-45-6789 206-555-1234 Seattle 206-555-6543 Joe 987-65-4321 908-555-2121 Westfield 908-555-1234 SSN → Name, City, but not SSN → PhoneNumber Anomalies: Redundancy = repeated data Update anomalies = Fred moves to “Bellevue” Deletion anomalies = Fred drops all phone numbers: what is his city ?

Relation Decomposition Break the relation into two: Name SSN City Fred 123-45-6789 Seattle Joe 987-65-4321 Westfield SSN PhoneNumber 123-45-6789 206-555-1234 206-555-6543 987-65-4321 908-555-2121 908-555-1234

Relational Schema Design Person buys Product name price ssn date Conceptual Model: Relational Model: plus FD’s Normalization: Eliminates anomalies

Decompositions in General R(A1, ..., An) Create two relations R1(B1, ..., Bm) and R2(C1, ..., Ck) such that: B1, ..., Bm  C1, ..., Ck = A1, ..., An and: R1 = projection of R on B1, ..., Bm R2 = projection of R on C1, ..., Ck

Incorrect Decomposition Sometimes it is incorrect: Name Price Category Gizmo 19.99 Gadget OneClick 24.99 Camera DoubleClick 29.99 Decompose on : Name, Category and Price, Category

Incorrect Decomposition Name Category Gizmo Gadget OneClick Camera DoubleClick Price Category 19.99 Gadget 24.99 Camera 29.99 When we put it back: Cannot recover information Name Price Category Gizmo 19.99 Gadget OneClick 24.99 Camera 29.99 DoubleClick

Normal Forms First Normal Form = all attributes are atomic Second Normal Form (2NF) = old and obsolete Third Normal Form (3NF) = this lecture Boyce Codd Normal Form (BCNF) = this lecture Others...

Boyce-Codd Normal Form A simple condition for removing anomalies from relations: A relation R is in BCNF if: Whenever there is a nontrivial dependency A1, ..., An → B in R , {A1, ..., An} is a key for R Including superkeys In English: Whenever a set of attributes of R determines one more attribute, it should determine all the attributes of R.

Example What are the dependencies? SSN → Name, City What are the keys? PhoneNumber City Fred 123-45-6789 206-555-1234 Seattle 206-555-6543 Joe 987-65-4321 908-555-2121 Westfield 908-555-1234 What are the dependencies? SSN → Name, City What are the keys? {SSN, PhoneNumber} Is it in BCNF?

Decompose it into BCNF SSN → Name, City Name SSN City Fred 123-45-6789 Seattle Joe 987-65-4321 Westfield SSN → Name, City SSN PhoneNumber 123-45-6789 206-555-1234 206-555-6543 987-65-4321 908-555-2121 908-555-1234

Summary of BCNF Decomposition Find a dependency that violates the BCNF condition: A1 , A2 , … An → B1, B2, … Bm Heuristics: choose B1, B2, … Bm “as large as possible” Decompose: Continue until there are no BCNF violations left. Others A’s B’s Exercise: Is there a 2-attribute relation that is not in BCNF ? R1 R2

Example Decomposition Person(name, SSN, age, hairColor, phoneNumber) SSN → name, age age → hairColor Decompose in BCNF (in class): Step 1: find all keys Step 2: now decompose

Other Example R(A,B,C,D) A → B, B → C Key: A, D Violations of BCNF: A → B, B → C, A → C, A → B,C Pick A → B,C: split R into R1(A,B,C), R2(A,D) What happens if we pick A → B first ?

Correct Decompositions A decomposition is lossless if we can recover: R(A,B,C) R1(A,B) R2(A,C) R’(A,B,C) should be the same as R(A,B,C) Decompose Recover R’ is in general larger than R. Must ensure R’ = R

Correct Decompositions Given R(A,B,C) s.t. A→B, the decomposition into R1(A,B), R2(A,C) is lossless

3NF: A Problem with BCNF Film Actor Character FD’s: Character Film; Film, Actor Character So, there is a BCNF violation, and we decompose. Film Character Character Film Actor Character No FDs

So What’s the Problem? Film Character Austin Powers Dr. Evil Actor Mike Myers Austin Powers Dr. Evil No problem so far. All local FD’s are satisfied. Let’s put all the data back into a single table again: What happened here? Film Actor Character Austin Powers Mike Myers Dr. Evil Violates the dependency: Film, Actor Character!

Solution: 3rd Normal Form (3NF) A simple condition for removing anomalies from relations: 3NF has a dependency-preserving decomposition A relation R is in 3rd normal form if : Whenever there is a nontrivial dependency A1, A2, ..., An  B for R , then {A1, A2, ..., An } a key for R, or B is part of a key. Including superkeys

Decomposition into 3NF Easy when we know BCNF decomposition (how?) Not-so-easy: if we want a dependency-preserving decomposition… In the book (3.5)