Changes between Version 10 and Version 11 of ERModel


Ignore:
Timestamp:
02/04/26 19:31:46 (5 days ago)
Author:
193284
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • ERModel

    v10 v11  
    22
    33== Description
    4 This page contains the ER model description and diagrams for the system.
    5 
    6 == **Entity-Relationship Model Wedding_Planner**
    7 
    8 == **Diagram**
    9 [[Image(wedding_planner_version4.png, width=100%)]]
    10 
    11 == **Data requirements**
    12 
    13 == **Entity: User**
    14 
    15 Explanation:
    16 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 serves as the main actor that creates weddings, organizes events, and interacts with guests and service providers. The entity is modeled separately to centralize user data and enable secure identification and ownership of weddings.
    17 
    18 **Candidate keys:**
    19 user_id – chosen as the primary key because it is a system-generated, stable, and unique identifier.
    20 email – candidate key because it is unique per user, but not selected as the primary key since it can change.
    21 
    22 **Attributes:**
     4This 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.
     5
     6== Entity-Relationship Model Wedding_Planner
     7
     8== Diagram
     9[[Image(wedding_planner_version5.png, width=100%)]]
     10
     11== Data requirements
     12
     13== Entity: User
     14
     15Explanation:
     16The 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.
     17
     18Candidate keys:
     19user_id – selected as the primary key because it is system-generated, stable, and unique
     20email – candidate key because it is unique per user, but not chosen as primary since it may change
     21
     22Attributes:
    2323user_id – numeric, required
    2424first_name – text, required
    … …  
    2929birthday – date, optional
    3030
    31 
    32 == **Entity: Wedding**
    33 
    34 Explanation:
    35 The Wedding entity represents a specific wedding event being planned and managed in the system. It acts as the central entity that connects all reservations, services, guests, and events related to a wedding. It is modeled as a separate entity to clearly group all wedding-related data and enable independent management of multiple weddings by different users.
    36 
    37 **Candidate keys:**
    38 wedding_id – chosen as the primary key as a unique system-generated identifier.
    39 
    40 **Attributes:**
     31== Entity: Wedding
     32
     33Explanation:
     34The 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.
     35
     36Candidate keys:
     37wedding_id – selected as the primary key as a unique system-generated identifier
     38
     39Attributes:
    4140wedding_id – numeric, required
    4241date – date, required
    4342budget – numeric, optional
    4443notes – text, optional
    45 
    46 
    47 == **Entity: Event**
    48 
    49 Explanation:
    50 The Event entity represents individual events related to a wedding, such as ceremonies, receptions, or parties. It allows the system to track schedules, types, and statuses of events. Modeling events separately enables flexibility in planning multiple events for a single wedding.
    51 
    52 **Candidate keys:**
    53 event_id – chosen as the primary key because it uniquely identifies each event.
    54 
    55 **Attributes:**
     44type – text, optional
     45status – text, optional
     46
     47== Entity: Event
     48
     49Explanation:
     50The 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.
     51
     52Candidate keys:
     53event_id – selected as the primary key because it uniquely identifies each event
     54
     55Attributes:
    5656event_id – numeric, required
    5757event_type – text, required
    … …  
    6161status – text, required
    6262
    63 
    64 == **Entity: Event_RSVP**
    65 
    66 Explanation:
    67 The Event_RSVP entity records responses of guests to event invitations. It is necessary to track attendance confirmations and response statuses for proper event organization.
    68 
    69 **Candidate keys:**
    70 response_id – chosen as the primary key as it uniquely identifies each RSVP response.
    71 
    72 **Attributes:**
     63== Entity: Event_RSVP
     64
     65Explanation:
     66The 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.
     67
     68Candidate keys:
     69response_id – selected as the primary key because it uniquely identifies each RSVP record
     70
     71Attributes:
    7372response_id – numeric, required
    7473status – text, required
    7574response_date – date, required
    7675
    77 
    78 == **Entity: Guest**
    79 
    80 Explanation:
    81 The Guest entity represents individuals invited to the wedding. It stores guest-specific information independently from registered users, as guests do not need system accounts.
    82 
    83 **Candidate keys:**
    84 guest_id – chosen as the primary key.
    85 
    86 **Attributes:**
     76== Entity: Guest
     77
     78Explanation:
     79The 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.
     80
     81Candidate keys:
     82guest_id – selected as the primary key
     83
     84Attributes:
    8785guest_id – numeric, required
    8886first_name – text, required
    … …  
    9088email – text, optional
    9189
    92 
    93 == **Entity: Attendance**
    94 
    95 Explanation:
    96 The Attendance entity represents the participation of guests in wedding events. It is used to track whether a guest will attend a specific event, and (when applicable) their seating assignment and role during that event. Seating information is optional because not all events require tables (e.g., church ceremony or civil registration).
    97 
    98 **Candidate keys:**
    99 attendance_id – chosen as the primary key.
    100 
    101 **Attributes:**
     90== Entity: Attendance
     91
     92Explanation:
     93The 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).
     94
     95Candidate keys:
     96attendance_id – selected as the primary key
     97
     98Attributes:
    10299attendance_id – numeric, required
    103100status – text, required
    … …  
    105102role – text, required
    106103
    107 
    108 == **Entity: Venue**
    109 
    110 Explanation:
    111 The Venue entity represents physical locations where wedding events take place. It stores capacity, pricing, and contact details to support venue selection and booking.
    112 
    113 **Candidate keys:**
    114 venue_id – chosen as the primary key.
    115 
    116 **Attributes:**
     104== Entity: Venue
     105
     106Explanation:
     107The Venue entity represents physical locations where wedding-related events take place. It stores capacity, pricing, and contact information to support venue selection and booking.
     108
     109Candidate keys:
     110venue_id – selected as the primary key
     111
     112Attributes:
    117113venue_id – numeric, required
    118114name – text, required
    … …  
    125121price_per_guest – numeric, required
    126122
    127 
    128 == **Entity: Venue_Type**
    129 
    130 Explanation:
    131 The Venue_Type entity categorizes venues (e.g., restaurant, hall, outdoor space). It is separated to ensure data consistency and easy extensibility.
    132 
    133 **Candidate keys:**
    134 type_id – chosen as the primary key.
    135 
    136 **Attributes:**
     123== Entity: Venue_Type
     124
     125Explanation:
     126The Venue_Type entity categorizes venues (e.g., restaurant, hall, outdoor space). It is modeled separately to ensure data consistency and allow easy extension.
     127
     128Candidate keys:
     129type_id – selected as the primary key
     130
     131Attributes:
    137132type_id – numeric, required
    138133type_name – text, required
    139134
    140 
    141 == **Entity: Venue_booking**
    142 
    143 Explanation:
    144 The Venue_booking entity represents reservations of venues for weddings. It captures scheduling and pricing information and ensures no booking conflicts occur.
    145 
    146 **Candidate keys:**
    147 booking_id – chosen as the primary key.
    148 
    149 **Attributes:**
     135== Entity: Venue_booking
     136
     137Explanation:
     138The 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.
     139
     140Candidate keys:
     141booking_id – selected as the primary key
     142
     143Attributes:
    150144booking_id – numeric, required
    151145date – date, required
    … …  
    155149price – numeric, required
    156150
    157 
    158 == **Entity: Photographer**
     151== Entity: Photographer
    159152
    160153Explanation:
    161154The Photographer entity represents professional photographers available for weddings. It stores contact and pricing information to support booking and comparison.
    162155
    163 **Candidate keys:**
    164 photographer_id – chosen as the primary key.
    165 
    166 **Attributes:**
     156Candidate keys:
     157photographer_id – selected as the primary key
     158
     159Attributes:
    167160photographer_id – numeric, required
    168161name – text, required
    … …  
    171164price_per_hour – numeric, required
    172165
    173 
    174 == **Entity: Photographer_booking**
    175 
    176 Explanation:
    177 This entity records bookings of photographers for specific weddings and time periods.
    178 
    179 **Candidate keys:**
    180 booking_id – chosen as the primary key.
    181 
    182 **Attributes:**
     166== Entity: Photographer_booking
     167
     168Explanation:
     169The Photographer_booking entity records photographer reservations for specific weddings and time intervals.
     170
     171Candidate keys:
     172booking_id – selected as the primary key
     173
     174Attributes:
    183175booking_id – numeric, required
    184176date – date, required
    … …  
    187179status – text, required
    188180
    189 
    190 == **Entity: Band**
    191 
    192 Explanation:
    193 The Band entity represents music performers available for weddings. It allows storage of genre, equipment, and pricing information.
    194 
    195 **Candidate keys:**
    196 band_id – chosen as the primary key.
    197 
    198 **Attributes:**
     181== Entity: Band
     182
     183Explanation:
     184The Band entity represents music performers available for weddings. It stores information needed for selection and booking.
     185
     186Candidate keys:
     187band_id – selected as the primary key
     188
     189Attributes:
    199190band_id – numeric, required
    200191band_name – text, required
    … …  
    204195price_per_hour – numeric, required
    205196
    206 
    207 == **Entity: Band_booking**
     197== Entity: Band_booking
    208198
    209199Explanation:
    210200The Band_booking entity represents reservations of bands for weddings, including timing and booking status.
    211201
    212 **Candidate keys:**
    213 booking_id – chosen as the primary key.
    214 
    215 **Attributes:**
     202Candidate keys:
     203booking_id – selected as the primary key
     204
     205Attributes:
    216206booking_id – numeric, required
    217207date – date, required
    … …  
    220210status – text, required
    221211
    222 
    223 == **Entity: Church**
     212== Entity: Church
    224213
    225214Explanation:
    226215The Church entity represents religious locations where wedding ceremonies can take place.
    227216
    228 **Candidate keys:**
    229 church_id – chosen as the primary key.
    230 
    231 **Attributes:**
     217Candidate keys:
     218church_id – selected as the primary key
     219
     220Attributes:
    232221church_id – numeric, required
    233222name – text, required
    … …  
    235224contact – text, required
    236225
    237 
    238 == **Entity: Priest**
    239 
    240 Explanation:
    241 The Priest entity represents clergy members who perform wedding ceremonies. It is modeled separately to allow assignment to church ceremonies.
    242 
    243 **Candidate keys:**
    244 priest_id – chosen as the primary key.
    245 
    246 **Attributes:**
     226== Entity: Priest
     227
     228Explanation:
     229The Priest entity represents clergy members who perform wedding ceremonies. It is modeled separately to allow flexible assignment to ceremonies.
     230
     231Candidate keys:
     232priest_id – selected as the primary key
     233
     234Attributes:
    247235priest_id – numeric, required
    248236name – text, required
    249237contact – text, required
    250238
    251 
    252239== Relationships and Constraints
    253240
    254241=== User – Wedding
    255 * One User can create/manage many Weddings (1:N).
    256 * Each Wedding belongs to exactly one User (mandatory).
     242
     243One User can organize multiple Weddings (1:N)
     244Each Wedding belongs to exactly one User (mandatory)
    257245
    258246=== Wedding – Event
    259 * One Wedding has many Events (1:N).
    260 * Each Event belongs to exactly one Wedding (mandatory).
     247
     248One Wedding can have multiple Events (1:N)
     249Each Event belongs to exactly one Wedding
    261250
    262251=== Wedding – Guest
    263 * One Wedding invites many Guests (1:N) (or M:N if a guest can be reused across multiple weddings).
    264 * Each Guest is linked to one Wedding (if guests are not reused).
     252
     253One Wedding can invite multiple Guests (1:N)
     254Each Guest is associated with one Wedding
    265255
    266256=== Guest – Event (RSVP)
    267 * Guest can RSVP to many Events and each Event can have many RSVPs (M:N).
    268 * Event_RSVP is the associative entity that stores: status, response_date.
     257
     258Guests can RSVP to multiple Events and Events can have multiple RSVPs (M:N)
     259Event_RSVP stores RSVP status and response date
    269260
    270261=== Guest – Event (Attendance)
    271 * Guest can attend many Events and each Event has many Attendance records (M:N).
    272 * Attendance stores per-event guest details: role, table_number (optional), status.
     262
     263Guests can attend multiple Events and Events can have multiple Attendance records (M:N)
     264Attendance stores role, seating, and attendance status
    273265
    274266=== Wedding – Venue_booking – Venue
    275 * One Wedding can have many Venue_bookings (1:N).
    276 * One Venue can be booked many times (1:N).
    277 * Venue_booking resolves M:N between Wedding and Venue and stores date/time/status/price.
    278 * Constraint: a Venue cannot be booked in overlapping time intervals.
     267
     268One Wedding can have multiple Venue_bookings
     269One Venue can be booked multiple times
     270Constraint: no overlapping bookings for the same Venue
    279271
    280272=== Wedding – Band_booking – Band
    281 * One Wedding can have many Band_bookings (1:N).
    282 * One Band can be booked many times (1:N).
    283 * Constraint: no overlapping bookings for the same Band.
     273
     274One Wedding can have multiple Band_bookings
     275Constraint: no overlapping bookings for the same Band
    284276
    285277=== Wedding – Photographer_booking – Photographer
    286 * One Wedding can have many Photographer_bookings (1:N).
    287 * One Photographer can be booked many times (1:N).
    288 * Constraint: no overlapping bookings for the same Photographer.
     278
     279One Wedding can have multiple Photographer_bookings
     280Constraint: no overlapping bookings for the same Photographer
    289281
    290282=== Wedding – Church
    291283
    292 Each Wedding is associated with exactly one Church (1:1).
    293 Each Church is associated with at most one Wedding for a given date and time.
    294 This relationship reflects the real-world assumption that a wedding ceremony is held in a single church.
    295 Since the relationship is 1:1 and no additional booking-specific attributes are required, a separate Church_booking entity is not needed.
    296 Constraint: a Church cannot be assigned to more than one Wedding at the same date and time.
    297 
    298 
    299 == **Entity-Relationship Model History**
    300 *.01 – Initial version of the ER model
    301 
    302 
    303 *.02 – Second version of the ER model with updated Church vs Wedding relationship
    304 
    305 *.03 -Third version of ER model with updated Church vs Wedding relationship
    306 
    307 *.04 -Fourth version of ER model, with updated clearer model representation and improved look
    308 
     284Each Wedding is associated with exactly one Church (1:1)
     285A Church cannot be assigned to more than one Wedding at the same date and time
     286
     287== Entity-Relationship Model History
     288
     289v0.1 – Initial ER model
     290v0.2 – Updated Church–Wedding relationship
     291v0.3 – Refined Church–Wedding constraints
     292v0.4 – Fourth version of the ER model with refined Church–Wedding relationship
     293v0.5 – Final version of the ER model with improved clarity, consistency, and full alignment with the relational database design