Changes between Version 23 and Version 24 of RelationalModel


Ignore:
Timestamp:
04/21/26 11:10:23 (11 days ago)
Author:
231027
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • RelationalModel

    v23 v24  
    2323'''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`: 1 - покачување на цените за тој процент, 0 - намалување на цените за тој процент).
     26 * '''Аргументација:''' Ова овозможува системот автоматски да ги менаџира цените во зависност од временските периоди (пр. "Early Bird" попусти или "Last Minute" поскапувања).
    2727
    2828'''3. Сегмент: Хиерархија и Интегритет на локации (Venue -> Section -> Seat)'''
    2929
    30  * '''Како и зошто:''' Локациите се моделирани хиерархиски преку '''Identifying''' релации. Секое седиште е дефинирано преку композитен клуч кој ги вклучува неговата секција и сала. Дополнително, воведени се '''Unique''' констреинти врз имињата на секциите во рамки на една сала и броевите на седишта во рамки на една секција.
     30 * '''Како и зошто:''' Локациите се моделирани хиерархиски преку '''Identifying''' релации. Секое седиште е дефинирано преку композитен клуч кој ги вклучува неговата секција и сала.
    3131 * '''Аргументација:''' Ова ја рефлектира реалната физичка поставеност на објектите и спречува дуплирање на сектори или седишта. Со ова се гарантира дека секој билет е врзан за прецизна и уникатна физичка локација во салата.
    3232
    … …  
    3434
    3535 * '''Како и зошто:''' Користена е специјализација на два нивоа:
    36   1. '''Изведувачи:''' `Performer` како база, со `Musical_Performer` и `Acting_Performer` како подтипови.
    37   2. '''Настани:''' `Event` како база, со `Concert` и `Play` како подтипови.
     36  1. '''Изведувачи:''' `Performer` како основна табела, со `Musical_Performer` и `Acting_Performer` како подтипови.
     37  2. '''Настани:''' `Event` како основна табела, со `Concert` и `Play` како подтипови.
    3838 * '''Аргументација:''' Ова овозможува базата да биде екстремно флексибилна. Музичките изведувачи имаат жанр и издавачка куќа, додека театарските имаат улоги и агенции, а сепак сите се менаџираат унифицирано преку главната табела на изведувачи. Истата логика овозможува системот за билети да работи идентично за концерти и за претстави.
    3939
    4040'''5. Сегмент: Финансиска безбедност и рефундација (Ticket_Refund)'''
    4141
    42  * '''Како и зошто:''' Табелата за рефундација е поврзана со трансакцијата (`Ticket_Purchase`) преку релација со '''Unique Constraint''' на колоната `purchase_id`.
     42 * '''Како и зошто:''' Табелата за рефундација е поврзана со трансакцијата (`Ticket_Purchase`) преку `purchase_id`.
    4343 * '''Аргументација:''' Со оваа логика физички се оневозможува за една иста трансакција (купување) да се вратат парите повеќе од еднаш. Ова е клучна заштита против финансиски манипулации или системски грешки, обезбедувајќи прецизно сметководствено следење на вратените средства.