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

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

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

Прилог:

• Visual Paradigm Model​

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

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

1. Segment: Ticket Inventory vs. Sales (Ticket vs. Actual_Ticket)

• How and Why: Моделот прави јасна разделба помеѓу понудата за билет и реализираната продажба. Табелата Ticket ги содржи сите потенцијални седишта за еден настан. Табелата Actual_Ticket се пополнува само при извршена трансакција. Релацијата е дефинирана како 1:1 со Unique Constraint на ticket_id во Actual_Ticket.
• Argumentation: Ова спречува најкритичен проблем во вакви системи - „double booking“ (продажба на исто седиште на повеќе лица). Дури и ако два процеси се обидат истовремено да запишат продажба, Unique клучот во базата ќе ја одбие втората трансакција.

2. Segment: Dynamic Pricing (Event_Period)

• How and Why: Наместо фиксна цена, воведовме табела Event_Period поврзана со терминот на настанот (Event_Happening). Секој период има дефиниран процент на зголемување или намалување (increase бит). Релацијата помеѓу терминот и периодите е 1:N.
• Argumentation: Ова овозможува системот автоматски да ја пресметува цената во зависност од датумот на купување (пр. Early Bird попусти или Last Minute поскапувања), без потреба од рачен UPDATE на цените во текот на продажбата.

3. Segment: Venue Hierarchy (Venue -> Section -> Seat)

• How and Why: Салите се моделирани хиерархиски преку 1:N релации. Секциите (Venue_Section) припаѓаат на сали, а индивидуалните седишта (Venue_Section_Seat) на секции.
• Argumentation: Ова овозможува лесно пребарување и филтрирање на слободни места по сектори (пр. „ложа“, „партер“) и ја рефлектира реалната физичка поставеност на објектите.

4. Segment: Performer Specialization (Inheritance)

• How and Why: Користена е специјализација (Inheritance) каде Performer е главен ентитет, а Musical_Performer и Acting_Performer се подтипови поврзани со релации од типот 1:1.
• Argumentation: Ова овозможува базата да биде флексибилна за различни типови настани. Музичките настани бараат податоци за жанр и дискографија, додека театарските бараат податоци за улоги и режија, а сепак сите ја делат основната структура на изведувач.

5. Segment: Refund Logic (Actual_Ticket_Refund)

• How and Why: Табелата за рефундација е поврзана директно со qr_code од продажбата со 1:1 релација.
• Argumentation: Со ова се гарантира дека само валидно продаден билет може да биде предмет на рефундација и се чува историја на вратените средства независно од оригиналната продажба, што е клучно за финансиско сметководство.