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

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


'''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)'''

Слично како customer, employee е специјализација на user.

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

Ова овозможува јасна поделба на улоги.


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

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

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

Овој модел овозможува scalability.


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

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

Причина:
 * бизнисите може да имаат повеќе филијали
 * адресата е составен атрибут (улица, град, телефон)

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


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

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

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

Ова овозможува динамички распоред.


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

Еден business има повеќе слики.

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


'''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

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


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

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

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


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

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

Содржи:
 * price
 * duration_minutes
 * is_active

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


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

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

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


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

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

Причина:
 * еден business може да има повеќе специјалности
 * специјалностите се делат помеѓу повеќе business-и


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

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

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


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

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

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


'''15. Working Schedule → Slot (1:N или деривација)'''

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

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


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

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

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


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

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

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


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

Секој appointment е поврзан со еден business.

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


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

Appointment е поврзан со конкретна услуга.

Причина:
 * јасна дефиниција што се извршува


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

Appointment е врзан за конкретен временски слот.

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


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

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

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


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

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

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


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

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

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


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

Review е поврзан со employee.

Причина:
 * оценување на извршител


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

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

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


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

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

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