Changes between Version 30 and Version 31 of RelationalModel

Timestamp:

06/29/26 21:18:45 (6 days ago)

Author:

231027

Comment:

--

RelationalModel

@@ -16 +16 @@
 Во овој дел се подетално објаснети специфичните сегменти од моделот кои содржат напредна логика или решенија за специфични бизнис проблеми.
 
-'''1. Сегмент: Животен циклус на билет и Продажба (Ticket vs. Ticket_Order и Ticket_Order_Item)'''
+'''1. Сегмент: Животен циклус на билет и Продажба (`Ticket` vs. `Ticket_Order` и `Ticket_Order_Item`)'''
 
  * '''Како и зошто:''' Моделот прави јасна разделба помеѓу инвентарот на билети за седишта (`Ticket`) и реализираната трансакција на купување преку `Ticket_Order` и `Ticket_Order_Item`. Табелата `Ticket` ги содржи сите потенцијални места за еден настан, додека `Ticket_Order_Item` е конкретна ставка од нарачката која содржи уникатен `qr_code` за секој купен билет.
  * '''Аргументација:''' Оваа структура овозможува прецизна историја на продажба. Кога еден билет ќе се рефундира, неговиот статус во `Ticket` (`is_available`) се враќа во '''true''' (слободен) и тој може повторно да се продаде во нова нарачка, додека претходниот запис во ставките од нарачките останува како сметководствен доказ.
 
-'''2. Сегмент: Динамично ценообразовање и фази (Event_Period)'''
+'''2. Сегмент: Динамично ценообразовање и фази (`Event_Period`)'''
 
  * '''Како и зошто:''' Наместо фиксна цена, воведена е посебна табела `Event_Period` директно поврзана со терминот на одржување (`Event_Happening`). Секој временски период има дефиниран опсег со `start_date` и `end_date`, како и атрибут `price_discount_percent` кој го одредува процентот на попуст во тој период.
  * '''Аргументација:''' Ова овозможува системот автоматски да ги калкулира цените во реално време во зависност од датумот кога корисникот купува билет (на пример, „Early Bird“ со помал процент на попуст кој се зголемува како што се приближува настанот).
 
-'''3. Сегмент: Хиерархија и Интегритет на локации (Venue -> Section -> Seat)'''
+'''3. Сегмент: Хиерархија и Интегритет на локации (`Venue` -> `Section` -> `Seat`)'''
 
  * '''Како и зошто:''' Локациите се моделирани хиерархиски преку Non-Identifying релации со користење на вештачки клучеви. Секое седиште има уникатно `seat_id` и преку надворешен клуч е поврзано со `section_id`, кое пак на ист начин референцира кон `venue_id`.
@@ -36 +36 @@
  * '''Аргументација:''' Ова овозможува строга безбедност и валидација на ниво на база. Администраторите и обичните корисници се автентицираат унифицирано преку базната табела, но нивните улоги и акции (како купување билети и оставање рејтинзи, кои се ексклузивни за `Regular_User`) се строго одвоени и заштитени. За логичка поделба на самите настани воведен е и шифрарник преку `Event_Type`.
 
-'''5. Сегмент: Финансиска безбедност и рефундација (Ticket_Refund и Ticket_Refund_Item)'''
+'''5. Сегмент: Финансиска безбедност и рефундација (`Ticket_Refund` и `Ticket_Refund_Item`)'''
 
  * '''Како и зошто:''' Процесот на рефундација е поделен на `Ticket_Refund` (глава на рефундацијата која се врзува со целата нарачка преку `order_id`) и `Ticket_Refund_Item` (ставки кои точно покажуваат кои поединечни карти се рефундирани преку `order_item_id`).