= Relational Model =

== Relational diagram ==

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

== Descriptive documentation and argumentation ==
= I Сегмент: Билети, нарачки и трансакции =

'''Вклучени ентитети:''' Order_cart, Ticket, Ticket_type, Price_tier, Payment, Payment_method, Payment_status, Discount, Refund_request.

'''Како е моделиран:'''  
Процесот на купување е моделиран околу `order_cart`, кој ја претставува нарачката/кошничката на корисникот. Наместо посебна `Order_Item` табела, поединечните купени или резервирани билети се чуваат директно во `Ticket`, каде секој билет е поврзан со конкретен `order_cart`, `ticket_type` и по потреба `seat`.

`Ticket_type` го дефинира типот на билет, на пример VIP, Regular или Student, додека `Price_tier` овозможува различни ценовни нивоа за истиот тип билет. `Payment` е одвоена табела за плаќањата, со посебни табели за `Payment_method` и `Payment_status`. Попустите се моделирани преку `Discount`, а рефундациите преку `Refund_request`.

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

* '''Еден ред Ticket = еден реален билет:'''  
  Ова е важно затоа што секој билет може да има свој статус, баркод, седиште, време на заклучување, скенирање и историја. Не е доволно само да се каже дека некој купил „3 VIP билети“ - системот мора да знае кои се тие три конкретни билети.

* '''Order_cart како трансакциски центар:'''  
  Нарачката ги групира билетите, попустот, корисникот, статусот и вкупната цена. Така полесно се следи дали нарачката е отворена, платена, истечена, откажана или рефундирана.

* '''Payment е издвоен од Order_cart:'''  
  Ова овозможува почиста финансиска логика. Нарачката кажува што се купува, а `Payment` кажува како, кога и колку е платено. Затоа може да се следат методи на плаќање, статуси на плаќање и рефундации без да се мешаат со логиката за билетите.

* '''Discount наместо Promo_code:'''  
  Во најновиот модел нема `Promo_code` како посебен ентитет. Наместо тоа, попустот е моделиран преку `Discount`, кој се поврзува со `order_cart`.

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

'''Вклучени ентитети:''' Event, Category, Event_category, Event_status, Location, Location_type, Section, Seat.

'''Како е моделиран:'''  
`Event` е главниот ентитет за настанот. Тој е поврзан со `Category` преку junction табелата `Event_category`, бидејќи еден настан може да има повеќе категории, а една категорија може да припаѓа на повеќе настани.

Локацијата е нормализирана преку `Location`, а нејзиниот тип преку `Location_type`. Дополнително, физичката структура на локацијата е претставена преку `Section` и `Seat`.

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

* '''Флексибилни категории:'''  
  Настан може истовремено да биде „Technology“, „Business“ и „Networking“. Со `Event_category` не се дуплираат категории и лесно може да се филтрираат настани според повеќе интереси.

* '''Локацијата не се повторува:'''  
  Ако повеќе настани се одржуваат на исто место, адресата, капацитетот и типот на локација не треба да се внесуваат повторно. Тоа ја намалува редундантноста и ја подобрува конзистентноста.

* '''Section и Seat се важни за билетирање:'''  
  Бидејќи билетот може да биде поврзан со конкретно седиште, моделот може да поддржи концертни сали, театри, конференциски простории или стадиони каде што капацитетот не е само бројка, туку реална структура.

= III Сегмент: Корисници, организатори и претплати =

'''Вклучени ентитети:''' User_app, Organizer, Subscription_organizer, Subscription_type, Staff, Staff_role.

'''Како е моделиран:'''  
`User_app` е централната табела за корисниците. Организаторите се моделирани посебно преку `Organizer`, а врската меѓу корисник и организатор се прави преку `Subscription_organizer`. Видот на претплата е издвоен во `Subscription_type`.

Персоналот е посебно моделиран преку `Staff`, со улоги во `Staff_role`.

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

* '''User_app не е преоптоварена со сите можни улоги:'''  
  Корисникот може да биде обичен посетител, да следи организатор, да купува билети, да остава reviews, и слично.

* '''Organizer е посебен дел од моделот:'''  
  Организаторот има свои податоци како company_name, contact_phone и website_url. Тоа не е исто како обичен кориснички профил.

* '''Subscription_organizer ја моделира релацијата корисник - организатор:'''  
  Ова овозможува еден корисник да следи повеќе организатори, а еден организатор да има повеќе претплатници.

= IV Сегмент: Распоред, сесии и операции на настани =

'''Вклучени ентитети:''' Event_schedule, Event_schedule_session, Session_type, Staff, Staff_role, Exhibitor, Exhibitor_event_schedule_session.

'''Како е моделиран:'''  
Настанот не се третира како еден обичен временски блок. `Event_schedule` го претставува распоредот, а `Event_schedule_session` ги претставува конкретните сесии, презентации, работилници или активности во рамки на тој распоред. `Session_type` го дефинира типот на сесијата.

Персоналот се организира преку `Staff_team_event_schedule`, каде се чува кој staff член работи во кој период. Изведувачите се поврзуваат со конкретни сесии преку `Exhibitor_event_schedule_session`.

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

* '''Голем настан има повеќе делови:'''  
  Конференција може да има opening talk, workshops, networking session и closing panel. Затоа `Event_schedule_session` е неопходна табела.

* '''Оперативната логика е одвоена од програмската логика:'''  
  Сесиите кажуваат што се случува на настанот, додека 'Staff_team_event_schedule' кажува кој работи и кога. Тоа се две различни работи и затоа се моделирани посебно.

* '''Изведувачите можат да бидат врзани за конкретни сесии:'''  
  Не мора секој exhibitor да биде релевантен за целиот настан. Некој може да биде присутен само на одредена сесија или дел од програмата.

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

'''Вклучени ентитети:''' Sponsor, Sponsor_event, Sponsor_type, Sponsor_type_sponsor, Exhibitor, Exhibitor_event_schedule_session.

'''Како е моделиран:'''  
Спонзорите се чуваат во `Sponsor`. Врската меѓу спонзор и настан е во `Sponsor_event`. Типовите на спонзорство, како Gold, Silver или Bronze, се во `Sponsor_type`, а нивната доделба се прави преку `Sponsor_type_sponsor`.

Изведувачите се моделирани посебно преку `Exhibitor` и се поврзуваат со конкретни сесии преку `Exhibitor_event_schedule_session`.

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

* '''Спонзор може да има различна улога на различни настани:'''  
  Истиот спонзор може да биде Gold sponsor на еден настан, но Silver sponsor на друг. Затоа не е добро типот на спонзорство да стои само во `Sponsor`.

* '''Junction табелите ја решаваат many-to-many логиката:'''  
  Еден настан може да има повеќе спонзори, а еден спонзор може да учествува на повеќе настани. Истото важи и за типови на спонзорства.

* '''Изведувачите не се исто што и спонзорите:'''  
  Спонзор плаќа или поддржува настан. Изведувачите имаат физичко или програмско присуство, најчесто поврзано со конкретна сесија или простор.