| 20 | | * '''Како и зошто:''' Моделот прави јасна разделба помеѓу инвентарот на седишта (`Ticket`) и реализираната трансакција (`Ticket_Purchase`). Табелата `Ticket` ги содржи сите потенцијални места за еден настан, додека `Ticket_Purchase` е запис за купување кој содржи уникатен `qr_code`. Релацијата е дефинирана како '''1:N''' помеѓу билетот и купувањата. |
| 21 | | * '''Аргументација:''' Оваа структура овозможува '''повторна продажба на исто седиште'''. Кога еден билет ќе се рефундира, неговиот статус се враќа во „слободен“, а во `Ticket_Purchase` се дозволува нов запис за следниот купувач. Со тоа се чува целосна историја на сопственост врз едно седиште низ времето. |
| | 20 | * '''Како и зошто:''' Моделот прави јасна разделба помеѓу инвентарот на седишта (''Ticket'') и реализираната трансакција (''Ticket_Purchase''). Табелата ''Ticket'' ги содржи сите потенцијални места за еден конкретен термин (''Event_Happening''), додека ''Ticket_Purchase'' е запис за купување кој содржи уникатен ''qr_code''. Врската е дефинирана како '''1:1''' помеѓу билетот и активното купување преку ''ticket_id''. |
| | 21 | * '''Аргументација:''' Користењето на ''ticket_id'' како примарен референтен клуч овозможува молскавично пребарување. Кога еден билет ќе се рефундира, статусот ''is_available'' во табелата ''Ticket'' се враќа во '''true''', овозможувајќи седиштето веднаш да се појави на пазарот, додека во ''Ticket_Purchase'' и ''Ticket_Refund'' се чува траен историски запис за претходната трансакција. |
| 25 | | * '''Како и зошто:''' Наместо фиксна цена, воведовме табела `Event_Period` поврзана со случувањето на настанот (`Event_Happening`). Секој период има дефиниран процент на промена и насока (`increase_decrease`: 1 - покачување на цените за тој процент, 0 - намалување на цените за тој процент). |
| 26 | | * '''Аргументација:''' Ова овозможува системот автоматски да ги менаџира цените во зависност од временските периоди (пр. "Early Bird" попусти или "Last Minute" поскапувања). |
| | 25 | * '''Како и зошто:''' Наместо фиксна цена, воведовме табела ''Event_Period'' поврзана со случувањето на настанот (''Event_Happening''). Секој период е дефиниран со ''start_date'' и ''end_date'', процент на промена и насока (''increase_decrease'': 1 - покачување, 0 - намалување). |
| | 26 | * '''Аргументација:''' Ова овозможува системот автоматски да ги менаџира цените во зависност од времето на купување. Бидејќи релацијата оди преку едноставен ''period_id'', пресметката на финалната цена при купување е оптимизирана и не бара сложени пребарувања. |
| 30 | | * '''Како и зошто:''' Локациите се моделирани хиерархиски преку '''Identifying''' релации. Секое седиште е дефинирано преку композитен клуч кој ги вклучува неговата секција и сала. |
| 31 | | * '''Аргументација:''' Ова ја рефлектира реалната физичка поставеност на објектите и спречува дуплирање на сектори или седишта. Со ова се гарантира дека секој билет е врзан за прецизна и уникатна физичка локација во салата. |
| | 30 | * '''Како и зошто:''' Локациите се моделирани преку '''Non-Identifying''' релации со користење на вештачки клучеви (''BIGSERIAL''). Секое седиште има свое уникатно ''seat_id'', кое е директно поврзано со ''section_id'', а секцијата со ''venue_id''. |
| | 31 | * '''Аргументација:''' Оваа структура е клучна за перформансите при работа со големи податоци (20+ милиони седишта). Наместо сложени композитни клучеви, се користи само еден '''BIGINT''' за поврзување. Ова драстично го намалува просторот што го заземаат индексите и ги забрзува '''JOIN''' операциите при пребарување на слободни места во салата. |
| 35 | | * '''Како и зошто:''' Користена е специјализација на два нивоа: |
| 36 | | 1. '''Изведувачи:''' `Performer` како основна табела, со `Musical_Performer` и `Acting_Performer` како подтипови. |
| 37 | | 2. '''Настани:''' `Event` како основна табела, со `Concert` и `Play` како подтипови. |
| 38 | | * '''Аргументација:''' Ова овозможува базата да биде екстремно флексибилна. Музичките изведувачи имаат жанр и издавачка куќа, додека театарските имаат улоги и агенции, а сепак сите се менаџираат унифицирано преку главната табела на изведувачи. Истата логика овозможува системот за билети да работи идентично за концерти и за претстави. |
| | 35 | * '''Како и зошто:''' Користена е специјализација (''Class Hierarchy'') на два нивоа преку споделени примарни клучеви: |
| | 36 | # '''Изведувачи:''' ''Performer'' (основа) -> ''Musical_Performer'' и ''Acting_Performer'' (подтипови). |
| | 37 | # '''Настани:''' ''Event'' (основа) -> ''Concert'' и ''Play'' (подтипови). |
| | 38 | * '''Аргументација:''' Ова овозможува „чист“ дизајн каде заедничките атрибути (име, контакт, опис) се чуваат на едно место, додека специфичните податоци (сетлисти, жанрови, режисери) се во посебни табели. Ова го олеснува проширувањето на системот со нови типови на настани без менување на постојната логика за билети. |
