=== 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@gmail.com||

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**