Objectives of Database Design Functional Dependencies 1st Normal Form Decomposition Boyce-Codd Normal Form 3rd Normal Form Multivalue Dependencies

Transcription

1 Objectives of Database Design Functional Dependencies 1st Normal Form Decomposition Boyce-Codd Normal Form 3rd Normal Form Multivalue Dependencies 4th Normal Form General view over the design process 1

2 Schema Managers = (branch, customer, account-managaer), with the following dependencies: 1. account-managaer branch 2. customer, branch account-manager is not in BCNF because of the first functional dependency. The two candidate keys of Managers are {customers, branch} e {account-manager, customer}. But: By decomposing Managers based on the 1st dependency, branch will be in a different schema from the one where customer will be. So it will be not possible to verify the 2nd dependency in just one schema! Solution: Do not allow the decomposition based on dependencies having attributes (on the right side) which are just part of candidate keys.. 2

3 A schema R is on the 3rd Normal Form (3FN) iff for all: α β F + at least one of the following conditions is true: α β is trivial (i.e., β α) α is superkey of R (i.e., α R F + ) Every attribute A (β α) is contained in a candidate key of R. (NOTE: each attribute may belong to a distinct candidate key) the 3rd condition relaxes the BCNF so it ensures that it is possible a decomposition with com preservation of the dependencies If R is in BCNF so it is also in 3FN 3

4 Esquema Manager = (branch, customer, account-manager) with the following FDs: 1. Account_manager branch managers 2. cliente, balcão gestor-conta branch Faro Pedro Maria It has two candidate keys: {customer, branch} and {account-manager, customer}. It is in 3ªFN because: 1. branch candidate key {customer, branch} and 2. {customer, branch} is candidate key It is not BCNF bacause FD 1 is not trivial and account_manager is not superkey. Decomposition BCNF: custo mer Pedro Carla Pedro Pedro customers Redundância! Ana Francisco Francisco Maria Does not preserve the functional dependency customer, branch account-manager 4 custo mer Lisboa Pedro Ana Porto Carla Francisco Porto Pedro Francisco manager-branch branch Lisboa Porto Faro Ana Francisco Maria

5 OptimizationIt is enough to verify a canonical cover of F (no need to check for all FD in F + ) Use the close of the attributes, in all FD α β, to check if α is superkey. If α is not a superkey, we need to verify if β- α belongs to any candidate key of R This test is very inefficient, as it involves the calculation of candidate keys It may be proven that to verify if a set of schemas is in 3NF, it is a NP-hard complexity (very complex!) However, it is possible to decompose to 3FN in polinomial time 5

6 be F c a canonical cover of F; i := 0; for each α β F c do if no schema R j, 1 j i contains α β then begin i := i + 1; R i := α β end if no schema R j, 1 j i contains a candidate key of R then begin i := i + 1; R i := one (any one) candidate key of R; end return (R 1, R 2,..., R i ) 6

7 Consider the schema: Info-managers = (branch, customer, account_manager, office) DFs defined on the schema are: Candidate keys are: Account_manager branch, office customer, branch account_manager {customer, branch} and {account_manager,customer} Info-managers is not in 3FN. Considering the FD account_manager branch, office, we see that: account_manager is nota superkey; office any candidate key. The cicle for of the algorithm, lead us to the introduction of the following decomposition schemas: Managers-office = (Account_manager, branch, office) managers = (customer, branch, account_manager) Since managers contains a candidate key of Info-managers, {customer,branch}, the decomposition process ends. 7

8 Esquema managers = (branch, customer, account_manager, office) with the following FDs : info-gestores Account_manager branch, office customer, branch account_manager Redundancy! It is neither in BCNF nor 3NF Decomposition to BCNF: Does not preserves the FD customer, branch account-manager branch branch 8 custo mer office Lisboa Pedro Ana 1.1 Porto Carla Francisco 2.1 Porto Pedro Francisco 2.1 Faro Pedro Maria 3.1 customers managers-branch office Lisboa Ana 1.1 Porto Francisco 2.1 Faro Maria 3.1 Managers-office custom er Pedro Carla Pedro Pedro Decomposition to 3NF: managers Redundancy! branch custo mer Lisboa Pedro Ana Porto Carla Francisco Porto Pedro Francisco Faro Pedro Maria branch Ana Francisco Francisco Maria office Lisboa Ana 1.1 Porto Francisco 2.1 Faro Maria 3.1

9 Consider the schema: With the folowing FDs: Then, the candidate key is: R = (A,B,C) A C B C { A, B } Since the cicle for of the algorithm, lead us to introduce the following decomposition schemas: R 1 = (A,C) R 2 = (B,C) And none of R 1 or R 2 contains the candidate key of R, the decomposition process adds: R 3 = (A, B) 9

10 Considere o schema Semester=(Sb,P,H,R,St,Av) representing the information related to the practical component of the evaluation of a subject in a semester, where Sb=subject, P=Professor, H=Hour, R=Room, St=Student e Av=Evaluation. Consider the following FDs: F= {Sb P, H R Sb; H P R, Sb St Av, H St R; H R P Sb R} First we find a canonical cover: F c = {Sb P, H R Sb, H P R, Sb St Av, H St R} Candidate keys (just one): {St, H} Cicle for cretes the following 5 schemas, corresponding to the 5 FDs of the canonical cover: R 1 =(Sb,P) R 2 =(H,R,Sb) R 3 =(H,P,R) R 4 =(Sb,St,Av) R 5 =(H,St,R) Since there is a schema (R 5 ) containing the candidate key ({St,H}), there is no need to create more schemas. 10

11 The described algorithm ensures that: Every schema R i is in 3FN The decomposition preserves the FDs and itʼs lossless Please note it is ensured that all FDs are preserved but only considering all schemas, not a subset aof te schemas. Decomposing R = (A,B,C), with A C and B C, in: R 1 = (A, C) R 2 = (B,C) R 3 = (A, B) preserves all DFs: F 1 = {A C}, F 2 = {B C}, F 3 = { } and (F 1 F 2 F 3 ) + = F + But (F 1 F 3 ) + F +, though R 1 R 3 = R!! Particularly AB C F + but AB C (F 1 F 3 ) + 11

12 The resuue lt of the algorithm is not unique since it depends on: The caconical cover used The candidate key of R that is used In some cases, the order by which FDs are considered 12

13 It is always possible to decompose a schema in a set of schemas in 3FN such that: Decomposition is lossless FDs are preserved But there may be some redundancy!! It is always possible to decompose a schema is a set of schemas in BCNF such that: Decomposition is lossless There is no redundancy But it may not be possible to preserve FDs!! 13

14 Objectives of the design, in a first phase: BCNF. Lossless decomposition. FDs preservation. If not possible, then we have to chose between No FDs preservation Some redundancy (due to the use of 3FN) 14

15 If the decomposition does not preserve FDs, we can criate a materialized view for each FD α β F c which is not preserved Oracle allow to create this type of view: create materialized view the materialized view must be defined for the projection of α β of the joins of the decomposed relations. The Fd must be imposed as candidate key of the materialized view. That implies an overhead (computational extra weight) of space: we have to store the view. time: views must be kept up to date 15