Релационен модел

ЕР Дијаграм

Дополнителен Опис

• Предложениот модел претставува систем за посредување помеѓу клиенти и музички изведувачи, каде што корисниците можат да креираат барања за настани, а изведувачите да одговорат со понуди. Основниот тек на системот е организиран преку следната логика: Request → Offer → Booking → Payment → Review

• Табелите Request, Offer и Booking го претставуваат основниот процес на резервација.
  • Request ги содржи сите информации за настанот (датум, време, буџет, локација, тип на настан).
  • Offer претставува одговор од изведувач на конкретен request и содржи предложена цена, траење и дополнителни трошоци.
  • Booking се креира само кога една понуда е прифатена.
• Важно е што Booking содржи само offer_id како foreign key, наместо директно да ги содржи request_id, client_id и bookable_id. Ова е направено со цел да се избегне редундантност, бидејќи сите овие информации можат индиректно да се добијат преку Offer.
• Овој дизајн овозможува: подобра нормализација, избегнување на дупликати и поедноставна логика при ажурирање.

• Ентитетот Bookable е воведен како апстракција за сите типови изведувачи.
  • ArtistProfile содржи податоци за индивидуален изведувач.
  • BandProfile содржи податоци за бенд.
  • BandMember овозможува поврзување помеѓу бенд и поединечни артисти.
• Овој дизајн овозможува: полесно управување со изведувачи, лесно додавање нов тип на изведувач, избегнување на дупли структури.

• Цените се моделирани преку табелата PricingRule, која дефинира основна цена, дополнителни трошоци и услови (тип на настан, траење...)
  • Дополнително, табелата PriceHistory се користи за чување на сите промени на цените со текот на времето.
• Овој дизајн овозможува: следење на историја на цени, анализа на промени, транспарентност во системот.

• Табелата AvailabilitySlot служи за дефинирање на достапноста на изведувачите.
  • Секој запис претставува временски интервал (start_datetime – end_datetime) во кој изведувачот е достапен или недостапен.
• Овој дизајн овозможува: спречување на двојни резервации, проверка на достапност пред креирање на booking, полесно пребарување.

• Локацијата и местото на одржување се моделирани како независни ентитети:
  • Location – град, регион, држава
  • Venue – конкретна локација (сала, клуб ...)
  • VenueType – тип на место (indoor, outdoor…)
• Табелата Request ги референцира овие ентитети преку foreign keys (location_id, venue_id, venue_type_id`), со што се избегнува дуплирање на податоци и се овозможува повторна употреба на истите.

• Табелата Message овозможува комуникација помеѓу корисниците (клиент и изведувач), при што пораките можат да бидат поврзани со конкретен Request или Booking.
• Овој дизајн овозможува: следење на комуникацијата, контекстуална размена на информации, подобро корисничко искуство.

• Payment ги чува сите информации за плаќања поврзани со booking.
• BookingStatusHistory ги чува сите промени на статусот на резервацијата.
• Овој дизајн овозможува: следење на финансиски трансакции, историја на статуси (pending, confirmed, cancelled) и подобра контрола.

• Табелата Review е поврзана директно со Booking, што значи дека рецензија може да постои само за завршена резервација.
• Овој дизајн овозможува: валидност на оценките, спречување на злоупотреба, реални и релевантни рецензии.