Functional dependency and normalization

Functional Dependency
and
Normalization
7/24/2017 1Md. Golam Moazzam, Dept. of CSE, JU

OUTLINE
 Functional Dependency (FD)
 Inference Axioms for FDs
 Trivial and Non-trivial Dependency
 Canonical Cover
 Normalization Process: Objectives
 1NF, 2NF, 3NF
 Data Anomalies
 Partial Dependencies
 Transitive Dependencies
 Boyce-Codd Normal Form
 Decomposition: Lossless or Lossy

 Objectives
- To control the redundancy of data.
- To preserve the consistency of data.
Data redundancy occurs when a piece of data is stored in more
than one place in the database.
If the content of that piece of data is changed to a particular
value, then it is necessary to ensure that every copy of the same
piece of data is changed to the same value. This piece of data is
said to be consistent in the database.
If some, but not all, copies of this piece of data are changed to
the same value, the data is said to be inconsistent.

 Functional Dependency (FD)
– Given a relation r(R) and two sets of its attributes A and B.
We will say that attribute(s) A functionally determines
attribute(s) B with respect to r, denoted by A → B, if and
only if for any two tuples t1 and t2 of r whenever
t1(A) = t2(A) then t1(B) =t2(B).
– That is, if A functionally determines B, then whenever two
tuples of r have identical values in column A, their
respective values in column B must also be identical.

Name Continent Area Length
Caspian Sea Asia – Europe 143244 760
Superior North America 31700 350
Victoria Africa 26828 250
Aral Sea Asia 24904 280
Huron North America 23000 206
Michigan North America 22300 307
Tanganyika Africa 12700 420
Lakes-of-The-World

Example: Given the Lakes-Of-The-World relation shown
above, state whether or not the functional dependencies
(a) Continent → Name and
(b) Name → Length are satisfied by this relation.

(a) Here t1(Continent)= t2(Continent)=North America
But t1(Name)= Superior ≠ t2(Name)=Huron
So, Continent → Name is not satisfied by the relation
i.e. Continent Name.
(b) The functional dependency Name → Length is satisfied by
the relation. Because for any given lake, there is only one
length associated with it.

 Inference Axioms for FDs/Armstrong's axioms
Given a set F of FDs, the inference axioms are a set of rules that tell
us that if a relation satisfies the FDs of F, the relation must satisfy
certain other FDs. The latter set of FDs are said to be derived or
logically deduced from the FDs of F.
1. If Y X, then X → Y (Reflexivity)
2. If X → Y, then XW → Y and/or XW → YW(Augmentation)
3. If X → Y and Y → Z, then X → Z (Transitivity)
4. If X → Y and YW → Z, then XW → Z (Pseudotransitivity)
5. If X → Z and X → Y, then X → YZ (Additivity or Union)
6. If X → YZ then X → Y and X → Z ( Projectivity or
Decomposition)


 Trivial and Non-trivial Dependency
Trivial
– A functional dependency FD: X → Y is called trivial if Y is a
subset of X.
– In other words, a dependency FD: X → Y means that the values
of Y are determined by the values of X.
Non-Trivial
– If an FD X → Y holds, where Y is not a subset of X, then it is
called a non-trivial FD.

 Canonical Cover
For a given set F of FDs, a canonical cover, denoted by Fc, is a
set of FDs where the following conditions are simultaneously
satisfied:
1. Every FD of Fc is simple. That is, the right-hand side of
every functional dependency of Fc has only one attribute.
2. Fc is left-reduced.
3. Fc is nonredundant.

 Canonical Cover
Example: Given the set F of FDs shown below, find a canonical cover for F.
F= {X → Z, XY → WP, XY → ZWQ, XZ → R}.
FC = {X → Z, XY → WP, XY → ZWQ, XZ → R}
= {X → Z, XY → W, XY → P, XY → Z, XY → W, XY → Q, XZ → R}. [Simple]
= {X → Z, XY → W, XY → P, XY → Z, XY → Q, XZ → R}. [Remove redundancy]
= {X → Z, XY → W, XY → P, XY → Z, XY → Q, XZ → R}.
= {X → Z, XY → W, XY → P, XY → Q, XZ → R}. [Remove redundancy]
= {X → Z, XY → W, XY → P, XY → Q, XZ → R}.
= {X → Z, XY → W, XY → P, XY → Q, X → R}. [Left-reduced]
FC = {X → Z, XY → W, XY → P, XY → Q, X → R}.
This resulting set where all FDs are simple, left-reduced and
non-redundant, is the canonical cover of F.

Problem 1: Assume that AB → C, C → D and D → A are
simultaneously satisfied by a relation r(R). What are the
candidate keys of this relation? Which one is the PK? What are
the prime attributes? Are there any super keys for this relation?
Solution:
A set of attributes of r is a candidate key of r if and only if the
set functionally determines every attribute of the relation. The
set of attributes that can be selected as candidate keys of the
relation r are: AB and DB. Let's see why.

Problem 1: Assume that AB → C, C → D and D → A . . . . .
AB is a candidate key.
The given FDs are: AB → C, C → D and D → A.
If AB is a key of r then it must be true that
AB → A, AB → B, AB→ C and AB→ D.
Using the inference axioms and the FDs of F we have that:
AB → A and AB → B ( Reflexivity axiom)
AB → C (given)
AB → C (given) and C → D (given) then AB → D (Transitivity
axiom)
Therefore, AB is a candidate key of the relation r because it
functionally determines any other attribute of the relation r.

DB is another candidate key.
The given FDs are: AB → C, C → D and D → A.
If DB is a key of r then it must be true that
DB → A, DB → B, DB → C and DB → D.
Using the inference axioms and the FDs of we have that;
DB → D and DB → B (Reflexivity axiom)
DB → D (previous step) and D → A (given) we have that DB → A
(Transitivity axiom)
DB → A (from previous step) and AB → C (given) then DBB → C
(Pseudotransitivity axiom)
Since B U B= B we can rewrite DBB → C as DB → C.
Therefore, DB is a candidate key of the relation r because it
functionally determines all other attributes of the relation r.

– There are two candidate keys AB and DB. However, only
one can be selected as the PK of the relation. The database
designer or the DBA should choose the one that makes more
sense or is more convenient for the application.
– The prime attributes of this relation are: A, B and D. A prime
attribute is any attribute that is part of a PK or an alternate
key.
– There are several super keys. They are: ABC, ADB, ABCD,
DBA, DBC and DBAC.

Problem 2: Given the relation r(A, B, C) and the set F={AB → C, B →
D, D → B} of functional dependencies, find the candidate keys of the
relation. How many candidate keys are in this relation? What are the
prime attributes?
AB → A and AB → B ( Reflexivity axiom)
AB → C (given)
AB → B (step 1) and B → D (given) then AB → D ( Transitivity
axiom)
Since AB determines every other attribute of the relation, we have that

Problem 2:. . . . .
AD is a candidate key.
AD → A and AD → D ( Reflexivity axiom)
AD → D (step 1) and D → B (given) then AD → B
AD → B (step 2) and AB → C (given) then AAD → C
(Pseudotransitivity axiom).
i.e. AD → C
Since AD determines every other attribute of the relation, we have that
AD is another candidate key.
The prime attributes are: A, B, and D.

 Prime and Non-prime attribute
– Prime attribute
• An attribute, which is a part of the primary-key, is known as a
prime attribute.
– Non-prime attribute
• An attribute, which is not a part of the primary-key, is said to
be a non-prime attribute.

Normalization
Normalization
– It refers to a reversible step-by-step process in which a
given set of relations is replaced by successive collections
of relations that have a progressively simpler and more
regular structure.
– Each step is referred to as a normal form.
– Since the process is reversible, the original set of relations
can be recovered with no loss of information.

Normalization
Objectives
– To make it feasible to represent any relation in the database.
– To obtain powerful relational retrieval algorithms based on a
collection of primitive relational operators.
– To free relations from undesirable insertion, update, and
deletion anomalies.
– To reduce the need for restructuring the relations as new data
types are introduced.

Normalization
Question: Normalize step by step the following database into 1NF, 2NF
and 3NF:
PROJECT(Proj-ID, Proj-Name, Proj-Mgr-ID, Emp-ID, Emp-Name,
Emp-Dpt, Emp-Hrly-rate, Total-Hrs)
Solution:
Table entries that have more than one value are called multivalue
entries. Table with multivalue entries are called unnormalized tables.
Within an unnormalized table, we will call a repeating group an
attribute or group of attributes that may have multivalue entries for
single occurrences of the table identifier. Here table PROJECT is an
unnormalized table where attributes Emp-ID, Emp-Name, Emp-Dpt,
Emp-Hrly-rate, and Total-Hrs are repeating groups. Thus, we need to
put the table in first normal form (1NF).

Normalization
FIRST NORMAL FORM (1NF)
– A relation r(R) is said to be in First Normal Form (1NF), if and
only if every entry of the relation has at most a single value.
– Thus, it requires to decompose the table PROJECT into two new
tables.
– It is also necessary to identify a PK for each table.

Normalization
– First table with nonrepeating groups:
PROJECT (Proj-ID, Proj-Name, Proj-Mgr-ID)
– Second table with table identifier and all repeating groups:
PROJECT-EMPLOYEE (Proj-ID, Emp-ID, Emp-Name,
– Here Proj-ID is the table identifier.

Normalization
Data Anomalies in 1NF Relations
– Redundancies in 1NF relations lead to a variety of data
anomalies:
• Insertion anomalies,
• Deletion anomalies and
• Update anomalies.

Normalization
– Insertion anomalies occur in PROJECT-EMPLOYEE relation
because we cannot insert information about any new employee
unless that employee is already assigned to a project. Any attribute
of the composite key (Proj-ID, Emp-ID) cannot be NULL.
– Deletion anomalies occur when we delete the last tuple of a
particular employee. In this case, we not only delete the project
information that connects that employee to a particular project but
also lose other information about the department for which this
employee works.

Normalization
– Update anomalies occur because the department for which an
employee works may appear many times in the table. It is this
redundancy of information that causes the anomaly because if
an employee moves to another department, we are now faced
with two problems: we either search the entire table looking
for that employee and update his Emp-Dpt value or we miss
one or more tuples of that employee and end up with an
inconsistent state.

Normalization
Partial Dependencies
– Given a relation r(R), the sets of attributes X and Y ( X,Y R),
and X → Y, we will say that attribute Y is fully dependent on
attribute X if only if there is no proper subset W of X such
that W → Y.
– If there is a proper subset W of X such that W → Y then
attribute Y is said to be partially dependent on attribute X.


Normalization
Partial Dependencies
PROJECT-EMPLOYEE (Proj-ID, Emp-ID, Emp-Name, Emp-Dpt,
Emp-Hrly-rate, Total-Hrs)
Emp-Id
Proj-Id
Emp-Name
Emp-Dpt
Emp-Hrly-Rate

Normalization
SECOND NORMAL FORM (2NF)
A relation r (R) is in Second Normal Form (2NF) if and only if the
following two conditions are met simultaneously:
• r(R) is already in 1NF.
• No nonprime attribute is partially dependent on any key or,
equivalently, each nonprime attribute in R is fully dependent
on every key.

Normalization
– In PROJECT-EMPLOYEE relation attributes Emp-Name,
Emp-Dpt and Emp-Hrly-rate are fully dependent only on Emp-
ID.
– The only attribute Total-Hrs fully depends on the composite PK
(Proj-ID, Emp-ID). This is shown below.
PROJECT-EMPLOYEE (Proj-ID, Emp-ID, Emp-Name, Emp-Dpt, Emp-Hrly-rate, Total-Hrs)

Normalization
Now break this relation into two new relations so that partial dependency
does not exist.
– HOURS-ASSIGNED (Proj-ID, Emp-ID, Total-Hrs)
– EMPLOYEE (Emp-ID, Emp-Name, Emp-Dpt, Emp-Hrly-rate)

Normalization
Relations in 2NF are still subject to data anomalies:
 Insertion anomalies,
 Deletion anomalies and
 Update anomalies.

Normalization
Insertion anomalies:
– For sake of explanation, let us assume that the department in which
an employee works functionally determines the hourly rate charged
by that employee. That is,
Emp-Dpt → Emp-Hrly-rate.
– Insertion anomalies occur in the EMPLOYEE relation. For
example, consider a situation where we would like to set in
advance the rate to be charged by the employees for a new
department. We cannot insert this information until there is an
employee assigned to that department.

Normalization
Deletion anomalies occur whenever we delete the tuple of an
employee who happens to be the only employee left in a department.
In this case, we lose the information about the rate that the department
charges.
Update anomalies occur because there may be several employees
from the same department working on different projects. If the
department rate changes, we need to make sure that the corresponding
rate is changed for all employees that work for that department.
Otherwise, the database may end up in an inconsistent state.

Normalization
Transitive Dependencies
Assume that A, B, and C are the set of attributes of a relation r(R).
Further assume that the following functional dependencies are
satisfied simultaneously:
A → B,
B A,
B → C,
C A and A → C.
C → B is neither prohibited nor required.
If all these conditions are true, we will say that attribute C is
transitively dependent on attribute A.

Normalization
THIRD NORMAL FORM (3NF)
– A relation r(R) is in Third Normal Form (3NF) if and only if the
following conditions are satisfied simultaneously:
• r(R) is already in 2NF.
• No nonprime attribute is transitively dependent on the key (i.e.
No nonprime attribute functionally determines any other
nonprime attribute).

Normalization
In EMPLOYEE relation, attribute Emp-Hrly-rate is transitively
dependent on the PK Emp-ID through the functional dependency
Emp-Dpt → Emp-Hrly-rate. This is shown below.
EMPLOYEE (Emp-ID, Emp-Name, Emp-Dpt, Emp-Hrly-rate)

Normalization
EMPLOYEE (Emp-ID, Emp-Name, Emp-Dpt, Emp-Hrly-rate)
Now break this relation into two new relations so that transitive dependency does
not exist.
EMPLOYEE (Emp-ID, Emp-Name, Emp-Dpt)
CHARGES (Emp-Dpt, Emp-Hrly-rate)
The new set of relations that we have obtained through the normalization process
does not exhibit any of the anomalies. That is, we can insert, delete and update
tuples without any of the side effects.

Normalization
Relations in 3NF are still susceptible to data anomalies
particularly when the relations have two overlapping candidate
keys or when a non prime attribute functionally determines a
prime attribute.

Normalization
Question. Normalize the following database step by step into 1NF,
2NF and 3NF:
SALES (Emp-No, Emp-Name, Store-Branch, Department, Item-No,
Item-Description, Sale-Price)
Solution:
Test Condition 1: Is the database unnormalized?
That is, repeating group and non-repeating group exist
simultaneously?
Then i) Decompose the table into two new tables.
ii) Identify PK for each table.
ii) Set a table identifier.

Normalization
SALES (Emp-No, Emp-Name, Store-Branch, Department, Item-No, Item-
Description, Sale-Price)
FIRST NORMAL FORM (1NF)
Non-Repeating group: Emp-No, Emp-Name, Store-Branch, Department
Repeating group: Item-No, Item-Description, Sale-Price
First table with non-repeating groups:
SALESPERSON (Emp-No, Emp-Name, Store-Branch, Department)
Second table with table identifier and all repeating groups:
SALES (Emp-No, Item-No, Item-Description, Sale-Price)
Here Emp-No is the table identifier.

Normalization
Test Condition 2: Data anomalies occur? Partial dependency exists?
In SALES relation, attribute Sale-Price is fully dependent on the
composite PK (Emp-No, Item-No). The attribute Item-Description
depends only on Item-No. This is shown below.

Normalization
Now break the SALES relation into two new relations so that partial
dependency does not exist.
SALESPERSON-ITEM (Emp-No, Item-No, Sale-Price)
ITEM-INFO (Item-No, Item-Description)

Normalization
Test Condition 3: Data anomalies occur? Transitive dependency exists?
In SALESPERSON relation, attribute Department is transitively
dependent on the PK Emp-No. This is shown below.

Normalization

Normalization
Now break the SALESPERSON relation into two new relations so that
transitive dependency does not exist.
SALESPERSON (Emp-No, Emp-Name, Store-Branch)
STORE (Store-Branch, Department)

Normalization
After 3NF, the new set of relations that we have obtained through the
normalization process does not exhibit any of the anomalies. That is,
we can insert, delete and update tuples without any of the side effects.
SALESPERSON (Emp-No, Emp-Name, Store-Branch)
STORE (Store-Branch, Department)

Normalization
Example: Consider the MANUFACTURER relation shown below where
each manufacturer has a unique ID and name. Manufacturers produce
items (identified by their unique item numbers) in the amounts
indicated. Manufacturers may produce more than one item and
different Manufacturers may produce the same items.
MANUFACTURER
ID Name Item-No Quantity
M101 Electronics USA H3552 1000
M101 Electronics USA J08732 500
M101 Electronics USA Y23490 200
M322 Electronics-R-Us H3552 900

Normalization
– This MANUFACTURER relation has two candidate keys:
(ID, Item-No) and (Name, Item-No)
that overlap on the attribute Item-No.
– The relation is in 3NF because there is only one nonprime attribute
and therefore it is impossible that this attribute can determine
another nonprime attribute.
– The relation MANUFACTURER is susceptible to update
anomalies. Consider for example the case in which one of the
manufacturers changes its name. If the value of this attribute is not
changed in all of the corresponding tuples there is not possibility of
having an inconsistent database.

Normalization
Boyce-Codd Normal Form
– A relation r(R) is in Boyce-Codd Normal Form (BCNF) if and only
of the following conditions are met simultaneously:
• The relation is in 3NF.
• For every functional dependency of the form X → A, we have
that either A X or X is a super key of r. In other words, every
functional dependency is either a trivial dependency or in the
case that the functional dependency is not trivial, then X must
be a super key.

Normalization
Boyce-Codd Normal Form
– To transform the relation of example into BCNF, we can
decompose it onto the following set of relational schemes:
Set No. 1
– MANUFACTURER (ID, Name)
– MANUFACTURER-PART (ID, Item-No, Quantity)
OR, Set No. 2
– MANUFACTURER (ID, Name)
– MANUFACTURER-PART (Name, Item-No, Quantity)

Normalization
Decomposition: Lossless or Lossy ?
– Whenever a relation is decomposed it is necessary to
ensure that the data in the original relation is represented
faithfully. That is, we need to make sure that we can
recover the original relation from the new relations that
have replaced it.
– Generally, the original relation is recovered by forming
the natural join of the new relations. If we can recover
the original relation we say that the decomposition is
lossless. Otherwise, it is lossy.

Normalization
Decomposition: Lossless or Lossy ?
Example: Consider the relation r shown below and its decomposition
R1 and R2. Is this decomposition lossless or lossy?
r R1 R2
X Y Z
x1 y1 z1
x2 y2 z2
x3 y2 z3
x4 y3 z4
X Y
x1 y1
x2 y2
x3 y2
x4 y3
Y Z
y1 z1
y2 z2
y2 z3
y3 z4
Decompose

Normalization
Lossless or Lossy Decomposition ?
r R1 R2
X Y Z
x1 y1 z1
x2 y2 z2
x3 y2 z3
x4 y3 z4
X Y
x1 y1
x2 y2
x3 y2
x4 y3
Y Z
y1 z1
y2 z2
y2 z3
y3 z4
Decompose
X Y Z
x1 y1 z1
x2 y2 z2
x2 y2 z3
x3 y2 z2
x3 y2 z3
x4 y3 z4
R1 Join R2

Normalization
Lossless or Lossy Decomposition ?
Example: Consider the relation r shown below and its decomposition
R1 and R2. Is this decomposition lossless or lossy?
Notice that the natural join of R1 and R2 has tuples that were not
present in the original relation. These tuples are called spurious tuples
because they represent spurious or false information. Since the
natural join of R1 and R2 does not recover the original relation, the
decomposition is lossy.

Functional dependency and normalization

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Functional dependency and normalization

Ähnlich wie Functional dependency and normalization (20)

Mehr von University of Potsdam

Mehr von University of Potsdam (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Functional dependency and normalization