Context Navigation

Changes between Version 2 and Version 3 of ERModel

Timestamp:: 01/02/26 02:43:52 (3 weeks ago)
Author:: 193284
Comment:: --

Legend:

: Unmodified
: Added
: Removed
: Modified

ERModel

-              v2
+              v3
 This page contains the ER model description and diagrams for the system.
+== ** Entity-Relationship Model Wedding_Planner**
+== **Entity-Relationship Model Wedding_Planner**
 == **Diagram**
 [[Image(Wedding_planner_Version.01.png, width=100%)]]
+== **Data requirements**
+== **Data requirements**
 == **Entity: User**
 …
 The User entity represents a registered person who uses the system to organize and manage weddings and related events. It stores personal and contact information and serves as the main actor that creates weddings, organizes events, and interacts with guests and service providers. The entity is modeled separately to centralize user data and enable secure identification and ownership of weddings.
+**Candidate keys:**
+**Candidate keys:**
 user_id – chosen as the primary key because it is a system-generated, stable, and unique identifier.
 email – candidate key because it is unique per user, but not selected as the primary key since it can change.
+**Attributes:**
+**Attributes:**
 user_id – numeric, required
 first_name – text, required
 last_name – text, required
 email – text, required, valid email format
 phone_number – text, optional
 gender – text, optional
 birthday – date, optional
 == Entity: Wedding
+== **Entity: Wedding**
 Explanation:
 The Wedding entity represents a specific wedding event being planned and managed in the system. It acts as the central entity that connects all reservations, services, guests, and events related to a wedding. It is modeled as a separate entity to clearly group all wedding-related data and enable independent management of multiple weddings by different users.
+**Candidate keys:**
+**Candidate keys:**
 wedding_id – chosen as the primary key as a unique system-generated identifier.
+**Attributes:**
+**Attributes:**
 wedding_id – numeric, required
+date – date, required
+date – date, required
 budget – numeric, optional
 notes – text, optional
 …
 The Event entity represents individual events related to a wedding, such as ceremonies, receptions, or parties. It allows the system to track schedules, types, and statuses of events. Modeling events separately enables flexibility in planning multiple events for a single wedding.
+**Candidate keys:**
+**Candidate keys:**
 event_id – chosen as the primary key because it uniquely identifies each event.
+**Attributes:**
+**Attributes:**
 event_id – numeric, required
 event_type – text, required
+date – date, required
+start_time – time, required
+end_time – time, required
+date – date, required
+start_time – time, required
+end_time – time, required
 status – text, required
 …
 Explanation:
+The Event_RSVP entity records responses of users or guests to event invitations. It is necessary to track attendance confirmations and response statuses for proper event organization.
+**Candidate keys:**
+The Event_RSVP entity records responses of guests to event invitations. It is necessary to track attendance confirmations and response statuses for proper event organization.
+**Candidate keys:**
 response_id – chosen as the primary key as it uniquely identifies each RSVP response.
+**Attributes:**
+**Attributes:**
 response_id – numeric, required
+status – text, required
+status – text, required
 response_date – date, required
 …
 The Guest entity represents individuals invited to the wedding. It stores guest-specific information independently from registered users, as guests do not need system accounts.
+**Candidate keys:**
+**Candidate keys:**
 guest_id – chosen as the primary key.
+**Attributes:**
+**Attributes:**
 guest_id – numeric, required
 first_name – text, required
 last_name – text, required
 email – text, optional
 …
 == **Entity: Attendance**
+Explanation:
+The Attendance entity represents the participation of guests in wedding events. It enables tracking seating, roles, and attendance status.
+**Candidate keys:**
+Explanation:
+The Attendance entity represents the participation of guests in wedding events. It is used to track whether a guest will attend a specific event, and (when applicable) their seating assignment and role during that event. Seating information is optional because not all events require tables (e.g., church ceremony or civil registration).
+**Candidate keys:**
 attendance_id – chosen as the primary key.
+**Attributes:**
+**Attributes:**
 attendance_id – numeric, required
+status – text, required
+table_number – numeric, required
+status – text, required
+table_number – numeric, optional
 role – text, required
-total – numeric, required
 == **Entity: Venue**
 …
 The Venue entity represents physical locations where wedding events take place. It stores capacity, pricing, and contact details to support venue selection and booking.
+**Candidate keys:**
+**Candidate keys:**
 venue_id – chosen as the primary key.
+**Attributes:**
+**Attributes:**
 venue_id – numeric, required
 name – text, required
 location – text, required
 city – text, required
 address – text, required
 capacity – numeric, required
 menu – text, optional
 phone_number – text, optional
 price_per_guest – numeric, required
 …
 The Venue_Type entity categorizes venues (e.g., restaurant, hall, outdoor space). It is separated to ensure data consistency and easy extensibility.
+**Candidate keys:**
+**Candidate keys:**
 type_id – chosen as the primary key.
+**Attributes:**
+**Attributes:**
 type_id – numeric, required
 type_name – text, required
 …
 The Venue_booking entity represents reservations of venues for weddings. It captures scheduling and pricing information and ensures no booking conflicts occur.
+**Candidate keys:**
+**Candidate keys:**
 booking_id – chosen as the primary key.
+**Attributes:**
+**Attributes:**
 booking_id – numeric, required
+date – date, required
+start_time – time, required
+end_time – time, required
+status – text, required
+date – date, required
+start_time – time, required
+end_time – time, required
+status – text, required
 price – numeric, required
 …
 The Photographer entity represents professional photographers available for weddings. It stores contact and pricing information to support booking and comparison.
+**Candidate keys:**
+**Candidate keys:**
 photographer_id – chosen as the primary key.
+**Attributes:**
+**Attributes:**
 photographer_id – numeric, required
 name – text, required
 email – text, required
 phone_number – text, required
 price_per_hour – numeric, required
 …
 This entity records bookings of photographers for specific weddings and time periods.
+**Candidate keys:**
+**Candidate keys:**
 booking_id – chosen as the primary key.
+**Attributes:**
+**Attributes:**
 booking_id – numeric, required
+date – date, required
+start_time – time, required
+end_time – time, required
+date – date, required
+start_time – time, required
+end_time – time, required
 status – text, required
 …
 The Band entity represents music performers available for weddings. It allows storage of genre, equipment, and pricing information.
+**Candidate keys:**
+**Candidate keys:**
 band_id – chosen as the primary key.
+**Attributes:**
+**Attributes:**
 band_id – numeric, required
 band_name – text, required
 genre – text, required
 equipment – text, optional
 phone_number – text, required
 price_per_hour – numeric, required
 == **Entity: Band_booking
+== **Entity: Band_booking**
 Explanation:
 The Band_booking entity represents reservations of bands for weddings, including timing and booking status.
+**Candidate keys:**
+**Candidate keys:**
 booking_id – chosen as the primary key.
+**Attributes:**
+**Attributes:**
 booking_id – numeric, required
+date – date, required
+start_time – time, required
+end_time – time, required
+status – text, required
+date – date, required
+start_time – time, required
+end_time – time, required
+status – text, required
 …
 The Church entity represents religious locations where wedding ceremonies can take place.
+**Candidate keys:**
+**Candidate keys:**
 church_id – chosen as the primary key.
+**Attributes:**
+**Attributes:**
 church_id – numeric, required
 name – text, required
 location – text, required
 contact – text, required
 …
 The Church_booking entity records church reservations for wedding ceremonies.
+**Candidate keys:**
+**Candidate keys:**
 booking_id – chosen as the primary key.
+**Attributes:**
+**Attributes:**
 booking_id – numeric, required
+date – date, required
+start_time – time, required
+end_time – time, required
+date – date, required
+start_time – time, required
+end_time – time, required
 status – text, required
 …
 The Priest entity represents clergy members who perform wedding ceremonies. It is modeled separately to allow assignment to church ceremonies.
+**Candidate keys:**
+**Candidate keys:**
 priest_id – chosen as the primary key.
+**Attributes:**
+**Attributes:**
 priest_id – numeric, required
 name – text, required
 contact – text, required
+== Relationships and Constraints
+=== User – Wedding
+* One User can create/manage many Weddings (1:N).
+* Each Wedding belongs to exactly one User (mandatory).
+=== Wedding – Event
+* One Wedding has many Events (1:N).
+* Each Event belongs to exactly one Wedding (mandatory).
+=== Wedding – Guest
+* One Wedding invites many Guests (1:N) (or M:N if a guest can be reused across multiple weddings).
+* Each Guest is linked to one Wedding (if guests are not reused).
+=== Guest – Event (RSVP)
+* Guest can RSVP to many Events and each Event can have many RSVPs (M:N).
+* Event_RSVP is the associative entity that stores: status, response_date.
+=== Guest – Event (Attendance)
+* Guest can attend many Events and each Event has many Attendance records (M:N).
+* Attendance stores per-event guest details: role, table_number (optional), status.
+=== Wedding – Venue_booking – Venue
+* One Wedding can have many Venue_bookings (1:N).
+* One Venue can be booked many times (1:N).
+* Venue_booking resolves M:N between Wedding and Venue and stores date/time/status/price.
+* Constraint: a Venue cannot be booked in overlapping time intervals.
+=== Wedding – Band_booking – Band
+* One Wedding can have many Band_bookings (1:N).
+* One Band can be booked many times (1:N).
+* Constraint: no overlapping bookings for the same Band.
+=== Wedding – Photographer_booking – Photographer
+* One Wedding can have many Photographer_bookings (1:N).
+* One Photographer can be booked many times (1:N).
+* Constraint: no overlapping bookings for the same Photographer.
+=== Wedding – Church_booking – Church
+* One Wedding can have many Church_bookings (1:N).
+* One Church can be booked many times (1:N).
+* Constraint: no overlapping bookings for the same Church.
 == **Entity-Relationship Model History**
 *.01 – Initial version of the ER model