Note: 

- klaj unique constraint na (parent_id,topic_title)
- тргни start_at vo moderator - thread. 
- trgni transitivni relacii kaj project_title i topic_title deka nemat smisla. 
- surogat kluc id vo blacklisted

= Нормализација и Подобрување на дизајн 
== Функционални зависности(ФЗ)  
Со цел целосно репрезентирање на атрибутите присутни во релациското мапирање, одредени атрибути со исти имиња ќе бидат преименувани. Лесно се заприметуваат таквите атрибути во релацијата R, на пр. **user(id) -> user_id** и **permission(name) -> permission_name**.
{{{ 
R(
   user: username, description, password, registered_at, email, sex,is_active,name, user_id
  feedback: feedback_submission_type, feedback_created_at, feedback_description 
  submission: submission_id, submission_status, submission_created_at, submission_description,
  blacklisted_user: blacklisted_id,blacklisted_start_date, blacklisted_end_date, reason,blacklisted_about_user
  tag: tag_name, 
  thread: thread_id, thread_created_at, thread_content 
  topic_thread: guidelines, topic_title, parent_id  
  project_thread: repo_url, project_title, 
  associated_with: asc_started_at, asc_ended_at, 
  channel: channel_name, channel_description, channel_UUID
  permissions: perm_name, 
  project_roles: pr_name, pr_id, pr_override_type,
  sends_message_in: msg_send_at, msg_content,
) 
}}} 

=== Иницијални ФЗ

1. {{{ user_id ->  username, description, password, registered_at, email, sex,is_active,name }}}  

2. {{{ username -> user_id, description, password, registered_at, email, sex,is_active,name }}} 

3. {{{ submission_id -> feedback_submission_type, feedback_created_at, feedback_description }}} 

4. {{{ submission_id ->  submission_status, submission_created_at, submission_description }}} 

5. {{{ blacklisted_id -> blacklisted_about_user,user_id, thread_id, blacklisted_start_date,  blacklisted_end_date, reason }}} 

6. {{{ thread_id -> thread_created_at, thread_content }}} 

7. {{{ thread_id -> guidelines, topic_title, parent_id }}} 

8. {{{ thread_id -> repo_url, project_title }}} 

9. {{{ {thread_id, user_id } -> asc_started_at, asc_ended_at }}} 

10. {{{ channel_UUID ->  channel_name,channel_description}}}  

12. {{{ {thread_id, msg_send_at, user_id } -> msg_content }}} 

13. {{{ pr_id -> pr_name, pr_override_type }}} 

14. {{{ parent_id -> thread_id }}} 

15. {{{ project_title -> repo_url, thread_id, thread_created_at, thread_content  }}} 

16. {{{ {parent_id, topic_title} -> guidelines, thread_created_at, thread_content }}} 

17. {{{ {pr_name, thread_id} -> pr_override_type }}} 

18. {{{ blacklisted_about_user -> user_id  }}} 

=== Изведени ФЗ

2. {{{ parent_id -> thread_id }}} 

3. {{{ parent_id -> thread_created_at, thread_content }}}

4. {{{ parent_id -> guidelines, topic_title, parent_id }}}

5. {{{ parent_id -> repo_url, project_title }}}

6. {{{ blacklisted_about_user -> username, description, password, registered_at, email, sex,is_active,name,user_id }}}

=== Анализа на функционални зависности
За анализата на функционални зависности ќе го користиме методот на LHS/RHS поделба. Според овој метод потребно е да се поделат атрибутите во 3 групи, односно атрибути што се среќаваат на лева страна од Функционалните зависности(LHS) и според истата логика атрибути на десна страна и атрибути кои се среќаваат на 2те страни. 

> **LHS**: 
>> {{{ submission_id,blacklisted_id,blacklisted_start_date, msg_send_at,pr_id,tag_name,perm_name,blacklisted_about_user, channel_UUID}}}

> **RHS**: 
>> {{{ description, password, registered_at, email, sex,is_active,name, feedback_submission_type, feedback_created_at, feedback_description, submission_status, submission_created_at, submission_description,blacklisted_end_date, reason, tag_name,thread_created_at, thread_content, guidelines,repo_url, asc_started_at, channel_description, perm_name, pr_override_type, msg_content }}} 

> **LHS & RHS**: 
>> {{{ user_id,thread_id,username,channel_name,parent_id,project_title,topic_title, pr_name}}} 

== Нормализација 

=== Сегашна нормална форма 

Имајќи во предвид дека **guidelines** e повеќе вредносен атрибут, доаѓаме до заклучок дека сегашната имплементација на релацијата не е ни во 1NF форма.

=== Декомпозиција на R во 1NF 
Со оделување на **guidelines** во посебна релација {{{ R1(thread_id, guideline) }}} и {{{ R2(username, thread_id, password...) }}} постигнуваме релациите да се во 1NF. 

Според досега разгледаното за R1(thread_id, guideline) ги имаме следниве ФЗ: 

1. {{{ thread_id -> thread_id }}}
2. {{{ guideline -> guideline }}} 

Според функционалните зависности, единствената комбинација на атрибути која го задоволува условот за супер клуч е {{{ {thread_id, guideline} }}}, бидејќи {{{ {thread_id, guideline}+ = {thread_id, guideline} }}}. Сепак, со цел да се оптимизираат операциите на базата (особено внесување и пребарување), ќе воведеме нов сурогат клуч **id** како примарен клуч. Заедно со него ги додаваме и следниве ФЗ {{{ id -> thread_id, guideline }}}.

Ова е практично, бидејќи природниот клуч {{{ {thread_id, guideline} }}} содржи guideline, која е varchar атрибут со променлива големина. Ако се користеше само природниот клуч, PostgreSQL ќе креираше B-tree индекс врз guideline, кој е поголем по големина и поради тоа побавно ќе се ажурира при **DRU** операции (потребни се повеќе IO страници за индексирање и податоци). Со воведување на сурогат клуч **id** како мал фиксно-димензионален атрибут (на пр. serial или bigserial), индексите се помали и операциите се поефикасни.

Со ова R1 ни се совпаѓа со релацијата **topic_guidelines**, па понатаму ќе ја референцираме како таква. 

=== Декомпозиција R1 до BCNF 
Според следниве ФЗ за R1: 
1. {{{ thread_id -> thread_id }}}
2. {{{ guideline -> guideline }}}
3. {{{ id -> thread_id, guideline }}}

Според тоа што само **id** ги определува сите атрибути({{{ id+ -> id,thread_id,guideline}}}) следува дека единствен кандидат клуч е **id**. 

Примарен клуч за оваа релациja би бил **id**, бидејќи неговиот затварач е {{{ id+ = {thread_id, guideline} }}} и е најмал затварач кој ја определува целата релација. 

Според 2NF релацијата не смеe да содржи парцијални зависности. Ова веќе е задоволено од ФЗ за R1. 
Според 3NF релацијата потребно е секоја ФЗ(X->A) да ги задоволи следниве својства: 

1. X e супер клуч на R 
2. А е примарен атрибут во R. 

Според ова релацијата е веќе во 3NF. 
Според BCNF секоја релација потребно е да го задоволува следното својство: 
   "За секое нетривијално (X->A) важи дека X е суперклуч на R". 
Според тоа што **id** e клуч на R1, следува дека релацијата е во BCNF. 

=== Декомпозиција R во 2NF 
Доколку би ги избрале само атрибутите на левата страна, во таков случај не би можеле да пристапиме до сите ФЗ во кои е вклучен thread_id. Заради тоа ќе го избериме thread_id. Со него имаме:
{{{
    { 
submission_id
user_id,
blacklisted_start_date
blacklisted_id
msg_send_at
pr_id
tag_name
perm_name
channel_UUID,
thread_id,
msg_send_at
} = { 
submission_id
blacklisted_start_date
msg_send_at
pr_id
tag_name
perm_name
blacklisted_about_user
channel_UUID, 
feedback_submission_type, feedback_created_at, feedback_description,
submission_status, submission_created_at, submission_description ,
channel_name,channel_description, 
pr_name, pr_override_type, 
user_id, 
username, description, password, registered_at, email, sex,is_active,name,
blacklisted_end_date, reason,
thread_created_at, thread_content,
topic_title, parent_id,
repo_url, project_title,
asc_started_at, asc_ended_at,
msg_send_at,msg_content,
thread_id,
pr_override_type
}
}}}

{{{ R1(user_id,username, description, password, registered_at, email, sex,is_active,name) }}} 

{{{ R2(submission_id,feedback_submission_type, feedback_created_at, feedback_description,submission_status, submission_created_at, submission_description)}}}

{{{ R3(blacklisted_about_user,user_id, thread_id, blacklisted_start_date,blacklisted_end_date, reason) }}} 


{{{ R4(thread_id,thread_created_at, thread_content,topic_title, parent_id,repo_url, project_title) }}}

{{{ R5(channel_UUID,channel_name,channel_description) }}}

{{{ R6(pr_id,pr_name, pr_override_type) }}}

{{{ R7(thread_id, msg_send_at, user_id,msg_content) }}}
 
{{{ R8(thread_id,user_id,asc_started_at, asc_ended_at) }}}

{{{ R9(perm_name,tag_name) }}}

=== Нормализација на R1 до 3NF 
Може да се запримети дека оваа релација е устaри релацијата **users**. 
За оваа релација важат следниве ФЗс:
1. {{{user_id ->  username, description, password, registered_at, email, sex,is_active,name}}}

2. {{{username -> user_id, description, password, registered_at, email, sex,is_active,name }}}

Од тоа што немаме транзитивни зависности во оваа релациja, следува дека **R1** e веќе во 3NF. 

=== Нормализација на R1 до BCNF

Oд претходниот чекор согледуваме дека секоја ФЗс вклучува супер клуч, што значи дека релацијта **R1** e веќе во BCNF. 

=== Нормализација на R2 до 3NF 
Единствени ФЗс за оваа релација се: 
1. {{{ submission_id -> feedback_submission_type, feedback_created_at, feedback_description }}} 

2. {{{ submission_id ->  submission_status, submission_created_at, submission_description }}} 

Со користење правилото !Унија/Декомпозиција од привалата за изведување на Армстронг добиваме: 

1. {{{ submission_id ->  submission_status, submission_created_at, submission_description, feedback_submission_type, feedback_created_at, feedback_description}}}

Од тоа што немаме транзитивни зависности, следува дека **R2** е веќе во 3NF. 

=== Нормализација на R2 до BCNF 

Од претходниот чекор, може да согледаме дека имаме само една ФЗ, што значи дека таа ФЗ мора да содржи суперклуч за релациjaта. Според претходно спомнатото може да се заклучи дека **R2** e веќе во BCNF.

=== Подобрување на нормализација на R2 

Oд доменот на апликацијата се согледува дека не секој submission мора да има feedback, тоа значи дека доста инстанци ќе имат null вредности за колоните feedback_submission_type, feedback_created_at, feedback_description. Со цел одбегнување на записи со голем број null вредности ќе изведиме 2 нови релации. 

1. {{{ R21(submission_id,submission_status, submission_created_at, submission_description) }}}  
2. {{{ R22(submission_id,feedback_submission_type, feedback_created_at, feedback_description) }}} 

На овој начин доколку некој submission нема feedback тогаш нема да има запис во **R22** и нема да има null вредности во записите. За разлика од претходното решение доста каде што feedback колоните би биле полни со null вредности. 

Притоа да согледаме дека **R21** e релациjaта **submission** и **R22** е **feedback**. 

=== Нормализација на R3 до BCNF

Единствена ФЗ присутна во оваа релациja е:


{{{
blacklist_id -> blacklisted_about_user,user_id,thread_id,
blacklisted_start_date,blacklisted_end_date, reason
}}}


R3 е веќе во BCNF, заради тоа што единствената ФЗ го вклучува суперклучот и нема транзитивни зависности. 


=== Нормализација на R4 до 3NF 
ФЗс присутни во оваа релација се: 

1. {{{ thread_id -> thread_created_at, thread_content, topic_title, parent_id, repo_url, project_title }}}
2. {{{ project_title -> thread_created_at, thread_content, repo_url }}}
3. {{{ {parent_id, topic_title} -> thread_content, thread_created_at }}}
4. {{{ parent_id ->  thread_created_at, thread_content, topic_title, parent_id, repo_url, project_title, thread_id }}}

{{{ R41(project_title, thread_created_at, thread_content, repo_url) }}} 
{{{ R42(parent_id, topic_title,thread_content, thread_created_at) }}} 
{{{ R43(thread_id, project_title, topic_title, parent_id) }}} 

 **thread_created_at** и **thread_content** се повторуваат во **R41** и **R42**, па според тоа може да се изведат во една заедничка релација, односно релацијата **R43**. 
Според тоа се добиваат следните релации: 

{{{ R41(project_title, repo_url) }}} 
{{{ R42(parent_id, topic_title) }}}  
{{{ R43(thread_id, project_title, topic_title, parent_id, thread_created_at, thread_content) }}} 

Од тоа што **thread** може да е или проект или topic, но не и двете. Tоа повлекува дека: 

- **thread** е проект -> **topic_title**, **parent_id** се null вредности. 
- **thread** е  topic -> **project_title** е null вредност. 

Со цел да избегнеме null вредности и да обезбедиме **lossless join** ќе го направиме следното: 

- **R41** ќе додадеме **thread_id** (за постигнување на  **lossless join**), додека од **R43** ќе отстраниме **project_title**. 
- **R42** ќе додадеме **thread_id** (за постигнување на  **lossless join**), додека од **R43** ќе остраниме  **topic_title**, **parent_id**. 

Со тоа се добиваат следните релации: 

{{{ R41(project_title, repo_url, thread_id) }}} 
{{{ R42(parent_id, topic_title, thread_id) }}}  
{{{ R43(thread_id, thread_created_at, thread_content) }}} 

=== Нормализација на R41 до BCNF 
Eдинстевни ФЗ присутни во оваа релација се: 
1. {{{ thread_id -> repo_url,project_title }}}
2. {{{ project_title -> repo_url, thread_id }}}

Лесно се согледува дека {{{ thread_id }}} и {{{project_title}}} се кандидат клучеви, па според тоа бидејќи немаме ниту еден атрибут на левата старна во ФЗти, кој не е кандидат клуч, релацијата е во BCNF. 

Притоа да согледаме дека **R41** е релацијата **project_thread**.

=== Нормализација на R42 до BCNF 
Eдинстевни ФЗ присутни во оваа релација се: 
1. {{{ thread_id -> topic_title,parent_id }}}
2. {{{ {topic_title,parent_id} -> thread_id }}}
3. {{{ parent_id -> topic_title, thread_id }}}

Бијдеќи {{{ parent_id }}} и {{{thread_id}}} се кандидат клучеви( {{{ {parent_id, topic_title} }}} е супер клуч) не постои ФЗ во која левата страна не е супер клуч. Тоа значи дека **R42** e во BCNF. 

Притоа да согледаме дека **R42** е релацијата **topic_thread**. 

=== Нормализација на R43 до BCNF 
Eдинстевни ФЗ присутни во оваа релација се: 
1. {{{ thread_id -> thread_created_at, thread_content }}}

Бидејќи само {{{ thread_id }}} e кандидат клуч, не постои ФЗ во која левата страна не е супер клуч. Според тоа **R43** е во BCNF. 

Притоа да согледаме дека **R43** е релацијата **thread**. 

=== Нормализација на R5 до BCNF
Единствена ФЗ присутна во оваа релациja е: 

{{{channel_UUID -> channel_name,channel_description}}}

R6 е веќе во BCNF, заради тоа што единствената ФЗ го вклучува суперклучот и нема транзитивни зависности. 

Притоа да согледаме дека **R5** е релацијата **channel**.

=== Нормализација на R6 до BCNF
Единствена ФЗ присутна во оваа релациja е: 

{{{pr_id -> pr_name, pr_override_type}}}

**R6** е веќе во BCNF, заради тоа што единствената ФЗ го вклучува суперклучот и нема транзитивни зависности. 

Може да се согледа дека **R6** е всушност **project_role**.

=== Нормализација на R7 до BCNF
Единствена ФЗ присутна во оваа релациja е: 

{{{ {thread_id, msg_send_at, user_id} -> msg_content}}}

**R7** е веќе во BCNF, заради тоа што единствената ФЗ го вклучува суперклучот и нема транзитивни зависности. 

Притоа да согледаме дека **R7* е релацијата **messages**. 

=== Нормализација на R8 до BCNF 
Единствена ФЗ присутна во оваа релациja е: 

{{{{thread_id,user_id} -> asc_started_at, asc_ended_at}}}

**R8** е веќе во BCNF, заради тоа што единствената ФЗ го вклучува суперклучот и нема транзитивни зависности. 

Пртиоа да согледаме дека **R8** е релацијата ** developer_associated_with_project**.