Normalization is a process of organizing the data

in database to avoid data redundancy, insertion

anomaly, update anomaly & deletion anomaly.
Let’s discuss about anomalies first then we will
discuss normal forms with examples.
Anomalies
There are three types of anomalies that occur
when the database is not normalized. These are –
Insertion, update and deletion anomaly.
 Boyce Codd Normal Form (BCNF)
• BCNF is a normal form used in database
normalization.
• BCNF was developed in 1974 by Raymond F.
Boyce and Edgar F. Codd
• Normalization is the process of efficiently
organizing data in a database .
 The Boyce-Codd Normal Form (BCNF)
(continued)
•Every determinant in table is a candidate key
• Has same characteristics as primary key, but for
some reason, not chosen to be primary key
•When table contains only one candidate key,
the 3NF and the BCNF are equivalent
•BCNF can be violated only when table contains
more than one candidate key
 The Boyce-Codd Normal Form (BCNF)
(continued)
• Most designers consider the BCNF as special case
of 3NF
• Table is in 3NF when it is in 2NF and there are no
transitive dependencies
• Table can be in 3NF and fails to meet BCNF
• No partial dependencies, nor does it contain transitive
dependencies
• A non key attribute is the determinant of a key
attribute
The Boyce-Codd Normal Form (BCNF) (continued)

5
The Boyce-Codd Normal Form (BCNF) (continued)

6
The Boyce-Codd Normal Form (BCNF) (continued)

7
 emp_id emp_nationality emp_dept dept_type dept_no_of_emp

Production and
1001 Austrian D001 200
planning

1001 Austrian stores D001 250

design and technical

1002 American D134 100
support

Purchasing
1002 American D134 600
department

Functional dependencies in the table above:

emp_id -> emp_nationality
emp_dept -> {dept_type, dept_no_of_emp}
Candidate key: {emp_id, emp_dept}
The table is not in BCNF as neither emp_id nor emp_dept alone are keys.
 To make the table comply with BCNF we can break the table in three tables like this:

emp_nationality table:
emp_dept_mapping table:
emp_id emp_nationality
1001 Austrian emp_id emp_dept
1002 American
Production and
emp_dept table: 1001
planning

emp_dept dept_type dept_no_of_emp

1001 stores
Production and
D001 200
planning
design and technical
stores D001 250 1002
support
design and
D134 100
technical support Purchasing
1002
department
Purchasing
D134 600
department
Functional dependencies:
emp_id -> emp_nationality
emp_dept -> {dept_type, dept_no_of_emp}

Candidate keys:
For first table: emp_id
For second table: emp_dept
For third table: {emp_id, emp_dept}

This is now in BCNF as in both the functional dependencies left side

part is a key.