Relational Model: EMS-AMCV

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

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

Атачменти:

• Visual Paradigm Model File

---

Опис на моделирањето и аргументација

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

1. Сегмент: Инвентар на билети наспроти Продажба (Ticket vs. Actual_Ticket)

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

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

• Како и зошто: Наместо фиксна цена, воведовме табела Event_Period поврзана со терминот на настанот (Event_Happening). Секој период има дефиниран процент на зголемување или намалување (increase бит).
• Аргументација: Ова овозможува системот автоматски да ја пресметува цената во зависност од датумот на купување (пр. Early Bird попусти или Last Minute поскапувања), без потреба од рачен UPDATE на цените во текот на продажбата.

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

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

4. Сегмент: Специјализација на изведувачи (Performer Inheritance)

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

5. Сегмент: Логика на рефундација (Actual_Ticket_Refund)

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