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

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

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

Прилог:

• Visual Paradigm Model​

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

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

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

• Како и зошто: Моделот прави јасна разделба помеѓу инвентарот на билети за седишта (Ticket) и реализираната трансакција на купување преку Ticket_Order и Ticket_Order_Item. Табелата Ticket ги содржи сите потенцијални места за еден настан, додека Ticket_Order_Item е конкретна ставка од нарачката која содржи уникатен qr_code за секој купен билет.
• Аргументација: Оваа структура овозможува прецизна историја на продажба. Кога еден билет ќе се рефундира, неговиот статус во Ticket (is_available) се враќа во true (слободен) и тој може повторно да се продаде во нова нарачка, додека претходниот запис во ставките од нарачките останува како сметководствен доказ.

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

• Како и зошто: Наместо фиксна цена, воведена е посебна табела Event_Period директно поврзана со терминот на одржување (Event_Happening). Секој временски период има дефиниран опсег со start_date и end_date, како и атрибут price_discount_percent кој го одредува процентот на попуст во тој период.
• Аргументација: Ова овозможува системот автоматски да ги калкулира цените во реално време во зависност од датумот кога корисникот купува билет (на пример, „Early Bird“ со помал процент на попуст кој се зголемува како што се приближува настанот).

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

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

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

• Како и зошто: Користена е специјализација (наследување) на ниво на кориснички профили, каде User е базна табела со заедничките атрибути (username, email, password), а Admin и Regular_User се подтипови со сопствени специфични улоги и атрибути (како date_of_birth кај обичниот корисник).
• Аргументација: Ова овозможува строга безбедност и валидација на ниво на база. Администраторите и обичните корисници се автентицираат унифицирано преку базната табела, но нивните улоги и акции (како купување билети и оставање рејтинзи, кои се ексклузивни за Regular_User) се строго одвоени и заштитени. За логичка поделба на самите настани воведен е и шифрарник преку Event_Type.

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

• Како и зошто: Процесот на рефундација е поделен на Ticket_Refund (глава на рефундацијата која се врзува со целата нарачка преку order_id) и Ticket_Refund_Item (ставки кои точно покажуваат кои поединечни карти се рефундирани преку order_item_id).
• Аргументација: Со оваа грануларна логика се оневозможува системска грешка или манипулација во која за една иста ставка од нарачката (Ticket_Order_Item) парите би се вратиле повеќе од еднаш. Моделот дозволува парцијално рефундирање (на пример, корисник купува 3 карти, а враќа само 1), со што се обезбедува прецизен финансиски и сметководствен биланс.