= Relational Model =

== Relational diagram ==

[[Image(ERD - UPS System.jpg, width=100%)]]

== Descriptive documentation and argumentation ==

Овој релационен модел е дизајниран да поддржи комплексен систем за менаџирање со настани и продажба на билети (EventMK), со строг фокус на нормализација, релациски интегритет и користење на CHECK ограничувања за спречување на податочни аномалии.

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

* '''Модел сегмент за Актори (User, Organizer, Staff):''' Наместо една генеричка табела, корисничките улоги се нормализирани во посебни ентитети бидејќи имаат различна бизнис логика. Крајните купувачи се чуваат во `"User"` табелата со посебна поврзана зависна табела `User_verification` за следење на статусот на верификација. Организаторите се издвоени во `Organizer`, додека персоналот е во `Staff` (директно врзан за конкретен настан со специфична улога).

* '''Модел сегмент за Инфраструктура (Venue, City, Address, Parking):''' Локацијата е детално нормализирана. Градовите (`City`) и адресите (`Address`) се посебни табели поврзани со главниот објект (`Venue`). За секоја локација се води евиденција и за паркинг просторот (`Parking`), каде преку строги CHECK ограничувања се контролира максималниот капацитет и моменталната достапност.

* '''Модел сегмент за Резервации и Билети (Reservation, Payment, Ticket, Section):''' Процесот на купување е реализиран преку трансакциско заглавие `Reservation` поврзано со `Payment`. Самите билети (`Ticket`) се директно врзани за резервацијата, настанот и конкретниот сектор (`Section`) кој ја диктира цената. Секој билет е уникатен ред со `serial_number`, `qr_code` и `is_used` флег (за спречување на двоен влез). Во `Payment` табелата се имплементирани опционални надворешни клучеви кон `Discount` и `Refund`, што овозможува флексибилна финансиска евиденција.

* '''Модел сегмент за Програма (Event, Performance, Performer):''' Самата програма на настанот е хиерархиски структурирана. Настанот (`Event`) е составен од временски блокови (`Performance` со почеток и крај). Бидејќи еден изведувач (`Performer`) може да настапува на повеќе настапи, а еден настап да има повеќе изведувачи, креирана е M:N поврзувачка табела `Performer_Performance`. Дополнително, секој изведувач си ја води својата програма преку табелата `Setlist`.

* '''M:N Релации:''' Моделот вклучува и дополнителни табели за разрешување на M:N врски кои се клучни за флексибилноста на системот, како на пример `Organizer_Venue` (еден организатор менаџира повеќе локации и обратно) и `Sponsor_Event` (спонзорства на настаните).