Changes between Version 7 and Version 8 of RelationalModel


Ignore:
Timestamp:
04/20/26 00:11:48 (13 days ago)
Author:
231088
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • RelationalModel

    v7 v8  
    1010
    1111- Сегмент: Request, Offer и Booking
    12 - Табелите Request, Offer и Booking го претставуваат основниот процес на резервација.
    13    - Request ги содржи сите информации за настанот (датум, време, буџет, локација, тип на настан).
    14    - Offer претставува одговор од изведувач на конкретен request и содржи предложена цена, траење и дополнителни трошоци.
    15    - Booking се креира само кога една понуда е прифатена.
     12- Табелите `Request, Offer и Booking` го претставуваат основниот процес на резервација.
     13   - `Request` ги содржи сите информации за настанот (датум, време, буџет, локација, тип на настан).
     14   - `Offer` претставува одговор од изведувач на конкретен request и содржи предложена цена, траење и дополнителни трошоци.
     15   - `Booking` се креира само кога една понуда е прифатена.
    1616- Важно е што Booking содржи само offer_id како foreign key, наместо директно да ги содржи request_id, client_id и bookable_id. Ова е направено со цел да се избегне редундантност, бидејќи сите овие информации можат индиректно да се добијат преку Offer.
    1717 
    18    - `Songs(published_by_artist_id, published_by_label_admin_id)`[*] - информација за кој ја објавил песната
    19    - `Albums(published_by_artist_id, published_by_label_admin_id)` - информација за кој го објавил албумот
    20    - `Resource_Shares(song_id, playlist_id, album_id)` - ресурс на кој се однесува дадената дозвола
    21    - `Resource_Shares(user_id, role_id)` - дали улогата ја додаваме на конкретен корисник или на одредена ролја
     18 
    2219
    23 За секое од наведените подмножества има меѓусебна исклучивост, поточно точно еден од клучевите мора да биде non-null. Ова не можеме да го опфатиме во релациониот модел, но истото ќе биде опфатено понатаму во DDL скриптата.
    2420
    25 [*] Во дијаграмот има грешка при именување на вториот атрибут (`Label_Adminsid` треба да биде `published_by_label_admin_id`).
    26 
    27 - Чуваме табели `Playback_Sessions` и `Song_Streams`. Причината за ова е бидејќи `Playback_Sessions` ги чува сите сесии каде некој корисник слушал некоја песна, макар и да ја слушал само неколку секунди или ја прескокнал додека барал некоја друга. Јасно е дека доколку ова го чуваме како едно слушање на песната ќе води до многу инфлаторни податоци, па затоа ќе поставиме одреден праг кој треба да се постигне за една сесија да се смета за валидно слушање (пр. 30 секунди). За секоја од овие валидни сесии при надминување на прагот ќе следи запис во `Song_Streams` табелата. Оваа табела намерно е денормализирана (содржи редундантни податоци за `streamed_at`, `song_id` кои би можеле да се земат и со join преку `playback_session_id`) со цел сите аналитики околу бројот на слушања да се прават директно на оваа табела бидејќи нема да ги содржи оние записи коишто не ни се од интерес.
    28 
    29 - `Song_Relationships` табелата служи за опфаќање на различни изданија од песни - нешто како Remix, Cover, Only Instrumental и слично, што е честа практика во индустријата. Ова би се постигнало преку додавање на нов запис во `Songs` со новото издание на песната, а потоа додавање на соодветен запис во `Song_Relationships`, каде `relationship_type` ја опишува релацијата за која станува збор, пример некој од горенаведените термини.
    30