Normalization
A technique for identifying
table structures that have
potential maintenance
problems
Normalization
Normalization removes duplication and
minimizes redundant chunks of data.
Normalization is a set of formal conditions
that assure that a database is maintainable.
The results of a well executed normalization
process are the same as those of a well
planned E-R model
PROCESS OF DATA
NORMALIZATION
ELIMINATE REPEATING GROUPS
Make a separate table for each set of related
attributes and give each table a primary key.
ELIMINATE REDUNDANT DATA
If an attribute depends on only part of a
multivalued key, remove it to a separate table.
ELIMINATE COLUMNS NOT DEPENDENT ON KEY
If attributes do not contribute to a description of
the key, remove them to a separate table.
Database Programming and Design
PROCESS OF DATA
NORMALIZATION
ISOLATE INDEPENDENT MULTIPLE RELATIONSHIPS
No table may contain two or more 1:n or n:m
relationships that are not directly related.
ISOLATE SEMANTICALLY RELATED MULTIPLE
RELATIONSHIPS
There may be practical constraints on information
that justify separating logically related many-tomany relationships.
Database Programming and Design
Anomalies
An anomaly is essentially an
erroneous change to data, more
specifically to a single record.
Anomalies
A table anomaly is a structure for which
a normal database operation cannot
be executed without information loss
or full search of the data table
Insertion Anomaly
Deletion Anomaly
Update or Modification Anomaly
Anomalies
Insert anomalyCaused when a record is
added to a detail table, with no related
record existing in a master table.
Anomalies
Delete anomalyCaused when a record
is deleted from a master table, without
first deleting all sibling records, in a
detail table. The exception is a cascade
deletion, occurring when deletion of a
master record automatically deletes all
child records in all related detail tables,
before deleting the parent record in the
master table.
Anomalies
Delete anomalyCaused when a record
is deleted from a master table, without
first deleting all sibling records, in a
detail table. The exception is a cascade
deletion, occurring when deletion of a
master record automatically deletes all
child records in all related detail tables,
before deleting the parent record in the
master table.
Anomalies
Update anomalyThis anomaly is
similar to deletion in that both
master and detail records must be
updated to avoid orphaned detail
records. When cascading, ensure
that any primary key updates are
propagated to related child table
foreign keys.
Normal Forms
Relational theory defines a number of
structure conditions called Normal
Forms that assure that certain data
anomalies do not occur in a
database.
Normal Forms
1st Normal Form (1NF)Eliminate
repeating groups such that all records
in all tables can be identified uniquely
by a primary key in each table. In
other words, all fields other than the
primary key must depend on the
primary key.
Normal Forms
2nd Normal Form (2NF)All non-key
values must be fully functionally
dependent on the
primary key. No partial dependencies
are allowed. A partial dependency
exists when a field is
fully dependent on a part of a
composite primary key.
Normal Forms
3rd Normal Form (3NF)Eliminate
transitive dependencies, meaning that
a field is indirectly
determined by the primary key. This is
because the field is functionally
dependent on another
field, whereas the other field is
dependent on the primary key.
Normal Forms
Boyce-Codd Normal Form (BCNF)
Every determinant in a table is a
candidate key. If there is
only one candidate key, 3NF and BCNF
are one and the same.
Normal Forms
4th Normal Form (4NF)Eliminate
multiple sets of multivalued
dependencies.
Normal Forms
5th Normal Form (5NF)Eliminate
cyclic dependencies. 5NF is also
known as Projection
Normal Form (PJNF).
Normal Forms
Domain Key Normal Form (DKNF)
DKNF is the ultimate application of
normalization and is
more a measurement of conceptual
state, as opposed to a transformation
process in itself.
Normal Forms
1NF
2NF
3NF
BCNF
keys
4NF
Keys; No repeating groups
No partial dependencies
No transitive dependencies
Determinants are candidate
No multivalued dependencies
1st Normal Form (1NF)
Eliminates repeating groups.
Defines primary keys.
All records must be identified uniquely with a primary key. A
primary key is unique and thus
no duplicate values are allowed.
All fields other than the primary key must depend on the
primary key, either directly or
indirectly.
All fields must contain a single value.
All values in each field must be of the same datatype.
Create a new table to move the repeating groups from the
original table.
a table in 0th Normal Form
detail of the AUTHORSBOOKS table shown in Figure 4-7,
demonstrating that
leaving a table with no Normal Forms applied at all is completely
silly.
how comma-delimited lists are used as another
common method of displaying 0th Normal Form data,
including repeated groups.
the application of 1NF, removing repeating fields by creating a
new table where the
original and new table are linked in a master-detail, one-tomany relationship.
primary keys are created on both tables where the detail table has a
composite primary
key. The composite primary key contains the master table primary
key field as the prefix field of its
primary key. Therefore, the prefix field AUTHOR on the BOOK
table is the foreign key pointing back to the
master table AUTHOR.
shows what the data looks like in the altered AUTHOR table and
the new BOOK table, previously
the AUTHORSBOOKS table.
2nd Normal Form (2NF)
The table must be in 1NF.
All non-key values must be fully functionally dependent on the primary
key. In other words,
non-key fields not completely and individually dependent on the primary
key are not allowed.
Partial dependencies must be removed. A partial dependency is a
special type of functional dependency that exists when a field is fully
dependant on a part of a composite primary key.
Stating the previous two points in a different way, remove fields that are
independent of the primary key.
Create a new table to separate the partially dependent part of the
primary key and its dependent
fields.
the BOOK table is
in 1NF after separation of repeating group books from the authors. The publisher and subject information
are relatively static compared with books.
the initial stage of the application of 2NF, removing static publisher
and subject
information from the more dynamic BOOK transaction table.
many-to-one relationships are established between dynamic and
static tables, namely
BOOK to PUBLISHER and BOOK to SUBJECT tables.
primary keys are created on both the PUBLISHER and SUBJECT tables to uniquely identify
individual publishers and subjects within their two respective tables. Identifying relationships as
BOOK
related to PUBLISHER and BOOK related to SUBJECT causes the publisher and subject primary key
values to be included in the composite primary key of the BOOK table.
changing
the relationships between dynamic and static tables from
identifying to non-identifying.
what the data looks like in the altered BOOK table with the new PUBLISHER and SUBJECT
tables shown as well. Multiple fields of publisher and subject field information previously duplicated
on the BOOK table (as shown in Figure 4-15) is now separated into the two new PUBLISHER and
SUBJECT tables, with duplicate publishers and subjects removed from the new tables.
3rd Normal Form (3NF)
The table must be in 2NF.
Eliminate transitive dependencies.
Atransitive dependency is where a field is
indirectly determined
by the primary key because that field is
functionally dependent on a second field,
where that
second field is dependent on the primary key.
Create a new table to contain any
separated fields.
Figure 4-23 shows one of the easiest interpretations of 3NF where
a many-to-many relationship presents
the possibility that more than one record will be returned using a
query joining both tables.
Figure 4-24 shows employees and tasks from the 2NF version on the left of the diagram in Figure 4-23.
Employees perform tasks in their daily routines, doing their jobs. If you were searching for the
employee
Columbia, three tasks would always be returned. Similarly, if searching for the third task shown in
Figure 4-24, two employees would always be returned. A problem would arise with this situation when
searching for an attribute specific to a particular assignment where an assignment is a single task
assigned to a single employee.
The transformation in Figure 4-25 could be conceived as being two 2NF transformations because a
many-to-one relationship is creating a more static table by creating the FOREIGN_EXCHANGE table.
A transitive dependency occurs where one field depends on another, which in turn depends on a
third
fieldthe third field typically being the primary key. A state of transitive dependency can also be
interpreted
as a field not being entirely dependent on the primary key.
There is usually a good reason for including calculated fieldsusually performance denormalization.
(Denormalization is explained as a concept in a later chapter.) In a data warehouse, calculated fields
are sometimes stored in materialized views. Data warehouse database modeling is also covered in a
later chapter.
Beyond 3rd Normal Form
(3NF)
BCNF or Boyce-Codd Normal Form (BCNF)Every determinant in
a table is a candidate key. If
there is only one candidate key, then 3NF and BCNF are one and
the same.
4th Normal Form (4NF)Eliminate multiple sets of multi-valued
dependencies.
5th Normal Form (5NF)Eliminate cyclic dependencies. 5NF is
also known as Projection normal
form (PJNF).
Domain Key normal form (DKNF)DKNF is the ultimate
application of normalization and is
more of a measurement of conceptual state as opposed to a
transformation process in itself.
Figure 4-30 shows removal of two often to be NULL valued fields from a table called EDITION,
creating
the new table called RANK. The result is a zero or one-to-one relationship between the RANK
and EDITION
tables. This implies that if a RANK record exists, then a corresponding EDITION record must
exist as well.
In the opposite case, however, an EDITION record can exist where a RANK record does not
have to exist.
Figure 4-31 shows a data picture of the normalized structure shown
at the lower-right of the diagram
in Figure 4-30. What has effectively happened is that potentially
NULL valued fields are moved into a
new table, creating a one-to-one or zero relationship.
Beyond 3rd Normal Form
(3NF)
Boyce-Codd Normal Form (BCNF)
BCNF does the following.
A table must be in 3NF.
A table can have only one candidate key.
A candidate key has potential for being a tables primary key. A table is not
allowed more than one
primary key because referential integrity requires it as such. It would be
impossible to check foreign keys
against more than one primary key. Referential integrity would be
automatically invalid, unenforceable,
and, thus, there would be no relational database model.
Beyond 3rd Normal Form
(3NF)
4th Normal Form (4NF)
4NF does the following.
A table must be in 3NF or BCNF with 3NF.
Multi-valued dependencies must be transformed into functional
dependencies. This implies
that one value and not multiple values are dependent on a primary key.
Eliminate multiple sets of multiple valued or multi-valued dependencies,
sometimes described
as non-trivial multi-valued dependencies.
A multiple valued set is a field containing a comma-delimited list or collections
of some kind. A collection
could be an array of values of the same type. Those multiple values are
dependent as a whole on the
primary key (the whole meaning the entire collection in each record).
Beyond 3rd Normal Form
(3NF)
5th Normal Form (5NF)
5NF does the following.
A table must be in 4NF.
Cyclic dependencies must be eliminated. A cyclic dependency is simply
something that depends
on one thing, where that one thing is either directly in indirectly dependent
on itself.
Beyond 3rd Normal Form
(3NF)
5th Normal Form (5NF)
5NF does the following.
A table must be in 4NF.
Cyclic dependencies must be eliminated. A cyclic dependency is simply
something that depends
on one thing, where that one thing is either directly in indirectly dependent
on itself.
Premier Products Order
Form
(Company
Order History)
Order # 12003
Date Oct 1, 1997
Oklahoma Retail Company
1111 Asp
Norman
1.
2.
3.
Description
Code Qty
Price Amount
Footballs
Sweat Shirts
Shorts
21
44
37
25.00 150
15.00 300
12.00 120
Total
6
20
10
570
0nf: Remove titles and
derived quantities
Order # 12003
Date Oct 1, 1997
Oklahoma Retail Company
1111 Asp
Norman
1.
2.
3.
Description
Code Qty
Price Amount
Footballs
Sweat Shirts
Shorts
21
44
37
25.00 150
15.00 300
12.00 120
Total
6
20
10
570
0 Normal Form
Remove titles and derived quantities
Schema notation
HISTORY(CustName, CustAddr, CustCity
{OrderNum, OrderDate {ProdDescr,
ProdCode, QtyOrdered, OrderPrice}}
1st Normal Form
Add keys
Remove repeating groups
1st Normal Form
Add Keys for embedded entities
Remove Repeating Groups
HISTORY(CustID, CustName, CustAddr,
CustCity {OrderNum, OrderDate {ProdDescr,
ProdCode, QtyOrdered, OrderPrice}}
1st Normal Form
Add Keys for embedded entities
Remove Repeating Groups
Create a table for each embedded entity,
from the outside for nested groups
Insert foreign keys and junction tables
CUSTOMER(CustID, CustName, CustAddr,
CustCity)
ORDER(OrderNum, CustID, OrderDate {ProdDescr,
ProdCode, QtyOrdered, OrderPrice})
1st Normal Form
CUSTOMER(CustID, CustName,
CustAddr, CustCity)
ORDER(OrderNum, CustID, OrderDate)
PRODUCT(ProdDescr, ProdCode,)
ORDER-PRODUCT(OrderNum,
ProdCode, QtyOrdered, OrderPrice)
1st Normal Form
CUSTOMER
ORDER
PRODUCT
1NF
(Keys, No Repeating Groups)
Table contains multi-valued attributes.
TABLE
{ ATTRIBUTES}
TABLE
??
ATTR-TABLE
2nd Normal Form
No partial dependencies
(an attribute has a partial
dependency if it depends
on part of a concatenated
key)
2nd Normal Form
ROSTER(StuID, ZAPNum, StudentName,
CourseTitle, CourseGrade)
Remove partial dependencies
STUDENT(StuID, StudentName)
SECTION(ZAPNum, CourseTitle)
STUDENT-SECTION(StuID, ZAPNum,
CourseGrade)
2nd Normal Form
ROSTER
STUDENT
SECTION
STUDENT-SECTION
2NF
No partial dependencies
Table has data from several connected tables.
TABLE
??
TABLE
??
3rd Normal Form
No transitive dependencies
(a transitive dependency is
an attribute that depends
on other non-key
attributes)
3rd Normal Form
Note: a transitive dependency arises
when attributes from a second entity
appear in a given table.
SECTION(ZAPNum, RoomNum, Day,
Time, CourseTitle, HoursCredit)
3rd Normal Form
SECTION(ZAPNum, RoomNum, Day,
Time, CourseID ,CourseTitle,
HoursCredit)
SECTION(ZAPNum, RoomNum, Day,
Time, CourseID)
COURSE(CourseID, CourseTitle,
HoursCredit)
3NF
No transitive dependencies
Table contains data from an embedded entity with
non-key attributes.
TABLE
TABLE
SUB-TABLE
??
SUB-TABLE
BCNF is the same, but the embedded table may
involve key attributes.
Boyce Codd Normal Form
Every determinant is a
candidate key
BCNF
BCNF dependenceies are like 3nf
dependencies but they involve some
key attributes
Note: BCNF often arises when a 1:m
relationship is modeled as a m:n
relationship
BCNF
SALESMAN-CUST(SalesID, CustID,
Commission)
SALESMAN(SalesID, Commission)
CUSTOMER(CustID, SalesID)
4th Normal Form
No multi-valued
dependencies
4th Normal Form
Note: 4th Normal Form violations
occur when a triple (or higher)
concatenated key represents a pair
of double keys
4th Normal Form
4th Normal Form
Multuvalued dependencies
Instructor
Book
Class
Price
Inro Comp
MIS 2003
Parker
Intro Comp
MIS 2003
Kemp
Data in Action
MIS 4533
Kemp
ORACLE Tricks MIS 4533
Warner
Data in Action
Warner
ORACLE Tricks MIS 4533
MIS 4533
4th Normal Form
INSTR-BOOK-COURSE(InstrID, Book,
CourseID)
COURSE-BOOK(CourseID, Book)
COURSE-INSTR(CourseID, InstrID)
4NF
(No multivalued dependencies)
Independent repeating groups have been treated as a
complex relationship.
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
