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

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


'''Relational diagram'''

----

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



----

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


'''1. User → Customer (1:1)'''

Релацијата помеѓу user и customer е one-to-one.

Секој customer мора да биде user, но не секој user е customer.

Ова е моделирано преку наследување (generalization), каде customer ја проширува основната user структура.

Причина:
 * се избегнува дуплирање на login податоци
 * се задржува централизирана автентикација
 * се одвојува улогата од идентитетот


'''2. User → Employee (1:1)'''

Employee е специјализација на user.

Причина:
 * employee има дополнителни атрибути (bio, hire_date)
 * не секој user е employee


'''3. User → Manager (1:1)'''

Manager е специјализација на user.

Причина:
 * дефинира административна улога
 * овозможува контрола на пристап


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

Еден business може да има повеќе location записи.

Причина:
 * поддршка за повеќе филијали
 * адресата е составен атрибут


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

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

Причина:
 * варира по ден
 * овозможува флексибилност


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

Бизнисот има повеќе слики.

Причина:
 * секоја слика има сопствени атрибути


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

Релацијата business_manager е many-to-many.

 * еден manager може да управува повеќе business-и
 * еден business може да има повеќе manager-и

Содржи:
 * assigned_at
 * valid_to

Причина:
 * се моделира временска зависност


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

Релацијата business_employee ги поврзува employee и business.

 * employee може да работи во повеќе business-и
 * business има повеќе employee-и

Содржи:
 * date_start
 * date_finish

Причина:
 * следење на ангажман низ време


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

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

Причина:
 * логичка организација
 * избегнување на дуплирање


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

Релацијата business_service содржи:

 * price
 * duration_minutes
 * is_active

Причина:
 * овие атрибути зависат од business, не од service
 * релацијата има бизнис значење


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

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

Причина:
 * различни вработени имаат различни вештини


'''12. Business ↔ Specialty (M:N)'''

Релацијата business_specialty ги поврзува business и specialty.

Причина:
 * повеќе специјалности по business
 * избегнување на дуплирање


'''13. Employee ↔ Business Specialty (M:N)'''

Релацијата employee_business_specialty дефинира специјалност во контекст на business.

Причина:
 * специјалноста зависи од конкретен business


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

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

Причина:
 * различни смени
 * флексибилност


'''15. Working Schedule → Slot (1:N)'''

Slot претставува временски интервали.

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


'''16. Appointment → Customer (N:1)'''

Еден customer може да има повеќе appointments.

Причина:
 * повеќе резервации по корисник


'''17. Appointment → Employee (N:1)'''

Еден employee може да има повеќе appointments.

Причина:
 * извршување на повеќе услуги


'''18. Appointment → Business (N:1)'''

Appointment е поврзан со еден business.

Причина:
 * услугата се извршува во конкретен business


'''19. Appointment → Service (N:1)'''

Appointment е поврзан со конкретен service.

Причина:
 * јасна дефиниција на услугата


'''20. Appointment → Slot (N:1)'''

Appointment е врзан за slot.

Причина:
 * спречување преклопување
 * контрола на термини


'''21. Appointment → Cancellation (1:0..1)'''

Еден appointment може да има една cancellation или ниедна.

Cancellation е моделирана како посебен ентитет кој содржи:

 * reason
 * refund_amount
 * canceled_at

Причина:
 * не секој appointment има отказ
 * избегнување на null вредности во appointment
 * јасно раздвојување на активни и откажани резервации
 * можност за чување дополнителни информации поврзани со отказот

Оваа релација претставува optional зависност и е важна за бизнис логиката.


'''22. Appointment → Reschedule Request (1:N)'''

Еден appointment може да има повеќе барања за промена.

Причина:
 * корисник може повеќе пати да побара промена
 * се чува историја на промени


'''23. Review → Customer (N:1)'''

Еден customer може да остави повеќе reviews.

Причина:
 * повеќе искуства


'''24. Review → Employee (N:1)'''

Review е поврзан со вработениот што ја извршил услугата.

Причина:
 * овозможува оценување на конкретен вработен


'''25. Review → Business (N:1)'''

Review се однесува на business.

Причина:
 * оценување на услугата како целина


'''26. Review → Appointment (1:1 или N:1)'''

Review е врзан за конкретен appointment.

Причина:
 * гарантира валидност
 * спречува лажни рецензии