Changes between Version 12 and Version 13 of RelationalModel

Timestamp:

04/19/26 23:38:46 (13 days ago)

Author:

231027

Comment:

--

RelationalModel

@@ -8 +8 @@
 
 '''Прилог:'''
- * [attachment:RelationalModel-ProjectCode.vpp Visual Paradigm Model File]
+ * [attachment:RelationalModel-ProjectCode.vpp Visual Paradigm Model]
 
 
@@ -17 +17 @@
 
 '''1. Сегмент: Инвентар на билети наспроти Продажба (Ticket vs. Actual_Ticket)'''
-* '''Како и зошто:''' Моделот прави јасна разделба помеѓу ''понудата'' за билет и ''реализираната продажба''. Табелата `Ticket` ги содржи сите потенцијални седишта за еден настан. Табелата `Actual_Ticket` се пополнува само при извршена трансакција. Врската е дефинирана како '''1-на-1''' со Unique Constraint на `ticket_id` во `Actual_Ticket`.
+* '''Како и зошто:''' Моделот прави јасна разделба помеѓу ''понудата'' за билет и ''реализираната продажба''. Табелата `Ticket` ги содржи сите потенцијални седишта за еден настан. Табелата `Actual_Ticket` се пополнува само при извршена трансакција. Релацијата е дефинирана како '''1:1''' со Unique Constraint на `ticket_id` во `Actual_Ticket`.
 * '''Аргументација:''' Ова спречува најкритичен проблем во вакви системи - „double booking“ (продажба на исто седиште на повеќе лица). Дури и ако два процеси се обидат истовремено да запишат продажба, Unique клучот во базата ќе ја одбие втората трансакција.
 
 '''2. Сегмент: Динамично ценообразовање (Event_Period)'''
-* '''Како и зошто:''' Наместо фиксна цена, воведовме табела `Event_Period` поврзана со терминот на настанот (`Event_Happening`). Секој период има дефиниран процент на зголемување или намалување (`increase` бит).
+* '''Како и зошто:''' Наместо фиксна цена, воведовме табела `Event_Period` поврзана со терминот на настанот (`Event_Happening`). Секој период има дефиниран процент на зголемување или намалување (`increase` бит). Релацијата помеѓу терминот и периодите е '''1:N'''.
 * '''Аргументација:''' Ова овозможува системот автоматски да ја пресметува цената во зависност од датумот на купување (пр. Early Bird попусти или Last Minute поскапувања), без потреба од рачен `UPDATE` на цените во текот на продажбата.
 
 '''3. Сегмент: Хиерархија на локации (Venue -> Section -> Seat)'''
-* '''Како и зошто:''' Салите се моделирани хиерархиски. Секциите (`Venue_Section`) припаѓаат на сали, а индивидуалните седишта (`Venue_Section_Seat`) на секции.
+* '''Како и зошто:''' Салите се моделирани хиерархиски преку '''1:N''' релации. Секциите (`Venue_Section`) припаѓаат на сали, а индивидуалните седишта (`Venue_Section_Seat`) на секции.
 * '''Аргументација:''' Ова овозможува лесно пребарување и филтрирање на слободни места по сектори (пр. „ложа“, „партер“) и ја рефлектира реалната физичка поставеност на објектите.
 
 '''4. Сегмент: Специјализација на изведувачи (Performer Inheritance)'''
-* '''Како и зошто:''' Користена е специјализација (Inheritance) каде `Performer` е главен ентитет, а `Musical_Performer` и `Acting_Performer` се подтипови.
+* '''Како и зошто:''' Користена е специјализација (Inheritance) каде `Performer` е главен ентитет, а `Musical_Performer` и `Acting_Performer` се подтипови поврзани со релации од типот '''1:1'''.
 * '''Аргументација:''' Ова овозможува базата да биде флексибилна за различни типови настани. Музичките настани бараат податоци за жанр и дискографија, додека театарските бараат податоци за улоги и режија, а сепак сите ја делат основната структура на изведувач.
 
 '''5. Сегмент: Логика на рефундација (Actual_Ticket_Refund)'''
-* '''Како и зошто:''' Табелата за рефундација е поврзана директно со `qr_code` од продажбата со 1-на-1 врска.
+* '''Како и зошто:''' Табелата за рефундација е поврзана директно со `qr_code` од продажбата со '''1:1''' релација.
 * '''Аргументација:''' Со ова се гарантира дека само валидно продаден билет може да биде предмет на рефундација и се чува историја на вратените средства независно од оригиналната продажба, што е клучно за финансиско сметководство.