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

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

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


[[Image(baza.png​​, height=200px)]] \\
\\
При анализа ги следине сите табелиод базата и одлучуваме:\\
→ Кои полиња зависат од што?\\
→ Што го одредува што?\\

 * '''Табела 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 корисник избира адреса од список,  \\
а не внесува нова секогаш а и зафаќа помал простор што води до подобра нормализација.
\\
[[Image(addresses.png​​, height=200px)]] \\
\\

= Update : Payment_methods
Направив нова посебна табела '''{{{payment_methods}}}''', каде поставив два начина на плаќање \\
кои се прикажани како избор и на веб, плаќање кеш при превземање или со картичка.
Двата начини имаат свое id, па така се избегнува можност за грешка \\
и доколку подоцна сакаме да додадеме некој нов метод на плаќање, е олеснат процесот. \\
Значи имаме олеснат процес и полесно оддржување. \\
\\
[[Image(methods.png​​, height=200px)]] \\
\\

= 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}}}'''.
На овој начин имаме едно дефинирање за секоја големина, која се користи унифицирано низ целата база. \\
Тоа ја прави структурата почиста, полесна за одржување и без грешки.\\
\\
[[Image(contains.png​​, height=200px)]] \\
\\
= Update : Stock
Како што веќе знаеме, сега наместо '''{{{size}}}''', користиме '''{{{id_size}}}''' од посебна табела '''{{{sizes}}}'''.\\
Нареден чекор како измена е бришење на '''{{{price}}}''' од табелата '''{{{stock}}}''',\\
бидејки може да доведе до конфузија дали цената се одредува на ниво на големина, \\
а во реалност е дека цената се одредува на ниво на продукт.\\

= Update : Wishlist
Оваа табела нуди нова функционалност на сајтот, посебна страна каде се издвоени посакуваните продукти на корисникот. \\
Оваа табела можеби нема многу удел во некоја функционалност во база, но придонесува до подобрено корисничко искуство, \\
со тоа што секој продукт има икона во форма на срце преку која може да издели продукти на посебна страна,  \\
и на крај од сите изделени продукти да одбере оние што ке ги купи.  \\
\\
[[Image(wishlist.png​​, height=200px)]] \\
\\