= Relational Model =

== Relational diagram ==

[[Image(RelationalModel-eventflow.svg)]]

== Descriptive documentation and argumentation ==
I Сегмент на моделот: Билети, нарачки и трансакции (Ticketing, Orders, and Transactions)

Вклучени ентитети: Order, Order_Item, Ticket, Ticket_Type, Payment, Promo_code.

Како е моделиран: Процесот на трансакција е високо нормализиран. Order делува како заглавие (содржи вкупна цена, ID на корисник, временски печат), кое се поврзува со повеќе записи Order_Item. Ticket_Type (кој ја дефинира цената, капацитетот, името како „ВИП“ или „Генерален влез“) е одвоен од поединечниот ентитет Ticket.

Зошто е моделиран на овој начин: 

1. Функционалност на кошничка (Cart): Одвојувањето на Order и Order_Item му овозможува на еден корисник да купи повеќе различни видови билети (на пр. 2 ВИП карти и 1 партер карта) во еден процес на наплата.

2. Единствени идентификатори: Одвојувањето на Ticket од Ticket_Type е од клучно значење. Иако 500 луѓе можат да купат „Генерален влез“ (Ticket_Type), на секој поединец му треба единствен ред Ticket со посебен QR код или баркод за чекирање на влезот.

3. Финансиска ревизија: Чувањето на Payment и Promo_code како посебни ентитети поврзани со нарачката овозможува стабилно финансиско известување, следејќи точно кои маркетинг кампањи поттикнале продажба и одвојувајќи ја логиката на порталот за плаќање од логиката за продажба на билети.

II Сегмент на моделот: Категоризација и структурирање на настани

Вклучени ентитети: Event, Category, Event_Category (Junction Table), Location, Location_type.

Како е моделиран: Постои врска „многу-кон-многу“ (many-to-many) воспоставена помеѓу Event и Category користејќи ја спојната табела Event_Category. Location е издвоена во сопствена посебна табела, поврзана со настанот преку надворешен клуч и дополнително категоризирана според Location_type.

Зошто е моделиран на овој начин:

1. Флексибилно означување (Tagging): Настан како „Самит на SaaS основачи“ можеби ќе треба да се означи под повеќе категории: „Технологија“, „Бизнис“ и „Вмрежување“. Спојната табела спречува дуплирање на податоците и им овозможува на корисниците да ја филтрираат платформата според повеќе интереси кои се вкрстуваат.

2. Менаџирање со локации: Со нормализирање на Location, повеќе настани можат да бидат поврзани со истото место без да се препишуваат адресата, капацитетот и координатите секој пат. Ова обезбедува конзистентност на податоците и ѝ овозможува на платформата да има „Страници за локации“ кои ги прикажуваат сите претстојни настани на одредена локација.

III Сегмент на моделот: Кориснички улоги и контрола на пристап

Вклучени ентитети: User, Organizer, Subscription_organizer, Role / Staff_role.

Како е моделиран: Има централна табела User за автентикација, која се разгранува во специфични улоги зависни од контекстот, како Organizer или Staff, во зависност од нивната врска со одреден настан или претплата.

Зошто е моделиран на овој начин:

1. Контрола на пристап базирана на улоги (RBAC): Еден корисник може да биде главен Organizer за сопствен настан, но едноставно редовен посетител на друга конференција. Со тоа што „is_organizer“ не е хардкодиран како едноставен булеан (boolean) во централната табела User, шемата поддржува multi-tenant authorization каде дозволите се строго поврзани со специфични ID-а на настани.

IV Сегмент на моделот: Операции на настани (Распоред и персонал)

Вклучени ентитети: Event_Schedule, Shift, Staff, Staff_role.

Како е моделиран: Наместо да се третира настанот како еден единствен блок од време, тој е разложен на Event_Schedule_Sеssion (сесии, работилници, итн.). Менаџирањето со персонал се менаџира преку систем на смени (Shift), каде што поединечни членови на персоналот Staff (на кои им е доделена улога Staff_role) се мапирани на специфични времиња/локации.

Зошто е моделиран на овој начин:

1. Детална логистика: Големите конференции не се едноставни. Оваа структура му овозможува на системот да изгради план за посетителите (кој зборува кога и каде) и распоред за операциите (кој чувар е на која врата во 14:00 часот). Ова го решава проблемот со комплексноста на повеќедневни настани со повеќе траки.

V Сегмент на моделот: Спонзорства и настани

Вклучени ентитети: Sponsor, Sponsor_tier.

Како е моделиран: Спонзорите се следат како посебни ентитети поврзани со конкретни настани, категоризирани според ниво на спонзорство Sponsor_tier (на пр., златно, сребрено, бронзено). Изложувачите исто така имаат посветени табели што ги мапираат со настанот.

Зошто е моделиран на овој начин:
1. Професорот ни сугерираше да ги раздвоиме во неколку junction tables, за да може даден спонзор да е различен тип (gold, silver...) на различни настани.