| | 1 | = Релационен модел |
| | 2 | |
| | 3 | == ЕР Дијаграм |
| | 4 | |
| | 5 | [[Image(RelationalModel-BlinkBuy.svg, 1400px)]] |
| | 6 | |
| | 7 | == Дополнителен Опис |
| | 8 | |
| | 9 | Релациониот модел е строго модуларен и е поделен на четири главни потсистеми: '''Identity''' (корисници и улоги), '''Catalog''' (производи и категории), '''Inventory & Fulfillment''' (складирање и физички примероци) и '''Sales & Engagement''' (продажба и корисничка интеракција). Оваа поделба овозможува висока скалабилност и полесно одржување на интегритетот на податоците. |
| | 10 | |
| | 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, што овозможува еден корисник да има повеќекратни улоги во системот. |
| | 12 | |
| | 13 | '''Каталог и Варијанти (Catalog & Product):''' Моделот користи напредна хиерархија за производите: |
| | 14 | |
| | 15 | CATEGORIES користи „self-reference“ (parent_category_id) за креирање на неограничени нивоа на категории и подкатегории. |
| | 16 | |
| | 17 | PRODUCTS го чува општиот концепт на производот (бренд, опис), додека PRODUCT_VARIANTS е клучната табела каде се дефинираат специфичните варијации (боја, меморија) со сопствен SKU и цена. |
| | 18 | |
| | 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) на системот. |
