Tehnica normalizrii relaiilor

La proiectarea structurii unei baze de date relaionale trebuie stabilite 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. Acest tabel ofer informaii despre persoane care ofer imobile de vnzare. Pentru a nu ncrca relaia, se vor considera valori ale atributelor prescurtate. OFERTANTI 1. 2. 3. 4. 5. 6. CNP# Numele Adresa_ofertant Nr Oferta Adresa_imobil

Figura 1. Structura relaiei OFERTANTI. OFERTANTI CNP# Numele N1 N1 N2 Adres_ofertant Str. Victoriei, Ionescu nr.22/12, Baia Gheorghe Mare, Maramures Str. Victoriei, Ionescu nr.22/12, Baia Gheorghe Mare, Maramures Popescu Str. Decebal Vasile Nr Oferta Adresa_imobil Sibiu, str. Trandafirilor Deva, Cluj,

nr.22 Imobil /12 nr.22 Imobil /12 5 Imobil

Figur 2. Coninutul relaiei 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, 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 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 2. De exemplu, se spune c o relaie se afl n a doua form normal FN2 dac i numai dac se afl n FN1. FN1 FN2 FN3 BCFN FN4 FN5

Figura 3. Formele normale ale relaiilor dintr-o baz de relaional (BDR). Normalizarea bazei de date relaionale poate fi imaginat ca un proces prin care porninduse 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.

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 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 clieni, 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 cantitate pret_unitar valoare valoare_tva total_valoare_factura total_valoare_tva Figura 4. Structura relaiei 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; 4

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# zi_factura luna_factura an_factura nume_client judet_client localitate_client strada_client nr_strada_client banca_client nr_cont_client nume_delegat prenume_delegat serie_CI_delegat numar_CI_delegat toal_valoare_factura toal_valoare_tva LINII_FACTURI nr_factura# cod_produs# denumire_produs unitate_de_masura cantitate pret_unitar valoare valoare_tva

Figura 5. 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 FN1, nu rezolv complet problema normalizrii.

Probleme propuse Aducei in FN1 urmatoarele baze de date: 1. ELEV (id, nume, prenume, adresa, disciplina_1, nota_1, disciplina_2, nota_2, , disciplina_n, nota_n) 2. ANGAJAT (cnp, nume, prenume, adresa, telefon, email, abilitati) 3. CONTRACT (nrc, data_contract, val_contract, cod_furnizor, den_furnizor, adresa_furnizor, prefix, tel, cont_banca, material (codmat, denmat, UM, pret_livrare, esalonare (luna, cant_contr, cant_livr))