Download presentation

Presentation is loading. Please wait.

1
1 CMSC424, Spring 2005 CMSC424: Database Design Lecture 9

2
2 CMSC424, Spring 2005 Relational Database Design Find a “good” collection of relation schemas; otherwise –Repetition of Information. Leads to anomalies –Inability to represent certain information. Use integrity constraints to refine the schema Main refinement technique: Decomposition –E.g. break ABCD into AB and BCD Must be careful with decomposition

3
3 CMSC424, Spring 2005 Decomposition All attributes of an original schema (R) must appear in the decomposition (R 1, R 2 ): R = R 1 R 2 Lossless-join decomposition. For all possible legal relations r on schema R r = R1 (r) R2 (r) How do you define legal ?

4
4 CMSC424, Spring 2005 Examples of Join Decompositions

5
5 CMSC424, Spring 2005 Goal — Devise a Theory for the Following Decide whether a particular relation R is in “good” form. In the case that a relation R is not in “good” form, decompose it into a set of relations {R 1, R 2,..., R n } such that each relation is in good form the decomposition is a lossless-join decomposition Our theory is based on: functional dependencies multivalued dependencies

6
6 CMSC424, Spring 2005 Normal Forms 1st, 2nd, 3rd, 4th Normal Forms Boyce-Codd Normal Form (BCNF)

7
7 CMSC424, Spring 2005 First Normal Form Atomic Domains Sometimes a function of how domain is used, rather than intrinsic properties of the domain A set of values as an attribute not acceptable Non-atomic values complicate storage and encourage redundant (repeated) storage of data We will assume 1st normal form compliance

8
8 CMSC424, Spring 2005 Rest of the normal forms… Need: functional dependencies multi-valued dependencies What are they ? Constraints on the set of legal relations

9
9 CMSC424, Spring 2005 Functional Dependencies Let R be a relation schema R and R The functional dependency holds on R if and only if for any legal relations r (R): t 1 [ ] = t 2 [ ] t 1 [ ] = t 2 [ ] Example: Consider r(A,B) with the following instance of r. On this instance, A B does NOT hold, but B A does hold. Beware: Difference between holding in one instance, and holding in all legal relations 14 1 5 37

10
10 CMSC424, Spring 2005 Functional Dependencies (Cont.) Generalization of the notion of keys K is a superkey for relation schema R if and only if K R K is a candidate key for R if and only if K R, and for no K, R Functional dependencies allow us to express constraints that cannot be expressed using superkeys.

11
11 CMSC424, Spring 2005 Functional Dependencies If a relation r is legal under a set F of functional dependencies, we say that r satisfies F. We say that F holds on R if all legal relations on R satisfy the set of functional dependencies F. What’s the difference between r and R above ?

12
12 CMSC424, Spring 2005 Functional Dependencies (Cont.) A functional dependency is trivial if it is satisfied by all instances of a relation E.g. customer-name, loan-number customer-name customer-name customer-name In general, is trivial if

13
13 CMSC424, Spring 2005 Closure of a Set of Functional Dependencies Given a set F set of functional dependencies, there are certain other functional dependencies that are logically implied by F. E.g. If A B and B C, then we can infer that A C F + (closure of F) Set of all functional dependencies logically implied by F Armstrong’s Axioms: if , then (reflexivity) if , then (augmentation) if , and , then (transitivity) These rules are sound complete

14
14 CMSC424, Spring 2005 Example R = (A, B, C, G, H, I) F = { A B A C CG H CG I B H} some members of F + A H AG I CG HI if , then (reflexivity) if , then (augmentation) if , and , then (transitivity)

15
15 CMSC424, Spring 2005 Procedure for Computing F + To compute the closure of a set of functional dependencies F: F + = F repeat for each functional dependency f in F + apply reflexivity and augmentation rules on f add the resulting functional dependencies to F + for each pair of functional dependencies f 1 and f 2 in F + if f 1 and f 2 can be combined using transitivity then add the resulting functional dependency to F + until F + does not change any further

16
16 CMSC424, Spring 2005 Closure of Functional Dependencies (Cont.) We can further simplify manual computation of F + by using the following additional rules. If holds and holds, then holds (union) If holds, then holds and holds (decomposition) If holds and holds, then holds (pseudotransitivity) The above rules can be inferred from Armstrong’s axioms.

17
17 CMSC424, Spring 2005 Closure of Attribute Sets For an attriute set , + = Closure of under F is the set of attributes that are functionally determined by under F: is in F + + Algorithm to compute + : result := ; while (changes to result) do for each in F do begin if result then result := result end

18
18 CMSC424, Spring 2005 Example of Attribute Set Closure R = (A, B, C, G, H, I) F = {A B A C CG H CG I B H} (AG) + 1.result = AG 2.result = ABCG(A C and A B) 3.result = ABCGH(CG H and CG AGBC) 4.result = ABCGHI(CG I and CG AGBCH) Is AG a candidate key? Is AG a super key? 1.Does AG R? == Is (AG) + R Is any subset of AG a superkey? 1.Does A R? == Is (A) + R 2.Does G R? == Is (G) + R

19
19 CMSC424, Spring 2005 Uses of Attribute Closure There are several uses of the attribute closure algorithm: Testing for superkey: To test if is a superkey, we compute +, and check if + contains all attributes of R. Testing functional dependencies To check if a functional dependency holds (or, in other words, is in F + ), just check if +. That is, we compute + by using attribute closure, and then check if it contains . Is a simple and cheap test, and very useful Computing closure of F For each R, we find the closure +, and for each S +, we output a functional dependency S.

20
20 CMSC424, Spring 2005 Canonical Cover Sets of functional dependencies may have redundant dependencies that can be inferred from the others Eg: A C is redundant in: {A B, B C, A C} Parts of a functional dependency may be redundant E.g. on RHS: {A B, B C, A CD} can be simplified to {A B, B C, A D} E.g. on LHS: {A B, B C, AC D} can be simplified to {A B, B C, A D}

21
21 CMSC424, Spring 2005 Extraneous Attributes Consider a set F of functional dependencies and the functional dependency in F. Attribute A is extraneous in if A and F logically implies (F – { }) {( – A) }. Attribute A is extraneous in if A and the set of functional dependencies (F – { }) { ( – A)} logically implies F. Note: implication in the opposite direction is trivial in each of the cases above, since a “stronger” functional dependency always implies a weaker one

22
22 CMSC424, Spring 2005 Testing if an Attribute is Extraneous Consider a set F of functional dependencies and the functional dependency in F. To test if attribute A is extraneous in compute ({ } – A) + using the dependencies in F check that ({ } – A) + contains A; if it does, A is extraneous To test if attribute A is extraneous in compute + using only the dependencies in F’ = (F – { }) { ( – A)}, check that + contains A; if it does, A is extraneous

23
23 CMSC424, Spring 2005 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. To compute a canonical cover for F: repeat Use the union rule to replace any dependencies in F 1 1 and 1 2 with 1 1 2 Find a functional dependency with an extraneous attribute either in or in If an extraneous attribute is found, delete it from until F does not change Note: Union rule may become applicable after some extraneous attributes have been deleted, so it has to be re-applied

24
24 CMSC424, Spring 2005 Example of Computing a Canonical Cover R = (A, B, C) F = {A BC B C A B AB C} Combine A BC and A B into A BC Set is now {A BC, B C, AB C} A is extraneous in AB C Check if the result of deleting A from AB C is implied by the other dependencies Yes: in fact, B C is already present! Set is now {A BC, B C} C is extraneous in A BC Check if A C is logically implied by A B and the other dependencies Yes: using transitivity on A B and B C. –Can use attribute closure of A in more complex cases The canonical cover is: A B B C

25
25 CMSC424, Spring 2005 Normalization Using Functional Dependencies When we decompose a relation schema R with a set of functional dependencies F into R 1, R 2,.., R n we want Lossless-join decomposition No redundancy Dependency preservation

26
26 CMSC424, Spring 2005 Example R = (A, B, C) F = {A B, B C) Can be decomposed in two different ways R 1 = (A, B), R 2 = (B, C) Lossless-join decomposition: R 1 R 2 = {B} and B BC Dependency preserving R 1 = (A, B), R 2 = (A, C) Lossless-join decomposition: R 1 R 2 = {A} and A AB Not dependency preserving (cannot check B C without computing R 1 R 2 )

Similar presentations

© 2021 SlidePlayer.com Inc.

All rights reserved.

To make this website work, we log user data and share it with processors. To use this website, you must agree to our Privacy Policy, including cookie policy.

Ads by Google