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

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

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

Прилог:

• 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 овозможува прецизно сметководствено следење на сите вратени средства по хронолошки редослед, што е од витално значење за ревизија на финансиското работење на системот.