Relational Database Design

(Normalization)
According to E.F.Codd, who is the inventor of the Relational Database, the goals of
Normalization include:
•It helps in vacating all the repeated data from the database.

•It helps in removing undesirable deletion, insertion, and update anomalies.

•It helps in making a proper and useful relationship between tables.

 Relational Database Design

● Features of Good Relational Design

● Atomic Domains and First Normal Form
● Decomposition Using Functional Dependencies
● Functional Dependency Theory
● Algorithms for Functional Dependencies
● Decomposition Using Multivalued Dependencies
● More Normal Form
● Database-Design Process
● Modeling Temporal Data
Normalization helps a database designer optimally distribute attributes into
Why is Database Normalization Important?
tables. The technique eliminates the following:
•Attributes with multiple values.
•Doubled or repeated attributes.
•Non-descriptive attributes.
•Attributes with redundant information.
•Attributes created from other features.
Although total database normalization is not necessary, it provides a well-
functioning information environment.

The method systematically ensures:

•A database structure suitable for generalized queries.
•Minimized data redundancy, increasing memory efficiency on a database
server.
•Maximized data integrity through the reduced insert, update, and delete
anomalies.

Database normalization transforms overall database consistency, providing

an efficient environment.
 The Banking Schema
● branch = (branch_name, branch_city, assets)
● customer = (customer_id, customer_name, customer_street, customer_city)
● loan = (loan_number, amount)
● account = (account_number, balance)
● employee = (employee_id. employee_name, telephone_number, start_date)
● dependent_name = (employee_id, dname)
● account_branch = (account_number, branch_name)
● loan_branch = (loan_number, branch_name)
● borrower = (customer_id, loan_number)
● depositor = (customer_id, account_number)
● cust_banker = (customer_id, employee_id, type)
● works_for = (worker_employee_id, manager_employee_id)
● payment = (loan_number, payment_number, payment_date, pay_amount)
● savings_account = (account_number, interest_rate)
● checking_account = (account_number, overdraft_amount)
 Combine Schemas?
● Suppose we combine borrower and loan to get
● bor_loan = (customer_id, loan_number, amount )
● Result is possible repetition of information (L-100 in
example below)
A Combined Schema Without Repetition
Consider combining loan_branch and loan
loan_amt_br = (loan_number, amount, branch_name)
No repetition (as suggested by example below)
●
What About Smaller Schemas?
Suppose we had started with bor_loan. How would we know to split up
(decompose) it into borrower and loan?
● Write a rule “if there were a schema (loan_number, amount), then loan_number
would be a candidate key”
● Denote as a functional dependency:
● loan_number → amount
● In bor_loan, because loan_number is not a candidate key, the amount of a loan
may have to be repeated. This indicates the need to decompose bor_loan.
● Not all decompositions are good. Suppose we decompose employee into
● employee1 = (employee_id, employee_name)
● employee2 = (employee_name, telephone_number, start_date)
● If we cannot reconstruct the original employee relation -- a lossy decomposition.
A Lossy Decomposition
 Definition Normalization
• Database Normalization is the process of splitting the tables into
smaller ones so as to remove anomalies in the database.
• It helps in reducing redundancy in the database.
• 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.
– It helps in removing undesirable deletion, insertion, and
update anomalies.
 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)
– Third Normal Form (3NF)
Number
– Boyce-Codd Normal Form (BCNF) of Complexity
Redundancy
Tables
– 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.
 Levels of Normalization

Each higher level is a subset of the lower level

 First Normal Form: Example to Think
Consider Relation Student which is not in 1NF

R_No Name Course

R_No Name Course
1 Nita C
1 Nita C, C++
1 Nita C++
2 Aarati DBMS
2 Aarati DBMS
3 Neha Java, DBMS
3 Neha Java
R1 PK (R_No), But Multivalued Attribute
3 Neha DBMS

R2 PK (R_No, Course) Compposite

PK
R_No Name Course1 Course2 R_No Name R_No Course
1 Nita 1 C
1 Nita C C++ 2 Aarati 1 C++
2 Aarati DBMS NULL 3 Neha 2 DBMS
3 Neha Java DBMS
3 Java
3 DBMS
R3 PK (R_No), But Many Null Values
R41 and R42 PK (R_No),and (R_No, Course)
First NF
 First Normal Form
● Domain is atomic if its elements are considered to be indivisible
units
● Examples of non-atomic domains:
● Set of names, composite attributes
● Identification numbers like CS101 that can be broken up
into parts
● A relational schema R is in first normal form if the domains of
all attributes of R are atomic
● Non-atomic values complicate storage and encourage redundant
(repeated) storage of data
● Example: Set of accounts stored with each customer, and set
of owners stored with each account.
 First Normal Form (Cont’d)
● Atomicity is actually a property of how the elements of the
domain are used.
● Example: Strings would normally be considered
indivisible
● Suppose that students are given roll numbers which are
strings of the form CS0012 or EE1127
● If the first two characters are extracted to find the
department, the domain of roll numbers is not atomic.
● Doing so is a bad idea: leads to encoding of information in
application program rather than in the database.
 First Normal Form (1NF) Example
A table is considered to be in 1NF if all the fields contain
only scalar values (as opposed to list of values).
Example (Not 1NF)

Author and AuPhone columns are not scalar

 1NF - Decomposition-Example
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
 Goal — Devise a Theory for the Following
● Decide whether a particular relation R is in “good” form.
● Ifa relation R is not in “good” form, decompose it into a set
of relations {R1, R2, ..., Rn} such that
● each relation is in good form
● the decomposition is a lossless-join decomposition
● Normalization theory is based on:
● Informal Design Guidelines for Relational Databases
➢ Semantics of the Relation Attributes
➢ Redundant Information in Tuples and Update
Anomalies
➢ Null Values in Tuples
➢ Spurious Tuples
➢ functional dependencies
➢ multivalued dependencies
 1.1 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.
Bottom Line: Design a schema that can be explained easily relation
by relation. The semantics of attributes should be easy to interpret.
 1.2 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 AN UPDATE ANOMALY (1)
Consider the relation:
EMP_PROJ ( Emp#, Proj#, Ename, Pname, No_hours)

• Update Anomaly: Changing the name of project

number P1 from “Billing” to “Customer-Accounting”
may cause this update to be made for all 100
employees working on project P1.
Figure: Two relation schemas suffering
from update anomalies
Figure: Example States for EMP_DEPT and
EMP_PROJ
 Guideline to Redundant Information
in Tuples and Update Anomalies
• 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
 1.3 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
 1.4 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.

There are two important properties of decompositions:

(a) non-additive or lossless 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
● Constraints that describes relationships between attributes on the
set of legal relations.
● Require that the value for a certain set of attributes determines
uniquely the value for another set of attributes.
● A functional dependency is a generalization of the notion of a key.
Let R be a relation schema R and R
The functional dependency
holds on R if and only if for any legal relations r(R), whenever any two
tuples t1 and t2 of r agree on the attributes , they also agree on the
attributes . That is,
t1[ ] = t2 [ ] t1[ ] = t2 [ ]
Example: Consider r(A,B ) with the following instance of r.
(1) 4
1 5
3 7
On this instance, A B does NOT hold, but B A does hold.
 Functional Dependencies

1. If one set of attributes in a table determines another set of

attributes in the table, then the second set of attributes is said
to be functionally dependent on the first set of attributes.

Example 1

ISBN Title Price Table Scheme: {ISBN, Title, Price}

0-321-32132-1 Balloon $34.00 Functional Dependencies: {ISBN} {Title}
{ISBN} {Price}
0-55-123456-9 Main Street $22.95

0-123-45678-0 Ulysses $34.00

1-22-233700-0 Visual $25.00

Basic
 Functional Dependencies
Table Scheme:{PubID,PubName,PubPhone}
Example 2
Functional Dependencies:
PubID PubName PubPhone
{PubId} {PubPhone}
1 Big House 999-999-9999

2 Small House 123-456-7890

{PubId} {PubName}
3 Alpha Press 111-111-1111 {PubName, PubPhone} {PubID}

Example 3
Table Scheme:
AuID AuName AuPhone
1 Sleepy 321-321-1111 {AuID, AuName, AuPhone}
2 Snoopy 232-234-1234 Functional Dependencies:
3 Grumpy 665-235-6532
{AuId} {AuPhone}
4 Jones 123-333-3333
{AuId} {AuName}
5 Smith 654-223-3455

6 Joyce 666-666-6666
{AuName, AuPhone} {AuID}
7 Roman 444-444-4444
 FD – Example
Database to track reviews of papers submitted to an academic conference.
Prospective authors submit papers for review and possible acceptance
in the published conference proceedings. Details of the entities
– Author information includes a unique author number, a name, a mailing
address, and a unique (optional) email address.
– Paper information includes the primary author, the paper number, the
title, the abstract, and review status (pending, accepted,rejected)
– Reviewer information includes the reviewer number, the name, the
mailing address, and a unique (optional) email address
– A completed review includes the reviewer number, the date, the paper
number, comments to the authors, comments to the program chairperson,
and ratings (overall, originality, correctness, style, clarity)
 FD – Example
Functional Dependencies
– AuthNo AuthName, AuthEmail, AuthAddress
– AuthEmail AuthNo
– PaperNo Primary-AuthNo, Title, Abstract, Status
– RevNo RevName, RevEmail, RevAddress
– RevEmail RevNo
– RevNo, PaperNo AuthComm, Prog-Comm, Date,
Rating1, Rating2, Rating3, Rating4, Rating5
 Inference Rules For FDs
Inference Rules There are 6 inference rules,
•Reflexive Rule: If B is a subset of A, then A logically determines B.

•Formally, B ⊆
⊆ A then A → B.

• Example: Address (A) of a house, then parameters House no, Street no, City etc.
• These all are the subsets of A. Thus, address (A) → House no. (B).
•Augmentation Rule: It is also known as Partial dependency. If A logically determines B,
then adding any extra attribute doesn't change the basic functional dependency.

• Example: A → B, then AC → BC is true

•Transitive rule: If A determines B and B determines C, then it can be said that A indirectly
determines B.

• Example: If A → B and B → C then A → C.

 Inference Rules For FDs
•Union Rule: Union rule states that If A determines B and C, then A determines BC.

• Example: If A → B and A → C then A → BC.

•Decomposition Rule: It is perfectly reverse of the above Union rule. According to this
rule, If A determined BC then it can be decomposed as A → B and A → C.

• Example: If A → BC then A → B and A → C.

•Pseudo Transitive Rule: According to this rule, If A determined B and BC determines D
then AC determines D.

• Example: If A → B and BC → D then AC → D.

Inference Rules For FDs
 Find all Candidate Keys from FDs: Closure Method
• R= ABCD and FDs={A → B, B → C, C → D )
• Closure of A is A+ ={ BCDA }
• Closure of B is B+ ={ BCD } so B is not CK
• Closure of C is C+ ={ CD }
• Closure of D is D+ ={ D }
• Set of CK ={A} and PK is A
• A is a Prime Attribute and C,D,B are non Prime Attribute
• AB+ is Super Key

• Example2:R= ABCD and FDs={A → B, B → C, C → D, D → A )

• Closure of A is A+ ={ BCDA }
• Closure of B is B+ ={ BCDA } so B is also CK
• Closure of C is C+ ={ CDBA }
• Closure of D is D+ ={ ABCD }
• Set of CK ={A, B, C, D}
• A, C, D, B is a Prime Attribute
 Find all Candidate Keys from FDs: Closure Method
• Example3:R= ABCDE and
• FDs={A → B, BC → D, E → C, D → A )
• Note: right side of FDs we have A, B, C, D so
• E can be determined only if E is also at left side.
• Closure of E is E+ ={ EC } So only E is not CK
• Closure of AB is AE+ ={ BCDAE } so AE is a CK

• Set of CK ={AE, BE, DE}

• A, D, B are Prime Attributes and C is non prime attribute

• Reference: https://youtu.be/bSdvM_0hzgc?si=dK5mfnXa0LBl-ULe

• Trivial And Nontrivial FDs

Ex: Ro_No → Name is non Trivial FD
Ro_No, Name → Name is trivial FD as
In X → Y , Y X
 Second Normal Form (2NF)
For a table to be in 2NF,
– The database is in first normal form
– All nonkey attributes in the table must be functionally dependent on the entire
primary key
(No non prime attribute is dependent on the proper subset of any candidate key
of the table)
Note: Remember that we are dealing with non-key attributes

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
 2NF - Decomposition
Example 1 (Converted to 2NF)
Old Scheme {Title, PubId, AuId, Price, AuAddress}
New Scheme {Title, PubId, AuId, Price}
New Scheme {AuId, AuAddress}
Algorithm:
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
 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

Example 2 (Converted to 2NF)

Old Scheme {City, Street, HouseNumber, HouseColor, CityPopulation}
New Scheme {City, Street, HouseNumber, HouseColor}
New Scheme {City, CityPopulation}
Note: Let us consider the problems with the movie studio database:
1. Redundancy – City Population is repeated many times
2. Insertion anomaly – Whenever we add a new record we have to add unnecessary information. We can not add
record until we know information about the city population
3. Deletion anomaly – Whenever we delete a record, useful information is deleted.
Update anomaly – The City Population needs to be updated in more than one location if it changes.
 2NF - Decomposition
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

Example 3 (Converted to 2NF)

Old Scheme {Studio, Movie, Budget, Studio_City}
New Scheme {Movie, Studio, Budget}
New Scheme {Studio, Studio_City}
 2NF - Decomposition
• Example: R= ABCDEF and
• FDs={C → F, E → A, EC → D, A → B )
• Note: right side of FDs we have A, B, F, D so
• EC can be determined only if EC is also at left side.
• Closure of EC is EC+ ={ ECABDF }

• Set of CK ={CE}
• C,E are Prime Attributes and A, B, D,F are non prime attribute
• Since F is determined from proper subset of CK which means partial
dependency exist.
• So this relation is not in 2NF
 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
A relation R having functional dependency A–>B is in 3NF if either of the
conditions given below are true .
• A is a superkey.
• B is prime attribute, that is B is the part of candidate key.
Example (Not in 3NF)
Scheme {Title, PubID, PageCount, Price }
1. Key {Title, PubId}
2. {Title, PubId} {PageCount}
3. {Title, PubID} {Price}
4. Both Price and PageCount depend on a key hence 2NF
5. Transitively {PageCount} {Price}hence not in 3NF
 3NF - Decomposition
1. Move all items involved in transitive dependencies to a new entity.
2. Identify a primary key for the new entity.
3. Place the primary key for the new entity as a foreign key on the
original entity.

Example 1
Old Scheme {Title, PubID, PageCount, Price }
New Scheme {PubID, PageCount, Price}
New Scheme {Title, PubID, PageCount}
New Scheme is in 3NF
 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

Example 2 (Converted to 3NF)

Old Scheme {Studio, StudioCity, CityTemp}
New Scheme {Studio, StudioCity}
New Scheme {StudioCity, CityTemp}
 3NF - Decomposition
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
– Both Contractor and Fee depend on the entire key hence 2NF

BuildingID Contractor Contractor Fee

Example 3 (Converted to 3NF) 100 Randolph Randolph 1200

Old Scheme {BuildingID, Contractor, Fee} 150 Ingersoll Ingersoll 1100

200 Randolph Pitkin 1100
New Scheme {BuildingID, Contractor}
250 Pitkin
New Scheme {Contractor, Fee} 300 Randolph
 2NF(Second Normal Form) 3NF(Third Normal Form)

It is already in 1NF. It is already in 1NF as well as in 2NF.

In 2NF non-prime attributes are allowed to be In 3NF non-prime attributes are only allowed to be
functionally dependent on non-prime attributes. functionally dependent on Super key of relation.

No partial functional dependency of non-prime

No transitive functional dependency of non-
attributes are on any proper subset of candidate key
prime attributes on any super key is allowed. .
is allowed.

Stronger normal form than 1NF but lesser than 3NF Stronger normal form than 1NF and 2NF.

It eliminates repeating groups in relation. It virtually eliminates all the redundancies.

The goal of the second normal form is to eliminate The goal of the third normal form is to ensure
redundant data. referential integrity.
 Third Normal Form Definition
A relation schema R is in third normal form (3NF) if for all:
in F+
at least one of the following holds:
is trivial (i.e., )
is a superkey for R
Each attribute A in – is contained in a candidate key for R.
(NOTE: each attribute may be in a different candidate key)
If a relation is in BCNF it is in 3NF (since in BCNF one of the first two
conditions above must hold).
Third condition is a minimal relaxation of BCNF to ensure dependency
preservation.
 Third Normal Form Example
• Example: R= ABCD and
• FDs={AB → CD, D → A)
• Note: right side of FDs we have A, C, D so
• B can be determined only if B is also at left side.
• Closure of EC is AB+ ={ ABCD } and DB+ ={ ABCD }

• Set of CK ={AB, DB}

• A,B,D are Prime Attributes and C is non prime attribute
• For each FD, L.H.S must be CK or FK OR
• R.H.S is a prime attribute.
• So this relation is in 3NF
 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
 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
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.
Example 1 (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}
 Decomposition – Loss of
Information
1. If decomposition does not cause any loss of information it is called a
lossless decomposition.
2. If a decomposition does not cause any dependencies to be lost it is
called a dependency-preserving decomposition.
3. Any table scheme can be decomposed in a lossless way into a
collection of smaller schemas that are in BCNF form. However the
dependency preservation is not guaranteed.
4. Any table can be decomposed in a lossless way into 3rd normal form
that also preserves the dependencies.
• 3NF may be better than BCNF in some cases

Use your own judgment when decomposing schemas

 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

Example 2 (Converted 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}

1. We got the {MovieID} {MovieTitle} relationship back

 BCNF - Decomposition
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 attributess belonging to keys violates BCNF

Example 3 (Converted to BCNF)

Old Scheme {Client, Problem, Consultant}
New Scheme {Client, Consultant}
New Scheme {Client, Problem}
 Comparison of BCNF and 3NF
It is always possible to decompose a relation into a set of
relations that are in 3NF such that:
the decomposition is lossless
the dependencies are preserved
It is always possible to decompose a relation into a set of
relations that are in BCNF such that:
the decomposition is lossless
it may not be possible to preserve dependencies.
 Example of BCNF Decomposition
R = (A, B, C )
F = {A B
B C}
Key = {A}
R is not in BCNF (B C but B is not superkey)
Decomposition
R1 = (B, C)
R2 = (A,B)
 Example of BCNF Decomposition
Original relation R and functional dependency F
R = (branch_name, branch_city, assets,
customer_name, loan_number, amount )
F = {branch_name assets branch_city
loan_number amount branch_name }
Key = {loan_number, customer_name}
Decomposition
R1 = (branch_name, branch_city, assets )
R2 = (branch_name, customer_name, loan_number, amount )
R3 = (branch_name, loan_number, amount )
R4 = (customer_name, loan_number )
Final decomposition
R1, R3, R4
 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.

Definition:
A relation schema R is in 4NF with respect to a set D of functional and
multivalued dependencies if for all multivalued dependencies in D+ of the
form , where R and R, at least one of the following hold:
is trivial (i.e., or = R)
is a superkey for schema R
 MVD (Cont.)
Tabular representation of

Let R be a relation schema and let R and R. The multivalued dependency

holds on R if in any legal relation r(R), for all pairs for 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 – ]
 Fourth Normal Form (4NF)
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
3. Many Cities can have the same movie
4. Violates 4NF

Movie ScreeningCity Genre

Hard Code Los Angles Comedy

Hard Code New York Comedy

Bill Durham Santa Cruz Drama

Bill Durham Durham Drama

The Code Warrier New York Horror

 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 (Converted 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

 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 2 (Converted to 4NF)

Old Scheme R = {Manager, Child, Employee}
New Scheme R1= {Manager, Child}
New Scheme R2={Manager, Employee}
 4NF - Decomposition
Example 3 (Not in 4NF)
Scheme {Employee, Skill, ForeignLanguage}
1. Primary Key {Employee, Skill, Language }
2. Each employee can speak multiple languages
3. Each employee can have multiple skills
4. It violates 4NF

Example 3 (Converted to 4NF)

Old Scheme R= {Employee, Skill, ForeignLanguage}
New Scheme R1= {Employee, Skill}
New Scheme R2= {Employee, ForeignLanguage}
 Fifth Normal Form (5NF)
• Fifth normal form is satisfied when all tables are broken into as
many tables as possible in order to avoid redundancy.
• Once it is in fifth normal form it cannot be broken into smaller
relations without changing the facts or the meaning.
Fifth normal form is also called as project-join normal form
(PJNF)
 Domain Key Normal Form (DKNF)
• The relation is in DKNF when there can be no insertion or
deletion anomalies in the database.
Case Study: Conversion to First Normal
Form
Conversion to Second Normal Form
(continued)
Conversion to Third Normal Form
(continued)
The Boyce-Codd Normal Form (BCNF)
(continued)
 Example Multivalued FD and
Normalization to 4Th Normal Form
R =(A, B, C, G, H, I)
F ={ A B
B HI
CG H}
R is not in 4NF since A B and A is not a superkey for R
Decomposition
a) R1 = (A, B) (R1 is in 4NF)
b) R2 = (A, C, G, H, I) (R2 is not in 4NF)
c) R3 = (C, G, H) (R3 is in 4NF)
d) R4 = (A, C, G, I) (R4 is not in 4NF)
Since A B and B HI, A HI, A I
e) R5 = (A, I) (R5 is in 4NF)
f)R6 = (A, C, G) (R6 is in 4NF)
• https://phoenixnap.com/kb/database-normalization
• https://www.geeksforgeeks.org/difference-between-lossless-and-
lossy-join-decomposition/