Lecture5 Functional Dependencies and Normalization for Relational Databases

Transcription

1 College of Computer and Information Sciences - Information Systems Dept. Lecture5 Functional Dependencies and Normalization for Relational Databases Ref. Chapter14-15 Prepared by L. Nouf Almujally & Aisha AlArfaj Last Example added by : L.Kholoud Baselm 1 IS220: Database Fundamentals

2 How to produce a good relation schema? Top-down approach Such as ER modeling ER model is mapped to a set of relations Set of well-designed relations Bottom-up approach Use normalization to create set of relations 2

3 Bottom-up approach STEPS: 1. Start with a set of relations. 2. Define the functional dependencies for the relation to specify the PK. 3. Transform relations to normal form. 3

4 Functional Dependencies Describes the relationship between attributes in a relation. If A and B are attributes of relation R, B is functionally dependent on A, denoted by A B, if each value of A is associated with exactly one value of B. B may have several values of A. A Determinant B is functionally dependent on A B Dependent 4

5 Functional Dependencies X Y X -> Y holds if whenever two tuples have the same value for X, they must have the same value for Y For any two tuples t and u in any relation instance r(r): If t[x]=u[x], then t[y]=u[y] If t & u agree here Then they must agree here X Y t 5 u

6 Functional Dependencies Example 1:1 or M:1 relationship between attributes in a relation StaffNo SL21 Position is functionally dependent on Staffno position Manager 1:M relationship between attributes in a relation position Manager StaffNo is NOT functionally dependent on position StaffNo SL21 SG5 6

7 Examples of FD constraints Social security number determines employee name SSN -> ENAME Project number determines project name and location PNUMBER -> {PNAME, PLOCATION} Employee ssn and project number determines the hours per week that the employee works on the project {SSN, PNUMBER} -> HOURS 7

8 Identifying the PK Purpose of functional dependency, specify the set of integrity constraints that must hold on a relation. The determinant attribute(s) are candidate of the relation, if: 1:1 relationship between determinant & dependent. All attributes that are not part of the CK should be functionally dependent on the key: CK all attributes of R Hold for all time. Primary Key (PK) is the candidate attribute(s) with the minimal set of functional dependency. 8

9 Identifying the PK If a relation schema has more than one key, each is called a candidate key. One of the candidate keys is arbitrarily designated to be the primary key, and the others are called Alternate keys. A Prime attribute must be a member of some candidate key A Nonprime attribute is not a prime attribute that is, it is not a member of any candidate key. 9

10 The Purpose of Normalization Normalization is a bottom-up approach to database design that begins by examining the relationships between attributes. It is performed as a series of tests on a relation to determine whether it satisfies or violates the requirements of a given normal form. Purpose: - Guarantees no redundancy due to FDs - Guarantees no update anomalies Normal Forms: First Normal Form (1NF) Second Normal Form (2NF) Third Normal Form (3NF) 10 Boyce-Codd Normal Form (BCNF)

11 Normal Forms Defined Informally 1 st normal form All attributes depend on the key 2 nd normal form All attributes depend on the whole key 3 rd normal form All attributes depend on nothing but the key 11

12 First Normal Form (1NF) 12

13 First Normal Form (1NF) Unnormalized form (UNF): A relation that contains one or more repeating groups. First normal form (1NF): A relation in which the intersection of each row and column contains one & only one value. 1NF Disallows: multivalued attribute nested relations; attributes whose values for an individual tuple are non-atomic (repeating group) 13

14 First Normal Form (1NF) Multivalued CLIENT_PROPERTY ClientNo Name PropertyNo CR76 CR56 John Key Aline Stewart PG4 PG16 PG4 PG36 PG16 Unnormalized form (UNF) Not in the 1NF because there are Multivalued attribute in the table (PropertyNo) 14

15 UNF 1NF Divide the relation to two relations: Relation 1 : Contains all the attributes except the multivalued attribute. Relation 2 : Contains the primary key of the first relation and the multivalued attribute Primary key becomes the combination of primary key and multivalued attribute. 15

16 UNF 1NF CLIENT_PROPERTY ClientNo Name PropertyNo CR76 John Key CR56 Aline Stewart PG4 PG16 PG4 PG36 PG16 Unnormalized form (UNF) CLIENT ClientNo Name CR76 John Key CR56 Aline Stewart CLIENT_PROPERTY ClientNo PropertyNo CR76 CR76 CR56 CR56 CR56 PG4 PG16 PG4 PG36 PG NF relations

17 UNF (multivalued) 1NF Multivalued Unnormalized form (UNF) 17 1NF relations

18 UNF (nested relations) Nested relation 1NF Unnormalized form (UNF) First normal form also disallows multivalued attributes that are themselves composite. These are called nested relations because each tuple can have a relation within it. 18

19 UNF (nested relations) Nested relation 1NF Unnormalized form (UNF) EMPLOYEE 1NF relations EMP_PROJECT Ssn Pnumber Hours

20 UNF (nested relations) 1NF Nested relation DPT_NO MG_NO EMP_NO EMP_NM D D Carl Sagan Mag James Larry Bird Jim Carter Paul Simon Unnormalized form (UNF) DPT_NO Dept MG_NO Dept_Emp DPT_NO EMP_NO EMP_NM D D Carl Sagan D NF relations D Mag James D Larry Bird D Jim Carter D Paul Simon Lecture5 20

21 Summary : first normal form (1NF) We say a relation is in 1NF if: all values stored in the relation are single-valued and atomic. There are no Multivalued Attributes. There are no repeating groups or nested relations in the table. 21

22 Second Normal Form (2NF) 22

23 Second Normal Form (2NF) Prime attribute: An attribute that is member of the primary key K Full functional dependency: when an non-prime attribute is determined by the whole of a COMPOSITE primary key. CUSTOMER Full Functional Dependency Cust_ID Name Order_ID 101 AT&T AT&T Cisco

24 Second Normal Form (2NF) Partial Dependency when an non-key attribute is determined by a part, but not the whole, of a COMPOSITE primary key. CUSTOMER Partial Dependency Cust_ID Name Order_ID 101 AT&T AT&T Cisco

25 Summary: Second Normal Form (2NF) A relation R is in 2NF if 1. R is 1NF, and 2. All non-prime attributes are fully dependent on the primary key. 3. no partial dependency in 2NF. 25

26 Second Normal Form (2NF) To transfer the relation to 2NF: 1) Remove partial dependencies by placing the functionally dependent attributes in a new relation along with a copy of their determinants. 26

27 Example1: 1NF 2NF Partial Dependencies Remove partial dependencies by placing the functionally dependent attributes in a new relation along with a copy of their determinants. 27

28 Example2: Second normal form -2NF Inventory Product_ID Supplier_ID Cost Supplier Address There are two non-key fields. So, here are the questions: If I know just Product_ID, can I find out Cost? No, because we have more than one supplier for the same product. If I know just Supplier_ID, and I find out Cost? No, because I need to know what the product is as well. Therefore, Cost is fully, functionally dependent upon the whole PK (Product_ID, Supplier_ID). 28

29 Example 2: Second normal form -2NF Inventory Product_ID Supplier_ID Cost Supplier Address If I know just Product_ID, can I find out Supplier Address? No, because we have more than one supplier for the same product. If I know just Supplier_ID, and I find out Supplier Address? Yes. The Address does not depend upon the product. Therefore, Supplier Address is NOT functionally dependent upon the whole PK (Product_ID, Supplier_ID). 29

30 Example 2: Second normal form -2NF Inventory Product_ID Supplier_ID Cost supplier Supplier_ID Supplier Address The above relations are now in 2NF 30

31 Third Normal Form (3NF) 31

32 Third Normal Form (3NF) Transitive functional dependency X, Y, Z are attributes of a relation, such that: If X Y and Y Z, then Z is transitively dependent on X via Y. Transitive Dependency EMPLOYEE Emp_ID F_Name L_Name Dept_ID Dept_Name 111 Mary Jones 1 Acct 122 Sarah Smith 2 Mktg 32

33 Third Normal Form (3NF) Examples: SSN -> DMGRSSN is a transitive FD Since SSN -> DNUMBER and DNUMBER -> DMGRSSN SSN -> ENAME is non-transitive Since there is no set of attributes X where SSN -> X and X -> ENAME 33

34 Third Normal Form (2) A relation schema R is in third normal form (3NF) if : 1. R in 2NF and 2. There is NO Transitive Dependency : when a non-key attribute determines another non-key attribute. 34

35 Third Normal Form (2) NOTE: In X -> Y and Y -> Z, with X as the primary key, we consider this a problem only if Y is not a candidate key. When Y is a candidate key, there is no problem with the transitive dependency. E.g., Consider EMP (SSN, Emp#, Salary ). Here, SSN -> Emp# -> Salary and Emp# is a candidate key. 35

36 Third Normal Form (3NF) To transfer the relation to 3NF: 1) Meet all the requirements of the 1NF 2) Meet all the requirements of the 2NF 3) Place transitive dependent attributes in a new relation along with a copy of their determinants. 36

37 Example: 2NF 3NF 2NF Transitive Dependencies 3NF 3NF If transitive dependencies exist, place transitively dependent attributes in a new relation along with a copy of their determinants. 37

38 Example : Third normal form -3NF Books Book_ID Author's Name Author's Address # of Pages If I know # of Pages, can I find out Author's Name? No. Can I find out Author's Address? No. If I know Author's Name, can I find out # of Pages? No. Can I find out Author's Address? YES. Therefore, Author's Address is transitively dependent upon Author's Name, not the PK for its existence. Books Authors Book_ID Author's Name # of Pages Author's Name Author's Address 38

39 39

40 Important Notes To normalize a relation (table) : Make sure you follow the correct order (1NF, 2NF, 3NF) o Unnormalized There are multivalued attributes or repeating groups o 1 st NF: no multivalued attribute/repeated groups. o 2 nd NF: 1 st NF + no partial dependency. o 3 rd NF: 2 nd NF +no transitive dependency. For each NF, write full justification why or why not the table in the NF Give full and correct reason (spelling is important) You should give your new relations (tables) names. Make sure you specify the primary key for new tables. 40

41 EXTRA EXAMPLES 41

42 Example 1: Determine NF ISBN Title ISBN Publisher Publisher Address BOOK No multivalued attributes ; therefore, the relation is at least in 1 NF ISBN Title Publisher Address 42

43 Example 1: Determine NF ISBN Title ISBN Publisher Publisher Address BOOK There is no COMPOSITE primary key, therefore there can t be partial dependencies. Therefore, the relation is at least in 2NF ISBN Title Publisher Address 43

44 Example 1: Determine NF ISBN Title ISBN Publisher Publisher Address BOOK Publisher is a non-prime attribute, and it determines Address, another non-prime attribute. Therefore, there is a transitive dependency, which means that the relation is NOT in 3 NF. ISBN Title Publisher Address 44

45 Example 1: Determine NF ISBN Title ISBN Publisher Publisher Address We know that the relation is at least in 2NF, and it is not in 3 NF. Therefore, we conclude that the relation is in 2NF. BOOK ISBN Title Publisher Address 45

46 Example 1: Determine NF ISBN Title ISBN Publisher Publisher Address BOOK In your solution you will write the following justification: 1) No M/V attributes, therefore at least 1NF 2) No partial dependencies, therefore at least 2NF 3) There is a transitive dependency (Publisher Address), therefore, not 3NF Conclusion: The relation is in 2NF ISBN Title Publisher Address 46

47 Example 1: Determine NF To convert it to 3NF : place transitive dependent attributes in a new relation along with a copy of their determinants. BOOK - Now in the 3NF ISBN Title Publisher Publisher Publisher Address 47

48 Example 2: Determine NF Product_ID Description ORDER No multivalued attributes; therefore, the relation is at least in 1 NF Order_No Product_ID Description 48

49 Example 2: Determine NF Product_ID Description The relation is at least in 1NF. There is a COMPOSITE Primary Key (PK) (Order_No, Product_ID), therefore there can be partial dependencies. Product_ID, which is a part of PK, determines Description; hence, there is a partial dependency. Therefore, the relation is not 2NF. ORDER Order_No Product_ID Description 49

50 Example 2: Determine NF Product_ID Description ORDER We know that the relation is at least in 1NF, and it is not in 2 NF. Therefore, we conclude that the relation is in 1 NF. Order_No Product_ID Description 50

51 Example 2: Determine NF Product_ID Description ORDER In your solution you will write the following justification: 1) No M/V attributes, therefore at least 1NF 2) There is a partial dependency (Product_ID Description), therefore not in 2NF Conclusion: The relation is in 1NF Order_No Product_ID Description 51

52 Example 2: Determine NF Remove partial dependencies by placing the functionally dependent attributes in a new relation along with a copy of their determinants. - Now in the 2NF - No Transitive therefore in the 3NF ORDER Order_No Product Product_ID Product_ID Description 52

53 Example 3: Determine NF EmpNum EmpPhone EmpDegrees BA BA, BSc, PhD BSc, MSc IS Emp_info in the 1NF? 2NF? 3NF? Explain why? 53

54 Determine 1 NF? There are Multivalued attributes; therefore, not in 1NF EmpNum EmpPhone Emp_phone (1NF) EmpNum EmpDegrees 123 BA 333 BA 333 BSc 333 PhD 679 BSc 679 MSc Emp_Degree (1NF) 54

55 Determine 2NF? There is no partial dependency, therefore in 2NF EmpNum EmpPhone Emp_phone (2NF) EmpNum EmpDegrees 123 BA 333 BA 333 BSc 333 PhD 679 BSc 679 MSc Emp_Degree (2NF) 55

56 Determine 3NF? There is no transitive dependency, therefore in 3NF EmpNum EmpPhone Emp_phone (3NF) EmpNum EmpDegrees 123 BA 333 BA 333 BSc 333 PhD 679 BSc 679 MSc Emp_Degree (3NF) 56

57 References Database Systems: A Practical Approach to Design, Implementation and Management. Thomas Connolly, Carolyn Begg. 5 th Edition, Addison-Wesley,

58 Normalization Example UNF 58

59 Normalization Example FD s 59

60 1NF? UNF NO.. The relation is not in 1NF because it contain a repeating group. The structure of the repeating group is: Repeating group=(propertyno,paddress,rentstart,rentfinish,rent,ownerno,oname) We remove the repeating group by placing the repeating data along with a copy of the PK in a separate relation. 60

61 1NF? 1NF 61

62 2NF 62

63 2NF 63

64 64

65 The resulting 3NF relations have the form: 65

66 66