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.
