# multivalued dependencies

Post on 01-Feb-2016

36 views

Embed Size (px)

DESCRIPTION

Multivalued Dependencies. Fourth Normal Form. Sources: Slides by Jeffrey Ullman book by Ramakrishnan & Gehrke. Limitations of FD’s. Some redundancies cannot be detected using just functional dependencies - PowerPoint PPT PresentationTRANSCRIPT

Multivalued DependenciesFourth Normal FormSources: Slides by Jeffrey Ullman book by Ramakrishnan & Gehrke

Limitations of FDsSome redundancies cannot be detected using just functional dependenciesExample: suppose a teacher can teach several courses, several books can be recommended for a course, and same book can be recommended for different courses.Suppose all this information is smushed together into one relation CTBThere are no FDs, so key is CTB and relation is in BCNFBut there is redundancy since course implies bookEliminate redundancy by decomposing into CT and CB

Example of FD Limitations

Definition of MVDNotion of MVD captures redundancy that FDs cantA multivalued dependency (MVD) on R, X ->->Y , says that if two tuples of R agree on all the attributes of X, then their components in Y may be swapped, and the result will be two tuples that are also in the relation.i.e., for each value of X, the values of Y are independent of the values of R-X-Y.

Relation with C ->-> T

Another ExampleConsumers(name, addr, phones, candiesLiked)A consumers phones are independent of the candies they like.name->->phones and name ->->candiesLiked.Thus, each of a consumers phones appears with each of the candies they like in all combinations.This repetition is unlike FD redundancy.name->addr is the only FD.

Tuples Implied by name->->phonesIf we have tuples:nameaddrphones candiesLikedsueap1 b1sueap2 b2

Picture of MVD X ->->Y XY others

equal

exchange

MVD RulesEvery FD is an MVD (promotion ).If X ->Y, then swapping Y s between two tuples that agree on X doesnt change the tuples.Therefore, the new tuples are surely in the relation, and we know X ->->Y.Complementation : If X ->->Y, and Z is all the other attributes, then X ->->Z.

Splitting Doesnt HoldLike FDs, we cannot generally split the left side of an MVD.But unlike FDs, we cannot split the right side either --- sometimes you have to leave several attributes on the right side.

ExampleConsumers(name, areaCode, phone, candiesLiked, manf)A consumer can have several phones, with the number divided between areaCode and phone (last 7 digits).A consumer can like several candies, each with its own manufacturer.

Example, ContinuedSince the areaCode-phone combinations for a consumer are independent of the candiesLiked-manf combinations, we expect that the following MVDs hold:name ->-> areaCode phonename ->-> candiesLiked manf

Example DataHere is possible data satisfying these MVDs:

nameareaCodephonecandiesLikedmanfSue650555-1111TwizzlersHersheySue650555-1111SmartiesNestleSue415555-9999TwizzlersHersheySue415555-9999SmartiesNestleBut we cannot swap area codes or phones by themselves.That is, neither name->->areaCode nor name->->phoneholds for this relation.

Fourth Normal FormThe redundancy that comes from MVDs is not removable by putting the database schema in BCNF.There is a stronger normal form, called 4NF, that (intuitively) treats MVDs as FDs when it comes to decomposition, but not when determining keys of the relation.

4NF DefinitionA relation R is in 4NF if: whenever X ->->Y is a nontrivial MVD, then X is a superkey.Nontrivial MVD means that:Y is not a subset of X, andX and Y are not, together, all the attributes.Note that the definition of superkey still depends on FDs only.

BCNF Versus 4NFRemember that every FD X ->Y is also an MVD, X ->->Y.Thus, if R is in 4NF, it is certainly in BCNF.Because any BCNF violation is a 4NF violation (after conversion to an MVD).But R could be in BCNF and not 4NF, because MVDs are invisible to BCNF.

Decomposition and 4NFIf X ->->Y is a 4NF violation for relation R, we can decompose R using the same technique as for BCNF.XY is one of the decomposed relations.All but Y X is the other.

ExampleConsumers(name, addr, phones, candiesLiked)FD: name -> addrMVDs: name ->-> phonesname ->-> candiesLikedKey is {name, phones, candiesLiked}.All dependencies violate 4NF.

Example, ContinuedDecompose using name -> addr:Consumers1(name, addr)In 4NF; only dependency is name -> addr.Consumers2(name, phones, candiesLiked)Not in 4NF. MVDs name ->-> phones and name ->-> candiesLiked apply. No FDs, so all three attributes form the key.

(Sadly, no simple rule for projecting MVDs onto decomposed relations use heuristics and knowledge of application)

Example: Decompose Consumers2Either MVD name ->-> phones or name ->-> candiesLiked tells us to decompose to:Consumers3(name, phones)Consumers4(name, candiesLiked)

Normal Form Comparisons4NF BCNF 3NF

Property3NFBCNF4NFeliminates FD redundanciesmostyesyeseliminates MVD redundanciesnonoyespreserves FDsyesmaybemaybepreserves MVDsmaybemaybemaybe

Recommended