Relational Model

Relational diagram

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 и со Promo_code.

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 логиката: Еден настан може да има повеќе спонзори, а еден спонзор може да учествува на повеќе настани. Истото важи и за типови на спонзорства.

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