Normalizare Tabele Derivate

Normalizarea tabelelor este realizata prin analiza FD asociate cu aceste tabele: FD explicite

de la cerinţele de analiză în baza de date, FD derivate din diagrama ER şi FD derivate din intuitie.

FD primar reprezintă dependenţele dintre elementele de date pe caresunt cheile de entităţi, care sunt, dependenţele. FD secundar, pe de altă parte, reprezintă dependenţele între elemente de date care cuprind o singură entitate, care sunt, dependenţele.

Derivabile primare FD din ER

Grad Conectivitate

FD primar

Sau binar Unu la unu 2 moduri: cheie (o parte) -> cheie (o parte)

binar unu-la-multi cheie (mai multe parti) -> cheie (o parte)

recursive Multi la multi Nici unul (cheie din ambele părţi)

Ternar

Generalizare Unu la unu la unu

Unu la multi la multi

Multi la multi la multi

niciunul 3 moduri: cheie (unul), cheie (mai multe) ->

cheie (unu)

1 mod: cheie ( multe), cheie ( multe) ->

cheie (unu)

Niciunul(cheile din cele 3 parti)

Niciunul(doar secundar FD)

Orice tabel B, care este inclus de către un alt tabel A poate fi potenţial

eliminat. Tabelul B este subsumat de către un alt tabel A atunci când toate

atributele din B sunt, de asemenea, cuprinse in A şi toate dependenţele de date în B, de asemenea, să apară în A.

Ne dorim să obţină FD primar prin aplicarea normelor din tabelul de mai sus. Rezultatele sunt prezentate în tabelul urmator.

FD primar derivat din diagrama ER

dept_no -> div_no în departamentul de relaţie "conţine"

emp_id -> dept_no în angajat relaţie de "are"

div_no -> emp_id în diviziunea de la relaţie "este de-condus-de"

dept_no -> emp_id din relaţia binara "este gestionat-de"

emp_id -> desktop_no din relaţia binara "a alocat"

desktop_no -> emp_no din relaţia binara "a alocat"

emp_id -> spouse_id din relaţia binara recursivă "Este căsătorita cu"

spouse_id -> emp_id din relaţia binare recursivă "Este de căsătorita cu"

emp_id, loc_name -> project_name din relaţia ternare "atribuit-la"

Dorim pentru a determina FD secundare:

div_no -> div_name, div_addr de la divizia de entitate

dept_no -> dept_name, dept_addr, mgr_id de la Departamentul de entitate

emp_id -> emp_name, emp_addr, office_no, phone_no de la entitatea Angajat

skill_type -> skill_descrip de la entitate de îndemânare

project_name -> dată_început, dată_sfârşit, head_id de la entitate de proiect

loc_name -> loc_county, loc_state, ZIP de la entitate Locaţia

mgr_id -> mgr_start_date, beeper_phone_no de la entitate Manager

assoc_name -> assoc_addr, phone_no, start_date de la entitate Prof-assoc

desktop_no -> computer_type, serial_no de la entitate Spaţiul de lucru

În tabelul de mai jos vom reuni FD primare şi secundare care se aplică pentru fiecare tabel de candidat. Am observat că pentru fiecare tabel, cu excepţia angajaţilor, toate atributele sunt funcţional dependente de cheia primară (notate în partea stângă a FD) şi sunt astfel BCNF. În caz de tabel

angajat, observăm că spouse_id determină emp_id şi emp_id este

cheie primară; prin urmare, spouse_id poate fi dovedit a fi un SuperKey. Prin urmare, angajatul se dovedeşte a fi BCNF.