Changes between Initial Version and Version 1 of RelationalModel


Ignore:
Timestamp:
04/18/26 19:44:35 (2 weeks ago)
Author:
231215
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • RelationalModel

    v1 v1  
     1= Relational Model =
     2
     3== Relational diagram ==
     4
     5[[Image(RelationalModel.jpg)]]
     6
     7== Descriptive documentation and argumentation ==
     8
     9Овој релационен модел е дизајниран да поддржи систем за менаџирање со настани и продажба на билети (EventMK), со фокус на релацискиот интегритет и спречување на аномалии при процесот на резервација и купување.
     10
     11* **Модел сегмент за Корисници и Улоги (Users & Roles):** За да се избегне редундантност и креирање на повеќе табели за различен тип на корисници (Админ, Организатор, Купувач), моделирана е една централна табела `Users`. Правата на пристап и бизнис логиката се регулирани преку поврзување со табела `Roles` (1:N или M:N релација, зависно од потребата еден корисник да има повеќе улоги), што овозможува лесна скалабилност на системот.
     12
     13* **Модел сегмент за Настани и Локации (Events, Venues & Sectors):** Еден објект (`Venues`) може да биде домаќин на повеќе настани. За да се овозможи флексибилна продажба на билети, локациите се дополнително поделени на сектори (табела `Sectors`, на пр. Партер, Трибина, VIP). Настанот (`Events`) е поврзан со конкретната локација, а капацитетот се менаџира преку достапните сектори.
     14
     15* **Модел сегмент за Билети (TicketCategories & Tickets):** Направена е строга поделба помеѓу дефиницијата на билетот (табела `TicketCategories` - дефинира цена и вкупен капацитет за даден сектор за конкретен настан) и самиот генериран билет (табела `Tickets` или `TicketInstances`). Секој купен билет е посебен запис (ред) со уникатен идентификатор (QR/баркод), што е неопходно за физичка валидација на влезот.
     16
     17* **Модел сегмент за Нарачки (Orders & OrderItems):** Процесот на трансакција е моделиран преку `Orders` (заглавие на нарачката со вкупна сума, датум и поврзаност со купувачот) и `OrderItems` (детали за секој поединечен билет купен во рамки на таа трансакција). Оваа нормализирана структура овозможува купување на повеќе различни билети во една иста трансакција и ја подготвува основата за пишување на тригери (во Фаза 4) кои ќе го намалуваат преостанатиот капацитет при секоја успешна нарачка.