Changes between Version 16 and Version 17 of RelationalModel

Timestamp:

04/20/26 00:03:05 (13 days ago)

Author:

231027

Comment:

--

RelationalModel

@@ -16 +16 @@
 Во овој дел се подетално објаснети специфичните сегменти од моделот кои содржат напредна логика или решенија за специфични бизнис проблеми.
 
-'''1. Segment: Ticket Inventory vs. Sales (Ticket vs. Actual_Ticket)'''
+'''1. Сегмент: Ticket Inventory vs. Sales (Ticket vs. Actual_Ticket)'''
 * '''Како и зошто:''' Моделот прави јасна разделба помеѓу ''понудата'' за билет и ''реализираната продажба''. Табелата `Ticket` ги содржи сите потенцијални седишта за еден настан. Табелата `Actual_Ticket` се пополнува само при извршена трансакција. Релацијата е дефинирана како '''1:1''' со Unique Constraint на `ticket_id` во `Actual_Ticket`.
 * '''Аргументација:''' Ова спречува најкритичен проблем во вакви системи - „double booking“ (продажба на исто седиште на повеќе лица). Дури и ако два процеси се обидат истовремено да запишат продажба, Unique клучот во базата ќе ја одбие втората трансакција.
 
-'''2. Segment: Dynamic Pricing (Event_Period)'''
+'''2. Сегмент: Dynamic Pricing (Event_Period)'''
 * '''Како и зошто:''' Наместо фиксна цена, воведовме табела `Event_Period` поврзана со терминот на настанот (`Event_Happening`). Секој период има дефиниран процент на зголемување или намалување (`increase` бит). Релацијата помеѓу терминот и периодите е '''1:N'''.
 * '''Аргументација:''' Ова овозможува системот автоматски да ја пресметува цената во зависност од датумот на купување (пр. Early Bird попусти или Last Minute поскапувања), без потреба од рачен `UPDATE` на цените во текот на продажбата.
 
-'''3. Segment: Venue Hierarchy (Venue -> Section -> Seat)'''
+'''3. Сегмент: Venue Hierarchy (Venue -> Section -> Seat)'''
 * '''Како и зошто:''' Салите се моделирани хиерархиски преку '''1:N''' релации. Секциите (`Venue_Section`) припаѓаат на сали, а индивидуалните седишта (`Venue_Section_Seat`) на секции.
 * '''Аргументација:''' Ова овозможува лесно пребарување и филтрирање на слободни места по сектори (пр. VIP Box, Parterre, Balcony) и ја рефлектира реалната физичка поставеност на објектите.
 
-'''4. Segment: Performer Specialization (Inheritance)'''
+'''4. Сегмент: Performer Specialization (Inheritance)'''
 * '''Како и зошто:''' Користена е специјализација (Inheritance) каде `Performer` е главен ентитет, а `Musical_Performer` и `Acting_Performer` се подтипови поврзани со релации од типот '''1:1'''.
 * '''Аргументација:''' Ова овозможува базата да биде флексибилна за различни типови настани. Музичките настани бараат податоци за жанр и дискографија, додека театарските бараат податоци за улоги и режија, а сепак сите ја делат основната структура на изведувач.
 
-'''5. Segment: Refund Logic (Actual_Ticket_Refund)'''
+'''5. Сегмент: Refund Logic (Actual_Ticket_Refund)'''
 * '''Како и зошто:''' Табелата за рефундација е поврзана директно со `qr_code` од продажбата со '''1:1''' релација.
 * '''Аргументација:''' Со ова се гарантира дека само валидно продаден билет може да биде предмет на рефундација и се чува историја на вратените средства независно од оригиналната продажба, што е клучно за финансиско сметководство.