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