| 3 | | [[Image("EMS-AMCV - ERD.jpg", 1400px)]] |
| | 3 | == Релационен дијаграм |
| | 4 | |
| | 5 | На сликата подолу е прикажан деталниот релационен модел на базата на податоци за системот EMS-AMCV, изработен во Visual Paradigm. Моделот е оптимизиран за ефикасно управување со трансакциите и висок интегритет на податоците. |
| | 6 | |
| | 7 | [[Image(RelationalModel-EMS-AMCV.svg)]] |
| | 8 | |
| | 9 | '''Атачменти:''' |
| | 10 | * [attachment:RelationalModel-EMS-AMCV.vpp Visual Paradigm Model File] |
| | 11 | |
| | 12 | --- |
| | 13 | |
| | 14 | == Опис на моделирањето и аргументација |
| | 15 | |
| | 16 | Во овој дел се подетално објаснети специфичните сегменти од моделот кои содржат напредна логика или решенија за специфични бизнис проблеми. |
| | 17 | |
| | 18 | '''1. Сегмент: Инвентар на билети наспроти Продажба (Ticket vs. Actual_Ticket)''' |
| | 19 | * '''Како и зошто:''' Моделот прави јасна разделба помеѓу ''понудата'' за билет и ''реализираната продажба''. Табелата `Ticket` ги содржи сите потенцијални седишта за еден настан. Табелата `Actual_Ticket` се пополнува само при извршена трансакција. Врската е дефинирана како '''1-на-1''' со Unique Constraint на `ticket_id` во `Actual_Ticket`. |
| | 20 | * '''Аргументација:''' Ова спречува најкритичен проблем во вакви системи — „double booking“ (продажба на исто седиште на повеќе лица). Дури и ако два процеси се обидат истовремено да запишат продажба, Unique клучот во базата ќе ја одбие втората трансакција. |
| | 21 | |
| | 22 | '''2. Сегмент: Динамично ценообразовање (Event_Period)''' |
| | 23 | * '''Како и зошто:''' Наместо фиксна цена, воведовме табела `Event_Period` поврзана со терминот на настанот (`Event_Happening`). Секој период има дефиниран процент на зголемување или намалување (`increase` бит). |
| | 24 | * '''Аргументација:''' Ова овозможува системот автоматски да ја пресметува цената во зависност од датумот на купување (пр. Early Bird попусти или Last Minute поскапувања), без потреба од рачен `UPDATE` на цените во текот на продажбата. |
| | 25 | |
| | 26 | '''3. Сегмент: Хиерархија на локации (Venue -> Section -> Seat)''' |
| | 27 | * '''Како и зошто:''' Салите се моделирани хиерархиски. Секциите (`Venue_Section`) припаѓаат на сали, а индивидуалните седишта (`Venue_Section_Seat`) на секции. |
| | 28 | * '''Аргументација:''' Ова овозможува лесно пребарување и филтрирање на слободни места по сектори (пр. „ложа“, „партер“) и ја рефлектира реалната физичка поставеност на објектите. |
| | 29 | |
| | 30 | '''4. Сегмент: Специјализација на изведувачи (Performer Inheritance)''' |
| | 31 | * '''Како и зошто:''' Користена е специјализација (Inheritance) каде `Performer` е главен ентитет, а `Musical_Performer` и `Acting_Performer` се подтипови. |
| | 32 | * '''Аргументација:''' Ова овозможува базата да биде флексибилна за различни типови настани. Музичките настани бараат податоци за жанр и дискографија, додека театарските бараат податоци за улоги и режија, а сепак сите ја делат основната структура на изведувач. |
| | 33 | |
| | 34 | '''5. Сегмент: Логика на рефундација (Actual_Ticket_Refund)''' |
| | 35 | * '''Како и зошто:''' Табелата за рефундација е поврзана директно со `qr_code` од продажбата со 1-на-1 врска. |
| | 36 | * '''Аргументација:''' Со ова се гарантира дека само валидно продаден билет може да биде предмет на рефундација и се чува историја на вратените средства независно од оригиналната продажба, што е клучно за финансиско сметководство. |
