| 18 | | '''1. Сегмент: Инвентар на билети наспроти Продажба (Ticket vs. Actual_Ticket)''' |
| 19 | | * '''Како и зошто:''' Моделот прави јасна разделба помеѓу ''понудата'' за билет и ''реализираната продажба''. Табелата `Ticket` ги содржи сите потенцијални седишта за еден настан. Табелата `Actual_Ticket` се пополнува само при извршена трансакција. Релацијата е дефинирана како '''1:1''' со Unique Constraint на `ticket_id` во `Actual_Ticket`. |
| 20 | | * '''Аргументација:''' Ова спречува најкритичен проблем во вакви системи - „double booking“ (продажба на исто седиште на повеќе лица). Дури и ако два процеси се обидат истовремено да запишат продажба, Unique клучот во базата ќе ја одбие втората трансакција. |
| | 18 | '''1. Segment: Ticket Inventory vs. Sales (Ticket vs. Actual_Ticket)''' |
| | 19 | * '''How and Why:''' Моделот прави јасна разделба помеѓу ''понудата'' за билет и ''реализираната продажба''. Табелата `Ticket` ги содржи сите потенцијални седишта за еден настан. Табелата `Actual_Ticket` се пополнува само при извршена трансакција. Релацијата е дефинирана како '''1:1''' со Unique Constraint на `ticket_id` во `Actual_Ticket`. |
| | 20 | * '''Argumentation:''' Ова спречува најкритичен проблем во вакви системи - „double booking“ (продажба на исто седиште на повеќе лица). Дури и ако два процеси се обидат истовремено да запишат продажба, Unique клучот во базата ќе ја одбие втората трансакција. |
| 22 | | '''2. Сегмент: Динамично ценообразовање (Event_Period)''' |
| 23 | | * '''Како и зошто:''' Наместо фиксна цена, воведовме табела `Event_Period` поврзана со терминот на настанот (`Event_Happening`). Секој период има дефиниран процент на зголемување или намалување (`increase` бит). Релацијата помеѓу терминот и периодите е '''1:N'''. |
| 24 | | * '''Аргументација:''' Ова овозможува системот автоматски да ја пресметува цената во зависност од датумот на купување (пр. Early Bird попусти или Last Minute поскапувања), без потреба од рачен `UPDATE` на цените во текот на продажбата. |
| | 22 | '''2. Segment: Dynamic Pricing (Event_Period)''' |
| | 23 | * '''How and Why:''' Наместо фиксна цена, воведовме табела `Event_Period` поврзана со терминот на настанот (`Event_Happening`). Секој период има дефиниран процент на зголемување или намалување (`increase` бит). Релацијата помеѓу терминот и периодите е '''1:N'''. |
| | 24 | * '''Argumentation:''' Ова овозможува системот автоматски да ја пресметува цената во зависност од датумот на купување (пр. Early Bird попусти или Last Minute поскапувања), без потреба од рачен `UPDATE` на цените во текот на продажбата. |
| 26 | | '''3. Сегмент: Хиерархија на локации (Venue -> Section -> Seat)''' |
| 27 | | * '''Како и зошто:''' Салите се моделирани хиерархиски преку '''1:N''' релации. Секциите (`Venue_Section`) припаѓаат на сали, а индивидуалните седишта (`Venue_Section_Seat`) на секции. |
| 28 | | * '''Аргументација:''' Ова овозможува лесно пребарување и филтрирање на слободни места по сектори (пр. „ложа“, „партер“) и ја рефлектира реалната физичка поставеност на објектите. |
| | 26 | '''3. Segment: Venue Hierarchy (Venue -> Section -> Seat)''' |
| | 27 | * '''How and Why:''' Салите се моделирани хиерархиски преку '''1:N''' релации. Секциите (`Venue_Section`) припаѓаат на сали, а индивидуалните седишта (`Venue_Section_Seat`) на секции. |
| | 28 | * '''Argumentation:''' Ова овозможува лесно пребарување и филтрирање на слободни места по сектори (пр. „ложа“, „партер“) и ја рефлектира реалната физичка поставеност на објектите. |
| 30 | | '''4. Сегмент: Специјализација на изведувачи (Performer Inheritance)''' |
| 31 | | * '''Како и зошто:''' Користена е специјализација (Inheritance) каде `Performer` е главен ентитет, а `Musical_Performer` и `Acting_Performer` се подтипови поврзани со релации од типот '''1:1'''. |
| 32 | | * '''Аргументација:''' Ова овозможува базата да биде флексибилна за различни типови настани. Музичките настани бараат податоци за жанр и дискографија, додека театарските бараат податоци за улоги и режија, а сепак сите ја делат основната структура на изведувач. |
| | 30 | '''4. Segment: Performer Specialization (Inheritance)''' |
| | 31 | * '''How and Why:''' Користена е специјализација (Inheritance) каде `Performer` е главен ентитет, а `Musical_Performer` и `Acting_Performer` се подтипови поврзани со релации од типот '''1:1'''. |
| | 32 | * '''Argumentation:''' Ова овозможува базата да биде флексибилна за различни типови настани. Музичките настани бараат податоци за жанр и дискографија, додека театарските бараат податоци за улоги и режија, а сепак сите ја делат основната структура на изведувач. |
| 34 | | '''5. Сегмент: Логика на рефундација (Actual_Ticket_Refund)''' |
| 35 | | * '''Како и зошто:''' Табелата за рефундација е поврзана директно со `qr_code` од продажбата со '''1:1''' релација. |
| 36 | | * '''Аргументација:''' Со ова се гарантира дека само валидно продаден билет може да биде предмет на рефундација и се чува историја на вратените средства независно од оригиналната продажба, што е клучно за финансиско сметководство. |
| | 34 | '''5. Segment: Refund Logic (Actual_Ticket_Refund)''' |
| | 35 | * '''How and Why:''' Табелата за рефундација е поврзана директно со `qr_code` од продажбата со '''1:1''' релација. |
| | 36 | * '''Argumentation:''' Со ова се гарантира дека само валидно продаден билет може да биде предмет на рефундација и се чува историја на вратените средства независно од оригиналната продажба, што е клучно за финансиско сметководство. |
