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

== ЕР Дијаграм

[[Image(RelationalModel-BlinkBuy.svg, 1400px)]]

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

- Релациониот модел е строго модуларен и е поделен на четири главни потсистеми: '''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) на системот.