== Candidate Key Determination ==

As mentioned before, based on business rules of the Wedding Planner system, the following functional dependencies hold:

|| ID || Functional Dependency || Justification ||
|| FD1 || user_id → user_first_name, user_last_name, user_email || User attributes depend only on user_id 
|| FD2 || wedding_id → wedding_date, wedding_budget, user_id || A wedding uniquely defines its properties 
|| FD3 || venue_id → venue_name, venue_type, venue_capacity || Venue attributes depend only on venue_id 
|| FD4 || booking_id → venue_id, wedding_id, booking_date, start_time, end_time || A booking uniquely defines a venue reservation ||
=== FD1: user_id → user_first_name, user_last_name, user_email ===

Proof:

|| Condition || Reason ||
|| user_id is unique || Each user has exactly one system account 
|| Name and email belong to the user || They do not depend on weddings or venues 
|| Same user_id always gives same values || No variation allowed by system rules 

Conclusion:

|| Functional Dependency ||
|| user_id → user_first_name, user_last_name, user_email ||

This dependency is non-transitive and deterministic.

=== FD2: wedding_id → wedding_date, wedding_budget, user_id ===

Proof:

|| Condition || Reason ||
|| wedding_id is unique || Each wedding is registered once 
|| Wedding date is fixed || A wedding cannot have multiple dates 
|| Budget belongs to the wedding || Independent of venue choice 
|| Each wedding has one owner || user_id identifies the organizer

Conclusion:

|| Functional Dependency ||
|| wedding_id → wedding_date, wedding_budget, user_id ||

This shows entity integrity for weddings.

=== FD3: venue_id → venue_name, venue_type, venue_capacity ===

Proof:

|| Condition || Reason ||
|| venue_id is unique || One ID per physical venue 
|| Name and type are static || Do not change per booking 
|| Capacity is venue-specific || Independent of weddings 

Conclusion:

|| Functional Dependency ||
|| venue_id → venue_name, venue_type, venue_capacity ||

Venue attributes are fully functionally dependent on venue_id.

=== FD4: booking_id → venue_id, wedding_id, booking_date, start_time, end_time ===

Proof:

|| Condition || Reason ||
|| booking_id is unique || One booking per reservation 
|| Booking ties venue and wedding || Both are required 
|| Date and time define reservation || Cannot vary per booking ||

Conclusion:

|| Functional Dependency ||
|| booking_id → venue_id, wedding_id, booking_date, start_time, end_time ||

This models a relationship entity (association table).

== Step 3: Attribute Closure Calculation ==

To find a candidate key, we compute attribute closures.

=== Attempt 1: user_id⁺ ===

|| Derived Attributes ||
|| user_first_name, user_last_name, user_email ||

❌ Does NOT determine wedding, venue, or booking data
→ Not a key

=== Attempt 2: wedding_id⁺ ===

|| Derived Attributes ||
|| wedding_date, wedding_budget, user_id, user_first_name, user_last_name, user_email ||

❌ Missing venue and booking data
→ Not a key

=== Attempt 3: venue_id⁺ ===

|| Derived Attributes ||
|| venue_name, venue_type, venue_capacity ||

❌ Missing user, wedding, booking
→ Not a key

=== Attempt 4: booking_id⁺ ===

|| Derived Attributes ||
|| venue_id, wedding_id, booking_date, start_time, end_time ||
|| venue_name, venue_type, venue_capacity ||
|| wedding_date, wedding_budget, user_id ||
|| user_first_name, user_last_name, user_email ||

✅ booking_id⁺ = ALL ATTRIBUTES

Thus:

|| Candidate Key ||
|| booking_id ||

To uniquely identify a tuple in R, the following composite key is required:

|| Candidate Key ||
|| (user_id, wedding_id, venue_id, booking_date) ||

This confirms that the initial relation has a composite primary key, which leads to partial dependencies.