Download presentation
Presentation is loading. Please wait.
1
Chapter 7: Relational Database Design
2
©Silberschatz, Korth and Sudarshan7.2 Chapter 7: Relational Database Design First Normal Form Goals of Relational Database Design Functional Dependencies Decomposition Boyce-Codd Normal Form Third Normal Form Multivalued Dependencies and Fourth Normal Form Overall Database Design Process
3
©Silberschatz, Korth and Sudarshan7.3 First Normal Form A domain is atomic if its elements are treated as indivisible units. Examples of atomic domains: Number of pets Gender Examples of non-atomic domains: Person names List of dependent first names Identification numbers like CS101 that can be broken into parts A relational schema R is in first normal form if the domains of all attributes of R are atomic (or rather, are treated atomically).
4
©Silberschatz, Korth and Sudarshan7.4 First Normal Form (Cont.) Atomicity is a property of how elements of the domain are used. Strings would normally be considered indivisible. Suppose that students are given roll numbers which are strings of the form CS0012 or EE1127. If the first two characters are extracted to find the department, the domain of roll numbers is not atomic. Accessing individual components of an individual attribute is a bad idea because it leads to encoding of information in application programs rather than in the database. Non-atomic values can also complicate storage and encourage redundant (repeated) storage of data. Set of accounts stored with each customer, and set of owners stored with each account. We assume all relations are in first normal form (revisit this in Chapter 9 on Object Relational Databases).
5
©Silberschatz, Korth and Sudarshan7.5 Goals of Relational Database Design Design Goals: Avoid redundant data – generally considered enemy #1. Ensure that relationships among attributes are represented. Facilitate the checking of updates for violation of database integrity constraints. We will formalize these goals in several steps.
6
©Silberschatz, Korth and Sudarshan7.6 The Database Design Process At a high-level, the database design process is driven by the level of normalization of a relational scheme. If relational scheme R is not sufficiently normalized, decompose it into a set of relational schemes {R 1, R 2,..., R n } such that: Each relational scheme is sufficiently normalized. The decomposition has a lossless-join. All functional dependencies are preserved. So what are normalization, lossless-join, functional dependencies, and what does preserving them mean?
7
©Silberschatz, Korth and Sudarshan7.7 Example Consider the relation schema: Note the redundancy - branch-name, branch-city, and assets are repeated for each loan and borrower. Wastes space. Creates Update, deletion, and insertion anomalies.
8
©Silberschatz, Korth and Sudarshan7.8 Update, Insertion and Deletion Anomalies Update Anomalies: Modify the asset value for the branch of loan L-17. Insertion Anomalies: Cannot store information about a branch if no loans exist without using null values. This is particularly bad since loan-number is part of the primary key. Subsequent insertion of a loan for that same branch would require the first tuple to be deleted. Deletion Anomalies: Deleting L-17 and L-14 might result in all Downtown branch information being deleted.
9
©Silberschatz, Korth and Sudarshan7.9 Decomposition Solution - decompose Lending-schema into: Branch-schema = (branch-name, branch-city,assets) Loan-info-schema = (customer-name, loan-number, branch-name, amount) For any decomposition: All attributes of an original schema (R) must appear in the decomposition (R 1, R 2 ): R = R 1 R 2 The decomposition must have a lossless-join, i.e., for all possible relations r on schema R r = R1 (r) R2 (r)
10
©Silberschatz, Korth and Sudarshan7.10 Example of Non-Lossless-Join Decomposition Decomposition of R = (A, B) R 2 = (A)R 2 = (B) AB 121121 A B 1212 r A(r)A(r) B(r)B(r) A (r) B (r) AB 12121212
11
©Silberschatz, Korth and Sudarshan7.11 Functional Dependencies Informally, a Functional Dependency (FD) is a constraint on the contents of a relation. An FD specifies that the values for a set of attributes determines uniquely the values for another set of attributes. The notion of a functional dependency is a generalization of the notion of a key (super, candidate, primary or unique). In fact, in a good design, every functional dependency in a database is realized as a key.
12
©Silberschatz, Korth and Sudarshan7.12 Functional Dependencies – Example #1 Consider the following schema: Loan-info-schema = (customer-name, loan-number, branch-name, amount) Applicable FDs: loan-number amount loan-number branch-name Non-applicable FDs: loan-number customer-name
13
©Silberschatz, Korth and Sudarshan7.13 Functional Dependencies – Example #2 Consider the following schema: Grade-schema = (student-id, name, course-id, grade) Applicable FDs: student-id name student-id, course-id grade Non-applicable FDs: student-id grade grade course-id
14
©Silberschatz, Korth and Sudarshan7.14 Functional Dependency - Formal Definition Let R be a relation schema where: R and R The functional dependency holds on R if and only if for any legal relations r(R), whenever any two tuples t 1 and t 2 of r agree on the attributes , they also agree on the attributes . That is, t 1 [ ] = t 2 [ ] t 1 [ ] = t 2 [ ] Alternatively, if then the relation r can never contain two tuples that agree on and disagree on .
15
©Silberschatz, Korth and Sudarshan7.15 Example – FD Formal Definition Consider r(A,B) with the following instance of r. On this instance, A B does NOT hold, but B A does hold. 14 1 5 37
16
©Silberschatz, Korth and Sudarshan7.16 Use of Functional Dependencies We use functional dependencies to: Impose FDs as design constraints on a relational scheme. We say that F holds on R if all legal relations on R satisfy the set of functional dependencies F. Test relations to see if they are legal under a given set of functional dependencies. If a relation r is legal under a set F of functional dependencies, we say that r satisfies F. Note that the difference between the two is important! If a set F holds on a relation R, then every relation (i.e., a set of tuples) must satisfy F. If a relation (i.e., a set of tuples) satisfies F, it may or may not be the case that F holds on R.
17
©Silberschatz, Korth and Sudarshan7.17 FDs – Holding vs. Satisfying Stated another way, a specific instance of a relation schema may satisfy a functional dependency even if the functional dependency does not hold on all legal instances. Example #1: A specific instance of Loan-schema may, by chance, satisfy: loan-number customer-name. Example #2: A specific instance of Grade-schema may, by chance, satisfy: grade course-id Example #3: Suppose an instance of Loan-schema (or Grade- schema) is empty. What FDs does it satisfy?
18
©Silberschatz, Korth and Sudarshan7.18 Defining Keys in Terms of FDs 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
19
©Silberschatz, Korth and Sudarshan7.19 Functional Dependencies (Cont.) A functional dependency is trivial if it is satisfied by all instances of a relation. Examples: customer-name, loan-number customer-name customer-name customer-name In general, is trivial if and only if
20
©Silberschatz, Korth and Sudarshan7.20 Closure of a Set of FDs Given a set F set of functional dependencies, there are other functional dependencies that are logically implied by F. For example, if A B and B C, then we can infer that A C ID# Date-of-Birth Date-of-Birth Zodiac-Sign ∴ ID# Zodiac-Sign The set of all functional dependencies logically implied by F is the closure of F. We denote the closure of F by F +.
21
©Silberschatz, Korth and Sudarshan7.21 Armstrong’s Axioms We can find all of F + by applying Armstrong’s Axioms: if , then (reflexivity) if , then (augmentation) if , and , then (transitivity) Armstrong’s axioms are both sound and complete: Sound - generate only functional dependencies that actually hold. Complete - generate all functional dependencies that hold. Minimal – no proper subset of the Axioms is complete.
22
©Silberschatz, Korth and Sudarshan7.22 Closure Example R = (A, B, C, G, H, I) F = { A B A C CG H CG I B H} Some members of F + A HTransitivity from A B and B H AG IAugmentation of A C with G, to get AG CG and then transitivity with CG I CG HIAugmentation of CG I to get CG CGI, augmentation of CG H to get CGI HI, and then transitivity
23
©Silberschatz, Korth and Sudarshan7.23 Procedure for Computing F + To compute the closure of a set of functional dependencies F (from the book): 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 NOTE: We will see an alternative procedure for this task later. Worst case time is exponential! Consider F = {A B1, A B2,…,A Bn}
24
©Silberschatz, Korth and Sudarshan7.24 Additional FD Rules The following additional rules will occasionally be helpful: 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/proven from Armstrong’s axioms.
25
©Silberschatz, Korth and Sudarshan7.25 Equivalent Sets of FDs Let F 1 and F 2 be two sets of functional dependencies. F 1 and F 2 are said to be equal, denoted F 1 = F 2, if: F 1 ⊆ F 2 and F 2 ⊆ F 1 F 2 is said to imply F 1 if F 1 ⊆ F 2 + F 1 and F 2 are said to be equivalent, denoted F 1 ≈ F 2, if F 1 implies F 2 and F 2 implies F 1, i.e., F 2 ⊆ F 1 + F 1 ⊆ F 2 +
26
©Silberschatz, Korth and Sudarshan7.26 Closure of Attribute Sets Given a set of attributes define the closure of under F (denoted by + ) as the set of attributes that are functionally determined by under F. Algorithm to compute +, the closure of under F result := ; while (changes to result) do for each in F do begin if result then result := result end
27
©Silberschatz, Korth and Sudarshan7.27 Example of Attribute Set Closure R = (A, B, C, G, H, I) F = {A B, A C, CG H, CG I, B H} (AG) + result = AG result = ABG(A B) result = ABCG(A C) result = ABCGH(CG H) result = ABCGHI(CG I) Is AG a candidate key? 1. Is AG a super key? Does AG R, i.e., is R ⊆ (AG) + 2. Is any subset of AG a super key? Does A R, i.e., is R ⊆ (A) + Does G R, i.e., is R ⊆ (G) +
28
©Silberschatz, Korth and Sudarshan7.28 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 . Computing closure of a set F of functional dependencies: For each R, we find the closure +, and for each S +, we output a functional dependency S.
29
©Silberschatz, Korth and Sudarshan7.29 Canonical Cover Sets of functional dependencies may have redundant dependencies that can be inferred from the others Example: A C is redundant in: {A B, B C, A C} Parts of a functional dependency may be redundant {A B, B C, A CD} can be simplified to {A B, B C, A D} {A B, B C, AC D} can be simplified to {A B, B C, A D} Intuitively, a canonical cover for F is a “minimal” set of functional dependencies equivalent to F, having no redundant dependencies or redundant parts of dependencies
30
©Silberschatz, Korth and Sudarshan7.30 Extraneous Attributes Let F be a set of FDs and suppose that is 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 above cases.
31
©Silberschatz, Korth and Sudarshan7.31 Examples of Extraneous Attributes Example #1: Given F = {A C, AB C } B is extraneous in AB C because {A C, AB C} logically implies A C. Example #2: Given F = {A C, AB CD} C is extraneous in AB CD since {A C, AB D} logically implies AB CD.
32
©Silberschatz, Korth and Sudarshan7.32 Testing if an Attribute is Extraneous Let F be a set of FDs and let be in F. To test if attribute A is extraneous in 1. compute ({ } – A) + using the dependencies in F 2. check that ({ } – A) + contains ; if it does, A is extraneous To test if attribute A is extraneous in 1. compute + using only the dependencies in F’ = (F – { }) { ( – A)}, 2. check that + contains ; if it does, A is extraneous
33
©Silberschatz, Korth and Sudarshan7.33 Canonical Cover – Formal Definition A canonical cover for F is a set of dependencies F c such that: F ≈ FcF ≈ Fc F logically implies all dependencies in F c, and F c logically implies all dependencies in F. No functional dependency in F c contains an extraneous attribute. Each left side of a functional dependency in F c is unique.
34
©Silberschatz, Korth and Sudarshan7.34 Computing a Canonical Cover 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.
35
©Silberschatz, Korth and Sudarshan7.35 Example of Computing a Canonical Cover R = (A, B, C) F = {A BC B C A B AB C} Combining A BC and A B gives {A BC, B C, AB C} A is extraneous in AB C gives {A BC, B C} C is extraneous in A BC gives {A B, B C}
36
©Silberschatz, Korth and Sudarshan7.36 Review – The Goals of Normalization Recall: Given a particular relational scheme R and an associated set of function dependencies F, first determine whether or not R is in “good” form, i.e., is it sufficiently normalized. If relation R is not sufficiently normalized, decompose it into a set of relations {R 1, R 2,..., R n } such that Each relation is sufficiently normalized The decomposition is a lossless-join decomposition All dependencies are preserved All of the above requirements will be based on: functional dependencies multivalued dependencies
37
©Silberschatz, Korth and Sudarshan7.37 Decomposition Previously, we decomposed the Lending-schema into: Branch-schema = (branch-name, branch-city,assets) Loan-info-schema = (customer-name, loan-number, branch-name, amount) In addition to not losing any attributes, the decomposition must have a lossless-join, i.e., for all possible relations r on R: r = R1 (r) R2 (r) Having defined FDs, we can now define the conditions under which a decomposition has a loss-less join: A decomposition of R into R 1 and R 2 has a lossless join if and only if at least one of the following dependencies is in F + : R 1 R 2 R 1 R 1 R 2 R 2
38
©Silberschatz, Korth and Sudarshan7.38 Example R = (A, B, C) F = {A B, B C) Can be decomposed in three different ways. R 1 = (A, B), R 2 = (B, C) Has a lossless-join: R 1 R 2 = {B} and B BC R 1 = (A, B), R 2 = (A, C) Has a lossless-join: R 1 R 2 = {A} and A AB R 1 = (A, C), R 2 = (B, C) Does not have a lossless-join.
39
©Silberschatz, Korth and Sudarshan7.39 Preservation of Functional Dependencies Suppose that: R is a relational scheme F is an associated set of functional dependencies {R 1, R 2,..., R n } is a decomposition of R F i is the set of dependencies F + that include only attributes in R i. The decomposition {R 1, R 2,..., R n } is said to be dependency preserving if (F 1 F 2 … F n ) + = F + Why is it important for a decomposition to preserve dependencies? Otherwise, checking updates for violation of functional dependencies may require computing joins, which is expensive.
40
©Silberschatz, Korth and Sudarshan7.40 Example R = (A, B, C) F = {A B, B C) Can be decomposed in three different ways. R 1 = (A, B), R 2 = (B, C) Lossless-join decomposition (as noted previously) Dependency preserving R 1 = (A, B), R 2 = (A, C) Lossless-join decomposition (as noted previously) Not dependency preserving (cannot check B C without computing R 1 R 2 ) R 1 = (A, C), R 2 = (B, C) Does not have a lossless-join (as noted previously) Not dependency preserving (cannot check A B without computing R 1 R 2 )
41
©Silberschatz, Korth and Sudarshan7.41 Example Note that we haven’t seen an example where the decomposition: Preserves dependencies Does not have a loss-less join. Exercise: Show a relational schema R, associated set of functional dependencies F, and a decomposition of R that preserves dependencies but does not have a loss-less join.
42
©Silberschatz, Korth and Sudarshan7.42 Testing for Dependency Preservation To check if a dependency from F is preserved in a decomposition of R into R 1, R 2, …, R n we apply the following simplified 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 is preserved. The test is applied to all dependencies in F. This procedure takes polynomial time, instead of the exponential time required to compute F + and (F 1 F 2 … F n ) +
43
©Silberschatz, Korth and Sudarshan7.43 Boyce-Codd Normal Form is trivial (i.e., ) is a superkey for R A relational scheme R is in BCNF with respect to a set F of functional dependencies if for all functional dependencies in F + of the form , where R and R, at least one of the following holds:
44
©Silberschatz, Korth and Sudarshan7.44 Testing for BCNF To determine if a relational scheme is in BCNF: Calculate F + For each non-trivial functional dependency in F + 1. compute + (the attribute closure of ) 2. verify that + includes all attributes of R, i.e., that it is a superkey for R => If a functional dependency in F + is identified that (1) is non-trivial and (2) where is not a superkey, then R is not in BCNF.
45
©Silberschatz, Korth and Sudarshan7.45 Example R = (A, B, C) F = {A B, B C} Candidate Key = {A} R is not in BCNF (why not?) Decomposition R 1 = (A, B), R 2 = (B, C) R 1 is in BCNF R 2 is in BCNF The decomposition has a lossless-join (how do we know?) The decomposition preserves dependencies (how do we know?)
46
©Silberschatz, Korth and Sudarshan7.46 Testing for BCNF Simplified test: It suffices to check only the dependencies in F for violation of BCNF, rather than all dependencies in F +. However, using only F is incorrect when testing a relation in a decomposition of R. For example, consider R (A, B, C, D), with F = {A B, B C} Decompose R into R 1 (A,B) and R 2 (A,C,D) Neither of the dependencies in F contain only attributes from (A,C,D) so we might be mislead into thinking R 2 satisfies BCNF. In fact, dependency A C in F + shows R 2 is not in BCNF.
47
©Silberschatz, Korth and Sudarshan7.47 BCNF Decomposition Algorithm Let R be a relational scheme, let F be an associated set of functional dependencies, and suppose that R is not in BCNF. result := {R}; done := false; compute F + ; while (not done) do if (there is a schema R i in result that is not in BCNF) then begin let be a nontrivial functional dependency that holds on R i such that R i is not in F +, and = ; result := (result – R i ) (R i – ) ( , ); end else done := true; Note that each resulting R i is in BCNF, and the decomposition will have a lossless-join.
48
©Silberschatz, Korth and Sudarshan7.48 Example of BCNF Decomposition Decomposition R 1 = (branch-name, branch-city, assets) R 2 = (branch-name, customer-name, loan-number, amount) R 3 = (branch-name, loan-number, amount) R 4 = (customer-name, loan-number) Final decomposition R 1, R 3, R 4 Consider the following Relational Scheme: R = (branch-name, branch-city, assets, customer-name, loan-number, amount) F = {branch-name assets, branch-city loan-number amount, branch-name} Candidate Key = {loan-number, customer-name} Note that R is not in BCNF (why?)
49
©Silberschatz, Korth and Sudarshan7.49 Keys Created by the BCNF Algorithm Ideally, each R i represents one functional dependency, where the LHS will be the primary key. For example, the following is in BCNF: R = (A,B,C) F = {A C, B C, A B, B A} Two Candidate Keys = {A} {B} Primary Key - A Secondary (unique) Key - B
50
©Silberschatz, Korth and Sudarshan7.50 Testing Relations in a Decomposition for BCNF To check if a relation R i in a decomposition of R is in BCNF, Either test R i for BCNF with respect to the restriction of F to R i (that is, all FDs in F + that contain only attributes from R i ) Or use the original set of dependencies F that hold on R, but with the following test: For every set of attributes R i, check that + (the attribute closure of ) either includes no attribute of R i - , or includes all attributes of R i (i.e., is a superkey). If the condition is violated by some in F, the dependency ( + - ) R i can be shown to hold on R i, and R i violates BCNF. We use above dependency to decompose R i
51
©Silberschatz, Korth and Sudarshan7.51 BCNF and Dependency Preservation R = (J, K, L) F = {JK L, L K} Two candidate keys = JK and JL Equivalent to the following from the banking enterprise: Banker-schema = (branch-name, customer-name, banker-name) banker-name branch name customer-name, branch name banker-name R is not in BCNF (why?) Any decomposition of R will fail to preserve JK L (why?) It is not always possible to get a BCNF decomposition that is dependency preserving:
52
©Silberschatz, Korth and Sudarshan7.52 Third Normal Form Motivation As shown on the previous slide, there exist relational schemes for which there is no BCNF decomposition that preserves dependencies. Thus, no algorithm for decomposing a relational scheme can guarantee both. Efficient checking for FD violation on updates is still typically necessary, so what do we do?
53
©Silberschatz, Korth and Sudarshan7.53 Third Normal Form Motivation, Cont. Solution: Define a weaker normal form, called Third Normal Form. Allows some redundancy (with resultant problems; as we shall see) Given any relational scheme, there is always a lossless-join, dependency-preserving decomposition into 3NF relational schemes. This is why 3NF is industry standard.
54
©Silberschatz, Korth and Sudarshan7.54 Third Normal Form A relation schema R is in third normal form (3NF) with respect to a set F of functional dependencies if, for all functional dependencies in F + of the form , where R and R, at least one of the following holds: is trivial (i.e., ) is a superkey for R Each attribute A in – is contained in a candidate key for R. If a relation is in BCNF it is in 3NF (why?) The third condition is a minimal relaxation of BCNF that will ensure dependency preservation. For the last condition, each attribute may be in a different candidate key.
55
©Silberschatz, Korth and Sudarshan7.55 3NF (Cont.) Recall the previous relational scheme, which was not in BNCF: R = (J, K, L) F = {JK L, L K} Two candidate keys: JK and JL Although R is not in BCNF, it is in 3NF: JK LJK is a superkey L KK is contained in a candidate key Later we will show that there is some redundancy in this schema.
56
©Silberschatz, Korth and Sudarshan7.56 Testing for 3NF Note that we only need to check FDs in F, rather than all FDs in F +. Use attribute closure to check for each non-trivial dependency , if is a superkey. If is not a superkey, we have to verify if each attribute in is contained in a candidate key of R. Expensive - requires finding all candidate keys. Testing for 3NF has been shown to be NP-hard, i.e., likely requires exponential time. Interestingly, decomposition into third normal form (described shortly) can be done in polynomial time.
57
©Silberschatz, Korth and Sudarshan7.57 3NF Decomposition Algorithm Let F c be a canonical cover for F; i := 0; for (each functional dependency in F c ) loop if (none of the schemas R j, 1 j i contains and ) then begin i := i + 1; R i := ( , ); end; end loop; if (none of the schemas R j, 1 j i contains a candidate key for R) then begin i := i + 1; R i := any candidate key for R; end ; return (R 1, R 2,..., R i ); Each resulting R i is in 3NF, the decomposition has a lossless-join, and all dependencies are preserved. As with the BCNF decomposition algorithm, each R i represents one or more functional dependencies, one of which will be enforced by a primary key; the rest must be enforced manually (doesn’t happen often).
58
©Silberschatz, Korth and Sudarshan7.58 Example Relation schema R: Banker-schema = (branch-name, customer-name,banker-name, office-number) Functional dependencies F: banker-name branch-name, office-number customer-name, branch-name banker-name Candidate keys: {customer-name, branch-name} {customer-name, banker-name} R is not in 3NF (why?)
59
©Silberschatz, Korth and Sudarshan7.59 Applying 3NF to Banker-info-schema The algorithm creates the following schemas: Banker-office-schema = (banker-name, branch-name, office-number) Banker-schema = (customer-name, branch-name, banker-name)
60
©Silberschatz, Korth and Sudarshan7.60 Summary: Comparison of BCNF and 3NF It is always possible to decompose a relational scheme into a set of relational schemes such that: All resulting relational schemes are in 3NF The decomposition has a lossless join All dependencies are preserved It is always possible to decompose a relational scheme into a set of relational schemes such that: All resulting relational schemes are in BCNF The decomposition has a lossless join => The decomposition, however, is not guaranteed to preserve dependencies.
61
©Silberschatz, Korth and Sudarshan7.61 Summary: Comparison of BCNF and 3NF, Cont. J j 1 j 2 j 3 null L l1l1l1l2l1l1l1l2 K k1k1k1k2k1k1k1k2 A schema that is in 3NF but not in BCNF has standard problems: Repetition of information, e.g., the relationship l 1, k 1 Update, insertion and deletion anomalies, e.g., need to use null values to represent the relationship l 2, k 2 where there is no corresponding value for J. Redundancy in 3NF: R = (J, K, L) F = {JK L, L K}
62
©Silberschatz, Korth and Sudarshan7.62 Design Goals Goal for a relational database design is: BCNF Lossless join Dependency preservation If we cannot achieve this, we accept one of Lack of dependency preservation Redundancy due to use of 3NF Note that if a relational scheme is in 3NF but not in BCNF, that relational scheme must have multiple distinct overlapping candidate keys. If a relational scheme does not have multiple distinct overlapping candidate keys, and if it is in 3NF, then it must also be in BCNF.
63
©Silberschatz, Korth and Sudarshan7.63 Design Goals Interestingly, SQL does not provide a direct way of specifying functional dependencies other than superkeys. FDs can be specified using assertions but they are expensive to test. Similarly FDs can be checked in program code, but that is also not desirable. Even if we had a dependency preserving decomposition, using SQL we would not be able to efficiently test a functional dependency whose left hand side is not a key.
64
End of Chapter
65
©Silberschatz, Korth and Sudarshan7.65 Testing for FDs Across Relations If decomposition is not dependency preserving, we can have an extra materialized view for each dependency in F c that is not preserved in the decomposition The materialized view is defined as a projection on of the join of the relations in the decomposition Many newer database systems support materialized views and database system maintains the view when the relations are updated. No extra coding effort for programmer. The functional dependency is expressed by declaring as a candidate key on the materialized view. Checking for candidate key cheaper than checking BUT: Space overhead: for storing the materialized view Time overhead: Need to keep materialized view up to date when relations are updated Database system may not support key declarations on materialized views
66
©Silberschatz, Korth and Sudarshan7.66 Multivalued Dependencies There are database schemas in BCNF that do not seem to be sufficiently normalized Consider a database classes(course, teacher, book) such that (c,t,b) classes means that t is qualified to teach c, and b is a required textbook for c The database is supposed to list for each course the set of teachers any one of which can be the course’s instructor, and the set of books, all of which are required for the course (no matter who teaches it).
67
©Silberschatz, Korth and Sudarshan7.67 There are no non-trivial functional dependencies and therefore the relation is in BCNF Insertion anomalies – i.e., if Sara is a new teacher that can teach database, two tuples need to be inserted (database, Sara, DB Concepts) (database, Sara, Ullman) courseteacherbook database operating systems Avi Hank Sudarshan Avi Jim DB Concepts Ullman DB Concepts Ullman DB Concepts Ullman OS Concepts Shaw OS Concepts Shaw classes Multivalued Dependencies (Cont.)
68
©Silberschatz, Korth and Sudarshan7.68 Therefore, it is better to decompose classes into: courseteacher database operating systems Avi Hank Sudarshan Avi Jim teaches coursebook database operating systems DB Concepts Ullman OS Concepts Shaw text We shall see that these two relations are in Fourth Normal Form (4NF) Multivalued Dependencies (Cont.)
69
©Silberschatz, Korth and Sudarshan7.69 Multivalued Dependencies (MVDs) Let R be a relation schema and let R and R. The multivalued dependency holds on R if in any legal relation r(R), for all pairs for tuples t 1 and t 2 in r such that t 1 [ ] = t 2 [ ], there exist tuples t 3 and t 4 in r such that: t 1 [ ] = t 2 [ ] = t 3 [ ] t 4 [ ] t 3 [ ] = t 1 [ ] t 3 [R – ] = t 2 [R – ] t 4 [ ] = t 2 [ ] t 4 [R – ] = t 1 [R – ]
70
©Silberschatz, Korth and Sudarshan7.70 MVD (Cont.) Tabular representation of
71
©Silberschatz, Korth and Sudarshan7.71 Example Let R be a relation schema with a set of attributes that are partitioned into 3 nonempty subsets. Y, Z, W We say that Y Z (Y multidetermines Z) if and only if for all possible relations r(R) r and r then r and r Note that since the behavior of Z and W are identical it follows that Y Z if Y W
72
©Silberschatz, Korth and Sudarshan7.72 Example (Cont.) In our example: course teacher course book The above formal definition is supposed to formalize the notion that given a particular value of Y (course) it has associated with it a set of values of Z (teacher) and a set of values of W (book), and these two sets are in some sense independent of each other. Note: If Y Z then Y Z Indeed we have (in above notation) Z 1 = Z 2 The claim follows.
73
©Silberschatz, Korth and Sudarshan7.73 Use of Multivalued Dependencies We use multivalued dependencies in two ways: 1.To test relations to determine whether they are legal under a given set of functional and multivalued dependencies 2.To specify constraints on the set of legal relations. We shall thus concern ourselves only with relations that satisfy a given set of functional and multivalued dependencies. If a relation r fails to satisfy a given multivalued dependency, we can construct a relations r that does satisfy the multivalued dependency by adding tuples to r.
74
©Silberschatz, Korth and Sudarshan7.74 Theory of MVDs From the definition of multivalued dependency, we can derive the following rule: If , then That is, every functional dependency is also a multivalued dependency The closure D + of D is the set of all functional and multivalued dependencies logically implied by D. We can compute D + from D, using the formal definitions of functional dependencies and multivalued dependencies. We can manage with such reasoning for very simple multivalued dependencies, which seem to be most common in practice For complex dependencies, it is better to reason about sets of dependencies using a system of inference rules (see Appendix C).
75
©Silberschatz, Korth and Sudarshan7.75 Fourth Normal Form A relation schema R is in 4NF with respect to a set D of functional and multivalued dependencies if for all multivalued dependencies in D + of the form , where R and R, at least one of the following hold: is trivial (i.e., or = R) is a superkey for schema R If a relation is in 4NF it is in BCNF
76
©Silberschatz, Korth and Sudarshan7.76 Restriction of Multivalued Dependencies The restriction of D to R i is the set D i consisting of All functional dependencies in D + that include only attributes of R i All multivalued dependencies of the form ( R i ) where R i and is in D +
77
©Silberschatz, Korth and Sudarshan7.77 4NF Decomposition Algorithm result: = {R}; done := false; compute D + ; Let D i denote the restriction of D + to R i while (not done) if (there is a schema R i in result that is not in 4NF) then begin let be a nontrivial multivalued dependency that holds on R i such that R i is not in D i, and ; result := (result - R i ) (R i - ) ( , ); end else done:= true; Note: each R i is in 4NF, and decomposition is lossless-join
78
©Silberschatz, Korth and Sudarshan7.78 Example R =(A, B, C, G, H, I) F ={ A B B HI CG H } R is not in 4NF since A B and A is not a superkey for R Decomposition a) R 1 = (A, B) (R 1 is in 4NF) b) R 2 = (A, C, G, H, I) (R 2 is not in 4NF) c) R 3 = (C, G, H) (R 3 is in 4NF) d) R 4 = (A, C, G, I) (R 4 is not in 4NF) Since A B and B HI, A HI, A I e) R 5 = (A, I) (R 5 is in 4NF) f)R 6 = (A, C, G) (R 6 is in 4NF)
79
©Silberschatz, Korth and Sudarshan7.79 Further Normal Forms Join dependencies generalize multivalued dependencies lead to project-join normal form (PJNF) (also called fifth normal form) A class of even more general constraints, leads to a normal form called domain-key normal form. Problem with these generalized constraints: are hard to reason with, and no set of sound and complete set of inference rules exists. Hence rarely used
80
©Silberschatz, Korth and Sudarshan7.80 Overall Database Design Process We have assumed schema R is given R could have been generated when converting E-R diagram to a set of tables. R could have been a single relation containing all attributes that are of interest (called universal relation). Normalization breaks R into smaller relations. R could have been the result of some ad hoc design of relations, which we then test/convert to normal form.
81
©Silberschatz, Korth and Sudarshan7.81 ER Model and Normalization When an E-R diagram is carefully designed, identifying all entities correctly, the tables generated from the E-R diagram should not need further normalization. However, in a real (imperfect) design there can be FDs from non-key attributes of an entity to other attributes of the entity E.g. employee entity with attributes department-number and department-address, and an FD department-number department- address Good design would have made department an entity FDs from non-key attributes of a relationship set possible, but rare --- most relationships are binary
82
©Silberschatz, Korth and Sudarshan7.82 Universal Relation Approach Dangling tuples – Tuples that “disappear” in computing a join. Let r 1 (R 1 ), r 2 (R 2 ), …., r n (R n ) be a set of relations A tuple r of the relation r i is a dangling tuple if r is not in the relation: Ri (r 1 r 2 … r n ) The relation r 1 r 2 … r n is called a universal relation since it involves all the attributes in the “universe” defined by R 1 R 2 … R n n If dangling tuples are allowed in the database, instead of decomposing a universal relation, we may prefer to synthesize a collection of normal form schemas from a given set of attributes.
83
©Silberschatz, Korth and Sudarshan7.83 Universal Relation Approach Dangling tuples may occur in practical database applications. They represent incomplete information E.g. may want to break up information about loans into: (branch-name, loan-number) (loan-number, amount) (loan-number, customer-name) Universal relation would require null values, and have dangling tuples
84
©Silberschatz, Korth and Sudarshan7.84 Universal Relation Approach (Contd.) A particular decomposition defines a restricted form of incomplete information that is acceptable in our database. Above decomposition requires at least one of customer-name, branch-name or amount in order to enter a loan number without using null values Rules out storing of customer-name, amount without an appropriate loan-number (since it is a key, it can't be null either!) Universal relation requires unique attribute names unique role assumption e.g. customer-name, branch-name Reuse of attribute names is natural in SQL since relation names can be prefixed to disambiguate names
85
©Silberschatz, Korth and Sudarshan7.85 Denormalization for Performance May want to use non-normalized schema for performance E.g. displaying customer-name along with account-number and balance requires join of account with depositor Alternative 1: Use denormalized relation containing attributes of account as well as depositor with all above attributes faster lookup Extra space and extra execution time for updates extra coding work for programmer and possibility of error in extra code Alternative 2: use a materialized view defined as account depositor Benefits and drawbacks same as above, except no extra coding work for programmer and avoids possible errors
86
©Silberschatz, Korth and Sudarshan7.86 Other Design Issues Some aspects of database design are not caught by normalization Examples of bad database design, to be avoided: Instead of earnings(company-id, year, amount), use earnings-2000, earnings-2001, earnings-2002, etc., all on the schema (company-id, earnings). Above are in BCNF, but make querying across years difficult and needs new table each year company-year(company-id, earnings-2000, earnings-2001, earnings-2002) Also in BCNF, but also makes querying across years difficult and requires new attribute each year. Is an example of a crosstab, where values for one attribute become column names Used in spreadsheets, and in data analysis tools
87
Proof of Correctness of 3NF Decomposition Algorithm
88
©Silberschatz, Korth and Sudarshan7.88 Correctness of 3NF Decomposition Algorithm 3NF decomposition algorithm is dependency preserving (since there is a relation for every FD in F c ) Decomposition is lossless join A candidate key (C) is in one of the relations R i in decomposition Closure of candidate key under F c must contain all attributes in R. Follow the steps of attribute closure algorithm to show there is only one tuple in the join result for each tuple in R i
89
©Silberschatz, Korth and Sudarshan7.89 Correctness of 3NF Decomposition Algorithm (Contd.) Claim: if a relation R i is in the decomposition generated by the above algorithm, then R i satisfies 3NF. Let R i be generated from the dependency Let B be any non-trivial functional dependency on R i. (We need only consider FDs whose right-hand side is a single attribute.) Now, B can be in either or but not in both. Consider each case separately.
90
©Silberschatz, Korth and Sudarshan7.90 Correctness of 3NF Decomposition (Contd.) Case 1: If B in : If is a superkey, the 2nd condition of 3NF is satisfied Otherwise must contain some attribute not in Since B is in F + it must be derivable from F c, by using attribute closure on . Attribute closure not have used - if it had been used, must be contained in the attribute closure of , which is not possible, since we assumed is not a superkey. Now, using ( - {B}) and B, we can derive B (since , and B since B is non-trivial) Then, B is extraneous in the right-hand side of ; which is not possible since is in F c. Thus, if B is in then must be a superkey, and the second condition of 3NF must be satisfied.
91
©Silberschatz, Korth and Sudarshan7.91 Correctness of 3NF Decomposition (Contd.) Case 2: B is in . Since is a candidate key, the third alternative in the definition of 3NF is trivially satisfied. In fact, we cannot show that is a superkey. This shows exactly why the third alternative is present in the definition of 3NF. Q.E.D.
92
©Silberschatz, Korth and Sudarshan7.92 Sample lending Relation
93
©Silberschatz, Korth and Sudarshan7.93 Sample Relation r
94
©Silberschatz, Korth and Sudarshan7.94 The customer Relation
95
©Silberschatz, Korth and Sudarshan7.95 The loan Relation
96
©Silberschatz, Korth and Sudarshan7.96 The branch Relation
97
©Silberschatz, Korth and Sudarshan7.97 The Relation branch-customer
98
©Silberschatz, Korth and Sudarshan7.98 The Relation customer-loan
99
©Silberschatz, Korth and Sudarshan7.99 The Relation branch-customer customer-loan
100
©Silberschatz, Korth and Sudarshan7.100 An Instance of Banker-schema
101
©Silberschatz, Korth and Sudarshan7.101 Tabular Representation of
102
©Silberschatz, Korth and Sudarshan7.102 Relation bc: An Example of Reduncy in a BCNF Relation
103
©Silberschatz, Korth and Sudarshan7.103 An Illegal bc Relation
104
©Silberschatz, Korth and Sudarshan7.104 Decomposition of loan-info
105
©Silberschatz, Korth and Sudarshan7.105 Relation of Exercise 7.4
Similar presentations
