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

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