Tutoriale HTML - Normalizarea relatiilor in ORACLE

Ce este normalizarea?

Normalizarea este o tehnică de proiectare a bazelor de date prin care se elimină (sau se evită) anumite anomalii şi inconsistenţe a datelor. O baza de date bine proiectată nu permite astfel ca datele să fie redundante, adică aceeaşi informaţie să se găsească în locuri diferite, sau să memorezi în baza de date, informaţii care se pot deduce pe baza altor informaţii memorate în aceeaşi bază de date. Anomaliile care pot să apară la o bază de date nenormalizată sunt următoarele:

anomalii la actualizarea datelor la o bibliotecă se înregistrează într-o tabelă următoarele date despre cărţi: ISBN, titlu, autor, preţ, subiect, editura, adresa editurii. La un moment dat o editură îşi schimbă adresa. Bibliotecara va trebui să modifice adresa editurii respective, în înregistrările corespunzătoare tuturor cărţilor din bibliotecă apărute la respectiva editură. Dacă această modificare nu se face cu succes, unele dintre înregistrări rămânând cu vechea adresă, apare din nou o inconsistenţă a datelor.

- anomalii de inserare – în exemplul anterior, nu vom putea memora adresa unei edituri, lucru inacceptabil dacă dorim să avem informaţii şi despre edituri a căror cărţi nu le avem în bibliotecă, eventual de la care dorim să facem comenzi.

- anomalii de ştergere – să presupunem că într-o tabelă memorăm următoarele informaţii: codul studentului, codul cursului, codul profesorului. La un moment dat, nici un student nu mai doreşte să participe la un anume curs. Ştergând toate înregistrările corespunzătoare cursului, nu vom mai putea şti niciodată cine preda acel curs.

Edgar Codd a definit primele trei forme normale 1NF, 2NF şi 3NF. Ulterior s-au mai definit formele normale 4NF, 5NF, 6NF care însă sunt rar folosite în proiectarea bazelor de date.

Prima formă normală

O entitate se găseşte în prima formă normală dacă şi numai dacă:- nu există atribute cu valori multiple;- nu există atribute sau grupuri de atribute care se repetă. Cu alte cuvinte toate atributele trebuie să fie atomice, adică să conţină o singură informaţie.

Dacă un atribut are valori multiple, sau un grup de atribute se repetă, atunci trebuie să creaţi o entitate suplimentară pe care să o legaţi de entitatea originală printr-o relaţie de 1:m. În noua entitate vor fi introduse atributele sau grupurile de atribute care se repetă.

Să considerăm entitatea din figura I.2.1, referitoare la notele elevilor unei clase. Câteva observaţii referitoare la această entitate: câte discipline are un elev? Câte perechi (disciplina, nota) va trebui să aibă entitatea Elevi? Să spunem că ştim exact câte discipline maxim poate studia un elev. Ce se întâmplă dacă în anul viitor şcolar acest număr de discipline va fi mai mare? În plus, la o materie un elev poate avea mai multe note. Câte note? Cum memorăm aceste note? Le punem în câmpul corespunzător disciplinei cu virgulă între ele?

Cum rezolvăm această problemă? Vom crea o nouă entitate în care vom introduce disciplina şi nota la disciplina respectivă (vezi figura I.2.2.).

În acest fel fiecărui elev îi pot corespunde oricâte note, iar la o disciplină poate avea oricâte note, singura restricţie conform acestui model fiind că un elev nu va putea primi în aceeaşi zi la aceeaşi materie mai multe note.

normalizarea relatiilor oracle

Figura I.2.1.

normalizarea relatiilor oracle

Figura I.2.2

Un alt exemplu de încălcare a regulilor primei formei normale, puţin mai "ascuns", este prezentat în figura I.2.5. De ce? Pentru că adresa este de forma "str. Florilor, bl. 45, sc. A, ap. 28, etaj 3, Braşov, cod 123123", formă care de fapt conţine mai multe informaţii elementare. Aşadar, în mod normal acest atribut ar trebui "spart" în mai multe atribute ca în figura I.2.6.

normalizarea relatiilor oracle

Figura I.2.5

normalizarea relatiilor oracle

Figura I.2.6.

Noile atributele introduse sunt opţionale întrucât dacă elevul locuieşte la casă, probabil atributele bloc, apartament, scara, etaj, nu au sens. Invers dacă elevul locuieşte la bloc, probabil nu poate fi completat numărul.

Pentru acest tip de încălcare a regulilor formei normale 1NF poate fi totuşi ignorată, decizia depinzând de natura fenomenului, sau afacerii modelate. În exemplul anterior, întrucât datele din interiorul unei adrese este puţin probabil să se modifice, modificându-se el mult adresa completă a unui elev, se poate decide să nu operăm modificarea anterioară. Dacă însă aceste informaţii s-ar modifica frecvent, de exemplu denumirile străzilor s-ar modifica mereu, atunci probabil modificarea este de dorit.

A doua formă normală

normalizarea relatiilor oracleO entitate se găseşte în a doua formă normală dacă şi numai dacă se găseşte în prima formă normală şi în plus orice atribut care nu face parte din UID (unique identifier) va depinde de întregul UID nu doar de o parte a acestuia.

De exemplu dacă memorăm angajaţii unui departament într-o entitate ca mai jos:

Se observă că data_nasterii şi adresa sunt două atribute care depind doar de id-ul angajatului nu de întregul UID care este combinaţia dintre atributele id_dep si id_angajat. Această situaţie se rezolvă prin crearea unei noi entităţi ANGAJAT, pe care o legăm de entitatea DEPARTAMENT printr-o relaţie 1:m.

normalizarea relatiilor oraclenormalizarea relatiilor oracle

O situaţie mai specială este în cazul relaţiilor barate, când trebuie ţinut seama că UID-ul unei entităţi este compus din atribute din entitatea respectivă plus un atribut sau mai multe atribute provenite din relaţia barată. Să considerăm următorul exemplu:

Se observă că UID-ul entităţii APARTAMENT este compus din combinaţia a trei atribute: numărul apartamentului, numărul blocului şi strada. Deci toate atributele din entitatea APARTAMENT care nu fac parte din UID, trebuie să depindă de întregul UID. Dar se ştie că atributul cod_postal depinde doar de strada si de numărul blocului, nu şi de numărul apartamentului. Acest lucru ne spune ca acest atribut nu este memorat la locul potrivit. Deoarece depinde doar de combinaţia (strada, nr_bloc), înseamnă că de fapt depinde de UID-ul entităţii bloc. Aşadar vom muta atributul cod_postal în entitatea BLOC.

Observaţie. Dacă o entitate se găseşte în prima formă normală şi UID-ul său este format dintr-un singur atribut atunci ea se găseşte automat în a doua formă normală.

A treia formă normală

O entitate se găseşte în a treia formă normală dacă şi numai dacă se găseşte în a doua formă normală şi în plus nici un atribut care nu este parte a UID-ului nu depinde de un alt atribut non-UID. Cu alte cuvinte nu se acceptă dependenţe tranzitive, adică un atribut să depindă de UID în mod indirect.

Luăm ca exemplu entitatea CARTE din figura I.2.10. Atributul biografie_autor nu depinde de ISBN ci de atributul autor. Nerezolvarea acestei situaţii duce la memorarea de date redundante, deoarece biografia unui autor va fi memorată pentru fiecare carte scrisă de autorul respectiv. Rezolvarea acestei situaţii este să creăm o nouă entitate AUTOR, pe care o legăm de entitatea CARTE printr-o relaţie 1:m (figura I.2.11.).

normalizarea relatiilor oracle

Figura I.2.10.

normalizarea relatiilor oracle

Figura I.2.11.

Atributul nu por avea alte atribute, asa ca el devine entitate.