Changes between Version 11 and Version 12 of RelationalModel


Ignore:
Timestamp:
05/29/26 11:32:15 (3 weeks ago)
Author:
231133
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • RelationalModel

    v11 v12  
    66
    77== Descriptive documentation and argumentation ==
    8 I Сегмент на моделот: Билети, нарачки и трансакции (Ticketing, Orders, and Transactions)
     8= I Сегмент: Билети, нарачки и трансакции =
    99
    10 Вклучени ентитети: Order, Order_Item, Ticket, Ticket_Type, Payment, Promo_code.
     10'''Вклучени ентитети:''' Order_cart, Ticket, Ticket_type, Price_tier, Payment, Payment_method, Payment_status, Discount, Refund_request.
    1111
    12 Како е моделиран: Процесот на трансакција е високо нормализиран. Order делува како заглавие (содржи вкупна цена, ID на корисник, временски печат), кое се поврзува со повеќе записи Order_Item. Ticket_Type (кој ја дефинира цената, капацитетот, името како „ВИП“ или „Генерален влез“) е одвоен од поединечниот ентитет Ticket.
     12'''Како е моделиран:''' 
     13Процесот на купување е моделиран околу `order_cart`, кој ја претставува нарачката/кошничката на корисникот. Наместо посебна `Order_Item` табела, поединечните купени или резервирани билети се чуваат директно во `Ticket`, каде секој билет е поврзан со конкретен `order_cart`, `ticket_type` и по потреба `seat`.
    1314
    14 Зошто е моделиран на овој начин:
     15`Ticket_type` го дефинира типот на билет, на пример VIP, Regular или Student, додека `Price_tier` овозможува различни ценовни нивоа за истиот тип билет. `Payment` е одвоена табела за плаќањата, со посебни табели за `Payment_method` и `Payment_status`. Попустите се моделирани преку `Discount`, а рефундациите преку `Refund_request`.
    1516
    16 1. Функционалност на кошничка (Cart): Одвојувањето на Order и Order_Item му овозможува на еден корисник да купи повеќе различни видови билети (на пр. 2 ВИП карти и 1 партер карта) во еден процес на наплата.
     17'''Зошто е моделиран на овој начин:'''
    1718
    18 2. Единствени идентификатори: Одвојувањето на Ticket од Ticket_Type е од клучно значење. Иако 500 луѓе можат да купат „Генерален влез“ (Ticket_Type), на секој поединец му треба единствен ред Ticket со посебен QR код или баркод за чекирање на влезот.
     19* '''Еден ред Ticket = еден реален билет:''' 
     20  Ова е важно затоа што секој билет може да има свој статус, баркод, седиште, време на заклучување, скенирање и историја. Не е доволно само да се каже дека некој купил „3 VIP билети“ - системот мора да знае кои се тие три конкретни билети.
    1921
    20 3. Финансиска ревизија: Чувањето на Payment и Promo_code како посебни ентитети поврзани со нарачката овозможува стабилно финансиско известување, следејќи точно кои маркетинг кампањи поттикнале продажба и одвојувајќи ја логиката на порталот за плаќање од логиката за продажба на билети.
     22* '''Order_cart како трансакциски центар:''' 
     23  Нарачката ги групира билетите, попустот, корисникот, статусот и вкупната цена. Така полесно се следи дали нарачката е отворена, платена, истечена, откажана или рефундирана.
    2124
    22 II Сегмент на моделот: Категоризација и структурирање на настани
     25* '''Payment е издвоен од Order_cart:''' 
     26  Ова овозможува почиста финансиска логика. Нарачката кажува што се купува, а `Payment` кажува како, кога и колку е платено. Затоа може да се следат методи на плаќање, статуси на плаќање и рефундации без да се мешаат со логиката за билетите.
    2327
    24 Вклучени ентитети: Event, Category, Event_Category (Junction Table), Location, Location_type.
     28* '''Discount наместо Promo_code:''' 
     29  Во најновиот модел нема `Promo_code` како посебен ентитет. Наместо тоа, попустот е моделиран преку `Discount`, кој се поврзува со `order_cart`.
    2530
    26 Како е моделиран: Постои врска „многу-кон-многу“ (many-to-many) воспоставена помеѓу Event и Category користејќи ја спојната табела Event_Category. Location е издвоена во сопствена посебна табела, поврзана со настанот преку надворешен клуч и дополнително категоризирана според Location_type.
     31= II Сегмент: Категоризација и структурирање на настани =
    2732
    28 Зошто е моделиран на овој начин:
     33'''Вклучени ентитети:''' Event, Category, Event_category, Event_status, Location, Location_type, Section, Seat.
    2934
    30 1. Флексибилно означување (Tagging): Настан како „Самит на SaaS основачи“ можеби ќе треба да се означи под повеќе категории: „Технологија“, „Бизнис“ и „Вмрежување“. Спојната табела спречува дуплирање на податоците и им овозможува на корисниците да ја филтрираат платформата според повеќе интереси кои се вкрстуваат.
     35'''Како е моделиран:''' 
     36`Event` е главниот ентитет за настанот. Тој е поврзан со `Category` преку junction табелата `Event_category`, бидејќи еден настан може да има повеќе категории, а една категорија може да припаѓа на повеќе настани.
    3137
    32 2. Менаџирање со локации: Со нормализирање на Location, повеќе настани можат да бидат поврзани со истото место без да се препишуваат адресата, капацитетот и координатите секој пат. Ова обезбедува конзистентност на податоците и ѝ овозможува на платформата да има „Страници за локации“ кои ги прикажуваат сите претстојни настани на одредена локација.
     38Локацијата е нормализирана преку `Location`, а нејзиниот тип преку `Location_type`. Дополнително, физичката структура на локацијата е претставена преку `Section` и `Seat`.
    3339
    34 III Сегмент на моделот: Кориснички улоги и контрола на пристап
     40'''Зошто е моделиран на овој начин:'''
    3541
    36 Вклучени ентитети: User, Organizer, Subscription_organizer, Role / Staff_role.
     42* '''Флексибилни категории:''' 
     43  Настан може истовремено да биде „Technology“, „Business“ и „Networking“. Со `Event_category` не се дуплираат категории и лесно може да се филтрираат настани според повеќе интереси.
    3744
    38 Како е моделиран: Има централна табела User за автентикација, која се разгранува во специфични улоги зависни од контекстот, како Organizer или Staff, во зависност од нивната врска со одреден настан или претплата.
     45* '''Локацијата не се повторува:''' 
     46  Ако повеќе настани се одржуваат на исто место, адресата, капацитетот и типот на локација не треба да се внесуваат повторно. Тоа ја намалува редундантноста и ја подобрува конзистентноста.
    3947
    40 Зошто е моделиран на овој начин:
     48* '''Section и Seat се важни за билетирање:''' 
     49  Бидејќи билетот може да биде поврзан со конкретно седиште, моделот може да поддржи концертни сали, театри, конференциски простории или стадиони каде што капацитетот не е само бројка, туку реална структура.
    4150
    42 1. Контрола на пристап базирана на улоги (RBAC): Еден корисник може да биде главен Organizer за сопствен настан, но едноставно редовен посетител на друга конференција. Со тоа што „is_organizer“ не е хардкодиран како едноставен булеан (boolean) во централната табела User, шемата поддржува multi-tenant authorization каде дозволите се строго поврзани со специфични ID-а на настани.
     51= III Сегмент: Корисници, организатори и претплати =
    4352
    44 IV Сегмент на моделот: Операции на настани (Распоред и персонал)
     53'''Вклучени ентитети:''' User_app, Organizer, Subscription_organizer, Subscription_type, Staff, Staff_role.
    4554
    46 Вклучени ентитети: Event_Schedule, Shift, Staff, Staff_role.
     55'''Како е моделиран:''' 
     56`User_app` е централната табела за корисниците. Организаторите се моделирани посебно преку `Organizer`, а врската меѓу корисник и организатор се прави преку `Subscription_organizer`. Видот на претплата е издвоен во `Subscription_type`.
    4757
    48 Како е моделиран: Наместо да се третира настанот како еден единствен блок од време, тој е разложен на Event_Schedule_Sеssion (сесии, работилници, итн.). Менаџирањето со персонал се менаџира преку систем на смени (Shift), каде што поединечни членови на персоналот Staff (на кои им е доделена улога Staff_role) се мапирани на специфични времиња/локации.
     58Персоналот е посебно моделиран преку `Staff`, со улоги во `Staff_role`.
    4959
    50 Зошто е моделиран на овој начин:
     60'''Зошто е моделиран на овој начин:'''
    5161
    52 1. Детална логистика: Големите конференции не се едноставни. Оваа структура му овозможува на системот да изгради план за посетителите (кој зборува кога и каде) и распоред за операциите (кој чувар е на која врата во 14:00 часот). Ова го решава проблемот со комплексноста на повеќедневни настани со повеќе траки.
     62* '''User_app не е преоптоварена со сите можни улоги:''' 
     63  Корисникот може да биде обичен посетител, да следи организатор, да купува билети, да остава reviews, или да биде дел од staff логиката. Затоа не е добро сите овие работи да се стават како boolean полиња во `User_app`.
    5364
    54 V Сегмент на моделот: Спонзорства и настани
     65* '''Organizer е посебен дел од моделот:''' 
     66  Организаторот има свои податоци како company_name, contact_phone и website_url. Тоа не е исто како обичен кориснички профил.
    5567
    56 Вклучени ентитети: Sponsor, Sponsor_tier.
     68* '''Subscription_organizer ја моделира релацијата корисник - организатор:''' 
     69  Ова овозможува еден корисник да следи повеќе организатори, а еден организатор да има повеќе претплатници.
    5770
    58 Како е моделиран: Спонзорите се следат како посебни ентитети поврзани со конкретни настани, категоризирани според ниво на спонзорство Sponsor_tier (на пр., златно, сребрено, бронзено). Изложувачите исто така имаат посветени табели што ги мапираат со настанот.
     71= IV Сегмент: Распоред, сесии и операции на настани =
    5972
    60 Зошто е моделиран на овој начин:
    61 1. Професорот ни сугерираше да ги раздвоиме во неколку junction tables, за да може даден спонзор да е различен тип (gold, silver...) на различни настани.
     73'''Вклучени ентитети:''' Event_schedule, Event_schedule_session, Session_type, Shift, Staff, Staff_role, Exhibitor, Exhibitor_event_schedule_session.
     74
     75'''Како е моделиран:''' 
     76Настанот не се третира како еден обичен временски блок. `Event_schedule` го претставува распоредот, а `Event_schedule_session` ги претставува конкретните сесии, презентации, работилници или активности во рамки на тој распоред. `Session_type` го дефинира типот на сесијата.
     77
     78Персоналот се организира преку `Shift`, каде се чува кој staff член работи во кој период. Изложувачите се поврзуваат со конкретни сесии преку `Exhibitor_event_schedule_session`.
     79
     80'''Зошто е моделиран на овој начин:'''
     81
     82* '''Голем настан има повеќе делови:''' 
     83  Конференција може да има opening talk, workshops, networking session и closing panel. Затоа `Event_schedule_session` е неопходна табела.
     84
     85* '''Оперативната логика е одвоена од програмската логика:''' 
     86  Сесиите кажуваат што се случува на настанот, додека `Shift` кажува кој работи и кога. Тоа се две различни работи и затоа се моделирани посебно.
     87
     88* '''Изложувачите можат да бидат врзани за конкретни сесии:''' 
     89  Не мора секој exhibitor да биде релевантен за целиот настан. Некој може да биде присутен само на одредена сесија или дел од програмата.
     90
     91= V Сегмент: Спонзорства и изложувачи =
     92
     93'''Вклучени ентитети:''' Sponsor, Sponsor_event, Sponsor_type, Sponsor_type_sponsor, Exhibitor, Exhibitor_event_schedule_session.
     94
     95'''Како е моделиран:''' 
     96Спонзорите се чуваат во `Sponsor`. Врската меѓу спонзор и настан е во `Sponsor_event`. Типовите на спонзорство, како Gold, Silver или Bronze, се во `Sponsor_type`, а нивната доделба се прави преку `Sponsor_type_sponsor`.
     97
     98Изложувачите се моделирани посебно преку `Exhibitor` и се поврзуваат со конкретни сесии преку `Exhibitor_event_schedule_session`.
     99
     100'''Зошто е моделиран на овој начин:'''
     101
     102* '''Спонзор може да има различна улога на различни настани:''' 
     103  Истиот спонзор може да биде Gold sponsor на еден настан, но Silver sponsor на друг. Затоа не е добро типот на спонзорство да стои само во `Sponsor`.
     104
     105* '''Junction табелите ја решаваат many-to-many логиката:''' 
     106  Еден настан може да има повеќе спонзори, а еден спонзор може да учествува на повеќе настани. Истото важи и за типови на спонзорства.
     107
     108* '''Изложувачите не се исто што и спонзорите:''' 
     109  Спонзор плаќа или поддржува настан. Изложувач има физичко или програмско присуство, најчесто поврзано со конкретна сесија или простор.