Changes between Version 12 and Version 13 of RelationalModel

Timestamp:

04/20/26 00:27:26 (13 days ago)

Author:

231088

Comment:

--

RelationalModel

@@ -13 +13 @@
    - `Offer` претставува одговор од изведувач на конкретен request и содржи предложена цена, траење и дополнителни трошоци.
    - `Booking` се креира само кога една понуда е прифатена.
-- Важно е што Booking содржи само offer_id како foreign key, наместо директно да ги содржи request_id, client_id и bookable_id. Ова е направено со цел да се избегне редундантност, бидејќи сите овие информации можат индиректно да се добијат преку Offer.
+- Важно е што `Booking` содржи само offer_id како foreign key, наместо директно да ги содржи request_id, client_id и bookable_id. Ова е направено со цел да се избегне редундантност, бидејќи сите овие информации можат индиректно да се добијат преку Offer.
+- '''Овој дизајн овозможува: подобра нормализација, избегнување на дупликати и поедноставна логика при ажурирање.'''
 
 - Ентитетот `Bookable` е воведен како апстракција за сите типови изведувачи.
@@ -19 +20 @@
    - `BandProfile` содржи податоци за бенд
    - `BandMember` овозможува поврзување помеѓу бенд и поединечни артисти
-  
+- '''Овој дизајн овозможува: полесно управување со изведувачи, лесно додавање нов тип на изведувач, избегнување на дупли структури.'''
+
   
 - Цените се моделирани преку табелата `PricingRule`, која дефинира основна цена, дополнителни трошоци и услови (тип на настан, траење...)
    - Дополнително, табелата `PriceHistory` се користи за чување на сите промени на цените со текот на времето.
+- '''Овој дизајн овозможува: следење на историја на цени, анализа на промени, транспарентност во системот.'''
+
 
 - Табелата `AvailabilitySlot` служи за дефинирање на достапноста на изведувачите.
    - Секој запис претставува временски интервал (start_datetime – end_datetime) во кој изведувачот е достапен или недостапен.
+- '''Овој дизајн овозможува: спречување на двојни резервации, проверка на достапност пред креирање на booking, полесно пребарување.'''
+
 
 - Локацијата и местото на одржување се моделирани како независни ентитети:
@@ -31 +37 @@
    - `Venue` – конкретна локација (сала, клуб ...)
    - `VenueType` – тип на место (indoor, outdoor…)
-- Табелата `Request` ги референцира овие ентитети преку foreign keys (`location_id`, `venue_id`, `venue_type_id`), со што се избегнува дуплирање на податоци и се овозможува повторна употреба на истите.
+- Табелата `Request` ги референцира овие ентитети преку foreign keys (location_id, venue_id, venue_type_id`), со што се избегнува дуплирање на податоци и се овозможува повторна употреба на истите.
 
 - Табелата `Message` овозможува комуникација помеѓу корисниците (клиент и изведувач), при што пораките можат да бидат поврзани со конкретен `Request` или `Booking`.
+- '''Овој дизајн овозможува: следење на комуникацијата, контекстуална размена на информации, подобро корисничко искуство.'''
+
 
 - `Payment` ги чува сите информации за плаќања поврзани со booking.
 - `BookingStatusHistory` ги чува сите промени на статусот на резервацијата.
+- '''Овој дизајн овозможува: следење на финансиски трансакции, историја на статуси (pending, confirmed, cancelled) и подобра контрола.'''
+
 
 - Табелата `Review` е поврзана директно со Booking, што значи дека рецензија може да постои само за завршена резервација.
+- '''Овој дизајн овозможува: валидност на оценките, спречување на злоупотреба, реални и релевантни рецензии.'''