Changes between Version 9 and Version 10 of RelationalModel

Timestamp:

04/20/26 01:56:12 (13 days ago)

Author:

231007

Comment:

--

RelationalModel

@@ -16 +16 @@
 == Детален опис на табелите
 
-1. User → Customer / Employee / Manager
-
-Моделот започнува со ентитетот user, кој ги содржи основните податоци за сите корисници (email, password, статус, датум на креирање).
-
-Наместо да се дуплираат овие податоци во повеќе табели, користен е пристап на наследување (generalization), при што customer, employee и manager се специјализации на user.
-
-Овој пристап е избран затоа што овозможува:
-
-централизирано управување со кориснички сметки
-избегнување на дуплирање на податоци
-можност за проширување (еден корисник потенцијално да има повеќе улоги)
-
-Секоја од овие табели содржи дополнителни атрибути специфични за улогата.
+
+'''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
+
+Ова овозможува:
+ * валидни рецензии
+ * спречување злоупотреба
+
+
+'''Заклучок'''
+
+Моделот обезбедува:
+ * нормализирана структура
+ * минимална редундантност
+ * флексибилност
+ * точна репрезентација на реални процеси
+
+Релациите не се користат само за поврзување, туку и за моделирање на бизнис логика и зависности.