Changes between Version 21 and Version 22 of RelationalModel


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

--

Legend:

Unmodified
Added
Removed
Modified

  • RelationalModel

    v21 v22  
    1616Во овој дел се подетално објаснети специфичните сегменти од моделот кои содржат напредна логика или решенија за специфични бизнис проблеми.
    1717
    18 === 1. Сегмент: Животен циклус на билет и Продажба (Ticket vs. Ticket_Purchase) ===
     18 1. Сегмент: Животен циклус на билет и Продажба (Ticket vs. Ticket_Purchase)
    1919
    20 * '''Како и зошто:''' Моделот прави јасна разделба помеѓу инвентарот на седишта (`Ticket`) и реализираната трансакција (`Ticket_Purchase`). Табелата `Ticket` ги содржи сите потенцијални места за еден настан, додека `Ticket_Purchase` е запис за купување кој содржи уникатен `qr_code`. Релацијата е дефинирана како '''1:N''' помеѓу билетот и купувањата.
    21 * '''Аргументација:''' Оваа структура овозможува '''повторна продажба на исто седиште'''. Кога еден билет ќе се рефундира, неговиот статус се враќа во „слободен“, а во `Ticket_Purchase` се дозволува нов запис за следниот купувач. Со тоа се чува целосна историја на сопственост врз едно седиште низ времето.
     20 * '''Како и зошто:''' Моделот прави јасна разделба помеѓу инвентарот на седишта (`Ticket`) и реализираната трансакција (`Ticket_Purchase`). Табелата `Ticket` ги содржи сите потенцијални места за еден настан, додека `Ticket_Purchase` е запис за купување кој содржи уникатен `qr_code`. Релацијата е дефинирана како '''1:N''' помеѓу билетот и купувањата.
     21 * '''Аргументација:''' Оваа структура овозможува '''повторна продажба на исто седиште'''. Кога еден билет ќе се рефундира, неговиот статус се враќа во „слободен“, а во `Ticket_Purchase` се дозволува нов запис за следниот купувач. Со тоа се чува целосна историја на сопственост врз едно седиште низ времето.
    2222
    23 === 2. Сегмент: Динамично ценообразовање и фази (Event_Period) ===
     23 2. Сегмент: Динамично ценообразовање и фази (Event_Period)
    2424
    25 * '''Како и зошто:''' Наместо фиксна цена, воведовме табела `Event_Period` поврзана со случувањето на настанот (`Event_Happening`). Секој период има дефиниран процент на промена и насока (`increase_decrease` булеан). Поставена е '''UNIQUE''' заштита врз `(event_happening_id, name)`.
    26 * '''Аргументација:''' Ова овозможува системот автоматски да ги менаџира цените во зависност од временските периоди (пр. "Early Bird" попусти или "Last Minute" поскапувања). Уникатниот клуч спречува логички грешки каде еден настан би имал две различни ценовни правила со исто име.
     25 * '''Како и зошто:''' Наместо фиксна цена, воведовме табела `Event_Period` поврзана со случувањето на настанот (`Event_Happening`). Секој период има дефиниран процент на промена и насока (`increase_decrease` булеан). Поставена е '''UNIQUE''' заштита врз `(event_happening_id, name)`.
     26 * '''Аргументација:''' Ова овозможува системот автоматски да ги менаџира цените во зависност од временските периоди (пр. "Early Bird" попусти или "Last Minute" поскапувања). Уникатниот клуч спречува логички грешки каде еден настан би имал две различни ценовни правила со исто име.
    2727
    28 === 3. Сегмент: Хиерархија и Интегритет на локации (Venue -> Section -> Seat) ===
     28 3. Сегмент: Хиерархија и Интегритет на локации (Venue -> Section -> Seat)
    2929
    30 * '''Како и зошто:''' Локациите се моделирани хиерархиски преку '''Identifying''' релации. Секое седиште е дефинирано преку композитен клуч кој ги вклучува неговата секција и сала. Дополнително, воведени се '''Unique''' констреинти врз имињата на секциите во рамки на една сала и броевите на седишта во рамки на една секција.
    31 * '''Аргументација:''' Ова ја рефлектира реалната физичка поставеност на објектите и спречува дуплирање на сектори или седишта. Со ова се гарантира дека секој билет е врзан за прецизна и уникатна физичка локација во салата.
     30 * '''Како и зошто:''' Локациите се моделирани хиерархиски преку '''Identifying''' релации. Секое седиште е дефинирано преку композитен клуч кој ги вклучува неговата секција и сала. Дополнително, воведени се '''Unique''' констреинти врз имињата на секциите во рамки на една сала и броевите на седишта во рамки на една секција.
     31 * '''Аргументација:''' Ова ја рефлектира реалната физичка поставеност на објектите и спречува дуплирање на сектори или седишта. Со ова се гарантира дека секој билет е врзан за прецизна и уникатна физичка локација во салата.
    3232
    33 === 4. Сегмент: Специјализација на ентитети (Inheritance) ===
     33 4. Сегмент: Специјализација на ентитети (Inheritance)
    3434
    35 * '''Како и зошто:''' Користена е специјализација на два нивоа:
    36  1. '''Изведувачи:''' `Performer` како база, со `Musical_Performer` и `Acting_Performer` како подтипови.
    37  2. '''Настани:''' `Event` како база, со `Concert` и `Play` како подтипови.
    38 * '''Аргументација:''' Ова овозможува базата да биде екстремно флексибилна. Музичките изведувачи имаат жанр и издавачка куќа, додека театарските имаат улоги и агенции, а сепак сите се менаџираат унифицирано преку главната табела на изведувачи. Истата логика овозможува системот за билети да работи идентично за концерти и за претстави.
     35 * '''Како и зошто:''' Користена е специјализација на два нивоа:
     36  1. '''Изведувачи:''' `Performer` како база, со `Musical_Performer` и `Acting_Performer` како подтипови.
     37  2. '''Настани:''' `Event` како база, со `Concert` и `Play` како подтипови.
     38 * '''Аргументација:''' Ова овозможува базата да биде екстремно флексибилна. Музичките изведувачи имаат жанр и издавачка куќа, додека театарските имаат улоги и агенции, а сепак сите се менаџираат унифицирано преку главната табела на изведувачи. Истата логика овозможува системот за билети да работи идентично за концерти и за претстави.
    3939
    40 === 5. Сегмент: Финансиска безбедност и рефундација (Ticket_Refund) ===
     40 5. Сегмент: Финансиска безбедност и рефундација (Ticket_Refund)
    4141
    42 * '''Како и зошто:''' Табелата за рефундација е поврзана со трансакцијата (`Ticket_Purchase`) преку релација со '''Unique Constraint''' на колоната `purchase_id`.
    43 * '''Аргументација:''' Со оваа логика физички се оневозможува за една иста трансакција (купување) да се вратат парите повеќе од еднаш. Ова е клучна заштита против финансиски манипулации или системски грешки, обезбедувајќи прецизно сметководствено следење на вратените средства.
     42 * '''Како и зошто:''' Табелата за рефундација е поврзана со трансакцијата (`Ticket_Purchase`) преку релација со '''Unique Constraint''' на колоната `purchase_id`.
     43 * '''Аргументација:''' Со оваа логика физички се оневозможува за една иста трансакција (купување) да се вратат парите повеќе од еднаш. Ова е клучна заштита против финансиски манипулации или системски грешки, обезбедувајќи прецизно сметководствено следење на вратените средства.