| 19 | | * '''How and Why:''' Моделот прави јасна разделба помеѓу ''понудата'' за билет и ''реализираната продажба''. Табелата `Ticket` ги содржи сите потенцијални седишта за еден настан. Табелата `Actual_Ticket` се пополнува само при извршена трансакција. Релацијата е дефинирана како '''1:1''' со Unique Constraint на `ticket_id` во `Actual_Ticket`. |
| 20 | | * '''Argumentation:''' Ова спречува најкритичен проблем во вакви системи - „double booking“ (продажба на исто седиште на повеќе лица). Дури и ако два процеси се обидат истовремено да запишат продажба, Unique клучот во базата ќе ја одбие втората трансакција. |
| | 19 | * '''Како и зошто:''' Моделот прави јасна разделба помеѓу ''понудата'' за билет и ''реализираната продажба''. Табелата `Ticket` ги содржи сите потенцијални седишта за еден настан. Табелата `Actual_Ticket` се пополнува само при извршена трансакција. Релацијата е дефинирана како '''1:1''' со Unique Constraint на `ticket_id` во `Actual_Ticket`. |
| | 20 | * '''Аргументација:''' Ова спречува најкритичен проблем во вакви системи - „double booking“ (продажба на исто седиште на повеќе лица). Дури и ако два процеси се обидат истовремено да запишат продажба, Unique клучот во базата ќе ја одбие втората трансакција. |
| 23 | | * '''How and Why:''' Наместо фиксна цена, воведовме табела `Event_Period` поврзана со терминот на настанот (`Event_Happening`). Секој период има дефиниран процент на зголемување или намалување (`increase` бит). Релацијата помеѓу терминот и периодите е '''1:N'''. |
| 24 | | * '''Argumentation:''' Ова овозможува системот автоматски да ја пресметува цената во зависност од датумот на купување (пр. Early Bird попусти или Last Minute поскапувања), без потреба од рачен `UPDATE` на цените во текот на продажбата. |
| | 23 | * '''Како и зошто:''' Наместо фиксна цена, воведовме табела `Event_Period` поврзана со терминот на настанот (`Event_Happening`). Секој период има дефиниран процент на зголемување или намалување (`increase` бит). Релацијата помеѓу терминот и периодите е '''1:N'''. |
| | 24 | * '''Аргументација:''' Ова овозможува системот автоматски да ја пресметува цената во зависност од датумот на купување (пр. Early Bird попусти или Last Minute поскапувања), без потреба од рачен `UPDATE` на цените во текот на продажбата. |
| 27 | | * '''How and Why:''' Салите се моделирани хиерархиски преку '''1:N''' релации. Секциите (`Venue_Section`) припаѓаат на сали, а индивидуалните седишта (`Venue_Section_Seat`) на секции. |
| 28 | | * '''Argumentation:''' Ова овозможува лесно пребарување и филтрирање на слободни места по сектори (пр. „ложа“, „партер“) и ја рефлектира реалната физичка поставеност на објектите. |
| | 27 | * '''Како и зошто:''' Салите се моделирани хиерархиски преку '''1:N''' релации. Секциите (`Venue_Section`) припаѓаат на сали, а индивидуалните седишта (`Venue_Section_Seat`) на секции. |
| | 28 | * '''Аргументација:''' Ова овозможува лесно пребарување и филтрирање на слободни места по сектори (пр. '''VIP Box''', '''Parterre''', '''Balcony''') и ја рефлектира реалната физичка поставеност на објектите. |
| 31 | | * '''How and Why:''' Користена е специјализација (Inheritance) каде `Performer` е главен ентитет, а `Musical_Performer` и `Acting_Performer` се подтипови поврзани со релации од типот '''1:1'''. |
| 32 | | * '''Argumentation:''' Ова овозможува базата да биде флексибилна за различни типови настани. Музичките настани бараат податоци за жанр и дискографија, додека театарските бараат податоци за улоги и режија, а сепак сите ја делат основната структура на изведувач. |
| | 31 | * '''Како и зошто:''' Користена е специјализација (Inheritance) каде `Performer` е главен ентитет, а `Musical_Performer` и `Acting_Performer` се подтипови поврзани со релации од типот '''1:1'''. |
| | 32 | * '''Аргументација:''' Ова овозможува базата да биде флексибилна за различни типови настани. Музичките настани бараат податоци за жанр и дискографија, додека театарските бараат податоци за улоги и режија, а сепак сите ја делат основната структура на изведувач. |
