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

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

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

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

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

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

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

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

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