fundamentals, design, and implementation, 9/e. database processing: fundamentals, design and...
TRANSCRIPT
Chapter 4/2 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
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
Chapter 4/4 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
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
Chapter 4/5 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
Example: Relation
Chapter 4/6 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
Example: Tables Not Relations
Chapter 4/7 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
Table-Relation or Not?
Chapter 4/8 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
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
Chapter 4/9 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
Where’s the keys?
Chapter 4/10 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
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?
Chapter 4/11 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
Functional Dependencies Examples
Composite– ObjectColor -> Weight– ObjectColor -> Shape
• ObjectColor -> (Weight, Shape)
– (CustomerNumber, ItemNumber, Quanity) -> Price
• CustomerNumber !-> Price
Chapter 4/12 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
Deletion Anomalies
Deleting facts about one entity causes the deletion of facts about another entity
Chapter 4/13 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
Insertion Anomalies
We cannot store facts about entity until we have another entity of different type to store– Add scuba to following
Chapter 4/14 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
Fixing Anomalies
Split the relation
Chapter 4/16 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
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
Chapter 4/17 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
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
Chapter 4/18 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
Relationship of Normal Forms
Chapter 4/19 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
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.
Chapter 4/20 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
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
Chapter 4/21 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
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
Chapter 4/22 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
Not Second Normal FormKey (sid,Activity)
Activity -> fee
Chapter 4/23 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
FIX
Chapter 4/24 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
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
Chapter 4/25 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
Violation of 3NF
Chapter 4/26 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
The Fix
Chapter 4/27 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
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.
Chapter 4/28 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
Violation of BCNF
Chapter 4/29 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
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
Chapter 4/30 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
Violation of 4TH NF
Chapter 4/31 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
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)
Chapter 4/32 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
FIX
Chapter 4/33 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
Fifth Normal Form (5NF)
The Fifth Normal Form concerns dependencies that are obscure and beyond the scope of this text.
Punt!
Chapter 4/34 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
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
Chapter 4/35 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
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
Chapter 4/36 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
DK/NF Example
Domain/Key Definition of Example Above
Chapter 4/37 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
DK/NF Example
Chapter 4/38 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
DK/NF Example
Chapter 4/39 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
Summary of Normal Forms
Chapter 4/40 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
Example: DK/NF
Chapter 4/41 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
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
Chapter 4/42 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
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
Chapter 4/43 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
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
Chapter 4/44 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
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
Chapter 4/45 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
Types of Attribute Relationship
Chapter 4/46 Copyright © 2004
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. Kroenke
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)