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

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

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

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

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