1. Further Normalization I
Chapter 12
Further Normalization I
1NF, 2NF, 3NF, BCNF

2. Topics in this Chapter
Nonloss Decomposition and Functional Dependencies
First, Second, and Third Normal Forms
Dependency Preservation
Boyce/Codd Normal Form
A Note on Relation-Valued Attributes

3. Normalization and Database Design
The “normal forms represent stages in achieving a more desirable design.
(“More desirable” means being more robust, having greater integrity.)
First normal form ( 1NF ) is what we achieved by specifying that relations contain single valued attributes only (each tuple has exactly one value for each attribute).
So, relations are always in (at least) 1NF.

4. Normalization and Database Design
Additional constraints that produce “further normalization” lead to one of the other designations ( 2NF, 3NF, etc.)   
Each “higher” normal form (2nd, 3rd, etc.) includes the previous ones—i.e., to be in “third normal form” means that the data is also in 2nd and in 1st.

5. Normalization
Normalized and 1 NF are the same thing; Frequently “normalized” is used to refer (incorrectly) to 3NF
Normalization helps control redundancy
Normalization is reversible; i.e. nonloss, or information preserving
Six normal forms are discussed: 1 through 5, and Boyce-Codd Normal Form (BCNF), which is an improvement on 3NF

6. First Normal Form
A relvar is in 1NF if and only if in every legal value of that relvar, every tuple contains exactly one value for each attribute
In this way, relvars are always in 1NF
A relvar in 1NF may display functional dependencies other than those emanating from the primary key
Such non-primary-key dependencies promote a miasma of update anomolies

7. S SP P Just “looks” right --because it is. Satisfies all normal forms.
| snum | sname | status | city |
| S1 | Smith | | London |
| S2 | Jones | | Paris |
| S3 | Blake | | Paris |
| S4 | Clark | | London |
| S5 | Adams | | Athens | SP
| snum | pnum | qty |
| S1 | P1 | 300 |
| S1 | P2 | 200 |
| S1 | P3 | 400 |
| S1 | P4 | 200 |
| S1 | P5 | 100 |
| S1 | P6 | 100 |
| S2 | P1 | 300 |
| S2 | P2 | 400 |
| S3 | P2 | 200 |
| S4 | P2 | 200 |
| S4 | P4 | 300 |
| S4 | P5 | 400 | P
| pnum | pname | color | weight | city |
| P1 | Nut | Red | | London |
| P2 | Bolt | Green | | Paris |
| P3 | Screw | Blue | | Rome |
| P4 | Screw | Red | | London |
| P5 | Cam | Blue | | Paris |
| P6 | Cog | Red | | London |
Just “looks” right
--because it is.
Satisfies all normal forms.
The suppliers and parts database

8. The table “SCP” recording supplier city in SCP rather than in S
| snum | scity | pnum | qty |
| S1 | London | P1 | 300 |
| S1 | London | P2 | 200 |
| S2 | Paris | P1 | 300 |
| S2 | Paris | P2 | 400 |
| S3 | Paris | P2 | 200 |
| S4 | London | P2 | 200 |
| S4 | London | P4 | 300 |
| S4 | London | P5 | 400 |
recording supplier city in SCP rather than in S
redundancy!
update problems:
how to change S4’s city (in three places)
how to record the city of a new supplier for whom there are no shipments?
primary key

9. Second Normal Form
A relation violates 2NF if a non-key field is a fact about a subset of a key.
A relation satisfies 2NF (is in 2NF) if it is in 1NF and every non-key attribute is irreducibly dependent on the primary key.
(i.e., dependent on the entire primary key)

10. Second Normal Form
A relvar is in 2NF if and only if it is in 1NF and every nonkey attribute is irreducibly dependent on the primary key
(Assumes only one candidate key)
A relvar in 2NF is less susceptible to update anomalies, but may still exhibit transitive dependencies
Both attributes in a transitive dependency are irreducibly implied by the primary key, and each implies the other

11. The table “Employees” In 1NF, but not good REDUNDANCY! And
| Emp_Id | Emp_Name | Dept# | DeptName | |
| A001 | Johnson | | Accounting |
| A023 | Chung | | Accounting |
| C085 | Allen | | Accounting |
| B120 | Gomez | | Sales |
| B211 | Davis | | Sales |
| A227 | Greenberg | | Production |
| C340 | Brown | | Production |
| C389 | Lopez | | Production |
| C395 | Clark | | Production |
| A502 | Edwards | | Sales |
| A616 | Scott | | Production |
| A700 | Sanyo | | Delivery |
| A722 | Adams | | Sales |
REDUNDANCY!
And
update problems:
change name of a department? (multiple updates required)
eliminate employee Sanyo? (what is the name of Dept 60?)

12. Update Anomalies “Update anomalies” include three operations:
An INSERT anomaly occurs when the user wishes to record a subordinate fact that is not dependent on the primary key (e.g., recording a supplier location before the supplier supplies a part)
A DELETE anomaly, conversely, may delete the location inadvertently
An UPDATE anomaly occurs when many updates are required to record a simple fact

13. The table “Employees” a transitive dependency Emp_Id Dept#
Dept# DeptName
Emp_Id transitively determines DeptName
Emp_Id DeptName
| Emp_Id | Emp_Name | Dept# | DeptName | |
| A001 | Johnson | | Accounting |
| A023 | Chung | | Accounting |
| C085 | Allen | | Accounting |
| B120 | Gomez | | Sales |
| B211 | Davis | | Sales |
| A227 | Greenberg | | Production |
| C340 | Brown | | Production |
| C389 | Lopez | | Production |
| C395 | Clark | | Production |
| A502 | Edwards | | Sales |
| A616 | Scott | | Production |
| A700 | Sanyo | | Delivery |
| A722 | Adams | | Sales |

14. Mutually independent keys
Non-key attributes are “mutually independent” if no such key is functionally dependent on any combination of the others (assuming only one candidate key).
Mutually independent => no transitive dependencies, such as
Emp# → Dept# Dept# → DeptName

15. Third Normal Form
A relation violates 3NF if some non-key attribute is a fact about another non-key attribute.
A relation is in 3NF if it is in 2NF and the non-key attributes are mutually independent.
A relation satisfies 3NF if it is in 2NF (and therefore also in 1NF) and every attribute is either part of the key or provides a fact about the key (all of it) and nothing else.

16. Third Normal Form
A relvar is in 3NF if and only if it is in 2NF and every nonkey attribute is nontransitively dependent on the primary key
(Assumes only one candidate key)
The process of normalization is a series of projections that eliminate complex functional dependencies
Such projections must be able to be recombined via JOIN to form the original relvar

17. Third Normal Form
A table is in 3NF if every column is either the key, or part of the key, or a fact about
the key, the whole key, and nothing but the key.

18. Third Normal Form
A relvar is in 3NF if and only if the nonkey attributes are both mutually independent and irreducibly dependent on the primary key
A relvar is in 3NF if and only if, for all time, each tuple consists of a primary key value that identifies some entity, together with a set of zero or more mutually independent attribute values that describe that entity in some way

19. Nonloss Decomposition and Functional Dependencies
Normalization uses a process of projection to decompose relvars
Recomposition is a process of joins
The decomposition of relvar R into projections R1…Rn is nonloss if R = the join of R1…Rn
The normalization procedure can be seen as a method for eliminating functional dependencies that do not emanate from a candidate key

20. decompose by projection
| snum | scity | pnum | qty |
| S1 | London | P1 | 300 |
| S1 | London | P2 | 200 |
| S2 | Paris | P1 | 300 |
| S2 | Paris | P2 | 400 |
| S3 | Paris | P2 | 200 |
| S4 | London | P2 | 200 |
| S4 | London | P4 | 300 |
| S4 | London | P5 | 400 |
The table “SCP”
decompose by projection
“S”
“SP”
| snum | scity |
| snum | pnum | qty |
the decomposition is lossless since a join of the two tables reproduces the original

21. decompose by projection
| Emp_Id | Emp_Name | Dept# | DeptName | |
| A001 | Johnson | | Accounting |
| A023 | Chung | | Accounting |
| C085 | Allen | | Accounting |
| B120 | Gomez | | Sales |
| B211 | Davis | | Sales |
| A227 | Greenberg | | Production |
| C340 | Brown | | Production |
| C389 | Lopez | | Production |
| C395 | Clark | | Production |
| A502 | Edwards | | Sales |
| A616 | Scott | | Production |
| A700 | Sanyo | | Delivery |
“Employees”
decompose by projection
“Employees”
“Departments”
| Emp_Id | Emp_Name | Dept# |
| Dept# | DeptName | |
the decomposition is lossless since a join of the two tables reproduces the original

22. Dependency Preservation
Dependency preservation refers to a specific case of nonloss decomposition, such that the normalized relvars are independent of each other
Some nonloss decompositions do not exhibit dependency preservation
Example: decompose supplier, city, status where supplier implies city and status, and city and status imply each other

23. Dependency Preservation
Dependency is preserved in this projection:
SC {S#, CITY}
CS {CITY, STATUS}
Dependency is not preserved in this one:
CS {S#, STATUS}
Although the second is nonloss, you still cannot update them independently

24. The table “SSP” violates BCNF snum sname
| snum | sname | pnum | qty |
| S1 | Smith | P1 | 300 |
| S1 | Smith | P2 | 200 |
| S2 | Jones | P1 | 300 |
| S2 | Jones | P2 | 400 |
| S3 | Blake | P2 | 200 |
| S4 | Clark | P2 | 200 |
| S4 | Clark | P4 | 300 |
| S4 | Clark | P5 | 400 |
The table “SSP”
again, assume unique supplier names
obviously bad (redundancy, etc.) but satisfies 3NF:
every attribute is key, part of the key, or about key, whole key, nothing but key
| snum | pnum |
candidate key:
qty
| sname | pnum |
candidate key:
qty
but:
snum
sname
violates BCNF

25. Boyce/Codd Normal Form
BCNF refers to decompositions involving relvars with more than one candidate key, where the candidate keys are composite and overlapping
A relvar is in BCNF if and only if every nontrivial, left- irreducible FD has a candidate key as its determinant
That is, a relvar is in BCNF if and only if every determinant is a candidate key

26. decompose by projection
| snum | sname | pnum | qty |
| S1 | Smith | P1 | 300 |
| S1 | Smith | P2 | 200 |
| S2 | Jones | P1 | 300 |
| S2 | Jones | P2 | 400 |
| S3 | Blake | P2 | 200 |
| S4 | Clark | P2 | 200 |
| S4 | Clark | P4 | 300 |
| S4 | Clark | P5 | 400 |
The table “SSP”
again, assume unique supplier names
decompose by projection
“S”
“SP”
| snum | sname |
| snum | pnum | qty |
the decomposition is lossless since a join of the two tables reproduces the original

27. “Employees” In BCNF, but lots of redundancy (violates 4NF)
| Emp_Id | Emp_Name | Skill | Language | |
| A001 | Johnson | Cook | English |
| A001 | Johnson | Cook | French | | A001 | Johnson | Cook | Spanish | | A001 | Johnson | Type | English | | A001 | Johnson | Type | French | | A001 | Johnson | Type | Spanish | | B211 | Davis | Weld | English |
| B211 | Davis | Weld | German | | B211 | Davis | Type | English | | B211 | Davis | Type | German |
etc.
In BCNF, but lots of redundancy (violates 4NF)
(multi-valued dependencies)
again, the solution is projection--a skills table and a language table

28. The Normalization Process
The “normal forms” are simply formalisms for describing problems that usually are apparent and that can cause obvious problems.
They are usually apparent in the form of redundancies, and common sense says to remove them.
Removal is a process of projecting the offending (proposed) table into two or more tables (in a lossless way).

29. Relation-Valued Attributes
A relation may include attributes whose values are relations
Traditionally this would be seen to violate 1NF, which was held to prohibit repeating groups
Now they are theoretically sound, but in practice you should avoid them because they have complicated predicates