Normalisation Chapter2 Contents

Transcription

1 Contents Objective Superkey & Candidate Keys Primary, Alternate and Foreign Keys Functional Dependence Using Instances Normalisation Introduction Normalisation Problems Normalisation Normalisation Why? Some Anomalies Relation : ASSIGN Functional Dependencies DETERMINANT Normalisation Forms First normal form Second Normal Form New 2NF relations Two new relations Third Normal Form NF--->3NF Normalisation Review But what a about doing an example Another Normalisation Example Another Normalisation Example Second Normal Form Another Normalisation Example Third Normal Form Boyce-Codd Normal Form (BCNF) NF Table Not in BCNF Anomalies in STUDENT_ADVISOR Converting a Relation to BCNF Decomposition into BCNF

2 Fourth Normal Forms Multivalued Dependencies Multivalued Dependencies (MVDs) Removing Multivalued Dependencies (MVDs) from a relation Fourth Normal Forms Higher Normal Forms Denormalisation Denormalization for Performance Other Design Issues Objective To understand the problems associated with tables which are not designed well and to understand the concepts of functional dependency, multivalued dependency, Nomalisation process and denormalisation. Contents 64

3 Keys Functional dependency Anomalies 1 st NF 2 nd NF 3 rd NF BCNF 4 th NF Higher Normal forms Denormalisation process Superkey & Candidate Keys Any set of attributes that uniquely identifies each row in a relation is termed a superkey A candidate key is a superkey such that no proper subset is a superkey within the relation o there maybe several candidate keys Primary, Alternate and Foreign Keys The candidate key that is selected to identify tuples uniquely within the relation is called primary key. The candidate keys that are not selected to be the primary key are called alternate keys. 65

4 A foreign key is an attribute or set of attributes within one relation that matches the candidate key of some relation Primary Key example Give an example of a superkey : (WorkerID, Name)-Superkey But is it a candidate key? No because it is not minimal Give examples of candidate keys: WorkID is a candidate key, Name is a candidate key WorkerID is the primary key; Name is an alternate key Exercises 66

5 Functional Dependence An attribute, (B), is functionally dependent on another attribute, (A) (or possible a collection of attributes), if each value of attribute (A) determines one and only one value in attribute (B) alternatively A functionally determines B The value of A determines the value of B The value of B depends on the value of A Functional dependence is the computer term for what is really a simple concept. Think of the definition as follows. If we have a value for attribute A, do we know that will always be able to find at 67 most a single value for B? If so, B is functionally dependent on A and A functionally determines B, and this dependence is usually illustrated using an arrow A --> B

6 Functional Dependence Exercises 68

7 Consider the following relation (capitalised letters are attribute names, lowercase letters and numbers are values) Which of the following proposed functional dependencies seem to apply to X? Identify a possible key for X Identify a possible key for X D (why?)why not AD or DE? 69

8 Using Instances Using just the instances of a relation should not be used to prove that an attribute or a combination of attributes is a candidate key. Instances only show that some attributes can not be candidate keys but never show that they can o recall attribute Name from previous exercise. What if we had selected Name as the primary key and then another worker joined with the name Barrister? Invalidates the choice of Name as primary key USE your knowledge of what an attribute means in the real-world in order to decide if duplicates will arise Normalisation Introduction Introduced by Codd together with relational database theory o Originally Codd defined three normal forms o later expanded to Boyce-Codd and fourth and fifth normal forms 70

9 Normalisation Problems Data redundancy (repetition) - The four rows for worker 1412 repeat the same name and skill type information o wastes space o leads to loss of data integrity (loss of consistency) 71

10 i.e. Update anomaly o C.Nemo skill is in error but only the first row is corrected Deletion anomaly o Coulomb (Worker-Id 1311) is away and building he worked has finished. If it is decided to delete the row containing information about the completed building then the rest of information about 1311 will be lost 72

11 Insertion anomaly o If we hire S.Spandolf but have not decided in which building he works and also assume null entries are not allowed then we can not enter information regarding the new employee (until he has been assigned to a building) Normalisation Normalisation: Why? How? o Check the database design o Identify problems (if any) o provide methods for correcting any problems o Using decomposition a process of splitting relations into multiple relations to eliminate anomalies and maintain data integrity 73

12 We have introduced the relational data model, its structure and the various ways of manipulating the data (with an emphasis on SQL). At all times we have used relations (tables) which were ready to use. How to move from a unrelational table(s) to relational tables is achieved using the normalisation process. Normalisation enables us to analyse the design of a relational database to see whether it is good or bad. In particular, normalisation gives us a method for identifying the existence of potential problems, called update anomalies, in the design. The normalisation process also supplies methods for correcting these problems. Normalisation Why? Formal measure of why one grouping of attributes may be better than another Each normal form requires that a relation satisfies a criteria for that form and this eliminates a different kind of redundancy Normalised relations will remain consistent following database operations and will store each fact only once Database operations applied to unnormalised relations may lead to anomalies Some Anomalies 74

13 Relation : ASSIGN Adding row (ASSIGN, <S85,35,P1,9>) causes Insertion Anomaly. Why? o two conflicting budgets for P1 Delete row(assign, <S79,27,P3,1>) causes Deletion Anomaly. Why? o removes project budget for P3 75

14 Functional Dependencies Determine the FDs. o Project Project_budget o Person-id, Project Time Spent on Project Two attributes are FUNCTIONALLY DEPENDENT if a value for ONE attribute specifies a SINGLE value for the other attribute 76

15 DETERMINANT Grade Rate of Pay Driver Crane Driver Keyboard Operator Systems Analyst The Rate of Pay is functionally dependent on Grade or, Grade determines Rate of Pay or, grade Rate of Pay. Grade is a DETERMINANT Integrity Rules entity integrity o Primary Key o primary key MUST NOT be NULL combined with the table property for unique row. Primary key must be both not null and unique o guarantees that each entity will have a unique identity The primary key of a relation is the attribute or collection of attributes that uniquely identifies a given row. It is common practice to underline the primary key of the relation. The primary key provides a mechanism for entity integrity (the rule that states that in any relation there must be always be a primary key, and that no part of the primary key may be null) There is another kind of key that is extremely important. An attribute in one relation that is required to match the primary key of another relation is called a foreign key. Foreign keys provide a mechanism for explicitly specifying relationships between two different relations, as well as a mechanism for ensuring referential integrity. (for example we are not allowed to enter a value in the foreign key if the primary key does not exist. 77

16 referential integrity o Foreign Key o foreign key must have either a null entry or an entry that matches the candidate key value in a table to which it is related Functional Dependencies An attribute (or attributes) of a table is the Primary Key for that table if Translation: o All attributes in the table are functionally dependent on the Primary Key, AND o Where the Primary Key is a collection of attributes (concatenated key), no subcollection of the columns used also exhibits the functional dependence property (Candidate key) 1. The primary key will identify a given row (unique) 2. No portion of the primary key can be an independent primary key Normalisation Forms First normal form Second normal Form Third normal form The process involves various types of normal forms. We will have a close look at the first, second and third normal forms. The idea is that a relation that is in 1NF is better that a relation that is not in 1NF; a relation that is in 2NF is even better and so on. The $xal of this process is to allow us to start with a relation or collection of relations and produce a new collection of relations equivalent to the same collection (i.e., the same information is represented) but is free of problems. 78

17 A relation is in first normal form (1NF) if it does not contain repeating groups Problem resolved o repeating groups (atomic values) A relation that conatins a repeating group is called an unnormalised relation (strictly speaking is not a relation at all). Removal of repeating groups is the starting point; and relations without repeating groups are said to be in first normal form. PACKID TAGNUM INSTDATE SOFTCOST AC /09/ DB /03/ /06/ DB /05/ Normalisation 79

18 Second Normal Form A relation is in second normal form (2NF) if it is in first normal form and no non-key attribute is dependent on only a portion of the primary key o Non-key attribute is an attribute if it is not part of the primary key The dependency diagram shows all the functional dependencies present. Dependency Diagram 80

19 New 2NF relations The way to correct the various problems is o Create a new relation by using the attributes from the offending FD as the attributes in the new relation. The determinant of the FD becomes the key of the new relation o The attribute on the right hand side of the FD is then eliminated from the original relation o If more than one FD prevents the relation from being 2NF, repeat the two steps from above o If the same determinant appears in more than one FD, place all the attributes functionally dependent on this determinant as nonkey attributes in the relation having the determinant as key Software(Packid, Tagnum,Instdate,Softcost) Package(Packid,Packname) PC(Tagnum,CompID) Still though the same problems An example 2NF Consider the following Assign relation 81

20 Consider the following relation The worker name is repeated. If the name of the worker changes, every row recording an assignment of that worker must be updated (update anomaly). The data might become inconsistent, with different rows showing different names for the same worker (because of update anomaly) 82

21 If at some time there are no assignments for the worker, there may be no row in which to keep the worker s name (insertion anomaly) Determine the FDs Example Decomposition Offending FD? Yes, one o WorkerID--->Name o Step1 Worker(WorkerID, Name) 83

22 o Step2 Assign(WorkerID, BLDG-ID, Start-Date) Foreign Key? o Foreign key: WorkerID references Worker Two new relations Third Normal Form A relation is in third normal form (3NF) if it is in second normal form and if the only determinants it contains are candidate keys i.e. It does not contain transitive dependencies. Determinant is an attribute (or collection of attributes) that determines another attribute 84

23 Again drawing a dependency diagram we might see that there exists a determinant attribute. You can draw for PC(Tagnum, compid, Empnum, Empname, location) to see that Empnum determines Empname. To scheme to follow to correct the deficiency in such a relation is that first: for each determinant that is not a candidate key, remove from the relation the attributes that depend on this determinant. Next create a new relation containing all the attributes from the original relatiom that depend on thsi determinant. Finally, make the determinant the primary key of this new relation PC (Tagnum, compid, Empnum, location) EMPLOYEE (Empnum, Empname) 2NF--->3NF The way to correct the various problems is o Create a new relation by removing from the original relation the attributes on the right hand side of the offending FD o Form a new relation consisting of those attributes on both the left and right side of the FD that fail the 3NF criterion. The determinant of the FD is the key o If the new relations are still not 3NF repeat 85

24 A 3NF Example Problems with this table? Consider the following relation If the bonus rate of the skill type changes, every such row must be updated. If a row is deleted, we may lose data giving the bonus rate for a skill type (update and deletion anomalies) If there are currently no permanent employees for a given skill type, there may be no row in which to keep the skill type s bonus rate (insertion anomaly) 86

25 FD for 3NF Example FD: Worker-ID--->Skill-Type FD:Worker-ID--->Bonus-Rate FD:Skill-Type--->Bonus-Rate Key? - Worker-ID Worker(WorkerID, Skill-Type, Bonus-rate) FD Alternative Notation New relations FD: Worker-ID--->Skill-Type FD:Worker-ID--->Bonus-Rate FD:Skill-Type--->Bonus-Rate Step1 o Worker(Worker-ID, Skill-Type) Step2 87

26 o Skill(Skil-Type, Bonus-Rate) Both 3NF Foreign Key? o Foreign Key:Skill-Type references Skill Normalisation Review But what a about doing an example Another Normalisation Example Another Normalisation Example First Normal Form 88

27 Another Normalisation Example Second Normal Form 89

28 Another Normalisation Example Third Normal Form Boyce-Codd Normal Form (BCNF) When a relation has more than one candidate key, anomalies may result even though the relation is in 3NF. E.g. STUDENT_ADVISOR table o SID, Major Advisor, Maj_GPA This reflects the constraint that although a given student may have more than one major, for each major a student has exactly one advisor and one GPA. SID Major Advisor Maj_GPA 90

29 123 Physics Hawking Music Mahler Literature Michener Music Bach Physics Hawking 3.5 There is a second FD Advisor Major Each advisor advises in exactly one major. This is not a transitive dependency. A transitive dependency is a FD between two nonkey attributes. SID Major Advisor Maj_GPA 123 Physics Hawking Music Mahler Literature Michener Music Bach Physics Hawking

30 3NF Table Not in BCNF Anomalies in STUDENT_ADVISOR The table is in 3NF, since there is no partial FDs and no transitive FDs. Howerever, because of the FD between Major and Advisor there are anomalies in the relation: SID Major Advisor Maj_GPA 123 Physics Hawking Music Mahler Literature Michener Music Bach Physics Hawking

31 Update anomalies e.g., replacing Hawking the Physics advisor by Einstein must be made in more than one rows Insertion anomalies can not add a new Computer science advisor before adding at least one student majoring in Computer science Deletion anomalies if student 789 aithdraws from school, we lose the information that Bach advises in Music. SID Major Advisor Maj_GPA 123 Physics Hawking Music Mahler Literature Michener Music Bach Physics Hawking 3.5 The anomalies result from the fact that there is a determinant (Advisor) that is not a candidate key in the relation. SID Major Advisor Maj_GPA 123 Physics Hawking Music Mahler

32 456 Literature Michener Music Bach Physics Hawking 3.5 Boyce-Codd Normal Form (BCNF) Every determinant in the table is a candidate key o Determinant is attribute whose value determines other values in row o 3NF table with one candidate key is already in BCNF Decomposition of Table Structure to Meet BCNF 94

33 Converting a Relation to BCNF A two step procedure. First step: o The relation is modified so that the determinant which is not a candidate key becomes a component of the primary key of the revised relation. o The attribute that is functionaly dependent on that determinant becomes a nonkey attribute. Revised relation schema: SID, Advisor Major, Maj_GPA Now the relation is not in the 2NF 95

34 Step two : eliminate the partial FD. o SID, Advisor Maj_GPA o Advisor Major Decomposition into BCNF Fourth Normal Forms Multivalued Dependencies There are database schemas in BCNF that do not seem to be sufficiently normalized Consider a database o 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 96

35 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). 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 o (database, Sara, DB Concepts) (database, Sara, Ullman) Therefore, it is better to decompose classes into: 97

36 We shall see that these two relations are in Fourth Normal Form (4NF) Multivalued Dependencies (MVDs) A multivalued dependency exists when there are at least three attributes ( for example A,B, and C) in a relation, and for each value of A there is a well-defined set of values of B and a well-defined set of values of C. However, the set of values of B is independent of set C, and vice versa. Example 98

37 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) < y 1, z 1, w 1 > r and < y 1, z 2, w 2 > r o then < y 1, z 1, w 2 > r and < y 1, z 2, w 1 > r Note that since the behavior of Z and W are identical it follows that Y Z if Y W 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: o If Y Z then Y Z o Indeed we have (in above notation) Z 1 = Z 2 The claim follows. Removing Multivalued Dependencies (MVDs) from a relation Divide the relation into two new relations. 99

38 Each of these tables contains two attributes that have a multivalued relationship in the original relation. Conversion to 4NF Fourth Normal Forms Fourth Normal Form (4NF) 100

39 o Table is in BCNF o Has no multiple sets of multivalued dependencies Higher Normal Forms 5 NF o deals with loosless joins, o occur very rearly and difficult to detect in practice o Complex definition Domain-Key Normal form (DKNF) o Its practical utility is quite limited 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 Normalization and Database Design Normalization should be part of the design process E-R Diagram provides macro view Normalization provides micro view of entities o Focuses on characteristics of specific entities o May yield additional entities Difficult to separate normalization from E-R diagramming Denormalisation Normalization is one of many database design goals 101

40 Normalized table requirements o Additional processing o Loss of system speed Normalization purity is difficult to sustain due to conflict in: o Design efficiency o Information requirements o Processing 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 o faster lookup o Extra space and extra execution time for updates o extra coding work for programmer and possibility of error in extra code Alternative 2: use a materialized view defined as account depositor o Benefits and drawbacks same as above, except no extra coding work for programmer and avoids possible errors Other Design Issues Some aspects of database design are not caught by normalization 102

41 Examples of bad database design, to be avoided: o Instead of earnings(company-id, year, amount), use o 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 o 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 103