| | 22 | |
| | 23 | == Descriptive documentation and argumentation == |
| | 24 | I Сегмент на моделот: Билети, нарачки и трансакции (Ticketing, Orders, and Transactions) |
| | 25 | |
| | 26 | Вклучени ентитети: Order, Order_Item, Ticket, Ticket_Type, Payment, Promo_code. |
| | 27 | |
| | 28 | Како е моделиран: Процесот на трансакција е високо нормализиран. Order делува како заглавие (содржи вкупна цена, ID на корисник, временски печат), кое се поврзува со повеќе записи Order_Item. Ticket_Type (кој ја дефинира цената, капацитетот, името како „ВИП“ или „Генерален влез“) е одвоен од поединечниот ентитет Ticket. |
| | 29 | |
| | 30 | Зошто е моделиран на овој начин: |
| | 31 | |
| | 32 | 1. Функционалност на кошничка (Cart): Одвојувањето на Order и Order_Item му овозможува на еден корисник да купи повеќе различни видови билети (на пр. 2 ВИП карти и 1 партер карта) во еден процес на наплата. |
| | 33 | |
| | 34 | 2. Единствени идентификатори: Одвојувањето на Ticket од Ticket_Type е од клучно значење. Иако 500 луѓе можат да купат „Генерален влез“ (Ticket_Type), на секој поединец му треба единствен ред Ticket со посебен QR код или баркод за чекирање на влезот. |
| | 35 | |
| | 36 | 3. Финансиска ревизија: Чувањето на Payment и Promo_code како посебни ентитети поврзани со нарачката овозможува стабилно финансиско известување, следејќи точно кои маркетинг кампањи поттикнале продажба и одвојувајќи ја логиката на порталот за плаќање од логиката за продажба на билети. |
| | 37 | |
| | 38 | II Сегмент на моделот: Категоризација и структурирање на настани |
| | 39 | |
| | 40 | Вклучени ентитети: Event, Category, Event_Category (Junction Table), Location, Location_type. |
| | 41 | |
| | 42 | Како е моделиран: Постои врска „многу-кон-многу“ (many-to-many) воспоставена помеѓу Event и Category користејќи ја спојната табела Event_Category. Location е издвоена во сопствена посебна табела, поврзана со настанот преку надворешен клуч и дополнително категоризирана според Location_type. |
| | 43 | |
| | 44 | Зошто е моделиран на овој начин: |
| | 45 | |
| | 46 | 1. Флексибилно означување (Tagging): Настан како „Самит на SaaS основачи“ можеби ќе треба да се означи под повеќе категории: „Технологија“, „Бизнис“ и „Вмрежување“. Спојната табела спречува дуплирање на податоците и им овозможува на корисниците да ја филтрираат платформата според повеќе интереси кои се вкрстуваат. |
| | 47 | |
| | 48 | 2. Менаџирање со локации: Со нормализирање на Location, повеќе настани можат да бидат поврзани со истото место без да се препишуваат адресата, капацитетот и координатите секој пат. Ова обезбедува конзистентност на податоците и ѝ овозможува на платформата да има „Страници за локации“ кои ги прикажуваат сите претстојни настани на одредена локација. |
| | 49 | |
| | 50 | III Сегмент на моделот: Кориснички улоги и контрола на пристап |
| | 51 | |
| | 52 | Вклучени ентитети: User, Organizer, Subscription_organizer, Role / Staff_role. |
| | 53 | |
| | 54 | Како е моделиран: Има централна табела User за автентикација, која се разгранува во специфични улоги зависни од контекстот, како Organizer или Staff, во зависност од нивната врска со одреден настан или претплата. |
| | 55 | |
| | 56 | Зошто е моделиран на овој начин: |
| | 57 | |
| | 58 | 1. Контрола на пристап базирана на улоги (RBAC): Еден корисник може да биде главен Organizer за сопствен настан, но едноставно редовен посетител на друга конференција. Со тоа што „is_organizer“ не е хардкодиран како едноставен булеан (boolean) во централната табела User, шемата поддржува multi-tenant authorization каде дозволите се строго поврзани со специфични ID-а на настани. |
| | 59 | |
| | 60 | IV Сегмент на моделот: Операции на настани (Распоред и персонал) |
| | 61 | |
| | 62 | Вклучени ентитети: Event_Schedule, Shift, Staff, Staff_role. |
| | 63 | |
| | 64 | Како е моделиран: Наместо да се третира настанот како еден единствен блок од време, тој е разложен на Event_Schedule_Sеssion (сесии, работилници, итн.). Екипирањето со персонал се менаџира преку систем на смени (Shift), каде што поединечни членови на персоналот Staff (на кои им е доделена улога Staff_role) се мапирани на специфични времиња/локации. |
| | 65 | |
| | 66 | Зошто е моделиран на овој начин: |
| | 67 | |
| | 68 | 1. Детална логистика: Големите конференции не се едноставни. Оваа структура му овозможува на системот да изгради план за посетителите (кој зборува кога и каде) и распоред за операциите (кој чувар е на која врата во 14:00 часот). Ова го решава проблемот со комплексноста на повеќедневни настани со повеќе траки. |
| | 69 | |
| | 70 | V Сегмент на моделот: Спонзорства и изложувачи |
| | 71 | |
| | 72 | Вклучени ентитети: Sponsor, Sponsor_tier. |
| | 73 | |
| | 74 | Како е моделиран: Спонзорите се следат како посебни ентитети поврзани со конкретни настани, категоризирани според ниво на спонзорство Sponsor_tier (на пр., златно, сребрено, бронзено). Изложувачите исто така имаат посветени табели што ги мапираат со настанот. |
| | 75 | |
| | 76 | Зошто е моделиран на овој начин: |
| | 77 | 1. Професорот ни сугерираше да ги раздвоиме во неколку junction tables, за да може даден спонзор да е различен тип (gold, silver...) на различни настани. |
