Нормализација и подобрувања на дизајнот на базата

Функционална зависност

За делот полагање на основен испит, почнувам од делот на Нормализација и Функционална зависност.
Правиме анализа на базата во моментот и треба да провериме :
-> Дали секое поле е атомско? (1НФ)
-> Дали сите атрибути зависат целосно од примарниот клуч? (2НФ)
-> Дали има транзитивни зависности? (3НФ) A → B и B → C, тогаш A → C
Моментална ситуација на базата е следна :

При анализа ги следине сите табелиод базата и одлучуваме:
→ Кои полиња зависат од што?
→ Што го одредува што?

• Табела 1 → orders :
  

id_order → payment_method, status, delivery_price, total_price, invoice_code, order_date, id_customer
Ова значи дека сè што се однесува на некоја нарачка,притоа секој атрибут зависи од примарен клуч id_order.
Заклучок: 1НФ - 2НФ - 3НФ
Табелата е нормализирана до 3НФ и нема потреба од декомпозиција.

• Табела 2 → customers:
  

id_customer → email, first_name, last_name, delivery_address, password, phone
id_customer е примарниот клуч па ги одредува сите други полиња што го опишуваат клиентот.
Заклучок: 1НФ - 2НФ - 3НФ
Табелата е нормализирана до 3НФ и нема потреба од декомпозиција.

• Табела 3 → delivery:
  

id_delivery, delivery_address, status, id_order
Во оваа табела, id_delivery е примарниот клуч со кој добиваме инфо каде дадена нарачка и каков статус има притоа имаме id_order кој е надворешен клуч и не влијае на зависностите на другите атрибути.
Заклучок: 1НФ - 2НФ - 3НФ
Табелата е нормализирана до 3НФ и нема потреба од декомпозиција.

• Табела 4 → contains:

quantity, size, price, id_order, id_stock
id_order + id_stock → quantity, size, price
Табелата contains е нормализирана во 2НФ и 3НФ и не треба декомпозиција иако имаме ваков спој за клуч.
Табелата contains го поврзува id_order со id_stock, и секоја нарачка ја означува количината на производот кој е поврзан со нарачката.
Заклучок: 1НФ - 2НФ - 3НФ
Табелата е нормализирана до 3НФ и нема потреба од декомпозиција.

• Табела 5 → stock:

id_stock, id_product, size, quantity, price
Оваа табела чува податоци за секој продукт за да видиме со што располагаме.
Табелата е во 2НФ, затоа што сите атрибути зависат целосно од примарниот клуч (id_stock).
Заклучок: 1НФ - 2НФ - 3НФ Табелата е нормализирана до 3НФ и нема потреба од декомпозиција.

• Табела 6 → products :

id_product, id_category, product_name, color, price, description, image_url
Табелата е во 2НФ, затоа што сите атрибути зависат целосно од id_product, кој е примарен клуч.
Заклучок: 1НФ - 2НФ - 3НФ
Табелата е нормализирана до 3НФ и нема потреба од декомпозиција.

• Табела 7 → categories:

id_category, category_name
Табелата е во 2NF, затоа што сите атрибути зависат целосно од id_category, кој е примарен клуч.

• Клучни точки за базата :
  

orders → customers = еден корисник може да има повеќе нарачки
delivery → orders = секоја достава е поврзана со една нарачка
stock → products = еден артикл во магацин е поврзан за еден производ, но може да има повеќе варијации по големина и боја
contains ја врзува orders и stock = една нарачка може да содржи повеќе артикли, а еден артикл може да биде дел од повеќе нарачки

• Заклучок: 1НФ - 2НФ - 3НФ
  

Табелата е нормализирана до 3НФ и нема потреба од декомпозиција.

Update

Може да забележиме во постоечкиот модел дека имаме јасни ентитети:
customers,products,orders,stock,contains,categories,delivery.
За почеток, што би можеле да подобриме?

Update : Address

Во оваа првична верзија, адресата се повторува во orders и delivery како и orders.
Но бидејки ова може да доведе до дупликати, компликации при менување адреса на корисник како и несинхронизираност, ке ја изделиме овој пат како посебна табела.
Наместо да се чуваат адресите директно во orders или delivery, се чува само foreign key id_address,
со што се овозможува повторна употреба на истата адреса за повеќе нарачки или достава.
На овој начин иста адреса не се чува повеќе пати,корисник може да има повеќе адреси
а воедно и при checkout корисник избира адреса од список,
а не внесува нова секогаш а и зафаќа помал простор што води до подобра нормализација.

Update : Payment_methods

Направив нова посебна табела payment_methods, каде поставив два начина на плаќање
кои се прикажани како избор и на веб, плаќање кеш при превземање или со картичка. Двата начини имаат свое id, па така се избегнува можност за грешка
и доколку подоцна сакаме да додадеме некој нов метод на плаќање, е олеснат процесот.
Значи имаме олеснат процес и полесно оддржување.

Update : Sizes

Оваа табела ја издвоивме како посебна за да не дојде до конфузија и дупликати.
Секоја големина овде има свој id_size, па ке се референцира кај сите други табели.
На овој начин се олеснува додадавање или измена на големини без да се менуваат многу табели.

Update : Contains

Во табелата contains наместо size ставаме id_stock,
значи правиме референца кон друга табела stockкоја го содржи производот и неговата големина.
Ова помага да се избегнат дупликати, бидејки во првиот случај во contains
се претставени како текст S,M,L,XL, некој може да напише "S", друг "s", трет "Small" и тоа создава неконзистентност.
Затоа како посебна табела sizes секоја големина има свој уникатен ID. Табелата stockго поврзува производот id_product со таа големина id_size, а табелата contains ја користи врската преку id_stock. На овој начин имаме едно дефинирање за секоја големина, која се користи унифицирано низ целата база.
Тоа ја прави структурата почиста, полесна за одржување и без грешки.

Update : Stock

Како што веќе знаеме, сега наместо size, користиме id_size од посебна табела sizes.
Нареден чекор како измена е бришење на price од табелата stock,
бидејки може да доведе до конфузија дали цената се одредува на ниво на големина,
а во реалност е дека цената се одредува на ниво на продукт.

Update : Wishlist

Оваа табела нуди нова функционалност на сајтот, посебна страна каде се издвоени посакуваните продукти на корисникот.
Оваа табела можеби нема многу удел во некоја функционалност во база, но придонесува до подобрено корисничко искуство,
со тоа што секој продукт има икона во форма на срце преку која може да издели продукти на посебна страна,
и на крај од сите изделени продукти да одбере оние што ке ги купи.
Поставена е POST рута за додавање, DELETE рута за вадење, GET рута за листање податоци.

Update : Полиња created_at и updated_at

Во оваа првична верзија, немаме на ниту една табела вакви полиња, но зошто се тие важни?
Кај табелите каде што се прават промени на податоци (на пр. orders, contains, stock)
додадов полиња created_at кое чува време кога редот е создаден и updated_at кое чува време кога последен пат е изменето нешто.
Овие полиња овозможуваат да знаеме кога е внесен или изменет некој запис, што е важно за разбирање на историјата и текот на настаните. Исто така, ако нешто тргне наопаку или се случи некоја грешка, со временските полиња може да видиме кога точно се направиле промените.

Update : Нова функционалност Набавка

Од тековните табели со ентитети и атрибути, може да се искористат елементите и додадеме нова функционалност на сајтот, кој за базата е веќе познат, но го подобрува корисничкото искуство кога ке се искористат истите а тоа е Набавка. За секој продукт во база, ке се чита од stock каде е = 0 одредена големина, и ке ги издвои тие големини на продукти каде веќе нема на залиха па ние ке му додадеме опции за додавање на залиха преку веб, односно избор на големина, избор на количина и со помош на копче преку веб ке му додадеме залиха на одреден продукт, а тој истата ке ја зачува и во базата а воедно и веднаш направи update на почетна дека постои залиха од тој продукт во дадена големина и одредена количина спремен за нарачка.