| 20 | | * '''Како и зошто:''' Моделот прави јасна разделба помеѓу инвентарот на седишта (`Ticket`) и реализираната трансакција (`Ticket_Purchase`). Табелата `Ticket` ги содржи сите потенцијални места за еден настан, додека `Ticket_Purchase` е запис за купување кој содржи уникатен `qr_code`. Релацијата е дефинирана како '''1:N''' помеѓу билетот и купувањата. |
| 21 | | * '''Аргументација:''' Оваа структура овозможува '''повторна продажба на исто седиште'''. Кога еден билет ќе се рефундира, неговиот статус се враќа во „слободен“, а во `Ticket_Purchase` се дозволува нов запис за следниот купувач. Со тоа се чува целосна историја на сопственост врз едно седиште низ времето. |
| | 20 | * '''Како и зошто:''' Моделот прави јасна разделба помеѓу инвентарот на билети за седишта (`Ticket`) и реализираната трансакција на купување преку `Ticket_Order` и `Ticket_Order_Item`. Табелата `Ticket` ги содржи сите потенцијални места за еден настан, додека `Ticket_Order_Item` е конкретна ставка од нарачката која содржи уникатен `qr_code` за секој купен билет. |
| | 21 | * '''Аргументација:''' Оваа структура овозможува прецизна историја на продажба. Кога еден билет ќе се рефундира, неговиот статус во `Ticket` (`is_available`) се враќа во '''true''' (слободен) и тој може повторно да се продаде во нова нарачка, додека претходниот запис во ставките од нарачките останува како сметководствен доказ. |
| 25 | | * '''Како и зошто:''' Наместо фиксна цена, воведовме табела `Event_Period` поврзана со случувањето на настанот (`Event_Happening`). Секој период има дефиниран процент на промена и насока (`increase_decrease`: `true` - покачување на цените за тој процент, `false` - намалување на цените за тој процент). |
| 26 | | * '''Аргументација:''' Ова овозможува системот автоматски да ги менаџира цените во зависност од временските периоди (пр. "Early Bird" попусти или "Last Minute" поскапувања). |
| | 25 | * '''Како и зошто:''' Наместо фиксна цена, воведена е посебна табела `Event_Period` директно поврзана со терминот на одржување (`Event_Happening`). Секој временски период има дефиниран опсег со `start_date` и `end_date`, како и атрибут `price_discount_percent` кој го одредува процентот на попуст во тој период. |
| | 26 | * '''Аргументација:''' Ова овозможува системот автоматски да ги калкулира цените во реално време во зависност од датумот кога корисникот купува билет (на пример, „Early Bird“ со помал процент на попуст кој се зголемува како што се приближува настанот). |
| 30 | | * '''Како и зошто:''' Локациите се моделирани хиерархиски преку '''Non-Identifying''' релации со користење на вештачки клучеви. Наместо секое седиште да носи композитен клуч од својата секција и сала, тоа е дефинирано преку уникатно, независно `seat_id`, кое преку надворешен клуч е поврзано со `section_id`. |
| 31 | | * '''Аргументација:''' Оваа структура е екстремно оптимизирана за работа со големи количини податоци. Со елиминирање на композитните клучеви, драстично се намалува комплексноста и големината на индексите во базата. Ова ќе овозможи брзи '''JOIN''' операции и заштеда на мемориски ресурси, додека интегритетот и физичката локација се гарантираат преку едноставни и брзи референци помеѓу табелите. |
| | 30 | * '''Како и зошто:''' Локациите се моделирани хиерархиски преку Non-Identifying релации со користење на вештачки клучеви. Секое седиште има уникатно `seat_id` и преку надворешен клуч е поврзано со `section_id`, кое пак на ист начин референцира кон `venue_id`. |
| | 31 | * '''Аргументација:''' Оваа структура е оптимизирана за работа со големи количини на податоци. Со елиминирање на комплексни композитни клучеви се намалува големината на индексите на диск, се забрзуваат '''JOIN''' операциите и се штедат мемориски ресурси, додека интегритетот на физичката локација е целосно загарантиран. |
| 35 | | * '''Како и зошто:''' Користена е специјализација на два нивоа: |
| 36 | | 1. '''Изведувачи:''' `Performer` како основна табела, со `Musical_Performer` и `Acting_Performer` како подтипови. |
| 37 | | 2. '''Настани:''' `Event` како основна табела, со `Concert` и `Play` како подтипови. |
| 38 | | * '''Аргументација:''' Ова овозможува базата да биде екстремно флексибилна. Музичките изведувачи имаат жанр и издавачка куќа, додека театарските имаат улоги и агенции, а сепак сите се менаџираат унифицирано преку главната табела на изведувачи. Истата логика овозможува системот за билети да работи идентично за концерти и за претстави. |
| | 35 | * '''Како и зошто:''' Користена е специјализација (наследување) на ниво на кориснички профили, каде `User` е базна табела со заедничките атрибути (`username`, `email`, `password`), а `Admin` и `Regular_User` се подтипови со сопствени специфични улоги и атрибути (како `date_of_birth` кај обичниот корисник). |
| | 36 | * '''Аргументација:''' Ова овозможува строга безбедност и валидација на ниво на база. Администраторите и обичните корисници се автентицираат унифицирано преку базната табела, но нивните улоги и акции (како купување билети и оставање рејтинзи, кои се ексклузивни за `Regular_User`) се строго одвоени и заштитени. За логичка поделба на самите настани воведен е и шифрарник преку `Event_Type`. |
| 42 | | * '''Како и зошто:''' Табелата за рефундација е поврзана со трансакцијата (`Ticket_Purchase`) преку `purchase_id`. |
| 43 | | * '''Аргументација:''' Со оваа логика физички се оневозможува за една иста трансакција (купување) да се вратат парите повеќе од еднаш. Ова е клучна заштита против финансиски манипулации или системски грешки, обезбедувајќи прецизно сметководствено следење на вратените средства. |
| | 40 | * '''Како и зошто:''' Процесот на рефундација е поделен на `Ticket_Refund` (глава на рефундацијата која се врзува со целата нарачка преку `order_id`) и `Ticket_Refund_Item` (ставки кои точно покажуваат кои поединечни карти се рефундирани преку `order_item_id`). |
| | 41 | * '''Аргументација:''' Со оваа грануларна логика се оневозможува системска грешка или манипулација во која за една иста ставка од нарачката (`Ticket_Order_Item`) парите би се вратиле повеќе од еднаш. Моделот дозволува парцијално рефундирање (на пример, корисник купува 3 карти, а враќа само 1), со што се обезбедува прецизен финансиски и сметководствен биланс. |
