CSC 426 Chapter 14, Fall 2011

Notre Dame University–Louaize · Principles of Database Systems · 48 pages · Dr. Maya Samaha

All CSC 426 files
CSC 426 Chapter 14, Fall 2011, page 1

Stuck on a question? A tutor can walk you through it.

CSC 426 Chapter 14, Fall 2011, page 2 CSC 426 Chapter 14, Fall 2011, page 3 CSC 426 Chapter 14, Fall 2011, page 4 CSC 426 Chapter 14, Fall 2011, page 5 CSC 426 Chapter 14, Fall 2011, page 6 CSC 426 Chapter 14, Fall 2011, page 7 CSC 426 Chapter 14, Fall 2011, page 8 CSC 426 Chapter 14, Fall 2011, page 9 CSC 426 Chapter 14, Fall 2011, page 10

Showing the first 10 of 48 pages. Download the PDF to see all of it.

More CSC 426 files

Show the text of this chapter
Chapter 14 Introduction to Normalization Using Functional and Multivalued Dependencies Chapter 14 Outline  Informal Design Guidelines for Relation Schemas  Functional Dependencies  Normal Forms Based on Primary Keys  General Definitions of Second and Third Normal Forms  Boyce-Codd Normal Form Introduction  Levels at which we can discuss goodness of relation schemas  Logical (or conceptual) level  Implementation (or physical storage) level  Approaches to database design:  Bottom-up or top-down Informal Design Guidelines for Relation Schemas  Measures of quality  Making sure attribute semantics are clear  Reducing redundant information in tuples  Reducing NULL values in tuples  Disallowing possibility of generating spurious tuples Guideline 1  Design relation schema so that it is easy to explain its meaning  Do not combine attributes from multiple entity types and relationship types into a single relation  Example of violating Guideline 1: Figure 14.3 Guideline 1 (cont’d.) Redundant Information in Tuples and Update Anomalies  Grouping attributes into relation schemas  Significant effect on storage space  Storing natural joins of base relations leads to update anomalies  Types of update anomalies:  Insertion  Deletion  Modification Guideline 2  Design base relation schemas so that no update anomalies are present in the relations  If any anomalies are present:  Note them clearly  Make sure that the programs that update the database will operate correctly Staff and DistributionCenter tables with StaffDistributionCenter table 13 NULL Values in Tuples  May group many attributes together into a “fat” relation  Can end up with many NULLs  Problems with NULLs  Wasted storage space  Problems understanding meaning Guideline 3  Avoid placing attributes in a base relation whose values may frequently be NULL  If NULLs are unavoidable:  Make sure that they apply in exceptional cases only, not to a majority of tuples Guideline 4  Design relation schemas to be joined with equality conditions on attributes that are appropriately related  Guarantees that no spurious tuples are generated  Avoid relations that contain matching attributes that are not (foreign key, primary key) combinations Summary and Discussion of Design Guidelines  Anomalies cause redundant work to be done  Waste of storage space due to NULLs  Difficulty of performing operations and joins due to NULL values  Generation of invalid and spurious data during joins Functional Dependencies  Formal tool for analysis of relational schemas  Enables us to detect and describe some of the above-mentioned problems in precise terms  Theory of functional dependency Definition of Functional Dependency  Constraint between two sets of attributes from the database  Property of semantics or meaning of the attributes  Legal relation states  Satisfy the functional dependency constraints Definition of Functional Dependency (cont’d.)  Given a populated relation  Cannot determine which FDs hold and which do not  Unless meaning of and relationships among attributes known  Can state that FD does not hold if there are tuples that show violation of such an FD Normal Forms Based on Primary Keys  Normalization process  Approaches for relational schema design  Perform a conceptual schema design using a conceptual model then map conceptual design into a set of relations  Design relations based on external knowledge derived from existing implementation of files or forms or reports Normalization of Relations  Takes a relation schema through a series of tests  Certify whether it satisfies a certain normal form  Proceeds in a top-down fashion  Normal form tests Normalization of Relations (cont’d.)  Properties that the relational schemas should have:  Nonadditive join property • Extremely critical  Dependency preservation property • Desirable but sometimes sacrificed for other factors Practical Use of Normal Forms  Normalization carried out in practice  Resulting designs are of high quality and meet the desirable properties stated previously  Pays particular attention to normalization only up to 3NF, BCNF, or at most 4NF  Do not need to normalize to the highest possible normal form Definitions of Keys and Attributes Participating in Keys  Definition of superkey and key  Candidate key  If more than one key in a relation schema • One is primary key • Others are secondary keys First Normal Form  Part of the formal definition of a relation in the basic (flat) relational model  Only attribute values permitted are single atomic (or indivisible) values  Techniques to achieve first normal form  Remove attribute and place in separate relation  Expand the key  Use several atomic attributes First Normal Form (cont’d.)  Does not allow nested relations  Each tuple can have a relation within it  To change to 1NF:  Remove nested relation attributes into a new relation  Propagate the primary key into it  Unnest relation into a set of 1NF relations First normal form (1NF)  Only 1NF is critical in creating appropriate tables for relational databases. All subsequent normal forms are optional.  A table in which the intersection of every column and record contains only one value. 31 DistributionCenter table is not in 1NF 32 Converting DistributionCenter table to 1NF 33 Second Normal Form  Based on concept of full functional dependency  Versus partial dependency  Second normalize into a number of 2NF relations  Nonprime attributes are associated only with part of primary key on which they are fully functionally dependent Third Normal Form  Based on concept of transitive dependency  Problematic FD  Left-hand side is part of primary key  Left-hand side is a nonkey attribute Second normal form (2NF)  A table that is in 1NF and in which the values of each non-primary-key column are determined by the values in all the columns that make up the primary key.  To assess whether a table breaks 2NF form requires identification of the primary key and functional dependencies associated with that table.  2NF only applies to tables with composite primary keys. 36 Functional dependency  Describes the relationship between columns in a table and indicates how columns relate to one another.  For example, consider a table with columns a and b, where b is functionally dependent on a (denoted a → b). If we know the value of a, we find only one value of b in all the records that has this value of a, at any moment in time. However, for a given value of b there may be several different values of a. 37 Second normal form (2NF)  Formal definition of 2NF is a table that is in 1NF and every non-primary-key column is fully functional dependent on the primary key.  Full functional dependency indicates that if a and b are columns of a table, b is fully determined by a, if b is not determined by any subset of a. If b is determined by a subset of a, this is referred to as a partial dependency.  Identification of partial dependencies on the primary key is evidence that a table is breaking 2NF and may suffer from update anomalies. 38 TempStaffAllocation table is not in 2NF 39 Converting TempStaffAllocation table to 2NF 40 Third normal form (3NF)  A table that is in 1NF and 2NF and in which the values in all non-primary-key column can be determined from only the primary key column(s) and no other columns.  The formal definition of 3NF is a table that is in 1NF and 2NF and in which no non- primary-key column is transitively dependent on the primary key. 41 Third normal form (3NF)  A transitive dependency describes a relationship between columns a, b, and c. If a determines b (a b) and b determines c (b → → c), then c is transitively dependent on a via b (provided that b or c does not determine a).  Identification of transitive dependencies on the primary key is evidence that a table is breaking 3NF and may suffer from update anomalies. 42 The StaffDistributionCenter table is not in 3NF 43 Converting StaffDistributionCenter table to 3NF 44 General Definitions of Second and Third Normal Forms More examples Summary  Informal guidelines for good design  Functional dependency  Basic tool for analyzing relational schemas  Normalization:  1NF, 2NF, 3NF,