Changes between Version 16 and Version 17 of RelationalModel


Ignore:
Timestamp:
04/21/26 17:59:45 (11 days ago)
Author:
231184
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • RelationalModel

    v16 v17  
    1616== Детален опис на табелите
    1717
     18= Детален опис на ER дијаграмот =
    1819
    19 '''1. User → Customer (1:1)'''
     20Ентитет-релациониот модел за системот „Резерво“ е дизајниран со цел да обезбеди флексибилна и скалабилна платформа за управување со закажување на услуги во мали бизниси. Основната архитектура се базира на јасна поделба помеѓу корисници, бизниси, услуги и термини, при што се користат принципи на нормализација и избегнување на дуплирање на податоци.
    2021
    21 Релацијата помеѓу user и customer е one-to-one.
     22Во основата на системот се наоѓа ентитетот '''User''', кој претставува централен идентитет за автентикација. Од него произлегуваат специјализирани ентитети како '''Customer''', '''Employee''' и '''Manager''', преку one-to-one релации. Овој пристап овозможува централизирано управување со кориснички податоци, додека во исто време се задржува флексибилност за дефинирање на различни улоги и нивните специфични атрибути.
    2223
    23 Секој customer мора да биде user, но не секој user е customer.
     24Ентитетот '''Business''' претставува организациска единица (на пример фризерски салон) и е поврзан со повеќе помошни ентитети. Бизнисот може да има повеќе локации, што е моделирано преку one-to-many релација со ентитетот '''Location''', со што се овозможува поддршка за повеќе филијали. Работното време е издвоено во посебен ентитет '''Business Hours''', со цел да се обезбеди флексибилност по денови и да се избегне сложена структура во самиот Business ентитет. Дополнително, бизнисот може да има повеќе слики преку ентитетот '''Gallery''', што овозможува подобра презентација.
    2425
    25 Ова е моделирано преку наследување (generalization), каде customer ја проширува основната user структура.
     26Релациите помеѓу бизнисите и корисниците со административни или извршни улоги се моделирани како many-to-many. Ентитетот '''Business_Manager''' овозможува еден менаџер да управува со повеќе бизниси и обратно, при што се чуваат и временски атрибути како период на важност. Слично, преку '''Business_Employee''' се следи ангажманот на вработените во различни бизниси низ време.
    2627
    27 Причина:
    28  * се избегнува дуплирање на login податоци
    29  * се задржува централизирана автентикација
    30  * се одвојува улогата од идентитетот
     28Услугите се моделирани преку ентитетот '''Service''', кој е поврзан со '''Service Category''' во one-to-many релација, што овозможува логичка организација и избегнување на дуплирање. Односот помеѓу бизнис и услуга е many-to-many, бидејќи иста услуга може да се нуди во повеќе бизниси, но со различна цена, времетраење или достапност. Затоа, релацијата '''Business_Service''' содржи дополнителни атрибути кои зависат од конкретниот бизнис.
    3129
     30Вработените и услугите исто така се поврзани преку many-to-many релација ('''Employee_Service'''), со што се дефинира кои услуги може да ги извршува секој вработен. Ова овозможува прецизно моделирање на вештини и капацитети.
    3231
    33 '''2. User → Employee (1:1)'''
     32Специјалностите се дополнителен слој на класификација, каде што бизнисите и вработените се поврзани преку соодветни релации. Ова овозможува детално опишување на експертизата во различни контексти.
    3433
    35 Employee е специјализација на user.
     34Работното време на вработените е моделирано преку ентитетот '''Working Schedule''', кој е поврзан со повеќе '''Slot''' записи. Slot-овите претставуваат временски интервали што директно се користат за управување со достапност и закажување.
    3635
    37 Причина:
    38  * employee има дополнителни атрибути (bio, hire_date)
    39  * не секој user е employee
     36Централниот ентитет во системот е '''Appointment''', кој ги поврзува customer, employee, business, service и slot. Овој ентитет претставува конкретна резервација и овозможува следење на сите релевантни информации за закажан термин. Релациите се дефинирани како many-to-one, бидејќи еден корисник, вработен или бизнис може да има повеќе термини.
    4037
     38Откажувањето на термините е моделирано преку посебен ентитет '''Cancellation''', кој е во optional one-to-one релација со '''Appointment'''. Овој пристап овозможува да се избегнат null вредности во главниот ентитет и да се зачуваат дополнителни информации како причина, време и износ за рефундација.
    4139
    42 '''3. User → Manager (1:1)'''
     40Промените на термините се следат преку ентитетот '''Reschedule Request''', кој е во one-to-many релација со '''Appointment'''. Ова овозможува чување на историја на сите обиди за промена на термин.
    4341
    44 Manager е специјализација на user.
     42Системот поддржува и механизам за оценување преку ентитетот '''Review''', кој е поврзан со customer, employee, business и appointment. На овој начин се гарантира дека секоја рецензија е валидна и поврзана со реална услуга, што спречува злоупотреби.
    4543
    46 Причина:
    47  * дефинира административна улога
    48  * овозможува контрола на пристап
    49 
    50 
    51 '''4. Business → Location (1:N)'''
    52 
    53 Еден business може да има повеќе location записи.
    54 
    55 Причина:
    56  * поддршка за повеќе филијали
    57  * адресата е составен атрибут
    58 
    59 
    60 '''5. Business → Business Hours (1:N)'''
    61 
    62 Работното време е издвоено во посебна табела.
    63 
    64 Причина:
    65  * варира по ден
    66  * овозможува флексибилност
    67 
    68 
    69 '''6. Business → Gallery (1:N)'''
    70 
    71 Бизнисот има повеќе слики.
    72 
    73 Причина:
    74  * секоја слика има сопствени атрибути
    75 
    76 
    77 '''7. Business ↔ Manager (M:N)'''
    78 
    79 Релацијата business_manager е many-to-many.
    80 
    81  * еден manager може да управува повеќе business-и
    82  * еден business може да има повеќе manager-и
    83 
    84 Содржи:
    85  * assigned_at
    86  * valid_to
    87 
    88 Причина:
    89  * се моделира временска зависност
    90 
    91 
    92 '''8. Business ↔ Employee (M:N)'''
    93 
    94 Релацијата business_employee ги поврзува employee и business.
    95 
    96  * employee може да работи во повеќе business-и
    97  * business има повеќе employee-и
    98 
    99 Содржи:
    100  * date_start
    101  * date_finish
    102 
    103 Причина:
    104  * следење на ангажман низ време
    105 
    106 
    107 '''9. Service → Service Category (1:N)'''
    108 
    109 Секој service припаѓа на една category.
    110 
    111 Причина:
    112  * логичка организација
    113  * избегнување на дуплирање
    114 
    115 
    116 '''10. Business ↔ Service (M:N)'''
    117 
    118 Релацијата business_service содржи:
    119 
    120  * price
    121  * duration_minutes
    122  * is_active
    123 
    124 Причина:
    125  * овие атрибути зависат од business, не од service
    126  * релацијата има бизнис значење
    127 
    128 
    129 '''11. Employee ↔ Service (M:N)'''
    130 
    131 Релацијата employee_service дефинира кои услуги може да ги извршува employee.
    132 
    133 Причина:
    134  * различни вработени имаат различни вештини
    135 
    136 
    137 '''12. Business ↔ Specialty (M:N)'''
    138 
    139 Релацијата business_specialty ги поврзува business и specialty.
    140 
    141 Причина:
    142  * повеќе специјалности по business
    143  * избегнување на дуплирање
    144 
    145 
    146 '''13. Employee ↔ Business Specialty (M:N)'''
    147 
    148 Релацијата employee_business_specialty дефинира специјалност во контекст на business.
    149 
    150 Причина:
    151  * специјалноста зависи од конкретен business
    152 
    153 
    154 '''14. Employee → Working Schedule (1:N)'''
    155 
    156 Еден employee има повеќе записи за работно време.
    157 
    158 Причина:
    159  * различни смени
    160  * флексибилност
    161 
    162 
    163 '''15. Working Schedule → Slot (1:N)'''
    164 
    165 Slot претставува временски интервали.
    166 
    167 Причина:
    168  * управување со достапност
    169  * олеснување на закажување
    170 
    171 
    172 '''16. Appointment → Customer (N:1)'''
    173 
    174 Еден customer може да има повеќе appointments.
    175 
    176 Причина:
    177  * повеќе резервации по корисник
    178 
    179 
    180 '''17. Appointment → Employee (N:1)'''
    181 
    182 Еден employee може да има повеќе appointments.
    183 
    184 Причина:
    185  * извршување на повеќе услуги
    186 
    187 
    188 '''18. Appointment → Business (N:1)'''
    189 
    190 Appointment е поврзан со еден business.
    191 
    192 Причина:
    193  * услугата се извршува во конкретен business
    194 
    195 
    196 '''19. Appointment → Service (N:1)'''
    197 
    198 Appointment е поврзан со конкретен service.
    199 
    200 Причина:
    201  * јасна дефиниција на услугата
    202 
    203 
    204 '''20. Appointment → Slot (N:1)'''
    205 
    206 Appointment е врзан за slot.
    207 
    208 Причина:
    209  * спречување преклопување
    210  * контрола на термини
    211 
    212 
    213 '''21. Appointment → Cancellation (1:0..1)'''
    214 
    215 Еден appointment може да има една cancellation или ниедна.
    216 
    217 Cancellation е моделирана како посебен ентитет кој содржи:
    218 
    219  * reason
    220  * refund_amount
    221  * canceled_at
    222 
    223 Причина:
    224  * не секој appointment има отказ
    225  * избегнување на null вредности во appointment
    226  * јасно раздвојување на активни и откажани резервации
    227  * можност за чување дополнителни информации поврзани со отказот
    228 
    229 Оваа релација претставува optional зависност и е важна за бизнис логиката.
    230 
    231 
    232 '''22. Appointment → Reschedule Request (1:N)'''
    233 
    234 Еден appointment може да има повеќе барања за промена.
    235 
    236 Причина:
    237  * корисник може повеќе пати да побара промена
    238  * се чува историја на промени
    239 
    240 
    241 '''23. Review → Customer (N:1)'''
    242 
    243 Еден customer може да остави повеќе reviews.
    244 
    245 Причина:
    246  * повеќе искуства
    247 
    248 
    249 '''24. Review → Employee (N:1)'''
    250 
    251 Review е поврзан со вработениот што ја извршил услугата.
    252 
    253 Причина:
    254  * овозможува оценување на конкретен вработен
    255 
    256 
    257 '''25. Review → Business (N:1)'''
    258 
    259 Review се однесува на business.
    260 
    261 Причина:
    262  * оценување на услугата како целина
    263 
    264 
    265 '''26. Review → Appointment (1:1 или N:1)'''
    266 
    267 Review е врзан за конкретен appointment.
    268 
    269 Причина:
    270  * гарантира валидност
    271  * спречува лажни рецензии
     44Целиот модел е дизајниран со цел да обезбеди висока флексибилност, минимална редундантност и лесна прилагодливост за различни типови бизниси кои работат со закажување на услуги.