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

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

Relational diagram

---

---

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

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.

Причина:

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