1 Functional Dependencies Meaning of FD’s Keys and Superkeys Inferring FD’s Source: slides by Jeffrey Ullman.

Slides:



Advertisements
Similar presentations
1 Lecture 7 Design Theory for Relational Databases (part 1) Slides based on
Advertisements

1 Design Theory. 2 Minimal Sets of Dependancies A set of dependencies is minimal if: 1.Every right side is a single attribute 2.For no X  A in F and.
1 Design Theory for Relational Databases Functional Dependencies Decompositions Normal Forms.
1 Loss-Less Joins. 2 Decompositions uDependency-preservation property: enforce constraints on original relation by enforcing some constraints on resulting.
Database Management Systems Chapter 3 The Relational Data Model (II) Instructor: Li Ma Department of Computer Science Texas Southern University, Houston.
Functional Dependencies - Example
Topics to be discusses Functional Dependency Key
Functional Dependencies, Normalization Rose-Hulman Institute of Technology Curt Clifton.
CMPT 354, Simon Fraser University, Fall 2008, Martin Ester 227 Database Systems I Design Theory for Relational Databases.
Functional Dependencies
Functional Dependencies. Babies At a birth, there is one baby (twins would be represented by two births), one mother, any number of nurses, and a doctor.
Classroom Exercise: Normalization
1 Multivalued Dependencies Fourth Normal Form Source: Slides by Jeffrey Ullman.
1 The Relational Data Model Functional Dependencies.
1 Multivalued Dependencies Fourth Normal Form. 2 Definition of MVD uA multivalued dependency (MVD) on R, X ->->Y, says that if two tuples of R agree on.
FDImplication: 1 Functional Dependencies (FDs) Let r(R) be a relation and let t  r, then the restriction of t to X  R, written t[X], is the projection.
1 Normalization Anomalies Boyce-Codd Normal Form 3 rd Normal Form Source: Slides by Jeffrey Ullman.
1 Multivalued Dependencies Fourth Normal Form Sources: Slides by Jeffrey Ullman book by Ramakrishnan & Gehrke.
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 Functional Dependencies Meaning of FD’s Keys and Superkeys Inferring FD’s.
The principal problem that we encounter is redundancy, where a fact is repeated in more than one tuple. Most common cause: attempts to group into one relation.
1 CMSC424, Spring 2005 CMSC424: Database Design Lecture 9.
Winter 2002Arthur Keller – CS 1804–1 Schedule Today: Jan. 15 (T) u Normal Forms, Multivalued Dependencies. u Read Sections Assignment 1 due. Jan.
1 Multivalued Dependencies Fourth Normal Form. 2 A New Form of Redundancy uMultivalued dependencies (MVD’s) express a condition among tuples of a relation.
1 Normalization Anomalies Boyce-Codd Normal Form 3 rd Normal Form.
1 Normalization Anomalies Boyce-Codd Normal Form 3 rd Normal Form Source: Slides by Jeffrey Ullman.
Fall 2001Arthur Keller – CS 1803–1 Schedule Today Oct. 2 (T) Relational Model. u Read Sections Assignment 1 due. Personal Letter of Introduction.
1 Functional Dependencies Why FD's Meaning of FD’s Keys and Superkeys Inferring FD’s Source: slides by Jeffrey Ullman.
Winter 2002Arthur Keller – CS 1803–1 Schedule Today: Jan. 10 (TH) u Relational Model, Functional Dependencies. u Read Sections Jan. 15 (T) u Normal.
Bad DB Design Duplicate of data Duplicate of data Updating Updating Deleting Deleting.
Fall 2001Arthur Keller – CS 1804–1 Schedule Today Oct. 4 (TH) Functional Dependencies and Normalization. u Read Sections Project Part 1 due. Oct.
1 Normalization Anomalies Boyce-Codd Normal Form 3 rd Normal Form.
Chapter 10 Functional Dependencies and Normalization for Relational Databases.
Database Systems Normal Forms. Decomposition Suppose we have a relation R[U] with a schema U={A 1,…,A n } – A decomposition of U is a set of schemas.
Decompositions uDo we need to decompose a relation? wSeveral normal forms for relations. If schema in these normal forms certain problems don’t.
Database Management Systems Chapter 3 The Relational Data Model (III) Instructor: Li Ma Department of Computer Science Texas Southern University, Houston.
1 Normalization Anomalies Boyce-Codd Normal Form 3 rd Normal Form.
Normalization Goal = BCNF = Boyce-Codd Normal Form = all FD’s follow from the fact “key  everything.” Formally, R is in BCNF if for every nontrivial FD.
Functional Dependencies. FarkasCSCE 5202 Reading and Exercises Database Systems- The Complete Book: Chapter 3.1, 3.2, 3.3., 3.4 Following lecture slides.
1 IT 244 Database Management System Topic 7 The Relational Data Model Functional Dependencies Ref : -A First Course in Database System (Jeffrey D Ullman,
IST 210 Normalization 2 Todd Bacastow IST 210. Normalization Methods Inspection Closure Functional dependencies are key.
1 Design Theory for Relational Databases Functional Dependencies Decompositions Normal Forms.
1 Multivalued Dependencies Fourth Normal Form Reasoning About FD’s + MVD’s.
1 Multivalued Dependencies Fourth Normal Form Reasoning About FD’s + MVD’s.
CS 405G: Introduction to Database Systems Instructor: Jinze Liu Fall 2009.
Functional Dependencies CIS 4301 Lecture Notes Lecture 8 - 2/7/2006.
Rensselaer Polytechnic Institute CSCI-4380 – Database Systems David Goldschmidt, Ph.D.
1 Functional Dependencies 函数依赖 Meaning of FD’s Keys and Superkeys Functional Dependencies.
1 The Relational Data Model Tables Schemas Conversion from E/R to Relations Functional Dependencies.
1 Design Theory for Relational Databases Functional Dependencies Decompositions Normal Forms.
Functional Dependencies Zaki Malik September 25, 2008.
CS411 Database Systems Kazuhiro Minami 04: Relational Schema Design.
Functional Dependencies. Babies Exercise 2.2.5: At a birth, there is one baby (twins would be represented by two births), one mother, any number of nurses,
Databases 1 Sixth lecture. 2 Functional Dependencies X -> A is an assertion about a relation R that whenever two tuples of R agree on all the attributes.
© 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. Functional dependencies Modification anomalies Major normal forms Relationship independence Practical concerns.
Design Theory for Relational Databases Functional Dependencies Decompositions Normal Forms: BCNF, Third Normal Form Introduction to Multivalued Dependencies.
1 Chapter 3 The Relational Data Model. 2 Contents u3.1 Basics of the Relational Model u3.2 From E/R diagrams to Relational Designs u3.4 Functional Dependencies.
1 Lecture 8 Design Theory for Relational Databases (part 2) Slides from
1 Design Theory for Relational Databases Functional Dependencies Decompositions Normal Forms.
1 Database Design: DBS CB, 2 nd Edition Physical RDBMS Model: Schema Design and Normalization Ch. 3.
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.
Design Theory for Relational Databases
Cushing, Keller, UlmanJudy Cushing
3.1 Functional Dependencies
CPSC-310 Database Systems
Multivalued Dependencies & Fourth Normal Form (4NF)
Functional Dependencies
Functional Dependencies
Multivalued Dependencies
Presentation transcript:

1 Functional Dependencies Meaning of FD’s Keys and Superkeys Inferring FD’s Source: slides by Jeffrey Ullman

2 Functional Dependencies uX -> A is an assertion about a relation R that whenever two tuples of R agree on all the attributes of X, then they must also agree on the attribute A. wSay “X -> A holds in R.” wConvention: …, X, Y, Z represent sets of attributes; A, B, C,… represent single attributes. wConvention: no set formers in sets of attributes, just ABC, rather than {A,B,C }.

3 Example Consumers(name, addr, candiesLiked, manf, favCandy) uReasonable FD’s to assert: 1.name -> addr 2.name -> favCandy 3.candiesLiked -> manf

4 Example Data nameaddr candiesLiked manffavCandy JanewayVoyager Twizzlers HersheySmarties JanewayVoyager Smarties NestleSmarties SpockEnterprise Twizzlers HersheyTwizzlers Because name -> addr Because name -> favCandy Because candiesLiked -> manf

5 FD’s With Multiple Attributes uNo need for FD’s with > 1 attribute on right. wBut sometimes convenient to combine FD’s as a shorthand. wExample: name -> addr and name -> favCandy become name -> addr favCandy u > 1 attribute on left may be essential. wExample: store candy -> price

6 Keys of Relations uK is a superkey for relation R if K functionally determines all of R. uK is a key for R if K is a superkey, but no proper subset of K is a superkey.

7 Example Consumers(name, addr, candiesLiked, manf,favCandy) u {name, candiesLiked} is a superkey because together these attributes determine all the other attributes. wname -> addr favCandy wcandiesLiked -> manf

8 Example, Cont. u{name, candiesLiked} is a key because neither {name} nor {candiesLiked} is a superkey. wname doesn’t -> manf; candiesLiked doesn’t -> addr. uThere are no other keys, but lots of superkeys. wAny superset of {name, candiesLiked}.

9 E/R and Relational Keys uKeys in E/R concern entities. uKeys in relations concern tuples. uUsually, one tuple corresponds to one entity, so the ideas are the same. uBut --- in poor relational designs, one entity can become several tuples, so E/R keys and Relational keys are different.

10 Example Data nameaddr candiesLiked manffavCandy JanewayVoyager Twizzlers HersheySmarties JanewayVoyager Smarties NestleSmarties SpockEnterprise Twizzlers HersheyTwizzlers Relational key = {name candiesLiked} But in E/R, name is a key for Consumers, and candiesLiked is a key for Candies. Note: 2 tuples for Janeway entity and 2 tuples for Twizzlers entity.

11 Where Do Keys Come From? 1.Just assert a key K. wThe only FD’s are K -> A for all attributes A. 2.Assert FD’s and deduce the keys by systematic exploration. wE/R model gives us FD’s from entity-set keys and from many-one relationships.

12 More FD’s From “Physics” uExample: “no two courses can meet in the same room at the same time” tells us: hour room -> course.

13 Inferring FD’s uWe are given FD’s X 1 -> A 1, X 2 -> A 2,…, X n -> A n, and we want to know whether an FD Y -> B must hold in any relation that satisfies the given FD’s. wExample: If A -> B and B -> C hold, surely A -> C holds, even if we don’t say so. uImportant for design of good relation schemas.

14 Inference Test uTo test if Y -> B, start by assuming two tuples agree in all attributes of Y. Y ??... ?

15 Inference Test – (2) uUse the given FD’s to infer that these tuples must also agree in certain other attributes. wIf B is one of these attributes, then Y -> B is true. wOtherwise, the two tuples, with any forced equalities, form a two-tuple relation that proves Y -> B does not follow from the given FD’s.

16 Closure Test uAn easier way to test is to compute the closure of Y, denoted Y +. uBasis: Y + = Y. uInduction: Look for an FD whose left side X is a subset of the current Y +. If the FD is X -> A, add A to Y +. uContinue until Y + cannot be changed.

17 Y+Y+ new Y + XA

18 Finding All Implied FD’s uMotivation: “normalization,” the process where we break a relation schema into two or more schemas. uExample: ABCD with FD’s AB ->C, C ->D, and D ->A. wDecompose into ABC, AD. What FD’s hold in ABC ? wNot only AB ->C, but also C ->A !

19 Why? a1b1ca1b1c ABC ABCD a2b2ca2b2c Thus, tuples in the projection with equal C’s have equal A’s; C -> A. a 1 b 1 cd 1 a 2 b 2 cd 2 comes from d 1 =d 2 because C -> D a 1 =a 2 because D -> A

20 Basic Idea 1.Start with given FD’s and find all nontrivial FD’s that follow from the given FD’s. wNontrivial = left and right sides disjoint. 2.Restrict to those FD’s that involve only attributes of the projected schema.

21 Simple, Exponential Algorithm 1.For each set of attributes X, compute X +. 2.Add X ->A for all A in X + - X. 3.However, drop XY ->A whenever we discover X ->A. uBecause XY ->A follows from X ->A in any projection. 4.Finally, use only FD’s involving projected attributes.

22 A Few Tricks uNo need to compute the closure of the empty set or of the set of all attributes. uIf we find X + = all attributes, so is the closure of any superset of X.

23 Example uABC with FD’s A ->B and B ->C. Project onto AC. wA + =ABC ; yields A ->B, A ->C. We do not need to compute AB + or AC +. wB + =BC ; yields B ->C. wC + =C ; yields nothing. wBC + =BC ; yields nothing.

24 Example --- Continued uResulting FD’s: A ->B, A ->C, and B ->C. uProjection onto AC : A ->C. wOnly FD that involves a subset of {A,C }.

25 A Geometric View of FD’s uImagine the set of all instances of a particular relation. uThat is, all finite sets of tuples that have the proper number of components. uEach instance is a point in this space.

26 Example: R(A,B) {(1,2), (3,4)} {} {(1,2), (3,4), (1,3)} {(5,1)}

27 An FD is a Subset of Instances uFor each FD X -> A there is a subset of all instances that satisfy the FD. uWe can represent an FD by a region in the space. uTrivial FD = an FD that is represented by the entire space. wExample: A -> A.

28 Example: A -> B for R(A,B) {(1,2), (3,4)} {} {(1,2), (3,4), (1,3)} {(5,1)} A -> B

29 Representing Sets of FD’s uIf each FD is a set of relation instances, then a collection of FD’s corresponds to the intersection of those sets. wIntersection = all instances that satisfy all of the FD’s.

30 Example A->B B->C CD->A Instances satisfying A->B, B->C, and CD->A

31 Implication of FD’s uIf an FD Y -> B follows from FD’s X 1 -> A 1,…,X n -> A n, then the region in the space of instances for Y -> B must include the intersection of the regions for the FD’s X i -> A i. wThat is, every instance satisfying all the FD’s X i -> A i surely satisfies Y -> B. wBut an instance could satisfy Y -> B, yet not be in this intersection.

32 Example A->B B->C A->C