Review: Keys. What is a Functional Dependency? Why use Functional Dependencies? Functional Dependency Properties

Transcription

1 Review: Keys Superkey: set of attributes whose values are unique for each tuple Note: a superkey isn t necessarily minimal. For example, for any relation, the entire set of attributes is always a superkey. A key should distinguish all possible tuples, not just the ones in a particular instance. Candidate key: a superkey in which every attribute is needed. Removing an attribute would destroy its key status. Note: A schema s candidate keys don t have to be all the same size. Example: Person could have {Soc_sec_num} and {first_name, middle_name, last_name} might be two candidate_keys. Primary key: candidate key the designer has chosen as THE key Note: Primary keys have to do with an actual implementation. Relational algebra and functional dependency theory do not distinguish between candidate keys and the primary key. What is a Functional Dependency? Definition A set of attributes B is functional dependent on another set of attributes A iff Each possible value of A associates with exactly one value of B Analogous to a function on variables B = f(a) Terminology and Notation Written A B Pronounced A determines B or B depends on A A is called the determinant set B is called the dependent set 1 2 Why use Functional Dependencies? Functional Dependencies (FD) will help us Express the logical, relational constraints between attributes (entity or relationship key descriptive attributes) Identify candidate keys Reduce data redundancy and anomalies by Testing for Normalization Telling us how to decompose a relation to achieve a higher level of normalization Data anomaly An logical inconsistency (FD violation), introduced by adding, changing, or deleting a tuple Most or all anomalies can be eliminated if we normalize a schema Functional Dependency Properties Notation: α, β, and γ are sets of attributes. The concatenation αβ means the union of the two sets. Armstrong s Axioms: If β α, then α β (reflexivity) If α β, then γ α γ β (augmentation) If α β and β γ, then α γ (transitivity) Useful Derived Properties If α β and α γ, then α β γ (union) If α β γ, then α β and α γ (decomposition) If α β and γ β δ, then α γ δ (pseudotransitivity) 3 4

2 Applying Armstrong s Axioms R = (A, B, C, G, H, I) F = { A B A C CG H CG I B H } Some members of F + A H by transitivity from A B and B H AG I by augmenting A C with G, to get AG CG and then transitivity with CG I CG HI by augmenting CG I to infer CG CGI, and augmenting of CG H to infer CGI HI, and then transitivity Normal Form Definitions Form 1NF 2NF 3NF BCNF Definition Prime attribute = an attribute in a candidate key α β is trivial if β α. Alternate Definition Attributes are single-valued, and a candidate key exists 1NF, and all non-prime attributes depend fully on every candidate key For all non-trivial FDs α β, α is a superkey, or every A in β α is a prime attribute For all non-trivial FDs α β, α is a superkey 1NF, and has no partial FDs 2NF, and has no transitive FDs Given α β, β is partially dependent on α if γ B where γ α. β is fully dependent if there is not such subset. If α β and β γ, then α transitively depends on γ 5 6 Redundancy in Non-Normalized Schemas Closure of Functional Dependency Sets Relation in 1NF but not 2NF: student, grade room Anomaly: What if we update the room in tuple 1? Relation in 2NF but not 3NF: room room room_capacity Anomaly: What if we update the room_capacity in tuple 1? 7 student Jack Jill Jack Jill CS100 CS250 CS350 CS400 CS100 CS100 CS250 CS250 room room grade B+ A- A B room_capacity When we say, for all FDs, what do we mean by all? Start with a set F of FDs Apply Armstrong s axioms to compute all implied FDs Reflexivity Augmentation Transitivity The set of all logically implied FDs is F +, the closure of F. So, to perform Normalization, we need to know the closure of a relation s functional dependencies Given a sufficient initial set F, Armstrong s axioms can find F+. What s the flaw? Guideline: every attribute must participate in an FD! 8

3 Closure of Attribute Sets Example of Attribute Set Closure Given a set of attributes α, the closure of α under F (denoted by α + ) is the set of attributes that are functionally determined by α under F Q: What s the difference between attribute closure and FD closure? Algorithm to compute α +, the closure of α under F α + := α; while (changes to α + ) do for each β γ in F do begin if β α + then α + := α + γ end R = (A, B, C, G, H, I) F = { A B A C CG H CG I B H } (AG) + 1. result = AG 2. (A C and A B) result = ABCG 3. (CG H and CG AGBC) result = ABCGH 4. (CG I and CG AGBCH) result = ABCGHI Is AG a candidate key? 1. Is AG a super key? Does AG R? == Is (AG) + R 2. Is any subset of AG a superkey? Does A R? == Is (A) + R Does G R? == Is (G) + R 9 10 Uses of Attribute Closure Extraneous Attributes Testing for superkey If α + contains all attributes of R, then α is a superkey An extraneous attribute is one that can be deleted from either left or right side of a FD, without reducing F + Testing functional dependencies If β α +, then α β holds Computing closure of F For each attribute γ R, find the closure γ + Then, for each S γ +, there is a functional dependency γ S Example: Given F = {A C, AB CD} C is extraneous in AB CD since AB C can be inferred even after deleting C Extraneous attributes can be removed by applying Armstrong s axioms 11 12

4 Canonical Cover Formally: A canonical cover for F is a set of dependencies F c such that F logically implies all dependencies in F c, and F c logically implies all dependencies in F, and No FD in F c contains an extraneous attribute, and Each left side of functional dependency in F c is unique Informally, it is a minimal version of F Canonical Cover A canonical cover for F is a set of dependencies F c such that F logically implies all dependencies in F c, and F c logically implies all dependencies in F, and No functional dependency in F c contains an extraneous attribute, and Each left side of functional dependency in F c is unique In some (vague) sense, it is a minimal version of F 13 Read up algorithms to compute F c 14 Using Decomposition for Normalization A Good Decomposition After finding F +, identify violating FDs: Partial dependencies: p X, p some candidate key C Transitive dependencies / non-key determinants: t X, t Observation Problem: We are trying to describe more than one kind of entity or relationship in one relation (p, t, and C all represent entities or relationships) Solution: Split up (decompose) the relation into individual entities and relations A good decomposition: reduces data redundancy and anomalies is lossless Is dependency-preserving Higher normal forms are stricter and therefore permit fewer data redundancies and anomalies: 1NF Lossless is concerned with preserving information. This seems like a non-negotiable requirement. Dependency-preserving is concerned with computational efficiency. In practice, most designs aim for 3NF, BCNF, or 4NF

5 Lossless Decomposition Informally: We don t want to lose any information when we decompose a relation A decomposition is lossless-join if joining the decomposed relations restores all tuples from the original relation A decomposition is lossless if joining the decomposed relations restores the original relation exactly Q: Which one preserves more information? All information? Formally: Lossless-join: R2 = R1 R2 Dependency Preservation Informally: A decomposition is dependency-preserving if checking the FDs of decomposed relations separately is as good as checking the FDs of the original relation That is, we don t need to join any relations to check any FDs (this is good because joins are computationally expensive) Formally: Let F i be the set of dependencies F + that include only attributes in R i. A decomposition is dependency preserving, if (F 1 F 2 F n ) + = F Comparison of BCNF and 3NF For any 1NF relation, there is always a 3NF decomposition that is lossless dependency-preserving there is always a BCNF decomposition that is lossless Possible trade-off: BCNF (fewer data redundancies and anomalies)? or Dependencies preserved (more efficient integrity checking)? Achieving Lossless BCNF Heath s Theorem Given a relation R (A, B, C) where A, B, and C are any sets of attributes R 1 (A, B), R 2 (A, C) is a lossless decomposition of R iff A B or A C Algorithm to achieve BCNF: Compute F + for all relations R i ; while (not in BCNF) choose an FD A B on R i where A is not a superkey Use A B and Heath s Theorem to decompose R i into R i1, R i2 Replace R i with R i1, R i2 end 19 20

6 Decomposition Example Bor_loan = (customer_id, loan_number, amount) candidate key: FD1: (customer_id, loan_number) loan_number amount loan_number is a not a superkey, so the schema is not in BCNF Using Heath s theorem: A = loan_number B = amount C = customer_id (customer_id, loan_number, amount) (loan_number, amount) (customer_id, loan_number) A B A C BCNF and Dependency Preservation A BCNF decomposition that is not dependency-preserving R = (J, K, L ) F = {JK L L K } Two candidate keys = JK and JL R is in 3NF but not in BCNF Any decomposition of R will fail to preserve JK L This implies that testing for JK L requires a join Redundancy in 3NF There is some redundancy in this schema Example of problems due to redundancy in 3NF R = (J, K, L) F = {JK L, L K } J j 1 j 2 j 3 null repetition of information (e.g., the relationship l 1, k 1 ) need to use null values (e.g., to represent the relationship l 2, k 2 where there is no corresponding value for J). L l 1 l 1 l 1 l 2 K k 1 k 1 k 1 k 2 Testing for Dependency Preservation To check if a dependency α β is preserved in a decomposition of R into R 1, R 2,, R n we apply the following test (with attribute closure done with respect to F) result = α while (changes to result) do for each R i in the decomposition t = (result R i ) + R i result = result t If result contains all attributes in β, then the functional dependency α β is preserved. We apply the test on all dependencies in F to check if a decomposition is dependency preserving This procedure takes polynomial time, instead of the exponential time required to compute F + and (F 1 F 2 F n )

7 Example of BCNF Decomposition How good is BCNF? Original relation R and functional dependency F R = (br_name, br_city, assets, cust_name, loan_num, amount ) F = { br_name br_city, assets loan_num amount, br_name } Key = {loan_num, cust_name} Decompose R into R 1 and R 2 R 1 = (br_name, br_city, assets ) R 2 = (br_name, cust_name, loan_num, amount ) R Consider a classes (, teacher, book ) such that (c, t, b) classes means that t is qualified to teach c, and b is a required textbook for c Decompose R 2 into R 3 and R 4 R 3 = (br_name, loan_num, amount ) R 4 = (cust_name, loan_num ) Final decomposition R 1, R 3, R 4 R1 R3 R2 R4 The is supposed to list for each the set of teachers any one of which can be the s instructor, and the set of books, all of which are required for the (no matter who teaches it). Q: What is the key? What are the FDs? How good is BCNF? (Cont.) classes teacher book Hank Hank Sudarshan Sudarshan Pete Pete OS Concepts Stallings OS Concepts Stallings There are no non-trivial functional dependencies; therefore, the relation is in BCNF Insertion anomalies i.e., if Marilyn is a new teacher that can teach, two tuples need to be inserted: (, Marilyn, ) (, Marilyn, ) How good is BCNF? (Cont.) Therefore, it is better to decompose classes into: teaches text teacher Hank Sudarshan Jim book OS Concepts Shaw This suggests the need for higher normal forms, such as Fourth Normal Form (4NF), which we shall see later