Changes between Version 1 and Version 2 of RelationalModel

Timestamp:

04/18/26 20:11:39 (2 weeks ago)

Author:

231215

Comment:

--

RelationalModel

@@ -7 +7 @@
 == Descriptive documentation and argumentation ==
 
-Овој релационен модел е дизајниран да поддржи систем за менаџирање со настани и продажба на билети (EventMK), со фокус на релацискиот интегритет и спречување на аномалии при процесот на резервација и купување.
+Овој релационен модел е дизајниран да поддржи комплексен систем за менаџирање со настани и продажба на билети (EventMK), со строг фокус на нормализација, релациски интегритет и користење на CHECK ограничувања за спречување на податочни аномалии.
 
-* **Модел сегмент за Корисници и Улоги (Users & Roles):** За да се избегне редундантност и креирање на повеќе табели за различен тип на корисници (Админ, Организатор, Купувач), моделирана е една централна табела `Users`. Правата на пристап и бизнис логиката се регулирани преку поврзување со табела `Roles` (1:N или M:N релација, зависно од потребата еден корисник да има повеќе улоги), што овозможува лесна скалабилност на системот.
+Во продолжение се образложени специфичните логички сегменти од моделот:
 
-* **Модел сегмент за Настани и Локации (Events, Venues & Sectors):** Еден објект (`Venues`) може да биде домаќин на повеќе настани. За да се овозможи флексибилна продажба на билети, локациите се дополнително поделени на сектори (табела `Sectors`, на пр. Партер, Трибина, VIP). Настанот (`Events`) е поврзан со конкретната локација, а капацитетот се менаџира преку достапните сектори.
+* '''Модел сегмент за Актори (User, Organizer, Staff):''' Наместо една генеричка табела, корисничките улоги се нормализирани во посебни ентитети бидејќи имаат различна бизнис логика. Крајните купувачи се чуваат во `"User"` табелата со посебна поврзана зависна табела `User_verification` за следење на статусот на верификација. Организаторите се издвоени во `Organizer`, додека персоналот е во `Staff` (директно врзан за конкретен настан со специфична улога).
 
-* **Модел сегмент за Билети (TicketCategories & Tickets):** Направена е строга поделба помеѓу дефиницијата на билетот (табела `TicketCategories` - дефинира цена и вкупен капацитет за даден сектор за конкретен настан) и самиот генериран билет (табела `Tickets` или `TicketInstances`). Секој купен билет е посебен запис (ред) со уникатен идентификатор (QR/баркод), што е неопходно за физичка валидација на влезот.
+* '''Модел сегмент за Инфраструктура (Venue, City, Address, Parking):''' Локацијата е детално нормализирана. Градовите (`City`) и адресите (`Address`) се посебни табели поврзани со главниот објект (`Venue`). За секоја локација се води евиденција и за паркинг просторот (`Parking`), каде преку строги CHECK ограничувања се контролира максималниот капацитет и моменталната достапност.
 
-* **Модел сегмент за Нарачки (Orders & OrderItems):** Процесот на трансакција е моделиран преку `Orders` (заглавие на нарачката со вкупна сума, датум и поврзаност со купувачот) и `OrderItems` (детали за секој поединечен билет купен во рамки на таа трансакција). Оваа нормализирана структура овозможува купување на повеќе различни билети во една иста трансакција и ја подготвува основата за пишување на тригери (во Фаза 4) кои ќе го намалуваат преостанатиот капацитет при секоја успешна нарачка.
+* '''Модел сегмент за Резервации и Билети (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` (спонзорства на настаните).