Tutoriale ORACLE - Normalizarea relațiilor în 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.

Figura I.2.1.

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.

Figura I.2.5

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ă

O 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.

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.).

Figura I.2.10.

Figura I.2.11.

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