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

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

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)

Слично како 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.

Причина:

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