Chapter 4 The Relational Model and Normalization

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke 2 Relations  Relational DBMS products store data in the form of relations, a special type of table  A relation is a two-dimensional table that has the following characteristics Rows contain data about an entity Columns contain data about attributes of the entity All entries in a column are of the same kind Each column has a unique name Cells of the table hold a single value The order of the columns is unimportant The order of the rows is unimportant No two rows may be identical  Although not all tables are relations, the terms table and relation are normally used interchangeably Table/row/column = file/record/field = relation/tuple/attribute

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke 3 Example: Relation

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke 4 Example: Tables Not Relations

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke 5 Functional Dependencies  A functional dependency occurs when the value of one (set of) attribute(s) determines the value of a second (set of) attribute(s)  The attribute on the left side of the functional dependency is called the determinant SID  GPA SKU  Department, SKU_Description (CustomerNumber, ItemNumber, Quantity)  Price  Mathematically, we say that “A” determines “B”, A  B  – Physically, we might say that “A” is a unique identifier for “B”

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke Functional Dependency (2)  Full Functional Dependency: “B” is functionally dependent on “A” but not on any subset of “A”  Transitive Dependency: If “B” and “C” are both dependent on “A”, but “C” is also dependent on “B”, we say that “C” is transitively dependent on “B” 6

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke 7 Normalization  Normalization eliminates modification anomalies Deletion anomaly: deletion of a row loses information about two or more entities Insertion anomaly: insertion of a fact in one entity cannot be done until a fact about another entity is added  Anomalies can be removed by splitting the relation into two or more relations; each with a different, single theme  Normalization works through classes of relations called normal forms

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke 8 Relationship of Normal Forms

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke 9 Normal Forms  Any table of data is in 1NF if it meets the definition of a relation  A relation is in 2NF if all its non-key attributes are dependent on all of the key (no partial dependencies) If a relation has a single attribute key, it is automatically in 2NF  A relation is in 3NF if it is in 2NF and has no transitive dependencies  A relation is in BCNF if every determinant is a candidate key  A relation is in fourth normal form if it is in BCNF and has no multi-value dependencies

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke 10 Example: 2NF

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke 11 Example: NOT IN 3NF

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke 12 Example: 3NF

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke 13 Example: NOT IN BCNF

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke 14 Example: BCNF

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke 15 Another Example: NOT IN BCNF CUSTOMER IDTool TypeTool trainer ID CUSTOMER ID + Tool Type  Tool Trainer ID CUSTOMER ID + Tool TRAINER ID is also an candidate key (unique) Tool TRAINER ID  Tool Type Specialized tool maker CUSTOMER IDTool trainer IDTool TypeTool trainer ID

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke 16 Example: NOT IN 4NF

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke 17 Example: 4NF

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke 18 Example: 4NF CUSTOMER IDTool TypesFavorite Sports CUSTOMER IDTool Types CUSTOMER IDFavorite Sports

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke 19 DK/NF  First published in 1981 by Fagin  DK/NF has no modification anomalies; so no higher normal form is needed  A relation is in DK/NF if every constraint on the relation is a logical consequence of the definition of keys and domains

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke 20 Example 1: DK/NF

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke 21 Example: DK/NF

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke 22 Normal Forms-Review  Any table of data is in 1NF if it meets the definition of a relation  A relation is in 2NF if all its non-key attributes are dependent on all of the key (no partial dependencies) If a relation has a single attribute key, it is automatically in 2NF  A relation is in 3NF if it is in 2NF and has no transitive dependencies  A relation is in BCNF if every determinant is a candidate key  A relation is in fourth normal form if it is in BCNF and has no multi-value dependencies

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke 23 De-normalized Designs  When a normalized design is unnatural, awkward, or results in unacceptable performance, a de- normalized design is preferred  Example Normalized relation  CUSTOMER (CustNumber, CustName, Zip)  CODES (Zip, City, State) De-Normalized relations  CUSTOMER (CustNumber, CustName, City, State, Zip)