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
