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

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

Relational diagram

---

---

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

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

Ова овозможува:

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

Заклучок

Моделот обезбедува:

• нормализирана структура
• минимална редундантност
• флексибилност
• точна репрезентација на реални процеси

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