Changes between Version 13 and Version 14 of Normalization


Ignore:
Timestamp:
09/22/25 22:40:05 (11 hours ago)
Author:
225144
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Normalization

    v13 v14  
    1414  feedback: feedback_submission_type, feedback_created_at, feedback_description
    1515  submission: submission_id, submission_status, submission_created_at, submission_description,
    16   blacklisted_user: blacklisted_start_date, blacklisted_end_date, reason,blacklisted_about_user
     16  blacklisted_user: blacklisted_id,blacklisted_start_date, blacklisted_end_date, reason,blacklisted_about_user
    1717  tag: tag_name,
    1818  thread: thread_id, thread_created_at, thread_content
    … …  
    37374. {{{ submission_id ->  submission_status, submission_created_at, submission_description }}}
    3838
    39 5. {{{ {blacklisted_about_user,user_id, thread_id, blacklisted_start_date} ->  blacklisted_end_date, reason }}}
     395. {{{ blacklisted_id -> blacklisted_about_user,user_id, thread_id, blacklisted_start_date,  blacklisted_end_date, reason }}}
    4040
    41416. {{{ thread_id -> thread_created_at, thread_content }}}
    … …  
    7676
    7777=== Анализа на функционални зависности
    78 За анализата на функционални зависности ќе го користиме методот на LHS/RHS поделба. Според овај метод потребно е да ги поделиме атрибутите во 3 групи, односно атрибути што се среќаваат на лева страна од Функционалните зависности(LHS) и според истата логика атрибути на десна страна и атрибути кои се среќаваат на 2те страни.
     78За анализата на функционални зависности ќе го користиме методот на LHS/RHS поделба. Според овој метод потребно е да се поделат атрибутите во 3 групи, односно атрибути што се среќаваат на лева страна од Функционалните зависности(LHS) и според истата логика атрибути на десна страна и атрибути кои се среќаваат на 2те страни.
    7979
    8080> **LHS**:
    … …  
    9191=== Сегашна нормална форма
    9292
    93 Имајќи предвид дека guidelines e повеќе вредносен атрибути, доаѓаме до заклучок дека сегашната имплементација на релација не е ни во 1NF форма.
     93Имајќи во предвид дека **guidelines** e повеќе вредносен атрибут, доаѓаме до заклучок дека сегашната имплементација на релацијата не е ни во 1NF форма.
    9494
    9595=== Декомпозиција на R во 1NF
    96 Со оделување на guidelines во посебна релација {{{ R1(thread_id, guideline) }}} и {{{ R2(username, thread_id, password...) }}} постигнуваме релациите да се во 1NF.
     96Со оделување на **guidelines** во посебна релација {{{ R1(thread_id, guideline) }}} и {{{ R2(username, thread_id, password...) }}} постигнуваме релациите да се во 1NF.
    9797
    9898Според досега разгледаното за R1(thread_id, guideline) ги имаме следниве ФЗ:
    … …  
    1011012. {{{ guideline -> guideline }}}
    102102
    103 Според функционалните зависимости, единствената комбинација на атрибути која го задоволува условот за супер клуч е {{{ {thread_id, guideline} }}}, бидејќи {{{ {thread_id, guideline}+ = {thread_id, guideline} }}}. Сепак, со цел да оптимизираме операциите на базата (особено внесување и пребарување), ќе воведеме нов сурогат клуч **id** како примарен клуч. Заедно со него ги додаваме и следниве ФЗ {{{ id -> thread_id, guideline }}}.
    104 
    105 Ова е практично бидејќи природниот клуч {{{ {thread_id, guideline} }}} содржи guideline, која е varchar атрибут со променлива големина. Ако се користеше само природниот клуч, PostgreSQL ќе креираше B-tree индекс врз guideline, кој е поголем по големина и поради тоа побавно ќе се ажурира при **DRU** операции (потребни се повеќе IO страници за индексирање и податоци). Со воведување на сурогат клуч **id** како мал фиксно-димензионален атрибут (на пр. serial или bigserial), индексите се помали и операциите се поефикасни.
    106 
    107 Со ова R1 ни се совпаѓат со релацијата **topic_guidelines**, отсега понатаму ќе ја референцираме како таква.
     103Според функционалните зависности, единствената комбинација на атрибути која го задоволува условот за супер клуч е {{{ {thread_id, guideline} }}}, бидејќи {{{ {thread_id, guideline}+ = {thread_id, guideline} }}}. Сепак, со цел да се оптимизираат операциите на базата (особено внесување и пребарување), ќе воведеме нов сурогат клуч **id** како примарен клуч. Заедно со него ги додаваме и следниве ФЗ {{{ id -> thread_id, guideline }}}.
     104
     105Ова е практично, бидејќи природниот клуч {{{ {thread_id, guideline} }}} содржи guideline, која е varchar атрибут со променлива големина. Ако се користеше само природниот клуч, PostgreSQL ќе креираше B-tree индекс врз guideline, кој е поголем по големина и поради тоа побавно ќе се ажурира при **DRU** операции (потребни се повеќе IO страници за индексирање и податоци). Со воведување на сурогат клуч **id** како мал фиксно-димензионален атрибут (на пр. serial или bigserial), индексите се помали и операциите се поефикасни.
     106
     107Со ова R1 ни се совпаѓа со релацијата **topic_guidelines**, па понатаму ќе ја референцираме како таква.
    108108
    109109=== Декомпозиција R1 до BCNF
    … …  
    1131133. {{{ id -> thread_id, guideline }}}
    114114
    115 Според тоа што само **id** ги определува сите атрибути({{{ id+ -> id,thread_id,guideline}}}) следува дека единствен супер клуч е **id**.
    116 
    117 Клуч за оваа релациja би бил **id**, бидејќи неговиот затварач е {{{ id+ = {thread_id, guideline} }}} и е најмал затварач кој ја определува целата релација.
     115Според тоа што само **id** ги определува сите атрибути({{{ id+ -> id,thread_id,guideline}}}) следува дека единствен кандидат клуч е **id**.
     116
     117Примарен клуч за оваа релациja би бил **id**, бидејќи неговиот затварач е {{{ id+ = {thread_id, guideline} }}} и е најмал затварач кој ја определува целата релација.
    118118
    119119Според 2NF релацијата не смеe да содржи парцијални зависности. Ова веќе е задоволено од ФЗ за R1.
    … …  
    124124
    125125Според ова релацијата е веќе во 3NF.
    126 Според BCNF секоја релација потребно е да го задоволува следново својство:
     126Според BCNF секоја релација потребно е да го задоволува следното својство:
    127127   "За секое нетривијално (X->A) важи дека X е суперклуч на R".
    128128Според тоа што **id** e клуч на R1, следува дека релацијата е во BCNF.
    129129
    130130=== Декомпозиција R во 2NF
    131 Доколку би ги избрале само атрибутите на левата страна, во таков случај не би можеле да пристапиме до сите ФЗ во кои е вклучен thread_id. Заради тоа ке го избериме thread_id. Со него имаме:
     131Доколку би ги избрале само атрибутите на левата страна, во таков случај не би можеле да пристапиме до сите ФЗ во кои е вклучен thread_id. Заради тоа ќе го избериме thread_id. Со него имаме:
    132132{{{
    133133    {
    … …  
    142142channel_UUID,
    143143thread_id,
    144 blacklisted_about_user,
    145144msg_send_at
    146145} = {
    … …  
    187186{{{ R8(thread_id,user_id,asc_started_at, asc_ended_at) }}}
    188187
    189 {{{ R9(perm_name) }}}
    190 {{{ R10(tag_name) }}}
     188{{{ R9(perm_name,tag_name) }}}
    191189
    192190=== Нормализација на R1 до 3NF
    193 Најпрвин да заприметиме дека оваа релација е устaри релацијата **users**.
     191Може да се запримети дека оваа релација е устaри релацијата **users**.
    194192За оваа релација важат следниве ФЗс:
    1951931. {{{user_id ->  username, description, password, registered_at, email, sex,is_active,name}}}
    … …  
    204202
    205203=== Нормализација на R2 до 3NF
    206 Да заприметиме дека единствени ФЗс за оваа релација се:
     204Единствени ФЗс за оваа релација се:
    2072051. {{{ submission_id -> feedback_submission_type, feedback_created_at, feedback_description }}}
    208206
    … …  
    217215=== Нормализација на R2 до BCNF
    218216
    219 Од претходниот чекор, согледаме дека имаме само една ФЗ, што значи дека таа ФЗ мора да содржи суперклуч за релациjaта. Според претходно дискусираното согледуваме дека **R2** e веќе во BCNF.
     217Од претходниот чекор, може да согледаме дека имаме само една ФЗ, што значи дека таа ФЗ мора да содржи суперклуч за релациjaта. Според претходно спомнатото може да се заклучи дека **R2** e веќе во BCNF.
    220218
    221219=== Подобрување на нормализација на R2
    222220
    223 Oд демонот на апликацијата согледува дека не секој submission мора да има feedback, тоа значи дека доста инстанци ќе имат null вредности за колоните feedback_submission_type, feedback_created_at, feedback_description. Со цел одбегнување на записи со доста null вредности ќе изведиме 2 нови релации.
     221Oд доменот на апликацијата се согледува дека не секој submission мора да има feedback, тоа значи дека доста инстанци ќе имат null вредности за колоните feedback_submission_type, feedback_created_at, feedback_description. Со цел одбегнување на записи со голем број null вредности ќе изведиме 2 нови релации.
    224222
    2252231. {{{ R21(submission_id,submission_status, submission_created_at, submission_description) }}} 
    2262242. {{{ R22(submission_id,feedback_submission_type, feedback_created_at, feedback_description) }}}
    227225
    228 На овај начин доколку некој submission нема feedback тогаш нема да има запис во **R22** и нема да има null вредности во записите. За разлика од претходното решение доста каде што feedback колоните би биле полни со null вредности.
     226На овој начин доколку некој submission нема feedback тогаш нема да има запис во **R22** и нема да има null вредности во записите. За разлика од претходното решение доста каде што feedback колоните би биле полни со null вредности.
    229227
    230228Притоа да согледаме дека **R21** e релациjaта **submission** и **R22** е **feedback**.
    … …  
    244242
    245243
    246 
    247244=== Нормализација на R4 до 3NF
    248 ФЗс пристурни во оваа релација се:
     245ФЗс присутни во оваа релација се:
    249246
    2502471. {{{ thread_id -> thread_created_at, thread_content, topic_title, parent_id, repo_url, project_title }}}
    … …  
    257254{{{ R43(thread_id, project_title, topic_title, parent_id) }}}
    258255
    259 Може да согледаме дека **thread_created_at** и **thread_content** се повторуваат во **R41** и **R42**, па според тоа може да ги изведиме во една заедничка релација, односно релацијата **R43**.
    260 Според тоа ги добиваме следниве релации:
     256 **thread_created_at** и **thread_content** се повторуваат во **R41** и **R42**, па според тоа може да се изведат во една заедничка релација, односно релацијата **R43**.
     257Според тоа се добиваат следните релации:
    261258
    262259{{{ R41(project_title, repo_url) }}}
    … …  
    264261{{{ R43(thread_id, project_title, topic_title, parent_id, thread_created_at, thread_content) }}}
    265262
    266 Од тоа што **thread** може да е или проект или топик, но не и двете, тоа повлекува дека:
     263Од тоа што **thread** може да е или проект или topic, но не и двете. Tоа повлекува дека:
    267264
    268265- **thread** е проект -> **topic_title**, **parent_id** се null вредности.
    269 - **thread** е топик -> **project_title** е null вредност.
     266- **thread** е  topic -> **project_title** е null вредност.
    270267
    271268Со цел да избегнеме null вредности и да обезбедиме **lossless join** ќе го направиме следното:
    … …  
    274271- **R42** ќе додадеме **thread_id** (за постигнување на  **lossless join**), додека од **R43** ќе остраниме  **topic_title**, **parent_id**.
    275272
    276 Со тоа ги добиваме следниве релации:
     273Со тоа се добиваат следните релации:
    277274
    278275{{{ R41(project_title, repo_url, thread_id) }}}
    … …  
    2852822. {{{ project_title -> repo_url, thread_id }}}
    286283
    287 Лесно се согледува дека {{{ thread_id }}} и {{{project_title}}} се кандидат клучеви, па според тоа бидејќи немаме ниту еден атрибут на левата старна во ФЗти, кои не е кандидат клуч, релацијата е во BCNF.
     284Лесно се согледува дека {{{ thread_id }}} и {{{project_title}}} се кандидат клучеви, па според тоа бидејќи немаме ниту еден атрибут на левата старна во ФЗти, кој не е кандидат клуч, релацијата е во BCNF.
    288285
    289286Притоа да согледаме дека **R41** е релацијата **project_thread**.
    … …  
    2952923. {{{ parent_id -> topic_title, thread_id }}}
    296293
    297 Бијдеќи {{{ parent_id }}} и {{{thread_id}}} се кандидат клучеви( {{{ {parent_id, topic_title} }}} е супер клуч) не постои ФЗ, во која левата страна не е супер клуч. Тоа значи дека **R42** e во BCNF.
     294Бијдеќи {{{ parent_id }}} и {{{thread_id}}} се кандидат клучеви( {{{ {parent_id, topic_title} }}} е супер клуч) не постои ФЗ во која левата страна не е супер клуч. Тоа значи дека **R42** e во BCNF.
    298295
    299296Притоа да согледаме дека **R42** е релацијата **topic_thread**.
    … …  
    312309{{{channel_UUID -> channel_name,channel_description}}}
    313310
    314 R6 е веќе во BCNF, заради тоа што единствената ФЗ го вклучува суперклучот и нема транзитивни зависимости.
     311R6 е веќе во BCNF, заради тоа што единствената ФЗ го вклучува суперклучот и нема транзитивни зависности.
    315312
    316313Притоа да согледаме дека **R5** е релацијата **channel**.
    … …  
    321318{{{pr_id -> pr_name, pr_override_type}}}
    322319
    323 **R6** е веќе во BCNF, заради тоа што единствената ФЗ го вклучува суперклучот и нема транзитивни зависимости.
    324 
    325 Да заприметиме дека **R6** е уствари **project_role**.
     320**R6** е веќе во BCNF, заради тоа што единствената ФЗ го вклучува суперклучот и нема транзитивни зависности.
     321
     322Може да се согледа дека **R6** е всушност **project_role**.
    326323
    327324=== Нормализација на R7 до BCNF
    … …  
    330327{{{ {thread_id, msg_send_at, user_id} -> msg_content}}}
    331328
    332 **R7** е веќе во BCNF, заради тоа што единствената ФЗ го вклучува суперклучот и нема транзитивни зависимости.
     329**R7** е веќе во BCNF, заради тоа што единствената ФЗ го вклучува суперклучот и нема транзитивни зависности.
    333330
    334331Притоа да согледаме дека **R7* е релацијата **messages**.
    … …  
    343340Пртиоа да согледаме дека **R8** е релацијата ** developer_associated_with_project**.
    344341
    345 === Нормализација на R9 до BCNF
    346 Најпрвин да заприметиме дека R9 е всушност релацијата **permissions**.
    347 
    348 Бидејќи немаме транзитивни релации и бидејќи {{{ perm_name+ = {perm_name} }}} е супер клуч на релацијата, добиваме дека **R9** е во BCNF.
    349 
    350 === Нормализација на R10
    351 Најпрвин да заприметиме декa R10 е уствари релацијата **tag**. Исто како и кај **R9**, лесно се согледува дека и оваа релација е во BCNF.
    352