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

== ЕР Дијаграм

[[Image(RelationalModel.svg, 1400px)]]

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

- Предложениот модел претставува систем за посредување помеѓу клиенти и музички изведувачи, каде што корисниците можат да креираат барања за настани, а изведувачите да одговорат со понуди. Основниот тек на системот е организиран преку следната логика:  '''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, што значи дека рецензија може да постои само за завршена резервација.
- '''Овој дизајн овозможува: валидност на оценките, спречување на злоупотреба, реални и релевантни рецензии.'''