Normalization
Design guidelines
Semantics of the Relation attributes
GUIDELINE 1: Informally, each tuple in a relation should
represent one entity or relationship instance. (Applies to
individual relations and their attributes).
• Attributes of different entities (EMPLOYEEs, DEPARTMENTs,
PROJECTs) should not be mixed in the same relation
• Only foreign keys should be used to refer to other entities
• Entity and relationship attributes should be kept apart as much as
possible.
Example
Design guidelines
Redundant Information in Tuples and Update
Anomalies
• Mixing attributes of multiple entities may cause
problems
• Information is stored redundantly wasting storage
• Problems with update anomalies
▫ Insertion anomalies
▫ Deletion anomalies
▫ Modification anomalies
Example of Update anomalies
Consider the relation:
EMP_PROJ ( Emp#, Proj#, Ename, Pname, No_hours)
• Modification Anomaly: Changing the name of
project number P1 from “Billing” to “CustomerAccounting” may cause this update to be made for all
100 employees working on project P1.
Example of Update anomalies
• Insert Anomaly: Cannot insert a project unless an employee
is assigned to .
Inversely - Cannot insert an employee unless he/she is
assigned to a project.
• Delete Anomaly: When a project is deleted, it will result in
deleting all the employees who work on that project.
Alternately, if an employee is the sole employee on a project,
deleting that employee would result in deleting the
corresponding project.
Design guidelines
• GUIDELINE 2: Design a schema that does not suffer
from the insertion, deletion and update anomalies. If
there are any present, then note them so that
applications can be made to take them into account
Design guidelines
NULL Values in tuples
GUIDELINE 3: Relations should be designed such that
their tuples will have as few NULL values as possible.
• Attributes that are NULL frequently could be placed in
separate relations (with the primary key)
• Reasons for nulls:
▫ attribute not applicable or invalid
▫ attribute value unknown (may exist)
▫ value known to exist, but unavailable
Design guidelines
Spurious tuples
• Bad designs for a relational database may result in
erroneous results for certain JOIN operations
• The "lossless join" property is used to guarantee
meaningful results for join operations.
GUIDELINE 4: The relations should be designed to
satisfy the lossless join condition. No spurious tuples
should be generated by doing a natural-join of any
relations.
Design guidelines
Spurious tuples
There are two important properties of decompositions:
(a) non-additive or losslessness of the corresponding join
(b) preservation of the functional dependencies.
Note that property (a) is extremely important and cannot
be sacrificed. Property (b) is less stringent and may be
sacrificed.
Functional dependencies
• Functional dependencies (FDs) are used to specify
formal measures of the "goodness" of relational designs
• FDs and keys are used to define normal forms for
relations
• FDs are constraints that are derived from the meaning
and interrelationships of the data attributes
• A set of attributes X functionally determines a set of
attributes Y if the value of X determines a unique value
for Y
Functional dependencies
• X -> Y holds if whenever two tuples have the same value
for X, they must have the same value for Y
• For any two tuples t1 and t2 in any relation instance
r(R): If t1[X]=t2[X], then t1[Y]=t2[Y]
• X -> Y in R specifies a constraint on all relation
instances r(R)
• Written as X -> Y; can be displayed graphically on a
relation schema. ( denoted by the arrow).
• FDs are derived from the real-world constraints on the
attributes
Examples of FDs
• social security number determines employee name
SSN -> ENAME
• project number determines project name and
location
PNUMBER -> {PNAME, PLOCATION}
• employee ssn and project number determines the
hours per week that the employee works on the
project
{SSN, PNUMBER} -> HOURS
Functional dependencies
• An FD is a property of the attributes in the schema R
• The constraint must hold on every relation instance
r(R)
• If K is a key of R, then K functionally determines all
attributes in R (since we never have two distinct tuples
with t1[K]=t2[K])
Inference Rules for FDs
• Given a set of FDs F, we can infer additional FDs that
hold whenever the FDs in F hold.
Armstrong's inference rules:
IR1. (Reflexive) If Y subset-of X, then X -> Y
IR2. (Augmentation) If X -> Y, then XZ -> YZ
(Notation: XZ stands for X U Z)
IR3. (Transitive) If X -> Y and Y -> Z, then X -> Z
•
IR1, IR2, IR3 form a sound
inference rules
and complete
set of
Inference Rules for FDs
Some additional inference rules that are useful:
• (Decomposition) If X -> YZ, then X -> Y and X -> Z
• (Union) If X -> Y and X -> Z, then X -> YZ
• (Psuedotransitivity) If X -> Y and WY -> Z, then WX -> Z
The last three inference rules, as well as any other
inference rules, can be deduced from IR1, IR2, and IR3
(completeness property)
Normalization
 The process of analyzing the relation schema based on
functional dependencies and primary key.
 The process of decomposing unsatisfactory "bad"
relations by breaking up their attributes into smaller
relations.
 The normal form of a relation refers to the highest
normal form condition that it meets.
 Denormalization: the process of storing the join of
higher normal form relations as a base relation—which is
in a lower normal form
Definitions of keys
• If a relation schema has more than one key, each is
called a candidate key. One of the candidate keys is
arbitrarily designated to be the primary key, and the
others are called secondary keys.
• A Prime attribute must be a member of some
candidate key
• A Nonprime attribute is not a prime attribute—that
is, it is not a member of any candidate key.
Levels of Normalization
•
Various levels of normalization are:
▫
▫
▫
▫
▫
▫
First Normal Form (1NF)
Second Normal Form (2NF)
Third Normal Form (3NF)
Boyce-Codd Normal Form (BCNF)
Fourth Normal Form (4NF)
Fifth Normal Form (5NF)
Most databases should be 3NF or BCNF in order to keep the query processing efficient.
Levels of Normalization
5NF
4NF
3NF
2NF
1NF
Purpose of Normalization
• To minimize redundancy
• To minimize update anomalies
First Normal Form
• Disallows
▫ composite attributes
▫ multivalued attributes
Handling multivalued attributes
Dnumber Dname
Dlocation
1
Research
Noida, Gurgaon
2
Administration
Delhi
3
Academic
Ghaziabad
Dnumber
Dname
Dnumber
Dlocation
1
Research
1
Noida
2
Administration
1
Gurgaon
3
Academic
2
Delhi
3
Ghaziabad
Handling composite attributes
E_id
Ename
Project
Pnum
Hours
1
John
101
102
5
7
2
Peter
101
6
E_id
Ename
E_id
Pnum
Hours
1
John
1
101
5
2
Peter
1
102
7
2
101
6
Second Normal Form
• Based on full functional dependency.
▫ A relation schema R is in 2NF if it is in 1NF and every non-prime
attribute is fully functionally dependent on primary key of R.
• Full functional dependency - a FD Y -> Z where removal of
any attribute from Y means the FD does not hold any more.
Examples:
▫ {SSN, PNUMBER} -> HOURS is a full FD since neither SSN -> HOURS nor
PNUMBER -> HOURS hold.
▫ {SSN, PNUMBER} -> ENAME is not a full FD (it is called a partial
dependency ) since SSN -> ENAME also holds.
• Applicable for functional dependencies
▫ where L.H.S. attributes are part of the primary key.
▫ where primary key is composed of more than one attribute.
Normalizing into 2NF
E_id
E_id
Pnum
Ename
Pnum
Ename
Pname
Pname
E_id
Hours
Pnum
Hours
Third Normal Form
• Based on the concept of transitive dependency.
• A relation schema R is in 3NF if it satisfies 2NF and no
non-prime attribute of R is transitively dependent on
primary key.
• If for every X → A in R,
▫ either X is a super-key of R.
▫ or A is a prime attribute of R.
Normalization into 3NF
E_id
E_id
Ename
Ename
Dnum
Dnum
Dnum
Dname
Dname
Normalization
Boyce Codd Normal Form(BCNF)
• Stricter than third normal form.
• For every X → A, X is a super key of R.
A relation in 3NF, but not in BCNF.
E_id
Pnum
Hours
Dnum
Normalizing into BCNF
E_id
Pnum
Hours
Pnum
Dnum
Questions on Functional Dependencies
Attribute Closure
To find attribute closure of an attribute set:
• Add elements of attribute set to the result set.
• Recursively add elements to the result set which can be
functionally determined from the elements of the result
set.
Questions on Functional Dependencies
1. Consider the universal relation R = {A, B, C, D, E, F, G,
H, I, J} and the set of functional dependencies F = {{A,
B} → {C}, {A} →{D, E}, {B} → {F}, {F} → {G, H}, {D}
→{I, J}}. Determine the attribute closure of B and
{A,B}.
Closure of {B} = {B,F,G,H}.
Closure of {A,B} = {A,B,C,D,E,F,G,H,I,J}.
Questions on Functional Dependencies
2. Consider the universal relation R = {A, B, C, D, E, F, G, H, I, J} and
the set of functional dependencies F = {{A, B} → {C}, {B, D} → {E, F},
{A, D} → {G, H}, {A} → {I}, {H} → {J}}. What is the key for R?
The key for any relation would be the set of attributes which can
directly or indirectly functionally determine all the other attributes.
Or, the set of attributes whose attribute closure is the set of all the
attributes.
Closure of {A,B}= {A,B,C,I}.
Closure of {A,D}= {A,D, G,H,I,J}
Closure of {B,D}= {B,D, E, F}
Closure of {A,B,D} = {A,B,D,C,E,F,G,H,I,J}
Hence {A,B,D} is the key for R.
Questions on Functional Dependencies
3. Consider a relation R(A, B, C, D, E) with the following
dependencies: AB → C, CD → E, DE → B. Is AB a candidate key
of this relation? If not, is ABD?
{A,B}+ = {A,B,C}
No, {A,B} is not a candidate key as they cannot determine all the
other attributes.
{A,B,D}+ = {A,B,D,C,E,B}
Yes, {A,B,D} is the candidate key.