Exit Exam Tutorial

Part 2: Fundamental Database Management Systems

Episode 4: Functional Dependency and Normalization
2.4 Functional Dependency and
Normalization
- Database normalization is a series of steps followed to
obtain a database design that allows for consistent storage
and efficient access of data in a relational database.
- These steps reduce data redundancy and the risk of data
becoming inconsistent.
- NORMALIZATION is the process of identifying the logical
associations between data items and designing a database
that will represent such associations but without suffering
the update anomalies which are;
1. Insertion Anomalies
2. Deletion Anomalies
3. Modification Anomalies
2.4 Functional Dependency and
Normalization
- Normalization may reduce system performance since data
will be cross referenced from many tables.
- Thus de-normalization is sometimes used to improve
performance, at the cost of reduced consistency
guarantees.
- Normalization normally is considered as good if it is lossless
decomposition.
- Mnemonic for remembering the rationale for normalization
could be the following:
1. No Repeating or Redundancy: no repeating fields in the
table.
2. The Fields Depend Upon the Key: the table should solely
depend on the key.
3. The Whole Key: no partial key dependency.
4. And Nothing But The Key: no inter-data dependency.
2.4 Functional Dependency and
Normalization
Pitfalls of Normalization
 Requires data to see the problems
 May reduce performance of the system
 Is time consuming,
 Difficult to design and apply and
 Prone to human error
2.4 Functional Dependency and
Normalization
The type of problems that could occur in insufficiently
normalized table is called update anomalies which includes;
1. INSERTION ANOMALIES: failure to place information
about a new database entry into all the places in the database
where information about that new entry needs to be stored.
2. DELETION ANOMALIES: failure to remove information
about an existing database entry when it is time to remove
that entry.
3. MODIFICATION ANOMALIES: involves changing some
value of the attribute of a table.
2.4 Functional Dependency and
Normalization
- Data Dependency: The logical association between data
items that point the database designer in the direction of a
good database design are referred to as determinant or
dependent relationships.
- In general, a functional dependency is a relationship among
attributes.
- In relational databases, we can have a determinant that
governs one other attribute or several other attributes.
- Partial Dependency: If an attribute which is not a member
of the primary key is dependent on some part of the
primary key (if we have composite primary key) then that
attribute is partially functionally dependent on the primary
key.
2.4 Functional Dependency and
Normalization
- Full Dependency: If an attribute which is not a member of
the primary key is not dependent on some part of the
primary key but the whole key (if we have composite
primary key) then that attribute is fully functionally
dependent on the primary key.
- Transitive Dependency: In mathematics and logic, a
transitive relationship is a relationship of the following
form: "If A implies B, and if also B implies C, then A implies
C."
2.4 Functional Dependency and
Normalization
2.4.1 Normalization
1. FIRST NORMAL FORM (1NF): Requires that all column
values in a table are atomic (e.g., a number is an atomic value,
while a list or a set is not).
- Definition of a table (relation) in 1NF
 There are no duplicated rows in the table/unique identifier.
 Each cell is single-valued (i.e., there are no repeating
groups).
 Entries in a column (attribute, field) are of the same kind.
2.4 Functional Dependency and
Normalization
2. SECOND NORMAL FORM (2NF): No partial dependency of
a non key attribute on part of the primary key.
- This will result in a set of relations with a level of Second
Normal Form.
- Any table that is in 1NF and has a single-attribute (i.e., a
non-composite) key is automatically also in 2NF.
- Definition of a table (relation) in 2NF
 It is in 1NF
 If all non-key attributes are dependent on all of the key. i.e.
no partial dependency.
- Since a partial dependency occurs when a non-key attribute
is dependent on only a part of the (composite) key, the
definition of 2NF is sometimes phrased as, "A table is in 2NF
if it is in 1NF and if it has no partial dependencies.“
2.4 Functional Dependency and
Normalization
3. THIRD NORMAL FORM (3NF): Eliminate Columns Not
Dependent On Key - If attributes do not contribute to a
description of the key, remove them to a separate table.
- This level avoids update and delete anomalies.
- Definition of a table (relation) in 3NF
 It is in 2NF
 There are no transitive dependencies between attributes.
4. BOYCE-CODD NORMAL FORM (BCNF): Isolate
Independent Multiple Relationships - No table may contain
two or more 1:n or N:M relationships that are not directly
related.
- A table is in BCNF if it is in 3NF and if every determinant is a
candidate key.
2.4 Functional Dependency and
Normalization
5. FOURTH NORMAL FORM (4NF): Isolate Semantically
Related Multiple Relationships.
- There may be practical constrains on information that
justify separating logically related many-to-many
relationships.
- A table is in 4NF if it is in BCNF and if it has no multi-valued
dependencies.
6. FIFTH NORMAL FORM (5NF): A model limited to only
simple (elemental) facts, as expressed in ORM.
- A table is in 5NF, also called "Projection-Join Normal Form"
(PJNF), if it is in 4NF and if every join dependency in the
table is a consequence of the candidate keys of the table.
2.4 Functional Dependency and
Normalization
7. DOMAIN-KEY NORMAL FORM (DKNF): A model free from
all modification anomalies.
- A table is in DKNF if every constraint on the table is a
logical consequence of the definition of keys and domains.
2.4 Functional Dependency and
Normalization
2.4.2 Physical Database Design Methodology for Relational
Database
- The Logical database design is concerned with the what.
- The Physical database design is concerned with the how.
- Physical database design is the process of producing a
description of the implementation of the database on
secondary storage.
- It describes the base relations, file organization, and indexes
used to achieve effective access to the data along with any
associated integrity constraints and security measures.
- Physical design describes the base relation, file organization,
and indexes used to achieve efficient access to the data, and
any associated integrity constraints and security measures.
- Sources of information for the physical design process include
global logical data model and documentation that describes
model.
2.4 Functional Dependency and
Normalization
- Describes the storage structures and access methods used
to achieve efficient access to the data
- Knowledge of the DBMS that is selected to host the
database systems, with all its functionalities, is required
since functionalities of current DBMS vary widely.
2.4 Functional Dependency and
Normalization
Special Thanks to the publisher and author with:
2.4 Functional Dependency and
Normalization
 TOPICS AND THE CONCEPTS:
Functional Dependency
Partial Dependency
Full Dependency
Transitive Dependency
First Normal Form
Second Normal Form
Third Normal Form
Boyce-Codd Normal Form
Fourth Normal Form
Fifth Normal Form
Domain-Key Normal Form
Logical and Physical Database for Relational Database

REFERENCES:
Fundamental Database Management Systems (6th Edition) by Ramez Elmasri, Shamkant B. Navaathe
Database Systems: A Practical Approach to Design, Implementation, and Management (6th Edition) by
Thomas Connolly, Carolyn Begg

PRESENTED BY:
Mohammed Nebil

HISTORY OF THE PROGRAMMING:

Boyce Codd

SPECIAL THANKS:
Digital Library of Educations
Federal Democratic Republic of Ethiopia, Ministry of Educations
Ethiopian Education Short Note