]
>
Normalization
Normalization
11.1 Top View
Eliminate anomalies by minimizing duplication: divide data between tables
- Each relational scheme deals with a single theme
- Likely to introduce interrelation (i.e., referential integrity) constraints
- Make it more efficient to maintain databases
- May make data more difficult to access
| Students |
| St-Name | Status |
| Ben | senior |
| Dan | freshment |
|
|
| Courses |
| Course-Name | Course-# |
| db | 670 |
| ds | 680 |
|
|
| Graders |
| St-Name | Course-# | Salary |
| Ben | 670 | 500 |
| Ben | 680 | 500 |
| Dan | 670 | 400 |
| Dan | 680 | 600 |
|
|
11.2 The Approach
- Normal forms provide
- Yard sticks for identifying bad designs
- Guidelines for eliminating the problems
- Analysis: Top-down
- Evaluate the relation schemas against the normal forms
- Decompose when the criteria are not met
- Synthesis: Composes relations
11.3 Types of Normal Forms
- Functional dependencies over primary keys:
- 1st normal form
- 2nd normal form
- 3rd normal form
- Boyce-Codd normal form
- Multivalues dependencies: 4NF
- Join dependencies: 5NF
|
|
11.4 First Normal Form
Allow only atomic values in attributes
Normalization through Decomposition
- Attributes violating 1NF and place it in a separate relation, along with the primary key
- The new relation uses all the attributes for a primary key
Normalization through Unrolling Multivalues
- Introduces duplicated data
Normalization through Unrolling Attributes
- Assumes a limit on the cardinality of multivalues
- Needs NULL values
11.5 Second Normal Form
Attributes not in the primary key should be fully dependent on the primary key.
|
| | NAME
|
| PROJ-NAME | PROJ-LOC | HOURS |
|
|
partial functional dependencies | SSN
NAME
PROJ-#
PROJ-NAME,
PROJ-LOC
|
|
full functional dependencies | SSN,
PROJ-#
HOURS
|
Normalization
Set a new table for each partial key and its dependent attributes.
| |
| |
|
|
| PROJ-NAME | PROJ-LOC |
|
|
11.6 Third Normal Form
Attributes not in the primary key should be functionally dependent only on the primary key.
|
| | NAME
| DEPT-# | DEPT-NAME |
|
DEPT-#
DEPT-NAME
Every non-key attribute must be a fact about the key, the whole key, and nothing but the key.
Normalization
- Create a separate relationship schema for the non-key attributes that functionally depend on non-key attributes
- Designate the latter attributes as primary keys.
- The new schemas represent independent entity facts about employees and departments.
- Natural join recovers the original relation.
- Without the decomposition, the schema is subject to update, deletion, and insertion anomalies.
11.7 Example
Exercise 10.27, p. 329 Consider the universal relation
and the
set of functional dependencies
-
-
-
-
-
For the above data
- Determine the key of
- Decompose
into 2NF relations
- Decompose the outcome into 3NF relations
Sketch of Solution
- Draw a schema with arrows showing the functional dependencies (e.g., fig 14.11(a))
- Find the primary key
- Find the closures of the proper nonempty subsets of the primary key
- Use the above closures to perform 2NF decompositions
- Find the closures of the proper nonempty subsets of the attributes not included in the primary key
- Use the above closures to perform 3NF decompositions
11.8 Boyce-Codd Normal Form (BCNF)
If is non-trivial
then is
a super key
- DEPT,PROJECT
MANAGER
MANAGER
DEPT
- Insertion anomaly: the DEPT of a MANAGER can’t be stored, if the PROJECT is not given
Normalization
11.9 Generalization
Assume keys instead of primary keys.
| Non-2NF | Partial dependency
|
| Non-3NF | transitive dependency:
|
| non-BCNF |
is not in ,
key, and
is not a
superkey.
|
11.10 Assignment #6
Due: Th, Nov 20
Problems 10.18 (a, c, e, g, i), 10.20, 10.26 and 10.29 from textbook (pages 328–330 4th ed; 373–374 5th
ed).
Q&A
Reference: Ch. 10.3–10.6 in textbook.