Changes between Version 14 and Version 15 of ERModel


Ignore:
Timestamp:
02/04/26 20:35:13 (5 days ago)
Author:
193284
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • ERModel

    v14 v15  
    22
    33== Description
    4 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.
     4This page presents the Entity–Relationship (ER) model of the Wedding Planner system.
     5The ER model defines the core entities, their attributes, and relationships required
     6to support wedding organization, event scheduling, guest management, and service reservations.
    57
    6 == Entity-Relationship Model: Wedding Planner
     8== Entity-Relationship Model – Wedding Planner
    79
    810== Diagram
    9 [[Image(Wedding_Planner_Verison5.png, width=100%)]]
     11[[Image(Wedding_Planner_Version5.png, width=100%)]]
    1012
    11 == Data requirements
     13== Entities and Relationships
    1214
    13 == Entity: User
     15The ER model consists of the following main entities:
     16User, Wedding, Event, Guest, Event_RSVP, Attendance, Venue, Venue_Type,
     17Venue_Booking, Photographer, Photographer_Booking, Band, Band_Booking,
     18Church, Priest, Registrar, and Registrar_Booking.
    1419
    15 Explanation:
    16 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.
     20Wedding is the central entity of the model. It represents a single wedding and
     21acts as the main aggregation point for all related data.
    1722
    18 Candidate keys:
    19 user_id – selected as the primary key because it is system-generated and unique 
    20 email – candidate key because it is unique per user, but not selected as primary since it may change
     23A User can organize multiple Weddings (1:N).
     24Each Wedding belongs to exactly one User.
    2125
    22 Attributes:
    23 user_id – numeric, required 
    24 first_name – text, required 
    25 last_name – text, required 
    26 email – text, required 
    27 phone_number – text, optional 
    28 gender – text, optional 
    29 birthday – date, optional 
     26A Wedding can have multiple Events (1:N).
     27Events represent scheduled parts of the wedding, such as ceremonies or receptions.
    3028
    31 == Entity: Wedding
     29Guests are associated with a Wedding (1:N).
     30Guests do not have system accounts and are modeled separately from users.
    3231
    33 Explanation:
    34 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.
     32Guest participation in events is modeled through two associative entities:
     33Event_RSVP (for invitation responses) and Attendance (for actual attendance details).
     34Both represent many-to-many relationships between Guest and Event.
    3535
    36 Candidate keys:
    37 wedding_id – selected as the primary key because it uniquely identifies each wedding
     36All service reservations (Venue, Band, Photographer, Registrar) are associated
     37directly with Wedding through booking entities.
     38This reflects the real-world rule that services are reserved for the entire wedding,
     39not for individual events.
    3840
    39 Attributes:
    40 wedding_id – numeric, required 
    41 date – date, required 
    42 budget – numeric, optional 
    43 notes – text, optional 
    44 type – text, optional 
    45 status – text, optional 
     41The Wedding–Church relationship is modeled as one-to-one (1:1),
     42enforcing that each wedding is held in exactly one church.
    4643
    47 == Entity: Event
     44No redundant or duplicate relationships are present in the final ER model.
    4845
    49 Explanation:
    50 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.
    51 
    52 Candidate keys:
    53 event_id – selected as the primary key
    54 
    55 Attributes:
    56 event_id – numeric, required 
    57 event_type – text, required 
    58 date – date, required 
    59 start_time – time, required 
    60 end_time – time, required 
    61 status – text, required 
    62 
    63 == Entity: Guest
    64 
    65 Explanation:
    66 The Guest entity represents people invited to a wedding. Guests do not need system accounts, therefore they are modeled separately from users.
    67 
    68 Candidate keys:
    69 guest_id – selected as the primary key
    70 
    71 Attributes:
    72 guest_id – numeric, required 
    73 first_name – text, required 
    74 last_name – text, required 
    75 email – text, optional 
    76 
    77 == Entity: Event_RSVP
    78 
    79 Explanation:
    80 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.
    81 
    82 Candidate keys:
    83 (guest_id, event_id) – natural composite key 
    84 response_id – surrogate primary key used in the relational model
    85 
    86 Attributes:
    87 response_id – numeric, required 
    88 status – text, required 
    89 response_date – date, required 
    90 
    91 == Entity: Attendance
    92 
    93 Explanation:
    94 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.
    95 
    96 Candidate keys:
    97 (guest_id, event_id) – natural composite key 
    98 attendance_id – surrogate primary key used in the relational model
    99 
    100 Attributes:
    101 attendance_id – numeric, required 
    102 status – text, required 
    103 table_number – numeric, optional 
    104 role – text, required 
    105 
    106 == Entity: Venue
    107 
    108 Explanation:
    109 The Venue entity represents physical locations where wedding events can be held. It stores information needed for capacity planning and pricing.
    110 
    111 Candidate keys:
    112 venue_id – selected as the primary key
    113 
    114 Attributes:
    115 venue_id – numeric, required 
    116 name – text, required 
    117 location – text, required 
    118 city – text, required 
    119 address – text, required 
    120 capacity – numeric, required 
    121 menu – text, optional 
    122 phone_number – text, optional 
    123 price_per_guest – numeric, required 
    124 
    125 == Entity: Venue_Type
    126 
    127 Explanation:
    128 The Venue_Type entity defines categories of venues, such as restaurant or wedding hall. It is modeled separately to avoid data duplication.
    129 
    130 Candidate keys:
    131 type_id – selected as the primary key
    132 
    133 Attributes:
    134 type_id – numeric, required 
    135 type_name – text, required 
    136 
    137 == Entity: Venue_booking
    138 
    139 Explanation:
    140 The Venue_booking entity represents reservations of venues for weddings. It connects weddings and venues and stores booking details.
    141 
    142 Candidate keys:
    143 booking_id – selected as the primary key
    144 
    145 Attributes:
    146 booking_id – numeric, required 
    147 date – date, required 
    148 start_time – time, required 
    149 end_time – time, required 
    150 status – text, required 
    151 price – numeric, required 
    152 
    153 == Entity: Photographer
    154 
    155 Explanation:
    156 The Photographer entity represents photographers available for booking.
    157 
    158 Candidate keys:
    159 photographer_id – selected as the primary key
    160 
    161 Attributes:
    162 photographer_id – numeric, required 
    163 name – text, required 
    164 email – text, required 
    165 phone_number – text, required 
    166 price_per_hour – numeric, required 
    167 
    168 == Entity: Photographer_booking
    169 
    170 Explanation:
    171 The Photographer_booking entity stores photographer reservations for weddings.
    172 
    173 Candidate keys:
    174 booking_id – selected as the primary key
    175 
    176 Attributes:
    177 booking_id – numeric, required 
    178 date – date, required 
    179 start_time – time, required 
    180 end_time – time, required 
    181 status – text, required 
    182 
    183 == Entity: Band
    184 
    185 Explanation:
    186 The Band entity represents music performers available for weddings.
    187 
    188 Candidate keys:
    189 band_id – selected as the primary key
    190 
    191 Attributes:
    192 band_id – numeric, required 
    193 band_name – text, required 
    194 genre – text, required 
    195 equipment – text, optional 
    196 phone_number – text, required 
    197 price_per_hour – numeric, required 
    198 
    199 == Entity: Band_booking
    200 
    201 Explanation:
    202 The Band_booking entity stores reservations of bands for weddings.
    203 
    204 Candidate keys:
    205 booking_id – selected as the primary key
    206 
    207 Attributes:
    208 booking_id – numeric, required 
    209 date – date, required 
    210 start_time – time, required 
    211 end_time – time, required 
    212 status – text, required 
    213 
    214 == Entity: Church
    215 
    216 Explanation:
    217 The Church entity represents religious locations where wedding ceremonies can take place.
    218 
    219 Candidate keys:
    220 church_id – selected as the primary key
    221 
    222 Attributes:
    223 church_id – numeric, required 
    224 name – text, required 
    225 location – text, required 
    226 contact – text, required 
    227 
    228 == Entity: Priest
    229 
    230 Explanation:
    231 The Priest entity represents clergy members who perform wedding ceremonies.
    232 
    233 Candidate keys:
    234 priest_id – selected as the primary key
    235 
    236 Attributes:
    237 priest_id – numeric, required 
    238 name – text, required 
    239 contact – text, required 
    240 
    241 == Relationships and Constraints
    242 
    243 User – Wedding:
    244 One User can organize multiple Weddings (1:N). Each Wedding belongs to exactly one User.
    245 
    246 Wedding – Event:
    247 One Wedding can have multiple Events (1:N). Each Event belongs to one Wedding.
    248 
    249 Wedding – Guest:
    250 One Wedding can invite multiple Guests (1:N).
    251 
    252 Guest – Event (RSVP):
    253 Guests can RSVP to multiple Events and Events can have multiple RSVPs (M:N).
    254 
    255 Guest – Event (Attendance):
    256 Guests can attend multiple Events and Events can have multiple Attendance records (M:N).
    257 
    258 Wedding – Venue_booking – Venue:
    259 A Wedding can have multiple Venue bookings and a Venue can be booked multiple times. Overlapping bookings for the same venue are not allowed.
    260 
    261 Wedding – Band_booking – Band:
    262 A Wedding can book multiple Bands. Overlapping bookings for the same band are not allowed.
    263 
    264 Wedding – Photographer_booking – Photographer:
    265 A Wedding can book multiple Photographers. Overlapping bookings for the same photographer are not allowed.
    266 
    267 Wedding – Church:
    268 Each Wedding is associated with exactly one Church. A Church cannot be assigned to more than one Wedding at the same date and time.
    269 
    270 == Entity-Relationship Model History
    271 
     46== ER Model History
    27247v0.1 – Initial ER model 
    27348v0.2 – Updated Church–Wedding relationship 
    274 v0.3 – Refined Church–Wedding constraints 
    275 v0.4 – Improved clarity and structure 
    276 v0.5 – Final ER model aligned with the relational database design
     49v0.3 – Refined constraints and relationships 
     50v0.4 – Model cleanup and clarity improvements 
     51v0.5 – Final ER model aligned with relational design