Baze date cap_4
1 like2,116 views
Normalizarea este un proces important în proiectarea bazelor de date, care ajută la crearea unor relații corecte între date și la prevenirea redundanței. Acesta identifică dependențele funcționale și permite descompunerea relațiilor pentru a atinge diferite forme normale. Procesul asigură că datele sunt stocate eficient, minimizând problemele de actualizare și menținând integritatea bazei de date.
Baze date cap_4
- 1. 4 NORMALIZAREA RELAŢIILOR 4.1 Scopul normalizării La proiectarea unei BD relaţionale, principalul obiectiv în realizarea unui model logic este crearea unei reprezentări corecte a datelor, relaţiilor dintre ele şi a constrângerilor. Pentru atingerea acestui obiectiv, trebuie identificat un set adecvat de relaţii. Normalizarea reprezintă o tratare de jos în sus a proiectării bazelor de date, care începe prin examinarea relaţiilor dintre atribute. Totuşi, de multe ori metodologia de proiectare abordează o tratare de sus în jos a BD (care începe prin identificarea principalelor entităţi şi relaţii), caz în care normalizarea este folosită ca tehnică de validare. Procesul de normalizare este o metodă formală, care identifică relaţiile bazându-se pe cheile primare ale acestora şi pe dependenţele funcţionale dintre atributele lor. Normalizarea ajută proiectanţii de BD, prin prezentarea unei serii de teste care pot fi aplicate relaţiilor individuale, pentru a preveni apariţia anomaliilor de reactualizare. Unul din principalele scopuri urmărite la proiectarea BD relaţionale, este gruparea atributelor în relaţii în aşa fel încât să se minimizeze redundanţa datelor şi prin aceasta să se reducă spaţiul de stocare necesar relaţiilor de bază implementate. Problemele asociate redundanţei datelor le vom ilustra printr-un exemplu. Exemplu: să analizăm următoarele alternative de relaţii: Personal (PersID, NumeP, AdresaP, Funcţie, Salariu, FilialaID) şi Filiala (FilialaID, AdresaF, TelF) faţă de PersonalFiliala (PersID, NumeP, AdresaP, Funcţie, Salariu, FilialaID, AdresaF, TelF) În relaţia PersonalFiliala există date redundante: detaliile referitoare la filială sunt repetate pentru fiecare membru al personalului aflat la filiala respectivă. Relaţiile care conţin date redundante pot crea probleme, denumite anomalii de reactualizare. Anomaliile de reactualizare se clasifică în: • anomalii de inserare care pot fi de două tipuri: − anomalii privind identitatea datelor redundante: de ex, pentru inserarea noilor membri ai personalului, trebuie incluse detalii despre filiala la care vor lucra, detalii care trebuie să coincidă cu valorile aflate pe celelalte rânduri ale relaţiei, altfel provocăm o incoerenţă a BD. − anomalii privind necesitatea introducerii de rânduri cu null pentru cheia primară: de ex, pentru a insera o nouă filială, care nu are nici un personal, este necesară introducerea de null-uri pentru atributele personalului; dar PersID este cheie primară şi nu e permis null-ul (deoarece se violează integritatea entităţilor) • anomalii de ştergere: ştergerea anumitor înregistrări duce la pierderea unor detalii care nu sunt stocate în altă parte: dacă se şterge ultimul membru al personalului de la o filială, se pierd detaliile despre filială
- 2. • anomalii de modificare: necesiatatea modificării unei date redundante, presupune modificarea ei în toate înregistrările în care ea apare: dacă trebuie modificat unul din atributele unei filiale, este necesară reactualizarea rândurilor corespunzătoare pentru toţi membrii personalului de la filiala respectivă, altfel BD devine incoerentă. Această analiză arată că relaţiile Personal şi Filiala au o structură mai bună decât PersonalFiliala. Procesul de normalizare furnizează o tehnică de proiectare a unor relaţii mai bine structurate. 4.2 Dependenţe funcţionale Dependenţele funcţionale sunt concepte fundamentale în procesul de normalizare. Dependenţa funcţională descrie legăturile dintre atributele unei relaţii: fie A şi B două atribute ale relaţiei R; atributul B este dependent funcţional de A (notat A→B) dacă fiecărei valori a atributului A îi corespunde o singură valoare a atributului B. A şi B pot fi simple sau compuse. Când există o dependenţă funcţională, ea este specificată ca o constrângere între atribute. Atributul din stânga săgeţii se numeşte determinant. Exemplu: să considerăm atributele PersID şi Salariu din relaţia Personal Personal (PersID, NumeP, AdresaP, Funcţie, Salariu, FilialaID) PersID → Salariu deci un membru al personalului are un singur salariu Salariu ×→ PersID un salariu nu determină un singur membru al personalului Exemplu: Să identificăm dependenţele funcţionale din relaţia PersonalFiliala PersonalFiliala (PersID, NumeP, AdresaP, Funcţie, Salariu, FilialaID, AdresaF, TelF) PersID → NumeP PersID → AdresaF AdresaF→ TelF PersID → AdresaP PersID → TelF TelF→ FilialaID PersID → Funcţie FilialaID→ AdresaF TelF→ AdresaF PersID → Salariu FilialaID→ TelF PersID → FilialaID AdresaF→ FilialaID În această relaţie sunt 13 dependenţe funcţionale cu PersID, FilialaID, AdresaF şi TelF ca determinanţi. Un format alternativ de afişare a acestor dependenţe este: PersID → NumeP, AdresaP, Funcţie, Salariu, FilialaID, AdresaF, TelF FilialaID → AdresaF, TelF AdresaF → FilialaID, TelF TelF → FilialaID, AdresaF Pentru a identifica cheia candidat (sau cheile candidat) din relaţia PersonalFiliala, este necesar să recunoaştem atributul (sau grupul de atribute) care identifică în mod unic fiecare rând din relaţie. Dacă o relaţie are mai mult de o chei candidat, trebuie identificată cheia primară. Toate atributele care nu fac parte din cheia primară, trebuie să fie dependente funcţional de această cheie.
- 3. Singura cheie candidat pentru relaţia PersonalFiliala (deci şi cheie primară) este PersID, deoarece toate celelalte atribute ale relaţiei sunt dependente funcţional de aceasta. Cu toate că atributele FilialaID, AdresaF, TelF sunt determinanţi în această relaţie, ele nu constituie chei candidat pentru ea. In orice relaţie, atributele sunt dependente funcţional de faţă de cheile acesteia, deoarece orice cheie are proprietatea că identifică în mod unic fiecare tuplă, deci determină în mod univoc valorile atributelor tuplei. 4.3 Procesul de normalizare - descompunerea schemelor de relaţie Conceptul de dependenţă funcţională este elementul central în procesul de normalizare. Normalizarea este o tehnică formală de analiză a relaţiilor, care se bazează pe cheile primare şi dependenţele funcţionale. Tehnica presupune o serie de reguli care pot fi utilizate pentru testarea relaţiilor individuale, astfel încât o BD poate fi normalizată până la orice grad. Atunci când o cerinţă nu este îndeplinită, relaţia care o deranjează trebuie să fie descompusă în relaţii care satisfac individual cerinţele normalizării. Adeseori, normalizarea este executată sub forma unei serii de paşi. Fiecare pas corespunde unei anumite forme normale, care are proprietăţi cunoscute. Pe măsură ce se desfăşoară normalizarea, relaţiile devin în mod progresiv mai restrictive (mai puternice) ca format şi mai puţin vulnerabile la anomaliile de reactualizare. Pentru modelul relaţional, numai prima formă normală (1NF) este de importanţă critică în crearea de relaţii adecvate. Toate formele normale următoare sunt opţionale. Totuşi, pentru evitarea anomaliilor de reactualizare, se recomandă efectuarea normalizării până la cel puţin forma 3NF. Forma nenormalizată (UNF) este un tabel care conţine unul sau mai multe grupuri repetitive. Un grup repetitiv este un atribut sau grup de atribute din cadrul tabelului, care apare cu valori multiple pentru o singură instanţă a atributului cheie. 4.4 Prima formă normală (1NF) Prima formă normală (1NF) este o relaţie în care intersecţia fiecărui rând cu fiecare coloană conţine o singură valoare şi numai una, adică toate atributele relaţiei iau valori unice. Vom porni analiza de la un format de tabel nenormalizat. Pentru a-l transforma în prima formă normală (1NF), vom identifica şi vom elimina grupurile repetitive. Pentru eliminarea grupurilor repetitive dintr-un tabel nenormalizat, există două tratări uzuale, sau două strategii de lucru: 1. Se elimină grupurile repetitive prin introducerea de date adecvate în coloanele goale ale rândurilor cu date repetitive. Cu alte cuvinte, se completează spaţiile libere prin dublarea datelor nerepetitive, acolo unde este necesar. Această tratare este denumită aplatizarea tabelului. Tabelul rezultant, denumit acum relaţie, conţine valori singulare la intersecţia fiecărui rând cu fiecare coloană. În cadrul acestei tratări se introduce o redundanţă în relaţia rezultantă, redundanţă ce va trebui ulterior eliminată în procesul de normalizare. 2. Se nominalizează un atribut (sau un grup de atribute) ca o cheie a tabelului nenormalizat, după care se elimină grupurile repetitive prin plasarea datelor care se repetă – împreună cu o copie a atributului cheie iniţial, într-o relaţie separată. Se identifică apoi cheile primare ale noilor relaţii. Dacă tabelul nenormalizat conţine mai mult de un grup repetitiv, această tratare se aplică în mod repetat, până nu mai rămân
- 4. grupuri repetitive. Un set de relaţii se află în prima formă normală dacă nu conţine grupuri repetitive. Ambele tratări sunt corecte, dar a doua produce relaţii aflate în cel puţin forma 1NF cu redundanţă mai mică. Exemplu: o agenţie imobiliară Pornim analiza de la un formular clasic, cu date despre proprietăţile închiriate de un anumit client. Pentru a simplifica exemplul, vom presupune că un client închiriază o anumită proprietate o singură dată şi nu închiriază mai multe proprietăţi în acelaşi timp. Detalii Client_Închiriere Numele clientului: Ion Buflea Numărul clientului: 76 Numărul Adresa Începutul Sfârşitul Chiria Numărul Numele proprietăţii proprietăţii închirierii închirierii proprietarului proprietarului 4 Rozelor 25 01.iul.94 31.aug.96 350 40 Tina Turner Braşov 16 Stejăriş 19 01.sep.96 01.sep.98 450 93 Vali Vijelie Braşov Detalii Client_Închiriere Numele clientului: Alina Gospodina Numărul clientului: 56 Numărul Adresa Începutul Sfârşitul Chiria Numărul Numele proprietăţii proprietăţii închirierii închirierii proprietarului proprietarului 4 Rozelor 25 01.sep.92 10.iun.94 350 40 Tina Turner Braşov 36 Erorilor 21 10.oct.94 01.dec.95 375 93 Vali Vijelie Braşov 16 Stejăriş 19 01.ian.96 10.aug.96 450 93 Vali Vijelie Braşov Datele referitoare la proprietăţile închiriate de cei doi clienţi le transferăm din formularele Detalii Client_Închiriere în următorul format de tabel: Tabelul ClientÎnchiriere Nr Nume Nr Adresa Început Sfârşit Chiria Nr Nume Client Client Proprietate Proprietate Închir Închir Proprietar Proprietar 76 Ion Buflea 4 Rozelor 25 01.iul.94 31.aug.96 350 40 Tina Turner Braşov 16 Stejăriş 19 01.sep.96 01.sep.98 450 93 Vali Vijelie Braşov 56 Alina 4 Rozelor 25 01.sep.92 10.iun.94 350 40 Tina Turner Gospodina Braşov
- 5. 36 Erorilor 21 10.oct.94 01.dec.95 375 93 Vali Vijelie Braşov 16 Stejăriş 19 01.ian.96 10.aug.96 450 93 Vali Vijelie Braşov Acesta este un exemplu de tabel nenormalizat. Putem identifica atributul cheie ca fiind NrClient. Identificăm grupurile repetitive ca fiind detaliile despre proprietatea închiriată, care se repetă pentru fiecare client care a închiriat proprietatea respectivă. Structura acestui grup repetitiv este: GrupRepetitiv (NrProprietate, AdresaProprietate, ÎnceputÎnchir, SfârşitÎnchir, Chiria, NrProprietar, NumeProprietar) Deci există valori multiple la intersecţia dintre anumite rânduri şi coloane. De ex, există două valori ale atributului NrProprietate (4 şi 16), corespunzătoare clientului Ion Buflea. Pentru a transforma un tabel nenormalizat în forma 1NF, trebuie să ne asigurăm că există o singură valoare la intersecţia dintre fiecare rând şi fiecare coloană. Aceasta se realizează prin eliminarea grupului repetitiv. Vom analiza procesul eliminare prin ambele strategii prezentate: 1. strategia aplatizării tabelului În cazul acestei tratări, se elimină grupul repetitiv prin transformarea unui rând cu valori multiple ale unui atribut în mai multe rânduri cu valori singulare pentru acel atribut (de fapt, prin introducerea datelor adecvate pe fiecare rând). Relaţia rezultată, ClientÎnchiriere, se află deja în prima formă normală. Identificăm cheile candidat ale relaţiei ClientÎnchiriere ca fiind cheile compuse (NrClient, NrProprietate), (NrClient, ÎnceputÎnchir) şi (NrProprietate, ÎnceputÎnchir). Selectăm drept cheie primară atributele (NrClient, NrProprietate) şi pentru claritate, le grupăm în stânga relaţiei. Relaţia ClientÎnchiriere Nr Nr Nume Adresa Început Sfârşit Chiria Nr Nume Client Proprietate Client Proprieta Închir Închir Proprietar Proprietar te 76 4 Ion Buflea Rozelor 01.iul.94 31.aug.96 350 40 Tina Turner 25 Braşov 76 16 Ion Buflea Stejăriş 01.sep.96 01.sep.98 450 93 Vali Vijelie 19 Braşov 56 4 Alina Rozelor 01.sep.92 10.iun.94 350 40 Tina Turner Gospodina 25 Braşov 56 36 Alina Erorilor 10.oct.94 01.dec.95 375 93 Vali Vijelie Gospodina 21 Braşov 56 16 Alina Stejăriş 01.ian.96 10.aug.96 450 93 Vali Vijelie Gospodina 19 Braşov Relaţia ClientÎnchiriere este definită după cum urmează: ClientÎnchiriere (NrClient, NrProprietate, NumeClient, AdresaProprietate, ÎnceputÎnchir, SfârşitÎnchir, Chiria, NrProprietar, NumeProprietar)
- 6. Relaţia este în forma 1NF deoarece există o singură valoare la intersecţia dintre fiecare coloană şi rând. Relaţia conţine date care se repetă de mai multe ori, deci este expusă anomaliilor de reactualizare. Pentru a le elimina va trebui transformată în 2NF. 2. strategia creerii unei relaţii separate În cazul celei de-a doua tratări, se elimină grupul repetitiv prin plasarea într-o relaţie separată a datelor respective împreună cu o copie a atributului cheie iniţial (NrClient). Apoi vom identifica o chei primară pentru noua relaţie. Formatele relaţiilor 1NF rezultante sunt: Client (NrClient, NumeClient) PropÎnchir_Proprietar (NrClient, NrProprietate, AdresaProprietate, ÎnceputÎnchir, SfârşitÎnchir, Chiria, NrProprietar, NumeProprietar) Relaţia Client NrClient NumeClient 76 Ion Buflea 56 Alina Gospodina Relaţia PropÎnchir_Proprietar Nr Nr Adresa Început Sfârşit Chiria Nr Nume Client Proprie- Proprietate Închir Închir Proprie- Proprietar tate tar 76 4 Rozelor 25 01.iul.94 31.aug.96 350 40 Tina Turner Braşov 76 16 Stejăriş 19 01.sep.96 01.sep.98 450 93 Vali Vijelie Braşov 56 4 Rozelor 25 01.sep.92 10.iun.94 350 40 Tina Turner Braşov 56 36 Erorilor 21 10.oct.94 01.dec.95 375 93 Vali Vijelie Braşov 56 16 Stejăriş 19 01.ian.96 10.aug.96 450 93 Vali Vijelie Braşov Ambele relaţii sunt în forma 1NF, deoarece acum există o singură valoare la intersecţia dintre fiecare coloană şi fiecare rând. Totuşi, relaţia PropÎnchir_Proprietar conţine o oarecare redundanţă şi prin urmare este vulnerabilă la anomaliile de rectualizare.
- 7. 4.5 A doua formă normală (2NF) Se bazează pe conceptul de dependenţă funcţională totală. Dependenţa funcţională totală arată că, dacă A şi B sunt atribute ale unei relaţii R, se spune că B este total dependent funcţional de A, dacă B este dependent funcţional de A dar nu şi de orice submulţime a lui A. O dependenţă funcţională A → B este totală dacă eliminarea oricărui atribut din A are ca rezultat anularea dependenţei. O dependenţă funcţională A → B este parţială dacă există un atribut care poate fi eliminat din A şi totuşi dependenţa să se menţină. De ex, să considerăm următoarea dependenţă funcţională: NrPersonal, NumePersonal → NrFilială Este corect să afirmăm că fiecare valoare din (NrPersonal, NumePersonal) este asociată unei singure valori a atributului NrFilială. Dar asta nu e o dependenţă funcţională totală, deoarece atributul NrFilială este dependent funcţional şi de un subset al atributelor (NrPersonal, NumePersonal), şi anume NrPersonal. A doua formă normală se aplică relaţiilor cu chei compuse, adică relaţiilor care au cheia primară compusă din două sau mai multe atribute. O relaţie a cărei cheie primară este compusă dintr-un singur atribut se află automat în cel puţin forma 2NF. O relaţie care nu se află în forma 2NF este expusă anomaliilor de reactualizare. De ex, să presupunem că trebuie să schimbăm chiria proprietăţii cu nr 4; va trebui să modificăm toate înregistrările (toate rândurile unde apare proprietatea nr 4), altfel BD devine incoerentă. A doua formă normală (2NF): o relaţie este în a doua formă normală dacă îndeplineşte condiţiile pentru prima formă normală şi fiecare atribut care nu este cheie primară este total dependent funcţional de cheia primară. Normalizarea relaţiilor 1NF la forma 2NF presupune eliminarea dependenţelor parţiale. Asta se face prin eliminarea din relaţie a atributelor parţial dependente funcţional, şi plasarea lor într-o nouă relaţie, împreună cu o copie a determinantului acestora. Exemplu: Să vedem care sunt dependenţele funcţionale din relaţia ClientÎnchiriere a cărei cheie primară constă din atributele (NrClient, NrProprietate). 1df NrClient , NrProprietate → ÎnceputÎnchir, SfârşitÎnchir (cheie primară) 2df NrClient → NumeClient (dependenţă parţială) 3df NrProprietate → AdresaProprietate, Chiria, NrProprietar, NumeProprietar (dependenţă parţială) 4df NrProprietar → NumeProprietar (dependenţă tranzitivă) 5df NrClient , ÎnceputÎnchir → NrProprietate, AdresaProprietate, SfârşitÎnchir, Chiria, NrProprietar, NumeProprietar (cheie candidat) 6df NrProprietate, ÎnceputÎnchir → NrClient, NumeClient, SfârşitÎnchir (cheie candidat) Se testează dacă relaţia ClientÎnchiriere se află în 2NF, prin identificarea dependenţelor parţiale de cheia primară. Observăm că:
- 8. • atributul (NumeClient) este parţial dependent de cheia primară – el fiind dependent numai de atributul NrClient (vezi 2df) • atributele proprietăţii (AdresaProprietate, Chiria, NrProprietar, NumeProprietar) sunt parţial dependente de cheia primară – ele fiind dependente numai de atributul NrProprietate (vezi 3df). Pentru a transforma relaţia ClientÎnchiriere în 2NF este necesară crearea de noi relaţii, astfel încât atributele care nu sunt chei primare să fie eliminate împreună cu o copie a părţii din cheia primară de care sunt total dependente funcţional. În acest fel obţinem 3 relaţii noi: Relaţia Client NrClient NumeClient 76 Ion Buflea 56 Alina Gospodina Relaţia Închiriere NrClient NrProprietate ÎnceputÎnchir SfârşitÎnchir 76 4 01.iul.94 31.aug.96 76 16 01.sep.96 01.sep.98 56 4 01.sep.92 10.iun.94 56 36 10.oct.94 01.dec.95 56 16 01.ian.96 10.aug.96 Relaţia ProprietateProprietar NrProprietate AdresaProprietate Chiria NrProprietar NumeProprietar 4 Rozelor 25 Braşov 350 40 Tina Turner 16 Stejăriş 19 Braşov 450 93 Vali Vijelie 36 Erorilor 21 Braşov 375 93 Vali Vijelie Client (NrClient, NumeClient) Închiriere (NrClient, NrProprietate, ÎnceputÎnchir, SfârşitÎnchir) ProprietateProprietar(NrProprietate, AdresaProprietate, Chiria, NrProprietar, NumeProprietar) 4.6 A treia formă normală (3NF) Cu toate că relaţiile 2NF conţin mai puţină redundanţă decât cele 1NF, ele tot mai sunt vulnerabile la anomaliile de reactualizare. De exemplu dacă dorim reactualizarea numelui unui proprietar, trebuie ca în relaţia ProprietateProprietar să modificăm toate rândurile în care apare acel nume. Această anomalie de reactualizare este cauzată de dependenţa tranzitivă. Astfel de dependenţe trebuie eliminate prin trecerea la 3NF. Pentru a descrie această trecere, să explicăm întâi noţiunea de dependenţă tranzitivă. Dependenţa tranzitivă: dacă A, B, C sunt atribute ale relaţiei R şi există dependenţele A → B şi B → C, se spune că C este dependent tranzitiv de A prin intermediul lui B (cu condiţia ca A să nu fie dependent funcţional de B sau C). De exemplu, să considerăm următoarele dependenţe funcţionale:
- 9. NrPersonal → NrFilială şi NrFilială → AdresăFilială Atunci dependenţa funcţională NrPersonal → AdresăFilială are loc prin intermediul atributului NrFilială. Iar condiţia cerută, ca NrPersonal să nu fie dependent funcţional de NrFilială şi AdresăFilială este adevărată. A treia formă normală (3NF): o relaţie este în a treia formă normală dacă îndeplineşte condiţiile pentru prima şi a doua formă normală şi în plus, nici un atribut (care nu este cheie primară) nu este dependent tranzitiv de cheia primară. Normalizarea relaţiilor de la 2NF la 3NF presupune eliminarea dependenţelor tranzitive. Asta se face prin eliminarea din relaţie a atributelor dependente tranzitiv, şi plasarea lor într-o nouă relaţie, împreună cu o copie a determinantului acestora. Exemplu: Să vedem care sunt dependenţele funcţionale din relaţiile Client, Închiriere şi ProprietateProprietar. Relaţia Client 2df NrClient → NumeClient Relaţia Închiriere 1df NrClient , NrProprietate → ÎnceputÎnchir, SfârşitÎnchir 5df1 NrClient , ÎnceputÎnchir → NrProprietate, SfârşitÎnchir 6df1 NrProprietate, ÎnceputÎnchir → NrClient, SfârşitÎnchir Relaţia ProprietateProprietar 3df NrProprietate → AdresaProprietate, Chiria, NrProprietar, NumeProprietar (dependenţă parţială) 4df NrProprietar → NumeProprietar (dependenţă tranzitivă) Toate atributele relaţiilor Client şi Închiriere, care nu sunt chei primare, sunt dependente funcţional numai de cheile primare. Aceste relaţii nu au dependenţe tranzitorii, deci se află deja în 3NF. În relaţia ProprietateProprietar, toate atributele care nu sunt chei primare, sunt dependente funcţional numai de cheia primară, cu excepţia atributului NumeProprietar, care este dependent şi de NrProprietar (vezi 4df). Acesta este un exemplu de dependenţă tranzitivă. Pentru a transforma relaţia ProprietateProprietar în 3NF, trebuie eliminată această dependenţă tranzitivă prin crearea a 2 relaţii noi, Proprietate şi Proprietar, de forma: Proprietate (NrProprietate, AdresaProprietate, Chiria, NrProprietar) Proprietar (NrProprietar, NumeProprietar) Relaţia Proprietate NrProprietate AdresaProprietate Chiria NrProprietar 4 Rozelor 25 Braşov 350 40 16 Stejăriş 19 Braşov 450 93 36 Erorilor 21 Braşov 375 93 Relaţia Proprietar NrProprietar NumeProprietar
- 10. 40 Tina Turner 93 Vali Vijelie Observaţi că relaţia iniţială ClientÎnchiriere a fost transformată prin procesul de normalizare în 4 relaţii aflate în forma 3NF. Acestea au forma: Client (NrClient, NumeClient) Închiriere (NrClient, NrProprietate, ÎnceputÎnchir, SfârşitÎnchir) Proprietate (NrProprietate, AdresaProprietate, Chiria, NrProprietar) Proprietar (NrProprietar, NumeProprietar) 4.7 Forma normală Boyce-Codd (BCNF) Relaţiile din baza de date trebuie proiectate astfel încât să nu aibă nici dependenţe parţiale, nici dependenţe tranzitive, deoarece acestea duc la apariţia anomaliilor de reactualizare. Formele 2NF şi 3NF elimină dependenţele parţiale şi tranzitive de cheia primară, dar nu tratează situaţiile în care rămân astfel de dependenţe faţă de cheile candidat ale unei relaţii. Forma normală Boyce-Codd se bazează pe dependenţele funcţionale care iau în consideraţie toate cheile candidat dintr-o relaţie. Pentru o relaţie cu o singură cheie candidat, formele 3NF şi BCNF sunt echivalente. Forma normală Boyce-Codd: o relaţie se află în BCNF dacă şi numai dacă fiecare determinant este o cheie candidat. Pentru a testa dacă o relaţie este în BCNF, se identifică toţi determinanţii şi se verifică dacă sunt chei candidat. Amintim că un determinant este un atribut sau un grup de atribute, de care alte atribute sunt total dependente funcţional. Diferenţa între formele 3NF şi BCNF constă în faptul că, pentru o dependenţă funcţională A → B, forma 3NF permite această dependenţă în cadrul unei relaţii dacă B este atribut cheie primară şi A nu este cheie candidat. Prin urmare BCNF este o variantă mai strictă a 3NF, astfel că orice relaţie aflată în BCNF este şi în forma 3NF. Reciproca nu e neapărat adevărată. Relaţiile Client, Închiriere, Proprietate, Proprietar se află deja în forma BCNF întrucât fiecare din ele are un singur determinant care este cheie canidat. Aşa că pentru prezentarea formei BCNF, vom imagina alt exemplu. Exemplu: RezultateSesiune (NumeProf, Disciplina, NumeStud, Nota) Cu ipotezele că fiecare profesor predă numai o disciplină, acordă numai o notă fiecărui student, există următoarele dependenţe: Disciplina, NumeStud → Nota Disciplina, NumeStud → NumeProf Această relaţie se poate descompune în: ProfDisc (NumeProf, Disciplina) ProfStudNota (NumeProf, NumeStud, Nota)
- 11. 4.8 A patra formă normală (4NF) Cu toate că BCNF elimină toate anomaliile datorate dependenţelor funcţionale, mai există un tip de dependenţă, numită dependenţă multivalorică, ce poate cauza probleme de redundanţă a datelor. Posibila existenţă a dependenţelor multivalorice în cadrul unei relaţii se datorează primei forme normale 1NF care nu permite unui atribut dintr-un rând să aibă o mulţime de valori. De exemplu, dacă într-o relaţie există două atribute multivalorice, trebuie să repetăm fiecare valoare a unuia din atribute împreună cu fiecare valoare a celuilalt, dar efectul este apariţia redundanţei datelor. Dependenţa multivalorică: se spune că între atributele A, B, C ale unei relaţii există o dependenţă multivalorică, dacă pentru fiecare valoare a lui A există o mulţime de valori ale lui B şi o mulţime de valori ale lui C, dar mulţimile valorilor lui B şi C sunt independente unele de altele. Notaţia simbolică: A −>> B Nu se iau în consideraţie cazurile în care • B este o submulţime a lui A • A∪B=R pentru că acestea nu specifică o constrângere asupra relaţiei. Să considerăm Relaţia Aproviz: Aproviz (NrMagazie, Furnizor, Produs, Preţ) În această relaţie dependenţa multivalorică este: NrMagazie −>> Furnizor NrMagazie −>> Produs Cu toate că relaţia este în BCNF (deoarece există o singură cheie candidat), ea este prost structurată datorită redundanţei datelor, cauzată de prezenţa dependenţei multivalorice. A patra formă normală (4NF): o relaţie care se află în BCNF şi nu conţine dependenţe multivalorice. Este o formă mai strictă decât BCNF pentru că împiedică relaţiile să conţină dependenţe multivalorice, prevenind astfel redundanţa datelor. Normalizarea de la BDNF la 4NF presupune eliminarea dependenţelor multivalorice prin plasarea atributului (atributelor) într-o nouă relaţie împreună cu o copie a determinantului.