= Релационен Модел

== ЕР Дијаграм за системот


'''Relational diagram'''

----

[[Image(24.03.svg​, 800px, align=center)]]



----

== Детален опис на табелите


'''1. User → Customer / Employee / Manager'''

Ентитетот '''user''' претставува основа за сите типови корисници во системот. Ги содржи заедничките атрибути како email, password, статус и timestamps.

Наместо да се дуплираат овие податоци, применета е generalization структура:
 * customer
 * employee
 * manager

Овој пристап овозможува:
 * централизирана автентикација
 * избегнување на дуплирање
 * можност за проширување

Секоја специјализација содржи дополнителни атрибути специфични за улогата.


'''2. Business и основни зависности'''

'''Business → Location (1:N)'''

Еден бизнис може да има повеќе локации. Локацијата е моделирана како посебен ентитет бидејќи адресата содржи повеќе атрибути.

Ова овозможува:
 * нормализација
 * избегнување на повторување
 * поддршка за повеќе филијали


'''Business → Business Hours (1:N)'''

Работното време е издвоено во посебна табела бидејќи варира по ден и не може да се претстави како едноставен атрибут.

Ова овозможува:
 * флексибилност
 * лесно ажурирање


'''Business → Gallery (1:N)'''

Бизнисот може да има повеќе слики, при што секоја има сопствени атрибути (URL, опис, датум).


'''3. Business ↔ Manager (M:N)'''

Релацијата '''business_manager''' е many-to-many бидејќи:
 * еден менаџер може да управува со повеќе бизниси
 * еден бизнис може да има повеќе менаџери

Содржи:
 * assigned_at
 * valid_to

Ова овозможува следење на историја и временска зависност.


'''4. Business ↔ Employee (M:N)'''

Релацијата '''business_employee''' ги поврзува вработените со бизнисите.

 * еден employee може да работи во повеќе бизниси
 * еден бизнис има повеќе вработени

Содржи:
 * date_start
 * date_finish

Ова овозможува следење на периодот на ангажман.


'''5. Service → Service Category (1:N)'''

Секој service припаѓа на една категорија.

Категоријата е посебен ентитет за:
 * избегнување на дуплирање
 * стандардизација
 * полесно проширување


'''6. Business ↔ Service (M:N)'''

Релацијата '''business_service''' содржи:
 * price
 * duration_minutes
 * is_active

Овие атрибути зависат од конкретниот бизнис.

Релацијата има сопствено значење и претставува дел од бизнис логиката.


'''7. Employee ↔ Service (M:N)'''

Релацијата '''employee_service''' дефинира кои услуги може да ги извршува секој вработен.

Ова е потребно бидејќи:
 * не сите вработени имаат исти вештини
 * услугите бараат специфични способности


'''8. Specialties'''

Се користи ентитет '''specialty''' и поврзувачки табели:
 * business_specialty
 * employee_business_specialty

Ова е затоа што:
 * специјалностите се мултивредносни
 * се избегнува дуплирање


'''9. Working Schedule и Slot'''

'''Employee → Working Schedule (1:N)'''

Работното време е моделирано како посебна табела со записи по ден.

Ова овозможува:
 * различни смени
 * динамичко управување


'''Slot'''

Ентитетот slot претставува временски интервали за закажување.

Се користи за:
 * проверка на достапност
 * управување со термини


'''10. Appointment'''

Ентитетот '''appointment''' е централен дел од системот.

Ги поврзува:
 * customer
 * employee
 * business
 * service
 * slot

Ова овозможува јасна структура и лесен пристап до податоци.


'''11. Cancellation'''

Ентитетот '''cancellation''' е поврзан со appointment.

Не секој appointment има cancellation, па затоа е издвоен.

Содржи:
 * reason
 * refund_amount

Ова овозможува јасна логика за откажувања.


'''12. Reschedule Request'''

Ентитетот '''reschedule_request''' се користи за промена на термин.

Наместо директно ажурирање, се креира нов запис.

Ова овозможува:
 * следење на историја
 * контрола на процесот


'''13. Review'''

Ентитетот '''review''' ги поврзува:
 * customer
 * employee
 * business
 * appointment

Ова овозможува:
 * валидни рецензии
 * спречување злоупотреба