Tehnica normalizrii relaiilor

La proiectarea structurii unei baze de date relaionale trebuie stabilite (dup cum s-a vzut n cursurile anterioare) n primul rnd tabelele n care vor fi memorate datele i asocierile dintre tabele. Acestea sunt stabilite ntr-o form iniial, dup care, prin rafinare succesiv se ajunge la forma definitiv. Acestei structuri iniiale i sunt aplicate un set de reguli care reprezint paii de obinere a unei baze de date normalizate. Dac o baz de date nu este normalizat ea nu poate fi utilizat cu un maxim de eficien. Algoritmul de normalizare a bazelor de date relaionale precum i paii acestuia au fost descrii de ctre E. F. Codd n 1972. Normalizarea este procesul reversibil de transformare a unei relaii n relaii de structur mai simpl. (Procesul este reversibil n sensul c nici o informaie nu este pierdut n timpul transformrii). Scopul normalizrii este de a suprima redundanele logice, de a evita anomaliile la reactualizare i rezolvarea problemei reconexiunii. Exemplu: Pentru a evidenia cteva exemple de redundane i anomalii, se va considera cazul relaiei iniiale OFERTANTI. Pentru a nu ncrca relaia, se vor considera valori ale atributelor prescurtate.
OFERTANTI:

cnp#numeleadresa_ clientnr_ telefonofertaadresa_ imobilCnp1N1Str. Victoriei, nr.22/12, Baia Mare, MaramuresNr1casaA_imobil1Cnp1N1Str. Victoriei, nr. 4/5, Cluj-Napoca, ClujNr1halaA_imobil2Cnp2N2Str. Viilor, nr.55/4, Oradea, BihorNr2casaA_imobil3Cnp3N3Str. Grii, nr. 14, Bucuresti Nr3terenA_imobil4

Fig.7.1. Relaia OFERTANTI Redundana logic: Tripletul (N1, Str. Victoriei, nr.22/12, Baia Mare, Maramures, Nr1) apare de dou ori. Anomalii la inserare: Dac o persoan ofer spre vnzare mai multe imobile, pentru nregistrarea ofertei trebuie rescris codul numeric personal nc o dat, deci cheia devine duplicat. Anomalii de tergere: tergerea unei persoane din baza de date atrage dup sine pierderea informaiilor despre oferta respectiv. Anomalii la modificare: Dac se modific numele strzii Victoriei din localitatea Baia Mare n strada Independenei, modificarea trebuie efectuat pentru fiecare 1

ofert din Baia Mare amplasat pe strada Victoriei. Dac ar exista 25 de oferte n aceast localitate pe strada Victoriei, costul modificrii ar fi mare pentru a modifica toate nregistrrile. Aceast redundan este eliminat dac atributul adresa este mprit n alte trei atribute: simbol_judet, cod_loc, id_strada. Valorile acestea vor fi codul judeului, localitii, respectiv a strzii preluate din relaiile deja existente JUDETE, LOCALITATI, respectiv STRAZI. n acest caz, modificarea se face doar o singur dat, n tabela STRAZI. Normalizarea Codd a definit iniial 3 forme normale, notate prin FN1, FN2 i FN3. ntruct ntr-o prim formulare, definiia FN3 ridic ceva probleme, Codd i Boyce au elaborat o nou variant, cunoscut sub numele de Boyce-Codd Normal Form (BCNF). Astfel BCNF este reprezentat separat n majoritatea lucrrilor. R. Fagin a tratat cazul FN4 i FN5. O relaie este ntr-o form normal dac satisface o mulime de constrngeri specificat n figura 7.2. De exemplu, se spune c o relaie se afl n a doua form normal FN2 dac i numai dac se afl n FN1.

Relaia universal FN1 FN2 FN3 BCFN

FN4 FN5

Fig.7.2. Formele normale ale relaiilor dintr-o BDR Normalizarea bazei de date relaionale poate fi imaginat ca un proces prin care pornindu-se de la relaia iniial/universal R se realizeaz descompunerea succesiv a acesteia n subrelaii, aplicnd operatorul de proiecie. Relaia R poate fi ulterior reconstruit din cele n relaii obinute n urma normalizrii, prin operaii de jonciune.

7.1 Prima form normal (FN1)

FN1 este strns legat de noiunea de atomicitate a atributelor unei relaii. Astfel, aducerea unei relaii n FN1 presupune introducerea noiunilor de: atribut simplu; atribut compus; grupuri repetitive de atribute. Atributul simplu- Atribut compus 2

Prin atribut simplu (atribut atomic) se nelege un atribut care nu mai poate fi descompus n alte atribute, n caz contrar, atributul este compus (atribut neatomic). Exemplu: Urmtoarele exemple de atribute pot fi considerate simple sau compuse n funcie de circumstane i de obiectivele bazei de date. Data calendaristic este un atribut n care apar cmpurile: zi, lun, an; Adresa este un atribut n care apar cmpurile: strada, nr, bloc, scara, etaj, apartament, localitate, jude; Data operaiunii bancare este un atribut n care apar cmpurile data, ora; Buletin/carte identitate este un atribut n care apar cmpurile: seria, nr. Aceste atribute pot fi atomice sau neatomice. Astfel adresa clienilor ageniei imobiliare intereseaz la nivel global, pe cnd pentru adresa ofertei sau a cererii de imobile este vital prelucrarea separat a fiecrui cmp considerat. Analog, atributul nume reprezent un atribut simplu al acestei baze de date, deoarece numele clientului intereseaz la nivel global. Grupuri repetitive de atribute Un grup repetitiv este un atribut (grup de atribute) dintr-o relaie care apare cu valori multiple pentru o singur apariie a cheii primare a relaiei nenormalizate. Exemplu: Fie relaia nenormalizat (primar) FACTURI. Dorim s stabilim o structur de tabele care s permit stocarea informaiilor coninute n document (factur) i obinerea unor situaii sintetice privind evidena sumelor facturate pe produse, pe clinei, pe anumite perioade de timp.

FACTURI nr_factura# data_factura nume_client adresa_client banca_client nr_cont_client delegat cod_produs denumire_produs unitate_de_masura cantiate pret_unitar valoare valoare_tva toal_valoare_factura toal_valoare_tva Fig. 7.3. Relaia FACTURI nenormalizat n cazul n care o factur conine mai multe produse, relaia de mai sus va avea grupurile repetitive: cod_produs, denumire_produs, cantitate, pret_unitar, valoare, valoare_tva. Aducerea unei relaii universale la FN1 FN1 este tratat n general cu superficialitate, deoarece principala cerin atomicitatea valorilor este uor de ndeplinit (cel puin la prima vedere). Dintre toate formele normale, doar FN1 are caracter de obligativitate. Se spune c o baz de date este normalizat daca toate relaiile se afl mcar n FN1. O relaie este n FN1 dac domeniile pe care sunt definite atributele relaiei sunt constituite numai din valori atomice. Un tuplu nu trebuie s conin atribute sau grupuri de atribute repetitive. Aducerea relaiilor n FN1 presupune eliminarea atributelor compuse i a celor repetitive. Se cunosc trei soluii pentru determinarea grupurilor repetitive: eliminarea grupurilor repetitive pe orizontal (n relaia R iniial, n locul atributelor compuse se trec componentele acestora, ca atribute simple); eliminarea grupurilor repetitive prin adugarea de tupluri; eliminarea grupurilor repetitive prin construirea de noi relaii

Primele dou metode genereaz relaii stufoase prin duplicarea forat a unor atribute, respectiv tupluri, crendu-se astfel redundane masive cu multiple anomalii de actualizare. Metoda a treia presupune eliminarea grupurilor repetitive prin construirea de noi relaii, ceea ce genereaz o structur ce ofer cel mai mic volum de redundan. Etapele de aducere a unei relaii n FN1 sunt: I. se construiete cte o relaie pentru fiecare grup repetitiv; II. n schema fiecrei noi relaii obinute la pasul 1 se introduce i cheia primar a relaiei R nenormalizate; III. cheia primar a fiecrei noi relaii va fi compus din atributele chei ale relaiei R, plus unul sau mai multe atribute proprii. Exemplu: Deoarece o factur poate avea unul sau mai multe produse nscrise pe aceasta, informaiile legate de produse vor fi separate ntr-o alt tabel. Aplicnd etapele de aducere la FN1, se obin dou relaii: FACTURI nr_factura# data_factura nume_client adresa_client banca_client nr_cont_client delegat toal_valoare_factura toal_valoare_tva LINII_FACTURI nr_factura# cod_produs# denumire_produs unitate_de_masura cantiate pret_unitar valoare valoare_tva

Fig. 7.4. Relaia FACTURI adus n forma normal FN1 Observaia1: Cmpul adresa_client curpinde informaii despre judeul, localitatea, strada i numrul domicililului clientului. Dac se consider c este de interes o eviden a sumelor factorizate pe judee sau localiti, se vor pune n locul cmpului adresa_client trei cmpuri distincte: judet_client, localitate_client, adresa_client, uurnd n acest fel interogrile. Observaia2: ntre tabela FACTURI i tabela LINII_FACTURI exist o relaie de unu la muli, adic unui numr unic de factur i pot corespunde unul sau mai multe produse care sunt memorate ca nregistrri n tabele LINII_FACTURI. Cheia primar n aceast tabel este o cheie compus, format din dou cmpuri: nr_factura i cod_produs. ns eliminarea grupurilor repetitive, adic aducerea unei relaii la FN 1, nu rezolv complet problema normalizrii.

7.2. A doua form normal (FN2)

5

FN2 este strns legat de noiunea de dependen funcional. Noiunea de dependen funcional a fost prezentat n cursul 5: Restricii de integritate ale modelului relaional. O relaie se afl n a doua form normal FN2 dac: 1. se afl n forma normal FN1 i 2. fiecare atribut care nu este cheie este dependent de ntreaga cheie primar. Etapele de aducere a unei relaii de la FN1 la FN2 sunt: I. Se identific posibila cheie primar a relaiei aflate n FN1; II. Se identific toate dependenele dintre atributele relaiei, cu excepia acelora n care sursa este un atribut component al cheii primare; III. Se identific toate dependenele care au ca surs un atribut sau subansamblu de atribute din cheia primar; IV. Pentru fiecare atribut (sau subansamblu) al cheii de la pasul III se creeaz o relaie care va avea cheia primar atributul (subansamblul) respectiv, iar celelalte atribute vor fi cele care apar ca destinaie n dependenele de la etapa III. Exemplu: Relaia care conine date redundante (de exemplu, modificarea denumirii unui produs atrage dup sine modificarea n fiecare tuplu n care apare acest produs) este relaia LINII_FACTURI. Se observ ca nu exist nici o dependen funcional ntre atributele necomponente ale cheii. n schimb, toate atributele care nu intr n alctuirea cheii compuse sunt dependente de aceasta, iar DF dintre atributul component al cheii primare sunt: cod_produs --> denumire_produs, cod_produs --> unitate_de_masura. Ca urmare se formeaz nc dou relaii. FACTURI nr_factura# data_factura nume_client adresa_client banca_client nr_cont_client delegat toal_valoare_factura toal_valoare_tva LINII_FACTURI nr_factura# cod_produs# cantiate pret_unitar valoare valoare_tva PRODUSE cod_produs# denumire_produs unitate_de_masura

Fig. 7.5. Relaia FACTURI n a doua forma normal FN2 Chiar dac au fost eliminate o parte din redundane, mai rmn i alte redundane ce se vor elimina aplicnd alte forme normale.

A treia form normal

7.3. A treia form normal (FN3)
O relaie este n forma normal trei FN3 dac: 1. se gsete n FN2 i 2. fiecare atribut care nu este cheie (nu particip la o cheie) depinde direct de cheia primar. A treia regul de normalizare cere ca toate cmpurile din tabele s fie independente ntre ele. Etapele de aducere a unei relaii de la FN2 la FN3 sunt: I. Se identific toate atributele ce nu fac parte din cheia primara i sunt surse ale unor dependene funcionale; II. Pentru aceste atribute, se construiete cte o relaie n care cheia primar va fi atributul respectiv, iar celelalte atribute, destinaiile din DF considerate; III. Din relaia de la care s-a pornit se elimin atributele destinaie din DF identificat la pasul I, pstrndu-se atributele surse. Exemplu: n relaia FACTURI se observ c atributul nume_client determin n mod unic atributele adresa_client, banca_client i nr_cont_client. Deci pentru atributul nume_client se construiete o relaie CLIENTI n care cheia primar va fi acest atribut, iar celelalte atribute vor fi adresa_client, banca_client i nr_cont_client. Cmpurile valoare i valoare_tva depind de cmpurile cantitate, pret_unitar, i de un procent fix de TVA. Fiind cmpuri ce se pot calcula n orice moment ele vor fi eliminate din tabel LINII FACTURI deoarece constituie informaie memorat redundant. FACTURI nr_factura# data_factura nume_client delegat toal_valoare_factura toal_valoare_tva LINII_FACTURI nr_factura# cod_produs# cantiate pret_unitar PRODUSE cod_produs# denumire_produs unitate_de_masura CLIENTI nume_client# adresa_client banca_client nr_cont_client

Fig. 8.1. Relaia FACTURI n a treia forma normal FN3 Observaia 1: Aceast a treia form normal mai poate suferi o serie de rafinri pentru a putea obine o structur performant de tabele ale bazei de date. De exemplu se observ c nume_client este un cmp n care este nscris un text destul de lung format dintr-o succesiune de litere, semne speciale (punct, virgul, cratim), spaii, numere. Ordonarea i regsirea informaiilor dup astfel de 7

cmpuri este lent i mai greoaie dect dup cmpuri numerice. Din acest motiv se poate introduce un nou atribut cod_client care s fie numeric i care s fie cheia primar de identificare a pentru fiecare client. Observaia 2: O alt observaie care poate fi fcut n legtur cu tabelele aflate n cea de a treia form normal este aceea c total_valoare_factura este un cmp care ar trebui s conin informaii sintetice obinute prin nsumarea valorii tuturor ofertelor aflate pe o factur. Este de preferat ca astfel de cmpuri s fie calculate n rapoarte sau interogri i s nu fie memorate n tabelele bazei de date. LINII_FACTURI PRODUSE CLIENTI FACTURI nr_factura# data_factura delegat nr_factura# cod_produs# cantiate pret_unitar cod_produs# denumire_produs unitate_de_masura cod_client# nume_client adresa_client banca_client nr_cont_client

Verificarea aplicrii corecte a procesului de normalizare se realizeaz astfel nct uniunea acestora s produc relaia iniial, cu alte cuvinte, descompunerea este fr pierderi. Celelalte forme normale se ntlnesc mai rar n practic. Aceste forme nu sunt respectate, n general, pentru c beneficiile de eficien pe care le aduc nu compenseaz costul i munca de care este nevoie pentru a le respecta