Capitolul 2.

La nceput a fost normalizarea

Motto:
Se poate elabora un ntreg capitol sau chiar carte despre normalizare, ns este greu de
scris ceva uor i plcut de citit (Rober J. Muller1)

O carte dedicat proiectrii bazelor de date ce ncepe abrupt cu normalizarea i

se termin aproape la fel poate nate discuii ndreptite. Dup cum am vzut i n
primul capitol, multe lucrri contureaz la nceput una sau mai multe metodologii
de proiectare a bazelor de date, iar normalizarea este inclus undeva spre miez, ca
etap, distinct sau nu, pentru obinerea schemei finale a bazei de date 2. Pe de alt
parte, normalizarea este ct se poate de tehnic, ba chiar tiinific pe alocuri, ceea
ce poate ndeprta cititorii mai puin rbdtori de la lectura urmtoarelor capitole.
De ce, totui, ne ncpnm s nclcm o reet de (relativ) succes i
consacrm primele capitole dependenelor dintre atribute i formelor normalizate
ale unei baze de date relaionale ? Mai nti, din raiuni istorico-sentimentale.
Edgar F. Codd, Dumnezeu s-l odihneasc - s-a prpdit n primvara lui 2003 -, a
fundamentat modelul relaional de organizare a datelor mpreun cu primele trei
forme normale3. Continuat prin munca multor specialiti, normalizarea a fost
prima teorie nchegat de elaborare a schemei unei baze de date.
Este drept c astzi sunt mai la ndemn modele precum E-R (entiti-relaii
sau entiti-asociaii), mai lizibile, expresive i uor de mnuit, ns acestea apar
mai trziu. Cel la care facem trimitere, modelul entiti-relaii, a fost elaborat de
Peter P. Chen pe la mijlocul anilor 70, iar altele pe parcursul anilor 80 i 90.
n al doilea rnd, dac modelele ce-i au sorgintea n E-R, OO, ORM etc. au
creat un veritabil turn babel al formalismelor i notaiilor, fiecare variant avnd
deopotriv suporteri i detractori la fel de nverunai, normalizarea are o imagine
de standard, metodologie unic, riguroas (este drept, cam scoroas pe alocuri).
Vom vedea, ns, nu peste mult timp, c i n privina normalizrii lucrurile nu
sunt definitive, ba, mai mult, excesul de normalizare stric de multe ori schema
bazei de date.
Nu n ultimul rnd, pentru aplicaiile relativ simple (chiar medii) i stabile n
timp, normalizarea rmne un mijloc la ndemn de a croi schema unei baze de
date. Dac lucrurile se complic, ns, este necesar s se recurg la alte metodologii
de proiectare.

1 [Muller99], p.321
2 [Harrington02], [Fleming & von Halle 89], [Riordan99], [Teorey99], [Hernandez97], [O'Neil &
O'Neil 01], [Elmasri & Navathe00]
3 Dup cum preciza i Chris Date [Date86], p.364, normalizarea nu este considerat parte a
modelului relaional, ci o teorie separat construit "deasupra" modelului
2 Capitolul 2

Cum normalizarea este legat ombilical de modelul relaional, primul paragraf

n vom cheltui cu parcurgerea sumar a noiunilor fundamentale ale relaionalului.

2.1. Concepte ale modelului relaional de organizare a

bazelor de date
Descrierea unui model de date se bazeaz, n principal, pe trei elemente:
structura - modul n care sunt organizate efectiv datele n baz, integritarea -
mecanismul de asigurare a corectitudinii datelor, i manipularea - n sensul
modificrii i extragerii informaiilor din baz. Dup cum spuneam i n capitolul
anterior, pentru aceast lucrare ne intereseaz primele dou aspecte, dei, vrnd-
nevrnd, atunci cnd ne vom pune problema implementrii tuturor restriciilor
bazei n oricare dintre SGBD-uri, vom recurge copios la opiunile manipulative ale
modelului.
Modelul relaional s-a conturat n dou articole publicate n 1969 i 1970 de
ctre E.F. Codd, matematician la centrul de cercetri din San Jose (California) al
firmei IBM. n acel moment, tehnologia bazelor de date era centrat pe modelele
ierarhic i reea, modele ce depind ntr-o mai mare msur de organizarea intern a
datelor pe suportul de stocare. Codd a propus o structur de date tabelar,
independent de tipul de echipamente i software de sistem pe care este
implementat, structur "nzestrat" cu o serie de operatori pentru extragerea
datelor. Dei puternic matematizat, modelul relaional este relativ uor de neles,
fiind definit printr-o serie de structuri de date (relaii alctuite din tupluri), operaii
aplicate asupra structurilor de date (selecie, proiecie, jonciune etc.) i reguli de
integritate care s asigure consistena datelor (chei primare, restricii refereniale
s.a.).
Fa de modelele ierarhice i reea, modelul relaional prezint cteva avantaje:
propune structuri de date uor de utilizat;
amelioreaz independena logic i fizic;
pune la dispoziia utilizatorilor limbaje ne-procedurale;
optimizeaz accesul la date;
mbuntete integritatea i confidenialitatea datelor;
ia n calcul o larg varietate de aplicaii;
abordeaz metodologic definirea structurii bazei de date.
Dac, teoretic, modelul s-a consacrat n anii `70, produsele software care s
gestioneze baze de date relaionale au devenit populare abia n deceniul 8. Dei
IBM a fost prima care a iniial un proiect destinat elaborrii unui SGBD relaional
(System/R, ncepnd cu 1974), prima firm care a lansat primul SGBDR comercial
a fost Relational Software Inc., astzi Oracle. Infiinarea firmei a avut loc n 1977,
iar lansarea produsului n 1979. Impunerea pe pia a SGBD-urilor grefate pe
modelul relaional a fost mult mai dificil dect s-ar putea nelege astzi. Abia n
deceniul 9, datorit vitezei ameliorate, securitii sporite i mai ales productivitii
dezvoltatorilor de aplicaii, modelul relaionat a ctigat supremaia.
Proiectarea bazelor de date 3

Exist o larg tipologie a SGBDR-urilor, aa nct orice categorisire i are riscul

su. Cele mai accesibile i, implicit, cele mai utilizate sunt SGBD-urile dedicate
iniial uzului individual: Access, Paradox, Visual FoxPro. Astzi, multe dintre
acestea au caracteristici profesionale i pot fi folosite la dezvoltarea aplicaiilor
pentru simulant a zeci de utilizatori. Pentru aplicaiile complexe din bnci,
corporaii, organizaii i instituii de mari dimensiuni s-au impus SGBDR-urile de
"categoria grea": Oracle, DB2 (IBM), Informix (IBM), Sybase (Sybase), SQL Server
(Microsoft). Acestea sunt mult mai robuste, mult mai fiabile, dar i costisitoare.
n ultimul timp i-au fcut apariia, ca alternative la sus-amintiii coloi, aa
zisele SGBD-uri (aproape) gratuite, precum PostgreSQL, MySQL, mSQL, Firebird
etc. Acestea ruleaz, de obicei, pe sisteme de operare de tip Linux (foarte ieftine) i
se ntrevd ca adversari serioi ai marilor productori.

2.1.1. Relaii/tabele, domenii, atribute, valori nule

La modul simplist, o baz de date relaional (BDR) poate fi definit ca un

ansamblu de relaii (tabele); fiecare tabel (sau tabel), alctuit din linii (tupluri),
are un nume unic i este stocat pe suport extern (de obicei disc). La intersecia
unei linii cu o coloan se gsete o valoare atomic. O relaie conine informaii
omogene legate de anumite entiti, procese, fenomene: CRI, ELEVI, LOCALI-
TI, PERSONAL, FACTURI etc. Spre exemplu, n figura 2.1 este reprezentat
tabela STUDENI ce stocheaz informaii privitoare la studenii nscrii la cursurile
unei faculti.

Figura 2.1. Relaia (tabela) STUDENI

4 Capitolul 2

n teoria relaional se folosete termenul relaie. Practica, ns, a consacrat

termenul tabel (engl. table). Un tuplu sau o linie este o succesiune de valori de
diferite tipuri. n general, o linie regrupeaz informaii referitoare la un obiect,
eveniment etc., altfel spus, informaii referitoare la o entitate: o carte (un titlu sau
un exemplar din depozitul unei biblioteci, depinde de circumstane), un/o
student(), o localitate (ora sau comun), un angajat al firmei, o factur emis etc.
n figur este pus n eviden aselea tuplu din tabela STUDENI, tuplu referitor la
studentul Ionescu Y Vasile. Linia respectiv este alctuit din nou valori ce
desemneaz: matricolul studentului; numele, iniiala tatlui i prenumele; codul
numeric personal (CNP-ul), adresa (stabil); anul de studiu; modulul (dac e n
anul 1 sau 2) sau specializarea (dac e n anii 3, 4 sau 5) la care este nscris
studentul; seria de curs; grupa; tipul de burs de care beneficiaz.
Teoretic, orice tuplu reprezint o relaie ntre clase de valori (n cazul nostru,
ntre nou clase de valori); de aici provine sintagma baze de date relaionale, n sensul
matematic al relaiei, de asociere a dou sau mai multe elemente. Firete, toate
tuplurile relaiei au acelai format (structur). Ordinea tuplurilor nu prezint
importan din punctul de vedere al coninutul informaional al tabelei.
Fiecare atribut este caracterizat printr-un nume i un domeniu de valori pe care
le poate lua. Domeniul poate fi definit ca ansamblul valorilor acceptate (autorizate) pentru
un element component al relaiei:
ntr-o tabel destinat datelor generale ale angajailor, pentru atributul
Sex, domeniul este alctuit din dou valori: Femeiesc i Brbtesc;
domeniul atributului Jude este alctuit din numele fiecrui jude (plus
Bucureti).
domeniul unui atribut precum PreUnitar, care se refer la preul la care
a fost vndut un produs/serviciu, este cu mult mai larg, fiind alctuit din
orice valoarea cuprins ntre 1 i 99999999999 lei (avnd n vedere rata
inflaiei).
Reinem corespondena noiunilor relaie-tabel, tuplu-linie i atribut-coloan.
Numrul de tabele pe care le conine o baz de date, atributele adunate n fiecare
tabel, domeniul fiecruia dintre atribute prezint diferene majore de la o baz la
alta, chiar dac uneori reflect acelai tip de procese. Intrm astfel n sfera
proiectrii bazelor de date, a dependenelor i normalizrii.
n figura 2.1 se observ c atributul Adresa conine, pe linia (tuplul) 8, o
valoarea curioas, notat NULL. Valoarea NULL este considerat o metavaloare i
indic faptul c, n acel loc, informaia este necunoscut sau inaplicabil. n cazul
nostru, studentei Manolache R. Iolanda nu i se cunoate adresa. Valoarea NULL este
diferit de valorile 0 sau spaiu.
n ncheiere, principalele caracteristici ale unei relaii sunt sistematizate dup
cum urmeaz:
n cadrul unei baze de date, o relaie prezint un nume distinct de al celorlalte
relaii.
valoarea unui atribut ntr-un tuplu oarecare conine a singur valoare (o
valoare atomic).
Proiectarea bazelor de date 5

fiecare atribut are un nume distinct.

orice valoare a unui atribut face parte din domeniul pe care a fost definit
acesta.
ordinea dispunerii atributelor n relaie nu prezint importan.
fiecare tuplu este distinct, adic nu pot exista dou tupluri identice.
ordinea tuplurilor nu influeneaz coninutul informaional al relaiei.

2.1.2. Restricii ale bazei de date

Principale restricii definibile n modelul relaional sunt: de domeniu, de

atomicitate, de non-nulitate, de unicitate, referenial i cele utilizator.

Restricia de domeniu
Dup cum am vzut n paragraful anterior, un atribut este definit printr-un
nume i un domeniu. Orice valoare a atributului trebuie s se ncadreze n
domeniul definit. Exist mai multe moduri de percepie a acestei restricii. O parte
din informaticieni substituie domeniul tipului atributului: numeric, ir de caractere,
dat calendaristic, logic (boolean) etc. i, eventual, lungimii (numrul maxim de
poziii/caractere pe care se poate ntinde un atribut). Dup cum se observ, este
luat n calcul numai aspectul sintactic al domeniului. Faptul c anul de studiu al
unei clase poate fi una din valorile: 9, 10, 11, 12 reprezint o restricie de
comportament sau, mai simplu, o restricie definit de utilizator.
Cea de-a doua categorie privete domeniul deopotriv sintactic i semantic.
Astfel, domeniul sintactic al atributului LitClasa (litera) dintr-o relaie precum
ELEVI_LICEU este un caracter, obligatoriu liter, i, chiar mai restrictiv, litera e
obligatoriu majuscul. Din punct de vedere semantic, LitClasa poate lua una din
valorile: A, B, C, ... n funcie de numrul de clase dintr-un an de studiu (cinci clase
de a IX-a, patru de a X-a etc.).
Majoritatea SGBD-urilor permit definirea tuturor elementelor ce caracterizeaz
domeniul (sintactic i semantic) atributuelor prin declararea tipului i lungimii
atributului i prin aa-numitele reguli de validare la nivel de cmp (field validation
rule). Sunt ns i produse la care domeniul poate fi definit explicit, sintactic i
semantic, dndu-i-se un nume la care vor fi legate atributele n momentul crerii
tabelelor.

Nenulitatea
Dei inventat de nsui E.F. Codd, valoarea nul este vehement contestat de
cea mai mare parte a liniei purist-relaionale (Date, Darwen, Pascal). Nu discutm
aici legitimitatea unei asemenea meta-valori, ci doar amintim c ntr-o baza de date
unora dintre atribute li se pot interzice valoarea NULL.

Atomicitate
Conform teoriei bazelor de date relaionale, orice atribut al unei tabele oarecare
trebuie s fie atomic, n sensul imposibilitii descompunerii sale n alte atribute. n
6 Capitolul 2

aceste condiii, se spune c baza de date se afl n prima form normal sau prima
form normalizat (1NF). n tabela STUDENI un atribut cu valori neatomice
poate fi considerat, pentru majoritatea situaiilor, Adresa, ntruct valorile sale
ngrmdesc elemente ce pot fi i individualizate: strada, numr, bloc, scara, etaj,
apartament, localitate i jude.
Astzi, atomicitatea valorii atributelor a devenit o int predilect a atacurilor
dumnoase la adresa modelului relaional, datorit imposibilitii nglobrii unor
structuri de date mai complexe, specifice unor domenii ca: proiectare asistat de
calculator, baze de date multimedia etc. Pentru detalii privind atomicitatea, vezi
capitolul urmtor.

Unicitate
ntr-o relaie nu pot exista dou linii identice (dou linii care prezint aceleai
valori pentru toate atributele). Mai mult, majoritatea relaiilor prezint un atribut,
sau o combinaie de atribute, care difereniaz cu siguran un tuplu de toate
celelalte tupluri ale relaiei. Cheia primar a unei relaii (tabele) este un atribut sau
un grup de atribute care identific fr ambiguitate fiecare tuplu (linie) al relaiei
(tabelei). Exist trei restricii pe care trebuie s le verifice cheia primar:
unicitate: o cheie identific un singur tuplu (linie) al relaiei.
compoziie minimal: atunci cnd cheia primar este compus, nici un atribut
din cheie nu poate fi eliminat fr distrugerea unicitii tuplului n cadrul
relaiei; n cazuri limit, o cheie poate fi alctuit din toate atributele relaiei.
valori non-nule: valorile atributului (sau ale ansamblului de atribute) ce
desemneaz cheia primar sunt ntotdeauna specificate, deci ne-nule; mai
mult, nici un atribut din compoziia cheii primare nu poate avea valori nule.
Cea de-a treia condiie se mai numete i restricie a entitii.
Domeniul unui atribut care este cheie primar ntr-o relaie este denumit
domeniu primar. Dac ntr-o relaie exist mai multe combinaii de atribute care
confer unicitate tuplului, acestea sunt denumite chei candidate. O cheie candidat
care nu este identificator primar este referit ca i cheie alternativ. n tabela
STUDENI, exist dou chei candidat, Matricol i CNP. Pe baza unor criterii
tainice (deocamdat), am ales Matricol drept cheie primar, CNP-ul devenind
cheie alternativ.
Dac cheia primar a tabelei STUDENI este una simpl, exist ns suficiente
cazuri n care cheia primar este compus din dou, trei s.a.m.d. sau, la extrem,
toate atributele relaiei. S lum spre analiz o relaie PERSONAL care conine date
generale despre angajaii firmei. Fiecare tuplu al relaiei se refer la un angajat,
atributele fiind: Nume, Prenume, DataNaterii, Vechime, SalariuTarifar.
Atributul Nume nu poate fi cheie, deoarece chiar i ntr-o ntreprindere de
talie mijlocie, este posibil s existe doi angajai cu acelai nume.
Dac apariia a dou persoane cu nume identice este posibil, atunci
apariia a dou persoane cu acelai Prenume este probabil.
Nici unul din aceste atributele DataNaterii, Vechime, SalariuTari-
far nu poate fi "nzestrat" cu funciunea de identificator.
Proiectarea bazelor de date 7

n acest caz, se ncearc gruparea a dou, trei, patru s.a.m.d. atribute, pn

cnd se obine combinaia care va permite diferenierea clar a oricrei linii
de toate celelalte.
Combinaia Nume+Adres pare, la primele dou vederi, a ndeplini
"cerinele" de identificator. Ar fi totui o problem: dac n aceeai firm
(organizaie) lucreaz mpreun soul i soia ? Ambii au, de obicei, acelai
nume de familie i, tot de obicei, acelai domiciliu. Este adevrat, cazul ales
nu este prea fericit. Dar este suficient pentru a compromiterea
combinaiei.
Urmtoarea tentativ este grupul Nume+Prenume+Adres, combinaie
neoperant dac n organizaie lucreaz tatl i un fiu (sau mama i o fiic)
care au aceleai nume i prenume i domiciliul comun.
Ar rmne de ales una dintre soluiile (Nume+Prenume+Adres+Vechi-
me) sau (Nume+Prenume+Adresa+DataNaterii).
Oricare din cele dou combinaii prezint riscul violrii restriciei de entitate,
deoarece este posibil ca, la preluarea unui angajai n baz, s nu i se cunoasc
adresa sau data naterii, caz n care atributul respectiv ar avea valoarea NULL.
Dificultile de identificare fr ambiguitate a angajailor au determinat firmele ca,
la angajare, s aloce fiecrei persoane un numr unic, numr denumit Marc. Prin
adugarea acestui atribut la cele existente, pentru relaia PERSONAL problema
cheii primare este rezolvat mult mai simplu. Actualmente, sarcina este
simplificat i prin utilizarea codului numeric personal (CNP), combinaie de 13
cifre care prezint avantajul c rmne neschimbat pe tot parcursul vieii
persoanei.

Restricia referenial
O baz de date relaional este alctuit din relaii (tabele) aflate n legtur.
Stabilirea legturii se bazeaz pe mecanismul cheii strine i, implicit, a restriciei
refereniale. Figura 2.2 prezint o relaie n care sunt implicate tabelele TIP_BURSE
i STUDENI. Atributul Tip_Bursa joac un rol de agent de legtur ntre cele
dou relaii. Pentru tabela TIP_BURSE, atributul Tip_Bursa este cheie primar, n
timp ce n tabela STUDENI, Tip_Bursa reprezint o coloan de referin sau cheie
strin (extern), deoarece numai pe baza valorilor sale se poate face legtura cu
relaia printe TIP_BURSE. Cheile strine sau coloanele de referin sunt deci
atribute sau combinaii de atribute care pun n legtur linii (tupluri) din relaii
diferite. Tabela n care atributul de legtur este primar se numete tabel-printe
(n cazul nostru, TIP_BURSE), iar cealalt tabel-copil.
Legat de noiunea de cheie strin apare conceptul de restricie referenial. O
restricie de integritate referenial apare atunci cnd o relaie face referin la o
alt relaie. Cnd dou tabele (relaii), T1 i T2, prezint atributul sau grupul de
atribute notat CH, care, pentru T1, este cheie primar, iar pentru T2 cheie strin,
dac n T2 se interzice apariia de valori nenule ale CH care nu exist n nici un
tuplu din T1, se spune c ntre T2 i T1 s-a instituit o restricie referenial.
8 Capitolul 2

Figura 2.2. Mecanismul de legare a tabelelor

Instituirea restriciei refereniale ntre tabela TIP_BURSE (printe) i STUDENI
(copil) permite cunoaterea, pentru fiecare student, a denumirii bursei i a
cuntumului lunar. Dac n STUDENI ar exista vreo linie n care valoarea atributu-
lui Tip_Burse ar fi, spre exemplu S3, este clar c acea linie ar fi orfan (nu ar avea
linie corespondent n tabela printe).

Observaii
Pentru muli utilizatori i profesioniti ai bazelor de date, denumirea de
"relaional" desemneaz faptul c o baz de date este alctuit din tabele
puse n legtur prin intermediul cheilor strine. Aceasta este, de fapt, a
doua accepiune a termenului de BDR, prima, cea "clasic", avnd n vedere
percepia fiecrei linii dintr-o tabel ca o relaie ntre clase de valori.
Majoritatea SGBD-urilor prezint mecanisme de declararea i gestionare
automat a restriciilor refereniale, prin actualizri n cascad i interzice-
rea valorilor care ar nclca aceste restricii.
Respectarea restriciilor refereniale este una din cele mai complicate sarcini
pentru dezvoltatorii de aplicaii ce utilizeaz baze de date. Din acest punct
de vedere, tentaia este a sparge baza de date n ct mai puine tabele cu
putin, altfel spus, de a avea relaii ct mai corpolente. Gradul de
fragmentare al bazei ine de normalizarea bazei de date, care, ca parte a
procesului de proiectare a BD, se bazez pe dependenele funcionale,
multivaloare i de jonciune ntre atribute.

Restricii-utilizator
Proiectarea bazelor de date 9

Restriciile utilizator mai sunt denumite i restricii de comportament sau

restricii ale organizaiei. De obicei, aceste restricii iau forma unor reguli de
validare la nivel de atribut, la nivel de linie/tabel sau a unor reguli implementate
prin declanatoare (triggere). Spre exemplu, se poate institui o regul care interzice
emiterea unei noi facturi (o nou vnzare) dac datoriile firmei client sunt mai mari
de 2 000 000 000 lei, iar directorul acesteia nu este membru n partidul/partidele de
guvernmnt.

2.2. Nevoia de normalizare

Unul dintre cele mai bune argumente n favoarea normalizrii ine de punerea
n eviden a ceea ce s-ar ntmpla n absena sa. S lum un prim exemplu, cel din
figura 2.3 care este dedicat stocrii datelor privitoare la studenii Facultii de
Economie i Administrarea Afacerilor (sau oricare alta), mai ales n ceea ce privete
situaia colar a acestora. Fiecare student are un identificator unic - Matricol,
este nscris la o specializare ntr-un an de studii i susine examenele la disciplinele
din planul de nvmnt. Orice disciplin are alocat un numr de credite prin
planul de nvmnt al specializrii. Fiecare student poate susine un examen de
mai multe ori pn l promoveaz (sau este exmatriculat). Astfel, Zineanu Ion a
picat examenul la Baze de date I n prima sesiune (pe 29 ianuarie 2004), dar l-a luat
n restane (pe 12 februarie).

STUDENI_EXAMENE
Matricol NumePrenume An Specializare CodDisc
EL13455 Popovici I Vasile 3 Informatic economic AI3501
EL13456 Zineanu W Ion 3 Informatic economic AI3501
EL13457 Ablaei R Zicu 3 Informatic economic AI3501
EL13455 Popovici I Vasile 3 Informatic economic AI3502
EL13456 Zineanu W Ion 3 Informatic economic AI3502
EL13457 Ablaei R Zicu 3 Informatic economic AI3502
EL13456 Zineanu W Ion 3 Informatic economic AI3501
EL13457 Ablaei R Zicu 3 Informatic economic AI3502
EL13458 pag M Michael 3 Informatic economic AI3503

DenumireDisc NrCredite DataExamen Nota

Baze de date I 6 29/01/2004 8
Baze de date I 6 29/01/2004 4
Baze de date I 6 29/01/2004 9
Programare vizual i RAD 7 01/02/2004 10
Programare vizual i RAD 7 01/02/2004 8
Programare vizual i RAD 7 01/02/2004 4
Baze de date I 6 12/02/2004 8
Programare vizual i RAD 7 15/02/2004 9
Analiza sistemelor informaionale 6 04/02/2004 7

Figura 2.3. Relaie supus normalizrii

10 Capitolul 2

Deoarece fiecare linie se refer la un examen susinut la o anumit dat de un

student, cheia primar a relaiei este combinaia (Matricol, CodDisc, DataExa-
men).

2.2.1. Redundane

Este lesne de observat c relaia de mai sus conine redundane. Astfel, dac un
student susine, pe parcursul primelor n semestre de studii, 25 de examene, atunci
matricolul, numele, anul i specializarea sunt prezente n toate cele 25 de linii. Dac
pentru o disciplin s-au consemnat n baza de date 1500 de examinri, atunci nu
numai codul, ci i denumirea i numrul de credite alocat disciplinei apar de
acelai numr de ori.
Cu ct baza de date este mai mare, cu att risipita de spaiu este mai
important. Chiar dac spaiul de stocare nu mai este o problem din punctul de
vedere al costului, obezitatea unei tabele precum cea de mai sus poate atrage
serioase probleme de vitez n exploatare (timpi de ateptare la preluarea noilor
note etc.).

2.2.2. Anomalii la inserare

S lum n discuie studenii din anul I. Dup examenul de admitere, ce are loc
n lunile iulie i septembrie acetia sunt nmatriculai. Dac, ns, baza de date are
schema relaiei de mai sus, preluarea este imposibil pn n momentul primului
examen al studentului respectiv. Aceasta deoarece n cheia primar sunt incluse i
atributele CodDisc i DataEx, iar modelul relaional interzice valori nule pentru
atributele-cheie (restricia de entitate). Ori, la data nmatriculrii, studenii din anul
I nu au nici un examen susinut (asta ar mai trebui !), iar prima sesiune e abia n
ianuarie viitor, aa c i CodDisc i DataEx sunt n acel moment NULL.

2.2.3. Anomalii la modificare

Presupunem c ntr-o furtunoas edin de catedr se decide ca disciplina

Programare vizual i RAD s fie redenumit Programare I, titulatur sub care v
aprea i n foile matricole ale studenilor din actualul an III care vor absolvi, mai
devreme sau mai trziu, specializarea Informatic economic. n baza de date exist
cteva sute de nregistrri referitoare la studeni examinai la aceast disciplin, i
toate trebuie modificate. Dac, dintr-un motiv sau altul, modificarea se face pe
numai o parte dintre liniile cu pricina, putem afirma c datele i pierd consistena.
Dup O'Neil & O'Neil, avem de-a face cu o anomalie de modificare ntr-o relaie
atunci cnd modificarea valorii unui atribut atrage obligativitatea actualizrii
aceleai valori pe mai multe linii4.

4 [O'Neil & O'Neil 01 ] p.357

Proiectarea bazelor de date 11

2.2.4. Anomalii la tergere

Anomaliile la tergere se manifest atunci cnd prin eliminarea unei linii dintr-o
tabel se pierd involuntar nu numai informaiile despre entitatea reflectat pe linia
respectiv, ci i alte informaii. Astfel, dac tergem ultima linie din relaia de mai
sus, cea care conine nota examenului la Analiza sistemelor informaionale susinut de
studentul pag Michael pe 4 februarie 2004, se pierd nu numai datele despre
examenul respectiv, ci i toate informaiile despre studentul pag M. Aceasta
deoarece aceasta era singura linie n care aprea studentul cu pricina.

2.3. Normalizarea - cteva tue

Vzut ca rigoare (matematic sau nu), art (n sensul de curat interpretabil,
dar i de bazat pe intuiie, creatoare), meserie (deprins prin imitaie i
desvrit prin experien), ceea ce se poate spune cu siguran despre
normalizare este, vorba lui C. J. Date, c nu reprezint un panaceu.
Proiectarea bazelor de date relaionale (BDR) presupune definirea atributelor,
gruparea lor n tabele, stabilirea legturilor dintre ele, a mecanismelor de
integritate i securitate, fiind un proces dificil n care cunotinele teoretice,
experiena, inteligena, intuiia i creativitatea proiectanilor se mbin ntr-un mod
mai mult sau mai puin armonios.
Structura final a BD trebuie s asigure un echilibru ntre, pe de o parte,
obinerea unui volum maxim de informaii ntr-un interval de timp ct mai scurt i,
pe de alt parte, eliminarea anomaliilor de stocare i actualizare, toate n condiiile
unui grad apreciabil de securitate i integritate.
Elaborarea schemei unei BD poate ncepe (i) cu gruparea tuturor atributelor ale
bazei de date ntr-o singur tabel (relaie universal). Dincolo de avantajul
compactrii, lucrul cu o singur (i gospodreasc) relaie atotcuprinztoare ridic
serioase probleme privind redundana datelor i genereaz anomalii importante la
adugarea, modificarea sau tergerea unor linii (tupluri), dup cum vzut n
frugalul exemplu din paragraful 2.1.
Ca i consecin direct, este necesar spargerea bazei n mai multe tabele care
sunt legate prin restricii de integritate referenial. Este tocmai obiectivul central al
normalizrii. Spargerea relaiei nu trebuie fcut oricum, deoarece apare riscul
pierderilor de informaii. De asemenea, un numr prea mare de tabele necesit un
efort sporit pentru controlul bazei i respectarea restriciilor. n plus, trebuie s
inem seama de faptul c obinerea multor informaii dintr-o baz de date
fragmentat este posibil prin operaiunea de jonciune, mare consumatoare de
resurse.
ntr-o enumerare mai mult dect seac (deci tiinific), principalele obiective
ale normalizrii sunt:
minimizarea spaiului necesar stocrii datelor;
minimizarea riscului apariiei de date inconsistente n cadrul BD;
12 Capitolul 2

minimizarea anomaliilor ce pot aprea la actualizare (inserarea datelor,

dar mai ales modificare i tergere).;
ameliorarea structurii bazei, reprezentarea diverselor conexiuni dintre
atributele bazei.
diminuarea nevoii de reorganizare periodic a modelului.
Obiect al numeroase studii, nu se poate afirma c exist o unanimitate de idei i
instrumente privind normalizarea. Importana normalizrii nu trebuie absolutizat,
deoarece adesea aceasta vine uneori n contradicie cu parametri extrem de
importani ai aplicaiilor de lucru cu bazele de date: vitez de acces, securitate
mrit, resurse hard/soft disponibile, reducerea traficului pe reea etc. Se poate
spune c o BD riguros normalizat nu este neaprat una optim.
Teoria clasic a normalizrii este construit n jurul a cinci forme care n
literatura noastr sunt referite ca normale [Lungu s.a.95] sau normalizate [Oprea99].
Dei termenul original este normal form (i nu normalized form), mai romnete sun
form normalizat. Nepunnd prea mult pre pe academisme, voi folosi n cele ce
urmeaz ambele sintagme, fr resentimente. Pentru a fi ntr-o anumit form
normal/normalizat o baz de date trebuie s respecte un anumit set de restricii.
Codd, printele modelului relaional, a definit iniial trei forme normale, notate
prin 1NF, 2NF i 3NF. ntruct, ntr-o prim formulare, definiia 3FN ridica ceva
probleme, Codd i Boyce au elaborat o nou variant, cunoscut sub numele Boyce-
Codd Normal Form (BCNF). Dei este vorba, n principiu, de o formulare mai
riguroas a aceleai 3FN, BCNF este prezentat separat n majoritatea lucrrilor.
Formele 4 i 5, legate de numele lui Ronald Fagin, sunt tratate mai cu reinere,
ca s nu spun pudoare, n literatura consacrat analizei i proiectrii bazelor de
date. Ba chiar unele lucrri cu tent mai pragmatic se opresc declarat la 3FN, pe
care o consider suficient n elaborarea BDR.

2.4. Etapele normalizrii

Fundamentul normalizrii BDR l constituie dependenele dintre atribute.
Primele trei forme normale pot fi determinate pe baza dependenelor funcionale
elementare (totale) i tranzitive. Forma a patra (4FN) se bazeaz pe dependenele
multivaloare, n timp ce a cincea form normal (5FN) pe dependenele de
jonciune. Problema este c dependenele multivaloare, i (mai ales) cele de
jonciune sunt dificil de identificat i rar ntlnite n practic.
Normalizarea BDR poate fi imaginat ca un proces prin care, pornindu-se de la
relaia iniial R (universal), se realizeaz descompunerea succesiv a acesteia n
sub-relaii dup succesiunea din figura 2.45. Relaia R poate fi ulterior re-
construit din cele n relaii obinute n urma normalizrii, prin operaii de jonciune
aplicate asupra acestora.

5 Vezi i [Oprea99], p.343

Proiectarea bazelor de date 13

Inceput

Relaie universal - R

nu Exist grupuri da
repetitive ?
Atomizarea atributelor

nu Relaia R are da
cheie primar ?
Descompunere n relaii
ce au cheie primar

1 FN

nu Exist DF da
pariale ?
Aducerea relaiilor n 2FN

2FN

nu Exist DF da
tranzitive ?
Aducerea relaiilor n 3FN

3 FN

nu Toi determinanii da
sunt chei candidate ?
Aducerea relaiilor
n BCFN

BCFN

nu da
Exist DF
multivaloare ?
Aducerea relaiilor n 4FN

4 FN

nu Exist dependene da
de jonciune ?
Aducerea relaiilor n 5FN

5 FN

Sf rit

Figura 2.4. Etapele clasice ale normalizrii bazelor de date relaionale

14 Capitolul 2

Nu putem ncheia acest crochiu al normalizrii fr a insista asupra faptului c,

esenialmente, ingredientul acesteia este de natur semantic. Normalizarea
reflect relaii care se manifest ntre atribute ale bazei. Este imposibil de
normalizat o relaie fr a cunoate fenomenul, procesul pe care l reflect.

2.5. Descompunere fr pierdere de informaii

Pe baza elementelor discutate n paragraful 2.2, rezult c prin normalizare se
ncearc a se elimina redundae i anomalii manifestate la actualizare. Eliminarea
se realizeaz prin "sfrmarea" relaiei n dou sau mai multe relaii "legate" prin
restricii de integritate referenial. Ulterior, prin operaiuni de jonciune, tabela
iniial poate fi recompus, ori de cte ori va fi cazul.
Cu ct "desfacem" relaia iniial (universal) n mai multe tabele, cu att
redundana datelor este mai redus (i, implicit, anomaliile evocate). Exist (i aici),
ns, o limit, deoarece la descompunere trebuie avut n vedere pstrarea unor
structuri care s permit, ulterior, obinerea informaiilor necesare prin operaiuni
de jonciune (apare noiunea de jonciune conservativ).
S presupunem c, n urma depistrii redundanei i anomaliilor de inserare-
modificare-tergere, proiectantul bazei a ales soluia descompunerii relaiei
STUDENI_EXAMENE (figura 2.3) n patru: STUDENI, DISCIPLINE, EXAMENE
i NOTE (figura 2.5).
STUDENI
Matricol NumePrenume An Specializare
EL13455 Popovici I Vasile 3 Informatic economic
EL13456 Zineanu W Ion 3 Informatic economic
EL13457 Ablaei R Zicu 3 Informatic economic
EL13458 pag M Michael 3 Informatic economic

DISCIPLINE
CodDisc DenumireDisc NrCredite
AI3501 Baze de date I 6
AI3502 Programare vizual i RAD 7
AI3503 Analiza sistemelor informaionale 6

EXAMENE NOTE
CodDisc DataExamen Matricol CodDisc Nota
AI3501 29/01/2004 EL13455 AI3501 8
AI3502 01/02/2004 EL13456 AI3501 4
AI3501 12/02/2004 EL13457 AI3501 9
AI3502 15/02/2004 EL13455 AI3502 10
AI3503 04/02/2004 EL13456 AI3502 8
EL13457 AI3502 4
EL13456 AI3501 8
EL13457 AI3502 9
EL13458 AI3503 7

Figura 2.5. O descompunere a relaiei universale STUDENI_EXAMENE

Proiectarea bazelor de date 15

Redundanele au fost reduse simitor. Numele i prenumele fiecrui student

apar pe o singur linie; la fel i denumirea disciplinei i numrul de credite. Cu
toate acestea, dac ncercm s refacem relaia iniial prin interogarea SQL:
SELECT s.matricol, s.numeprenume, s.an,
s.specializare, d.coddisc, d.denumiredisc,
d.nrcredite, e.dataexamen, n.nota
FROM studenti s INNER JOIN note n ON s.matricol=n.matricol
INNER JOIN discipline d ON d.coddisc=n.coddisc
INNER JOIN examene e ON d.coddisc=e.coddisc
s-ar obine tabela STUDENI_EXAMENE2 din figura 2.6.
STUDENI_EXAMENE2
Matricol NumePrenume An Specializare CodDisc
EL13455 Popovici I Vasile 3 Informatica economica AI3501
EL13455 Popovici I Vasile 3 Informatica economica AI3501
EL13456 Zaineanu W Ion 3 Informatica economica AI3501
EL13456 Zaineanu W Ion 3 Informatica economica AI3501
EL13457 Abalasei R Zicu 3 Informatica economica AI3501
EL13457 Abalasei R Zicu 3 Informatica economica AI3501
EL13455 Popovici I Vasile 3 Informatica economica AI3502
EL13455 Popovici I Vasile 3 Informatica economica AI3502
EL13456 Zaineanu W Ion 3 Informatica economica AI3502
EL13456 Zaineanu W Ion 3 Informatica economica AI3502
EL13457 Abalasei R Zicu 3 Informatica economica AI3502
EL13457 Abalasei R Zicu 3 Informatica economica AI3502
EL13456 Zaineanu W Ion 3 Informatica economica AI3501
EL13456 Zaineanu W Ion 3 Informatica economica AI3501
EL13457 Abalasei R Zicu 3 Informatica economica AI3502
EL13457 Abalasei R Zicu 3 Informatica economica AI3502
EL13458 Spaga M Michael 3 Informatica economica AI3503
EL13455 Popovici I Vasile 3 Informatica economica AI3501

DenumireDisc NrCredite DataExamen Nota

Baze de date I 6 29.01.2004 8
Baze de date I 6 12.02.2004 8
Baze de date I 6 29.01.2004 4
Baze de date I 6 12.02.2004 4
Baze de date I 6 29.01.2004 9
Baze de date I 6 12.02.2004 9
Programare vizuala si RAD 7 15.02.2004 10
Programare vizuala si RAD 7 01.02.2004 10
Programare vizuala si RAD 7 15.02.2004 8
Programare vizuala si RAD 7 01.02.2004 8
Programare vizuala si RAD 7 15.02.2004 4
Programare vizuala si RAD 7 01.02.2004 4
Baze de date I 6 12.02.2004 8
Baze de date I 6 29.01.2004 8
Programare vizuala si RAD 7 01.02.2004 9
Programare vizuala si RAD 7 15.02.2004 9
Analiza sistemelor informationale 6 04.02.2004 7
Baze de date I 6 29.01.2004 8

Figura 2.6. Prin recompunere se obine o alt relaie universal dect cea iniial
16 Capitolul 2

Se observ c rezultatul difer sensibil de tabela iniial. Exemplul este un pic

forat, dar n practic deseori apar cazuri cnd erorile de proiectare a bazei sunt
greu de identificat. Ceea ce s-a dorit a se demonstra este faptul c normalizarea nu
nseamn descompunea arbitrar a tabelelor n altele mai mici.

2.6. Relaia universal

Prima etap a normalizrii const n identificarea informaiilor ce trebuie
stocate i gestionate cu ajutorul bazei de date. Este momentul n care la aplicaiile
complexe intr n scen analitii de sistem, cei care observ cum se deruleaz
procesele, operaiunile ce constituie obiectul aplicaiei/bazei de date, discut cu
toate categoriile de utilizatori, ncearc s identifice soluii anterioare de la aceeai
organizaie sau de la organizaii similare pentru a putea anticipa problemele cele
mai dificile etc. Pentru aplicaiile mari munca analitilor i proiectanilor este
extrem de laborioas i consumatoare de timp i nervi. Este unul dintre motivele
pentru care aceast categorie profesional are salarii mari i este destul de
"curtat". Noi vom ncerca s ne plasm ntr-o zon mai "aerisit", fr a cdea in
derizoriu.
Noiunea de relaie universal este unul dintre destulele ingrediente ale
modelului relaiona care ncep prin a prea jenant de banal, i din care, n final,
fiecare nelege ce vrea, fr a ajunge la un punct comun, ci doar la un nor de
puncte de vedere comun. Noi o s considerm relaia universal drept relaia
alctuit din toate atributele identificate ca fiind relevante pentru aplicaie i toate
tuplurile posibile cu valorile acestor atribute6. Prin urmare, schema relaiei
universale conine toate atributele bazei de date.

Baza de date VNZRI

Pe parcusul acestui capitol i urmtoarelor ne propunem s elaborm (i)
schema unei prime baze de date prin care s poat fi gestionate informaiile
relevante despre vnzrile unei firme comerciale, de producie etc. Pentru o mai
bun vizualizare, se poate recurge la o form tabelar de prezentare a datelor, n
care coloanele ar fi: numele atributului, aa cum este folosit n baza de date (ceva
mai scurt), numele ntreg al atributului, tipul atributului, lungimea, explicaii
suplimentare, restricii etc.
Tabelul 2.1 este ceva mai modest, avnd doar dou coloane, dedicate numelui
atributului i unor explicaii sumare. Atributele care intereseaz n mod deosebit
sunt cele legate de:
clieni: codul, denumirea, adresa, codul potal, localitate, judeul (inclusiv
regiunea), codul fiscal, numrul de telefon;

6 Din acest punct de vedere, de plasm mai aproape de accepiunea lui Chris Date ([Date04], p.195)
Proiectarea bazelor de date 17

produse: codul, denumirea, unitatea de msur, grupa (textile,

nclminte, buturi rcoritoare, buturi spirtoase etc.), procentul de TVA
aplicat;
facturi: numrul, data ntocmirii, clientul, observaii (note despre clauze
din factur), apoi produsele vndute n factura respectiv: linia pe care
apare fiecare produs, cantitatea i preul facturat.
ncasri: codul unic asociat fiecrei ncasri, date despre documentul pe
baza cruia se face ncasarea (ordin de plat, cec etc.), numrul facturii
ncasate, trana ncasat din factura respectiv.
Tabel 2.1. VNZRI - dicionarul datelor (simplificat)

Atribut Descriere
Jud Indicativul auto al judeului (2 caractere)
Jude Denumirea judeului
Regiune Regiunea rii din care face parte judeul
CodPost Codul potal al unei adrese
Localitate Denumirea oraului sau satului
Comuna Denumirea comunei din care face parte satul curent
CodCl Codul firmei client
DenCl Denumirea firmei-client
CodFiscal Codul fiscal al firmei client
StradaCl Strada pe care se afl sediul clientul
NrStradaCl Numrul la care se afla adresa clientului
BlocScApCl Eventualele informaii suplimentare despre adresa clientului:
bloc, scar, etaj, apartament
TelefonCl Telefonul firmei client
CodPr Codul produsului / sortimentului comercializat
DenPr Denumirea produsului
UM Unitatea de msur a produsului/sortimentului
Grupa Grupa sortimental (Bere, Ciocolat, Cafea etc.) n care se
ncadreaz produsul curent
ProcTVA Procentul TVA aplicat n mod obinuit produsului
NrFact Numrul facturii emise
DataFact Data ntocmirii facturii
Obs Observaii privitoare la factur
Linie Linia curent (corespunztoare unui produs) dintr-o factur
Cantitate Cantitatea vndut din produs n factur (pe linia curent)
PreUnit Preul unitar de vnzare (fr TVA) al produsului n factur (pe
linia curent)
Codnc Codul ncasrii
Datanc Data ncasrii (n care banii intr n casierie sau n contul bancar)
CodDoc Codul documentului de ncasare
NrDoc Numrul documentului de ncasare
DataDoc Data la care a fost ntocmit documentul de ncasare
Tran Trana primit din factur prin ncasarea (documentul) curent

Una dintre cele mai importante observaii ce se cuvine a fi fcute n acest

moment ine de faptul c o serie de informaii foarte importante, precum:
18 Capitolul 2

valoarea fr TVA a unui produs facturat (de pe o linie a fiecrei facturi);

TVA calculat pe linia unei facturi (pentru un produs vndut);
valoarea cu TVA a unei linii (produs) dintr-o factur;
valoarea fr TVA a unei facturi;
TVA colectat aferent unei facturi;
valoarea total (cu TVA) a unei facturi;
valoarea total a ncasrilor pentru o factur;
valoarea total a vnzrilor ctre fiecare client;
valoarea total a ncasrilor de la un client;
restul de plat pentru fiecare client (diferena vnzri - ncasri);
valoarea vnzrilor pentru fiecare localitate;
valoarea vnzrilor pentru fiecare jude;
valoarea vnzrilor pentru fiecare regiune (Moldova, Banat etc.);
i multe altele au fost eliminate din dicionarul de date, deoarece pot fi calculate
pornind ce la celelalte prezente n dicionar. Vom vedea ceva mai trziu c atunci
cnd este vorba de date accesate n mod frecvent, pentru calcularea crora este
necesar un consum de resurse important, se poate recurge la introducerea
controlat a unor atribute redundante.
O factur conine mai multe linii i poate fi ncasat n una, dou sau mai multe
trane. Deoarece exist un interval ntre momentul ntocmirii de ctre client a
documentului de plat (DataDoc) i momentul intrrii efective a banilor n contul
(sau casieria) firmei (Datanc), se folosesc ambele atribute.

Baza de date FILMOGRAFIE

Pentru un centru de nchirieri video se pune problema constituirii unei baze de
date cu informaii despre filmele aflate pe casetele sau DVD-urile oferite (legal)
spre nchieriere. Fiecare film are un cod unic (identificator), iar atributele principale
sunt cele din tabelul 2.2.
Tabel 2.2. FILMOGRAFIE - dicionarul datelor (simplificat)

Atribut Descriere
IdFilm Codul unic al filmului
TitluOriginal Titlul n englez, francez etc., aa cum apare la lansarea filmului
TitluRO Traducerea romneasc a titlului original
AnLans Anul lansrii
Productori Productorul sau productorii filmului
Regizori Regizorul sau regizorii filmului
Distribuie Actorii i rolurile interpretate n film
Genuri Genul/genurile la care se ncadreaz filmul (horror, comedie etc.)
Premii Numele premiului - tipul (Oscar, Leul de argint, Ursul de aur etc.),
categoria (cel mai bun film, cel mai bun actor n rol principal) anul
premiului i, eventual, numele actorului.
Proiectarea bazelor de date 19

Un film poate fi produs i regizat de una, dou sau mai multe persoane. Pentru
fiecare actor distribuit n film intereseaz i personajul sau personajele (dac
actorul e n dublu rol) interpretate. O pelicul se poate ncadra la mai multe
categorii (dram, comedie) simultan. Dac un premiu se refer la regie, scenariu
etc., intereseaz numele, tipul i anul decernrii, iar dac se refer la o performan
actoriceasc, la informaiile anterioare se adaug i numele actorului laureat.
Practic, dou tupluri din aceast relaie s-ar prezenta c n figura 2.5.

IdFilm TitluOriginal TitluRO AnLans Productori Regizori

11899 As Good As It Mai bine nu se 1997 James Brooks James Brooks
Gets poate Bridget Johnson
Kristi Zea
12345 Bicentennial Omul bicentenar 1999 Michael Barnathan Chris Columbus
Man Chris Columbus
Gail Katz

Distribuie Genuri Premii

Jack Nicholson (Levin Udall)
Helen Hunt (Carol Connelly)
Greg Kinnear (Simon Bishop)
Cuba Gooding Jr. (Frank Sachs)
Robin Williams (Andrew Martin)
Embeth Davidtz (Little Miss Amanda
Martia / Portia Charney)
Sam Neil (Richard Martin)
Oliver Platt (Rupert Burns)
Kiersten Warren (Galatea)
comedie Oscar - cel mai bun actor n rol
dram principal (Jack Nicholson) - 1998
romantic Oscar - cea mai bun actri n rol
principal (Helen Hunt) - 1998
Globul de aur - cea mai bun
imagine - 1998
Globul de aur - cel mai bun actor
ntr-o comedie/musical (Jack
Nicholson) - 1998
Globul de aur - cea mai bun actri
ntr-o comedie/musical (Helen Hunt)
- 1998
SF
dram
romantic

Figura 2.5. O descompunere a relaiei universale FILMOGRAFIE

Aceste dou relaii universale, ca i altele, vor fi supuse, n capitolele urmtoare,
normalizrii i tuturor discuiilor i problemelor legate de acest demers.

ncheiem acest capitol prin a mrturisi c, n ciuda relativei accesibiliti a

noiunilor expuse vis-a-vis de relaia universal, literatura de specialitate a
consemnat cteva dispute pe acest subiect. Spre exemplu, n 1981 William Kent
afirma c includerea tuturor coloanelor ntr-o singur relaie universal foreaz
folosirea valorilor nule7. Aa cum vom discuta spre finalul capitolului urmtor,
chiar dac ne-am numra printre liber-nulliti (cei care sunt de acord cu folosirea
valorilor NULL fr prea mult strngere de inim, printre care se numra nsui
E.F. Codd), de cele mai multe ori relaia universal prezint atribute componente

7 [Kent81]
20 Capitolul 2

ale cheii sale primare ce risc s ia valori nule, ceea ce modelul relaional nu
accept, indiferent de tabere.
n articolul su din 1981, Kent este chiar tranant spunnd c relaia universal
este un model nesatisfctor pentru teoria i practica relaional 8. Afirmaia sa a
strnit reacia a o serie de autori, printre care Jeffrey Ullman9, pentru care care,
dincolo de inadvertene, conceptul de relaie universal este unul polimorfic, fiind
suficient de amintit dou dintre abordri: pe de o parte, ca un soi de creuzet,
rezervor al tuturor atributelor i dependenelor dintre atribute i, pe de alt parte,
ca o perspectiv general a utilizatorilor asupra bazei de date.
Fr a-l supra prea mult pe Ullman, vom considera relaia universal drept o
construcie ipotetic de pornire n demersul normalizrii, fr a fi anxioi privitor
la unicitatea sau neunicitatea sa, i alte proprieti care nu au prea mult tangena
cu proiectarea efectiv a unei baze de date.

8 [Kent81]
9 Vezi, spre exemplu, [Ullman82], [Ullman83]