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

ЕР Дијаграм

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

• Релациониот модел е строго модуларен и е поделен на четири главни потсистеми: 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и неговата локација во warehouse. Ова е важно за бизнис логиката на BlinkBuy, бидејќи овозможува точно следење на гаранциите (WARRANTY) по парче.

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

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