Proiectarea Bazelor de Date

şi limbajul SQL

1
 CUPRINS

INTRODUCERE..................................................................................................................................3
CAPITOLUL 1. MODELE DE DESCRIERE A DATELOR...................................................................5
1.1. MODELARE E-R (ENTITY-RELATIONSHIP)......................................................................................5
1.2. REPREZENTARE GRAFICĂ - DIAGRAME E-R.................................................................................... 8
1.3. RESTRICTII STRUCTURALE.........................................................................................................11
1.4. CHEI.................................................................................................................................... 14
CAPITOLUL 2. ALGEBRA RELAŢIONALĂ...................................................................................16
2.1 STRUCTURA RELAŢIONALA A DATELOR.........................................................................................16
2.2. ALGEBRA RELAŢIONALĂ...........................................................................................................19
CAPITOLUL 3. NORMALIZAREA DATELOR...............................................................................25
3.2. DEPENDENŢE FUNCŢIONALE..................................................................................................... 29
3.3. FORME NORMALE.................................................................................................................. 33
CONCLUZII...................................................................................................................................38
CAPITOLUL 4. PROIECTAREA A BAZELOR DE DATE RELAŢIONALE...........................................40
4.1. METODOLOGIA PROIECTĂRII BAZELOR DE DATE............................................................................40
4.2. PREZENTAREA METODOLOGIEI..................................................................................................41
4.3. CREAREA MODELULUI LOGIC.....................................................................................................43
4.4. PROIECTAREA LOGICĂ A BAZEI DE DATE - EXEMPLU.......................................................................51
CAPITOLUL 5. SECURITATE ŞI INTEGRITATE............................................................................65
5.1. INTEGRITATE......................................................................................................................... 65
5.2. SECURITATE.......................................................................................................................... 68
CAPITOL 6. LIMBAJUL SQL......................................................................................................72
6.1. TIPURILE DE DATE SQL........................................................................................................... 73
6.2. INSTRUCŢIUNI PENTRU DEFINIREA DATELOR.................................................................................74
6.3. INSTRUCŢIUNI PENTRU MANIPULAREA DATELOR...........................................................................74
6.4. INSTRUCŢIUNE SELECT...........................................................................................................76
6.5. ORDONAREA TUPLELOR (CLAUZA ORDER BY)............................................................................80
6.6. GRUPAREA REZULTATELOR (CLAUZA GROUP BY)........................................................................82
6.7. INTEROGARI PE MAI MULTE TABELE...........................................................................................84
6.8. SUBINTEROGARI.....................................................................................................................86
6.9. OPERATORII ANY ŞI ALL.........................................................................................................90
6.10. OPERATORUL EXISTS...........................................................................................................93
BIBLIOGRAFIE........................................................................................................................94

2
3
INTRODUCERE

În primii ani, calculatoarele erau utilizate mai ales pentru a duce la bun
sfârşit calcule laborioase în care nu erau implicate cantităţi prea mari de date, aşa-
numitele calcule ştiinţifice. Odată cu apariţia limbajelor de nivel înalt şi a
posibilităţii stocării de mari cantităţi de informaţie pe suport magnetic adresabil
(memorie externa) s-a pus şi problema eficientizării prelucrării acestora. De data
aceasta nu calculele creşteau costul în timp al prelucrărilor ci manipularea datelor,
respectiv regăsirea, actualizarea, etc. S-a constatat ca un factor important al
creşterii eficienţei prelucrărilor este modul de organizare al informaţiilor. De aici şi
până la a gândi sisteme unitare de reprezentare şi manipulare a masivelor de date
n-a mai fost decât un pas.
Prima variantă de prelucrare a cantităţilor mari de informaţie s-a bazat pe
organizarea datelor sub forma înregistrărilor în fişiere tradiţionale pe suport
adresabil. În această variantă se elaborau programe de aplicaţie care defineau şi
manipulau propriile date şi aveau în general ca scop elaborarea de rapoarte pentru
diverşi beneficiari. Aceste programe au avut menirea de a înlocui prelucrarea
sistemelor de fişiere manuale care mai funcţionează şi astăzi în unele locuri cum ar
fi cabinetele medicale. Aşadar prelucrările oferite de un sistem tradiţional bazat pe
fişiere copiau în mare masură metodele manuale de prelucrare. Evident că puterea
de calcul şi memorare caracteristică sitemelor de calcul au făcut ca gama
prelucrărilor să crească simţitor, la aceasta adăugându-se viteza şi siguranţa
prelucrărilor.
Cu toate ca la momentul respectiv abordarea tradiţională bazată pe fişiere a
fost un evident progres, putem să amintim aici şi o serie de limitări ale acestui
sistem de prelucrare a datelor:
 Separarea şi izolarea datelor
 Duplicarea datelor
 Dependenţa datelor
4
  Incompatibilitatea fişierelor
 Interogări fixe / proliferarea aplicaţiilor.
Evoluţia metodelor şi tehnicilor de organizare a datelor a fost determinată de
necesitatea de a avea un acces cât mai rapid şi mai uşor la un volum din ce în ce
mai mare de informaţii precum şi de perfecţionarea echipamentelor de culegere,
memorare, transmitere şi prelucrare a datelor.
Conceptul de bază de date s-a definit în 1969 cu ocazia prezentării primului
proiect de raport CODASYL (Raportul final s-a prezentat în 1971). Ideea
principală în organizarea datelor se baza pe existenţa a trei componente de bază:
 schema de reţea - care reprezenta organizarea logica a întregii baze de
date;
 subschema - care reprezenta o parte a bazei de date aşa cum e vazută
de utilizator sau de programele de aplicaţie;
 un limbaj de gestionare a datelor - care definea caracteristicile datelor,
structura lor şi care manipula datele.
Pentru standardizare, s-au propus trei limbaje:
 un limbaj de definire a datelor (LDD) la nivel de schemă;
 un limbaj ător la nivel de subschemă;
 un limbaj de manipulare a datelor (LMD).

5
Capitolul 1. Modele de descriere a datelor
Generalitati
Un model de date cuprinde trei parti:
1. o parte referitoare la structura, care consta intr-un set de reguli ce impun
modul de alcatuire a bazei de date;
2. o parte referitoare la manipularea datelor, care defineste tipul de operatii
care sunt permise asupra datelor. Sunt incluse aici operatiile care sunt utilizate
pentru a actualiza sau a regasi datele in baza de date precum şi operatiile pentru
schimbarea structurii bazei de date;
3. o parte referitoare la integritatea datelor, parte care cuprinde reguli de
integritate care asigura acuratetea datelor.
Modele de date se pot realiza pentru fiecare nivel de abstractizare. Astfel
putem vorbi de:
 model extern de date (care reprezinta asa-numitul univers al
discursului, adica punctul de vedere al utilizatorului);
 model de date conceptual (care reprezinta structura logica a bazei de
date, independenta de sistemul de gestiune ales);
 model de date intern (care reprezinta schema conceptuala intr-un mod
in care poate fi perceputa de SGBD).
Modele de date bazate pe obiecte utilizeaza concepte: entităţi, atribute,
relaţii.

1.1. Modelare E-R (Entity-Relationship)

Modelul E-R (Entity-Relationship) este un model conceptual de nivel înalt,
dezvoltat de Chen în 1976. Primele idei legate de utilizarea modelului E-R la
proiectarea unei baze de date au fost expuse de Chen (1977) şi au fost continuate
de Sakai (1980). Conceptele de specializare şi generalizare au fost introduse de
Smith (1977) şi au fost utilizate ulterior de Lenzerini şi Santucci (1983) la
definirea restrictiilor de cardinalitate. Modelul E-R constituie un mod de

6
reprezentare a bazelor de date relaţionale şi de aceea este un instrument util in
proiectarea acestora.
Concepte de baza
Conceptele primare ale modelului E-R includ : tip de entitate (multime-
entitate), tip de relaţie (multime-relatie), atribute.
Numim entitate un obiect sau un concept ce se poate identifica in mod unic.
Notiunea de entitate este un concept de baza in cadrul modelului E-R. Ea
reprezinta 'obiecte' concrete (cu existenta fizica) sau abstracte (cu existenta
conceptuala).
Exemplu: Popescu Ion, posesor al buletinului de identitate seria ABC,
numarul: 444555 este o entitate deoarece identifica in mod unic o persoana in acest
univers. O entitate care reprezinta un obiect ceva mai abstract poate fi, de exemplu,
un cont la banca identificabil in mod unic prin numarul sau şi numele bancii.
Numim tip de entitate sau multime-entitate un set de entitati de acelasi tip.
Exemplu: Multimea tuturor persoanelor care sunt studenti ai Facultatii de
Stiinte pot defini multimea-entitate sau tipul de entitate student.
Tipul de entitate reprezintă o multime de 'obiecte' ce apartin lumii reale şi
care sunt descrise de aceleasi proprietati.
Orice obiect care apartine unui tip de entitate şi care este identificabil in mod
unic este numit simplu entitate. (se mai intalnesc denumirile: aparitia unei entitati
sau instanta unei entitati). Un tip de entitate conţine mai multe entităţi. O baza de
date este o colectie de tipuri de entitate din care fiecare contine un numar
neprecizat de entitati de acelasi tip.
Tipurile de entitate nu sunt neaparat disjuncte. Aceasta inseamna ca pot
exista entitati care sa apartina mai multor tipuri de entitate.
Exemplu: Se pot defini urmatoarele tipuri de entitate: profesor,
corespunzator tuturor cadrelor didactice ale Facultatii de Stiinte şi student,
corespunzator tuturor studentilor aceleiasi facultati. Se observa usor ca pot exista
studenti care sunt in acelasi timp şi cadre didactice (studenti la master care sunt
preparatori sau asistenti).
7
 Un tip de entitate se identifică printr-un nume şi o listă de proprietati. O bază
de date conţine în general mai multe tipuri de entităţi. Fiecare tip de entitate are
propriul set de proprietati.
Numim atribute proprietaţile atasate unui tip de entitate.
Exemplu: entitatea student poate fi descrisa de atributele: nume_student,
prenume_student, data_nasterii, sex, adresa, telefon, numar_matricol, grupa.
Prin domeniul atributului intelegem multimea valorilor care pot fi atribuite
unui atribut simplu.
Atributele unei entitati contin valorile care descriu fiecare entitate şi cu
ajutorul carora fiecare entitate se poate identifica in mod unic. Aceste valori
reprezinta cea mai mare parte a datelor memorate intr-o baza de date.
Domeniul unui atribut nu se poate defini intotdeauna foarte exact. De
exemplu, atributul nume_student trebuie să fie un şir de caractere dar poate lua ca
valori doar un nume de familie existent. Unele domenii se pot descompune în mai
multe subdomenii. De exemplu data_naşterii se poate descompune in
subdomeniile: an, lună, zi.
In general putem considera ca fiecare entitate este reprezentabila cu ajutorul
unei multimi de perechi de forma (nume_atribut, valoare_atribut), cate o pereche
pentru fiecare atribut atasat tipului de entitate corespunzator.
Exemplu: o entitate a tipului de entitate student poate fi reprezentata de
multimea: {(nume_student, Popescu), (prenume_student, Ion), (data_nasterii,
15.11.1991), (sex, masculin), (adresa, B-dul Moscova, 12, Chisinau, cod 2068),
(telefon, (022)444555), (numar_matricol, 31455), (grupa, 7211)}
Atributele se pot clasifica în simple sau compuse; cu o singură valoare sau
cu mai multe valori; respectiv derivate.
Numim atribut simplu orice atribut care are doar o singură componentă şi o
existenţă independentă.
Aceste atribute nu se pot diviza în mai multe atribute distincte. Ele se mai
numesc şi atribute atomice.
Exemplu: atributul sex corespunzator tipului de entitate student.
8
 Numim atribut compus orice atribut care are mai multe componente,
fiecare cu o existenţă independentă.
Aceste atribute se pot diviza în general in mai multe atribute simple.
Exemplu: atributul adresă se poate descompune în atributele: strada, număr,
oraş, cod_poştal. Decizia ca un atribut compus să se descompună în mai multe
atribute simple este dependentă de modul în care se va utiliza acel atribut: pe
componente, sau ca un întreg.
Numim atribut cu o singură valoare orice atribut care poate lua cate o
singură valoare pentru fiecare entitate.
Majoritatea atributelor sunt atribute cu o singură valoare.
Numim atribut cu mai multe valori orice atribut care poate lua mai multe
valori pentru fiecare entitate.
Pentru atributele cu mai multe valori trebuie precizate numarul minim şi
numarul maxim de valori pe care le poate lua atributul respectiv.
Exemplu: atributul telefon poate fi un atribut cu mai multe valori. In acest
caz se poate limita de exemplu numarul numerelor de telefon la care poate fi gasit
studentul la minim 0 şi la maxim 3. Deci se pot stabili numarul minim şi numarul
maxim de valori pe care le poate lua atributul.
Numim atribut derivat orice atribut a cărui valoare se poate calcula din
unul sau mai multe alte atribute. Aceste atribute nu trebuie neaparat sa descrie
entitatea careia ii corespunde atributul derivat.
Exemple: valoarea pentru atributul vârsta este derivată din valoarea
atributului data_naşterii şi din data curenta. Valoarea atributului
numărul_total_de_entităţi se poate calcula numărând entităţile înregistrate.

1.2. Reprezentare grafică - diagrame E-R

Intreaga structura logica a unei baze de date poate fi reprezentata grafic cu
ajutorul diagramelor E-R. O astfel de diagrama contine elemente grafice cum ar fi:
 dreptunghiuri, care reprezinta tipuri de entitate;
 elipse, care reprezinta atribute;

9
  linii, care au rolul de a evidentia legaturile intre elementele
diagramei.
Dreptunghiurile şi elipsele sunt etichetate cu numele 'obiectului' reprezentat.
Acestea nu sunt singurele elemente grafice utilizate intr-o diagrama E-R. Pe
masura ce vom defini noi concepte vom reveni cu precizari legate de modul de a le
reprezenta.
Un atribut se reprezintă printr-o elipsă, legată de entitatea careia îi este
asociat cu o linie şi etichetată cu numele atributului. Elipsa este trasata cu linie
punctată, dacă atributul este un atribut derivat şi respectiv cu linie dublă, daca
atributul poate lua mai multe valori.
Dacă un atribut este compus, atunci componentele atributului se reprezintă
prin elipse legate cu cate o linie de atributul compus.

numãr
num
e bloc
locatari adresa

numãr adresa
scara
matricol apartamen etaj
t adresa

adresa

Reprezentarea cu diagrama E-R a entitatii

adresalocatari

adresa
De exemplu, entitatea locatari are următoarele atribute: număr_matricol,
nume şi adresa. Dintre aceste atribute, atributul adresa este atribut compus, care se
descompune în număr_bloc, scara, etaj şi apartament. Atributul număr_matricol
este o cheie.
Numim tip de relaţie orice asociere între tipuri de entităţi.
Numim relaţie orice asociere între entităti, când asocierea include cate o
entitate pentru toate tipurile de entitate participante.
Fie E1, E2, ..., En tipuri de entitate. Formal, un tip de relatie este o
submultime a urmatoarei multimi:
10
 {( e1, e2, ..., en) | unde e1E1, e2E2, ..., enEn }
ceea ce inseamna ca ( e1, e2, ..., en) reprezinta formal o relatie.
Exemplu: Intr-o aplicaţie care ar servi unor evidente in cadrul asociatiilor de
locatari putem considera tipul de entitate locatari descris de atributele: nume,
adresa şi numar_matricol şi tipul de entitate scari descris de atributele
numar_de_bloc şi scara. Intre tipul de entitate scari şi tipul de entitate locatari se
poate stabili un tip de relatie numit este_locuita_de. Acest tip de relatie va contine
relatii de tipul ('Scara A', 'Popescu Ion') care va fi interpretata: "Scara A este
locuita de Popescu Ion".
Numim gradul relaţiei numărul entităţilor participante în relaţie. Asadar
relatia reprezentata mai sus are gradul n. Entităţiile implicate intr-o relaţie se
numesc participanţi. Dacă intr-o relaţie sunt doi participanţi, atunci relaţia se
numeşte binară.
Tipurile de relatii se reprezinta in diagramele E-R cu ajutorul romburilor
care sunt etichetate cu numele tipului de relatie.
nume

numar
scara numar
de adresa
matricol
bloc
scari este locu- locatari
1 ita de M

Reprezentarea cu diagrama E-R a relatiei este_locuita_de

Functia pe care o joaca o entitate intr-o relatie se numeste rolul entitatii. In

general nu este necesar sa se specifice rolul entitatilor intr-o relatie, deoarece
acesta este in general implicit.
Numim relaţie recursivă orice relaţie în care aceleaşi entităţi participă în
roluri diferite. In acest caz este necesar sa se precizeze rolurile entitatilor implicate.
În cazul relaţiilor recursive, in diagrama E-R corespunzatoare, cele două arce de la

11
entitate la relaţie şi înapoi, primesc diferite etichete, care sunt importante în
înţelegerea corectă a relaţiei.
Exemplu: Daca am considera entitatile lucratori şi manageri care se refera la
personalul aceleiasi intreprinderi, am face constatarea ca sunt descrise de aceleasi
atribute deci apartin aceluiasi tip de entitate şi anume angajati. Relatia binara
lucreaza_pentru, stabilita intre lucratori şi manageri este o relatie recursiva.
Rolurile jucate de fiecare entitate se pot stabili recurgandu-se la perechi ordonate
(muncitor, manager). Astfel relatia ('Popescu Ion', 'Ionescu Gheorghe') se
interpreteaza "Popescu Ion lucreaza pentru (este subordonatul lui) Ionescu
Gheorghe".
lucrator
angajati lucreaza

manager pentru

Reprezentarea cu diagrama E-R a relatiei recursive lucreaza_pentru

Unui tip de relatie i se pot asocia atribute descriptive in acelasi mod in care
se pot asocia atribute unui tip de entitate.
Exemplu: Tipului de relatie este_locuita_de, care implica tipurile de entitate
scari şi locatari, i se poate asocia atributul data care sa retina data la care locatarul
L s-a mutat pe scara S. Dupa cum se observa, acest atribut descrie exclusiv tipul de
relatie şi el nu mai are sens in afara ei.

1.3. Restrictii structurale

Este posibil sa se stabileasca diverse restrictii la care continutul unei baze de
date trebuie sa se conformeze. Vom trata in continuare restricţiile care se pot
impune entitatilor participante intr-o relatie. Aceste restrictii trebuie sa reflecte
caracteristicile relatiilor asa cum se percep in 'lumea reala'. Doua tipuri importante
de restrictii sunt de mentionat aici: restrictii de cardinalitate şi restrictii de
participare.

12
 a) Restrictii de cardinalitate Numim cardinalitate (polaritate) numărul
relaţiilor posibile pentru o entitate participantă. Altfel spus, cardinalitatea exprima
numarul entitatilor la care o alta entitate poate fi asociata prin intermediul unei
relatii.
Observatie: Am utilizat in definitia de mai sus referiri la entitati şi la relatii
pentru a fi mai expliciti. Restrictiile structurale se refera insa in mod evident la
tipurile de relatie şi la tipurile de entitate asociate. Aceasta observatie ramane
valabila şi in consideratiile ce urmeaza.
Majoritatea tipurilor de relatie au gradul doi. Cardinalitatea in acest caz
poate fi de tipurile: unu-la-unu (1:1), unu-la-mai-multe (1:M), sau mai-multe-la-
mai-multe (M:N).
Relaţiile unu-la-unu:
În relaţiile unu-la-unu, o entitate, apartinand unui tip de entitate, este legată
de cel mult o entitate din celalalt tip de entitate implicat in relatia respectiva.
Implicarea fiecarei entitati intr-o relatie data este numita "participarea entitatii".
In diagrama E-R se eticheteaza arcul dintre relaţie şi fiecare tip de entitate cu
cardinalul relaţiei; in cazul relatiilor unu-la-unu fiecare din cele doua arce se
eticheteaza cu 1.
Relaţiile unu-la-mai-multe:
In relaţia de tip unu-la-mai-multe orice entitate, apartinand primului tip de
entitate, este legată de 0, 1, sau mai multe entităţi apartinand celui de-al doilea tip
de entitate participant la relatie. Exemplificăm acest tip de relaţie prin relaţia
este_locuita_de dintre tipurile de entităţi scari, respectiv locatari. In reprezentarea
grafică a acestui tip de relatie, arcul dinspre tipul de entitate scari se eticheteaza cu
1 iar arcul dinspre tipul de entitate locatari se eticheteaza cu M.
Din exemplul de mai sus se observă usor că dacă relaţia directă este de unu-
la-mai-multe, atunci relatia inversă este de unu-la-unu.
Relaţiile mai-multe-la-mai-multe:
Acest tip de relaţie se deosebeşte de relaţia unu-la-mai-multe prin faptul că
relaţia inversă nu este de unu-la-unu, ci de unu-la-mai-multe. Deci, dacă şi relaţia
13
directă şi relaţia inversă sunt de tipul unu-la-mai-multe, atunci relaţia directa este
de tipul mai-multe-la-mai-multe şi se notează cu (N:M).

atribute atribute
scari este locuita de locatari
nr_mat
nr_bloc R1
Sc.A Fam.1 numele
scara

R2 Fam.2
Sc.B nr_mat
nr_bloc
Fam.3 numele
scara R3
Sc.C
Reprezentarea cu retele semantice a relaţiei 1:M este_locuita_de
nr_mat
nr_bloc
b) Restrictii de participare numele
scara
Numim restrictii de participare acele restrictii prin care se determină dacă
existenţa unui tip de entitate depinde de faptul ca este legat sau nu de un alt tip de
entitate prin intermediul relatiei in discutie.
Participarea unei entitati poate fi totală sau parţială. Participarea este totala
daca existenta entitatii respective necesita existenta unei entitati asociate în relaţia
dată. În caz contrar participarea se numeşte parţială. Termenii participare totala şi
participare partiala pot fi inlocuiti cu participare obligatorie respectiv participare
optionala. În diagrama E-R aceste tipuri de relaţii se reprezintă prin arc cu linie
dublă pentru participarea totală, respectiv cu linie simplă pentru participarea
parţială. Pentru participarea parţială, există un mod de notaţie prin care se
etichetează arcele relaţiei cu perechea de numere ce reprezintă minimul, respectiv
maximul entităţilor participante la relaţie.
Exemplu: Daca se considera filialele unei firme oarecare ca entitati in tipul
de entitate filiala şi daca se considera tipul de entitate personal (unde entitatile
reprezinta personalul firmei respective) se poate defini tipul de relatie are_alocat
stabilit intre o filiala concreta şi personalul firmei. In acest caz, daca se considera
ca fiecare filiala are alocat personal al firmei atunci participarea tipului de entitate
filiala in relatia are_alocat este totala. Daca insa admitem ca unii membri ai
14
personalului (de exemplu vanzatorii) nu lucreaza in birourile nici unei filiale,
atunci participarea tipului de entitate personal in relatia are_alocat este partiala.
c) Dependenţele de existenţă
Numim tip slab de entitate un tip de entitate, a cărui existenţă este
dependentă de existenta unui alt tip de entitate.
Numim tip tare de entitate un tip de entitate, a cărui existenţă nu depinde
de existenta nici unui alt tip de entitate.
Entităţile slabe se mai numesc existential dependente sau subordonate iar
entitatile tari se mai numesc părinte sau dominante.
In diagrama E-R tipurile de entitate tari se reprezinta cu un dreptunghi trasat
cu linie simpla. Pentru tipurile de entitate slabe conturul dreptunghiului este trasat
cu linie dubla. De asemenea aceasta notatie se extinde şi la relatii. Astfel: o relatie
care leaga doua tipuri de entitate tari este reprezentata cu un romb trasat cu linie
simpla iar relatia care leaga un tip de entitate tare de un tip de entitate slab este
reprezentata cu un romb trasat cu linie dubla.

1.4. Chei
Conceptual este evident ca entitatile şi relatiile individuale care participa la
modelarea unei baze de date sunt distincte intre ele. Diferenta intre entitati sau
diferenta intre relatii se exprima cu ajutorul atributelor care le descriu.
Numim supercheie asociata unui tip de entitate, orice submultime a
multimii de atribute ce descriu tipul de entitate, submultime care poate duce la
identificarea in mod unic a oricarei entitati in cadrul tipului de entitate luat in
considerare.
Este evident ca, daca o submultime de atribute formeaza o supercheie, atunci
orice multime de atribute care include supercheia este tot o supercheie.
Numim cheie candidat orice supercheie care contine un numar minim de
atribute. Pentru o cheie candidat nici o submultime proprie nu mai este supercheie.
Putem spune ca o cheie candidat este caracterizata de urmatoarele proprietati:

15
 - unicitatea, deoarece valoarea cheii este unica pentru fiecare entitate in
parte;
- ireductibilitatea, deoarece nici o submultime proprie de atribute ale cheii
nu are proprietatea de unicitate.
Observatie: Faptul ca valorile unei chei candidat sunt unice pentru fiecare
entitate nu poate fi determinat decat cu ajutorul informatiilor semantice referitoare
la valorile atributelor ce formeaza cheia. Trebuie sa se cunoasca semnificatiile din
lumea reala a atributelor ce formeaza cheia pentru a se stabili daca acestea vor avea
valori unice. Doar faptul ca, pentru o multime oarecare de entitati concrete, valorile
difera intre ele nu este de ajuns.
Pentru un tip de entitate este posibil sa se poata determina una sau mai multe
chei candidat.
Dintre acestea, cheia primară este cheia aleasa ca mijloc principal de
identificare a entitatilor in cadrul tipului de entitate respectiv.
Cheia primară este in general cea mai scurtă dintre cheile candidat.
In diagrama E-R atributele care intră în componenţa cheii primare, se
evidentiază prin sublinierea numelui atributului.
Numim cheie compusă orice cheie candidat care contine cel putin două
atribute.
Probleme se ivesc atunci cand trebuie sa identificam in mod unic entitatile
unui tip de entitate slab. Sa observam ca un tip de entitate tare are intotdeauna o
cheie primara, deci are intotdeauna cel putin o cheie candidat. Un tip de entitate
slab nu are cheie primara.
Numim discriminatorul unui tip de entitate slab, un set de atribute care
permite realizarea unei distinctii intre entitatile care depind de o anume entitate
tare. Asadar, cheia primara a unui tip de entitate slab este formata din cheia
primara a tipului de entitate tare de care este dependenta existential, la care se
adauga multimea atributelor care compun discriminatorul tipului de entitate slab.

16
Capitolul 2. Algebra relaţională
In cadrul bazelor de date relaţionale, datele sunt organizate sub forma unor
tablouri bidimensionale (tabele) de date, numite relaţii. Asocierile dintre relaţii se
reprezintă explicit prin atribute de legătură. Aceste atribute figurează într-una din
relaţiile implicate in asociere (de regulă, în cazul legaturilor de tip "unu la mulţi")
sau sunt plasate într-o relaţie distinctă, construită special pentru exprimarea
legaturilor între relaţii (în cazul legaturilor de tip "mulţi la mulţi"). O bază de date
relaţională (BDR) reprezintă un ansamblu de relaţii, prin care se reprezintă atât
datele cât şi legăturile dintre date.
Operatorii modelului relaţional. Definesc operaţiile care se pot efectua
asupra relaţiilor, in scopul realizarii funcţiilor de prelucrare asupra bazei de date,
respectiv consultarea, inserarea, modificarea şi ştergerea datelor.
Restricţiile de integritate ale modelului relaţional. Permit definirea
stărilor coerente ale bazei de date.

2.1 Structura relaţionala a datelor

Prezentarea structurii relaţionale a datelor impune definirea noţiunilor de:
domeniu, relaţie, atribut şi schemă a unei relaţii.
Domeniu
Domeniul reprezintă un ansamblu de valori, caracterizat printr-un nume. Un
domeniu se poate defini explicit, prin enumerarea tuturor valorilor apartinând
acestuia sau implicit, prin precizarea proprietăţilor pe care le au valorile din cadrul
domeniului respectiv.
Sa considerăm, de exemplu domeniile D1, D2, D3, definite astfel:
D1: ("F","M")
D2: (x / x aparţine N, x aparţine [0,100])
D3: (s/s=şir de caractere)
În cazul lui D1 s-a recurs la o definire explicită, în timp ce pentru D2 şi D3
s-a utilizat definirea implicită.

17
 Pentru un ansamblu de domenii D1, D2, ..., Dn produsul cartezian al
acestora reprezinta ansamblul tuplurilor <v1, v2, ..., vn>, unde: v1 este o valoare
apartinând domeniului D1, v2 este o valoare din D2.
De exemplu, tuplurile: <"Maria", "F", 50>, <"Vasile", "M",15>,
<"Vasile","M",20>, <"Vasile", "F",100> aparţin produsului cartezian: D3 x
D1 x D2.
Relaţie
Să presupunem că se acordă o anumită semnificaţie valorilor domeniilor D1,
D2, D3, definite anterior.
Sa considerăm, de exemplu ca D1 cuprinde valorile referitoare la sexul unei
persoane, D2 conţine valori care exprimă vârsta unei persoane şi D3 cuprinde
numele unor persoane.
Numai unele dintre tuplurile produsului cartezian: D3 x D1 x D2 pot avea o
semnificaţie şi anume cele care conţin numele, sexul şi vârsta aceleiaşi persoane.
Dintre cele 202 tupluri care au valoarea "Vasile" pe prima pozitie, numai
unul poate avea o semnificaţie, dacă presupunem că există o singură persoană cu
acest nume.
Se desprinde de aici necesitatea definirii unei submulţimi de tupluri, din
cadrul produsului cartezian al domeniilor, submulţime care să cuprindă numai
tuplurile cu semnificaţie.
Relaţia reprezintă un subansamblu al produsului cartezian al mai multor
domenii, subansamblu caracterizat printr-un nume şi care conţine tupluri cu
semnificatie. Considerând, de exemplu, că nu se cunosc decât două persoane
definim realţia R prin tuplurile care descriu aceste persoane şi anume:
R: (<"Maria", "F", 30>, <"Vasile", "M", 35>)
Intr-o relaţie, tuplurile trebuie să fie distincte (nu se admit duplicări ale
tuplurilor).
O reprezentare comodă a relaţiei este tabelul bidimensional (tabela de date în
care liniile reprezinta tuplurile, iar coloanele corespund domeniilor).

18
 Relaţie reprezentată sub forma unei tabele de date
Reprezentarea tabelară este preferată adesea altor forme de reprezentare a
relaţiilor, întrucat este uşor de înţeles şi de utilizat.
În prezentarea conceptului de reţatie se recurge uneori la analogii cu alte
concepte, extrem de bine cunoscute în domeniul prelucrării automate a datelor
precum cel de fişier. Relaţia poate avea semnificaţia unui fişier, tuplul poate fi
considerat drept o înregistrare, iar valorile din cadrul tuplului pot fi interpretate
drept valori ale câmpurilor de înregistrare.
În cadrul modelului relaţional nu intereseaza decat relaţiile finite, chiar dacă
în construirea relaţiilor se admit domenii infinite. Numărul tuplurilor dintr-o relaţie
reprezinta cardinalul relaţiei, în timp ce numărul valorilor dintr-un tuplu defineste
gradul relaţiei.
Atribut
In timp ce tuplurile dintr-o relaţie trebuie să fie unice un domeniu poate
apare de mai multe ori în produsul cartezian pe baza căruia este definită relaţia.
Să considerăm, de exemplu, că pentru o persoana dispunem de urmatoarele
date: nume,sex, vârsta şi numele soţului/soţiei.
O posibilitate de organizare a acestor date o reprezintă relaţia PERS:
R: D3 D1 D2

“Maria” “F” 30
“Vasile” “M” 35
Relaţia PERS

Relatia PERS reprezintă un subansamblu al produsului cartezian:

D3 x D1 x D2 x D3.
Semnificaţia valorilor din cadrul unui tuplu se stabileşte în acest caz nu
numai pe baza domeniului de care aparţin valorile, ci şi in funcţie de poziţia
ocupată în cadrul tuplului. Dependenţa fată de ordine a datelor inseamnă o
19
reducere a flexibiltăţii organizarii datelor. Într-o organizare eficientă, flexibilă,
ordinea liniilor şi a coloanelor din cadrul tabelei de date nu trebuie să prezinte nici
o importanţă. Pentru a diferenţia coloanele care conţin valori ale aceluiaşi domeniu
şi a elimina astfel dependenţa de poziţie în cadrul tabelei se asociază fiecarei
coloane un nume distinct, ceea ce duce la aparitţa noţiunii de atribut.
Atributul reprezintă coloana unei tabele de date, caracterizată printr-un
nume. Numele coloanei (atributului) exprimă de obicei semnificaţia valorilor din
cadrul coloanei respective.
Schema unei relaţii
Prin schema unei relaţii se întelege numele relaţiei, urmat de lista
atributelor, pentru fiecare atribut precizându-se domeniul asociat.

2.2. Algebra relaţională

Modelul relaţional ofera doua colecţii de operatori pe relaţii şi anume:
 algebra relaţionala;
 calculul relaţional.
E. F. Codd a introdus algebra relaţionala (AR) cu operaţii pe relaţii, fiecare
operaţie având drept operanzi una sau mai multe relaţii şi producând ca rezultat o
altă relaţie.
Unele operaţii ale AR pot fi definite prin intermediul altor operaţii. În acest
sens, putem vorbi de:
 operaţii de bază, precum: reuniunea, diferenţa, produsul cartezian etc.
 operaţii derivate, ca: intersecţia, diviziunea etc.
Codd a introdus aşa numita AR standard, constituită din 6 operaţii de bază:
reuniunea, diferenţa, produsul cartezian, proiecţia, selecţia şi joncţiunea precum şi
din două operaţii derivate: intersecţia şi diviziunea.
Ulterior, la operaţiile AR standard au fost adăugate şi alte operaţii, aşa
numitele operaţii "adiţionale" sau extensii ale AR standard,
precum:complementara unei relaţii, splitarea (spargerea) unei relaţii, închiderea
tranzitivă etc.

20
 1. Reuniunea. Reprezintă o operaţie a AR definita pe doua relaţii: R1 şi R2
ambele cu o aceeaşi schemă, operaţie care constă din construirea unei noi relaţii
R3, cu schema identică cu R1 şi R2 şi având drept extensie tuplurile din R1 şi R2
luate impreună o singură dată.
Notaţia pentru reuniune este: R1 U R2
Reprezentarea grafică a reuniunii:
A B

X Y Z X Y Z
1 2 3 1 2 3
10 11 12 40 50 60
20 30 40 70 80 90

C= A U B
X Y Z
1 2 3
10 11 12
20 30 40
40 50 60
70 80 90

2. Diferenţa. Reprezintă operaţie din AR definită pe doua relaţii: R1 şi R2,

ambele cu o aceeaşi schemâ, operaţia constând din construirea unei noi relaţii R3,
cu schema identică cu a operanzilor şi cu extensia formată din acele tupluri ale
relaţiei R1 care nu se regăsesc şi în relaţia R2.
Notaţia pentru operaţia de diferenţă a doua relaţii este: R1-R2
C= A - B
X Y Z
10 11 12
20 30 40

3. Produs cartezian. Reprezintă o operaţie a AR definită pe două relaţii: R1

şi R2, operaţie care constă din construirea unei noi relaţii R3, a cărei schemă se
obţine prin concatenarea schemelor relaţiilor R1 şi R2 şi a cărei extensie cuprinde
toate combinaţiile tuplurilor din R1 cu cele din R2.
Notaţia pentru desemnarea operaţiei este: R1xR2.
21
 A B AxB
X Y W Z X Y W Z
1 2 1 2 1 2 1 2
10 15 20 30 1 2 20 30
40 50 1 2 40 50
10 15 1 2
10 15 20 30
10 15 40 50

4. Proiecţia. Reprezintă o operaţie din AR definită asupra unei relaţii R,

operaţie care constă din construirea unei noi relaţii P, în care se regăsesc unele
atribute din R, înseamnă efectuarea unor tăieturi verticale asupra lui R, care pot
avea ca efect apariţia unor tupluri duplicate ce se cer a fi eliminate.
Prin operaţia de proiecţie se trece de la o relaţie de grad n la o relaţie de grad
p, mai mic decât cel iniţial (p < n) ceea ce explică şi numele de proiecţie atribuit
operaţiei.
Notaţia pentru operaţia de proiecţie este:
ΠAi,Aj,…,Am(R)
5. Selecţia. Reprezintă o operaţie din AR definită asupra unei relaţii R,
operaţie care constă din construierea unei relaţii S, a cărei schemă este identică cu
cea a relaţiei R şi a cărei extensie este constituită din acele tupluri din R care
satisfac o condiţie menţionată explicit în cadrul operaţiei. Întrucât cel mai adesea,
nu toate tuplurile din R satisfac, această condiţie, selecţia înseamnă efectuarea unor
tăieturi orizontale asupra relaţiei R, adică eliminarea de tupluri. Condiţia precizată
în cadrul operaţiei de selecţie este în general de forma:

unde: "operator de comparaţie" poate fi: <, <=, >=, > sau <>.

22
 Notaţia folosită in mod uzual pentru desemnarea operaţiei de selecţie este
următoarea:
Σ(conditie)R.
6. Joncţiunea (Joinul). Reprezintă o operaţie din AR definită pe două
relaţii: R1 şi R2, operaţie care constă din construirea unei noi relaţii R3,
prin concatenarea unor tupluri din R1 cu tupluri din R2. Se concateneaza acele
tupluri din R1 şi R2 care satisfac o anumita condiţie, specificată explicit în cadrul
operaţiei. Extensia relaţiei R3 va contine deci combinaţiile acelor tupluri care
satisfac condiţia de concatenare.
Notaţiiile pentru desemnarea operaţiei de joncţiune sunt:

Reprezentarea grafică a acestei operaţii:

In general, condiţia de concatenare menţionata in cadrul operaţiei de

joncţiune este de forma:

In funcţie de operatorul do comparaţie din cadrul condiţiei de concatenare,

joinul poate fi de mai multe tipuri. Cel mai important tip de join, în sensul celei
mai frecvente utilizări este equijoinul.
Equijoinul reprezinta joncţiunea dirijată de o condiţie de forma:

Operatia de joncţiune se poate exprima cu ajutorul operaţiilor de

produs cartezian şi selecţie, rezultatul unui join fiind acelaşi cu rezultatul unei
selecţii operate asupra unui produs cartezian, adică:

23
 JOIN (R1,R2, condiţie) = RESTRICT(PRODUCT(R1,R2), condiţie)
Produsul cartezian reprezintă o operaţie laborioasă şi foarte costisitoare, ceea
ce face ca in locul produsului să fie utilizat joinul ori de câte ori acest lucru este
posibil. Cu toate că apare drept o operaţie derivată, joinul este prezentat de obicei
drept o operaţie de bază din AR, dată fiind importanţa sa in cadrul sistemelor
relaţionale, în special la construirea relaţiilor virtuale.
Au fost definite numeroase variante ale operaţiei de joncţiune, variante care
diferă nu numai în funcţie de tipul condiţiilor de concatenare, ci şi după modul de
definire a schemei şi respectiv, extensiei relaţiei rezultate prin joncţiune.
Joncţiunea naturală. In cazul equijoinului, schema relaţiei conţine toate
atributele celor doi operanzi. În toate tuplurile relaţiei rezultat vor exista de aceea
cel puţin două valori egale. In sensul eliminării acestei redundanţe s-a introdus
joncţiunea naturală, ca operaţie definită pe două relaţii: R1 şi R2, prin care este
construită o noua relaţie R3, a cărei schemă este obţinută prin reuniunea atributelor
din relaţiile R1 şi R2 (atributele cu acelaşi nume se iau o singură dată) şi a cărei
extensie conţine tuplurile obţinute prin concatenarea tuplurilor din R1 cu tuplurile
din R2 care prezintă aceleaşi valori pentru atributele cu acelaşi nume.

Notaţia pentru joncţiunea naturală este:

Reprezentarea grafică a acestei operaţii:

Operaţia de joncţiune naturală a relaţiilor ORAŞE şi ESTIMĂRI

24
 7. Intersecţia. Reprezintă o operaţie a AR definită pe două relaţii: R1 şi R2
ambele cu aceeaşi schemă, operaţie care constă din construirea unei noi relaţii R3,
cu schema identică cu a operanzilor şi cu extensia formată din tuplurile comune lui
R1 şi R2.
Notaţie pentru intersecţia este: R1∩R2
Reprezentarea grafică a operaţiei de intersecţie:
A B

X Y Z X Y Z
1 2 3 1 2 3
10 11 12 40 50 60
20 30 40 70 80 90

C= A ∩ B
X Y Z
1 2 3

Intersecţia reprezintă o operaţie derivată, care poate fi exprimată prin

intermediul unor operaţii de bază. De exemplu, operaţia de intersecţie se poate
exprima prin intermediul operaţiei de diferenţă, cu ajutorul următoarelor
echivalenţe:
R1 ∩ R2=R1-(R1-R2)
R1∩ R2=R2-(R2-R1).

25
Capitolul 3. Normalizarea datelor
3.1. Redundanta informatiilor şi anomalii la actualizare
La proiectarea unei baze de date, un obiectiv foarte important, care trebuie
urmarit cand se gandeste un model de date, este realizarea unei reprezentari corecte
a datelor, a relatiilor dintre date şi a restrictiilor impuse asupra datelor. Pentru
realizarea acestui obiectiv se utilizeaza tehnica normalizarii, care are ca scop
principal identificarea setului celui mai adecvat de relatii care sa modeleze
realitatea dorita.
Procesul de normalizare a fost introdus de E. F. Codd (1972). Iniţial s-au
propus trei forme normale, notate 1NF, 2NF, respectiv 3NF. Mai târziu, prin
enuntarea unei definitii mai tari a formei normale trei, s-a obtinut forma Boyce-
Codd (BCNF), după numele celor care au introdus aceasta forma normala: R.
Boyce şi E.F.Codd (1974). Toate aceste forme normale se bazeaza pe dependentele
functionale stabilite intre atributele unei relatii.
Formele normale cele mai folosite sunt: forma normală 3 şi forma normală
Boyce-Codd. Există şi forme normale mai tari - forma normală 4 (4NF) şi forma
normală 5 (5NF) - dar acestea se folosesc foarte rar.
Procesul de normalizare este o metodă formală care identifica relaţiile
bazandu-se pe cheile primare ale acestora (sau pe cheile candidat în cazul BCNF)
şi pe dependenţele funcţionale care exista intre atributele acestor relatii.
Normalizarea sprijina proiectantul bazei de date, dandu-i posibilitatea sa aplice o
serie de teste asupra relatiilor individuale, asa incat schema relaţionala poate fi
normalizata la forma normala dorita, pentru a se preveni aparitia anomaliilor la
actualizare.
Pentru a ilustra procesul de normalizare, vom utiliza exemple din sistemul
informatic Asociatie de locatari.
Partea cea mai importantă la proiectarea bazei de date este gruparea
atributelor în relaţii cu scopul de a minimiza redundanţa informaţiilor şi (odata cu
aceasta) spaţiul ocupat de relatii (tabele sau fişiere) pe suportul magnetic.
26
 Fie relaţia Furnizori_Cheltuieli exemplificată mai jos. In exemple se vor simplifica
numele atributelor.

Cod_furn Den_furn Cod_fiscal Cod_chelt Den_chelt Data Valoare

F100 Moldgaz R1234567 C15 Incalzire 30.06.12 2150,00
F100 Moldgaz R1234567 C16 Apa calda 30.06.12 500,00
F110 Renel R7654321 C10 Iluminat 30.06.12 3000,00
F110 Renel R7654321 C11 Lift 30.06.12 200,00

Relaţia Furnizori_Cheltuieli
Sa presupunem ca aplicaţia pe care o vom studia ca exemplu contine datele
organizate intr-o singura relatie descrisa de urmatoarele schema de relatie:
Furnizori_Cheltuieli = (Cod_furn, Den_furn, Cod_fiscal, Cod_chelt,
Den_chelt, Data, Valoare)
Dintre atribute, cele evidentiate constituie cheia primara pentru relatia
respectiva. Relatia Furnizori_Cheltuieli are cheia compusa din atributele
Cod_furn, Cod_Chelt şi Data. Datele sunt prost organizate in relatia prezentata.
Informaţia despre furnizori din relatia Furnizori_Cheltuieli este redundantă.
Detaliile despre furnizor se repetă la fiecare introducere a unei cheltuieli noi.
Nu este insa singura problema pe care o organizare nepotrivita a datelor o
poate genera.
O altă consecinta a redundanţei informatiilor din baza de date, o reprezinta
problemele de actualizare a informaţiei stocate. Enumeram mai jos o parte dintre
acestea.
Anomalii de adaugare
Anomaliile de inserare se pot clasifica în două tipuri:
 Pentru a adauga detaliile despre o cheltuială către un furnizor, în
relaţia Furnizori_Cheltuieli trebuie obligatoriu adăugate şi detaliile despre
furnizorul în cauză, chiar dacă ele există deja în baza de date. Această anomalie
poate duce la apariţia de informatii diferite despre acelasi furnizor în înregistrări
diferite. Informatia despre furnizor isi pierde in acest mod consistenta, nu ne mai
putem baza pe corectitudinea datelor despre furnizor in baza de date.

27
  Pentru a adăuga detalii despre un furnizor nou în relaţia
Furnizori_Cheltuieli, trebuie neapărat adăugată şi o cheltuială pentru asociaţia de
locatari către acel furnizor. În cazul în care încă nu a sosit factura de la furnizor, nu
se poate înregistra nici o cheltuială şi deci trebuie introduse valori nule. Este
nerecomandabil sa se lucreze cu valori nule deoarece se genereaza probleme la
regasirea şi actualizarea informatiilor.
Anomalii de ştergere
În cazul ştergerii unei cheltuieli a asociaţiei de locatari către un furnizor nou
(tot in cadrul relatiei Furnizori_Cheltuieli ), se va şterge şi furnizorul. Deci toate
detaliile introduse despre acel furnizor vor fi pierdute, ceea ce duce la
obligativitatea reintroducerii datelor la o nouă folosire al acelui furnizor.
Anomalii de modificare
Dacă în relaţia Furnizori_Cheltuieli dorim să schimbăm valoarea unui
atribut al unui furnizor, va trebui să schimbăm datele pentru fiecare apariţie a
acelui furnizor. De exemplu, dacă dorim să schimbăm codul fiscal al furnizorului
cu codul F100, va trebui să schimbăm acest atribut în toate tuplele in care apare
furnizorul F100. Din nou, este posibil ca datele sa nu fie modificate corect. Este
posibil sa ramana tuple cu datele nemodificate sau este posibil sa se modifice
datele respective cu valori diferite in locuri diferite. (Nu dorim sa insistam asupra
cauzelor care pot duce la aceste situatii.).
Anomaliile enumerate mai sus se pot evita prin folosirea (in acest caz) a
două relatii distincte: Cheltuieli şi Furnizori. În acest caz dacă trebuie modificat un
atribut al unui furnizor, modificarea se va executa intr-un singur loc în relatia
Furnizori. Asemanator, daca e necesara o stergere in relatia Cheltuieli, aceasta nu
va mai afecta furnizorii din relatia Furnizori. De asemenea orice cheltuiala
adaugata şi orice furnizor nou adaugat nu se vor mai conditiona reciproc in nici un
fel.
Descompuneri cu pierderi de informatii
In urma analizarii anomaliilor de actualizare prezentate mai sus am tras
concluzia ca o descompunere a relatiilor care ne fac probleme este binevenita şi
28
duce la rezolvarea problemelor. Este bine insa sa tratam descompunerile de relatii
cu prudenta deoarece o descompunere neglijenta ne poate crea probleme la fel de
mari cu acelea de care tocmai ne-am ocupat. Este posibil sa pierdem informatii
daca nu suntem atenti la modul in care se realizeaza descompunerea.
In general se poate urmari ca in fiecare relatie sa se reprezinte informatii
despre o singura multime-entitate. Criteriul este mai mult de ordin intuitiv şi el nu
ne este de mare ajutor in cazul reprezentarii multimilor-relatie. In acest caz, intr-o
relatie se intalnesc date despre mai multe multimi-entitate. Este necesar sa se
stabileasca o modalitate riguroasa de a decide care sunt informatiile care trebuie sa
alcatuiasca o astfel de relatie.
Orice relatie se construieste pe baza unei scheme de relatie. Fie R o schema
oarecare de relatie. Un set de scheme de relatie reprezinta o descompunere a lui R
şi se noteaza {R1, R2, …, Rn} daca

=R

Aceasta inseamna ca orice atribut din schema de relatie initiala R se

regaseste in cel putin o schema de relatie din descompunere. Daca ne raportam la
relatiile care se bazeaza pe schemele de mai sus, fie r relatia construita pe schema
R si fie relatiile r1, r2, …, rn construite pe schemele de relatie ce formeaza
descompunerea. In termenii algebrei relaţionale se poate considera egalitatea;
ri = pentru toti 1in.
Deci fiecare ri este proiectia relatiei r pe atributele care apar in schema de
relatie Ri.
Descompunerile cu pierderi de informatii se pot clasifica in Descompuneri
cu pierderi la jonctiune şi Descompuneri cu pierderea dependentelor. Pentru a
clarifica lucrurile in aceasta directie este necesara mai intai definirea notiunii de
dependenta functionala.

29
3.2. Dependenţe funcţionale
Unul din cele mai importante concepte asociate cu normalizarea este
conceptul de dependenţă funcţională. Dependenţa funcţională descrie un anumit tip
de legatura care se stabileste intre atributele aceleiasi relatii.
Fie o schema de relatie R şi fie submultimile de atribute A şi B din R. Se
verifica AR şi BR. Spunem ca B depinde functional de A şi scriem AB daca
pentru orice relatie legala r, construita pe schema de relatie R, se verifica
urmatoarea situatie:
pentru orice pereche de tuple t1 şi t2 din r, pentru care t1[A]=t2[A], are loc
intotdeauna şi t1[B]=t2[B].
Aceasta inseamna ca atunci cand un tuplu t1 are (pe submultimea de atribute
A) aceeasi valoare cu alt tuplu t2, obligatoriu cele doua tuple vor avea aceeasi
valoare şi pe submultimea de atribute B. Valorile din B sunt in mod unic
determinate de valorile din A.
Numim determinant al unei dependente funcţionale, atributul, sau mulţimea
atributelor din partea stângă a săgeţii.
O parte dintre dependenţele funcţionale pentru relaţia Furnizori_Cheltuieli
sunt:
Cod_furn  Den_furn
Cod_furn  Cod_fiscal
Cod_chelt Den_chelt
Cod_chelt, Cod_furn, Data  Valoare
Numele furnizorului este determinat in mod unic de codul furnizorului. La
coduri egale, numele sunt identice.
Valoarea insa nu poate fi determinata in mod unic decat de combinatia cod
cheltuiala, cod furnizor şi data. Intr-o anume data, un anumit furnizor, pentru un
anumit serviciu (care duce la un anume cod cheltuiala) cere o suma bine
determinata de bani. Nici una dintre valori nu poate determina valoarea şi nici in
combinatii de cate doua. Daca nu se iau cele trei informatii impreuna se pot crea
confuzii in legatura cu valoarea. (Acelasi cod de cheltuiala poate corespunde la
30
valori diferite in date diferite. Acelasi furnizor poate avea chiar şi coduri de
cheltuiala diferite darmite valoarea care le reprezinta, s.a.m.d.)
Notiunea de dependenta functionala generalizeaza notiune de cheie. Se poate
da urmatoarea definitie a supercheii:
Spunem ca submultimea de atribute K din schema de relatie R este o
supercheie daca KR, adica pentru orice pereche de tuple t1 şi t2 din r, pentru care
t1[K]=t2[K], are loc intotdeauna şi t1[R]=t2[R].
Dependentele functionale ne permit sa exprimam restrictii asupra relatiilor
pe care nu le putem exprima cu ajutorul cheilor. Dependenţa funcţională este o
proprietate legata de semantica atributelor în relaţii. Dependentele functionale pot
fi stabilite de cine cunoaste exact legaturile intre valorile atributelor, deci de catre
cineva care cunoaste foarte bine aplicaţia şi semnificatia informatiilor din relatii.
Nu se pot da retete pentru stabilirea dependentelor functionale, dar se pot da
metode de a determina toate dependentele functionale dintr-o relatie daca se
cunosc cateva dependente de la care poate porni algoritmul.
O metoda de a determina multimea tuturor dependentelor functionale dintr-o
relatie se bazeaza pe asa-numitele Axiome ale lui Armstrong.
Regulile (Axiomele) lui Armstrong:
1) regula reflexivitatii – daca X este un subset de atribute din R şi YX,
atunci are loc XY;
2) regula creşterii – daca X, Y şi W sunt subseturi de atribute din R şi
daca XY atunc WXWY;
3) regula tranzitivitatii – daca X, Y şi Z sunt subseturi de atribute din R
şi daca XY şi YZ atunci are loc şi XZ.
Cele trei reguli sunt suficiente şi formeaza un set complet pentru a se putea
determina toate dependentele functionale daca se porneste de la un set de baza
initial. Totusi se mai utilizeaza in mod obisnuit şi reguli suplimentare (care pot fi
deduse din primele trei) deoarece usureaza calculele.

31
 Astfel:
4) regula reuniunii – daca X, Y şi Z sunt subseturi de atribute din R şi
daca XY şi XZ atunci şi XYZ;
5) regula descompunerii – daca daca X, Y şi Z sunt subseturi de atribute
din R şi daca XYZ atunci au loc şi XY şi XZ;
6) regula pseudotranzitivitatii - daca X, Y, W şi Z sunt subseturi de
atribute din R şi daca XY şi WYZ atunci şi WXZ

EXEMPLU:
Fie schema de relatie R={A, B, C, G, H, I} şi fie setul de dependente initial
notat cu F şi format din dependentele: AB, AC, CGH, CGI, BH.
Pornind de la acest set initial se mai pot calcula şi urmatoarele dependente:
 AH, utilizand regula tranzitivitatii aplicata la dependentele AB şi
BH;
 CGHI, utilizand regula reuniunii pentru dependentele CGH şi
CGI;
si asa mai departe… …
Daca se noteaza cu F setul initial de dependente functionale, cu F + se va nota
inchiderea lui F (deci toate dependentele functionale care se pot defini pentru
relatia in cauza.)
Putem reveni in acest moment pentru a trata descompunerile de relatii. Am
subliniat mai inainte ca este necesar sa fim atenti la descompuneri pentru a evita
pierderea de informatii.
Descompuneri fara pierderi la jonctiune
Fie o descompunere oarecare {R1, R2, …, Rn} a relatiei R. Pentru o
descompunere oarecare se verifica intotdeuna relatia:

r ri

unde prin X s-a notat produsul cartezian, operatie din algebra relaţionala.
Altfel spus, orice tuplu din relatia r duce, prin descompunere, la cate un tuplu t i in
32
fiecare relatie ri. Cand se realizeaza produsul cartezian cu toate relatiile r i, se obtin
in general mai multe tuple decat au fost in relatia initiala r, deoarece produsul
cartezian are ca rezultat toate combinatiile posibile intre elementele participante.
Asupra relatiilor dintr-o baza de date se impun intotdeauna anumite restrictii
sau conditii, care sa asigure corectitudinea informatiilor din respectiva baza de
date.
In general spunem ca o relatie este legala daca satisface toate regulile sau
restrictiile care sunt impuse la proiectarea bazei de date.
Fie C un set de restrictii asupra bazei de date. O descompunere {R 1, R2, …,
Rn} a unei scheme de relatie R este o descompunere fara pierderi la jonctiune
pentru R, daca pentru toate relatiile r definite pe schema R (care sunt legale sub
restrictiile C) se verifica:

r=

Vom prezenta in continuare un criteriu cu ajutorul caruia se poate verifica

daca este o descompunere fara pierderi la jonctiune sau nu.
Definitie. Fie R o schema de relatie şi fie descompunerea lui R reprezentata
de {R1, R2}. Aceasta descompunere este fara pierderi la jonctiune daca cel putin
una dintre urmatoarele dependente functionale se gasesc in F+:
R1R2R1
R1R2R2
Descompuneri cu pastrarea dependentelor
Pastrarea dependentelor duce la pastrarea consistentei informatiilor din baza
de date. Se pot impune restrictii care permit sistemului sa verifice la orice
actualizare a informatiilor ca nu se va crea o relatie ilegala.
Fie F setul initial de dependente functionale, definit pe o schema de relatie
R. şi fie {R1, R2, …, Rn} o descompunere a lui R. Notam cu F i restrictia la Ri a
multimii de dependente functionale F. (Se cere ca dependentele functionale din Fi
sa includa doar atribute care se regasesc in relatia Ri).

33
 Vom obtine un set de multimi de dependente functionale F 1, F2, …, Fn. Fie

F'= Fi, reuniunea seturilor de dependente funtionale. In general F'F. Dar s-ar

putea ca sa se verifice relatia F'+=F+. Daca se intampla asa atunci spunem ca

descompunerea este o descompunere cu pastrarea dependentei.

3.3. Forme normale

Normalizarea este un proces de organizare a datelor in relatiile unei baze de
date. Acest proces presupune respectarea unor reguli prin care baza de date se
poate normaliza până la un anumit grad, adica se aduce la o anumita forma
normala.
Normalizarea se execută trecând prin toate formele normale, până la forma
normală cerută. La proiectarea unei baze de date e recomandabil sa se ajunga cel
puţin pana la forma normală trei. Aceasta asigura evitarea anomaliilor descrise la
inceputul acestui capitol.
Forma Normală Unu (1NF)
Numim Formă Nenormalizată (UNF) orice tabelă care conţine una sau mai
multe grupuri repetitive pe atribute.
Forma Normală Unu (1NF): Spunem ca o relaţie se gaseste in Forma
normala unu daca orice atribut este atomic, adica nu exista nici atribute compuse
nici repetitive.
Pentru a transforma tabela Furnizori_Cheltuieli în forma normală unu,
identificăm şi ştergem grupurile repetitive din tabelă. Eliminarea acestor grupuri
repetitive se poate realiza în două moduri:
Conform primei modalităţi, eliminăm grupurile repetitive, prin crearea altor
înregistrări, în care să fie introduse valorile din aceste grupuri, împreună cu
celelalte valori ale atributelor din înregistrarea la care se lucrează. Tabele astefel
rezultată va fi în formă normală unu.
În a doua modalitate, fiecare valoare a grupurilor repetitive le copiem într-o
nouă relaţie împreună cu cheia primară din tabela iniţială. Putem avea mai multe

34
grupuri repetitive. În acest caz creăm mai multe relaţii noi. Aceste relaţii noi,
precum şi tabela normalizată vor fi în formă normală unu.
Pentru relaţia Furnizori_Cheltuieli:
Cod_furn Den_furn Cod_fiscal Cod_chelt Den_chelt Data Valoare
F100 Moldgaz R1234567 C15 Incalzire 30.06.12 2150,00
F100 Moldgaz R1234567 C16 Apa calda 30.06.12 500,00
F110 Renel R7654321 C10 Iluminat 30.06.12 3000,00
F110 Renel R7654321 C11 Lift 30.06.12 200,00
Tabela nenormalizată Furnizori_Cheltuieli.

Observăm că pentru furnizorul "Moldgaz" avem două tipuri de cheltuieli.

La fel şi pentru furnizorul "Renel".

Pentru a transforma această tabelă în 1NF, trebuie să avem o singură valoare

la fiecare intersecţie linie coloană.
Daca vom normaliza dupa prima metoda, vom scrie repetiţiile pe diferite rânduri iar coloanele
care nu conţin repetiţii, vor fii copiate corespunzator pe fiecare rând

Cod_furn Den_furn Cod_fiscal Cod_chelt Den_chelt Data Valoare

F100 Moldgaz R1234567 C15 Incalzire 30.06.12 2150,00
F100 Moldgaz R1234567 C16 Apa calda 30.06.12 500,00
F110 Renel R7654321 C10 Iluminat 30.06.12 3000,00
F110 Renel R7654321 C11 Lift 30.06.12 200,00
Tabela Furnizori_Cheltuieli în 1NF

În tabela normalizatã, cheia va fi (Cod_furn, Cod_chelt, Data).

Normalizând tabela iniţială după a doua modalitate, vom crea o a doua
tabelă cu informaţiile care nu se repetă, împreună cu cheia primară din tabela
iniţială. Deci cele două tabele vor fi următoarele:
Furnizori (Cod_furn, Den_furn, Cod_fiscal)
Cheltuieli (Cod_furn, Cod_chelt, Data, Den_chelt, Valoare)
Cele două tabele astfel create sunt în 1NF:
35
 Cheltuieli
Cod_furn. Cod_chelt Data Den_chelt Valoare
F100 C15 30.06.12 Incalzire 1500
F100 2 C16 30.06.12 Apa calda 500
F110 3 C10 30.06.12 Iluminat 3000
F110 4 C11 30.06.12 Lift 200
Furnizori
Cod_furn Den_furn Cod_fiscal
F100 Moldgaz R1234567
F110 Renel R7654321
Relaţiile Cheltuieli şi Furnizori, create prin metoda a doua de normalizare.
Pentru a demonstra trecerea la forma normală doi şi mai departe, vom folosi
relaţia Furnizori_Cheltuieli.
Forma Normală Doi (2NF)
Forma normală doi se obtine utilizand conceptul de dependenţă funcţională
totală.
Dependenţa funcţională totală. Dacă A este un subset de doua sau mai
multe atribute şi B este atribut (sau subset de atribute) al aceleiasi relaţii, spunem
ca B este total dependent funcţional de grupul de atribute A, dacă B este dependent
funcţional de A, dar nu este dependent funcţional de nici un subset de atribute din
A.
De exemplu să luăm următoarea dependenţă funcţională:
Cod_chelt, Cod_furn, Data  Valoare
Dependenţa funcţională este totala pentru ca Valoare nu depinde functional
de nici un subset de atribute al grupului Cod_chelt, Cod_furn, Data.
Forma normală doi trebuie verificată doar la relaţiile care au cheie compusă
pe poziţie de cheie primară. Relaţia la care cheia primară se compune dintr-un
singul atribut, este în 2NF daca este in 1NF.

36
 Forma Normală Doi (2NF). O relaţie este în forma normală doi, dacă este
în forma normală unu şi fiecare atribut care nu aparţine cheii primare, este total
dependent funcţional de cheia primară.
Vom demonstra aducerea la forma normală doi, folosind relaţia
Furnizori_Cheltuieli. Putem trece la forma normală doi prin ştergerea atributelor
care nu depind total de cheia primară şi trecerea lor într-o altă tabelă împreună cu
determinantul lor. După efectuarea acestor transformări, vom obtine următoarele
relaţii:
Relatia Cheltuieli:
Cod_furn. Cod_chelt Data Valoare
F100 C15 30.06.99 1500
F100 C16 30.06.99 500
F110 C10 30.06.99 3000
F110 C11 30.06.99 200
Relaţia Furnizori:
Cod_furn Den_furn Cod_fiscal
F100 Moldgaz R1234567
F110 Renel R7654321
Relatia Tip_cheltuiala:
Cod_Chelt Den_chelt
C15 Incalzire
C16 Apa calda
C10 Iluminat
C11 Lift
Relaţiile rezultate după trecerea la 2NF a relaţiei Furnizori_Cheltuieli.
Relaţiile rezultate au următoarele scheme de relatie:
Furnizori = (Cod_furn., Den_furn, Cod_fiscal)
Tip cheltuială = (Cod_Chelt., Den_chelt)
Cheltuieli = (Cod_furn, Cod_chelt, Data, Valoare)

37
 Forma Normală Trei (3NF)
Forma normală doi chiar dacă nu conţine atâta redundanţă ca forma normală
unu, totuşi există cazuri în care pot apărea anomalii la actualizare. Aceste anomalii
apar din cauza redundanţei generate de dependenţa tranzitivă.
Dependenţă tranzitivă. Dacă atributele A, B, C sunt în relaţiile AB şi
BC, atunci spunem că atributul C este dependent tranzitiv de atributul A, via B.
Forma Normală Trei (3NF). Spunem ca o relaţie este în formă normala trei
daca este deja in forma normală doi şi nici un atribut care nu aparţine cheii primare
nu este tranzitiv dependent de cheia primara.
În cazul existenţei dependenţei tranzitive, ştergem coloanele care sunt
tranzitiv dependente de cheia primară şi creăm o relaţie nouă cu aceste coloane,
împreună cu determinantul lor, adică cheia primară.
Examinând relaţiile în forma normală de mai sus, observăm că nu există
dependenţe tranzitive. Deci relaţiile sunt în formă normală trei.
Forma Normală Boyce-Codd (BCNF)
Baza de date trebuie proiectată astfel încât să nu conţină dependenţe parţiale
sau tranzitive, pentru că altfel ne putem confrunta cu anomaliile descrise la
inceputul capitolului.
Forma normală Boyce-Codd se obtine utilizand cheile candidat din relaţie. O
relaţie cu o singură cheie candidat în formă normală trei este şi în formă normală
Boyce-Codd.
Forma normală Boyce-Codd (BCNF). Spunem ca o relaţie este în forma
normală Boyce-Codd dacă şi numai dacă orice determinant din relaţie este cheie
candidat.
Să căutăm determinanţii din exemplul de mai sus:
Cod_furn  Den_furn, Cod_fiscal
Cod_chelt  Den_chelt
Cod_furn, Cod_chelt, Data  Valoare

38
 Toţi cei trei determinanţi sunt şi chei candidat in relatiile lor. Deci relatiile
din exemplul de mai sus sunt în formă normală Boyce-Codd. Relaţiile în formă
normală trei sunt în general şi în formă normală Boyce-Codd. În cazul în care
relaţia nu este în formă normală Boyce-Codd, trecerea la BCNF se realizează prin
ştergerea din relaţia iniţială a atributelor care sunt asociate unui determinant care
nu este cheie candidat şi crearea unei noi relaţii cu aceste atribute şi determinantul
lor.
Există situaţii când este foarte greu de descompus relatiile, ca să ajungem la
BCNF. În aceste situaţii este indicata rămânerea la forma normală trei.

Concluzii
Forma Normală Unu (1NF)
Trebuie să căutăm toate intersecţiile de linii şi coloane, unde există
repetiţii. Aceste repetiţii se pot elimina prin două modalităţi:

 Crearea de noi înregistrări pentru fiecare valoare a repetiţiei, după care

se caută o nouă cheie primară.
 Ştergerea atributelor care conţin repetiţii şi crearea de noi relaţii care
vor conţine atributele şterse, precum şi cheia primara din relaţia iniţială.
Forma Normală Doi (2NF)
Se caută dependenţele totale de cheia primara, adică toate atributele care
depind funcţional de un subset de atribute a cheii primare. Dacă cheia primară este
compusă dintr-un singur atribut, atunci relaţia este în forma normală doi, daca este
deja in forma normala unu. Dacă există dependenţe partiale, ştergem atributele care
depind parţial de cheia primara şi creăm o relaţie nouă care să se compună din
atributele şterse împreună cu determinantul lor.
Forma Normală Trei (3NF)
Pentru a trece la forma normală trei, trebuie să eliminăm dependenţele
tranzitive. Eliminarea se realizează prin ştergerea câmpurilor dependente tranzitiv
de cheia primară din relaţia iniţială şi crearea unei noi relaţii cu aceste atribute şi
determinantul lor.

39
 Forma Normală Boyce-Codd (BCNF)
Cerinţa la forma normală Boyce-Codd este ca fiecare determinant din relaţie
să fie cheie candidat. În cazul în care nu este îndeplinită această cerinţă, vom şterge
atributele dependente funcţional de determinantul care nu este cheie candidat şi
creăm o nouă relaţie în care să avem atributele şterse şi determinantul lor. În unele
cazuri trecerea la forma normală Boyce-Codd complică foarte mult baza de date,
caz în care este de preferat rămânerea la forma normală trei.

40
Capitolul 4. Proiectarea a bazelor de date relaţionale

Metodologia proiectării bazei de date se compune din două etape mari:

proiectarea logică, în care proiectantul decide asupra structurii logice a bazei de
date, şi proiectarea fizică, în care proiectantul decide cum se va implementa
structura logică în sistemul de gestiune a bazelor de date (SGBD).

4.1. Metodologia proiectării bazelor de date

Definiţie: Metodologie de proiectare: O aproximare structurată, care
utilizează proceduri, tehnici, instrumente şi documentaţii pentru a facilita procesul
de proiectare.
Metodologia de proiectare se compune din etape, care la rândul lor se
compun din paşi, care orientează proiectantul la fiecare nivel al creării bazei de
date.
Proiectarea logică şi fizică a bazei de date
Definiţie: Proiectare logică: Procesul de construcţie a unui model de
informaţii folosite într-o întreprindere, bazată pe modelul de date, dar independent
de particularizările sistemului de gestiune a bazei de date şi a altor considerente
fizice.
Proiectarea logică începe cu crearea modelului conceptual al bazei de date,
care este independent de implementarea într-un SGBD. Modelul conceptual este
apoi proiectat pe un model logic, care va influenţa mai târziu modelul de date în
care se va implementa.
Definiţie: Proiectare fizică: Este procesul de descriere a implementării
bazei de date într-un SGBD.
În această etapă a proiectării este creată baza de date într-un SGBD,
împreună cu procedurile de actualizare. În această etapă există un feedback între
proiectarea fizică şi cea logică, pentru că deciziile luate la implementarea fizică pot
afecta baza de date logice.

41
4.2. Prezentarea metodologiei
Să vedem care sunt paşii de urmat în proiectare:

Pasul 1. Proiectarea logică a bazei de date relaţionale: Crearea unui

model conceptual local, pentru vederile utilizatorilor.
Pasul 1.1. Identificarea tipurilor de entităţi.
Pasul 1.2. Identificarea tipurilor de relaţii.
Pasul 1.3. Identificarea şi atribuirea de atribute la tipurile de entităţi şi
tipurile de relaţii.
Pasul 1.4. Determinarea domeniilor de definiţie a atributelor.
Pasul 1.5. Determinarea atributelor care compun cheile candidate şi
primare.
Pasul 1.6. Specializare/generalizare (pas opţional).
Pasul 1.7. Desenarea diagramei entity-relationship.
Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului.
Pasul 2. Crearea şi validarea modelului logic local.
Pasul 2.1. Proiectarea modelului conceptual local pe un model logic local.
Pasul 2.2. Crearea relaţiilor pentru modelul logic local.
Pasul 2.3. Validarea modelului, utilizând normalizarea.
Pasul 2.4. Validarea modelului din nou, utilizând tranzacţiile.
Pasul 2.5. Desenarea diagramei ER.
Pasul 2.6. Definirea regulilor de integritate a bazei de date.
Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului.
Pasul 3. Crearea şi validarea modelului logic global de date.
Pasul 3.1. Compunerea modelelor logice locale într-un model logic global.
Pasul 3.2. Validarea modelului logic global.
Pasul 3.3. Verificarea posibilităţii de a completa baza de date în viitor.
Pasul 3.4. Desenarea diagramei ER finale.
Pasul 3.5. Verificarea modelului logic global cu ajutorul utilizatorului.

42
 Pasul 4. Proiectarea fizică şi implementarea bazei de date
relaţionale: Translatarea modelului logic global în SGBD.
Pasul 4.1. Proiectarea relaţiilor de bază în SGBD.
Pasul 4.2. Crearea regulilor de integritate în SGBD.
Pasul 5. Proiectarea şi implementarea reprezentării fizice.
Pasul 5.1. Analizarea tranzacţiilor.
Pasul 5.2. Alegerea organizării fişierelor.
Pasul 5.3. Alegerea indecsilor secundari.
Pasul 5.4. Introducerea unei redundanţe comntrolate.
Pasul 5.5. Estimarea spaţiului pe disc.
Pasul 6. Proiectarea şi implementarea unui mechanism de securitate.
Pasul 6.1. Crearea view-urilor pentru utilizatori.
Pasul 6.2. Proiectarea regulilor de acces la baza de date.
Pasul 7. Verificarea sistemului operaţional.
Proiectarea logică a bazei de date se divide în trei paşi mari. Primul pas are
ca obiectiv, descompunerea proiectării sistemului informatic în vederi, care se pot
discuta cu utilizatorii sistemului. Modelul de date astfel creat, se validează prin
normalizare şi prin tranzacţii în pasul doi. În final, se generează modelul global al
întreprinderii, care este la rândul lui validat şi verificat cu ajutorul utilizatorului
sistemului.

Factori critici pentru succesul proiectării logice:

 Lucrul interactiv cu utilizatorul sistemului.

 Folosirea unei metodologii structurate pentru procesul de proiectare a
bazei de date.
 Încorporarea regulilor de integritate în modelul logic de date.
 Combinarea validării conceptuale, prin normalizare şi prin tranzactii,
la proiectarea modelului logic de baze de date.
 Utilizarea diagramelor pentru a reprezenta cât mai multe modele
logice posibile.
43
  Crearea dicţionarului de date, ca supliment al modelului de date.

4.3. Crearea modelului logic

Pasul 1. Crearea modelului conceptual local, pentru utilizatori.

Obiectivul: Crearea unui model conceptual local, pentru view-urile

utilizatorilior.

Primul pas în proiectarea bazei de date este de a colecta datele necesare

pentru realizarea sistemului, ceea ce putem culege, discutând cu viitorii utilizatori
ai bazei de date. Această discuţie presupune o despărţire în vederi, a bazei de date,
vederi care pot lucra separat.

Despărţirea în vederi se poate realiza în mai multe moduri. O modaliate ar fi

analiza datelor globale şi găsirea de părţi relativ independente. O altă modalitate ar
fii analiza rapoartelor, procedurilor cerute şi/sau observarea sistemului existent în
lucru.

Modelele conceptuale locale trebuie să conţină:

 tipuri de entităţi,
 tipuri de relaţii,
 atribute,
 domeniile atributelor,
 cheile candidat,
 chei primare
Paşii din prima etapă a proiectării logice sunt:

 Pasul 1.1. Identificarea tipurilor de entităţi.

 Pasul 1.2. Identificarea tipurilor de relaţii.
 Pasul 1.3. Identificarea şi atribuirea de atribute la tipurile de entităţi şi
tipurile de relaţii.
 Pasul 1.4. Determinarea domeniilor de definiţie a atributelor.

44
  Pasul 1.5. Determinarea atributelor care compun cheile candidate şi
primare.
 Pasul 1.6. Specializare/generalizare (pas opţional).
 Pasul 1.7. Desenarea diagramei entity-relationship.
 Pasul 1.8. Verificarea modelului conceptual local cu ajutorul
utilizatorului.
Pasul 1.1. Identificarea tipurilor de entităţi

Obiectivul: Identificarea tipurilor de entităţi principale în vederile

utilizatorilor.

Primul pas în proiectarea bazei de date este identificarea entităţiilor din

datele furnizate de utilizatori. De exemplu, dacă avem informaţiile Nr_Mat,
Nr_Bloc, Scara, Etaj, Apartament şi Nume, putem identifica entitatea Locatari. În
general putem identifica entităţiile în mai multe moduri. De exemplu în locul
entităţii Locatari, am putea crea o entitate Locatari cu atributele Nr_Mat şi Nume,
iar celelelte informaţii în entitatea ProprietateLocatari.

Există cazuri când entităţiile sunt greu de identificat, pentru că modul de

prezentare a viitorilor utilizatori necesită explicaţii. Utilizatorii descriu aceste
entităţi, folosind sinonime şi omonime, ceea ce îngreunează identificarea
entităţilor. Sinonimele prin care se descrie aceaşi entitate, se pot considera
sinonime şi la crearea modelului logic, evidenţiind aceste sinonime ca diverse
aliasuri ai entităţiilor.

Documentarea tipurilor de entităţi

După identificarea entităţiilor, le dăm câte un nume, iar aceste nume le vom
evidenţia în dicţionarul de date, împreună cu explicaţiile despre entităţi, precum şi
posibilele aliasuri.

Pasul 1.2. Identificarea tipurilor de relaţii

Obiectivul: Identificarea relaţiilor importante dintre entităţi.

45
 După identificarea entităţiilor, va trebui să identificăm şi relaţiile importante
dintre aceste entităţi. Releţiile se descriu printr-un verb al relaţiei. De exemplu:

 Scările sunt Locuite de Locatari

 Furnizorii Provoacă Cheltuieli
La identificarea relaţiilor vom lua în considerare doar relaţiile care ne
interesează. Degeaba există şi alte relaţii care să se poată identificate, dacă nu
prezintă importanţă pentru problema noastră, atunci nu le luăm în consideraţie.

În cele mai multe din cazuri, relaţiile sunt binare, adică se realizează întrea
exact două entităţi. Există şi relaţii mai complexe, care se realizează între mai
multe entităţi, sau relaţii recursive, care pune în relaţie o singură entitate cu ea
însăşi.

Determinarea cardinalităţii şi a participării la tipurile de relaţii

După identificarea tipurilor de relaţii, trebuie să determinăm cardinalitatea

lor, alegând dintre posibilităţiile: unu-la-unu (1:1), unu-la-multe (1:M), sau multe-
la-multe (M:N). Dacă se cunosc valori specifice ale cardinalităţiilor, aceste valori
se scriu la documentarea relaţiilor. În continuare determinăm şi participarea la
relaţie, care poate fii totală, sau parţială.

Documentarea tipurilor de relaţii

După identificarea tipurilor de relaţii, le denumim şi le introducem în

dicţionarul de date, împreună cu cardinalitatea şi participarea lor.

Utilizarea modelării ER

Pentru vizualizarea sistemelor complicate, utilizăm diagrama ER, pentru că

este mult mai uşor de a cuprinde toate informaţiile. Vă propunem ca să utilizaţi
întotdeauna diagrama ER, pentru o mai bună vizualizare a datelor.

Pasul 1.3. Identificarea şi asocierea de atribute la tipurile de entităţi şi

tipurile de relaţii
46
 Obiectivul: Asocierea de atribute la tipurile de entităţi şi la tipurile de relaţii.

Următorul pas în metodologie este identificarea atributelor. Aceste atribute

se identifică în aceeaşi mod ca şi entităţiile. Pentru o mai uşoară identificare,
trebuie să luăm entităţiile şi relaţiile ca rând şi să ne punem următoarea întrebare:
Ce informaţii deţinem despre această … ? Răspunsul la această întrebare ne va da
atributele căutate.

Atribute simple sau compuse

Este important să notăm dacă un atribut este simplu sau compus. Conform
acestei informaţii va trebui să luăm decizii referitoare la acel atribut. Dacă un
atribut este compus, atunci putem opta pentru descompunerea sa, dacă este
necesară prelucrarea separată a detelor compuse, sau putem să-l lăsăm compus în
caz contrar.

De exemplu, atributul Adresă conţine informaţiile (Nr_Bloc, Scara, Etaj,

Apartament). Noi va trebui să prelucrăm aceste informaţii separat, deci vom
descompune acest atribut în cele patru atribute simple.

Putem avea cazuri în care atributele simple să le compunem. De exemplu, în

cazul atributelor Nume_Familie şi Prenume, neavând nevoie de aceste informaţii
separat, le vom compune în atributul Nume.

Atribute derivate (calculate)

Sunt acele atribute, care se pot calcula din alte atribute existente în baza de
date. De exemplu numărul locatarilor de pe o scară se poate număra în tipul de
entitate Locatari. Deci acest atribut este atribut derivat.

În general aceste atribute nu trebuie incluse în modelul de date, pentru că în

cazul în care se modifică atributul din care se calculează atributul derivat, trebuie
să se modifice şi acesta. În cazul în care nu se modifică, baza de date devine

47
inconsistentă. De aceea este important de a menţiona dacă un atribut este sau nu
derivat.

Dacă identificăm un atribut care să nu-l putem asocia nici unei entităţi sau
relaţii, ne întoarcem la paşii anteriori, identificând noua relaţie sau entitate la care
să asociem atributul respectiv.

În cazul în care putem asocia acelaşi atribut la mai multe entităţi, atunci va
trebui să decidem dacă generalizăm sau nu aceste entităţi, proces care este descris
la pasul 1.6.

Documentarea atributelor

După identificarea atributelor, le asociem un nume, şi le înregistrăm în

dicţionarul de date, împreună cu următoarele informaţii:

 numele şi descrierea atributului,

 toate aliasurile şi sinonimele prin care este cunoscut atributul,
 tipul de date şi lungimea,
 valorile iniţiale ale atributelor (dacă există),
 dacă atributul acceptă sau nu valoarea nulă,
 dacă atributul este sau nu compus, şi dacă este atunci atributele simple
care îl compun,
 dacă atributul este sau nu derivat şi atributul din care derivă,
 dacă atributul acceptă sau nu mai multe valori.
Pasul 1.4. Determinarea domeniului atributelor

Obiectivul: Determinarea domeniului atributelor în modelul conceptual

local.

Domeniul atributului este o mulţime de valori pe care o poate lua. Pentru a

controla în totalitate domeniul atributelor, se poate evidenţia următoarele:

 setul de valori admisibile pentru un atribut,

48
  operaţiile admisibile asupra unui atribut,
 ce atribute se pot compara cu atributul respectiv, în combinaţiile cu
alte atribute,
 mărimea şi formatul câmpului atributului.
Documentarea domeniilor atributelor

Actualizăm dicţionarul de date cu domeniul de definiţie al fiecărui atribut.

Pasul 1.5. Determinarea atributelor care compun cheile candidat şi primare

Obiectivul: Identificarea cheilor candidat pentru fiecare entitate şi alegerea

cheilor primare în cazul în care sunt mai multe chei candidat.

Identificarea cheilor şi selectarea cheilor primare

O cheie candidat este un atribut, sau un grup de atribute care identifică unic
fiecare înregistrare din tipul de entitate. Putem identifica una, sau mai multe chei
candidat. În acest caz trebuie să alegem dintre ele o cheie primară. Cheile candidat
care nu sunt primare, se vor numi chei alternante. Pentru alegerea unei chei ca fiind
cheie primară, vom ţine cont de următoarele:

 cheia candidat, care are un număr minim de atribute,

 cheia candidat, care îşi va schimba cel mai rar valoarea,
 cheia candidat, care este cel mai puţin probabil să sufere modificări în
viitor,
 cheia candidat, care este compusă din cele mai puţine caractere (în
cazul atributelor de tip caracter),
 cheia candidat, care este cel mai uşor de folosit din punctul de vedere
al utilizatorului.
Prin procesul de identificare a cheilor primare, deducem şi dacă o
entitate este entitate “tare”, sau entitate “slabă”. Dacă reuşim să identificăm o cheie
primară, atunci entitatea este tare, altfel este slabă. O entitate slabă nu poate exista

49
fără o entitate tare, care să-i fie “părinte”. Cheia primară a entităţii slabe este
derivată parţial sau total din cheia primară a entităţii tari.

Documentarea cheilor primare şi alternante

Înscriem cheile primare şi pe cele alternante în dicţionarul de date.

Pasul 1.6. Specializarea/generalizarea tipurilor de entităţi (pas

opţional)

Obiectivul: Identificarea entităţiilor subclasă respectiv superclasă,

între entităţiile apropiate.

În acest pas putem opta pentru a continua modelarea ER, folosind

procesul de generalizare sau specializare. Dacă alegem procesul de specializare,
vom încerca să definim una, sau mai multe subclase ale entităţii respective. Dacă
însă alegem procesul de generalizare, vom căuta superclase pentru acea entitate.

Un exemplu pentru procesul de generalizare ar fii entităţiile

Şef_de_scară şi Familii. Ambele entităţi au atribuite următoarele atribute: Nr_mat,
Nr_bloc, Scara, Etaj, Apartament şi Nume. Pe lângă aceste atribute, entitatea
Şef_de_scară mai are asociate atributul Data_intrare_func; iar entitatea Familii,
atributele Nr_pers, Nr_pers_prezente şi Nr_chei. Deci, cele două entităţi având
atribute în comun, le putem generaliza în entitatea Locatari, care va conţine
atributele comune, şi entităţile Şef_de_scară şi Familii, conţinând doar atributele
diferite - particularizările faţă de superclasă.

Pasul 1.7. Desenarea diagramei ER.

Obiectivul: Desenarea unei diagrame ER, care va fi reprezentarea

conceptuală a vederilor utilizatorilor despre întreprindere.

În momentul acesta suntem în măsură să prezentăm o giagramă

completă a modelului bazat pe vederile utilizatorilor despre întreprindere.

50
 Pasul 1.8. Verificarea modelului conceptual local cu ajutorul
utilizatorului

Obiectivul: Verificarea modelului conceptual local cu ajutorul

utilizatorului, pentru a vedea dacă modelul este o reprezentare adevărată a vederii
utilizatorului despre întreprindere.

Înainte de a termina pasul 1, trebuie verificat modelul conceptual

elaborat. Acest model include diagrama ER şi documentaţia anexată. În cazul în
care apare orice fel de anomalie, repetăm procesul de mai înainte şi remediem
problema.

Pasul 2. Crearea şi validarea modelului logic local

Obiectivul: Crearea unui model logic local bazată pe modelul

conceptual al utilizatorilor asupra întreprinderii şi validarea ei prin procesul de
normalizare şi prin tehnica tranzacţiilor cerute.

În acest pas verificăm modelul conceptual creat în pasul anterior şi

eliminăm din el structurile care sunt dificil de realizat într-un SGBD. Activităţile
din acest pas sunt:

 Pasul 2.1. Proiectarea modelului conceptual local pe un model logic

local.
 Pasul 2.2. Crearea relaţiilor pentru modelul logic local.
 Pasul 2.3. Validarea modelului, utilizând normalizarea.
 Pasul 2.2. Validarea modelului din nou, utilizând tranzacţiile.
 Pasul 2.5. Desenarea diagramei ER.
 Pasul 2.6. Definirea regulilor de integritate ale bazei de date.
 Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului.
Pasul 3. Crearea şi validarea modelului global logic de date.

51
 Obiectivul: Combinarea modelelor locale logice într-un model logic
global.

A treia activitate majoră în proiectarea bazei de date logice este

crearea modelului logic global, prin compunerea tuturor modelelor locale. După
combinarea modelelor locale, trebuie validat modelul global prin tehnica de
normalizare şi după aceea, prin tehnica tranzacţiilor.

Acest proces este foarte important în proiectarea bazei de date, pentru

că el demonstrează că reprezentarea întreprinderii este independentă de orice
utilizator, funcţie sau aplicaţie. Activităţile din acest pas sunt:

 Pasul 3.1. Compunerea modelelor logice locale într-un model logic

global.
 Pasul 3.2. Validarea modelului logic global.
 Pasul 3.3. Verificarea posibilităţii de a completa baza de date în viitor.
 Pasul 3.2. Desenarea diagramei ER finale.
 Pasul 3.5. Verificarea modelului logic global cu ajutorul utilizatorului.

4.4. Proiectarea logică a bazei de date - Exemplu

În acest capitol vom învăţa despre:

 Cum să folosim metodologia de proiectare a bazelor de date

relaţionele.
 Cum să folosim această metodologie pentru proiectarea bazei de date
a sistemului ‘Asociaţie de locatari’.

Cerinţele utilizatorilor.
Analiza şi colectarea datelor îl vom începe la o asociaţie de locatari. Aici
trebuie să cerem informaţiile necesare pentru realizarea sistemului. Trebuie să
colectăm informaţiile despre lucrul de zi cu zi a şefului asociaţiei de locatari. Vom
mai avea nevoie de toate rapoartele pe care ei le întocmesc. Toate informaţiile

52
despre sistemul de evidenţă a asociaţiei de locatari se pot împărţi în mai multe
view-uri. Aceste view-uri sunt:

 Evidenţa locatarilor şi a apartamentelor din asociaţie,

 Evidenţa cheltuielilor locatarilor,
 Evidenţa personalului asociaţiei,
 Evidenţa obiectelor de inventar şi a mijloacelor fixe,
 Plata datoriilor asociaţiei către furnizori”.
Cerinţele la baza de date.

Evidenţa locatarilor şi a apartamentelor din asociaţie:

(1) În baza de date vor fi memorate toţi locatarii asociaţiei de locatari.
Informaţiile necesare despre locatari sunt: adresa (număr bloc, scara, etajul şi
apartamentul) şi numele. Ei vor fi unic determinaţi de un număr matricol unic pe
toată asociaţia de locatari.
(2) Dintre locatari trebuie să evidenţiem pentru fiecare familie câte un
reprezentant. Pentru fiecare familie trebuie să avem la dispoziţie informaţiile:
numărul membrilor de familie, numărul persoanelor prezente în locuinţă în luna
curentă şi numărul de chei de la uşa principală.
(3) Tot dintre locatari se alege câte un şef de scară pentru fiecare scară din
asociaţie. Şef de scară trebuie să fie exact unul pe fiecare scară şi trebuie să
locuiască în scara pentru care s-a ales. Pentru şeful de scară mai avem în plus
informaţia: data intrării în funcţie.
(4) La evidenţa clădirilor din asociaţia de locatari, avem de memorat
scările care aparţin asociaţiei. Scările sunt identificate unic prin numărul blocului şi
litera scării. Mai trebuie să ştim despre fiecare scară dacă are lift.
(5) Pe fiecare scară avem mai multe apartamente. Despre apartamente
trebuie să memorăm informaţiile următoare: nr. apartamentului, suprafaţa, numărul
de cutii poştale şi numărul de prize tv.

Evidenţa cheltuielilor locatarilor

53
 (1) Fiecare cheltuială se înregistrează în momentul primilii facturii de la
furnizor. Cheltuielile sunt identificate unic printr-un număr de ordine care este
continuu pe un an. Pentru fiecare cheltuială se înregistrează informaţiile: codul
cheltuielii, codul furnizorului, numărul şi data facturii, valoarea facturii.
(2) Cheltuielile se pot referii la o singură scară sau la mai multe scări, sau
se pot referi la o singură familie sau mai multe familii.
(3) Pentru fiecare familie se înregistrează lunar valoarea ce trebuie plătită
asociaţiei. Dacă este cazul, se înregistrează şi restanţele.
(4) Când o familie îşi achită datoria la asociaţie, se emite o chitanţă, care
trebuie să conţină informaţii despre valoarea plătită, data plăţii şi numele persoanei
care a făcut plata. Chitanţa se identifică unic prin numărul său.
(5) Pentru a efectua mai uşor înregistrarea cheltuielilor, memorăm şi
datele despre furnizori. Aceste date sunt: denumirea, codul fiscal, contul bancar şi
banca, adresa (strada, numărul, bl., sc., ap., localitatea şi judeţul). Furnizorii se pot
identifica unic printr-un cod intern - cod furnizor.
(6) Pe lângă cheltuielile către furnizori există şi cheltuieli, care trebuiesc
plătite de locatari, dar care rămân la asociaţie. Astfel de cheltuială este fondul de
rulment, fondul de reparaţii, sau dacă este cazul, şi alte fonduri. Aceste cheltuieli
se vor înregistra în acelaşi mod ca şi celelalte, cu diferenţa că aici se va introduce
un “furnizor” special pregătit.
(7) Fiecare familie trebuie să aibă plătită o sumă la asociaţia de locatari
pentru fondul de rulment. În cazuri speciale se adună bani şi pentru fondul de
reparaţii, sau alte fonduri.

Evidenţa personalului asociaţiei.

(1) Personalul asociaţiei se va memora în baza de date, identificarea
făcându-se după un număr matricol unic. Mai folosim informaţiile: numele, data
naşterii, meseria, data angajării şi scările din asociaţie unde lucrează.
(2) Un angajat poate să lucreze în mai multe scări şi pe o scară pot să
lucreze mai mulţi angajati.

54
 Evidenţa mijloacelor fixe şi a obiectelor de inventar.
(1) Mijloacele fixe şi obiectele de inventar se vor identifica unic, cu
ajutorul unui cod numit numar de inventar. Pentru aceste obiecte mai reţinem
următoarele informaţii: numele, valoarea şi locul unde este amplasat.

Plata datoriilor asociaţiei către furnizori.

(1) O factură sosită de la un furnizor se poate achita prin casă, sau prin
ordin de plată. Pentru aceste achitări reţinem informaţiile: valoarea achitată, data
achitării şi numărul urdinului de plată sau a chitanţei.
Tranzacţiile cerute.

Evidenţa locatarilor şi a apartamentelor din asociaţie:

(1) Listă cu locatarii de pe o scară,
(2) Listă cu familiile de pe o scară,
(3) Listă cu şefii de scară,
(4) Listă cu proprietăţile apartamentelor ocupate pe o scară.

Evidenţa cheltuielilor locatarilor

(1) Listă cu cheltuielile fiecărei familii pe scări,
(2) Listă cu toate cheltuielile asociaţiei de locatari.
(3) Chitanţa care se emite la fiecare plată.

Evidenţa personalului asociaţiei.

(1) Listă cu personalul asociaţiei.

Evidenţa mijloacelor fixe şi a obiectelor de inventar.

(1) Listă cu mijloacele fixe şi valoarea lor, din asociaţia de loacatari,
(2) Listă cu obiectele de inventar ai asociaţiei de locatari.

Plata datoriilor asociaţiei către furnizori.

(1) Listă cu facturile scadente primite de la furnizori,
(2) Situaţia plăţilor facturilor de la furnizori, înglobând facturile dintr-o
perioadă dată, împreună cu modul lor de plată.

Proiectarea a bazelor de date relaţionale.

55
 Pasul 1. Crearea modelelor conceptuale locale, bazate pe view-urile
utilizatorilor:

Înainte să ne apucăm de crearea modelului conceptual local, să ne reamintim

din ce se compune acest model:

 tipuri de entităţi,
 tipuri de relaţii,
 atribute,
 domeniile atributelor,
 chei candidat,
 chei primare.

Pasul 1.1. Identificarea tipurilor de entităţi.

Începem să identificăm tipurile de entităţi din toate vederile utilizatorilor.

Vom descrie separat identificarea acestor entităţi pentru cele două vederi.

În cazul evidenţei locatarilor şi al apartamentelor, tipurile de entităţi sunt:

Locatari Scări

Şef de scară Apartamente

Familii

În cazul evidenţei plăţilor tipurile de entităţi sunt:

Cheltuieli Furnizori

Plăţi Chitanţe

Familii Scări

Documentarea tipurilor de entităţi

Pasul 1.2. Identificarea tipurilor de relaţii.

56
 În continuare identificăm tipurile de relaţii. Tipurile de relaţii se reprezintă
prin verbe ale relaţiilor. Tipurile de relaţii din cele două view-uri sunt prezentate în
tabelele de mai jos:

Tipuri de relaţii din view-ul “Locatari”:

Tip de entitate Tip de relaţie Tip de entitate

Scări sunt locuite de Locatari

sunt locuite de Familii

sunt conduse de Şef de scară

se compun din Apartamente

Tipuri de relaţii din view-ul “Cheltuieli”:

Tip de entitate Tip de relaţie Tip de entitate

Furnizorii provoacă Cheltuieli

Celtuieli sunt plătite de Familii

sunt plătite de Scări

Familii trebuie să plătească Plăţi

primesc Chitanţe

Determinarea cardinalităţii şi a participării pentru tipurile de relaţii.

În contunuare vom determina cardinalul şi participarea relaţiilor prezentate

în tabelele de mai sus. Cardinalul poate să fie unul dentre următoarele: unu-la-unu
(1:1), unu-la-multe (1:M), sau multe-la-multe (M:N). Participarea poate să fie
parţială sau totală.

Să luăm de exemplu relaţia dintre Scări şi Locatari. Pentru a fi foarte siguri

de cardinalul relaţiei, vom pune următoarea întrebare:

57
 Întrebare: Pot locui pe o scară mai mulţi locatari?

Răspuns: Da.

Deci relaţia Scările sunt locuite de Locatari are cardinalul 1:M. În

continuare va trebui să aflăm şi cardinalul relaţiei inverse, adică a relaţiei Locatarii
locuiesc în apartementele de pe Scări.

Întrebare: Un locatar poate locui în mai multe apartamente de pe scări

diferite?

Răspuns : Nu.

La această întrebare avem nevoie de o explicaţie: Dacă o persoană are două

locuinţe în aceaşi asociaţie de locatari, atunci el va apare în entitatea locatari de
două ori, cu număr matricol diferit. Deci un număr matricol poate să locuiască doar
într-un singur apartament.

Deci cardinalul acestei relaţii este de 1:1, de unde rezultă că relaţia iniţială
are cardinalul 1:M.

Pentru a afla participarea entităţilor la relaţie, punem următoarele întrebări:

Întrebare: Fiecare scară este locuită de cel puţin un locatar?

Răspuns : Nu.

Întrebare: Fiecare locatar locuieşte într-unul din aceste scări?

Răspuns: Da.

Deci tipul de entitate scări partcipă parţial, iar tipul de entitate Locatari
participă total la relaţie.

Fie relaţia Cheltuieli sunt plătite de Scări, din view-ul “Cheltuieli”. Să

determinăm cardinalul şi participarea ei:

Întrebare: Există cheltuială care se referă la mai multe scări?

58
 Răspuns : Da.

Întrebare: Scările pot avea mai multe cheltuieli?

Răspuns : Da.

Întrebare: Fiecare cheltuială trebuie să fie asociată unei scări?

Răspuns : Nu, pentru că poate fi asociată doar unor familii.

Întrebare: Fiecare scară trebuie să aibă cheltuieli?

Răspuns : Nu, pentru că pot fi scări fără locatari.

După aceste întrebări şi răspunsuri, am ajuns la concluzia că relaţia are

cardinalul N:M (ambele relaţii - şi cea directă şi cea inversă - au cardinalul 1:M),
iar participarea parţială de ambele părţi.

Utilizarea modelării ER.

Pentru o înţelegere mai uşoară a relaţiilor dintre entităţi, se poate folosi

diagrama ER.

Menţionăm, că verbele care reprezintă relaţiile de cardinal 1:M se pun în

direcţia unu-la-multe. În cazul în care relaţia a fost altfel evidenţiată, ea va fi
redenumită.

Diagrama ER. a view-ului “Locatari”.

59
 Diagrama ER a view-ului “Cheltuieli”

Pasul 1.3. Identificarea şi asocierea atributelor la tipurile de relaţii şi

tipurile de entităţi.

În acest pas identificăm atributele ce se asociază tipurilor de entităţi sau

tipurilor de relaţii. Atributele sunt informaţii care caracterizează entităţile,
resoective relaţiile. Aceste atribute le putem găsi în descrierea acordată de
utilizatori.

Tabela. Atributele tipurilor de entităţi din view-ul “Locatari”:

Tip de entitate Atribute

Locatari Nr_Mat
Adresa (Nr_bloc, Scara, Etaj, Apartament)
Nume
Familii Nr_Mat
Adresa (Nr_bloc, Scara, Etaj, Apartament)
Nume
Nr_pers
Nr_pers_prez
Nr_chei
Sef_Scara Nr_Mat
Adresa (Nr_bloc, Scara, Etaj, Apartament)
Nume
Data_intrare_func
Scări Adresa (Nr_bloc, Scara)
Lift
Apartamente Apartament
Suprafaţa
Cutii_poştale
60
 Nr_prize_tv
Tabela. Atributele tipurilor de entităţi din view-ul “Cheltuieli”:

Tip de entitate Atribute

Familii Nr_mat
Fond_rulment
Fond_reparaţii
Alte_fonduri
Plăţi Data
Valoare
Restanţă
Chitanţe Nr_Chit
Valoare
Data
Cheltuieli Nr_crt
Cod_cheltuiala
Nr_factura
Data_factura
Valoare
Furnizori Cod_furnizor
Denumire
Cod_fiscal
Cont
Banca
Adresa (Strada,Nr.Bl.,Sc., Ap., Localitate)

Documentarea atributelor:

Pentru documentaţie se descrie fiecare atribut, se menţionează tipul de date

folosit precum şi lungimea câmpului, reguli, valoarea implicită, toate aliasurile lui,
dacă atributul este sau nu compus, dacă este derivat sau nu, dacă admite mai multe
valori şi dacă admite valoarea nulă.

Pasul 1.2. Determinarea domeniilor atributelor:

În acest pas determinăm domeniile atributelor. Domeniul unui atribut este

nulţimea acelor valori, pe care le poate lua în lucrul de zi cu zi.

Pasul 1.5. Determinarea atributelor care aparţin cheilor candidat şi

primare:

61
 Acum vom examina tabelele şi vom căuta cheile candidat pentru entităţile în
cauză. Dintre aceste chei candidat vom selecta cheia primară.

Documentarea cheilor primare şi alternante.

Documentăm atributele care compun cheile primare şi cheile alternante.

Pasul 1.6. Specializarea/generalizarea tipurilor de entităţi (pas opţional).

În acest pas putem dezvolta modelul ER, utilizând procesul de

specializare/generalizare asupra entităţilor identifcate în pasul 1.1. Dacă vrem să
folosim procesul de specializare, vom căuta diferenţele dintre entităţi, iar în cazul
procesului de generalizare, asemănările dintre ele.

De exemplu, în view-ul “Locatari”, entităţile Locatari, Familii şi Şef_scară

au atributele Nr_mat, Adresa şi Nume în comun. Entitatea Familii mai are în plus
atributele Nr_pers, Nr_pers_prez şi Nr_chei iar entitatea Şef_scară are în plus doar
atributul Data_intreare_func. Entitatea Locatari are asociate doar atributele comune
cu cele două entităţi. Deci putem generaliza entităţile Familii şi Şef_scară, punând
pe post de superclasă entitatea Locatari, iar celelalte două fiind subclase. Relaţia
superclasă-subclasă dintre entitatea Locatari şi Familii respectiv Şef_scară este o
relaţie parţială şi nondisjunctă, pentru că în Locatari sunt toţi locatarii asociaţiei,
deci şi acelea care nu sunt nici capi de familie şi nici şefi de scară iar pe de altă
parte, şeful de scară poate să fie şi cap de familie.

Pasul 1.7. Desenarea modelului ER.

62
 Pentru o mai bună înţelegere a modelului local creat, folosim diagrama ER.
Această diagramă şi documentaţia creată se referă la modelul local conceptual.

Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului.

Înainte de a termina pasul 1, trebuie verificat modelul la care s-a ajuns. Dacă
se descoperă erori, atunci ne întoarcem la pasurile anterioare şi le remediem. Vom
repeta aceşti paşi până când modelul creat va fi în conformitate cu realitatea.

Pentru fiecare entitate tare a modelului, creăm o relaţie care include toate
atributele simple ale entităţii. Structura entităţii Furnizori este:

Furnizori (Cod_furnizor, Denumire, Cod_fiscal, Cont, Banca, Str., Bl., Sc.,

Ap., Loc., Jud.)

Cheie primară: Cod_furnizor

Pentru fiecare entitate slabă, descriem relaţia, incluzând atributele simple ale
entităţii, specificând cheia străină şi entitatea la care se referă această cheie străină.
Structura entităţii Cheltuieli este:

Cheltuieli (Nr_crt, Cod_furnizor, Cod_cheltuială, Nr_factură, Data_factură,

Valoare)

Cheie primară: Nr_crt

Cheie străină : Cod_furnizor

Acest proces continuă, până când se vor prelucra toade relaţiile din baza de
date.
63
 Validarea modelului prin normalizare.

În acest pas validăm baza de date prin normalizare.

 Forma Normală Unu (1NF), eliminarea repetiţiilor din atribute.

 Forma Normală Doi (2NF), eliminarea dependenţelor parţiale de cheia
primară.
 Forma Normală Trei (3NF), eliminarea dependenţelor tranzitive de
cheia primară.
 Forma Normală Boyce-Codd (BCNF), eliminarea anomaliilor care au
mai rămas.
Trebuie să analizăm fiecare relaţie. Verificăm dacă relaţiile sunt în forma
normală Boyce-Codd.

Pentru a exemplifica acest proces, să analizăm relaţia Furnizori.

Furnizori (Cod_furnizor, Denumire, Cod_fiscal, Cont, Banca, Str, Nr, Bl,

Sc, Ap, Loc, )

Cheie primară: Cod_furnizor

Cheie alternantă: Cod_fiscal

Cod_furnizor  Denumire, Cod_fiscal, Cont, Banca, Str, Nr, Bl, Sc, Ap,
Loc

Cod_fiscal  Cod_furnizor, Denumire, Cont, Banca, Str, Nr, Bl, Sc, Ap,
Loc

Cheltuieli (Nr_crt, Cod_furnizor, Cod_cheltuială, Nr_factură, Data_factură,

Valoare)

Cheie primară: Nr_crt

Nr_crt  Cod_furnizor, Cod_cheltuială, Nr_factură, Data_factură, Valoare

Pentru acest exemplu avem următoarele demonstraţii:

64
  Nu există grupuri repetitive în niciunul dintre entităţi. Deci relaţia este
în forma normală unu.
 Fiecare cheie se compune dintr-un singur atribut. De aceea nu putem
avea dependenţă parţială de cheie. Deci relaţia este în formă normală doi.
 Nu există dependenţe tranzitive de cheie, deci relaţia este în formă
normală trei.
 Fiecare determinant evidenţiat este cheie, deci relaţia este în formă
normală Boyce-Codd.
Acest proces se continuă pentru fiecare relaţie.

Diagrama globală şi finală ER.

65
Capitolul 5. Securitate şi integritate
5.1. Integritate
Integritatea bazelor de date se refera la corectitudinea informaţiilor şi
presupune detectarea, corectarea şi prevenirea diferitelor erori care pot afecta
datele introduse în bazele de date. Cand facem referiri la integritatea datelor,
întelegem că datele sunt consistente relativ la toate restrictiile formulate anterior
(care se aplica datelor respective) şi ca urmare a acestui fapt, datele sunt
considerate valide.
Conditiile de integritate numite şi reguli sau restrictii de integritate nu permit
introducerea in baza de date a unor date aberante şi sunt exprimate prin conditii
puse asupra datelor.
In general sunt acceptate mai multe criterii de clasificare a regulilor de
integritate.
O serie de conditii sunt de tip structural, legate de anumite egalitati intre
valori, şi exprimate prin dependente functionale sau prin declararea unor campuri
cu valori unice (de cele mai multe ori aceste campuri sunt chei).
O alta serie de conditii se clasifica dupa unitatea la care se aplica restrictia si,
in acest caz, exista restrictii pe domenii (ce privesc anumite valori pentru atribute)
sau restrictii pe tabele (relatii). Restrictiile pe tabele pot fi unituplu (se refera la
fiecare tuplu in parte) sau multituplu (se refera la combinatii de mai multe tupluri).
O restrictie de integritate de relatie unituplu impune ca in fiecare tuplu al
unei relatii de baza, in campurile corespunzatoare cheii primare, se apara valori
diferite de valorile nule corespunzatoare. Aceasta regula se mai poate enunta şi sub
forma: "intr-o baza de date relaţionala nu se inregistreaza nici o informatie despre
ceva ce nu poate fi identificat."
Un exemplu de restrictie de integritate de relatie de tip multituplu este
restrictia referentiala care se exprima prin conditia ca, pentru cheile externe, daca
nu sunt nule, sa se admita valori corespunzatoare uneia din cheile primare existente

66
in relatia referita. Verificarea acestei conditii are loc de cate ori se insereaza un nou
tuplu ce contine o cheie externa sau se modifica valoarea unei chei externe a unui
tuplu, semnalandu-se eventualele neconcordante şi anuland modificarile.
Verificarea unicitatii cheii primare şi restrictiile rezultate din dependentele
functionale şi multivaloare sunt alte exemple de acelasi tip.
Un alt criteriu de clasificare este acela prin care se deosebesc regulile de
integritate ce se refera la diferitele stari ale bazei de date de regulile ce se refera la
tranzitia dintr-o stare in alta.
Restrictiile pot fi clasificate şi din punct de vedere al momentului in care se
aplica ele, astfel avem reguli imediate (ce se verifica in momentul in care se
efectueaza operatia indicata) sau reguli amanate (ce se verifica numai dupa ce au
fost executate şi alte operatii asociate dar inainte de a se modifica baza de date).
In functie de aria de aplicare, restrictiile pot fi impartite in restrictii generale,
aplicabile tuturor relatiilor din baza de date şi restrictii particulare, care se pot
aplica numai la anumite relatii.
Regulile de integritate se aplica relatiilor de baza in care sunt reprezentate
efectiv datele bazei de date. Dintre regulile generale cel mai des folosite in modelul
relaţional sunt regulile ce privesc cheile primare şi cheile externe.
Analizam in continuare cateva tipuri de restrictii de integritate.
I. Restrictii pentru integritatea entitatii
Enunt: Intr-o relatie de baza nici un atribut al unei chei primare nu poate
avea valori nule.
Deja cunoastem ca se cere (in multe situatii) ca valorile cheilor primare sa
fie unice. In majoritatea SGBD unicitatea cheii primare şi integritatea entitatii sunt
conditii obligatorii.
II. Restrictii pentru integritatea referentiala
Enunt: Daca exista o cheie externa intr-o relatie, ori valoarea cheii externe
trebuie sa se potriveasca cu valoarea unei chei candidat a vreunui tuplu in relatia de
origine, ori valoarea cheii externe trebuie sa fie nula.

67
 Cu alte cuvinte, daca o valoare exista intr-o relatie pe post de cheie externa,
ori ea trebuie sa se potriveasca cu valoarea unei chei primare dintr-o alta relatie ori
sa fie nula.
III. Restrictiile de domeniu
Aceste restrictii sunt intotdeauna restrictii de stare imediate. Aceste restrictii
se pot referi la tipul de date pentru un atribut, la o lista de valori posibile, la un
ordin de marime, la un format sau o forma, la o conditie exprimata cu o formula
logica sau la o procedura care este apelata de cate ori are loc o modificare pentru
domeniul specificat.
Integritatea datelor este strans corelata cu securitatea datelor unei baze de
date.
Daca se definesc controalele de securitate in absenta celor de integritate,
validitatea şi consistenta datelor se bazeaza exclusiv pe utilizarea corecta şi de
buna credinta a sistemului de catre utilizatorii autorizati. Daca insa se definesc
numai controale de integritate, datele au sansa sa fie consistente dar sunt
susceptibile la pericolele care provin din lipsa securitatii.
Este important de mentionat aici ca restrictiile de integritate nu garanteaza
corectitudinea datelor. Aceasta deoarece este aproape imposibil (in multe situatii)
ca verificarea corectitudinii sa fie realizata automat.
Exemplu: Nu se poate verifica automat daca numele unei persoane este
"Pop" sau "Popa", cum nu se poate verifica automat daca data nasterii este
"10.01.2001" sau "01.01.2001", etc.
Pentru a asigura un grad multumitor de integritate a datelor trebuie prevazute
restrictii de integritate in asociere cu principalele momente in care datele
respective sunt manipulate, cum ar fi: introducerea, actualizarea şi stergerea.
Acestea sunt operatii susceptibile de introducerea de date inconsistente in baza de
date.
Asociata cu integritatea datelor este şi protectia datelor impotriva unor
evenimente de avarie cum ar fi caderea sistemului cauzata de defectarea unor
componente hardware sau software.
68
 Pierderea accidentala de consistenta a datelor poate rezulta din:
- incidente ce apar pe parcursul executarii tranzactiilor,
- anomalii datorate accesului concurent la baza de date,
- anomalii datorate lucrului cu date distribuite pe mai multe calculatoare intr-
o retea,
- erori logice care apar din programele utilizator, si altele.
Pentru reconstituirea bazelor de date in cazul cand pot sa apara inconsistente
in general, majoritatea bazelor de date se copiaza periodic pe medii magnetice ce
se pastreaza in locuri sigure. De asemenea se tine o evidenta a tuturor
transformarilor efectuate in baza de date de cand s-a efectuat ultima copie. Fisierul
care contine aceste modificari se numeste jurnal. Fiecare inregistrare din jurnal
contine un identificator al programului care a facut modificarea, fosta valoare şi
noua valoare introdusa pentru un element. Tot in jurnal se mai pastreaza diferitele
momente importante din desfasurarea programelor (inceput, sfarsit, terminarea
unor operatii, etc.).
Se spune despre o tranzactie ca este comisa daca au fost terminate toate
calculele produse de ea in aria de lucru şi s-a facut o copie a rezultatelor ei in
jurnal. Aparitia unor caderi dupa ce o tranzactie a fost comisa nu afecteaza
continutul bazei de date deoarece se poate reconstitui baza de date cu ajutorul
ultimei copii şi a jurnalului in care se gasesc toate rezultatele tranzactiilor comise.
Modificarile tranzactiilor abandonate sau necomise nu sunt luate in considerare la
parcurgerea jurnalului pentru restaurarea bazei de date.
Se defineste strategia de comitere in doua faze astfel: o tranzactie poate sa
scrie intr-o baza de date numai dupa ce a fost comisa şi o tranzactie poate fi comisa
numai dupa ce a inregistrat in jurnal toate schimbarile de elemente produse de ea.

5.2. Securitate
Prin securitatea bazelor de date se intelege protejarea bazelor de date
impotriva folosirii neautorizate a lor şi in special a modificarilor şi distrugerilor

69
nedorite de date şi a citirilor nepermise de date. Pentru realizarea securitatii datelor
din baza de date se utilizeaza controale tehnice şi administrative.
Securitatea este in general asociata cu urmatoarele situatii:
- acces fraudulos la date,
- pierderea confidentialitatii (secretului) datelor,
- pierderea caracterului privat al datelor,
- pierderea integritatii datelor,
- pierderea disponibilitatii datelor.
Este mai dificila protejarea datelor impotriva accesului rauvoitor, intentionat.
Se recunoaste ca de fapt nu exista protectie absolut sigura ci doar protectii şi
masuri de securitate mai eficiente sau mai putin eficiente.
Forme de acces intentionat şi rauvoitor la datele unei baze de date:
- citire neautorizata a unor date,
- modificari neutorizate de date,
- distrugeri de date.
Notiunea de securitate a bazei de date este de obicei asociata cu accesul
rauvoitor, pe cand integritatea se refera la evitarea pierdelor accidentale de
consistenta. Adevarul este insa undeva la mijloc.
Pentru protectia bazei de date se pot lua masuri de asigurare a securitatii la
mai multe nivele:
- la nivel fizic - locurile in care se afla calculatoarele trebuie protejate de
accesul persoanelor neautorizate;
- la nivel uman – este recomandabil sa se acorde autorizatiile de acces cu
multa grija şi sa se tina evidente stricte ale persoanelor autorizate
- la nivel sistem de operare – slabiciunile protectiei la nivel de sistem de
operare trebuie eliminate sau compensate de alte masuri
- la nivel SGBD – sistemul ofera anumite facilitati care sprijina protectia
datelor
Tehnici de asigurare a securitatii datelor:
1. Identificarea utilizatorilor.
70
 Fiecarui utilizator in parte i se acorda anumite drepturi de operare pe diferite
portiuni din baza de date la diferite nivele cum ar fi relatia, inregistrarea, pagina,
atributul, etc. Drepturile se refera la posibilitatea citirii, inserarii, stergerii sau
modificarii datelor respective. Identificarea se face de obicei prin parole stabilite
fie de administratorul bazei de date fie de utilizator.
2. Protejarea datelor prin codificare (criptare).
Deoarece s-ar putea ajunge la date şi prin alte mijloace decat prin
intermediul SGBD-ului (de exemplu prin citirea directa a mediului magnetic) se
poate face o protectie prin pastrarea codificata a datelor pe mediul magnetic.
Decodificarea datelor se poate face numai dupa identificarea utilizatorului prin
garzi asociate lui.
3. Utilizarea view-urilor in aplicaţii.
Abilitatea view-urilor de a "ascunde" o parte din informatiile din baza de
date poate fi utilizata şi pentru stabilirea unui anumit grad de securitate a datelor.
Astfel se poate vorbi de acces la nivel de relatie (tabela) sau acces la nivel de view.
In unele sisteme nu sunt acceptate modificari prin intermediul view-urilor.
Astfel de view-uri se numesc read-only (numai pentru citire) şi sunt utilizate mai
ales in aplicaţiile in care datele pot fi citite de toti utilizatorii (baze de date publice)
dar modificarile se fac numai cu aprobarea administratorului/proprietarului bazei
de date.
Modificarile din view-uri nu sunt in general admise deoarece pot duce la
efecte laterale ce privesc parti din baza de date ce nu apar in view-uri. De exemplu
stergerea unui element din view poate sa duca la eliminarea unui alt element care
are singura legatura cu elemntul sters şi care nu se afla in view.
4. Administrarea şi transmiterea drepturilor.
Se tine evidenta stricta a drepturilor de acces ale fiecarui utilizator la portiuni
din baza de date şi se fixeaza reguli de transmitere de la un utilizator la altul a
dreptului de acces.
Forme de autorizare:
- autorizare la citire (consultare)
71
 - autorizare la inserare (adaugare)
- autorizare la actualizare (care exclude stergerile)
- autorizare la stergeri (la nivel de tuplu)
In situatiile de mai sus nu se pune problema modificarilor la nivel de schema
a bazei de date.
Daca consideram şi acest aspect putem vorbi de:
- autorizare la nivel de index (creare-stergere de indexi)
- autorizare la nivel de relatii (creare)
- autorizare de modificari la nivel de relatii (stergeri sau adaugari de atribute
in cadrul relatiilor)
- autorizari de stergeri ale relatiilor
Diferitele protectii pot fi indicate prin intermediul limbajului de prelucrare a
datelor. Portiunile din baza de date ce pot fi folosite de utilizator pot fi definite prin
operatii de selectie şi proiectie care fac invizibile alte portiuni ale bazei de date.
Conducerea organizatiei, care este proprietara bazei de date, trebuie sa ia
masuri de securitate care reduc riscul de a se pierde informatii sau de a se distruge
informatii. Prin pierdere de informatii se poate intelege ca se pierde caracterul
privat al informatiilor, ele devin accesibile unui grup mai mare de persoane decat
cel prevazut. Nu intotdeauna "scurgerile" de informatii lasa urme, deci nu se
materializeaza intotdeauna in schimbari detectabile la nivelul bazei de date.
Problema securitatii cuprinde aspecte legale, sociale şi etice, aspecte privind
controlul fizic (paza şi posibilitati de blocarea accesului la terminale), aspecte de
politie (fixarea conditiilor de acces), aspecte operationale (modul de stabilire a
parolelor), aspecte privind controlul hard (modul de acces hard la diferite
componente), securitatea sistemului de operare (protejarea informatiilor şi anularea
rezultatelor intermediare pentru pastrarea secretului datelor) aspecte privind
notiunea de proprietate asupra datelor din baza de date şi altele asemanatoare.
Trebuie sa mentionam aici ca furturile şi fraudele nu sunt neaparat legate de
baza de date, ele sunt un factor de risc pentru intreaga organizatie, gravitatea
acestor fapte depinzand şi de profilul organizatiei in cauza.
72
Capitol 6. Limbajul SQL

Limbajul SQL (Structured Query Language) se bazează pe studiile lui E.F.

Codd, prima implementare a acestui limbaj datând din 1970. Lansat iniţial de IBM.
Standardizat prima dată de ANSI, apoi ISO.
SQL este în prezent, unul din cele mai puternice limbaje structurate pentru
interogarea bazelor de date relaţionale. SQL este un limbaj complet standardizat şi
se poate utiliza pentru a accesa baze de date Oracle, SQL Server, MySQL ş.a.
Primul standard SQL a fost creat in anul 1989 de cãtre ANSI fiind cunoscut
sub numele de ANSI-SQL'89 şi a fost revizuit in octombrie 1992 sub noua
denumire: ANSI-SQL'92.
In anul 1992, firma Microsoft, in calitate de membru SAG, a lansat pe piata
produsul ODBC (Open Database Connectivity), un standard API-SQL care
defineste o interfatã de programare a aplicaţiilor (API) pentru accesul la bazele de
date. Pe de alta parte, un alt membru SAG, firma Borland, a pregatit propriul sãu
standard API-SQL denumit IDAPI (Integrated Database Application
Programming Interface).

Instrucţiunile SQL pot fi grupate în:

 instrucţiuni de definire a datelor, care permit descrierea structurii BD
(DDL – Data Description Language)
 instrucţiuni de manipulate a datelor: adaugă, şterge, modifică
înregistrări (DML – Data Manipulating Language)
 instrucţiuni de selecţie a datelor, care permit consultarea BD (DQL –
Data Query Language)
 instrucţiuni de procesare a tranzacţiilor
 instrucţiuni de control al cursorului
 instrucţiuni pivind controlul accesului la date

73
 Scrierea comenzilor SQL
O instrucţiune SQL este formată din cuvinte rezervate şi cuvinte definite
de utilizator. Cuvintele rezervate constituie partea fixă şi se scriu exact cum este
necesar. Cuvintele definite de utilizator reprezintă denumirile diverselor obiecte
din BD.
Terminator de instrucţiune este „;”.
Identificatorii SQL sunt utilizaţi pentru a numi obiecte din BD. Pentru
caracterele utilizate, standardul ISO permite A...Z, a...z, 0...9, _. Restricţii impuse
identificatorilor:
• nu poate fi mai lung de 128 caractere
• trebuie să înceapă cu o literă
• nu poate conţine spaţii libere

6.1. Tipurile de date SQL

Există 6 tipuri de date scalare SQL definite în standardul ISO, prezentate în tabelul care urmează

Tipul de data Declaraţii

caracter CHAR, VARCHAR

bit BIT, BIT VARYING

exact numeric NUMERIC, DECIMAL, INTEGER, SMALLINT

aproximativnumeric FLOAT, REAL, DOUBLEPRECISION

data-timp DATE, TIME, TIMESTAMP

interval INTERVAL

74
6.2. Instrucţiuni pentru definirea datelor
CREATE TABLE nume_tabel
(câmp1 tip_dată [NOT NULL],
câmp2 tip_dată [NOT NULL],
câmp3 tip_dată [NOT NULL]...);
Crează un tabel şi defineşte structura unei înregistrări precum şi tipurile de
date asociate câmpurilor. Numele tabelului trebuie să fie unic în BD. Clauza NOT
NULL arată că în câmpul respectiv nu se memorează valori de tip NULL.
ALTER TABLE nume_tabel
ADD nume_câmp tip_dată
Adaugă un câmp la un tabel existent.
DROP TABLE nume_tabel
Şterge complet un tabel din BD.
Exemplu:
1. create table product(p_id number(4) not null, p_desc varchar(25) not
null, cost number(7,2), price number(7,2));
2. alter product add m_id number(4) not null;
3. drop table product;

6.3. Instrucţiuni pentru manipularea datelor

Foarte utile în exploatarea unei BD, aceste instrucţiuni se implementează
prin interogările de acţiune. Este necesară o mare precauţie în utilizarea lor
deoarece acţiunile sunt ireversibile, putând influienţa inclusiv integritatea
referenţială a BD.
Cele mai importante sunt: INSERT, UPDATE şi DELETE.
Interogările de acţiune tip INSERT sunt folosite pentru adăugarea de
înregistrări dintr-un tabel în altul. Există două forme ale instrucţiunii şi
anume:

a) INSERT ... VALUES

b) INSERT ... SELECT

75
 a). In primul caz se adaugă o singură înregistrare într-un tabel,
menţionându-se câmpurile şi valorile acestora. Se utilizează pentru operaţii simple,
care presupun lucrul cu un număr redus de înregistrări.
INSERT INTO nume_tabel (câmp1, câmp2...)
VALUES (valoare1, valoare2...);
Reguli:
• valorile din clauza VALUES vor avea aceeaşi natură cu câmpurile din clauza
INTO
• corespondenţă între câmp1 şi valoare1, etc.
• dacă un câmp are specificaţia NOT NULL, este obligatorie introducerea unei
valori pentru aceasta

b). În al doilea caz, este posibil să se copieze mai multe înregistrări dintr-
un tabel în unul sau mai multe tabele.
INSERT INTO tabel_destinaţie (câmp1, câmp2...)
SELECT câmp1, câmp2...
FROM tabel_sursă
WHERE criteriu_de_adăugare;
Reguli:
• numărul şi natura câmpurilor din clauza INTO să fie aceleaşi cu cele returnate
de instrucţiunea SELECT
• dacă nu se introduce WHERE, toate înregistrările din tabel_sursă vor fi
adăugate în tabel_destinaţie
Interogările de acţiune tip DELETE şterg parţial sau total înregistrările
dintr-un tabel. Nu se foloseşte pentru ştergerea de valori din câmpuri individuale,
ci acţionează asupra înregistrării în totalitatea ei. Dacă se şterg toate înregistrările,
structura de tabel rămâne, ea putând fi eliminată numai cu DROP TABLE.
DELETE FROM nume_tabel
[WHERE criteriu_de_ştergere];

76
 Ca şi instrucţiunea INSERT, operaţia de ştergere a înregistrărilor dintr-o
tabelă poate duce la probleme de integritate referenţială în alte tabele.
Interogările de acţiune tip UPDATE pot introduce înregistrări noi şi pot
modifica valorile câmpurilor din înregistrări existente.
UPDATE nume_tabel
SET nume_câmp1=valoare1 [,nume_câmp2=valoare2]...
[WHERE criteriu_de_actualizare];
Ca şi în celelalte locuri unde apare clauza WHERE, restricţionarea se poate
accentua folosind şi operatori logici.
Exemplu:
UPDATE Comunicaţii
SET Reţea=”Orange”
WHERE Reţea=”Dialog” AND Data>'12.12.2011';

6.4. Instrucţiune SELECT

O interogare SQL are urmatoarea forma generala:
SELECT [DISTINCT/ALL] <lista de atribute>
FROM <lista de relatii>
[WHERE <conditie> / GROUP BY< lista de atribute> /
HAVING <conditie> / ORDER BY <lista de atribute>
[ASC / DESC] / UNION <sub_interogare>]; ... ...
Dupã cum se observã, singurele elemente obligatorii intr-o interogare SQL
sunt clauzele SELECT cu lista de atribute ce vor fi extrase şi clauza FROM cu
relatiile din care fac parte atributele. Asadar o interogare SQL trebuie sa contina
cel putin urmatoarele informatii:
SELECT <lista de atribute>
FROM <lista de relatii>
Restul clauzelor sunt optionale.
Lista de atribute poate consta din :

77
  o serie de atribute separate prin virgulã care vor apãrea în tabela-
rezultat în ordinea explicitatã în linia de comandã, de la stanga la dreapta;
 toate atributele din relatia asupra careia se aplica interogarea, în
ordinea în care au fost definite în aceastã relatie (in locul acestei liste se poate
utiliza semnul "*");
 expresii formate din urmatoarele elemente:
- atribute şi operatori aritmetici (de exemplu: cantitate*pret_unitar)
- functii standard (de exemplu CONCAT( ));
- constante;
- variabile de memorie.
 expresii care contin functii SQL agregat cum ar fi AVG( ), MAX( ),
MIN( ), COUNT( ), SUM( ) ...
Optiunea DISTINCT permite eliminarea tuplelor duplicat. In acest mod
numai prima aparitie a unui tuplu este afisatã în tabela-rezultat.
Exemplu:
"Sa se afiseze toate orasele resedinte ale furnizorilor, dar sa apara fiecare
oras o singura data in tabela-rezultat"
SELECT DISTINCT oras
FROM furnizori;
Aceasta interogare va avea ca rezultat o tabela care contine toate orasele in
care isi au resedinta furnizorii din tabela FURNIZORI, dar fiecare oras va fi afisat
o singura data.
Optiunea ALL permite dimpotrivã, afisarea tuplelor-duplicat. Aceastã
optiune este implicitã.
Clauza FROM are forma generala:
FROM <<nume relatie>/ <nume view>[<alias>] ... >
si specifica relatiile (pot fi şi nume de view) din care vor fi regãsite datele. In cazul
în care se operazã cu mai multe tabele, este utilã atribuirea unor prescurtãri,
(numite alias) numelor de tabele ce vor fi utilizate în interogare.

78
 Exemple:
1) "Sa se afiseze codurile furnizorilor şi numerele de comanda
corespunzatoare pentru toti furnizorii care a cel putin o comanda"
SELECT 1.cod_furnizor, B.numar_comanda
FROM furnizori 1, comenzi B
WHERE 1.cod_furnizor=B.cod_furnizor;
2) "Sa se afiseze codurile furnizorilor, numele furnizorilor, cantitatile, şi
numerele comenzilor pentru toti furnizorii care au cel putin o comanda"
SELECT A.cod_furnizor, nume_furnizor, cantitate, numar_comanda
FROM furnizori A, comenzi B
WHERE A.cod_furnizor=B.cod_furnizor
A se observa ca in al doilea exemplu nu s-a mai utilizat notatia cu alias
pentru atributul numar_comanda din tabela comenzi deoarece nu este pericol de
confuzie. In schimb s-a utilizat notatia pentru a deosebi atributul cod_furnizor din
tabela furnizori de atributul cu acelasi nume din tabela comenzi.
Pentru a restrange tuplele ce apar în tabela-rezultat, se specificã o conditie de
cãutare prin utilizarea unui predicat de selectie in clauza WHERE.
Clauza WHERE are forma generala:
WHERE <predicat> / <expresie>;
Numai tuplele care satisfac predicatul de selectie vor fi incluse in tabela-
rezultat. Predicatul de cãutare poate fi specificat printr-o conditie logica in care se
utilizeaza urmatoarele elemente:
 operatori:
- aritmetici: + - / *
- relaţionali:< > <= >= <> != =
- logici: NOT AND OR
- operatori SQL: IN, EXISTS, ALL, ANY
 sub-interogãri (exprimate prin interogari SQL),cu observatia cã
acestea vor fi primele evaluate şi tabela-rezultat trebuie sã corespundã operatorilor
ce i se aplicã în continuare.
79
 Operatorii aritmetici
Ca operanzi, se pot utiliza atribute, constante, functii sau expresii algebrice.
Expresiile algebrice pot aparea in clauzele SELECT sau WHERE.
Exemplu:
"Sa se afiseze codul produsului şi valoarea pe care o reprezinta cantitatea
de produs comandata la diversi furnizori"
SELECT cod_produs, cantitate*pret_unitar
FROM comenzi
WHERE cantitate<>0;
Operatorii relaţionali
< mai mic
> mai mare
! negarea operatorilor <, >, =. Se obtin operatorii: !=(diferit), !<(nu mai
mic), !>(nu mai mare).
<= mai mic sau egal
=> mai mare sau egal
<> diferit
Facem observatia că valorile comparate trebuie să apartină unor tipuri de
date compatibile (care se pot compara intre ele).
Exemplu:
"Sa se afiseze codurile plantelor de culoare alba."
SELECT cod-produs
FROM flori
WHERE culoare='alb':
Operatorii logici
Dacã o clauzã WHERE contine mai multe conditii formate prin utilizarea
aceluiasi tip de oparator logic, evaluarea se va face de la stanga la dreapta. tipul de
operator logic este dat de precedenta operatorilor. Operatorul NOT are cea mai
mare prioritate, urmat de AND şi OR care practic sunt de prioritati egale.

80
 Pentru a schimba ordinea de evaluare a unei expresii se utilizeazã
parantezele rotunde ().
Exemple:
1) "Sa se afiseze numele plantelor de culoare alba şi de inaltime minima 50
cm"
SELECT nume_planta
FROM flori
WHERE culoare='alb' AND inaltime<50;
2) "Sa se afiseze numele, culoarea şi inaltimea plantelor care fie au
culoarea alba fie sunt de inaltime mai mica de 50 cm"
SELECT nume_planta, culoare, inaltime
FROM flori
WHERE culoare='alb' OR inaltime<50;
3) A se observa ca ultima interogare este echivalenta cu interogarea
SELECT nume_planta, culoare, inaltime
FROM flori
WHERE culoare='alb' OR NOT inaltime>=50;

6.5. Ordonarea tuplelor (clauza ORDER BY)

În exemplele anterioare, tuplele tabelei-rezultat apar în aceeasi ordine în care
au fost introduse. Pentru modificarea ordinii de afisare se utilizeazã clauza
ORDER BY. Forma generala a acestei clauze este:
ORDER BY <(<nume atribut>/<numãr întreg>)(ASC/ DESC)>,...
Tuplele sunt ordonate în mod implicit în ordine ascendentã (ASC). Ordinea
este: 0,...,9,A,...,Z,a,...,z conform codului ASCII. Afisarea în ordine descrescãtoare
se poate face prin utilizarea optiunii DESC.
Exemplu:
"Sa se afiseze datele despre florile din evidente in ordinea alfabetica a
numelor florilor."
SELECT *

81
 FROM flori
ORDER BY nume_planta ASC;
A se observa ca daca ar fi lipsit mentiunea ASC, ordinea tuplelor ar fi fost
aceeasi deoarece ordinea ascendenta este implicita.
În loc de precizarea numelui atributului dupã care se face ordonarea, se
poate preciza pozitia atributului în lista de atribute specificate în comanda
SELECT.
Exemplu:
SELECT oras, cod_furnizor, nume_furnizor
FROM furnizori
ORDER BY 1 DESC, 3 ASC;
In urma executiei interogarii se va obtine o tabela cu numele oraselor sortate
descrescator şi pentru fiecare oras, codurile furnizorilor şi apoi numele funizorilor
in ordine alfabetica.
Operatorul IN permite simplificarea predicatului de cãutare.Predicatul IN
testeazã dacã valoarea unui atribut specificat în lista de atribute din clauzaWHERE
se potriveste uneia din valorile listei specificate în predicatul IN (testeazã
apartenenta la o multime).
Exemplu:
"Sa se afiseze toate datele despre furnizorii care au sediul in Chisinau sau in
Balti sau in Calaras"
SELECT *
FROM furnizori
WHERE oras IN ('Chisinau', 'Balti', 'Calaras');
Functii standard
Functiile standard, cunoscute şi sub numele de functii agregat, apar in clauza
SELECT şi se aplica atributelor din tabelele implicate in interogare. Functii
standard sunt:
- valoarea medie - AVG
- valoarea minima - MIN
82
 - valoarea maxima - MAX
- total(sumare) - SUM
- numãrãtoare - COUNT
NOTA: Nu este permisa utilizarea acestor functii in clauza WHERE
deoarece ele actioneaza la nivel de atribut şi nu la nivel de tuplu.
Exemple:
1)"Care este cantitatea minima comandata?"
SELECT MIN(cantitate)
FROM comenzi;
Spre exemplu,urmãtoarea interogare are ca rezultat afisarea cantitãtii totale
şi a numãrului de produse din fisierul de comenzi.
SELECT SUM(cantitate), COUNT(*)
FROM comenzi;
2) "Care este cantitatea medie comandata?"
SELECT AVG(cantitate)
FROM comenzi;
3)"Care este cantitatea totala comandata din planta cu cod '202'?"
SELECT SUM(cantitate)
FROM comenzi
WHERE cod_produs='202';
4)"Cate tuple contine tabela de flori?"
SELECT COUNT(*)
FROM flori;
5)"Cate culori de flori sunt inregistrate pentru florile din fisier?"
SELECT COUNT(DISTINCT culoare)
FROM flori;

6.6. Gruparea rezultatelor (clauza GROUP BY)

În multe cazuri, utilizatorul doreste anumite situatii sintetice, cum ar fi
obtinerea de totaluri şi subtotaluri. Pentru aceaste operatii, limbajul SQL permite

83
utilizarea clauzelor GROUP BY şi HAVING. Aceste clauze organizeazã tuplele
în grupuri asupra cãrora se pot realiza anumite operatii, în special prin aplicarea
functiilor agregat.
Clauza GROUP BY grupeazã tuplele din relatie dupã atributele cu aceeasi
valoare care sunt specificate în clauzã, şi generezã un singur tuplu pentru fiecare
grup de tuple cu aceeasi valoare pe atribut.
Atributele care apar în clauza SELECT pot fi de douã feluri:
- atribute care alcãtuiesc baza pentru grupare (cele care apar în clauza
GROUP BY)
- atribute care nu participa la gruparea rezultatelor.
Exemplu:
1)"In ce orase exista furnizori ai florariei?"
SELECT oras
FROM furnizori
GROUP BY oras;
In urma executarii interogarii vor apare orasele din fisierul de furnizori
listate o singura data.
2)"Cati furnizori au sediul in fiecare oras?"
SELECT oras, COUNT(*)
FROM furnizori
GROUP BY oras;
3)"In care orase locuiesc cel putin 3 furnizori?"
SELECT oras, COUNT(*)
FROM furnizori
GROUP BY oras
HAVING COUNT(*)>=3;
Clauza GROUP BY se poate folosi şi cu clauzele ORDER BY şi WHERE.
Exemple:
1)"Sa se afiseze in ordine alfabetica orasele in care exista furnizori ai
florariei".
84
 SELECT oras
FROM furnizori
GROUP BY oras
ORDER BY oras;
2)"Care furnizori livreaza in interval de cel mult 17 zile?"
SELECT cod_furnizor
FROM comenzi
WHERE timp_livrare<17
GROUP BY cod_furnizor;

6.7. Interogari pe mai multe tabele

Una dintre operatiile cele mai frecvente realizate cu mai multe tabele este
jonctiunea sau produsul cartezian. Jonctiunea aminteste de operatiile din algebra
relaţionala şi chiar este posibil de realizat (urmand anumite structuri ale interogarii
SQL) oricare dintre tipurile de jonctiune prezentate teoretic in cadrul algebrei
relaţionale. Se pot de asemenea realiza operatii ca reuniunea, intersectia şi
diferenta. Sintaxa interogarii SQL difera de la un SGBD la altul dar sub o forma
directa sau printr-o constructie sintactica specifica se pot realiza oricare dintre
operatiile amintite.
Exemple:
1)"Sa se afiseze codurile furnizorilor, numele furnizorilor, cantitatile
comandate şi numerele comenzilor"
SELECT 1.cod_furnizor, nume_furnizor, cantitate, nr_comanda
FROM furnizori 1, comenzi b
WHERE 1.cod_furnizor=b.cod_furnizor;
A se observa scrierea cu notarea tuplelor care apartin fiecarei tabele pentru a
evita orice confuzie in legatura cu tabela din care se va extrage informatia. Exista
doua atribute in tabele diferite care au acelasi nume: atributele cod_furnizor.
Modul de notare de mai sus este acceptat de sintaxa SQL şi diferentiaza atributul
cod_furnizor din tabela furnizori de atributul cod_furnizor din tabela comenzi.

85
 2)"Sa se afiseze datele de mai sus dar numai pentru furnizorii care au
adresa in Chisinau"
SELECT 1.cod_furnizor, nume_furnizor, cantitate, nr_comanda
FROM furnizori 1, comenzi b
WHERE 1.cod_furnizor=b.cod_furnizor AND oras='Chisinau';
3)"Ce flori au aceeasi inaltime cu laleaua?" A se observa ca aceasta
interogare necesita realizarea produsului cartezian al tabelei FLORI cu ea insasi.
SELECT p1.nume_planta, p2.nume_planta, p1.inaltime, p2.inaltime
FROM flori p1, flori p2
WHERE p1.inaltime=p2.inaltime AND p2.nume_planta='LALEA';

Clauza UNION
Clauza UNION permite realizarea reuniunii de tabele. In cazul cand dorim
sa reunim doua sau mai multe tabele, este obligatoriu ca acestea sa fie descrise de
scheme de relatie identice (acelasi numar de atribute şi corespunzator – de la
stanga la dreapta – atributele din tabele au acelasi nume şi aceeasi descriere).
Aceste conditii sunt impuse tabelelor implicate in operatiile intersectie şi minus
(diferenta). Operatiile reuniune, intersectie şi diferenta de tabele actioneaza analog
cu aceleasi operatii aplicate la multimi.
Forma generala a reuniunii de tabele este:
SELECT A1 ,…, Am
FROM
[WHERE …]
UNION
SELECT A1 ,…, Am
FROM …
[WHERE …]
Exemple:
1)"Sa se afiseze numele plantelor şi codurile plantelor care au inaltimea fie
mai mica decat 20 cm fie mai mare decat 50 cm."
86
 SELECT nume_planta, cod_produs
FROM flori
WHERE culoare='alb' AND inaltime<20
UNION
SELECT nume_planta, cod_produs
FROM flori
WHERE culoare='alb' AND inaltime>50;

6.8. Subinterogari
Unul din motivele pentru care SQL este considerat un limbaj puternic de
interogare este acela cã oferã posibilitatea construirii interogãrilor complexe,
formate din mai multe subinterogãri simple.
Aceste interogãri complexe sunt construite prin includerea în clauza
WHERE a inca unei clauze SELECT. Forma generala a unei astfel de constructii
este:
SELECT < lista atribute1 >
FROM < lista relatii1 >
WHERE < subinterogare >
Se observa ca aceasta constructie a fost deja utilizata in exemplul de mai sus
care ilustreaza o clauza UNION.
In constructia de mai sus clauza SELECT interioarã genereazã valorile
pentru conditia de cãutare a clauzei SELECT exterioare care o contine. Clauza
SELECT exterioarã genereazã o relatie pe baza valorilor generate de cãtre clauza
interioarã. Modul de constuire a interogãrii exterioare depinde de numãrul valorilor
returnate de cãtre interogarea interioarã. În acest sens, putem distinge:
- subinterogãri care returneazã o singurã valoare
- subinterogãri care returneazã mai multe valori.
Din punctul de vedere al ordinii de evaluare al interogãrilor putem distinge:
 subinterogãri simple

87
 Interogarea interioarã este evaluatã prima, independent de interogarea
exterioarã. Rezultatul evaluãrii interogãrii interioare este utilizat de cãtre
interogarea exterioarã .
 subinterogãri corelate
Valorile returnate de cãtre interogarea interioarã depind de valorile returnate
de cãtre interogarea exterioarã. Interogarea interioarã este evaluatã repetat pentru
fiecare tuplu cercetat de interogarea exterioara.
Subinterogãri simple care returnezã o singurã valoare
Aceste interogãri au urmãtoarea sintaxã:
SELECT < lista atribute >
FROM < lista relatii >
WHERE < atribut > (< subinterogare >);
unde este un operator relaţional: = <>>= <= !=
Vom considera urmãtorul exemplu:
Exemplu:
1)"Sã se afiseze numele plantelor care au inaltimea egala cu cea a lalelei".
SELECT nume_planta
FROM flori
WHERE inaltime=
(SELECT inaltime
FROM flori
WHERE nume_planta='LALEA');
Aceeasi interogare poate oferi lista numelor de plante in ordine alfabetica
inversa daca se utilizeaza şi o clauza ORDER BY.
SELECT nume_planta
FROM flori
WHERE inaltime=
(SELECT inaltime
FROM flori
WHERE nume_planta='LALEA')
88
 ORDER BY nume_planta DESC;
Procesul de evaluare a acestei interogãri se desfãsoarã astfel:
Se evalueazã în primul rînd interogarea interioarã. Conditia de evaluare a
interogãrii interioare este nume_planta='LALEA'.
Valoarea obtinuta pentru atributul inaltime (sa presupunem ca laleaua are 30
cm) este stocata într-o tabela temporara. Rezultatul evaluãrii interogãrii interioare
devine conditie de cãutare pentru interogarea exterioarã, care ar putea fi exprimata
in aceasta faza ca:
SELECT nume_planta
FORM flori
WHERE inaltime=30;
In urma executarii interogarii exterioare este creatã o relatie finalã, ce va
contine tuplele a cãror inaltime este aceeasi cu valoarea stocata în tabela
temporarã.
Interogarea interioarã poate contine în clauza WHERE şi conditii complexe,
formate prin utilizarea operatorilor logici (NOT, AND, OR) şi a functiilor agregat
(AVG, MAX, …).
Exemplu:
"Sa se afiseze numele plantelor care au inaltimea minima"
SELECT nume_planta
FORM flori
WHERE inaltime=
(SELECT MIN(inaltime)
FROM flori);
Subinterogãri simple care returnezã mai multe valori
Principiul de construire a acestui tip de interogare imbricatã utilizeazã în
clauza WHERE conditii, care evaluate, genereazã o multime de valori. In aceastã
categorie intrã operatorii (NOT) IN, (NOT) ANY, (NOT) ALL, (NOT) EXISTS.
Exemplu:
1)"Care furnizori mai au inca de executat livrari?"
89
 SELECT nume_furnizor
FROM furnizori
WHERE cod_furnizor IN
(SELECT cod_furnizor
FROM comenzi
GROUP BY cod_furnizor);
2)"Care furnizori, dintre furnizorii obisnuiti ai florariei, nu mai au nimic de
livrat?"
SELECT nume_furnizor
FROM furnizori
WHERE cod_furnizor NOT IN
(SELECT cod_furnizor
FROM comenzi
GROUP BY cod_furnizor);
A se observa ca cele doua interogari difera doar prin operatorul logic NOT.
De asemenea se poate remarca faptul ca prima interogare aminteste de apartenenta
din teoria multimilor iar a doua interogare corespunde operatiei minus (diferenta).
Daca versiunea SQL nu are un cuvant rezervat pentru operatia diferenta intre
tabele, se poate constru aceasta operatie cu ajutorul preicatului NOT IN ca in
exemplul de mai sus.
3)"Care furnizori au numarul maxim de comenzi de flori?"
SELECT nume_furnizor
FROM furnizori
WHERE cod_furnizor IN
(SELECT cod_furnizor
FROM comenzi
GROUP BY cod_furnizor
HAVING COUNT(*)=
(SELECT MAX(COUNT(cod_furnizor))
FROM comenzi
90
 GROUP BY cod_furnizor));
Subinterogãri corelate
În exemplele de panã acum, interogarea interioarã era evaluatã prima, dupã
care valoarea sau valorile rezultate erau utilizate de cãtre clauza WHERE din
interogarea exterioarã.
Exista şi o alt forma de subinterogare şi anume subinterogarea corelatã,
caz în care interogarea exterioarã transmite repetat cîte o valoare pentru interogarea
interioarã.
De fiecare datã cînd este transmisã o valoare, este evaluatã interogarea
interioarã. Dacã ambele interogãri acceseazã acelasi tabel, trebuie asigurate alias-
uri pentru fiecare referintã la tabelul respectiv. Ambele interogãri accesezã tuple
diferite din acelasi tabel în acelasi moment.
Exemplu:
"Sa se afiseze culoarea, inaltimea şi numele plantelor pentru plantele cu
inaltimea maxima, ordonate dupa culoare"
SELECT culoare, inaltime, nume_planta
FROM flori f
WHERE inaltime=
(SELECT MAX(inaltime)
FROM flori
WHERE culoare=f.culoare)
ORDER BY culoare;
A se observa ca şi interogarea anterioara se poate incadra in cazul ilustrat de
exemplul de mai sus.

6.9. Operatorii ANY şi ALL

Operatorul ANY poate fi utilizat în combinatie cu oricare dintre operatorii
relaţionali (= <>>= <= !=) pentru a se verifica dacã valoarea unui atribut este
egala, mai mica, mai mare, etc…decat oricare dintre valorile mentionate odata cu
operatorul. Urmãtoarele predicate sunt echivalente :

91
 = ANY si IN
!= ANY si NOT IN
Operatorul ALL returneazã tuplele pentru care valorile atributului din clauza
WHERE sunt mai mici, mai mari, mai mici sau egale, etc. … decat toate valorile
generate de interogarea interioarã. Sã facem observatia cã acest operator nu poate
fi utilizat cu operatorul relaţional =, ceea ce ar corespunde cazului banal în care
toate valorile din listã sunt identice:
Pentru a stabili mai exact modul in care se selecteaza valorile cu operatorii
ANY şi ALL dam mai jos o serie de cazuri concrete.
Sa presupunem ca interogarea este de forma:
SELECT …
FROM …
WHERE x < ALL (1, 2, 3, 4)
Sa observam ca daca inlocuim operatorul ALL cu expresia verbala toate
putem citi "Valorile lui x trebuie sa fie mai mici decat toate valorile din paranteza
ce urmeaza dupa ALL."
Atunci vom lua in considerare urmatoarele situatii:

Valori ale lui x care

Expresia din clauza WHERE
corespund
x < ALL 0, -1, -2, …
x <= ALL 1, 0, -1, -2, …
x > ALL 5, 6, 7, …
x >= ALL 4, 5, 6, ..
Daca vom studia o interogare de forma:
SELECT …
FROM …
WHERE x < ANY (1, 2, 3, 4)
Sa observam ca daca inlocuim operatorul ANY cu expresia verbala oricare
putem citi "Valorile lui x trebuie sa fie mai mici decat oricare dintre valorile din
paranteza ce urmeaza dupa ALL."
Vom lua in considerare urmatorul tabel:
92
 Valori ale lui x care
Expresia din clauza WHERE
corespund
x < ANY 3, 2, 1, 0, -1, -2, …
x <= ANY 4, 3, 2, 1, 0, -1, -2, …
x > ANY 2, 3, 4, 5, 6, 7, …
x >= ANY 1, 2, 3, 4, 5, 6, ..
Exemple:
1)"Sa se afiseze numele plantelor, pretul unitar şi culoarea pentru plantele
care au minim 50 cm inaltime şi pretul minim din grupul de plante de inaltime sub
50 cm"
SELECT nume_planta, pret_unitar, culoare
FROM flori
WHERE pret_unitar<ALL
(SELECT pret_unitar
FROM flori
WHERE inaltime>=50);
2)"Sa se afiseze numele plantelor şi pretul unitar pentru plante mai mari de
50 cm, din care se exclude cea mai scumpa planta"
SELECT nume_planta, pret_unitar
FROM flori
WHERE inaltime>=50 AND pret_unitar<ANY
(SELECT pret_unitar
FROM flori
WHERE inaltime>=50);
3)"Sa se afiseze numele plantei şi pretul unitar pentru planta cea mai
scumpa cu inaltimea mai mare sau egala cu 50 cm"
SELECT nume_planta, pret_unitar
FROM flori
WHERE inaltime>=50 AND NOT pret_unitar<ANY
(SELECT pret_unitar

93
 FROM flori
WHERE inaltime>=50);

6.10. Operatorul EXISTS

Operatorul EXISTS verificã dacã pentru fiecare tuplu al relatiei existã tuple
care satisfac conditia interogãrii interioare. In cazul în care existã asemenea tuple,
EXISTS ia valoarea de adevãr TRUE. Astfel, operatorul EXISTS permite
specificarea mai multor atribute în interogarea interioarã. Acest lucru este posibil
deoarece nu se verificã valoarea unui anumit atribut ca în cazurile anterioare, ci se
genereazã o valoare de adevãr (TRUE sau FALSE), dupã cum existã sau nu existã
o anumitã valoare într-o relatie diferitã de cea utilizatã în interogarea exterioarã.
Ca şi operatorii ANY şi ALL, operatorul EXISTS apare in clauza WHERE.
Exemplu:
"Care plante au un pret unitar egal sau mai mic cu cea mai ieftina planta de
culoare alba?"
SELECT nume_planta, pret_unitar, culoare
FROM flori f
WHERE NOT EXISTS
(SELECT *
FROM flori
WHERE culoare='alb' AND pret_unitar>f.pret_unitar);
Interogarea SELECT interioarã defineste o tabela care contine acele tuple
pentru care se verifica conditia din clauza WHERE interna. Daca nu exista nici o
planta de culoare alba şi care sa aiba pretul unitar mai mare decat pretul unitar din
tuplul curent, conditia NOT EXISTS este evaluatã la valoarea logica TRUE.

94
BIBLIOGRAFIE

1. К.Дж.Дейт Введение в системы баз данных. Киев:Диалектика, 1998.

2. Г.Хансен, Дж.Хансен Базы данных. Разработка и управление.Изд.
Бином, 1999.
3. Н.Вирт. Алгоритмы и структуры данных. М:Мир, 1989.
4. М.Грабер Введение в SQL. М:Лори, 1996.
5. Дж.Доуман, С.Эммерсон, М.Дарновски Практическое руководство по
SQL. Киев:Диалектика, 1997.
6. M. Stanescu şi colectiv Limbaje de programare şi bănci de date. ASE,
Bucuresti, 1992

95