Tehnica-normalizrii-relaiilor

7/28/2019 Tehnica-normalizrii-relaiilor

1/8

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 forminiial, dup care, prin rafinare succesiv se ajunge la forma definitiv. Acesteistructuri iniiale i sunt aplicate un set de reguli care reprezint paii de obinere aunei baze de date normalizate. Dac o baz de date nu este normalizat ea nupoate fi utilizat cu un maxim de eficien. Algoritmul de normalizare a bazelor dedate relaionale precum i paii acestuia au fost descrii de ctre E. F. Codd n1972.

Normalizarea este procesul reversibil de transformare a unei relaii nrelaii de structur mai simpl. (Procesul este reversibil n sensul c nici oinformaie nu este pierdut n timpul transformrii). Scopul normalizrii este de asuprima redundanele logice, de a evita anomaliile la reactualizare i rezolvarea

problemei reconexiunii.

Exemplu: Pentru a evidenia cteva exemple de redundane i anomalii, se vaconsidera cazul relaiei iniiale OFERTANTI. Pentru a nu ncrca relaia, se vorconsidera valori ale atributelor prescurtate.

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 dupsine pierderea informaiilor despre oferta respectiv.

- Anomalii la modificare: Dac se modific numele strzii Victoriei din localitateaBaia Mare n strada Independenei, modificarea trebuie efectuat pentru fiecare

1

cnp#numeleadresa_ clientnr_

telefonofertaadresa_ imobilCnp1N1Str. Victoriei, nr.22/12, BaiaMare, MaramuresNr1casaA_imobil1Cnp1N1Str. Victoriei, nr. 4/5,Cluj-Napoca, ClujNr1halaA_imobil2Cnp2N2Str. Viilor, nr.55/4,Oradea, BihorNr2casaA_imobil3Cnp3N3Str. Grii, nr. 14, BucurestiNr3terenA_imobil4

OFERTANTI:


2/8

ofert din Baia Mare amplasat pe strada Victoriei. Dac ar exista 25 de oferte naceast localitate pe strada Victoriei, costul modificrii ar fi mare pentru amodifica toate nregistrrile. Aceast redundan este eliminat dac atributuladresa 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. ntructntr-o prim formulare, definiia FN3 ridic ceva probleme, Codd i Boyce auelaborat o nou variant, cunoscut sub numele de Boyce-Codd Normal Form(BCNF). Astfel BCNF este reprezentat separat n majoritatea lucrrilor. R. Fagina 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 afln a doua form normal FN2 dac i numai dac se afl n FN1.

Fig.7.2. Formele normale ale relaiilor dintr-o BDR

Normalizarea bazei de date relaionale poate fi imaginat ca un proces princare pornindu-se de la relaia iniial/universal R se realizeaz descompunereasuccesiv a acesteia n subrelaii, aplicnd operatorul de proiecie. Relaia Rpoate fi ulterior reconstruit din cele n relaii obinute n urma normalizrii, prinoperaii 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

Relaia universalFN1FN2FN3BCFN FN4

FN5


3/8

Prin atribut simplu (atribut atomic) se nelege un atribut care nu mai poatefi descompus n alte atribute, n caz contrar, atributul este compus (atributneatomic).

Exemplu: Urmtoarele exemple de atribute pot fi considerate simple saucompuse 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 clienilorageniei imobiliare intereseaz la nivel global, pe cnd pentru adresa ofertei saua 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 careapare cu valori multiple pentru o singur apariie a cheii primare a relaieinenormalizate.

Exemplu: Fie relaia nenormalizat (primar) FACTURI. Dorim s stabilim ostructur 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.

3


4/8

Fig. 7.3. Relaia FACTURI nenormalizat

n cazul n care o factur conine mai multe produse, relaia de mai sus va aveagrupurile 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. Sespune c o baz de date este normalizat daca toate relaiile se afl mcar nFN1.

O relaie este n FN1 dac domeniile pe care sunt definite atributele relaieisunt constituite numai din valori atomice. Un tuplu nu trebuie s conin atributesau grupuri de atribute repetitive.

Aducerea relaiilor n FN1 presupune eliminarea atributelor compuse i acelor 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

4

FACTURI

nr_factura#data_factura

nume_clientadresa_clientbanca_clientnr_cont_clientdelegatcod_produsdenumire_produsunitate_de_masuracantiatepret_unitarvaloarevaloare_tvatoal_valoare_facturatoal_valoare_tva


5/8

Primele dou metode genereaz relaii stufoase prin duplicarea forat aunor atribute, respectiv tupluri, crendu-se astfel redundane masive cu multipleanomalii de actualizare.

Metoda a treia presupune eliminarea grupurilor repetitive prin construireade 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 cheiaprimar a relaiei R nenormalizate;

III. cheia primar a fiecrei noi relaii va fi compus din atributele chei alerelaiei R, plus unul sau mai multe atribute proprii.

Exemplu: Deoarece o factur poate avea unul sau mai multe produse nscrise peaceasta, informaiile legate de produse vor fi separate ntr-o alt tabel. Aplicndetapele de aducere la FN1, se obin dou relaii:

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 estede interes o eviden a sumelor factorizate pe judee sau localiti, se vor pune nlocul 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 deunu 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 doucmpuri: nr_factura i cod_produs.

ns eliminarea grupurilor repetitive, adic aducerea unei relaii la FN1, nurezolv complet problema normalizrii.

7.2. A doua form normal (FN2)

5

FACTURI

nr_factura#data_facturanume_clientadresa_clientbanca_clientnr_cont_clientdelegattoal_valoare_factura

toal_valoare_tva

LINII_FACTURI

nr_factura#cod_produs#denumire_produsunitate_de_masuracantiatepret_unitarvaloarevaloare_tva


6/8

FN2 este strns legat de noiunea de dependen funcional. Noiuneade dependen funcional a fost prezentat n cursul 5: Restricii de integritateale 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 excepiaacelora n care sursa este un atribut component al cheii primare;

III. Se identific toate dependenele care au ca surs un atribut sausubansamblu de atribute din cheia primar;

IV. Pentru fiecare atribut (sau subansamblu) al cheii de la pasul III se creeazo relaie care va avea cheia primar atributul (subansamblul) respectiv, iarcelelalte atribute vor fi cele care apar ca destinaie n dependenele de laetapa III.

Exemplu: Relaia care conine date redundante (de exemplu, modificareadenumirii unui produs atrage dup sine modificarea n fiecare tuplu n care apareacest produs) este relaia LINII_FACTURI. Se observ ca nu exist nici odependen funcional ntre atributele necomponente ale cheii. n schimb, toateatributele 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.

Fig. 7.5. Relaia FACTURI n a doua forma normal FN2

Chiar dac au fost eliminate o parte din redundane, mai rmn i alteredundane ce se vor elimina aplicnd alte forme normale.

6

LINII_FACTURI

nr_factura#cod_produs#cantiatepret_unitarvaloarevaloare_tva

PRODUSE

cod_produs#denumire_produsunitate_de_masura

FACTURI

nr_factura#data_facturanume_clientadresa_clientbanca_clientnr_cont_clientdelegattoal_valoare_facturatoal_valoare_tva


7/8

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 i2. fiecare atribut care nu este cheie (nu particip la o cheie) depinde direct decheia primar.

A treia regul de normalizare cere ca toate cmpurile din tabele s fieindependente 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 nmod unic atributele adresa_client, banca_client i nr_cont_client. Decipentru atributul nume_client se construiete o relaie CLIENTI n care cheiaprimar va fi acest atribut, iar celelalte atribute vor fi adresa_client,banca_client i nr_cont_client. Cmpurile valoare i valoare_tva depind decmpurile cantitate, pret_unitar, i de un procent fix de TVA. Fiind cmpuri cese pot calcula n orice moment ele vor fi eliminate din tabel LINII FACTURI

deoarece constituie informaie memorat redundant.

Fig. 8.1. Relaia FACTURI n a treia forma normal FN3

Observaia 1: Aceast a treia form normal mai poate suferi o serie de rafinripentru a putea obine o structur performant de tabele ale bazei de date. Deexemplu se observ c nume_client este un cmp n care este nscris un textdestul de lung format dintr-o succesiune de litere, semne speciale (punct, virgul,cratim), spaii, numere. Ordonarea i regsirea informaiilor dup astfel de

7

LINII_FACTURI

nr_factura#cod_produs#cantiatepret_unitar

PRODUSE


FACTURI

nr_factura#data_facturanume_clientdelegattoal_valoare_facturatoal_valoare_tva

CLIENTI

nume_client#adresa_clientbanca_clientnr_cont_client


8/8

cmpuri este lent i mai greoaie dect dup cmpuri numerice. Din acest motivse poate introduce un nou atribut cod_client care s fie numeric i care s fiecheia 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 valoriituturor ofertelor aflate pe o factur. Este de preferat ca astfel de cmpuri s fiecalculate n rapoarte sau interogri i s nu fie memorate n tabelele bazei dedate.

Verificarea aplicrii corecte a procesului de normalizare se realizeazastfel 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 suntrespectate, n general, pentru c beneficiile de eficien pe care le aduc nucompenseaz costul i munca de care este nevoie pentru a le respecta

8

LINII_FACTURI

nr_factura#cod_produs#cantiatepret_unitar

PRODUSE


FACTURI

nr_factura#data_facturadelegat

CLIENTI

cod_client#nume_clientadresa_clientbanca_clientnr_cont_client

Tehnica-normalizrii-relaiilor

Documents

Transcript of Tehnica-normalizrii-relaiilor