Changes between Version 22 and Version 23 of RelationalModel
- Timestamp:
- 04/21/26 01:10:02 (12 days ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
RelationalModel
v22 v23 16 16 Во овој дел се подетално објаснети специфичните сегменти од моделот кои содржат напредна логика или решенија за специфични бизнис проблеми. 17 17 18 1. Сегмент: Животен циклус на билет и Продажба (Ticket vs. Ticket_Purchase) 18 '''1. Сегмент: Животен циклус на билет и Продажба (Ticket vs. Ticket_Purchase)''' 19 19 20 20 * '''Како и зошто:''' Моделот прави јасна разделба помеѓу инвентарот на седишта (`Ticket`) и реализираната трансакција (`Ticket_Purchase`). Табелата `Ticket` ги содржи сите потенцијални места за еден настан, додека `Ticket_Purchase` е запис за купување кој содржи уникатен `qr_code`. Релацијата е дефинирана како '''1:N''' помеѓу билетот и купувањата. 21 21 * '''Аргументација:''' Оваа структура овозможува '''повторна продажба на исто седиште'''. Кога еден билет ќе се рефундира, неговиот статус се враќа во „слободен“, а во `Ticket_Purchase` се дозволува нов запис за следниот купувач. Со тоа се чува целосна историја на сопственост врз едно седиште низ времето. 22 22 23 2. Сегмент: Динамично ценообразовање и фази (Event_Period) 23 '''2. Сегмент: Динамично ценообразовање и фази (Event_Period)''' 24 24 25 25 * '''Како и зошто:''' Наместо фиксна цена, воведовме табела `Event_Period` поврзана со случувањето на настанот (`Event_Happening`). Секој период има дефиниран процент на промена и насока (`increase_decrease` булеан). Поставена е '''UNIQUE''' заштита врз `(event_happening_id, name)`. 26 26 * '''Аргументација:''' Ова овозможува системот автоматски да ги менаџира цените во зависност од временските периоди (пр. "Early Bird" попусти или "Last Minute" поскапувања). Уникатниот клуч спречува логички грешки каде еден настан би имал две различни ценовни правила со исто име. 27 27 28 3. Сегмент: Хиерархија и Интегритет на локации (Venue -> Section -> Seat) 28 '''3. Сегмент: Хиерархија и Интегритет на локации (Venue -> Section -> Seat)''' 29 29 30 30 * '''Како и зошто:''' Локациите се моделирани хиерархиски преку '''Identifying''' релации. Секое седиште е дефинирано преку композитен клуч кој ги вклучува неговата секција и сала. Дополнително, воведени се '''Unique''' констреинти врз имињата на секциите во рамки на една сала и броевите на седишта во рамки на една секција. 31 31 * '''Аргументација:''' Ова ја рефлектира реалната физичка поставеност на објектите и спречува дуплирање на сектори или седишта. Со ова се гарантира дека секој билет е врзан за прецизна и уникатна физичка локација во салата. 32 32 33 4. Сегмент: Специјализација на ентитети (Inheritance) 33 '''4. Сегмент: Специјализација на ентитети (Inheritance)''' 34 34 35 35 * '''Како и зошто:''' Користена е специјализација на два нивоа: … … 38 38 * '''Аргументација:''' Ова овозможува базата да биде екстремно флексибилна. Музичките изведувачи имаат жанр и издавачка куќа, додека театарските имаат улоги и агенции, а сепак сите се менаџираат унифицирано преку главната табела на изведувачи. Истата логика овозможува системот за билети да работи идентично за концерти и за претстави. 39 39 40 5. Сегмент: Финансиска безбедност и рефундација (Ticket_Refund) 40 '''5. Сегмент: Финансиска безбедност и рефундација (Ticket_Refund)''' 41 41 42 42 * '''Како и зошто:''' Табелата за рефундација е поврзана со трансакцијата (`Ticket_Purchase`) преку релација со '''Unique Constraint''' на колоната `purchase_id`.
