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.