Kroenke-DBP-e10-PPT-Chapter03

COS 346
Day 5
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-1
Agenda
• Questions?
• Assignment 1 Is Corrected
– 2 A’s, 3 B’s, 1 C and 1 D
– Pay attention to details!
• Problems with reports and forms
• MultiTable Examples in Appendix A
• Assignment Two is posted
– Marcia’s Dry Cleaning Project on page 97 & 98, question A
through F
– Due Feb 5 at 3:35 PM (next Class)
• Discussion on The Relational Model and Normalization
– More in class work
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-2
Modification Anomalies
• Deletion Anomaly
• Insertion Anomaly
• Update Anomaly
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-3
Deletion Anomalies
• Deleting facts about one entity causes the
deletion of facts about another entity
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-4
Insertion Anomalies
• We cannot store facts about entity until we
have another entity of different type to
store
– Add scuba to following
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-5
Modification Anomalies
• The EQUIPMENT_REPAIR table before and after an
incorrect update operation on AcquisitionCost for Type =
Drill Press:
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-6
Fixing Anomalies
• Split the relation
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-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
• However, breaking up a relation may create referential
integrity constraints
• Normalization works through classes of relations called
normal forms
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-8
Relationship of Normal Forms
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-9
Normal Forms
• Relations are categorized as a normal form
based on which modification anomalies or other
problems that they are subject to:
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-10
Normal Forms
• 1NF – A table that qualifies as a relation is in 1NF
• 2NF – A relation is in 2NF if all of its nonkey attributes
are dependent on all of the primary key
• 3NF – A relation is in 3NF if it is in 2NF and has no
determinants except the primary key
• Boyce-Codd Normal Form (BCNF) – A relation is in
BCNF if every determinant is a candidate key
“I swear to construct my tables so that all nonkey
columns are dependent on the key, the whole key
and nothing but the key, so help me Codd.”
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-11
Normal Forms (Part 2)
• 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.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-12
Eliminating Modification Anomalies from
Functional Dependencies in Relations
• Put all relations into Boyce-Codd Normal Form
(BCNF):
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-13
Putting a Relation into BCNF:
EQUIPMENT_REPAIR
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-14
Putting a Relation into BCNF:
EQUIPMENT_REPAIR
EQUIPMENT_REPAIR (ItemNumber, Type, AcquisitionCost,
RepairNumber, RepairDate, RepairAmount)
ItemNumber  (Type, AcquisitionCost)
RepairNumber  (ItemNumber, Type, AcquisitionCost,
RepairDate, RepairAmount)
ITEM
(ItemNumber, Type, AcquisitionCost)
REPAIR (ItemNumber, RepairNumber, RepairDate, RepairAmount)
Where REPAIR.ItemNumber must exist in
ITEM.ItemNumber
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-15
Putting a Relation into BCNF:
New Relations
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-16
Putting a Relation into BCNF:
SKU_DATA
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-17
Putting a Relation into BCNF:
SKU_DATA
SKU_DATA
(SKU, SKU_Description, Department, Buyer)
SKU  (SKU_Description, Department, Buyer)
SKU_Description  (SKU, Department, Buyer)
Buyer  Department
SKU_DATA
(SKU, SKU_Description, Buyer)
BUYER
(Buyer, Department)
Where BUYER.Buyer must exist in SKU_DATA.Buyer
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-18
Putting a Relation into BCNF:
New Relations
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-19
Multivalued Dependencies
• A multivalued dependency occurs when
a determinant determines a particular set
of values:
Employee  Degree
Employee  Sibling
PartKit  Part
• The determinant of a multivalued
dependency can never be a primary key
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-20
Multivalued Dependencies
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-21
Eliminating Anomalies from
Multivalued Dependencies
• Multivalued dependencies are not a
problem if they are in a separate relation,
so:
– Always put multivalued dependencies into
their own relation
– This is known as Fourth Normal Form (4NF)
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-22
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)
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-23
Fifth Normal Form (5NF)
• The Fifth Normal Form concerns
dependencies that are obscure and
beyond the scope of this text.
• Punt!
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-24
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
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-25
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
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-26
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)
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-27
David M. Kroenke’s
Database Processing
Fundamentals, Design, and Implementation
(10th Edition)
End of Presentation:
Chapter Three
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition
© 2006 Pearson Prentice Hall
3-28