= Релационен модел =

== Релационен дијаграм

На сликата подолу е прикажан деталниот релационен модел на базата на податоци за системот EMS-AMCV, изработен во Visual Paradigm. Моделот е оптимизиран за ефикасно управување со трансакциите и висок интегритет на податоците.

[[Image(RelationalModel-ProjectCode.svg)]]

'''Прилог:'''
 * [attachment:RelationalModel-ProjectCode.vpp Visual Paradigm Model]



== Дескриптивна документација и аргументација

Во овој дел се подетално објаснети специфичните сегменти од моделот кои содржат напредна логика или решенија за специфични бизнис проблеми.

'''1. Сегмент: Животен циклус на билет и Продажба (Ticket vs. Ticket_Purchase)'''

* '''Како и зошто:''' Моделот прави јасна разделба помеѓу инвентарот на седишта (''Ticket'') и реализираната трансакција (''Ticket_Purchase''). Табелата ''Ticket'' ги содржи сите потенцијални места за еден конкретен термин (''Event_Happening''), додека ''Ticket_Purchase'' е запис за купување кој содржи уникатен ''qr_code''. Врската е дефинирана како '''1:1''' помеѓу билетот и активното купување преку ''ticket_id''.
* '''Аргументација:''' Користењето на ''ticket_id'' како примарен референтен клуч овозможува молскавично пребарување. Кога еден билет ќе се рефундира, статусот ''is_available'' во табелата ''Ticket'' се враќа во '''true''', овозможувајќи седиштето веднаш да се појави на пазарот, додека во ''Ticket_Purchase'' и ''Ticket_Refund'' се чува траен историски запис за претходната трансакција.

'''2. Сегмент: Динамично ценообразовање и фази (Event_Period)'''

* '''Како и зошто:''' Наместо фиксна цена, воведовме табела ''Event_Period'' поврзана со случувањето на настанот (''Event_Happening''). Секој период е дефиниран со ''start_date'' и ''end_date'', процент на промена и насока (''increase_decrease'': 1 - покачување, 0 - намалување).
* '''Аргументација:''' Ова овозможува системот автоматски да ги менаџира цените во зависност од времето на купување. Бидејќи релацијата оди преку едноставен ''period_id'', пресметката на финалната цена при купување е оптимизирана и не бара сложени пребарувања.

'''3. Сегмент: Хиерархија и оптимизација на локации (Venue -> Section -> Seat)'''

* '''Како и зошто:''' Локациите се моделирани преку '''Non-Identifying''' релации со користење на вештачки клучеви (''BIGSERIAL''). Секое седиште има свое уникатно ''seat_id'', кое е директно поврзано со ''section_id'', а секцијата со ''venue_id''.
* '''Аргументација:''' Оваа структура е клучна за перформансите при работа со големи податоци (20+ милиони седишта). Наместо сложени композитни клучеви, се користи само еден '''BIGINT''' за поврзување. Ова драстично го намалува просторот што го заземаат индексите и ги забрзува '''JOIN''' операциите при пребарување на слободни места во салата.

'''4. Сегмент: Специјализација на ентитети (Inheritance)'''

* '''Како и зошто:''' Користена е специјализација (''Class Hierarchy'') на два нивоа преку споделени примарни клучеви:
# '''Изведувачи:''' ''Performer'' (основа) -> ''Musical_Performer'' и ''Acting_Performer'' (подтипови).
# '''Настани:''' ''Event'' (основа) -> ''Concert'' и ''Play'' (подтипови).
* '''Аргументација:''' Ова овозможува „чист“ дизајн каде заедничките атрибути (име, контакт, опис) се чуваат на едно место, додека специфичните податоци (сетлисти, жанрови, режисери) се во посебни табели. Ова го олеснува проширувањето на системот со нови типови на настани без менување на постојната логика за билети.

'''5. Сегмент: Финансиска безбедност и рефундација (Ticket_Refund)'''

* '''Како и зошто:''' Табелата за рефундација е поврзана со трансакцијата (''Ticket_Purchase'') преку ''purchase_id'', кој во оваа табела е поставен како '''UNIQUE'''.
* '''Аргументација:''' Со ова физички се оневозможува за една иста трансакција да се изврши рефундација повеќе од еднаш. Користењето на ''BIGSERIAL'' за ''refund_id'' овозможува прецизно сметководствено следење на сите вратени средства по хронолошки редослед, што е од витално значење за ревизија на финансиското работење на системот.