Scribd
Upload
42 views23 pages

Week 15

The document discusses database normalization and different normal forms including 1NF, 2NF, 3NF, BCNF, and 4NF. It explains how to transform tables between normal forms and that sometimes denormalization is used to improve query performance, though it increases data redundancy.

Uploaded by

Ha ia
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
42 views23 pages

Week 15

The document discusses database normalization and different normal forms including 1NF, 2NF, 3NF, BCNF, and 4NF. It explains how to transform tables between normal forms and that sometimes denormalization is used to improve query performance, though it increases data redundancy.

Uploaded by

Ha ia
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 23

15th Week

DBMS
By
Dr Syed Khaldoon Khurshid
Topics/Concepts to be covered in 14th
and 15th Weeks
• What normalization is and what role it plays in the
database design process.
• About the normal forms 1NF, 2NF, 3NF, BCNF, and
4NF.
• How normal forms can be transformed from lower
normal forms to higher normal forms.
• That normalization and ER modeling are used
concurrently to produce a good database design.
• Improving the database design.
• That some situations require denormalization to
generate information efficiently.
Higher-level Normal Forms
• Tables in 3NF will perform suitably in
business transactional databases.
However, there are occasions when
higher normal forms are useful.
• A special case of 3NF, known as Boyce-
Codd normal form (BCNF), and fourth
normal form (4NF).
The Boyce-Codd Normal Form (BCNF)
• A table is in Boyce-Codd normal form
(BCNF) when every determinant in the
table is a candidate key.
• When a table contains only one
candidate key, the 3NF and the BCNF are
equivalent.
• Putting that proposition another way,
BCNF can be violated only when the
table contains more than one
candidate key.
The Boyce-Codd Normal Form (BCNF)
• The table structure shown in Figure 5.7
has no partial dependencies, nor does it
contain transitive dependencies. (The
condition C → B indicates that a
nonkey attribute determines part of
the primary key—and that
dependency is not transitive!) Thus, the
table structure in Figure 5.7 meets the
3NF requirements. Yet the condition C →
B causes the table to fail to meet the
BCNF requirements.
The Boyce-Codd Normal Form (BCNF)
The Boyce-Codd Normal Form (BCNF)
Fourth Normal Form (4NF)
• When encountered with poorly designed
databases, or it can be asked to convert
spreadsheets into a database format in
which multiple multivalued attributes exist.
Fourth Normal Form (4NF)
• Specifically, the discussion of 4NF is
largely academic if you make sure that
your tables conform to the following two
rules:
1. All attributes must be dependent on
the primary key, but they must be
independent of each other.
2. No row may contain two or more
multivalued facts about an entity.
Normalization and database design
Normalization and database design
The Normal forms with their characteristics
Denormalization
• Occasionally it is expected to denormalize
some portions of a database design in order
to meet performance requirements.
• Denormalization produces a lower normal
form; that is, a 3NF will be converted to a
2NF through denormalization.
• However, the price which is payed for
increased performance through
denormalization is greater data redundancy.
Denormalization
• Good database design also considers processing (or
reporting) requirements and processing speed. The
problem with normalization is that as tables are
decomposed to conform to normalization
requirements, the number of database tables
expands. Therefore, in order to generate
information, data must be put together from
various tables.
Denormalization
• Joining a large number of tables takes
additional input/output (I/O) operations
and processing logic, thereby reducing
system speed. Most relational database
systems are able to handle joins very efficiently.
• However, rare and occasional circumstances
may allow some degree of denormalization
so processing speed can be increased.
Denormalization
• For example, should people in a real-world database environment worry
that a ZIP_CODE determines CITY in a CUSTOMER table whose primary
key is the customer number?
• Is it really practical to produce a separate table for
– ZIP (ZIP_CODE, CITY)
End of Course

You might also like