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

ЕР Дијаграм

Дополнителен Опис

Релациониот модел е строго модуларен и е поделен на четири главни потсистеми: Identity (корисници и улоги), Catalog (производи и категории), Inventory & Fulfillment (складирање и физички примероци) и Sales & Engagement (продажба и корисничка интеракција). Оваа поделба овозможува висока скалабилност и полесно одржување на интегритетот на податоците.

Модул за Идентитет (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, што овозможува еден корисник да има повеќекратни улоги во системот.

Каталог и Варијанти (Catalog & Product): Моделот користи напредна хиерархија за производите:

CATEGORIES користи „self-reference“ (parent_category_id) за креирање на неограничени нивоа на категории и подкатегории.

PRODUCTS го чува општиот концепт на производот (бренд, опис), додека PRODUCT_VARIANTS е клучната табела каде се дефинираат специфичните варијации (боја, меморија) со сопствен SKU и цена.

За дополнителна флексибилност, користиме EAV (Entity-Attribute-Value) пристап преку табелите PRODUCT_ATTRIBUTES и PRODUCT_ATTRIBUTE_VALUES, што овозможува додавање на нови карактеристики за производите без промена на шемата на базата.

Инвентар и Серијализација (Inventory & Fulfillment): Ова е јадрото на системот каде се прави дистинкција помеѓу логичка и физичка залиха:

INVENTORY_ITEM ја чува агрегираната количина по магацин и варијанта.

PRODUCT_INSTANCE е ентитетот кој го следи секој поединечен физички артикл преку serial_number. Ова е клучно за бизнис логиката на BlinkBuy, бидејќи овозможува точно следење на гаранциите (WARRANTY) по парче.

Табелата ORDER_ITEM_ALLOCATIONS служи како bridge помеѓу продадената ставка (ORDER_ITEMS) и конкретниот физички примерок. Ова овозможува поддршка на quantity > 1 во нарачката, додека во позадина се алоцираат соодветен број на различни физички инстанци.

Продажба и Логистика (Sales & Shipping):

SHOPPING_CART работи исклучиво на ниво на варијанта (variant_id) за да се оптимизираат перформансите.

PAYMENTS табелата дозволува повеќе записи за една нарачка, поддржувајќи логика на повторни обиди при неуспешно плаќање (retries).

SHIPMENTS и SHIPMENT_ITEMS овозможуваат една нарачка да биде поделена во повеќе пратки (split shipments) доколку производите се наоѓаат во различни магацини на продавачот.

Ограничувања и Интегритет (Integrity Rules): Во моделот се применети строги правила за бришење на податоци:

CASCADE: Се применува кај ентитети кои немаат смисла без својот родител, како што се USER_SESSIONS, USER_NOTIFICATIONS и WISHLIST_ITEMS. Кога корисникот се брише, овие записи автоматски се чистат.

RESTRICT: Се користи за клучни деловни записи. На пример, не може да се избрише варијанта на производ ако за неа постои историја на цени (PRODUCT_PRICE_HISTORY) или ако е веќе дел од реализирана нарачка (ORDER_ITEMS), со цел да се зачува ревизорската трага (audit trail) на системот.