Релационен модел

ЕР Дијаграм

Дополнителен Опис

• Предложениот модел претставува систем за посредување помеѓу клиенти и музички изведувачи, каде што корисниците можат да креираат барања за настани, а изведувачите да одговорат со понуди. Основниот тек на системот е организиран преку следната логика: Request → Offer → Booking → Payment → Review

• Сегмент: Request, Offer и Booking
• Табелите Request, Offer и Booking го претставуваат основниот процес на резервација.
  • Request ги содржи сите информации за настанот (датум, време, буџет, локација, тип на настан).
  • Offer претставува одговор од изведувач на конкретен request и содржи предложена цена, траење и дополнителни трошоци.
  • Booking се креира само кога една понуда е прифатена.
• Важно е што Booking содржи само offer_id како foreign key, наместо директно да ги содржи request_id, client_id и bookable_id. Ова е направено со цел да се избегне редундантност, бидејќи сите овие информации можат индиректно да се добијат преку Offer.

• Songs(published_by_artist_id, published_by_label_admin_id)[*] - информација за кој ја објавил песната
• Albums(published_by_artist_id, published_by_label_admin_id) - информација за кој го објавил албумот
• Resource_Shares(song_id, playlist_id, album_id) - ресурс на кој се однесува дадената дозвола
• Resource_Shares(user_id, role_id) - дали улогата ја додаваме на конкретен корисник или на одредена ролја

За секое од наведените подмножества има меѓусебна исклучивост, поточно точно еден од клучевите мора да биде non-null. Ова не можеме да го опфатиме во релациониот модел, но истото ќе биде опфатено понатаму во DDL скриптата.

[*] Во дијаграмот има грешка при именување на вториот атрибут (Label_Adminsid треба да биде published_by_label_admin_id).

• Чуваме табели Playback_Sessions и Song_Streams. Причината за ова е бидејќи Playback_Sessions ги чува сите сесии каде некој корисник слушал некоја песна, макар и да ја слушал само неколку секунди или ја прескокнал додека барал некоја друга. Јасно е дека доколку ова го чуваме како едно слушање на песната ќе води до многу инфлаторни податоци, па затоа ќе поставиме одреден праг кој треба да се постигне за една сесија да се смета за валидно слушање (пр. 30 секунди). За секоја од овие валидни сесии при надминување на прагот ќе следи запис во Song_Streams табелата. Оваа табела намерно е денормализирана (содржи редундантни податоци за streamed_at, song_id кои би можеле да се земат и со join преку playback_session_id) со цел сите аналитики околу бројот на слушања да се прават директно на оваа табела бидејќи нема да ги содржи оние записи коишто не ни се од интерес.

• Song_Relationships табелата служи за опфаќање на различни изданија од песни - нешто како Remix, Cover, Only Instrumental и слично, што е честа практика во индустријата. Ова би се постигнало преку додавање на нов запис во Songs со новото издание на песната, а потоа додавање на соодветен запис во Song_Relationships, каде relationship_type ја опишува релацијата за која станува збор, пример некој од горенаведените термини.