Database Normalization

1
 Normalization
Normalization is a method for designing a relational
database, which is generate a set of relation schemas that
allows us to store information without unnecessary
redundancy and allows us to retrieve information easily.

Normalization is a process that “improves” a database

design by generating relations that are of higher normal
forms.

2
 Normalization
Properties of Normalization

 It is the process of organizing the columns (attributes)

and tables(relations) of a relational database to reduce
data redundancy and improve the data integrity

 It ensures optimum structure

 It ensures atomic data

 It eliminates data inconsistencies and anomalies ( insert,

delete and update)

3
 Normalization
• This involves restructuring the tables to successively
meeting higher forms of Normalization.
• A properly normalized database should have the
following characteristics
– Scalar values in each fields
– Absence of redundancy.
– Minimal use of null values.
– Minimal loss of information.

4
 Normalization
Roll Name Age Book Subject Price
1 Karim 20 b1 Network 500
2 Rahim 21 b2 Algorithm 550
3 Jasim 20 b10 DBMS 600
4 Rayan 19 b4 Communication 703
5 Mahira 22 b15 Electronics 415
6 Mouri 19 b20 Management 425
7 Nihal 20 b11 Math 672
8 Shamim 22 b17 Graphics 737
9 Sohel 23 b19 Automation 532
1 Karim 20 b21 E-commerce 503

Primary Key is Roll and Book.

So they are prime attributes
A prime attribute cannot be insert null
A prime attribute can not be update 5
 Normalization
1NF a relation in BCNF, is
also in 3NF
2NF
a relation in 3NF is also
in 2NF
3NF
a relation in 2NF is also
BCNF in 1NF

6
 Levels of Normalization
• Levels of normalization based on the amount of
redundancy in the database.
• Various levels of normalization are:
– First Normal Form (1NF)
– Second Normal Form (2NF)

Redundancy

Number of Tables
– Third Normal Form (3NF)

Complexity
– Boyce-Codd Normal Form (BCNF)
– Fourth Normal Form (4NF)
– Fifth Normal Form (5NF)
– Domain Key Normal Form (DKNF)

Most databases should be 3NF or BCNF in order to

avoid the database anomalies. 7
 First Normal Form (1NF)
A table is considered to be in 1NF if all the fields contain
only scalar values (as opposed to list of values) that’s means all
fields must be atomic and single value.
Example (Not 1NF)
ISBN Title AuName AuPhone PubName PubPhone Price

0-321-32132-1 Balloon Sleepy, 321-321-1111, Small House 714-000-0000 $34.00

Snoopy, 232-234-1234,
Grumpy 665-235-6532

0-55-123456-9 Main Street Jones, 123-333-3333, Small House 714-000-0000 $22.95

Smith 654-223-3455
0-123-45678-0 Ulysses Joyce 666-666-6666 Alpha Press 999-999-9999 $34.00

1-22-233700-0 Visual Roman 444-444-4444 Big House 123-456-7890 $25.00

Basic

Author and AuPhone columns are not scalar

8
 1NF - Decomposition
1. Place all items that appear in the repeating group in a new table
2. Designate a primary key for each new table produced.
3. Duplicate in the new table the primary key of the table from
which the repeating group was extracted or vice versa.
Example (1NF)

ISBN AuName AuPhone

0-321-32132-1 Sleepy 321-321-1111

ISBN Title PubName PubPhone Price 0-321-32132-1 Snoopy 232-234-1234

0-321-32132-1 Balloon Small House 714-000-0000 $34.00 0-321-32132-1 Grumpy 665-235-6532

0-55-123456-9 Main Street Small House 714-000-0000 $22.95 0-55-123456-9 Jones 123-333-3333

0-123-45678-0 Ulysses Alpha Press 999-999-9999 $34.00 0-55-123456-9 Smith 654-223-3455

1-22-233700-0 Visual Big House 123-456-7890 $25.00 0-123-45678-0 Joyce 666-666-6666

Basic
1-22-233700-0 Roman 444-444-4444
9
 Normalization-1NF
SID Sname S Addr Major CID Ctitle Iname ILoc Grade

111 Rahim 204, MH IS11 IS11 DBMS MKN SAC 203 A

IS22 SAD MMH NAC 504 B
222 Karim 405, MV IT IS11 DBMS MKN SAC 203 C
IT22 COA RMZ NAC 307 B
IT33 C HK NAC 601 A

After Decomposition
SID Sname S Addr Major CID Ctitle Iname ILoc Grade

111 Rahim 204, MH IS11 IS11 DBMS MKN SAC 203 A

111 Rahim 204, MH IS11 IS22 SAD MMH NAC 504 B
222 Karim 405, MV IT IS11 DBMS MKN SAC 203 C
222 Karim 405, MV IT IT22 COA RMZ NAC307 B
222 Karim 405, MV IT IT33 C HK NAC 601 A
10
 Second Normal Form (2NF)
For a table to be in 2NF, there are two requirements
– The database is in first normal form
– All nonkey attributes in the table must be functionally dependent on the entire
primary key
– There is no partial dependency should exist
Note: Remember that we are dealing with non-key attributes

SID Sname S Addr Major CID Ctitle Iname ILoc Grade

111 Rahim 204, MH IS11 IS11 DBMS MKN SAC 203 A

111 Rahim 204, MH IS11 IS22 SAD MMH NAC 504 B
222 Karim 405, MV IT IS11 DBMS MKN SAC 203 C
222 Karim 405, MV IT IT22 COA RMZ NAC307 B
222 Karim 405, MV IT IT33 C HK NAC 601 A

11
 2NF - Decomposition
1. If a data item is fully functionally dependent on only a part of the
primary key, move that data item and that part of the primary key to
a new table.
2. If other data items are functionally dependent on the same part of the
key, place them in the new table also
3. Make the partial primary key copied from the original table the
primary key for the new table. Place all items that appear in the
repeating group in a new table
Example 1 (Convert to 2NF)
Old Scheme  {Title, PubId, AuId, Price, AuAddress}
New Scheme  {Title, PubId, AuId, Price}
New Scheme  {AuId, AuAddress}

12
 Second Normal Form (2NF)
Example 1 (Not 2NF)
Scheme  {Title, PubId, AuId, Price, AuAddress}
1. Key  {Title, PubId, AuId}
2. {Title, PubId, AuID}  {Price}
3. {AuID}  {AuAddress}
4. AuAddress does not belong to a key
5. AuAddress functionally depends on AuId which is a subset of a key

13
 Second Normal Form (2NF)
Example 2 (Not 2NF)
Scheme  {City, Street, HouseNumber, HouseColor, CityPopulation}
1. key  {City, Street, HouseNumber}
2. {City, Street, HouseNumber}  {HouseColor}
3. {City}  {CityPopulation}
4. CityPopulation does not belong to any key.
5. CityPopulation is functionally dependent on the City which is a
proper subset of the key

Old Scheme  {City, Street, HouseNumber, HouseColor, CityPopulation}

New Scheme  {City, Street, HouseNumber, HouseColor}
New Scheme  {City, CityPopulation}

14
 Second Normal Form (2NF)
Example 1 (Not 2NF)
Example 3 (Not 2NF)
Scheme  {studio, movie, budget, studio_city}
1. Key  {studio, movie}
2. {studio, movie}  {budget}
3. {studio}  {studio_city}
4. studio_city is not a part of a key
5. studio_city functionally depends on studio which is a proper subset of
the key

(Convert to 2NF)
Old Scheme  {Studio, Movie, Budget, StudioCity}
New Scheme  {Movie, Studio, Budget}
New Scheme  {Studio, City}

15
 Second Normal Form (2NF)
• In the Grade-Report Relation there are 4 FDs
• Primary Key: {SID, CID} is composite key
• SID→Sname Saddr Major
• CID →Ctitle Iname Iloc
• SID CID →Grade
• Iname →Iloc

• If primary key is a single attribute then the relation is always 2NF

SID Sname SAddr Major CID Ctitle Iname ILoc Grade

111 Rahim 204, MH IS11 IS11 DBMS MKN SAC 203 A

111 Rahim 204, MH IS11 IS22 SAD MMH NAC 504 B
222 Karim 405, MV IT IS11 DBMS MKN SAC 203 C
222 Karim 405, MV IT IT22 COA RMZ NAC307 B
222 Karim 405, MV IT IT33 C HK NAC 601 A
16
 SID Sname S Addr Major CID Ctitle Iname ILoc Grade

111
Second
Rahim
Normal
204, MH IS11
Form (2NF)
IS11 DBMS MKN SAC 203 A
111 Rahim 204, MH IS11 IS22 SAD MMH NAC 504 B
222 Karim 405, MV IT IS11 DBMS MKN SAC 203 C
222 Karim 405, MV IT IT22 COA RMZ NAC307 B
222 Karim 405, MV IT IT33 C HK NAC 601 A

SID Sname S Addr Major CID Ctitle Iname ILoc

111 Rahim 204, MH IS11 IS11 DBMS MKN SAC 203

222 Karim 405, MV IT IS22 SAD MMH NAC 504
IS11 DBMS MKN SAC 203
SID CID Grade
IT22 COA RMZ NAC307

111 IS11 A IT33 C HK NAC 601

111 IS22 B
222 IS11 C
222 IT22 B
17
222 IT33 A
 Third Normal Form (3NF)
This form dictates that all non-key attributes of a table must
be functionally dependent on a candidate key i.e. there can
be no interdependencies among non-key attributes.

For a table to be in 3NF, there are two requirements

– The table should be second normal form
– No attribute is transitively dependent on the primary key

18
 Third Normal Form (3NF)
Example (Not in 3NF)
Scheme  {Title, PubID, PageCount, Price }
1. Key  {Title, PubId}
2. {Title, PubId}  {PageCount}
3. {PageCount}  {Price}
4. Both Price and PageCount depend on a key hence 2NF
5. Transitively {Title, PubId}  {PageCount} and {PageCount}  {Price}
hence not in 3NF

19
 Third Normal Form (3NF)
SID Sname S Addr Major CID Ctitle Iname ILoc

111 Rahim 204, MH IS11 IS11 DBMS MKN SAC 203

222 Karim 405, MV IT IS22 SAD MMH NAC 504
IS11 DBMS MKN SAC 203
IT22 COA RMZ NAC307
SID CID Grade IT33 C HK NAC 601

111 IS11 A
111 IS22 B CID →Ctitle
222 IS11 C CID → Iname
CID →Iloc
222 IT22 B
Iname →Iloc
222 IT33 A

20
 Third Normal Form (3NF)
CID Ctitle Iname ILoc
SID Sname S Addr Major

IS11 DBMS MKN SAC 203

111 Rahim 204, MH IS11
IS22 SAD MMH NAC 504
222 Karim 405, MV IT
IS11 DBMS MKN SAC 203
SID CID Grade IT22 COA RMZ NAC307
IT33 C HK NAC 601
111 IS11 A
111 IS22 B
CID Ctitle Iname
222 IS11 C Iname ILoc
222 IT22 B
IS11 DBMS MKN
222 IT33 A MKN SAC 203
IS22 SAD MMH
MMH NAC 504
CID →Ctitle IS11 DBMS MKN
CID → Iname RMZ NAC307
IT22 COA RMZ
CID →Iloc HK NAC 601
Iname →Iloc IT33 C HK 21
 Third Normal Form (3NF)
Example (Not in 3NF)
Scheme  {Title, PubID, PageCount, Price }
1. Key  {Title, PubId}
2. {Title, PubId}  {PageCount}
3. {PageCount}  {Price}
4. Both Price and PageCount depend on a key hence 2NF
5. Transitively {Title, PubID}  {Price} hence not in 3NF

Old Scheme  {Title, PubID, PageCount, Price }

New Scheme  {PubID, PageCount, Price}
New Scheme  {Title, PubID, PageCount}

22
 Third Normal Form (3NF)
Example 2 (Not in 3NF)
Scheme  {Studio, StudioCity, CityTemp}
1. Primary Key  {Studio}
2. {Studio}  {StudioCity}
3. {StudioCity}  {CityTemp}
4. {Studio}  {CityTemp}
5. Both StudioCity and CityTemp depend on the entire key hence 2NF
6. CityTemp transitively depends on Studio hence violates 3NF

(Convert to 3NF)
Old Scheme  {Studio, StudioCity, CityTemp}
New Scheme  {Studio, StudioCity}
New Scheme  {StudioCity, CityTemp}

23
 Third Normal Form (3NF)
Example 3 (Not in 3NF)
Scheme  {BuildingID, Contractor, Fee}
1. Primary Key  {BuildingID}
2. {BuildingID}  {Contractor}
3. {Contractor}  {Fee}
4. {BuildingID}  {Fee}
5. Fee transitively depends on the BuildingID
6. Both Contractor and Fee depend on the entire key hence 2NF
BuildingI Contractor Fee
D
100 Randolph 1200
(Convert to 3NF) 150 Ingersoll 1100

Old Scheme  {BuildingID, Contractor, Fee} 200 Randolph 1200

250 Pitkin 1100

New Scheme  {BuildingID, Contractor}
300 Randolph 1200
New Scheme  {Contractor, Fee}

24
 Boyce-Codd Normal Form (BCNF)
• BCNF does not allow dependencies between attributes that belong to
candidate keys.
• BCNF is a refinement of the third normal form in which it drops the
restriction of a non-key attribute from the 3rd normal form.
• Third normal form and BCNF are not same if the following conditions are
true:
– The table has two or more candidate keys
– At least two of the candidate keys are composed of more than one
attribute
– The keys are not disjoint i.e. The composite candidate keys share some
attributes

25
 Boyce-Codd Normal Form (BCNF)
Example 1 - Address (Not in BCNF)
Scheme  {City, Street, ZipCode }
1. Key1  {City, Street }
2. Key2  {ZipCode, Street}
3. No non-key attribute hence 3NF
4. {City, Street}  {ZipCode}
5. {ZipCode}  {City}
6. Dependency between attributes belonging to a key
(Convert to BCNF)
Old Scheme  {City, Street, ZipCode }
New Scheme1  {ZipCode, Street}
New Scheme2  {City, Street}
• Loss of relation {ZipCode}  {City}
Alternate New Scheme1  {ZipCode, Street }
Alternate New Scheme2  {ZipCode, City}

26
 Boyce Codd Normal Form (BCNF)
Example 2 - Movie (Not in BCNF)
Scheme  {MovieTitle, MovieID, PersonName, Role, Payment }
1. Key1  {MovieTitle, PersonName}
2. Key2  {MovieID, PersonName}
3. Both role and payment functionally depend on both candidate keys thus 3NF
4. {MovieID}  {MovieTitle}
5. Dependency between MovieID & MovieTitle Violates BCNF

(Convert to BCNF)
Old Scheme  {MovieTitle, MovieID, PersonName, Role, Payment }
New Scheme  {MovieID, PersonName, Role, Payment}
New Scheme  {MovieTitle, PersonName}
• Loss of relation {MovieID}  {MovieTitle}
New Scheme  {MovieID, PersonName, Role, Payment}
New Scheme  {MovieID, MovieTitle}
• We got the {MovieID}  {MovieTitle} relationship back
27
 Boyce Codd Normal Form (BCNF)
Example 3 - Consulting (Not in BCNF)
Scheme  {Client, Problem, Consultant}
1. Key1  {Client, Problem}
2. Key2  {Client, Consultant}
3. No non-key attribute hence 3NF
4. {Client, Problem}  {Consultant}
5. {Client, Consultant}  {Problem}
6. Dependency between attributes belonging to keys violates BCNF

Example 3 (Convert to BCNF)

Old Scheme  {Client, Problem, Consultant}
New Scheme  {Client, Consultant}
New Scheme  {Client, Problem}

28
 BCNF - Decomposition
1. Place the two candidate primary keys in separate entities
2. Place each of the remaining data items in one of the resulting entities
according to its dependency on the primary key.
SID Major Advisor There are two FD
123 CSE Instructor-1 SID Major →Advisor
125 History Instructor-2 Advisor →Major
456 BMB Instructor-3
SID Advisor Advisor Major
789 EEE Instructor-4
123 Instructor-1 Instructor-1 CSE
999 CSE Instructor-1
125 Instructor-2 Instructor-2 History
456 Instructor-3 Instructor-3 BMB
789 Instructor-4 Instructor-4 EEE
999 Instructor-1

29
 Fourth Normal Form (4NF)
  • Fourth normal form eliminates independent many-to-one relationships
between columns.
• To be in Fourth Normal Form,
– a relation must first be in Boyce-Codd Normal Form. 
– a given relation may not contain more than one multi-valued attribute.
– Non trivial multivalued dependencies other than a candidate key

Example (Not in 4NF)

Scheme  {MovieName, ScreeningCity, Genre)
Primary Key: {MovieName, ScreeningCity, Genre)
1. All columns are a part of the only candidate key, hence BCNF
2. Many Movies can have the same Genre Movie ScreeningCity Genre
3. Many Cities can have the same movie Hard Code Los Angles Comedy
4. Violates 4NF Hard Code New York Comedy

Bill Durham Santa Cruz Drama

 
Bill Durham Durham Drama
30
The Code Warrier New York Horror
 Fourth Normal Form (4NF)
  • Fourth normal form eliminates independent many-to-one relationships
between columns.
• To be in Fourth Normal Form,
– a relation must first be in Boyce-Codd Normal Form. 
– a given relation may not contain more than one multi-valued attribute.
– Non trivial multivalued dependencies other than a candidate key
Course Instructor Textbook Course Instructor Course Textbook
Database MKN1 Silberschatz Database MKN1 Database Silberschatz
  MMH Hector
Database MMH
MSA Database Hector
Database MSA Finance Weston
Finance MSK Weston
Gilford Finance MSK Finance Gilford

31
 Fourth Normal Form (4NF)
Example 2 (Not in 4NF) Manager Child  Employee
   
Scheme  {Manager, Child, Employee} Jim Beth Alice

1. Primary Key  {Manager, Child, Employee} Mary Bob Jane

2. Each manager can have more than one child Mary NULL Adam
3. Each manager can supervise more than one employee
4. 4NF Violated

Example 3 (Not in 4NF)

Scheme  {Employee, Skill, ForeignLanguage}
5. Primary Key  {Employee, Skill, Language }
6. Each employee can speak multiple languages
7. Each employee can have multiple skills
Employee Skill Language
8. Thus violates 4NF
1234 Cooking French

1234 Cooking German

1453 Carpentry Spanish

1453 Cooking Spanish

2345 Cooking Spanish
32
 4NF - Decomposition
1. Move the two multi-valued relations to separate tables
2. Identify a primary key for each of the new entity.

Example 1 (Convert to 4NF)

Old Scheme  {MovieName, ScreeningCity, Genre}
New Scheme  {MovieName, ScreeningCity}
New Scheme  {MovieName, Genre}

Movie Genre Movie ScreeningCity

Hard Code Comedy Hard Code Los Angles

Bill Durham Drama Hard Code New York

The Code Warrier Horror Bill Durham Santa Cruz

Bill Durham Durham

The Code Warrier New York

33
 4NF - Decomposition
Example 2 (Convert to 4NF) Manager Child  Manager Employee
Old Scheme  {Manager, Child, Employee}    
Jim Beth Jim Alice

New Scheme  {Manager, Child} Mary Bob Mary Jane

New Scheme  {Manager, Employee} Mary Adam

Example 3 (Convert to 4NF)

Old Scheme  {Employee, Skill, ForeignLanguage}
New Scheme  {Employee, Skill}
New Scheme  {Employee, ForeignLanguage}

Employee Skill Employee Language

1234 Cooking 1234 French

1453 Carpentry 1234 German

1453 Cooking 1453 Spanish

2345 Cooking 2345 Spanish
34
 Normalization
1. 1NF----- Atomic and Single Value
2. 2NF----- 1NF and No Partial Dependency
3. 3NF----- 2NF and No Transitive Dependency
4. BCNF---3 NF and Non-Key attributes Determine Partial Key
5. 4 NF-----BCNF and No non-trivial multi valued dependency

35
 Exercise
Given a relation R( A, B, C, D) and Functional Dependency set
FD = { AB → CD, B → C }, determine whether the given R is in
2NF? If not convert it into 2 NF.

Solution: Let us construct an arrow diagram on R using FD to

calculate the candidate key.

AB+ = AB CD (from the method we studied earlier)

Since the closure of AB contains all the attributes of R, hence
AB is Candidate Key

36
 Exercise
Solution:

Definition of 2NF: No non-prime attribute should be partially

dependent on Candidate Key

As FD B → C, the above table R( A, B, C,

D) is not in 2NF

a) R1( B, C)
b) R2(A, B, D)
37
 Exercise
Given a relation R( X, Y, Z, W, P) and Functional Dependency
set FD = { X → Y, Y → P, and Z → W}, determine whether the
given R is in 3NF? If not convert it into 3 NF.

Solution: Let us construct an arrow diagram on R using FD to

calculate the candidate key.

XZ + = XZYPW
Since the closure of XZ contains all the attributes of R, hence
XZ is Candidate Key

38
Solution:
Exercise

XZ + = XZYPW
Since the closure of XZ contains all the attributes of R, hence
XZ is Candidate Key
Definition of 3NF: First it should be in 2NF and if there exists a
non-trivial dependency between two sets of attributes
• R1(X, Y) {Using FD X → Y}
• R2(Y, P) {Using FD Y → P}
• R3(Z, W) {Using FD Z → W}
And create one table for Candidate Key XZ
• R4( X, Z) { Using Candidate Key XZ }
39
 Exercise
Given a relation R( X, Y, Z) and Functional Dependency set
FD = { XY → Z and Z → Y }, determine whether the given R
is in BCNF? If not convert it into BCNF.
Solution: Let us construct an arrow diagram on R using FD to
calculate the candidate key.

Let us calculate the closure of X

X + = X; Since X+ contains only X, so it is not a candidate key.
Let us check the combination of Y, i.e. XY, XZ.
XY + = XYZ; Since XY+ contains XYZ, so it is a candidate key.
XZ + = XYZ; Since XZ+ contains XYZ, so it is a candidate key.

40
 Exercise
Solution:

BCNF: 3 NF and Non-Key attributes Determine Partial Key

Convert the table R( X, Y, Z) into BCNF:
Since due to FD: Z → Y, our table was not in BCNF, let's
decompose the table
FD: Z→ Y was creating an issue, hence one table R1( Z, Y )
Create Table for key XY R2(X, Y) as XY was candidate key
OR
Create Table for key XZ R2(X, Z) as XZ was candidate key

41
First normal form (1NF)
A relation is in first normal form if every attribute in every row can contain
only one single (atomic) value.
A university uses the following relation:
Student(Surname, Name, Skills)
The attribute Skills can contain multiple values and therefore the relation
is not in the first normal form.
But the attributes Name and Surname are atomic attributes
that can contain only one value.

42
Second normal form (2NF)
A relation is in second normal form if it is in 1NF and every non key
attribute is fully functionally dependent on the primary key.
A university uses the following relation:

Student(IDSt, StudentName, IDProf, ProfessorName, Grade)

The attributes IDSt and IDProf are the identification keys.

All attributes a single valued (1NF).

The following functional dependencies exist:

1. The attribute ProfessorName is functionally dependent on attribute
IDProf (IDProf --> ProfessorName)

2. The attribute StudentName is functionally dependent on

IDSt (IDSt --> StudentName)

3. The attribute Grade is fully functional dependent on

IDSt and IDProf (IDSt, IDProf --> Grade)

43
The following functional dependencies
exist:

1. The attribute ProfessorName is

functionally dependent on attribute
IDProf (IDProf --> ProfessorName)

2. The attribute StudentName is

functionally dependent on
IDSt (IDSt --> StudentName)

3. The attribute Grade is fully

functional dependent on
IDSt and IDProf (IDSt, IDProf -->
Grade)

44
Third normal form (3NF)
A relation is in third normal form if it is in 2NF and no non key attribute is transitively
dependent on the primary key. A bank uses the following relation:
Vendor(ID, Name, Account_No, Bank_Code_No, Bank)

The attribute ID is the identification key. All attributes are single valued (1NF).
The table is also in 2NF.
The following dependencies exist:
1. Name, Account_No, Bank_Code_No are functionally dependent on ID
(ID --> Name, Account_No, Bank_Code_No)
2. Bank is functionally dependent on Bank_Code_No
(Bank_Code_No --> Bank)

45
• Student_IDStudent_Name, Campus_Address, Major
• Course_ID Course_Title, Instructor_Name, Instructor_Location
• {Student_ID, Course_ID} Grade
• Instructor_Name Instructor_Location

i. Which normalization form of the relation belongs to?

ii. Normalize the following tables of data to 3 NF and draw the relation schema
diagram.

46
• Student_IDStudent_Name, Campus_Address, Major
• Course_ID Course_Title, Instructor_Name, Instructor_Location
• {Student_ID, Course_ID} Grade
• Instructor_Name Instructor_Location

i. Which normalization form of the relation belongs to?

ii. Normalize the following tables of data to 3 NF and draw the relation schema diagram.

It is 1NF because there are two keys to determine other attributes.

47
Normalization 3 NF and the relation schema diagram are bellow

48
 • Consider the following relation for published books:
• BOOK (book title, author, type_of_book, price, author_affiliation,
publisher).
• Suppose the following dependencies exist:
{ (book_title)(publisher, type_of_book);
(type_of_book)(price);
(author)  (author_affiliation) }.
• What is the highest normal form that the above relation satisfies?

There exist partial functional dependencies

((book_title)(publisher, type_of_book);
(author)  (author_affiliation))
which violates it from being in 2NF, hence it is in 1NF (atomicity of attributes is
always assumed until specifically mentioned).

49
• You are given the below functional dependencies for relation R(A,B,C,D,E),
• F ={AB → C, AB → D, D → A, BC → D, BC → E}.
a. Is this relation is in BCNF? If not, show all dependencies that violate it.
b. Is this relation in 3NF? If not, show all dependencies that violate it.

• Keys for the relation: {A, B}, {B, C}.

• a. Not in BCNF since D → A , Non-Key attributes Determine Partial Key
• b. In 3NF since in D → A,

1NF and No Partial Dependency that’s why 2NF

A is part of a key. as 2NF and No Transitive Dependency

50