Changes between Version 11 and Version 12 of RelationalModel

Timestamp:

04/20/26 02:03:33 (13 days ago)

Author:

231007

Comment:

--

RelationalModel

@@ -17 +17 @@
 
 
-'''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 бидејќи:
- * еден менаџер може да управува со повеќе бизниси
- * еден бизнис може да има повеќе менаџери
+'''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-и
 
 Содржи:
@@ -70 +95 @@
  * valid_to
 
-Ова овозможува следење на историја и временска зависност.
-
-
-'''4. Business ↔ Employee (M:N)'''
-
-Релацијата '''business_employee''' ги поврзува вработените со бизнисите.
-
- * еден employee може да работи во повеќе бизниси
- * еден бизнис има повеќе вработени
+Причина:
+ * релацијата има временска компонента
+ * се чува историја
+
+
+'''8. Business ↔ Employee (M:N)'''
+
+Релацијата business_employee ги поврзува employee и business.
+
+ * employee може да работи во повеќе business-и
+ * business има повеќе employee-и
 
 Содржи:
@@ -84 +111 @@
  * date_finish
 
-Ова овозможува следење на периодот на ангажман.
-
-
-'''5. Service → Service Category (1:N)'''
-
-Секој service припаѓа на една категорија.
-
-Категоријата е посебен ентитет за:
+Причина:
+ * се моделира реален ангажман
+ * се овозможува tracking на историја
+
+
+'''9. Service → Service Category (1:N)'''
+
+Секој service припаѓа на една category.
+
+Причина:
+ * категоризација на услуги
  * избегнување на дуплирање
- * стандардизација
- * полесно проширување
-
-
-'''6. Business ↔ Service (M:N)'''
-
-Релацијата '''business_service''' содржи:
+ * подобра организација
+
+
+'''10. Business ↔ Service (M:N)'''
+
+Релацијата business_service ги поврзува 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
-
-Ова овозможува:
- * валидни рецензии
- * спречување злоупотреба
+Причина:
+ * цената не е фиксна за 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.
+
+Причина:
+ * гарантира валидност
+ * спречува лажни рецензии