Third Normal Form (3NF) – Detailed Explanation

Third Normal Form builds on Second Normal Form by eliminating transitive dependencies.

Even though 2NF removes partial dependencies, data anomalies can still exist if non-key attributes depend on other non-key attributes.

Formal Definition of 3NF

A relation R is in Third Normal Form (3NF) if and only if:

R is already in Second Normal Form (2NF)

For every functional dependency X → A, at least one of the following holds:

1.X is a superkey, OR

2.A is a prime attribute (part of some candidate key)

This definition ensures that non-key attributes depend only on the primary key and nothing else.

Why 3NF Is Necessary in Wedding Planner

In the Wedding Planner system, many entities are logically independent, but still connected:

1.Weddings are created by users

2.Venues have descriptive properties

3.Bookings connect weddings and venues

If descriptive attributes are stored indirectly via other non-key attributes, transitive dependencies arise, which violate 3NF.

Relations After 2NF (Starting Point for 3NF)

Table	Primary Key	Attributes
user	user_id	user_first_name, user_last_name, user_email
wedding	wedding_id	wedding_date, wedding_budget, user_id
venue	venue_id	venue_name, venue_type, venue_capacity
venue_booking	booking_id	venue_id, wedding_id, booking_date, start_time, end_time

All relations are in 2NF, but this does not guarantee 3NF.

Identification of Transitive Dependencies

A transitive dependency exists when:

Primary Key → Non-Key Attribute → Another Non-Key Attribute

Transitive Dependency Analysis

Dependency Chain	Explanation
wedding_id → user_id → user_email	wedding_id indirectly determines user data
booking_id → venue_id → venue_name	booking_id indirectly determines venue attributes

In both cases:

1.The middle attribute (user_id, venue_id) is not a key

2.The final attribute is non-key

3This violates 3NF

Why This Violates 3NF (Formal Proof)

Consider:

wedding_id → user_id user_id → user_email

By transitivity:

wedding_id → user_email

Since:

wedding_id is not a superkey of the user relation

user_email is not a prime attribute

➡ 3NF is violated

Decomposition Strategy for 3NF

To eliminate transitive dependencies:

*Each non-key attribute must depend directly on the primary key

*Intermediate determining attributes must be separated into their own relations

*This process does not lose data and does not break dependencies.

3NF Decomposition (Final Relations)

USER

user_id	user_first_name	user_last_name	user_email
1	Ana	Trajkovska	ana.trajkovska@…

FD: user_id → user_first_name, user_last_name, user_email

WEDDING

wedding_id	wedding_date	wedding_budget	user_id
W01	2026-06-20	8500	1

FD: wedding_id → wedding_date, wedding_budget, user_id

VENUE

venue_id	venue_name	venue_type	venue_capacity
W011	Lakeside Garden Venue	Outdoor Garden	200

FD: venue_id → venue_name, venue_type, venue_capacity

VENUE_BOOKING

booking_id	venue_id	wedding_id	booking_date	start_time	end_time
B01	V01	W01	2026-06-20	12:00	13:00

FD: booking_id → venue_id, wedding_id, booking_date, start_time, end_time

Proof That 3NF Conditions Are Satisfied

For every functional dependency:

Dependency	Determinant Type
user_id → user_email	user_id is PK
wedding_id → wedding_budget	wedding_id is PK
venue_id → venue_type	venue_id is PK
booking_id → start_time	booking_id is PK

✔ All determinants are superkeys

✔ No non-key attribute determines another non-key attribute