= ER Model == Description This page contains the Entity–Relationship (ER) model description and diagrams for the Wedding Planner system. The ER model captures the core entities, their attributes, and relationships required to support wedding planning, event organization, guest management, and service reservations. == Entity-Relationship Model Wedding_Planner == Diagram [[Image(Wedding_Planner_Verison5.png, width=100%)]] == Data requirements == Entity: User Explanation: 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 acts as the main system actor. A user can create and manage multiple weddings, invite guests, and reserve services. This entity is modeled separately to centralize user data, support authentication, and establish ownership of weddings. Candidate keys: user_id – selected as the primary key because it is system-generated, stable, and unique email – candidate key because it is unique per user, but not chosen as primary since it may change 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 Explanation: The Wedding entity represents a specific wedding being planned and managed within the system. It is the central entity that connects all guests, events, reservations, and service bookings. Modeling it separately allows the system to manage multiple weddings independently and associate all related data consistently. Candidate keys: wedding_id – selected as the primary key as a unique system-generated identifier Attributes: wedding_id – numeric, required date – date, required budget – numeric, optional notes – text, optional type – text, optional status – text, optional == Entity: Event Explanation: The Event entity represents individual events associated with a wedding, such as ceremonies, receptions, or celebrations. Modeling events separately allows each wedding to have multiple scheduled events with different times and purposes. Candidate keys: event_id – selected as the primary key because it uniquely identifies each event Attributes: event_id – numeric, required event_type – text, required date – date, required start_time – time, required end_time – time, required status – text, required == Entity: Event_RSVP Explanation: The Event_RSVP entity stores responses from guests regarding their attendance at specific events. It is required to track confirmations, declines, and response dates for event planning purposes. Candidate keys: response_id – selected as the primary key because it uniquely identifies each RSVP record Attributes: response_id – numeric, required status – text, required response_date – date, required == Entity: Guest Explanation: The Guest entity represents individuals invited to a wedding. Guests do not need system accounts, therefore they are modeled separately from users. This allows flexible guest management without authentication requirements. Candidate keys: guest_id – selected as the primary key Attributes: guest_id – numeric, required first_name – text, required last_name – text, required email – text, optional == Entity: Attendance Explanation: The Attendance entity represents the actual participation of guests in wedding events. It allows tracking attendance status, assigned roles, and seating arrangements. Seating information is optional, as not all events require tables (e.g., ceremonies). Candidate keys: attendance_id – selected as the primary key Attributes: attendance_id – numeric, required status – text, required table_number – numeric, optional role – text, required == Entity: Venue Explanation: The Venue entity represents physical locations where wedding-related events take place. It stores capacity, pricing, and contact information to support venue selection and booking. Candidate keys: venue_id – selected as the primary key 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 == Entity: Venue_Type Explanation: The Venue_Type entity categorizes venues (e.g., restaurant, hall, outdoor space). It is modeled separately to ensure data consistency and allow easy extension. Candidate keys: type_id – selected as the primary key Attributes: type_id – numeric, required type_name – text, required == Entity: Venue_booking Explanation: The Venue_booking entity represents reservations of venues for weddings. It resolves the many-to-many relationship between weddings and venues and stores scheduling and pricing information. Candidate keys: booking_id – selected as the primary key Attributes: booking_id – numeric, required date – date, required start_time – time, required end_time – time, required status – text, required price – numeric, required == Entity: Photographer Explanation: The Photographer entity represents professional photographers available for weddings. It stores contact and pricing information to support booking and comparison. Candidate keys: photographer_id – selected as the primary key Attributes: photographer_id – numeric, required name – text, required email – text, required phone_number – text, required price_per_hour – numeric, required == Entity: Photographer_booking Explanation: The Photographer_booking entity records photographer reservations for specific weddings and time intervals. Candidate keys: booking_id – selected as the primary key Attributes: booking_id – numeric, required date – date, required start_time – time, required end_time – time, required status – text, required == Entity: Band Explanation: The Band entity represents music performers available for weddings. It stores information needed for selection and booking. Candidate keys: band_id – selected as the primary key 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 Explanation: The Band_booking entity represents reservations of bands for weddings, including timing and booking status. Candidate keys: booking_id – selected as the primary key Attributes: booking_id – numeric, required date – date, required start_time – time, required end_time – time, required status – text, required == Entity: Church Explanation: The Church entity represents religious locations where wedding ceremonies can take place. Candidate keys: church_id – selected as the primary key Attributes: church_id – numeric, required name – text, required location – text, required contact – text, required == Entity: Priest Explanation: The Priest entity represents clergy members who perform wedding ceremonies. It is modeled separately to allow flexible assignment to ceremonies. Candidate keys: priest_id – selected as the primary key Attributes: priest_id – numeric, required name – text, required contact – text, required == Relationships and Constraints === User – Wedding One User can organize multiple Weddings (1:N) Each Wedding belongs to exactly one User (mandatory) === Wedding – Event One Wedding can have multiple Events (1:N) Each Event belongs to exactly one Wedding === Wedding – Guest One Wedding can invite multiple Guests (1:N) Each Guest is associated with one Wedding === Guest – Event (RSVP) Guests can RSVP to multiple Events and Events can have multiple RSVPs (M:N) Event_RSVP stores RSVP status and response date === Guest – Event (Attendance) Guests can attend multiple Events and Events can have multiple Attendance records (M:N) Attendance stores role, seating, and attendance status === Wedding – Venue_booking – Venue One Wedding can have multiple Venue_bookings One Venue can be booked multiple times Constraint: no overlapping bookings for the same Venue === Wedding – Band_booking – Band One Wedding can have multiple Band_bookings Constraint: no overlapping bookings for the same Band === Wedding – Photographer_booking – Photographer One Wedding can have multiple Photographer_bookings Constraint: no overlapping bookings for the same Photographer === Wedding – Church Each Wedding is associated with exactly one Church (1:1) A Church cannot be assigned to more than one Wedding at the same date and time == Entity-Relationship Model History v0.1 – Initial ER model v0.2 – Updated Church–Wedding relationship v0.3 – Refined Church–Wedding constraints v0.4 – Fourth version of the ER model with refined Church–Wedding relationship v0.5 – Final version of the ER model with improved clarity, consistency, and full alignment with the relational database design