Normalisation. Databases: Topic 4

Transcription

1 Normalisation Databases: Topic 4

2 Resources for this Topic Readings (text): - Chapter 3 Other Readings: - Chapple, M (n.d) Database Normalization Basics, Retrieved from - (2008) Normalization Example,

3 Topic Objectives This topic aims to introduce you to normalisation as an important process in relational database design. It addresses the following unit learning objectives: Demonstrate an understanding of database principles and theory, particularly those relating to the Relational Model Design a database, demonstrating practical skills in normalisation and data modelling In order to achieve the unit learning objectives, on successful completion of this topic, you should be able to: Define and explain the types of modification anomalies associated with redundant information in tables Explain the purpose of normalisation Identify functional dependencies among attributes Define, and use examples of as appropriate, the following terms: Partial functional dependency Transitive functional dependency Give definitions of the following: 1NF 2NF 3NF BCNF Be able to identify which normal form a given relation is in Normalise a given relation to a more appropriate normal form Discuss some limitations that may be associated with normalisation

4 Topic Outline Relational design guidelines Modification anomalies Insertion Deletion Update Functional dependencies Normal forms: 1NF, 2NF, 3NF, BCNF Limitations of the normalisation process

5 1. Relational Design Guidelines

6 Normalisation - Normalisation is a technique for producing a set of suitable relations that support the data requirements of an enterprise. - Characteristics of a suitable set of relations include: - the minimal number of attributes necessary to support the data requirements of the enterprise; - attributes with a close logical relationship are found in the same relation; - minimal redundancy with each attribute represented only once with the important exception of attributes that form all or part of foreign keys.

7 Why bother? - Bad/poor/suboptimal designs: - have negative impacts on the performance of the database - have negative impacts on the ability of the database to be used for decision making

8 Some high level design guidelines - Relations should be simple to understand - This means they should correspond to a single real-world concept - Relations should not have any update anomalies - Normalisation should remove these anomalies - Usually the database will contain several relations. Design should ensure that relations can be joined (to get information from more than one relation) without generating 'extra' records - This is done by ensuring that any joins will be made between the primary key of one relation and the foreign key of the other - Functional dependencies that exist in the original data should be preserved in the database design

9 2. Modification Anomalies

10 Modification Anomalies - Modification anomalies may arise when data in a relation containing redundant data are modified - They lead to inconsistency in the database: - Insertion anomalies - The need to enter more data than is required - Update anomalies - Not all instances of data update - Deletion anomalies - The unintentional deletion of data - GOOD DESIGN IS THE BEST WAY TO AVOID INCONSISTENCIES

11 Examples StudentID StudentName Address Unit Code Unit Title Offering Mark Bruce 1 Random Cres ICT218 Databases S Bruce 1 Random Cres ICT231 Systems Analysis and Design S Mary 46 The Mews ICT231 Systems Analysis and Design S Mary 46 The Mews ICT218 Databases S INSERTION ANOMALY: To insert a new unit in the example above, it is necessary to know a student and an offering of the unit. UPDATE ANOMALY: If we change Mary s address we need to change two rows DELETION ANOMALY: if we delete Bruce s enrolment in Databases in Semester 1, 2010, we lose all information regarding that offering.

12 Can you identify how anomalies could occur in this relation? StaffNum Name Position Salary SchoolNum School School Phone S21 Barry Brightwater School Dean MH47 Happiness x005 S37 Deloris Delight Lecturer LH53 Hopeless Causes x003 S14 Carrie Cumbersome Professor LH53 Hopeless Causes x003 S09 Albert Algorithm School Dean 9000 XS67 Low Self Esteem x007 S05 Edwina Elocution School Dean LH53 Hopeless Causes x003 S41 Frank Forensic Cleaner 9000 MH47 Happiness x005

13 Are those problems resolved? StaffNum Name Position Salary SchoolNum S21 Barry Brightwater School Dean MH47 S37 Deloris Delight Lecturer LH53 S14 Carrie Cumbersome Professor LH53 S09 Albert Algorithm School Dean 9000 XS67 S05 Edwina Elocution School Dean LH53 S41 Frank Forensic Cleaner 9000MH47 SchoolNum School School Phone MH47 Happiness x005 LH53 Hopeless Causes x003 XS67 Low Self Esteem x007

14 Decomposition of Relations - When decomposing relations in the normalisation process, two important facets of the original data must be preserved: - Lossless Join - Any instance of the original relation can be identified from the decomposed relations - Dependency Preservation - Any constraint on the original relation can be maintained by enforcing the constraint on each of the smaller relations

15 StaffNum Name Position Salary SchoolNum School School Phone S21 Barry Brightwater School Dean MH47 Happiness x005 S37 Deloris Delight Lecturer LH53 Hopeless Causes x003 S14 Carrie Cumbersome Professor LH53 Hopeless Causes x003 S09 Albert Algorithm School Dean 9000 XS67 Low Self Esteem x007 S05 Edwina Elocution School Dean LH53 Hopeless Causes x003 S41 Frank Forensic Cleaner 9000 MH47 Happiness x005 StaffNum Name Position Salary SchoolNum S21 Barry Brightwater School Dean MH47 S37 Deloris Delight Lecturer LH53 S14 Carrie Cumbersome Professor LH53 S09 Albert Algorithm School Dean 9000 XS67 S05 Edwina Elocution School Dean LH53 S41 Frank Forensic Cleaner 9000MH47 SchoolNum School School Phone MH47 Happiness x005 LH53 Hopeless Causes x003 XS67 Low Self Esteem x007 Do we have lossless-joins here?

16 3. Functional Dependencies

17 Functional Dependencies - Normalisation is a way of transforming an unsatisfactory relation schema (one with modification anomalies) into a 'better' design by reducing redundancy - A functional dependency is a relationship between attributes such that the value of one attribute can be found from the value of another

18 Why bother? - FDs represent information about the system we are modelling which should be preserved - Normal forms 1NF, 2NF, 3NF and BCNF are based on functional dependencies between the attributes in a relation (higher normal forms are based on other dependencies)

19 X à Y We can say that X determines Y if: - There exists at most one value of Y for every value of X - For example: we can say that student number determines date of birth as for each student number there is one and only one date of birth. - Can we say that student name determines student number?

20 Example: Consider the following relation: EMPLOYEE ( EmployeeID, Name, Address, DeptNo ) if the value of EmployeeID is known, the values of Name, Address and DeptNo can be found - in other words: Name, Address, DeptNo are functionally dependent on EmployeeID EmployeeID functionally determines Name, Address, DeptNo EmployeeID is called the determinant of the FD

21 Writing FDs We can write FDs as: EmployeeID Name, Address, DeptNo OR Name EmployeeID Address DeptNo (StudentNo, Unit, Semester, Year) Grade

22 Some rules about FD s - Reflexivity - If Y Í X, then X à Y - Augmentation - If X à Y, then XZ à YZ - Transitivity - If X à Y, and Y à Z, then X à Z - Decomposition - If X à YZ, then XàY and XàZ - Union - If X à Y, and X à Z, the X à YZ

23 Example: What functional dependencies can you identify in the following relation (assuming the data is representative)? List only the direct dependencies StudentID Name Course OfferingNo Semester Year Grade UnitCode Title S1 Kyle IT HD ICT231 Systems Analysis S1 Kyle IT D ICT208 BI T&T S2 Helen IT D ICT231 Systems Analysis S2 Helen IT C ICT218 Databases S2 Helen IT N ICT218 Databases

24 Example: What functional dependencies can you identify in the following relation (assuming the data is representative)? List only the direct dependencies StaffNum Name Position Salary SchoolNum School School Phone S21 Barry Brightwater School Dean MH47 Happiness x005 S37 Deloris Delight Lecturer LH53 Hopeless Causes x003 S14 Carrie Cumbersome Professor LH53 Hopeless Causes x003 S09 Albert Algorithm School Dean 9000 XS67 Low Self Esteem x007 S05 Edwina Elocution School Dean LH53 Hopeless Causes x003 S41 Frank Forensic Cleaner 9000 MH47 Happiness x005

25 Example: What functional dependencies can you identify in the following relation (assuming the data is representative)? List only the direct dependencies StaffNum Name Position Salary SchoolNum School School Phone S21 Barry Brightwater School Dean MH47 Happiness x005 S37 Deloris Delight Lecturer LH53 Hopeless Causes x003 S14 Carrie Cumbersome Professor LH53 Hopeless Causes x003 S09 Albert Algorithm School Dean 9000 XS67 Low Self Esteem x007 S05 Edwina Elocution School Dean LH53 Hopeless Causes x003 S41 Frank Forensic Cleaner 9000 MH47 Happiness x005

26 Example: What functional dependencies can you identify in the following relation (assuming the data is representative)? List only the direct dependencies StaffNum Name Position Salary SchoolNum School School Phone S21 Barry Brightwater School Dean MH47 Happiness x005 S37 Deloris Delight Lecturer LH53 Hopeless Causes x003 S14 Carrie Cumbersome Professor LH53 Hopeless Causes x003 S09 Albert Algorithm School Dean 9000 XS67 Low Self Esteem x007 S05 Edwina Elocution School Dean LH53 Hopeless Causes x003 S41 Frank Forensic Cleaner 9000 MH47 Happiness x005

27 FD s and PK s A primary key is simply a more restrictive type of FD - a FD in which the value of the determinant is unique eg. In the relation: EMP_DEPT (EmpID, Name, Address, DeptNo, DeptName) we have the FDs: EmpID Name, Address, DeptNo, DeptName DeptNo DeptName In any instance of EMP_DEPT the same DeptNo may occur many times, but the value for EmpID (the primary key) is unique

28 Deriving PK s from FD s If we do not know the candidate key(s) of a relation, they can be found: - From the semantics (meaning) of the relation - By examining the FDs that occur in the relation - we can use a dependency diagram to identify the minimum combination of attributes from which all others can be found

29 Example: What is the candidate key of this relation? SchoolNumàSchool, Phone StaffNum Name Position Salary SchoolNum School School Phone S21 Barry Brightwater School Dean MH47 Happiness x005 S37 Deloris Delight Lecturer LH53 Hopeless Causes x003 S14 Carrie Cumbersome Professor LH53 Hopeless Causes x003 S09 Albert Algorithm School Dean 9000 XS67 Low Self Esteem x007 S05 Edwina Elocution School Dean LH53 Hopeless Causes x003 S41 Frank Forensic Cleaner 9000 MH47 Happiness x005 Here, staffnum is the determinant Name, Position, salary and SchoolNum are determined by staffnum

30 Dependency Diagrams

31 4. Normal Forms

32 Normal Forms - As above, we are most interested in 1NF, 2NF, 3NF and BCNF - For practical purposes, we usually aim to have relations in 3NF or BCNF, although denormalisation can sometimes be necessary for performance reasons

33 1NF -- BCNF Each NF become progressively more restrictive the higher the NF; the definition of any NF includes the definition of the preceding NF - 1NF:All valid relations are in 1NF - 2NF:1NF PLUS no partial functional dependencies - 3NF:2NF PLUS no transitive functional dependencies - BCNF: 3NF PLUS all determinants are candidate keys

34 First Normal Form (1NF) - For a relation to be in 1NF, it needs to be a valid relation - No repeating groups or nesting in relations - This relation is NOT in 1NF (i.e., it is unnormalised) StudentID Name Course OfferingNo Semester Year Grade UnitCode Title S1 Kyle IT HD ICT231 Systems Analysis D ICT208 BI T&T S2 Helen IT D ICT231 Systems Analysis C ICT218 Databases N ICT218 Databases

35 Solution StudentID Name Course OfferingNo Semester Year Grade UnitCode Title S1 Kyle IT HD ICT231 Systems Analysis D ICT208 BI T&T S2 Helen IT D ICT231 Systems Analysis C ICT218 Databases N ICT218 Databases - Repeat StdID, Name and Course for each tuple StudentID Name Course OfferingNo Semester Year Grade UnitCode Title S1 Kyle IT HD ICT231 Systems Analysis S1 Kyle IT D ICT208 BI T&T S2 Helen IT D ICT231 Systems Analysis S2 Helen IT C ICT218 Databases S2 Helen IT N ICT218 Databases - Can you find examples of modification anomalies in this design?

36 Solution StudentID Name Course OfferingNo Semester Year Grade UnitCode Title S1 Kyle IT HD ICT231 Systems Analysis D ICT208 BI T&T S2 Helen IT D ICT231 Systems Analysis C ICT218 Databases N ICT218 Databases - Repeat StdID, Name and Course for each tuple StudentID Name Course OfferingNo Semester Year Grade UnitCode Title S1 Kyle IT HD ICT231 Systems Analysis S1 Kyle IT D ICT208 BI T&T S2 Helen IT D ICT231 Systems Analysis S2 Helen IT C ICT218 Databases } S2 Helen IT N ICT218 Databases Update Anomaly - Can you find examples of modification anomalies in this design?

37 Solution StudentID Name Course OfferingNo Semester Year Grade UnitCode Title S1 Kyle IT HD ICT231 Systems Analysis D ICT208 BI T&T S2 Helen IT D ICT231 Systems Analysis C ICT218 Databases N ICT218 Databases - Repeat StdID, Name and Course for each tuple StudentID Name Course OfferingNo Semester Year Grade UnitCode Title S1 Kyle IT HD ICT231 Systems Analysis S1 Kyle IT D ICT208 BI T&T S2 Helen IT D ICT231 Systems Analysis S2 Helen IT C ICT218 Databases S2 Helen IT N ICT218 Databases Insertion Anomaly Add student Jones: S3, Jones - Can you find examples of modification anomalies in this design?

38 Solution StudentID Name Course OfferingNo Semester Year Grade UnitCode Title S1 Kyle IT HD ICT231 Systems Analysis D ICT208 BI T&T S2 Helen IT D ICT231 Systems Analysis C ICT218 Databases N ICT218 Databases - Repeat StdID, Name and Course for each tuple StudentID Name Course OfferingNo Semester Year Grade UnitCode Title S1 Kyle IT HD ICT231 Systems Analysis S1 Kyle IT D ICT208 BI T&T S2 Helen IT D ICT231 Systems Analysis S2 Helen IT C ICT218 Databases S2 Helen IT N ICT218 Databases Insertion Anomaly Add unit ASAD: ICT353, SAD - Can you find examples of modification anomalies in this design?

39 Solution StudentID Name Course OfferingNo Semester Year Grade UnitCode Title S1 Kyle IT HD ICT231 Systems Analysis D ICT208 BI T&T S2 Helen IT D ICT231 Systems Analysis C ICT218 Databases N ICT218 Databases - Repeat StdID, Name and Course for each tuple StudentID Name Course OfferingNo Semester Year Grade UnitCode Title S1 Kyle IT HD ICT231 Systems Analysis S1 Kyle IT D ICT208 BI T&T S2 Helen IT D ICT231 Systems Analysis S2 Helen IT C ICT218 Databases S2 Helen IT N ICT218 Databases Deletion Anomaly - Can you find examples of modification anomalies in this design?

40 Second Normal Form (2NF) - A relation is in 2NF if: - It is in 1NF, AND - There are no partial functional dependencies - A partial functional dependency exists where a nonkey attribute is dependent on only part of the key, rather than the whole of the key

41 Partial Functional Dependencies - Given the relation below: - Where the PK is StudentID, OfferingNo - and the FD s are: - StudentID à Name, Course - OfferingNo à Semester, Year, UnitCode, Title - StudentID, OfferingNo à Grade StudentID Name Course OfferingNo Semester Year Grade UnitCode Title S1 Kyle IT HD ICT231 Systems Analysis S1 Kyle IT D ICT208 BI T&T S2 Helen IT D ICT231 Systems Analysis S2 Helen IT C ICT218 Databases S2 Helen IT N ICT218 Databases

42 Partial Functional Dependencies - Given the relation below: - Where the PK is StudentID, OfferingNo - and the FD s are: - StudentID à Name, Course [PFD] - OfferingNo à Semester, Year, UnitCode, Title [PFD] - StudentID, OfferingNo à Grade StudentID Name Course OfferingNo Semester Year Grade UnitCode Title S1 Kyle IT HD ICT231 Systems Analysis S1 Kyle IT D ICT208 BI T&T S2 Helen IT D ICT231 Systems Analysis S2 Helen IT C ICT218 Databases S2 Helen IT N ICT218 Databases

43 Modification Anomalies with PFD s - There are a number of anomalies that arise from the present design: - If we were to change the title of ICT218, then we would have to update the title for every offering of the unit - If we were to delete the only offering of unit ICT208, then we would lose all details of that unit - Could we insert a new unit into this table? StudentID Name Course OfferingNo Semester Year Grade UnitCode Title S1 Kyle IT HD ICT231 Systems Analysis S1 Kyle IT D ICT208 BI T&T S2 Helen IT D ICT231 Systems Analysis S2 Helen IT C ICT218 Databases S2 Helen IT N ICT218 Databases

44 Solution The solution (for the PFDs) is to create relations based on the FD s where the determinants are components of the primary key: Relation1 (StdID, Name, Course) Relation2 (OfferingNo, UnitCode, Title, Semester, Year) There is also a further functional dependency in the table on the previous slide: StdID, OfferingNo Grade As the determinant of this FD IS the PK it will form a third relation: Relation3 (OfferingNo, StdID, Grade)

45 So - Now each nonkey attribute is fully FD on the key of the relation it is in, so each relation is in at least 2NF - We have also eliminated the potential anomalies identified in the original relation.

46 Third Normal Form (3NF) - A relation is in 3NF IF: - It is in 2NF, and - there are no transitive functional dependencies (TFD s) - A TFD exists where a non-key attribute is determined by another non-key attribute

47 Example Relation1 (StdID, Name, Course) Relation2 (OfferingNo, Year, Semester, UnitCode, Title) Relation3 (StdID, OfferingNo, Grade) There is a transitive dependency in Relation2: OfferingNo UnitCode UnitCode Title The TD is OfferingNo à Title because Unit Code is a non-key attribute What kinds of anomalies are present in the current design? StudentID Name Course S1 Kyle IT S2 Helen IT OfferingNo Semester Year UnitCode Title ICT231 Systems Analysis ICT208 BI T&T ICT218 Databases ICT218 Databases StudentID OfferingNo Grade S HD S D S D S C S N

48 Example Relation1 (StdID, Name, Course) Relation2 (OfferingNo, Year, Semester, UnitCode, Title) Relation3 (StdID, OfferingNo, Grade) There is a transitive dependency in Relation2: OfferingNo UnitCode UnitCode Title The TD is OfferingNo à Title because Unit Code is a non-key attribute What kinds of anomalies are present in the current design? StudentID Name Course S1 Kyle IT S2 Helen IT OfferingNo Semester Year UnitCode Title ICT231 Systems Analysis ICT208 BI T&T ICT218 Databases ICT218 Databases StudentID OfferingNo Grade S HD S D S D S C S N

49 Solution To transform a relation in 2NF only to a set of relations each in at least 3NF, - Create a set of relations based on the full and non-transitive dependencies in the original: Relation2-1 (OfferingNo, Year, Semester, UnitCode) Relation2-2 (UnitCode, Title) - Now each attribute is fully and nontransitively dependent on the key of its relation, so each relation is in (at least) 3NF - Note that we can join the relations on the key and foreign key - Note too, that the original relation was about offerings AND units. The new relations are both about one thing only. OfferingNo Semester Year UnitCode ICT ICT ICT ICT218 UnitCode Title ICT231 Systems Analysis ICT208 BI T&T ICT218 Databases

50 Cheat Sheet Note: We have a compound primary key: AID,BID PFD TFD AID BID Cdata Edata Fdata Gdata 1 A xxx xxx xxx xxx 1 B xxx xxx xxx xxx 1 B xxx xxx xxx xxx

51 Examples Given the following relation and functional dependencies: 1. What is (are) the candidate key(s)? 2. Which NF is the relation in? 3. Convert the relation into a relation or set of relations in at least 3NF STUDENT (StudentNo, Name, PrimaryMajor, School) StudentNo à Name, PrimaryMajor PrimaryMajor à School

52 Examples Given the following relation and functional dependencies: 1. What is (are) the candidate key(s)? 2. Which NF is the relation in? 3. Convert the relation into a relation or set of relations in at least 3NF STUDENT (StudentNo, Name, PrimaryMajor, School) StudentNo à Name, PrimaryMajor PrimaryMajor à School

53 Examples Given the following relation and functional dependencies: 1. What is (are) the candidate key(s)? 2. Which NF is the relation in? 3. Convert the relation into a relation or set of relations in at least 3NF STUDENT (StudentNo, Name, PrimaryMajor, School) StudentNo à Name, PrimaryMajor PrimaryMajor à School

54 Examples Given the following relation and functional dependencies: 1.What is (are) the candidate key(s)? 2.Which NF is the relation in? 3.Convert the relation into a relation or set of relations in at least 3NF STUDENT (StudentNo, Name, PrimaryMajor, School) StudentNo à Name, PrimaryMajor PrimaryMajor à School 1NF?

55 Examples Given the following relation and functional dependencies: 1.What is (are) the candidate key(s)? 2.Which NF is the relation in? 3.Convert the relation into a relation or set of relations in at least 3NF STUDENT (StudentNo, Name, PrimaryMajor, School) StudentNo à Name, PrimaryMajor PrimaryMajor à School 1NF Yes, it is a valid relation.

56 Examples Given the following relation and functional dependencies: 1.What is (are) the candidate key(s)? 2.Which NF is the relation in? 3.Convert the relation into a relation or set of relations in at least 3NF STUDENT (StudentNo, Name, PrimaryMajor, School) StudentNo à Name, PrimaryMajor PrimaryMajor à School 1NF Yes, it is a valid relation. 2NF?

57 Examples Given the following relation and functional dependencies: 1.What is (are) the candidate key(s)? 2.Which NF is the relation in? 3.Convert the relation into a relation or set of relations in at least 3NF STUDENT (StudentNo, Name, PrimaryMajor, School) StudentNo à Name, PrimaryMajor PrimaryMajor à School 1NF Yes, it is a valid relation. 2NF Yes, no non-key attributes determine by partial key

58 Examples Given the following relation and functional dependencies: 1.What is (are) the candidate key(s)? 2.Which NF is the relation in? 3.Convert the relation into a relation or set of relations in at least 3NF STUDENT (StudentNo, Name, PrimaryMajor, School) StudentNo à Name, PrimaryMajor PrimaryMajor à School 1NF Yes, it is a valid relation. 2NF Yes, no non-key attributes determine by partial key 3NF?

59 Examples Given the following relation and functional dependencies: 1.What is (are) the candidate key(s)? 2.Which NF is the relation in? 3.Convert the relation into a relation or set of relations in at least 3NF STUDENT (StudentNo, Name, PrimaryMajor, School) StudentNo à Name, PrimaryMajor PrimaryMajor à School 1NF Yes, it is a valid relation. TFD 2NF Yes, no non-key attributes determine by partial key 3NF No, It is Transitive, a non-key determines a non-key

60 Examples Given the following relation and functional dependencies: 1. What is (are) the candidate key(s)? 2. Which NF is the relation in? 3. Convert the relation into a relation or set of relations in at least 3NF STUDENT (StudentNo, Name, PrimaryMajor, School) StudentNo à Name, PrimaryMajor PrimaryMajor à School SOLUTION: STUDENT (StudentNo, Name, PrimaryMajor) MAJOR (PrimaryMajor, School) TFD

61 Examples Given the following relation and functional dependencies: 1.What is (are) the candidate key(s)? 2.Which NF is the relation in? 3.Convert the relation into a relation or set of relations in at least 3NF ENROLS (StudentNo, Name, UnitCode, UnitName, Grade) StudentNo à Name UnitCode à UnitName StudentNo, UnitCode à Grade

62 Examples Given the following relation and functional dependencies: 1.What is (are) the candidate key(s)? 2.Which NF is the relation in? 3.Convert the relation into a relation or set of relations in at least 3NF ENROLS (StudentNo, Name, UnitCode, UnitName, Grade) StudentNo à Name UnitCode à UnitName StudentNo, UnitCode à Grade

63 Examples Given the following relation and functional dependencies: 1.What is (are) the candidate key(s)? 2.Which NF is the relation in? 3.Convert the relation into a relation or set of relations in at least 3NF ENROLS (StudentNo, Name, UnitCode, UnitName, Grade) StudentNo à Name UnitCode à UnitName StudentNo, UnitCode à Grade 1NF Yes, it is a valid relation.

64 Examples Given the following relation and functional dependencies: 1.What is (are) the candidate key(s)? 2.Which NF is the relation in? 3.Convert the relation into a relation or set of relations in at least 3NF PFD PFD ENROLS (StudentNo, Name, UnitCode, UnitName, Grade) StudentNo à Name UnitCode à UnitName StudentNo, UnitCode à Grade 1NF Yes, it is a valid relation. 2NF No, non-key attributes determine by partial key

65 Examples Given the following relation and functional dependencies: 1.What is (are) the candidate key(s)? 2.Which NF is the relation in? 3.Convert the relation into a relation or set of relations in at least 3NF PFD PFD ENROLS (StudentNo, Name, UnitCode, UnitName, Grade) SOLUTION STUDENTS (StudentNo, Name) UNITS (UnitCode, UnitName) ENROLS (StudentNo, UnitCode, Grade)

66 Examples Given the following relation and functional dependencies: 1.What is (are) the candidate key(s)? 2.Which NF is the relation in? 3.Convert the relation into a relation or set of relations in at least 3NF COORDINATES (UnitCode, Semester, Option, Coordinator) UnitCode, Semester, Option à Coordinator

67 Examples Given the following relation and functional dependencies: 1.What is (are) the candidate key(s)? 2.Which NF is the relation in? 3.Convert the relation into a relation or set of relations in at least 3NF COORDINATES (UnitCode, Semester, Option, Coordinator) UnitCode, Semester, Option à Coordinator

68 Examples Given the following relation and functional dependencies: 1.What is (are) the candidate key(s)? 2.Which NF is the relation in? 3.Convert the relation into a relation or set of relations in at least 3NF COORDINATES (UnitCode, Semester, Option, Coordinator) UnitCode, Semester, Option à Coordinator

69 Examples Given the following relation and functional dependencies: 1.What is (are) the candidate key(s)? 2.Which NF is the relation in? 3.Convert the relation into a relation or set of relations in at least 3NF COORDINATES (UnitCode, Semester, Option, Coordinator) UnitCode, Semester, Option à Coordinator 1NF Yes, it is a valid relation. 2NF Yes, no PFD, no non-key attributes determine by partial key 3NF Yes, no TFDs, no non-key determines a non-key

70 Examples Given the following relation and functional dependencies: 1. What is (are) the candidate key(s)? 2. Which NF is the relation in? 3. Convert the relation into a relation or set of relations in at least 3NF SHOP (ShopNo, ItemNo, Date, QtySold) Each shop sells a number of items on each day Shop No Item No Date S1 M2 3/10 4 S1 M3 3/10 4 S2 M2 3/10 2 S1 M2 4/10 7 Qty Sold

71 Examples Given the following relation and functional dependencies: 1. What is (are) the candidate key(s)? 2. Which NF is the relation in? 3. Convert the relation into a relation or set of relations in at least 3NF SHOP (ShopNo, ItemNo, Date, QtySold) Each shop sells a number of items on each day Shop No Item No Date S1 M2 3/10 4 S1 M3 3/10 4 S2 M2 3/10 2 S1 M2 4/10 7 Qty Sold

72 Examples Given the following relation and functional dependencies: 1. What is (are) the candidate key(s)? 2. Which NF is the relation in? 3. Convert the relation into a relation or set of relations in at least 3NF SHOP (ShopNo, ItemNo, Date, QtySold) Each shop sells a number of items on each day Shop No Item No Date S1 M2 3/10 4 S1 M3 3/10 4 S2 M2 3/10 2 S1 M2 4/10 7 Qty Sold

73 Examples Given the following relation and functional dependencies: 1. What is (are) the candidate key(s)? 2. Which NF is the relation in? 3. Convert the relation into a relation or set of relations in at least 3NF SHOP (ShopNo, ItemNo, Date, QtySold) Each shop sells a number of items on each day Shop No Item No Date S1 M2 3/10 4 S1 M3 3/10 4 S2 M2 3/10 2 S1 M2 4/10 7 1NF Yes, it is a valid relation. 2NF Yes, no PFD, no non-key attributes determine by partial key 3NF Yes, no TFDs, no non-key determines a non-key Qty Sold

74 Examples Given the following relation and functional dependencies: 1. What is (are) the candidate key(s)? 2. Which NF is the relation in? 3. Convert the relation into a relation or set of relations in at least 3NF APPLICATION (ApplicNo, Customer, CustAddress, DateApproved) Each loan application is by one customer but each customer may make many applications ApplicNo Customer Address Date Appr X97 JoeBlog Perth 2/3 X99 Vicki Sydney 3/3 Y72 JoeBlog Perth 3/3

75 Examples Given the following relation and functional dependencies: 1. What is (are) the candidate key(s)? 2. Which NF is the relation in? 3. Convert the relation into a relation or set of relations in at least 3NF APPLICATION (ApplicNo, Customer, CustAddress, DateApproved) Each loan application is by one customer but each customer may make many applications ApplicNo Customer Address Date Appr X97 JoeBlog Perth 2/3 X99 Vicki Sydney 3/3 Y72 JoeBlog Perth 3/3

76 Examples Given the following relation and functional dependencies: 1. What is (are) the candidate key(s)? 2. Which NF is the relation in? 3. Convert the relation into a relation or set of relations in at least 3NF APPLICATION (ApplicNo, Customer, CustAddress, DateApproved) Each loan application is by one customer but each customer may make many applications ApplicNo Customer Address Date Appr X97 JoeBlog Perth 2/3 X99 Vicki Sydney 3/3 Y72 JoeBlog Perth 3/3

77 Examples Given the following relation and functional dependencies: 1. What is (are) the candidate key(s)? 1NF Yes, it is a valid relation. 2NF Yes, no PFD, no non-key attributes determine by partial key 3NF No, there is a non-key determines a non-key 2. Which NF is the relation in? 3. Convert the relation into a relation or set of relations in at least 3NF APPLICATION (ApplicNo, Customer, CustAddress, DateApproved) Each loan application is by one customer but each customer may make many applications ApplicNo Customer Address Date Appr X97 JoeBlog Perth 2/3 X99 Vicki Sydney 3/3 Y72 JoeBlog Perth 3/3 TFD

78 Examples Part No Description Vendor Address UnitCost 1234 Logic Chip Fast Chips Perth Smart Chips Sydney Memory chip Fast Chips Perth 3.00 Quality Chips Sydney 2.00 Smart Chips Sydney 5.00 (a) Convert this table to a single relation (called PART-SUPPLIER) in first normal form. Illustrate the relation with the same sample data. (b) List the functional dependencies in PART-SUPPLIER and identify the candidate key(s). (c) Convert PART-SUPPLIER to a set of relations in at least third normal form.

79 Examples Part No Description Vendor Address UnitCost 1234 Logic Chip Fast Chips Perth Smart Chips Sydney Memory chip Fast Chips Perth NF NO! It is not a valid relation. Quality Chips Sydney 2.00 Smart Chips Sydney 5.00 (a) Convert this table to a single relation (called PART-SUPPLIER) in first normal form. Illustrate the relation with the same sample data. (b) List the functional dependencies in PART-SUPPLIER and identify the candidate key(s). (c) Convert PART-SUPPLIER to a set of relations in at least third normal form.

80 Examples Part No Description Vendor Address UnitCost 1234 Logic Chip Fast Chips Perth Logic Chip Smart Chips Sydney Memory chip Fast Chips Perth Memory chip Quality Chips Sydney Memory chip Smart Chips Sydney NF Fix it. (a) Convert this table to a single relation (called PART-SUPPLIER) in first normal form. Illustrate the relation with the same sample data. (b) List the functional dependencies in PART-SUPPLIER and identify the candidate key(s). (c) Convert PART-SUPPLIER to a set of relations in at least third normal form.

81 Examples Part No Description Vendor Address UnitCost 1234 Logic Chip Fast Chips Perth Logic Chip Smart Chips Sydney Memory chip Fast Chips Perth Memory chip Quality Chips Sydney Memory chip Smart Chips Sydney 5.00 (a) Convert this table to a single relation (called PART-SUPPLIER) in first normal form. Illustrate the relation with the same sample data. (b) List the functional dependencies in PART-SUPPLIER and identify the candidate key(s). (c) Convert PART-SUPPLIER to a set of relations in at least third normal form.

82 Examples Part No Description Vendor Address UnitCost 1234 Logic Chip Fast Chips Perth Logic Chip Smart Chips Sydney Memory chip Fast Chips Perth Memory chip Quality Chips Sydney Memory chip Smart Chips Sydney 5.00 (a) Convert this table to a single relation (called PART-SUPPLIER) in first normal form. Illustrate the relation with the same sample data. (b) List the functional dependencies in PART-SUPPLIER and identify the candidate key(s). (c) Convert PART-SUPPLIER to a set of relations in at least third normal form.

83 Examples Part No Description Vendor Address UnitCost 1234 Logic Chip Fast Chips Perth Logic Chip Smart Chips Sydney Memory chip Fast Chips Perth Memory chip Quality Chips Sydney Memory chip Smart Chips Sydney NF Yes, we fixed it. (a) Convert this table to a single relation (called PART-SUPPLIER) in first normal form. Illustrate the relation with the same sample data. (b) List the functional dependencies in PART-SUPPLIER and identify the candidate key(s). (c) Convert PART-SUPPLIER to a set of relations in at least third normal form.

84 Examples Part No Description Vendor Address UnitCost 1234 Logic Chip Fast Chips Perth Logic Chip Smart Chips Sydney Memory chip Fast Chips Perth Memory chip Quality Chips Sydney Memory chip Smart Chips Sydney NF Yes, we fixed it. (a) Convert this table to a single relation (called PART-SUPPLIER) in first normal 2NF form.? Illustrate the relation with the same sample data. (b) List the functional dependencies in PART-SUPPLIER and identify the candidate key(s). (c) Convert PART-SUPPLIER to a set of relations in at least third normal form.

85 Examples PFD PFD Part No Description Vendor Address UnitCost 1234 Logic Chip Fast Chips Perth Logic Chip Smart Chips Sydney Memory chip Fast Chips Perth Memory chip Quality Chips Sydney Memory chip Smart Chips Sydney NF Yes, we fixed it. (a) Convert this table to a single relation (called PART-SUPPLIER) in first normal 2NF form. No, we Illustrate have 2 the Partial relation Functional with the Dependencies same sample data. (b) List the functional dependencies in PART-SUPPLIER and identify the candidate key(s). (c) Convert PART-SUPPLIER to a set of relations in at least third normal form.

86 Examples PFD PFD Part No Description Vendor Address UnitCost 1234 Logic Chip Fast Chips Perth Logic Chip Smart Chips Sydney Memory chip Fast Chips Perth Memory chip Quality Chips Sydney Memory chip Smart Chips Sydney 5.00 SOLUTION (a) Convert this table to a single relation (called PART-SUPPLIER) in first normal PART form. (PartNo, Illustrate Description) the relation with the same sample data. (b) VENDOR List the functional (Vendor, Address) dependencies in PART-SUPPLIER and identify the candidate PART-SUPPLIER key(s). (PartNo, Vendor, UnitCost) (c) Convert PART-SUPPLIER to a set of relations in at least third normal form.

87 Higher Normal Forms 1NF, 2NF, and 3NF are based largely on functional dependencies Recall: A relation is in 1NF if there are no multi-valued (or nested) attributes A relation is in 2NF if it is in 1NF AND there exists no partial functional dependencies A relation is in 3NF if it is in 2NF AND there exists no transitive functional dependencies

88 BCNF - Boyce-Codd Normal Form (BCNF) - Redundancies can still exist in relations in 3NF - Consider the following relation: - STUDENT_ADVISOR (StudentID, AdvisorName, Major) - Where: -a student can have many majors -a staff member will only advise for one major -a major can have more than one staff member as advisor - There are two Functional Dependencies: StudentID, Major à AdvisorName AdvisorName à Major StudentID AdvisorName Major 654 Bill BIS 655 Bob GT 656 Hui Min CS 656 Mary GT 657 Shabnam CFISM 658 Bill BIS Is the relation in 3NF, and are there any anomalies?

89 Example In the relation below, we have part of the key being determined by a non-key attribute Part of the key (Major), determined by non-key attribute (AdvisorName)

90 BCNF Definition We can see from the previous slide that 3NF does not guarantee removal of all anomalies -BCNF is a stricter version of 3NF - A relation is in BCNF if: It is in 3NF, and Every determinant is a candidate key

91 Solution Are there any modification anomalies present now?

92 BCNF Formal Stuff: Note that: All relations in BCNF are in 3NF Most relations in 3NF are also in BCNF Only when there is a FD X à Y where Y is a key attribute X is not a key of the relation is the relation in 3NF but not BCNF eg.( A, B, C ) with FDs AB à C and C à B candidate keys areab, AC Relation is not in BCNF, because in C à B, B is a key attribute C is not a key

93 5. Some limitations of normalisation

94 A final word on normalisation Normalisation helps to create a 'good' design However, don't be obsessive about it: eg.(name, Street, Suburb, Postcode) is in 2NF Name Ò Street, Suburb Suburb Ò Postcode should it be converted to two 3NF relations?? Codd spoke of the Minimal meaningful unit Good design also takes into account processing requirements (more later) - in practice, creating more tables means more joins, so slower processing this is the tradeoff for avoiding redundancy Need to look at how the database will be used in practice when making decisions about denormalisation (later)

95 6. Revision Questions

96 Outline - Relational design guidelines - Update anomalies - Functional dependency - Normal forms: 1NF, 2NF, 3NF - Limitations of the normalisation process

97 Revision questions Now. -What are the types of update anomalies associated with redundant information in tables? -Why is normalisation done? -What does partial functional dependency mean? -What does transitive functional dependency mean? -Define: 1NF, 2NF, 3NF, BCNF -What limitations are there that may be associated with normalisation? Later. -Can you identify which normal form a given relation is in? -Can you normalise a given relation to a more appropriate normal form?