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

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

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

Прилог:

• 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: 1 - покачување на цените за тој процент, 0 - намалување на цените за тој процент).
• Аргументација: Ова овозможува системот автоматски да ги менаџира цените во зависност од временските периоди (пр. "Early Bird" попусти или "Last Minute" поскапувања).

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

• Како и зошто: Локациите се моделирани хиерархиски преку Identifying релации. Секое седиште е дефинирано преку композитен клуч кој ги вклучува неговата секција и сала.
• Аргументација: Ова ја рефлектира реалната физичка поставеност на објектите и спречува дуплирање на сектори или седишта. Со ова се гарантира дека секој билет е врзан за прецизна и уникатна физичка локација во салата.

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

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

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

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