Normalization

CHANDAN MUKHERJEE (Asst Prof) 26630615 9831125100
MTech,BE(CSE),Diploma(Electrical)
Java & Oracle Global Certified
Give Training in Different Multinational Company
___________________________________________________________________________________________________
Relational Database Design [9L]
Functional Dependency
Refer Navate BOOK
FUNCTIONAL DEPENDENCY
TRIVIAL FD NON TRIVIAL FD COMPLETELY NON
TRIVIAL FD
X -> Y and Y is the subset X -> Y and Y is not subset X -> Y and X intersect Y is
of X of X null
ABC -> BC ABC -> BD A -> D
Normalization using funtional dependencies.
Normalization in DBMS:
Normalization is a process of organizing the data in database to avoid data redundancy, insertion
anomaly, update anomaly & deletion anomaly.
Ensuring data dependencies make sense i.e. data is logically stored.
Normalization can also be thought of as a trade-off between data redundancy and performance.
Normalizing a relation reduces data redundancy but introduces the need for joins when all of the
data is required by an application such as a report query.
Permit efficient updates of the data in the database.
Avoid the danger of losing data unknowingly.
Different anamolies in designing a Database:
Anomalies in DBMS
Example: Suppose a manufacturing company stores the employee details in a table named
employee that has four attributes: emp_id for storing employees id, emp_name for storing
employees name, emp_address for storing employees address and emp_dept for storing the
department details in which the employee works.
_____________________________________________________________________________________
Teaches All Subjects for Engineering / Diploma / BCA / MCA / BSc / AMIE / DOECC Students.
Project Guide for BE / MCA / BCA / Diploma Students.
Address:- 80, Ramlal Dutta Road, P.O- Bhadrakali, Dist:- Hooghly, 712232. Rly Station:- Uttarpara
(Nera Amarendra Vidyapith Boys School)
___________________________________________________________________________________________________
Emp_ID Emp_Name Emp_Address Emp_Dept

101 Rik Kolkata D001
101 Rik Kolkata D002
123 Sanjay Delhi D890
166 Ravi Mumbai D900
166 Ravi Mumbai D950
The above table is not normalized. We will see the problems that we face when a table is not
normalized.
Insert anomaly: Suppose a new employee joins the company, who is under training and currently
not assigned to any department then we would not be able to insert the data into the table if
emp_dept field doesnt allow nulls.
Delete anomaly: Suppose, if at a point of time the company closes the department D890 then
deleting the rows that are having emp_dept as D890 would also delete the information of
employee Sanjay since she is assigned only to this department.
Update anomaly: In the above table we have two rows for employee Rik as he belongs to two
departments of the company. If we want to update the address of Rik then we have to update the
same in two rows or the data will become inconsistent. If somehow, the correct address gets
updated in one department but not in other then as per the database, Rick would be having two
different addresses, which is not correct and would lead to inconsistent data.
To overcome these anomalies, we need to normalize the data.
1st Normal Form

A database is in first normal form if it satisfies the following conditions:
Each attribute (column) contains atomic (Single) value only
There are no repeating groups
All values for a given attribute (column) must be of the same type.
Each attribute (column) name must be unique.
No two tuples (rows) in a relation can be identical.
The order of the tuples (rows) is insignificant.
The order of attributes (columns) is insignificant
_____________________________________________________________________________________
___________________________________________________________________________________________________
To bring this table to first normal form, we split the table into two tables and now we have the
resulting tables:
Second normal form (2NF)

A table is said to be in 2NF if both the following conditions hold:
Table is in 1NF (First normal form)
No non-prime attribute is dependent on the proper subset of any

candidate key of table.
(A relation is in second normal form if it is free from partial-key dependencies)
Relations that have a single attribute for a key are automatically in 2NF.
This is one reason why we often use artificial identifiers (non-composite keys) as keys.
Example: Suppose a school wants to store the data of teachers and the subjects they teach.
They create a table that looks like this: Since a teacher can teach more than one subjects, the
table can have multiple rows for a same teacher.
_____________________________________________________________________________________
___________________________________________________________________________________________________
Teacher_ID SUBJECT Teacher_Age

111 C 38
111 JAVA 38
222 COBOL 38
333 JAVA 40
333 Oracle 40
Candidate Keys: {Teacher_Id, Subject} Teacher ID -> Teacher_Age
Non prime attribute: Teacher_Age
The table is in 1 NF because each attribute has atomic values.
However, it is not in 2NF because non prime attribute Teacher_Age is dependent on
Teacher_ID alone which is a proper subset of candidate key. This violates the rule for 2NF as
the rule says no non-prime attribute is dependent on the proper subset of any candidate key of
the table.
To make the table complies with 2NF we can break it in two tables like this:
Teacher_details table:
Teacher ID Teacher_Age
111 38
222 38
333 40
Teacher_subject table:
Teacher_Id Subject
111 C
111 JAVA
222 COBOL
333 JAVA
333 Oracle
Now the tables comply with Second normal form (2NF).
_____________________________________________________________________________________
___________________________________________________________________________________________________
Third Normal form (3NF)

A table design is said to be in 3NF if both the following conditions hold:
Table must be in 2NF
Transitive functional dependency of non-prime attribute on any super key should be removed.
[An attribute that is not part of any candidate key is known as non-prime attribute.]
Consider relation R containing attributes A, B and C. R(A, B, C)

If A B and B C then A C (Transitive Dependency: Three attributes with the above
dependencies. )
In other words 3NF can be explained like this: A table is in 3NF if it is in 2NF and for each
functional dependency X-> Y at least one of the following conditions hold:
X is a super key of table
Y is a prime attribute of table
An attribute that is a part of one of the candidate keys is known as prime attribute.
_____________________________________________________________________________________
___________________________________________________________________________________________________
FD are : Book ID -> Price, Genere ID

Genere ID -> Genere Type
_____________________________________________________________________________________
___________________________________________________________________________________________________
Boyce -Codd Normal form (BCNF)
Table must be in 3NF

A relation is in BCNF, if and only if, every determinant is a candidate key.
FD : Student_ID, Major -> Advisor

[Each Student Takes 1 course(Major) from 1 Teacher(Advisor)
only but 1 Student takes more than 1 course(Major)]
Advisor -> Major [Each Teacher(Advisor) Teaches only 1 Subject(Major) ]
Primary Key : [Student_ID, Major]
Above Table is in 3NF. NO TRANSITIVE DEPENDENCY.
Problems BCNF overcomes
If the record for student 232-22-2111 is deleted, we lose not only information on that student but
also lost the fact that GOWAN advises in MANAGEMENT.
we cannot record the fact that WATSON can advise on COMPUTING until we have a student
majoring in COMPUTING to whom we can assign WATSON as an advisor.
_____________________________________________________________________________________
___________________________________________________________________________________________________
After Divide in BCNF
IT IS LOSSLESS JOIN
BUT FD Student_ID, Major -> Advisor IS NOT PRESEVING HERE.
SO BCNF IS NOT ALWAYS DEPENDENCY PRESERVING.
_____________________________________________________________________________________
___________________________________________________________________________________________________
RELATION IS IN 3NF BUT NOT IN BCNF
The difference between 3NF and BCNF is that

For a functional dependency A B,
3NF allows this dependency in a relation if B is a primary-key attribute and A is not a candidate
key,
whereas BCNF insists that for this dependency to remain in a relation, A must be a candidate
key.
Why BCNF is stronger than 3NF

A relation R is in 3NF if and only if every dependency A->B satisfied by R meets at least ONE of the following
criteria:
1. A->B is trivial (i.e. B is a subset of A)
2. A is a superkey
3. B is a subset of a candidate key
BCNF doesn't permit the third of these options.
Therefore, BCNF is said to be stronger than 3NF because 3NF permits some dependencies which BCNF does
not.
OR
_____________________________________________________________________________________
___________________________________________________________________________________________________
When a relation has more than one candidate key, anomalies may result even though the relation
is in 3NF.
3NF does not deal satisfactorily with the case of a relation with overlapping candidate keys i.e.
composite candidate keys with at least one attribute in common.
BCNF is based on the concept of a determinant.
A determinant is any attribute (simple or composite) on which some other attribute is fully
functionally dependent.
A relation is in BCNF is, and only if, every determinant is a candidate key.
BCNF covers very specific situations where 3NF misses inter-dependencies between non-key (but
candidate key) attributes. Typically, any relation that is in 3NF is also in BCNF.
However, a 3NF relation won't be in BCNF if
(a) there are multiple candidate keys,
(b) the keys are composed of multiple attributes, and
(c) there are common attributes between the keys.
Decomposition:
Emp ID Emp Training Training Training Skill ID Skill Skill Where Grades
Name Center Center Center Name Learned(Room
Code Name Location No)
1 Chandan 50 EcoSpace Kolkata 21 Java 203 8
22 .Net 104 7
23 Oracle 306 9
2 Supratim 60 Building Bangalore 21 Java 150 7
24 C 160 8
23 Oracle 310 9
Here relation between Emp & skill is 1 : M
Apply the 1st Rule All attribute should be atomic. We get the following table.
Emp ID Emp Training Training Training Skill ID Skill Skill Where Grades
Name Center Center Center Name Learned(Room
Code Name Location No)
_____________________________________________________________________________________
___________________________________________________________________________________________________
1 Chandan 50 EcoSpace Kolkata 21 Java 203 8
1 Chandan 50 EcoSpace Kolkata 22 .Net 104 7
1 Chandan 50 EcoSpace Kolkata 23 Oracle 306 9
2 Supratim 60 Building Bangalore 21 Java 150 7
2 Supratim 60 Building Bangalore 24 C 160 8
2 Supratim 60 Building Bangalore 23 Oracle 310 9
Apply the 2nd Rule. Separate repeating group of data. We get the following tables.
Table 1
Emp ID Emp Name Training Center Training Center Training Center
Code Name Location
1 Chandan 50 EcoSpace Kolkata
2 Supratim 60 Building Bangalore
Table 2
Emp ID Skill ID Skill Name Skill Where Grades
Learned
(Room No)
1 21 Java 203 8
1 22 .Net 104 7
1 23 Oracle 306 9
2 21 Java 150 7
2 24 C 160 8
2 23 Oracle 310 9
AFTER 1 NF WE ARE GETTING 2 TABLES.
In TABLE 2
Skill ID -> Skill Name
Emp ID, Skill ID -> Skill Where Learned , Grades
Here Candidate key is { Emp ID, Skill ID } . Partial dependency present. Now divide it.
_____________________________________________________________________________________
___________________________________________________________________________________________________
Emp ID Skill ID Skill Name Skill Where Grades

Learned
(Room No)
1 21 Java 203 8
1 22 .Net 104 7
1 23 Oracle 306 9
2 21 Java 150 7
2 24 C 160 8
2 23 Oracle 310 9
Divide the Table 2 in two different tables for removing partial dependency.
Table -3
Skill ID Skill Name
21 Java
22 .Net
23 Oracle
21 Java
24 C
23 Oracle
Table -4
Emp ID Skill ID Skill Where Learned Grades
(Room No)
1 21 203 8
1 22 104 7
1 23 306 9
2 21 150 7
2 24 160 8
2 23 310 9
Now Both Table (Table 3 & Table 4) in 2NF. No Partial Dependency Present
Table 1
Emp ID Emp Name Training Center Training Center Training Center
Code Name Location
1 Chandan 50 EcoSpace Kolkata
2 Supratim 60 Building Bangalore
Emp ID -> Emp Name, Training Center Code

Training Center Code -> Training Center Name, Training Center Location
_____________________________________________________________________________________
___________________________________________________________________________________________________
Here Transitive dependency present. So this table is in 2NF but Not in 3NF. To convert this in 3NF we
divide the table.
Table 4
Emp ID Emp Name Training
Center Code
1 Chandan 50
2 Supratim 60
Table 5
Training Center Training Center Training Center
Code Name Location
50 EcoSpace Kolkata
60 Building Bangalore
Now Table 4 & Table 5 is in 3NF. No Transitive Dependency Present.
EXAMPLE:
_____________________________________________________________________________________
___________________________________________________________________________________________________
_____________________________________________________________________________________
___________________________________________________________________________________________________
_____________________________________________________________________________________
___________________________________________________________________________________________________
EXAMPLE 2
Primary key is (S#, P#)
FD : S#,P# -> QTY

S# -> STATUS, CITY
CITY -> STATUS
PARTIAL DEPENDENCY PRESENT(STATUS & CITY ONLY DEPENDS ON S#) SO DIVIDE IT.
_____________________________________________________________________________________
___________________________________________________________________________________________________
FD : S# -> STATUS, CITY S#,P# -> QTY
CITY -> STATUS
HERE TRANSITIVE DEPENDENCY PRESENT S# -> CITY, CITY -> STATUS
CANONICAL COVER OR MINIMAL COVER :-

1. SINGLETONE RIGHT HAND SIDE. [ EXAMPLE :- A -> B OR AC -> B ]
2. REMOVAL OF EXTRANEOUS ATTRIBUTE. [MEANS EXTRA ATTRIBUTE WHICH NOT REQUIRED]
3. REMOVAL OF REDUNDENT FUNCTIONAL DEPENDENCY
F = { A -> B, AB -> C, D -> AC, D -> E } G = { A -> BC, D -> AB }
APPLY RULE 1 FOR F APPLY RULE 1 FOR G

A -> B A -> B
AB -> C A -> C
D -> A [ USING DECOMPOSITION D -> A
RULE] D -> B
D -> C
D -> E
ONLY CHECK LEFT HAND SIDE MORE ONLY CHECK LEFT HAND SIDE MORE
THAN 1 ATTRIBUTE RELATED FD LIKE THAN 1 ATTRIBUTE RELATED FD LIKE
AB -> C AB -> C
FOR AB -> C HERE ALL LEFT HAND SIDE
CALCULATE ATTRIBUTE ARE SINGLE . SO WE
A+ = { A } DONT NEED TO CHECK ANYTHING.
= { A B } [ USING A -> B]
B+ = { B }
FROM A CLOSURE WE ARE GETTING B.

SO B IS EXTRANEOUS ATTRIBUTE. WE
REMOVE B. SO
AB -> C BECOMES A -> C
A -> B A -> B
_____________________________________________________________________________________
___________________________________________________________________________________________________
A -> C A -> C
D -> A D -> A
D -> C D -> B
D -> E
CONSIDER A -> B. NOW CALCULATE A CONSIDER A -> B. NOW CALCULATE A
CLOSURE WITHOUT USING A -> B FD. CLOSURE WITHOUT USING A -> B FD.
NOW CALCULATE A+ ={ A C } NOW CALCULATE A+ ={ A C }
SO WE CAN T GET B HERE. SO A -> B IS SO WE CAN T GET B HERE. SO A -> B IS
NOT REDUNDENT. NOT REDUNDENT.
CONSIDER A -> C. NOW CALCULATE A CONSIDER A -> C. NOW CALCULATE A
CLOSURE WITHOUT USING A -> C FD. CLOSURE WITHOUT USING A -> C FD.
NOW CALCULATE A+ ={ A B } NOW CALCULATE A+ ={ A B }
SO WE CAN T GET C HERE. SO A -> C IS SO WE CAN T GET C HERE. SO A -> C IS
NOT REDUNDENT. NOT REDUNDENT.
CONSIDER D -> A. NOW CALCULATE D CONSIDER D -> A. NOW CALCULATE D
CLOSURE WITHOUT USING D -> A FD. CLOSURE WITHOUT USING D -> A FD.
NOW CALCULATE D+ ={ D C E } NOW CALCULATE D+ ={ D B }
SO WE CAN T GET A HERE. SO D -> A SO WE CAN T GET A HERE. SO D -> A
IS NOT REDUNDENT. IS NOT REDUNDENT.
CONSIDER D -> C. NOW CALCULATE A CONSIDER D -> B. NOW CALCULATE D
CLOSURE WITHOUT USING D -> C FD. CLOSURE WITHOUT USING D -> B FD.
NOW CALCULATE D+ ={ D A E B C } NOW CALCULATE D+ ={ D A B C }
SO WE ARE GETTING C HERE. SO D -> C SO WE ARE GETTING B HERE. SO D -> B
IS REDUNDENT. WE SHOULD REMOVE IS REDUNDENT. WE SHOULD REMOVE
IT. IT.
CONSIDER D -> E. NOW CALCULATE D
CLOSURE WITHOUT USING D -> E FD.
NOW CALCULATE D+ ={ D C B }
SO WE CAN T GET E HERE. SO D -> E IS
NOT REDUNDENT.
A -> B A -> B
A -> C A -> C
D -> A D -> A
D -> E
ANSWER IS F COVERS G
lossy decompostion
Loss of information on either the data in our table or the interrelationships between the various
data items are called lossy decompostion.
In lossy decompostion,the information found in original database is not preserved after
decomposition.
In lossy decomposition,we loss some of the functional dependency relationship
_____________________________________________________________________________________
___________________________________________________________________________________________________
LOSSLESS
The lossless join property is a feature of decomposition supported by normalization. It is the
ability to ensure that any instance of the original relation can be identified from corresponding
instances in the smaller relations. Lossless means functioning without a loss. In other words,
retain everything.
_____________________________________________________________________________________
___________________________________________________________________________________________________
DEPENDENCY PRESERVING
_____________________________________________________________________________________
___________________________________________________________________________________________________
_____________________________________________________________________________________
___________________________________________________________________________________________________
Multi-Valued Dependencies:
REFER NAVATE BOOK
DEFINATION
Let R be a relation schema. The multivalued dependency ->> holds on R if, in any legal
relation r(R), for all pairs of tuples t1 and t2 in r such that t1[] = t2[], there exist tuples t3
and t4 in r such that
t1[] = t2[] = t3[] = t4[]
t3[] = t1[]
t3[R ] = t2[R ]
t4[] = t2[]
t4[R ] = t1[R ]
A multivalued dependency (MVD) on R, X ->->Y, says that if two tuples of R agree on

all the attributes of X, then their components in Y may be swapped, and the result will
be two tuples that are also in the relation.
i.e., for each value of X, the values of Y are independent of the values of R-X-Y
_____________________________________________________________________________________
___________________________________________________________________________________________________
To understand the concept of MVD, let us consider a schema denoted as MPD (Man, Phones, Dog_Like),
Person : Meaning of the tuples
Man(M) Phones(P) Dogs_Like(D) Man M have phones P, and likes the dogs D.
M1 P1/P2 D1/D2 M1 have phones P1 and P2, and likes the dogs D1 and D2.
M2 P3 D2 M2 have phones P3, and likes the dog D2.
Key : MPD
There are no non trivial FDs because all attributes are combined forming Candidate Key i.e. MDP. The
multivalued dependency is shown by. So, in the above relation, two multivalued dependencies exists

1. Man Phones
2. Man Dogs_Like
A mans phone are independent of the dogs they like. But after converting the above relation in Single Valued
Attribute, Each of a mans phones appears with each of the dogs they like in all combinations.
Man(M) Phones(P) Dogs_Likes(D)

M1 P1 D1
M1 P2 D2
M2 P3 D2
M1 P1 D2
M1 P2 D1
Some Points to note here about relation Person :

Some unwanted(shaded) tuples will also exist in the relation while converting it into single
valued attributes.
However, We can see that the relation is in BCNF, and thus we would not consider decomposing
if further if we looked only at the FDs that hold over the relation Person.
The redundancy exists in BCNF relation because of MVD.
_____________________________________________________________________________________
___________________________________________________________________________________________________
Trivial and Non Trivial MVD :
A MVD X Y in R is called a trivial MVD is
Y is a subset of X (X Y) or
X Y = R. Otherwise, it is a non trivial MVD and we have to repeat values redundantly
in the tuples.
4NF
DEFINATION NAVATE BOOK
Man(M) Phones(P) Dogs_Likes(D) Address(A)

M1 P1 D1 49-ABC,Bhiwani(HR.)
M2 P3 D2 36-XYZ,Rohtak(HR.)
The Key of the relation is MPD, and there are two multivalued dependencies exists in the relation and one FD,
which are
1. FD1 : Man Phones
2. FD2 : Man Dogs_Like
3. FD3 : Man Address
All dependencies violate 4NF. To remove MVDs, We decompose Person_Modify into relations as:
_____________________________________________________________________________________
___________________________________________________________________________________________________
In the above relations for both the MVDs X is Man, which is again not the super key, but as X Y = R i.e.
(Man & Phones) together make the relation.
So, the above MVDs are trivial and in FD 3, Address is functionally dependent on Man, where Man is the key
in Person_Address, hence all the three relations are in 4NF.
Every nontrivial MVD is really an FD with a superkey on the left, if the relation is in 4NF.
5NF
Definition 1 :
A relation R is in 5NF if and only if every join dependency in R is implied by the candidate keys of R.
Definition 2 :
A relation decomposed into two relations must have loss-less join Property, which ensures that no spurious
or extra tuples are generated, when relations are reunited through a natural join.
Example:
If a company makes a product and an agent is an agent for that company, then he always sells that product
for the company. Under these circumstances, the ACP table is shown as:
ACP :
Agent Company Product
A1 PQR Nut
A1 PQR Bolt
A1 XYZ Nut
A1 XYZ Bolt
A2 PQR Nut
_____________________________________________________________________________________
___________________________________________________________________________________________________
The relation ACP is again decompose into 3 relations. Now, the natural Join of all the three relations will be
shown as :
R3 :
R1 : R2 :
Company Product
Agent Company Agent Product
PQR Nut
A1 PQR A1 Nut
PQR Bolt
A1 XYZ A1 Bolt
XYZ Nut
A2 PQR A2 Nut
XYZ Bolt
Result of Natural Join of R1 and R3 over Company and then Natural Join of R13 and R2 over Agentand
Product
R123 :
Agent Company Product
A1 PQR Nut
A1 PQR Bolt
A1 XYZ Nut
A1 XYZ Bolt
A2 PQR Nut
Hence, in this example, all the redundancies are eliminated, and the decomposition of ACP is a lossless join
decomposition. Hence the relation is in 5NF as it does not violate the property of lossless join.
What does Denormalization mean?

Denormalization is a strategy that database managers use to increase the performance of a database
infrastructure. It involves adding redundant data to a normalized database to reduce certain types of problems
with database queries that combine data from various tables into a single table.
OR
Denormalization is the process of attempting to optimise the read performance of a database by
adding redundant data or by grouping data. In some cases, denormalisation helps cover up the
inefficiencies inherent in relational database software. A relational normalised database imposes a
heavy access load over physical storage of data even if it is well tuned for high performance.
_____________________________________________________________________________________
___________________________________________________________________________________________________
1NF 2NF 3NF BCNF
0% if it doesnt contain MVD, Otherwise, it may contain

Redundancy Hgh <1NF <2NF
Redundancy
Lossless Join Always Always Always Always
Dependency Some relation may not possible to decompose in BCNF by
Always Always Always
Preserving preserving dependency
4NF
0% redundancy Yes
Lossless Yes
Dependency Preserving may or may not be
Problem may exist ?? Join Dependency
***************************************************************************************
What is normalization?
It is a process of analysing the given relation schemas based on their Functional Dependencies (FDs)
and primary key to achieve the properties
Minimizing redundancy
Minimizing insertion, deletion and update anomalies.
What is Functional Dependency?
A Functional dependency is denoted by X Y between two sets of attributes X and Y that are subsets
of R specifies a constraint on the possible tuple that can form a relation state r of R. The constraint is for any
two tuples t1 and t2 in r if t1[X] = t2[X] then they have t1[Y] = t2[Y]. This means the value of X component
of a tuple uniquely determines the value of component Y.
When is a functional dependency F said to be minimal?
Every dependency in F has a single attribute for its right hand side.
We cannot replace any dependency X A in F with a dependency Y A where Y is a proper subset of
X and still have a set of dependency that is equivalent to F.
We cannot remove any dependency from F and still have set of dependency that is equivalent to F.
What is Multivalued dependency?
Multivalued dependency denoted by X Y specified on relation schema R, where X and Y are both
subsets of R, specifies the following constraint on any relation r of R: if two tuples t1 and t2 exist in r such that
t1[X] = t2[X] then t3 and t4 should also exist in r with the following properties
t3[x] = t4[X] = t1[X] = t2[X]
t3[Y] = t1[Y] and t4[Y] = t2[Y]
t3[Z] = t2[Z] and t4[Z] = t1[Z] where [Z = (R-(X U Y)) ]
What is Lossless join property?

It guarantees that the spurious tuple generation does not occur with respect to relation schemas after
_____________________________________________________________________________________
___________________________________________________________________________________________________
decomposition.
What is 1 NF (Normal Form)?

The domain of attribute must include only atomic (simple, indivisible) values.
What is Fully Functional dependency?
It is based on concept of full functional dependency. A functional dependency X Y is full functional
dependency if removal of any attribute A from X means that the dependency does not hold any more.
What is 2NF?
A relation schema R is in 2NF if it is in 1NF and every non-prime attribute A in R is fully functionally
dependent on primary key.
What is 3NF?
A relation schema R is in 3NF if it is in 2NF and for every FD X A either of the following is true
X is a Super-key of R.
A is a prime attribute of R.
In other words, if every non prime attribute is non-transitively dependent on primary key.
What is BCNF (Boyce-Codd Normal Form)?
A relation schema R is in BCNF if it is in 3NF and satisfies additional constraints that for every FD X
A, X must be a candidate key.
What is 4NF?
A relation schema R is said to be in 4NF if for every Multivalued dependency X Y that holds
over R, one of following is true
X is subset or equal to (or) XY = R.
X is a super key.
What is 5NF?
A Relation schema R is said to be 5NF if for every join dependency {R1, R2, ..., Rn} that holds R, one
the following is true
Ri = R for some i.
The join dependency is implied by the set of FD, over R in which the left side is key of R.
What is Domain-Key Normal Form?
A relation is said to be in DKNF if all constraints and dependencies that should hold on the constraint
can be enforced by simply enforcing the domain constraint and key constraint on the relation.
What is join dependency and inclusion dependency?

Join Dependency:
A Join dependency is generalization of Multivalued dependency.A JD {R1, R2, ..., Rn} is said
to hold over a relation R if R1, R2, R3, ..., Rn is a lossless-join decomposition of R . There is no set of sound
and complete inference rules for JD.
Inclusion Dependency:
An Inclusion Dependency is a statement of the form that some columns of a relation are
contained in other columns. A foreign key constraint is an example of inclusion dependency.
What are Armstrong rules? How do we say that they are complete and/or sound
_____________________________________________________________________________________
___________________________________________________________________________________________________
The well-known inference rules for FDs
Reflexive rule :
If Y is subset or equal to X then X Y.
Augmentation rule:
If X Y then XZ YZ.
Transitive rule:
If {X Y, Y Z} then X Z.
Decomposition rule :
If X YZ then X Y.
Union or Additive rule:
If {X Y, X Z} then X YZ.
Pseudo Transitive rule :
If {X Y, WY Z} then WX Z.
Of these the first three are known as Amstrong Rules. They are sound because it is enough if a set of FDs
satisfy these three. They are called complete because using these three rules we can generate the rest all
inference rules.
How can you find the minimal key of relational schema?
Minimal key is one which can identify each tuple of the given relation schema uniquely. For
finding the minimal key it is required to find the closure that is the set of all attributes that are dependent on
any given set of attributes under the given set of functional dependency.
Algo. I Determining X+, closure for X, given set of FDs F

1. Set X+ = X
2. Set Old X+ = X+
3. For each FD Y Z in F and if Y belongs to X + then add Z to X+
4. Repeat steps 2 and 3 until Old X+ = X+
Algo.II Determining minimal K for relation schema R, given set of FDs F

1. Set K to R that is make K a set of all attributes in R
2. For each attribute A in K
a. Compute (K A)+ with respect to F
b. If (K A)+ = R then set K = (K A)+
What do you understand by dependency preservation?

Given a relation R and a set of FDs F, dependency preservation states that the closure of the
union of the projection of F on each decomposed relation Ri is equal to the closure of F. i.e.,
((R1(F)) U U (Rn(F)))+ = F+
if decomposition is not dependency preserving, then some dependency is lost in the decomposition.
_____________________________________________________________________________________

Normalization

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Normalization

Uploaded by

Copyright:

Available Formats

CHANDAN MUKHERJEE (Asst Prof) 26630615 9831125100

Relational Database Design [9L]

Ensuring data dependencies make sense i.e. data is logically stored.

Permit efficient updates of the data in the database.

Avoid the danger of losing data unknowingly.

Different anamolies in designing a Database:

Emp_ID Emp_Name Emp_Address Emp_Dept

1st Normal Form

Each attribute (column) contains atomic (Single) value only

There are no repeating groups

Second normal form (2NF)

Table is in 1NF (First normal form)

No non-prime attribute is dependent on the proper subset of any

Teacher_ID SUBJECT Teacher_Age

Now the tables comply with Second normal form (2NF).

Third Normal form (3NF)

Consider relation R containing attributes A, B and C. R(A, B, C)

Y is a prime attribute of table

FD are : Book ID -> Price, Genere ID

Boyce -Codd Normal form (BCNF)

Table must be in 3NF

FD : Student_ID, Major -> Advisor

Advisor -> Major [Each Teacher(Advisor) Teaches only 1 Subject(Major) ]

Primary Key : [Student_ID, Major]

Above Table is in 3NF. NO TRANSITIVE DEPENDENCY.

Problems BCNF overcomes

After Divide in BCNF

SO BCNF IS NOT ALWAYS DEPENDENCY PRESERVING.

RELATION IS IN 3NF BUT NOT IN BCNF

The difference between 3NF and BCNF is that

Why BCNF is stronger than 3NF

BCNF is based on the concept of a determinant.

2 Supratim 60 Building Bangalore 21 Java 150 7

Here relation between Emp & skill is 1 : M

1 Chandan 50 EcoSpace Kolkata 22 .Net 104 7

1 Chandan 50 EcoSpace Kolkata 23 Oracle 306 9

2 Supratim 60 Building Bangalore 21 Java 150 7

2 Supratim 60 Building Bangalore 24 C 160 8

2 Supratim 60 Building Bangalore 23 Oracle 310 9

2 Supratim 60 Building Bangalore

Emp ID Skill ID Skill Name Skill Where Grades

2 Supratim 60 Building Bangalore

Emp ID -> Emp Name, Training Center Code

Now Table 4 & Table 5 is in 3NF. No Transitive Dependency Present.

Primary key is (S#, P#)

FD : S#,P# -> QTY

HERE TRANSITIVE DEPENDENCY PRESENT S# -> CITY, CITY -> STATUS

CANONICAL COVER OR MINIMAL COVER :-

F = { A -> B, AB -> C, D -> AC, D -> E } G = { A -> BC, D -> AB }

APPLY RULE 1 FOR F APPLY RULE 1 FOR G

FROM A CLOSURE WE ARE GETTING B.

A multivalued dependency (MVD) on R, X ->->Y, says that if two tuples of R agree on

M2 P3 D2 M2 have phones P3, and likes the dog D2.

Man(M) Phones(P) Dogs_Likes(D)

Some Points to note here about relation Person :

Man(M) Phones(P) Dogs_Likes(D) Address(A)

What does Denormalization mean?

1NF 2NF 3NF BCNF

0% if it doesnt contain MVD, Otherwise, it may contain

What is Lossless join property?

What is 1 NF (Normal Form)?

What is join dependency and inclusion dependency?

Algo. I Determining X+, closure for X, given set of FDs F