wiki:ERModel

Version 13 (modified by 193284, 5 days ago) ( diff )

--

ER Model

Description

This page describes the Entity–Relationship (ER) model of the Wedding Planner system. The ER model defines the main entities, their attributes, and the relationships between them, in order to support wedding planning, event organization, guest management, and service reservations.

Entity-Relationship Model: Wedding Planner

Diagram

No image "Wedding_Planner_Version5.png" attached to ERModel

Data requirements

Entity: User

Explanation: The User entity represents a registered person who uses the system to organize and manage weddings. A user can create and manage multiple weddings and is responsible for all planning activities. This entity stores personal and contact information and represents the owner of weddings in the system.

Candidate keys: user_id – selected as the primary key because it is system-generated and unique email – candidate key because it is unique per user, but not selected as primary since it may change

Attributes: user_id – numeric, required first_name – text, required last_name – text, required email – text, required phone_number – text, optional gender – text, optional birthday – date, optional

Entity: Wedding

Explanation: The Wedding entity represents a specific wedding being planned in the system. It is the central entity that connects guests, events, and all service bookings. Each wedding belongs to one user and acts as the main context for all related data.

Candidate keys: wedding_id – selected as the primary key because it uniquely identifies each wedding

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 related to a wedding, such as a ceremony or reception. Each wedding can have multiple events, scheduled at different times.

Candidate keys: event_id – selected as the primary key

Attributes: event_id – numeric, required event_type – text, required date – date, required start_time – time, required end_time – time, required status – text, required

Entity: Guest

Explanation: The Guest entity represents people invited to a wedding. Guests do not need system accounts, therefore they are modeled separately from users.

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: Event_RSVP

Explanation: The Event_RSVP entity stores guest responses to event invitations. It allows tracking whether a guest has accepted or declined an invitation and when the response was given.

Candidate keys: (guest_id, event_id) – natural composite key response_id – surrogate primary key used in the relational model

Attributes: response_id – numeric, required status – text, required response_date – date, required

Entity: Attendance

Explanation: The Attendance entity represents the actual participation of guests in events. It stores attendance status, guest role, and seating information when applicable. Seating is optional because not all events require tables.

Candidate keys: (guest_id, event_id) – natural composite key attendance_id – surrogate primary key used in the relational model

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 events can be held. It stores information needed for capacity planning and pricing.

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 defines categories of venues, such as restaurant or wedding hall. It is modeled separately to avoid data duplication.

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 connects weddings and venues and stores booking details.

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 photographers available for booking.

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 stores photographer reservations for weddings.

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.

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 stores reservations of bands for weddings.

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.

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.

Wedding – Event: One Wedding can have multiple Events (1:N). Each Event belongs to one Wedding.

Wedding – Guest: One Wedding can invite multiple Guests (1:N).

Guest – Event (RSVP): Guests can RSVP to multiple Events and Events can have multiple RSVPs (M:N).

Guest – Event (Attendance): Guests can attend multiple Events and Events can have multiple Attendance records (M:N).

Wedding – Venue_booking – Venue: A Wedding can have multiple Venue bookings and a Venue can be booked multiple times. Overlapping bookings for the same venue are not allowed.

Wedding – Band_booking – Band: A Wedding can book multiple Bands. Overlapping bookings for the same band are not allowed.

Wedding – Photographer_booking – Photographer: A Wedding can book multiple Photographers. Overlapping bookings for the same photographer are not allowed.

Wedding – Church: Each Wedding is associated with exactly one Church. 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 – Improved clarity and structure v0.5 – Final ER model aligned with the relational database design

Attachments (8)

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.