prev

next

out of 73

Published on

16-Nov-2014View

619Download

2

Embed Size (px)

DESCRIPTION

Study Guides of Functional Dependency Concepts in Database Programming

Transcript

<p>FUNCTIONAL DEPENDENCIES</p>
<p>CSC343</p>
<p>Functional Dependencies</p>
<p>Functional Dependencies</p>
<p>Examples: PERSON RelationPERSON SIN NAME CITY 123 Laurent Toronto 324 Bill Toronto 574 Bill Montreal What can we say about Person table?</p>
<p> If I know the sin number I know the name SIN attribute determines NAME attribute. Attribute NAME functionally depends on attribute SIN Warning: Knowing the NAME does not imply the SIN knowledge: NAMENOTATION: SIN NAME</p>
<p>SIM</p>
<p>2 CSC343</p>
<p>Functional Dependencies</p>
<p>Functional Dependencies</p>
<p>COURSES RelationSTUDENT 0,n enroll 0,n COURSES 1,1 teach 0,n PROF Name Name Name</p>
<p>COURSE</p>
<p>NAME Database Database Database Math</p>
<p>PROF STUDENT MIGNET SMITH MIGNET BILL MIGNET SMITH HARDIN GEORGE</p>
<p> A Course has only one Professor NAME PROF 2 tuples that have the same value for NAME have the same value for PROF3 CSC343</p>
<p>Functional Dependencies</p>
<p>Functional Dependencies</p>
<p>Key ExamplePERSON (SIN, LastName, FirstName, Address)</p>
<p>SIN SIN SIN</p>
<p>LastName FirstName Address</p>
<p> If we know the SIN value, we know all the attributes. 2 tuples sharing the same SIN are identical SIN identies a tuple. SIN is a keySIN LastName FirstName SIN LastName is a superkey (LastName is redundant)4 CSC343</p>
<p>Functional Dependencies</p>
<p>Functional Dependencies</p>
<p>SUPPLYING RelationSUPP (SNAME, PNAME, QUANT, PRICE)</p>
<p>SNAME PNAME QUANT SNAME PNAME PRICE SNAME PNAME is a key.SUPPLIER 0,n Quant SUPPLYING 0,n PRODUCT Pname Price Sname</p>
<p>5 CSC343</p>
<p>Functional Dependencies</p>
<p>Functional Dependencies</p>
<p>ADDRESS RelationADDRESS (STREET, NUMBER, CITY, ZIPCODE) Simplifying Hypothesis</p>
<p> Several zipcode for a city: Toronto = M5B3F4, M5S2E4, . . . One city for a zipcode: Mxxxxx = Toronto An address (street + number + city) belongs only to one zipcode: 4 St George Street,Toronto = M5S 2E4 Number Street City Zipcode City Zipcode</p>
<p>Keys of the relation ADDRESS: (Street Number City) and (Number Street Zipcode)</p>
<p>6 CSC343</p>
<p>Functional Dependencies</p>
<p>Functional Dependencies</p>
<p>Denitions</p>
<p>a) Functional Dependencies Let R(U) a relational schema, r one relation of the schema R, X attribute sub-set of R. The functional dependencies X Y U, Y U two</p>
<p>is true in r, iff (if and only if) for every tuples of r that share the same value for all attributes of X, they also share the same value for all attributes of Y. Example: ADDRESS(STREET, NUMBER, CITY, ZIPCODE) X = ZipCode Y = City</p>
<p>7 CSC343</p>
<p>Functional Dependencies</p>
<p>Functional Dependencies</p>
<p>b) SuperKey Let R(U) a schema and X U a attribute subset. X is a superkey superkey of r of the schema R, if X</p>
<p>U.</p>
<p>Example: SIN LASTNAME SIN LASTNAME FIRSTNAME ADDRESS SIN LASTNAME is a superkey c) KEY X is a key, if: 1. X is a superkey: X 2. it does not exist Y U X, such that Y U</p>
<p>Example: STREET NUMBER CITY STREET NUMBER CITY ZIPCODE STREET NUMBER CITY is a key (why?)</p>
<p>8 CSC343</p>
<p>Functional Dependencies</p>
<p>Functional Dependencies</p>
<p>Finding a Key: Example</p>
<p>COURSE(Name,Hour,Room,Prof) N HR, HR P We can proof from that if we know the name of the course, we also know the name of the professor. (Name is a key): 1. N HR: two tuples that share the name of the course share also the hour and the room value. 2. HR P: two tuples that share the hour and the room share also the name of the professor. 3. FD 1 and 2 implie that two tuples which have the same name for the course have also the same professor name: N P We can dene some properties and rules on the FD which permit to deduct others FDs.</p>
<p>9 CSC343</p>
<p>Functional Dependencies</p>
<p>Functional Dependencies</p>
<p>Functional Dependencies Properties</p>
<p>(Armstrongs Axioms) 1) Reexivity If X Y then Y X (for every attribute subsets X et Y)</p>
<p>Example: NAME CITY NAME Trivial: Two persons who have the same name and live in the same city have the same name.</p>
<p>10 CSC343</p>
<p>Functional Dependencies</p>
<p>Functional Dependencies</p>
<p>2) Transitivity If X Y and Y Z, then X Z Example : R(SIN, ZIPCODE, CITY) SIN ZIPCODE, ZIPCODE CITY SIN CITY If we know the zipcode from a sin number and the city form the zipcode then we know the city from the sin number. 3) Augmentation X Y XZ YZ SIN CITY ZIPCODE CITY Example: SIN</p>
<p>ZIPCODE</p>
<p>11 CSC343</p>
<p>Functional Dependencies</p>
<p>Functional Dependencies</p>
<p>4) Union et decomposition X X A, X Y, WY B Z 5) Pseudotransitivity</p>
<p>XWX</p>
<p>AB Z</p>
<p>REMARK: Union, decomposition and pseudotransitivity can be deduced from the others axioms.</p>
<p>12 CSC343</p>
<p>Functional Dependencies</p>
<p>Functional Dependencies</p>
<p>Closing set of a functional dependencies set</p>
<p>From the functional dependencies set given from the real world and using the preceding properties (Armstrongs axioms) we can deduce others FDs: Examples: 1) R(A,B,C,D) = A B, B C A C C Transitivity: A Notation:</p>
<p>13 CSC343</p>
<p>Functional Dependencies</p>
<p>Functional Dependencies</p>
<p>2) R(Course, Prof, Hour, Room, Student, Mark) = C HR P, HR P, HS C, HP C,P,M R, CS M, HS R</p>
<p>So HS is a key Why? The union of denoted . and every deduced FD is called closing set, or attribute closure of is</p>
<p>14 CSC343</p>
<p>Functional Dependencies</p>
<p>Functional Dependencies</p>
<p>Minimal Closure</p>
<p>The minimal closure 1. We can infer from</p>
<p>of a set</p>
<p>of functional dependencies (FD) is a set of FD such that: : =</p>
<p>the same FD than from</p>
<p>(decomposition)</p>
<p>2. Only one attribute is on the right side on every FD in</p>
<p>3. Every FD are useful: if we delete one we can not obtain 4. Every FD are elemantary: the set A which is not elementary by A B.</p>
<p> anymore.</p>
<p>C; AC B is redundant: we replace AC B,</p>
<p>15 CSC343</p>
<p>Functional Dependencies</p>
<p>Functional Dependencies</p>
<p>ExampleFunctional Dependencies AB C C A BC D ACD B D EG BE C CE AG CE ACD Minimal Closure AB C C A BC D CD B D E D G BE C CE G</p>
<p>A is missing, why? B is not elementary, why?</p>
<p>16 CSC343</p>
<p>Functional Dependencies</p>
<p>Functional Dependencies</p>
<p>Answer: ACD C CCD CD A B is not elemenaty, why? CCD ACD ACD by augmentation CD ACD (A B CD A by reexivity and union) B by transitivity</p>
<p>ACD and ACD</p>
<p>Second demonstration By pseudotransitivity, C A, ACD B CCD B CD B.</p>
<p>17 CSC343</p>
<p>Functional Dependencies</p>
<p>Functional Dependencies</p>
<p>Minimal Closure</p>
<p>Concretely, the minimal closure</p>
<p> is either directly given by the real world analysis. is eitheir trivialy deduced because: every FD are useful and elementary It is enough to decompose the right side of every FDs.</p>
<p>18 CSC343</p>
<p>Functional Dependencies</p>
<p>Functional Dependencies</p>
<p>New Denition for a SuperKey</p>
<p>Let R(U) a relational schema, a set of functional dependencies and X U a set of attributes. X is a superkey of R if for all A U X or if: X Compute A A</p>
<p> from</p>
<p>might take time. X A is easy and fast.</p>
<p>But show that</p>
<p>19 CSC343</p>
<p>Functional Dependencies</p>
<p>Functional Dependencies</p>
<p>Calculation of a key of a relation</p>
<p>Let R(U) a relational schema and X</p>
<p>U a set of attributes. X A</p>
<p> We dene as a subset of attributes A such that If A belongs to , then by denition X A is the set of functionally dependent attributes of X.To nd a key we use the following algorithm: 1. We search for one X such that</p>
<p> = U X is a superkey X such that = U 2. X is a key, if it does not exist Y</p>
<p>20 CSC343</p>
<p>Functional Dependencies</p>
<p>Functional Dependencies</p>
<p>Step 1: We start from X For every Y A, such that Y We get . Step i: We start For every Y We get .</p>
<p>X, Y</p>
<p>A</p>
<p>, we add A to X.</p>
<p>A, such that Y</p>
<p> , Y</p>
<p>A</p>
<p>, we add A to</p>
<p> .</p>
<p>We stop when we do not nd new FDs anymore.</p>
<p> =</p>
<p> =</p>
<p>21 CSC343</p>
<p>Functional Dependencies</p>
<p>Functional Dependencies</p>
<p>Examples</p>
<p>1. Show that HS is a key for R(CHSNRP) with the set</p>
<p>of FD given before.</p>
<p>2. for the relation ADDRESS(CITY, STREET, NUMBER, ZIPCODE), show that CITY STREET NUMBER is a key. What is the other one?</p>
<p>22 CSC343</p>
<p>UPDATE ANOMALIES</p>
<p>CSC343</p>
<p>Functional Dependencies</p>
<p>Update Anomalies</p>
<p>Example</p>
<p>Let the schema S1: Supplier(SNAME, FADDRESS) Product(SNAME, PNAME, PRICE) and the set of DF: SNAME FADDRESS, (SNAME PNAME) PRICE</p>
<p>Suppose now that we replace S1 by S2: R(SNAME, SADDRESS, PNAME, PRICE)</p>
<p>24 CSC343</p>
<p>Functional Dependencies</p>
<p>Update Anomalies</p>
<p>Anomalies</p>
<p>R(SNAME, SADDRESS, PNAME, PRICE) SNAME SADDRESS, (SNAME PNAME) PRICE</p>
<p>What is the key of R? SMITH JONS SMITH Toronto Montreal Toronto COMPUTER COMPUTER KEYBOARD 1000 900 400</p>
<p>1) REDONDANCY: the address for one supplier appears several times. 2) UPDATE: if we change the address in one tuple, we must also perform the same update in the others.</p>
<p>25 CSC343</p>
<p>Functional Dependencies</p>
<p>Update Anomalies</p>
<p>3) DELETION: if JONS do not supply COMPUTER anymore, we delete the second tuple we lost any information about JONS. 4) INSERTION: we can not insert a new supplier and its address if we do not know, at least, one product that it supplies. SMITH JONS SMITH DURAND Toronto Montreal Toronto NICE COMPUTER COMPUTER KEYBOARD 1000 900 400</p>
<p> THE INITIAL SCHEMA S1 IS BETTER</p>
<p>26 CSC343</p>
<p>Functional Dependencies</p>
<p>Update Anomalies</p>
<p>Integrity Constraints</p>
<p>The list of attributes is not sufcient to describe the semantic of the real world. It exists several types of constraints on the tuples: 1. dependencies (functional, multivalued, ...) 2. constraints that depend of the attribute domain: year 3. etc. It is the dependencies which permits a good schema conception, i.e., the decomposition in good relations. 2000</p>
<p>27 CSC343</p>
<p>Functional Dependencies</p>
<p>Update Anomalies</p>
<p>Qualities for a good schema</p>
<p>1. Avoid anomalies</p>
<p> decomposition</p>
<p>2. The decomposition should keep the same amount of information Join a relation f1 of the schema SUPPLIER(SNAME, SADDRESS) and a relation f2 of the schema SUPPLIER(SNAME, PNAME, PRICE) got by decomposition of the relation r of the schema R(SNAME, SADDRESS, PNAME, PRICE) must give back r. 3. The decomposition must keep the same constraints (FD). The decomposition of R in R1(SNAME, SADDRESS, PRICE) and R2(PNAME, PRICE) do not preserve the FD. Why?</p>
<p>28 CSC343</p>
<p>DECOMPOSITION AND NORMAL FORM</p>
<p>CSC343</p>
<p>Functional Dependencies</p>
<p>Decomposition and Normal Form</p>
<p>Relation in rst normal form (1NF)</p>
<p> All attributes are atomic (elementary) Relation that we know.</p>
<p>30 CSC343</p>
<p>Functional Dependencies</p>
<p>Decomposition and Normal Form</p>
<p>Relation 1NF MARKS ( COURSE DB DB DB ARCHI ARCHI Relation N1FN MARKS ( COURS DB PERF (STUDENT John Mark Tom Tom John MARK) ) 80 90 0 100 0 STUDENT John Mark Tom Tom John MARK ) 80 90 0 100 0</p>
<p>ARCHI</p>
<p>31 CSC343</p>
<p>Functional Dependencies</p>
<p>Decomposition and Normal Form</p>
<p>Relation in 3rd Normal Form</p>
<p> 2nd Normal Form:Purely historical.</p>
<p> 3rd normal form: 3NF avoid most of the anomalies Goal of the game: to decompose a relation (1NF) to a set of 3NF relations.</p>
<p>32 CSC343</p>
<p>Functional Dependencies</p>
<p>Decomposition and Normal Form</p>
<p>3NF: First Denition</p>
<p>Let (R, F) be a relational schema. We suppose that is a minimal closure. A of ,</p>
<p>Denition: R is in 3NF, if for every X</p>
<p> either X is a key or A belongs to one of the keys.</p>
<p>33 CSC343</p>
<p>Functional Dependencies</p>
<p>Decomposition and Normal Form</p>
<p>Examples: 3rd Normal Form</p>
<p>1) Post(City, Street, Zipcode) = CS Z, Z C Keys: CS, SZ Post is in 3NF. 2) Supplier(SNAME, ADDR, PNAME, PRICE) = SNAME ADDR, SNAME PNAME Keys: (SNAME PNAME) Supplier is not in 3NF. PRICE</p>
<p>34 CSC343</p>
<p>Functional Dependencies</p>
<p>Decomposition and Normal Form</p>
<p>3) Schedule(Course, Hour, Room) = RH C, C R Keys: RH, CH Schedule is in 3NF. 4) R(A, B, C, D) = AB C, B D, BC A</p>
<p>Keys: AB, BC R is not in 3NF.</p>
<p>35 CSC343</p>
<p>Functional Dependencies</p>
<p>Decomposition and Normal Form</p>
<p>3NF: Second Denition</p>
<p>Remark: It is not necessary for of ,</p>
<p>to be a minimal closure. It is enough that for all FD X</p>
<p>A</p>
<p> A is only composed by one attribute. A is not one of the attribute of XThe denition of a 3NF schema becames: Denition: A relation R is in 3NF, if every FD X conditions, A of</p>
<p> satises the preceding</p>
<p> either X is a superkey or A belongs to one of the keys.Actually, it is not necessary to check all FD of It is enough to check the ones belonging to !</p>
<p>.</p>
<p>36 CSC343</p>
<p>Functional Dependencies</p>
<p>Decomposition and Normal Form</p>
<p>RemarK (Contd): Why superkey in the rst condition? With conditions 1 and 2 weaker than the condition on the minimal closure it may exist some non elementary conditions: If X A is a non elementary condition and if X = U, then X is a superkey.</p>
<p>37 CSC343</p>
<p>Functional Dependencies</p>
<p>Decomposition and Normal Form</p>
<p>Remark (end): R(A,B,C,D) = AB C, B D, D B, B is not a minimal closure, why? (R, ) is in 3NF, why? A</p>
<p>38 CSC343</p>
<p>Functional Dependencies</p>
<p>Decomposition and Normal Form</p>
<p>Lossless-Join DecompositionExample R ( A a a c B B b b b C ) c a d</p>
<p>and</p>
<p>=</p>
<p>A</p>
<p>We decompose in: R1 ( A a c B ) b b R2 ( B b b b C ) c a d</p>
<p>39 CSC343</p>
<p>Functional Dependencies</p>
<p>Decomposition and Normal Form</p>
<p>R1 = (R) R2 = (R) R = R1 R2 R</p>
<p>R: ( A a a a c c c B b b b b b b C ) c a d c a d</p>
<p>The decomposition of R in R1 and R2 losses information. The join creates tuples that do not exist in R.</p>
<p>40 CSC343</p>
<p>Functional Dependencies</p>
<p>Decomposition and Normal Form</p>
<p>Now we decompose R in: R1( A a c B ) b b R2 ( A a a c C ) c a d</p>
<p>R = R1 R2 = R: R ( A a a c B b b b C ) c a d</p>
<p>this decomposition is lossless-join. The condition is that after the join we found the same information than before the decomposition.</p>
<p>41 CSC343</p>
<p>Functional Dependencies</p>
<p>Decomposition and Normal Form</p>
<p>Denition A decomposition of R in R1, R2, ..., Rk with regard to a set of FD lossless-join iff for every instance r of the schema R that satises , we have: r= Theorem: If (R1, R2) is decomposition of R and w.r.t. , iff: R1 R1 belongs to</p>
<p>is</p>
<p>(r)</p>
<p>(r). . . </p>
<p>(r)</p>
<p>a set of FD, then (R1, R2) is lossless-join R2 or R2 R2 - R1 R1 - R2</p>
<p>.</p>
<p>42 CSC343</p>
<p>Functional Dependencies</p>
<p>Decomposition and Normal Form</p>
<p>Examples</p>
<p>R (A, B, C) = A 1) R1(A, B), R2(B, C) AB BC = B AB - BC = A BC - AB = C B</p>
<p> The decomposition loses information.</p>
<p>The FD B</p>
<p>A does not exist, nor B</p>
<p>C in</p>
<p>43 CSC343</p>
<p>Functional Dependencies</p>
<p>Decomposition and Normal Form</p>
<p>2) R1(A, B), R3(A, C) AB AC = A AB - AC = B A B is</p>
<p> the decomposition is lossless join.</p>
<p>( ).</p>
<p>44 CSC343</p>
<p>Functional Dependencies</p>
<p>Decomposition and Normal Form</p>
<p>Dependency Preserving Decomposition</p>
<p>Denitions 1. Projection of a set of FD om Z U ( )= Example: R(A,B,C,D), = AB ( ) = AB C, C A</p>
<p>C, C</p>
<p>A, A</p>
<p>D</p>
<p>2. Decomposition which preserves the FDs of Let = (R1,...,Rk) be a decomposition, and a set of FD. preserves the FDs of , if we can nd again every FDs of from the union all FDs projected from in ( ), . . . , ( ): = </p>
<p>of</p>
<p>45 CSC343</p>
<p>Functional Dependencies</p>
<p>Decomposition and Normal Form</p>
<p>Examples</p>
<p>R(A,B,C,D)</p>
<p> = (ABC, = (ABC,R(A,B,C)</p>
<p>= AB</p>
<p>C, C</p>
<p>A, A</p>
<p>D</p>
<p>BD) do not preserve the FDs of AD) preserves the FDs of</p>
<p>= A B, B A, A C = (AB, BC) preserve the FDs of</p>
<p>46 CSC343</p>
<p>Functional Dependencies</p>
<p>D...</p>