Changes between Initial Version and Version 1 of Proof of Candidate Key

Timestamp:

01/27/26 23:10:10 (13 days ago)

Author:

213087

Comment:

--

Proof of Candidate Key

@@ +1 @@
+== 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.