Changes between Version 20 and Version 21 of RelationalModel


Ignore:
Timestamp:
04/21/26 01:00:18 (12 days ago)
Author:
231027
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • RelationalModel

    v20 v21  
    1616Во овој дел се подетално објаснети специфичните сегменти од моделот кои содржат напредна логика или решенија за специфични бизнис проблеми.
    1717
    18 '''1. Сегмент: Инвентар на билети наспроти Продажба (Ticket vs. Actual_Ticket)'''
     18=== 1. Сегмент: Животен циклус на билет и Продажба (Ticket vs. Ticket_Purchase) ===
    1919
    20 * '''Како и зошто:''' Моделот прави јасна разделба помеѓу ''понудата'' за билет и ''реализираната продажба''. Табелата `Ticket` ги содржи сите потенцијални седишта за еден настан. Табелата `Actual_Ticket` се пополнува само при извршена трансакција. Релацијата е дефинирана како '''1:1''' со Unique Constraint на `ticket_id` во `Actual_Ticket`.
     20* '''Како и зошто:''' Моделот прави јасна разделба помеѓу инвентарот на седишта (`Ticket`) и реализираната трансакција (`Ticket_Purchase`). Табелата `Ticket` ги содржи сите потенцијални места за еден настан, додека `Ticket_Purchase` е запис за купување кој содржи уникатен `qr_code`. Релацијата е дефинирана како '''1:N''' помеѓу билетот и купувањата.
     21* '''Аргументација:''' Оваа структура овозможува '''повторна продажба на исто седиште'''. Кога еден билет ќе се рефундира, неговиот статус се враќа во „слободен“, а во `Ticket_Purchase` се дозволува нов запис за следниот купувач. Со тоа се чува целосна историја на сопственост врз едно седиште низ времето.
    2122
    22 * '''Аргументација:''' Ова спречува најкритичен проблем во вакви системи - „double booking“ (продажба на исто седиште на повеќе лица). Дури и ако два процеси се обидат истовремено да запишат продажба, Unique клучот во базата ќе ја одбие втората трансакција.
     23=== 2. Сегмент: Динамично ценообразовање и фази (Event_Period) ===
    2324
     25* '''Како и зошто:''' Наместо фиксна цена, воведовме табела `Event_Period` поврзана со случувањето на настанот (`Event_Happening`). Секој период има дефиниран процент на промена и насока (`increase_decrease` булеан). Поставена е '''UNIQUE''' заштита врз `(event_happening_id, name)`.
     26* '''Аргументација:''' Ова овозможува системот автоматски да ги менаџира цените во зависност од временските периоди (пр. "Early Bird" попусти или "Last Minute" поскапувања). Уникатниот клуч спречува логички грешки каде еден настан би имал две различни ценовни правила со исто име.
    2427
     28=== 3. Сегмент: Хиерархија и Интегритет на локации (Venue -> Section -> Seat) ===
    2529
    26 '''2. Сегмент: Динамично ценообразовање (Event_Period)'''
     30* '''Како и зошто:''' Локациите се моделирани хиерархиски преку '''Identifying''' релации. Секое седиште е дефинирано преку композитен клуч кој ги вклучува неговата секција и сала. Дополнително, воведени се '''Unique''' констреинти врз имињата на секциите во рамки на една сала и броевите на седишта во рамки на една секција.
     31* '''Аргументација:''' Ова ја рефлектира реалната физичка поставеност на објектите и спречува дуплирање на сектори или седишта. Со ова се гарантира дека секој билет е врзан за прецизна и уникатна физичка локација во салата.
    2732
    28 * '''Како и зошто:''' Наместо фиксна цена, воведовме табела `Event_Period` поврзана со терминот на настанот (`Event_Happening`). Секој период има дефиниран процент на зголемување или намалување (`increase` бит). Релацијата помеѓу терминот и периодите е '''1:N'''.
     33=== 4. Сегмент: Специјализација на ентитети (Inheritance) ===
    2934
    30 * '''Аргументација:''' Ова овозможува системот автоматски да ја пресметува цената во зависност од датумот на купување (пр. Early Bird попусти или Last Minute поскапувања), без потреба од рачен `UPDATE` на цените во текот на продажбата.
     35* '''Како и зошто:''' Користена е специјализација на два нивоа:
     36 1. '''Изведувачи:''' `Performer` како база, со `Musical_Performer` и `Acting_Performer` како подтипови.
     37 2. '''Настани:''' `Event` како база, со `Concert` и `Play` како подтипови.
     38* '''Аргументација:''' Ова овозможува базата да биде екстремно флексибилна. Музичките изведувачи имаат жанр и издавачка куќа, додека театарските имаат улоги и агенции, а сепак сите се менаџираат унифицирано преку главната табела на изведувачи. Истата логика овозможува системот за билети да работи идентично за концерти и за претстави.
    3139
     40=== 5. Сегмент: Финансиска безбедност и рефундација (Ticket_Refund) ===
    3241
    33 
    34 '''3. Сегмент: Хиерархија на локации (Venue -> Section -> Seat)'''
    35 
    36 * '''Како и зошто:''' Салите се моделирани хиерархиски преку '''1:N''' релации. Секциите (`Venue_Section`) припаѓаат на сали, а индивидуалните седишта (`Venue_Section_Seat`) на секции.
    37 
    38 * '''Аргументација:''' Ова овозможува лесно пребарување и филтрирање на слободни места по сектори (пр. VIP Box, Parterre, Balcony) и ја рефлектира реалната физичка поставеност на објектите.
    39 
    40 
    41 
    42 '''4. Сегмент: Специјализација на изведувачи (Performer Inheritance)'''
    43 
    44 * '''Како и зошто:''' Користена е специјализација (Inheritance) каде `Performer` е главен ентитет, а `Musical_Performer` и `Acting_Performer` се подтипови поврзани со релации од типот '''1:1'''.
    45 
    46 * '''Аргументација:''' Ова овозможува базата да биде флексибилна за различни типови настани. Музичките настани бараат податоци за жанр и дискографија, додека театарските бараат податоци за улоги и режија, а сепак сите ја делат основната структура на изведувач.
    47 
    48 
    49 
    50 '''5. Сегмент: Логика на рефундација (Actual_Ticket_Refund)'''
    51 
    52 * '''Како и зошто:''' Табелата за рефундација е поврзана директно со `qr_code` од продажбата со '''1:1''' релација.
    53 
    54 * '''Аргументација:''' Со ова се гарантира дека само валидно продаден билет може да биде предмет на рефундација и се чува историја на вратените средства независно од оригиналната продажба, што е клучно за финансиско сметководство.
     42* '''Како и зошто:''' Табелата за рефундација е поврзана со трансакцијата (`Ticket_Purchase`) преку релација со '''Unique Constraint''' на колоната `purchase_id`.
     43* '''Аргументација:''' Со оваа логика физички се оневозможува за една иста трансакција (купување) да се вратат парите повеќе од еднаш. Ова е клучна заштита против финансиски манипулации или системски грешки, обезбедувајќи прецизно сметководствено следење на вратените средства.