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

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

На сликата подолу е прикажан деталниот релационен модел на базата на податоци за системот 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: 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.
• Аргументација: Со оваа логика физички се оневозможува за една иста трансакција (купување) да се вратат парите повеќе од еднаш. Ова е клучна заштита против финансиски манипулации или системски грешки, обезбедувајќи прецизно сметководствено следење на вратените средства.