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

== ЕР Диаграм ==
[[Image(wims.png)]]


=== Visual Paradigm Project File ===
**[attachment:RelationalModel-WIMS.vpp]**
== Дополнителен Опис ==

=== 1. Производи (BRANDS, PRODUCTS, PRODUCT_VARIANTS, PRODUCT_IMAGES) ===
* Табелата **BRANDS** чува единствени имиња на производители или брендови. Се чуваат во посебна табела, бидејќи истиот бренд може да покрива стотици варијанти. Така се избегнува редундантност и се овозможува лесна промена на името на брендот на едно место. 
* Табелата **PRODUCTS** претставува логичка или „апстрактна" единица на производот, она што го опишуваме со ime и description, без физички карактеристики. Причината за ваквото разделување е тоа што, на пример, „Маица" е еден производ, но постои во повеќе бои, големини и брендови, а тоа се варијантите.
* Табелата **PRODUCT_VARIANTS** е централна точка за физичкото следење на залихи. Секоја варијанта носи SKU (уникатен идентификатор за набавка и складирање), баркод, цена, тежина, статус и врска до бренд и производ. Бидејќи залихите, движењата и сликите се врзуваат за конкретната варијанта (а не за апстрактниот производ), ова ни дава прецизност: знаеме не само дека имаме „маици" туку и колку „сини маици, XL, Adidas" точно се наоѓаат во кој бин.
* Табелата **PRODUCT_IMAGES** чува слики врзани директно за варијанта, не за производот, бидејќи различните варијанти визуелно изгледаат различно. Полето position овозможува подредување на сликите (прва, втора...).

=== 2.Категории (CATEGORIES, PRODUCT_CATEGORIES) ===
* Табелата **CATEGORIES** е самореференцирачка — секоја категорија може да има parent_id кој покажува на друга категорија во истата табела. Ова е класичен „adjacency list" модел за дрвести структури. На пример: Електроника → Телефони → Паметни телефони. 
* Табелата **PRODUCT_CATEGORIES** е врска многу-кон-многу помеѓу производите и категориите. Еден производ може да припаѓа на повеќе категории (на пример, „спортска облека" и „маици"), а една категорија може да содржи многу производи. Врската е дефинирана на ниво на производ (не варијанта), бидејќи категоризацијата е логичка, а не физичка карактеристика.

=== 3. Атрибути (ATTRIBUTES, ATTRIBUTE_VALUES, VARIANT_ATTRIBUTES) ===
* Табелата **ATTRIBUTES** дефинира тип на атрибут, неговиот тип на податок (data_type, на пример „string", „number") и евентуална единица мерка (unit, на пример „cm", „ml"). 
* Табелата **ATTRIBUTE_VALUES** чува конкретни вредности за секој атрибут (на пример, за атрибутот „Боја": „Црвена", „Сина", „Зелена").
* Табелата **VARIANT_ATTRIBUTES** ги поврзува варијантите со нивните конкретни вредности на атрибути.

=== 4. Магацинска структура (WAREHOUSES, SECTIONS, LOCATIONS, BINS) ===
* Табелата **WAREHOUSES** претставува физичка градба или просторија. Секој магацин има уникатно име, адреса, град и земја корисно при проширување на системот кон повеќелокациски компании.
* Табелата **SECTIONS** претставува именувана зона внатре во магацинот (на пример, „Зона А", Зона Б", „Зона Југ", „Зона 32"). Уникатноста е на ниво на (warehouse_id, name), бидејќи секциите мора да бидат уникатни само во рамките на истиот магацин.
* Табелата **LOCATIONS** претставува конкретна физичка позиција во секцијата, дефинирана преку ред, колона и ниво (рафт). Уникатноста (section_id, row, column, level) гарантира дека не постојат две идентични позиции во иста секција. Дополнително, location_code е уникатен бизнис-идентификатор (на пример, „A-03-02-01").
* Табелата **BINS** е последното ниво во хиерархијата. Секој бин е физичка кутија или контејнер на дадена локација. Ограничувањето UQ_BINS_LOCATION гарантира дека на секоја локација може да постои само еден бин тоа е дизајнерска одлука која ја поедноставува логиката на движење.

=== 5.Залихи (INVENTORY, INVENTORY_MOVEMENTS) ===
* Табелата **INVENTORY** претставува моментална состојба на залиха: колку единици од одредена варијанта се наоѓаат во одреден бин. Составениот уникатен клуч (product_variant_id, bin_id) осигурува дека за иста комбинација не може да постојат два записа. Полето reserved_quantity означува количина која е резервирана (на пример, за нарачка), а уште не е физички извадена ова овозможува точно следење на достапни залихи.
* Табелата **INVENTORY_MOVEMENTS** чува историски запис за секое движење на производ. Секое движење е поврзано со изворен бин (from_bin_id) и/или целен бин (to_bin_id). Кога from_bin_id е NULL, тоа е прием на нова роба; кога to_bin_id е NULL, тоа е издавање/испорака. 
=== 6.Трансакции (TRANSACTION_TYPES, INVENTORY_TRANSACTIONS, DELIVERY_TRANSACTIONS, SHIPMENT_TRANSACTIONS) ===
* Табелата **TRANSACTION_TYPES** е едноставен шифарник кој ги дефинира можните типови на трансакции (на пример: DELIVERY, SHIPMENT, TRANSFER). 
* Табелата **INVENTORY_TRANSACTIONS** е заедничка основа за сите трансакции. Чува универзални полиња: кој вработен ја создал трансакцијата, кој ја ажурирал, кој ја прифатил и кој ја спакувал. Ваквото разделување значи дека бизнис-логиката за „прием" и „испорака" не мора да се дуплира само специфичните полиња одат во подтабелите.
* Табелата **DELIVERY_TRANSACTIONS** е подтип за приемот на роба и содржи специфични полиња: добавувач и напомена за доставница. 
* Табелата **SHIPMENT_TRANSACTIONS** е подтип за испраќање на роба и носи специфични полиња: број на пратка и дестинациска адреса. 
=== 7.Вработени (EMPLOYEES, EMPLOYEE_WAREHOUSE_ASSIGNMENTS) ===
* Табелата **EMPLOYEES** чува сеопфатни информации за секој вработен: лични податоци, контакт, работно место, статус и датуми на вработување и евентуално на отказ. Полето manager_id е самореференцирачко секој вработен може да има надреден, а тоа формира менаџерска хиерархија.
* Табелата **EMPLOYEE_WAREHOUSE_ASSIGNMENTS** ја моделира временски условената врска помеѓу вработениот и магацинот во кој работи. Со start_date и end_date може да се следи историјата на распоредување. Некој работник можел да работи во Магацин А до март, а потоа во Магацин Б. Полето is_primary означува кој магацин е примарно работно место. 
=== 8. Улоги и Дозволи (ROLES, PERMISSIONS, ROLES_EMPLOYEES, PERMISSIONS_ROLES) ===
* Табелите **ROLES** и **PERMISSIONS** се независни ентитети: улогата е групирање (на пример, „Магацински менаџер"), а дозволата е конкретно право (на пример, „Може да одобрува движења"). И двете имаат created_at/updated_at за аудит.
* Табелата **PERMISSIONS_ROLES** е врска многу-кон-многу помеѓу дозволи и улоги: на улога можат да и се доделат повеќе дозволи, а иста дозвола може да ја имаат повеќе улоги.
* Табелата **ROLES_EMPLOYEES** е врска многу-кон-многу помеѓу улоги и вработени: на вработен можат да му се доделат повеќе улоги истовремено, а иста улога може да ја имаат повеќе вработени. Ваквата структура е флексибилна, нов тип на корисник се дефинира со нова улога и доделување на соодветни дозволи, без да се менува структурата на базата.