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

ЕР Дијаграм

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

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

• Модул за Идентитет (Identity): Централниот ентитет е табелата USERS, која е разделена од USER_PROFILES. Оваа нормализација е направена со цел автентикациските податоци (email, password_hash) да бидат изолирани од личните податоци (first_name, last_name, phone_number). Врската е 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 служи како мост помеѓу продадената ставка (ORDER_ITEMS) и конкретниот физички примерок (PRODUCT_INSTANCE). Ова овозможува поддршка на quantity > 1 во нарачката, додека во позадина се алоцираат соодветен број на различни физички инстанци.

• Продажба и Логистика (Sales & Shipping):
  • SHOPPING_CART работи исклучиво на ниво на варијанта (variant_id) за да се оптимизираат перформансите и да се избегне предвремено резервирање на сериски броеви во фаза на купување.
  • PAYMENTS табелата дозволува повеќе записи за една нарачка, поддржувајќи логика на повторни обиди при неуспешно плаќање.
  • SHIPMENTS и SHIPMENT_ITEMS овозможуваат една нарачка да биде поделена во повеќе пратки (split shipments) доколку производите се наоѓаат во различни магацини (WAREHOUSES) на продавачот.

• Ограничувања и Интегритет (Integrity Rules): Во моделот се применети строги правила за бришење на податоци:
  • CASCADE: Се применува кај ентитети кои немаат смисла без својот родител, како што се USER_SESSIONS, USER_NOTIFICATIONS и WISHLIST_ITEMS. Кога корисникот се брише, овие записи автоматски се чистат.
  • RESTRICT: Се користи за клучни деловни записи. На пример, не може да се избрише варијанта на производ ако за неа постои историја на цени (PRODUCT_PRICE_HISTORY) или ако е веќе дел од реализирана нарачка (ORDER_ITEMS), со цел да се зачува ревизорската трага (audit trail) на системот.