chapter five db normalization
chapter five db normalization
Database 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
designing a database that will represent such associations
but without suffering the update anomalies.
Normalization of Database
Database Normalisation is a technique of organizing
the data in the database.
Normalization is a systematic approach of
decomposing tables to eliminate data redundancy and
undesirable characteristics like:
Insertion,
Update
and Deletion Anamolies.
Normalization is used for mainly two purpose,
Eliminating reduntant(useless) data.
Ensuring data dependencies make sense i.e data is
logically stored.
The type of problems that could occur in insufficiently
normalized table is called update anomalies which
includes:
Insertion anomalies
Deletion anomalies
Modification anomalies
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
Deletion anomalies
Failure to remove information about an existing database
entry when it is time to remove that entry.
Modification anomalies
In a properly normalized database table the change will be
effected and used accordingly.
Functional Dependency (FD)
functional dependency is a relationship among attributes.
Data Dependency
The logical associations between data items that point the
database designer in the direction of a good database
design are referred to as determinant or dependent
relationships.
Two data items A and B are said to be in a determinant or
dependent relationship if certain values of data item B
always appears with certain values of data item A.
If the data item A is the determinant data item and B the
dependent data item then the direction of the association is
from A to B and not vice versa.
The essence of this idea is that if the existence of
something, call it A, implies that B must exist and have a
certain value, and then we say that "B is functionally
dependent on A.
" We also often express this idea by saying that "A
determines B," or that "B is a function of A, “or that "A
functionally governs B."
Often, the notions of functionality and functional
dependency are expressed briefly by the statement, "If A,
then B.“
It is important to note that the value B must be unique for a
given value of A, i.e., any given value of A must imply just
one and only one value of B, in order for the relationship
to qualify for the name "function.
" (However, this does not necessarily prevent different
values of A from implying the same value of B.)
Example
Dinner Type of Wine
Meat Red
Fish White
Since the type of Wine served depends on the type of Dinner, we say
Wine is functionally dependent on Dinner.
Dinner Wine
Dinner Type of Wine
Types of Fork
Meat Red
Meat fork
Fish White
Fish fork
Since both Wine type and Fork type are determined by the Dinner
type, we say Wine is functionally dependent on Dinner and Fork is
functionally dependent on Dinner.
Dinner Wine
Dinner Fork
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.
Let {A, B} is the Primary Key and C is no key attribute.
Then if {A,B}C and BC or AC Then C is partially
functionally dependent on {A,B}
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.
Let {A,B} is the Primary Key and C is no key attribute
Then if {A,B}C and BC and AC does not hold ( if B
cannot determine C and A cannot determine C).
Then C Fully functionally dependent on {A,B}
Transitive Dependency
A transitive relationship is a relationship of the following
form:
"If A implies B, and if also B implies C, then A implies C.“
Example: If Mr X is a Human, and if every Human is an
Animal, then Mr X must be an Animal.
Generalized way of describing transitive dependency is
that:
If A functionally governs B, AND
If B functionally governs C
THEN A functionally governs C Provided that neither C
nor B determines A i.e. (B / A and C / A)
In the normal notation:
{(AB) AND (BC)} ==> AC provided that B /A and
C /A
levels or steps in normalization called Normal Forms.
The level of complexity, strength of the rule and
decomposition increases as we move from one lower level
Normal Form to the higher.
Normalization towards a logical design consists of the
following steps:
Un-Normalized Form: Identify all data elements
First Normal Form: Find the key with which you can
find all data
Second Normal Form: Remove part-key dependencies.
Make all data dependent on the whole key.
Third Normal Form: Remove non-key dependencies.
Make all data dependent on nothing but the key.
UNNORMALIZED
A table that contains one or more repeating groups.
A repeating group is a field or group of fields that hold
multiple values for a single occurrence of a field.
FIRST NORMAL FORM (1NF)
A table (relation) is in 1NF
If
There are no duplicated rows in the table.
Each cell is single-valued (i.e., there are no repeating
groups).
Entries in a column (attribute, field) are of the same kind.
Example for First Normal form (1NF)