Fundamentals, Design, and Implementation, 9/e

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/2 Copyright © 2004 Agenda  Questions from last Class?  Assignment # 2 Corrected –2 D’s, 4 F’s and 1 non-submit Extremely poor performance We will go over assignment in detail Many violations of UMFK Academic Integrity Policy  Assignment # 3 Posted due Feb 5 –Next class –I expect to see more individual effort –I will allow a few minutes to field questions  First Exam –Feb 9 –Chaps 1-3 –20 M/C; 5 Short essays –60 min WebCT, Open book  Today’s discussion –The Relational Model and Normalization

Fundamentals, Design, and Implementation, 9/e Chapter 4 The Relational Model and Normalization

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/4 Copyright © 2004 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 –Cells of the table hold a single value –All entries in a column are of the same kind –Each column has a unique name –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. KroenkeChapter 4/5 Copyright © 2004 Example: Relation

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/6 Copyright © 2004 Example: Tables Not Relations

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/7 Copyright © 2004 Table-Relation or Not?

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/8 Copyright © 2004 Types of Keys  A key is one or more columns of a relation that identifies a row  A unique key identifies a single row; a non-unique key identifies several rows  Composite key is a key that contains two or more attributes  A relation has one unique primary key and may also have additional unique keys called candidate keys  Primary key is used to –Represent the table in relationships –Organize table storage –Generate indexes

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/9 Copyright © 2004 Where’s the keys?

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/10 Copyright © 2004 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  DormName, Fee –(CustomerNumber, ItemNumber, Quantity)  Price  While a primary key is always a determinant, a determinant is not necessarily a primary key –Question? –Are Candidate keys always a determinant?

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/11 Copyright © 2004 Functional Dependencies Examples  Composite –ObjectColor -> Weight –ObjectColor -> Shape ObjectColor -> (Weight, Shape) –(CustomerNumber, ItemNumber, Quanity) -> Price CustomerNumber !-> Price

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/12 Copyright © 2004 Deletion Anomalies  Deleting facts about one entity causes the deletion of facts about another entity

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/13 Copyright © 2004 Insertion Anomalies  We cannot store facts about entity until we have another entity of different type to store –Add scuba to following

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/14 Copyright © 2004 Fixing Anomalies  Split the relation

Fundamentals, Design, and Implementation, 9/e COS 346 DAY 6

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/16 Copyright © 2004 Agenda  Questions from last Class?  Assignment #3 due  Assignment # 4 Posted due Feb 12  First Exam Next Class –Feb 9 –Chaps 1-3 –20 M/C; 5 Short essays –60 min WebCT, Open book  Today’s discussion –The Relational Model and Normalization

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/17 Copyright © 2004 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  However, breaking up a relation may create referential integrity constraints  Normalization works through classes of relations called normal forms

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/18 Copyright © 2004 Relationship of Normal Forms

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/19 Copyright © 2004 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  Fifth Normal form is too theoretical to bother with  To be in Domain/Key Normal Form (DK/NF) every constraint on the relation must be a logical consequence of the definition of keys and domains.

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/20 Copyright © 2004 First Normal Form (1NF)  Any table of data is in 1NF if it meets the definition of a relation  To be in First Normal Form (1NF) a relation must have only single-valued attributes -- neither repeating groups nor arrays are permitted  May have Modification anomalies

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/21 Copyright © 2004 Second Normal Form (2NF)  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  To be in Second Normal Form (2NF) the relation must be in 1NF and each nonkey attribute must be dependent on the whole key (not a subset of the key)  Can have modification anomalies  Fix by decomposing into two relations

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/22 Copyright © 2004 Not Second Normal Form Key (sid,Activity) Activity -> fee

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/23 Copyright © 2004 FIX

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/24 Copyright © 2004 Third Normal Form (3NF)  To be in Third Normal Form (3NF) the relation must be in 2NF and no transitive dependencies may exist within the relation.  A transitive dependency is when an attribute is indirectly functionally dependent on the key (that is, the dependency is through another nonkey attribute)  Can have anomalies

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/25 Copyright © 2004 Violation of 3NF

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/26 Copyright © 2004 The Fix

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/27 Copyright © 2004 Boyce-Codd Normal Form (BCNF)  To be in Boyce-Codd Normal Form (BCNF) the relation must be in 3NF and every determinant must be a candidate key.

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/28 Copyright © 2004 Violation of BCNF

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/29 Copyright © 2004 Fourth Normal Form (4NF)  To be in Fourth Normal Form (4NF) the relation must be in BCNF and the relation may not contain multi-valued dependencies.  Has update anomalies

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/30 Copyright © 2004 Violation of 4 TH NF

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/31 Copyright © 2004 Fixing 4thNF (Generally Speaking)  A relation R(A,B,C) –A->->B –A->->C –B and C are independent  Create  R(A,B) andR1(A,C)

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/32 Copyright © 2004 FIX

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/33 Copyright © 2004 Fifth Normal Form (5NF)  The Fifth Normal Form concerns dependencies that are obscure and beyond the scope of this text.  Punt!

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/34 Copyright © 2004 Domain/Key Normal Form (DK/NF)  To be in Domain/Key Normal Form (DK/NF) every constraint on the relation must be a logical consequence of the definition of keys and domains.  Ultimate Normal Form –1981 Fagin  NO possible anomalies

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/35 Copyright © 2004 DK/NF Terminology  Constraint –A rule governing static values of attributes  Key –A unique identifier of a tuple  Domain –A description of an attribute’s allowable values

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/36 Copyright © 2004  DK/NF Example Domain/Key Definition of Example Above 

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/37 Copyright © 2004 DK/NF Example

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/38 Copyright © 2004 DK/NF Example

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/39 Copyright © 2004 Summary of Normal Forms

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/40 Copyright © 2004 Example: DK/NF

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/41 Copyright © 2004 The Synthesis of Relations  Given a set of attributes with certain functional dependencies, what relations should we form?  Example: A and B are two attributes –If A  B and B  A A and B have a one-to-one attribute relationship –If A  B, but B not  A A and B have a many-to-one attribute relationship –If A not  B and B not  A A and B have a many-to-many attribute relationship

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/42 Copyright © 2004 One-to-One Attribute Relationships  Attributes that have a one-to-one relationship must occur together in at least one relation  Call the relation R and the attributes A and B: –Either A or B must be the key of R –An attribute can be added to R if it is functionally determined by A or B –An attribute that is not functionally determined by A or B cannot be added to R –A and B must occur together in R, but should not occur together in other relations –Either A or B should be consistently used to represent the pair in relations other than R

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/43 Copyright © 2004 Many-to-One Attribute Relationships  Attributes that have a many-to-one relationship can exist in a relation together  Assume C determines D in relation S –C must be the key of S –An attribute can be added to S if it is determined by C –An attribute that is not determined by C cannot be added to S

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/44 Copyright © 2004 Many-to-Many Attribute Relationships  Attributes that have a many-to-many relationship can exist in a relation together  Assume attributes E and F reside together in relation T –The key of T must be (E, F) –An attribute can be added to T if it is determined by the combination (E, F) –An attribute may not be added to T if it is not determined by the combination (E, F) –If adding a new attribute, G, expands the key to (E, F, G), then the theme of the relation has been changed Either G does not belong in T or the name of T must be changed to reflect the new theme

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/45 Copyright © 2004 Types of Attribute Relationship

Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 4/46 Copyright © 2004 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)

Fundamentals, Design, and Implementation, 9/e Chapter 4 The Relational Model and Normalization