Changes between Version 1 and Version 2 of RelationalModel


Ignore:
Timestamp:
04/20/26 00:03:19 (13 days ago)
Author:
231169
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • RelationalModel

    v1 v2  
    77== Дополнителен Опис
    88
    9     Релациониот модел е строго модуларен и е поделен на четири главни потсистеми: '''Identity''' (корисници и улоги), '''Catalog''' (производи и категории), '''Inventory & Fulfillment''' (складирање и физички примероци) и '''Sales & Engagement''' (продажба и корисничка интеракција). Оваа поделба овозможува висока скалабилност и полесно одржување на интегритетот на податоците.
     9- Релациониот модел е строго модуларен и е поделен на четири главни потсистеми: '''Identity''' (корисници и улоги), '''Catalog''' (производи и категории), '''Inventory & Fulfillment''' (складирање и физички примероци) и '''Sales & Engagement''' (продажба и корисничка интеракција). Оваа поделба овозможува висока скалабилност и полесно одржување на интегритетот на податоците.
    1010
    11     '''Модул за Идентитет (Identity):''' Централниот ентитет е табелата USERS, која е разделена од USER_PROFILES. Оваа нормализација е направена со цел автентикациските податоци (email, password_hash) да бидат изолирани од личните податоци (first_name, last_name, profile_picture_url). Врската е 1:1, каде user_id во профилот е UNIQUE. Улогите (admin, customer, seller) се чуваат во шифрарникот ROLES и се доделуваат преку меѓутабелата USER_ROLES, што овозможува еден корисник да има повеќекратни улоги во системот.
     11- '''Модул за Идентитет (Identity):''' Централниот ентитет е табелата `USERS`, која е разделена од `USER_PROFILES`. Оваа нормализација е направена со цел автентикациските податоци (`email`, `password_hash`) да бидат изолирани од личните податоци (`first_name`, `last_name`, `phone_number`). Врската е 1:1, каде `user_id` во профилот е UNIQUE. Улогите (admin, customer, seller) се чуваат во шифрарникот `ROLES` и се доделуваат преку меѓутабелата `USER_ROLES`, што овозможува еден корисник да има повеќекратни улоги во системот.
    1212
    13     '''Каталог и Варијанти (Catalog & Product):''' Моделот користи напредна хиерархија за производите:
     13- '''Каталог и Варијанти (Catalog & Product):''' Моделот користи напредна хиерархија за производите:
     14    - Табелата `CATEGORIES` користи „self-reference“ (`parent_category_id`) за креирање на неограничени нивоа на категории и подкатегории.
     15    - `PRODUCTS` го чува општиот концепт на производот (бренд, опис), додека `PRODUCT_VARIANTS` е клучната табела каде се дефинираат специфичните варијации (боја, меморија) со сопствен SKU и цена.
     16    - За дополнителна флексибилност, користиме '''EAV (Entity-Attribute-Value)''' пристап преку табелите `PRODUCT_ATTRIBUTES` и `PRODUCT_ATTRIBUTE_VALUES`, што овозможува додавање на нови карактеристики за производите без промена на шемата на базата.
    1417
    15         CATEGORIES користи „self-reference“ (parent_category_id) за креирање на неограничени нивоа на категории и подкатегории.
     18- '''Инвентар и Серијализација (Inventory & Fulfillment):''' Ова е јадрото на системот каде се прави дистинкција помеѓу логичка и физичка залиха:
     19    - `INVENTORY_ITEM` ја чува агрегираната количина по магацин и варијанта.
     20    - `PRODUCT_INSTANCE` е ентитетот кој го следи секој поединечен физички артикл преку `serial_number`. Ова е клучно за бизнис логиката на BlinkBuy, бидејќи овозможува точно следење на гаранциите (`WARRANTY`) по парче.
     21    - Табелата `ORDER_ITEM_ALLOCATIONS` служи како '''bridge''' помеѓу продадената ставка (`ORDER_ITEMS`) и конкретниот физички примерок (`PRODUCT_INSTANCE`). Ова овозможува поддршка на `quantity` > 1 во нарачката, додека во позадина се алоцираат соодветен број на различни физички инстанци.
    1622
    17         PRODUCTS го чува општиот концепт на производот (бренд, опис), додека PRODUCT_VARIANTS е клучната табела каде се дефинираат специфичните варијации (боја, меморија) со сопствен SKU и цена.
     23- '''Продажба и Логистика (Sales & Shipping):'''
     24    - `SHOPPING_CART` работи исклучиво на ниво на варијанта (`variant_id`) за да се оптимизираат перформансите и да се избегне предвремено резервирање на сериски броеви во фаза на купување.
     25    - `PAYMENTS` табелата дозволува повеќе записи за една нарачка, поддржувајќи логика на повторни обиди при неуспешно плаќање (retries).
     26    - `SHIPMENTS` и `SHIPMENT_ITEMS` овозможуваат една нарачка да биде поделена во повеќе пратки (split shipments) доколку производите се наоѓаат во различни магацини (`WAREHOUSES`) на продавачот.
    1827
    19         За дополнителна флексибилност, користиме '''EAV (Entity-Attribute-Value)''' пристап преку табелите PRODUCT_ATTRIBUTES и PRODUCT_ATTRIBUTE_VALUES, што овозможува додавање на нови карактеристики за производите без промена на шемата на базата.
    20 
    21     '''Инвентар и Серијализација (Inventory & Fulfillment):''' Ова е јадрото на системот каде се прави дистинкција помеѓу логичка и физичка залиха:
    22 
    23         INVENTORY_ITEM ја чува агрегираната количина по магацин и варијанта.
    24 
    25         PRODUCT_INSTANCE е ентитетот кој го следи секој поединечен физички артикл преку serial_number. Ова е клучно за бизнис логиката на BlinkBuy, бидејќи овозможува точно следење на гаранциите (WARRANTY) по парче.
    26 
    27         Табелата ORDER_ITEM_ALLOCATIONS служи како '''bridge''' помеѓу продадената ставка (ORDER_ITEMS) и конкретниот физички примерок. Ова овозможува поддршка на quantity > 1 во нарачката, додека во позадина се алоцираат соодветен број на различни физички инстанци.
    28 
    29     '''Продажба и Логистика (Sales & Shipping):'''
    30 
    31         SHOPPING_CART работи исклучиво на ниво на варијанта (variant_id) за да се оптимизираат перформансите.
    32 
    33         PAYMENTS табелата дозволува повеќе записи за една нарачка, поддржувајќи логика на повторни обиди при неуспешно плаќање (retries).
    34 
    35         SHIPMENTS и SHIPMENT_ITEMS овозможуваат една нарачка да биде поделена во повеќе пратки (split shipments) доколку производите се наоѓаат во различни магацини на продавачот.
    36 
    37     '''Ограничувања и Интегритет (Integrity Rules):''' Во моделот се применети строги правила за бришење на податоци:
    38 
    39         '''CASCADE:''' Се применува кај ентитети кои немаат смисла без својот родител, како што се USER_SESSIONS, USER_NOTIFICATIONS и WISHLIST_ITEMS. Кога корисникот се брише, овие записи автоматски се чистат.
    40 
    41         '''RESTRICT:''' Се користи за клучни деловни записи. На пример, не може да се избрише варијанта на производ ако за неа постои историја на цени (PRODUCT_PRICE_HISTORY) или ако е веќе дел од реализирана нарачка (ORDER_ITEMS), со цел да се зачува ревизорската трага (audit trail) на системот.
     28- '''Ограничувања и Интегритет (Integrity Rules):''' Во моделот се применети строги правила за бришење на податоци:
     29    - '''CASCADE:''' Се применува кај ентитети кои немаат смисла без својот родител, како што се `USER_SESSIONS`, `USER_NOTIFICATIONS` и `WISHLIST_ITEMS`. Кога корисникот се брише, овие записи автоматски се чистат.
     30    - '''RESTRICT:''' Се користи за клучни деловни записи. На пример, не може да се избрише варијанта на производ ако за неа постои историја на цени (`PRODUCT_PRICE_HISTORY`) или ако е веќе дел од реализирана нарачка (`ORDER_ITEMS`), со цел да се зачува ревизорската трага (audit trail) на системот.