| | 1 | |
| | 2 | |
| | 3 | |
| | 4 | == ** Entity-Relationship Model Wedding_Planner** |
| | 5 | |
| | 6 | |
| | 7 | |
| | 8 | |
| | 9 | == **Diagram** |
| | 10 | [[Image(Wedding_planner_Version.01.png, width=100%)]] |
| | 11 | |
| | 12 | |
| | 13 | |
| | 14 | == **Data requirements** |
| | 15 | |
| | 16 | == **Entity: User** |
| | 17 | |
| | 18 | Explanation: |
| | 19 | 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. |
| | 20 | |
| | 21 | |
| | 22 | **Candidate keys:** |
| | 23 | |
| | 24 | user_id – chosen as the primary key because it is a system-generated, stable, and unique identifier. |
| | 25 | |
| | 26 | email – candidate key because it is unique per user, but not selected as the primary key since it can change. |
| | 27 | |
| | 28 | |
| | 29 | **Attributes:** |
| | 30 | |
| | 31 | user_id – numeric, required |
| | 32 | |
| | 33 | first_name – text, required |
| | 34 | |
| | 35 | last_name – text, required |
| | 36 | |
| | 37 | email – text, required, valid email format |
| | 38 | |
| | 39 | phone_number – text, optional |
| | 40 | |
| | 41 | gender – text, optional |
| | 42 | |
| | 43 | birthday – date, optional |
| | 44 | |
| | 45 | |
| | 46 | == Entity: Wedding |
| | 47 | |
| | 48 | Explanation: |
| | 49 | 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. |
| | 50 | |
| | 51 | |
| | 52 | **Candidate keys:** |
| | 53 | |
| | 54 | wedding_id – chosen as the primary key as a unique system-generated identifier. |
| | 55 | |
| | 56 | |
| | 57 | **Attributes:** |
| | 58 | |
| | 59 | wedding_id – numeric, required |
| | 60 | |
| | 61 | date – date, required |
| | 62 | |
| | 63 | budget – numeric, optional |
| | 64 | |
| | 65 | notes – text, optional |
| | 66 | |
| | 67 | |
| | 68 | == **Entity: Event** |
| | 69 | |
| | 70 | Explanation: |
| | 71 | 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. |
| | 72 | |
| | 73 | |
| | 74 | **Candidate keys:** |
| | 75 | |
| | 76 | event_id – chosen as the primary key because it uniquely identifies each event. |
| | 77 | |
| | 78 | |
| | 79 | **Attributes:** |
| | 80 | |
| | 81 | event_id – numeric, required |
| | 82 | |
| | 83 | event_type – text, required |
| | 84 | |
| | 85 | date – date, required |
| | 86 | |
| | 87 | start_time – time, required |
| | 88 | |
| | 89 | end_time – time, required |
| | 90 | |
| | 91 | status – text, required |
| | 92 | |
| | 93 | |
| | 94 | == **Entity: Event_RSVP** |
| | 95 | |
| | 96 | Explanation: |
| | 97 | The Event_RSVP entity records responses of users or guests to event invitations. It is necessary to track attendance confirmations and response statuses for proper event organization. |
| | 98 | |
| | 99 | |
| | 100 | **Candidate keys:** |
| | 101 | |
| | 102 | response_id – chosen as the primary key as it uniquely identifies each RSVP response. |
| | 103 | |
| | 104 | |
| | 105 | **Attributes:** |
| | 106 | |
| | 107 | response_id – numeric, required |
| | 108 | |
| | 109 | status – text, required |
| | 110 | |
| | 111 | response_date – date, required |
| | 112 | |
| | 113 | |
| | 114 | == **Entity: Guest** |
| | 115 | |
| | 116 | Explanation: |
| | 117 | 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. |
| | 118 | |
| | 119 | |
| | 120 | **Candidate keys:** |
| | 121 | |
| | 122 | guest_id – chosen as the primary key. |
| | 123 | |
| | 124 | |
| | 125 | **Attributes:** |
| | 126 | |
| | 127 | guest_id – numeric, required |
| | 128 | |
| | 129 | first_name – text, required |
| | 130 | |
| | 131 | last_name – text, required |
| | 132 | |
| | 133 | email – text, optional |
| | 134 | |
| | 135 | |
| | 136 | == **Entity: Attendance** |
| | 137 | |
| | 138 | |
| | 139 | Explanation: |
| | 140 | The Attendance entity represents the participation of guests in wedding events. It enables tracking seating, roles, and attendance status. |
| | 141 | |
| | 142 | |
| | 143 | **Candidate keys:** |
| | 144 | |
| | 145 | attendance_id – chosen as the primary key. |
| | 146 | |
| | 147 | |
| | 148 | **Attributes:** |
| | 149 | |
| | 150 | attendance_id – numeric, required |
| | 151 | |
| | 152 | status – text, required |
| | 153 | |
| | 154 | table_number – numeric, required |
| | 155 | |
| | 156 | role – text, required |
| | 157 | |
| | 158 | total – numeric, required |
| | 159 | |
| | 160 | |
| | 161 | == **Entity: Venue** |
| | 162 | |
| | 163 | Explanation: |
| | 164 | The Venue entity represents physical locations where wedding events take place. It stores capacity, pricing, and contact details to support venue selection and booking. |
| | 165 | |
| | 166 | |
| | 167 | **Candidate keys:** |
| | 168 | |
| | 169 | venue_id – chosen as the primary key. |
| | 170 | |
| | 171 | |
| | 172 | **Attributes:** |
| | 173 | |
| | 174 | venue_id – numeric, required |
| | 175 | |
| | 176 | name – text, required |
| | 177 | |
| | 178 | location – text, required |
| | 179 | |
| | 180 | city – text, required |
| | 181 | |
| | 182 | address – text, required |
| | 183 | |
| | 184 | capacity – numeric, required |
| | 185 | |
| | 186 | menu – text, optional |
| | 187 | |
| | 188 | phone_number – text, optional |
| | 189 | |
| | 190 | price_per_guest – numeric, required |
| | 191 | |
| | 192 | |
| | 193 | == **Entity: Venue_Type** |
| | 194 | |
| | 195 | Explanation: |
| | 196 | The Venue_Type entity categorizes venues (e.g., restaurant, hall, outdoor space). It is separated to ensure data consistency and easy extensibility. |
| | 197 | |
| | 198 | |
| | 199 | **Candidate keys:** |
| | 200 | |
| | 201 | type_id – chosen as the primary key. |
| | 202 | |
| | 203 | |
| | 204 | **Attributes:** |
| | 205 | |
| | 206 | type_id – numeric, required |
| | 207 | |
| | 208 | type_name – text, required |
| | 209 | |
| | 210 | |
| | 211 | == **Entity: Venue_booking** |
| | 212 | |
| | 213 | Explanation: |
| | 214 | The Venue_booking entity represents reservations of venues for weddings. It captures scheduling and pricing information and ensures no booking conflicts occur. |
| | 215 | |
| | 216 | |
| | 217 | **Candidate keys:** |
| | 218 | |
| | 219 | booking_id – chosen as the primary key. |
| | 220 | |
| | 221 | |
| | 222 | **Attributes:** |
| | 223 | |
| | 224 | booking_id – numeric, required |
| | 225 | |
| | 226 | date – date, required |
| | 227 | |
| | 228 | start_time – time, required |
| | 229 | |
| | 230 | end_time – time, required |
| | 231 | |
| | 232 | status – text, required |
| | 233 | |
| | 234 | price – numeric, required |
| | 235 | |
| | 236 | |
| | 237 | == **Entity: Photographer** |
| | 238 | |
| | 239 | Explanation: |
| | 240 | The Photographer entity represents professional photographers available for weddings. It stores contact and pricing information to support booking and comparison. |
| | 241 | |
| | 242 | |
| | 243 | **Candidate keys:** |
| | 244 | |
| | 245 | photographer_id – chosen as the primary key. |
| | 246 | |
| | 247 | |
| | 248 | **Attributes:** |
| | 249 | |
| | 250 | photographer_id – numeric, required |
| | 251 | |
| | 252 | name – text, required |
| | 253 | |
| | 254 | email – text, required |
| | 255 | |
| | 256 | phone_number – text, required |
| | 257 | |
| | 258 | price_per_hour – numeric, required |
| | 259 | |
| | 260 | |
| | 261 | == **Entity: Photographer_booking** |
| | 262 | |
| | 263 | Explanation: |
| | 264 | This entity records bookings of photographers for specific weddings and time periods. |
| | 265 | |
| | 266 | |
| | 267 | **Candidate keys:** |
| | 268 | |
| | 269 | booking_id – chosen as the primary key. |
| | 270 | |
| | 271 | |
| | 272 | **Attributes:** |
| | 273 | |
| | 274 | booking_id – numeric, required |
| | 275 | |
| | 276 | date – date, required |
| | 277 | |
| | 278 | start_time – time, required |
| | 279 | |
| | 280 | end_time – time, required |
| | 281 | |
| | 282 | status – text, required |
| | 283 | |
| | 284 | |
| | 285 | == **Entity: Band** |
| | 286 | |
| | 287 | Explanation: |
| | 288 | The Band entity represents music performers available for weddings. It allows storage of genre, equipment, and pricing information. |
| | 289 | |
| | 290 | |
| | 291 | **Candidate keys:** |
| | 292 | |
| | 293 | band_id – chosen as the primary key. |
| | 294 | |
| | 295 | |
| | 296 | **Attributes:** |
| | 297 | |
| | 298 | band_id – numeric, required |
| | 299 | |
| | 300 | band_name – text, required |
| | 301 | |
| | 302 | genre – text, required |
| | 303 | |
| | 304 | equipment – text, optional |
| | 305 | |
| | 306 | phone_number – text, required |
| | 307 | |
| | 308 | price_per_hour – numeric, required |
| | 309 | |
| | 310 | |
| | 311 | == **Entity: Band_booking |
| | 312 | |
| | 313 | Explanation: |
| | 314 | The Band_booking entity represents reservations of bands for weddings, including timing and booking status. |
| | 315 | |
| | 316 | |
| | 317 | **Candidate keys:** |
| | 318 | |
| | 319 | booking_id – chosen as the primary key. |
| | 320 | |
| | 321 | |
| | 322 | **Attributes:** |
| | 323 | |
| | 324 | booking_id – numeric, required |
| | 325 | |
| | 326 | date – date, required |
| | 327 | |
| | 328 | start_time – time, required |
| | 329 | |
| | 330 | end_time – time, required |
| | 331 | |
| | 332 | status – text, required |
| | 333 | |
| | 334 | |
| | 335 | |
| | 336 | == **Entity: Church** |
| | 337 | |
| | 338 | Explanation: |
| | 339 | The Church entity represents religious locations where wedding ceremonies can take place. |
| | 340 | |
| | 341 | |
| | 342 | **Candidate keys:** |
| | 343 | |
| | 344 | church_id – chosen as the primary key. |
| | 345 | |
| | 346 | |
| | 347 | **Attributes:** |
| | 348 | |
| | 349 | church_id – numeric, required |
| | 350 | |
| | 351 | name – text, required |
| | 352 | |
| | 353 | location – text, required |
| | 354 | |
| | 355 | contact – text, required |
| | 356 | |
| | 357 | |
| | 358 | == **Entity: Church_booking** |
| | 359 | |
| | 360 | Explanation: |
| | 361 | The Church_booking entity records church reservations for wedding ceremonies. |
| | 362 | |
| | 363 | |
| | 364 | **Candidate keys:** |
| | 365 | |
| | 366 | booking_id – chosen as the primary key. |
| | 367 | |
| | 368 | |
| | 369 | **Attributes:** |
| | 370 | |
| | 371 | booking_id – numeric, required |
| | 372 | |
| | 373 | date – date, required |
| | 374 | |
| | 375 | start_time – time, required |
| | 376 | |
| | 377 | end_time – time, required |
| | 378 | |
| | 379 | status – text, required |
| | 380 | |
| | 381 | |
| | 382 | == **Entity: Priest** |
| | 383 | |
| | 384 | Explanation: |
| | 385 | The Priest entity represents clergy members who perform wedding ceremonies. It is modeled separately to allow assignment to church ceremonies. |
| | 386 | |
| | 387 | |
| | 388 | **Candidate keys:** |
| | 389 | |
| | 390 | priest_id – chosen as the primary key. |
| | 391 | |
| | 392 | |
| | 393 | **Attributes:** |
| | 394 | |
| | 395 | priest_id – numeric, required |
| | 396 | |
| | 397 | name – text, required |
| | 398 | |
| | 399 | contact – text, required |
| | 400 | |
| | 401 | |
| | 402 | |
| | 403 | == **Entity-Relationship Model History** |
| | 404 | |
| | 405 | *.01 – Initial version of the ER model |