Relational Model

Relational diagram

Descriptive documentation and argumentation

Овој релационен модел е дизајниран да поддржи комплексен систем за менаџирање со настани и продажба на билети (EventMK), со строг фокус на нормализација, релациски интегритет и користење на CHECK ограничувања за спречување на податочни аномалии.

Во продолжение се образложени специфичните логички сегменти од моделот:

• Модел сегмент за Актори (User, Organizer, Staff): Наместо една генеричка табела, корисничките улоги се нормализирани во посебни ентитети бидејќи имаат различна бизнис логика. Крајните купувачи се чуваат во "User" табелата со посебна поврзана зависна табела User_verification за следење на статусот на верификација. Организаторите се издвоени во Organizer, додека персоналот е во Staff (директно врзан за конкретен настан со специфична улога).

• Модел сегмент за Инфраструктура (Venue, City, Address, Parking): Локацијата е детално нормализирана. Градовите (City) и адресите (Address) се посебни табели поврзани со главниот објект (Venue). За секоја локација се води евиденција и за паркинг просторот (Parking), каде преку строги CHECK ограничувања се контролира максималниот капацитет и моменталната достапност.

• Модел сегмент за Резервации и Билети (Reservation, Payment, Ticket, Section): Процесот на купување е реализиран преку трансакциско заглавие Reservation поврзано со Payment. Самите билети (Ticket) се директно врзани за резервацијата, настанот и конкретниот сектор (Section) кој ја диктира цената. Секој билет е уникатен ред со serial_number, qr_code и is_used флег (за спречување на двоен влез). Во Payment табелата се имплементирани опционални надворешни клучеви кон Discount и Refund, што овозможува флексибилна финансиска евиденција.

• Модел сегмент за Програма (Event, Performance, Performer): Самата програма на настанот е хиерархиски структурирана. Настанот (Event) е составен од временски блокови (Performance со почеток и крај). Бидејќи еден изведувач (Performer) може да настапува на повеќе настапи, а еден настап да има повеќе изведувачи, креирана е M:N поврзувачка табела Performer_Performance. Дополнително, секој изведувач си ја води својата програма преку табелата Setlist.

• M:N Релации: Моделот вклучува и дополнителни табели за разрешување на M:N врски кои се клучни за флексибилноста на системот, како на пример Organizer_Venue (еден организатор менаџира повеќе локации и обратно) и Sponsor_Event (спонзорства на настаните).