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

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

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

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

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



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

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

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

 * '''Како и зошто:''' Моделот прави јасна разделба помеѓу инвентарот на седишта (`Ticket`) и реализираната трансакција (`Ticket_Purchase`). Табелата `Ticket` ги содржи сите потенцијални места за еден настан, додека `Ticket_Purchase` е запис за купување кој содржи уникатен `qr_code`. Релацијата е дефинирана како '''1:N''' помеѓу билетот и купувањата.
 * '''Аргументација:''' Оваа структура овозможува '''повторна продажба на исто седиште'''. Кога еден билет ќе се рефундира, неговиот статус се враќа во „слободен“, а во `Ticket_Purchase` се дозволува нов запис за следниот купувач. Со тоа се чува целосна историја на сопственост врз едно седиште низ времето.

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

 * '''Како и зошто:''' Наместо фиксна цена, воведовме табела `Event_Period` поврзана со случувањето на настанот (`Event_Happening`). Секој период има дефиниран процент на промена и насока (`increase_decrease`: `true` - покачување на цените за тој процент, `false` - намалување на цените за тој процент).
 * '''Аргументација:''' Ова овозможува системот автоматски да ги менаџира цените во зависност од временските периоди (пр. "Early Bird" попусти или "Last Minute" поскапувања).

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

 * '''Како и зошто:''' Локациите се моделирани хиерархиски преку '''Non-Identifying''' релации со користење на вештачки клучеви. Наместо секое седиште да носи композитен клуч од својата секција и сала, тоа е дефинирано преку уникатно, независно `seat_id`, кое преку надворешен клуч е поврзано со `section_id`.
 * '''Аргументација:''' Оваа структура е екстремно оптимизирана за работа со големи количини податоци. Со елиминирање на композитните клучеви, драстично се намалува комплексноста и големината на индексите во базата. Ова ќе овозможи брзи '''JOIN''' операции и заштеда на мемориски ресурси, додека интегритетот и физичката локација се гарантираат преку едноставни и брзи референци помеѓу табелите.

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

 * '''Како и зошто:''' Користена е специјализација на два нивоа:
  1. '''Изведувачи:''' `Performer` како основна табела, со `Musical_Performer` и `Acting_Performer` како подтипови.
  2. '''Настани:''' `Event` како основна табела, со `Concert` и `Play` како подтипови.
 * '''Аргументација:''' Ова овозможува базата да биде екстремно флексибилна. Музичките изведувачи имаат жанр и издавачка куќа, додека театарските имаат улоги и агенции, а сепак сите се менаџираат унифицирано преку главната табела на изведувачи. Истата логика овозможува системот за билети да работи идентично за концерти и за претстави.

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

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