Prima Forma Normala

Capitolul 3.
Prima form normalizat

Prima form normalizat (1NF) este, n general, tratat cu superficialitate de
majoritatea practicienilor n materie de proiectare a bazelor de date. Aceasta
deoarece principala cerin atomicitatea valorilor este un deziderat uor de
ndeplinit, cel puin la prima vedere. Cele mai sensibile chestiuni n aducerea
relaiilor n 1NF sunt legate de atomicitate, eliminarea grupurilor repetitive,
precum i de stabilirea cheii primare, cheie primar care devine o problem
delicat atunci cnd se pornete de la o relaie cu zeci sau sute de atribute.
Pe de alt parte, noiunea de atomicitate este una destul de alunecoas. Dei n
primele lucrri Codd nu formuleaz o definiie riguroas a atomicitii, timp de
aproape trei decenii majoritatea autorilor din "zona" relaionalului au considerat ca
pe o prim "porunc" a unei relaii (tabele) necesitatea ca valoarea oricrui atribut
pe orice linie (tuplu) s fie una scalar (atomic, nedecompozabil). De ctva timp,
ns, Chris Date i ali relaioniti ncearc c depeasc limitele atomicitii,
nlocuind domeniile cu tipuri care pot fi att scalare, ct i compozite (definite de
utilizator).
3.1. Definiii ale primei forme normalizate

Teoria normalizrii nu face parte, propriu-zis, din modelul relaional. Dintre
toate formele normalizate, doar prima are caracter de obligativitate. O baz de date
este normalizat dac toate relaiile (tabelele) care o alctuiesc se afl mcar n 1NF.
Celelalte forme normale sunt dezirabile pentru diminuarea redundanelor,
spaiului ocupat pe disc sau anomaliilor manifestate la actualizare, ns nu sunt
obligatorii.
Dup Codd, o relaie este n prima form normal dac nici unul dintre domeniile
sale nu conine elemente care sunt, la rndul lor, seturi (ansambluri)1. Se cuvine de
adugat remarca lui Date care crede ca ar fi fost mai nimerit ca, n locul termenului
domenii, Codd s-l fi folosit pe cel de atribute. Actualmente, muli "relaioniti"
prefer termenul tip celui de domeniu2.
Unele lucrri3 definesc o relaie aflat n 1NF ca acea relaie n care fiecare atribut
prezint numai valori atomice, adic toate atributele sunt ne-decompozabile; dup
R.Riordan, o relaie este n 1NF dac domeniile pe care sunt definite atributele relaiei
sunt scalare4. n ediia a treia a crii dedicate sistemelor de baze de date, Connoly i
Begg sunt mai tranani: o relaie n 1NF este o relaie n care intersecia oricrei linii cu
1 [Codd72]
2 [Date04]
3 [Date86], [Miranda&Busta90], [Connoly s.a.96], [Dollinger98]
4 [Riordan99]
2 Capitolul 3
oricare coloan conine o valoare i numai una5. Astfel, 1NF respinge ideea de set de
valori, tuplu de valori sau combinaia acestora ca valoare a unui singur atribut pe
un oricare tuplu (linie) a relaiei.
Ali autori formeaz explicit pentru 1NF i restricia: toate atributele ce compun
relaia s fie n dependen funcional fa de cheia relaiei, ceea este, oarecum, o
tautologie, ntruct una dintre "poruncile" valabile pentru orice tabel stipuleaz
negru pe alb c ntr-o relaie nu pot exista dou tupluri identice sau, altfel spus,
ntr-o relaie trebuie s existe mcar un atribut sau combinaie de atribute ale cror
valori s deosebeasc orice tuplu de toate celelalte sau orice relaie posed o cheie
primar.
Formularea care a generat cele mai multe confuzii este legat de noiunea de
grupuri repetitive6: O relaie n 1NF nu trebuie s conin grupuri repetitive.
De obicei, noiunea de grup repetitiv este raportat direct la cea de atomicitate.
Diferenierea atomicitate grup repetitiv apare n [Lungu s.a.95], pentru care un
atribut atomic este unul simplu (ne-compus): O relaie este n 1NF dac domeniile
pe care sunt definite atributele relaiei sunt constituite numai din valori atomice
(elementare). n plus, un tuplu nu trebuie s conin atribute sau grupuri de
atribute repetitive7. Din pcate, autorii se opresc aici cu definiia, pstrnd o
remarcabil discreie vis-a-vis de ceea ce consider grup repetitiv. La fel stau
lucrurile i la dna. Ileana Popescu8.
Un plus de claritate aduce definiia lui Toby Teorey, pentru care o relaie este n
1NF dac i numai dac toate coloanele conin numai valori atomice; aceasta
nseamn c nu exist grupuri (coloane) repetitive n cadrul vreunei linii a tabelei.
Imediat autoarea precizeaz c un grup repetitiv apare ntr-o tabel atunci cnd unui
atribut multi-valoare i sunt permise dou sau mai multe valori reprezentate n cadrul unei
aceleai linii9. Sau, dup cum spunea Chris Date pn n ediia a asea a celei mai
cunoscute cri a sa, un grup repetitiv reprezint o coloan care conine cteva
valori n fiecare linie, sau, altfel spus, un numr diferit de valori pe linii diferite10.
n concluzie, aducerea unei relaii n 1NF presupune discutarea urmtoarelor
elemente:
raportul atribut simplu/atribut compus;
grupuri repetitive de atribute (pe orizontal);
grupuri repetitive de valori n cadrul fiecrei celule a tabelei.
5 [Connoly & Begg 02], p.388

6 [Date86], [Pratt&Adamski91], [Oprea99]), [Lungu s.a.95]
7 [Lungu s.a. 95], p.169
8 [Popescu 01], p.78
9 [Teorey99], p.99
10 Preluare din ediia a opta a crii ([Date 04], p.153), unde Date se autociteaz pentru a
demonstra c nelesese greit noiunea de domeniu (tip) i, n consecin greise atunci cnd a
formulat definiia 1NF.
Proiectarea bazelor de date 3
3.2. Atribute simple i atribute compuse

Primele vizate de stigmatul neatomicitii sunt atributele compuse. Cu ani
buni n urm, n cursurile de profil, exemplul clasic al unui atribut compus era
DataCalendaristic, alctuit, cum altfel, din cmpurile: Ziu, Lun, An. Era
vremea nfloritoare a COBOLului i FORTRANului, cnd nu existau mecanisme de
declarare i gestionare a variabilelor i atributelor de tip DATE; verificarea
corectitudinii datei calendaristice cdea n sarcina programatorului ce trebuia s
scrie o rutin special.
Astzi, nu exist SGBD sau mediu de programare care s nu prezinte tipul de
dat DATE prin care se gestioneaz simultan toate cele trei elemente; prin funcii
de conversie se pot obine: ziua (DAY), luna (MONTH), anul (YEAR), ba chiar
calcula numrul de zile, luni, ani dintre dou date calendaristice i alte minunii.
Ca s nu mai vorbim de tipul DATETIME i acesta omniprezent n produsele
software ale zilelor noastre.
Un alt exemplu celebru privind atribute compuse (non-atomice) este Adresa.
Fiind alctuit din Strad, Numr, Bloc, Scar, Etaj, Apartament, plus
CodPotal (dup noul sistem de codificare) discuia despre atomicitatea adresei
pare de prisos, iar descompunerea sa imperativ. Din nou ns trebuie s ne
raportm la obiectivele bazei. Fr ndoial c, pentru BD a unei filiale CONEL sau
ROMTELECOM, sau pentru poliie, preluarea separat a fiecrui element
constituent al adresei este vital. Intereseaz, spre exemplu, ce abonai sunt pe
strada Tranziiei sau cte cereri sunt depuse de ceteni de pe strzile Lascr Catargi,
Titu Maiorescu i Marina Scupra. Sau, un cioranian ce lucreaz n cadrul Poliiei, ar
putea fi interesat s afle dac gradul de sinucidere al persoanelor ce locuiesc la
etajul trei este mai mare dect cel al persoanelor de la parter.
Cu totul altfel stau lucrurile pentru un importator direct, pentru un mare en-
grossist sau pentru o firm de producie. Partenerii de afaceri ai acestora sunt
persoane juridice, iar adresa intereseaz numai la nivel general. Este drept c
imediat dup Revoluie deveniser mari furnizori naionali de cupru i aluminiu i
persoane fizice (vezi cazul bulibaei din Ciurea, dar asta-i alt poveste).
Alte exemple de atribute ce pot fi considerate, n funcie de circumstane, simple
sau compuse: DataOperaiuniiBancare (Data+Ora), BuletinIdentitate
(Seria+Numr), NrnmatriculareAuto (privit global, sau pe cele trei
componente: jude, numr i combinaia trei de litere).
n relaia universal FILMOGRAFIE, al crei dicionar de date simplificat este
cel din tabelul 2.2, cel puin dou atribute sunt compuse i trebuie "sparte",
Distribuie i Premii. Astfel, n Distribuie pot fi delimitate mcar dou
informaii, Actor i Rol. n cazul premiilor, ar trebui detaliat discuia prin
introducerea atributelor:
- denumire premiu (Oscar, Globul de aur etc.);
- locul atribuirii (Hollywod, Cannes, Berlin, Veneia, Bucureti etc.);
- categoria (regie, scenariu, actor n rol principal etc.)
- anul decernrii;
4 Capitolul 3
- numele actorului, dac categoria este pentru interpretare.

Astfel, noua form a dicionarului de date este cea din tabelul 3.1.
Tabel 3.1. FILMOGRAFIE - dicionarul datelor (simplificat) - versiunea 2
Atribut Descriere
IdFilm Codul unic al filmului
TitluOriginal Titlul n englez, francez etc, aa cum apare la lansare filmului
TitluRO Traducerea romneasc a titlului original
AnLans Anul lansrii
Productori Productorul sau productorii filmului
Regizori Regizorul sau regizorii filmului
Rol Rolul din film
Actor Actorul care interpreteaz rolul/filmul curente
Genuri Genul/genurile la care se ncadreaz filmul (horror, comedie etc.)
DenPremiu Numele premiului - tipul (Oscar, Leul de argint, Ursul de aur etc.)
LocDecernare Locul n care se organizeaz festivitatea sau festivalul
Categorie Categoria premiului (pentru ce anume se acord premiul)
AnPremiu Anul decernrii
Concluzionnd n termeni rabinici, ambele variante, descompunerea sau

nedescompunerea atributelor compuse, sunt valabile de la caz la caz, alegerea
soluiei fiind n concordan cu specificul bazei de date (i inspiraia
proiectantului). n plus, nu trebuie uitat c i pentru atributele compuse pot fi
extrase destule informaii utiliznd n SQL operatorul LIKE.
Atomicitatea atributelor ntr-o baz de date relaional a fost privit ca o limit
serioas a modelului, datorit imposibilitii adaptrii BDR la specificul unor
domenii precum multimedia, CAD etc. Muli autori, dintre care merit amintii cu
deosebire Chris J. Date i Hugh Darwen, se opun ideii de atomicitate formulat de
Codd (vezi i paragraful 3.5).
3.3. Despre grupuri repetitive i urmrile lor

O relaie (tabel) n 1NF nu trebuie s conin atribute care se repet ca grupuri.
ntr-o alt formulare, toate liniile unei tabele trebuie s conin acelai numr de
atribute. Fiecare celul a tabelei (intersecia unei coloane cu o linie), altfel spus,
valoarea unui atribut pe o linie (nregistrare), trebuie s fie atomic.
Dup [Connoly s.a.96], un grup repetitiv este un atribut sau grup de atribute
dintr-o tabel care apare cu valori multiple pentru o singur apariie a cheii
primare a tabelei ne-normalizate.
S lum exemplul tabelei BIBLIOTEC din figura 3.1. Tabela gestioneaz infor-
maii despre crile existente n depozitul bibliotecii Facultii de Economie i
Administrarea Afacerilor (FEAA). De remarcat c n blibliotec exist dou
exemplare ale crii cu ISBN-ul 973-683-709-2 i trei exemplare de cea dedicat
Visual FoxPro. Prima carte a fost scris de patru autori i i sunt asociate opt
cuvinte-cheie, iar a doua are un singur autor. Relaia nenormalizat conine trei
grupuri repetitive: Cote, Autori i CuvinteCheie.
BIBLIOTEC
ISBN Titlu Cote Autori
973-683-889-7 Visual FoxPro. Ghidul III-13421, III- Marin Fotache, Ioan
dezvoltrii aplicaiilor 13422, III-13423 Brava, Ctlin Strmbei,
profesionale Liviu Creu
973-683-709-2 SQL. Dialecte DB2, Oracle i III-10678, III- Marin Fotache
Visual FoxPro 10679
Editura LocSediuEd AnApariie CuvinteCheie

Polirom Iai 2002 baze de date, SQL, proceduri stocate, FoxPro,
formulare, orientare pe obiecte, client-server, web
Polirom Iai 2001 baze de date, algebr relaional, SQL
Figura 3.1. Relaia universal nenormalizat BIBLIOTEC

Paragrafele urmtoarele sunt dedicate prezentrii unor soluii pentru
eliminarea grupurilor repetitive. Trebuie precizat, ns, c nu ntotdeauna
grupurile repetitive reprezint o problem major. Spre exemplu, ntr-o relaie gen
PERSOANE_CONTACT atributul Telefoane poate avea valori ne-atomice,
deoarece pot exista mai multe numere att la birou, ct i mobile (muli manageri
au cte un aparat pe fiecare reea - Orange, Conex, Zapp)...
3.3.1. Grupuri repetitive pe orizontal
Una dintre cele mai nerecomandate soluii pentru eliminarea grupurilor

repetitive ine de extinderea pe orizontal a tabelelor, prin duplicarea forat a unor
atribute. Revenim la figura anterioar. Pentru a nltura grupurile repetitive de pe
primele dou linii, putem fi tentai s modificm structura tabelei, ca n figura 3.2.
BIBLIOTEC_GRUPURI_REPETITIVE_PE_ORIZONTAL
ISBN Titlu Cota1 Cota2 Cota3
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii III-13421 III-13422 III-13423
aplicaiilor profesionale
973-683-709-2 SQL. Dialecte DB2, Oracle i Visual III-10678 III-10679 NULL
FoxPro
Autor1 Autor2 Autor3 Autor4 Editura LocSediuEd

Marin Fotache Ioan Brava Ctlin Strmbei Liviu Creu Polirom Iai
Marin Fotache NULL NULL NULL Polirom Iai
AnApariie CuvntCheie1 CuvntCheie2 CuvntCheie3 CuvntCheie4

2002 baze de date SQL proceduri stocate FoxPro
2001 baze de date algebr relaional SQL NULL
CuvntCheie5 CuvntCheie6 CuvntCheie7 CuvntCheie8

6 Capitolul 3
formulare orientare pe obiecte client-server web
NULL NULL NULL NULL
Figura 3.2. O soluie (destul de penibil) de eliminare a grupurilor repetitive

Dei tabela se afl n prima form normal, structura acesteia este hilar. Ar
trebui s rezervm cteva zeci de atribute pentru cotele crilor, alt serie de
atribute pentru autori (apropo, care este numrul maxim de autori ce au participat
la scrierea unei cri ?), ca s nu mai vorbim de cuvintele cheie.
Atenie, ns ! Dei hilar, schema de mai sus nu violeaz conceptul de atomici-
tate, oricare ar fi formularea acestuia. Unii autori respectabili, precum Toby
Teorey11, greesc atunci cnd dau exemple de relaii nenormalizate de tipul celor
din figura 3.2 (este drept, la Teorey atributele care se repet n cadrul relaiei au
acelai nume, ceea ce modelul relaional respinge din start).
Aceast variant de normalizare funcioneaz totui n cazuri punctuale. Spre
exemplu, nu este exagerat ca ntr-o tabel s avem atribute de genul celei din figura
3.3.
PERSOANE_1
CNP Nume Prenume DataNaterii CNPMam CNPTat
2641121390802 Bucur Cerasela 21-11-1964 2440611390167 1401205390102
...
Figura 3.3. Un exemplu rezonabil de atribut pseudo-repetitiv

Cum orice persoan are cel mult doi prini (re)cunoscui, putem introduce
grupul de atribute CNPMam, CNPTat, dei, din punct de vedere relaional, este
corect i varianta din figura 3.4.
PERSOANE_2
CNP Nume Prenume DataNaterii CNPPrinte Printe
2641121390802 Bucur Cerasela 21-11-1964 2440611390167 Mam
2641121390802 Bucur Cerasela 21-11-1964 1401205390102 Tat
...
Figura 3.4. O alt prim form normal a relaiei PERSOANE_1
3.3.2. Eliminarea grupurilor repetitive prin adugarea de

tupluri
A doua variant pstreaz structura relaiei (universale sau nu), n sensul c nu

se modific numrul de atribute, adugndu-se tupluri (linii) suplimentare astfel
nct orice valoare a celor trei atribute de tipul "grupuri repetitive" devine atomic.
Apare ns problema: cum anume completm tuplurile pentru ca s fie preluate
toate informaiile, iar, pe de alt parte, eventualele actualizri s nu antreneze
11 [Teorey99], pp.99-100
pierderi sau alterri de informaii ? n acest sens, am putea lua n discuie trei
soluii, dup cum urmeaz.
Numr minim de linii - o singur valoare atomic pentru fiecare atribut

compozit
Avem trei atribute non atomice (multivaloare). n figura 3.1, pentru fiecare
carte, numrul de linii din tabel va fi maximul dintre numrul cotelor, numrul
autorilor i numrul cuvintelor cheie. Astfel, pentru Visual FoxPro sunt trei cote,
patru autori i opt cuvinte cheie; aadar, vom avea opt linii (primele opt din figura
3.5). Valorile cotelor n liniile 4-8 vor fi NULL; la fel valorile atribului Autor
pentru liniile 5-8.
BIBLIOTEC_TUPLURI_NOI_SOLUIA_1
ISBN Titlu Cot Autor
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplicaiilor III-13421 Marin Fotache
profesionale
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplicaiilor III-13422 Ioan Brava
profesionale
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplicaiilor III-13423 Ctlin Strmbei
profesionale
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplicaiilor NULL Liviu Creu
profesionale
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplicaiilor NULL NULL
profesionale
profesionale
profesionale
profesionale
973-683-709-2 SQL. Dialecte DB2, Oracle i Visual FoxPro III-10678 Marin Fotache
973-683-709-2 SQL. Dialecte DB2, Oracle i Visual FoxPro III-10679 NULL
973-683-709-2 SQL. Dialecte DB2, Oracle i Visual FoxPro NULL NULL
Editura LocSediuEd AnApariie CuvntCheie

Polirom Iai 2002 baze de date
Polirom Iai 2002 SQL
Polirom Iai 2002 proceduri stocate
Polirom Iai 2002 FoxPro
Polirom Iai 2002 formulare
Polirom Iai 2002 orientare pe obiecte
Polirom Iai 2002 client-server
Polirom Iai 2002 web

8 Capitolul 3
Polirom Iai 2001 algebr relaional

Figura 3.5. Completarea cu tupluri - soluia 1

Deoarece o cot nu poate identifica dect o singur carte, cheia primar a noii
relaii este alctuit din trei atribute, (Cot, Autor, CuvntCheie). Redundana
datelor este evident. Dac pentru cartea de Visual FoxPro am dori s mai
introducem un nou cuvnt cheie, ar trebui inserat o linie nou n tabel, n care
valorile atributelor Autor i Cot s fie nule. Aceasta nu este ns singura
problem. S presupunem c sintagma proceduri stocate este greit asociat crii de
Visual FoxPro. n mod normal, corectarea acestei greeli presupune tergerea celui
de-al treilea tuplu:
DELETE FROM BIBLIOTEC_TUPLURI_NOI_SOLUTIA_1
WHERE ISBN = '973-683-889-7' AND
cuvntcheie = 'proceduri stocate')
Necazul e c tergerea liniei se face cu dou pierderi de informaii. Prima

pierdere ine de calitatea de coautor al acestei cri a lui Ctlin Strmbei, iar a
doua este legat de exemplarul crii ce are cota III-13423. Aceasta deoarece tuplul
ters era singurul care se referea la autorul i la cota cu pricina.
Am putea ncerca un artificiu, i anume ca tergerea unui cuvnt cheie sau autor
sau cot s nu se fac prin tergerea liniei respective, ci setarea pe NULL a valorii
de pe linia incriminat:
UPDATE BIBLIOTEC_TUPLURI_NOI_SOLUTIA_1
SET cuvntcheie = NULL
WHERE ISBN = '973-683-889-7'
AND cuvntcheie = 'proceduri stocate')
Nici aceast idee nu e din cale-afar de inteligent. Dac am dori eliminarea

sintagmei web pentru aceeai carte:
UPDATE BIBLIOTEC_TUPLURI_NOI_SOLUTIA_1
SET cuvntcheie = NULL
WHERE ISBN = '973-683-889-7' AND cuvntcheie = 'web')
atunci linia modificat devine cu totul de prisos n tabel, toate cele trei atribute,
Cota, Autor i CuvntCheie avnd valori NULL. Cu alte cuvinte, dup
modificare, tuplul nu spune nimic, nu are valoare informaional. Practic, dup
fiecare NULL-izare pe o linie a unuia dintre cele trei atribute trebuie verificat dac
pe linia respectiv celelalte dou atribute au valori NULL, caz n care se poate
terge.
Mai exist o problem i din punct de vedere al coninutului informaional. S
presupunem c ne intereseaz s aflm care sunt autorii ce au scris despre SQL.
innd seama de stuctura relaiei de mai sus, am fi tentai s folosim o selecie
dup cuvntul cheie SQL urmat de o proiecie a valorilor atributului Autor:
SELECT autor
FROM BIBLIOTEC_TUPLURI_NOI_SOLUTIA_1
WHERE cuvntcheie = 'SQL')
Rezultatul furnizat este alctuit din dou linii, una ce conine valoarea Ioan
Brava, iar celalalt valoarea NULL. Lipsesc, deci, ceilali trei autori ai crii despre
Visual FoxPro, din care unul (sracul) a scris chiar o carte despre SQL. Interogarea
ce furnizeaz rspunsul corect trebuie s foloseasc o jonciune sau corelare dup
atributul ISBN. Prin urmare, este necesar de tiut c structura informaional pe
care o reprezint tabela de mai sus are o serie de neajunsuri.
Cel mai net motiv de renunare la aceast variant este prezena valorilor nule
n componena atributelor cheie primar, dup cum vom discuta n paragraful 3.4.
Numr de linii egal cu suma valorilor elementare ale atributelor de tip grup
repetitiv
A doua soluie de completare are n vedere eliminarea problemei de la tergerea
unei linii n cazul soluiei precedente, i anume: pe oricare linie, o valoare nenul a
unuia dintre cele trei atribute atrage dup sine nulitatea celorlalte dou - vezi
figura 3.6. Spre exemplu, prima carte are 3 cote, 4 autori i 8 cuvinte cheie; prin
urmare vor fi necesare 3 + 4 + 8 = 15 linii.
BIBLIOTEC_TUPLURI_NOI_SOLUIA_2
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplicaiilor III-13421 NULL
profesionale
profesionale
profesionale
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplicaiilor NULL Marin Fotache
profesionale
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplicaiilor NULL Ioan Brava
profesionale
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplicaiilor NULL Ctlin Stmbei
profesionale
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplicaiilor NULL Liviu Creu
profesionale
profesionale
profesionale
profesionale
profesionale
profesionale
profesionale
profesionale
profesionale
973-683-709-2 SQL. Dialecte DB2, Oracle i Visual FoxPro NULL Marin Fotache
10 Capitolul 3


Polirom Iai 2002 NULL
Polirom Iai 2002 proceduri stocate
Polirom Iai 2002 FoxPro
Polirom Iai 2002 formulare
Polirom Iai 2002 orientare pe obiecte
Polirom Iai 2002 client-server
Polirom Iai 2002 web

Polirom Iai 2001 algebr relaional

Aceast secund soluie, dei presupune un numr de linii mai mare, elimin
necazul pierderii involuntare de informaii. Astfel, tergerea unui cuvnt cheie nu
va afecta, cu siguran, nici un autor sau exemplar ai crii respective.
Ca i n cazul soluiei anterioare, indezirabilitatea variantei este legat de
prezena valorilor nule n componena atributelor cheie primar.
Numr maxim de linii, egal cu produsul valorilor elementare ale atributelor

de tip grup repetitiv
De data aceast, tiem valorile nule de la rdcin, introducnd n relaie toate
combinaiile Autor-Cot-CuvntCheie. Cum prima carte are 3 cote, 4 autori i 8
cuvinte cheie, n relaia BIBLIOTEC_TUPLURI_NOI_SOLUTIA_3 vor exista 3 * 4

* 8 = 96 de tupluri referitoare la aceasta - vezi figura 3.7.
BIBLIOTEC_TUPLURI_NOI_SOLUIA_3 (fragment)
profesionale
profesionale
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplicaiilor III-13421 Ctlin Stmbei
profesionale
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplicaiilor III-13421 Liviu Creu
profesionale
profesionale
profesionale
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplicaiilor III-13421 Ctlin Stmbei
profesionale
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplicaiilor III-13421 Liviu Creu
profesionale
.... (nc 88 de linii pentru cartea de Visual
FoxPro, plus 6 pentru cartea de SQL )

...

Cele opt linii din figur se refer doar la primele dou cuvinte cheie (baze i date
i SQL) pentru primul exemplar (cota III-13421) din prima carte. Aducerea relaiei
n 1NF eliminnd grupurile repetitive prin adugarea de noi tupluri de aceast
manier se dovedete mai mult dect costisitoare. Aceasta nu numai din punctul
de vedere al spaiului excesiv consumat datorit redundanei masive, dar i dac
ne gndim la anomaliile de actualizare. Spre exemplu, pentru a nu pierde
informaii, atunci cnd adugm un cuvnt-cheie nou pentru cartea luat spre
12 Capitolul 3
analiz, e nevoie s inserm n tabel nu mai puin de 3 (cote) * 4 (autori) = 12 linii.

Dezvoltnd aceast idee optimist, imaginai-v cum stau lucrurile pentru o
lucrare monumental cu 10 autori i 78 de cuvinte-cheie din care n bibliotec
exist 40 de exemplare ?
3.3.3. Eliminarea grupurilor repetitive prin construirea de noi

relaii
Dup nduful provocat de redundana masiv a ultimei soluii de normalizare,

cea care urmeaz este ca o uurare: ruperea din relaia universal a grupurilor i
constituirea de relaii noi12. Spre exemplu n [Lungu s.a.95] este formulat reeta
de aducere a unei relaii n 1NF prin parcurgerea a patru pai:
n relaia universal, n locul atributelor compuse se trec componentele
acestora, ca atribute simple;
se constituie cte o relaie pentru fiecare grup repetitiv;
n schema fiecrei noi relaii obinute la pasul doi se introduce i cheia
primar a relaiei R nenormalizat;
cheia primar a fiecrei noi relaii va fi compus din atributele/atributele
cheie ale R plus unul sau mai multe atribute proprii.
Aplicnd acest algoritm la relaia BIBLIOTEC obinem patru tabele, COTE,

AUTORI_CRI, CRI_CUVCHEIE i CRI cu structura din figura 3.8.
COTE
ISBN Cot
973-683-889-7 III-13421 CRI_CUVCHEIE
973-683-889-7 III-13422 ISBN CuvntCheie
973-683-889-7 III-13423 973-683-889-7 baze de date
973-683-709-2 III-10678 973-683-889-7 SQL
973-683-709-2 III-10679 973-683-889-7 proceduri stocate
973-683-889-7 FoxPro
973-683-889-7 formulare
AUTORI_CRI 973-683-889-7 orientare pe obiecte
ISBN Autor 973-683-889-7 client-server
973-683-889-7 Marin Fotache 973-683-889-7 web
973-683-889-7 Ioan Brava 973-683-709-2 baze de date
973-683-889-7 Ctlin Strmbei 973-683-709-2 algebr relaional
973-683-889-7 Liviu Creu 973-683-709-2 SQL
973-683-709-2 Marin Fotache
973-683-709-2 Marin Fotache
CRI
ISBN Titlu Editura LocSediuEd AnApariie
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii Polirom Iai 2002
aplicaiilor profesionale
12 Soluia este sugerat n [Lungu s.a.95], [Oprea99], [Connoly s.a.96], [Elmasri & Navathe 00] etc.
973-683-709-2 SQL. Dialecte DB2, Oracle i Polirom Iai 2001

Visual FoxPro
Figura 3.8. O patra tentativ de aducere n 1NF a relaiei BIBLIOTEC

Structura obinut se detaeaz prin cel mai mic volum de redundan de pn
acum, ceea ce antreneaz i economii de stocare i reducerea sensibil a anomaliilor
de actualizare. Personal, ns, reproez acestui stil de normalizare bazat pe
eliminarea grupurilor repetitive caracterul prea ochiometric. Observarea
grupurilor repetitive depinde decisiv de ordinea n care sunt dispuse atributele n
relaie (teoria relaional prevede clar c nici ordinea coloanelor, nici cea a liniilor
nu influeneaz coninutul informaional al unei tabele).
S discutm relaia BIBLIOTEC_2, ce are aceeai structur ca BIBLIOTEC,
dar ordinea atributelor este schimbat vezi figura 3.9.
BIBLIOTEC_2
Cot ISBN Titlu Autori
III-13421 973-683-889-7 Visual FoxPro. Ghidul dezvoltrii Marin Fotache, Ioan Brava,
aplicaiilor profesionale Ctlin Strmbei, Liviu Creu
III-10678 973-683-709-2 SQL. Dialecte DB2, Oracle i Visual Marin Fotache
FoxPro
III-10679 973-683-709-2 SQL. Dialecte DB2, Oracle i Visual Marin Fotache
FoxPro
Editura LocSediuEd AnAparitie CuvinteCheie

Figura 3.9. Relaia BIBLIOTEC cu ordinea atributelor schimbat

Tabela BILIOTEC_2 este mai aproape de realitate dect BIBLIOTEC. n
depozit sunt trei exemplare ale crii dedicate Visual FoxPro, acestora
corespunzndu-le trei tupluri n noua relaie. Cheia primar este Cot (observai
c ISBN-ul se repet pe primele trei linii i pe ultimele dou).
Dup calapodul aplicat ceva mai sus, exist dou grupuri repetitive, Autori i
CuvinteCheie. Drept care ne grbim a descompune relaia universal n trei
relaii aflate n 1NF ca n figura 3.10.
COTE_AUTORI COTE_CUVCHEIE
14 Capitolul 3
Cot Autor Cot CuvntCheie

III-13421 Marin Fotache III-13421 baze de date
III-13421 Ioan Brava III-13421 SQL
III-13421 Ctlin Strmbei III-13421 proceduri stocate
III-13421 Liviu Creu III-13421 FoxPro
III-13422 Marin Fotache III-13421 formulare
III-13422 Ioan Brava III-13421 orientare pe obiecte
III-13422 Ctlin Strmbei III-13421 client-server
III-13422 Liviu Creu III-13421 web
III-13423 Marin Fotache III-13422 baze de date
III-13423 Ioan Brava III-13422 SQL
III-13423 Ctlin Strmbei III-13422 proceduri stocate
III-13423 Liviu Creu III-13422 FoxPro
III-10678 Marin Fotache III-13422 formulare
III-10679 Marin Fotache III-13422 orientare pe obiecte
III-13422 client-server
III-13422 web
III-13423 baze de date
III-13423 SQL
III-13423 proceduri stocate
III-13423 FoxPro
III-13423 formulare
III-13423 orientare pe obiecte
III-13423 client-server
III-13423 web
III-10678 algebr relaional
III-10678 SQL
III-10679 algebr relaional
III-10679 SQL
CRI2
Cota ISBN Titlu Editura LocSe- AnApa-
diuEd riie
III- 973-683-889-7 Visual FoxPro. Ghidul dezvoltrii Polirom Iai 2002
13421 aplicaiilor profesionale
III- 973-683-709-2 SQL. Dialecte DB2, Oracle i Polirom Iai 2001
10678 Visual FoxPro
III- 973-683-709-2 SQL. Dialecte DB2, Oracle i Polirom Iai 2001
10679 Visual FoxPro
Figura 3.10. Prima form normalizat a relaiei BIBLIOTEC_2

Teoretic, baza de date din figura 3.10 este n 1NF. Schema sa difer sensibil ns
de aceeai BD care n 1NF arat ca n figura 3.8. Intuim c autorii i cuvintele se
refer la o carte (ISBN), deci la toate exemplarele sale, deci suntem nclinai s
alegem varianta din figura 3.8. Atunci cnd numrul atributelor este mare i
situaia reflectat este complex, identificarea grupurilor repetitive poate deveni,

pe alocuri, o loterie.
Pentru remedierea problemelor datorate caracterului arbitrar al dispunerii
atributelor n relaie, am putea institui o regul: se ncepe cu atributele cele mai
generale (non-repetitive) i se continu apoi ctre cele mai repetitive. n cazul
relaiei BIBLIOTEC, s-ar putea ncepe cu ISBN-ul, continund cu Titlu,
Editur, LocSediuEd, AnApariie, apoi Autori i CuvinteCheie.
Similar, putem s descompunem relaia universal FILMOGRAFIE pe baza
urmtoarelor grupuri repetitive:
- Productori (atributul Productor);
- Regizori (atributul Regizor);
- Distribuie (atributele Rol i Actor);
- Genuri (atributul Gen);
- Premii (atributele DenPremiu, LocDecernare, Categorie, AnPremiu,
Actor).
Obinem ase tabele corespunztoare celor cinci grupuri repetitive, plus ce
rmne din relaia iniial (FILME) - vezi figura 3.11.
FILME
IdFilm TitluOriginal TitluRO AnLans
11899 As Good As It Gets Mai bine nu se poate 1997
12345 Bicentennial Man Omul bicentenar 1999
PRODUCTORI REGIZORI
IdFilm Productor IdFilm Regizor
11899 James Brooks 11899 James Brooks
11899 Bridget Johnson 12345 Chris Columbus
11899 Kristi Zea
12345 Michael Barnathan
12345 Chris Columbus
12345 Gail Katz
DISTRIBUIE GENURI
IdFilm Rol Actor IdFilm Gen
11899 Levin Udall Jack Nicholson 11899 comedie
11899 Carol Connelly Helen Hunt 11899 dram
11899 Simon Bishop Greg Kinnear 11899 romantic
11899 Frank Sachs Cuba Gooding Jr. 12345 SF
12345 Andrew Martin Robin Williams 12345 dram
12345 Little Miss Amanda Martia Embeth Davidtz 12345 romantic
12345 Portia Charney Embeth Davidtz
12345 Richard Martin Sam Neil
12345 Rupert Burns Oliver Platt
12345 Galatea Kiersten Warren
PREMII
IdFilm DenPremiu LocDe- Categorie AnPre- Actor
16 Capitolul 3
cernare miu
11899 Oscar Hollywood cel mai bun actor n rol 1998 Jack Nicholson
principal
11899 Oscar Hollywood cea mai bun actri n 1998 Helen Hunt
rol principal
11899 Globul de aur New York cea mai bun imagine 1998 NULL
11899 Globul de aur New York cel mai bun actor ntr-o 1998 Jack Nicholson
comedie/musical
11899 Globul de aur New York cea mai bun actri ntr- 1998 Helen Hunt
o comedie/musical
Figura 3.11. Constituirea de relaii separate pentru fiecare grup repetitiv pentru BD
FILMOGRAFIE
Gselnia funcioneaz n cazul relaiei referitoare la crile din biblioteca FEAA
i la filmografie. Schimbm ns datele problemei. Lum n discuie tabela
DOTARE_JUCRII din figura 3.12 care gestioneaz dotarea cu jucrii a fiecrui
copil al unei familii. n spiritul dreptului inviolabil la proprietate i al luptei contra
colectivismului, fiecare jucrie aparine, cel puin oficial, unui singur copil al
familiei, eventualele mprumuturi fiind rodul exclusiv al negocierilor (i violenei
juvenile).
DOTARE_JUCRII
CodFamilie NumeFamilie Copil Jucrii DataCumprrii
1111 Popescu Ioan Marc Trenule electric 14-05-1998
Loredana Ppu Barbie 15-09-1998
Elvis Puzzle 200 piese 23-12-1998
Puzzle 250 piese 14-05-1999
Puzzle 200 piese 24-12-1999
Csua Lego 08-03-2000
...
Figura 3.12. Relaie ne-normalizat

Din examinarea relaiei de mai sus, reiese c exist dou grupuri repetitive:
Copii i (Jucrii, DataCumprrii). Prin aplicarea regulii de separare a
grupurilor repetivive, obinem trei relaii, COPII, JUCRII, FAMILII - vezi figura
3.13.
COPII JUCRII
CodFamilie Copil CodFamilie Jucrii DataCumprrii
1111 Marc 1111 Trenule electric 14-05-1998
1111 Loredana 1111 Ppu Barbie 15-09-1998
1111 Elvis 1111 Puzzle 200 piese 23-12-1998
1111 Puzzle 250 piese 14-05-1999
1111 Puzzle 200 piese 24-12-1999
1111 Csua Lego 08-03-2000
FAMILII
CodFamilie NumeFamilie
1111 Popescu Ioan
Figura 3.13. Baza de date DOTARE_JUCRII adus n 1NF prin eliminarea grupurilor
repetitive
Dei nu am fcut dect s urmm un algoritm prescris ca sigur, avem de a face
cu un caz tipic de descompunere cu pierdere de informaii. n cazul nostru, cele trei
relaii nu furnizeaz o informaie esenial: crui copil i aparine o jucrie anume.
Oricum am proceda, eliminarea grupurilor repetitive nu rezolv corect
ntotdeauna problema normalizrii (aducerii relaiei n 1NF i continurii apoi cu
2NF s.a.m.d.), deoarece identificarea lor se face prin observaie i nu pe baza unei
analize semantice riguroase a relaiilor dintre atribute.
Dei atrage un grad de redundan considerabil, este recomandabil ca n aceast
situaie 1NF a relaiei s fie obinut prin introducerea n tabel a unei linii pentru
fiecare jucrie i duplicarea valorilor celorlate atribute, ca n figura 3.14.
DOTARE_JUCRII_1
CodFamilie NumeFamilie Copil Jucrie DataCumprrii
1111 Popescu Ioan Marc Trenule electric 14-05-1998
1111 Popescu Ioan Loredana Ppu Barbie 15-09-1998
1111 Popescu Ioan Elvis Puzzle 200 piese 23-12-1998
1111 Popescu Ioan Loredana Puzzle 250 piese 14-05-1999
1111 Popescu Ioan Marc Puzzle 200 piese 24-12-1999
1111 Popescu Ioan Loredana Csua Lego 08-03-2000
Figura 3.14. Relaia adus n 1NF

Esenial n rezolvarea problemei este contientizarea entitii creia i se aloc o
linie n tabel. n cadrul relaiei DOTARE_JUCRII_1, fiecare linie se refer la o
jucrie afectat unui copil al unei familii.
Nici relaia universal VNZRI, ale crei atribute sunt cele din tabelul 2.1, nu
este scutit de probleme la identificarea atributelor repetitive, dar amnm discuia
pentru paragraful urmtor.
3.4. Prima form normal i problema cheii primare a

relaiei universale
De cele mai multe ori, constituirea unei relaii universale atotcuprinztoare se
lovete de o problem major cea a cheii primare. Asupra acestui necaz, civa
autori au atras atenia cu ceva timp n urm13. Modelul relaional prezin dou
restricii eseniale vis-a-vis de cheia primar: unicitate i valori nenule pentru
atributele din alctuirea cheii (restricia de entitate). Or, dac dorim s identificm
fiecare linie a relaiei, trebuie s definim, n cele mai multe situaii, o cheie primar
cu multe atribute, care, ns, n anumite tupluri ar avea valori nule. Pe de alt
13 Vezi, spre exemplu, [Kent81]

18 Capitolul 3
parte, dac nu vrem s fie violat restricia de entitate, trebuie s renunm la a

prelua n relaia universal linii vitale din punctul de vedere al coninutului
informaional al bazei de date.
S lum n discuie cteva cazuri.
Vechea codificare potal, valabil pna n mai 2003

Pn n luna mai 2003 codurile potale erau atribuite la nivel de ora i comun
(cu unele excepii), ca n figura 3.15. Dac ntr-o comun erau mai multe sate, era
posibil ca unele dintre acestea s partajeze acelai cod potal. Singurul ora pentru
care existau mai multe coduri era Bucuretiul.
LOCALITI_CODURI_VECHI
CodPotal OraComun Sat Jude
5319 Vntori Vntori Vrancea
5319 Vntori Jorti Vrancea
5319 Vntori Mircetii-Vechi Vrancea
5613 Roznov Roznov Neam
5613 Roznov Slobozia Neam
5300 Focani NULL Vrancea
Figura 3.15. Vechile coduri potale - tabela nu este n 1NF

O localitate desemneaz un ora sau un sat. Ei bine, cheia primar ar trebui s
fie combinaia (CodPotal, OraComun, Sat). Dar valoarea atributului Sat
este NULL atunci cnd linia respectiv se refer la un ora. Prin urmare, relaia de
mai sus nu se afl n prima form normal, deoarece ncalc restricia de entitate
(un atribut din cheie prezint valori nule). Practic, pentru a fi n 1NF, relaia nu
trebuie s conin oraele, ceea ce este de neacceptat. Aducerea sa n 1NF se
realizeaz prin intermediul depedendenelor funcionale. Este drept, c putem
pcli teoria i SGBD-urile actuale, definind pentru atributul Sat o valoare
implicit nenul spre exemplu un spaiu. Aceasta miroase ns a crpeal
mioritic i vom vedea n paragraful urmtor c avem soluii mai onorabile.
Noua codificare potal, valabil dup mai 2003

Sistemul de codificare potal introdus n mai 2003 este mult mai fin, n sensul
c un cod are acum ase cifre, n loc de patru, iar alocarea se mai face la nivel de
localitate doar n cazul satelor i oraelor mai mici; n rest, la nivel de strad sau
chiar imobil - vezi figura 3.16.
Astfel, n tabela CODURI_NOI_V1 prima linie indic faptul c localitatea
Vntori din judeul Vrancea are codul potal 627395, localitatea fiind i "capital"
de comun, cel puin dup nume. Urmtoarele dou linii se refer la alte dou sate
din aceeai comun. Valorile NULL ale atributelor Strada i Numere pe aceste
prime trei linii semnalizeaz faptul c pentru aceste sate nu se opereaz o
delimitare a codurilor pe strzi (de fapt, ulie).
Lucrurile devin cu adevrat interesante odat cu liniile 4-7 care conin coduri
potale ale unor adrese (locaii, n limbaj contemporan) din municipiul Iai. Pentru
simplificare, toate cele patru coduri sunt atribuite unor adrese aflate pe bulevardul
Independenei. Astfel, codul 700106 este asociat tuturor imobilelor din Bd. Indepen-
denei, iar valoarea 1-5, 9-13 pentru atributul Numere desemneaz urmtoarele
numere: 1, 3, 5 (1-5) i 9, 11, 13 (9-13). Valoarea aceluiai atribut pe linia urmtoare
(codul 700099) - 18-T indic un set de valori pare ce ncepe cu 18 i continu cu 20,
22, ... pn la ultima adres par de pe bulevardul Independenei. T-ul nseamn
deci "Terminare", epuizare, i asigur atribuirea automat a acestui cod potal
eventualelor viitoare construcii ridicate pe acest bulevard (dac o mai fi loc). Pe
linia de mai jos valoarea 25-T se refer la toate numele impare ncepnd cu 25 pn
la ultimul imobil situal pe acea parte ("impar") a bulevardului. Penultima linie a
tabelei semnaleaz un lucru oarecum deranjant: un cod potal poate fi alocat chiar
i la dou sau mai multe strzi, n cazul nostru, numerelor pare de la 2 la 26 i
numrului 28 de pe bulevardul Carol I, dar i tuturor numelor de pe aleea Veronica
Micle (n tabel este preluat titulatura de pe www.posta-romana.ro).
CODURI_NOI_V1
CodPotal Localitate Strada Numere Comuna Jude
627395 Vntori NULL NULL Vntori Vrancea
627397 Jorti NULL NULL Vntori Vrancea
627399 Mircetii-Vechi NULL NULL Vntori Vrancea
700106 Iai Bd. Independenei 1-5 NULL Iai
9-13
700099 Iai Bd. Independenei 18-T NULL Iai
700102 Iai Bd. Independenei 25-T NULL Iai
700100 Iai Bd. Independenei 7-13 NULL Iai
700505 Iai Bd. Carol I 2-26 NULL Iai
28
Aleea Micle Veronica T
700482 Iai Bd. Carol I 26A NULL Iai
30-32
36
700504 Iai Bd. Carol I 28A NULL Iai
34
38
42
707295 Mirceti NULL NULL Mirceti Iai
Figura 3.16. Noile coduri potale - tabel nenormalizat

Firete, ne punem ntrebarea: de ce codul 700505 nu a fost atribuit succesiunii 2-
28 de pe Bd. Carol I, ci avem dou intervale, 2-26 i 28-28 ? Rspunsul ni-l ofer
rndul urmtor, din care aflm c 26A de pe Bd. Carol I are alt cod - 700482 ! Prin
urmare, acelai numr poate fi alocat codurilor diferite, diferenierea fcndu-se
prin litere sau binecunoscutul bis.
Cheia primar este atributul CodPotal, ns relaia este departe de 1NF.
Avem de a face cu dou atribute multivaloare: Strada i Numere. O prim idee
ar fi s rupem relaia, constuind cte o tabel pentru fiecare grup repetitiv, ca n
figura 3.17.
CODURI_LOCALITI
20 Capitolul 3
CodPotal Localitate Comuna Jude

627397 Jorti Vntori Vrancea
627399 Mircetii-Vechi Vntori Vrancea
700106 Iai NULL Iai
700099 Iai NULL Iai
700102 Iai NULL Iai
700100 Iai NULL Iai
700505 Iai NULL Iai
700482 Iai NULL Iai
700504 Iai NULL Iai
707295 Mirceti Mirceti Iai
CODURI_STRZI CODURI_NUMERE
CodPotal Strada CodPotal Numere
700106 Bd. Independenei 700106 1-5
700099 Bd. Independenei 700106 9-13
700102 Bd. Independenei 700099 18-T
700100 Bd. Independenei 700102 25-T
700505 Bd. Carol I 700100 7-13
700505 Aleea Micle Veronica 700505 2-26
700482 Bd. Carol I 700505 28
700504 Bd. Carol I 700505 T
700482 26A
700482 30-32
700482 36
700504 28A
700504 34
700504 38
700504 42
Figura 3.17. Tentativ euat de normalizare a relaiei CODURI_NOI_V1

Dup cum am mai pit-o n paragraful anterior, ruperea relaiei iniiale s-a
fcut cu pierderi de informaii. Deoarece un cod potal poate fi alocat la dou strzi
diferite (vezi 700505), numerele din CODURI_NUMERE nu pot fi alocate corect
ntotdeauna.
O alt cale ar fi s nlocuim atributul Numere cu nu mai puin de patru

cmpuri, pentru a ctiga n limpezime informaional, dup cum urmeaz:
TipNr (tip numr) care s conin doar valorile:
o NULL - pentru localiti fr o delimitare oficial pe strzi;
o "pare" - adic 1, 3, 5, ...;
o "impare" - adic 2, 4, 6;
o "ambele" - adic numere consecutive;
NrIniial (numrul iniial) indic numrul limit inferioar a
intervalului;
LitIniial (litera iniial, dac este cazul) se folosete pentru a indica
dac intervalul pornete de la 11B sau 24A etc.;
NrFinal (numrul final din interval) indic numrul limita superioar a

intervalului;
LitFinal (litera final) semnalizeaz c c intervalul se oprete la 11B
sau 24A etc.
Astfel, tabela de mai sus ar prelua forma din figura 3.18.
CODURI_NOI_V2
CodPotal Localitate Strada TipNr NrIniial LitIniial
627395 Vntori NULL NULL NULL NULL
627397 Jorti NULL NULL NULL NULL
627399 Mircetii-Vechi NULL NULL NULL NULL
700106 Iai Bd. Independenei impare 1 NULL
700099 Iai Bd. Independenei pare 18 NULL
700100 Iai Bd. Independenei impar 7 NULL
700505 Iai Bd. Carol I pare 2 NULL
700505 Iai Aleea Micle Veronica ambele 1 NULL
700482 Iai Bd. Carol I pare 26 A
700504 Iai Bd. Carol I pare 28 A
707295 Mirceti NULL NULL NULL NULL
NrFinal LitFinal Comuna Jude

NULL NULL Vntori Vrancea
5 NULL NULL Iai
13 NULL NULL Iai
NULL NULL NULL Iai
NULL NULL NULL Iai
13 NULL NULL Iai
26 NULL NULL Iai
28 NULL NULL Iai
NULL NULL NULL Iai
26 A NULL Iai
32 NULL NULL Iai
36 NULL NULL Iai
28 A NULL Iai
34 NULL NULL Iai
38 NULL NULL Iai
42 NULL NULL Iai
NULL NULL Mirceti Iai
Figura 3.18. Noile coduri potale - tabel normalizat dar fr cheie primar
22 Capitolul 3
Spre deosebire de forma nenormalizat, tabela de mai sus ar permite gsirea

imediat a codului potal al unei adrese de genul Bd. Carol I nr 29. Dei am putea
folosi un limbaj mai abstract de genul celui din ediia a opta a lucrrii lui Chris
Date, vom recurge la SQL:
SELECT codpostal
FROM CODURI_NOI_V2
WHERE jude = 'Iai' AND localitate='Iai' AND Strada='Bd.
Carol I' AND
(
(nriniial = 29 and litiniial IS NULL) OR
(nrfinal = 29 and litfinal IS NULL)
OR
(tipnr <> 'pare' AND nriniial < 29 AND nrfinal > 29 )
)
Ca exerciiu pentru acas, ncercai s aflai acceai informaie din schema

nenormalizat a tabelei (CODURI_NOI_V2).
n modelul relaional este obligatoriu ca orice relaie s posede cheie primar,

alctuit, la limit, din toate atributele relaiei. Altfel spus, dac n SQL o tabel
poate avea linii identice, n teoria relaional nu. Este una dintre "mbuntirile"
SQL care au atras mnia multor autori majori n domeniul bazelor de date
relaionale, precum E.F. Codd, C.J. Date, H. Darwen, F. Pascal.
Ei bine, pentru a identifica un tuplu unic n relaia de mai sus am avea nevoie
de combinaia (CodPotal, Strada, NrIniial, LitIniial). Or, n
majoritatea tuplurilor tabelei de mai sus, cel puin unul dintre acestea are valori
nule. Dup cum observm, problema vine din regimul diferit al localitilor fr
codificare la nivel strzi (satele i micile orae). Aa nct vom sparge relaia
CODURI_NOI_V2 n dou, CODURI_SATE i CODURI_ORAE. Denumirea este
discutabil, deoarece este posibil s existe sate mai mari, n curs de a deveni orae,
crora s li se repartizeze mai multe coduri. Pentru simplitate, pstrm cele dou
denumiri, iar coninutul ar fi cel din figura 3.19.
CODURI_SATE
CodPotal Localitate Comuna Jude
627397 Jorti Vntori Vrancea
627399 Mircetii-Vechi Vntori Vrancea
707295 Mirceti Mirceti Iai
CODURI_ORAE
Cod Locali Strada TipNr NrIni- LitIni- NrFi- LitFi- Ju-
Potal tate ial ial nal nal de
700106 Iai Bd. Independenei impare 1 5 NULL Iai
700106 Iai Bd. Independenei impare 9 13 NULL Iai
700099 Iai Bd. Independenei pare 18 NULL NULL Iai
700102 Iai Bd. Independenei impare 25 NULL NULL Iai
700100 Iai Bd. Independenei impar 7 13 NULL Iai
700505 Iai Bd. Carol I pare 2 26 NULL Iai

700505 Iai Aleea Micle Veronica ambele 1 NULL NULL Iai
700482 Iai Bd. Carol I pare 26 A 26 A Iai
700504 Iai Bd. Carol I pare 28 A 28 A Iai
Figura 3.19. Tabele separate pentru localitile cu un singur cod i pentru localitile cu
mai multe coduri
CODURI_SATE are o mndree de cheie primr: CodPotal. La
CODURI_ORAE n-am scpat de improvizaii. Astfel, pentru a evita nulitatea
literei iniiale, am folosit spaiul, aa nct cheia primar este (CodPotal,
Strada, NrIniial, LitIniial).
Am rezolvat o problem i am dat de alta: la majoritatea cutrilor trebuie s
efectum n prealabil reuniunea celor dou tabele, ceea ce e destul de apstor.
Spre exemplu, primul i ultimul cod potal alocat judeului Iai este necesar o
interogare de genul:
SELECT MAX(codpotal) AS cod_minim,

MAX(codpotal) AS cod_maxim
FROM
(SELECT codpotal, localitate, NULL AS strada,
NULL AS tipnr, NULL AS nriniial,
NULL AS litiniial, NULL AS nrfinal,
NULL AS litfinal, comuna, jude
FROM coduri_sate
UNION
SELECT codpotal, localitate, strad, tipnr, nriniial,
litiniial, nrfinal, litfinal, NULL, judeu
FROM coduri_orae)
WHERE judet='Iai'
Marea majoritate a practicienilor prefer soluia gordian, adic folosirea unei

chei surogat care este unic pentru fiecare linie (atributele de tip cheie surogat pot
fi n majoritatea SGBD-urilor gestionate automat) - vezi tabela CODURI_NOI_V3
din figura 3.20. Risipa de spaiu generat de introducerea acestui atribut reprezint
un pre rezonabil la durerile de cap pricinuite de valorle nule ale "fostelor" atribute
cheie. Atributul Id nu are nici o relevan informaional, ci doar ne ajut s
asigurm unicitatea cheii primare fr pericolul nclcrii restriciei de entitate.
CODURI_NOI_V3
Id CodPotal Localitate Strada TipNr NrIniial
3456789 627395 Vntori NULL NULL NULL
3456790 627397 Jorti NULL NULL NULL
3456791 627399 Mircetii-Vechi NULL NULL NULL
24 Capitolul 3
3456792 700106 Iai Bd. Independenei impare 1

3456794 700099 Iai Bd. Independenei pare 18
3456796 700100 Iai Bd. Independenei impar 7
3456797 700505 Iai Bd. Carol I pare 2
3456799 700505 Iai Aleea Micle Veronica ambele 1
3456807 707295 Mirceti NULL NULL NULL
LitIniial NrFinal LitFinal Comuna Jude

NULL NULL NULL Vntori Vrancea
NULL 5 NULL NULL Iai
NULL NULL NULL NULL Iai
A 26 A NULL Iai
A 28 A NULL Iai
NULL NULL NULL Mirceti Iai
Figura 3.20. Noile coduri potale - tabel normalizat dar fr cheie primar
Atenie, ns ! Cheile surogat constituie o tentaie creia (ca oricrei tentaii)
trebuie s i se dea curs cu moderaie.
Baza de date VNZRI

i relaia universal a bazei de date VNZRI sufer de aceai problem a
cheii primare, i, implicit, prima form normal este mai mult dect discutabil.
Conform "preceptelor" relaionale, VNZRI {Jud, Jude, Regiune, CodPost,
Localitate, Comun, CodCl, DenCl, CodFiscal, StradaCl, NrStradaCl, BlocScApCl,
TelefonCl, CodPr, DenPr, UM, Grupa, ProcTVA, NrFact, DataFact, Obs, Linie,
Cantitate, PreUnit, Codnc, Datanc, CodDoc, NrDoc, DataDoc, Tran} trebuie s
prezinte o combinaie de atribute a crei valori confer unicitate fiecrui tuplu.
innd seama c:
- un client are un singur sediu central (poate avea filiale, ns ne limitm la a
considera c facturarea se face pe adresa sediului central);
- o factur emis are un numr unic i se ntocmete unui singur client;
- o factur conine una sau mai multe linii;
- pe fiecare linie este nregistrat un produs, fiecare vndut ntr-o anumit
cantitate i la un anumit pre unitar;
- deoarece este posibil re-diferenierea procentului de tax pe valoarea
adugat n funcia de categoria produselor (alimentare, medicamente,
cri, bunuri considerate de lux etc.), ProcTVA este bine de asociat fiecrui
produs;
- o ncasare are la baz un document justificativ;
- o factur poate de pltit de client n trane;
- la o ncasare se pot achita, integral sau parial, una sau mai multe facturi,
cheia primar ar fi combinaia (NrFact, Linie, Codnc). Necazul este c la
momentul ntocmirii nu se cunosc datele despre ncasri. Mai mult, aceasta poate
surveni la distane mari n timp, mai ales n condiiile blocajelor financiare care ne-
au fcut celebri n mediul economic european.
Potrivit primei soluii care nu ncalc restricia de entitate, inserarea de linii n
tabela VNZRI se face abia n momentul ncasrii facturii, ceea ce este inadmisibil,
ntruct baza de date va fi incapabil s furnizeze informaii vitale precum:
vnzrile pe ziua, sptmna, luna, anul curente;
vnzrile pe produse;
vnzrile pe clieni;
creanele (valoarea rmas de ncasat) fa de clieni.
A doua soluie este spargerea relaiei universale. Cum ? Prin eliminarea

grupurilor repetitive. Dar care sunt grupurile repetitive, n condiiile n care o
factur poate fi achitat n trane (mai multe ncasri), iar o ncasare poate "regla"
mai multe facturi ? Vom vedea n capitolele viitoare cum, pe baza dependenelor
funcionale, putem obine o structur mult mai acceptabil.
Baza de date FILMOGRAFIE

n paragraful anterior am obinut o schem ce se apropie destul de mult de
rezonabil, cel puin n materie de eliminare a grupurilor repetitive. Dintre cele ase
tabele ale bazei de date FILMOGRAFIE din figura 3.11 s examinm pre de cteva
minute pe ultima - PREMII. Cheia primar este combinaia (IdFilm, DenPremiu,
Categorie, AnPremiu) n condiiile n care orice premiu de interpretare se
acord unui singur actor/actri. Ce se fi ntmpl ns dac Oscarul pentru cel mai
bun actor n rol principal ar fi fost acordat simultan lui Robert de Niro i Al Pacino
pentru prestaia lor dintr-un film celebru, n care, practic, nu putem spune c unul
din roluri este principal, iar cellalt secundar. Toate cele patru atribute ale cheii ar
26 Capitolul 3
prezenta valori identice pe dou tupluri (un tuplu pentru de Niro, cellalt pentru
Pacino), iar restricia de cheie primar ar fi nclcat.
Cnd proiectm baze de date trebuie s ne gndim i la astfel de spee
marginale ce pot compromite o structur chiar dup ani buni de funcionare a
aplicaiei. Fiind tentai s adugm celor patru atribute din cheie pe al cincilea,
Actor, nu putem s nu observm c, pentru premiile acordate la categoriile regie,
scenariu etc., acest atribut are valori NULLe, ceea ce violeaz restricia de entitate.
Soluia cea mai la ndemn ine de ruperea acestei relaii n dou, una dedicat
premiilor de interpretare, iar a doua celorlalte premii - vezi figura 3.21.
PREMII_INTERPRETARE
IdFilm DenPremiu LocDe- Categorie AnPre- Actor
cernare miu
11899 Oscar Hollywood cel mai bun actor n rol 1998 Jack Nicholson
principal
11899 Oscar Hollywood cea mai bun actri n 1998 Helen Hunt
rol principal
11899 Globul de aur New York cel mai bun actor ntr-o 1998 Jack Nicholson
comedie/musical
11899 Globul de aur New York cea mai bun actri ntr- 1998 Helen Hunt
o comedie/musical
CELELALTE_PREMII
IdFilm DenPremiu LocDe- Categorie AnPre-
cernare miu
11899 Globul de aur New York cea mai bun imagine 1998
Figura 3.21. Ruperea relaiei PREMII din cauza problemelor de cheie primar
3.5. Dezbateri pe marginea i n centrul primei forme

normale
Prima form normal este, fr ndoial, un ciudat amestec de facil i confuz.
Putem spune chiar c mare parte din doza de facil, de superficialitate din cursurile
universitare, crile dedicate bazelor de date sau chiar proiectrii bazelor de date
(inclusiv normalizrii) i au sorgintea tocmai n confuzia care a nvluit, nc de la
nceputurile relaionalului, definirea prime forme normale i atomicitii14. Unii
autori, precum Elmasri i Navathe, consider restricia de atomicitate proprie
modelului relaional, restricie care este este eliminat din modelele relaional
imbricat (nested relational model) i obiectual-relaional care, ambele, permit relaii
nenormalizate15.
14 Exist lucrri respectabile, precum [Atzeni s.a. 99], care nici nu fac aluzie la prima form
normal sau atomicitatea valorilor ntr-o relaie
15 [Elmasri & Navathe 00], p. 485
Ceea ce se nelegem ndeobte prin atomicitatea atributelor ine de caracterul

scalar al valorilor: ntregi, iruri de caractere, date calendaristice. Prin comparaie,
un atribut nonatomic este unul definit pe un domeniu de valori compozite,
complexe. Fiecare component dintr-o valoare compozit poate fi, la rndul ei,
compozit, ajungndu-se la o structur ierarhic i flexibil, n funcie de natura
obiectului sau procesului modelat. Elmasri i Navathe sunt ct se poate de limpezi:
pentru atributele unei relaii n 1NF, singurele valori permise sunt cele atomice sau
indivizibile16.
n ceea ce m privete, materialul favorit legat de 1NF este cel al lui Chris Date
publicat n iunie 2003 pe site-ul http://www.dbdebunk.com17, site conceput i
gestionat de un apropiat al lui Date i un necrutor observator al ignoranei
comunitii IT (i academice) n materie de baze de date - Fabian Pascal. Materialul
evocat constituie deopotriv ncununarea i convergena lucrrilor scrise singur
(cea mai celebr este cartea a crei a opta ediie a fost tradus i n romnete) sau
mpreun cu Hugh Darwen (vezi The Third Manifesto). Meritoriu este i faptul c,
din capul locului, Date se autodenun ca fiind unul dintre cei care, de-a lungul
timpului, au contribuit la confuzia n care se scald atomicitatea.
Prima definiie a 1NF aparine, firete, lui E.F. Codd pentru care o relaie este n
1NF dac nici unul dintre domeniile sale nu are elemente (valori) de tip set 18.
Civa ani mai trziu, Codd afirm c un domeniu este simplu dac toate valorile
sale sunt atomice, adic nedecompozabile de ctre SGBD19. Date identific n cartea
lui Codd publicat n 199020 dou afirmaii similare:
valorile din domeniile pe care fiecare relaie este definit sunt
necesarmente atomice vis-a-vis de SGBD;
datele atomice sunt cele care nu pot fi descompuse de ctre SGBD n
subcomponente (cu excepia unor funcii speciale).
Din pcate, Codd elimin o neclaritate nlocuind-o cu alta. i Date se ntreab:
ce nsemn cu excepia unor funcii speciale ? Faptul c dintr-un ir de caractere
(exemplul clasic de valoare atomic) pot fi extrase diferite componente prin funcii
precum SUBSTR, funcii prezente n mai toate SGBD-urile actuale, face din
valoarea de tip ir de caractere una neatomic ? Sun cam hilar. Mai ales c, dac
raportm atomicitatea la SGBD-uri, deseori vom fi n situaia n care o valoare
atomic ntr-o baz de date gestionat cu un SGBD s fie neatomic n cazul unei
aceleai baze de date (structuri) implementat pe un alt SGBD. Ceea ce, s
recunoatem, nu e prea onorant pentru un model att de riguros fundamentat aa
cum este relaionalul.
Date, mpreun cu Darwen i Pascal propun renunarea la atomicitate ca o
cerin a 1NF. Dup Date, atomicitatea nici nu are o semnificaie absolut, ntruct
16 [Elmasri & Navathe 00], p. 485

17 [Date03]
18 [Codd72]. Preluare din [Date03]
19 [Codd79]
20 [Codd90]
28 Capitolul 3
depinde de ceea ce dorim s facem cu datele asupra atomicitii crora ne

pronunm21. Practic, toate tabelele care respect principiile modelului relaional
sunt n 1NF, iar aceast prim normal pstreaz din relevan doar n dou
privine:
indic faptul c relaia la care se refer poate s nu fie ntr-o form
normalizat superioar (2NF, 3NF...);
o structur de date ce respect 1NF este una relaional, cu alte cuvinte
tabelele care nu sunt n 1NF sunt non-relaionale.
Acestui din urm aspect merit o discuie detaliat, deoarece ine de aspectul
structural al modelului relaional.
Renunarea la atomicitate nu este singura schimbare fundamental n modelul
relaional. Domeniile pot conine orice tip de valori: scalare sau compozite, iruri
de caractere, numere, dar i vectori, liste, imagini, nregistrri audio/video,
documente XML sau orice tip de definit de utilizatori. Dealminteri, dac iniial
Codd s-a strduit s impun sintagma domeniu n detrimentul tipului, tocmai
pentru a opera o distrincie net dintre baze de date i limbaje de programare,
Date, Darwen i Pascal sunt, n ultimul timp, mult mai apropiai de noiunea de tip,
pe care o consider mai sugestiv i, n plus, identic aplicabil i altor modele de
organizare a datelor date. Atta vreme ct exist suport din partea SGBD-ului
pentru definirea, stocarea i accesarea sa, se poate folosi orice tip de date ntr-o BD.
Revenim la relaia BIBLIOTEC din figura 3.1. Pe baza tipului ir de caractere,
putem defini un domeniu de tip vectori de iruri de caractere, iar cele trei atribute,
Cote, Autori i CuvinteCheie se vor declara pe acest nou domeniu de tip set.
Chiar dac noua relaie, denumit BIBLIOTEC_SET (figura 3.22), seamn izbitor
cu forma denormalizat, este de o schem radical diferit.
BIBLIOTEC_SET
ISBN Titlu Cote_SET Autori_SET
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii {III-13421,III- {Marin Fotache,
aplicaiilor profesionale 13422, III-13423} Ioan Brava, Ctlin
Strmbei, Liviu Creu}
973-683-709-2 SQL. Dialecte DB2, Oracle i {III-10678, {Marin Fotache}
Visual FoxPro III-10679}
Editura LocSediuEd AnApariie CuvinteCheie_SET

Polirom Iai 2002 {baze de date, SQL, proceduri stocate, FoxPro,
formulare, orientare pe obiecte, client-server, web}
Polirom Iai 2001 {baze de date, algebr relaional, SQL}
Figura 3.22. Domenii de tip set

A doua inovaie o constituie atributele ale cror valori pot fi chiar relaii
(relation-valued attributes) - ATR. n exemplul nostru, n locul celor trei seturi putem
folosi cte o relaie. Ctigul este important, deoarece pentru ingredientul folosit
este pur relaional (relaia !), iar mecanismul de declarare a restriciilor i cel de
21 [Date03]
interogare (algebra relaional) este, n esen, acelai. Atributele Cote_REL,

Autori_REL i CuvinteCheie_REL din relaia BIBLIOTEC_ATR (figura 3.23)
sunt de acest tip, iar valorile lor pot fi supuse operatorilor clasici: selecie, proiecie,
jonciune etc. Date i Harwen propun civa noi operatori algebrici relaionali
pentru a asigura comparabilitatea tabelelor cu i fr ATR, GROUP i
UNGROUP22.
BIBLIOTEC_ ATR
ISBN Titlu Cote_REL
973-683-889-7 Visual FoxPro. Ghidul dezvoltrii aplicaiilor profesionale Cote
III-13421
III-13422
III-13423
973-683-709-2 SQL. Dialecte DB2, Oracle i Visual FoxPro Cote

III-10678
III-10679
Autori_REL Editura LocSediuEd AnApariie CuvinteCheie_REL

Autori Polirom Iai 2002 CuvinteCheie
Marin Fotache baze de date
Ioan Brava SQL
Ctlin Strmbei proceduri stocate
Liviu Creu FoxPro
formulare
orientare pe obiecte
client-server
web
Autori Polirom Iai 2001 CuvinteCheie
Marin Fotache baze de date
algebr relaional
Stocate
Figura 3.23. Atribute de tip relaii (ATR)

Din contr, dac am folosi prima variant - cea a seturilor - ar fi necesari
operatori speciali: reuniune de seturi, intersecie de seturi etc.
Aceast a doua inovaie a modelului relaional este o consecin direct a
primeia. Practic, dac un atribut X este de tip relaie, iar D este domeniul lui X,
atunci toate valorile lui D sunt relaii. n plus, orice atribut de tip relaie poate
conine atribute care sunt, la rndul lor, de tip relaii, astfel nct numrul
nivelurilor de imbricare este nelimitat.
22 Vezi [Date & Darwen00]

30 Capitolul 3
Interesant este n acest sens i lucrarea publicat n 1984 de ctre Serge

Abiteboul i Nicole Bidoit. Dei autorii afirmau c propun un model de date nou (l-
au botezat Verso), n mare ideea era ca valoarea unui atribut s fie nu numai
atomic, ci i o instan a unui format (autorii au ezitat s foloseasc termenul
relaie). Ceea ce este notabil la modelul propus este c prin acest mecanism era
obinut o ierarhie ce putea fi interogat folosind aceeai operatori algebrici
relaionali. Cu att mai mult cu ct valorile nule aveau o form de reprezentare
care ar mulumi astzi pe Date i compania (relaii vide) 23.
Howard Dreizen i Shi-Huo Chang propun n numrul din decembrie 1989 al
ACM Transactions on Database Systems acceptarea, cu titlu restrictiv, a unor condiii
excepionale n schema bazei de date, pentru a rezolva o serie de situaii practice
relativ rare care ns creaz anomalii n schema bazei. Cu acest prilej, autorii se
pronun pentru folosirea relaiilor incluse, altfel spus, includerea relaiilor n alte
relaii, de o manier nerestrictiv; astfel, o relaie R (D1, D2, ..., Dn) de n domenii
este recursiv omogen dac fiecare domeniu este fie (1) un set de valori atomice fie
(2) un set de relaii recursive omogen cu scheme identice24.
Odat trecut euforia contactului cu atributele de tip relaii, ne putem ntreba

retoric, precum Date: n proiectarea schemei bazei chiar avem nevoie de ATR-uri ?
ntrebarea corect ar fi, mai degrab: cnd ATR-urile sunt mai avantajoase, prin
comparaie cu cele atomice (i mecanismul de normalizare expus n acest capitol) ?
Principalul avantaj ine, dup cum am discutat, de enorma lor flexibilitate. Dintre
limite sau, dup caz, dezavantaje, ar merita nceput cu structura ierarhic a ATR,
ca i n lumea orientrii pe obiecte, n general. Nu ntotdeauna realitatea este
ierarhic. Relaiile dintre obiecte pot fi cu mult mai complexe, iar de cele mai multe
ori sunt necesare regrupri, resistematizri ale datelor, situaii n care stngciile
structurilor ierarhice se manifest n toat splendoarea lor.
S lum discuie relaia STUDENI_EXAMENE din figura 2.3 pentru care
ncercm s valorificm ATR-urile. Prima variant - vezi figura 3.24 - folosete un
atribut de tip relaie numite Examene_ATR ce conine informaii despre fiecare
toate examenele susinute de un student. Relaia STUDENI_EXAMENE_ATR1 va
conine doar cte un tuplu pentru fiecare student.
STUDENI_EXAMENE_ATR1
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
23 Vezi [Abiteboul & Bidoit 84]

24 [Dreizen & Chang 89]
EL13458 pag M Michael 3 Informatic economic
Examene_ATR
CodDisc DenumireDisc NrCredite DataExamen Nota
AI3501 Baze de date I 6 29/01/2004 8
AI3502 Programare vizual i RAD 7 01/02/2004 10
AI3501 Baze de date I 6 29/01/2004 4
AI3501 Baze de date I 6 12/02/2004 8
AI3501 Baze de date I 6 29/01/2004 9
AI3503 Analiza sistemelor informaionale 6 04/02/2004 7
Figura 3.24. Prima variant de folosire a ATR

n egal msur se poate ns folosi i un ATR care s conin toi examinaii
pentru o disciplin dat ntr-o sesiune - StudeniNote_ATR. Relaia s-ar prezenta
dup cum este sugerat n figura 3.25.
STUDENI_EXAMENE_ATR2
CodDisc DenumireDisc NrCredite DataExamen
AI3501 Baze de date I 6 29/01/2004
AI3501 Baze de date I 6 12/02/2004
AI3502 Programare vizual i RAD 7 01/02/2004
AI3502 Programare vizual i RAD 7 15/02/2004
AI3503 Analiza sistemelor informaionale 6 04/02/2004
StudeniNote_ATR
Matricol NumePrenume An Specializare Nota
EL13455 Popovici I Vasile 3 Informatic economic 8
EL13456 Zineanu W Ion 3 Informatic economic 4
EL13457 Ablaei R Zicu 3 Informatic economic 9
32 Capitolul 3

EL13455 Popovici I Vasile 3 Informatic economic 10
EL13458 pag M Michael 3 Informatic economic 7
Figura 3.25. A doua variant de folosire a ATR

Care dintre cele dou variante reflect mai bine realitatea ? Prima variant
prezint avantajul gruprii tuturor examenelor unui student sub "umbrela"
tuplului care se refer la studentul respectiv. Ar fi relativ simplu de calculat media
studentului, de aflat la ce examene a picat o singur dat, sau de dou (trei...) ori
etc. Dar dac ne intereseaz studenii care au luat la Programare orientat pe obiecte
aceai not ca i pag Michael, atunci interogarea s-ar complica destul. A doua
variant este, ca structur, mai aproape de realitate, deoarece notele sunt preluate
de pe cataloage care se ntocmesc la fiecare examen. Avantajul obinerii lejere a
catalogului de la examen este "compensat" de dificultatea calculrii mediilor pentru
un student sau formaie de studiu, pentru comparaii ntre situaiile colare ale
studenilor etc.
Din acest punct de vedere, renunarea la ATR i lucrul cu atribute atomice se
materializeaz ntr-o structur, s-i spunem, mai neutr, care, dei nu att de
intuitiv precum cea ierarhic, se preteaz mult mai bine la prelucrri dintre cele
mai diverse.
Dup discuia din acest paragraf, n care domeniile pot fi definite ct se poate
de flexibil, n funcie de nevoile aplicaiei, ne putem pune ntrebarea: ce rost mai
are s discutm despre aducerea relaii n 1NF, operaiune care, uneori, presupune
creterea numrului de tupluri de cteva ori, astfel nct n loc s micorm
redundana, mai degrab o mrim, cel puin aparent ?
Dou ar fi argumentele n sprijinul celor prezentate n acest capitol pn n
paragraful n care ne aflm (oricum este ultimul !). Mai nti, n procesul
normalizrii, acesta e doar primul pas. Redundana pe care o introducem rezolv o
problem extrem de important, cea a pierderilor de informaii. Dup cum o s
vedem n capitolele urmtoare, este aproape sigur c n celelalte forme normalizate
vom scpa de aproape tot ce este redundant ntr-o relaie.
Al doilea argument ine de instrumentele software de care dispunem. La acest
moment suportul SGBD-urilor pentru domenii de tip set, ca s nu mai vorbim de
atribute de tip relaie, este mai degrab unul modest. Chiar dac produsele
importante au faciliti importante n definirea de obiecte, cnd se pune problema
mecanismului de declarare a integritii obiectelor, i mai ales a celui de interogare,
lucrurile se acutizeaz. Chiar dac teoretic opiunile sunt generoase, atunci cnd se
pune problema punerii n oper a unei aplicaii de lucru cu baze de date nu putem
eluda "meandrele concretului", cu att mai puin "sinergia faptelor".

Prima Forma Normala

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Prima Forma Normala

Încărcat de

Drepturi de autor:

Formate disponibile

Capitolul 3.

Prima form normalizat

3.1. Definiii ale primei forme normalizate

5 [Connoly & Begg 02], p.388

3.2. Atribute simple i atribute compuse

- numele actorului, dac categoria este pentru interpretare.

Concluzionnd n termeni rabinici, ambele variante, descompunerea sau

3.3. Despre grupuri repetitive i urmrile lor

Editura LocSediuEd AnApariie CuvinteCheie

Figura 3.1. Relaia universal nenormalizat BIBLIOTEC

3.3.1. Grupuri repetitive pe orizontal

Una dintre cele mai nerecomandate soluii pentru eliminarea grupurilor

Autor1 Autor2 Autor3 Autor4 Editura LocSediuEd

AnApariie CuvntCheie1 CuvntCheie2 CuvntCheie3 CuvntCheie4

2001 baze de date algebr relaional SQL NULL

CuvntCheie5 CuvntCheie6 CuvntCheie7 CuvntCheie8

formulare orientare pe obiecte client-server web

NULL NULL NULL NULL

Figura 3.2. O soluie (destul de penibil) de eliminare a grupurilor repetitive

Figura 3.3. Un exemplu rezonabil de atribut pseudo-repetitiv

Figura 3.4. O alt prim form normal a relaiei PERSOANE_1

3.3.2. Eliminarea grupurilor repetitive prin adugarea de

A doua variant pstreaz structura relaiei (universale sau nu), n sensul c nu

Numr minim de linii - o singur valoare atomic pentru fiecare atribut

Editura LocSediuEd AnApariie CuvntCheie

Polirom Iai 2002 SQL

Polirom Iai 2002 proceduri stocate

Polirom Iai 2002 FoxPro

Polirom Iai 2002 formulare

Polirom Iai 2002 orientare pe obiecte

Polirom Iai 2002 client-server

Polirom Iai 2002 web

Polirom Iai 2001 baze de date

Polirom Iai 2001 algebr relaional

Figura 3.5. Completarea cu tupluri - soluia 1

Necazul e c tergerea liniei se face cu dou pierderi de informaii. Prima

Nici aceast idee nu e din cale-afar de inteligent. Dac am dori eliminarea

973-683-709-2 SQL. Dialecte DB2, Oracle i Visual FoxPro NULL NULL

Editura LocSediuEd AnApariie CuvntCheie

Polirom Iai 2002 NULL

Polirom Iai 2002 NULL

Polirom Iai 2002 NULL

Polirom Iai 2002 NULL

Polirom Iai 2002 NULL

Polirom Iai 2002 NULL

Polirom Iai 2002 baze de date

Polirom Iai 2002 SQL

Polirom Iai 2002 proceduri stocate

Polirom Iai 2002 FoxPro

Polirom Iai 2002 formulare

Polirom Iai 2002 orientare pe obiecte

Polirom Iai 2002 client-server

Polirom Iai 2002 web

Polirom Iai 2001 NULL

Figura 3.6. Completarea cu tupluri - soluia 2

Numr maxim de linii, egal cu produsul valorilor elementare ale atributelor

cuvinte cheie, n relaia BIBLIOTEC_TUPLURI_NOI_SOLUTIA_3 vor exista 3 * 4

Editura LocSediuEd AnApariie CuvntCheie

Polirom Iai 2002 baze de date

Polirom Iai 2002 baze de date

Polirom Iai 2002 baze de date

Polirom Iai 2002 SQL

Polirom Iai 2002 SQL

Polirom Iai 2002 SQL