baze-TOATE SUBIECTELE

1.
Care este forma corecta pentru a adauga constrangeri la nivel de coloana si

/sau la nivel
de tabel?
CREATE TABLE [schema.]nume_tabel (
nume_coloana tip_de_date, [DEFAULT expr] [constrangere_de_coloana], ...
..[constrangere la nivel de tabel])
nume_coloana tip_de_date [DEFAULT expr], [constrangere_de_coloana] ...
nume_coloana tip_de_date, [DEFAULT expr], [constrangere_de_coloana], ...
nume_coloana tip_de_date [DEFAULT expr] [constrangere_de_coloana], ...
2. Care este comanda corecta care determina marirea salariul tuturor angajatilor
din tabelul
salariat cu 5%?
UPDATE salariu
SET salariu = salariu * 1.05;
UPDATE salariat
SET salariu = salariu * 1.05;
UPDATE salariat
SET salariu = 1.05;
UPDATE salariat
SET salariu = salariu + salariu* 1.05;
3. Care este comanda corecta care insereaza in tabelul
TOTALURI(cod_departament,
numar_angajati, suma_salarii)?
INSERT INTO totaluri
SELECT cod_departament, COUNT(*),SUM(salariu)
FROM salariat
GROUP BY cod_departament;
SELECT cod_departament, SUM(cod_angajat),SUM(salariu)
FROM salariat
SELECT cod_departament, COUNT(*),SUM(salariu)
FROM salariat;
SELECT cod_departament, COUNT(),SUM(salariu)
FROM salariat
ORDER BY cod_departament;
4. Care comanda afiseaza numele angajatilor, fara duplicate, care au manager?
SELECT DISTINCT nume
FROM salariat
WHERE manager IS NOT NULL;
FROM salariat
WHERE manager IS NULL;
SELECT nume
FROM salariat
WHERE manager IS NOT NULL;
FROM salariat
WHERE manager != NULL;
5. Care este comanda corecta care pentru fiecare facultate, se insereaza in
tabelul
SALARII(cod_fac, nr_prof, total_sal_fac) numarul de profesori si suma salariilor pe
care
facultatea o plateste profesorilor sai?
INSERT TO TOTALURI
SELECT COD_FAC, COUNT(*) , SUM(SALARIU)
FROM PROF ORDER BY COD_FAC;
INSERT INTO TOTALURI
FROM PROF ;
INSERT INTO TOTALURI
FROM PROF GROUP BY COD_FAC;
SELECT COD_FAC, SUM(COD_PROF),SUM(SALARIU)
FROM PROF
GROUP BY COD_FAC;
6. Care secventa este corecta pentru a afisa citi angajati nu au o valoare
introdusa pe
coloana salariu?
SELECT COUNT()
FROM salariati
WHERE SALARIU =0;
SELECT COUNT(*)
FROM salariati
WHERE SALARIU =NULL;
SELECT COUNT(*)
FROM salariati
WHERE SALARIU IS NOT NULL;
SELECT COUNT(*)
FROM salariati
WHERE SALARIU IS NULL;
7. Care este comanda corecta care determina dublarea salariilor cu rotunjire la 2
zecimale a
angajatilor care sunt titulari?
UPDATE salariat
SET salariu=ROUND(salariu*2,2);
UPDATE salariat
SET salariu=ROUND(salariu*2)
WHERE titular =’y’;
UPDATE salariat
SET salariu=ROUND(salariu*2,2)
UPDATE salariat
SET salariu=ROUND(salariu*0.5,2)
8. Care este comanda corecta care afiseaza numele salariatilor care castiga mai
mult decat
salariul mediu pe companie, in ordine crescatoare a salariului?
SELECT nume
FROM salariati
WHERE salariu >AVG(salariu);
SELECT nume
FROM salariati
WHERE salariu > (SELECT AVG(salariu) FROM salariati)
ORDER BY salariu;
SELECT nume
FROM salariati
WHERE salariu > (SELECT AVG(salariu) FROM salariati
ORDER BY salariu);
SELECT nume
FROM salariati
ORDER BY 1;
9. Ce comanda modifica in tabelul SALARIAT
COD _ANG
NUME
PRENUME
DATA_ANG
VARSTA
EMAIL
SALARIU
not null
numeric de
5
sir de
caractere
de
maxim 20
sir
caractere
de maxim
20
date,
valoare
implicita
data
curentã
numeric de
2
sir de
caractere
de
dimensiune
fixa, de 30
valoare
implicita 0
numar de
10 cu 2
zecimale
dimensiunea coloanei nume la 30 si pe cea a coloanei salariu la 12 cu 3 zecimale?
ALTER TABLE salariat
MODIFY nume VARCHAR2(30), salariu NUMBER(12,3);
MODIFY nume VARCHAR2(30), salariu NUMBER(12,3);
MODIFY nume VARCHAR2(30), MODIFY salariu NUMBER(12,3);
MODIFY (nume VARCHAR2(30), salariu NUMBER(12,3));
10. Care este comanda corecta care sterge valoarea coloanei salariu pentru
angajatii care
sunt angajati cu contract de colaborare?
DELETE salariu
FROM salariati
WHERE contract=’colaborare’;
UPDATE salariati
SET salariu IS null
DROP salariu
FROM salariati
UPDATE salariati
SET salariu=null
11. Care este comanda incorecta care afiseaza numele, salariul si varsta pentru
toti salariatii
care castiga mai mult de 1000, rezultatul fiind sortat descendent dupa salariu, iar
pentru cei
care au acelasi salariu in ordine crescatoare dupa nume?
SELECT nume, salariu, varsta
FROM salariat
WHERE salariu>1000
ORDER BY salariu DESC nume ASC;
FROM salariat
WHERE salariu>1000
ORDER BY salariu DESC, nume ASC;
FROM salariat
WHERE salariu>1000
ORDER BY salariu DESC, nume;
FROM salariat
WHERE salariu>1000
ORDER BY 2 DESC, 1 ASC;
12. Actualizarile realizate asupra tabelelor de baza ale unei vizualizari se reflecta
totdeauna
in vizualizare
Adevărat
Fals
13. Care este comanda corecta pentru a afisa numele, prenumele si varsta
salariatilor, iar
pentru cei care au varsta necunoscuta sa apara textul “varsta necunoscuta”?
SE LECT nume, prenume, NVL(varsta, ‘varsta necunoscuta’)
FROM salariat;
SELECT nume, prenume, NVL(TO_CHAR(varsta), ‘varsta necunoscuta’)
FROM salariat;
SE LECT nume, prenume, NVL(CHAR(varsta), ‘varsta necunoscuta’)
FROM salariat;
SE LECT nume, prenume, NVL2(TO_CHAR(varsta), ‘varsta necunoscuta’)
FROM salariat;
14. Care comanda afiseaza numarul de angajati din fiecare departament?
SE LECT cod_departament, COUNT(*)
FROM salariat;
SE LECT cod_departament, SUM(cod_ angajat)
FROM salariat
SELECT cod_ departament, COUNT(*)
FROM salariat
SE LECT cod_departament, COUNT()
FROM salariat
15. Pentru a introduce in tabelul SALARIAT
COD _ ANG
NUME
PRENUME
DATA_ ANG
VARSTA
SALARIU
not null
numeric de 5
sircaractere
de maxim 20
sir caractere
de maxim 20
date, valoare
implicita data
curentã
numeric de 2
valoare
implicita 0
numar de 10
cu 2 zecimale
doua coloane: Cod_Funct si Email ce varianta folosim?
ALTER TABLE SALARIAT ADD Cod_Funct NUMBER(2), ALTER COLUMN ADD Email char(25);
ALTER TABLE SALARIAT ADD Cod_Funct NUMBER(2), ADD Email CHAR(25);
ALTER TABLE SALARIAT ADD (Cod_Funct NUMBER(2) , Email CHAR(25));
ALTER TABLE SALARIAT ADD Cod_Funct NUMBER(2), ALTER ADD Email char(25);
16. Ce comanda creeaza tabelul SALARIAT_ 1 care sã aiba aceeiasi structura cu
tabelul SALARIAT
COD _ANG
NUME
PRENUME
DATA_ANG
VARSTA
EMAIL
SALARIU
not null
numeric de
5
sir de
caractere
de
maxim 20
sir
caractere
de maxim
20
date,
valoare
implicita
data
curentã
numeric de
2
sir de
caractere
de
dimensiune
fixa, de 30
valoare
implicita 0
numar de
10 cu 2
zecimale
si sa contina salariatii care au salariu >100?
CRE ATE TABLE SALARIAT_1
SE LECT * FROM SALARIAT WHERE SALARIU>100;
CREATE TABLE SALARIAT_ 1 AS
SELECT * FROM SALARIAT WHERE SALARIU>100;
CRE ATE TABLE SALARIAT_1 AS
SE LECT FROM SALARIAT WHERE SALARIU>100;
CRE ATE TABLE SALARIAT_1 AS
SE LECT COD_ANG, SALARIU FROM SALARIAT WHERE SALARIU>100;
17. Pentru a modifica dimensiunea coloanei prenume la 30 si pe cea a salariului la
12 cu 3
zecimale, din tabelul SALARIAT
COD _ANG
NUME
PRENUME
DATA_ANG
VARSTA
EMAIL
SALARIU
not null
numeric de
5
sir de
caractere
de
maxim 20
sir
caractere
de maxim
20
date,
valoare
implicita
data
curentã
numeric de
2
sir de
caractere
de
dimensiune
fixa, de 30
valoare
implicita 0
numar de
10 cu 2
zecimale
care varienta este corecta?
ALTER TABLE SALARIAT
MODIFY (prenume VARCHAR2(30) salariu NUMBER(12,3));
MODIFY (prenume VARCHAR2(30)), MODIFY(salariu NUMBE R(12,3));
MODIFY (prenume VARCHAR2(30) , salariu NUMBER(12,3));
ADD (prenume VARCHAR2(30), salariu NUMBER(12,3));
18. Care este varianta corecta pentru a crea tabelul Salariat, cu caracteristicile de
mai jos?
COD _ANG
NUME
PRENUME
DATA_ANG
VARSTA
EMAIL
SALARIU
not null
numeric de
5
sir de
caractere
de
maxim 20
sir
caractere
de maxim
20
date,
valoare
implicita
data
curentã
numeric de
2
sir de
caractere
de
dimensiune
fixa, de 30
valoare
implicita 0
numar de
10 cu 2
zecimale
CREATE TABLE SALARIAT (
cod_ ang NUMBER(5) NOT NULL,
nume VARCHAR2(20),
prenume VARCHAR2(20),
data_ angajarii DATE DEFAULT SYSDATE,
varsta NUMBER(2),
email CHAR(50),
salariu NUMBER(10,2) DEFAULT 0);
CRE ATE TABLE SALARIAT (
cod_ ang NUMBER(5)
nume VARCHAR2(20),
data_ angajarii DATE ,
varsta NUMBER(2),
email CHAR(50),
CRE ATE TABLE SALARIAT (
cod_ ang NUMBER(5) NOT NULL,
nume VARCHAR2(20),
data_ angajarii DATE, DE FAULT SYSDATE ,
varsta NUMBER(2),
email CHAR(50),
salariu NUMBER(10,2), DE FAULT 0);
19. Care varianta este corecta pentru a redenumi tabelul SALARIAT cu numele
SALARIATI?
RENAME SAL ARIAT TO SALARIATI;
RENAME SALARIAT WITH SALARIATI;
RENAME TABLE SALARIAT TO TABLE SALARIATI;
RENAME TABLE SALARIAT WITH TABLE SALARIATI;
20. Care ste comanda corecta care afiseaza codul departamentelor pentru care
salariul
minim depaseste 5000$?
SELECT cod_departament
FROM salariat
WHERE MIN(salariu)>5000
SE LECT cod_departament
FROM salariat
GROUP BY cod_departament
HAVING MIN(salariu)>5000;
SE LECT cod_departament
FROM salariat
GROUP BY cod_departament
MIN(salariu)>5000;
ALTE SUBIECTE TIMISOARA
Care este comanda corecta care afiseaza numele si salariul angajatilor condusi
direct de
Ionescu Mihai?
SELECT nume, salariu
FROM salariati
WHERE cod_sef = (SELECT cod_angajat FROM salariati
WHERE nume ='Ionescu' AND prenume ='Mihai' );
FROM salariati
WHERE cod_sef = (SELECT cod_angajat FROM salariati
WHERE nume ='Ionescu', prenume ='Mihai' );
FROM salariati
WHERE cod_sef = ‘Ionescu Mihai';
FROM salariati
WHERE cod_sef != (SELECT cod_angajat FROM salariati
WHERE nume ='Ionescu' AND prenume ='Mihai' );
Ce comanda sterge din tabelul SALARIAT
COD _ANG NUME PRENUME DATA_ANG VARSTA EMAIL SALARIU
not null numeric de 5 sir de
caractere de
maxim 20 sir caractere de maxim 20 date, valoare implicita data curentã numeric
de 2 sir de
caractere de dimensiune fixa, de 30 valoare implicita 0
numar de 10 cu 2 zecimale
coloana nume si coloana salariu?
DROP nume, salariu;
DROP COLUMN (nume, salariu);
DROP (nume, salariu);
DROP COLUMN nume, COLUMN salariu;
Care este comanda corecta care afiseaza numele salariatilor care lucreaza in
departamentul
3 si au salariul >100 sau care sunt din departamentul 5 si au salariul <200?
SELECT nume
FROM salariat
WHERE (cod_deptartament=3 OR salariu>100) AND (cod_deptartament=5 OR salariu<200);
SELECT nume
FROM salariat
WHERE (cod_deptartament=3 AND salariu>100) OR (cod_deptartament=5 AND
salariu<200);
SELECT nume
FROM salariat
WHERE (cod_deptartament=3 AND salariu>100) AND (cod_deptartament=5 AND
salariu<200);
SELECT nume
FROM salariat
WHERE (cod_deptartament=3 AND salariu>100) OR (cod_deptartament=5 OR salariu<200);
Care dintre urmatoarele comenzi intoarce numarul zilei din luna carespunzator
datei
curente?
SELECT TO_CHAR(SYSDATE,’DDD’)
FROM dual;
SELECT TO_CHAR(SYSDATE,’DAY’)
FROM dual;
SELECT TO_CHAR(SYSDATE,’D’)
FROM dual;
SELECT TO_CHAR(SYSDATE,’DD’)
FROM dual;
Care este comanda corecta care afiseaza numele salariatilor si numele
departamentelor in
care lucreaza, inclusiv departamentele in care nu lucreaza salariati?
SELECT nume_salariat, nume_departament
FROM salariati s, departamente d
WHERE s.cod_departament = d.cod_departament;
WHERE s.cod_departament(+) = d.cod_departament;
WHERE s.cod_departament = d.cod_departament(+);
WHERE s.cod_departament(+) = d.cod_departament(+);
Pentru a insera in tabelul SALARIAT inregistrari,
not null numeric de 5 sir caractere de maxim 20 sir caractere de maxim 20 date,
valoare
implicita data curentã numeric de 2 sir de
care varianta este incorecta?
INSERT INTO SALARIAT(COD _ANG, NUME,PRENUME,DATA_ANG,VARSTA,EMAIL, SALARIU)
VALUES(5, ‘Ene’, ‘Ana’, ‘1/06/2009’, 20, ‘INTERZIS PE FORUM CU ADRESE DE EMAIL.com’,
2500.50)
INSERT INTO SALARIAT(COD _ANG, NUME,PRENUME, VARSTA, EMAIL) VALUES(5, ‘Ene’, ‘Ana’,
20,
‘INTERZIS PE FORUM CU ADRESE DE EMAIL.com’)
INSERT INTO SALARIAT(COD _ANG, NUME,PRENUME,VARSTA,EMAIL, SALARIU)
VALUES(5,
‘Ene’, ‘Ana’, ‘1/06/2009’, 20, ‘INTERZIS PE FORUM CU ADRESE DE EMAIL.com’)
INSERT INTO SALARIAT
VALUES(5, ‘Ene’, ‘Ana’, ‘1/06/2009’, 20, ‘INTERZIS PE FORUM CU ADRESE DE EMAIL.com’,
2500.50)
Ce comanda creeaza tabelul SALARIAT_1 care sã aiba aceeiasi structura cu
tabelul SALARIAT
not null numeric de 5 sir de
caractere de
maxim 20 sir caractere de maxim 20 date, valoare implicita data curentã numeric
de 2 sir de
CREATE TABLE SALARIAT_1
CREATE TABLE SALARIAT_1 AS
SELECT FROM SALARIAT WHERE SALARIU>100;
SELECT COD_ANG, SALARIU FROM SALARIAT WHERE SALARIU>100;
Care este comanda nu elimina simultan spatiile de la inceputul si sfarsitul
coloanei nume?
SELECT TRIM(nume)
FROM salariat;
SELECT RTRIM(LTRIM(nume))
FROM salariat;
SELECT LTRIM(RTRIM(nume))
FROM salariat;
SELECT LTRIM(nume)
FROM salariat;
2. Care este comanda corecta care afiseaza toate functiile pe care nu lucreaza
angazatii?
A SELECT cod_functie
FROM functii
WHERE cod_functie IN
(select cod_functie FROM salariati WHERE cod_functie IS NOT NULL)
B SELECT cod_functie
FROM functii
WHERE cod_functie NOT IN
(select cod_functie FROM salariati WHERE cod_functie IS NULL)
C SELECT cod_functie
FROM functii
(select cod_functie FROM salariati)
D SELECT cod_functie
FROM functii
(select cod_functie FROM salariati WHERE cod_functie IS NOT NULL)
Raspuns D.
ALTE TESTE
3-Care este comanda corecta care afiseaza numele cititorilor care au carti nerestituite?
SELECT nume_ cititor
FROM imprumuta
WHERE data_ restituirii = NULL;
SE LECT nume_cititor
FROM imprumuta
WHERE data_ restituirii IS NOT NULL;
SELECT nume_ cititor
FROM imprumuta
WHERE data_ restituirii IS NULL;
SE LECT nume_cititor
FROM imprumuta
WHERE data_ restituirii > SYSDATE;
6-Care comanda nu defineste corect un tabel?
CREATE TABLE [schema.]nume_ tabel (
nume_coloana tip_de_date [DEFAULT expr], ...);
CREATE TABLE nume_ tabel [(col1, col2...)]
AS subcerere;
nume_ coloana tip_de_date, [DEFAULT expr], [constrangere_de_coloana], ...);
nume_coloana tip_de_date [DEFAULT expr] [constrangere_ de_coloana], ...
8-Ce comanda creeaza corect tabelul SALARIAT, specificand constrangerile
COD _ ANG NUME PRENUME DATA_ANG VARSTA EMAIL SALARIU
cheie primara numeric de 5 not null
sir decaractere demaxim 20 sir caractere de maxim 20 date, valoare
implicita data curentã numeric de 2 unic sir de caractere de dimensiune fixa, de 30 > 0
CREATE TABLE salariat(
cod_ ang NUMBER(5) PRIMARY KEY,
nume VARCHAR2(20) NOT NULL,
data_ ang DATE DEFAULT SYSDATE,
varsta NUMBER(2),
email CHAR(30) UNIQUE,
salariu NUMBER(10,2) CHECK (salariu > 0));
cod_ ang NUMBER(5) PRIMARY KE Y,
data_ ang DATE DEFAULT SYSDATE ,
varsta NUMBER(2),
email CHAR(30) UNIQUE ,
salariu NUMBER(10,2) > 0));
cod_ ang NUMBER(5) PRIMARY KE Y,
data_ ang DATE DEFAULT SYSDATE ,
varsta NUMBER(2),
email CHAR(30),
9-Care este comanda corecta care afiseaza numele si salariul angajatilor condusi direct de
‘ENE
DAN’?
FROM salariati
WHERE cod_manager = (SELE CT cod_manager FROM salariati
WHERE UPPER(nume) ='ENE ' , UPPER(pren) ='DAN' );
SE LECT nume, salariu
FROM salariati
WHERE cod_manager = (SELE CT cod_ang FROM salariati
WHERE nume ='ENE' , pren ='DAN' );
SE LECT nume, salariu
FROM salariati
(SE LECT cod_ang FROM salariati
WHERE UPPER(nume) ='ENE ' AND UPPER(pren) ='DAN' );
FROM salariati
WHERE cod_manager = (SELECT cod_ ang FROM salariati
WHERE UPPER(nume) ='ENE' AND UPPER(pren) ='DAN' );
10. Care este comanda corecta care afiseaza numarul total al cartilor imprumutate in anul
2008?
SELECT COUNT()
FROM imprumuta
WHERE TO_CHAR(data_ imprumutului,’yyyy’)=2008;
SELECT COUNT(*)
FROM imprumuta
WHERE TO_CHAR(data_ imprumutului,’yyyy’)=2008;
SE LECT COUNT(*)
FROM imprumuta
WHERE data_ imprumutului=2008;
SE LECT COUNT(*)
FROM imprumuta
WHERE TO_CHAR(data_ imprumutului,’yy’)=2008;
14-Care comanda listeaza numele tuturor angajatilor care au a treia litera din nume 'a'?
SELECT nume
FROM salariat
WHERE nume LIKE '_ _a$';
SELECT nume
FROM salariat
WHERE nume LIKE '%a%';
SELECT nume
FROM salariat
WHERE nume LIKE '__ a%';
15-Care este comanda corecta care afiseaza toate departamentele care platesc salariatilor
sai o
suma mai mare ca 20000?
SELECT nume_ departament
FROM departament
WHERE 20000<
(SE LECT sum(salariu) FROM salariat);
SE LECT nume_departament
FROM departament A
WHERE 20000<
(SE LECT sum(salariu) FROM salariat B
where cod_ departament=cod_departament);
SE LECT nume_departament
FROM departament
WHERE 20000<
(SE LECT sum(salariu) FROM salariat
where A.cod_ departament=B.cod_departament);
SELECT nume_departament
FROM departament A
WHERE 20000<
(SELECT sum(salariu) FROM salariat B
where A.cod_departament=B.cod_departament);
18-Care este comanda corecta care afiseaza codul departamentelor, numele
departamentelor si
suma salariilor pentru fiecare departament?
SELECT cod_ departament, nume_departament, SUM(salariu)
GROUP BY cod_departament, nume_departament;
SE LECT cod_departament, nume_ departament, SUM(salariu)
WHERE s.cod_ departament=d.cod_departament
SELECT cod_departament, nume_departament, SUM(salariu)
WHERE s.cod_departament=d.cod_departament
SE LECT cod_departament, nume_ departament, SUM(salariu)
FROM salariati, departamente
WHERE s.cod_ departament=d.cod_departament
19-Care este comanda corecta care sa afiseze daca exista angajati care nu lucreaza in
departamentul ‘Contractari’ si al caror salariu coincide cu salariul unui angajat din
departamentul
‘Contractari’?
SELECT nume, salariu, cod_depart
FROM salariati
WHERE salariu IN (SELECT salariu FROM salariati s, department d
WHERE s.cod_depart = d.cod_depart AND nume_depart <> ‘Contractari’)
AND cod_depart= (SELECT cod_depart FROM department
WHERE nume_depart = ‘Contractari’);
SE LECT nume, salariu, cod_depart
FROM salariati
WHERE salariu IS IN (SELECT salariu FROM salariati s, department d
WHERE s.cod_ depart = d.cod_ depart , nume_ depart = ‘Contractari’)
AND cod_depart<> (SELECT cod_depart FROM department
SE LECT nume, salariu, cod_depart
FROM salariati
WHERE (salariu) IN (SELECT salariu FROM salariati s, department d
WHERE s.cod_ depart = d.cod_ depart AND nume_depart = ‘Contractari’)
teste fotografii care nu se regasesc mai sus
1.Care este comanda corecta care afiseaza numarul total de carti dintr-o
biblioteca pentru
fiecare domeniu:
SELECT cod_domeniu, COUNT(numar_exemplare)
FROM biblioteca
GROUP BY cod_domeniu;
SELECT cod_domeniu, SUM(numar_exemplare)
FROM biblioteca
SELECT cod_domeniu, SUM(cod_carte)
FROM biblioteca
SELECT cod_domeniu, COUNT(*)
FROM biblioteca
2.Pentru tabelul salariat
cod_depart cod_ang# nume pren salariu cod_funct
care este comanda corecta, pentru a modifica salariul la 3000, pentru angajatii
care lucreaza
in departamentul 10 si au salariul <3000?
UPDATE salariat SET salariu=3000
WHERE cod_depart=10 AND salariu<3000;
MODIFY salariat SET salariu=3000
WHERE cod_depart=10, salariu<3000;
UPDATE salariat SET cod_depart=10 AND salariu<3000
WHERE salariu=3000;
3.Care este comanda corecta care listeaza numele ale functiilor care exista in
departamentul
30, fara duplicate
SELECT DISTINCT nume_functie
FROM salariati s, functii f
WHERE cod_functie=cod_functie
AND cod_departament=30;
WHERE s.cod_functie=f.cod_functie
FROM salariati, functii f
SELECT nume_functie
4.Care este comanda corecta care determina micsorarea salariilro cu 10%, cu
rotunjire la 2
zecimale, a angajatilor care sunt titulari
UPDATE salariat
SET salariu=ROUND(salariu*0.9,2);
UPDATE salariat
WHERE titular='N';
UPDATE salariat
WHERE titular='N';
UPDATE salariat
WHERE titular='Y';
5.O constrangere de tip PRIMARY KEY poate fi declarata numai la nivel de coloana
A/F
6.Efectele unei comenzi DDL pot fi anulate cu o comanda ROLLBACK
A/F
7.Efectele unei comenzi DML pot fi anulate cu o comanda ROLLBACK
A/F
8.Care este comanda corecta care se afiseaza numele si prenumele pentru toti
angajatii cu
varsta necunoscuta?
SELECT nume, prenume
FROM salariat
WHERE varsta=NULL;
FROM salariat
WHERE varsta IS NULL;
FROM salariat
WHERE varsta=0;
FROM salariat
WHERE varsta IS NOT NULL;
9.Care este comanda corecta care determina micsorarea salariilro cu 10%, cu
rotunjire la 2
zecimale, a angajatilor care NU sunt titulari
UPDATE salariat
SET salariu=ROUND(salariu*0.9,2);
UPDATE salariat
WHERE titular='N';
UPDATE salariat
WHERE titular="N";
UPDATE salariat
WHERE titular='Y';
10.Pot fi eliminate mai multe coloane dintr-un tabel folosind o singura comanda
ALTER
TABLE ... DROP COLUMN
A/F
11.Care este comanda corecta care afiseaza numele si data angajarii pentru
salariatii care au
fost angajati dupa angajatul avand codul 10, in ordine descrescatoare a numelui?
SELECT nume, data_angajarii
FROM salariat
WHERE data_angajarii >
(SELECT data_angajarii FROM salariat WHERE cod_angajat = 10);
FROM salariat
(SELECT data_angajarii FROM salariat WHERE cod_angajat = 10)
ORDER BY nume;
FROM salariat
(SELECT data_angajarii FROM salariat WHERE cod_angajat = 10)
ORDER BY nume DESC;
FROM salariat
(SELECT * FROM salariat WHERE cod_angajat = 10)
ORDER BY nume DESC;
baze_de_date
Probleme pentru examenul de licenta
1. O baza de date relationala este

a. O colectie de date interrelationate gestionate ca o singura
b. unitate
c. Un produs software furnizat de un producator de baze de date
d. O structura de date, cum ar fi un tabel, o vizualizare sau un index
2. Definitaalinunei
Un Obiect acelasi
bazemod de toti
de date esteproducatorii de software
a. O colectie de inregistrari inrudite, stocate ca o singura unitate
b. Un produs software furnizat de un producator de baze de date
c. O structura, cum ar fi un tabel, o vizualizare sau un index
d. O colectie de date interrelationate gestionate ca o singuraunitate
3. Care din urmtoarele baze de date nu este un RDBMS (sistem de gestionare a bazelor
de date
relatioanale)
a. Oracle Database
b. MySQL
c. Excel Database
d. Microsoft SQL Server
4. Un sistem RDBMS(sistem de gestionare a bazelor de date relatioanale) nu urmatorul
include
serviciu
a. Acceptarea unui limbaj de interogare
b. Mecanisme de securitate, pentru a impiedica accesul si modificarea neautorizata a
datelor
c. Mutarea datelor in si din fisiere de date, dupa cum este necesar
d. Generarea diagramelor ERD (Entity Relationship Diagram)
5. Componentele unei baze de date relationale nu includ
a. Tabele
b. Diagrame
c. ERD
d. Restrictii
Relatii
6. Printre tipurile de restrictii care pot fi folosite in bazele de date relationale, nu se numara
a. NOT NULL
b. Relatii
c. CHECK
d. Cheie primara
e. Unicitate
7. Normalizarea nu rezolva
a. Anomalia de stergere
b. Anomalia de actualizare
c. Anomalia de inserare
d. Anomalia de creare
8. Un identificator unic (cheie primara)
a. Poate fi compus numai dintr-un singur atribut
b. Poate fi compus din atribute concatenate
c. Poate fi compus din atribute cu valoarea NULL
d. Poate fi compus din zero, unul sau mai multe atribute
9. Prima forma normala rezolva anomaliile cauzate de
a. Grupurile repetitive si atributele
b. multivaloare
c. Dependentele partiale de cheia primara
d. Dependentele tranzitive
10. Relatiile
A doua formadenormala
tip unu-la-mai-multi
rezolva anomaliile cauzate de
a. Grupurile repetitive
b. Dependentele partiale de cheia primara
c. Grupurile repetitive si atributele multi valoare
d. Dependentele tranzitive
11. A treia forma normala rezolva anomaliile cauzate de
a. Dependentele partiale de cheia primara
b. Grupurile repetitive
c. Dependentele tranzitive
d. Atributele multivaloare
12. Problemele de dependenŃă tranzitivă
a. Sunt rezolvate de a doua formă normală
b. Sunt rezolvate de prima formă normală
c. Apar atunci când un atribut non-cheie depinde doar de o parte a cheii primare
d. Sunt rezolvate de a treia formă normală
13. SQL este
a. Un limbaj procedural
b. Un limbaj neprocedural
c.
Un limbaj orientat spre obiecte
Un limbaj grafic, folosit pentru definirea diagramelor ER si a diagramelor
d.
conceptuale
14. Un model de date reprezinta o colectie integrata de concepte care nu descriu
a. date
b. relatii dintre date
c. date despre echipa realizatoare a modelului
d. constrângeri existente asupra datelor sistemului real analizat.
15. Nu este caracteristica a modelului relational
a. prezenta tuplurilor identice
b. articolele unui domeniu sunt omogene
c. toate valorile unui domeniu corespunzatoare tuturor cazurilor nu mai pot fi
descompuse in alte valori (sunt atomice)
d. fiecare coloana defineste un domeniu distinct si nu se poate repeta in cadrul
aceleiasi relatii
16. Modelul relational nu are ca regula de integritate structurala
a. Unicitatea cheii. Cheia primara trebuie sa fie unica si minimala.
b. Integritatea entitatii. Atributele cheii primare trebuie sa fie diferite de valoarea
null.
c. Integritatea referirii. O cheie externa trebuie sa corespunda unei valori a
cheii
d. primare asociate.
Integritatea referirii. O cheie externa trebuie sa fie ori null in intregime, ori sa
corespunda unei valori a cheii primare asociate.
17. Relatia m:n devine in modelul relational
a. tabel asociativ cu cheia primara formata numai din doua chei externe pentru cele
doua tabele asociate
b. tabel asociativ cu cheia primara formata din doua chei externe pentru cele
doua tabele asociate plus eventuale coloane aditionale
c. chei externe
d. entitate independenta
18. Care nu este un concept utilizat pentru a descrie formal - uzual - fizic elementele d
baza ale
organizarii
a. relatie -datelor
tablou- fisier
b. tuplu - linie- inregistrare
c. atribut - coloana - camp
d. domeniu - zona- functie
19. Instructiunile SQL nu fac parte din categoria
a. Limbajul de interogare a datelor (DQL)
b. Limbajul de definire a datelor (DDL - Data Definition Language)
c. Limbajul de selectare a datelor (DSL - Data Selection Language)
d. Limbajul de manipulare a datelor (DML - Data Manipulation Language)
20. Limbajul de definire a datelor (DDL - Data Definition Language) nu include urmatoarea instructiune
a. DELETE
b. CREATE
c. ALTER
d. DROP
21. Limbajul de manipulare a datelor (DML – Data Manipulation Language) nu include instructiuniea
a. INSERT
b. UPDATE
c. DELETE
d. ALTER
22. Tipurile de date temporale standard nu includ
a. DATE
b. DATETIME
c. TIME
d. TIMESTAMP
23. Valorile NULL
a. Sunt egale cu alte valori NULL
b. Este acelasi lucru ca si spatiile libere
c. Sunt intotdeauna permise in mod prestabilit
d. Pot fi folosite pentru reprezentarea datelor care lipsesc sau nu sunt
cunoscute
24. Definitia unei coloane din instructiunea CREATE TABLE nu poate include
a. Numele tabelului
b. O clauza DEFAULT
c. O clauza NULL sau NOT NULL
d. Numele coloanei
25. Sintaxa corecta pentru o restrictie NOT NULL este
a. nume_coloana REFERENCES NOT NULL
b. nume_coloana tip_de_DATA IS NOT NULL
c. nume_coloan tip_de_DATA NOT NULL
d. DEFAULT
a [NULL | NOT NULL]
26. Sintaxa corecta pentru o restrictie UNIQUE este
a. [CONSTRAINT nume_restrictie] UNIQUE {nume_coloana[,nume
b. coloana...])
c. [CONSTRAINT nume_restrictie] UNIQUE (nume_tabel)
d. nume_coloana REFERENCES UNIQUE nume_tabel
27. DEFAULT
Sintaxa corecta UNIQUE (nume_coloana)
pentru o restrictie referentiala asupra unei coloane este
a. CONSTRAINT nume_restrictie] REFERENCES nume_tabel
b. nume_coloana REFERENCES nume_tabel
c. FOREIGN KEY nume_coloana REFERENCES nume_tabel (nume_coloana)
d. REFERENCES nume_tabel (nume_coloana)
28. Utilizarile valide ale instructiunii ALTER TABLE nu include
a. Adaugarea coloanelor
b. Eliminarea unei chei primare
c. Redenumirea unui tabel
d. Adaugarea unei restrictii
29. Nu este functie SQL standard pentru siruri de caractere
a. UPPER
b. LENGTH sau LEN
c. LOWER
d. LIKE
30. Operatorul UNION
a. Include randurile duplicate in setul de rezultate
b. Combina seturile de rezultate a doua interogari intr-un singur set de
rezultate si elimina randurile duplicate din setul de rezultate
c. Combina doua interogari intr-o singura interogare de tip join
d. Este numit JOIN in unele implementari SQL
31. O instructiune SQL care contine o functie de agregare
a. Nu poate include, in acelasi timp, o clauza GROUP BY si o clauza ORDER BY
b. Trebuie sa includa o clauza GROUP BY
c. Trebuie sa includa o clauza ORDER BY
d. Poate contine si coloane obisnuite si coloane calculate
32. Care este varianta corecta pentru a crea tabelul Salariat, cu caracteristicile de mai jos?
VARST
COD _ANG NUME PRENUME DATA_ANG EMAIL SALARIU
A
valoare
sir date, sir deimplicita
not null caractere de
sir caractere
valoare
numeric
caractere de0
de dimensiunenumar de
numeric de 5 de maxim 20 de 2
maxim implicita 10
dimensiune
20 data curentă fixa, de 30 cu 2
zecimale
a. CREATE TABLE SALARIAT (
cod_ang NUMBER(5) NOT
NULL, nume VARCHAR2(20),
data_angajarii DATE DEFAULT
SYSDATE, varsta NUMBER(2),
email CHAR(50),
b. CREATE TABLE SALARIAT (
cod_ang NUMBER(5)
nume VARCHAR2(20),
data_angajarii DATE ,
varsta NUMBER(2),
email CHAR(50),
c. CREATE TABLE SALARIAT (
cod_ang NUMBER(5) , NOT NULL,
nume VARCHAR2(20),
data_angajarii DATE , DEFAULT SYSDATE,
varsta NUMBER(2),
email CHAR(50),
salariu NUMBER(10,2) , DEFAULT 0);
33. Pentru a insera in tabelul SALARIAT inregistrari
DATA_AN
COD _ANG NUME PRENUME VARSTA EMAIL SALARIU
G
valoare
sir de
implicita
sir date, caractere
sir caractere
valoare numeric de 2 de
0
numeric de 5 de maxim 20 numar de
maxim 20 implicita data dimensiune
10 cu 2
curentă fixa, de 30
zecimale
care varianta este incorecta?
a. INSERT INTO SALARIAT(COD _ANG, NUME, PRENUME, DATA_ANG, VARSTA, EMAIL,
SALARIU) VALUES(5, ‘Ene’, ‘Ana’, ‘1/06/2009’, 20, ‘ea@gmail.com’, 2500.50)
b. INSERT INTO SALARIAT(COD _ANG, NUME, PRENUME, VARSTA, EMAIL)
VALUES(5, ‘Ene’, ‘Ana’, 20, ‘ea@gmail.com’)
c. INSERT INTO SALARIAT(COD _ANG, NUME,PRENUME,VARSTA,EMAIL,
SALARIU) VALUES(5, ‘Ene’, ‘Ana’, ‘1/06/2009’, 20, ‘ea@gmail.com’)
d. INSERT INTO SALARIAT
VALUES(5, ‘Ene’, ‘Ana’, ‘1/06/2009’, 20, ‘ea@gmail.com’, 2500.50)
34. Care este varianta corecta pentru a crea tabelul CARTE, cu caracteristicile de mai jos, indicand cheile la nive
de coloana?
(Tabelele DOMENIU_CARTE si CARTE sunt in relatia 1:M)
CARTE(codc CHAR(5), titlu VARCHAR2(30), autor VARCHAR2(30), pret NUMBER(8,2), nrex

NUMBER(3), coddom CHAR(5))
a. CREATE TABLE CARTE

(codc CHAR(5) PRIMARY KEY,
titlu VARCHAR2(30),
autor VARCHAR2(30),
pret
NUMBER(8,2), nrex
NUMBER(3),
coddom CHAR(5) NOT NULL)
b. CREATE TABLE CARTE
(codc CHAR(5) PRIMARY
KEY,
titlu VARCHAR2(30),
autor VARCHAR2(30),
pret
NUMBER(8,2), nrex
NUMBER(3),
coddom CHAR(5) NOT NULL
REFERENCES DOMENIU(coddom));
c. CREATE TABLE CARTE
(codc CHAR(5) ,
titlu VARCHAR2(30),
autor VARCHAR2(30),
pret
NUMBER(8,2), nrex
NUMBER(3),
PRIMARY KEY (codc),
FOREIGN KEY (coddom)
REFERENCES DOMENIU (coddom));
35. Care este varianta corecta pentru a crea tabelul CARTE, cu caracteristicile de mai jos(codc cheie primara
coddom cheie secundara), indicand cheile la nivel de tabel?
CARTE(codc CHAR(5) , titlu VARCHAR2(30), autor VARCHAR2(30), pret NUMBER(8,2), nrex


titlu VARCHAR2(30),
autor VARCHAR2(30),
pret
NUMBER(8,2), nrex
NUMBER(3),
coddom CHAR(5) NOT NULL)
b. CREATE TABLE CARTE
titlu VARCHAR2(30),
autor VARCHAR2(30),
pret
NUMBER(8,2), nrex
NUMBER(3),
REFERENCES DOMENIU(coddom));
(codc CHAR(5),
titlu VARCHAR2(30),
auto VARCHAR2(30),
r NUMBER(8,2),
pret
nrex NUMBER(3),
coddom CHAR(5) NOT
NULL, PRIMARY KEY
(codc),
REFERENCES DOMENIU
36. Sa se creeze tabelul asociativ imprumuta, a carui structura este data
mai jos(codc, codcit si
dataim sunt chei primare). Sa se precizeze legatura cu tabelele carte si cititor, aflate in relatia M:M
(mai multi
a. la mai multi)
IMPRUMUTA (
codc CHAR(5),
codcit CHAR(5),
dataim DATE DEFAULT
datare SYSDATE,
s DATE,
dataef DATE,
PRIMARY KEY (codel, codec, dataim),
FOREIGN KEY (codc)
REFERENCES CARTE
(codc), FOREIGN KEY (codcit)
REFERENCES
CITITOR(codcit));
b. IMPRUMUTA (
codc CHAR(5) PRIMARY KEY,
codcit CHAR(5) PRIMARY KEY,
dataim DATE DEFAULT SYSDATE PRIMARY KEY,
datares DATE,
dataef DATE,
FOREIGN KEY (codc)
REFERENCES CARTE (codc),
FOREIGN KEY (codcit)
REFERENCES CITITOR(codcit));
c. IMPRUMUTA (
codc CHAR(5) REFERENCES CARTE (codc),
codcit CHAR(5) REFERENCES CITITOR(codcit),
dataim DATE DEFAULT SYSDATE,
datares DATE,
dataef DATE,
PRIMARY KEY (codel, codec, dataim));
37. Sa se creeze tabelul CARTE_INFO(codc, titlu, autor) prin copiere din tabelu
CARTE(codc CHAR(5) , titlu VARCHAR2(30), autor VARCHAR2(30), pret NUMBER(8,2), nrex
selectand cartile care au coddom=’I’

a. CREATE TABLE CARTEINFO
(codc CHAR(5),
titlu VARCHAR2(30),
autor VARCHAR2(30),
FROM CARTE
PRIMARY KEY (codc),
REFERENCES DOMENIU (coddom));
b. CREATE TABLE CARTE_INFO

(codc CHAR(5) PRIMARY
KEY,
titlu VARCHAR2(30),
autor VARCHAR2(30),
FROM CARTE
WHERE coddom = ’I’;
c. CREATE TABLE CARTE_INFO
AS SELECT codc, titlu, autor
FROM CARTE
WHERE coddom = ’I’;
38. Pentru a introduce in tabelul SALARIAT
COD DATA_AN
NUME PRENUME VARSTA SALARIU
_ANG G
valoare
implicita
date,
not null sircaractere sir caractere
valoare numeric de 2
0
numeric de 5 de maxim 20 de maxim 20 numar de
implicita data
10 cu 2
curentă
zecimale
doua coloane: Cod_Funct si Email ce varianta folosim?
a. ALTER TABLE SALARIAT ADD Cod_Funct NUMBER(2), ALTER COLUMN ADD

Email char(25);
b. ALTER TABLE SALARIAT ADD Cod_Funct NUMBER(2), ADD Email CHAR(25);
c. ALTER TABLE SALARIAT ADD (Cod_Funct NUMBER(2) , Email CHAR(25));
d. ALTER TABLE SALARIAT ADD Cod_Funct NUMBER(2), ALTER ADD Email
char(25);
39. Ce comanda creeaza tabelul SALARIAT_1 care să aiba aceeiasi structura c
tabelul SALARIAT
DATA_AN VARST
COD _ANG NUME PRENUME EMAIL SALARIU
G A
valoare
sir de date, sir de caractere
sir caractere
valoare
numeric
de
implicita
numeric de 5 maxim 20 de maxim 20 de 2 0
implicita data dimensiune
numar de
curentă fixa, de 30
10 cu 2
zecimale

a. CREATE TABLE SALARIAT_1
b. CREATE TABLE SALARIAT_1
AS SELECT * FROM SALARIAT WHERE SALARIU>100;
c. CREATE TABLE SALARIAT_1
AS SELECT FROM SALARIAT WHERE SALARIU>100;
d. CREATE TABLE SALARIAT_1
AS SELECT COD_ANG, SALARIU FROM SALARIAT WHERE SALARIU>100;
40. Ce comanda sterge din tabelul
SALARIAT
COD DATA_AN
NUME PRENUME VARSTA EMAIL SALARIU
_ANG G
valoare
sir de
implicita
sir de date, valoare caractere
sir caractere
implicita
numeric
de
0
numeric de 5 de maxim 20 de numar de
maxim 20 data curentă dimensiune
2 10 cu 2
fixa, de 30
zecimale
a. ALTER TABLE SALARIAT

DROP nume, salariu;
b. ALTER TABLE SALARIAT
DROP COLUMN (nume, salariu);
c. ALTER TABLE
SALARIAT DROP (nume,
d. salariu);
41. Ce DROP COLUMN
comanda nume, tabelul
creeaza corect COLUMN salariu; specificand constrangerile?
SALARIAT,
COD DATA_AN
NUME PRENUME VARSTA EMAIL SALARIU
_ANG G
unic
sir de
not null > 0
cheie date, valoare caractere
sir de sir caractere numar de
primara implicita data numeric de 2 de
caractere de de maxim 20 10 cu 2
numeric de 5 curentă dimensiun
maxim 20 zecimale
e fixa,
de
30
a. CREATE TABLE salariat(
cod_ang NUMBER(5) PRIMARY
KEY, nume VARCHAR2(20) NOT
NULL, prenume VARCHAR2(20),
data_ang DATE DEFAULT
SYSDATE, varsta NUMBER(2),
salariu NUMBER(10,2) CHECK (salariu >
0));
b. CREATE TABLE salariat(
cod_ang NUMBER(5) PRIMARY KEY,
data_ang DATE DEFAULT SYSDATE,
varsta NUMBER(2),
salariu NUMBER(10,2) > 0));
c. CREATE TABLE salariat(
data_ang DATE DEFAULT SYSDATE,
varsta NUMBER(2),
email CHAR(30),
42. Care este comanda corecta prin care se adauga constrangerea de cheie primara tabelului
IMPRUMUTA (cod_cititor, cod_carte, data_imprumut, data_restituire)?
a. ALTER TABLE IMPRUMUTA

ADD PRIMARY KEY cod_cititor, PRIMARY KEY cod_carte, PRIMARY KEY
data_imprumut;
b. ALTER TABLE IMPRUMUTA
ADD PRIMARY KEY cod_cititor, cod_carte, data_imprumut;
c. ALTER TABLE IMPRUMUTA
ADD CONSTRAINT cp PRIMARY KEY (cod_cititor, cod_carte,
d. data_imprumut);
ALTER TABLE IMPRUMUTA
ADD
43. Pentru PRIMARY
tabelul Salariat KEY (cod_cititor, cod_carte, data_imprumut);
cod_depart cod_ang# nume pren salariu cod_funct
care este comanda corecta, pentru a modifica salariu la 3000, pentru angajatii care lucreaza in departamentu
10 si au salariul<3000?
a. UPDATE salariat SET salariu=3000
b. MODIFY salariat SET salariu=3000
WHERE cod_depart=10 , salariu<3000;
c. UPDATE salariat SET cod_depart=10 AND
salariu<3000
d. WHERE salariu=3000;
WHEREîn
44. Să se insereze cod_depart=10
tabelul CARTEAND salariu<3000;
toate cărŃile din tabelul CARTE_INFO, presupunând că tabelul
CARTE_INFO a fost deja creat.
AS SELECT codc, titlu, autor
FROM CARTE_INFO;
b. INSERT INTO CARTE
SELECT
FROM CARTE_INFO;
AS SELECT *
FROM CARTE_INFO;
d. INSERT INTO
SELECt
CARTE *
TFROM CARTE_INFO;
45. Pentru profesorii titulari, sa se maresca cumulul cu 10% si sa se rotunjeasca la 2 zecimale.
UPDATE PROF SET CUMUL = ROUND([CUMUL]*1.1,2)
WHERE TITULAR="Y";
a. UPDATE PROF SET CUMUL = (CUMUL*1.1)
WHERE TITULAR=’Y’;
b. MODIFY PROF SET CUMUL = ROUND(CUMUL*1.1,2)
c. UPDATE PROF SET CUMUL = ROUND(CUMUL*1.1,2
d. UPDATE PROF SET CUMUL = ROUND(CUMUL*1.1,2);
46. Sã se modifice pretul cartilor din biblioteca, care se gasesc intr-un numar de exemplare
mai mic
decat media numarului de exemplare pe biblioteca. Noua valoare a pretului sa fie egala c
suma
a. preturilor cartilor
UPDATE CARTE scrise de ‘BARBU’.
SET pret = SUM(pret)
(SELECT CARTE
FROM autor = ’BARBU’)
WHERE nrexWHERE < (SELECT AVG(nrex)
FROM CARTE);
b. MODIFY CARTE
SET pret = (SELECT SUM(pret)
FROM carte
WHERE autor = ’BARBU’)
WHERE nrex < (SELECT AVG(nrex)
FROM CARTE);
c. UPDATE CARTE
pret = ( SUM(pret)
FROM carte
WHERE autor = ’BARBU’)
WHERE nrex < ( AVG(nrex)
FROM CARTE);
d. UPDATE CARTE
pret = (SELECT SUM(pret)
FROM carte
WHERE autor = ’BARBU’ and
nrex < ( AVG(nrex)
FROM CARTE);
47. Pentru tabelele:
PROF
cod_prof# cod_fac nume pren salariu cod_fuct
TOTALURI
cod_fac# nr_prof total_sal
care este secventa corecta pentru o instructiune INSERT cu o instructiune SELECT interna, pentru a insera in
tabelul TOTALURI, un rand pentru fiecare facultate din tabelul PROF, care sa contina numarul de profesori
din facultate si suma salariilor lor?
a. INSERT TO TOTALURI
b. INSERT INTO TOTALURI
SELECT COD_FAC, COUNT(*) AS NR_PROF, SUM(SALARIU) AS TOTAL_SAL
FROM PROF ;
c. INSERT INTO TOTALURI
SELECT COD_FAC, COUNT(*) AS NR_PROF, SUM(SALARIU) AS
TOTAL_SAL FROM PROF GROUP BY COD_FAC;
48. Pentru tabelul
PROFcod_prof# cod_fac pren salariu
care este secventa corecta pentru a modifica salariile cu 10% , care nu contin valori NULL?
a. UPDATE PROF SET SALARIU = SALARIU*1.1
WHERE SALARIU NOT NULL;
b. UPDATE PROF SET SALARIU = SALARIU*1.1
c. UPDATE PROF SElLECT SALARIU = SALARIU*1.1
WHERE SALARIU <>0;
49. Pentru tabelul PROF
cod_prof# cod_fac nume pren salariu cod_funct
care este secventa corecta pentru a sterge toate cadrele didactice care sunt profesori consultanti?
a. DELETE FROM PROF WHERE
b. COD_FUNCT=’C’;
c. DELETE PROF WHERE COD_FUNCT<>’C’;
d. DROP FROM PROF WHERE COD_FUNCT=’C’;
DROP
50. Pentru tabelul:PROF WHERE COD_FUNCT=’C’;
FAC
cod_fac# denumire adresa
care este secventa corecta pentru o inserare, folosind instructiunea SELECT
a. INSERT INTO FAC

(COD_FAC, DENUMIRE, ADRESA)
SELECT VALUES(MAX(COD_FAC)+1, 'LIMBI', 'ION GHICA')
b. INSERT INTO FAC
SELECT MAX(COD_FAC)+1, 'LIMBI', 'ION GHICA'
FROM FAC;
c. INSERT INTO FAC
SELECT MAX(COD_FAC)+1, 'LIMBI', 'ION
GHICA' FROM FAC;
51. Pentru tabelul
PROF
cod_prof# cod_fac nume pren salariu
care este secventa corecta pentru a afisa toti profesorii impreuna cu media _ salariu pentru fiecare
facultate , rotunjita la doua pozitii zecimale
a. SELECT COD_FAC,
ROUND (AVG (SALARIU), 2) AS
FROM PROF medie_salariu
ORDER BY COD_FAC;
b. SELECT COD_FAC,
ROUND (AVG (SALARIU, 2) AS
GROUP BY COD_FAC;
c. SELECT COD_FAC,
ROUND (AVG (SALARIU), 2) AS
GROUP BY COD_FAC;
d. SELECT FROM PROF COD_FAC,
ROUND AVG (SALARIU), 2 AS
medie_salariu
GROUP BY COD_FAC;
52. Pentru
tabelul
care este secventa corecta pentru a afisa suma salariilor tuturor profesorilor din universitate.
a. SELECT SUM (Salariu) AS Total_Salariu
FROM PROF;
b. SELECT SUM (Salariu) AS Total_Salariu
FROM PROF
GROUP BY COD_FAC;
c. SELECT SALARIU, SUM (Salariu) AS
Total_Salariu
d. FROM PROF;
SELECT COD_FAC, SUM (Salariu) AS Total_Salariu
53. PentruFROM PROF;
tabelul
care este secventa corecta pentru a afisa toti profesorii pentru care COD_FAC =1 si
salariu>=1200, sau toti profesorii pentru care COD_FAC =3 si salariu < 2000.
a. SELECT COD_FAC, COD_PROF, NUME, SALARIU

FROM PROF
WHERE (COD_FAC=1 OR SALARIU >1200)
AND (COD_FAC =3 OR SALARIU<2000);
b. SELECT COD_FAC, COD_PROF, NUME,SALARIU
FROM PROF
WHERE (COD_FAC=1 AND SALARIU >1200)
AND (COD_FAC =3 AND SALARIU<2000);
c. SELECT COD_FAC, COD_PROF, NUME,
SALARIU
FROM PROF
WHERE (COD_FAC=1 AND SALARIU >1200)
OR (COD_FAC =3 AND SALARIU<2000);
d. SELECT COD_FAC, COD_PROF, NUME,SALARIU
FROM PROF
WHERE COD_FAC=1 OR SALARIU >1200
OR (COD_FAC =3 OR SALARIU<2000);
54. Pentru tabelul
PROF
care secventa este corecta pentru a afisa citi profesori nu au o valoare introdusa pe coloana salariu?
a. SELECT COUNT(salariu)
FROM PROF
WHERE SALARIU =0;
b. SELECT COUNT(*)
FROM PROF
WHERE SALARIU =NULL;
c. SELECT COUNT(*)
FROM PROF
d. SELECT
COUNT(*) FROM
PROF
WHERE
55. O uniune SALARIU
(join) IS NULL;
fara o clauzä WHERE sau o clauza JOIN
a. Nu returneaza nici un rand din setul de rezultate
b. Reprezinta o uniune interna (inner join)
c. Are ca rezultat un produs cartezian
d. Reprezinta o uniune externa(outer join)
56. O uniune externa (outer join) nu
a. Poate fi scrisa in Oracle SQL folosind un simbol (+) in clauza

b. FROM
c. Poate fi scrisa in Oracle SQL folosind un simbol (+) in clauza WHERE
d. Returneaza toate randurile din unul sau din ambele tabele
Poate
57. Pentru fi catre stanga, catre dreapta sau completa
tabelele:
PROF
FAC
care este secventa corecta pentru o interogare de uniune interna(inner join) care sa afiseze toti profesorii si
denumirile facultatilor la care predau, in ordinea crescatoare a denumirilor
a. SELECT NUME, PREN, DENUMIRE
FROM FAC, PROF
WHERE A.COD_FAC =B.COD_FAC
ORDER BY FAC.DENUMIRE;
b. SELECT NUME, PREN, DENUMIRE
FROM FAC, PROF
WHERE
FAC.COD_FAC=PROF.COD_FAC ORDER
BY FAC.DENUMIRE;
c. SELECT NUME, PREN, DENUMIRE
FROM FAC, PROF
WHERE FAC.COD_FAC=PROF.COD_FAC;
58. a.Să SELECT
se obtinapentru
codcfiecare carte, codul sau şi numarul de exemplare care nu au fost inca restituite.
FROM IMPRUMUTA
WHERE dataef IS
NULL
GROUP BY codc;
b. SELECT COUNT(*)
FROM
IMPRUMUTA
GROUP BY codc;
c. SELECT codc,
COUNT(*)
FROM IMPRUMUTA
WHERE
GROUP BY dataef codc;
IS
d. SELECT COUNT(*)
FROM
IMPRUMUTA
WHERE
GROUP BY dataef =0 codc;
59. Care este secventa corecta care să afişeze numărul cărŃilor împrumutate cel puŃin de
două ori
(pentru fiecare carte împrumutată mai mult decât o dată să se obŃină numărul de câte o
a fost împrumutată).
a. SELECT
COUNT(COUNT(codel))
FROM imprumuta
GROUP BY codcarte
b. HAVING COUNT(*)>1;
SELECT COUNT(codel)
FROM imprumuta
GROUP BY codcarte
HAVING COUNT(*)>1;
c. SELECT COUNT(COUNT(codel))
FROM imprumuta
WHERE COUNT(*)>1;
d. SELECT COUNT(codel)
FROM imprumuta
ORDERBY BY codcarte
HAVING COUNT(*)>1;
60. Care este secventa corecta care afiseaza pentru fiecare domeniu de carte, numărul
cărŃilor din domeniu, media preŃurilor şi numărul total de exemplare
a. SELECT codcarte, COUNT(*), AVG(pret)

FROM CARTE
GROUP BY codcarte;
b. SELECT coded, AVG(pret), SUM(nrex)
FROM CARTE
GROUP BY codcarte;
c. SELECT codcarte, COUNT(*), AVG(pret),
SUM(nrex) FROM CARTE
GROUP BY codcarte;
d. SELECT COUNT(*), AVG(pret), SUM(nrex)
FROM CARTE
ORDER BY codcarte;
61. Pentru
tabelele:
PROF
FAC
care este secventa corecta pentru o interogare de uniune externa catre stanga, care sa afiseze toti profesorii si
denumirile facultatilor la care predau
a. SELECT NUME, PREN, DENUMIRE

FROM FAC PROF LEFT OUTER JOIN ON A.COD_FAC = B.COD_FAC;
b. SELECT NUME, PREN, DENUMIRE
FROM FAC LEFT OUTER JOIN PROF ON
A.COD_FAC = B.COD_FAC;
c. SELECT NUME, PREN, DENUMIRE
FROM FAC A LEFT OUTER JOIN PROF B ON A.COD_FAC =
B.COD_FAC;
62. Pentru tabelele:
PROF
FUNCTII
cod_funct# nume_funct
care este secventa corecta pentru o subinterogare necorelata, care sa afiseze toate functiile pentru care nu
exista profesorii incadrati
a. SELECT cod_funct, nume_funct
FROM functii
WHERE cod_funct NOT IN
(SELECT DISTINCT cod_funct FROM
b. prof);
SELECT cod_funct, nume_funct
FROM functii
c. SELECT DISTINCT cod_funct FROM prof;
SELECT cod_funct, nume_funct
FROM functii
WHERE cod_funct IN
63. Care(SELECT
este comandacod_funct
corecta careFROM
pentruprof);
fiecare facultate, se insereaza in tabelul TOTALURI(cod_fac,
nr_prof, total_sal_fac) numarul de profesori si suma salariilor pe care facultatea o plateste profesorilor sai?
a. INSERT TO TOTALURI
b. INSERT INTO TOTALURI
FROM PROF ;
c. INSERT INTO TOTALURI
SELECT COD_FAC, COUNT(*) ,
SUM(SALARIU) FROM PROF
GROUP BY COD_FAC;
d. INSERT INTO TOTALURI
SELECT COD_FAC, SUM(COD_PROF), SUM(SALARIU)
FROM PROF
GROUP BY COD_FAC;
64. Să se obŃină titlurile şi preŃurile cărŃilor mai scumpe decât cartea având titlul “Baze de date”, al cărui
autor este Popescu (self join).
a. SELECT x.titlu, x.pret

FROM carte x, y
WHERE x.pret < y.pret
AND y.titlu = ’Baze de date’
AND y.autor = ’Popescu’;
b. SELEC x.titlu, x.pret
T carte x, carte y
FROM x.pret > y.pret
WHERE y.titlu = ’Baze de date’
AND y.autor = ’ Popescu’;
c. AND x.titlu, x.pret
SELECT carte x, carte y
WHERE titlu = ’Baze de date’
AND autor = ’ Popescu’;
d. AND x.titlu, x.pret
SELECT carte x, carte y
WHERE y.titlu = ’Baze de date’, y.autor = ’ Popescu’;
65. PentruANDtabelele
PROFESORI(codp, nume, pren, salariu)
COPII (codp, nume_c, virsta)
care este secventa corecta pentru a afisa profesorii cu copii
a. SELECT a.nume, a.pren
FROM PROFESORI A
WHERE a.codp IN (SELECT DISTINCT
codp
b. FROM COPII);
SELECT a.nume, a.pren
FROM PROFESORI A
WHERE codp IN (SELECT codp
FROM COPII);
c. SELECT a.nume, a.pren
FROM PROFESORI A
WHERE a.codp IN COPII;
d. SELECT a.nume, a.pren
FROM PROFESORI A
WHERE a.codp IN DISTINCT codp
FROM COPII;
66. Pentru tabelele
PROFESORI(codp, nume, pren, salariu)
COPII (codp, nume_c, virsta)
care este secventa corecta pentru a afisa profesorii fara copii
a. SELECT a.nume, a.pren
FROM PROFESORI A
WHERE codp NOT IN (SELECT codp FROM COPII);
b. SELECT a.nume, a.pren
FROM PROFESORI A
WHERE a.codp NOT IN (SELECT DISTINCT codp FROM
c. COPII);
FROM PROFESORI A
d. WHERE a.codp NOT IN SELECT codp FROM copii;
FROM PROFESORI A
WHERE a.codp
67. Se considera IS NOTunei(SELECT
pentru actionarii DISTINCT codpFROM
firme, urmatoarele tabele COPII
ACTIONARI(nume varchar2(20), cod_act number(5))
ACTIUNI (cod_act number(5), seriain number(8), seriasf number(8), valoar number(8))
(unde seriain si seriasf reprezinta seria de inceput, respectiv de sfarsit al intervalului de actiuni pe
care il are un actionar).
Care este secventa corecta care afiseaza pentru un actionar (introdus de la tastatura), intervalele
seriilor actiunilor sale
a. SELECT a.seriain, a.seriasf, b.nume
FROM actiuni a, actionari b
WHERE a.codact=b.codact AND
b. b.nume=‘&x’;
SELECT a.seriain, a.seriasf, b.nume
FROM actiuni , actionari
c. WHERE a.codact=b.codact AND nume=‘&x’;
d. WHERE a.codact=b.codact ;
WHERE a.codact=b.codact
68. Se considera pentru actionarii uneiOR
firme,b.nume=‘&x’;
tabelul
ACTIUNI (cod_act number(5), seriain number(8), seriasf number(8), valoar number(8))
(unde seriain si seriasf reprezinta seria de inceput, respectiv de sfarsit al intervalului de actiuni pe
care il are un actionar).
Care este secventa corecta care afiseaza suma necesara firmei pentru plata tuturor
devidentelor (numrul de actiuni inmultit cu valoarea unei actiuni)?
a. SELECT SUM((seriain+seriasf)*valoare))
FROM ACTIUNI;
b. SELECT SUM((seriasf-seriasf)*valoare))
FROM ACTIUNI;
c. SELECT SUM((seriain-seriasf)*valoare))
FROM ACTIUNI;
d. SELECT SUM((seriasf-
seriain+1)*valoare)) FROM
ACTIUNI;
69. Pentru tabelele
Angajat(cod_angajat, nume, pren, …..)
Are_functia (cod_angajat, cod_functie, salariu ,…..)
Functii(cod_functie, ……)
care este comanda corecta pentru a calcula suma salariilor angajatului ‘ENE ANA’, care cumuleaza mai multe
functii, in diferite compartimente?
a. SELECT COUNT(SALARIU) AS SALARIU_CUMULAT
FROM salariat, are_functia
WHERE s.cod_salariat=a.cod_salariat
AND NUME='ENE' AND PREN='ANA’;
b. SELECT Sum(SALARIU) AS SALARIU_CUMULAT
FROM salariat, are_functia
WHERE NUME='ENE' , PREN='ANA’;
c. SELECT Sum(SALARIU) AS
SALARIU_CUMULAT FROM salariat s,
are_functia a
WHERE s.cod_salariat=a.cod_salariat
AND
70. Pentru NUME='ENE' AND PREN='ANA’;
tabelele:
PROF
FAC
care este secventa corecta pentru o subinterogare corelata, care sa afiseze toate facultatile pentru care suma
salariile profesorilor este mai mare 10000
a. SELECT DISTINCT DENUMIRE
FROM FAC
WHERE 10000< (SELECT sum(salariu)
FROM PROF WHERE A.COD_FAC=B.COD_FAC);
b. SELECT DISTINCT
DENUMIRE FROM FAC A
WHERE 10000< ( SELECT sum(salariu)
FROM PROF B WHERE
c. A.COD_FAC=B.COD_FAC);
SELECT DISTINCT DENUMIRE
FROM FAC A
WHERE 10000< SELECT sum(salariu)
71. CareFROM PROFcorecta
este comanda B WHERE
pentruA.COD_FAC=B.COD_FAC;
a afisa toti salariatii , in ordine crescatoare dupa nume, care sunt manageri ?
a. SELECT DISTINCT sef.nume, angajat.cod_manager
FROM salariati sef, salariati angajat
WHERE sef.cod_salariat= angajat.cod_manager
ORDER BY sef.nume;
b. SELECT DISTINCT sef.nume, angajat.cod_manager
WHERE cod_salariat= cod_manager
ORDER BY sef.nume;
c. SELECT DISTINCT nume, cod_manager
WHERE sef.cod_salariat= angajat.cod_manager;
d. ELECT DISTINCT nume, cod_manager
WHERE cod_salariat= cod_manager
ORDER BY sef.nume;
72. Care este comanda corecta care sa afiseze daca exista angajati care nu lucreaza in departamentul ‘Contractari
si al caror salariu coincide cu salariul unui angajat din departamentul ‘Contractari’?
a. SELECT nume, salariu, cod_depart
FROM salariati
WHERE salariu IN (SELECT salariu FROM salariati , department d
WHERE s.cod_depart = d.cod_depart AND nume_depart <> ‘Contractari’)
AND cod_depart= (SELECT cod_depart FROM department
b. SELECT nume, salariu, cod_depart
FROM salariati
WHERE salariu IS IN (SELECT salariu FROM salariati , department
WHERE s.cod_depart = d.cod_depart , nume_depart = ‘Contractari’)
c. SELECT nume, salariu, cod_depart
FROM salariati
WHERE (salariu) IN (SELECT salariu FROM salariati s, department
d
WHERE s.cod_depart = d.cod_depart AND nume_depart =
‘Contractari’) AND cod_depart<> (SELECT cod_depart FROM
73. Care estedepartment
comanda corecta care afiseaza numarul total de carti imprumutate si restituite pentru fiecare citito
al unei biblioteci?
a. SELECT cod_cititor, COUNT()
FROM imprumuta
WHERE data_restituirii NOT NULL
GROUP BY cod_cititor;
b. SELECT cod_cititor, COUNT(*)
FROM imprumuta
WHERE data_restituirii IS NOT NULL;
c. SELECT cod_cititor, COUNT(*)
FROM imprumuta
d. SELECT cod_cititor,
COUNT(*) FROM imprumuta
WHERE data_restituirii IS NOT
NULL
74. Care este comanda corecta care determina micsorarea salariilor cu 10%, cu rotunjire la 2 zecimale , a
angajatilor care nu sunt titulari?
a. UPDATE salariat
SET salariu=ROUND(salariu*0.9, 2);
b. UPDATE salariat
SET salariu=ROUND(salariu*1.1)
WHERE titular =’N’;
c. UPDATE salariat
SET salariu = ROUND(salariu*0.9,
2) WHERE TITULAR=’N’;
d. UPDATE salariat
SET salariu=ROUND(salariu+salariu*0.1)
WHERE titular =’Y’;
75. Care este comanda corecta care afiseaza numele si salariul angajatilor condusi direct de ‘ENE DAN’?
a. SELECT nume, salariu
FROM salariati
WHERE cod_ang = (SELECT cod_manager FROM salariati
WHERE UPPER(nume) ='ENE' , UPPER(pren) ='DAN' );
b. SELECT nume, salariu
FROM salariati
WHERE cod_manager IN (SELECT cod_ang FROM salariati
WHERE nume ='ENE' , pren ='DAN' );
c. SELECT nume, salariu
FROM salariati
(SELECT cod_ang FROM salariati
WHERE UPPER(nume) ='ENE' AND UPPER(pren) ='DAN' );
d. SELECT nume, salariu
FROM salariati
WHERE cod_manager = (SELECT cod_ang FROM salariati
WHERE UPPER(nume) ='ENE' AND UPPER(pren) ='DAN
76. Care este);comanda corecta care afiseaza numele cititorilor care au carti nerestituite?
a. SELECT nume_cititor
FROM imprumuta
WHERE data_restituirii = NULL;
b. SELECT nume_cititor
FROM imprumuta
WHERE data_restituirii IS NOT NULL;
c. SELECT nume_cititor
FROM imprumuta
WHERE data_restituirii IS NULL;
d. SELECT nume_cititor
FROM imprumuta
WHERE data_restituirii > SYSDATE;
77. Care este comanda corecta care sterge valoarea coloanei salariu pentru angajatii care sunt angajati cu contract
de colaborare?
a. DELETE salariu
FROM salariati
b. UPDATE salariati
SET salariu IS null
c. DROP salariu
FROM salariati
d. UPDATE salariati
SET salariu=null
78. Care este comanda corecta care afiseaza codul departamentelor, numele departamentelor si suma salariilor
pentru fiecare departament?
a. SELECT cod_departament, nume_departament, SUM(salariu)
b. SELECT cod_departament, nume_departament, SUM(salariu)
c. SELECT cod_departament, nume_departament,
SUM(salariu) FROM salariati s, departamente d
d. SELECT cod_departament, nume_departament, SUM(salariu)
FROM salariati, departamente
79. Care este comanda corecta care afiseaza numele salariatilor care castiga mai mult decat salariul
mediu pe
companie,
a. SELECT in ordine
nume crescatoare a salariului?
FROM salariati
WHERE salariu >AVG(salariu);
b. SELECT nume
FROM salariati
WHERE salariu > (SELECT AVG(salariu) FROM
salariati) ORDER BY salariu;
c. SELECT nume
FROM salariati
WHERE salariu > (SELECT AVG(salariu) FROM salariati
ORDER BY salariu);
d. SELECT nume
FROM salariati
ORDER BY 1;
80. Care este comanda corecta care afiseaza toate functiile pe care nu lucreaza angajati?
a. SELECT cod_functie
FROM functii
WHERE cod_functie IN
(SELECT cod_functie FROM salariati WHERE cod_functie IS NOT NULL);
b. SELECT cod_functie
FROM functii
(SELECT cod_functie FROM salariati WHERE cod_functie IS NULL);
c. SELECT cod_functie
FROM functii
(SELECT cod_functie FROM salariati);
d. SELECT cod_functie
FROM functii
(SELECT cod_functie FROM salariati WHERE cod_functie IS NOT
NULL);
Intrebări şi probleme la cursul de Baze de date, anul III,
toate formele de învăŃământ
PARTEA I. Concepte despre Bazele de date relaŃionale. Normalizare
Probleme
1. Să se normalizeze tabelul CURS_SUDENT
Presupunem că tabela Curs_Student conŃine următoarele date:

CURS_SUDENT
NrMatricol NumeSt PrenumeSt Grupa Cursuri-Nota
458 Predescu Alexandru 114 engleza-7,germana-8
521 Radu George 122 desen-tehnic-10,franceza-7
627 Cristescu Lucian 243 programare-8,engleza-10
746 Irimia Diana 361 analiza numerica-9
782 Tanase Daciela 341 gernana-6,programare-10
982 Bunea Mihaela 114 rezistenta materialelor-8
1204 Dragnea Liviu 412 educatie fizica-10
S1520 Popa Marius 452 analiza numerica-7,engleza-9
Coloana Cursuri conŃine mult prea multa informaŃie.

Să presupunem că am înlocui coloana Cursuri cu două noi coloane:
CURS_SUDENT
NrMatricol NumeSt PrenumeSt Grupa Curs1 Nota1 Curs2 Nota2
458 Predescu Alexandru 114 engleza 7 germana 8
521 Radu George 122 desen tehnic 10 franceza 7
627 Cristescu Lucian 243 programare 8 engleza 10
746 Irimia Diana 361 analiza numerica 9
782 Tanase Daciela 341 germana 6 programare 10
rezistenta
982 Bunea Mihaela 114 materialelor 8
1204 Dragnea Liviu 412 educatie fizica 10
1520 Popa Marius 452 analiza numerica 7 engleza 9
1.1 Să se aducă tabela CURS_SUDENT la FN1. Pentru aceasta să se creeeze

tabelul CURS_SUDENT modificat corespunzător FN1.
Amintim că o tabelă este în prima formă normală(FN1) dacă valorile tuturor

atributelor care o compun sunt atomice (indivizibile). În plus, nu trebuie să existe atribute
sau grupuri de atribute repetitive.
1.2 Să se aducă tabela CURS_SUDENT la FN2. Pentru aceasta să se creeeze

tabelele CURS_SUDENT modificat corespunzător FN2 şi tabelele SUDENT
şi CURS, rezultate în urma normalizării la FN1.
Amintim că o tabelă este în FN2, dacă este în FN1 şi fiecare atribut care nu face
parte din cheia primară este dependent de întreaga cheie primară.
Pentru a obŃine o relaŃie FN2 se poate aplica regula Casey-Delobel.
α∪β mulŃimea atributelor care intervin în dependenŃele funcŃionale;
α∪γ reprezintă reuniunea determinantului cu restul atributelor lui A.
.
1.3 Este tabela CURS_SUDENT realizată la 1.2 în FN3? (JustificaŃi răspunsul)
2. Să se aducă tabelul Profesor la FN3 şi să se creeze tabela Titlu, rezultat în

urma normalizării
PROFESOR
IdProf Nume Catedra IdTitlu Titlu Salariu
1 Popescu Marin Matematici 1 lector dr. 1300
2 Dragnea Ion Limbi straine 4 asistent 950
3 Iosif Irina Educatie fizica 3 lector 1100
4 Ilie Daniel Informatica 2 conferentiar dr. 1700
5 Savu Cristina Limbi straine 5 prepartor 680
6 Cristea George Fizica 6 profesor dr. 2150
7 Ene Horia Informatica 1 lector dr. 1300
Amintim că o tabelă este în FN3 dacă este în FN2 şi toate coloanele care nu fac
parte din cheia primară sunt mutual independente (depind direct de cheia primară şi
numai de ea)
3. Tabelele Profesor şi Titlu sunt în relaŃia 1:m (un Titlu corespunde la mai
multe cadre didactice).
Tabele de mai sus păstrează regulile de integritate?
Amintim ca regulile de integritate sunt;

- unicitatea cheii primare
- integritatea entităŃii – valorile cheii primare sa fie diferite de valoarea null(o
valoare necunoscuta sau lipseşte)
- integritatea referenŃială ) o cheie secundară trebuie să fie null în întregime
sau să corespundă unei valori a cheii primare asociate.(in tabela asociată
nu trebuie să existe valori fără corespondent).
4. Să se determine anomaliile pentru tabelul Avion (RedundanŃă logică,
Anomalie la inserŃie, Anomalie la ştergere şi Anomalie la modificare).
Avion
A# nume capacitate localitate
1 AIRBUS 250 PARIS
2 AIRBUS 250 PARIS
3 AIRBUS 250 LONDRA
4 CAR 100 PARIS
5 B707 150 LONDRA
6 B707 150 LONDRA
Constrângere:
toate avioanele cu acelaşi nume au aceeaşi capacitate.
5. Să se implementeze FN1 pentru tabelul MASINA:
Persoana Vehicul
Eu R25 - W14 - R21
Tu 205
El R5 - 305
noi BX - 305 - R12 - R25
6. Să se aducă la FN2 tabelul ATASAT_LA, prin spargerea lui în 2 tabele

ATASAT_LA _2A şi ATASAT_LA_ 2B
ATASAT_LA
COD_SALARIAT# JOB_COD NR_PROIECT# FUNCTIA SUM
A
S1 PROGRAMATOR P1 SUPERVIZOR 60
S1 PROGRAMATOR P2 CERCETATOR 25
S1 PROGRAMATOR P3 AUXILIAR 10
S3 VANZATOR P3 SUPERVIZOR 60
S5 INGINER P3 SUPERVIZOR 60
7. Tabelul ATASAT_LA _2A rezultat de la 6. să se aducă la FN3, realizând tabelele

ATASAT_LA _3A şi ATASAT_LA _3B
8. Presupunem că un şantier poate executa mai multe lucrări de bază şi că o
lucrare poate fi executată de mai multe şantiere.
Pentru relaŃia EXECUTA să se specifice dependenŃele, realizând relaŃia
EXECUTA_1!
Avem relaŃiile următoare

LUCRARE(cod_obiectiv#, cod_lucrare#, nume);
SANTIER(nr_santier#, specialitate, sef);
EXECUTA(cod_obiectiv#, cod_lucrare#, nr_santier#, descriere, functie,
conducator, data_inceput, data_sfarsit).
9.Să se aducă relaŃia EXECUTA_1 rezultat de la 8, în FN3 cu regula Casey-

Delobel!
10. Să se aducă la forma BCNF (Forma normală Boyce-Codd )

INVESTESTE_IN(cod_contractant#, cod_obiectiv#, nr_contract, cota_parte),
realizand INVESTESTE_IN _1 şi INVESTESTE_IN_2.
(Formal, o relaŃie R este în forma normală Boyce-Codd dacă şi numai dacă

pentru orice dependenŃă funcŃională totală X → A, X este o cheie (candidat) a
lui R.)
Intrebări
AlegeŃi răspunsurile corecte pentru fiecare din următoarele întrebări cu răspunsuri
multiple. Întrebările pot avea mai multe răspunsuri corecte.
1. SQL este
a. Un limbaj realizat de Dr. E. F. Codd
b. Un limbaj folosit pentru comunicarea cu bazele de date relaŃionale
c. Un limbaj folosit pentru definirea diagramelor ERD
d. Folosit pentru definirea şi modificarea obiectelor unei baze de date
e. Folosit pentru definirea paginilor web

2. O bază de date este
a. O structură denumită de date, cum ar fi un tabel, o vizualizare sau un

index
b. Un produs software furnizat de un producător de baze de date
c. O colecŃie de date interrelaŃionate gestionate ca o singură unitate
d. Definită în acelaşi mod de toŃi producătorii de software
e. Implementată diferit de diferiŃi producători
3. Un sistem de gestionare a bazelor de date este
a. O structură, cum ar fi un tabel, o vizualizare sau un index
b. O colecŃie de date interrelaŃionate gestionate ca o singură unitate
c. Un produs software furnizat de un producător de baze de date
d. Deseori abreviat sub forma DBMS
e. O structură denumită de date, cum ar fi un tabel, o vizualizare sau un

index
4. Exemple de sisteme RDBMS sunt
a. EXCEL
b. MySQL
c. PostgreSQL
d. Oracle Database
e. Microsoft SQL Server
5. Componentele unei baze de date relaŃionale includ
a. RelaŃii
b. Tabele
c. Vizualizări de utilizator
d. Diagrame ERD
e. RestricŃii
6. Printre tipurile de restricŃii care pot fi folosite în bazele de date se numără
a. NOTNULL
b. RelaŃie
c. Cheie primară
d. CHECK
e. Unicitate
7. Scopul normalizării este de a rezolva următoarele probleme
a. Anomalia de inserare
b. Performante reduse
c. Anomalia de creare
d. Anomalia de ştergere
e. Anomalia de actualizare
8. Procesul de normalizare
a. Începe de la tabele, pentru a ajuta proiectanŃii să descopere vizualizările de

utilizator
b. A fost dezvoltat de Dr. E. F. Codd
c. A fost dezvoltat de Oracle
d. Este aplicat sistematic fiecărei vizualizări de utilizator
9. Un identificator unic(cheie)
a. Trebuie determinat înaitea procesului de normalizare
b. Poate fi compus dintr-un singur atribut
c. Poate fi compus din zero sau mai multe atribute
d. Poate fi compus din mai multe atribute concatenate
10. Prima formă normală rezolvă anomaliile cauzate de
a. DependenŃele parŃiale de cheia primară

c. DependenŃele tranzitive
e. RelaŃiile de tip unu-la-mai-mulŃi
11. A doua formă normală rezolvă anomaliile cauzate de
d. Atributele mulŃi valoare
12. A treia formă normală rezolvă anomaliile cauzate de
13. Pentru aducerea în prima formă normală a unei relaŃii ne-normalizate
a. Atributele care depind doar de o parte a cheii sunt eliminate
b. Atributele multivaloare sunt mutate într-o nouă relaŃie
c. Atributele care sunt dependente tranzitiv sunt eliminate
d. Grupurile repetitive sunt mutate într-o nouă relaŃie
e. Identificatorul unic al relaŃiei originale este copiat în noua relaŃie
14. Problemele de dependenŃă parŃială
a. Sunt rezolvate de FN2
b. Sunt rezolvate de FN3

c. Pot apărea în relaŃiile cu chei primare concatenate
d. Apar cand un atribut non-cheie depinde doar de o parte a cheii primare
e. Apar cand un atribut non-cheie depinde de un alt atribut non-cheie
Partea a_II_a Access
1.
1.Deschideti o aplicatie de baze de date.

2.Creati o baza de date noua in diirectorul My Documents.
3.Creati o tabela cu urmatoarele campuri:
Cod_valuta Number
Valuta Currency
Curs Number
4.In tabela create, stabiliti Cod_valuta ca fiind cheie primara.

5.Creati un formulat nou.
6.Cu ajutorul formularului introduceti urmatoarele 5 inregistrari in tabela:
2 euro 35.000
3 dolar 33.000
1 franc
5 lira
4
7.Creati un filtru de tipul Filter By Selection pentru tabela create.

8.Deschideti tabela create.
9.Mutati atributul 3 inaintea atributului 1
10.Salvati datele si deschideti aplicatia de baze de date.
2.
1.Deschideti baza de date 1.mdb.
2.Utilizati instrumentul de cautare, pentru a gasi in tabela Profesor inregistrarea cu
numele Maria.
3.In aceasta inregisrare modificati numele in Alina.
4.Creati o interogare asupra tabelei Profesor, in care afisati toate atributele pentru
profesorii cu o vechime mai mare de 15 ani.
5.Rulati interogarea creata.
6.Creati o interogare asupra tabelei Universitate in care afisati doar campurile 1 si
3.
7.Stabiliti atributul Nr_profesori din tabela Catedra ca fiind indexat fara duplicate.
8.Creati un raport asupra tabelei Profesori.
9.Grupati datele din raport dupa atributul Vechime.
10. Salvati modificarile facute si inchideti aplicatia de baze de date .
3.
1.Deschideti o aplicatie de baze de date.

2.Creati o baza de date noua in directorul My Documents.
A Number (cheie primara)

B Text
A Number
E Date
5.Craeti o legatura intre tabele prin intermediul campului A .

6.Stabiliti atributul E ca fiind indexat fara duplicate.
7.Ctreati un filtr de tipul Filter By Selection pentru prima tabela.
8.Creati o interogare asupra tabelei 2 in care afisati doar canpul 2.
9.Modificati orientarea paginii.
10. Salvati toate datele si inchideti aplicatia de baze de date.

2.Stergeti tabela Informatii, din baza de date.
3.Deschideti tabela Casete si modificati dimensiunea atributului Nume_film la
100.
4.Deschideti un formular existent.
5.Cu ajutorul formei selectati inregisrarea 3 si modificati Nr_casete la 10.
6.Utilizati comanda Undo pentru a reface operatia anterioara.
7.Modificati lungimea unei coloane in tabela Casete.
8.Utilizati instrumentul de cautare, pentru a gasi intregistrarea cu valoarea
Richard Gere pentru atributul Actor.
9.Stergeti aceasta inregistrare.
10. Inchideti aplicatia de baze de date.
4.
1.Deschideti aplicatia de baze de date.
2.Creati o baza de date noua in direcctorul My Documents. Salvati-o cu numele
dumneavoastra.
Inregistrare 1 Number-Long Integer

Inregistrare 2 Text- dimensiune 50
Inregistrare 3 Currency
4.Salvati tabela cu numele Numere.

5.Creati un formular nou asupra tabelei Numere.
6.Salvati formularul cu denumirea Formular Numere.
7.Introduceti 2 inregistrari in tabela Numere. cu ajutorul formei create.
Inregistrare 1 Inregistrare 2 Inregistrare 3

100 Prima valoare 31
300 A doua valoare 32
8.Utilizati instrum,entul de cautare, pentrua gasi inregistrarea in care campul

Inregisrare 3 ia valoare 31.
9.Modificati Prima valoare cu Prima_Valoare.
10.Salvati modificarile facute si inchideti aplicatia de baze de date.
1.Deschideti baza de date cu 4.mdb.

2.Adaugati atributul Adresa_firma tabelei Comenzi.
3.Stergeti tabela Informatii din baza de date.
4.Modificati tipul coloanei Nume_produs in tabela Produs.
5.Creati o interogare asupra tabelei Produs, in caer afisati doar campurile ce au
unitatea de masura « litrii »
6.Creati un raport asupra tabelei Produs.
7.Introduceti in antetul raportului o imagine.
8.Mutati imaginea in partea stanga a antetului.
9.Salvati raportul cu denumirea Raport_Produs.
5.

2.Craeti o baza de date noua cu nmele baza de date pe C:/
3.In baza de date nou create , construiti o tabela cu urmatorele atribute :
Tara Text-dimensiune 20
Data_curenta Date/Time- Short Date
Nume_firma Texe-dimensiune 30
Cheie_primara Autonumber
4.Stabiliti atributul Data_curenta ca find indexat cu dupliacte.

5.Mutati atributul Cheie_primara astfel incat sa devina primul atribut din tabela.
6.Creati o regula de validare pentru atributul Cheie_primara, astfel incat sa nu
primesca valori mai mari de 256.
7.Introduceti in tabela creata 5 inregistrari.
8.Imprimati toate inregistrarile din tabela.
10.Inchideti aplicatia de baze de date.
1.Deschideti baze de date 5.mdb.

2.Creati un filtru de tipul Filter By Selection pentru tabela Carte.
3.Sortarti datele din tabela Autor in ordine alfabetica dupa numele autorului.
4.Aplicati filtrul creat asupra tabelei Carte.
5.Creati un formular pentru tabela Autor.
6.Cu ajutorul formularului selectati inregistrarea 2 si modificati numele autorului.
7.Stergeti inregisrarea cu nr 1 din tabela.
8.Creati un raport asupra tabelei Carte.
9.Modificati dimensiunea paginii din A4 in Letter.
6.
2.Creati o baza de date noua si salvati-o in directorul My Documents.
3.Utilizati functia Help pentru a cauta informatii despre tabele.
4.Creati o tabela noua si denumiti-o Informatii.
5.Introduce-ti in tabela 3 atribute.
6.In tabela creata stabiliti primul camp ca fiind cheie primara.
7.Creati un raport asupra acestei tabele.
8.Grupati datele din raport in functie de al doilea atribut.
9.Salvati raportul cu numele Raport.
10.Inchideti baza de date creata.

3.Stergeti tabela Campuri din baza de date.
4.Modificati lungimea unei coloane in tabela Autor.
5.Creati un formular pentru tabela Autor.
6.Adaugati numele dumneavoastra in antetul formularului creat.
7.Creati o interogare cu date din tabelele Autor si Carte.
8.Salvati interogarea cu numele Query.
7.
2.Creati o baza de date noua datele dumneavoastra pe directorul C :
3.Afisati pe ecran bara de instrumente WEB.
4.Creati o tabela cu urmatoarele atribute :
COD Numeric Byte

NUME Text dimensiune 15 caractere
SUMA Currency Euro
5.Creati o noua tabela cu urmatoarele atribute :
Nr_Crt Autonumber
Cod Numeric Byte
Firma Text dimensiune 20
Adresa Text dimensiune 25
6.Stabiliti in prima tabela ca cheie primara COD.

7.Creati o legatura intre cele doua tabele dupa campul COD
8.Salvati modificarile facute
9.Mutati in tabela 2 campul Firma dupa campul Adresa
10.Inchideti aplicatia de baze de date
1.Deschideti o aplicatie de baze de date

2.Deschideti baza de date 7.mdb
3.Modificati lungimea unei coloane in tabela Catedra
4.Cautati inregistrarea cu nr 3 si modificati cod profesor ca fiind egal cu 10
5.Creati o interogare cu date din tabelele Catedra si Profesor.
6.Sortati datele din tabela Profesor in ordine alfabetica dupa Nume_profesor
7.Creati un raport asupra tabelei Universitate.
8.Modificati orientarea paginii.
9.Imprimati toate datele obtinute in raportul anterior creat
10.Salvati toate modificarile facute si inchideti baza de date.
8.
1.Deschideti o aplicatie de baze de date
2.Creati o baza de date noua in directorul C :
3.Creati o tabela in care introduceti 5 campuri.Dintre acestea 2 vor fi de tip
Text,2 vor fi numerice si 1 de tip data calendaristica
4.Creati un formular nou asupra tabelei create anterior.
5.Cu ajutorul noului formular introduceti in tabela 5 inregistrari
6.Adaugati numele dumneavoastra in antetul formei.
7.Creati o interogare care sa contina numai campurile 1 si 2
9.Imprimati doar inregistrarile selectate din tabela creata
10.Salvati toate datele si inchideti aplicatia de baze de date
1.Deschideti baza de date 8.mdb

2.Deschideti tabela Masini si introduceti urmatorul atribut Nume.
3.Stergeti legatura dintre tabelele Masini si Masini Disponibile
4.Sortati datele din tabela Masini, in ordine crescatoare dupa atributul
Masini_disponibile
5.Creati un raport asupra tabelei Masini
6.Introduceti in subsolul raportului numele dvs.
7.Grupati datele din raport dupa atributul Masini_disponibile
8.Modificati dimensiunea paginii din A4 in Letter
9.Imprimati raportul la o imprimanta disponibila
10.Salvati modificarile facute si inchideti apllicatia de baze de date.
9.
1. Deschideti o aplicatie de baze de date.
2. Creati o baza de date noua in directorul My Documents.
3. Creati o tabela cu urmatoarele campuri:
Numar_intrare Number
Data_intrare Date
Cantitate_intrata Number
Denumire_produs Text
4. In tabela create stabiliti atributul Numar_Intrare ca fiind cheie primara.

5. Creati un formular nou.
6. Cu ajutorul formularului introduceti 5 inregistrari in tabela.
7. Creati un filtru de tipul Filter Exculding Selection.
8. Deschideti tabela creata in Desing View.
9. Mutati atributul 3 inaintea atributului 1.
10. Salvati datele si inchideti aplicatia de baze de date.
1. Deschideti baza de date 9.mdb.

2. Utilizati instrumentul de cautare, pentru a gasi inregistrarea cu valoarea 2 pentru
atributul Cod_caseta din tabela Casete.
3. In aceasta inregistrare modificati numele filmului ca fiind Film5.
4. Creati o interogare asupra tabelei Casete in care afisati doar campurile 1,3,5.
5. Rulati interogarea creata.
6. Creati o interogare asupra tabelei Casete, in care afisati doar campurile pentru care
atributul Tip_film are valoarea Actiune.
7. Stabiliti atributul Nume_film ca fiind indexat cu duplicate.
8. Creati un raport asupra tabelei Casete.
9. Grupati datele din raport dupa atributul Cod_imprumut.
10. Salvati modificarile facute si inchideti aplicatiile de baze de date.
10.
1. Deschideti o aplicatie de baze de date.
2. Creati o baza de date noua in directorul My Documents.
3. Creati o tabela denumita Elevi ce va contine urmatoarele campuri:
Nume_elevi Text
Data_nasterii Date
Varsta Number - Integer
Nr_scoala Number - Integer
4. Creati o tabela denumita Clasa ce va contine urmatoarele campuri :
Nume Text
Clasa Number
Medie Number
Nr_scoala Number - Integer
5. Creati o legatura intre tabela Elevi si tabela Clasa.

6. stabiliti atributul Nr_scoala ca fiind indexat fara duplicate.
7. Creati un filtru de tipul Filter By Form pentru tabela Elevi.
8. Creati o interogare asupra ambelor tabele in care afisati campurile Nume_elevi,
Varsta, Clasa, Media.
9. modificati orientarea paginii.
10. Salvati toate datele si inchideti aplicatia de baze de date.

2. Adaugati urmatorul atribut Numar_telefon tabelei Autor.
3. Stergeti tabela Campuri din baza de date.
4. Modificati lungimea coloanei Nume in tabela Autor la 100 de caractere.
5. Creati o interogare asupra tabelei Carte, in care afisati doar cartile ce au codul mai
mare de 100.
6. Creati un raport asupra tabelei Autor.
7. Introduceti in antetul raportului o imagine.
8. Mutati imaginea in partea stanga a antetului.
9. Salvati raportul cu denumirea Raport autor.
10. Salvati modificarile facute si inchideti aplicatia de baze de date.
11.
1. Deschideti aplicatia de baze de date.
2. creati o baza de date noua si salvati-o in directorul My Documents.
3. Utilizati functia Help pentru a cauta informatii despre tabele.
4. Creati o tabela noua si denumiti-o Informatii.
5. Introduceti in tabela 3 atribute.
6. in tabela creata, stabiliti primul camp ca fiind cheie primara.
7. Creati un raport asupra acestei tabele.
8. Grupati datele din raport in functie de al doilea atribut.
9. Salvati raportul cu numele de Raport.
10. Inchideti baza de date creata.
2. Stergeti tabela Informatii din baza da date.
3. Deschideti tabela Produs si modificati dimensiunea atributului Cantitate.
4. Deschideti formularul Produs.
5. Cu ajutorul formularului selectati inregistrarea 3 si modificati Cantitatea la 250.
6. Utilizati comanda Undo pentru a reface operatia anterioara.
7. Modificati lungimea unei coloane in tabela Comenzi.
8. Utilizati instrumental de cautare, pentru a gasi inregistrarea cu Cod_produs 4.
9. Stergeti aceasta inregistrare.
12.
2. Creati o baza de date noua in directorul My Documents. Salvati-o cu numele
dumneavoastra.
3. Creati o tabela cu urmatoarele campuri:
CNP Number Double

Nume Text dimensiune 50
Data Date/Time Medium Date
4. Salvati tabela cu numele Persoana.

5. Creati un formular nou asupra tabelei Persoana.
6. Salvati formularul cu denumirea Formular Persoana.
7. Introduceti doua inregistrari in tabela Persoana, cu ajutorul formei create.
CNP Nume Data

102 Alina 19-Jun-94
98 Maria 18-Feb-2002
8.Utilizati instrumental de cautare, pentru a gasi inregistrarea cu CNP-ul 102.

9. Modificati numele persoanei in Andrei.

2. Adaugati urmatorul atribut – Adresa_mail – tabelei Profesor.
3. Stergeti tabela De sters din baza de date.
4. Modificati lungimea unei coloane in tabela Profesor.
5. Creati o interogare asupra tabelei Universitate, in care afisati doar campurile care au
valoarea atributului Cod_Catedra mai mare decat 100.
6. Creati un raport asupra tabelei Universitate.
7. Introduceti in antetul raportului o imagine.
8. Mutati imaginea in partea stanga a antetului.
9. Salvati raportul cu denumirea Universitate.
13.
2. Creati o baza de date noua cu numele baza de date pe C:\
3. In baza de date noua creata, construiti o tabela cu urmatoarele atribute :
Oras Text dimensiune 20
Data examinarii Date/Time Short Date
Nume Centru Text dimensiune 30
Numar curent Autonumber
4. Stabiliti atributul Nume Centru ca fiind indexat cu duplicate.

5. Mutati atributul Numar Curent, astfel incat sa devina primul atribut din tabela.
6. Creati o regula de validare pentru atributul Numar Curent, astfel incat sa nu
primeasca valori mai mari de 256.
7. Introduceti in tabela creata 5 inregistrari.
8. Imprimati toate inregistrarile din tabela.
9. Salvati toate datele.

3. Stergeti tabela Informatii din baza de date.
4. Modificati tipul atributului Cantitate, din tabela Produs, din Text in Number.
5. Deschideti formularul Produs.
6. Adaugati numele dumneavoastra in antetul formulaului Produs.
7. Creati o interogare cu date in tabelele Produs si Comenzi in care sa afisati din tabela
Produs campurile Nume_produs si Unitate_de_masura, iar din tabela Comenzi
campurile Nume_firma si Cantitate_ceruta, pentru acele inregistrari pentru care
cod_produs din tabela Produs este egal cu cod_produs din tabela Comenzi.
14.
1. Deschideti aplicatia de baza de date.
2. Creati o baza de date noua si salvati-o in directorul My Documents.
3. Utilizati functia Help pentru a cauta informatii despre tabele.
4. Creati o tabela noua si denumiti-o Informatii.
5. Introduceti in tabele 3 atribute .
6. In tabela creata stabiliti primul camp ca fiind cheie primara .
7. Creati un raport asupra acestei tabele .
8. Grupati datele din raport in functie de al 2-lea atribut .
9. Salvati raportul cu numele Raport.
10. Inchideti baza de date creata .

2. Deschideti tabela Casete imprumutate si introduceti atributul
Data_imprumut de tip Date .
3. Stergeti legatura dintre tabelele Casete si Casete imprumutate.
4. Sortati datele din tabela Casete in ordine descrescatoare dupa atributul
Actor.
5. Creati un raport asupra tabelei Casete .
6. Introduceti in antetul raportului , numele dumneavoastra si data curenta .
7. Grupati datele din raport dupa atributul Tip_film .
8. Modificati dimensiunea paginii din Letter in A4 .
9. Imprimati raportul la o imprimanta disponibila .
10. Salvati modificarile facute si inchideti aplicatia de baza de date .
15.
1. Deschideti aplicatia de baza de date .
2. Creati o baza de date noua cu numele dumneavoastra pe directorul C:
3. Afisati pe ecran bara de instrumente Database .
4. Creati o tabela cu urmatoarele atribute :
Atribut 1 Numeric Byte

Atribut 2 Text dimensiune 15 caractere
Atribut 3 Currency tip Euro
5. Creati o noua tabela cu urmatoarele atribute :
Atribut 1 Numeric Byte

6. Stabiliti in prima tabela ca cheie primara Atribut 1 .

7. Creati o legatura intre cele doua tabele dupa campul Atribut 1.
8. Salvati modificarile facute .
9. Mutati in tabela 2 campul Atribut 5 inaintea campului Atribut 4 .
10.Inchidetai aplicatia de baza de date .

2. Utilizati instrumentul de cautare , pentru a gasi in tabela Profesor inregistrarea
cu numele Maria .
3. In aceasta inregistrare modificati numele in Andreea .
4. Creati o interogare asupra tabelei Profesor , in care afisati toate atributele
pentru profesorii cu o vechime mai mare de 15 ani .
5. Rulati interogarea creata .
6. Creati o interogare aspura tabelei Universitatea in care afisati doar campurile 1
si 3 .
7. Stabiliti atributul Nr_profesori din tabela Catedra ca fiind indexat fara
duplicitate .
8. Creati un raport asupra tabelei Profesori .
9. Grupati datele din raport dupa atributul Vechime .
10.Salvati modificarile facute si inchideti aplicatia de baza de date .
16.
1. Deschideti o aplicatie de baze de date .
2. Creati o baza de date noua in directorul My Documents .
3. Creati o tabela cu urmatoarele campuri :
A Number (Cheie primara)

B Text
A Number
E Date
5. Creati o legatura intre tabelele prin intermediul campului A .

6. Stabiliti atributul E ca fiind indexat fara duplicitate .
7. Creati un filtru de tipul Filter By Selection pentru prima tabela .
8. Creati o interogare asupra tabelei 2 in care afisati doar campul 2.
9. Modificati orientarea paginii .
10.Salvati toate datele si inchideti aplicatia de baze de date .
1. Deschideti baza de date 16.mdb .

2. Adaugati atributul Adresa_firma tabelei Comenzi .
3. Stergeti tabela Informatii din baza de date .
4. Modificati tipul coloanei Nume_produs din tabela Produs .
5. Creati o interogare asupra tabelei Produs , in care afisati doar campurile ce au
unitatea de masura "litri" .
6. Creati un rapot asupra tabelei Produs .
7. Introduceti in antetul raportului o imagine .
8. Mutati imaginea in partea stanga a antetului .
9. Salvati raportul cu denumirea Raport_produs .
10.Salvati modificarile facute si inchideti baza de date .
17.
1. Deschideti o aplicatie de baza de date .
2. Creati o baza de date noua in directorul C :
3. Creati o tabela in care introduceti 5 campuri . Dintre acestea doua vor fi de tip
Text ,doua vor fi numerice si unul de tip data calendaristica .
4. Creati un formular nou asupra tabelei create anterior .
5. Cu ajutorul noului formular introduceti in tabela 5 inregistrari .
6. Adaugati numele dumneavoastra in antetul formei .
7. Creati o interogare care sa contina numai campurile 1 si 2 .
9. Imprimati doar inregistrarile selectate din tabela creata .
10.Salvati toate datele si inchideti aplicatia de baza de date .
1. Deschideti baza de date 17.mdb
2. Stergeti tabela Date din baza de date .
3. Deschideti tabela Casete imprumutate si modificati tipul atributului
Nr_casete_imprumutate ca fiind Integer .
4. Deschideti un formular existent .
5. Cu ajutorul formei selectati intregistrarea 4 si modificati Nr_casete la 15 .
6. Utilizati comanda Undo pentru a reface operatia anterioara .
7. Modificati lungimea unei colane din tabela Produs .
8. Utilizati instrumentul de cautare , pentru a gasi inregistrarea cu valoare Desene
animate pentru atributul Tip_film .
9. Stergeti aceasta inregistrare .
10.Inchideti aplicatia de baza de date .
18.
1. Deschideti aplicatia de baze de date .
2. Creati o baza de date noua in directorul My Documents . Salvati-o cu
numele dumneavoastra .
CNP Number Double

Nume Text dimensiune 50
Data Date/Time Medium Date
4. Salvati tabela cu numele Persoana .

5. Creati un formular nou asupra tabelei Persoana .
6. Salvati formularul cu denumirea Formular Persoana .
7. Introduceti doua inregistrari in tabela Persoana cu ajutorul formei create .
CNP Nume Data

102 Alina 19-Jun-94
98 Maria 18-Feb-2002
8. Utilizati instrumentul de cautare pentru a gasi inregistrarea cu CNP-ul 102 .

9. Modificati numele persoanei in Mihai .
10.Salvati modificarile facute si inchideti baza de date .

3. Stergeti tabela Campuri din baza de date
4. Modificati lungimea unei coloane in tabela Autor .
5. Creati un formular pentru tabela Autor .
6. Adaugati numele dumneavoastra in antetul formularului creat .
7. Creati o interogare cu date din tabelele Autor si Carte .
8. Salvati interogarea cu numele Query .
10.Salvati modificarile facute si inchideti aplicatie de baze de date .
19.
2. Creati o baza de date noua cu numele baza de date pe C:\
3. In baza de date nou creata construiti o tabela cu urmatoarele atributre :
Oras Text dimensiune 20

Data examinarii Date/Time Short Date
Nume centru Text dimensiune 30
Numar curent Autonumber
4. Mutati atributul Numar Curent astfel incat sa devina primul atribut din tabela .
5. Atasati atributului Oras optiunea Indexed with Duplicates .
6. Creati o regula de validare pentru atributul Numar Curent , astfel incat sa nu
primeasca valori mai mari de 256 .
7. Introduceti in tabela creata 5 inregistrari .
8. Imprimati toate inregistrarile din tabela .
9. Salvati toate datele .
10.Inchideti aplicatia de baze de date .
1. Deschideti o aplicatie de baze de date .

3. Modificati lungimea unei coloane in tabela Catedra .
4. Cautati inregistrarea cu nr. 3 si modificati cod profesor ca fiind egal cu 10.
5. Creati o interogare cu date din tabelele Catedra si Profesor
6. Sortati datele din tabela Profesor in ordine alfabetica dupa Nume_profesor
7. Creati un raport asupra tabelei Universitate
8. Modificati orientarea paginii
9. Imprimati toate datele obtinute in raporturi ulterior creat
10. Salvati toate modificarile facute si inchideti baza de date
20.
1. Deschideti aplicatia de baze de date
2. Creati o baza de date noua cu numele dumneavoastra pe C:/
3. In baza de date nou creata construiti o tabela cu urmatoarele atribute
Nume_depozit Text-dimensiune 20
Data_curenta Date/Time- Short Date
Nume_material Text- dimensiune 30
Cod_curent Autonumber
4. Stabiliti atributul Data_curenta ca fiind indexat dublicate

5. Mutati atributul Cod_curent astfel incat sa devina primul atribut din tabela
6. Creati o regula de validare pentru atributul Cod_curent, astfel incat sa nu primeasca
valori mai mari de 256
7. Introduceti in tabela creata 5 inregistrari
8. Imprimati toate inregistrarile din tabela
9. Salvati toate datele
10. Inchideti aplicatia de baze de date

2. Utilizati instrumentul de cautare pentru a gasi inregistrarea cu valoarea 2 pentru
atributul Cod_caseta din tabela Casetei
3. In aceasta inregistrare modificati numele filmului ca fiind Film interesant
4. Creati o interogare asupra tabelei Casete in care afisati doar campurile 2 si 4
5. Rulati interogarea creata
6. Creati o interogare asupra tabelei Casete, in care afisati doar campurile pentru care
atributul Tip_film are valoarea Actiune
7. Stabiliti atributul Nume_film ca fiind indexat cu duplicate
8. Creati un raport asupra tabelei Casete
9. Grupati datele din raport dupa atributul Cod_imprumut
10. Salvati modificarile facute si inchideti aplicatia de baze de date
Partea a_III_a SQL
Întrebări şi Probleme
multiple. Întrebările pot avea mai multe răspunsuri corecte.
1. SQL este
a. Un limbaj orientat spre obiecte
b. Un limbaj procedural
c. Un limbaj nonprocedural
d. Un limbaj declarativ
e. Un limbaj standard
2. Într-un aranjament client/server

a. Componentele software DBMS ruleaza pe server
b. Componentele software DBMS ruleaza pe client
c. Componentele software ale clientului SQL ruleaza pe client
d. Componentele software ale clientului SQL ruleaza pe server
3. Un client SQL in linia de comanda

a. Necesita un sistem bazat pe ferestre
b. Ruleaza pe o mare varietate de platforme client.
c. Necesita un browser web pe client.
d. Afişează datele şi opŃiunile de comandă folosind caracteristici grafice
e. Afişează răspunsurile la comenzi sub formă de mesaje de tip text
4. Un client SQL cu interfata grafica (GUI)
5. Un client SQL bazat pe web

6. ClienŃii SQL oferiŃi de Oracle sunt

a. iSQL
b. Query Analyzer
c. iSQL*Plus
d. SQL*Plus
e. SQLWorksheet
7. ClienŃii SQL oferiŃi de Microsoft sunt

a. iSQL
b. Query Analyzer
c. iSQL*Plus
d. SQL*Plus
e. SQLWorksheet
8. Extensiile SQL create de furnizori

a. Cresc portabilitatea codului SQL
b. Scad portabilitatea codului SQL
c. Contribuie la diferenŃierea produselor oferire de diferiŃi producători
d. Au fost bazate pe cererile pieŃei
e. Sunt compatibile între implementările diferiŃilor producători
9. InstrucŃiunile SQL
a. încep cu un cuvânt cheie reprezentând o comandă
b. Se termină cu un cuvânt cheie reprezentând o comandă
c. încep cu un delimitator, cum ar fi caracterul punct şi virgulă
d. Se termină un delimitator, cum ar fi caracterul punct şi virgulă
e. încep cu o paranteză deschisă
10. Elementele limbajului SQL includ

a. Cuvinte cheie
b. Nume ale obiectelor din baza de date
c. Operatori
d. RestricŃii
e. Constante
11. Elementele limbajului SQL sunt separate prin

a. Virgule
b. Exact un spaŃiu
c. Unul sau mai multe spaŃii
d. Linie nouă
e. LiniuŃe de subliniere
12. Numele obiectelor bazei de date pot include

a. Paranteze
b. LiniuŃe de subliniere
c. Numere
d. Litere
e. Virgule
13. InstrucŃiunile SQL pot li împărŃite în următoarele categorii

a. Limbajul dc definire a datelor (DDI, - Data Definition Language)
b. Limbajul dc selectare a datelor (DSL - Dala Selection Language)
c. Limbajul dc replicare a datelor (DRL - Dala Replication Language)
d. Limbajul pentru controlul datelor (DCL - Data Control Language)
e. Limbajul dc manipulare a datelor (DML - Data Manipulation Language)
14. Limbajul de definire a datelor (DDL - Data Definition Language) include

următoarele instrucŃiuni:
a. SELECT
b. INSERT
c. CREATE
d. ALTER
e. DELETE
15. Limbajul de interogare a datelor (DQL - Data Query Language) include

a. SELECT
b. INSERT
c. CREATE
d. ALTER
e. DELETE
16. Limbajul de manipulare a datelor (DML - Data Manipulation Language) include
a. SELECT
b. INSERT
c. CREATE
d. UPDATE
e. DELETE
Limbajul de definire a datelor - DDL
multiple. ReŃineŃi că întrebările pot avea mai multe răspunsuri corecte.
1. Tipurile de date oferă următoarele avantaje
a. Respectă standardele publicate
b. Oferă un set de comportamente utile pentru utilizatorii bazei
c. Asigură independenŃa faŃă de date
d. RestricŃionează datele din coloane la caractere care au sens în context
e. Ajută sistemul DBMS să stocheze mai eficient datele din coloane
2. Tipurile de date pentru caractere
a. Sunt mai flexibile decât tipurile de date numerice
b. Acceptă atât date cu lungime fixă, cât şi date cu lungime variabilă.
c. Necesită întotdeauna specificarea preciziei şi a scalei
d. Determină completarea coloanelor până la lungimea maximă maximă
e. Pot stoca şiruri de caractere în format specific unei limbi naŃionale
3. Tipurile de date numerice
a. Sunt mai flexibile decât tipurile de date pentru caractere
b. RestricŃionează valorile din coloane la numere şi simboluri înrudite, cum ar fi
virgulele şi simbolul dolar
c. Necesită întotdeauna specificarea preciziei şi a scalei
d. Stochează valori exacte sau aproximative
e. Sunt potrivite pentru a fi folosite în calcule
4. Tipurile numerice standard includ
a. INTEGER
b. NUMBER
c. FLOAT
d. BOOLEAN
e. INTERVAL
5. Tipurile de date temporale standard includ
a. DATETIME
b. DATE
c. TIMESTAMP
d. TIMEZONE
e. TIME
6. Valorile NULL
a. Pot fi folosite pentru reprezentarea datelor care lipsesc sau nu sunt cunoscute
b. Înseamă acelaşi lucru ca şi spaŃiile libere
c. Sunt egale cu alte valori NULL
d. Nu sunt egale cu alte valori NULL
e. Sunt întotdeauna permise în mod prestabilit
7. InstrucŃiunile DDL includ
a. CREATE
b. ALTER
c. DELETE
d. INSERT
e. UPDATE
8. InstrucŃiunea CREATE DATABASE
a. FuncŃionează exact la fel în toate sistemele DBMS relaŃionale
b. Specifieă întotdeauna numele bazei de date
c. Specifieă întotdeauna numele proprietarului bazei de date
d. Poate include parametri specifici producătorului
e. FuncŃionează la fel cu instrucŃiunea CREATE SCHEMA
9. DefiniŃia unei coloane din instrucŃiunea CREATE TABLE poate include
a. Numele tabelului
b. Numele coloanei
c. restricŃie la nivel de tabel
d. clauză DEFAULT
e. O clauză NULL sau NOT NULL
10. Numele unei coloane dintr-un tabel
a. Trebuie să fie specificat în instrucŃiunea CREATE TABLE
b. Trebuie să fie unic în cadrul bazei de date
c. Trebuie să fie unic în cadrul tabelului
d. Poate fi folosit într-un singur index
e. Trebuie să fie specificat în instrucŃiunea ALTER TABLE
11. O restricŃie la nivel de coloană
a. Poate referi una sau mai multe coloane
b. Poate fi inclusă într-o instrucŃiune CREATE TABLE sau ALTER TABLE
c. Foloseşte o sintaxă identică sau aproape identică cu cea a unei restricŃii de
acelaşi tip la nivel de tabel
d. Poate fi folosită oriunde ar putea fi folosită o restricŃie la nivel de tabel
e. Are o sintaxă care diferă de la un tip de restricŃie la altul
12. Sintaxa corectă pentru clauza DEFAULT este
a. DEFAULT (precizie, scală)
b. DEFAULT [NULL | NOT NULL]
c. DEFAULT (expresie)
d. DEFAULT (nume–coloană) REFERENCES name–tabel (nume_coloană.)
e. DEFAULT [UNIQUE | PRIMARY KEY]
13. Sintaxa corectă pentru o restricŃie NOT NULL este
a. nume_coloană tip--de–date IS NOT NULL
b. nume_coloană tip–de–date NOT NULL
c. DEFAULT [NULL | NOT NULL]
d. CREATE NOT NULL INDEX ON nume_coloană
e. nume–coloană REFERENCES NOT NULL
14. Sintaxa corectă pentru o restricŃie UNIQUE este
a. [CONSTRAINT nume—restricŃie] UNIQUE (nume_coloană)
b. [CONSTRAINT nume—restricŃie] UNIQUE (nume_tabel)
c. DEFAULT UNIQUE (nume_coloană)
d. nume_coloană REFERENCES UNIQUE nume_tabel
e. DEFAULT [UNIQUE | PRIMARY KEY]
15. Sintaxa corectă pentru o restricŃie referenŃială este
a. [CONSTRAINT nume—restricŃie] REFERENCES nume_index
b. [CONSTRAINT nume—restricŃie] REFERENCES nume_tabel
c. FOREIGN KEY nume_coloană REFERENCES nume_tabel (nume_coloană)
d. REFERENCES nume—tabel (nume_coloană)
e. nume_coloană REFERENCES UNIQUE nume_tabel
16. InstrucŃiunea CREATE INDEX
a. Poate fi folosită pentru crearea restricŃiilor de unicitate şi cheie primară
b. Poate include cuvântul cheie UNIQUE
c. Trebuie să refere două sau mai multe nume de coloane
d. Poate include cuvintele cheie ASC sau DESC pentru orice coloană
e. Poate specifica ordinea ascendentă sau descendentă pentru una sau mai multe
coloane
17. Instructiunea CREATE VIEW
a. Stochează o interogare în baza de date
b. Poate include cuvântul cheie opŃional CASCADE
c. Poate include cuvântul cheie opŃional OR REPLACE
d. Trebuie să conŃină o comandă DMI, validă
e. Trebuie să conŃină o instrucŃiune SELECT validă
18. Utilizările valide ale instrucŃiunii ALTER TABLE includ
a. Adăugarea coloanelor
b. Modificarea lungimii sau a preciziei coloanelor
d. Eliminarea unei chei primare
e. Adăugarea unei chei primare
19. O instrucŃiune ALTER TABLE nu poate fi folosită pentru
a. Schimbarea tipului de date al unei coloane la un tip numeric dacă în coloana
respectivă există date de alt tip
b. Redenumirea unei coloane
c. Schimbarea unei restricŃii din NULL în NOT NULL pentru o coloană care
conŃine valori nule
d. Eliminarea unei chei exteme care referă o cheie primară
e. Eliminarea unei chei primare dacă există chei exteme care referă cheia
primară
20. InstrucŃiunea DROP poate fi folosită pentru a şterge
a. restricŃie referenŃială
b. Un index
c. Un tabel
d. O coloană dintr-un tabel
e. O vizualizare
Limbajul de interogare a datelor(DQL)
Întrebări şi probleme
1. O instrucŃiune SELECT fără o clauză WHERE

a. Selectează toate coloanele din tabel sau vizualizare
b. Returnează un mesaj de eroare
c. Selectează toate rândurile din tabel sau vizualizare
d. Afişează numai definiŃia tabelului sau a vizualizării
e. Scrie întotdeauna rezultatele într-un fişier jurnal
2. În SQL, ordinea rândurilor din rezultatele interogării

a. Este specificată de clauza SORTED BY
b. Poate fi ascendentă sau descendentă pentru orice coloană
c. În mod prestabilit este descendentă, dacă nu se specifică o altă ordine
d. Este imprevizibilă dacă nu este specificată in interogare
e. Poate fi specificată numai pentru coloanele din setul de rezultate al interogării
3. Operatorul BETWEEN
a. Specifică un domeniu de valori care include şi capetele
b. Poate fi rescris folosind operatorii <= şi NOT <=
c. Poate fi rescris folosind operatorii <= şi >=
d. Selectează rândurile adăugate în tabel într-un anumit interval de timp
e. Nu este inclus în standardul ISO/ANSI
4. Operatorul LIKE standard

a. Foloseşte semne de întrebare drept caractere de înlocuire poziŃionale
b. Foloseşte liniuŃe de subliniere drept caractere de înlocuire poziŃionale
c. Foloseşte liniuŃe de subliniere drept caractere de înlocuire nepoziŃionale
d. Foloseşte simboluri procent drept caractere de înlocuire poziŃionale
e. Foloseşte simboluri procent drept caractere de înlocuire nepoziŃionale
5. O instrucŃiune SQL care confine o funcŃie de agregare

a. Poate conŃine şi coloane calculate
b. Poate conŃine şi coloane obisnuite
c. Trebuie să includă o clauză ORDER BY
d. Trebuie să includă o clauză GROUP BY
e. Nu poate include, în acelaşi timp, o clauză GROUP BY şi o clauză
ORDERBY
6. Când operatorii AND şi OR sunt combinaŃi în aceeaşi clauză WHERE

a. Sistemul SGBD returnează un mesaj de eroare
b. Operatorul AND are prioritate mai mare decât operatorul OR
c. Operatorul AND are prioritate mai mică decât operatorul OR
d. Parantezele, sunt obligatorii
e. Parantezele sunt opŃionale
7. Sintaxa corectă pentru eliminarea valorilor nule din rezultatele interogării este
a. = NULL
b. NOT = NULL
c. <>NULL
d. IS NULL
e. IS NOT NULL
8. FuncŃiile SQL standard pentru şiruri de caractere includ

a. UPPER
b. MIDDLE
c. LOWER
d. SUBSTR
e. EXISTS
9. FuncŃiile, SQL matematice standard includ

a. LENGTH
b. ROUND
c. CAST
d. MIN
e. ABS
10. Operatorul UNION

a. Elimină rândurile duplicate din setul de rezultate
b. Include rândurile duplicate în setul de rezultate
c. Combină două interogări într-o singură interogare de tip join
d. Combină seturile de rezultate a două interogări într-un singur set de
rezultate
e. Este numit JOIN în unele implementări SQL
ScrieŃi instrucŃiunile SQL pentru următoarele probleme
1. GăsiŃi toate filmele din tabelul FILM pentru care MPAA_COD_INCHIRIERE

are altă valoare decât „R".
2. AfişaŃi titlurile şi preŃurile tuturor filmelor pentru care
PRET_VANZARE_DVD este cel puŃin 19.99, dar nu mai mare de 29.99,
ordonate crescător după preŃ.
3. AfişaŃi toate filmele pentru care genul (COD_GEN_FILM) este Comdy şi
categoria MPAA (MPAA _COD_INCHIRIERE) este PG-13, împreună cu
filmele pentru care genul este Drama şi categoria este R.
4. 14. Câte închirieri (tabelul FILM_INCHIRIAT) nu au nici o valoare în coloana
LATE_OR_LOSS_FEE?
5. Câte persoane au un nume de familie (NUME_FAMILIE_PERSOANA) care
conŃine litera „a", majusculă sau minusculă?
6. AfişaŃi toate titlurile de filme care conŃin cuvântul „the", cu sau fără literă
mare.
7. FolosiŃi funcŃia SUM pentru a afla totalul valorilor din coloana
PLATA_INCHIRIAT din tabelul FILM_INCHIRIAT.
8. AfişaŃi primele cinci caractere din numele de familie
(NUME_FAMILIE_PERSOANA) din tabelul PERSOANA, dar eliminaŃi toate
valorile duplicate din setul de rezultate?
9. Din tabelul FILM, afişaŃi toate genurile (COD_GEN_FILM), împreună cu
media preŃurilor pentru DVD (PRET_VANZARE_DVD) pentru fiecare gen,
rotunjită la două poziŃii zecimale.
10. AfişaŃi toate filmele (ID_FILM) care au fost închiriate (tabelul
FILM_INCHIRIAT), cu suma totală strânsă din taxele de închiriere
(PLATA_INCHIRIAT) sau taxele de întârziere sau pierdere
(PLATA_PENALIZARE) pentru filmul respectiv. Sugestie: adunaŃi valorile
PLATA_INCHIRIAT şi PLATA_PENALIZARE, apoi însumaŃi (SUM)
rezultatul respectiv pentru fiecare valoare ID_FILM. Unele valori din
coloana PLATA_PENALIZARE sunt nule, aşa că, dacă nu aveŃi o funcŃie
care să înlocuiască valorile nule cu o altă valoare (zero, în acest caz), veŃi
obŃine valori nule în rezultate. În Oracle, funcŃia se numeşte NVL, în Microsoft
SQL Server se numeşte ISNULL, iar în MySQL se numeşte IFNULL. (Se pare
că nu există o funcŃie echivalentă în D132).
Combinarea datelor din mai multe tabele
l. O subinterogare
a. Poate fi folosită pentru a selecta valorile care vor fi aplicate condiŃiilor din
clauza WHERE
b. Poate fi corelată sau necorelată
c. Reprezintă o cale puternică de calculare a coloanelor
d. Trebuie să nu fie încadrate în paranteze
e. Permite selectarea flexibilă a rândurilor
2. O uniune (join) fără o clauză WHERE sau o clauză JOIN

a. Are ca rezultat un mesaj de eroare
b. Nu returnează nici un rând din setul de rezultate
c. Reprezintă o uniune externă (outer join)
d. Reprezintă o uniune internă (inner join)
e. Are ca rezultat un produs cartezian
3. O uniune externă (outer join)

a. Poate fi scrisă în Oracle SQL folosind un simbol (+) în clauza FROM
b. Poate fi scrisă în Microsoft SQL Server folosind operatorul = sau =* în clauza
WHERE
c. Returnează toate rândurile doar din unul dintre tabele
d. Returnează toate rândurile din unul sau din ambele tabele
e. Poate fi catre stânga, către dreapta sau completă
4. O auto-uniune (self join)

a. Nu poate avea niciodată ca rezultat un produs cartezian
b. Poate fi o uniune internă sau o uniune externă
c. Rezolvă relaŃiile recursive
d. Poate folosi o subinterogare pentru a limita şi mai mult rândurile selectate
e. Implică două tabele diferite
5. O uniune (Join)
a. Combină coloanele din două sau mai multe tabele în rezultatele unei singure
interogări
b. Combină rânduri din interogari multiple într-un singur set de rezultate
c. Este realizată ori de câte ori în clauza FROM sunt specificate mai multe tabele
d. Necesită folosirea unei clauze JOIN
e. Necesită o listă de tabele separate prin virgule în clauza FROM
6. O uniune de egalitate (equijoin)

a. Este cunoscută şi sub numele de uniune externă (outerjoin)
b. Este cunoscută şi sub numele de uniune internă (innerjoiti)
c. Este cunoscută şi sub numele de auto-uniune (selfjoin)
d. Realizează întotdeauna legarea rândurilor folosind o condiŃie de egalitate (=)
e. Realizează întotdeauna legarea rândurilor folosind o condiŃie de inegalitate
(<>)
7. Calificatorii numelor de coloane:

a. Pot fi nume de tabele
b. Pot fi numere care indică poziŃia relativă a tabelelor dîn lista FORM
c. Pot fi pseudonime pentru numele de coloane , definite în clauza FORM
d. Pot fi pseudonime pentru numele de tabele, definite în clauza FORM
8, O uniune încruşişată este:

a. O uniune Naturală
b. N produs cartezian
c. O uniune externă
d. O uniune Internă
9. O clauză JOIN folosind cuvântul cheie USING

a. Nu poate fi folosită atunci când coloanele prin care se face legarea tabelelor
au nume diferite
b. Nu poate fi folosită atunci când coloanele prin care se face legarea tabelelor
au aceleaşi nume
c. Defineşte o uniune internă
d. Defineşte o uniune externă
e. Defineşte o auto-uniune
10. O subinterogare corelată
a. Rulează mai eficient decât o subinterogare necorelată
b. Rulează mai puin eficient decât o subinterogare necorelată
c. Are o interogare internă care refera coloane din interogarea externă
d. Are o interogare externă care refera coloane din interogarea internă
e. Are o interogare internă care nu face nici o referire la coloanele din
interogarea externă
ScrieŃi instrucŃiunile SQL pentru următoarele probleme:
1. AfişaŃi numele şi identificatorul de client ale tuturor persoanelor decedate

(valoarea DATA_MORTII nu este nulă) care încă au conturi de client.
2. AfişaŃi numele angajatilor care au conturi de clienŃi. FolosiŃi uniuni pentru a
stabili ce clienŃi sunt angajaŃi şi ce angajaŃi au conturi de clienŃi.
3. RescrieŃi interogarea anterioară pentru a folosi subinterogări în loc de uniuni.
4. AfişaŃi numele de familie al fiecarui angajat, împreună cu numele de familie
al şefu1ui lor.
5. AfişaŃi numărul de închirieri pentru fiecare format (DVD şi VHS).
6. AfişaŃi numărul de identificare (FILM_ID) şi data la care trebuie returnate
(DATA_RETURNARII) pentru toate filmele închiriate şi încă nereturnate
(coloană RETURNAT_DATA din tabelul FILM_INCH conŃine valori nule),
dar care nu au fost cumpărate (coloană DATA_VANZARII din tabelul
FILM_COPY conŃine valori nule).
7. AfişaŃi numarul de identificare şi titlul filmelor care nu au fost închiriate
niciodată.
8. Folosind subinterogări pentru a filtra rândurile. AfişaŃi titlul filmelor pentru
care în inventar există o copie VHS (MEDIA_FORMAT = ‘V’, iar
DATA_VANZARII are valoarea NULL) dar pentru care nu există copii DVD
(MEDIA_FORMAT = ‚D’ ).
9. RescrieŃi interogarea anterioară folosind o uniune în local unei subinterogări
pentru a găsi filmele în format VHS.
10. AfişaŃi toate filmele pentru care în inventar există mai multe copii în acelaşi
format.
interogărilor avansate
Întrebări şi Probleme
1. FuncŃiile SQL
a. Returnează un set de valori
b. Returnează o singură valoare
c. Pot fi folosite în clauza WHERE a unei instrucŃiuni SQL
d. Pot fi folosite ca pseudonime pentru numele tabelelor intr-o instr. SQL
e. Pot fi folosite în lista de coloane a unei instrucŃiuni SQL
2. FuncŃia REPLACE
a. Înlocuieşte un nume de tabel cu un nume de vizualizare
b. Înlocuieşte numele unei coloane cu pseudonimul coloanei
c. Înlocuieşte un şir de caractere dintr-o coloană cu un alt şir de caractere
d. Înlocuieşte toate valorile dintr-o coloană cu un alt set de valori
e. Înlocuieşte toate rândurile dintr-o vizualizare cu rânduri conŃinând date dintr-
un alt tabel
3. FuncŃia LTRIM
a. Elimină spaŃiile de la sfârşitul şirurilor de caractere
b. Elimină spaŃiile de la începutul şirurilor de caractere
c. Poate fi imbricată cu alte funcŃii
d. înlocuieşte valorile nule cu alte valori în şirurile de caractere
e. Elimină spaŃiile de la începutul şi de la sfârşitul şirurilor de caractere
4. FuncŃia CHAR
a. Este numită CHR în unele implementări SQL
b. Este identică cu funcŃia ASCII în unele implementări SQL
c. Returnează valoarea corespunzătoare unui caracter din setul de caractere ASCII
d. Returnează caracterul corespunzător unei valori
e. Transformă o valoare numerică într-un şir de caractere
5. FuncŃia SIGN
a. Returnează -l daca parametrul furnizat are valoare negativa
b. Returnează 0 dacă parametrul furnizat are valoarea zero
c. Returnează +1 dacă parametrul furnizat are o valoare pozitivă
d. Returnează 0 dacă parametrul furnizat are valoarea NULL
e. Returnează o valoare nulă dacă parametrul furnizat nu este un număr
6. FuncŃia CEILING
a. Rotunjeşte un număr prin adăugire până la primul număr întreg
b. Rotunjeşte un număr prin scădere până la primul număr întreg
c. Returnează întotdeauna un număr întreg
d. Returnează un număr întreg sau o valoare nulă
e. Este numită CEIL în unele implementări SQL
7. FuncŃia FLOOR
a. Rotunjeşte un număr prin adăugire până la primul număr întreg
b. Rotunjeşte un număr prin scădere până la primul număr întreg
c. Returnează întotdeauna un număr întreg
d. Returnează un număr întreg sau o valoare nulă
e. Este numită FLR în unele implementări SQL
8. Expresiile CASE
a. Permit executarea condiŃională a clauzelor dintr-o instrucŃiune SQL
b. Există sub două forme, respectiv statice şi dinamice
c. Exista sub două forme, respectiv cu căutare şi fara cautare
d. Există sub două forme, respectiv simple şi cu cautare
e. Există sub două forme, respectiv standard şi cu cautare
ScrieŃi instrucŃiunile SQL pentru următoarele probleme:
1. AfişaŃi valorile MPAA_RATING_COD din tabelul MPAA_RATING, cu

liniuŃele de despărŃire înlocuite cu spaŃii.
2. Folosind funcŃia CHAR (numită CHR în Oracle), afişaŃi valorile FILM_ID şi
FILM_TITLU pentru toate filmele care conŃin apostrofuri (caracterul ASCII
39) în titlu.
3. AflaŃi valoarea ASCII a semnului de exclamare (!).
4. AflaŃi preŃul mediu al filmelor în format DVD (coloana RETAIL_PRET _DVD
din tabelul FILM), cu media calculată rotunjită prin adăugire la cea mai
apropiată sumă fără zecimale.
5. AflaŃi preŃul mediu al filmelor în format VHS (coloana RETAIL_PRET_VHS
din tabelul FILM), cu media calculată rotunjită prin scădere la cea mai
apropiată sumă fără zecimale.
6. Pentru o bază de date Oracle, generaŃi comenzile SQL pentru eliminarea tuturor
restricŃiilor referenŃiale aflate în proprietatea utilizatorului curent. Vizualizarea
Oracle de tip catalog se numeşte USER_CONSTRAINTS, iar restricŃiile
referenŃiale au valoarea 'R' în coloana CONSTRAINT_TYPE. Numele tabelului
pe care se bazează restricŃia se află în coloana TABLE_NAME a vizualizării.
Nu uitaŃi că trebuie să folosiŃi comanda ALTER TABLE pentru eliminarea unei
restricŃii.
7. Pentru o bază de date Microsoft SQL Server, afişaŃi toate restricŃiile de tip cheie
externă. FolosiŃi tabelul de sistem SYSOBJECTS, în care NAME este numele
restricŃiei, iar coloana XTYPE are valoarea 'F' pentru restricŃiile de tip cheie
externă.
8. ScrieŃi o instrucŃiune SQL care afişează fiecare cont de client
(CLIENT_CONT_ID) cu un şir de caractere bazat pe valoarea coloanei
COPIL_INCH_ALLOWED_INDIC, care să conŃină textul „Poate fi inchiriat de
copii" dacă valoarea coloanei este 'Y' şi textul „Nu poate fi inchiriat de copii"
dacă valoarea este 'N'. Sugestie: Cel mai bine funcŃionează în acest caz o
expresie CASE simplă.
9. ScrieŃi o instrucŃiune SQL care afişează fiecare film (FILM_ID) şi o valoare
pentru deceniu, în funcŃie de valoarea coloanei ANUL_PRODUCERII sau
necunoscut), în acest caz v-ar fi de folos o expresie CASE cu cautare.
10. ScrieŃi o instrucŃiune SQL care afişează fiecare inchiriere a unui film (tabelul
FILM_INCH) cu valoarea TAXA_PENALIZAREclasificaŃa astfel:
None (valoare nulă sau zero), Minor (valoare < 10) sau Major (valoare > 10) .
Limbajul de manipulare a datelor – DML

1. Limbajul DML include următoarele comenzi SQL:

a. INSERT
b. REMOVE
c. UPDATE
d. SELECT
e. DROP
2. O instrucŃiune DML poate referi
a. Coloane din mai multe tabele
b. Coloane dintr-un singur tabel
c. O vizualizare care conŃine coloane dintr-un singur tabel
d. Coloane ale unei vizualizări bazate pe un singur tabel
e. Coloane ale unei vizualizări bazate pe mai multe tabele
3. La formarea unei instrucŃiuni DML, trebuie să tineti seama de următoarele

restricŃii
a. RestricŃii referenŃiale
b. RestricŃii de securitate
c. RestricŃii NOT NULL
d. RestricŃii de unicitate
e. RestricŃii cheie primară
4. O instrucŃiune INSERT cu o clauză VALUES

a. Trebuie să aibă o listă de coloane
b. Trebuie să aibă o listă de valori
c. Poate insera rânduri multiple la o singură rulare
d. Poate folosi cuvântul cheie NULL pentru a atribui valori nule coloanelor
e. Poate include o clauză WHERE
5. O instrucŃiune INSERT cu o comandă SELECT imbricată este utilă pentru

a. Găsirea următoarei valori pentru o cheie primară atribuită secvenŃial
b. Mutarea rândurilor dintr-un tabel în altul
c. Popularea unui tabel de test cu date dintr-un alt tabel
d. Eliminarea rândurilor duplicate dintr-un tabel
e. Inserarea mai multor rânduri într-un tabel cu o singură instrucŃiune
6. O instrucŃiune INSERT cu o comandă SELECT imbricată

a. Trebuie să aibă două liste de coloane, una în clauza INSERT şi una în
b. Trebuie să aibă o instrucŃiune SELECT internă care retumează un singur rând
de date
c. Poate folosi cuvântul cheie NULL pentru a atribui valori nule coloanelor
d. Poate include o clauză WHERE
e. Trebuie să aibă în instrucŃiunea SELECT internă o listă de coloane care
corespunde cu lista de coloane din clauza INSERT sau cu coloanele din tabelul
în care sunt inserate datele
7. O instrucŃiune UPDATE fără o clauză WHERE

a. Actualizează toate rândurile din tabel cu valori nule
b. încearcă să actualizeze toate rândurile din tabel
c. Eşuează şi returnează o eroare
d. Şterge toate rândurile din tabel
8. O instrucŃiune DELETE fără o clauză WHERE
a. Actualizează toate rândurile din tabel cu valori nule
b. Eşuează si returnează o eroare
c. încearcă să şteargă toate rândurile din tabel
d. Are ca rezultat un produs cartezian
e. Trebuie să includă o listă de coloane
9. O instrucŃiune UPDATE
a. Trebuie să includă o clauză SET
b. Trebuie să furnizeze o nouă valoare pentru cel puŃin o coloană
c. Trebuie să includă o clauză WHERE
d. Poate atribui unei coloane valoarea unei alte coloane
e. Poate atribui unei coloane o listă de valori derivate dintr-o expresie
10. O instrucŃiune DELETE

a. Poate include o listă opŃională de coloane
b. Poate include o clauză WHERE opŃională
c. Poate folosi cuvântul cheie FORCE pentru a forŃa ştergerea rândurilor
d. Nu poate încălca restricŃiile referenŃiale ale tabelului
e. Poate avea o instrucŃiune SELECT internă, ca parte a clauzei WHERE
11. Clauza SET dintr-o instrucŃiune UPDATE poate atribui unei coloane o valoare
care este
a. O constantă
b. Numele unei alte coloane
c. O listă de valori
d. Orice expresie din care rezultă o singură valoare
e. Cuvântul cheie NULL
12. InstrucŃiunea SELECT internă a unei instrucŃiuni INSERT poate include

a. O clauză WHERE
b. O clauză GROUP BY
c. Una sau mai multe funcŃii de agregare
d. O uniune a mai multor tabele
e. O clauză UNION
ScrieŃi instrucŃiuni SQL pentru următoarele probleme
13. Folosind o instrucŃiune INSERT cu o clauză VALUES, dar fără listă de

coloane, inseraŃi în tabelul FILM_GENRE un nou rând, cu valorile FILM_COD_GEN =
TRAIN' şi FILM_DESCRIERE_GEN = Training'.
14. Folosind o instrucŃiune INSERT cu o clauză VALUES si o listă de coloane,

inseraŃi în tabelul FILM un nou rând, cu următoarele valori pentru date:
FILM_ID: 99
FILM_COD_GEN: 'TRAIN'
MPAA_COD_RATING: NR
FILM_NUME: ANGAJAT
Training Video
15. Folosind o instrucŃiune INSERT cu o instrucŃiune SELECT internă, inseraŃi

în tabelul FILM_LIMBA un rând pentru limba japoneză (COD_LIMBA = 'ja'),
asociat cu toate filmele din tabelul FILM. (în prezent, tabelul
FILM_LIMBA nu conŃine nici un rând pentru limba japoneză.)
16. CreaŃi un tabel, numit TOTAL_INCHIRIERE, folosind instrucŃiunea

CREATE de mai jos. Folosind o instrucŃiune INSERT cu o instrucŃiune SELECT internă,
inseraŃi în tabelul TOTAL_INCHIRIEREun rând pentru fiecare film din tabelul FILM
INCHIRIERE, conŃinând numărul total de închirieri şi suma totală obŃinută din
închirierea filmului respectiv.
CREATE TABLE TOTAL_INCHIRIERE
(FILM_ID INTEGER NOT NULL,
NUMBER_OF_INCHIRIERES INTEGER NOT NULL,
TOTAL_COST_INCHIRIERES NUMERIC (7, 2) NOT NULL);
17. ŞtergeŃi toate rândurile din tabelul INCHIRIERE TOTAL.
18.ŞtergeŃi rândurile pentru limba japoneză, create la întrebarea 15.
19. Copia 1 a filmului 1 (FILM_ID = 1, NUMAR_COPIE = 1) a fost vândută

pe data de 15 ianuarie 2005. actualizaŃi rândul respectiv din tabelul
FILM_COPII.
20. ActualizaŃi tabelul FILM astfel încât să creşteŃi cu 10 procente toate

preŃurile pentru formatul VHS (RETAIL_PRET_VHS) care nu conŃin valori
nule.
Partea I Concepte despre bazele de date relationale. Normalizare
"1. SQL este
a. Un limbaj realizat de Dr. E. F. Codd
b. Un limbaj folosit pentru comunicarea cu bazele de date relationale
c. Un limbaj folosit pentru definirea diagramelor ERD
d. Folosit pentru definirea si modificarea obiectelor unei baze de date
e. Folosit pentru definirea paginilor web"
Raspuns B, D
"2. O baza de date este
a. O structura denumita de date, cum ar fi un tabel, o vizualizare sau unindex
c. O colectie de date interrelationate gestionate ca o singura unitate
d. Definita în acelasi mod de toti producatorii de software
e. Implementata diferit de diferiti producatori"
Raspuns C, E
"3. Un sistem de gestionare a bazelor de date este
a. O structura, cum ar fi un tabel, o vizualizare sau un index
b. O colectie de date interrelationate gestionate ca o singura unitate
c. Un produs software furnizat de un producator de baze de date
d. Deseori abreviat sub forma DBMS
e. O structura denumita de date, cum ar fi un tabel, o vizualizare sau un index"
C,D
"4. Exemple de sisteme RDBMS sunt
a. EXCEL
b. MySQL
c. PostgreSQL
d. Oracle Database
e. Microsoft SQL Server"
B,C,D,E
"5. Componentele unei baze de date relationale includ
a. Relatii
b. Tabele
c. Vizualizari de utilizator
d. Diagrame ERD
e. Restrictii"
A,B,E
"6. Printre tipurile de restrictii care pot fi folosite în bazele de date se
numara
a. NOT NULL
b. Relatie
c. Cheie primara
d. CHECK
e. Unicitate"
A,C,D,E
"7. Scopul normalizarii este de a rezolva urmatoarele probleme
a. Anomalia de inserare
b. Performante reduse
c. Anomalia de creare
d. Anomalia de stergere
e. Anomalia de actualizare"
A,D,E
"8. Procesul de normalizare
a. Începe de la tabele, pentru a ajuta proiectantii sa descopere vizualizarile
de utilizator
b. A fost dezvoltat de Dr. E. F. Codd
c. A fost dezvoltat de Oracle
d. Este aplicat sistematic fiecarei vizualizari de utilizator"
B,D
"9. Un identificator unic(cheie)
a. Trebuie determinat înaitea procesului de normalizare
b. Poate fi compus dintr-un singur atribut
c. Poate fi compus din zero sau mai multe atribute
d. Poate fi compus din mai multe atribute concatenate"
A,D
"10. Prima forma normala rezolva anomaliile cauzate de
e. Relatiile de tip unu-la-mai-multi"
B,D
"11. A doua forma normala rezolva anomaliile cauzate de
d. Atributele multi valoare
A
"12. A treia forma normala rezolva anomaliile cauzate de
C
"13. Pentru aducerea în prima forma normala a unei relatii ne-normalizate
a. Atributele care depind doar de o parte a cheii sunt eliminate
b. Atributele multivaloare sunt mutate într-o noua relatie
d. Grupurile repetitive sunt mutate într-o noua relatie
e. Identificatorul unic al relatiei originale este copiat în noua relatie"
B,D,E
"14. Problemele de dependenta partiala
a. Sunt rezolvate de FN2
b. Sunt rezolvate de FN3
c. Pot aparea în relatiile cu chei primare concatenate
d. Apar cand un atribut non-cheie depinde doar de o parte a cheii primare
e. Apar cand un atribut non-cheie depinde de un alt atribut non-cheie"
A, C, D
Partea a_III_a SQL

"1. SQL este
a. Un limbaj orientat spre obiecte
b. Un limbaj procedural
c. Un limbaj nonprocedural
d. Un limbaj declarativ
e. Un limbaj standard"
C,D,E
"2. Într-un aranjament client/server
a. Componentele software DBMS ruleaza pe server
b. Componentele software DBMS ruleaza pe client
c. Componentele software ale clientului SQL ruleaza pe client
d. Componentele software ale clientului SQL ruleaza pe server"
A,C,D
"3. Un client SQL in linia de comanda
d. Afiseaza datele si optiunile de comanda folosind caracteristici grafice
e. Afiseaza raspunsurile la comenzi sub forma de mesaje de tip text"
B,E
"4. Un client SQL cu interfata grafica (GUI)
A,D
"5. Un client SQL bazat pe web
B,C,D
"6. Clientii SQL oferiti de Oracle sunt
a. iSQL
b. Query Analyzer
c. iSQL*Plus
d. SQL*Plus
e. SQLWorksheet"
C,D,E
"7. Clientii SQL oferiti de Microsoft sunt
a. iSQL
b. Query Analyzer
c. iSQL*Plus
d. SQL*Plus
e. SQLWorksheet"
A,B
"8. Extensiile SQL create de furnizori
a. Cresc portabilitatea codului SQL
b. Scad portabilitatea codului SQL
c. Contribuie la diferentierea produselor oferire de diferiti producatori
d. Au fost bazate pe cererile pietei
e. Sunt compatibile între implementarile diferitilor producatori"
B, C, D
"9. Instructiunile SQL
a. încep cu un cuvânt cheie reprezentând o comanda
b. Se termina cu un cuvânt cheie reprezentând o comanda
c. încep cu un delimitator, cum ar fi caracterul punct si virgula
d. Se termina un delimitator, cum ar fi caracterul punct si virgula
e. încep cu o paranteza deschisa"
A,D
"10. Elementele limbajului SQL includ
a. Cuvinte cheie
b. Nume ale obiectelor din baza de date
c. Operatori
d. Restrictii
e. Constante"
A,B,C,E
"11. Elementele limbajului SQL sunt separate prin
a. Virgule
b. Exact un spatiu
c. Unul sau mai multe spatii
d. Linie noua
e. Liniute de subliniere"
C
"12. Numele obiectelor bazei de date pot include
a. Paranteze
b. Liniute de subliniere
c. Numere
d. Litere
e. Virgule"
B,C,D
"13. Instructiunile SQL pot li împartite în urmatoarele categorii
a. Limbajul dc definire a datelor (DDl, - Data Definition Language)
b. Limbajul dc selectare a datelor (DSL - Dala Selection Language)
c. Limbajul dc replicare a datelor (DRL - Dala Replication Language)
d. Limbajul pentru controlul datelor (DCL - Data Control Language)
e. Limbajul dc manipulare a datelor (DML - Data Manipulation Language)"
A,D,E
"14. Limbajul de definire a datelor (DDL-Data Definition Language) include urm.
instructiuni:
a. SELECT
b. INSERT
c. CREATE
d. ALTER
e. DELETE"
C,D
"15. Limbajul de interogare a datelor (DQL - Data Query Language) include urm.
instructiuni:
a. SELECT
b. INSERT
c. CREATE
d. ALTER
e. DELETE"
A
"16. Limbajul de manipulare a datelor (DML-Data Manipulation Language) include
instructiuni:
a. SELECT
b. INSERT
c. CREATE
d. UPDATE
e. DELETE"
B,D,E
Limbajul de definire a datelor - DDL

"1. Tipurile de date ofera urmatoarele avantaje
a. Respecta standardele publicate
b. Ofera un set de comportamente utile pentru utilizatorii bazei
c. Asigura independenta fata de date
d. Restrictioneaza datele din coloane la caractere care au sens în context
e. Ajuta sistemul DBMS sa stocheze mai eficient datele din coloane"
B,D,E
"2. Tipurile de date pentru caractere
a. Sunt mai flexibile decât tipurile de date numerice
b. Accepta atât date cu lungime fixa, cât si date cu lungime variabila.
c. Necesita întotdeauna specificarea preciziei si a scalei
d. Determina completarea coloanelor pâna la lungimea maxima maxima
e. Pot stoca siruri de caractere în format specific unei limbi nationale"
A,B,E
"3. Tipurile de date numerice
a. Sunt mai flexibile decât tipurile de date pentru caractere
b. Restrictioneaza valorile din coloane la numere si simboluri înrudite, cum ar
fi virgulele si simbolul dolar
c. Necesita întotdeauna specificarea preciziei si a scalei
d. Stocheaza valori exacte sau aproximative
e. Sunt potrivite pentru a fi folosite în calcule"
D,E
"4. Tipurile numerice standard includ
a. INTEGER
b. NUMBER
c. FLOAT
d. BOOLEAN
e. INTERVAL"
A, C
"5. Tipurile de date temporale standard includ
a. DATETIME
b. DATE
c. TIMESTAMP
d. TIMEZONE
e. TIME"
B,C,E
"6. Valorile NULL
a. Pot fi folosite pentru reprezentarea datelor care lipsesc sau nu sunt
cunoscute
b. Înseama acelasi lucru ca si spaNiile libere
c. Sunt egale cu alte valori NULL
d. Nu sunt egale cu alte valori NULL
e. Sunt întotdeauna permise în mod prestabilit"
A,D
"7. Instructiunile DDL includ
a. CREATE
b. ALTER
c. DELETE
d. INSERT
e. UPDATE"
A,B
"8. Instructiunea CREATE DATABASE
a. Functioneaza exact la fel în toate sistemele DBMS relationale
b. Specifiea întotdeauna numele bazei de date
c. Specifiea întotdeauna numele proprietarului bazei de date
d. Poate include parametri specifici producatorului
e. Functioneaza la fel cu instructiunea CREATE SCHEMA"
B,D
"9. Definitia unei coloane din instructiunea CREATE TABLE poate include
a. Numele tabelului
b. Numele coloanei
c. restrictie la nivel de tabel
d. clauza DEFAULT
e. O clauza NULL sau NOT NULL"
B,D,E
"10. Numele unei coloane dintr-un tabel
a. Trebuie sa fie specificat în instructiunea CREATE TABLE
b. Trebuie sa fie unic în cadrul bazei de date
c. Trebuie sa fie unic în cadrul tabelului
d. Poate fi folosit într-un singur index
e. Trebuie sa fie specificat în instructiunea ALTER TABLE"
A,C
"11. O restrictie la nivel de coloana
a. Poate referi una sau mai multe coloane
b. Poate fi inclusa într-o instructiune CREATE TABLE sau ALTER TABLE
c. Foloseste o sintaxa identica sau aproape identica cu cea a unei restrictii de
acelasi tip la nivel de tabel
d. Poate fi folosita oriunde ar putea fi folosita o restrictie la nivel de tabel
e. Are o sintaxa care difera de la un tip de restrictie la altul"
B,C
"12. Sintaxa corecta pentru clauza DEFAULT este
a. DEFAULT (precizie, scala)
b. DEFAULT [NULL | NOT NULL]
c. DEFAULT (expresie)
d. DEFAULT (nume–coloana) REFERENCES name–tabel (nume_coloana.)
e. DEFAULT [UNIQUE | PRIMARY KEY]"
C
"13. Sintaxa corecta pentru o restrictie NOT NULL este
a. nume_coloana tip--de–date IS NOT NULL
b. nume_coloana tip–de–date NOT NULL
d. CREATE NOT NULL INDEX ON nume_coloana"
B
"14. Sintaxa corecta pentru o restrictie UNIQUE este
a. [CONSTRAINT nume—restrictie] UNIQUE (nume_coloana)
b. [CONSTRAINT nume—restrictie] UNIQUE (nume_tabel)
c. DEFAULT UNIQUE (nume_coloana)
d. nume_coloana REFERENCES UNIQUE nume_tabel"
A
"15. Sintaxa corecta pentru o restrictie referentiala este

a. [CONSTRAINT nume—restrictie] REFERENCES nume_index
b. [CONSTRAINT nume—restrictie] REFERENCES nume_tabel
d. REFERENCES nume—tabel (nume_coloana)
e. nume_coloana REFERENCES UNIQUE nume_tabel"
D
"16. Instructiunea CREATE INDEX
a. Poate fi folosita pentru crearea restrictiilor de unicitate si cheie primara
b. Poate include cuvântul cheie UNIQUE
c. Trebuie sa refere doua sau mai multe nume de coloane
d. Poate include cuvintele cheie ASC sau DESC pentru orice coloana
e. Poate specifica ordinea ascendenta sau descendenta pentru una sau mai multe
coloane"
B,E
"17. Instructiunea CREATE VIEW
a. Stocheaza o interogare în baza de date
b. Poate include cuvântul cheie optional CASCADE
c. Poate include cuvântul cheie optional OR REPLACE
d. Trebuie sa contina o comanda DMI, valida
e. Trebuie sa contina o instructiune SELECT valida"
A,C,E
"18. Utilizarile valide ale instructiunii ALTER TABLE includ
a. Adaugarea coloanelor
b. Modificarea lungimii sau a preciziei coloanelor
d. Eliminarea unei chei primare
e. Adaugarea unei chei primare"
A,B,D,E
"19. O instructiune ALTER TABLE NU poate fi folosita pentru
a. Schimbarea tipului de date al unei coloane la un tip numeric daca în coloana
respectiva exista date de alt tip
b. Redenumirea unei coloane
c. Schimbarea unei restrictii din NULL în NOT NULL pentru o coloana care contine
valori nule
d. Eliminarea unei chei exteme care refera o cheie primara
e. Eliminarea unei chei primare daca exista chei exteme care refera cheia
primara"
A,C,E
"20. Instructiunea DROP poate fi folosita pentru a sterge
a. restrictie referentiala
b. Un index
c. Un tabel
d. O coloana dintr-un tabel
e. O vizualizare"
B,C,E

"1. O instructiune SELECT fara o clauza WHERE
a. Selecteaza toate coloanele din tabel sau vizualizare
b. Returneaza un mesaj de eroare
c. Selecteaza toate rândurile din tabel sau vizualizare
d. Afiseaza numai definiNia tabelului sau a vizualizarii
e. Scrie întotdeauna rezultatele într-un fisier jurnal"
C
"2. În SQL, ordinea rândurilor din rezultatele interogarii
a. Este specificata de clauza SORTED BY
b. Poate fi ascendenta sau descendenta pentru orice coloana
c. În mod prestabilit este descendenta, daca nu se specifica o alta ordine
d. Este imprevizibila daca nu este specificata in interogare
e. Poate fi specificata numai pentru coloanele din setul de rezultate al
interogarii"
BD
"3. Operatorul BETWEEN
a. Specifica un domeniu de valori care include si capetele
b. Poate fi rescris folosind operatorii <= si NOT <=
c. Poate fi rescris folosind operatorii <= si >=
d. Selecteaza rândurile adaugate în tabel într-un anumit interval de timp
e. Nu este inclus în standardul ISO/ANSI"
A,C
"4. Operatorul LIKE standard
a. Foloseste semne de întrebare drept caractere de înlocuire pozitionale
b. Foloseste liniute de subliniere drept caractere de înlocuire pozitionale
c. Foloseste liniute de subliniere drept caractere de înlocuire nepozitionale
d. Foloseste simboluri procent drept caractere de înlocuire pozitionale
e. Foloseste simboluri procent drept caractere de înlocuire nepozitionale"
B,E
"5. O instructiune SQL care contine o functie de agregare
a. Poate contine si coloane calculate
b. Poate contine si coloane obisnuite
c. Trebuie sa includa o clauza ORDER BY
d. Trebuie sa includa o clauza GROUP BY
e. Nu poate include, în acelasi timp, o clauza GROUP BY si o clauza ORDER BY"
A, B
"6. Când operatorii AND si OR sunt combinati în aceeasi clauza WHERE
a. Sistemul SGBD returneaza un mesaj de eroare
b. Operatorul AND are prioritate mai mare decât operatorul OR
c. Operatorul AND are prioritate mai mica decât operatorul OR
e. Parantezele sunt optionale"
B, E
"7. Sintaxa corecta pentru eliminarea valorilor nule din rezultatele interogarii
este
a. = NULL
b. NOT = NULL
c. <>NULL
d. IS NULL
e. IS NOT NULL"
E
"8. Functiile SQL standard pentru siruri de caractere includ
a. UPPER
b. MIDDLE
c. LOWER
d. SUBSTR
e. EXISTS"
A, C, D
"9. Functiile, SQL matematice standard includ
a. LENGTH
b. ROUND
c. CAST
d. MIN
e. ABS"
B,E
"10. Operatorul UNION
a. Elimina rândurile duplicate din setul de rezultate
b. Include rândurile duplicate în setul de rezultate
c. Combina doua interogari într-o singura interogare de tip join
d. Combina seturile de rezultate a doua interogari într-un singur set de
rezultate
e. Este numit JOIN în unele implementari SQL"
A, D
Combinarea datelor din mai multe tabele

"l. O subinterogare
a. Poate fi folosita pentru a selecta valorile care vor fi aplicate conditiilor
din clauza WHERE
b. Poate fi corelata sau necorelata
c. Reprezinta o cale puternica de calculare a coloanelor
d. Trebuie sa nu fie încadrate în paranteze
e. Permite selectarea flexibila a rândurilor"
A,E
"2. O uniune (join) fara o clauza WHERE sau o clauza JOIN
b. Nu returneaza nici un rând din setul de rezultate
c. Reprezinta o uniune externa (outer join)
d. Reprezinta o uniune interna (inner join)
e. Are ca rezultat un produs cartezian"
E
"3. O uniune externa (outer join)
a. Poate fi scrisa în Oracle SQL folosind un simbol (+) în clauza FROM
b. Poate fi scrisa în Microsoft SQL Server folosind operatorul *= sau =* în
clauza
WHERE
c. Returneaza toate rândurile doar din unul dintre tabele
d. Returneaza toate rândurile din unul sau din ambele tabele
e. Poate fi catre stânga, catre dreapta sau completa (outer join)"
a. Poate fi scrisa în Oracle SQL folosind un simbol (+) în clauza FROM
B,D,E
"4. O auto-uniune (self join)
a. Nu poate avea niciodata ca rezultat un produs cartezian
b. Poate fi o uniune interna sau o uniune externa
c. Rezolva relatiile recursive
d. Poate folosi o subinterogare pentru a limita si mai mult rândurile selectate
e. Implica doua tabele diferite"
B,C,D
"5. O uniune (Join)
a. Combina coloanele din doua sau mai multe tabele în rezultatele unei singure
interogari
b. Combina rânduri din interogari multiple într-un singur set de rezultate
c. Este realizata ori de câte ori în clauza FROM sunt specificate mai multe
tabele
d. Necesita folosirea unei clauze JOIN
e. Necesita o lista de tabele separate prin virgule în clauza FROM"
A, C
"6. O uniune de egalitate (equijoin)
a. Este cunoscuta si sub numele de uniune externa (outerjoin)
b. Este cunoscuta si sub numele de uniune interna (innerjoiti)
c. Este cunoscuta si sub numele de auto-uniune (selfjoin)
d. Realizeaza întotdeauna legarea rândurilor folosind o conditie de egalitate
(=)
e. Realizeaza întotdeauna legarea rândurilor folosind o condiNie de inegalitate
(<>)"
B,D
"7. Calificatorii numelor de coloane:
a. Pot fi nume de tabele
b. Pot fi numere care indica pozitia relativa a tabelelor din lista FROM
c. Pot fi pseudonime pentru numele de coloane , definite în clauza FROM
d. Pot fi pseudonime pentru numele de tabele, definite în clauza FROM"
e. Rezolva referinte ambigue la coloane
A, D, E
"8. O uniune încrusisata este:
a. O uniune Naturala
b. Un produs cartezian
c. O uniune externa
d. O uniune Interna"
B
"9. O clauza JOIN folosind cuvântul cheie USING
a. Nu poate fi folosita atunci când coloanele prin care se face legarea
tabelelor au nume diferite
b. Nu poate fi folosita atunci când coloanele prin care se face legarea
tabelelor au aceleasi nume
c. Defineste o uniune interna
d. Defineste o uniune externa
e. Defineste o auto-uniune"
A, C
"10. O subinterogare corelata
a. Ruleaza mai eficient decât o subinterogare necorelata
b. Ruleaza mai puin eficient decât o subinterogare necorelata
c. Are o interogare interna care refera coloane din interogarea externa
d. Are o interogare externa care refera coloane din interogarea interna
e. Are o interogare interna care nu face nici o referire la coloanele din
interogarea externa"
B, C
Scrierea interogarilor avansate

"1. Functiile SQL
a. Returneaza un set de valori
b. Returneaza o singura valoare
c. Pot fi folosite în clauza WHERE a unei instructiuni SQL
d. Pot fi folosite ca pseudonime pentru numele tabelelor intr-o instr. SQL
e. Pot fi folosite în lista de coloane a unei instructiuni SQL"
B, C, E
"2. Functia REPLACE
a. Înlocuieste un nume de tabel cu un nume de vizualizare
b. Înlocuieste numele unei coloane cu pseudonimul coloanei
c. Înlocuieste un sir de caractere dintr-o coloana cu un alt sir de caractere
d. Înlocuieste toate valorile dintr-o coloana cu un alt set de valori
e. Înlocuieste toate rândurile dintr-o vizualizare cu rânduri conNinând date
dintrun
alt tabel"
C
"3. Functia LTRIM
a. Elimina spatiile de la sfârsitul sirurilor de caractere
b. Elimina spatiile de la începutul sirurilor de caractere
c. Poate fi imbricata cu alte functii
d. înlocuieste valorile nule cu alte valori în sirurile de caractere
e. Elimina spatiile de la începutul si de la sfârsitul sirurilor de caractere"
B, C
"4. Functia CHAR
a. Este numita CHR în unele implementari SQL
b. Este identica cu functia ASCII în unele implementari SQL
c. Returneaza valoarea corespunzatoare unui caracter din setul de caractere
ASCII
d. Returneaza caracterul corespunzator unei valori din setul de caractere ASCII
e. Transforma o valoare numerica într-un sir de caractere "
A, D
"5. Functia SIGN
a. Returneaza -l daca parametrul furnizat are valoare negativa
b. Returneaza 0 daca parametrul furnizat are valoarea zero
c. Returneaza +1 daca parametrul furnizat are o valoare pozitiva
d. Returneaza 0 daca parametrul furnizat are valoarea NULL
e. Returneaza o valoare nula daca parametrul furnizat nu este un numar"
A, B
"6. Funtia CEILING
a. Rotunjeste un numar prin adaugire pâna la primul numar întreg
b. Rotunjeste un numar prin scadere pâna la primul numar întreg
c. Returneaza întotdeauna un numar întreg
d. Returneaza un numar întreg sau o valoare nula
e. Este numita CEIL în unele implementari SQL"
A, D, E
"7. Functia FLOOR
a. Rotunjeste un numar prin adaugire pâna la primul numar întreg
b. Rotunjeste un numar prin scadere pâna la primul numar întreg
c. Returneaza întotdeauna un numar întreg
d. Returneaza un numar întreg sau o valoare nula
e. Este numita FLR în unele implementari SQL"
B, D
"8. Expresiile CASE
a. Permit executarea conditionala a clauzelor dintr-o instructiune SQL
b. Exista sub doua forme, respectiv statice si dinamice
c. Exista sub doua forme, respectiv cu cautare si fara cautare
d. Exista sub doua forme, respectiv simple si cu cautare
e. Exista sub doua forme, respectiv standard si cu cautare"
A, D
Limbajul de manipulare a datelor – DML

"1. Limbajul DML include urmatoarele comenzi SQL:
a. INSERT
b. REMOVE
c. UPDATE
d. SELECT
e. DROP"
A, C
"2. O instructiune DML poate referi
a. Coloane din mai multe tabele
b. Coloane dintr-un singur tabel
c. O vizualizare care contine coloane dintr-un singur tabel
d. Coloane ale unei vizualizari bazate pe un singur tabel
e. Coloane ale unei vizualizari bazate pe mai multe tabele"
B, C,E
"3. La formarea unei instructiuni DML, trebuie sa tineti seama de urmatoarele
restrictii
a. Restrictii referentiale
b. Restrictii de securitate
c. Restrictii NOT NULL
d. Restrictii de unicitate
e. Restrictii cheie primara"
A, C D, E
"4. O instructiune INSERT cu o clauza VALUES
a. Trebuie sa aiba o lista de coloane
b. Trebuie sa aiba o lista de valori
c. Poate insera rânduri multiple la o singura rulare
d. Poate folosi cuvântul cheie NULL pentru a atribui valori nule coloanelor
e. Poate include o clauza WHERE"
B, D
"5. O instructiune INSERT cu o comanda SELECT imbricata este utila pentru
a. Gasirea urmatoarei valori pentru o cheie primara atribuita secvential
b. Mutarea rândurilor dintr-un tabel în altul
c. Popularea unui tabel de test cu date dintr-un alt tabel
d. Eliminarea rândurilor duplicate dintr-un tabel
e. Inserarea mai multor rânduri într-un tabel cu o singura instructiune"
A, C, E
"6. O instructiune INSERT cu o comanda SELECT imbricata
a. Trebuie sa aiba doua liste de coloane, una în clauza INSERT si una în
instructiunea SELECT interna
b. Trebuie sa aiba o instructiune SELECT interna care retumeaza un singur rând
de date
c. Poate folosi cuvântul cheie NULL pentru a atribui valori nule coloanelor
d. Poate include o clauza WHERE
e. Trebuie sa aiba în instructiunea SELECT interna o lista de coloane care
corespunde cu lista de coloane din clauza INSERT sau cu coloanele din tabelul în
care sunt inserate datele"
C, D, E
"7. O instructiune UPDATE fara o clauza WHERE
a. Actualizeaza toate rândurile din tabel cu valori nule
b. încearca sa actualizeze toate rândurile din tabel
c. Esueaza si returneaza o eroare
d. Sterge toate rândurile din tabel
e. Are ca rezultat un produs cartezian"
B
"8. O instructiune DELETE fara o clauza WHERE
a. Actualizeaza toate rândurile din tabel cu valori nule
b. Esueaza si returneaza o eroare
c. încearca sa stearga toate rândurile din tabel
d. Are ca rezultat un produs cartezian
e. Trebuie sa includa o lista de coloane"
C
"9. O instructiune UPDATE
a. Trebuie sa includa o clauza SET
b. Trebuie sa furnizeze o noua valoare pentru cel putin o coloana
c. Trebuie sa includa o clauza WHERE
d. Poate atribui unei coloane valoarea unei alte coloane
e. Poate atribui unei coloane o lista de valori derivate dintr-o expresie"
A, B, D
"10. O instructiune DELETE
a. Poate include o lista optionala de coloane
b. Poate include o clauza WHERE optionala
c. Poate folosi cuvântul cheie FORCE pentru a forta stergerea rândurilor
d. Nu poate încalca restrictiile referentiale ale tabelului
e. Poate avea o instructiune SELECT interna, ca parte a clauzei WHERE"
B, D, E
"11. Clauza SET dintr-o instructiune UPDATE poate atribui unei coloane o valoare
care este
a. O constanta
b. Numele unei alte coloane
c. O lista de valori
d. Orice expresie din care rezulta o singura valoare
e. Cuvântul cheie NULL"
A, B, D, E
"12. Instructiunea SELECT interna a unei instructiuni INSERT poate include
a. O clauza WHERE
b. O clauza GROUP BY
c. Una sau mai multe functii de agregare
d. O uniune a mai multor tabele
e. O clauza UNION"
A, B, C, D, E
Adevarat / Fals
Pentru a fi in a treia forma normala , o relatie trebuie sa nu fie in prima forma normala sau in a doua
forma normala:
- Adevarat
- Fals
Pentru a fi in a treia forma normala o relatie nu trebuie sa fie in prima sau a doua forma normala?
- Adevarat
- Fals
Probleme de dependenta tranzitiva apar atunci cand un atribut non-cheie depinde de un alt atribut non-
cheie
- Adevarat
- Fals
Diagrama ERD este un model de date conceptual de nivel înalt, dependent de platforma hardware
utilizată şi de tipul de RDBMS (SGBD) – ului utilizat
- Adevarat
- Fals
Folosind aplicatia Microsoft Access, se poate administra toata informatia într-o singura baza de date
(Database)?
- Adevarat
- Fals
Folosing MSAccess se poate administra toata informatia intr-o singura baza de date ?
- Adevarat
- Fals
A doua forma normala nu rezolva anomaliile cauzate de
a. Dependentele partiale de cheia primară
d. Atributele multi valoare
e. Relatiile de tip unu-la-mai-multi
A doua formă normală rezolvă anomaliile cauzate de

a. Grupurile repetitive
b. Dependentele partiale de cheia primară
c. Grupurile repetitive si atributele multivaloare
d Dependentele tranzitive
A treia forma normala rezolva anomaliile cauzate de : si 4 var de raspuns

a. Dependentele partiale de cheia primară
e. Relatiile de tip unu-la-mai-multi
Atunci când se foloseste operatorul “+” , apare o eroare de tipul Type Mismatch (Nepotrivire de tip) in
cazul cand
a. ambii operanzi sunt valori numerice
b. ambii operanzi sunt siruri de caractere
c. un operand este valoare numerica si celalalt un sir de caractere
d. un operand este valoare numerica si celalalt de tipul date/time
Care din următoarele baze de date nu este RDBMS
a. Postage SQL
b. Oracle Database
c. My SQL
d. Microsoft SQL Server
e. Excel database
Care nu este un concept utilizat pentru a descrie formal-uzual-fizic elementele de baza ale organizarii
datelor
a. relatie-tablou-fisier
b. tuplu-linie-inregistrare
c. atribut-coloana-camp
d. domeniu-functie-functie
Care nu este o interogare de actiune?

a. cu actualizare
b. cu creeare de tabele
c. cu adaugare si stergere
d. cu parametru
Care din interogarile cu actiune pot afecta doar campuri izolate?:

a. cu actualizare
b.cu adaugare
c.cu stergere
d.cu creare de tabele
Clinetii SQL oferiti de Microsoft nu sunt:

a. SqLWorsheet
b. sql PLUS
c. iSql
d. Isql PLUS
Campurile calculate intr-un raport se pot introduce in modul Design View:

a. numai in banda Report Footer
b. numai in banda Group Footer
c. in banda de Detail,Group F.si Report F.
d. numai in banda de Detail
Cind se realizeaza un table cu Report View din tabele relationale, informatiile fiind grupate pe parte one
a relatiei si se opteaza pentru SUMMARY OPTION atunci:
a. se introduc calculele solicitate in banda de subsol de grup
b. se introduc calculele solicitate in banda de detaliu de grup
c. se introduc calculele solicitate in benzile de subsol de grup de subsol de raport
d. se introduc calculele solicitate in banda de detaliu de grup si subsol de grup
Cate reguli a emis Codd / Modelul relational conceput si dezvoltat de E.F. Codd cuprinde un set de
a. 25 reguli
b. 13 reguli
c. 100 reguli
d 15 reguli
Cand operatorii AND si OR sunt combinati in aceeasi clauza WHERE
a. Operatorul AND are prioritate mai mare decat operatorul OR
b. Sistemul DBMS returneaza un mesaj de eroare
c. Operatorul AND are prioritate mai mica decat operatorul OR
Cand operatorii AND §i OR sunt combinati in aceeasi clauza WHERE

a. Sistemul SGBD returneaza un mesaj de eroare
b. Operatorul AND are prioritate mai mare decat operatorul OR
c. Operatorul AND are prioritate mai mica decat operatorul OR
e. Parantezele sunt optionale
Componentele unei baze de date relationale NU includ :

a. Relatii
b. tabele
c. restrictii
d. diagrame ERD
Componentele unei baze de date relationale nu includ:

a.indexuri
b.tabele
c.diagrame ERD
d.restrictii
e.relatii
<!>Criteriul de selectie se poate seta

a. prin intermediul celulei TOTALS + Expression Builder
b. prin intermediul celulei Criteria +Expression Builder sau prin tastarea expresiei
c. prin intermediul celulei Sort + tastarea expresiei
d. prin intermediul celulei TOTALS si Criteria, ambele ambele avand acelasi efect
<!>Criteriul de selectie se poate seta

a. prin intermediul celulei TOTALS + Expression Builder
b. prin intermediul celulei Criteria +Expression Builder sau prin tastarea expresiei
c. prin intermediul celulei Sort + tastarea expresiei
d. prin intermediul celulei TOTALS si Criteria, ambele ambele avand acelasi efect
<!>Calificatorii numelor de coloane NU :

a. rezolva referintele ambigue la coloane
b. pot fi nume de tabele
c. pot fi pseudonime ptr. numele de coloane, definite in clauza FROM
d. pot fi pseudonime pentru numele de tabele, definite in clauza FROM
<!>Calificatorii numelor de coloane NU :

a. rezolva referintele ambigue la coloane
b. pot fi nume de tabele
c. pot fi pseudonime pentru numele de coloane, definite in clauza FROM
d. pot fi pseudonime pentru numele de tabele, definite in clauza FROM
Daca relationarea tabelelor dintr-o interogare s-a facut prin definirea legaturilor implicite (din fereastra
Relationships), atunci:
a. trebuie refacute legaturile in cadrul interogarii
b. acestea sunt ignorate in timpul rularii interogarii
c. adaugarea lor intr-o interogare se face impreuna cu relatiile dintre ele
d. tabelele nu trebuiesc sa fie legate in interogare
Dacă tabelele dintr-o interogare nu sunt legate una de alta fie direct (în interogare), fie indirect (prin
legătură implicită, din fereastra Relationship), Acces afisează
a. Toate combinatiile de înregistrări (produs cartezian) dintre câmpurile tabelelor
b. Numai înregistrările din prima tabelă
c. Numai înregistrările din ultima tabelă
d. Nu afisează nimic
Definitia unei coloane din instructiunea CREATE TABLE nu poate include

a. Numele tabelului …sau [/restrictie la nivel de tabel/]
b. O clauză DEFAULT
c. O clauză NULL sau NOT NULL
d Numele coloanei
<!>Din ferestra Relationships la apasarea butonului Join Type se poate selecta modul in care vor fi
extrase datele din tabele, mod care nu poate fi:
a. numai acele înregistrari în care câmpurile din legatura coincid
b. toate înregistrarile din tabela principala si numai acele înregistrari din tabela corelata în care
câmpurile din legatura coincid.
c. toate înregistrarile din tabela corelata si numai acele înregistrari din tabela principala în care
d. toate inregistrarile din ambele tabele
<!>Din ferestra Relationships la apasarea butonului Join Type se poate selecta modul in care vor fi
extrase datele din tabele, mod care nu poate fi:
a. numai acele înregistrari în care câmpurile din legatura coincid
b. toate înregistrarile din tabela principala si numai acele înregistrari din tabela corelata în care
c. toate înregistrarile din tabela corelata si numai acele înregistrari din tabela principala în care
d. toate inregistrarile din ambele tabele
Expresiile nu se utilizează în
a. Definirea unui criteriu de selectie
b. Crearea unui câmp calculat
c. Actualizarea unor înregistrări într-o interogare
d. Definirea proprietătii Validation Text a unei tabele
Functia AVG(Expr):
a. include campuri de valoare NULL in calcul
b. poate fi folosita intr-o interogare
c. calculeaza media geometrica a datelor din acel camp
d. operanzii din Expr nu pot include o functie definita de utilizator.
Functiile SQL matematice standard NU includ :
-ROUND
-ABS
-CAST
-EXP
Functia LTRIM
a. Elimina spatiile de la sfarsitul sirurilor de caractere
b. Elimina spatiile de la inceputul sirurilor de caractere
c. Poate fi imbricata cu alte functii
d. Inlocuieste valorile nule cu alte valori in sirurile de caractere
e. Elimina spatiile de la inceputul si de la sfarsitul sirurilor de caractere
Integritatea referintiala este un sistem de reguli folosit de Acces pentru a se asigura ca:
a. relatiile intre tabele sunt valide
b. relatiile intre tabele nu se modica
c. relatiile intre tabele sunt valide si ca nu se sterg sau modica accidental datele in legatura
d. nu sunt definite relatii
Integritatea referentială nu se poate seta atunci când

a. Câmpurile în relatie au acelasii tip de date
b. Tabelele nu apartin aceleasi baze de date Access
c. Tabelele apar in aceleasi baze de date Access
d. Câmpul în relatie din tabela principală este cheie primară sau are un index unic
In cadrul diagramei entitate-relatie (ERD) care nu este o entitate speciala

a. Entitate dependentã
b. Entitate tranzitiva
c. Subentitate
d. Superentitate
Interogariea de tip functie

a. poate calcula suma, media, numararea, minimul, maximul, varianta sau deviatia standard
pentru unul sau mai multe câmpuri dintr-o tabela in linia Totals, fie pentru toate înregistrarile, fie
pe unul sau mai multe grupuri de înregistrari
b. poate calcula suma, media, numararea, minimul, maximul, varianta sau deviatia standard pentru unul
sau mai multe câmpuri dintr-o tabela in linia Totals, numai pentru toate înregistrarile
c. poate calcula suma, media, numararea, minimul, maximul, varianta sau deviatia standard pentru unul
sau mai multe câmpuri dintr-o tabela in linia Totals, numai pentru pe un grup de înregistrari
d. prin intermediul liniei Criteria nu pot fi afectate rezultatele calcularii.
Integritatea referentială nu se poate seta atunci când

a. Câmpurile în relatie au acelasii tip de date
b. Tabelele nu apartin aceleasi baze de date Access
c. Tabelele apar in aceleasi baze de date Access
d. Câmpul în relatie din tabela principală este cheie primară sau are un index unic
Limbajul DML nu include următoarea instructiune SQL
a. INSERT
b. UPDATE
c. SELECT …sau [/CREATE /]
d. DELETE
Modelul relational NU are ca regula de integritate structurala :

a. Unicitatea cheii primare
b. Intregritatea entitatii.Atributele cheii primare sunt diferite de valoarea NULL
c. Integritatea referiirii. O cheie externa trebuie sa corespunda unei valori a cheii primare
associate.
d. Integritatea referiirii. O cheie externa trebuie sa fie NULL in intregime, ori sa corespunda unei valori
a cheii primare asociate
Modelul relațional conceput și dezvoltat de E.F. Codd cuprinde un set de

a. 25 reguli
b. 13 reguli
c. 100 reguli
d. 15 reguli
Nu sunt clientii SQL oferiti de Oracle

a. SQL Worksheet
b. My SQL
c. SQL*Plus
d. iSQL*Plus
Nu se selecteaza intr-o interogare

a. un singur câmp prin executarea unui click pe numele unui câmpului
b. un bloc de câmpuri prin click pe primul câmp din bloc, se tine apasata tasta Shift si apoi se executa
click pe ultimul câmp din blocul dorit.
c. mai multor câmpuri dar nesituate intr-un bloc atunci se executa click pe fiecare dintre ele
tinându-se apasata tot timpul tasta Shift
d. toate cimpurile prin dublu-click pe bara de titlu a tabelei sau printr-un singur click pe asterix (*).
Normalizarea nu rezolva anomalia:

a. de creare
b. de stergere
c. de actualizare
d. de inserare
Nu este functie SQL matematica standard:

a. ROUND
b. EXP
c. ABS
d. CAST
Numele unei coloane dintr-un tabel :
a. Nu trebuie sa fie in baza de date
b. Nu trebuie sa fie in cadrul unui tabel
c. Trebuie sa fie specificat in instructiunea ALTER TABLE
d. Trebuie sa fie specificat in instructiunea CREATE TABLE
…sau[/trebuie sa fie unic in cadrul tabelului/]
O interogare parametrizată este o interogare

a. În care una sau mai multe valori ale criteriilor de selectie sunt specificate în mod interactive
b. În care numai una dintre valorile criteriilor de selectie poate fi specificată
c. Care atunci când se rulează afisează o fereastră creată de utilizator
d.Care atunci când se rulează afisează o fereastră proprie în care afisează un rezultat
O uniune incrucisata(cross join)

a. O uniune Naturală
b. N produs cartezian
c. O uniune externă
d. O uniune Internă
O uniune (Join) fara o clauza WHERE sau o clauza JOIN

b. Nu returnează nici un rând din setul de rezultate
c. Reprezintă o uniune externă (outer join)
d. Reprezintă o uniune internă (inner join)
O uniune de egalitate(equijoin):
a. este cunoscuta si sub numele de auto-uniune(slfjoin)
b. este cunoscuta si sub numele de uniune externa(outerjoin)
c. realizeaza intotdeauna legarea randurilor folosind o conditie de egalitate(=)
d. realizeaza intotdeauna legarea randurilor folosind o conditie de inegalitate(<>)
O cheie Primara nu poate fi setata: U click-dreaptape campul dorit sa fie cheie primarasi din meniul
afisat se apasa Primary Key sau U se selecteaza campul respectiv si se apasa butonul de Primary Key
meniul Design View,U se deschide fereastra de definire a unui index caruia i se adreseaza proprietatea
Primary la Yes.
a. cu click dreapta pe campul dorit sa fie cheie primara si din meniul afisat se apasa Primary Key.
b. daca se deschide fereastra de definire a unui index si se creeaza un index caruia i se seteaza
proprietatea Primary la Yes.
c. din FieldProprerties,Indexed,Yes(No Duplicates)
d. daca se selecteaza campul respectiv si se apasa butonul de Primary Key din meniul Design View.
O interogare incrucisata (Crosstab) este realizata dintr-o o interogare de selectie, din care se poate alege
a. toate campurile interogarii
b. cel mult 3 campuri pentru antet de linii, un camp pentru antet coloana si o functie aplicata
valorilor dintr-un camp
c. cal putin 3 campuri pentru antet de linii, si mai multe campuri entru antet coloana si o functie aplicata
valorilor dintr-un cimp
d. nu se poate realiza astfel de interogari
O forma (sau formular) reprezinta modalitatea de a
a. modifica date numai dintr-o singura tabela
b. modifica, adauga, sterge date din mai multe tabele
c. modifica date dintr-o singura interogare
d. modifica date dintr-o interogare si un tabel
O baza de date este

a. O colectie de date interrelationate gestionate ca o singura unitate
c. O structura de date, cum ar fi un tabel, o vizualizare sau un index
d. Definita in acelasi mod de toti producatorii de software
O forma nu poate fi creata

a. pe baza unei interogari de actiune
b. pe baza unui tabel
c. pe baza unei interogari
d. pe baza mai multor tabele
O forma (sau formular) reprezinta modalitatea de a

O cheie Primara nu poate fi setata:

a. cu click dreapta pe campul dorit sa fie cheie primara si din meniul afisat se apasa Primary Key.
b. daca se deschide fereastra de definire a unui index si se creeaza un index caruia i se seteaza
proprietatea Primary la Yes.
c. din FieldProprerties,Indexed,Yes(No Duplicates)
d. daca se selecteaza campul respectiv si se apasa butonul de Primary Key din meniul Design View.
O uniune de egalitate(equijoin):
a. este cunoscuta si sub numele de auto-uniune(slfjoin)
b. este cunoscuta si sub numele de uniune externa(outerjoin)
c. realizeaza intotdeauna legarea randurilor folosind o conditie de egalitate(=)
d. realizeaza intotdeauna legarea randurilor folosind o conditie de inegalitate(<>)
O clauza JOIN folosind cuvantul cheie USING

a. Nu poate fi folosita atunci cand coloanele prin care se face legarea tabelelor au aceleasi nume
b. Nu poate fi folosita atunci cand coloanele prin care se face legarea tabelelor au nume diferite
c. Defineste o uniune externa
d. Defineste o auto-uniune
O interogare cu stergere (Delete Query) poate:

a. sterge doar cimpurile izolate
b. sterge un grup de inregistrari dintr-un tabel
c. sterge un grup de inregistrari dintr-un table sau din mai multe tabele legate intr-o relatie unu-
la- mai- multi daca stergerile in cascada sunt active
d. sterge o inregistrare dintr-un tabel la un moment dat
Operatorul + genereaza eroarea Type Mismatch atunci cand
a. ambii operanzi sunt siruri de caractere
b. ambii operanzi sunt numere
c. un operator este numar si unul sir de caractere
d. un operator este numar si unul data
O interogare incrucisata (Crosstab) este realizata dintr-o interogare de selectie din care se poate alege:
a. toate campurile interogatorii
b. cel mult 3 campuri pt. antet de linii,un camp pt. antet coloana si o functie aplicata valorilor
dintr-un camp.
c. cel putin 3 campuri pt. antet de linii si mai multe campuri penru antet coloana si o functie aplicata
valorilor dintr-un camp.
d. nu se poate realiza astfel de interogari.
O instructiune UPDATE trebuie sa includa:

a. o clauza WHERE
b. o clauza SET
c. o clauza SELECT
d. o clauza INSERT
O interogare parametrizata este o interogare

a. in care una sau mai multe valori ale criteriilor de selectie sunt specificate in mod interactiv
b. in care numai una dintre valorile criteriilor de selectie poate fi specificata
c. care atunci cand se ruleaza afiseaza o fereastra creata de utilizator
d. care atunci cand se ruleaza afiseaza o fereastra proprie in care afiseaza un rezultat
O forma (formulare) reprezinta modalitatea de a:

O interogare MakeQuery nu realizeaza:

a. Realizarea unei copii de siguranta a unei tabele
b. Schimbarea ordinii inregistrarilor dintr-o tabela
c. Crearea unei tabele pentru exportul intr-o alta baza de date MS Access
d. Crearea unei tabele ce va contine numai inregistrari vechi
<!>O interogare cu actiune este o interogare care realizeaza modificari asupra:

a. unei singure inregistrari dintr-un table
b. asupra mai multor inregistrari din una sau mai multe tabele
c. unei singure tabele la un moment dat
d. mai multor tabele la un moment dat
<!>O interogare cu actiune este o interogare care realizeaza modificari asupra:

a. unei singure inregistrari dintr-un table
b. asupra mai multor inregistrari din una sau mai multe tabele
c. unei singure tabele la un moment dat
d. mai multor tabele la un moment dat
Operatorul BETWEEN
a. Specifică un domeniu de valori care include si capetele
c. Selectează rândurile adăugate în tabel într-un anumit interval de timp
d. Nu este inclus în standardul ISO/ANSI
Proprietatea Format se foloseste pt:

a. a seta modul in care campurile de tip text sunt afisate
b. a stoca datele intr-un anumit format
c. a seta modul in care campul de tip numar sunt tiparite
d. a seta modul in care datele sunt afisate si tiparite
Proprietatea de Indexare (Indexed)

a. seteaza un index pe un singur cimp
b. creaza si seteaza un index pe un cimp al unei tabele
c. se foloseste pentru a mari viteza de interogare a unei tabele pe unul sau mai multe campuri
d. afecteaza ordinea de stocare (ordinea fizica) a inregistrarilor
Pentru a crea un raport utilizând generatorul (Report Wizard) avem planul general cu optiunea implicita
a. Columnar
b. Tabular
c. Justified
Pentru a introduce câmpuri calculate într-un raport se foloseşte elemente din bara toolbox
a. Label Box Aa
b. Text Box ab
c. Check
d. Combo Box
Pentru aducerea in prima forma normala a unei relatii ne-normalizate se operatie nu se efectueaza ?
a. Grupurile repetitive sunt mutate intr-o noua relatie
b. Atributele multivaloare sunt mutate intr-o noua relatie
d. Identificatorul unic al unei relatii originale este copiat in noua relatie
Pentru a specifica criterii de selectii pentru o interogare, acestea nu se fac

a. numai pentru un camp
b. pentru mai multe campuri, daca expresiile pentru criteriile de selectie sunt pe aceeasi linie in tabelul
de design, cand Access foloseste operatorul And, adica vor fi returnate numai inregistratile ce
indeplinesc toate criteriile
c. pentru mai multe campuri, daca expresiile pentru criteriile de selectie sunt in linii diferite ale tabelului
de design, cand Access foloseste operatorul Or, adica vor fi returnate numai inregistratile ce indeplinesc
cel putin unul din criteriile de selectie
d. in celula TOTALS a tabelului de design
Problemele de dependenta partiala nu:

a. sunt rezolvate de a 2 forma normala
b. sunt rezolvate de a 3 forma normala
c. apar atunci cand un atribut non-cheie depinde doar de o parte a cheii primare
d. pot aparea numai in relatii cu chei primare concatenate
Pentru realizarea unei interogari cu actualizare nu se efectueaza pasul:
a. se creeeaza o interogare
b. se adauga tabelele si se selecteaza campurile ce se doresc actualizate
c. se stabilesc criteriile de selectie pt acestea,daca exista atunci se apasa butonul Update Query din
meniul Query Type din Toolbar
d. in celula Update To …(aici cred ca e incompleta)
Problemele de dependenta partiala nu:

a. sunt rezolvate de a 2 forma normala
b. sunt rezolvate de a 3 forma normala
c. apar atunci cand un atribut non-cheie depinde doar de o parte a cheii primare
d. pot aparea numai in relatii cu chei primare concatenate

a. se creeeaza o interogare
b. se adauga tabelele si se selecteaza campurile ce se doresc actualizate
c. se stabilesc criteriile de selectie pt acestea,daca exista atunci se apasa butonul Update Query din
d. in celula Update To (aici cred ca e incompleta)
Pentru a introduce câmpuri calculate într-un raport se foloseste din bara toolbox:
a. Label Box Aa
b. Text Box ab
c. Check
d. Combo Box
Prima forma normala rezolva anomaliile cauzate de

a. Grupurile repetitive si atributele multivaloare
b. Dependentele partiale de cheia primara
d. Relatiile de tip unu-la-mai-multi
Pentru a specifica criterii de selctie pentru o interogare, aceste nu se fac

a. numai pentru un cimp
b. penrtru mai multe cimpuri, daca expresiile pentru criteriile de selectie sunt pe aceeasi linie în
tabelul de design, cand Access foloseste operatorul And, adica vor fi returnate numai
înregistrarile ce îndeplinesc toate criteriile.
c. pentru mai multe criterii pe acelasi camp, expresiile sunt în linii diferite ale tabelului de deisgn cand
Access foloseste operatorul Or, adica vor fi returnate acele înregistrari ce îndeplinesc cel putin unul
dintre criteriile de selectie.
d. in celula TOTALS a tabelului design
Relatia m:n devine in modelul relational:

a. tabel asociativ cu cheia primara formata din 2 chei externe pt. cele 2 tabele asociate
b. tabel asociativ cu cheia primara formata din 2 chei externe pt. cele 2 tabele asociate plus eventuale
coloane aditionale
c. chei externe
d. entitate independenta
Sintaxa corectă pentru o restricţie NOT NULL este
a. nume_coloană tip-de-date IS NOT NULL
b. nume_coloană tip_de_date NOT NULL
d. CREATE NOT NULL INDEX ON nume_coloană
Sintaxa corecta pentru o restrictie referentiala este

a. [CONSTRAINT nume—restrictie] REFERENCES nume_index
b. [CONSTRAINT nume—restrictie] REFERENCES nume_tabel
d. REFERENCES nume—tabel (nume_coloana)
Sintaxa corecta pentru eliminarea valorilor nule din rezultatele interogarii este
a. = NULL
b. NOT = NULL
c. <>NULL
d. IS NULL
e. IS NOT NULL
SQL NU este:
a. Un limbaj procedural
b. Un limbaj nonprocedural
c. Un limbaj declarativ
d. Un limbaj standard
Tipurile numerice standard nu includ:

a. INTEGER
b. FLOAT
c. INTERVAL
d. BIGINT
Textul de validare se foloseste

a. pentru a valida datele dintr-un cimp
b. impreuna cu Regula de Validare (Validation Rule) si reprezinta mesajul afisat la incalcarea regulei de
validare
c. impreuna cu Regula de Validare (Validation Rule) si reprezinta mesajul afisat daca nu se incalca
regula de validare
d. pentru a valida datele dintr-o inregistrare
Un model de date reprezinta o colectie integrata de concepte care nu descriu:

a. date
b. relatii dintre date
c. date despre echipa realizatoare a modelului
d. constrangeri existente asupra datelor sistemului real analizat
Un obiect al bazei de date este

a. O structura denumita de date, cum ar fi un tabel, o vizualizare sau un index
c. O colectie de date interrelationale gestionate ca o singura unitate
d. O colectie de inregistrari inrudite, stocate ca o singura unitate
Un sistem de gestionare a bazelor de date, abreviat sub forma DBMS sau RDBMS sau SGBD este
a. o colectie de inregistrari inrudite, stocate ca o singura unitate
b. o colectie de date interrelationate gestionate ca o singura unitate
c. o structura de date, cum ar fi un tabel, o vizualizare sau un index
d. un produs software furnizat de un producator de baze de date
Un sistem de gestionare a bazelor de date :

a. o structura cum ar fi un tabel
b. o colectie de date interrelationate
c. un produs softwer furnizat de un producator
d. o structura denumita date , cum ar fi un tabel
Un câmp calculat într-o interogare

a. Se efectuează pe fiecare înregistrare folosind numai un câmp
b. Afisează rezultatul unei expresii si valoarea este recalculată de fiecare dată când o valoare din
exprese se schimbă
c. Se pot folosi numai la afisarea unor rezultate
d. Se pot folosi numai la definirea unor criterii de selectie sau pentru a determina asupra căror
înregistrări să se execute o actiune
Valorile NULL
a. pot fi folosite pentru reprezentarea datelor care lipsesc sau care nu sunt cunoscute
b. înseamnă acelaşi lucru ca şi spaţiile libere
c. sunt egale cu alte valori NULL
d. sunt întotdeauna permise în mod prestabilit
Un identificator unic (cheie) poate fi compus...

- am raspuns : poate fi compus din mai multe atribute concatenate
Pentru realizarea unor interogari grupate...

- am raspuns: se realizeaza o interogare de selectie din tabelele dorite si se selecteaza pentru
anumite campuri o functie de celula Total.
Daca integritatea referentiala este setata:

- am raspuns: nu se poate valoarea unei chei primare in tabela principala, daca acea inregistrare
are inregistrari corelate in tabela secuindara.
Functia NOW() intoarce:

- am raspuns: data si timpul exact conform cu data si ora sistemului
Prin operatia Export se poate

- am raspuns: exporta dintr-o baza de date access intr-o alta baza de date access
Proprietatea Format se foloseste pentru

- am raspuns: a seta modalitatea in care datele sunt afisate si tiparite
Daca integritatea referentiala este setata

- am raspuns: nu se poate schimba valoarea unei chei primare
In meniul Tools ce apartine database Utilities nu exista
- am raspuns: memo
Problemele de dependenta partiala Nu

- am raspuns: sunt rezolvate de FN3
Relatia m:n devine in mod relational

- am raspuns: tabel asociativ in care o inregistrare din A poate avea mai multe in B si invers
Pentru a crea un raport utilizand report Wizard avem planul general cu optiunea implicita
- am raspuns: tabular
O instructiune Alter Table nu poate fi folosita pentru

- am raspuns: redenumirea unei coloane
DDL nu include urmatoarea instructiune

- am raspuns: DELETE
Un identificator unic (o cheie primara)

- am raspuns: poate fi compus dintr-un singur atribut
O interogare cu stergere (Delete Query)

- am raspuns : sterge un grup de inregistrari dintr-un tabel sau din mai multe tabele legate printr-o
relatie unu la mai multi daca stergerile in cascada sunt active.
Componentele unei baze de date relationale nu includ

- am raspuns : diagrame ERD
O uniune fara clauza WHERE sau o clauza Join

- am raspuns are ca rezultat un produs cartezian
Operatorul BETWEEN
a. Specifică un domeniu de valori care include si capetele
c. Selectează rândurile adăugate în tabel într-un anumit interval de timp
d. Nu este inclus în standardul ISO/ANSI
O instructiune DELETE nu
a. Poate include o listă optională de coloane
b. Poate include o clauză WHERE optională
c. Nu poate încălca restrictiile referentiale ale tabelului
d. Poate avea o instructiune SELECT internă, ca parte a clauzei WHERE
Functiile SQL standar pt.siruri de caractere NU includ

- Upper
-LOWER
-...
-LIKE - raspuns LIKE
Care este secvenţa corectă pentru a şterge toate înregistrările tabelului TOTALURI
- DELETE FROM TOTALURI
Access permite crearea unor relaţii logice sub forma unor legări între tabele
- temporale (la nivelul interogărilor) şi implicite (din fereastra Relationships)
O interogare cu creare de tabele (Make-tables Query) nu realizează

- crearea unor tabele pentru exportul într-o bază de date MS Access
Pentru realizarea unor interogări grupate

- se selectează pentru toate câmpurile o funcţie în celula Totals
Un obiect al unei baze de date este

- o structură, cum ar fi un tabel, o vizualizare sau un index
Pasii pentru conversia unei baze de date NU sunt:

- deschiderea bazei ce urmeaza a fi convertita
O instructiune SELECT fara o clauza WHERE

- va selecta toate randurile din tabel sau vizualizare
Instructiune SQL prin care se cerea sa se stearga toti profesorii din tabel.
- DELETE profesori FROM tabel
table cod fac, denumire adresa

care este secventa corecta pentru o inserare folosind instructiunea SELECT
-INSERT INTO FAC
SELECT VALUES(MAX(COD_FAC)+1, 'LIMBI', 'ION GHICA');
-INSERT INTO FAC
FROM FAC;
-INSERT INTO FAC
FROM FAC;
table prof cod fac, cod prof,nume, prenume, salariu, cod functie
care este secventa corecta , pentru a modifica functia si salariu prof cu (cod_fac=2 cod_prof=1) din
lector(cod_funct=3, salariu 2000) la conferentiar(cod_funct=4, salriu=3000)?
-UPDATE PROF SET COD_FUNCT=4, SALARIU=3000
WHERE COD_FAC=2 AND COD_PROF=1;
-UPDATE PROF SELECT COD_FUNCT=4, SALARIU=3000
WHERE COD_FAC=2 AND COD_PROF=1;
-UPDATE PROF SET COD_FAC=2 AND COD_PROF=1
WHERE COD_FUNCT=4, SALARIU=3000;
2 tabele a. ca cel de la nr 12 b.functii
cod functii, den functii
care este secventa corecta pentru o subinterogare necorelata, care sa afiseze toate functiile pentru care nu
exista profesorii incadrati
-SELECT cod_funct, nume_funct
FROM functii
(SELECT DISTINCT cod_funct FROM prof)
FROM functii WHERE cod_funct NOT IN
SELECT DISTINCT cod_funct FROM prof
FROM functii
WHERE cod_funct IN
(SELECT cod_funct FROM prof);
Pt. tabelul:
PROF cod_fac# cod_prof# nume prenume salariu
care este secvența corectă pt. a insera o înregistrare:
• INSERT INTO PROF VALUES (4, 3, ’POPA’, ’DAN’, 1234)
• INSERT INTO PROF VALUES (4, 5, POPA, DAN, 1234)
• INSERT INTO PROF (cod_prof, nume, prenume, salariu) VALUES (4, 3, ’POPA’, ’DAN’, 1234)
Pt. tabelul:
PROF cod_fac# cod_prof# nume prenume salariu
care este secvența corectă pt. a afișa toate facultățile pt. care COD_FAC=1 și salariu>=1200, sau
facultățile pt. care COD_FAC=3 și salariu<2000
• SELECT COD_FAC, COD_PROF, NUME, SALARIU, FROM PROF WHERE (COD_FAC=1
AND SALARIU>1200) OR (COD_FAC=3 AND SALARIU<2000)
Au mai fost 3 variante asemănătoare unde erau înlocuite AND cu OR
Care nu sunt instructiuni SQL?

Limbajul dc replicare a datelor (DRL - Dala Replication Language)
Limbajul de manipulare a datelor (DML - Data Manipulation Language) NU include:

CREATE
Tipurile de date temporale standard NU includ

TIMEZONE
Text boxurile unei forme create automat

sint legate direct la mai multe tabele astfel incit orice modificare adusa valorilor din ele se
transmite..
O interogare SQL din care trebuie selectati din tabelul PROF profesorii care au codul facultatii
(COD_FAC) egal cu 8
a. SELECT FROM PROF WHERE COD_FAC=8;
b. SELECT FROM PROF WHERE COD_FAC<>8;
c. SELECT FROM PROF WHERE COD_FAC IS 8; (asa imi aduc aminte aici, dar daca nu era IS era tot
o balarie)
Pentru tabelul PROF Cod_fac# | Cod_prof# | Nume | Pren | Salariu
Care este secventa corecta pentru a modifica salariile cu 10%, care nu contin valori NULL?
a. UPDATE PROF SET SALARIU = SALARIU*1.1
WHERE SALARIU NOT NULL;
b. UPDATE PROF SET SALARIU = SALARIU*1.1
WHERE SALARIU IS NOT NULL
c. UPDATE PROF SELECT SALARIU = SALARIU*1.1
WHERE SALARIU <> 0;
O cheie primara (Primary Key)

reprezinta un mod unic de identificare a unei înregistrari într-o tabela.
a. nu este un index
b. este un idex creat numai pe un cimp
c. este un idex creat pe minimum doua cimpuri
Dacă tabelele dintr-o interogare nu sunt legate una de alta fie direct (în interogare), fie indirect (prin
legătură implicită, din fereastra Relationship), Acces afișează
• Toate combinațiile de înregistrări (produs cartezian) dintre câmpurile tabelelor
• Numai înregistrările din prima tabelă
• Numai înregistrările din ultima tabelă
• Nu afișează nimic
Textul de validare se foloseste

Raspuns: impreuna cu Regula de Validare si reprezinta mesajul afisat la incalcarea regulei de
validate
Numerele stocate in campuri nenumerice ale unei interogari sunt stocate

Raspuns: ca siruri de caractere (celelalte variante erau ca siruri numerice, se pune in fata 0 pt
numerele mici si nu se accepta sortarea)
Un camp calculat intr-o interogare

Raspuns: afiseaza rezultatul unei expresii si valoarea este recalculata de fiecare data cand o
valoare din expresie se schimba)
Pentru aducerea in prima forma normala a unei relatii ne-normalizate ce operatie nu se efectueaza
Raspuns: nu mai tin minte cum era formulat ceva despre atribute dependent tranzitive, oricum era
singurul care nu avea legatura cu FN1
O insctructiune SELECT fara o clauza WHERE

Raspuns: selecteaza toate randurile din tabel sau vizualizare
Tabelul PROF cu coloanele cod_fac, cod_prof, nume, ore, salariu se intreba care este secventa corecta
pentru a afisa suma salariilor tuturor profesorilor (de la toate facultatile)
Raspuns:
SELECT SUM(salariu) AS TotalSalarii
FROM PROF
GROUP BY
Se dadea tabelul FAC cu campurile cod_fac, denumire si adresa si se intreba care este varianta corecta
pentru introducerea unei noi inregistrari
Raspuns:
INSERT INTO FAC
(cod_fac, denumire, adresa)
SELECT VALUES (MAX(cod_fac)+1, 'o demunire', 'o adresa');
Utilizarile valide ale instructiunii ALTER TABLE nu include

Raspuns: Redenumirea unui tabel
Operatorul LIKE
Raspuns: Foloseste caracterul procent drept caracter de inlocuire nepozitional
O interogare SQL prin care se solicita afisarea rotunjirii mediei salariilor profesorilor, cu 2 zecimale,
grupat dupa facultati.
Aici a fost ceva ciudat. O varianta era cu SORTED BY, una era cu expresia numerica fara o paranteza si
2 erau identice, si aici ma refer la semne de punctuatie, paranteze, spatii, etc.
Aceste 2 variante identice aveau si formatul corect din punctul meu de vedere:
SELECT ROUND(AVG(expresie numerica),2)AS salarii
FROM prof GROUP BY COD_FAC;
Care nu este un concept utilizat pentru a descrie formal-uzual-fizic elementele de baza ale organizarii
datelor:
raspuns: domeniu- functie-functie
Un sistem de gestiune al bazelor de date este:
raspuns : un produs software furnizat de un producator de baze de date
Numerele stocate in campuri nenumerice ale unei interogari sunt sortate:
raspuns: ca siruri de caractere
Care nu este restrictie (Tipuri de restrictii)
raspuns: relatie ( mai erau variantele primary key, not null, check)
Functia NOW() ...
raspuns: returneaza data si ora sistemului
Eliminarea valorilor nule ...
raspuns: IS NOT NULL
57. Instructiunile SQL ....
raspuns: incep cu un cuvant cheie si se termina cu caracterul;
58. Intr-un aranjament client server:
raspuns: componentele soft ale clientului SQL ruleaza pe client
O auto-uniune:
raspuns: autouniunea foloseste un singur tabel
extensiile procedurale ale limbajului sql includ:java,c++,php, oracle pl/sql
pt tabelul ...
raspuns INSERT INTO PROF(cod_prof nume, prenume, salariu) NAMES (4,3,POPA,DAN,1234)
nu este functie sql standard pt siruri de caractere:upper, lenght, lower, like
pt tabelul...
raspuns SELECT DISTINCT DENUMIRE FROM FAC WHERE 1000<(SELECT sum(salariu)
O uniune join --combina coloanele din doua sau mai multe tabele in rezultatul unei singure
interogari
un sistem dbms nu ofera serviciul- - mecanisme de securitate
un index poate fi creat pe urmat tipuri-- text number, currency sau date and time
daca relationarea tabelelor dintr-o interogare s-a facut prin definirea legaturilor implicite atunci:
- adaugarea lor intr-o interogare se face impreuna cu relatiile dintre ele
interogarea cu stergere sterge.. daca stergerile in cascada sint active
prin operatia de import nu se pot introduce in baza de date
- tabele de informare din baze de date in versiuni mai vechi..
prima forma normala rezolva anomaliile
- grupuri repetitive si atribute multivaloare
integritatea referentiala este un sistem de reguli folosit de acces pt a se asigura ca :
relatiile intre tabele sint valide
care nu este un concept utilizat pt a descrie formal- uzual- fizic
- domeniu-functie- functie
text boxurile unei forme create automat
- sint legate direct la mai multe tabele astfel incit orice modificare adusa valorilor din ele se
transmite..
Numerele stocate in campuri nenumerice ale unei interogari sunt sortate:

a.ca siruri de caractere
a)se creeeaza o interogare
b)se adauga tabelele si se selecteaza campurile ce se doresc actualizate
c)se stabilesc criteriile de selectie pt acestea,daca exista atunci se apasa butonul Update Query din
d) NU.......(aici este o varianta de raspuns care incepe cu NU...si aceasta este cea corecta )
Tabelul PROF cu coloanele cod_fac, cod_prof, nume, ore, salariu se intreba care este secventa corecta
pentru a afisa suma salariilor tuturor profesorilor :
SELECT SUM(salariu) AS TotalSalarii FROM PROF
Intr-un aranjament client/server NU :

(componentele softwer DBMS ruleaza pe un client )
Definitia unei coloane din instructiunea CREATE TABEL NU poate include :

Numele tabelului
O uniune Join fara o clauza WHERE sau o clauza JOIN:

Are ca rezultat un produs cartezian
Dacă o tabelă din baza de date cerută care a fost legată de o tabelă externă, se şterg
- se şterge şi legătura sa, nu însă şi fişierul extern de care a fost legat
LABORATOR 1 SQL
CERERI MONOTABEL
1. Analizaţi sintaxa simplificată a comenzii SELECT. Care dintre clauze sunt obligatorii?
SELECT { [ {DISTINCT | UNIQUE} | ALL] lista_campuri | *}
FROM [nume_schemă.]nume_obiect ]
[, [nume_schemă.]nume_obiect …]
[WHERE condiţie_clauza_where]
[GROUP BY expresie [, expresie …]
[HAVING condiţie_clauza_having] ]
[ORDER BY {expresie | poziţie} [, {expresie | poziţie} …] ]
2. Găsiţi eroarea din instrucţiunea următoare.
SELECT employee_id, last_name, salary * 12 salariu anual
FROM employees;
Obs: SALARIU ANUAL este un alias pentru câmpul care reprezintă salariul anual.
Dacă un alias conţine blank-uri, el va fi scris obligatoriu între ghilimele. Altfel, ghilimelele pot fi
omise. Alias-ul apare în rezultat, ca antet de coloană pentru expresia respectivă. Doar cele specificate între
ghilimele sunt case-sensitive, celelalte fiind scrise implicit cu majuscule.
Varianta 1:
SELECT employee_id, last_name, salary * 12 salariu_anual
FROM employees;
Varianta 2:
SELECT employee_id, last_name, salary * 12 " Salariu Anual "
FROM employees;
3. Să se listeze structura tabelelor din schema HR (EMPLOYEES, DEPARTMENTS, JOB_HISTORY,

JOBS, LOCATIONS, COUNTRIES, REGIONS), observând tipurile de date ale coloanelor.
Obs: Se va utiliza comanda SQL*Plus
DESCRIBE nume_tabel
4. Să se listeze conţinutul tabelelor din schema considerată, afişând valorile tuturor câmpurilor.
Obs: Se va utiliza comanda SQL
SELECT * FROM nume_tabel;
5. Să se obţină încă o dată rezultatul cererii precedente, fără a rescrie cererea.
Obs: Ultima comandă SQL lansată de către client este păstrată în buffer-ul SQL.
Pentru rularea acesteia se utilizează “/” sau RUN.
6. Listaţi structura tabelului EMPLOYEES şi apoi daţi comanda RUN (sau “/”). Ce observaţi? Comenzile
SQL*Plus sunt păstrate în buffer?
DESC employees
RUN
1
7. Să se afişeze codul angajatului, numele, codul job-ului, data angajării. Salvaţi instrucţiunea SQL într-un
fişier numit p1_14.sql.
Obs: Pentru salvarea ultimei comenzi SQL se utilizează comanda SAVE. Precizarea extensiei „.sql” a
fişierului nu este obligatorie.
SELECT employee_id, last_name, job_id, hire_date
FROM employees;
SAVE z:\…\ p1_14.sql
8. Reexecutaţi cererea folosind fişierul p1_14.sql.
START z:\…\ p1_14.sql
sau
@ z:\…\ p1_14.sql
9. Editaţi fişierul p1_14.sql, adăugând coloanelor câte un alias (cod, nume, cod job, data angajarii).
EDIT z:\…\ p1_14.sql
Cererea se modifică astfel:

SELECT employee_id cod, last_name nume, job_id " cod job ", hire_date " data angajarii "
FROM employees;
@ z:\…\ p1_14.sql
10. Să se listeze, cu şi fără duplicate, codurile job-urilor din tabelul EMPLOYEES.

SELECT job_id FROM employees;
SELECT DISTINCT job_id FROM employees;
SELECT UNIQUE job_id FROM employees;
Obs. DISTINCT = UNIQUE
11. Să se afişeze numele concatenat cu prenumele, separate prin spaţiu. Etichetaţi coloana “Nume si
prenume”.
Obs: Operatorul de concatenare este “||”. Şirurile de caractere se specifică între apostrofuri (NU ghilimele,
caz în care ar fi interpretate ca alias-uri).
SELECT last_name|| ' ' || first_name " Nume si prenume "
FROM employees;
12. Să se listeze numele şi salariul angajaţilor care câştigă mai mult de 10000 $.
SELECT last_name, salary
FROM employees
WHERE salary > 10000;
13. Să se modifice cererea anterioară astfel încât să afişeze numele şi salariul pentru toţi angajaţii al căror
salariu este cuprins între 5000$ şi10000$.
Obs: Pentru testarea apartenenţei la un domeniu de valori se poate utiliza operatorul
[NOT] BETWEEN valoare1 AND valoare2
FROM employees
WHERE salary BETWEEN 5000 AND 10000;
14. Să se creeze o cerere pentru a afişa numele angajatului şi numărul departamentului pentru angajatul 104.
2
SELECT last_name, department_id
FROM employees
WHERE employee_id =104;
15. Să se afişeze numele şi salariul pentru toţi angajaţii din departamentele 10 sau 30, în ordine alfabetică a
numelor.
Obs: Apartenenţa la o mulţime finită de valori se poate testa prin intermediul operatorului IN, urmat de
lista valorilor între paranteze şi separate prin virgule:
expresie IN (valoare_1, valoare_2, …, valoare_n)
FROM employees
WHERE department_id IN (10, 30)
ORDER BY last_name;
16. Să listeze numele şi salariile angajaţilor care câştigă mai mult de 10000 $ şi lucrează în departamentul 10
sau 30. Se vor eticheta coloanele drept Angajat si Salariu lunar.
17. Care este data curentă?
Obs: Pseudocoloana care returnează data curentă este SYSDATE. Pentru completarea sintaxei obligatorii
a comenzii SELECT, se utilizează tabelul DUAL:
SELECT SYSDATE
FROM dual;
Datele calendaristice pot fi formatate cu ajutorul funcţiei TO_CHAR(data, format), unde formatul poate fi
alcătuit dintr-o combinaţie a următoarelor elemente:
Element Semnificaţie
D Numărul zilei din săptămână (duminică=1;
luni=2; …sâmbătă=6).
DD Numărul zilei din lună.
DDD Numărul zilei din an.
DY Numele zilei din săptămână, printr-o
abreviere de 3 litere (MON, THU etc.)
DAY Numele zilei din săptămână, scris în
întregime.
MM Numărul lunii din an.
MON Numele lunii din an, printr-o abreviere de 3
litere (JAN, FEB etc.)
MONTH Numele lunii din an, scris în întregime.
Y Ultima cifră din an
YY, YYY, YYYY Ultimele 2, 3, respectiv 4 cifre din an.
YEAR Anul, scris în litere (ex: two thousand
four).
HH12, HH24 Orele din zi, între 0-12, respectiv 0-24.
MI Minutele din oră.
SS Secundele din minut.
SSSSS Secundele trecute de la miezul nopţii.
18. Să se afişeze numele şi data angajării pentru fiecare salariat care a fost angajat în 1987. Se cer 2 soluţii:
una în care se lucrează cu formatul implicit al datei şi alta prin care se formatează data.
3
Varianta1:
SELECT first_name, last_name, hire_date
FROM employees
WHERE hire_date LIKE („%87‟);
Varianta 2:
SELECT first_name, last_name, hire_date
FROM employees
WHERE TO_CHAR(hire_date, „YYYY‟)=‟1987‟;
Sunt obligatorii ghilimelele de la şirul „1987‟? Ce observaţi?
19. Să se afişeze numele şi job-ul pentru toţi angajaţii care nu au manager.
SELECT last_name, job_id
FROM employees
WHERE manager_id IS NULL;
20. Să se afişeze numele, salariul şi comisionul pentru toţi salariaţii care câştigă comisioane. Să se sorteze
datele în ordine descrescătoare a salariilor, iar pentru cei care au acelaşi salariu în ordine crescătoare a
comisioanelor.
SELECT last_name, salary, commission_pct
FROM employees
WHERE commission_pct IS NOT NULL
ORDER BY salary DESC, commission_pct ASC;
21. Să se listeze numele tuturor angajaţilor care au a treia litera din nume 'a'.
Obs: Pentru a forma măştile de caractere utilizate împreună cu operatorul LIKE cu scopul de a compara
şirurile de caractere, se utilizează:
% - reprezentând orice şir de caractere, inclusiv şirul vid;
_ (underscore) – reprezentând un singur caracter.
SELECT DISTINCT last_name
FROM employees
WHERE last_name LIKE '__a%';
22. Folosind data curentă să se afişeze următoarele informaţii:

- numele zilei, numărul zilei din săptămână, numărul zilei din luna, respectiv numărul zilei din an;
- numărul lunii din an, numele lunii cu abreviere la 3 caractere, respectiv numele complet al lunii;
- ora curentă (ora, minute, secunde).
23. Să se listeze numele departamentelor care funcţionează în locaţia având codul 1700 şi al căror manager
este cunoscut.
24. Să se afişeze codurile departamentelor în care lucrează salariaţi.
25. Să se afişeze numele şi prenumele salariaţilor angajaţi în luna mai 1987.
26. Să se listeze codurile angajaţilor care au avut şi alte joburi faţă de cel prezent. Să se ordoneze rezultatul
descrescător după codul angajatului.
27. Să se afişeze numele şi data angajării pentru cei care lucrează în departamentul 80 şi au fost angajaţi în
luna martie a anului 1997.
28. Să se afişeze numele joburilor care permit un salariu cuprins între 8300$ şi 14000$.
29. Care este grila de salarizare pentru un salariu de 10000$?
4
30. Să se listeze numele tuturor angajaţilor care au 2 litere 'L' în nume şi lucrează în departamentul 30 sau
managerul lor este 123.
31. Să se afişeze numele, job-ul şi salariul pentru toţi salariaţii al căror job conţine şirul 'CLERK' sau 'REP' şi
salariul nu este egal cu 1000, 2000 sau 3000 $.
32. Să se afişeze numele, salariul şi comisionul pentru toţi angajaţii al căror salariu este mai mare decât de 5
ori valoarea comisionului (salary*commission_pct*5).
5
LABORATOR 2 - SQL
FUNCŢII SQL (single-row)
Funcţiile SQL sunt predefinite în sistemul Oracle şi pot fi utilizate în instrucţiuni SQL. Ele nu
trebuie confundate cu funcţiile definite de utilizator, scrise în PL/SQL.
 Dacă o funcţie SQL este apelată cu un argument având un alt tip de date decât cel aşteptat, sistemul
converteşte implicit argumentul înainte să evalueze funcţia.
 Dacă o funcţie SQL este apelată cu un argument null, atunci aceasta returnează valoarea null.
Singurele funcţii care nu urmează această regulă sunt CONCAT, NVL şi REPLACE.
Principalele funcţii SQL pot fi clasificate în următoarele categorii:
 Funcţii single-row
 Funcţii multiple-row (funcţii agregat)
Funcţiile single-row returnează câte o linie rezultat pentru fiecare linie a tabelului sau vizualizării
interogate. Aceste funcţii pot apărea în listele SELECT, clauzele WHERE, START WITH, CONNECT BY
şi HAVING.
1. Analizaţi următoarele funcţii pentru prelucrarea şirurilor de caractere:

Funcţie Semnificaţie Exemplu
Converteşte un şir de caractere
LOWER (expresie) LOWER ('AbCdE') = 'abcde'
la minuscule.
UPPER (expresie) UPPER ('AbCdE') = 'ABCDE'
la majuscule.
la un şir care începe cu
INITCAP (expresie) INITCAP ('AbCdE') = 'Abcde'
majusculă şi continuă cu
minuscule.
Extrage din expresia de tip şir
de caractere, n caractere
începând cu poziţia m. Dacă
SUBSTR ('AbCdE', 2, 2) = 'bC'
lipseşte argumentul n, atunci
SUBSTR ('AbCdE', 2) = 'bCdE'
SUBSTR (expresie, m[, n]) extrage toate caracterele până la
SUBSTR ('AbCdE', -3,2) = 'Cd'
sfârşitul şirului. Dacă m este
SUBSTR ('AbCdE', -3) = 'CdE'
negativ numărătoarea poziţiilor
începe de la sfârşitul şirului de
caractere spre început.
Returnează numărul de
LENGTH (expresie) LENGTH ('AbCdE') = 5
caractere al expresiei.
Returnează poziţia la care se
găseşte a n-a ocurentă a
INSTR (LOWER('AbC aBcDe'), 'ab', 5, 2)
expresiei 'expr1' în cadrul
=0
INSTR (expresie, expr1[, m][, n]) expresiei 'expresie', căutarea
INSTR (LOWER('AbCdE aBcDe'), 'ab', 5)
începând de la poziţia m. Daca
=7
m sau n lipsesc, valorile
implicite sunt 1 pentru ambele.
LTRIM (expresie[, expr1]) sau Reversul funcţiilor LPAD, RTRIM ('abcdeXXXX', 'X')
RTRIM (expresie[, expr1]) RPAD. Trunchează expresia = 'abcde'
caracter la stânga sau la dreapta LTRIM (' abcde') = 'abcde'
prin eliminarea succesivă a
caracterelor din expresia expr1.
Implicit, daca lipseşte, expr1
este ' ' un spaţiu.
TRIM (LEADING 'X' FROM
Permite eliminarea caracterelor 'XXXabcdeXXX') = 'abcdeXXX'
TRIM (LEADING | TRAILING | specificate (caractere_trim) de TRIM (TRAILING 'X' FROM
BOTH caractere_trim FROM la începutul (leading) , sfârşitul 'XXXabcdeXXX') = 'XXXabcde'
expresie) (trailing) sau din ambele părţi, TRIM ( BOTH 'X' FROM
dintr-o expresie caracter data. 'XXXabcdeXXX') = 'abcde'
TRIM (' abcde ') = 'abcde'
2. Să se afişeze pentru fiecare angajat din departamentul 20 un şir de caractere de forma "Funcţia
salariatului {prenume} {nume} este {cod functie}". Să se afişeze prenumele cu iniţiala litera mare, iar
numele cu litere mari (Stephen KING), iar codul funcţiei să se afişeze cu litere mici.
3. Să se afişeze pentru angajatul cu numele 'HIGGINS' codul, numele şi codul departamentului. Cum se
scrie condiţia din WHERE astfel încât să existe siguranţa ca angajatul 'HIGGINS' va fi găsit oricum ar fi
fost introdus numele acestuia? Căutarea trebuie să nu fie case-sensitive, iar eventualele blank-uri care
preced sau urmează numelui trebuie ignorate.
UPPER(TRIM(last_name))='HIGGINS';
4. Să se afişeze pentru toţi angajaţii al căror nume se termină în 'n', codul, numele, lungimea numelui şi
poziţia din nume în care apare prima data litera 'a'. Asociaţi aliasuri coloanelor returnate de cerere.
SELECT employee_id, last_name, LENGTH(last_name), INSTR(UPPER(last_name), 'A')
FROM employees
WHERE SUBSTR(last_name,-1)='n';
5. Analizaţi următoarele funcţii aritmetice:
ROUND(1.6) = 2
Returnează valoarea rotunjită a expresiei
ROUND(1.4) = 1
până la n zecimale. Daca n este negativ sunt
ROUND (expresie [, n]) ROUND (1234.56,1) = 1234.6
rotunjite cifre din stânga virgulei. Valoarea
ROUND (1230.56, -2) = 1200
implicită pentru n este 0.
ROUND (1260.56, -2) = 1300
MOD (11, 4) = MOD (11, -4) = 3

MOD (m,n) Returnează restul împărţirii lui m la n.
MOD(-11, 4) = MOD (-11, -4) = -3
6. Să se afişeze detalii despre salariaţii care au lucrat un număr întreg de săptămâni până la data curentă.
MOD(ROUND(SYSDATE – hire_date), 7)=0;
7. Să se afişeze numele, salariul şi numărul de mii al salariului rotunjit la 2 zecimale pentru cei care nu au
salariul divizibil cu 1000.
8. Analizaţi următoarele operaţii pe expresii de tip dată calendaristică:
Tipul de date al
Operaţie Descriere
rezultatului
date -/+ number Date Scade/Adaugă un număr de zile dintr-o / la o dată.
date1 - date2 Number Întoarce numărul de zile dintre două date calendaristice.
date +/-
Date Scade/Adaugă un număr de ore la o / dintr-o dată calendaristică.
number/24
9. Să se afişeze data (luna, ziua, ora, minutul si secunda) de peste 10 zile.
SYSDATE+10
10. Să se afişeze numărul de zile rămase până la sfârşitul anului.
ROUND(TO_DATE(‟31-DEC-2009‟)-SYSDATE)
11. a. Să se afişeze data de peste 12 ore.
SYSDATE+12/24
b. Să se afişeze data de peste 5 minute.
SYSDATE+1/288
12. Analizaţi următoarele funcţii pentru prelucrarea datelor calendaristice:
SYSDATE Întoarce data şi timpul curent
Returnează numărul de luni dintre
data date1 şi data date2. Rezultatul
MONTHS_BETWEEN poate fi pozitiv sau negativ după cum ROUND(MONTHS_BETWEEN
(date1, date2) date1 este mai recentă sau nu faţă de (SYSDATE + 31, SYSDATE)) = 1
date2. Zecimalele reprezintă parţi
dintr-o luna!
Adaugă n luni la o data specificată. MONTHS_BETWEEN
ADD_MONTHS (date, n) Valoarea n trebuie să fie întreagă (ADD_MONTHS(SYSDATE, 3),
(pozitivă sau negativă). SYSDATE) = 3
NEXT_DAY('15-dec-2006','Monday')
Returnează data corespunzătoare
= '18-dec-2006'
NEXT_DAY (date, char) primei zile a săptămânii specificate
NEXT_DAY ('15-dec-2006',1)
(char) care urmează după date.
= '18-dec-2006'
13. Să se afişeze numele angajatului, data angajării şi data negocierii salariului, care a avut loc în prima zi de
Luni, după 6 luni de serviciu. Etichetaţi această coloană “Negociere”.
NEXT_DAY(ADD_MONTHS(hire_date, 6), „Monday‟)
14. Pentru fiecare angajat să se afişeze numele şi numărul de luni de la data angajării. Etichetaţi coloana
“Luni lucrate”. Să se ordoneze rezultatul după numărul de luni lucrate. Se va rotunji numărul de luni la
cel mai apropiat număr întreg.
SELECT last_name, ROUND(MONTHS_BETWEEN(SYSDATE, hire_date)) “Luni lucrate”
FROM employees
ORDER BY MONTHS_BETWEEN(SYSDATE, hire_date);
FROM employees
ORDER BY “Luni lucrate”;

FROM employees
ORDER BY 2;
15. Analizaţi următoarele funcţii de conversie:
Obs. Conversiile implicite asigurate de server-ul Oracle sunt:
 de la VARCHAR2 sau CHAR la NUMBER;
 de la VARCHAR2 sau CHAR la DATE;
 de la NUMBER la VARCHAR2 sau CHAR;
 de la DATE la VARCHAR2 sau CHAR.
SELECT last_name
FROM employees
WHERE TO_CHAR(hire_date,'yyyy')=1994;
SELECT last_name
FROM employees
WHERE hire_date='07-JUN-1994';
SELECT employee_id||' '||last_name||' '||hire_date
FROM employees
WHERE department_id=10;
Conversiile explicite se realizează cu ajutorul funcţiilor de tip TO_{tip}
Converteşte o valoare de tip numeric sau dată TO_CHAR('3') = ' 3'
calendaristică, la un şir de caractere conform cu TO_CHAR(-12) = '-12'
TO_CHAR
formatul specificat sau cu setările naţionale TO_CHAR(sysdate, 'DDMMYYYY')
(expr_number_sau
specificate (NLS - National Language Support).
_date[, format][, = ' 09122004'
Daca formatul sau parametrii lipsesc se
nlsparameters]) TO_CHAR (sysdate + 365 * 57,
utilizează formatul şi parametrii impliciţi.
Formatul este case sensitive. 'ddmmyyyy') = ' 25112061'
TO_NUMBER Converteşte o valoare de tip şir de caractere la o
(expr_char[, valoare numerică conform cu formatul TO_NUMBER ('-12.22', 'S99.99')
format][, specificat. Dacă formatul sau parametrii lipsesc = -12.22
nlsparameters]) se utilizează formatul şi parametrii impliciţi.
Converteşte o valoare de tip şir de caractere la o
TO_DATE
valoare de tip dată calendaristică în
(expr_char[, TO_DATE ('15-feb-2006','dd-mon-
conformitate cu formatul specificat. Dacă
format][, yyyy')
formatul sau parametrii lipsesc se utilizează
nlsparameters])
formatul şi parametrii impliciţi.
16. Să se afişeze numele şi prenumele pentru toţi angajaţii care s-au angajat în luna mai.
17. Analizaţi următoarele funcţii SQL:
Returnează expr1 dacă aceasta nu este NVL(NULL, 1) = 1
NULL, expr2 în caz contrar. Cele 2 expresii NVL(2, 1) = 2
NVL (expr1, expr2) trebuie să aibă acelaşi tip sau expr2 să NVL('c', 1) = 'c' -- face conversie
permită conversia implicită la tipul NVL(1, 'c') -- eroare
expresiei expr1. --nu face conversie
Dacă expr1 este nenulă atunci returnează NVL2 (1, 2, 3) = 2
NVL2 (expr1, expr2, expr3)
expr2, altfel Returnează expr3 NVL2 (NULL, 2, 3) = 3
18. Să se afişeze numele angajaţilor şi comisionul. Dacă un angajat nu câştigă comision, să se scrie “Fara
comision”. Etichetaţi coloana “Comision”.
NVL(TO_CHAR(commission_pct), „Fara comision‟)
19. Să se listeze numele, salariul şi comisionul tuturor angajaţilor al căror venit lunar depăşeşte 10000$.
salary * NVL(commission_pct, 0) venit_lunar
20. Analizaţi expresia CASE şi funcţia DECODE:
Funcţie/Expresie Semnificaţie Exemplu

CASE expr WHEN expr_bool1
În funcţie de valoarea unei expresii
THEN return_expr1
returnează valoarea primei perechi
[WHEN expr_bool2 THEN
WHEN .. THEN care se potriveşte sau
return_expr2
dacă nu se potriveşte nici una expresia
...
din ELSE. Nu se poate specifica NULL
WHEN expr_booln THEN
pentru toate expresiile de returnat.
return_exprn ]
(return_expri). Toate expresiile trebuie
[ELSE return_expr]
sa aibă acelaşi tip de date
END
DECODE (expr, expr_cautare1, Decodifică valoarea expresiei. Dacă
expr_rezultat1, valoarea expresiei este expr_cautarei
DECODE (1, 1, 2, 3) = 2
[expr_cautare2, expr_rezultat2, atunci e returnată expr_rezultati. Dacă
DECODE (2, 1, 2, 3) = 3
.. nu se potriveşte nici o expresie de
DECODE (3, 1, 2, 3) = 3
expr_cautaren, expr_rezultatn, ] căutare atunci e returnat
[rezultat_implicit]) rezultat_implicit.
21. Să se afişeze numele, codul funcţiei, salariul şi o coloana care să arate salariul după mărire. Se ştie că
pentru IT_PROG are loc o mărire de 10%, pentru ST_CLERK 15%, iar pentru SA_REP o mărire de
20%. Pentru ceilalţi angajaţi nu se acordă mărire. Să se denumească coloana "Salariu revizuit".
SELECT last_name, job_id, salary,
DECODE(job_id,
„IT_PROG‟, salary*1.1,
‟ST_CLERK‟, salary*1.15,
„SA_REP‟, salary*1.2,
salary ) “salariu revizuit”
FROM employees;

CASE job_id WHEN „IT_PROG‟ THEN salary* 1.1
WHEN ‟ST_CLERK‟ THEN salary*1.15
WHEN „SA_REP‟ THEN salary*1.2
ELSE salary
END “salariu revizuit”
FROM employees;

CASE WHEN job_id= „IT_PROG‟ THEN salary* 1.1
WHEN job_id=‟ST_CLERK‟ THEN salary*1.15
WHEN job_id =„SA_REP‟ THEN salary*1.2
ELSE salary
END “salariu revizuit”
FROM employees;
22. Să se afişeze numele salariatului şi codul departamentului în care acesta lucrează. Dacă există salariaţi
care nu au un cod de departament asociat, atunci pe coloana id_depratment să se afişeze:
a. textul “fara departament”;
b. valoarea zero.
23. a. Să se afişeze numele angajaţilor care nu au manager.
b. Să se afişeze numele angajaţilor şi codul managerilor lor. Pentru angajaţii care nu au manager să apară
textul “nu are sef”.
24. Să se afişeze numele salariatului şi:
- venitul anual dacă are comision;
- salariul dacă nu are comision.
Se va utiliza funcţia NVL2.
25. Să se afişeze numele salariatului, salariul şi salariul revizuit astfel:
- dacă lucrează de mai mult de 200 de luni atunci salariul va fi mărit cu 20%;
- dacă lucrează de mai mult de 150 de luni, dar mai puţin de 200 de luni, atunci salariul va fi mărit cu
15%;
- dacă lucrează de mai mult de 100 de luni, dar mai puţin de 150 de luni, atunci salariul va fi mărit cu
10%;
- altfel, salariul va fi mărit cu 5%.
LABORATOR 3 - SQL
CERERI MULTITABEL, SUBCERERI
Atunci când în clauza FROM a unei comenzi SELECT apar mai multe tabele se realizează produsul
cartezian al acestora. De aceea numărul de linii rezultat creşte considerabil, fiind necesară restricţionarea
acestora cu o clauza WHERE.
Atunci când este necesară obţinerea de informaţii din mai multe tabele se utilizează condiţii de join.
Join-ul este operaţia de regăsire a datelor din două sau mai multe tabele, pe baza valorilor comune ale unor
coloane. Condiţiile de corelare utilizează de obicei coloanele cheie primară şi cheie externă.
Pentru claritatea şi eficienţa accesului la baza de date se recomandă prefixarea numelor coloanelor cu
numele tabelelor din care fac parte (tabel.coloana). De asemenea, există posibilitatea de a utiliza aliasuri pentru
tabelele din clauza FROM şi utilizarea lor în cadrul comenzii SELECT respective (alias.coloana). Această
identificare (prin 'tabel.coloana' sau 'alias.coloana') este obligatorie atunci când se face referinţă la o coloana ce
apare în mai mult de un tabel din clauza FROM.
Tipuri de join:
 equijoin (se mai numeşte inner join sau simple join) - compunerea a două tabele diferite după o
condiţie ce conţine operatorul de egalitate.
SELECT last_name, department_name, location_id, e.department_id
FROM employees e, departments d
WHERE e.department_id = d.department_id;
Obs: Numele sau alias-urile tabelelor sunt obligatorii în dreptul coloanelor care au acelaşi nume în
mai multe tabele.
 nonequijoin - compunerea a două relaţii tabele după o condiţie oarecare, ce NU conţine operatorul
de egalitate.
SELECT last_name, salary, grade_level
FROM employees, job_grades
WHERE salary BETWEEN lowest_sal AND highest_sal;
 outerjoin - compunerea externă a două tabele diferite completând una dintre relaţii cu valori NULL
acolo unde nu există în aceasta nici un tuplu ce îndeplineşte condiţia de corelare. Relaţia completată
cu valori NULL este cea în dreptul căreia apare “(+)”. Operatorul (+) poate fi plasat în orice parte a
condiţiei de join, dar nu în ambele părţi. Full outer join = Left outer join UNION Right outer join.
SELECT last_name, department_name,location_id
WHERE e.department_id(+) = d.department_id;
 selfjoin - compunerea externă a unui tabel cu el însuşi după o condiţie dată.
SELECT sef.last_name, angajat.last_name
FROM employees sef, employees angajat
WHERE sef.employee_id = angajat.manager_id
ORDER BY sef.last_name;
1. Pentru fiecare angajat să se afişeze numele, codul şi numele departamentului.
SELECT last_name, e.department_id, department_name
WHERE e.department_id = d.department_id;
2. Să se afişeze numele angajatului, numele departamentului pentru toţi angajaţii care câştigă comision.
3. Să se listeze numele job-urile care există în departamentul 30.
SELECT DISTINCT job_title
FROM employees e, jobs j
WHERE e.job_id = j.job_id
AND department_id = 30;
4. Să se afişeze numele, job-ul şi numele departamentului pentru toţi angajaţii care lucrează în Seattle.
SELECT last_name, job_id, department_name
FROM employees e, departments d, locations s
WHERE e.department_id = d.department_id
AND d.location_id = s.location_id
AND city = „Seattle‟;
5. Să se afişeze numele, salariul, data angajării şi numele departamentului pentru toţi programatorii care
lucrează în America.
region_name = „Americas‟
job_title = „Programmer‟
6. Să se afişeze numele salariaţilor şi numele departamentelor în care lucrează. Se vor afişa şi salariaţii care nu
lucrează într-un departament (right outher join).
SELECT last_name, department_name
WHERE e.department_id = d.department_id(+);
7. Să se afişeze numele departamentelor şi numele salariaţilor care lucrează în ele. Se vor afişa şi
departamentele care nu au salariaţi (left outher join).
8. Să se afişeze numele, job-ul, numele departamentului, salariul şi grila de salarizare pentru toţi angajaţii.
9. Să se afişeze codul angajatului şi numele acestuia, împreună cu numele şi codul şefului său direct. Se vor
eticheta coloanele Ang#, Angajat, Mgr#, Manager. Să se salveze instrucţiunea într-un fişier numit p3_9.sql.
SELECT a.employee_id “Ang#”, a.last_name “Angajat”, b.employee_id “Mgr#”, b.last_name “Manager”
FROM employees a, employees b
WHERE a.manager_id = b. employee_id;
10. Să se modifice p3_9.sql pentru a afişa toţi salariaţii, inclusiv pe cei care nu au şef.
11. Să se afişeze numele salariatului şi data angajării împreună cu numele şi data angajării şefului direct pentru
salariaţii care au fost angajaţi înaintea şefilor lor. Se vor eticheta coloanele Angajat, Data_ang, Manager si
Data_mgr.
12. Pentru fiecare angajat din departamentele 20 şi 30 să afişeze numele, codul departamentului şi toţi colegii
săi (salariaţii care lucrează în acelaşi departament cu el). Se vor eticheta coloanele corespunzător.
SELECT a.last_name “Angajat”, a.department_id ”Departament”, b.last_name “Coleg”
WHERE a.department_id = b.department_id
AND a.employee_id <> b.employee_id
AND a.department_id IN (20,30)
ORDER BY a.last_name;
13. Să se afişeze numele şi data angajării pentru salariaţii care au fost angajaţi după Fay.
SELECT last_name, hire_date
FROM employees
WHERE hire_date > (SELECT hire_date
FROM employees
WHERE last_name = „Fay‟);
sau
SELECT a.last_name, a.hire_date
WHERE UPPER(b.last_name)=‟FAY‟ AND a.hire_date>b.hire_date;
14. Scrieţi o cerere pentru a afişa numele şi salariul pentru toţi colegii (din acelaşi departament) lui Fay. Se va
exclude Fay.
FROM employees
WHERE last_name <> „Fay‟
AND department_id = (SELECT department_id
FROM employees
WHERE last_name = „Fay‟);
15. Să se afişeze codul departamentului, codul şi numele angajaţilor care lucrează în acelaşi departament cu cel
puţin un angajat al cărui nume conţine litera “T”. Să se ordoneze după codul departamentului.
SELECT employee_id, last_name, department_id
FROM employees
WHERE department_id IN (SELECT DISTINCT department_id
FROM employees
WHERE UPPER(last_name) LIKE „%T%‟)
ORDER BY department_id;
16. Să se afişeze numele şi salariul angajaţilor conduşi direct de Steven King.
FROM employees
WHERE manager_id = (SELECT employee_id
FROM employees
WHERE UPPER(last_name) ='KING'
AND UPPER(first_name) ='STEVEN' );
17. Să se afişeze numele şi job-ul tuturor angajaţilor din departamentul „Sales‟.
SELECT last_name, job_id
FROM employees
WHERE department_id = (SELECT department_id
FROM departments
WHERE department_name ='Sales');
18. Să se afişeze numele angajaţilor, numărul departamentului şi job-ul tuturor salariaţilor al căror departament
este localizat în Seattle.
SELECT last_name, job_id, department_id
FROM employees
WHERE department_id IN (SELECT department_id
FROM departments
WHERE location_id = (SELECT location_id
FROM locations
WHERE city = „Seattle‟));
Rezolvaţi această problemă utilizând join-uri.
19. Să se afle dacă există angajaţi care nu lucrează în departamentul „Sales‟ şi al căror salariu şi comision
coincid cu salariul şi comisionul unui angajat din departamentul „Sales‟.
SELECT last_name, salary, commission_pct, department_id
FROM employees
WHERE (salary, commission_pct) IN (SELECT salary, commission_pct
AND department_name = „Sales‟)
AND department_id <> (SELECT department_id
FROM departments
WHERE department_name = „Sales‟);
20. Scrieţi o cerere pentru a afişa numele, numele departamentului şi salariul angajaţilor care nu câştigă
comision, dar al căror manager coincide cu managerul unui angajat care câştigă comision.
SELECT last_name, department_name, salary
AND e.manager_id IN (SELECT DISTINCT manager_id
FROM employees
WHERE commission_pct IS NOT NULL)
AND commission_pct IS NULL;
21. Scrieţi o cerere pentru a afişa angajaţii care câştigă mai mult decât oricare funcţionar. Sortaţi rezultatele
după salariu, în ordine descrescătoare.
SELECT last_name, salary, job_id
FROM employees
WHERE salary > (SELECT MAX(salary)
FROM employees
WHERE job_id LIKE '%CLERK')
ORDER BY salary DESC;
22. Să se afişeze codul, numele şi salariul tuturor angajaţilor care câştigă mai mult decât salariul mediu.
23. Să se afişeze pentru fiecare salariat angajat în luna martie numele său, data angajării şi numele jobului.
24. Să se afişeze pentru fiecare salariat al cărui câştig total lunar este mai mare decât 12000 numele său,
câştigul total lunar şi numele departamentului în care lucrează.
25. Să se afişeze pentru fiecare angajat codul său şi numele joburilor sale anterioare, precum şi intervalul de
timp în care a lucrat pe jobul respectiv.
26. Să se modifice cererea de la punctul 25 astfel încât să se afişeze şi numele angajatului, respectiv codul
jobului său curent.
27. Să se modifice cererea de la punctul 26 astfel încât să se afişeze şi numele jobului său curent.
28. Să se afişeze salariaţii care au acelaşi manager ca şi angajatul având codul 140.
29. Să se afişeze numele departamentelor care funcţionează în America.
LABORATOR 4 - SQL
Funcţii multiple-row (grup). Gruparea datelor.
Aceste tipuri de funcţii pot fi utilizate pentru a returna informaţia corespunzătoare fiecăruia dintre
grupurile obţinute în urma divizării liniilor tabelului cu ajutorul clauzei GROUP BY.
Pot apărea în clauzele SELECT, ORDER BY şi HAVING. Server-ul Oracle aplică aceste funcţii fiecărui
grup de linii şi returnează un singur rezultat pentru fiecare mulţime.
Exemple de funcţii grup: AVG, SUM, MAX, MIN, COUNT etc.
Tipurile de date ale argumentelor funcţiilor grup pot fi CHAR, VARCHAR2, NUMBER sau DATE.
Funcţiile AVG şi SUM, operează numai asupra valorilor numerice. Funcţiile MAX şi MIN pot opera asupra
valorilor numerice, caracter sau dată calendaristică.
Toate funcţiile grup, cu excepţia lui COUNT(*), ignoră valorile null. COUNT(expresie)
returnează numărul de linii pentru care expresia dată nu are valoarea null. Funcţia COUNT returnează un
număr mai mare sau egal cu zero şi nu întoarce niciodată valoarea null.
Când este utilizată clauza GROUP BY, server-ul sortează implicit mulţimea rezultată în ordinea
crescătoare a valorilor coloanelor după care se realizează gruparea.
Absenţa clauzei GROUP BY conduce la aplicarea funcţiei grup pe mulţimea tuturor liniilor tabelului.
În clauza GROUP BY se trec obligatoriu toate coloanele prezente în clauza SELECT, care nu sunt
argument al funcţiilor grup.
1. Să se afişeze cel mai mare salariu, cel mai mic salariu, suma şi media salariilor tuturor angajatilor. Etichetaţi
coloanele Maxim, Minim, Suma, respectiv Media. Să se rotunjească rezultatele.
SELECT MIN(salary) min, MAX(salary) max, SUM(salary) suma, ROUND(AVG(salary)) media
FROM employees;
2. Utilizând funcţia grup COUNT să se determine:
a. numărul total de angajaţi;
b. numărul de angajaţi care au manager;
c. numărul de manageri.
3. Să se afişeze diferenţa dintre cel mai mare şi cel mai mic salariu. Etichetaţi coloana “Diferenta”.
4. Să se listeze numărul de angajaţi din departamentul având codul 50.
5. Caţi angajaţi din departamentul 80 câştigă comision?
6. Să se selecteze valoarea medie şi suma salariilor pentru toţi angajaţii care sunt reprezentanţi de vânzări
(SA_MAN, SA_REP).
7. Să se selecteze data angajării primei persoane care a fost angajată de companie.
8. Să se afişeze numărul de angajaţi pentru fiecare job.
SELECT job_id, COUNT(employee_id) nr_angajati
FROM employees
GROUP BY job_id;
9. Să se afişeze minimul, maximul, suma şi media salariilor pentru fiecare departament.
10. Să se afişeze codul departamentului şi media salariilor pentru fiecare job din cadrul acestuia.
SELECT department_id, job_id, AVG(salary)
FROM employees
GROUP BY department_id, job_id;
11. a. Să se afişeze codul departamentelor pentru care salariul minim depăşeşte 5000$.
SELECT department_id, MIN(salary)
FROM employees
GROUP BY department_id
HAVING MIN(salary)>5000;
1
b. Să se modifice cererea anterioară astfel încât să se afişeze şi oraşul în care funcţionează aceste
departamente.
12. Să se obţină codul departamentelor şi numărul de angajaţi al acestora pentru departamentele care au cel
puţin 10 angajaţi.
13. Să se obţină codul departamentelor şi suma salariilor angajaţilor care lucrează în acestea, în ordine
descrescătoare după sumă. Se consideră angajaţii care au comision şi departamentele care au mai mult de 5
angajaţi.
14. Să se obţină job-ul pentru care salariul mediu este minim.
SELECT job_id
FROM employees
GROUP BY job_id
HAVING AVG(salary) = (SELECT MIN(AVG(salary))
FROM employees
GROUP BY job_id);
15. Să se afişeze cel mai mare dintre salariile medii pe departamente.
16. a. Să se afişeze codul, numele departamentului şi suma salariilor pe departamente.
SELECT d.department_id, department_name,a.suma
FROM departments d, (SELECT department_id ,SUM(salary) suma
FROM employees
GROUP BY department_id) a
WHERE d.department_id =a.department_id;
b. Daţi o altă metodă de rezolvare a acestei probleme.
17. a. Scrieţi o cerere pentru a afişa numele departamentului, numărul de angajaţi şi salariul mediu pentru
angajaţii din acel departament. Coloanele vor fi etichetate Departament, Nr. angajati, Salariu Mediu.
SELECT department_name “Departament”,
(SELECT COUNT(employee_id)
FROM employees
WHERE department_id = d.department_id ) ” Nr. angajati”,
(SELECT AVG(salary)
FROM employees
WHERE department_id = d.department_id) ”Salariu mediu”
FROM departments d;
b. Daţi o altă metodă de rezolvare pentru problema anterioară.
18. Să se creeze o cerere prin care să se afişeze numărul total de angajaţi şi, din acest total, numărul celor care
au fost angajaţi în 1997, 1998, 1999 şi 2000. Datele vor fi afişate în forma următoare:
Total 1997 1998 1999 2000
--------------------------------------------------------------
50 10 5 25 1
SUM(DECODE(TO_CHAR(hire_date,'yyyy'),1997,1,0))
2
Operatorii ROLLUP şi CUBE
Clauza GROUP BY permite gruparea liniilor selectate după valorile expresiilor precizate în aceasta.
Pentru fiecare grup, va fi returnată o singură linie de informaţie. Clauza GROUP BY poate produce grupări
superagregat utilizând extensiile CUBE sau ROLLUP.
ROLLUP grupează liniile selectate pe baza valorilor primelor n, n - 1, …, 0 expresii din
specificaţia GROUP BY şi returnează o singură linie pentru fiecare grup. ROLLUP creează grupări prin
deplasarea într-o singură direcţie, de la dreapta la stânga, de-a lungul listei de coloane specificate în
clauza GROUP BY. Apoi, se aplică funcţia agregat acestor grupări. Dacă sunt specificate n expresii în
operatorul ROLLUP, numărul de grupări generate va fi n + 1. Liniile care se bazează pe valoarea primelor
n expresii se numesc linii obişnuite, iar celelalte se numesc linii superagregat.
GROUP BY ROLLUP (expr_1, expr_2, …, expr_n) generează n+1 tipuri de linii, corespunzătoare
următoarelor grupări:
 GROUP BY (expr_1, expr_2, …, expr_n-1, expr_n)
 GROUP BY (expr_1, expr_2, …, expr_n-1)
 …
 GROUP BY (expr_1, expr_2)
 GROUP BY (expr_1)
 GROUP BY () – corespunzător absenţei clauzei GROUP BY şi deci, calculului funcţiilor grup din
cerere pentru întreg tabelul.
CUBE grupează liniile selectate pe baza valorilor tuturor combinaţiilor posibile ale expresiilor
specificate şi returnează câte o linie totalizatoare pentru fiecare grup. Acest operator este folosit pentru a
produce mulţimi de rezultate care sunt utilizate în rapoarte. În vreme ce ROLLUP produce subtotalurile
doar pentru o parte dintre combinaţiile posibile, operatorul CUBE produce subtotaluri pentru toate
combinaţiile posibile de grupări specificate în clauza GROUP BY, precum şi un total general.
Dacă există n coloane sau expresii în clauza GROUP BY, vor exista 2n combinaţii posibile
superagregat.
19. Să se afişeze codurile departamentelor în care lucrează cel puţin un angajat, iar pentru fiecare dintre acestea
şi pentru fiecare manager care lucrează în departamentul respectiv să se afişeze numărul de salariaţi. De
asemenea, să se afişeze numărul de salariaţi pentru fiecare departament indiferent de manager şi numărul
total de angajaţi din companie.
SELECT department_id, manager_id, COUNT(employee_id)

FROM employees
WHERE manager_id IS NOT NULL AND department_id IS NOT NULL
GROUP BY ROLLUP (department_id, manager_id);
department_id manager_id COUNT(employee_id)

---------------------------------------------------------------------
10 7782 1
10 7839 1
10 2
-----------------------------------------------------------------------
20 7566 2
20 7788 1
20 7839 1
20 7902 1
20 5
-----------------------------------------------------------------------
30 7698 5
30 7839 1
30 6
-----------------------------------------------------------------------
13
3
20. Să se afişeze codurile departamentelor în care lucrează cel puţin un angajat, iar pentru fiecare dintre acestea
şi pentru fiecare manager care lucrează în departamentul respectiv să se afişeze numărul de salariaţi. De
asemenea, să se afişeze numărul de salariaţi pentru fiecare departament indiferent de manager, numărul de
angajaţi subordonaţi unui manager indiferent de departament şi numărul total de angajaţi din companie.
SELECT department_id, manager_id, COUNT(employee_id)

FROM employees
WHERE manager_id IS NOT NULL AND department_id IS NOT NULL
GROUP BY CUBE (department_id, manager_id);
department_id manager_id COUNT(employee_id)

---------------------------------------------------------------------
10 7782 1
10 7839 1
10 2
-----------------------------------------------------------------------
20 7566 2
20 7788 1
20 7839 1
20 7902 1
20 5
-----------------------------------------------------------------------
30 7698 5
30 7839 1
30 6
-----------------------------------------------------------------------
7566 2
7698 5
7782 1
7788 1
7839 3
7902 1
----------------------------------------------------------------------
13
21. Pentru fiecare departament, job, respectiv an al angajării să se afişeze numărul de salariaţi. De asemenea se
va afişa numărul de angajaţi:
- pentru fiecare departament şi job, indiferent de anul angajării;
- pentru fiecare departament, indiferent de job şi de anul angajării;
- la nivel de companie.
22. Să se afişeze suma alocată pentru plata salariilor pe joburi (codul jobului), în cadrul departamentului (codul
departamentului). De asemenea, să se afişeze valoarea totală necesară pentru plata salariilor la nivel de
departament, valoarea totală necesară pentru plata salariilor la nivel de job, indiferent de departament şi
valoarea totală necesară pentru plata salariilor la nivel de companie.
23. Funcţia GROUPING(expresie) întoarce:
- valoarea 0, dacă expresia a fost utilizată pentru calculul valorii agregat
- valoarea 1, dacă expresia nu a fost utilizată.
24. Să se afişeze numele departamentelor, titlurile job-urilor şi valoarea medie a salariilor, pentru:
- fiecare departament şi, în cadrul său pentru fiecare job;
- fiecare departament (indiferent de job);
- întreg tabelul.
De asemenea, să se afişeze şi o coloană care indică intervenţia coloanelor department_name şi job_title în obţinerea
rezultatului.
4
25. Modificaţi cererea anterioară astfel încât să se afişeze numele departamentelor, titlurile job-urilor şi
valoarea medie a salariilor, pentru:
- fiecare departament şi, în cadrul său pentru fiecare job;
- fiecare departament (indiferent de job);
- fiecare job(indiferent de departament);
- întreg tabelul.
Cum intervin coloanele în obţinerea rezultatului?
Să se afişeze ‟Dept‟, dacă departamentul a intervenit în agregare şi „Job‟, dacă job-ul a intervenit în agregare.
DECODE(GROUPING(department_name), 0, „Dept‟)
26. Utilizaţi cererea de la punctul 20.
a. Eliminaţi clauza WHERE din această cerere. Analizaţi rezultatul obţinut.
b. Modificaţi cererea obţinută astfel încât să se identifice dacă o valoare null din rezultat este stocată pe
una dintre coloanele manager_id sau department_id sau este produsă de operatorul CUBE.
27. Clauza GROUPING SETS. Permite obţinerea numai a anumitor grupări superagregat. Acestea pot fi
precizate prin intermediul clauzei:
GROUP BY GROUPING SETS ((expr_11, expr_12, …, expr_1n), (expr_21, expr_22, …expr_2m), …)

28. Să se afişeze numele departamentelor, numele job-urilor, codurile managerilor angajaţilor, maximul şi suma
salariilor pentru:
- fiecare departament şi, în cadrul său, fiecare job;
- fiecare job şi, în cadrul său, pentru fiecare manager;
- întreg tabelul.
GROUPING SETS ((department_name, job_title), (job_title, e.manager_id), ());
5
LABORATOR 5 SQL
I. Limbajul de control al datelor (COMMIT, SAVEPOINT, ROLLBACK)
II. Limbajul de prelucrare a datelor (LMD). INSERT, UPDATE, DELETE.
I. Limbajul de control al datelor (COMMIT, SAVEPOINT, ROLLBACK)
 Comanda COMMIT permanentizează modificările care au fost realizate de tranzacţia curentă (o

tranzacţie este un set de comenzi DML - INSERT, UPDATE, DELETE sau MERGE); comanda suprimă
toate punctele intermediare definite în tranzacţie şi eliberează blocările tranzacţiei.
Observaţie:
Sistemul realizează un commit implicit:
- la închiderea normală a unui client Oracle (de exemplu SQL*Plus),
- după fiecare comandă LDD (CREATE, ALTER, DROP).
 Comanda SAVEPOINT marchează un punct intermediar în procesarea tranzacţiei. În acest mod este
posibilă împărţirea tranzacţiei în subtranzacţii.
Comanda SAVEPOINT are sintaxa:
SAVEPOINT nume_pct_intermediar;
 Comanda ROLLBACK permite renunţarea la modificările efectuate; aceasta determină încheierea
tranzacţiei, anularea modificărilor asupra datelor şi restaurarea stării lor precedente.
Comanda ROLLBACK are sintaxa:-
ROLLBACK [TO SAVEPOINT nume_punct_salvare];
Observaţie:
- sistemul realizează un rollback implicit dacă sistemul se închide anormal (defecţiune hardware sau
software, pană de curent etc.);
- nici o comanda LDD (CREATE, ALTER; DROP) nu poate fi anulată.
1. Ce efect are următoarea secvenţă de instrucţiuni?
CREATE TABLE dept_*** AS

SELECT * FROM departments;
SELECT *
FROM dept_***;
SAVEPOINT a;
DELETE FROM dept_***;
INSERT INTO dept_***

VALUES (300,’Economic’,100,1000);

VALUES (350,’Cercetare’,200,2000);
SAVEPOINT b;

VALUES (400,’Juritic’,150,3000);
SELECT COUNT(*)
FROM dept_***;
ROLLBACK TO b;
1
SELECT COUNT(*)
FROM dept_***;
ROLLBACK TO a;

VALUES (500,’Contabilitate’,175,1500);
COMMIT;
SELECT *
FROM dept_***;
II. Limbajul de prelucrare a datelor (LMD). INSERT, UPDATE, DELETE, MERGE.
1. Să se creeze tabele emp_*** şi dept_*** (dacă nu este deja creat), având aceeaşi structură şi date ca şi
tabelele employees, respectiv departments.
2. Să se selecteze toate înregistrările din cele două tabele create anterior.
3. Ştergeţi toate înregistrările din cele 2 tabele create anterior. Salvati modificarile.
DELETE FROM emp_***;
...
COMMIT;
4. Să se listeze structura tabelului employees şi să se compare cu structura tabelului emp_***. Ce observaţi?
5. Sintaxa simplificată a comenzii INSERT
- pentru inserarea unei singuri linii:
INSERT INTO nume_tabel [(col1,col2,...)]
VALUES (expresie1, expresie2, ...);
- pentru inserarea liniilor rezultat ale unei comenzi SELECT:
INSERT INTO nume_tabel [(col1,col2,...)]
{comanda_SELECT};
Observatii:
- lista de coloane (dacă este precizată) trebuie să se potrivească ca număr şi tip de date cu lista de
expresii;
- în loc de tabel (nume_tabel), insererea se mai poate face si prin intermediul unei vizualizări;
- daca se omit coloane în lista de inserare, acestea primesc valoarea NULL sau valoarea implicită.
- posibile probleme la inserare:
- lipsa de valori pentru coloane NOT NULL,
- nepotrivirea listei de coloane cu cea de expresii,
- valori duplicate ce încalcă o constrângere de unicitate,
- încălcarea vreunei constrângeri de integritate referenţială,
- încălcarea unei constrângeri de tip CHECK,
- nepotrivire de tip de date,
- valoare prea mare pentru coloana respectivă.
- dacă se foloseşte expresia DEFAULT, atunci valoarea inserată este NULL sau valoarea implicită
setată la nivel de tabel.
6. Să se exemplifice câteva din erorile care pot să apară la inserare şi să se observe mesajul returnat de sistem.
- lipsa de valori pentru coloane NOT NULL (coloana department_name este NOT NULL)
INSERT INTO dept_*** (department_id, location_id)
VALUES (200, 2000);
- nepotrivirea listei de coloane cu cea de expresii
2
VALUES (200, 2000);
INSERT INTO dept_*** (department_id, department_name,location_id)
VALUES (200, 2000);
- nepotrivire de tip de date,
VALUES (‘D23’, 2000);
- valoare prea mare pentru coloană
VALUES (15000, 2000);
7. Copiaţi în tabelul emp_*** salariaţii (din tabelul employees) al căror comision depăşeşte 25% din salariu.
8. Creaţi tabele emp1_***, emp2_*** şi emp3_*** cu aceeaşi structură ca tabelul employees. Copiaţi din
tabelul employees:
- în tabelul emp1_*** salariaţii care au salariul mai mic decât 6000;
- în tabelul emp2_*** salariaţii care au salariul cuprins între 6000 şi 10000;
- în tabelul emp3_*** salariaţii care au salariul mai mare decât 10000.
Verificaţi rezultatele, apoi ştergeţi toate înregistrările din aceste tabele.
Obs. Clauza ALL determină evaluarea tuturor condiţiilor din clauzele WHEN. Pentru cele a căror valoare
este TRUE, se inserează înregistrarea specificată în opţiunea INTO corespunzătoare.
CREATE TABLE emp1_***

AS SELECT * FROM employees WHERE 1=0;


INSERT ALL
WHEN salary < =6000 THEN
INTO emp1_***
WHEN salary > = 6000 AND salary <= 10000 THEN
INTO emp2_***
ELSE
INTO emp3_***
SELECT * FROM employees;
DELETE FROM emp1_***;

COMMIT;
9. Să se creeze tabelul emp0_*** cu aceeaşi structură ca tabelul employees. Copiaţi din tabelul employees:
- în tabelul emp0_*** salariaţii care lucrează în departamentul 80;
- în tabelul emp1_*** salariaţii care au salariul mai mic decât 6000;
- în tabelul emp2_*** salariaţii care au salariul cuprins între 6000 şi 10000;
- în tabelul emp3_*** salariaţii care au salariul mai mare decât 10000.
Dacă un salariat se încadrează în tabelul emp0_*** atunci acesta nu va mai fi inserat şi în alt tabel
(tabelul corespunzător salariului său).
3
Obs. Clauza FIRST determină inserarea corespunzătoare primei clauze WHEN a cărei condiţie este evaluată
TRUE. Toate celelalte clauze WHEN sunt ignorate.
Sintaxa simplificată a comenzii DELETE

DELETE FROM nume_tabel
[WHERE conditie];
10. Ştergeţi toate înregistrările din tabelele emp_*** şi dept_***. Inseraţi în aceste tabele toate înregistrările
corespunzătoare din employees, respectiv departments. Permanentizaţi modificările.
11. Ştergeţi angajaţii care nu au comision. Anulaţi modificările.
DELETE FROM emp_***

WHERE commission_pct IS NULL;
ROLLBACK;
12. Eliminaţi departamentele care nu au nici un angajat. Anulaţi modificările.
13. Eliminaţi angajaţii care nu aparţin unui departament valid. Anulaţi modificările.
14. Sintaxa simplificată a comenzii UPDATE:

UPDATE nume_tabel [alias]
SET col1 = expr1[, col2=expr2]
[WHERE conditie];
sau
UPDATE nume_tabel [alias]
SET (col1,col2,...) = (subcerere)
[WHERE conditie];
Observatii:
- de obicei pentru identificarea unei linii se foloseşte o condiţie ce implică cheia primară;
- dacă nu apare clauza WHERE atunci sunt afectate toate liniile tabelului specificat.
15. Măriţi salariul tuturor angajaţilor din tabelul emp_*** cu 5%. Anulaţi modificările.
UPDATE emp_***
SET salary = salary * 1.05;
ROLLBACK;
16. Schimbaţi jobul tuturor salariaţilor din departamentul 80 care au comision în 'SA_REP'. Anulaţi
modificările.
17. Să se promoveze Douglas Grant la manager în departamentul 20, având o creştere de salariu cu 1000$.
18. Să se modifice jobul şi departamentul angajatului având codul 114, astfel încât să fie la fel cu cele ale
angajatului având codul 205.
19. Schimbaţi salariul şi comisionul celui mai prost plătit salariat din firmă, astfel încât să fie egale cu
salariul si comisionul directorului.
UPDATE emp_***
SET (salary, commission_pct) = (SELECT salary, commission_pct
FROM emp_***
4
WHERE manager_id IS NULL)
WHERE salary = (SELECT MIN(salary)
FROM emp_***);
ROLLBACK;
20. Pentru fiecare departament să se mărească salariul celor care au fost angajaţi primii astfel încât să devină
media salariilor din companie.
21. Să se modifice valoarea emailului pentru angajaţii care câştigă cel mai mult în departamentul în care
lucrează astfel încât acesta să devină iniţiala numelui concatenată cu “_” concatenat cu prenumele.
Anulaţi modificările.
5
LABORATOR 6 SQL - LDD
Limbajul de definire a datelor (CREATE, ALTER, DROP)
Crearea tabelelor
nume_coloana tip_de_date [DEFAULT1 expr], ...);
CREATE TABLE nume_tabel [(col1, col2...)]
AS subcerere;
1. Creaţi tabelul salariat_*** având următoarea structură:
Nume Caracteristici Tip
cod_ang NOT NULL NUMBER(4)
nume VARCHAR2(25)
prenume VARCHAR2(25)
functia VARCHAR2(20)
sef NUMBER(4)
Valoare implicită data
data_angajarii DATE
curentă
varsta NUMBER(2)
email CHAR(50)
salariu Valoare implicită 0 NUMBER(9,2)
CREATE TABLE salariat_*** (

cod_ang NUMBER(4) NOT NULL,
nume VARCHAR2(25),
functia VARCHAR2(20),
sef NUMBER(4),
data_angajarii DATE DEFAULT SYSDATE,
varsta NUMBER(2),
email CHAR(50),
2. Afişaţi structura tabelului creat anterior.
3. Se dau următoarele valori:
COD _ANG NUME PRENUME FUNCTIA SEF DATA_ANG VARSTA EMAIL SALARIU
1 ..... ..... director null ........ 30 ..... 5500
2 ..... ..... functionar 1 ......... 25 ..... 0
3 ..... ...... economist 1 ......... 45 ..... 3000
4 ..... .... functionar 1 ......... 35 ...... 1000
4. Inseraţi în tabelul salariat_*** prima înregistrare din tabelul de mai sus fără să precizaţi lista de
coloane în comanda INSERT.
5. Inseraţi a doua înregistrare folosind o listă de coloane din care excludeţi data_angajarii şi salariul
care au valori implicite. Observaţi apoi rezultatul.
6. Inseraţi înregistrările 3 şi 4.
7. Creaţi tabelul functionar_*** care să conţină funcţionarii din tabelul salariat_***, având
următoarele coloane: codul, numele, salariul anual şi data angajării. Verificaţi cum a fost creat
tabelul şi ce date conţine.
1
Modificarea tabelelor
8. Adăugaţi o nouă coloană tabelului salariat_*** care să conţină data naşterii.
ALTER TABLE salariat_***

ADD (datan DATE);
9. Modificaţi dimensiunea coloanei nume la 30 si pe cea a salariului la 12 cu 3 zecimale.

MODIFY (nume VARCHAR2(30), salariu NUMBER(12,3));
10. Modificaţi tipul coloanei email la VARCHAR2.

11. Modificaţi valoarea implicită a coloanei data_angajarii la data sistemului + o zi.
12. Eliminaţi coloana varsta din tabelul salariat_***.

DROP COLUMN varsta;
Redenumirea şi eliminarea tabelelor
RENAME nume_tabel TO nume_nou;

DROP TABLE nume_tabel;
13. Redenumiţi tabelul functionar_*** cu funct_***.
14. Recreaţi tabelul functionar_*** utilizând tabelul funct_***..
15. Eliminaţi tabelul funct_***.
Constrângeri
Adăugarea constrângerilor la crearea tabelului (CREATE TABLE)

nume_coloana tip_de_date [DEFAULT expr]
[constrangere_de_coloana], ...
16. Ştergeţi şi apoi creaţi din nou tabelul salariat_*** cu următoarea structură.
NUME TIP CONSTRÂNGERE
cod_ang NUMBER(4) Cheie primară
nume VARCHAR2(25) NOT NULL
prenume VARCHAR2(25)
data_nasterii DATE data_nasterii<data_angajarii
functia VARCHAR2(9) NOT NULL
Referă ca şi cheie externă cod_ang din acelaşi
sef NUMBER(4)
tabel
data_angajarii DATE
email VARCHAR2(20) unic
salariu NUMBER(12,3) >0
cod_dept NUMBER(4) Combinaţia NUME + PRENUME să fie unică
2
Observaţie:
Constrângerile de tip CHECK se pot implementa la nivel de coloană doar dacă nu referă o altă
coloană a tabelului.
DROP TABLE salariat_***;

data_nasterii DATE,
functia VARCHAR2(9) NOT NULL,
sef NUMBER(4) REFERENCES salariat_*** (cod_ang),
email VARCHAR2(20) UNIQUE,
salariu NUMBER(9,2) CHECK (salariu > 0),
cod_dep NUMBER(4),
CONSTRAINT const_c_*** CHECK (data_angajarii > data_nasterii),
CONSTRAINT const_u_*** UNIQUE (nume,prenume,data_nasterii));
17. Ştergeţi tabelul salariat_***, iar apoi recreaţi-l implementând toate constrângerile la nivel de
tabel.
Observaţie: Constrângerea de tip NOT NULL se poate declara doar la nivel de coloană.
DROP TABLE salariat_***;

cod_ang NUMBER(4),
data_nasterii DATE,
functia VARCHAR2(9) NOT NULL,
sef NUMBER(4),
email VARCHAR2(20),
salariu NUMBER(9,2),
cod_dep NUMBER(4),
CONSTRAINT ccp_*** PRIMARY KEY (cod_ang),
CONSTRAINT cce_*** FOREIGN KEY (sef) REFERENCES salariat_***
(cod_ang),
CONSTRAINT cu1_*** UNIQUE (email),
CONSTRAINT cc1_*** CHECK (data_angajarii > data_nasterii),
CONSTRAINT cc2_***CHECK (salariu > 0),
CONSTRAINT cu2_*** UNIQUE (nume,prenume,data_nasterii));
18. Creaţi tabelul departament_*** care să aibă următoarea structură.
NUME TIP CONSTRÂNGERI

COD_DEP NUMBER(4) Cheie primară
NUME VARCHAR2(20) Not null
ORAS VARCHAR2(25)
3
Adăugarea constrângerilor ulterior creării tabelului, eliminarea, activarea sau dezactivarea
constrângerilor (ALTER TABLE)
- adaugă constrângeri
ALTER TABLE nume_tabel
ADD [CONSTRAINT nume_constr] tip_constr (coloana);
- elimină constrângeri
DROP [CONSTRAINT nume_constr] tip_constr (coloana);
- activare/dezactivare constrângere
MODIFY CONSTRAINT nume_constr ENABLE|DISABLE;
sau
ENABLE| DISABLE nume_constr;
19. Inseraţi o nouă înregistrare în salariat_*** de forma:
cod nume prenume data_n functia sef data_ang email salariu cod_dep
11-JUN-
2 N2 P2 economist 1 Sysdate E2 2000 10
1960
Ce observaţi? Introduceţi înregistrarea dar specificând valoarea NULL pentru coloana sef.
20. Încercaţi să adăugaţi o constrângere de cheie externă pe cod_dep din salariat_***. Ce
observaţi?

ADD CONSTRAINT cce2_*** FOREIGN KEY (cod_dep) REFERENCES
departament_*** (cod_dep);
21. Inseraţi o nouă înregistrare în departament_***. Apoi adăugaţi constrângerea de cheie externă
definită anterior.
cod_dep nume loc
10 Economic Bucuresti
22. Inseraţi noi înregistrări în salariat_***, respectiv în departament_***. Care trebuie să fie
ordinea de inserare?
cod nume prenume data_n functia sef data_ang email salariu cod_dep
11-JUN-
3 N3 P3 jurist 2 Sysdate E3 2500 20
1967
cod_dep nume loc

20 Juritic Constanta
23. Ştergeţi departamentul 20 din tabelul departament_***. Ce observaţi?
24. Ştergeţi constrângerea cce2_***. Recreaţi această constrângere adăugând opţiunea ON
DELETE CASCADE.
DROP CONSTRAINT cce2_***;
departament_*** (cod_dep) ON DELETE CASCADE;
25. Ştergeţi departamentul 20 din tabelul departament_***. Ce observaţi în tabelul salariat_***?
Anulaţi modificările.
4
26. Ştergeţi constrângerea cce2_***. Recreaţi această constrângere adăugând opţiunea ON
DELETE SET NULL.

DROP CONSTRAINT cce2_***;
departament_*** (cod_dep) ON DELETE SET NULL;
27. Încercaţi să ştergeţi departamentul 10 din tabelul departament_***. Ce observaţi?
Consultarea dicţionarului datelor
Informaţii despre tabelele create se găsesc în vizualizările :

 USER_TABLES – informaţii complete despre tabelele utilizatorului curent.
 ALL_TABLES – informaţii complete despre tabelele tuturor utilizatorilor.
 COLS – informaţii despre coloane.
 TAB – informaţii de bază despre tabelele existente în schema utilizatorului curent.
Informaţii despre constrângeri găsim în :

 USER_CONSTRAINTS – informaţii despre constrângerile definite de utilizatorul
curent;
 ALL_CONSTRAINTS – informaţii despre cosntrângerile definite de toţi utilizatorii.
5
LABORATOR 7 SQL - LDD
Vizualizări. Secvenţe. Indecşi. Sinonime.
 Definirea vizualizărilor
Vizualizările sunt tabele virtuale care sunt construite pe baza unor tabele sau vizualizări,
denumite tabele de bază. Ele nu conţin date ci sunt ca nişte imagini logice asupra datelor din tabelele
de bază. Sunt definite de o cerere SQL, de aceea mai sunt denumite şi cereri stocate.
Avantajele utilizării vizualizărilor:
- restricţionarea accesului la date;
- simplificarea unor cereri complexe;
- prezentarea de diferite imagini asupra datelor.
Vizualizările se pot fi simple sau complexe. Asupra vizualizărilor simple se pot realiza operaţii
LMD. Asupra vizualizărilor complexe nu sunt posibile operaţii LMD în toate cazurile decât dacă sunt
definiţi declanşatori de tip INSTEAD OF.
Caracteristici Simple Complexe
Număr de tabele de baza Un singur tabel Unul sau mai multe tabele
Conţine funcţii Nu Da
Conţine grupări de date Nu Da
Sintaxa simplificată a comenzii CREATE VIEW este:

CREATE [OR REPLACE] [FORCE | NOFORCE] VIEW nume_view [(alias, alias, ..)]
AS subcerere
[WITH CHECK OPTION [CONSTRAINT nume_constr]]
[WITH READ ONLY [CONSTRAINT nume_constr]];
- FORCE permite crearea vizualizarea înainte de a defini tabelele de bază;
- subcererea poate fi oricât de complexă dar nu poate conţine clauza ORDER BY;
- WITH CHECK OPTION permite inserarea şi modificarea prin intermediul vizualizării numai
a liniilor ce sunt accesibile vizualizării; dacă lipseşte numele constrângerii atunci sistemul
asociază un nume implicit de tip SYS_Cn acestei constrângeri;
- WITH READ ONLY asigură că prin intermediul vizualizării nu se pot executa operaţii LMD.
Nu se pot realiza operaţii LMD în vizualizări ce conţin:
- funcţii grup,
- clauza GROUP BY sau HAVING,
- cuvântul cheie DISTINCT,
- pseudocoloana ROWNUM,
- coloane definite de expresii,
- coloane NOT NULL din tabelul de bază, care nu sunt incluse în coloanele vizualizării.
- linii ce nu sunt accesibile vizualizării (în cazul utilizării clauzei WITH CHECK OPTION).
Nu se pot actualiza:
- coloane ale căror valori rezultă prin calcul sau definite cu ajutorul funcţiei DECODE,
- coloane care nu respectă constrângerile din tabelele de bază.
Pentru vizualizările bazate pe mai multe tabele, orice operaţie INSERT, UPDATE sau DELETE
poate modifica datele doar din unul din tabelele de bază. Acest tabel este cel protejat prin cheie (key
preserved).
Eliminarea unei vizualizări se face prin comanda DROP VIEW :
DROP VIEW nume_viz;
Observaţie:
Subcererile temporare caracterizate de un alias ce apar în comenzile SELECT, INSERT.
UPDATE, DELETE, MERGE se numesc vizualizai inline (de exemplu o subcerere utilizată
în clauza FROM a comenzii SELECT). Spre deosebire de vizualizările propriu-zise acestea
nu sunt considerate obiecte ale schemei şi sunt entităţi temporare.
Observaţie:
Reactualizarea tabelelor implică reactualizarea corespunzătoare a vizualizărilor.
Reactualizarea vizualizărilor nu implică întotdeauna reactualizarea tabelelor de bază.
1. Să se creeze vizualizarea v_emp_*** care să conţină codul şi numele salariaţilor din tabelul emp_***.
Să se afişeze conţinutul acesteia. Să se insereze o nouă înregistrare în această vizualizare. Ce
observaţi? Să se şteargă vizualizarea v_emp_***.
CREATE VIEW v_emp_*** (cod, nume)

AS
SELECT employee_id, last_name
FROM emp_***;
INSERT INTO v_emp_***

VALUES (400,’N1’);
DROP VIEW v_emp_***;
2. Să se creeze vizualizarea v_emp_*** care să conţină codul, numele, emailul, data angajării, salariul şi
codul jobului salariaţilor din tabelul emp_***. Să se analizeze structura şi conţinutul vizualizării. Să
se insereze o nouă înregistrare în această vizualizare. Să se verifice că noua înregistrare a fost inserată
şi în tabelul de bază.
Observaţie: Trebuie introduse neapărat în vizualizare coloanele care au constrângerea NOT NULL în
tabelul de bază (altfel, chiar dacă tipul vizualizării permite operaţii LMD, acestea nu vor fi posibile
din cauza nerespectării constrângerilor NOT NULL).
CREATE VIEW v_emp_***

AS
SELECT employee_id, last_name, email, hire_date, salary,job_id
FROM emp_***;
DESC v_emp_***
SELECT * FROM v_emp_***;
INSERT INTO v_emp_***

VALUES (400,’N1’,’E1’,SYSDATE,5000,’SA_REP’);
SELECT employee_id, last_name, email, hire_date, salary, job_id

FROM emp_***;
3. Să se mărească cu 1000 salariul angajatului având codul 400 din vizualizarea creată anterior. Ce efect
va avea această acţiune asupra tabelului de bază?
UPDATE v_emp_***
SET salary=salary+1000
WHERE employee_id = 400;
SELECT employee_id, last_name, salary
FROM emp_***
4. Să se şteargă angajatul având codul 400 din vizualizarea creată anterior. Ce efect va avea această
acţiune asupra tabelului de bază?
DELETE FROM v_emp_***

SELECT employee_id, last_name, salary

FROM emp_***
5. a) Să se creeze vizualizarea v_emp_dept_*** care să conţină employee_id, last_name, hire_date,

job_id, department_id din tabelul emp_*** şi coloana department_name din tabelul dept_***.
CREATE VIEW v_emp_dept_*** AS

SELECT employee_id, last_name, email, hire_date, job_id,
e.department_id, department_name
FROM emp_*** e, dept_*** d
WHERE e.department_id =d.department_id;
b) Să încerce inserarea înregistrării (500, 'N2', 'E2',SYSDATE,’SA_REP’,30, 'Administrativ') în

vizualizarea creată anterior.
INSERT INTO v_emp_dept_***

VALUES (500, 'N2', 'E2',SYSDATE,’SA_REP’,30, 'Administrativ');
c) Care dintre coloanele vizualizării v_emp_dept_*** sunt actualizabile?
SELECT column_name, updatable

FROM user_updatable_columns
WHERE UPPER(table_name) = UPPER('v_emp_dept_***');
d) Adăugaţi tabelului emp_*** constrângerea de cheie externă care referă tabelul dept_***, apoi
verificaţi ce coloane din vizualizarea v_emp_dept_*** sunt actualizabile.
ALTER TABLE emp_***

ADD CONSTRAINT cp_emp_*** PRIMARY KEY (employee_id);
ALTER TABLE dept_***

ADD CONSTRAINT cp_dept1_*** PRIMARY KEY (department_id);
ALTER TABLE emp_***

ADD CONSTRAINT ce_emp1_*** FOREIGN KEY (department_id)
REFERENCES dept_***(department_id);

d) Recreaţi vizualizarea v_emp_dept_***, apoi verificaţi ce coloane sunt actualizabile.

DROP VIEW v_emp_dept_***;
CREATE VIEW v_emp_dept_*** AS

SELECT employee_id, last_name, email, hire_date, job_id,
e.department_id, department_name
WHERE e.department_id =d.department_id;

f) Inseraţi o linie prin intermediul acestei vizualizări.

Obs. Tabelul ale cărui coloane sunt actualizabile este protejat prin cheie.
INSERT INTO v_emp_dept_*** (employee_id, last_name,email,hire_date,

job_id, department_id)
VALUES (500, 'N2', 'E2',SYSDATE,’SA_REP’,30);
g) Ce efect are o operaţie de ştergere prin intermediul vizualizării v_emp_dept_***? Comentaţi.
DELETE FROM v_emp_dept_***

SELECT employee_id, last_name, hire_date, job_id, department_id

FROM emp_***
SELECT department_id, department_name

FROM dept_***
WHERE department_id = 30;
6. Să se creeze vizualizarea v_dept_*** care să conţine codul şi numele departamentului, numărul de

angajaţi din departamentul respectiv şi suma alocată pentru plata salariilor. Această vizualizare
permite actualizări?
CREATE VIEW v_dept_*** (cod, nume, nr_angajati, val_salarii)

AS
SELECT e.department_id, department_name, COUNT(*) nr_angajati,
SUM(salary) val_salarii
GROUP BY e.department_id, department_name;
7. a) Să se creeze vizualizarea v_emp30_*** care să conţină numele, emailul, data angajării, salariul,
codul jobului şi codul departamentului celor care lucrează în departamentul 30. În această
vizualizare nu se va permite modificarea sau inserarea liniilor ce nu sunt accesibile ei. Daţi un nume
constrângerii.
CREATE VIEW v_emp30_*** AS
SELECT employee_id, last_name, email, hire_date, salary, job_id,
department_id
FROM emp_***
WHERE department_id=30
WITH CHECK OPTION CONSTRAINT ck_option1_***;
b) Să se listeze structura şi conţinutul vizualizării v_emp30_***.
DESCRIBE v_emp30_***
SELECT * FROM v_emp30_***;
c) Să se încerce prin intermediul vizualizării inserarea unui angajat în departamentul 10 şi a unui

angajat în departamentul 30.
INSERT INTO v_emp30_***

VALUES (111, 'N1', 'E1',SYSDATE,1000,’SA_REP’,10);
INSERT INTO v_emp30_***

VALUES (11, 'N11', 'E11',SYSDATE,1000,’SA_REP’,30);
d) Să se încerce prin intermediul vizualizării modificarea departamentului unui angajat.
UPDATE v_emp30_***
SET department_id =20
8. Să se creeze o vizualizare (v_dept_***) asupra tabelului dept_*** să nu permită efectuarea nici unei
operaţii LMD. Testaţi operaţiile de inserare, modificare şi ştergere asupra acestei vizualizări.
CREATE VIEW v_dept_*** AS

SELECT *
FROM dept_***
WITH READ ONLY;
9. Să se consulte informaţii despre vizualizarea v_dept_***. Folosiţi vizualizarea dicţionarului datelor

USER_VIEWS (coloanele VIEW_NAME şi TEXT).
Obs: Coloana TEXT este de tip LONG. În cazul selectării unei coloane de tip LONG trebuie utilizată
comanda SET LONG n pentru a seta numărul de caractere afişate.
SET LONG 200
SELECT view_name, text

FROM user_views
WHERE UPPER(view_name)=UPPER(’v_dept_***’);
 Definirea secvenţelor
O secvenţă este un obiect al bazei de date ce permite generarea de numere întregi unice cu scopul de a
fi folosiţi ca valori pentru cheia primară sau coloane numerice unice. Secvenţele sunt independente de
tabele.
Sintaxa comenzii CREATE SEQUENCE este:
CREATE SEQUENCE nume_secvenţă
[INCREMENT BY n]
[START WITH valoare_start]
[ {MAXVALUE valoare_maximă | NOMAXVALUE} ]
[ {MINVALUE valoare_minimă | NOMINVALUE} ]
[ {CYCLE | NOCYCLE} ]
[ {CACHE n | NOCACHE} ];
- INCREMENT BY specifică diferenţa dintre valorile succesive ale secvenţei (valoare implicită 1).
- START WITH specifică primul număr care va fi generat de secvenţă (valoare implicită 1).
- MAXVALUE, MINVALUE precizează valoarea maximă, respectiv minimă pe care o poate genera
secvenţa. Opţiunile NOMAXVALUE, NOMINVALUE sunt implicite. NOMAXVALUE specifică
valoarea maximă de 1027 pentru o secvenţă crescătoare şi -1 pentru o secvenţă descrescătoare.
NOMINVALUE specifică valoarea minimă 1 pentru o secvenţă crescătoare şi -1026 pentru o secvenţă
descrescătoare.
- CYCLE şi NOCYCLE specifică dacă secvenţa continuă să genereze numere după obţinerea valorii
maxime sau minime. NOCYCLE este opţiunea implicită.
- CACHE n precizează numărul de valori pe care server-ul Oracle le prealocă şi le păstrează în
memorie. În mod implicit, acest număr de valori este 20. Opţiunea CACHE pemite accesul mai rapid la
valorile secvenţei care sunt păstrate în memorie. Aceste valori sunt generate la prima referinţă asupra
secvenţei. Fiecare valoare din secvenţă se furnizează din secvenţa memorată. După utilizarea ultimei
valori prealocate secvenţei, următoarea solicitare a unei valori determină încărcarea unui alt set de
numere în memorie. Pentru a nu fi prealocate şi reţinute în memorie astfel de valori, se utilizează
opţiunea NOCACHE.
Pseudocoloanele NEXTVAL şi CURRVAL permit utilizarea secvenţelor.
- nume_secv.NEXTVAL returnează următoarea valoare a secvenţei, o valoare unică la fiecare
referire. Trebuie aplicată cel puţin o dată înainte de a folosi CURRVAL;
- nume_secv.CURRVAL returnează valoarea curentă a secvenţei.
Pseudocoloanele NEXTVAL şi CURRVAL se pot utiliza în:
- lista SELECT a comenzilor ce nu fac parte din subcereri;
- lista SELECT a unei cereri ce apare într-un INSERT;
- clauza VALUES a comenzii INSERT;
- clauza SET a comenzii UPDATE.
Pseudocoloanele NEXTVAL şi CURRVAL nu se pot utiliza:
- în lista SELECT a unei vizualizări;
- într-o comandă SELECT ce conţine DISTINCT, GROUP BY, HAVING sau ORDER BY;
- într-o subcerere în comenzile SELECT, UPDATE, DELETE;
- în clauza DEFAULT a comenzilor CREATE TABLE sau ALTER TABLE.
Ştergerea secvenţelor se realizează cu ajutorul comenzii DROP SEQUENCE.
DROP SEQUENCE nume_secv;
10. Să se creeze o secvenţă care are pasul de incrementare 10 şi începe de la 10, are ca valoare maximă
10000 şi nu ciclează.
CREATE SEQUENCE sec_***
INCREMENT BY 10
START WITH 10
MAXVALUE 10000
NOCYCLE;
11. Să se modifice toate liniile din tabelul emp_***, regenerând codul angajaţilor astfel încât să utilizeze
secvenţa sec_emp***. Să se anuleze modificările.
UPDATE emp_***
SET employee_id = sec_emp***.NEXTVAL;
ROLLBACK;
12. Să se introducă un nou salariat în tabelul emp_*** folosindu-se pentru codul salariatului secvenţa
creată.
INSERT INTO emp_*** (employee_id,last_name,email,hire_date,job_id)
VALUES(sec_emp***.NEXTVAL,'x','x',sysdate,'x');
13. Să se afişeze valoarea curentă a secvenţei.

SELECT sec_***.CURRVAL valoare
FROM DUAL;
Exerciţiu
a) Creaţi o secvenţă pentru generarea codurilor de departamente, seq_dept_***. Secvenţa va începe
de la 200, va creşte cu 10 la fiecare pas şi va avea valoarea maximă 20000, nu va cicla.
b) Să se selecteze informaţii despre secvenţele utilizatorului curent (nume, valoare minimă,
maximă, de incrementare, ultimul număr generat). Se va utiliza vizualizarea user_sequences.
c) Să se insereze o înregistrare nouă în DEPT_*** utilizând secvenţa creată.
d) Să se selecteze valoarea curentă a secvenţei.
e) Să se şteargă secvenţa.
 Definirea indecşilor
Un index este un obiect al unei scheme utilizator care este utilizat de server-ul Oracle pentru a mări
performanţele unui anumit tip de cereri asupra unui tabel.
Indecşii:
- evită scanarea completă a unui tabel la efectuarea unei cereri;
- reduc operaţiile de citire/scriere de pe disc utilizând o cale mai rapidă de acces la date şi anume
pointeri la liniile tabelului care corespund unor anumite valori ale unei chei (coloane);
- sunt independenţi de tabelele pe care le indexează, în sensul că dacă sunt şterşi nu afectează
conţinutul tabelelor sau comportamentul altor indecşi;
- sunt menţinuţi şi utilizaţi automat de către server-ul Oracle;
- sunt şterşi odată cu eliminarea tabelului asociat.
Indecşii pot fi creaţi :
- automat: la definirea unei constrângeri PRIMARY KEY sau UNIQUE;
- manual: cu ajutorul comenzii CREATE INDEX.
Se creează un index atunci când:
- o coloană conţine un domeniu mare de valori;
- o coloană conţine un număr mare de valori null;
- una sau mai multe coloane sunt folosite des în clauza WHERE sau în condiţii de join în programele
de aplicaţii;
- tabelul este mare şi de obicei cererile obţin mai puţin de 2%-4% din liniile tabelului;
- tabelul nu este modificat frecvent.
Sintaxa comenzii CREATE INDEX:
CREATE [UNIQUE] INDEX nume_index
ON tabel (coloana1 [, coloana2…]);
Modificarea unui index se face prin comanda ALTER INDEX.
Eliminarea unui index se face prin comanda: DROP INDEX nume_index;
14. Să se creeze un index neunic, emp_last_name_idx_***, asupra coloanei last_name din tabelul
emp_***.
15. Să se creeze indecşi unici asupra codului angajatului (employee_id) şi asupra combinaţiei last_name,
first_name, hire_date.
16. Creaţi un index neunic asupra coloanei department_id din emp_*** pentru a eficientiza joinurile
dintre acest tabel şi dept_***.
 Definirea sinonimelor
Pentru a simplifica accesul la obiecte se pot asocia sinonime acestora.
Crearea unui sinonim este utilă pentru a evita referirea unui obiect ce aparţine altui utilizator
prefixându-l cu numele utilizatorului şi pentru a scurta numele unor obiecte cu numele prea lung.
Comanda pentru crearea sinonimelor este:
CREATE [PUBLIC] SYNONYM nume_sinonim
FOR obiect;
Eliminarea sinonimelor se face prin comanda DROP SYNONYM nume_sinonim;
17. Creaţi un sinonim public se_*** pentru tabelul emp_***.
18. Creaţi un sinonim pentru vizualizarea v_dept_***.
19. Utilizând sinonimele create anterior, afişaţi informaţii depre salariţi şi despre departamente.
 Informaţii din dicţionarul datelor
Tipuri de vizualizări ale dicţionarului datelor:

ALL_* - obiecte accesibile utilizatorului curent,
DBA_* - obiecte accesibile numai administratorului,
USER_* - obiecte ale utilizatorului curent
1. Tabelele utilizatorului curent:
SELECT table_name
FROM user_tables
ORDER BY table_name;
2. Definiţiile şi numele constrângerilor:
SELECT constraint_name, constraint_type, search_condition, table_name

FROM user_constraints
WHERE table_name IN ('EMPLOYEES', 'DEPARTAMENTS’)
ORDER BY table_name, constraint_name;
3. Coloanele asociate unei constrângeri:
SELECT constraint_name, column_name

FROM user_cons_columns
WHERE table_name IN ('EMPLOYEES', 'DEPARTAMENTS’)
ORDER BY table_name, constraint_name;
4. Informaţii despre vizualizări:
SELECT view_name
FROM user_views;
5. Informaţii referitoare la secvenţe:
SELECT sequence_name, min_value, max_value, increment_by, last_number

FROM user_sequences;
6. Informaţii referitoare la indecşi:
SELECT index_name, table_name
FROM user_indexes;
SELECT index_name
FROM user_ind_columns;
SELECT a.index_name, a.column_name,a.column_position poz, b.uniqueness

FROM user_indexes b, user_ind_columns a
WHERE a.index_name = b.index_name
AND a.table_name = 'EMP_***';
7. Informaţii referitoare la sinonime:
SELECT synonym_name, table_owner, table_name

FROM user_synonyms;
1. GENERALITĂŢI DESPRE BAZE DE DATE
1.1. Introducere
Baza de date este un ansamblu structurat de date coerente, fără
redondanţă inutilă, astfel încât acestea pot fi prelucrate eficient de mai
mulţi utilizatori într-un mod concurent.
Baza de date este o colecţie de date persistente, care sunt folosite de
către sistemele de aplicaţii ale unei anumite „întreprinderi“. Datele din baza
de date persistă deoarece, după ce au fost acceptate de către sistemul de
gestiune pentru introducerea în baza de date, ele pot fi şterse din bază
numai printr-o cerere explicită adresată sistemului de gestiune.
Aici, termenul de „întreprindere“ este un cuvânt generic, utilizat
pentru a desemna orice organizaţie independentă, de natură tehnică,
comercială, ştiinţifică sau de alt tip. Întreprinderea poate fi, de exemplu, un
spital, o bancă, o facultate, o fabrică, un aeroport etc. Fiecare întreprindere
are regulile proprii de funcţionare şi conţine o mulţime de date
referitoare la modul său de operare.
Datele din baza de date pot fi atît integrate, cât şi partajate.
Noţiunea de integrat se referă la faptul că baza de date poate fi considerată
ca o unificare a mai multor fişiere, iar prin partajare se înţelege că baza de
date poate fi partajată concurent între diferiţi utilizatori.
Un sistem de gestiune a bazelor de date (SGBD – Data Base
Management System) este un produs software care asigură interacţiunea cu
o bază de date, permiţând definirea, consultarea şi actualizarea datelor din
baza de date. Toate cererile de acces la baza de date sunt tratate şi
controlate de către SGBD. Organizarea datelor în baze de date constituie o
formă de centralizare a acestora. Aceasta implică existenţa unui
administrator al bazei de date (DBA – Data Base Administrator)
care este o persoană sau un grup de persoane ce răspund de ansamblul
activităţilor (analiză, proiectare, implementare, exploatare, întreţinere etc.)
legate de baza de date. Atribuţiile unui administrator pot fi grupate în patru
mari categorii: atribuţii de proiectare, atribuţii administrative, atribuţii
operative şi atribuţii de coordonare.
Concepte ale bazelor de date relaţionale
În această parte se face o prezentare generală a conceptelor bazelor

de date relaţionale.
O bază de date relațională este o colecţie de informaţii
interrelaţionate gestionate ca o singură unitate.
2
A ceastă definiţie este foarte largă, deoarece există mari diferenţe
între concepţiile diferiţilor producători care pun la dispoziţie sisteme de
baze de date. De exemplu, Oracle Corporation defineşte o bază de date ca
fiind o colecţie de fişiere fizice gestionate de o singură instanţă (copie) a
produsului software pentru baze de date, în timp ce Microsoft defineşte o
bază de date SQL Server ca fiind o colecţie de date şi alte obiecte.
Un obiect al bazei de date este o structură de date denumită, stocată
în bază de date, cum ar fi un tabel, o vizualizare sau un index.
Există mari diferenţe între implementările furnizorilor de baze de
date. În majoritatea sistemelor de baze de date, datele sunt stocate în mai
multe fişiere fizice, dar în Microsoft Access toate obiectele bazei de date,
împreună cu datele care aparţin unei baze de date sunt stocate într-un
singur fişier fizic.(Un fişier este o colecţie de înregistrări înrudite stocate ca
o singură untiate de sistemul de operare al calculatorului.) Totuşi, unul
dintre principalele avantaje ale bazelor de date relaţionale este faptul că
detaliile de implementare fizică sunt separate de definiţiile logice ale
obiectelor bazei de date, astfel încât majoritatea utilizatorilor bazei de date
nu au nevoie să ştie unde (şi cum) sunt stocate obiectele bazei de date în
sistemul de fişiere al calculatorului.
Sistem de gestionare a bazei de date (DBMS sau SGBD)
Un sistem de gestionare a bazei de date (DBMS database

management system) este un produs software furnizat de producătorul
bazei de date. Produse software precum Microsoft Access, Microsoft SQL
Server, Oracle Database,Sybase, DB2,INGRES, MySQL şi Postgre SQL
fac parte din categoria DBMS sau, mai corect, DBMS relaţionale
(RDBMS).
RDBMS-urile sunt cunoscute şi sub numele de SGBD-uri. Ambele
prescurtări vor fi folosite în acestă expunere.
Sistemul DBMS pune la dispoziţie toate serviciile de bază necesare
pentru organizarea şi întreţinerea bazei de date, inclusiv următoarele:
- Transferarea datelor în şi din fişierele fizice de date, în funcţie de
cerinţe.
- Gestionarea accesului concurenţial la date al mai multor
utilizatori, inclusiv prevenirea conflictelor care ar putea fi
cauzate de actualizările simultane.
- Gestionarea tranzacţiilor, astfel încât toate modificările făcute
asupra bazei de date printr-o tranzacţie să fie executate ca o
singură unitate. Cu alte cuvinte, dacă tranzacţia reuşeşte, toate
3
modificările efectuate de tranzacţie sunt înregistrate în bază de

date; dacă tranzacţia eşuează, nici una dintre modificări nu este
înregistrată în bază de date.Totuşi, reţineţi ca unele sisteme
RDBMS nu asigură suportul pentru tranzacţii.
- Acceptă un limbaj de interogare, care reprezintă sistemul de
comenzi folosit de utilizator pentru a obţine date din bază de
date. SQL este principalul limbaj folosit pentru sistemele DBMS
relaţionale.
- Funcţii pentru salvarea bazei de date şi pentru refacerea bazei de
date în urma erorilor.
- Mecanisme de securitate pentru împiedicarea accesului neautorizat
la date şi modificarea acestora.
Ce este o bază de date relaţională ?
O bază de date relaţională este o bază de date care respectă modelul

relaţional, dezvoltat de Dr.E.F.Codd. Modelul relaţional prezintă datele sub
forma familiarelor tabele bidimensionale, similar cu o foaie de calcul
tabelar. Spre deosebire de o foaie de calcul tabelar, nu este obligatoriu ca
datele să fie stocate într-o formă tabelară, iar modelul permite şi
combinarea tabelelor (crearea uniunilor (joining), în terminologia
relaţională) pentru formarea vizualizarilor, care sunt prezentate tot ca tabele
bidimensionale. Flexibilitatea extraordinară a bazelor de date relaţionale
este dată de posibilitatea de a folosi tabelele independent sau în combinaţii,
fără nici o ierarhie sau secvenţă predefinită în care trebuie să se facă
accesul la date.
Dicţionarul datelor (catalog de sistem), structurat şi administrat

ca o bază de date (metabază de date), contine „date despre date“, furnizează
descrierea tuturor obiectelor unei baze de date, starea acestor obiecte,
diversele constrângeri de securitate şi de integritate etc. Dicţionarul poate fi
interogat, la fel, ca orice altă bază de date.
4
1.2. Gestiunea bazelor de date
Un sistem de baze de date presupune următoarele componente

principale, care definesc arhitectura acestuia:
• baza de date propriu-zisă în care se memorează datele;
• sistemul de gestiune a bazei de date, care realizează gestionarea şi
prelucrarea complexă a datelor;
• un dicţionar al bazei de date (metabaza de date), ce conţine
informaţii despre date, structura acestora, statistici, documentaţie;
• mijloace hardware (comune sau specializate);
• reglementări administrative destinate bunei funcţionări a
sistemului;
• personalul implicat (utilizatori finali, administratorul datelor,
administratorul bazei de date, proiectanţi, programatori de
aplicaţii).
Se pot identifica patru categorii de persoane implicate în mediul
bazelor de date:
• administratorii de date şi baze de date,
• proiectanţii (designeri) de baze de date,
• programatorii de aplicaţii,
• utilizatorii finali.
Administratorul de date (DA) este un manager, nu un tehnician, ce:
• decide care date trebuie stocate în baza de date;
• stabileşte regulile de întreţinere şi de tratare a acestor date după ce
sunt stocate. De exemplu, o reg u lă ar putea fi aceea prin care se
stabilesc pentru utilizatori privilegii asupra informaţiilor din baza
de date, cu alte cuvinte o anumită politică de securitate a datelor.
Administratorul bazei de date (DBA) este responsabil cu
implementarea deciziilor administratorului de date şi cu controlul general al
sistemului, la nivel tehnic. El este un profesionist în domeniul IT, care:
• creează baza de date reală;
• implementează elementele tehnice de control;
• este responsabil cu asigurarea funcţionării sistemului la
performanţe adecvate, cu monitorizarea performanţelor;
• furnizează diverse servicii tehnice etc.
Proiectanţii de baze de date pot acoperi atât aspectul fizic, cât şi cel
logic al concepţiei.
Proiectantul de baze de date care abordează direcţia logică trebuie să
posede o cunoaştere completă şi amănunţită a modelului real de proiectat şi
a regulilor de funcţionare ale acestuia. Practic, acesta proiectează
5
conceptual baza de date, iar modelul creat este independent de programele

de aplicaţii, de limbajele de programare. De asemenea, va proiecta logic
baza de date, proiectare care este îndreptată spre un anumit model de date
(relaţional, orientat obiect, ierarhic etc.).
Proiectantul de baze de date fizice preia modelul logic de date şi
stabileşte cum va fi realizat fizic. Acesta trebuie să cunoască
funcţionalităţile SGBD-ului, avantajele şi dezavantajele fiecărei alternative
corespunzătoare unei implementări. Practic, se face transpunerea modelului
logic într-un set de tabele supuse unor constrângeri, se selectează structuri
de stocare şi metode de acces specifice, astfel încât să se asigure
performanţe, se iau măsuri privind securitatea datelor.
Utilizatorii finali sunt cei care accesează interactiv baza de date.
Aceasta a fost proiectată, implementată, întreţinută pentru a satisface
necesităţile informaţionale ale clienţilor. Utilizatorii finali pot fi utilizatori
simpli, care nu cunosc nimic despre baza de date, despre SGBD, dar
accesează baza prin intermediul unor programe de aplicaţie. În general,
această clasă de utilizatori alege anumite opţiuni din meniul aplicaţiei.
Există utilizatori finali sofisticaţi, care sunt familiarizaţi cu structura bazei
de date. Ei pot utiliza limbaje speciale pentru a exploata posibilităţile
oferite de baza de date.
Programatori de aplicaţii sunt responsabili de scrierea programelor
aplicaţie ce conferă funcţionalitatea cerută de utilizatorii finali. Programele
pot fi scrise în diferite limbaje de programare (C++, PL/SQL, Java etc.).
Cerinţe minimale care se impun unei baze de date:

• asigurarea unei redundanţe minime în date;
• furnizarea în timp util a informaţiilor solicitate (timpul de răspuns
la o interogare);
• asigurarea unor costuri minime în prelucrarea şi întreţinerea
informaţiei;
• capacitatea de a satisface, cu aceleaşi date, necesităţi
informaţionale ale unui număr mare de utilizatori,
• posibilitatea de adaptare la cerinţe noi, răspunsuri la interogări
neprevăzute iniţial (flexibilitate);
• exploatarea simultană a datelor de către mai mulţi utilizatori
(sincronizare);
• asigurarea securităţii datelor prin mecanisme de protecţie împotriva
accesului neautorizat (confidenţialitate);
6
• înglobarea unor facilităţi destinate validării datelor şi recuperării
lor în cazul unor deteriorări accidentale, garantarea (atât cât este
posibil) că datele din baza de date sunt corecte (integritate);
• posibilitatea de valorificare a eforturilor anterioare şi anticiparea
nevoilor viitoare (compatibilitate şi expandabilitate);
• permisivitatea, prin ierarhizarea datelor după criteriul frecvenţei
acceselor, a unor reorganizări (eventual dinamice) care sporesc
performanţele bazei.
În cadrul unei baze de date putem vorbi de patru niveluri de
abstractizare şi de percepţie a datelor: intern, conceptual, logic şi
extern. Datele există doar la nivel fizic, iar celelalte trei niveluri reprezintă
virtualizări ale acestora.
• Nivelul fizic (intern) este descris de schema fizică a datelor (bit,
octet, adresă);
• Nivelul conceptual este descris de schema conceptuală a datelor
(articol, înregistrare, zonă) şi reprezintă viziunea programatorilor
de sistem asupra datelor;
• Nivelul logic este descris de una din schemele logice posibile ale
datelor şi reprezintă viziunea programatorului de aplicaţie asupra
datelor;
• Nivelul virtual (extern) reprezintă viziunea utilizatorului final
asupra datelor.
Independenţa datelor cuprinde două aspecte fundamentale: o
modificare a structurii fizice nu va afecta aplicaţia şi reciproc, modificări
ale aplicaţiei vor lăsa nealterată structura fizică de date.
• Independenţa fizică: posibilitatea modificării schemei fizice a
datelor fără ca aceasta să implice modificarea schemei conceptuale,
a schemei logice şi a programelor de aplicaţie. Este vorba despre
imunitatea programelor de aplicaţie faţă de modificările modului în
care datele sunt stocate fizic şi accesate.
• Independenţa logică: posibilitatea modificării schemei conceptuale
a datelor fără ca aceasta să implice modificarea schemei logice şi a
programelor de aplicaţie. Prin independenţa logică a datelor se
urmăreşte a se crea fiecărui utilizator iluzia că este singurul
beneficiar al unor date pe care, în realitate, le foloseşte în comun
cu alţi utilizatori.
Independenţă faţă de strategiile de acces permite programului să
precizeze data pe care doreşte să o acceseze, dar nu modul cum accesează
această dată. SGBD-ul va stabili drumul optim de acces la date.
7
În limbajele de programare uzuale declaraţiile şi instrucţiunile

executabile aparţin aceluiaşi limbaj. În lumea bazelor de date, funcţiile de
declarare şi de prelucrare a datelor sunt realizate cu ajutorul unor limbaje
diferite, numite limbaje pentru baze de date.
• Limbaje pentru definirea datelor (DDL – Data Description
Language). Descrierea concretă a unui DDL este specifică fiecărui
sistem de gestiune, dar funcţiile principale sunt aceleaşi. La nivel
conceptual, DDL realizează definirea entităţilor şi a atributelor
acestora, sunt precizate relaţiile dintre date şi strategiile de acces la
ele, sunt stabilite criterii diferenţiate de confidenţialitate şi de
validare automată a datelor utilizate.
• Limbaje pentru prelucrarea datelor (DML – Data Manipulation
Language). Operaţiile executate în cadrul unei baze de date
presupun existenţa unui limbaj specializat, în care comenzile se
exprimă prin fraze ce descriu acţiuni asupra bazei. În general, o
comandă are următoarea structură: operaţia (calcul aritmetic sau
logic, editare, extragere, deschidere-închidere, adăugare, ştergere,
căutare, reactualizare etc.), criterii de selecţie, mod de acces
(secvenţial, indexat etc.), format de editare. Există limbaje DML
procedurale, care specifică cum se obţine rezultatul unei comenzi
DML şi limbaje neprocedurale, care descriu doar datele ce vor fi
obţinute şi nu modalitatea de obţinere a acestora.
• Limbaje pentru controlul datelor (DCL – Data Control Language).
Controlul unei baze de date se referă la asigurarea confidenţialităţii
şi integrităţii datelor, la salvarea informaţiei în cazul unor
defecţiuni, la obţinerea unor performanţe, la rezolvarea unor
probleme de concurenţă.
Limbajele universale nu se utilizează frecvent pentru gestionarea

unei baze de date, dar există această posibilitate. De exemplu, sistemul
Oracle este dotat cu precompilatoare (C, Pascal, ADA, Cobol, PL/1,
Fortran) care ajută la incorporarea de instrucţiuni SQL sau blocuri PL/SQL
în programe scrise în alte limbaje, de nivel înalt, numite limbaje gazdă.
Sistemul de gestiune a bazelor de date interacţionează cu programele
de aplicaţie ale utilizatorului şi cu baza de date, oferind o mulţime de
facilităţi. Realizarea optimă a acestor facilităţi este asigurată de
obiectivele fundamentale ale unui sistem de gestiune. Câteva dintre
aceste obiective vor fi enumerate în continuare.
• Independenţa fizică. Obiectivul esenţial este acela de a permite
realizarea independenţei structurilor de stocare în raport cu
8
structurile de date din lumea reală. Se defineşte mulţimea de date
indiferent de forma acesteia din lumea reală, ţinând seama doar de
a realiza un acces simplu la date şi de a obţine anumite
performanţe.
• Independenţa logică. Grupul de lucru care exploatează baza de date
poate să utilizeze diferite informaţii de bază (nu aceleaşi), pentru a-
şi construi entităţi şi relaţii. Fiecare grup de lucru poate să
cunoască doar o parte a semanticii datelor, să vadă doar o
submulţime a datelor şi numai sub forma în care le doreşte.
Această independenţă asigură imunitatea schemelor externe faţă de
modificările făcute în schema conceptuală.
• Prelucrarea datelor de către neinformaticieni. Neinformaticienii
văd datele independent de implementarea lor şi pot exploata aceste
date prin intermediul unui sistem de meniuri oferit de aplicaţia pe
care o exploatează.
• Administrarea centralizată a datelor. Administrarea datelor
presupune definirea structurii datelor şi a modului de stocare a
acestora. Administrarea este în general centralizată şi permite o
organizare coerentă şi eficace a informaţiei.
• Coerenţa datelor. Informaţia trebuie să satisfacă constrângeri
statice sau dinamice, locale sau generale.
• Neredundanţa datelor. Fiecare aplicaţie posedă datele sale proprii
şi aceasta conduce la numeroase dubluri. De asemenea,
organizarea nejudicioasă a relaţiilor poate să genereze redundanţă
în date. Administrarea coerentă a datelor trebuie să asigure
neduplicarea fizică a datelor. Totuşi, nu sunt excluse nici cazurile
în care, pentru a realiza performanţe referitoare la timpul de acces
la date şi răspuns la solicitările utilizatorilor, să se accepte o
anumită redundanţă a datelor.
• Partajabilitatea datelor. Aceasta permite ca aplicaţiile să partajeze
datele din baza de date în timp şi simultan. O aplicaţie poate folosi
date ca şi cum ar fi singura care le utilizează, fără a şti că altă
aplicaţie, concurent, le poate modifica.
• Securitatea şi confidenţialitatea datelor. Datele trebuie protejate de
un acces neautorizat sau rău intenţionat. Există mecanisme care
permit identificarea şi autentificarea utilizatorilor şi există
proceduri de acces autorizat care depind de date şi de utilizator.
Sistemul de gestiune trebuie să asigure securitatea fizică şi logică a
informaţiei şi să garanteze că numai utilizatorii autorizaţi pot
efectua operaţii corecte asupra bazei de date.
9
Sistemele de gestiune a bazelor de date au, din nefericire, şi

dezavantaje dintre care se remarcă:
• complexitatea şi dimensiunea sistemelor pot să crească
considerabil, datorită necesităţii extinderii funcţionalităţilor
sistemului;
• costul, care variază în funcţie de mediu şi funcţionalitatea oferită,
la care se adugă cheltuieli periodice de întreţinere;
• costuri adiţionale pentru elemente de hardware;
• costul conversiei aplicaţiilor existente, necesară pentru ca acestea
să poată funcţiona în noua configuraţie hardware şi software;
• impactul unei defecţiuni asupra aplicaţiilor, bazei de date sau
sistemului de gestiune.
Structura unui sistem de gestiune a bazelor de date este de

complexitate variabilă, iar nivelul real de funcţionalitate diferă de la produs
la produs. În orice moment apar noi necesităţi, care cer o nouă
funcţionalitate, astfel încât aceasta nu va putea deveni niciodată statică. În
general, un SGBD trebuie să includă cel puţin cinci clase de module:
• programe de gestiune a bazei de date (PGBD), care realizează
accesul fizic la date ca urmare a unei comenzi;
• module pentru tratarea limbajului de definire a datelor, ce permit
traducerea unor informaţii (care realizează descrierea datelor, a
legăturilor logice dintre acestea şi a constrângerilor la care sunt
supuse), în obiecte ce pot fi apoi exploatate în manieră procedurală
sau neprocedurală;
• module pentru tratarea limbajului de prelucrare a datelor
(interpretativ, compilativ, generare de programe), care permit
utilizatorilor inserarea, ştergerea, reactualizarea sau consultarea
informaţiei dintr-o bază de date;
• module utilitare, care asigură întreţinerea, prelucrarea, exploatarea
corectă şi uşoară a bazei de date;
• module de control, care permit controlul programelor de aplicaţie,
asigurarea confidenţialităţii şi integrităţii datelor, rezolvarea unor
probleme de concurenţă, recuperarea informaţiei în cazul unor
avarii sau defecţiuni hardware sau software etc.
10
Modulele PGBD asigură accesul fizic la date ca urmare a unei
comenzi. Cum lucrează aceste module?
• găsesc descrierea datelor implicate în comandă;
• identifică datele şi tipul acestora;
• identifică informaţii ce permit accesul la structurile fizice de
stocare (fişiere, volume etc.);
• verifică dacă datele sunt disponibile;
• extrag datele, fac conversiile, plasează datele în spaţiul de memorie
al utilizatorului;
• transmit informaţii de control necesare execuţiei comenzii, în
spaţiul de memorie al utilizatorului;
• transferă controlul programului de aplicaţie.
Prin urmare, din punct de vedere conceptual:
• utilizatorul lansează o cerere de acces;
• SGBD-ul acceptă cererea şi o analizează;
• SGBD-ul inspectează pe rând, schema internă corespunzatoare
utilizatorului, schema conceptuală, definiţia structurii de stocare şi
corespondenţele corespunzătoare;
• SGBD-ul execută operaţiile necesare în baza de date stocată.
1.3. Arhitectura sistemelor de gestiune a bazelor de date
Asigurarea independenţei fizice şi logice a datelor impune adoptarea

unei arhitecturi de baze de date organizată pe trei niveluri:
• nivelul intern (baza de date fizică);
• nivelul conceptual (modelul conceptual, schema conceptuală);
• nivelul extern (modelul extern, subschema, vizualizarea).
Nivelul central este nivelul conceptual. Acesta corespunde structurii

canonice a datelor ce caracterizează procesul de modelat, adică structura
semantică a datelor fără implementarea pe calculator. Schema conceptuală
permite definirea tipurilor de date ce caracterizează proprietăţile elementare
ale entităţilor, definirea tipurilor de date compuse care permit regruparea
atributelor pentru a descrie entităţile modelului şi legăturile între aceste
entităţi, definirea regulilor pe care trebuie să le respecte datele etc.
Nivelul intern corespunde structurii interne de stocare a datelor.
Schema internă permite descrierea datelor unei baze sub forma în care sunt
11
stocate în memoria calculatorului. Sunt definite fişierele care conţin aceste

date, articolele din fişiere, drumurile de acces la aceste articole etc.
La nivel conceptual sau intern, schemele descriu o bază de date. La
nivel extern schemele descriu doar o parte din date care prezintă interes
pentru un utilizator sau un grup de utilizatori. Schema externă reprezintă o
descriere a unei părţi a bazei de date ce corespunde viziunii unui program
sau unui utilizator. Modelul extern folosit este dependent de limbajul
utilizat pentru prelucrarea bazei de date. Schema externă permite asigurarea
unei securităţi a datelor. Un grup de lucru va accesa doar datele descrise în
schema sa externă, iar restul datelor sunt protejate împotriva accesului
neautorizat sau rău intenţionat.
Pentru o bază de date particulară există o singură schemă internă, o
singură schemă conceptuală, dar există mai multe scheme externe.
În afară de aceste trei niveluri, arhitectura presupune şi anumite
corespondenţe dintre acestea:
• corespondenţa conceptual-intern defineşte relaţia dintre nivelul
conceptual şi baza de date stocată, specificând modul în care
înregistrările şi câmpurile conceptuale sunt reprezentate la nivel
intern;
• corespondenţa extern-conceptual defineşte relaţia dintre o anumită
vizualizare externă şi nivelul (vizualizarea) conceptual,
reprezentând cheia independenţei logice de date;
• corespondenţa extern-extern permite definirea unor vizualizări
externe în funcţie de altele, fără a necesita o definiţie explicită a
corespondenţei cu nivelul conceptual.
Arhitectura funcţională de referinţă propusă de grupul de lucru
ANSI/X3/SPARC este axată pe dicţionarul datelor şi cuprinde două părţi:
• prima, permite descrierea datelor (compoziţia dicţionarului
datelor);
• a doua, permite prelucrarea datelor (interogarea şi reactualizarea
bazei de date).
În fiecare parte se regăsesc cele trei niveluri: intern, conceptual şi
extern. Acestea nu sunt neapărat distincte pentru orice SGBD.
Interfeţele numerotate din figura 1.1, ce descriu arhitectura de
referinţă a unui SGBD, corespund următoarelor transformări:
a) Limbaj de descriere a datelor conceptuale, format sursă – permite
administratorului întreprinderii să definească schema conceptuală,
format sursă.
12
b) Limbaj de descriere a datelor conceptuale, format obiect – se
obţine din compilarea celui precedent şi permite aranjarea schemei
obiect în dicţionarul datelor.
c) Limbaj de descriere a datelor conceptuale, format editare –
permite administratorilor aplicaţiilor şi a bazelor să consulte
schema conceptuală pentru a defini reguli de corespondenţă.
d) Limbaje de descriere a datelor externe, format sursă – permit
administratorilor aplicaţiilor să definească scheme externe
corespunzând schemei conceptuale. Deoarece sistemele de
gestiune pot suporta mai multe modele externe, pot exista mai
multe limbaje de descriere a datelor externe.
e) Limbaje de descriere a datelor externe, format obiect – corespund
formelor compilate ale celor precedente şi permit aranjarea
schemelor externe (obiect) în dicţionarul datelor.
f) Limbaj de descriere a datelor interne, format sursă – permite
administratorului bazei de date să definească schema internă şi
regulile de corespondenţă cu schema conceptuală.
g) Limbaj de descriere a datelor interne, format obiect – corespunde
formei compilate a celui precedent şi permite aranjarea schemei
interne (obiect) în dicţionarul datelor.
h) Limbaje de prelucrare a datelor externe, format sursă – permit
programatorilor de aplicaţii sau utilizatorilor neinformaticieni să
manipuleze date externe (view).
i) Limbaje de prelucrare a datelor externe, format obiect – corespund
formelor compilate ale celor precedente.
j) Limbaj de prelucrare a datelor conceptuale, format obiect – produs
de procesorul de transformare extern/ conceptual pentru a
manipula datele externe.
k) Limbaj de prelucrare a datelor interne, format obiect –produs de
procesorul de transformare conceptual/intern pentru a gestiona
datele interne.
l) Limbaj de stocare a datelor, format obiect – corespunde interfeţei
cu sistemul de stocare a datelor.
m) Interfaţa cu memoria secundară – permite efectuarea de
intrări/ieşiri în/din unitatea de memorie secundară.
n) Interfaţa de acces la dicţionarul datelor – permite diverselor
procesoare de transformare să acceseze scheme obiect şi reguli de
corespondenţă.
13
Procesoarele din figura 1.1 au următoarele funcţii:

• procesorul schemei conceptuale compilează schema conceptuală şi
dacă nu sunt erori depune schema compilată în dicţionarul datelor;
• procesorul schemei externe compilează schemele externe şi
regulile de corespondenţă externă şi dacă nu sunt erori aranjează
schema compilată şi regulile de corespondenţă în dicţionarul
datelor;
• procesorul schemei interne are rol similar pentru schema internă;
• procesorul de transformare extern/conceptual transformă
manipulările externe în manipulări conceptuale şi invers, datele
conceptuale în date externe;
• procesorul de transformare conceptual/intern transformă
manipulările conceptuale în manipulări interne şi invers, datele
interne în date conceptuale;
• procesorul de transformare intern/stocare transformă manipulările
interne în primitive ale sistemului de stocare şi invers, eliberează
datele stocate într-un format corespunzător schemei interne.
14
administrator
întreprindere
a
administratorul c procesor c administratorul
bazei de date schema aplicaţiilor
DESCRIERE
conceptuală
b
f d
g e
procesor dicţionarul procesor
schema datelor schema
internă externă
procesor k procesor j procesor

intern/ conceptual/ extern/
alocare intern conceptual
l i
sistem
PRELUCRARE
program
de aplicaţii
alocare extern
h h
m
programator
aplicaţie utilizatori
memorii
secundare
Fig. 1.1. Arhitectura de referinţă a unui SGBD.
Gardarin a propus o arhitectură funcţională apropiată de arhitectura

sistemelor de gestiune actuale care are la bază doar două niveluri:
• schema, care corespunde integrării schemelor interne şi
conceptuale;
• vizualizarea, care este o schemă externă.
15
Sistemul de gestiune gestionează un dicţionar de date care este

alimentat prin comenzi de definire a schemei şi prin comenzi de definire a
vizualizărilor.
Aceste comenzi, precum şi cererile de prelucrare sunt analizate şi
tratate de un procesor numit analizor. Analizorul realizează analiza
sintactică şi semantică a cererii şi o traduce în format intern. O cerere în
format intern care face referinţă la o vizualizare este tradusă în una sau mai
multe cereri care fac referinţă la obiecte ce există în baza de date
(modificarea cererilor).
În cadrul acestei arhitecturi există un procesor, numit translator,
care realizează modificarea cererilor, asigură controlul drepturilor de acces
şi controlul integrităţii în cazul reactualizărilor.
Componenta cheie a sistemului de gestiune este procesorul
optimizor care elaborează un plan de acces optim pentru a trata cererea.
Acest procesor descompune cererea în operaţii de acces elementare şi alege
o ordine de execuţie optimală. De asemenea, evaluează costul planului de
acces înaintea execuţiei sale.
Planul de acces ales şi elaborat de optimizor este executat de un
procesor numit executor. La acest nivel este gestionat controlul
concurenţei.
1.4. Evoluţia bazelor de date
Istoria bazelor de date şi a sistemelor de gestiune a bazelor de date

poate fi rezumată în trei generaţii:
• sisteme ierarhice şi reţea,
• sisteme relaţionale,
• sisteme avansate (orientate obiect, relaţionale orientate obiect,
deductive, distribuite, multimedia, multibaze, active, temporale,
decizionale, magazii de date etc.).
•
Baze de date ierarhice şi reţea
Pentru modelele ierarhice şi reţea, datele sunt reprezentate la nivel de
articol prin legături ierarhice (arbore) sau de tip graf. Slaba independenţă
fizică a datelor complică administrarea şi prelucrarea acestora. Limbajul de
prelucrare a datelor impune programatorului să specifice drumurile de
acces la date.
16
Baze de date relaţionale
A doua generaţie de SGBD-uri este legată de apariţia modelelor
relaţionale (1970), care tratează entităţile ca nişte relaţii. Piaţa actuală de
baze de date este acoperită în majoritate de sisteme relaţionale. Bazele de
date relaţionale sunt caracterizate de:
• structuri de date simple, intuitive,
• inexistenţa pointerilor vizibili pentru utilizator,
• constrângeri de integritate,
• operatori aplicaţi relaţiilor care permit definirea, căutarea şi
reactualizarea datelor.
Dezvoltarea unei aplicaţii riguroase utilizand o bază de date
relaţionale necesită cunoaşterea a trei niveluri de instrumente, eterogene
din punct de vedere conceptual:
• nivelul instrumentelor grafice (interfaţa);
• nivelul aplicaţie, cu limbajele sale de dezvoltare;
• nivelul SGBD, cu standardul SQL (Structured Query Language) ce
permite definirea, prelucrarea şi controlul bazei de date.
Baze de date orientate obiect

Bazele de date relaţionale nu folosesc însă obiecte complexe şi
dinamice, nu realizează gestiunea datelor distribuite şi nici gestiunea
cunoştinţelor. A treia generaţie de SGBD-uri, sistemele avansate, încearcă
să depăşească aceste limite ale sistemului relaţional.
Suportul obiectelor complexe şi dinamice şi prelucrarea acestora este
dificilă pentru sistemele relaţionale, deoarece tipul datelor este limitat la
câteva domenii alfanumerice, iar structura datelor este simplă. Sistemele
relaţionale nu modelează obiecte complexe ca grafuri, liste etc. Un obiect
complex poate să fie descompus în relaţii, dar apar dificultăţi atât la
descompunerea, cât şi la refacerea acestuia prin compunere. De asemenea,
limbajele modelului relaţional permit prelucrarea cu dificultate a obiectelor
complexe.
Un sistem relaţional nu suportă obiecte dinamice care incorporează
atât partea de date (informaţii) efective, cât şi o parte relativă la tratarea
acestora.
Îmbinarea tehnicii limbajelor orientate obiect cu a bazelor de date a
permis realizarea bazelor de date orientate obiect. Acestea permit
organizarea coerentă a obiectelor partajate între utilizatori concurenţi.
Sistemele de gestiune de baze de date orientate obiect (SGBDOO) prezintă
o serie de avantaje:
17
• realizează o modelare superioară a informaţiei,

• furnizează posibilităţi superioare de deducţie (ierarhie de clase,
moştenire),
• permit luarea în considerare a aspectelor dinamice şi integrarea
descrierii structurale şi comportamentale,
• asigură îmbunătăţirea interfeţei cu utilizatorul.
Cu toate avantajele incontestabile oferite de SGBDOO-uri,
impunerea lor pe piaţa bazelor de date nu a fost uşoară. Câteva motivaţii a
acestei situaţii:
• absenţa unei fundamentări teoretice face imposibilă definirea unui
SGBDOO de referinţă;
• gestiunea obiectelor complexe este mai dificilă decât accesul la
relaţii prin cereri SQL;
• utilizatorii au investit sume uriaşe în sistemele relaţionale şi nu le
pot abandona cu uşurinţă. Trecerea la noua tehnologie orientată
obiect implică investiţii mari şi nu păstrează aproape nimic din
vechile soluţii.
Baze de date relaţionale orientate obiect

Simplitatea modelului relaţional, combinată cu puterea tehnologiei
orientate obiect a generat un domeniu nou şi promiţător în lumea bazelor de
date, şi anume bazele de date relaţionale orientate obiect.
Construcţia unui sistem de gestiune de baze de date relaţionale
orientate obiect (SGBDROO) trebuie să pornească de la cele existente.
Aceasta se poate realiza în două moduri: dezvoltând un sistem relaţional
prin adăugarea caracteristicilor obiectuale necesare sau pornind de la un
sistem orientat obiect şi adăugând caracteristicile relaţionale.
Baze de date deductive

O relaţie este o mulţime de înregistrări ce reprezintă fapte.
Cunoştinţele sunt aserţiuni generale şi abstracte asupra faptelor.
Cunoştinţele permit să raţionezi, ceea ce permite deducerea de noi fapte,
plecând de la fapte cunoscute. Un SGBD relaţional suportă o formă limitată
de cunoştinţe, şi anume constrângerile de integritate, iar restul trebuie
integrate în programele de aplicaţie. Aceasta generează probleme deoarece
cunoştinţele trebuie codificate în programe şi apare imposibilitatea de a
partaja cunoştinţe între utilizatori. Totul se complică dacă există un volum
mare de fapte.
18
Bazele de date deductive, utilizând programarea logică, gestionează
cunoştinţe relativ la baze de date care, în general, sunt relaţionale. Bazele
de date deductive permit deducerea de noi informaţii, plecând de la
informaţiile stocate în baza de date. Un SGBD deductiv posedă:
• un limbaj de definire a datelor care permite definirea structurii
predicatelor sub formă de relaţii şi constrângeri de integritate
asociate;
• un limbaj de prelucrare a datelor care permite efectuarea
reactualizărilor asupra datelor şi formularea unor cereri;
• un limbaj de reguli de deducţie care permite ca, plecând cu
predicatele definite anterior, să se specifice cum pot fi construite
predicate derivate.
Baze de date distribuite

Un sistem distribuit este un ansamblu de maşini ce sunt
interconectate printr-o reţea de comunicaţie şi utilizate într-un scop global.
Administrarea şi prelucrarea datelor distribuite, situate pe diferite
calculatoare şi exploatate de sisteme eterogene este obiectivul fundamental
al bazelor de date distribuite.
Bazele de date distribuite sunt sisteme de baze de date cooperante
care rezidă pe maşini diferite, în locuri diferite. Această mulţime de baze de
date este exploatată de utilizator ca şi cum ar fi o singură bază de date.
Programul de aplicaţie care exploatează o bază de date distribuite poate
avea acces la date rezidente pe mai multe maşini, fără ca programatorul să
cunoască localizarea datelor.
Modelul relaţional a rămas instrumentul principal prin care se
realizează prelucrarea datelor distribuite.
Câteva dintre argumentele pentru a justifica această afirmaţie sunt:
• bazele relaţionale oferă flexibilitate de descompunere în vederea
distribuirii;
• operatorii relaţionali pot fi folosiţi pentru combinaţii dinamice ale
informaţiilor descentralizate;
• limbajele sistemelor relaţionale sunt concise şi asigură o economie
considerabilă a transmiterii datelor. Ele fac posibil, pentru un nod
oarecare al reţelei, să analizeze intenţia unei tranzacţii, să o
descompună rapid în componente ce pot fi realizate local şi
componente ce pot fi transportate altor noduri.
19
Calculatoare şi maşini baze de date

Soluţia pentru a descentraliza prelucrarea datelor, în scopul evitării
saturării memoriei şi a procesoarelor calculatorului central, a fost apariţia
calculatoarelor baze de date şi a maşinilor baze de date. Descentralizarea
presupune transferarea unei părţi din funcţiile unui SGBD către un
calculator periferic (calculator backend) adică deplasarea algoritmilor de
căutare şi a celor de actualizare a datelor mai aproape de memoria
secundară. Acest calculator periferic permite utilizarea optimă a resurselor
şi realizarea paralelismului în tratarea cererilor de informaţii.
Calculatorul periferic poate fi un calculator clasic, dar cu un software
specific de SGBD (calculator bază de date) sau poate fi o maşină cu
hardware specializat în gestiunea bazelor de date (maşină bază de date).
Maşinile baze de date sunt înzestrate cu arhitecturi paralele special adaptate
pentru gestionarea unui volum mare de date. Tratarea paralelă a cererilor
permite reducerea timpului total de execuţie a acestora.
O execuţie în paralel solicită, fie descompunerea unui program în
module, care pot fi executate în paralel (descompunere funcţională), fie
descompunerea datelor în subgrupe, astfel încât toate procesoarele să
execute acelaşi lucru, dar pe date diferite. Performanţele tratării paralele
depind de modul în care sunt efectuate descompunerile.
Multibaze de date
Diferite departamente ale unei organizaţii mai mari pot folosi diferite
sisteme de gestiune. Cu toate că fiecare sistem este dezvoltat pentru a
satisface nevoile propriului său departament, informaţiile cu care lucrează
pot fi utile şi altor departamente. De aceea, pentru ca organizaţia să
funcţioneze bine, trebuie să existe o modalitate globală da a vedea datele
din fiecare sistem. Există două caracteristici ale unor astfel de sisteme care
fac acceasarea datelor în acest mediu integrat greoaie, uneori chiar
imposibilă:
• autonomie – fiecare SGBD are o autonomie completă, ceea ce
înseamnă că fiecare manager are control deplin asupra sistemului;
• eterogenitate – sistemele pot opera pe diferite platforme, cu diferite
modele de date şi limbajele de interogare.
Una dintre soluţiile folosite pentru a depăşi dificultăţile întâmpinate în
respectarea autonomiei şi a eterogenităţii este utilizarea sistemelor multibaze
de date.
20
Un sistem multibaze de date (SMB) este alcătuit din mai multe sisteme
de baze de date privite integrat, în care se construiesc una sau mai multe
scheme globale pe baza schemelor fiecărei baze de date componente, astfel
încât să se poată realiza accesul uniform şi integrat la fiecare din bazele de
date componente. Fiecare schemă globală este construită pe baza unui model
particular de date. De exemplu, se poate construi o schemă globală ce are la
bază modelul relaţional pentru utilizatorii care sunt familiarizaţi cu acest
model, dar se poate construi o schemă globală bazată pe modelul orientat
obiect pentru utilizatorii bazelor de date orientate obiect.
Pentru o schemă globală dată, un sistem multibaze de date constă din
sistemele componente împreună cu un sistem front-end, care suportă un
singur model de date şi un singur limbaj de interogare. Principalele sarcini ale
sistemului front-end sunt gestionarea schemei globale şi procesarea cererilor
globale.
Un avantaj major al acestui model, faţă de altele, este faptul că o
singură interogare poate accesa date din mai multe baze de date într-un mod
integrat, fără să afecteze nici o aplicaţie care este scrisă utilizând una dintre
bazele de date componente.
Baze de date cu suport decizional

Sistemele informatice, în particular bazele de date, au ajuns la
maturitate. Marile companii au acumulat o mare cantitate de informaţii din
domeniul lor de activitate, pe care le păstrează în tabele istorice şi sunt
nefolositoare sistemelor operaţionale ale companiei, care funcţionează cu
date curente. Analizate, aceste date ar putea oferi informaţii despre tendinţe
şi evoluţii care ar putea interesa compania. Pentru a putea analiza aceste
mari cantităţi de date este nevoie de tehnologii şi instrumente speciale.
Ideea de a analiza colecţii de date provenind din sistemele
operaţionale ale companiei sau din surse externe pentru a le folosi ca suport
în procesul de decizie nu aparţine ultimului deceniu, dar baze de date care
să funcţioneze eficient după aceste criterii au fost studiate şi implementate
în ultimii ani. Principalul scop al acestor baze de date a fost de a întâmpina
nevoile sistemelor operaţionale, a căror natură este inerent tranzacţională.
Sistemele tranzacţionale sunt interesate, în primul rând, să controleze
la un moment dat o singură tranzacţie. De exemplu, într-un sistem bancar,
atunci când clientul face un depozit, sistemul operaţional bancar este
responsabil de a înregistra tranzacţia într-u n tab el al tranzacţiilo r şi d e a
creşte nivelul curent al contului clientului, stocat în alt tabel.
21
Un sistem operaţional tipic operează cu evenimente predefinite şi,

datorită naturii lor, necesită acces rapid la date. Uzual, fiecare tranzacţie
operează cu cantităţi mici de date.
De-a lungul timpului, nevoile sistemelor operaţionale nu se schimbă
mult. Aplicaţia care înregistrează tranzacţia, ca şi cea care controlează
accesul utilizatorului la informaţie (partea de raportare a sistemului
bancar), nu se modifică prea mult. În acest tip de sistem, informaţia
necesară în momentul în care un client iniţiază o tranzacţie trebuie sa fie
actuală. Înainte ca o bancă să aprobe un împrumut este nevoie să se asigure
de situaţia financiară stabilă a clientului în acel moment, şi nu cu un an
înainte.
În ultimii ani s-au pus la punct principii şi tehnologii noi care să
servească procesului de analiză şi administrare a datelor. O bază de date
optimizată în acest scop defineşte o Data Warehouse (magazie de date), iar
principiul pe care îl urmează este cunoscut sub numele de procesare
analitică (OLAP – On Line Analytical Processing). Spre deosebire de
acesta, principiul pe care se bazează sistemele tranzacţionale a fost numit
procesare tranzacţională (OLTP – On Line Transactional Processing).
Aplicaţiile unei Data Warehouse trebuie să ofere răspunsuri unor
întrebări de tipul: „Care zi din săptămână este cea mai aglomerată?“ „Ce
clienţi, cu care avem relaţii intense, nu au beneficiat de reduceri de
preţuri?“. O caracteristică a bazelor de date analitice este că interogările la
care acestea trebuie să răspundă sunt ad-hoc, nu sunt predefinite, iar baza
de date trebuie optimizată astfel încât să fie capabilă să răspundă la orice
fel de întrebare care poate implica mai multe tabele.
În această abordare, organele generale de decizie necesită accesul la
toate datele organizaţiei, oriunde s-ar afla acestea. Pentru o analiză
corespunzătoare a organizaţiei, afacerilor, cerinţelor, tendinţelor este
necesară nu numai accesarea valorilor curente din baza de date, ci şi a
datelor istorice. Prin urmare, pentru a facilita acest tip specific de analiză a
informaţiei a fost creată magazia de date, care conţine informaţii extrase
din diverse surse, întreţinute de diverse unităţi operative, împreună cu
istoricul şi rezumatul tranzacţiilor.
Sursele de date pentru o magazie cuprind:
• date operaţionale, păstrate în baze de date ierarhice, de prima
generaţie;
• date departamentale, păstrate în sisteme de fişiere patentate;
22
• date cu caracter personal, păstrate pe staţii de lucru şi servere
personale;
• sisteme externe (baze de date comerciale, Internet etc.)
Data warehouse este o colecţie de date:
• orientate spre subiect (principalele subiecte ale modelului sunt
clienţii, produsele, vânzările, în loc de domeniile de activitate),
• nevolatile (datele nu sunt reactualizate, înlocuite în timp real, ci
sunt adăugate ca un supliment al bazei),
• integrate (transpunerea datelor provenite din diverse surse de
informaţii se face într-un format consistent),
• variabile în timp (concentrarea depozitului de date se face asupra
schimbărilor care au loc în timp).
Administrator Depozit de date Utilitare

cereri,
META-FLUX rapoarte
Sursa 1 Metadate
Date operationale
Date cu nivel
mare de agregare
Utilitare
Administrator Administrator OLAP
FLUX incarcare date cereri
INTERN
FLUX
Date cu nivel EXTERN
mic de agregare FLUX
ASCENDENT
Date detaliate Utilitare
SGBD Data mining
Sursa n
Date operationale Administrator Depozit de date
Utilitare pentru
Arhive/ date FLUX accesul
backup DESCENDENT utilizatorilor finali
Fig 1.2. Arhitectura unui depozit de date
Înmagazinarea datelor se concentrează asupra gestionării a cinci

fluxuri de informaţii:
23
• fluxul intern, care reprezintă procesele asociate extragerii şi

încărcării datelor din fişierele sursă în magazia de date;
• fluxul ascendent, care reprezintă procesele asociate adăugării de
valoare datelor din magazie, cu ajutorul împachetării şi distribuirii;
• fluxul descendent, care reprezintă procesele asociate arhivării,
salvării, refacerii datelor din magazie;
• fluxul extern, care reprezintă procesele asociate punerii la dispoziţie
a datelor pentru utilizatorii finali;
• meta-fluxul, care reprezintă procesele asociate gestionării meta-
datelor (date despre date).
În arhitectura depozitului de date intervin câteva componente
specifice acestei structuri.
• Administratorul pentru încărcarea datelor (componenta front-end)
realizează toate operaţiile asociate cu obţinerea (extragerea) şi
încărcarea datelor operaţionale într-un depozit de date.
• Administratorul depozitului de date realizează toate operaţiile
legate de administrarea datelor din depozit. Operaţiile realizate de
componenta de administrare a depozitului de date includ: analiza
datelor pentru a asigura consistenţa acestora; transformarea şi
mutarea datelor sursă din structurile temporare de stocare în
tabelele depozitului de date; crearea de indecşi şi vizualizări asupra
tabelelor de bază; generarea denormalizării (dacă este necesar);
generarea agregărilor; crearea arhivelor şi a backup-urilor.
• Administratorul cererilor (componenta back-end) realizează toate
operaţiile legate de administrarea cererilor utilizator. Această
componentă este construită folosind utilitarele de acces la date
disponibile utilizatorilor finali, utilitarele de monitorizare a
depozitului de date, facilităţile oferite de sistemul de baze de date
şi programele personalizate.
• În zona ce include date agregate sunt stocate toate agregările
predefinite de date, pe diferite niveluri. Scopul, menţinerii
acestora, este de a mări performanţa cererilor care necesită
agregări. Datele agregate sunt actualizate permanent, pe măsură ce
sunt încărcate noi informaţii în depozit.
• Scopul principal al depozitelor de date este de a oferi informaţii
necesare utilizatorilor pentru luarea deciziilor strategice de
marketing. Aceşti utilizatori interacţionează cu depozitul de date
prin diferite utilitare de acces (utilitare pentru rapoarte şi cereri,
24
utilitare pentru dezvoltarea aplicaţiilor, utilitare pentru procesarea
analitică on-line (OLAP), utilitare data mining) etc.
Instrumentele de acces pentru utilizatorii finali ai magaziilor de date:
• prelucrarea analitică on-line;
• extensiile limbajului SQL;
• instrumentele de extragere a datelor.
Prelucrarea analitică on-line (OLAP) reprezintă sinteza, analiza şi
consolidarea dinamică a unor volume mari de date multidimensionale.
Serverele de baze de date OLAP utilizează structuri multidimensionale
pentru stocarea datelor şi a relaţiilor dintre date. Aceste structuri pot fi
vizualizate prin cuburi de date şi cuburi în cadrul cuburilor etc. Fiecare
latură a cubului reprezintă o dimensiune. Serverele de baze de date OLAP
multidimensionale acceptă operaţiile analitice uzuale: consolidarea
(gruparea), parcurgerea în jos (inversul consolidării), tranşarea, tăierea.
OLAP necesită o modalitate de agregare a datelor conform mai multor
grupări diferite, în număr foarte mare, iar utilizatorii trebuie să le aibă în
vedere pe toate.
Instrumentele OLAP presupun organizarea informaţiei într-un model
multidimensional care este susţinut de o bază de date:
• multidimensională (MOLAP), în care datele sunt stocate
conceptual în celulele unui tablou multidimensional;
• relaţională (ROLAP), proiectată pentru a permite
interogări multidimensionale.
În acest context, a devenit o necesitate extinderea limbajului SQL
prin operaţii puternice, necesare pentru rezolvarea noului tip de abordare.
Au fost introduse noi funcţii numerice (limita inferioară, limita superioară
etc.), noi funcţii statistice (distribuţie, distribuţie inversă, corelaţie etc.), noi
operatori de agregare, extensii ale clauzei GROUP BY etc.
De exemplu, RISQL (Red Brick Intelligent SQL), proiectat pentru
analiştii din domeniul afacerilor, permite: ordonare după rang (pe diferite
niveluri - de exemplu, gruparea filialelor în trei categorii pe baza venitului
generat în anul precedent), partajarea pieţei, compararea anului curent cu
cel precedent etc.
O altă problemă esenţială este extragerea datelor şi utilizarea
acestora pentru luarea de decizii cruciale în domeniul afacerilor.
Descoperirea unor noi corelaţii, tipare, tendinţe, prin extragerea unor
cantităţi mari de date folosind strategia inteligenţei artificiale este una din
modalităţile de rezolvare.
Extragerea datelor presupune capacitatea de a construi modele mai
degrabă previzibile, decât retrospective. Modelarea predictivă utilizează
25
informaţii pentru a forma un model al caracteristicilor importante ale unui

fenomen.
Tehnicile asociate operaţiilor fundamentale de extragere sunt:
• modelarea predictivă (clasificarea cu ajutorul unei reţele neurale
sau al unei inducţii de tip arbore şi previziunea valorilor, utilizând
tehnici de regresie);
• segmentarea bazei de date (comasarea demografică şi comasarea
neurală care se deosebesc prin metodele uilizate pentru a calcula
distanţa dintre înregistrări, prin intrările de date permise);
• analiza legăturilor (descoperirea asocierilor, descoperirea tiparelor,
descoperirea secvenţelor de timp similare);
• detectarea deviaţiilor (statistici şi vizualizări pentru identificarea
împrăştierii datelor, utilizând tehnici moderne de vizualizare
grafică). În această clasă pot fi considerate, de exemplu, detectarea
fraudelor privind utilizarea cărţilor de credit, pretenţiile de
despăgubire ale asiguraţilor etc.
În concluzie, spre deosebire de un sistem OLTP, Data Warehouse
este o bază de date a cărei structură este proiectată pentru a facilita analiza
datelor. Un sistem de suport decizional urmăreşte, în primul rând, obţinerea
de informaţii din baza de date, în timp ce unul OLTP urmăreşte
introducerea de informaţii în baza de date. Datorită acestor diferenţe,
structura optimă a unei Data Warehouse este radical diferită de cea a unui
sistem OLTP.
Depozitele de date şi sistemele OLTP sunt supuse unor cerinţe
diferite, dintre care cele mai semnificative se referă la operaţii, actualizarea
datelor, proiectare, operaţii tipice şi date istorice.
• Operaţii. Depozitele sunt create pentru a permite interogări ad hoc.
Ele trebuie să fie suficient de flexibile pentru a putea răspunde
interogărilor spontane ale utilizatorilor. Sistemele OLTP suportă
numai operaţii predefinite. Aplicaţiile pot fi optimizate sau create
special numai pentru acele operaţii.
• Actualizarea datelor. Utilizatorii finali ai unui depozit de date nu
fac în mod direct actualizări ale depozitului. În sistemele OLTP,
utilizatorii realizează, de obicei, în mod individual procedurile de
modificare a bazei de date. În acest fel, baza de date OLTP este
întotdeauna la zi şi reflectă starea curentă a fiecărei tranzacţii.
• Proiectare. Depozitele de date folosesc, în mod uzual, scheme
denormalizate, în timp ce sistemele OLTP folosesc scheme
normalizate pentru a optimiza performanţele operaţiilor.
26
• Operaţii tipice. O simplă interogare a depozitului de date poate
scana mii sau chiar milioane de înregistrări (de exemplu, cererea
„Care sunt vânzările totale către toţi clienţii din luna trecută?“), în
timp ce o operaţie tipică OLTP accesează doar o parte mai mică
din înregistrări.
• Date istorice. Depozitele de date stochează datele pe o perioadă
lungă de timp, luni sau ani. Acest lucru oferă suport pentru analiza
istorică a informaţiei. Sistemele OLTP reţin date istorice atât timp
cât este necesar pentru a îndeplini cu succes cerinţele tranzacţiilor
curente.
Sistemele OLTP Data Warehouse

Păstrează date curente Păstrează date istorice
Stochează date detaliate, agregate uşor
Stochează date detaliate
sau puternic
Datele sunt dinamice Datele sunt în mare măsură statice
Prelucrare ad-hoc, nestructurată şi
Prelucrare repetitivă
euristică
Nivel înalt de transfer al Nivel mediu sau scăzut de transfer al
tranzacţiilor tranzacţiilor
Tipar de utilizare previzibil Tipar de utilizare imprevizibil
Conduse prin tranzacţii Conduse prin analiză
Susţin deciziile de zi cu zi Susţin deciziile strategice
Deservesc un număr mare Deservesc un număr relativ redus de
de utilizatori utilizatori din administraţie
Orientate spre aplicaţii Orientate spre subiect
Fig. 1.3. OLTP versus Data Warehouse
O bază de date OLAP poate fi relaţională, dar datorită naturii ei

orientate spre dimensiuni, au fost dezvoltate pentru gestionarea acestor
baze de date construcţii multidimensionale, mai potrivite pentru o raportare
flexibilă. Spre deosebire de bazele de date relaţionale, structura unei baze
de date multidimensionale nu implică tabele, linii şi coloane, ci obiecte de
următoarele tipuri: variabile, dimensiuni, niveluri, ierarhii, atribute.
Data Warehouse, care cuprinde de obicei informaţii despre o
întreagă companie, poate fi subîmpărţită în baze de date departamentale,
numite rafturi de date (Data Marts). De exemplu, poate exista un Data
27
Mart al departamentului financiar, un altul al departamentului vânzări şi un

altul pentru departamentul marketing.
Construcţia unei astfel de baze de date poate fi abordată în două
moduri.
• O primă abordare este de a construi mai întâi un schelet al bazei de
date la care se lipesc ulterior rafturile de date. Aceasta necesită o
analiză prealabilă a întregului şi o delimitare a blocurilor
componente. Ea cere un timp mai lung de dezvoltare, dar rezultatul
este o bază de date unitară.
• A doua metodă este de a construi mai întâi rafturi specifice, efortul
constând, în acest caz, în asocierea acestora. Această soluţie oferă
mai rapid, aplicaţii funcţionale utilizatorilor, dar au de suferit
unitatea şi portabilitatea aplicaţiilor finale.
Utilizatorii trebuie să-şi schimbe optica asupra bazelor de date pentru
a fi capabili să folosească puterea şi flexibilitatea instrumentelor analitice
de care dispun. Instrumentele OLAP au evoluat ca o modalitate de a
rezolva interogările complicate necesare procesului de analiză a datelor.
Combinaţia între bazele de date multidimensionale şi instrumentele
analitice prietenoase face uşoară analiza, sinteza şi consolidarea datelor.
În ultimii ani, marii producători de sisteme de gestiune a bazelor de
date relaţionale, precum Oracle, au introdus în produsele lor construcţii
care să faciliteze accesul la datele din sistemele fundamentale pentru luarea
de decizii. Astfel, noile versiuni de SGBD-uri ale firmelor mari prevăd o
modalitate mai inteligentă de a realiza operaţia de compunere între două
sau mai multe tabele, metode de indexare noi, potrivite pentru marile
cantităţi de date statice cu care operează sistemele Data Warehouse,
capacitatea de a detecta şi optimiza interogări de un tip special,
posibilitatea de a folosi mai multe procesoare pentru a rezolva o interogare.
Un sistem Data Warehouse are un efect fundamental asupra
utilizatorilor. Ei pot manevra mult mai flexibil sistemul, au posibilităţi
elevate pentru interogarea datelor, dar ei trebuie să ştie cum să prelucreze şi
să vizualizeze datele şi cum să le folosească în procesul de decizie.
Un efort ce trebuie făcut pentru construirea unui sistem de suport
pentru decizii (DSS – Decision Support System) constă în procesul de
descoperire a informaţiilor utile din baza de date. Acest proces, numit Data
Mining sau Knowledge Discovery in Databases (KDD), procesează mari
cantităţi de date, a căror corelare nu este neapărat evidentă, în vederea
descoperirii de tendinţe şi tipare.
28
1.5. Arhitecturi multi-user pentru sisteme de gestiune a

bazelor de date
Arhitecturile uzuale care sunt utilizate pentru implementarea

sistemelor de gestiune a bazelor de date multi-user sunt: teleprocesarea,
arhitectura fişier-server arhitectura client-server.
Teleprocesarea este arhitectura tradiţională, ce cuprinde un
calculator cu o singură unitate CPU şi un numar de terminale care sunt
incapabile să funcţioneze singure. Terminalele trimit mesaje la programele
aplicaţie ale utilizatorilor, care la rândul lor, utilizează serviciile SGBD.
Această arhitectură a plasat o greutate teribilă asupra calculatorului
central, care pe lângă rularea programelor de aplicaţii şi ale SGBD-ului,
mai trebuie să preia şi din munca terminalelor (de exemplu, formatarea
datelor pentru afişarea pe ecran).
Arhitectura fişier-server, presupune deja că procesarea este
distribuită în reţea (de obicei o reţea locală LAN). Arhitectura cuprinde
fişierele cerute de aplicaţii şi SGBD-ul. Aplicaţiile şi funcţiile SGBD sunt
executate pe fiecare staţie de lucru, solicitând când este nevoie fişiere de pe
server-ul de fişiere. Dintre dezavantaje se remarcă:
• existenţa unui trafic intens pe reţea;
• necesitatea unei copii complete a SGBD-ului pe fiecare
staţie de lucru;
• acelaşi fişier poate fi accesat de mai multe SGBD-uri,
ceea ce implică un control complex al integrităţii, simultaneităţii,
reconstituirii.
Arhitectura client-server se referă la modul în care interacţionează
componentele software pentru a forma un sistem. Există un proces client,
care necesită resurse şi un proces server, care oferă resurse.
În arhitectura client-server, clientul (front end) emite, prin
intermediul reţelei locale, o cerere SQL care este executată pe server (back-
end); acesta trimite ca răspuns ansamblul înregistrărilor rezultat. Într-o
astfel de interacţiune maşinile sunt eterogene, iar protocoalele de reţea pot
fi distincte.
În contextul bazelor de date, client-ul:
• administrează interfaţa cu utilizatorul şi logica aplicaţiei;
• acceptă şi verifică sintaxa intrărilor utilizatorilor;
• procesează aplicaţiile;
• generează cerinţele pentru baza de date şi le trimite server-ului;
29
• transmite răspunsul înapoi la utilizator.
În contextul bazelor de date, server-ul:

• primeşte şi procesează cerinţele clienţilor pentru baza de date;
• verifică autorizarea;
• garantează respectarea constrângerilor de integritate;
• efectuează procesarea interogare-reactualizare şi trimite clientului
răspunsul;
• realizează optimizarea interogărilor;
• asigură controlul concurenţei dintre mai multi clienţi care se ignoră
(mecanisme de blocare);
• intreţine dictionarul datelor;
• oferă acces simultan la baza de date;
• asigură robusteţea în cazul defecţiunilor;
• oferă controlul reconstituirii etc.
Arhitectura tradiţională client-server pe „două etaje (straturi)“
presupune:
• client-ul – responsabil, în primul rand, de prezentarea datelor către
client;
• server-ul – responsabil, în primul rand, de furnizarea serviciilor
către client.
Arhitectura client-server pe „trei etaje“ presupune trei straturi,
fiecare fiind rulat, potenţial, pe o platformă diferită.
• stratul (client) format din interfaţa cu utilizatorul, care este rulat pe
calculatorul utilizatorului final;
• stratul (server de aplicaţie), ce manevrează logica aplicaţiilor şi
prelucrării datelor, şi care poate servi mai mulţi clienţi (conectare
la celelalte două straturi se face prin reţele locale LAN sau de mare
suprafaţă WAN);
• stratul (server-ul de baze de date), care se ocupă cu validarea
datelor şi accesarea bazei de date (stochează date necesare stratului
din mijloc).
Arhitectura se potriveşte natural mediului Web. Un browser Web
acţionând drept client şi un server Web fiind server de aplicaţie.
Middleware este un strat, evident software, între aplicaţia postului
client şi server-ul de baze de date, constituit dintr-o interfaţă de programare
a aplicaţiilor (API - Application Programming Interface) şi un protocol de
reţea.
30
API descrie tipul de interacţiune dintre o aplicaţie client şi un server
la distanţă, via un protocol de comunicaţie şi de formatare a datelor. Scopul
existenţei interfeţei de programare a aplicaţiilor este de a oferi o interfaţă
unică mai multor server-e de baze de date.
Este convenabil ca sistemele de baze de date să fie considerate ca
fiind formate dintr-un server (sistemul SGBD însăşi) şi un set de clienţi
(aplicaţiile). Frecvent, clienţii şi server-ul pot fi rulate pe calculatoare
diferite, realizându-se un tip simplu de procesare distribuită. În general,
fiecare server poate deservi mai multi clienţi, iar fiecare client poate accesa
mai multe server-e. Dacă sistemul oferă transparenţă totală (fiecare client
se poate comporta ca şi cum ar comunica cu un singur server, de pe un
singur calculator) atunci este vorba despre un sistem de baze de date
distribuite.
1.6. Tehnologia Web şi sistemele SGBD

Internet = o colecţie mondială de reţele de calculatoare.
Intranet = un sit Web sau un grup de sit-uri care aparţin unei
organizaţii, accesibil numai pentru membrii acesteia.
Extranet = o reţea intranet care este parţial accesibilă utilizatorilor
externi autorizaţi.
Reţea Web (World Wide Web) = un sistem bazat pe hipermedii care
pune la dispoziţie un mijloc simplu, de tip „indicare-clic“ de răsfoire a
informaţiilor pe Internet, folosind hiperlegăturile.
HTTP = protocolul utilizat pentru a transfera pagini Web prin
intermediul Internetului.
HTML = limbajul de formatare a documentelor utilizat în
proiectarea majorităţii paginilor Web.
Adresa URL = şir de caractere alfanumerice care reprezintă adresa
unei resurse pe Internet şi modul în care trebuie accesată resursa.
Interfaţa de poartă comună (CGI) = defineşte modul în care
scripturile comunică cu server-ul Web. Este tehnica de bază de integrare a
bazelor de date în reţeaua Web.
În mediul Web funcţionează modelul three tier format din:
• un strat de interfaţă cu utilizatorul (client),
• un strat de logică a afacerii şi prelucrare a datelor (server de
aplicaţii),
• un sistem SGBD (server de baze de date) distribuit pe calculatoare
diferite.
Avantajele reţelei Web ca platformă de baze de date:
• avantagele SGBD;
31
• simplitate;
• independenţa de platformă;
• interfaţa grafică cu utilizatorul;
• acces transparent în reţea;
• standardizare (HTML standard de facto).
Arhitectura de calcul în reţea a sistemului Oracle (NCA Network
Computing Architecture) se axează în principal pe furnizarea
extensibilităţii pentru mediile distribuite. Arhitectura este construită pe
baza tehnologiei CORBA pentru manipularea obiectelor. Este o structură
three tier care se bazează pe utilizarea de:
• cartuşe de software care permit utilizatorilor să adauge
funcţionalităţi individuale în aplicaţii (cartuşele pot fi construite
în Java, C/C++, Visual Basic, SQL şi pot fi conectate la oricare
din cele 3 straturi);
• protocoale deschise şi interfeţe standardizate care permit
comunicarea între cartuşe (distribuite într-o reţea) prin
intermediul unui program magistrală (ICX);
• clienţi extensibili, server-e de aplicaţie, server-e de baze
de date;
• dezvoltarea şi administrarea integrată a cartuşelor.
Un cartus utilizeaza un limbaj de definire a interfetelor (IDL)
pentru a putea fi identificat de alte obiecte intr-un sistem distribuit. De
exemplu, PL/SQL este un astfel de cartus.
Arhitectura multitier a sistemului Oracle9i

Arhitectura cu mai multe niveluri (multitier) conţine următoarele
elemente:
• unul sau mai mulţi client-i care iniţiază operaţii;
• unul sau mai multe server-e de aplicaţii care execută părţi ale
operaţiilor;
• un server de baze de date care stochează datele folosite de operaţii.
Client-ul, care poate fi un browser Web sau un proces user, iniţiază o
cerere pentru a executa o operaţie referitoare la informaţiile stocate în baza
de date. Conectarea la server-ul bazei de date se face printr-unul sau mai multe
server-e de aplicaţii.
Server-ul de aplicaţii constituie interfaţa dintre client-i şi server-ul
bazei de date, asigurând accesul la informaţii. De asemenea, el include un
nivel adiţional pentru securitate. Server-ul de aplicaţii îşi asumă identitatea
client-ului, atunci când execută, pe server-ul de baze de date, operaţiile
solicitate de acesta.
Arhitectura multitier permite folosirea unui server de aplicaţii pentru
32
acreditarea client-ului, conectarea la server-ul de baze de date şi execuţia
operaţiilor iniţiate de client. Privilegiile server-ului de aplicaţii sunt limitate
pentru a preveni execuţia operaţiilor nedorite sau inutile în timpul unei
operaţii client.
Server-ul de baze de date pune la dispoziţia server-ului de aplicaţii
informaţiile necesare pentru soluţionarea operaţiilor lansate de către client.
De asemenea, acesta face distincţia între operaţiile pe care server-ul de
aplicaţii le cere în favoarea client-ului şi cele pe care le solicită în nume
propriu.
Oracle9i Developer Suite
HTTP
Clienti HTTP Oracle9i Application Oracle9i Database

Server
Nivel 1 Nivel 2 Nivel 3
Fig. 1.4. Arhitectura three-tier a sistemului Oracle9i

2 MODELAREA
ENTITATE - RELAŢIE
Pr oiectar ea baz elor de date or ientate obiect
M ODELAREA BAZELOR DE DATE
2.1. Preliminarii
Un model este o reprezentare a obiectelor şi evenimentelor lumii reale şi

a asocierilor dintre ele. De fapt, el reprezintă o abstracţie asupra aspectelor
semnificative ale unei „întreprinderi“, ale unui sistem real, ignorând proprietăţile
accidentale. Modelul este cel pe care utilizatorii trebuie să-l cunoască;
implementarea unui model este cea pe care utilizatorii nu este necesar să o
cunoască. Diferenţa dintre model şi implementare este, de fapt, un caz special şi
important al deosebirii uzuale dintre logic şi fizic.
Modelele se impun prin sintaxa şi prin semantica lor şi, din acest punct
de vedere, există trei tipuri fundamentale de modele:
• modele care descriu aspectele statice ale procesului modelat;
• modele care descriu aspectele dinamice ale procesului modelat;
• modele care descriu aspectele funcţionale ale procesului modelat.
Un model de date reprezintă o colecţie integrată de concepte necesare
descrierii:
• datelor,
• relaţiilor dintre ele,
• constrângerilor existente asupra datelor sistemului real analizat.
Modelarea unei baze de date permite trecerea de la percepţia unor fapte
din lumea reală la reprezentarea lor prin date. Modelul de date trebuie să
reflecte fidel fenomene ale lumii reale, să urmărească evoluţia acestei lumi şi
comunicarea dintre fenomenele lumii reale.
Modelul trebuie să asigure conceptele de bază care permit proiectantului
bazei de date şi utilizatorilor să comunice, fără ambiguităţi, cunoştinţele lor
privind funcţionarea şi organizarea modelului real analizat. Prin urmare, un
model de date trebuie să reprezinte datele şi să le facă înţelese.
În esenţă, modelul de date are trei componente:
• o mulţime de reguli conform cărora sunt construite bazele de date
(partea structurală);
• o mulţime de operaţii permise asupra datelor, care sunt utilizate pentru
reactualizarea sau regăsirea datelor (partea de prelucrare);
• o mulţime de reguli de integritate, care asigură coerenţa datelor.
Abordarea generală a problemei modelării semantice a datelor se face în

patru etape.
58 PROIECTAREA BAZELOR DE DATE
• Se identifică o mulţime de concepte semantice care sunt utile în
descrierea lumii reale. Se presupune că lumea reală (modelul real
analizat) este formată din entităţi care au anumite proprietăţi, că
fiecare entitate are o identitate, că există legături, corelaţii între
entităţi. Conceptul de corelaţie, ca şi cel de entitate, este util, în mod
intuitiv, la descrierea modelului.
• Se caută o mulţime de obiecte formale, simbolice care sunt utilizate
pentru reprezentarea conceptelor semantice anterioare.
• Se dau reguli de integritate formale şi generale (constrângeri) care să
reflecte restricţiile la care este supus modelul.
• Se defineşte o mulţime de operatori formali prin care pot fi prelucrate
şi analizate obiectele formale.
2.2. Modelul entitate-relaţie
Una dintre cele mai cunoscute abordări ale modelării semantice (cu
siguranţă una dintre cele mai utilizate) este cea bazată pe modelul entitate-
relaţie (E/R). Acesta a fost introdus de către Peter.P. Chen în 1976 şi rafinat
de atunci în diverse moduri de către acesta şi de mulţi alţi cercetători, ca un
model de date conceptual, pentru a uşura proiectarea bazelor de date. Pentru
reprezentarea grafică a modelului sunt utilizate diagramele E/R, care sunt
modele neformalizate pentru reprezentarea unui model, unui sistem din lumea
reală.
Diagramele E/R constituie o tehnică de reprezentare a structurii logice a
bazei de date, într-o manieră grafică. Aceste diagrame oferă un mijloc simplu şi
inteligibil de comunicare a caracteristicilor importante ale designului unei
anumite baze de date.
Diagrama E/R este un model de date conceptual de nivel înalt,
independent de platforma hardware utilizată şi de tipul SGBD-ului. Modelul
este constituit din concepte care descriu structura bazei de date şi tranzacţiile de
regăsire sau reactualzare asociate.
Popularitatea modelului E/R ca modalitate de abordare a proiectării
bazelor de date poate fi atribuită în principal tehnicii de realizare a diagramelor
E/R. Această tehnică, ca şi modelul E/R însuşi, a evoluat de-a lungul timpului
datorită noilor problematici care au apărut în proiectarea bazelor de date.
Baza de date poate fi definită ca o mulţime de date ce modelează un

sistem real. Acest sistem este format din obiecte legate între ele. Modelul
E/R împarte elementele unui sistem real în două categorii: entităţi şi relaţii
(legături, asocieri) între aceste entităţi. Entităţiile şi legăturile au anumite
caracteristici, numite atribute. Nu trebuie confundat conceptul de relaţie,
în sensul de asociere, care intervine în definirea diagramei E/R cu
conceptul de relaţie care este specific modelului relaţional.
Modelarea entitate-relaţie 59
Studiu de caz
Exemplele din acest capitol se referă la proiectarea unui model de date ce
furnizează informaţii despre prezentări de modă, evenimente care reprezintă
momente importante în lumea caselor de modă.
Vom prezenta modelul de date, restricţiile pe care trebuie să le respecte şi
vom încerca, într-o manieră didactică, să construim diagrama E/R
corespunzătoare. Vom considera, în abordarea iniţială, anumite situaţii care nu
sunt optime, în sensul că pot genera redundanţă, anomalii la reactualizări sau nu
permit rezolvarea anumitor interogări asupra modelului. Vom încerca să arătăm
care sunt deficienţele modelului, situaţiile care le-au generat şi cum pot fi
corectate (parţial sau total) anomaliile respective.
Modelul de date va gestiona informaţii legate de organizarea şi
funcţionarea prezentărilor de modă. Există firme organizatoare care se ocupă de
buna desfăşurare a acestor prezentări. O firmă organizatoare poate fi contactată
prin angajaţi specializaţi pe diferite domenii (financiar, social, publicitate,
securitate, sisteme de iluminare, coregrafie, sisteme de sonorizare, cazare,
primiri/plecări aeroport etc.).
Firme specializate sunt angajate pentru soluţionarea problemelor legate
de securitate, publicitate, asigurări, iar restul problemelor sunt rezolvate cu
salariaţii proprii ai caselor de modă şi a firmei organizatoare. Modalităţile de
securitate, asigurări, publicitate proprii caselor de modă, modelelor sau
agenţiilor de modele nu intră în proiectarea modelului.
Prezentările pot fi sponsorizate, considerându-se doar informaţiile
referitoare la persoane (fizice sau juridice) care au contribuit efectiv la
finanţarea prezentărilor de modă. Mai exact, nu sunt incluşi sponsorii posibili.
La aceste evenimente participă case de modă, care prezintă vestimentaţii
concepute de creatorii casei respective. Creatorii pot fi cei care concep
vestimentaţia (designeri) sau cei care o realizează efectiv, incluzând croitori,
lucrători care se ocupă cu broderia sau cu realizarea diverselor accesorii.
În cadrul prezentării de modă, vestimentaţiile sunt purtate de manechine
care aparţin anumitor agenţii de modele. Casele de modă angajează modele care
să le prezinte vestimentaţiile cu prilejul acestor evenimente. Modelul de date
prezintă şi un istoric al activităţii manechinelor (în cadrul diverselor agenţii).
Casele de modă angajează pentru o prezentare stilişti care se ocupă cu
machiajul şi coafura modelelor.
De asemenea, modelul analizează informaţii legate de localizarea şi
accesarea firmelor de publicitate, a persoanelor de contact din firmele
organizatoare, a caselor de modă, a agenţiilor şi a modelelor, a sponsorilor, a
societăţilor de asigurare şi a firmelor care asigură securitatea evenimentelor.
Modelul de date respectă anumite restricţii de funcţionare.
• Casele de modă pot fi organizatori de prezentări.
• Chiar dacă o casă de modă este organizator, ea apelează la serviciile
unei firme specializate în organizarea unor astfel de evenimente.
• Un model sau un stilist este angajat (temporar) pentru o prezentare, de
o singură casă de modă.
• O casă de modă poate angaja mai multe modele şi mai mulţi stilişti
pentru o prezentare.
• Orice prezentare de modă are un organizator unic, care poate apela la
serviciile altor instituţii specializate (securitate, asigurări, publicitate).
• Pentru organizator s-a considerat un singur cont în/din care se pot face
plăţile.
• O casă de modă poate avea mai mulţi designeri, dar un designer poate
lucra pentru o singură casă de modă.
• Pentru contactarea unei persoane fizice sau juridice s-a considerat câte
un singur număr de telefon fix, telefon mobil, fax şi o singură adresă de
mail.
• Pentru localizarea unei persoane fizice sau juridice s-a considerat o
singură adresă de bază.
• Sunt luaţi în considerare doar angajaţii firmei de pază şi protecţie care
participă efectiv la asigurarea securităţii prezentărilor de modă.
• Creatorii de accesorii pot fi angajaţi permanenţi ai unei case de modă.
Dacă pentru anumite vestimentaţii sunt necesare accesorii create de
specialişti care nu aparţin casei de modă, aceştia vor fi consideraţi
angajaţi special pentru evenimentul respectiv.
• S-a considerat că proprietarul unei case de modă fie este unic, fie, dacă
sunt mai mulţi, va fi considerat drept proprietar cel care deţine numărul
maxim de acţiuni.
Entitate
Entitatea este un obiect sau un concept, care este semnificativ pentru
modelul real analizat. O entitate poate fi dependentă (slabă), existenţa sa
depinzând de altă entitate sau independentă (tare), caz în care ea nu depinde de
existenţa altei entităţi.
Entitatea poate fi persoană, loc, concept, activitate etc. Prin urmare, ea
poate fi un obiect cu existenţă fizică, reală sau poate fi un obiect cu existenţă
conceptuală, abstractă.
Pentru o analiză didactică a problematicii abordate, construirea
diagramelor E/R, se vor considera şi aspecte ale modelului real analizat, care nu
apar în diagrama finală.
Pentru modelul de date referitor la prezentările de modă, structurile
PUBLICITATE, ORGANIZATOR, PERS_CONTACT, PREZENTARE,
SPONSOR, FIRMA_PUB, CASA_MODA, CREATOR, VESTIMENTATIE,
MODEL, ACCESORIU, LOCALIZARE, AGENTIE, ISTORIC, FIRMA_SEC,
ANGAJAT_SEC,SOCIETATE_ASIG, ANGAJAT_TEMP, INFO_CONTACT,
LOCATIE reprezintă entităţi.
Observaţii
• Entităţile devin tabele în modelele relaţionale.
• În general, entităţile se scriu cu litere mari.
• Entităţile sunt substantive, dar nu orice substantiv este o entitate.

Trebuie ignorate substantivele nerelevante.
• Cheia primară identifică unic o entitate şi face distincţie între valori
diferite ale entităţii. Aceasta trebuie să fie unică şi cunoscută la orice
moment. Cheia primară trebuie să fie controlată de administratorul
bazei, să nu conţină informaţii descriptive, să fie simplă, fără
ambiguităţi, să fie stabilă, să fie familiară utilizatorului astfel încât
acesta să o poată folosi cu uşurinţă.
• Pentru fiecare entitate este obligatoriu să se dea o descriere detaliată.
• Nu pot exista, în aceeaşi diagramă, două entităţi cu acelaşi nume, sau
o aceeaşi entitate cu nume diferite.
Vom prezenta entităţile modelului de date, dând o descriere completă a
fiecăreia. De asemenea, pentru fiecare entitate se va preciza cheia primară.
Toate entităţile care vor fi prezentate sunt independente, cu excepţia
entităţilor dependente ACCESORIU, ISTORIC şi a subentităţii MODEL.
ORGANIZATOR = firmă (persoană juridică) specializată, care se ocupă cu
organizarea şi buna desfăşurare a unei prezentări de modă. Ea poate apela la
societăţi specializate pentru rezolvarea problemelor ce apar în organizarea
prezentării de modă sau poate oferi servicii proprii pentru desfăşurarea optimă a
evenimentului. Cheia primară a entităţii este cod_organizator.
PERS_CONTACT = persoană fizică, aparţinând firmei organizatoare, care este
responsabilă cu un anumit domeniu de activitate specific organizării prezentării
de modă. Ea poate fi contactată pentru diversele probleme care privesc
prezentarea, fiind punctul de legătură dintre direcţiile din firma organizatoare şi
cele din societăţile externe, care se ocupă efectiv cu realizarea tuturor
problemelor ce apar în organizarea evenimentului. Atributul cod_pers_contact
reprezintă cheia primară a entităţii.
SPONSOR = persoană fizică sau juridică ce contribuie financiar sau în altă
manieră la desfăşurarea prezentării de modă. Cheia primară a acestei entităţi
este cod_sponsor.
FIRMA_PUB = persoană juridică ce asigură publicitatea evenimentului. Firma
organizatoare poate apela la mai multe firme de publicitate. Cheia primară a
acestei entităţi este cod_firma_pub.
PUBLICITATE = activitatea efectivă de publicitate asigurată de o firmă de
publicitate. Firmele de publicitate asigură diferite modalităţi de realizare a
publicităţii (presă, televiziune, radio etc.). Cheia primară a acestei entităţi este
cod_publicitate.
FIRMA_SEC = persoană juridică ce asigură securitatea prezentării de modă. Se
consideră că o singură firmă asigură securitatea evenimentului. Cheia primară a
acestei entităţi este cod_firma_sec.
ANGAJAT_SEC = persoană fizică, angajată a unei firme de securitate, care
participă efectiv la asigurarea serviciilor de pază şi protecţie a prezentărilor de
modă. Cheia primară a acestei entităţi este cod_angajat.
SOC_ASIG = persoană juridică responsabilă de asigurarea (din punctul de
vedere al societăţii organizatoare) tuturor activităţilor pe care le implică
prezentarea de modă. Se consideră că firma organizatoare apelează la o singură
societate de asigurări. Modelul de date nu ia în considerare asigurările făcute de
agenţiile de modele pentru angajatele sale, asigurările încheiate chiar de către
modele sau asigurările contractate de casele de modă. Cheia primară a acestei
entităţi este cod_soc_asig.
PREZENTARE = evenimentul efectiv al prezentării de modă. Modelul de date
consideră doar prezentări de modă semnificative din lumea caselor de modă.
Cheia primară a acestei entităţi este cod_prezentare.
CASA_MODA = persoană juridică a cărei activitate constă în crearea de
vestimentaţii şi accesorii pentru aceste vestimentaţii. Cheia primară a entităţii
este cod_casa_moda.
CREATOR = persoană fizică, angajată (permanent sau special) a unei case de
modă, care creează efectiv vestimentaţiile sau accesoriile acestora prezentate în
cadrul evenimentului respectiv. Cheia primară a entităţii este cod_creator.
VESTIMENTATIE = vestimentaţia concepută şi realizată de creatorii unei case
de modă. Cheia primară a entităţii este cod_vestimentatie.
ACCESORIU = entitate dependentă de VESTIMENTATIE, care conţine
informaţii referitoare la accesoriile unei anumite vestimentaţii. Cheia primară a
entităţii este compusă din cod_accesoriu şi cod_ vestimentatie.
ANGAJAT_TEMP = persoană fizică, angajată temporar pentru o anumită
prezentare de către o casă de modă, fie pentru realizarea machiajului şi a
coafurii modelelor care vor prezenta vestimentaţii în cadrul prezentării (stilist),
fie pentru a purta creaţiile acesteia la prezentarea respectivă (model). Cheia
primară a entităţii este cod_angajat_temp.
MODEL = subentitate a entităţii ANGAJAT_TEMP, ce conţine informaţii
specifice manechinelor. Cheia primară a entităţii este cod_angajat_temp.
AGENTIE = agenţia de modele care se ocupă cu gestionarea activităţilor
(participare la prezentări de modă, contracte pentru reclama diverselor produse
etc.) modelelor sale. Cheia primară a entităţii este cod_agentie.
ISTORIC = entitate dependentă de MODEL, care conţine istoricul angajărilor
unui model la diferite agenţii. Cheia primară a entităţii este compusă din
cod_model şi data_angajare.
LOCALIZARE = identifică localizarea unei persoane fizice (sponsor, persoană
de contact, model, creator, stilist), juridice (firmă de publicitate, securitate,
asigurări, organizator, casă de modă, agenţie de modele) sau eveniment
(prezentare de modă). Cheia primară a entităţii este cod_localizare.
LOCATIE = entitate care identifică locaţia în care se desfăşoară o anumită

prezentare de modă. Cheia primară a entităţii este cod_locatie.
INFO_CONTACT = identifică modalitatea de contact a unei persoane fizice
(sponsor, persoană de contact, angajat temporar, creator) sau juridice (firmă de
publicitate, securitate, asigurări, organizator, casă de modă, agenţie de modele).
Cheia primară a entităţii este cod_info_contact.
Relaţie
Relaţia (asocierea) este o comunicare între două sau mai multe entităţi. O
valoare a unei relaţii este o comunicare între valorile entităţilor pe care le leagă.
Relaţia exprimă un raport care există între aceste entităţi. Gradul unei
relaţii este dat de numărul de entităţi participante într-o relaţie (de exemplu,
relaţie binară, ternară, cvadruplă, n-ară).
Existenţa unei relaţii este subordonată existenţei entităţilor pe care le
leagă. Între două entităţi pot exista mai multe relaţii.
O relaţie în care aceeaşi entitate participă mai mult decât o dată în diferite
roluri defineşte o relaţie recursivă. Uneori, aceste relaţii sunt numite unare.
Observaţii
• În modelul relaţional, relaţiile devin tabele speciale sau coloane
speciale care referă chei primare.
• Relaţiile sunt verbe, dar nu orice verb este o relaţie.
• Pentru fiecare relaţie este important să se dea o descriere detaliată.
• În aceeaşi diagramă pot exista relaţii diferite cu acelaşi nume. În acest
caz, ele sunt diferenţiate de către entităţile care sunt asociate prin
relaţia respectivă.
• Pentru fiecare relaţie trebuie stabilită cardinalitatea (maximă şi
minimă) relaţiei, adică numărul de tupluri ce aparţin relaţiei.
Asupra entităţilor participante într-o relaţie pot fi impuse constrângeri
care trebuie să reflecte restricţiile care există în lumea reală asupra relaţiilor. O
clasă de constrângeri, numite constrângeri de cardinalitate, este definită de
numărul de înregistrări posibile pentru fiecare entitate participantă (raport de
cardinalitate). Cel mai întâlnit tip de relaţii este cel binar, iar în acest caz
rapoartele de cardinalitate sunt, în general, one-to-one (1:1), one-to-many (1:n)
sau many-to-many (m:n).
De exemplu, în modelul analizat este definită relaţia organizeaza care
leagă entităţile ORGANIZATOR şi PREZENTARE, relaţie care poate fi scrisă
sub forma ORGANIZATOR_organizeaza_PREZENTARE, pentru a percepe mai
uşor asocierile existente. Relaţia are cardinalitatea minimă 1:1 şi cardinalitatea
maximă 1:n.
Vom prezenta relaţiile modelului de date, dând o descriere completă a
fiecăreia. De fapt, denumirile acestor legături sunt sugestive, reflectând
conţinutul acestora şi entităţile pe care le leagă. Pentru fiecare relaţie se va
preciza cardinalitatea minimă şi maximă.
FIRMA_PUB_face_PUBLICITATE = relaţie care leagă entităţile FIRMA_PUB
şi PUBLICITATE, reflectând legătura dintre acestea (ce publicitate face o
anumită firmă de publicitate). Ea are cardinalitatea minimă 1:1 (o firmă de
publicitate trebuie să realizeze cel puţin o publicitate şi o publicitate trebuie
făcută de cel puţin o firmă de publicitate) şi cardinalitatea maximă 1:n (o firmă
de publicitate poate asigura mai multe publicităţi, iar o publicitate poate fi
făcută de o singură firmă specializată).
PUBLICITATE_se_face_PREZENTARE = relaţie care leagă entităţile
PUBLICITATE şi PREZENTARE, reflectând legătura dintre acestea (pentru o
prezentare, ce publicitate se face). Relaţia are cardinalitatea minimă 1:1 şi
cardinalitatea maximă 1:n.
ORGANIZATOR_are_PERS_CONTACT = relaţie dintre ORGANIZATOR şi
PERS_CONTACT, reflectând legătura dintre acestea (ce persoane din firma
organizatoare pot fi contactate pentru soluţionarea diverselor probleme). Ea are
cardinalitatea minimă 1:1 şi cardinalitatea maximă 1:n.
FIRMA_SEC_are_ANGAJAT_SEC = relaţie dintre entităţile FIRMA_SEC şi
ANGAJAT_SEC, reflectând legătura dintre acestea (ce angajaţi, implicaţi în
acţiunea de pază a prezentărilor de modă, au firmele de securitate). Ea are
ANGAJAT_SEC_paza_PREZENTARE = relaţie de tip many-to-many dintre
entitatea PREZENTARE şi ANGAJAT_SEC, reflectând legătura dintre acestea
(ce angajaţi ai firmei de securitate asigură buna desfăşurare a prezentărilor de
modă). Ea are cardinalitatea minimă 1:1 şi cardinalitatea maximă m:n.
SOC_ASIG_asigura_PREZENTARE = relaţie dintre entitatea PREZENTARE şi
SOC_ASIG, reflectând legătura dintre acestea (ce societate este angajată pentru
asigurarea diverselor aspecte din cadrul prezentării de modă). Ea are
CASA_MODA_participa_PREZENTARE = relaţie de tip many-to-many dintre
entităţile CASA_MODA şi PREZENTARE (ce case de modă participă la
prezentări). Ea arată şi dacă respectivele case participă, sau nu, ca organizator la
prezentari. Relaţia are cardinalitatea minimă 1:1 şi cardinalitatea maximă m:n.
CASA_MODA_lucreaza_CREATOR = relaţie dintre entităţile CASA_MODA şi
CREATOR (la ce case de modă lucrează creatorii). Relaţia are cardinalitatea
minimă 1:1 şi cardinalitatea maximă 1:n.
CREATOR_creeaza_VESTIMENTATIE = relaţie dintre entităţile CREATOR şi
VESTIMENTATIE (ce creatori realizează vestimentaţiile). Relaţia are
cardinalitatea minimă 1:0 şi cardinalitatea maximă1:n.
VESTIMENTATIE_are_ACCESORIU = relaţie dintre entităţile ACCESORIU şi

VESTIMENTATIE (ce accesorii au vestimentaţiile). Relaţia are cardinalitatea
MODEL_prezintă_VESTIMENTATIE = relaţie ce leagă entităţile MODEL şi
VESTIMENTATIE (ce vestimentaţii au fost purtate de modele). Relaţia are
CREATOR_face_ACCESORIU = relaţie ce leagă entităţile CREATOR şi
ACCESORIU (ce creatori au realizat accesoriile). Relaţia are cardinalitatea
PREZENTARE_prezinta_VESTIMENTATIE = relaţie care leagă entităţile
PREZENTARE şi VESTIMENTATIE (ce vestimentaţii au fost prezentate la
evenimentele de modă). Relaţia are cardinalitatea minimă 1:1 şi cardinalitatea
maximă 1:n.
PREZENTARE_are_LOCATIE = relaţie ce leagă entităţile PREZENTARE şi
LOCATIE (ce prezentări de modă se desfăşoară într-o locaţie). Deoarece într-o
locaţie pot să fie mai multe prezentări, relaţia are cardinalitatea minimă 1:1 şi
cardinalitatea maximă n:1.
MODEL_lucreaza_AGENTIE = relaţie dintre entităţile MODEL şi AGENTIE
(la ce agenţie este angajat un model). Relaţia are cardinalitatea minimă 1:1 şi
cardinalitatea maximă n:1.
MODEL_are_ISTORIC = relaţie dintre entităţile MODEL şi ISTORIC (istoricul
activităţii unui model, prin diferite agentii). Relaţia are cardinaliatea minimă 1:0
şi cardinalitatea maximă 1:n.
ISTORIC_refera_AGENTIE = relaţie ce leagă entităţile ISTORIC şi AGENTIE
(la ce agenţie se referă fiecare înregistrare din istoricul unui model). Relaţia are
SPONSOR_finanteaza_PREZENTARE = relaţie de tip many-to-many dintre
entităţile SPONSOR şi PREZENTARE, reflectând legătura dintre acestea (ce
sponsori finanţează prezentările de modă). Relaţia are cardinalitatea minimă 0:1
şi cardinalitatea maximă m:n.
PERS_CONTACT_are_LOCALIZARE = relaţie ce leagă entităţile
LOCALIZARE şi PERS_CONTACT (localizarea unei persoane de contact).
Ţinând cont de restricţiile impuse modelului, relaţia are cardinalitatea minimă
1:1 şi cea maximă 1:1. O astfel de relaţie este definită şi pentru entităţile
FIRMA_PUB, FIRMA_SEC, PREZENTARE, ORGANIZATOR,
CASA_MODA, SPONSOR, ANGAJAT_TEMP, SOC_ASIG, CREATOR,
LOCATIE şi AGENTIE, care sunt legate de entitatea LOCALIZARE,
permiţând astfel localizarea tuturor structurilor modelului.
PERS_CONTACT_are_INFO_CONTACT = relaţie care leagă
INFO_CONTACT şi PERS_CONTACT (modalitatea de accesare a unei
persoane de contact). Ţinând cont de restricţiile impuse modelului, relaţia are
cardinalitatea minimă 1:1 şi cea maximă 1:1. O astfel de relaţie este definită şi
pentru entităţile FIRMA_PUB, FIRMA_SEC, ORGANIZATOR,
CASA_MODA, SPONSOR, ANGAJAT_TEMP, SOC_ASIG, CREATOR,
LOCATIE şi AGENTIE, care sunt legate de entitatea INFO_CONTACT,
permiţând astfel accesarea tuturor structurilor modelului.
ANGAJAT_TEMP_primeste_la_PREZENTARE_de_la_CASA_MODA = relaţie
de tip 3 ce leagă entităţile ANGAJAT_TEMP, PREZENTARE şi
CASA_MODA, reflectând cine a fost angajat temporar, de ce casă de modă,
pentru ce prezentare. Denumirea acestei relaţii va fi primeste.
Atribut
Atributul este o proprietate descriptivă a unei entităţi sau a unei relaţii. De
exemplu, numele unei case de modă este un atribut al entităţii CASA_MODA,
iar data la care o casă de modă participă la o prezentare este un atribut al relaţiei
participă ce leagă entităţile PREZENTARE şi CASA_MODA.
Atributele pot fi simple (de exemplu, suma cu care este plătit un model de
către o casă de modă pentru o prezentare), compuse (de exemplu, adresa unei
firme de publicitate), cu valori multiple (de exemplu, numerele de telefon ale
unei persoane de contact), derivate (de exemplu, vârsta unei persoane se obţine
din data naşterii).
Observaţii
• Trebuie făcută distincţia între atribut care uzual devine coloană în
modelele relaţionale şi valoarea acestuia, care devine valoare în coloane.
• Atributele sunt substantive, dar nu orice substantiv este atribut.
• Fiecărui atribut trebuie să i se dea o descriere completă în
specificaţiile modelului (exemple, contraexemple, caracteristici).
• Pentru fiecare atribut trebuie specificat numele, tipul fizic (integer,
float, char etc.), valori posibile, valori implicite, reguli de validare,
constrângeri, tipuri compuse.
În continuare vor fi prezentate, parţial, atributele entităţilor şi relaţiilor
dând o descriere a fiecăruia, a caracteristicilor şi a constrângerilor pe care
trebuie să le îndeplinească. Semnificaţia unor atribute a căror denumire nu este
semnificativă sau care include mai multe caracteristici decât denumirea va fi
comentată pe parcursul lucrării.
Entitatea independentă ANGAJAT_TEMP are ca atribute:
cod_angajat_temp = variabilă de tip întreg, de lungime maximă 5, care
reprezintă codul unui angajat temporar.
nume = variabilă de tip caracter, de lungime maximă 25, care reprezintă numele
angajatului.
prenume = variabilă de tip caracter, de lungime maximă 25, care reprezintă
prenumele angajatului.
data_nastere = variabilă de tip dată calendaristică, care reprezintă data naşterii
angajatului respectiv.
sex = variabilă de tip caracter, luând valorile m sau f, de lungime 1, care
reprezintă sexul angajatului.
nationalitate = variabilă de tip caracter, de lungime maximă 12, care reprezintă

naţionalitatea unui angajat temporar.
cod_localizare = variabilă de tip întreg, de lungime maximă 5, care reprezintă
codul localizării angajatului. Atributul trebuie să corespundă la o valoare a cheii
primare din tabelul LOCALIZARE.
cod_info_acces = variabilă de tip caracter, de lungime maximă 5, care
reprezintă codul informaţiei de acces pentru angajatul respectiv. Atributul
trebuie să corespundă la o valoare a cheii primare din tabelul
INFO_CONTACT.
tip = variabilă de tip caracter, de lungime 10, care reprezintă funcţia pentru care
a fost angajată persoana respectivă. De exemplu, poate să fie model, stilist sau
eventual poate lua alte valori.
Subentitatea MODEL are ca atribute:
cod_angajat_temp = variabilă de tip întreg, de lungime maximă 5, care
reprezintă codul modelului.
cod_agentie = variabilă de tip întreg, de lungime maximă 5, care reprezintă
codul agenţiei la care este angajat în prezent modelul. Atributul trebuie să
corespundă la o valoare a cheii primare din tabelul AGENTIE.
inaltime = variabilă de tip numeric, de lungime 3, care reprezintă înălţimea
modelului în centimetri.
nr_pantof = variabilă de tip numeric (real), care reprezintă numărul pe care îl
poartă la pantof modelul respectiv.
info = variabilă de tip text, care include informaţii speciale despre model
(dimensiuni, greutate, preferinţe, elemente confidenţiale, palmares etc.).
Entitatea PUBLICITATE are atributele: cod_publicitate, cod_firma_pub,
cod_prezentare, tip, nume, suma, observatii. Atributul tip poate lua valorile
radio, televiziune, presa, panouri publicitare etc. Atributul nume este legat de
atributul tip în sensul că poate reprezenta numele postului de radio, al celui de
televiziune, al publicaţiei care face publicitatea.
Entitatea FIRMA_PUB are atributele: cod_firma_pub, nume, info, director,
observatii, nume_pers_contact, cod_localizare, cod_info_acces.
Entitatea ORGANIZATOR are atributele: cod_organizator, denumire, banca,
cont, informatii, cod_localizare, cod_info_acces.
Entitatea PERS_CONTACT are atributele: cod_pers_contact, cod_organizator,
nume, prenume, directie, cod_localizare, cod_info_acces.
Entitatea PREZENTARE are atributele: cod_prezentare, denumire, data_start,
data_final, cod_organizator, cod_soc_asig, cod_locatie.
Entitatea SPONSOR are atributele: cod_sponsor, tip, nume, info, cod_localizare,
cod_info_acces. Atributul tip poate lua valorile persoana fizică sau persoana
juridică. În primul caz, atributul nume va reprezenta numele şi prenumele
persoanei fizice, iar în cel de al doilea caz, va reprezenta numele societăţii.
Entitatea CASA_MODA are atributele: cod_casa_moda, nume, cifra_afaceri,
proprietar, director, istoric, data_creare, cod_localizare, cod_info_acces.
Entitatea CREATOR are atributele: cod_creator, nume, prenume, data_nastere,
data_angajare, cod_casa_moda, tip, mod_angajare, info, cod_localizare,
cod_info_acces. Atributul tip poate lua valorile designer, croitor, broder,
creator_accesorii. Atributul mod_angajare poate lua valorile permanent sau
special.
Entitatea VESTIMENTATIE are atributele: cod_vestimentatie, denumire,
valoare, descriere, cod_creator, cod_model, cod_prezentare.
Entitatea ACCESORIU are atributele: cod_vestimentatie, cod_accesoriu, tip,
descriere, valoare, cod creator.
Entitatea AGENTIE are atributele: cod_agentie, nume, data_creare, director,
cifra_afaceri, info, cod_localizare, cod_info_acces.
Entitatea ISTORIC are atributele: cod_model, data_angajare, data_final,
cod_agentie, conditii.
Entitatea LOCALIZARE are atributele: cod_localizare, adresa, cod_postal, oras,
tara.
Entitatea LOCATIE are atributele: cod_locatie, denumire, tip, capacitate,
cod_localizare, cod_info_acces. Atributul tip reprezintă tipul locaţiei respective
şi poate lua valorile: hotel, esplanadă, teatru, mall etc.
Entitatea INFO_CONTACT are atributele: cod_info_contact, telefon_mobil,
mail, telefon_fix, fax.
Entitatea FIRMA_SEC are atributele: cod_firma_sec, nume_firma, tip_servicii,
director, observatii, cod_localizare, cod_info_acces.
Entitatea ANGAJAT_SEC are atributele cod_angajat, nume, prenume,
data_nastere, specializare, nivel, observatii, cod_localizare, cod_firma_sec,
cod_info_acces.
Entitatea SOC_ASIG are atributele: cod_soc_asig, conditii, suma, director,
observatii, nume_pers_contact_firma, cod_localizare, cod_info_acces.
Relaţia CASA_MODA_participa_PREZENTARE are ca atribute:
cod_prezentare = variabilă de tip întreg, de lungime maximă 5, care reprezintă
codul prezentării. Atributul trebuie să corespundă la o valoare a cheii primare
din tabelul PREZENTARE.
cod_casa_moda = variabilă de tip întreg, de lungime maximă 5, care reprezintă
codul casei de modă. Atributul trebuie să corespundă la o valoare a cheii
primare din tabelul CASA_MODA.
tip = variabilă de tip caracter, de lungime maximă 15, care reprezintă
modalitatea în care o casă de modă participă la o prezentare, în sensul că poate
fi organizator sau neorganizator.
data = variabilă de tip dată calendaristică reprezentând ziua în care defilează

modelele casei de modă. Atributul nu este multiplu, deoarece s-a presupus că
defilarea unei case de modă are loc într-o singură zi.
Relaţia SPONSOR_finanteaza_PREZENTARE are ca atribute: cod_sponsor,
cod_prezentare, data_emitere, suma, banca, cont_emitent, cod_ordin_plata.
Relaţia ANGAJAT_SEC_paza_PREZENTARE are atributele: cod_angajat,
cod_prezentare, tip_paza, dotare, observaţii.
Relaţia ANGAJAT_TEMP_primeste_la_PREZENTARE_de_la_CASA_MODA
are ca atribute: cod_angajat_temp, cod_casa_moda, cod_prezentare suma,
data_achitare, cont, banca.
Nu s-au introdus atributele cont şi banca la entitatea ANGAJAT_TEMP,
deoarece modelul de date nu-şi propune să furnizeze informaţii complete
referitoare la toate conturile şi băncile modelelor, stiliştilor etc. Se consideră
doar banca şi contul în care casa de modă depune bani pentru prezentarea la
care aceştia au fost angajaţi.
2.3. Diagrama entitate- relaţie
Pentru proiectarea diagramei entitate-relaţie au fost stabilite anumite

reguli (care nu sunt unice):
• entităţile sunt reprezentate prin dreptunghiuri;
• relaţiile dintre entităţi sunt reprezentate prin arce neorientate;
• atributele care reprezintă chei primare trebuie subliniate sau marcate
prin simbolul „#“, plasat la sfârşitul numelui acestor atribute;
• cardinalitatea minimă este indicată în paranteze, iar cardinalitatea
maximă se scrie fără paranteze;
• nu este necesar să fie specificate, în cadrul diagramei, toate atributele.
Vom comenta câteva cazuri speciale de entităţi, relaţii, atribute şi modul
lor de reprezentare în cadrul diagramei entitate-relaţie.
• Dependenţa. Există entităţi, numite entităţi dependente care nu pot
exista în mod independent. De exemplu, se observă că entitatea
ACCESORIU depinde de VESTIMENTATIE, iar LOCATIE depinde
de entitatea PREZENTARE. Cheia primară a unei entităţi dependente
include cheia primară a sursei (cod_vestimentatie) şi cel puţin o
descriere a entităţii (cod_accesoriu). Entitatea dependentă se dese-
nează prin dreptunghiuri cu linii mai subţiri.
• Moştenirea atributelor. O subentitate (subclasă) este o submulţime
a unei alte entităţi, numită superentitate (superclasă). De exemplu,
ANGAJAT_TEMP este o superentitate pentru MODEL, iar MODEL
este o subentitate pentru ANGAJAT_TEMP. Subentitatea se
desenează prin dreptunghiuri incluse în superentitate. Există o relaţie
între o subentitate şi o superentitate, numită ISA, care are
cardinalitatea maximă 1:1 şi minimă 1:0.
• Cheile primare, atributele şi relaţiile unei superentităţi sunt valabile
pentru orice subentitate. Afirmaţia reciprocă este falsă. De exemplu,
un informatician, considerat ca subentitate a entităţii
PERS_CONTACT, poate avea ca atribute limbajele de programare
cunoscute şi nivelul de cunoaştere a acestora, dar aceste atribute nu
sunt semnificative pentru o persoană de contact care coordonează
asigurarea securităţii prezentării de modă. Cheia primară a subentităţii
INFORMATICIAN este cod_pers_contact, care este cheia primară a
superentităţii PERS_CONTACT.
• Specializare. După valorile unor atribute clasificatoare se pot
determina clase. Un grup de subentităţi reciproc exclusive defineşte o
clasă. Clasele se aliniază în desen vertical. De exemplu, pentru
entitatea PUBLICITATE, după valorile atributului tip, pot fi definite
subentităţile PANOURI_PUBLICITARE, PRESA, TELEVIZIUNE,
RADIO, fiecare având atributele sale proprii.
• Generalizare. Din entităţi similare care au mai multe atribute comune
se pot crea superentităţi. Aceste superentităţi conţin atributele comune,
iar atributele speciale sunt asignate la subentităţi. Pentru noile
superentităţi se introduc chei primare artificiale. De exemplu, din
entităţile FIRMA_PUB, FIRMA_SEC şi SOC_ASIG se poate crea
superentitatea FIRMA având drept atribute: cod_firma (cheie primară
artificială), informaţii de accesare, informaţii de localizare, director,
observatii.
• Într-o diagramă E/R se pot defini relaţii recursive. De exemplu, poate
fi definită relaţia PERS_CONTACT_supervizeaza_PERS_CONTACT.
• Unele relaţii sunt relative la două entităţi şi le numim de tip 2, iar dacă
relaţiile implică mai mult de două entităţi, le vom numi de tip 3. Trei
relaţii de tip 2 sunt diferite de o relaţie de tip 3. Rupând o relaţie de tip
3 în trei relaţii de tip 2, poate să apară informaţie incorectă.
• Trebuie excluse din model relaţiile indirecte pentru că ele pot conduce
la redundanţă în baza de date.
• Atributele derivabile trebuie eliminate şi introduse expresii prin care
aceste atribute pot fi calculate.
• Uneori apare o incertitudine referitoare la faptul că o anumită
informaţie poate fi considerată o relaţie sau un atribut. O relaţie poate
fi reprezentată ca un atribut, sau putem folosi relaţii în loc de atribute.
Dacă un atribut al unei entităţi reprezintă cheia primară a unei alte
entităţi, atunci el referă o relaţie.
• Uneori este greu de stabilit dacă informaţia analizată reprezintă o
entitate sau o relaţie. Dacă există o incertitudine, se cercetează cheia
primară. Dacă această cheie combină cheile primare a două entităţi,
atunci se defineşte o relaţie. Cheia primară a relaţiei organizeaza
combină atributele cod_organizator şi cod_prezentare, care reprezintă

cheile primare ale entităţilor ORGANIZATOR şi PREZENTARE.
Prin urmare, ORGANIZATOR_organizeaza_PREZENTARE va defini
o relaţie şi nu o entitate.
• Un atribut indirect este inoportun. El nu descrie real relaţia sau
entitatea. Prin urmare, atributele indirecte trebuie reasignate. De fapt,
un atribut indirect este un caz special de relaţie indirectă care trebuie
eliminată pentru că introduce redundanţă în date.
• Există atribute opţionale, a căror valoare este uneori necunoscută,
alteori neaplicabilă. Aceste atribute trebuie introduse la subentităţi.
Algoritmul pentru proiectarea diagramei E/R cuprinde următoarele etape:
1. identificarea entităţilor din cadrul sistemului analizat;
2. identificarea relaţiilor (asocierilor) dintre entităţi şi stabilirea cardi-
nalităţii;
3. identificarea atributelor aferente entităţilor şi asocierilor dintre
entităţi;
4. stabilirea atributelor de identificare a entităţilor, adică stabilirea
cheilor.
Relaţiile reflectă legături naturale care există între componentele
sistemului. Aceeaşi realitate poate fi însă percepută diferit de către diverşi
analişti pentru un acelaşi sistem, putând fi obţinute modele structurale distincte.
O diagramă E/R pentru modelul comentat în această secţiune este reprezentată
în figura 2.1. Diagrama este corectă, dar este optimizabilă.
Construirea diagramei conceptuale, obţinerea schemelor relaţionale şi
normalizarea acestora vor genera un model relaţional care va elimina anumite
clase de anomalii ce pot să apară în proiectarea modelului de date.
Deficienţe ale modelului E/R

În proiectarea unui model de date pot apărea diverse probleme datorită
unei interpretări eronate a sensului unei relaţii. Aceste probleme sunt denumite
capcane de conectare.
Unele dintre aceste capcane pot să nu fie semnificative pentru modelul
particular considerat, în timp ce altele cer restructurarea modelului. Există două
clase importante de capcane: de întrerupere şi în evantai.
O capcană de întrerupere poate să apară acolo unde modelul sugerează
existenţa unei relaţii între entităţi, dar nu există o cale între anumite apariţii ale
entităţilor. Această capcană poate să apară acolo unde există o relaţie cu
participare parţială (0 la cardinalitatea minimă), care face parte din calea dintre
entităţile ce sunt legate.
O capcană în evantai poate să apară acolo unde modelul ia în considerare
o relaţie între entităţi, dar calea dintre anumite apariţii ale entităţilor este
ambiguă. Aceste capcane apar când două sau mai multe relaţii one_to_many
provin din aceeaşi entitate.
INFO_CONTACT
1
FIRMA_PUB are
1 1
are M(1) PERS_CONTACT
face ORGANIZATOR 1
1 M(1)
M(1) are
M(1)
PUBLICITATE
1
organizeaza LOCALIZARE
FIRMA SEC LOCATIE

1 se_face
1
are are
M(1) M(1) M(1)
M(1) paza M(1) 1 M(1) finanteaza M(0)
ANGAJAT SEC PREZENTARE SPONSOR
M(1) 1 M(1)
1 asigura participa
SOC ASIG
M(1)
CASA_MODA primeste
prezinta 1
lucreaza
ANGAJAT_TEMP
M(1)
1 CREATOR MODEL 1(0) ISA 1
1 1 1 M(1)
creeaza prezinta
lucreaza_la
M(1) M(0) 1
face VESTIMENTATIE M(1) are AGENTIE
1 1
are refera
M(0) M(0)
M(0) ACCESORIU ISTORIC M(1)
Fig. 2.1. Diagrama E/R.
Practic, aceste capcane generează situaţiile în care, aşa cum a fost

proiectat modelul de date, el nu poate să răspundă la anumite interogări. De
exemplu, pentru a afla pentru ce prezentare de modă a fost creată o anumită
vestimentaţie, a fost necesară introducerea unei legături între entităţile
PREZENTARE şi VESTIMENTATIE, care însă a generat redundanţă în
modelul de date.
Modelul E/R extins
Conceptele de bază ale modelării entitate-relaţie nu sunt suficiente pentru
a reprezenta cerinţele aplicaţiilor actuale, care sunt mult mai complexe. Au fost
propuse, în acest sens, mai multe modele de date semantice. Modelul E/R
susţinut cu concepte semantice adiţionale defineşte modelul E/R extins (EER).
Acesta include toate conceptele modelului original, împreună cu conceptele

adiţionale de specializare, generalizare şi categorie. Aceste noi concepte au fost
deja nominalizate în acest capitol.
Superclasa (superentitatea) este o entitate care include subclase
(subentităţi) distincte, ce trebuie reprezentate în modelul de date. Subclasa are
un rol distinct şi, evident, este membră a unei superclase. O subclasă, fiind o
entitate, poate să posede propriile subclase. O entitate împreună cu subclasele
ei, subclasele acestora şi aşa mai departe defineşte o ierarhie de tip (ierarhie de
specializare). De exemplu, ANGAJAT_TEMP reprezintă o superclasă pentru
entitatea MODEL.
Specializarea este procesul de maximizare a diferenţelor dintre membrii
unei entităţi, prin identificarea caracteristicilor distinctive ale acestora.
Specializarea constituie o abordare de sus în jos în definirea unei mulţimi de
superclase şi a subclaselor lor. Pot exista diverse specializări ale aceleiaşi
entităţi, bazate pe diferite caracteristici de diferenţiere.
Dacă subclasele unei specializări sunt disjuncte, atunci o entitate poate fi
membră doar a unei subclase a acesteia (constrângere de disjuncţie).
O specializare cu participare totală specifică faptul că fiecare entitate din
superclasă trebuie să fie membră a unei subclase din specializare (constrângere
de participare).
De exemplu, specializarea contractelor de angajare poate fi cu participare
totală dacă fiecare angajat din PERS_CONTACT este fie angajat cu contract
permanent cu normă întreagă, fie cu contract temporar cu normă incompletă.
O specializare cu participare parţială specifică faptul că nu este necesar ca
o entitate să aparţină vreunei subclase a acesteia. De exemplu, există salariaţi în
PERS_CONTACT care nu aparţin niciunei subentităţi ale acesteia.
Generalizarea este procesul de minimizare a diferenţelor dintre entităţi,
prin identificarea caracteristicilor comune ale acestora. Generalizarea reprezintă
o abordare de jos în sus, care are ca rezultat identificarea unei superclase
generalizate din subclasele iniţiale.
Orice relaţie superclasă/subclasă (inclusiv cele ale unei subclase
partajate) dintr-o ierarhie de specializare/generalizare are o singură superclasă.
Totuşi, anumite situaţii necesită modelarea unei relaţii superclasă/subclasă cu
mai mult decât o superclasă distinctă. În acest caz, subclasa defineşte o
categorie. Categoria este procesul de modelare a unei singure subclase, cu o
relaţie care implică mai mult decât o singură superclasă distinctă.
2.4. Modelare orientată pe obiecte cu UML
Un limbaj de modelare reprezintă o modalitate de a comunica despre un

sistem şi de a exprima diversele modele produse în cadrul procesului de analiză
şi dezvoltare a sistemului. Limbajul furnizează o notaţie care permite
reprezentarea unui design.
Limbajul este format dintr-un set de concepte, principii şi reguli de
utilizare a acestora, cu scopul de a reprezenta modelele produse în diferite etape
de dezvoltare a sistemului. Fără un limbaj de modelare, este dificilă colaborarea
şi comunicarea dintre membrii echipei pe parcursul proiectării sistemului.
Ca orice limbaj, un limbaj de modelare are o sintaxă şi o semantică, iar
pentru semantica modelului trebuie aleasă sintaxa cea mai expresivă. De cele
mai multe ori, un limbaj de modelare este un limbaj grafic (diagramatic).
Dacă pentru utilizatori, limbajele de modelare uşurează munca de
realizare a sistemelor software, pentru realizatorii acestora sarcinile sunt
multiple şi dificile. Pentru ca un limbaj de modelare să se impună, el trebuie să
asigure o bună specificare a conceptelor sale şi a modului de reprezentare a
acestora. În acest scop, limbajele trebuie să asigure suport pentru modelatori, în
vederea rafinării treptate a soluţiei şi a captării semanticii procesului.
The Unified Modeling Language (UML) este, aşa cum semnifică şi
numele, un limbaj vizual de modelare şi de comunicare despre sistem. UML nu
este un limbaj de programare, deoarece nu dispune de întreg sprijinul semantic
şi vizual pentru a defini un astfel de limbaj. înlocui limbajele de programare.
UML este un limbaj pentru modelarea orientată pe obiecte, cu suport pentru
modelare vizuală, funcţionând ca o modalitate de a comunica şi de a exprima
cunoştinţe.
UML este un limbaj grafic de modelare pentru specificarea, vizualizarea,
construcţia şi documentarea componentelor unui sistem software (pentru
întreprinderi, telecomunicaţii, sisteme bancare şi financiare, transporturi etc.)
sau pentru modelarea organizaţională a unor sisteme non-software (din justiţie,
medicină, afaceri etc.).
UML nu este un limbaj de programare, dar modelele exprimate în UML
pot fi implementate uşor în limbaje de programare orientate pe obiecte (C++,
Java, C#) sau în baze de date relaţionale. Este posibilă nu numai generarea
codului dintr-un model UML, dar şi ingineria inversă, constând în construirea
dintr-un cod dat a unui model UML.
UML este un limbaj de modelare pentru documentare, deoarece permite
realizarea tuturor documentelor necesare înţelegerii modelului şi diagramelor
utilizate pe tot parcursul ciclului de viaţă al unui proces de realizare a unui
sistem. Documentele componentelor sistemului conţin specificarea cerinţelor,
arhitecturii şi proiectării sistemului; elaborarea codului sursă, planuri de
dezvoltare şi de management al proiectului.
În concluzie, UML nu este un limbaj de programare vizual, dar este un
model de limbaj de modelare vizual; nu este o metodologie, dar este o notaţie
pentru aceasta; nu este un proces, dar oferă suport complet pentru construcţia şi
dezvoltarea acestuia.
Este important de menţionat că UML este un limbaj de modelare, şi nu o
metodă. Majoritatea metodelor conţin atât un limbaj de modelare, cât şi un
proces. Limbajul de modelare furnizează, după cum am mai subliniat, doar
notaţia pentru reprezentarea unui design. Procesul cuprinde, însă, paşii care
trebuie să fie urmaţi pentru a realiza un design.
UML cuprinde tehnici specifice mai multor metode de dezvoltare

(proiectare) şi este suficient de logic, de expresiv pentru a putea fi utilizat
împreună cu orice metodă sau proces de dezvoltare.
Ca orice limbaj, UML are sintaxa şi semantica sa. Cu ajutorul alfabetului
şi al cuvintelor limbajului, se pot scrie propoziţii (fragmente din diagrame)
despre subiectul de analizat. Propoziţiile se pot grupa în paragrafe (diagrame
UML).
Paragrafele, la rândul lor, se pot grupa în secţiuni (moduri de vizualizare)
şi, în final, secţiunile se pot organiza în documente. Documentele UML sunt
modelele sistemului.
Sintaxa limbajului UML implică diagrame, în timp ce semantica lui se
bazează pe paradigma orientării pe obiecte. Din punct de vedere al modelării
orientate pe obiecte, entităţile (conceptele) se numesc clase, iar relaţiile dintre
ele se numesc asocieri.
Diagrama este o reprezentare grafică a unei mulţimi de elemente, de
obicei folosindu-se forme geometrice pentru a reprezenta entităţi şi linii pentru a
reprezenta asocieri. În UML, diagrama este o proiecţie a sistemului,
reprezentând o parte a sistemului sau chiar întregul sistem dintr-un anumit punct
de vedere. Acelaşi element poate apărea în toate diagramele, în câteva diagrame
sau în nicio diagramă.
UML conţine 9 tipuri de diagrame, fiecare reflectând una sau mai multe
dintre cele 5 tipuri de vizualizări posibile asupra unui sistem software.
• Diagrama claselor descrie structura unui sistem în general. În
componenţa ei intră clase, stereotipuri şi relaţiile dintre acestea.
• Diagrama obiectelor descrie structura unui sistem la un anumit
moment. Acest tip de diagramă este o variantă a diagramei claselor
care, în locul unei clase, prezintă mai multe instanţe ale ei, fiind
formată din obiecte şi legături dintre ele.
• Diagrama cazurilor de utilizare descrie funcţionalitatea unui sistem,
prezentând actorii externi, cazurile de utilizare identificate numai din
punct de vedere al actorilor (comportamentul sistemului, aşa cum este
perceput de utilizatorii lui), precum şi relaţiile dintre actori şi cazurile
de utilizare. Un actor poate fi orice sau oricine interacţionează cu
sistemul (trimite sau recepţionează mesaje de la sistem sau schimbă
informaţii cu acesta). Actorul are un rol în cadrul unui sistem, nu este
un utilizator individual al acestuia şi, din acest motiv, el este o entitate
(o clasă), nu o instanţă. Un caz de utilizare este iniţiat mereu de un
actor şi furnizează o valoare actorului.
• Diagrama componentelor (diagrama de implementare) descrie
structura fizică a codului în termenii componentelor de cod şi relaţiilor
dintre acestea.
• Diagrama de desfăşurare (de exploatare) indică arhitectura fizică pe
care este implementat sistemul, calculatoarele, nodurile sistemului şi
conexiunile dintre ele.
• Diagrama secvenţelor este o diagramă de interacţiune, care prezintă
colaborarea dinamică dintre un număr de obiecte, punând accentul pe
secvenţele de mesaje trimise între acestea pe măsura scurgerii
timpului.
• Diagrama de colaborare este tot o diagramă de interacţiune, dar care,
pe lângă interacţiunea dintre obiecte (schimbul de mesaje), prezintă
obiectele şi legăturile dintre ele.
• Diagrama de stare descrie ciclul de viaţă al unui element (al
obiectelor, subsistemelor şi sistemelor), prin specificarea stărilor în
care se găseşte elementul şi a evenimentelor care îi modifică starea.
• Diagrama de activitate prezintă activităţile şi responsabilităţile
elementelor sistemului, fiind utilizată pentru modelarea funcţiilor
sistemului. Ea are ca elemente constitutive stări de acţiune şi mesaje
care vor fi trimise sau recepţionate ca parte a acţiunii realizate.
În UML, diagramele fac parte din două categorii.
• Diagrame dinamice sau comportamentale – descriu comportamentul
şi interacţiunile dintre diverse entităţi ale sistemului informatic. Din
această categorie, fac parte diagramele de secvenţă, colaborare, stare şi
activitate.
• Diagrame statice sau structurale - descriu structura, responsabilităţile
sistemului informatic, componentele executabile ale sistemului,
locaţiile fizice de execuţie şi nodurile de stocare a datelor. Din această
categorie, fac parte diagramele claselor, obiectelor, cazurilor de
utilizare, componentelor şi diagramele de exploatare.
Pe lângă structura statică şi comportamentul dinamic, pentru
caracterizarea completă a unui sistem este necesară şi funcţionalitatea acestuia,
care poate fi analizată folosind diagramele cazurilor de utilizare.
Din punct de vedere al modelării sistemelor orientate pe obiecte din
perspectiva UML, aspectele statice sunt: clasele şi relaţiile dintre clase,
interfeţele, topologia hardware necesară execuţiei aplicaţiei.
Secţiunile UML sau modurile de vizualizare sunt grupuri de diagrame
care se adresează unei anumite mulţimi de entităţi. Toate diagramele UML pot
fi organizate în vizualizări. Fiecare vizualizare este descrisă folosind un număr
de diagrame ce conţin informaţii referitoare la un anumit aspect particular al
sistemului.
Există 5 tipuri importante de vizualizări asupra unui sistem software.
• Modul de vizualizare structural (logic) al arhitecturii unui sistem
se referă la cerinţele funcţionale ale acestuia, adică prezintă serviciile
furnizate de sistem utilizatorilor săi. Vizualizarea logică tratează din
interior sistemul şi descrie atât structura internă a acestuia, formată din
clase, obiecte şi relaţii, cât şi colaborările, legăturile care apar în urma
schimbului de mesaje între obiecte, pentru a realiza funcţionalitatea
dorită. Notaţia UML este dedicată, în mare parte, reprezentării
arhitecturii logice (clase, asocieri, obiecte, legături, generalizări,

polimorfism, pachete etc.)
• Modul de vizualizare a componentelor sistemului (implementare)
se concentrează pe descrierea componentelor care implementează
sistemul, dependenţele care există între ele, resursele alocate acestora,
precum şi rezolvarea unor probleme legate de reutilizarea,
portabilitatea codului şi informaţii administrative.
• Modul de vizualizare a cazurilor de utilizare surprinde
funcţionalitatea sistemului, aşa cum este ea percepută de actorii
externi care interacţionează cu sistemul, precum şi de utilizatorii
acestuia, de diferiţi membri ai echipei realizatoare sau de către alte
sisteme. În componenţa acestui mod intră diagramele cazurilor de
utilizare pentru descrierea statică a aspectului funcţional şi ocazional.
Se pot folosi şi diagrame de activitate pentru a încapsula latura
dinamică a funcţionalităţii.
• Modul de vizualizare comportamental este util pentru gestionarea
eficientă a resurselor, pentru execuţii paralele şi tratări asincrone ale
unor evenimente din sistem, precum şi pentru rezolvarea unor
probleme legate de comunicare şi sincronizare.
• Modul de vizualizare a desfăşurării (mediu) se referă la
desfăşurarea fizică a sistemului, indicând ce calculatoare şi ce tipuri de
noduri vor fi folosite pentru implementarea sistemului, cum sunt
acestea conectate, precum şi ce procese se vor executa în fiecare nod.
UML oferă, pe lângă elementele de bază, şi unele facilităţi care permit
organizarea şi extinderea diagramelor. Aceste facilităţi pot fi simple notaţii sau
pot fi elemente de extindere a limbajului UML. Dintre facilităţile cele mai
importante se remarcă pachetele, notele, stereotipurile şi proprietăţile.
• Pachetul reprezintă un mecanism de grupare a elementelor de
modelare. În UML, un pachet defineşte un mecanism de organizare a
elementelor în grupuri legate semantic.
• Nota cuprinde ipotezele şi deciziile aplicate în timpul analizei şi al
proiectării. Notele sunt corespondentul comentariilor din limbajele de
programare.
• Stereotipul este un concept introdus în UML, care permite extinderea
elementelor de bază pentru a crea noi elemente. Un stereotip
reprezintă un înţeles specific asociat unui element.
• Proprietatea este un element de extindere UML, care lărgeşte
proprietăţile şi semantica unui element UML.
Modelarea unui sistem priveşte modelarea aspectelor sale funcţionale,
statice şi dinamice. Pentru ca un sistem să aibă succes, în primul rând trebuie ca
cerinţele sistemului să fie exprimate într-o manieră care să permită o uşoară
înţelegere, indiferent de nivelul de pregătire informatică a celor implicaţi în
proiect, iar în al doilea rând trebuie ca membrii echipei de dezvoltare să poată
asimila cu uşurinţă modificările care apar pe parcurs în cerinţe.
Aceste condiţii sunt rezolvate în diagrama cazurilor de utilizare, care are
rolul de a reprezenta în formă grafică funcţionalităţile pe care trebuie să le
îndeplinească sistemul în faza sa finală. Pentru crearea modelului cazurilor de
utilizare, trebuie identificaţi actorii, cazurile de utilizare, relaţiile dintre actori şi
relaţiile dintre cazurile de utilizare. Realizarea acestor faze presupune discuţii
între utilizatori şi analiştii de sistem.
Cazul de utilizare poate fi privit ca un instrument de stimulare a
posibililor utilizatori în exprimarea propriilor puncte de vedere. Adeseori,
utilizatorii ştiu mai multe decât pot să explice şi nu le este uşor să se pronunţe
clar cum vor folosi sistemul. Cazurile de utilizare ajută la îndepărtarea acestui
impediment.
Discuţiile iniţiale trebuie să ducă la descoperirea actorilor şi a cazurilor
de utilizare care descriu cerinţele funcţionale în termeni generali şi care pot
stabili frontierele domeniului studiat. Următoarele discuţii au ca scop
înţelegerea, în detaliu, a domeniului studiat, ceea ce duce la evitarea introducerii
unor cazuri de utilizare, care ar îngreuna procesul de analiză.
Un caz de utilizare este o descriere a unei funcţionalităţi pe care o oferă
sistemul, o colecţie de scenarii referitoare la utilizarea unui sistem. Un scenariu
descrie o succesiune de evenimente introduse de un actor, care poate fi o
persoană, un dispozitiv hardware sau chiar trecerea timpului. Deci, actorii sunt
entităţile care iniţiază o secvenţă de evenimente (un scenariu). Rezultatul
secvenţei de evenimente trebuie să fie concretizat în ceva utilizabil de către
actorul ce a iniţiat secvenţa sau de către alt actor.
Diagrama cazurilor de utilizare are ca elemente de modelare actorii,
cazurile de utilizare, relaţiile dintre cazurile de utilizare.
Detaliile despre fiecare caz de utilizare pot fi date în documente text sau
pot fi folosite tehnici noi, de modelare dinamică, de exemplu diagramele de
activitate sau diagramele de interacţiune, pentru a specifica secvenţele de paşi
ale cazului de utilizare.
Construirea unei diagrame a cazurilor de utilizare are drept obiective:
• să capteze şi să descrie cerinţele funcţionale ale sistemului, cerinţe
rezultate în urma discuţiilor purtate de clienţi şi/sau utilizatori ai
sistemului cu dezvoltatorii acestuia;
• să ofere o descriere clară şi consistentă a ceea ce va trebui să facă
sistemul, adică folosirea modelului pentru comunicarea cerinţelor
tuturor persoanelor implicate în construirea sistemului, şi să constituie
un punct de plecare pentru alte activităţi (design, testare şi
implementare);
• să constituie o bază pentru realizarea textelor de verificare, ce decid
dacă funcţionalitatea finală concordă cu cerinţele iniţiale ale
sistemului;
• să permită transformarea cerinţelor funcţionale în viitoare clase şi

operaţii.
Diagramele UML pot fi desenate şi administrate utilizând un utilitar
CASE (Computer Edit Software Engineering). Aceste utilitare sunt deosebit de
utile în cazul unor diagrame complexe. Totuşi, dacă diagrama este prea
complicată, atunci este necesară partiţionarea ei în mai multe diagrame sau
reprezentarea la un nivel superior de abstractizare.
Exemple de utilitare CASE care permit realizarea diagramelor UML sunt
reprezentate de: Microsoft Office Visio, IBM Rational Rose Professional Data
Modeler, Altova UModel, Borland Together, Visual Paradigm for UML,
ArgoUML etc.
Interesul pentru suportul modelării bazelor de date cu ajutorul UML a
condus la crearea unor profile specifice. Un profil constituie o propunere a unei
comunităţi şi regrupează o mulţime de elemente UML care se aplică unui
context particular şi care conservă metamodelul UML. IBM Rational Rose
include un astfel de profil adaptat bazelor de date.
Există o diferenţă între un model (de exemplu, modelul conceptual de
date) şi un formalism (în care este descris un model). Astfel, putem vorbi despre
modelarea conceptuală a datelor urmând formalismul entitate-relaţie sau
formalismul UML. Notaţia exprimă doar aspectul referitor la reprezentare.
Pe lângă formalismul entitate-relaţie, considerat standardul de facto
pentru modelarea datelor, o opţiune alternativă este oferită de către UML.
Acesta include primitive pentru modelarea datelor, iniţial concepute pentru
reprezentarea structurii claselor unei aplicaţii orientate obiect, dar care pot fi
folosite pentru specificarea modelului de date al domeniului unei aplicaţii. În
particular, diagramele de clase UML pot fi utilizate ca alternativă la diagramele
entitate-relaţie.
Diferenţa majoră dintre o diagramă de clase UML şi o diagramă entitate-
relaţie este reprezentată de diferenţa dintre o clasă şi o entitate: o clasă este o
generalizare a noţiunii de entitate, care permite proiectantului să specifice nu
numai atribute, ci şi funcţii (numite metode) aplicabile instanţelor clasei. Astfel,
această diferenţă face ca UML să fie mai general decât modelul entitate-relaţie,
iar proiectantul poate exploata diagramele de clase UML pentru a realiza
aceeaşi specificaţie pe care o poate obţine cu ajutorul modelului entitate-relaţie.
Fig. 2.2. Diagrama de clase corespunzătoare unei restricţii a modelului.

Diagramele de clase UML au mai multe caracteristici decât diagramele
entitate-relaţie, cum ar fi posibilitatea de a specifica reguli de derivare pentru
atribute şi relaţii utilizând limbajul OCL (Object Constraint Language).
Pentru exemplificarea utilizării formalismului UML, vom considera o
restricţie a modelului utilizat pe parcursul acestei lucrări şi vom construi
diagrama de clase corespunzătoare. Construcţia diagramei a fost realizată cu
ajutorul programului Microsoft Visio şi este prezentată în figura 2.2 . Din
motive de spaţiu, a fost redus numărul de atribute precizate pentru fiecare clasă
din cadrul diagramei.
Prezentăm câteva observaţii referitoare la construcţia acestui model

utilizând o diagramă de clase UML. Unele observaţii au caracter general,
amintind anumite noţiuni UML necesare înţelegerii construcţiei modelului.
• Tabelul următor stabileşte echivalenţele dintre formalismele
modelului entitate-relaţie şi al notaţiei UML:
Entitate-relaţie UML
Tip entitate Clasă
Asociere (relaţie) Asociere (relaţie)
Entitate Obiect
Cardinalitate Multiplicitate
Model conceptual de Diagramă de clase
date
• Descrierea claselor în UML se divide în trei compartimente care

conţin respectiv numele clasei, atributele acesteia şi signatura
metodelor clasei. În cazul reprezentării unui model relaţional de date
nu există metode, deci al treilea compartiment este vid.
• Cardinalităţile din modelul entitate-relaţie pro ups d e Chen şi
multiplicităţile din formalismul UML sunt poziţionate identic pe axa
de reprezentare a relaţiei.
• Asocierile dispun de anumite caracteristici, dintre care se remarcă:
nume, roluri, clase de asociere.
• Numele unei asocieri este dat de o formă verbală activă sau pasivă.
Acest nume este plasat în mijlocul liniei reprezentând relaţia
respectivă. De exemplu, asocierea organizeaza dintre clasele
Organizator şi Prezentare este reprezentată în diagrama de clase prin
acest nume plasat pe linia care conectează cele două clase.
• Numele asocierii poate fi însoţit de un triunghi îndreptat către clasa
desemnată de forma verbală, cu sco pu l d e a indica sensu l d e citire a
relaţiei. De exemplu, în cazul asocierii creeaza se precizează că relaţia
se citeşte dinspre clasa Creator către clasa Vestimentatie.
• Extremitatea unei asocieri poate indica un rol. Acesta descrie modul în
care clasele sunt percepute prin intermediul relaţiei respective. Un rol
este în general desemnat printr-o formă nominală sau verbală. De
exemplu, asocierea lucreaza dintre clasele Casa_moda şi Creator este
reprezentată atât prin nume, cât şi prin rolurile angajat şi firma.
• În UML, asocierile one to one (1:1) au multiplicitatea 0..1 sau 1 la
fiecare extremitate; asocierile one to many (1:N) au multiplicitatea *
sau 1..* la o extremitate şi 0..1 sau 1 la cealaltă extremitate; asocierile
many to many (N:N) au multiplicitatea * sau 1..* la fiecare
extremitate.
• O asociere many to many cu atribute este reprezentată în UML printr-o
clasă de asociere. Aceasta conţine atributele asocierii şi este conectată
printr-o linie punctată la linia reprezentând relaţia. De exemplu,
asocierii dintre clasele Sponsor şi Prezentare îi este ataşată clasa de
asociere Finanteaza.
• Între clasele Angajat_temp şi Model există o asociere de generalizare,
corespunzătoare relaţiei ISA („is a”). Generalizarea este reprezentată
printr-o săgeată, al cărei vârf este un triunghi gol, dinspre subclasă
către superclasă.
• Între clasele Vestimentatie şi Accesoriu există o relaţie de agregare
compusă. Agregarea reprezintă în UML o asociere care nu este
simetrică şi pentru care o extremitate are un rol predominant faţă de
cealaltă. Această asociere priveşte un singur rol al său. Agregarea
aparţine mai degrabă etapei de concepţie detaliată decât celei de
modelare. Astfel, ea se va traduce la nivelul codului SQL prin
declanşatori sau constrângeri.
• Există două forme de agregare: compusă şi partajată. Compunerea
exprimă o relaţie de apartenenţă mai puternică, apărând atunci când
relaţia este de tipul „compune” sau „face parte din”. Reprezentarea
compunerii se face prin intermediul unui romb plin, poziţionat lângă
clasa care reprezintă întregul. Multiplicitatea extremităţii agregat nu
poate depăşi 1.
• Agregarea partajată presupune că un obiect poate face parte din mai
multe agregate, iar întregul se poate modifica în timp.O astfel de
relaţie se reprezintă prin intermediul unui romb gol, poziţionat lângă
clasa care reprezintă întregul.
• Relaţiile de grade strict mai mari decât 2 sunt reprezentate în UML cu
ajutorul unui romb (ca în figura 2.2) sau prin intermediul unei clase cu
stereotip. Stereotipurile constituie un mecanism de extensibilitate al
UML. Ele permit extinderea vocabularului UML astfel încât să poată
fi definite noi elemente ale modelului, derivate din cele existente dar
cu proprietăţi specifice domeniului problemei. Reprezentarea grafică a
unui stereotip se face prin plasarea numelui său, încadrat între
caracterele „<<” şi „>>” deasupra numelui unui alt element.
• În exemplul considerat, asocierea primeste este ternară, constituind
totodată o clasă de asociere. Reprezentarea acestei relaţii de gradul 3
prin intermediul unei clase cu stereotip are forma indicată în figura
2.3.
Fig. 2.3. Asociere UML de tipul 3 cu stereotip.

Diagrame entitate-relaţie
Diagrama E/R – model neformalizat pentru reprezentarea unui
sistem din lumea reală. Este un model de date conceptual de nivel înalt
dezvoltat de Chen (1976) pentru a facilita proiectarea bazelor de date.
Modelul de date conceptual este independent de:
• tipul SGBD-ului;
• platforma hardware utilizata.
Modelul conceptual este constituit din concepte care descriu:
• structura bazei de date;
• tranzactii de regasire si reactualizare asociate.
Entitate: persoană, loc, concept, activitate, eveniment care este

semnificativ pentru ceea ce modelăm.
DEPARTAMENT
SARCINA
lucreaza_in conduce
apartine_la
atasat_la
SALARIAT PROIECT
Observaţii:
• Entităţile devin tabele în modelele relaţionale.
• În general, entităţile se scriu cu litere mari.
• Entităţile sunt substantive, dar nu orice substantiv este o entitate.
• Pentru fiecare entitate este obligatoriu să se dea o descriere
detaliată.
• Nu pot exista, în aceeaşi diagramă, două entităţi cu acelaşi nume,
sau o aceeaşi entitate cu nume diferite.
Cheia primară este un identificator unic în cadrul entităţii, făcând
distincţie între valori diferite ale acesteia.
2
Cheia primară:
• trebuie să fie unică şi cunoscută la orice moment;
• trebuie să fie controlată de administratorul bazei;
• trebuie să nu conţină informaţii descriptive, să fie simplă, fără
ambiguităţi;
• să fie stabilă;
• să fie familiară utilizatorului.
Relaţie (asociere): o comunicare între două sau mai multe entităţi.

Existenţa unei relaţii este subordonată existenţei entităţilor pe care le leagă.
Gradul (tipul) unei relatii este dat de numarul entitatilor participante la
relatia respectiva.
Observaţii:
• În modelul relaţional, relaţiile devin tabele speciale sau coloane
speciale care referă chei primare.
• Relaţiile sunt verbe, dar nu orice verb este o relaţie.
• Pentru fiecare relaţie este important să se dea o descriere
detaliată.
• În aceeaşi diagramă pot exista relaţii diferite cu acelaşi nume. În
acest caz, le diferenţiază entităţile care sunt asociate prin relaţia
respectivă.
• Pentru fiecare relaţie trebuie stabilită cardinalitatea (maximă şi
minimă) relaţiei, adică numărul de tupluri ce aparţin relaţiei.
Se pot afla cardinalitatile cu verbele :
poate (cardinalitate maximă)  trebuie (cardinalitate minima)
Exemplu:
Câţi salariaţi pot lucra într-un departament? Mulţi!
În câte departamente poate lucra un salariat? In cel mult unul!

Relaţia SALARIAT_lucreaza_in_DEPARTAMENT are cardinalitatea
maximă many-one (n:1).
Exemplu:
Câţi salariaţi trebuie să conducă un departament? Cel puţin unul!
Câte departamente trebuie să conducă un salariat? Zero!

Relaţia SALARIAT_conduce_DEPARTAMENT are cardinalitatea minimă
one-zero (1:0).
3
Atribut: proprietate descriptivă a unei entităţi sau a unei relaţii.

Atributele pot fi simple, compuse, cu valori multiple, derivate.
Observaţii:
• Trebuie făcută distincţia între tipul atributului (devine coloană în
modelele relaţionale) şi valoarea acestuia (devine valoare în
coloane).
• Atributele sunt substantive, dar nu orice substantiv este atribut.
• Fiecărui atribut trebuie să i se dea o descriere completă (exemple,
contraexemple, caracteristici).
• Pentru fiecare atribut trebuie specificat numele, tipul fizic
(integer, float, char etc.), valori posibile, valori implicite, reguli
de validare, tipuri compuse.
Pentru proiectarea diagramei entitate-relaţie au fost stabilite

anumite reguli (nu sunt unice):
1. entităţile sunt reprezentate prin dreptunghiuri;
2. relaţiile dintre entităţi sunt reprezentate prin arce neorientate;
3. atributele care reprezintă chei primare trebuie subliniate sau
marcate prin simbolul „#“, plasat la sfârşitul numelui acestor
atribute;
4. cardinalitatea minimă este indicată în paranteze, iar cardinalitatea
maximă se scrie fără paranteze;
5. nu trebuie specificate toate atributele.
SALARIAT PROIECT
cod_salariat nr_proiect
nume M(0) atasat_la M(0) descriere
prenume data_initiala buget_alocat
sex
functia
salariu 1
1 M(0)
apartine_la
conduce lucreaza_in
1(0) 1 M
DEPARTAMENT SARCINA
cod_departament nr_proiect
nume nr_sarcina
nr_cladire data_inceperii
stare
Diagrama E/R.
4
Cazuri speciale de entităţi, relaţii, atribute şi modul lor de

reprezentare în cadrul diagramei entitate-relaţie.
1. Entitate dependentă – nu poate exista în mod independent
(SARCINA depinde de PROIECT). Cheia primară a unei entităţi
dependente include cheia primară a sursei (nr_proiect) şi cel puţin o
descriere a entităţii (nr_sarcina). Entitatea dependentă se desenează
prin dreptunghiuri cu linii mai subţiri.
2. Moştenirea atributelor. Subentitate (subclasă) – submulţime a unei
alte entităţi, numită superentitate (superclasă) (SALARIAT < –– >
PROGRAMATOR). Subentitatea se desenează prin dreptunghiuri
incluse în superentitate. Există o relaţie între o subentitate şi o
superentitate, numită ISA, care are cardinalitatea maximă 1:1 şi
minimă 1:0. Cheile primare, atributele şi relaţiile unei superentităţi
sunt valabile pentru orice subentitate. Afirmaţia reciprocă este falsă.
3. Generalizare. Din entităţi similare care au mai multe atribute comune
se pot crea superentităţi. Aceste superentităţi conţin atributele
comune, iar atributele speciale sunt asignate la subentităţi. Pentru
noile superentităţi se introduc chei primare artificiale.
4. Specializare. După valorile unor atribute clasificatoare se pot
determina clase. Un grup de subentităţi reciproc exclusive defineşte o
clasă. Clasele se aliniază în desen vertical.
5. Într-o diagramă E/R se pot defini relaţii recursive.
6. Unele relaţii sunt relative la două entităţi şi le numim de tip 2, iar
dacă relaţiile implică mai mult de două entităţi, le vom numi de tip 3.
Trei relaţii de tip 2 sunt diferite de o relaţie de tip 3. Rupând o relaţie
de tip 3 în trei relaţii de tip 2, pot apărea informaţii incorecte.
7. Trebuie excluse din model relaţiile indirecte deoarece ele pot conduce
la redundanţă în baza de date.
8. Atributele derivabile trebuie eliminate şi introduse expresii prin care
aceste atribute pot fi calculate.
9. Relaţie sau atribut? Dacă un atribut al unei entităţi reprezintă cheia
primară a unei alte entităţi, atunci el referă o relaţie (cod_departament
în tabelul SALARIAT).
10. Entitate sau relaţie? Se cercetează cheia primară. Dacă aceasta
combină cheile primare a două entităţi, atunci este vorba de o relaţie.
(cheia primară a relaţiei asociat_la combină cod_salariat cu
nr_proiect, prin urmare, SALARIAT_asociat la_PROIECT va defini o
relaţie şi nu o entitate).
5
11. Un atribut indirect este inoportun. El nu descrie real relaţia sau

entitatea. Prin urmare, atributele indirecte trebuie reasignate. De fapt,
un atribut indirect este un caz special de relaţie indirectă care trebuie
eliminată pentru că introduce redundanţă în date (numărul clădirii în
care lucrează un salariat este un atribut al entităţii DEPARTAMENT
şi nu este o caracteristică a entităţii SALARIAT).
12. Există atribute opţionale, a căror valoare este uneori necunoscută,
alteori neaplicabilă. Aceste atribute trebuie introduse la subentităţi
(comisionul pentru deplasare şi zona de lucru sunt atribute specifice
unui agent teritorial şi trebuie introduse la subentitatea
AGENT_TERITORIAL).
Algoritmul pentru proiectarea diagramei entitate-relaţie:

1. identificarea entităţilor din cadrul sistemului analizat;
2. identificarea relaţiilor dintre entităţi şi stabilirea cardinalităţii;
3. identificarea atributelor aferente entităţilor şi asocierilor dintre
entităţi;
4. stabilirea atributelor de identificare a entităţilor (stabilirea
cheilor).
SALARIAT
cod_salariat PROIECT
nume job_cod nr_proiect
atasat_la descriere
ISA M(0) M(0) buget_alocat
AGENT_TERITORIAL
zona data_initiala
1 1(0) comision functia 1
PROGRAMATOR apartine_la
ISA
limbaj
nivel 1(0)
1 1(0)
M(1)
SARCINA
1 M(0) 1(0) nr_proiect
nr_sarcina
data_inceperii
conduce lucreaza_in stare
casatorit
1(0) 1
DEPARTAMENT
cod_departament
nume
nr_cladire
Diagrama E/R.
6
Modelul EER (modelul E/R extins) = Diagrama E/R + concepte

aditionale (subclasă, superclasă, moştenire, specializare, generalizare).
Gestiunea activităţilor de împrumut dintr-o bibliotecă
S-a presupus (restrictiv) că într-o zi un cititor nu poate împrumuta,

de mai multe ori, aceeaşi carte. Modelul prezintă anomalii (de exemplu,
cheia primară de la entitatea carte)! A fost gândit în această manieră cu
scop pur didactic.
Entităţile şi relaţiile care intervin în acest model sunt următoarele:
1. CARTE (entitate independentă) – orice carte care se găseşte în
inventarul bibliotecii. Cheia primară este atributul codel.
2. CITITOR (entitate independentă) – orice cititor care poate
împrumuta cărţi. Cheia primară este atributul codec.
3. DOMENIU (entitate independenta) – domeniul căruia îi aparţine
o carte. Cheia primară este atributul coded.
4. IMPRUMUTA – relaţie având cardinalitatea m:m care leagă
entităţile CITITOR şi CARTE.
5. APARTINE – relaţie care leagă atributele CARTE şi
DOMENIU. Relaţia are cardinalitatea maximă m:1, iar
cardinalitatea minimă 1:1.
CITITOR
CARTE M(1) M(0)
codec#
codel# imprumuta nume
titlu dep
autor
pret
nrex
1 DOMENIU
M(0)
coded#
apartine intdom
7
Gestiunea activităţilor de editare dintr-o editură

Se analizeaza activitatea dintr-o editură referitoare la culegerea
textelor, realizarea elementelor grafice, machetarea unor publicaţii.
FRAME
SALARIAT nr_publicatie#
cod_salariat# nr_capitol#
nume job tip nr_frame#
M(1) M(0)
ISA GRAFICIAN scrie M(0)

1 1(0)
tip include
1
CAPITOL
TEHNOREDACTOR 1 M(0) nr_publicatie#
ISA nr_capitol#
tip_editor
1 1(0)
1 realizează
M(1)
cuprinde
1
ISA
1 1(0) REDACTOR_SEF 1 M(0) PUBLICATIE
experienta coordoneaza nr_publicatie#
stil
limba
Gestiunea activităţilor unei firme de construcţii

Baza de date construită prin acest model, furnizează informaţii legate
de obiective de execuţie, investitori, executanţi, şantiere, contracte etc.
necesare unui manager al unei firme de construcţii
8
SANTIER
CONTRACTANT nr_santier#
cod_contractant# specialitate
adresa sef
telefon
cont 1
executa
banca
tip_contractant M(0)
executa
SUBANTREPENOR LUCRARE
nume 1 M( cod_obiectiv#
nume_adm 1) cod_lucrare#
functie_adm adresa
1 ISA 1(0) M(1)
INVESTITOR necesita
tip_investitor
1
investeste_in
PERS_FIZICA OBIECTIV_
nume INVESTITIE
1 M(1) cod_obiectiv#
prenume
ISA
bi denumire
1 ISA 1(0) adresa
1
atasat_la
PERS_JURIDICA 1
tip_juridic
incheie CONTRACT
ISA nume
nr_contract#
functie
1 M(1) tip_contract
data_avans
Tabelele din cursurile Oracle Education. Tabelele emp, dept,

salgrade modelează gestiunea salariaţilor unei firme.
Tabelul emp(empno#, ename, job, mgr, hiredate, sal, com, deptno)
conţine informaţii despre salariaţii unei firme. Pentru fiecare salariat sunt
definite următoarele atribute: empno: codul salariatului; ename: numele
salariatului; job: funcţia; mgr: codul şefului; hiredate: data angajării; sal:
salariul; com: comisionul; deptno: codul departamentului în care lucrează.
Tabelul dept (deptno#, dname, loc) conţine informaţii despre
departamentele în care lucrează salariaţii. Atributele sale reprezintă:
deptno: codul departamentului; dname: numele departamentului; loc:
localitatea unde funcţionează departamentul.
Tabelul salgrade(grade#, losal, hisal) conţine informaţii despre
grilele de salarizare. Atributele tabelului au următoarea semnificaţie: grade:
codul grilei de salarizare; losal: limita inferioară a grilei de salarizare;
hisal: limita superioară a grilei de salarizare.
9
Ordonarea informaţiilor cu privire la descoperirile de

monede antice din Romania
petrecut_in EVENIMENT
PUNCT
gasita_in
stantata_cu
ARTICOL publicata MONEDA STANTA
inclusa_in
pastrata_la
TEZAUR MUZEU
STANŢA (nr_stanţă, împărat emitent, valoare nominală, an emitere,

monetăria, legenda de pe avers, legenda de pe revers) == > atribute ale
entităţii STANTA
Completaţi cardinalitatea!
Evidenţa şcolilor de şoferi din Romania
SCOALA CLIENT
cod_scoala# cod_client#
INSTRUCTOR EXAMEN
cod_instructor# cod_examen#
EXAMINATOR
MASINA cod_examinator#
cod_masina#
Completaţi relaţiile (lucreaza_la, conduce, sustine, asista, instruieste) dintre

entităţi şi specificaţi cardinalitatea!
10
Campionatele de fotbal ale diferitelor ţări
ECHIPA
Cod_echipa# M(1) sustine M(1) SPONSOR
Nume Cod_sponsor#
Oras Nume
joaca
M(1)
MECI
Tara#
Nr_etapa#
Cod_meci#
M(1)
apartine_de
ETAPA
Tara
Nr_etapa
M(1)
atasata_la
CAMPIONAT
Tara#
11
Modelul relaţional
Modelul relaţional a fost conceput şi dezvoltat de E.F. Codd. El este
un model formal de organizare conceptuală a datelor, destinat reprezentării
legăturilor dintre date, bazat pe teoria matematică a relaţiilor. Modelul
relaţional este alcătuit numai din relaţii şi prin urmare, orice interogare
asupra bazei de date este tot o relaţie.
Calităţi:
• este simplu;
• riguros din punct de vedere matematic;
• nu este orientat spre sistemul de calcul.
Modalităţi pentru definirea unui SGBD relaţional:
• prezentarea datelor în tabele supuse anumitor operaţii de tip
proiecţie, selecţie, reuniune, compunere, intersecţie etc.
• un sistem de baze de date ce suportă un limbaj de tip SQL –
Structured Query Language;
• un sistem de baze de date care respectă principiile modelului
relaţional introdus de E.F. Codd.
Caracteristicile unui model relaţional:
• structura relaţională a datelor;
• operatorii modelului relaţional;
• regulile de integritate care guvernează folosirea cheilor în model.
Aceste trei elemente corespund celor trei componente ale ingineriei
software: informaţie, proces, integritate.
Structura datelor
Definirea noţiunilor de domeniu, relaţie, schemă relaţională, valoare
null şi tabel vizualizare (view).
Conceptele utilizate pentru a descrie formal, uzual sau fizic
elementele de bază ale organizării datelor sunt date în următorul tabel:
Formal Uzual Fizic
relaţie tablou fişier
tuplu linie înregistrare
atribut coloană câmp
domeniu tip de dată tip de dată
12
Domeniu – mulţime de valori care poate fi definită fie enumerând

elementele componente, fie definind o proprietate distinctivă a domeniului
valorilor.
Fie D 1 , D 2 , ..., D n domenii finite, nu neapărat disjuncte. Produsul
cartezian D 1 × D 2 × ... × D n al domeniilor D 1, D 2, ..., Dn este definit de
mulţimea tuplurilor (V1 , V2 , ..., Vn ), unde V1 ∈ D 1, V2 ∈ D 2, ..., Vn ∈ Dn .
Numărul n defineşte aritatea tuplului.
O relaţie R pe mulţimile D 1, D2 , ..., D n este o submulţime a produsului
cartezian D1 × D2 × ... × Dn, deci este o mulţime de tupluri. Caracteristicile
unei relaţii  comentat curs!
Caracteristicile unei relatii:
• are o denumire unica;
• fiecare celula contine o valoare atomica;
• fiecare atribut are nume unic;
• toate valorile unui atribut apartin aceluiasi domeniu;
• ordinea atributelor nu are importanta;
• nu exista dubluri ale tuplurilor;
• teoretic, ordinea tuplurilor nu are importanta.
Definirea unei relaţii se referă la mulţimi care variază în timp. Pentru a
caracteriza o relaţie este necesară existenţa un element invariant în timp:
structura relaţiei (schema relaţională). Mulţimea numelor atributelor
corespunzătoare unei relaţii R defineşte schema relaţională a relaţiei
respective. Vom nota schema relaţională prin R(A 1, A2, ..., An ). Exemplu!
Putem reprezenta o relaţie printr-un tabel bidimensional în care fiecare
linie corespunde unui tuplu şi fiecare coloană corespunde unui domeniu din
produsul cartezian. O coloană corespunde de fapt unui atribut. Numărul
atributelor defineşte gradul (aritatea) relaţiei, iar numărul de tupluri din
relaţie defineşte cardinalitatea relaţiei.
Exemplu (crearea unui tabel în SQL):
CREATE TABLE salariat (
cod_salariat SMALLINT,
nume VARCHAR(25),
prenume VARCHAR(20),
sex CHAR(1),
salariu INTEGER,
sot SMALLINT,
job_cod VARCHAR(6),
cod_departament SMALLINT );
13
Când se inserează tupluri într-o relaţie, de multe ori un atribut este

necunoscut sau neaplicabil. Pentru a reprezenta acest atribut a fost
introdusă o valoare convenţională în relaţie, şi anume valoarea null.
Tabelul vizualizare (view, filtru, relaţie virtuală, vedere) constituie
un filtru relativ la unul sau mai multe tabele, care conţine numai informaţia
necesară unei anumite abordări sau aplicaţii.
Vizualizarea este virtuală deoarece datele pe care le conţine nu sunt
în realitate memorate într-o bază de date. Este memorată numai definiţia
vizualizării. Vizualizarea nu este definită explicit, ca relaţiile de bază, prin
mulţimea tuplurilor componente, ci implicit, pe baza altor relaţii prin
intermediul unor expresii relaţionale. Stabilirea efectivă a tuplurilor care
compun vizualizarea se realizează prin evaluarea expresiei atunci când
utilizatorul se referă la acest tabel.
Exemplu (crearea unei vizualizări în SQL):
CREATE VIEW programator(nume,departament)
AS SELECT nume,cod_departament
FROM salariat
WHERE job_cod=’programator’;
Reguli de integritate  aserţiuni pe care datele conţinute în baza

de date trebuie să le satisfacă.
Trebuie făcută distincţia între:
• regulile structurale inerente modelării datelor;
• regulile de funcţionare specifice unei aplicaţii particulare.
Există trei tipuri de constrângeri structurale (de cheie, de referinţă, de
entitate) ce constituie mulţimea minimală de reguli de integritate pe care
trebuie să le respecte un SGBD relaţional. Restricţiile de integritate
minimale sunt definite în raport cu noţiunea de cheie a unei relaţii.
O mulţime minimală de atribute ale căror valori identifică unic un
tuplu într-o relaţie reprezintă o cheie pentru relaţia respectivă.
Fiecare relaţie are cel puţin o cheie. Una dintre cheile candidat va fi
aleasă pentru a identifica efectiv tupluri şi ea va primi numele de cheie
primară. Cheia primară nu poate fi reactualizată. Atributele care reprezintă
cheia primară sunt fie subliniate, fie urmate de semnul #.
O cheie identifică linii şi este diferită de un index care localizează
liniile. O cheie secundară este folosită ca index pentru a accesa tupluri. Un
grup de atribute din cadrul unei relaţii care conţine o cheie a relaţiei poartă
numele de supercheie.
14
Fie schemele relaţionale R1(P1, S1) şi R2(S1, S2), unde P1 este cheie
primară pentru R1, S1 este cheie secundară pentru R1, iar S1 este cheie
primară pentru R2. În acest caz, vom spune că S1 este cheie externă (cheie
străină) pentru R1.
Modelul relaţional respectă trei reguli de integritate structurală.
 Regula 1 – unicitatea cheii. Cheia primară trebuie să fie unică şi
minimală.
 Regula 2 – integritatea entităţii. Atributele cheii primare trebuie
să fie diferite de valoarea null.
 Regula 3 – integritatea referirii. O cheie externă trebuie să fie ori
null în întregime, ori să corespundă unei valori a cheii primare
asociate.
Proiectarea modelului relaţional (exemple  curs!)
Transformarea entităţilor
 Entităţile independente devin tabele independente. Cheia
primară nu conţine chei externe.
 Entităţile dependente devin tabele dependente. Cheia primară a
entităţilor dependente conţine cheia primară a entităţii de care
depinde (cheie externă) plus unul sau mai multe atribute
adiţionale.
 Subentităţile devin subtabele. Cheia externă se referă la
supertabel, iar cheia primară este această cheie externă (cheia
primară a subentităţii PROGRAMATOR este cod_salariat care
este o cheie externă).
Transformarea relaţiilor
 Relaţiile 1:1 şi 1:n devin chei externe. Relaţia conduce devine
coloană în tabelul DEPARTAMENT, iar relaţia lucreaza_in
devine coloană în tabelul SALARIAT. Simbolul „×“ indică
plasamentul cheii externe, iar simbolul „×“ exprimă faptul că
această cheie externă este conţinută în cheia primară. Relaţia 1:1
plasează cheia externă în tabelul cu mai puţine linii.
 Relaţia m:n devine un tabel special, numit tabel asociativ, care
are două chei externe pentru cele două tabele asociate. Cheia
primară este compunerea acestor două chei externe plus
eventuale coloane adiţionale. Tabelul se desenează punctat.
15
 Relaţiile de tip trei devin tabele asociative. Cheia primară este

compunerea a trei chei externe plus eventuale coloane adiţionale.
Transformarea atributelor
 Un atribut singular devine o coloană.
 Atributele multiple devin tabele dependendente ce conţin cheia
primară a entităţii şi atributul multiplu. Cheia primară este o
cheie externă, plus una sau mai multe coloane adiţionale.
 Entităţile devin tabele, iar atributele lor devin coloane în aceste
tabele. Ce devin atributele relaţiilor? Pentru relaţii 1:1 şi 1:n,
atributele relaţiilor vor aparţine tabelului care conţine cheia
externă, iar pentru relaţii m:n şi de tipul trei, atributele vor fi
plasate în tabelele asociative.
SALARIAT
cod_salariat#
PROIECT
nr_proiect#
conduce lucreaza_in apartine_la
DEPARTAMENT
cod_departament#
SARCINA
nr_proiect#
nr_sarcina#
atasat_la
SALARIAT cod_salariat# PROIECT
cod_salariat# nr_proiect# nr_proiect#
TELEFON
cod_salariat#
SALARIAT nr_telefon#
cod_salariat#
Cele patru tipuri de tabele (independente, dependente, subtabele şi

asociative) se deosebesc prin structura cheii primare.
16
Tabel Reprezintă Cheie primară

Independent entitate independentă nu conţine chei externe
Subtabel subentitate o cheie externă
entitate dependentă o cheie externă şi una sau mai
Dependent
atribute multiple multe coloane adiţionale
relaţie m:n două sau mai multe chei externe
Asociativ
relaţii de tip 3 şi (opţional) coloane adiţionale
Diagrama conceptuală pentru proiectarea modelului relaţional

comentat a fost construită din diagrama E/R prin adăugarea tabelelor
asociative şi prin marcarea cheilor externe.
SALARIAT
cod_salariat# PROIECT
salariu job_cod nr_proiect#
nume ATASAT_LA descriere
sex AGENT_TERITORIAL cod_salariat# buget_alocat
zona nr_proiect#
comision functie
PROGRAMATOR
limbaj
nivel
apartine_la
conduce lucreaza_in casatorit SARCINA

nr_proiect#
nr_sarcina#
data_inceperii
DEPARTAMENT TELFON stare
cod_departament# cod_salariat#
nume nr_telefon#
nr_cladire
Schemele relaţionale corespunzătoare acestei diagrame conceptuale

sunt următoarele:
– SALARIAT(cod_salariat#, nume, prenume, sex, job_cod, cod_sot,
forma_plata, nr_depart);
17
– DEPARTAMENT(cod_departament#, nume, numar_cladire,

cod_sal);
– ATASAT_LA(cod_salariat#, nr_proiect#, functia);
– PROIECT(nr_proiect#, descriere, buget_alocat);
– SARCINA(nr_proiect#, nr_sarcina, data_inceperii, stare);
– AGENT_TERITORIAL(cod_salariat#, zona, comision);
– PROGRAMATOR(cod_salariat#, limbaj, nivel);
– TELEFON(cod_salariat#, nr_telefon#).
Gestiunea activităţilor unei firme de construcţii

CONTRACTANT(cod_contractant#, adresa, telefon, cont, banca,
tip_contractant);
SUBANTREPRENOR(cod_contractant#, nume, nr_reg_comert,
nume_adm, functie_adm);
INVESTITOR(cod_contractant#, tip_investitor);
PERS_FIZICA(cod_contractant#, nume, prenume, bi);
PERS_JURIDICA(cod_contractant#, tip_juridic, nume, reprez_legal,
functie);
CONTRACT(nr_contract#, tip_contract, data_incheiere, garantie,
val_investitie, durate_executie, cont, banca, perioada, avans, data_avans,
cod_contractant);
OBIECTIV_INVESTITIE(cod_obiectiv#, denumire, adresa, adc,
nr_cert_urb, nr_aut_constr, nr_contract, cod_contractant);
LUCRARE(cod_lucrare#, cod_obiectiv#, tip_lucrare, nume, data_inc,
data_sf, nr_santier, cod_contractant);
18
CONTRACTANT
cod_contractant#
adresa
telefon
cont
banca tip_contractant
LUCRARE ŞANTIER
SUBANTREPENOR cod_lucrare# nr_şantier#
executa
nume executa cod_obiectiv# specialitate şef
nume_adm
funcţie_adm
necesita
INVESTITOR
tip_investitor OBIECTIV_INVESTITIE
cod_obiectiv#
denumire
PERS_FIZICA
adresa
investeste_in
nume
prenume
bi
atasat_la
CONTRACT
PERS_JURIDICA nr_contract#
tip_contract
tip_juridic data_avans
nume incheie
functie
19
Gestiunea activităţilor de editare dintr-o editură
REALIZEAZA FRAME
SALARIAT cod_salariat# nr_publicatie#
cod_salariat# nr_publicatie# nr_capitol#
nume job nr_capitol# nr_frame#
nr_frame# tip
GRAFICIAN
tip include
TEHNOREDACTOR CAPITOL
tip_editor scrie nr_publicatie#
nr_capitol#
REDACTOR_SEF dimensiune
experienta
coordoneaza cuprinde
PUBLICATIE
TELEFON LIMBA nr_publicatie#
cod_salariat# cod_salariat# stil
nr_telefon# limba_cun#
SALARIAT(cod_salariat#, nume, prenume, vechime, salariu, job);

GRAFICIAN(cod_salariat#, tip);
TEHNOREDACTOR(cod_salariat#, tip_platforma, tip_editor, viteza);
REDACTOR_SEF(cod_salariat#, experienta);
LIMBA(cod_salariat#, limba_cunos#);
TELEFON(cod_salariat#, nr_telefon#);
REALIZEAZA(cod_salariat#, nr_frame#, nr_publicatie#, nr_capitol#,
data_inc, data_lim);
FRAME(nr_frame#, nr_publicatie#, nr_capitol#, tip, dim, format);
CAPITOL(nr_publicatie#, nr_capitol#, dimensiune, cod_salariat);
PUBLICATIE(nr_publicatie#, stil, beneficiar, autor, cod_salariat, cost,
titlu, limba).
20
Algebra relaţională
Limbajul de definire a datelor (LDD) precizează entităţile, relaţiile
dintre ele, atributele, structura atributelor, cheile, constrângerile, prin
urmare defineşte structura obiectelor bazei de date (schema bazei).
Limbajul de prelucrare a datelor (LMD) dintr-o bază de date
relaţionale cuprinde aspecte referitoare la introducerea, eliminarea,
modificarea şi căutarea datelor.
• Introducerea datelor – permite adăugarea de tupluri la o relaţie.
Tuplurile pot fi introduse de utilizator sau pot fi obţinute din alte
relaţii existente în baza de date.
• Eliminarea datelor – permite ştergerea tuplurilor ce satisfac
condiţii date.
• Modificarea datelor – permite reactualizarea tuplurilor ce
satisfac condiţii date cu noi valori ale atributelor sau cu rezultate
ale unor operaţii aritmetice efectuate asupra unor valori existente.
• Căutarea datelor – permite găsirea tuplurilor sau a unor părţi ale
tuplurilor ce satisfac condiţii date.
Modelul relaţional oferă două mulţimi de operatori pe relaţii:
• algebra relaţională (filtrele se obţin aplicând operatori specializaţi
asupra uneia sau mai multor relaţii din cadrul bazei relaţionale);
• calculul relaţional (filtrele se obţin cu ajutorul unor formule
logice pe care tuplurile rezultatului trebuie să le satisfacă).
Algebra relaţională a fost introdusă de E.F. Codd ca o mulţime de

operaţii formale acţionând asupra unor relaţii şi având ca rezultat alte
relaţii. Baza teoretică pentru limbajele de interogare relaţionale o constituie
operatorii introduşi de Codd pentru prelucrarea relaţiilor.
Operatorii modelului relaţional definesc operaţiile care se pot efectua
asupra relaţiilor în scopul realizării funcţiilor de prelucrare asupra BD.
Operatorii sunt numai pentru citire (nu actualizeaza operanzi)!!!
Scopul fundamental al algebrei relationale este de a permite scrierea
expresiilor relationale. Expresiile servesc ca o reprezentare de nivel
superior, simbolică, a intenţiilor utilizatorului şi pot fi supuse unei
diversităţi de reguli de transformare (optimizare).
Relaţiile sunt închise faţă de algebra relaţională (operanzii şi

21
rezultatele sunt relaţii  ieşirea unei operaţii poate deveni intrare pentru
alta)  posibilitatea imbricării expresiilor în algebra relaţională).
Operatorii algebrei relaţionale sunt:
• operatori tradiţionali pe mulţimi (UNION, INTERSECT,
PRODUCT, DIFFERENCE);
• operatori relaţionali speciali (PROJECT, SELECT, JOIN,
DIVISION).
Calculul relaţional reprezintă o adaptare a calculului predicatelor la
domeniul bazelor de date relaţionale. Ideea de bază este de a identifica o
relaţie cu un predicat. Pe baza unor predicate iniţiale, prin aplicarea unor
operatori ai calculului cu predicate (conjuncţia, disjuncţia, negaţia,
cuantificatorul existenţial şi cel universal) se pot defini noi relaţii.
Calculul relaţional p o ate să fie orientat pe tuplu ri sau o rientat p e
domenii.
Echivalenţa dintre algebra relaţională şi calculul relaţional a fost
demonstrată de J.D.Ullman. Această echivalenţă arată că orice relaţie
posibil de definit în algebra relaţională poate fi definită şi în cadrul calcului
relaţional, şi reciproc.
Operatorii (unari sau binari) algebrei relaţionale realizează
următoarele funcţii:
• SELECT (selecţie) – extrage tupluri ce satisfac o condiţie specificată;
• PROJECT (proiecţie) – extrage atributele specificate;
• DIFFERENCE (diferenţă) – extrage tupluri care apar într-o relaţie, dar
nu apar în cealaltă;
• PRODUCT (produs cartezian) – generează toate perechile posibile de
tupluri, primul element al perechii fiind luat din prima relaţie, iar cel de-
al doilea element din cealaltă relaţie;
• UNION (reuniune) – reuneşte două relaţii;
• INTERSECT (intersecţie) – extrage tupluri care apar în ambele relaţii;
• DIVISION (diviziune) – extrage valorile atributelor dintr-o relaţie, care
apar în toate valorile atributelor din cealaltă relaţie;
• JOIN (compunere) – extrage tupluri din mai multe relaţii corelate:
• NATURAL JOIN (compunere naturală) – combină tupluri din două
relaţii, cu condiţia ca atributele comune să aibă valori identice;
• SEMI-JOIN (semi-compunere) – selectează tupluri ce aparţin unei
singure relaţii, care sunt corelate cu tupluri din cea de a doua relaţie;
22
• Θ-JOIN (Θ-compunere) – combină tupluri din două relaţii (nu neaparat

corelate), cu condiţia ca valorile atributelor specificate să satisfacă o
anumită condiţie;
• OUTER JOIN (compunere externă) – combină tupluri din două relaţii,
astfel încât condiţiile de corelare să fie satisfăcute. Tuplurile din orice
relaţie care nu satisfac aceste condiţii sunt completate cu valori null.
Pentru operatorii UNION, INTERSECT şi DIFFERENCE, se
presupune că sunt aplicaţi numai la relaţii având aceeaşi aritate, iar ordinea
(nu numele) atributelor este aceeaşi.
Operatorul PROJECT
Proiecţia este o operaţie unară care elimină anumite atribute ale unei
relaţii producând o submulţime „pe verticală“ a acesteia. Suprimarea unor
atribute poate avea ca efect apariţia unor tupluri duplicate, care trebuie
eliminate.
Prin proiecţie se construieşte dintr-o relaţie R, o nouă relaţie:
a) ştergând din R atributele care nu sunt menţionate în parametrii
proiecţiei;
b) eliminând dublurile care apar după ştergere.
Pentru a reprezenta operatorul proiecţie sunt utilizate diferite notaţii:
Π A1, ..., Am (R) PROJECT (R, A1 , ..., Am)
R[A1 , ..., Am ]
unde A1 , A 2 , ..., Am sunt parametrii proiecţiei relativ la relaţia R.
Exemplu. Să se obţină o listă ce conţine numele, prenumele şi sexul
angajaţilor.
1. Proiecţie în algebra relaţională:
Rezultat = PROJECT(SALARIAT, nume, prenume, sex)
2. Proiecţie cu dubluri în SQL:
SELECT nume, prenume, sex
FROM salariat;
3. Proiecţie fără dubluri în SQL:
SELECT DISTINCT nume, prenume, sex
FROM salariat;
23
Operatorul SELECT
Selecţia (restrictia) este o operaţie unară care produce o submulţime
pe „orizontală“ a unei relaţii R. Această submulţime se obţine prin
extragerea tuplurilor din R care satisfac o condiţie specificată.
Sunt utilizate diferite notaţii:
σ condiţie (R) R[condiţie]
SELECT(R, condiţie) RESTRICT(R, condiţie).
Exemplu. Să se obţină informaţii complete despre angajaţii de sex
masculin.
1. Selecţie în algebra relaţională:
Rezultat = SELECT(SALARIAT, sex = ‘m’)
2. Selecţie în SQL:
SELECT *
FROM salariat
WHERE sex = ’m’;
Operatorul UNION
Reuniunea a două relaţii R şi S este mulţimea tuplurilor aparţinând
fie lui R, fie lui S, fie ambelor relaţii.
Sunt utilizate notaţiile:
R∪S
UNION(R, S)
OR(R, S)
APPEND(R, S).
Exemplu. Să se obţină lista cu numele persoanelor fizice şi a
subantreprenorilor.
SELECT nume
FROM subantreprenor
UNION
SELECT nume
FROM pers_fizica;
24
Operatorul DIFFERENCE
Diferenţa a două relaţii R şi S este mulţimea tuplurilor care aparţin
lui R, dar nu aparţin lui S. Diferenţa este o operaţie binară necomutativă
care permite obţinerea tuplurilor ce apar numai într-o relaţie.
R–S
DIFFERENCE(R, S)
REMOVE(R, S)
MINUS(R, S).
Exemplu. Să se obţină lista cu numărul contractului, tipul
contractului, valoarea investiţiei şi durata lucrării pentru contractele de
subantrepriză pentru care valoarea investiţiei nu depăşeşte 60000$.
1. Diferenţă în algebra relaţională:
R=PROJECT(SELECT(CONTRACT, tip_contract=T),
nr_contract, tip_contract, val_investitie, durata_lucrare);
S=PROJECT(SELECT(CONTRACT, val_investitie > 60000),
nr_contract, tip_contract, val_investitie, durata_lucrare);
Rezultat = DIFFERENCE(R, S)
2. Diferenţa în SQL:
SELECT nr_contract,tip_contract,
val_investitie,durata_lucrare
FROM contract
WHERE tip_contract
MINUS
SELECT nr_contract,tip_contract,
val_investitie,durata_lucrare
FROM contract
WHERE val_investitie>60000;
Evident diferenţa se poate referi la tabele diferite! Implementaţi
cererea prin care se listează toate oraşele în care se află o filială, dar nici o
proprietate.
Operatorul INTERSECT
Intersecţia a două relaţii R şi S este mulţimea tuplurilor care aparţin
şi lui R şi lui S. Operatorul INTERSECT este un operator binar, comutativ,
derivat:
25
R ∩ S = R – (R – S)
R ∩ S = S – (S – R).
INTERSECT(R, S)
R∩S
AND(R, S).
În anumite dialecte SQL există operator special (INTERSECT), care
realizează această operaţie. Operatorii INTERSECT şi DIFFERENCE pot
fi simulaţi în SQL (în cadrul comenzii SELECT) cu ajutorul opţiunilor
EXISTS, NOT EXISTS, IN, != ANY.
Exemplu. Utilizând tabelele agent_teritorial şi programator să se
obţină lista codurilor salariaţilor care sunt programatori, dar care lucrează şi
ca agenţi teritoriali.
1. Intersecţie în algebra relaţională:
R = PROJECT(AGENT_TERITORIAL, cod_salariat);
S = PROJECT(PROGRAMATOR, cod_salariat),
Rezultat = INTERSECT(R, S).
2. Intersecţie în SQL:
SELECT cod_salariat
FROM agent_teritorial
INTERSECT
SELECT cod_salariat
FROM programator;
3. Simularea intersecţiei în SQL:
SELECT cod_salariat
FROM programator p
WHERE EXISTS
(SELECT cod_salariat
FROM agent_teritorial a
WHERE p.cod_salariat=a.cod_salariat);
Operatorul PRODUCT
Fie R şi S relaţii de aritate m, respectiv n. Produsul cartezian al lui R
cu S este mulţimea tuplurilor de aritate m + n unde primele m componente
formează un tuplu în R, iar ultimele n componente formează un tuplu în S.
26
R×S
PRODUCT(R, S)
TIMES(R, S).
Exemplu. Să se obţină lista tuturor posibilităţilor de investiţie în
diverse obiective de către o firmă care este persoană juridică.
1. Produs cartezian în algebra relaţională:
R = PROJECT(PERS_JURIDICA, nume, cod_contractant);
S = PROJECT(OBIECTIV_INVESTITIE, denumire);
Rezultat = PRODUCT(R, S).
2. Produs cartezian în SQL:
SELECT cod_contractant, nume, denumire
FROM obiectiv_investitie, pers_juridica;
Operatorul DIVISION
Diviziunea este o operaţie binară care defineşte o relaţie ce conţine
valorile atributelor dintr-o relaţie care apar în toate valorile atributelor din
cealaltă relaţie.
DIVIDE(R, S)
DIVISION(R, S)
R ÷ S.
Diviziunea conţine acele tupluri de dimensiune n – m la care, adăugând
orice tuplu din S, se obţine un tuplu din R.
Operatorul diviziune poate fi exprimat formal astfel:
R(n) ÷ S(m) = {t(n-m)  ∀ s ∈ S, (t, s) ∈ R} unde n > m şi S ≠ ∅.
Operatorul DIVISION este legat de cuantificatorul universal (∀) care
nu există în SQL. Cuantificatorul universal poate fi însă simulat cu ajutorul
cuantificatorului existenţial (∃) utilizând relaţia:
∀x P(x) ≡ ¬ ∃ x ¬ P(x).
Prin urmare, operatorul DIVISION poate fi exprimat în SQL prin
succesiunea a doi operatori NOT EXISTS.
Exemplu. Să se obţină codurile salariaţilor ataşaţi tuturor proiectelor
pentru care s-a alocat un buget egal cu 1000.
1. Diviziune în algebra relaţională:
27
R = PROJECT(ATASAT_LA, cod_salariat, nr_proiect);

S = PROJECT(SELECT(PROIECT, buget = 1000), nr_proiect);
Rezultat = DIVISION(R, S).
2. Diviziune în SQL:
SELECT UNIQUE cod_salariat
FROM atasat_la sx
WHERE NOT EXISTS
(SELECT *
FROM proiect pp
WHERE proiect.buget=’1000’
AND NOT EXISTS
(SELECT *
FROM atasat_la bb
WHERE pp.nr_proiect=bb.nr_proiect
AND bb.cod_salariat=sx.cod_salariat));
3. Simularea diviziunii cu ajutorul funcţiei COUNT:
SELECT cod_salariat
FROM atasat_la
WHERE nr_proiect IN
(SELECT nr_proiect
FROM proiect
WHERE buget=1000)
GROUP BY cod_salariat
HAVING COUNT(nr_proiect)=
(SELECT COUNT(*)
FROM proiect
WHERE buget=1000);
Operatorul JOIN
Operatorul de compunere (uniune) permite regăsirea informaţiei din
mai multe relaţii corelate. Operatorul combină produsul cartezian, selecţia
şi proiecţia.
Operatorul NATURAL JOIN

Operatorul de compunere naturală (NATURAL JOIN) combină
tupluri din două relaţii R şi S, cu condiţia ca atributele comune să aibă
valori identice.
Algoritmul care realizează compunerea naturală este următorul:
1. se calculează produsul cartezian R × S;
28
2. pentru fiecare atribut comun A care defineşte o coloană în R şi o

coloană în S, se selectează din R × S tuplurile ale căror valori
coincid în coloanele R.A şi S.A (atributul R.A reprezintă numele
coloanei din R × S corespunzătoare coloanei A din R);
3. pentru fiecare astfel de atribut A se proiectează coloana S.A, iar
coloana R.A se va numi A.
Operatorul NATURAL JOIN poate fi exprimat formal astfel:
JOIN(R, S) = Π i1,...,im σ(R.A1 = S.A1)∧ ... ∧(R.Ak = S.Ak) (R × S),
unde A1 , ..., Ak sunt atributele comune lui R şi S, iar i1 , ..., i m reprezintă lista
componentelor din R × S (păstrând ordinea iniţială) din care au fost
eliminate componentele S.A1 , ..., S.Ak .
Exemplu. Să se obţină informaţii complete despre angajaţi şi
departamentele în care lucrează.
1. Operatorul de compunere naturală în algebra relaţională:
Rezultat = JOIN(SALARIAT, DEPARTAMENT).
2. Operatorul de compunere naturală în SQL:
SELECT *
FROM salariat, departament
WHERE nr_depart = cod_departament;
Operatorul θ-JOIN
Operatorul θ-JOIN combină tupluri din două relaţii (nu neapărat
corelate) cu condiţia ca valorile atributelor specificate să satisfacă o
anumită condiţie specificată explicit în cadrul operaţiei.
Operatorul θ-JOIN este un operator derivat, fiind o combinaţie de
produs scalar şi selecţie:
JOIN(R, S, condiţie) = σ condiţie (R × S)
Exemplu. Să se afişeze pentru fiecare salariat, codul acestuia şi grila
sa de salarizare.
SELECT empno, level
FROM salgrade, emp
WHERE sal BETWEEN losal AND hisal;
Exemplu. Să se obţină informaţii despre contractanţi (codul şi banca)
şi obiectivele de investiţie asociate acestora (denumire, număr certificat de
urbanizare) cu condiţia ca obiectivele să nu fie la aceeaşi adresă ca şi
contractanţii.
29
1. Operatorul θ-JOIN în algebra relaţională:

R = PROJECT(CONTRACTANT, cod_contractant, banca);
S = PROJECT(OBIECTIV_INVESTITIE, denumire, nr_cert_urb);
Rezultat = JOIN(R, S, OBIECTIV_INVESTITIE.adresa <>
CONTRACTANT.adresa).
2. Opratorul θ-JOIN în SQL:
SELECT cod_contractant,banca, nr_cert_urb,
denumire
FROM contractant a,obiectiv_investitie b
WHERE b.adresa <> a.adresa;
Operatorul SEMI-JOIN
Operatorul SEMI-JOIN conservă atributele unei singure relaţii
participante la compunere şi este utilizat când nu sunt necesare toate
atributele compunerii. Operatorul este asimetric.
Tupluri ale relaţiei R care participă în compunerea (naturală sau
θ-JOIN) dintre relaţiile R şi S.
SEMI-JOIN este un operator derivat, fiind o combinaţie de proiecţie
şi compunere naturală sau proiecţie şi θ-JOIN:
SEMIJOIN(R, S) = ΠM (JOIN(R, S))
SEMIJOIN(R, S, condiţie) = Π M (JOIN(R, S, condiţie)),
unde am notat prin M atributele relaţiei R.
Exemplu. Să se obţină informaţii referitoare la persoanele fizice
(nume, buletin) care investesc în obiective cu caracter recreativ.
1. Operatorul SEMI-JOIN în algebra relaţională:
R = SELECT(OBIECTIV_INVESTITIE, denumire = ’cabana’ OR
denumire = ’casa de vacanta’)
S = JOIN(PERS_FIZICA, R)
Rezultat = PROJECT(S, nume, buletin).
2. Operatorul SEMI-JOIN în SQL:
SELECT nume,bi
FROM pers_fizica a,obiectiv_investitie b
WHERE a.cod_contractant = b.cod_contractant
AND (denumire=’cabana’)OR (denumire= ’casa
de vacanta’);
30
Operatorul OUTER JOIN

Operaţia de compunere externă combină tupluri din două relaţii
pentru care sunt satisfăcute condiţiile de corelare. În cazul aplicării
operatorului JOIN se pot pierde tupluri, atunci când există un tuplu în una
din relaţii pentru care nu există nici un tuplu în cealaltă relaţie, astfel încât
să fie satisfăcută relaţia de corelare.
Operatorul elimină acest inconvenient prin atribuirea valorii null
valorilor atributelor care există într-un tuplu din una dintre relaţiile de
intrare, dar care nu există şi în cea de-a doua relaţie.
Practic, se realizează compunerea a două relaţii R şi S la care se
adaugă tupluri din R şi S, care nu sunt conţinute în compunere, completate
cu valori null pentru atributele care lipsesc.
Compunerea externă poate fi: LEFT, RIGHT, FULL. De exemplu,
OUTER JOIN LEFT reprezintă compunerea în care tuplurile din R, care nu
au valori similare în coloanele comune cu relaţia S, sunt de asemenea
incluse în relaţia rezultat.
Exemplu. Să se obţină informaţii referitoare la persoanele fizice care
sunt investitori (chiar dacă nu au investit în obiective industriale) şi la
obiectivele de investiţie industriale (chiar şi cele care nu sunt construite de
persoane fizice).
R = SELECT(OBIECTIV_INVESTITIE, denumire = 'industrial')
Rezultat = OUTERJOIN(PERS_FIZICA, R).
Operatorii algebrei relaţionale pot fi reprezentaţi grafic cu ajutorul
unor simboluri speciale.  curs!
Operaţii adiţionale: complement, despicare, închidere tranzitivă.
Funcţii asociate: MIN, MAX, COUNT, AVG, SUM, VAR, STD etc.
31
Evaluarea şi optimizarea interogărilor

Procesarea interogărilor
O expresie a algebrei relaţionale este constituită din relaţii legate
prin operaţii din algebra relaţională. O expresie se poate reprezenta grafic
cu ajutorul unui arbore, numit arbore algebric, în care nodurile corespund
operatorilor din cadrul expresiei respective.
Evaluarea unei expresii presupune efectuarea prelucrărilor indicate
de operatorii din expresie în ordinea apariţiilor sau în ordinea fixată prin
paranteze. Rezultatul evaluării unei expresii este o relaţie derivată din
relaţiile menţionate ca operanzi în cadrul expresiei.
Două expresii sunt echivalente, dacă în urma evaluării lor se obţine
ca rezultat aceeaşi relaţie.
Exemple referitoare la moduri echivalente de exprimare a unei cereri

(vor fi rezolvate la curs!).
1. Informaţii despre salariaţii care nu contribuie la machetarea nici
unei publicaţii, dar au retribuţia mai mare decât o valoare dată.
2. Codul şi numele subantreprenorilor care au realizat lucrări
specializate la obiective case de vacanţă sau cabane.
3. Codurile şi telefoanele investitorilor, valoarea si durata de execuţie
a investitiilor a caror valoare este între două limite specificate.
4. Perioada de desfăşurare şi preţul ofertelor care încep după 1
ianuarie 2003 şi sunt:
• sejururi la munte;
• excursii în care autocarele sunt conduse de şoferi angajaţi după 1
mai 1987 şi supravegheate de ghizi ce cunosc limba engleză care
au făcut specializare în Suedia.
În majoritatea sistemelor de gestiune, şi în special în cele relaţionale,
interfaţa cu utilizatorul este de tip neprocedural. Utilizatorul defineşte datele
pe care doreşte să le vizualizeze fără a da algoritmii de acces. Sistemul
trebuie să convertească cererea utilizatorului:
• într-o cerere optimală;
• în proceduri de acces optimal la datele fizice.
Garantarea absolută a performanţelor optime pentru procesorul
limbajului relaţional este imposibilă. Corectă ar fi utilizarea cuvântului
„ameliorare“ în locul cuvântului „optimizare“.
32
Evaluarea unei interogări se efectuează în trei etape.

 Analiza cererii presupune studierea sintactică şi semantică a cererii
pentru a verifica corectitudinea sa şi a simplifica criteriul de
căutare.
 Ordonanţarea presupune descompunerea cererii într-o mulţime de
operaţii elementare şi determinarea unei ordini optimale a acestor
operaţii. Operaţiile sunt, în general, cele ale algebrei relaţionale. La
sfârşitul etapei se obţine un plan de execuţie pentru cerere.
 Execuţia presupune efectuarea (paralel şi/sau secvenţială)
operaţiilor elementare furnizate de planul de execuţie pentru a
obţine rezultatul cererii.
Presupunem că utilizatorul transmite sistemului de gestiune o cerere

exprimată prin ordine SQL. Pentru a răspunde cererii, SGBD-ul trebuie să
înţeleagă cererea utilizatorului. Cererea trebuie să fie corectă sintactic, datele
trebuie să fie disponibile utilizatorului şi trebuie localizate analizând diferite
drumuri de acces la ele. Aceste funcţii sunt realizate de SGBD cu ajutorul a
două module funcţionale care comunică permanent:
• analizorul cererilor, care asigură verificarea sintactică şi
semantică a cererii, localizarea datelor implicate în cerere (găsirea
adresei blocurilor ce conţin datele), furnizarea planului de execuţie.
• administratorul datelor (executorul), care execută efectiv cererea
(primeşte planurile de execuţie furnizate de modulul de optimizare
şi le execută). Execuţia presupune căutarea blocurilor ce conţin
datele şi transferul blocurilor în memoria cache.
Ideea generală:
cerere arbore algebric (nu este unic)  plan de executie  optimizare
Un plan de execuţie implică o secvenţă de paşi pentru evaluarea cererii
(în mod obişnuit, fiecare pas din planul de execuţie corespunde unei operaţii
relaţionale) precum şi metoda care va fi folosită pentru evaluarea operaţiei.
De obicei, pentru o operaţie relaţională dată, există mai multe metode ce pot
fi folosite pentru evaluarea acesteia.
Două planuri de execuţie diferite care au întotdeauna acelaşi rezultat se
numesc echivalente. Planuri de execuţie echivalente pot avea diferite
costuri. Scopul optimizării cererilor este de a găsi, printre diversele planuri
de execuţie echivalente, pe acela de cost minim. Într-un sistem centralizat,
costul evaluării unei cereri este suma a două componente, costul I/O
(transferuri de date) şi costul CPU (verificare de condiţii, operaţii join etc.).
33
Ordinea de execuţie a operaţiilor

O interogare constă dintr-un număr de operaţii. Ordinea în care se
efectuează operaţiile are un rol important în evaluarea costului necesar
realizării interogării.
Există două modalităţi de abordare pentru a determina ordinea de
execuţie a operaţiilor:
• algebric;
• bazat pe estimarea costului.
Ambele folosesc o mulţime de reguli care permit transformarea unui
plan de execuţie (reprezentat ca o expresie scrisă în termenii algebrei
relaţionale) în altul, echivalent.
Optimizarea cererilor bazată pe algebra relaţională se realizează în
două etape:
• se exprimă cererile sub forma unor expresii algebrice relaţionale;
• se aplică acestor expresii transformări algebrice care conduc la
expresii echivalente, dar care vor fi executate mai eficient.
Procesul de transformare a cererilor se realizează conform unei
strategii de optimizare care poate să fie:
• independentă de modul de memorare a datelor (strategie generală);
• dependentă de modul de memorare (strategie specifică unui anumit
SGBD).
Proprietăţile operatorilor algebrei relaţionale

Proprietatea 1. Comutativitatea operaţiilor de join şi produs cartezian:
JOIN(R1, R2) = JOIN(R2, R1)
R1 × R2 = R2 × R1
Proprietatea 2. Asociativitatea operaţiilor de join şi produs cartezian:

JOIN(JOIN(R1, R2), R3) = JOIN(R1, JOIN(R2, R3))
(R1 × R2) × R3 = R1 × (R2 × R3)
Proprietatea 3. Compunerea proiecţiilor:

ΠA1,...,Am (ΠB1,...,Bn (R)) = ΠA1,...,Am (R),
unde {A1, A2,...,Am } ⊆ {B1, B2,...,Bn }.
Proprietatea 4. Compunerea selecţiilor:

σcond1 (σcond2 (R)) = σcond1∧cond2 (R) = σ cond2 (σ cond1 (R)),
unde am notat prin cond condiţia după care se face selecţia.
34
Proprietatea 5. Comutarea selecţiei cu proiecţia:

ΠA1,...,Am (σcond (R)) = σcond (ΠA1,...,Am (R)),
unde condiţia după care se face selecţia implică numai atributele A1 ,...,Am.
Dacă condiţia implică şi atributele B1,...,Bn , care nu aparţin mulţimii
{A1,...,Am}, atunci:
ΠA1,...,Am (σcond (R)) = ΠA1,...,Am (σcond (ΠA1,...,Am,B1,...,Bn (R)))
Proprietatea 6. Comutarea selecţiei cu produsul cartezian:

Dacă toate atributele menţionate în condiţia după care se face selecţia
sunt atribute ale relaţiei R1, atunci:
σcond (R1 × R2) = σ cond (R1) × R2
Dacă condiţia este de forma cond1∧cond2 şi dacă cond1 implică
numai atribute din R1, iar cond2 implică numai atribute din R2, atunci
σcond (R1 × R2) = σ cond1 (R1) × σcond2 (R2)
Dacă cond1 implică numai atribute din R1, iar cond2 implică atribute
atât din R1 cât şi din R2, atunci:
σcond (R1 × R2) = σ cond2 (σcond1 (R1) × R2)
Proprietatea 7. Comutarea selecţiei cu reuniunea:

σcond (R1 ∪ R2) = σcond (R1) ∪ σ cond (R2)
Proprietatea 8. Comutarea selecţiei cu diferenţa:

σcond (R1 – R2) = σcond (R1) – σcond (R2)
Proprietatea 9. Comutarea proiecţiei cu reuniunea:

ΠA1,...,Am (R1 ∪ R2) = ΠA1,...,Am (R1) ∪ ΠA1,...,Am (R2)
Proprietatea 10. Comutarea proiecţiei cu produsul cartezian:
Dacă A1,...,Am este o listă de atribute ce apar în schemele relaţionale
R1 şi R2 şi dacă lista este formată din atribute aparţinând lui R1 (notate prin
B1,...,Bn ) şi din atribute aparţinând lui R2 (notate prin C1 ,...,Ck ) atunci:
ΠA1,...,Am (R1 × R2) = Π B1,...,Bn (R1) × ΠC1,...,Ck (R2)
Proprietatea 11. Compunerea proiecţiei cu operaţia join:

Dacă A1,...,Am este o listă de atribute ce apar în schemele relaţionale
R1 şi R2 şi dacă lista este formată din atribute aparţinând lui R1 (notate prin
B1,...,Bn ) şi din atribute aparţinând lui R2 (notate prin C1 ,...,Ck ) atunci:
ΠA1,...,Am (JOIN(R1,R2,D)) = ΠA1,...,Am (JOIN(ΠD,B1,...,Bn(R1), Π D,C1,...,Ck(R2),D),
unde am notat prin JOIN(R1, R2, D) operaţia de compunere naturală între R1
şi R2 după atributul comun D.
35
Proprietatea 12. Compunerea selecţiei cu operaţia join:

σcond (JOIN (R1, R2, D)) = σcond (JOIN (Π D,A (R1), ΠD,A (R2), D)),
unde A reprezintă atributele care apar în condiţia după care se face selecţia.
Reguli de optimizare frecvent folosite:

Regula de optimizare 1. Selecţiile se execută cât mai devreme
posibil. Motivaţia acestei reguli este că selecţiile reduc substanţial
dimensiunea relaţiilor. Regula de transformare 4 poate fi folosită
pentru a separa două sau mai multe selecţii în selecţii individuale
care pot fi distribuite join-ului sau produsului cartezian folosind
comutarea selecţiei cu join-ul.
Regula de optimizare 2. Produsurile carteziene se înlocuiesc cu join-
uri, ori de câte ori este posibil. Un produs cartezian între două relaţii
este de obicei mult mai scump (ca şi cost) decât un join între cele
două relaţii, deoarece primul generează concatenarea tuplurilor în
mod exhaustiv şi poate genera un rezultat foarte mare. Această
transformare se poate realiza folosind legătura dintre produs
cartezian, join şi selecţie.
Regula de optimizare 3. Dacă sunt mai multe join-uri atunci cel care
se execută primul este cel mai restrictiv. Un join este mai restrictiv
decât altul dacă produce o relaţie mai mică. Se poate determina care
join este mai restrictiv pe baza factorului de selectivitate sau cu
ajutorul informaţiilor statistice. Algebric, acest lucru se poate realiza
folosind regula de transformare 2.
Regula de optimizare 4. Proiecţiile se execută la început pentru a
îndepărta atributele nefolositoare. Dacă un atribut al unei relaţii nu
este folosit în operaţiile ulterioare atunci trebuie îndepărtat. În felul
acesta se va folosi o relaţie mai mică în operaţiile ulterioare. Aceasta
se poate realiza folosind comutarea proiecţiei cu join-ul.
Exemple curs!!!
36
Regulile lui Codd

Caracteristici ale modelului relaţional:
• nu există tupluri identice;
• ordinea liniilor şi a coloanelor este arbitrară;
• articolele unui domeniu sunt omogene;
• fiecare coloană defineşte un domeniu distinct şi nu se poate repeta în
cadrul aceleiaşi relaţii;
• toate valorile unui domeniu corespunzătoare tuturor cazurilor nu mai
pot fi descompuse în alte valori (sunt atomice).
Avantajele modelului relaţional:

• fundamentare matematică riguroasă;
• independenţă fizică a datelor;
• posibilitatea filtrărilor;
• existenţa unor structuri de date simple;
• realizarea unei redundanţe minime;
• supleţe în comunicarea cu utilizatorul neinformatician.
Ca limite ale modelului relaţional putem menţiona:

• rămâne totuşi redundanţă,
• ocupă spaţiu,
• apar fenomene de inconsistenţă,
• nu există mecanisme pentru tratarea optimă a cererilor recursive,
• nu lucrează cu obiecte complexe,
• nu există mijloace perfecţionate pentru exprimarea constrângerilor de
integritate,
• nu realizează gestiunea totala a datelor distribuite,
• nu realizează gestiunea cunoştinţelor.
În anul 1985, E.F. Codd a publicat un set de 13 reguli în raport cu

care un sistem de gestiune a bazelor de date poate fi apreciat ca relaţional.
Nici un sistem de gestiune a bazelor de date pus în vânzare pe piaţa
comercială nu respectă absolut toate regulile definite de Codd, dar acest
lucru nu împiedică etichetarea acestor sisteme drept relaţionale.
37
Nu trebuie apreciat un SGBD ca fiind relaţional sau nu, ci măsura în

care acesta este relaţional, deci numărul regulilor lui Codd pe care le
respectă.
Regula 1 – regula gestionării datelor. Un SGBD relaţional trebuie să
fie capabil să gestioneze o bază de date numai prin posibilităţile sale
relaţionale.
Regula 2 – regula reprezentării informaţiei. Într-o bază de date
relaţională, informaţia este reprezentată la nivel logic sub forma unor
tabele ce poartă numele de relaţii.
Regula 3 – regula accesului garantat la date. Fiecare valoare dintr-o
bază de date relaţională trebuie să poată fi adresată în mod logic printr-o
combinaţie formată din numele relaţiei, valoarea cheii primare şi numele
atributului.
Regula 4 – regula reprezentării informaţiei necunoscute. Un sistem
relaţional trebuie să permită utilizatorului definirea unui tip de date numit
„null“ pentru reprezentarea unei informaţii necunoscute la momentul
respectiv.
Regula 5 – regula dicţionarelor de date. Asupra descrierii bazelor de
date (informaţii relative la relaţii, vizualizări, indecşi etc.) trebuie să se
poată aplica aceleaşi operaţii ca şi asupra datelor din baza de date.
Regula 6 – regula limbajului de interogare. Trebuie să existe cel
puţin un limbaj pentru prelucrarea bazei de date.
Regula 7 – regula de actualizare a vizualizării. Un SGBD trebuie să
poată determina dacă o vizualizare poate fi actualizată şi să stocheze
rezultatul interogării într-un dicţionar de tipul unui catalog de sistem.
Regula 8 – regula limbajului de nivel înalt. Regulile de prelucrare
asupra unei relaţii luată ca întreg sunt valabile atât pentru operaţiile de
regăsire a datelor, cât şi asupra operaţiilor de inserare, actualizare şi
ştergere a datelor.
Regula 9 – regula independenţei fizice a datelor: Programele de
aplicaţie şi activităţile utilizatorilor nu depind de modul de depunere a
datelor sau de modul de acces la date.
Regula 10 – regula independenţei logice a datelor. Programele de
aplicaţie trebuie să fie transparente la modificările de orice tip efectuate
asupra datelor.
Regula 11 – regula independenţei datelor din punct de vedere al
integrităţii. Regulile de integritate trebuie să fie definite într-un sublimbaj
relaţional, nu în programul de aplicaţie.
38

distribuirii. Distribuirea datelor pe mai multe calculatoare dintr-o reţea de
comunicaţii de date, nu trebuie să afecteze programele de aplicaţie.
Regula 13 – regula versiunii procedurale a unui SGBD. Orice
componentă procedurală a unui SGBD trebuie să respecte aceleaşi
restricţii de integritate ca şi componenta relaţională.
Deoarece regulile lui Codd sunt prea severe pentru a fi respectate de
un SGBD operaţional, s-au formulat criterii minimale de definire a unui
sistem de gestiune relaţional.
Un SGBD este minimal relaţional dacă:
• toate datele din cadrul bazei sunt reprezentate prin valori în tabele;
• nu există pointeri observabili de către utilizator;
• sistemul suportă operatorii relaţionali de proiecţie, selecţie şi
compunere naturală, fără limitări impuse din considerente interne.
Un SGBD este complet relaţional dacă este minimal relaţional şi
satisface în plus condiţiile:
• sistemul suportă restricţiile de integritate de bază (unicitatea cheii
primare, constrângerile referenţiale, integritatea entităţii).
• sistemul suportă toate operaţiile de bază ale algebrei relaţionale.
NORMALIZAREA RELAŢIILOR
În procesul modelării unei baze de date relaţionale, o etapă importantă
o reprezintă normalizarea relaţiilor conceptuale (Codd, 1972), adică
obţinerea de relaţii „moleculare“fără a pierde nimic din informaţie pentru a
elimina:
• redundanţa;
• anomaliile reactualizării informaţiilor.
Tehnica normalizării permite obţinerea unei scheme conceptuale
rafinate printr-un proces de ameliorare progresivă a unei scheme conceptuale
iniţiale a bazei de date relaţionale. După fiecare etapă de ameliorare, relaţiile
bazei de date ating un anumit grad de perfecţiune, deci se află într-o anumită
formă normală. Trecerea unei relaţii dintr-o formă normală în alta, presupune
eliminarea unei anumit tip de dependenţe nedorite, care sunt transformate în
dependenţe admisibile, adică dependenţe care nu provoacă anomalii.
39
Procesul de ameliorare a schemei conceptuale trebuie:

• să garanteze conservarea datelor, adică în schema conceptuală
finală trebuie să figureze toate datele din cadrul schemei iniţiale;
• să garanteze conservarea dependenţelor dintre date, adică în
schema finală fiecare dependenţă trebuie să aibă determinantul şi
determinatul în schema aceleiaşi relaţii;
• să reprezinte o descompunere minimală a relaţiilor iniţiale,
adică nici una din relaţiile care compun schema finală nu trebuie
să fie conţinută într-o altă relaţie din această schemă.
Există două metode pentru a modela baze de date relaţionale fără
anomalii sau pierderi de informaţie.
• Schema descompunerii pleacă de la o schemă relaţională
universală ce conţine toate atributele BD. Schema se descompune
prin proiecţii succesive în subrelaţii. Descompunerea se opreşte
când continuarea ei ar duce la pierderi de informaţie. Algoritmii
de descompunere se bazează, în general, pe descrierea formală a
dependenţei dintre atribute.
• Schema sintezei pleacă de la o mulţime de atribute
independente. Utilizând proprietăţi de semantică şi legături între
atribute se pot compune noi relaţii, astfel încât, acestea să nu
sufere de anumite anomalii. Algoritmii se bazează, în general, pe
teoria grafurilor pentru a reprezenta legătura între atribute.
Dependenţe funcţionale
O relaţie universală este o relaţie ce grupează toate atributele care
modelează sistemul real cercetat. Fie E, mulţimea dependenţelor
considerate de proiectantul bazei pentru o schemă relaţională sau pentru o
relaţie universală. Plecând de la o mulţime de proprietăţi formale ale
dependenţelor, proprietăţi considerate drept reguli de deducţie (axiome),
poate fi obţinută mulţimea maximală de dependenţe asociate lui E. Această
mulţime defineşte închiderea lui E.
Fie E mulţimea dependenţelor unei relaţii şi p 1, p 2, ..., p r, r ≥ 1,
proprietăţi formale ale acestor dependenţe. Dacă există o mulţime E′, astfel
încât orice dependenţă a mulţimii E este derivabilă din E′ prin aplicarea
proprietăţilor p 1, p2 , ..., pr , atunci mulţimea E′ defineşte acoperirea lui E
pentru proprietăţile p1 , p 2, ..., p r.
E′ este o acoperire minimală pentru E, dacă nu există nici o
submulţime proprie, nevidă a lui E′ care să fie o acoperire pentru E.
40
Evident, E şi E′ au închideri identice, deci dispun de acelaşi potenţial

informaţional!
Fie R(A1 , A2 , ..., An ) o schemă relaţională şi fie X, Y submulţimi de
atribute ale lui R. X determină funcţional Y sau Y depinde funcţional (FD)
de X, dacă pentru orice relaţie r (valoare curentă a lui R) nu există două
tupluri care să aibă aceleaşi valori pentru atributele lui X şi să aibă valori
diferite pentru cel puţin un atribut din Y. Cu alte cuvinte, o valoare a lui X,
determină unic o valoare a lui Y.
Notaţia utilizată pentru desemnarea dependenţei funcţionale este X
→ Y. X este numit determinant, iar Y este numit determinat (sau
dependent). Dependenţa funcţională X → Y este trivială dacă Y ⊆ X.
Comparând toate submulţimile de atribute ale unei relaţii şi
determinând legăturile dintre ele, se pot obţine toate dependenţele
funcţionale pe care o relaţie le satisface. Această abordare nu este eficientă,
consumând mult timp.
Există posibilitatea ca, ştiind anumite dependenţe funcţionale şi
utilizând reguli de deducţie, să fie obţinute toate dependenţele funcţionale.
Fie X, Y, Z, W mulţimi de atribute ale unei scheme relaţionale R şi fie
următoarele axiome:
Ax1 – reflexivitate. X → X. Mai general, dacă Y ⊆ X, atunci X → Y.
Ax2 – creşterea determinantului. Pot fi considerate următoarele
formulări echivalente pentru această axiomă.
1. Dacă X → Y şi X ⊆ Z, atunci Z → Y.
2. Dacă X → Y şi W ⊆ Z, atunci X ∪ Z → Y ∪ W.
3. Dacă X → Y atunci X ∪ Z → Y ∪ Z.
4. Dacă X → Y atunci X ∪ Z → Y.
Ax3 – tranzitivitate. Dacă X → Y şi Y → Z, atunci X → Z.
O mulţime de axiome este completă dacă şi numai dacă plecând de
la o mulţime de dependenţe E se pot obţine toate dependenţele închiderii
lui E, utilizând axiomele mulţimii.
O mulţime de axiome este închisă dacă şi numai dacă plecând de la
o mulţime de dependenţe E, nu poate fi dedusă cu ajutorul axiomelor o
dependenţă care nu aparţine închiderii lui E. (nu obţin altele!)
Ullman a demonstrat că axiomele Ax1 – Ax3, numite axiomele lui
Amstrong, reprezintă o mulţime închisă şi completă de axiome. Consecinţa
41
acestui rezultat este că închiderea lui E reprezintă mulţimea

dependenţelor deduse din E, prin aplicarea axiomelor lui Amstrong!!!
Nu toate dependenţele funcţionale sunt folositoare pentru modelarea
relaţională. O dependenţă funcţională X → Y se numeşte dependenţă
funcţională totală (FT), dacă şi numai dacă nu există nici o submulţime
proprie X′ ⊂ X, astfel încât X′ → Y. Dacă există o submulţime proprie X′ ⊂
X, astfel încât X′ → Y, atunci dependenţa funcţională X → Y este parţială.
În axioma Ax2, dependenţa Z → Y este o dependenţă funcţională parţială.
În cazul dependenţei funcţionale totale, axiomele lui Amstrong se
reduc la o axiomă unică şi anume pseudo-tranzitivitatea:
dacă X → Y şi W ∪ Y → Z, atunci W ∪ X → Z.
Această axiomă este o regulă de deducţie completă pentru total
dependenţe:
• pseudo-tranzitivitatea implică tranzitivitatea (W = ∅);
• reflexivitatea nu poate fi utilizată pentru a obţine dependenţe
totale;
• reflexivitatea şi pseudo-tranzitivitatea implică creşterea.
Dacă F este o mulţime de dependenţe funcţionale totale, atunci
închiderea pseudo-tranzitivă F+ a acestei mulţimi este reuniunea
mulţimilor dependenţelor funcţionale totale care pot fi obţinute din F
folosind axioma de pseudo-tranzitivitate.
Două mulţimi de dependenţe funcţionale totale sunt echivalente
dacă au închideri pseudo-tranzitive identice. Pentru a modela scheme
relaţionale se consideră mulţimi minimale de dependenţe funcţionale totale,
capabile să genereze toate închiderile pseudo-tranzitive. Aceste mulţimi
definesc acoperiri minimale.
O mulţime de dependenţe funcţionale totale F* asociată unei mulţimi
de atribute A defineşte o acoperire minimală dacă satisface următoarele
proprietăţi:
• nici o dependenţă funcţională din F* nu este redundantă;
• toate dependenţele funcţionale totale între submulţimi ale lui A
sunt în închiderea pseudo-tranzitivă a lui F*.
Orice mulţime de dependenţe totale are cel puţin o acoperire minimală.
Alegerea acoperirii minimale este punctul de start în modelarea schemelor
relaţionale.
42
Dependenţele funcţionale între atributele bazei pot fi reprezentate

grafic. Fie A = {A1 , A2, ..., An } o mulţime de atribute şi fie o mulţime de
dependenţe funcţionale {Xi → Aj}, unde Xi este o submulţime a lui A.
Graful dependenţelor funcţionale este un graf direcţionat bipartit,
definit astfel:
1. pentru fiecare atribut A j există un singur nod având eticheta A j ;
2. pentru fiecare dependenţă funcţională de forma A i → A j, există
un arc de la Ai la Aj;
3. pentru fiecare dependenţă funcţională de forma X i → A j, unde
mulţimea Xi este definită de X i = {Ai 1 , ..., Ai p } cu p > 1, există un
nod auxiliar etichetat prin Xi şi o mulţime de arce plecând de la
Ai1 , ..., Ai p pentru a obţine pe Xi şi printr-un arc adiţional de la Xi la
Aj. Nodurile Xi se reprezintă prin dreptunghiuri.
Exemplu:
1. Graful dependenţelor funcţionale pentru schema relaţională
CONSUMATOR_DE_VIN(W#, localitate, varsta, calitate, regiune, tara, D#,
nume, data, cantitate) şi acoperirea minimală.
localitate
W#
calitate
varsta
regiune
tara
data cantitate
D#
nume
localitate
W#
calitate
varsta
43
regiune
tara
data cantitate
D#
nume
2. Graful dependenţelor funcţionale pentru schema relaţională
OBIECTIV_INVESTITIE. Dependentele sunt deduse din regulile impuse de
beneficiar!
aria_construita
denumire
nr_certificat_urbanizare
cod_obiectiv# adresa
nr_aut_construtie
nr_contract cod_contractant
Necesitatea normalizării
Anomaliile care apar în lucrul cu baza de date se produc datorită

dependenţelor care există între datele din cadrul relaţiilor bazei de date.
Dependenţele sunt plasate greşit în tabele!!!
Avion
A# nume capacitate localitate
1 AIRBUS 250 PARIS
2 AIRBUS 250 PARIS
3 AIRBUS 250 LONDRA
4 CAR 100 PARIS
5 B707 150 LONDRA
6 B707 150 LONDRA
Constrângere:
toate avioanele cu acelaşi nume au aceeaşi capacitate.
Datorită dependenţei introduse pot exista: anomalii la inserare,
modificare sau ştergere, redundanţă în date, probleme de reconexiune.
44
1. Redundanţă logică. Cuplul (AIRBUS, 250) apare de trei ori.

2. Anomalie la inserţie. S-a cumpărat un B727 cu 150 locuri. El
poate fi inserat în relaţia AVION doar dacă se defineşte o nouă
valoare pentru cheia primară.
3. Anomalie la ştergere. Dacă este ştearsă înregistrarea pentru care
A# este 4, atunci se pierde informaţia că un avion CAR are
capacitatea 100.
4. Anomalie la modificare. Dacă se modifică capacitatea lui B707
de la 150 la 170, atunci costul modificării este mare pentru a
modifica toate înregistrările, iar dacă se modifică doar o
înregistrare atunci constrângerea nu va mai fi verificată.
5. Problema reconexiunii. Considerăm schemele relaţionale:
AVION1 = PROJECT(AVION, A#, nume)
AVION22 = PROJECT(AVION, nume, capacitate, localitate)
AVION3 = JOIN(AVION1, AVION2).
Se observă că schema AVION3 este diferită de AVION.
Apare un tuplu nou: (3, AIRBUS, 250, PARIS).
Anomaliile au apărut datorită dependenţei funcţionale (constrângerii)

introduse anterior!!!
Normalizarea are drept scop:
• suprimarea redundanţei logice,
• evitarea anomaliilor la reactualizare,
• rezolvarea problemei reconexiunii.
Există o teorie matematică a normalizării al cărei autor este E.F.
Codd. Soluţia: construirea unor tabele standard (forme normale).
Normalizarea este procesul reversibil de transformare a unei relaţii, în
relaţii de structură mai simplă. Procesul este reversibil în sensul că nici o
informaţie nu este pierdută în timpul transformării. O relaţie este într-o formă
normală particulară dacă ea satisface o mulţime specificată de constrângeri.
Procesul normalizării se realizează plecând de la o relaţie universală ce
conţine toate atributele sistemului de modelat, plus o mulţime de anomalii.
Orice formă normală se obţine aplicând o schemă de descompunere. Există
două tipuri de descompuneri.
• Descompuneri ce conservă dependenţele. Această
descompunere presupune desfacerea relaţiei R în proiecţiile R 1 ,
R2 , ..., Rk , astfel încât dependenţele lui R sunt echivalente (au
45
închideri pseudo-tranzitive identice) cu reuniunea dependenţelor

lui R1 , R 2 , ..., Rk .
• Descompuneri fără pierderi de informaţie (L-join). Această
descompunere presupune desfacerea relaţiei R într-o mulţime de
proiecţii R1 , R2 , ..., Rj, astfel încât pentru orice realizare a lui R
este adevărată relaţia:
R = JOIN(ΠB1 (R), ΠB2 (R), ...,ΠBj (R))
unde, pentru 1 ≤ k ≤ j, B k reprezintă mulţimea atributelor corespunzătoare
proiecţiei R k (Rk = Π Bk (R)). Prin urmare, relaţia iniţială poate fi
reconstruită considerând compunerea naturală a relaţiilor obţinute prin
descompunere. Formele normale sunt obţinute prin descompuneri fără
pierderi de informaţie.
O descompunere fără pierdere de informaţie, utilizată în procesul
normalizării, este dată de regula Casey-Delobel:
Fie R(A) o schemă relaţională şi fie α, β, γ o partiţie a lui A.
Presupunem că α determină funcţional pe β. Atunci:
R(A) = JOIN(Π α∪β(R), Π α∪γ (R)).
α∪β  mulţimea atributelor care intervin în dependenţele funcţionale;
α∪γ  reprezintă reuniunea determinantului cu restul atributelor lui A.
Relatia universala
FN1
FN2
FN3
BCNF
FN4
FN5
Pentru exemplul analizat anterior:

α = {nume},
β = {capacitate},
γ = {A#, localitate}.
Aplicând Casey-Delobel se obţin schemele:
AVION1(nume#, capacitate)
AVION2)A#, nume, localitate).
46
Se observă că anomaliile comentate au dispărut!

AVION1
Nume Capacitate
AIRBUS 150
CAR 100
B707 150
AVION2
A# Nume Localitate
1 AIRBUS PARIS
2 AIRBUS PARIS
3 AIRBUS LONDRA
4 CAR PARIS
5 B707 LONDRA
6 B707 LONDRA
Forma normală (FN1)

O relaţie este în prima formă normală dacă fiecărui atribut care o
compune îi corespunde o valoare indivizibilă (atomică).
Exemplu: variante pentru a implementa FN1 pentru tabelul MASINA:
Persoana Vehicul
Eu R25 - W14 - R21
Tu 205
El R5 - 305
noi BX - 305 - R12 - R25
Varianta 1
Persoana Vehicul
Eu R25
Eu W14
Eu R21
Tu 205
El R5
El 305
Noi BX
Noi 305
Noi R12
Noi R25
47
Varianta 2
Persoana Prima Doi Trei Patru
Eu R25 W14 R21
Tu 205
El R5 305
Noi BX 305 R12 R25
Varianta 3 (4 tabele)
Masina 31 (similar se definesc Masina_32, Masina_33, Masina_34)..
Persoana Vehicul
Eu R25
Tu 205
El R5
Noi BX
Masina_34
Persoana Vehicul
Noi R25
Forma normală 2 (FN2)

O relaţie R este în a doua formă normală dacă şi numai dacă:
• relaţia R este în FN1;
• fiecare atribut care nu este cheie (nu participă la cheia primară)
este dependent de întreaga cheie primară.
atasat_la
Cod_salariat# Job_cod Nr_proiect# Functia Suma
S1 Programator P1 Supervizor 60
S1 Programator P2 Cercetator 25
S1 Programator P3 Auxiliar 10
S3 Vanzator P3 Supervizor 60
S5 Inginer P3 Supervizor 60
atasat_2a
Cod_salariat# Nr_proiect# Functia Suma
S1 P1 Supervizor 60
S1 P2 Cercetator 25
S1 P3 Auxiliar 10
S3 P3 Supervizor 60
48
S5 P3 Supervizor 60
atasat_2b
Cod_salariat# Job_cod
S1 Programator
S3 Vanzator
S5 Inginer
A doua condiţie exprimă necesitatea total dependenţei de cheia

primară. Această formă normală interzice manifestarea unor dependenţe
funcţionale parţiale în cadrul relaţiei R!!!
Pentru a obţine o relaţie FN2 se poate aplica regula Casey-Delobel.
Fie relaţia R(K1, K2, X, Y), unde K1 şi K2 definesc cheia primară, iar X şi Y
sunt mulţimi de atribute, astfel încât K1 → X. Din cauza dependenţei
funcţionale K1 → X care arată că R nu este în FN2, se înlocuieşte R (fără
pierdere de informaţie) prin două proiecţii R1(K1, K2, Y) şi R2(K1, X).
K1 K2
Exemplu. Presupunem că un şantier poate executa mai multe lucrări

de bază şi că o lucrare poate fi executată de mai multe şantiere.
LUCRARE(cod_obiectiv#, cod_lucrare#, nume);
EXECUTA(cod_obiectiv#, cod_lucrare#, nr_santier#, descriere,
functie, conducator, data_inceput, data_sfarsit).
Pentru relaţia EXECUTA sunt evidente dependenţele:
{cod_obiectiv#, cod_lucrare#} → {data_inceput, data_sfarsit},
{cod_obiectiv#, cod_lucrare#, nr_santier#} → {descriere, functie,
conducator}.
49
Relaţia EXECUTA este în FN1, dar nu este în FN2 deoarece

atributele data_inceput şi data_sfarsit nu depind de numărul şantierului,
deci nu depind de întreaga cheie primară. Pentru a obţine o relaţie în FN2
se aplică regula Casey Delobel şi relaţia EXECUTA se desface în:
EXECUTA_1(cod_obiectiv#, cod_lucrare#, nr_santier#, descriere,
functie, conducator)
EXECUTA_2(cod_obiectiv#, cod_lucrare#, data_inceput,
data_sfarsit).
Intuitiv, o relaţie R este în a treia formă normală dacă şi numai dacă:
• fiecare atribut care nu este cheie (nu participă la o cheie) depinde
direct de cheia primară.
Fie R o relaţie, X o submulţime de atribute ale lui R şi A un atribut al
relaţiei R. A este dependent tranzitiv de X dacă există Y astfel încât X → Y
şi Y → A (A nu aparţine lui Y şi Y nu determină pe X). X nu este dependent
funcţional de Y sau A!
De exemplu, dacă K 1 , K 2 , K 3 → A1 şi dacă K 1 , K 2 , A1 → A2 , atunci
K 1 , K 2 , K 3 → K 1 , K 2 , A1 şi K 1 , K 2 , A 1 → A2 . Prin urmare, A2 este
dependent tranzitiv de K 1 , K 2 , K 3 .
Formal, o relaţie R este în a treia formă normală dacă şi numai dacă:
• fiecare atribut care nu este cheie (nu participă la o cheie) nu este
dependent tranzitiv de nici o cheie a lui R.
O relaţie este în FN3 dacă şi numai dacă fiecare atribut (coloană)
care nu este cheie, depinde de cheie, de întreaga cheie şi numai de cheie.
Fie relaţia R(K, X1 , X2 , X3 ), unde atributul X2 depinde tranzitiv de K,
iar K este cheia primară a lui R. Presupunem că K → X1 → X 2 . Din cauza
dependenţei funcţionale X 1 → X 2 care arată că R nu este în FN3, se
înlocuieşte R (fără pierdere de informaţie) prin două proiecţii R1(K, X1 , X 3 )
şi R2(X 1 , X2 ).
K X1 X2
X3
50
Exemplu: Tabelul atasat_2a nu este in FN3. De ce?

atasat_3a
Cod_salariat# Nr_proiect# Functia
S1 P1 Supervizor
S1 P2 Cercetator
S1 P3 Auxiliar
S3 P3 Supervizor
S5 P3 Supervizor
atasat_3b
Functia Suma
Supervizor 60
Cercetator 25
Auxiliar 10
Exemplu. În tabelul EXECUTA1(cod_obiectiv#, cod_lucrare#,
nr_santier#, descriere, functie, conducator) continuă să existe redundanţă în
date.
Atributul conducator depinde indirect de cheia primară prin
intermediul atributului functie. Între atributele relaţiei există dependenţele:
{cod_obiectiv#, cod_lucrare#, nr_santier#} → {descriere},
{cod_obiectiv#, cod_lucrare#, nr_santier#} → {functie} → {conducator}.
Pentru a aduce relaţia EXECUTA_1 în FN3 se aplică regula Casey-
Delobel. Relaţia se desface, prin eliminarea dependenţelor funcţionale
tranzitive, în proiecţiile:
EXECUTA11(cod_obiectiv#, cod_lucrare#, nr_santier#, descriere, functie)
EXECUTA12(functie, conducator).
Schema de sinteză pentru obţinerea lui FN3

Algoritmul de sinteză construieşte o acoperire minimală F a
dependenţelor funcţionale totale. Se elimină atributele şi dependenţele
funcţionale redundante. Mulţimea F este partiţionată în grupuri Fi , astfel
încât în fiecare grup Fi sunt dependenţe funcţionale care au acelaşi membru
stâng şi nu există două grupuri având acelaşi membru stâng. Fiecare grup
Fi produce o schemă FN3. Algoritmul realizează o descompunere ce
conservă dependenţele.
Algoritm SNF3 (aducerea unei relaţii în FN3 prin utilizarea unei
scheme de sinteză):
51
1. Se determină F o acoperire minimală a lui E (mulţimea

dependenţelor funcţionale).
2. Se descompune mulţimea F în grupuri notate Fi , astfel încât în
cadrul fiecărui grup să existe dependenţe funcţionale având
aceeaşi parte stângă.
3. Se determină perechile de chei echivalente (X, Y) în raport cu F
(două mulţimi de atribute X, Y sunt chei echivalente dacă în
mulţimea de dependenţe E există atât dependenţa X Y, cât şi
dependenta Y  X).
4. Pentru fiecare pereche de chei echivalente: se identifică grupurile
Fi şi F j care conţin dependenţele funcţionale cu partea stângă X şi
respectiv Y; se formează un nou grup de dependenţe Fi j, care va
conţine dependenţele funcţionale având membrul stâng (X, Y); se
elimină grupurile Fi şi Fj , iar locul lor va fi luat de grupul Fi j.
5. Se determină o acoperire minimală a lui F, care va include toate
dependenţele X → Y, unde X şi Y sunt chei echivalente (celelalte
dependenţe sunt redundante).
6. Se construiesc relaţii FN3 (câte o relaţie pentru fiecare grup de
dependenţe funcţionale).
Se observă că algoritmul solicită

• determinarea unei acoperiri minimale (algoritmii EAR şi EDF);
• determinarea închiderii (A + ) unei mulţimi de atribute A în raport
cu mulţimea de dependenţe funcţionale E (algoritm AIDF).
Determinarea acoperirii minimale presupune eliminarea atributelor şi
dependenţelor redundante. Acoperirea minimală nu este unică şi depinde de
ordinea în care sunt eliminate aceste atribute şi dependenţe redundante.
Algoritm EAR (elimină atributele redundante din determinantul

dependenţelor funcţionale)
Pentru fiecare dependenţă funcţională din E şi pentru fiecare atribut
din partea stângă a unei dependenţe funcţionale:
Pas1. Se elimină atributul considerat.
Pas2. Se calculează închiderea părţii stângi reduse.
Pas3. Dacă închiderea conţine toate atributele din determinantul
dependenţei, atunci atributul eliminat la pasul 1 este redundant şi rămâne
eliminat. În caz contrar, atributul nu este redundant şi se reintroduce în
partea stângă a dependenţei funcţionale.
52
Algoritm EDF (elimină dependenţele funcţionale redundante din E)

Pentru fiecare dependenţă funcţională X Y din E:
Pas1. Se elimină dependenţa din E.
Pas2. Se calculează închiderea X + , în raport cu mulţimea redusă de
dependenţe.
Pas3. Dacă Y este inclus în X + , atunci dependenţa X Y este
redundantă şi rămâne eliminată. În caz contrar, se reintroduce în E.
Algoritm AIDF (determină închiderea lui A)

Pas1. Se caută dacă există în E dependenţe X Y pentru care
determinantul X este o submulţime a lui A, iar determinatul Y nu este
inclus în A.
Pas2. Pentru fiecare astfel de dependenţă funcţională se adaugă
mulţimii A atributele care constituie determinatul dependenţei.
Pas3. Dacă nu mai există dependenţe funcţionale de tipul de la pasul
1, atunci A + = A.
Exemplu:
Fie dependenţele funcţionale:
f1: F  N; f2: F  P; f3: P, F, N  U;
F4: P  C; f5: P  T; f6: C  T; f7: N  F.
Pas1 (suprimarea atributelor redundante). Atributul A i este

redundant în dependenţa funcţională A 1, A 2 , …A i , …A n  Z, dacă
dependenţa funcţională A 1, A 2 , …A i − 1 , A i + 1 …A n  Z poate fi
generată plecând de la mulţimea iniţială de dependenţe (E) şi de la
axiomele considerate.
f1: F  N; f3: P, F, N  U sau N, P, F  U;
Aplicând axioma de pseudotranzitivitate se obţine:
F, P, F  U  P, F  U
Pas2 (suprimarea dependenţelor funcţionale redundante).

Dependenţa funcţională f este redundantă în E dacă E + = (E - f) + , unde E +
reprezintă închiderea lui E.
Se observă că f5 este redundantă (poate fi obţinută din f4 şi f6). La
sfârşitul etapei se obţine:
f1: F  N; f2: F  P; f3: P, F  U; P este redundant =>F-->U
53
f4: P  C; f6: C  T; f7: N  F.
Pas3 (gruparea dependenţelor având acelaşi membru stâng).

F1 = {f1, f2, f3}; F2 = {f4}; F3 = {f6}; F4 = {f7}
Pas4 (regruparea mulţimilor F i si F j dacă există dependenţe de

forma X  Y şi Y  X, unde X reprezinta partea stanga a dependenţei lui
F i şi Y este partea stângă a dependenţei lui F j .
Din F1 şi F4 se obţine:
G1 = {f1, f2, f3, f7}; G2 = {f4}; G3 = {f6}.
Pas5 (generarea relaţiilor FN3).
R1(F#, N, P, U); R2(P#, C); R3(C#, T).
De remarcat: R1 nu este in BCNF! De ce? Exista dependenta N -->F.
Exerciţiu:
Presupunem că o parte din activităţiile de pe un aeroport sunt
caracterizate de atributele:
A -- număr zbor;
B -- tip avion;
C -- aeroport plecare;
D -- aeroport sosire;
E -- linia aeriană;
F -- ora plecării;
G -- capacitate;
H -- număr locuri rezervate;
I -- data;
J -- tarif;
K -- prestaţii la bord.
Între aceste atribute există legături exprimate prin dependenţele:
A  BEFG
ACDI  H
CD  J
CDF  K
BG
CF  ABE
AC  D
ABD  C
EG  B
54
Aplicând algoritmul de sinteză se obţin relaţiile:

R1(B#, G)
R2(E#, G#, B)
R3(A#, B, E, F)
R4(C#, D#, J)
R5(A#, C#, I#, H)
R6(A, C, D, F, K) în care cheile primare pot să fie oricare dintre:
AD sau AC sau CF.
Încercaţi să justificaţi acest rezultat!!!
Forma normală Boyce-Codd (BCNF)
Determinantul este un atribut sau o mulţime de atribute
neredundante, care constituie un identificator unic pentru alt atribut sau altă
mulţime de atribute ale unei relaţii date.
Intuitiv, o relaţie R este în forma normală Boyce-Codd dacă şi
numai dacă fiecare determinant este o cheie candidat.
Formal, o relaţie R este în forma normală Boyce-Codd dacă şi
numai dacă pentru orice dependenţă funcţională totală X → A, X este o
cheie (candidat) a lui R.
Regula Casey Delobel pentru R(K1#, K2#, X) presupunând că există

dependenţa: X  K2.  R1(K1#, X) şi R2(X#, K2)
K1 K2
X
Exemplu:
ADRESA(cod_parsoana#, telefon#, adresa)
cod_persoana
adresa
55
telefon
În dependenţa adresa  telefon se observă că determinantul nu este

o cheie candidat. Relaţia ADRESA se desface în:
ADRESA_1(cod_persoana#, adresa);
ADRESA_2(adresa#, telefon).
Relaţiile sunt în BCNF, se conservă datele, dar nu se conservă
dependenţele (s-a pierdut cod_persoana, telefon  adresa).
Exemplu:
Relaţia INVESTESTE_IN leagă entităţile INVESTITOR şi
OBIECTIV_INVESTITIE. Ea are schema relaţională:
INVESTESTE_IN(cod_contractant#, cod_obiectiv#, nr_contract,
cota_parte). Între atributele relaţiei există dependenţele:
{cod_contractant#, cod_obiectiv#} → {nr_contract, cota_parte},
{nr_contract} → {cod_obiectiv}.
Se aplică regula Casey-Delobel şi se aduce relaţia în BCNF.
INVESTESTE_IN_1(cod_obiectiv, nr_contract#);
INVESTESTE_IN_2(cod_contractant#, nr_contract, cota_parte).
Pentru ca o relaţie să fie adusă în BCNF nu trebuie în mod

obligatoriu să fie în FN3. Se pot aduce în BCNF şi relaţii aflate în FN1 sau
FN2. Acest lucru este posibil întrucât dependenţele funcţionale parţiale şi
cele tranzitive sunt tot dependenţe noncheie, adică dependenţe ai căror
determinanţi nu sunt chei candidat. Presupunem că R este o relaţie ce
conţine atributele A.
Algoritm TFBCNF (aducerea unei relaţii R din FN1 în BCNF)
1. Dacă relaţia conţine cel mult două atribute, atunci R este în
BCNF şi algoritmul s-a terminat.
2. Dacă relaţia conţine mai mult de două atribute, se consideră toate
perechile (X, Y) de atribute distincte din A.
3. Se determină A 1 , închiderea mulţimii A 1 = A – {X, Y}.
+
4. Dacă pentru orice pereche (X, Y), X ∉ A1 + atunci relaţia R este în

BCNF şi algoritmul s-a terminat.
5. În caz contrar (pentru cel puţin o pereche (X, Y), X aparţine lui
A1 +), relaţia R nu este în BCNF.
56
6. Se reduce progresiv schema relaţiei şi se reia algoritmul,

exploatând relaţia redusă. Orice relaţie obţinută prin reducerea lui
R şi care este în BCNF se consideră ca făcând parte din
descompunerea lui R în procesul aducerii sale în BCNF.

FN4 elimină redundanţele datorate relaţiilor m:n, adică datorate
dependenţei multiple.
Intuitiv, o relaţie R este în a patra formă normală dacă şi numai dacă
relaţia este în BCNF şi nu conţine relaţii m:n independente.
Fie R o relaţie definită pe o mulţime de atribute A = {A 1 , A 2 , ..., An }
şi fie X, Y, Z ⊂ A. Se spune că X multidetermină pe Z sau că Z este
multidependent de X :
• dacă pentru fiecare valoare a lui Z în R există numai o valoare
pentru perechea (X, Y);
• dacă valoarea lui Z depinde numai de valoarea lui X.
Acest tip de dependenţă, numită şi multivaloare sau multidependenţă
(MVD) se notează prin X →→ Z.
Intuitiv, multidependenţa reprezintă situaţia în care valoarea
unui atribut (sau a unei mulţimi de atribute) determină o mulţime de
valori a altui atribut (sau mulţimi de atribute)!!!
Multidependenţa X →→ Y poate fi gândită ca o regulă de deducţie:
dacă tuplurile <x, y, z> şi <x, y′, z′> sunt în relaţie la un moment r, atunci la
momentul r sunt în relaţie şi tuplurile <x, y, z′> şi <x, y′, z>.
x y z
x y' z'
x y z'
x y' z
Orice dependenţă funcţională este o multidependenţă. Afirmaţia

inversă nu este adevărată. Dacă X → Y (FD), atunci pentru oricare două
57
tupluri <x, y, z> şi <x, y′, z′>, se obţine y = y′. Prin urmare în relaţie apar
tuplurile <x, y′, z> şi <x, y, z′> şi deci X →→ Y (MVD).
Fie W, V, X, Y şi Z submulţimi de atribute ale unei scheme relaţionale
R. Fiind dată o mulţime T de multidependenţe există o mulţime completă
de axiome (Ax1–Ax8) care permit obţinerea tuturor multidependenţelor ce
se pot deduce din mulţimea T:
Ax1. Dacă Y ⊂ X, atunci X → Y.
Ax2. Dacă X → Y, atunci X ∪ Z → Y ∪ Z.
Ax3. Dacă X → Y şi Y → Z, atunci X → Z.
Ax4. Dacă X →→ Y, atunci X →→ R – {X ∪ Y}.
Ax5. Dacă X →→ Y şi V ⊂ W, atunci W ∪ X →→ V ∪ Y.
Ax6. Dacă X →→ Y şi Y →→ Z, atunci X →→ (Z – Y).
Ax7. Dacă X → Y, atunci X →→ Y.
Ax8. Dacă X →→ Y, Z → W, W ⊂ Y şi Y ∩ Z = ∅, atunci X → W.
O multidependenţă elementară este o multidependenţă care are
părţi stângi şi drepte minimale (nu există X′ ⊂ X şi Y′ ⊂ Y a.i. X′ →→ Y′).
Formal, relaţia R este în a patra formă normală dacă şi numai dacă:
• R este în BCNF;
• orice dependenţă multivaloare este o dependenţă funcţională.
O relaţie BCNF este în FN4 dacă pentru orice multidependenţă
elementară de forma X →→ Y, X este o supercheie a lui R. Aducerea
relaţiilor în FN4 presupune eliminarea dependenţelor multivaloare atunci
când sunt mai mult de una în cadrul unei relaţii.
Regula de descompunere în relaţii FN4. Fie R(X, Y, Z) o schemă
relaţională care nu este în FN4 şi fie X →→ Y o multidependenţă
elementară care nu este de forma „CHEIE →→ atribut“. Această relaţie
este descompusă prin proiecţie în două relaţii:
R = JOIN(ΠX∪Y (R), ΠX∪Z (R)).
Aplicând recursiv această regulă, se obţin relaţii FN4.
Exemplu. Fie relaţia INVESTITIE(cod_contractant#, denumire,
telefon) şi presupunem că un investitor poate avea mai multe numere de
telefon şi că poate investi în mai multe obiective. Între atributele relaţiei
există multidependenţele:
cod_contractant# →→ denumire;
cod_contractant# →→ telefon.
58
Relaţia INVESTITIE este în BCNF. Pentru a aduce relaţia în FN4 o

vom descompune prin proiecţie în două relaţii:
INVESTITIE_1(cod_contractant#, denumire),
INVESTITIE_2(cod_contractant#, telefon).
INVESTITIE = JOIN(INVESTITIE_1, INVESTITIE_2).

FN5 îşi propune eliminarea redundanţelor care apar în relaţii m:n
dependente. În general, aceste relaţii nu pot fi descompuse. S-a arătat că o
relaţie de tip 3 este diferită de trei relaţii de tip 2. Există totuşi o excepţie, şi
anume, dacă relaţia este ciclică
Intuitiv, o relaţie R este în forma normală 5 dacă şi numai dacă:
1. relaţia este în FN4;
2. nu conţine dependenţe ciclice.
Dependenţa funcţională şi multidependenţa permit descompunerea
prin proiecţie, fără pierdere de informaţie, a unei relaţii în două relaţii.
Regulile de descompunere (FN1 – FN4) nu dau toate descompunerile
posibile prin proiecţie ale unei relaţii. Există relaţii care nu pot fi
descompuse în două relaţii dar pot fi descompuse în trei, patru sau mai
multe relaţii fără a pierde informaţii. Pentru a obţine descompuneri L-join
în trei sau mai multe relaţii, s-a introdus conceptul de join-dependenţă sau
dependenţă la compunere (JD).
Fie {R1 , R2 , ..., Rp } o mulţime de scheme relaţionale care nu sunt
disjuncte şi a căror reuniune este R.
R satisface join-dependenţa *{R 1 , R 2 , ..., Rp } dacă la fiecare
moment al lui R are loc egalitatea:
R = JOIN(Πα1 (R), Πα2 (R), ..., Παp (R))
unde αk reprezintă mulţimea atributelor corespunzătoare lui Rk (1 ≤ k ≤ p).
Join-dependenţa *{R 1 , R 2 , ..., Rp } are loc în R, dacă R1 , R2 , ..., Rp
este o descompunere L-join a lui R. Pentru p = 2 se regăseşte
multidependenţa. O join-dependenţă *{R1 , R2 , ..., Rp } în care una dintre R i
este chiar R, defineşte o join-dependenţă trivială.
Join-dependenţa generalizează multidependenţa. Într-adevăr,
multidependenţa X →→ Y în relaţia R(X, Y, Z) (deci şi X →→ Z),
corespunde join-dependenţei *{X ∪ Y, X ∪ Z}. Invers, join-dependenţa
*{R1 , R 2 } corespunde multidependenţei R1 ∩ R2 →→ R1 – (R1 ∩ R2 ).
59
Formal, o relaţie R este în FN5 dacă şi numai dacă orice join-

dependenţă *{R 1 , R 2 , ..., Rp } care are loc în R fie este trivială, fie conţine o
supercheie a lui R (adică, o anumită componentă Ri este o supercheie a lui
R). Cu alte cuvinte, o relaţie R este în FN5 dacă orice join-dependenţă
definită pe R este implicată de cheile candidat ale lui R.
Între mulţimile de atribute X, Y şi Z din cadrul relaţiei R există o join-
dependenţă dacă există multidependenţe între fiecare dintre perechile de
mulţimi (X, Y), (Y, Z) şi (X, Z).
Aducerea în FN5 prin eliminarea join dependenţelor!
Exemplu.
Fie schema R(furnizor, cod_consumabil, cantitate, pret).
Reguli:
• un furnizor produce mai multe consumabile;
• nu toţi furnizorii produc aceleaşi consumabile;
• preţul unui consumabil de la un furnizor este variabil şi nu
depinde de cantitate.
Furnizor Cod_consumabil Cantitate Pret

F1 1 500 100
F2 1 100 80
F2 1 500 100
F2 2 500 100
Relaţia este în FN4, dar există redundanţă în date. Relaţia se

descompune prin proiecţie în:
R1(furnizor#, cod_consumabil#)
R2(furnizor#, cantitate, pret)
R3(cod_consumabil#, cantitate, pret).
S-au eliminat redundanţele:
(F2,1) pentru R1;
(F2, 500, 100) pentru R2;
(1, 500, 100) pentru R3.
Se observă că:
JOIN(R1, R2) ≠ R;
JOIN(R1, R3) ≠ R;
JOIN(R3, R2) ≠ R;
JOIN(R1, R2, R3) = JOIN(R1, JOIN(R2, R3)) = R
60
Există join dependenţa:

*{R1(furnizor, cod_consumabil), R2(furnizor, cantitate, pret),
R3(cod_consumabil, cantitate, pret)}
Exemplu.
Fie schema relaţională:
EXECUTANT(nr_santier#, cod_obiectiv#, cod_lucrare#, data_inceput,
data_sfarsit). Un şantier poate executa mai multe lucrări referitoare la
acelaşi obiectiv sau poate executa o lucrare pentru un obiectiv în intervale
de timp distincte. Se presupune că mai multe şantiere pot executa aceeaşi
lucrare, în acelaşi interval de timp sau în intervale de timp distincte.
Relaţia, datorită dependenţelor formulate anterior, nu este în FN5. Ea
se poate desface prin proiecţie în trei relaţii:
EX1(nr_santier#, cod_obiectiv#, cod_lucrare#);
EX2(nr_santier#, data_inceput, data_sfarsit);
EX3(cod_obiectiv#, cod_lucrare#, data_inceput, data_sfarsit).
Sunt evidente relaţiile:
EXECUTANT ≠ JOIN(EX1, EX2),
EXECUTANT = JOIN(JOIN(EX1, EX2), EX3).
Concluzii:
1. FN1 → FN2 elimină redundanţele datorate dependenţei netotale
a atributelor care nu participă la o cheie, faţă de cheile lui R. Se
suprimă dependenţele funcţionale care nu sunt totale.
2. FN2 → FN3 elimină redundanţele datorate dependenţei
tranzitive. Se suprimă dependenţele funcţionale tranzitive.
3. FN3 → BCNF elimină redundanţele datorate dependenţei
funcţionale. Se suprimă dependenţele în care partea stângă nu
este o supercheie.
4. BCNF → FN4 elimină redundanţele datorate multidependenţei.
Se suprimă toate multidependenţele care nu sunt şi dependenţe
funcţionale.
61
5. FN4 → FN5 elimină redundanţele datorate dependentei. ciclice.

Se suprimă toate join-dependenţele care nu sunt implicate de o
cheie.
6. BCNF, FN4 şi FN5 corespund la regula că orice determinant este
o cheie, dar de fiecare dată dependenţa cu care se defineşte
determinantul este alta şi anume dependenţa funcţională,
multidependenţa sau join-dependenţa).
7. Descompunerea unei relaţii FN2 în FN3 conservă datele şi
dependenţele, pe când descompunerea unei relaţii FN3 în BCNF
şi, respectiv, a unei relaţii BCNF în FN4 conservă doar datele.
Cateva observaţii şi concluzii referitoare la

PROIECTAREA BAZELOR DE DATE
Proiectarea conceptuală a bazei de date -- construirea
reprezentării conceptuale a bazei de date, care include identificarea tipurilor
importante de entităţi, relaţii, atribute.
1) identificarea tipurilor de entităţi (E);
2) identificarea tipurilor de relaţii (R);
3) identificarea şi asocierea atributelor (A) cu tipurile de E sau R;
4) determinarea domeniilor atributelor;
5) determinarea atributelor chei candidat şi chei primare;
6) specializarea şi generalizarea tipurilor de entităţi;
7) desenarea diagramei E/R;
8) revizuirea modelului de date conceptual local, împreună cu
utilizatorul, pentru a garanta că modelul este o reprezentare
corectă a punctului de vedere al utilizatorului asupra sistemului
real analizat.
Proiectarea logică a bazei de date -- transpunerea reprezentării

conceptuale în structura logică a BD, care include proiectarea relaţiilor.
1) transpunerea modelului conceptual local în modelul de date logic
local:
62
− eliminarea relaţiilor M:N (înlocuirea prin relaţii de tip 1:M sau

prin tabele asociative);
− eliminarea relaţiilor complexe (înlocuirea prin relaţii de tip
1:M);
− eliminarea relaţiilor recursive (înlocuirea prin relaţii
dependente);
− eliminarea atributelor multiple (înlocuirea prin relaţii
dependente;
− reexaminarea relaţiilor 1:1 (sunt într-adevăr 2 relaţii distincte?);
− eliminarea relaţiilor redundante.
2) extragerea relaţiilor din modelul de date logic local pentru a
reprezenta entităţile şi relaţiile (legăturile);
3) normalizarea relaţiilor;
4) validarea modelului conform tranzacţiilor utilizatorului pentru a
garanta că acesta acceptă şi rezolvă operaţiile cerute de către
model (se verifică faptul că modelul furnizează toate informaţiile
cerute de fiecare tranzacţie şi se reprezintă schematic calea
urmată de fiecare tranzacţie, direct în diagrama E/R);
5) desenarea diagramei conceptuale;
6) definirea constrîngerilor de integritate;
7) revizuirea modelului de date conceptual local, împreună cu
utilizatorii;
8) construirea şi validarea modelului de date logic global prin
combinarea modelelor locale:
– îmbinarea modelelor locale (revizuirea E, R, A, CP, CE,
constrîngeri, revizuirea denumirilor, căutarea entităţilor şi
relaţiilor care lipsesc, reactualizarea documentaţiei);
– normalizarea modelului;
– validarea modelului conform tranzacţiilor utilizatorului;
– verificarea în vederea dezvoltării ulterioare;
– desenarea diagramei conceptuale finale;
– revizuirea modelului de date conceptual global, împreună cu
utilizatorii.
Modalităţi pentru asigurarea integrităţii refenţiale!!!
Se specifică constrângeri de existenţă care definesc condiţiile în care
o cheie candidat sau o cheie externă poate fi inserată, ştearsă sau
reactualizată.
63
Exemplu: DOMENIU_contine_CARTE (1:M)

1) Inserare în relaţia "copil" (carte) - se verifică dacă domeniul cărţii
inserate este null sau corespunde unui domeniu existent.
2) Ştergerea în relaţia "copil" (fără probleme).
3) Reactualizarea în relaţia "copil" (similar cazului 1).
4) Inserarea în relaţia "părinte" (domeniu) se face fără probleme.
5) Reactualizarea cheii primare în relaţia "părinte" (dacă există o
apariţie în tabelul "copil" care face referinţă la vechea valoare a
cheii, atunci se pierde integritatea refenţială). Se pot aplica
strategii pentru a asigura integritatea refenţială (vezi 6).
6) Ştergerea unei apariţii din relaţia "părinte" (se pierde integritatea
referenţială dacă se şterge un domeniu de carte, dar există cel
puţin o carte din domeniul respectiv). Există 5 strategii care pot fi
luate în considerare.
− NO ACTION (nici o acţiune)- nu se poate şterge un domeniu
dacă există o carte în domeniul respectiv;
− CASCADE - se şterge domeniul şi automat se şterg toate cărţile
din domeniu ş.a.m.d.;
− SET NULL - se şterge domeniul, iar toate cărţiile din domeniul
respectiv vor avea codul domeniului setat null;
− SET DEFAULT - setare la o valoare prestabilită;
− NO CHECK - când este şters un domeniu de carte, nu se face
nimic pentru a garanta că integritatea refenţială este menţinută
(nici o verificare).
Proiectarea fizică a bazei de date -- implementarea fizică a structurii

logice într-o capacitate de stocare secundară corespunzătoare SGBD-ului
ţintă. Se descriu structurile de stocare şi metodele de acces utilizate pentru
realizarea unui acces eficient la date.
1) Transformarea relaţiilor extrase din modelul de date logic global
într-o formă care să poată fi implementată în SGBD-ul relaţional
ţintă (LDD).
2) Proiectarea (definirea) constrângerilor sistemului real modelat în
SGBD-ul ţintă (CONSTRAINT, declanşatori).
3) Proiectarea reprezentării fizice - determinarea organizării
fişierelor şi a metodelor de acces (indecşi) care vor fi utilizate
pentru a stoca relaţiile de bază (modul în care relaţiile şi tuplurile
vor fi păstrate în cadrul capacităţii de stocare secundare).
64
4) Introducerea unei redundanţe controlate (denormalizarea).

5) Estimarea necesarului de spaţiu pe disc cerut de baza de date.
6) Proiectarea mecanismelor de securitate:
− proiectarea vizualizărilor (VIEW);
− proiectarea regulilor de acces la relaţiile de bază şi la vizualizări
(privilegii, role-uri).
7) Monitorizarea neîntreruptă şi reglarea sistemului operaţional
pentru obţinerea unor performanţe maxime (micşorarea
configuraţiei hardware, timpi de răspuns mai scăzuţi, transfer
eficient etc.).
Comentăm pasul 4 referitor la considerarea introducerii unei

redundanţe controlate (denormalizare). NU există reguli fixe!!! Pasul 4
presupune:
• considerarea datelor derivate (calculate);
• considerarea dublării atributelor şi grupării relaţiilor.
Considerarea datelor derivate

De exemplu, în relaţia PROPRIETATE_DE INCHIRIAT apare drept
câmp, codul persoanei care a tranzacţionat închirierea. Prin urmare, s-ar
putea calcula pentru fiecare angajat, câte proprietăţi a închiriat SAU se poate
introduce în tabelul PERSONAL, un câmp calculat (derivat) ce conţine
numărul proprietăţilor închiriate de acesta.
Considerarea dublării atributelor şi grupării relaţiilor
Dublarea atributelor sau gruparea relaţiilor are ca scop reducerea
numărului de join-uri necesare pentru efectuarea unei interogări.
FILIALA (nr_fil#, strada, zona, oras, codpostal, tel, fax)
Relaţia nu este în FN3 deoarece codpostal determină funcţional
atributele zona şi oras. Aplic FN3 şi se obţine:
FIL(nr_fil#, strada, codpostal, tel, fax
COD_P(zona, oras, codpostal#)
Nu este convenabil, deoarece rareori vom accesa adresa filialei, fără
informaţii referitoare la zona şi oraş. Prin urmare, preferăm FN2.
Vom analiza câteva situaţii concrete de denormalizare.
• combinarea relaţiilor de tip 1:1
• dublarea atributelor care nu sunt chei în relaţii 1:M
65
SELECT p.*, ptr.nume

FROM proprietate_de_inchiriat p, proprietar ptr
WHERE p.nrptr=ptr.nrptr AND nrfil='S3';
Atributul nrptr este codul proprietarului. Dacă se va dubla atributul
nume din relaţia proprietate_de_inchiriat, atunci interogarea devine:
SELECT p.*
FROM proprietate_de_inchiriat p
WHERE nrfil='S3';
Avantaje sau dejavantaje ?!? Depinde de problemele care pot apărea.
• tabele de referinţă (tabele de căutare)
Acestea conţin, de obicei, un cod şi o descriere. De exemplu se poate
defini un tabel căutare "părinte" pentru tipul de proprietate şi modifica
tabelul proprietate_de_inchiriat ("copil") astfel:
TIP_PROPRIETATE(tip, descriere)
PROPRIETATE_DE_INCHIRIAT(nrpte, strada, zona, oras,
coppostal, tipul, nrcamere, chirie, nrptr, nrfiliala, nrpersonal)
Avantaje:
– dacă este modificată descrierea, atunci se va modifica o singură
dată, în tabelul de căutare;
– se reduce dimensiunea relaţiei "copil";
• dublarea atributelor cheii externe într-o relaţie de tip 1:M
pentru simplificarea join-urilor
Să se enumere proprietarii de proprietăţi de închiriat dintr-o filială.
SELECT ptr.nume
FROM proprietate_de_inchiriat p, proprietar ptr
WHERE p.nrptr=ptr.nrptr AND p.nrfil='S3';
Dacă se dublează cheia externă nrfiliala în relaţia PROPRIETAR,
adică se introduce o relaţie directă între FILIALA şi PERSONAL, atunci
cererea devine:
SELECT p.nume
FROM proprietar p
WHERE nrfil='S3';
ATENŢIE! Sunt necesare constrângeri suplimentare asupra cheilor
externe. De exemplu, dacă un proprietar ar închiria prin mai multe filiale
(atribut multiplu), atunci modificările nu mai sunt valabile.
De remarcat că singurul motiv pentru care relaţia
proprietate_de_inchiriat conţine atributul nrfiliala constă în faptul că este
66
posibil ca o proprietate să nu aibă alocat un membru de personal, mai ales la

început, când este preluată iniţial de către agenţie.
• Dublarea atributelor în relaţiile de tip M:N, pentru reducerea
join-urilor.
Presupunem că relaţia M:N dintre chirias şi proprietate_de_inchiriat
a fost descompusă prin introducerea relaţiei intermediare VIZITARE.
Care sunt chiriaşii care au vizitat proprietăţi, dar mai au de făcut
comentarii asupra uneia dintre ele? Personalul de la agenţie are nevoie de
atributul strada atunci când vorbeşte cu chiriaşii.
SELECT p.strada, c.*, v.data
FROM chirias c, vizitare v, proprietate_de_inchiriat p
WHERE v.nrpte = p.nrpte
AND c.nrch = v.nrch AND comentarii IS NULL;
Atributul nrpte este codul proprietăţii, iar nrch este codul chiriaşului.
Dacă se introduce atributul strada în relaţia VIZITARE, atunci

cererea devine:
SELECT v.strada, c.*, v.data
FROM chirias c, vizitare v
WHERE c.nrch = v.nrch AND comentarii IS NULL;
Comentăm pasul 3! Proiectarea reprezentării fizice

Scopul este de a stoca datele în mod eficient. Pentru măsurarea
eficienţei poate fi analizată:
• capacitatea de stocare pe disc;
• timpul de răspuns;
• transferul de tranzacţii (numărul de tranzacţii care pot fi efectuate
într-un anumit interval de timp).
Pentru îmbunătăţirea performanţelor trebuie ca proiectantul să
cunoască cum interacţionează cele 4 componente hardware (memoria
principală, CPU, discul I/O, reţeaua) şi modul cum acestea afectează
performanţele sistemului.
Principiile de bază ale distribuirii datelor pe unităţile de disc:
• fişierele sistemului de operare să fie separate de cele ale BD;
• fişierele principale ale BD să fie separate de fişierele de indexare;
• fişierul jurnalului de recuperare să fie separat de restul BD.
În această etapă se face şi analizarea tranzacţiilor, adică cunoaşterea
funcţionalităţii acestora şi analizarea celor mai importante dintre acestea.
67
Pentru fiecare tranzacţie trebuie detrminat:

• frecvenţa estimată cu care va fi rulată;
• relaţiile şi atributele accesate;
• tipul de acces (inserare, interogare, ştergere sau rectualizare);
• atributele care apar în predicate (condiţii);
• atributele care apar în join-uri;
• constrângerile de timp impuse tranzacţiilor.
Limbaje pentru prelucrarea datelor relaţionale

Unul dintre cele mai mari merite ale modelului relaţional este că prin
intermediul multiplelor sale limbaje de interogare (neprocedurale) permite
utilizatorului, chiar şi neinformatician, să indice rezultatul care îl
interesează, fără a preciza modul în care este obţinut acest rezultat.
O relaţie poate fi definită ca o mulţime, sau ca un predicat. Conform
dualităţii definiţiei unei relaţii, limbajele de prelucrare a datelor relaţionale
pot fi grupate în:
• limbaje algebrice - bazate pe teoria mulţimilor (SEQUEL, SQL);
• limbaje predicative - fondate pe calculul predicatelor.
Limbajele predicative pot fi:
• orientate pe tupluri (QUEL, ALPHA);
• orientate pe domenii (pot fi non-grafice (ILL, FQL) sau grafice).
Limbajele grafice pot fi:
• cu variabile domeniu explicite (QBE);
• fără variabile domeniu explicite (LAGRIF, CUPID, VGQF).
SQL este limbajul standard de descriere a datelor şi acces la
informaţiile din baza de date. SQL nu este un limbaj unic (cu excepţia
standardului care este puţin utilizat), existând peste o 100 de dialecte. Au
fost concepute şi dezvoltate diferite versiuni ale standardului SQL de către
68
ANSI, IBM, Microsoft, Borland, etc. Din păcate, lipsa unui standard unic
SQL are drept consecinţe creşterea costurilor programelor de gestiune a
bazelor de date şi îngreunarea întreţinerii arhitecturilor client/server.
Un grup de specialişti în baze de date s-au reunit sub numele SAG
(SQL Access Group) cu scopul de a construi un limbaj SQL comun şi de a
realiza pentru fiecare dialect un program de conversie din dialect în SQL, şi
invers.
Rezultatul a fost că în:
• 1992, Microsoft a lansat ODBC (Open Database Connectivity)
care este o mulţime de primitive bazate pe activitatea lui SAG;
• 1994 Borland a lansat IDAPI (Integrated Database Application
Programming Interface) care este o bibliotecă de funcţii SQL ce
se pot integra într-un program gazdă.
Limbaje algebrice
În abordarea algebrică, o relaţie este considerată ca o mulţime de
tupluri, iar o bază de date este considerată ca o mulţime de relaţii pe care
sunt definiţi operatorii algebrici.
Există două tipuri de operatori algebrici: mulţime (intersecţie,
reuniune, diferenţă, produs cartezian) şi relaţionali (proiecţie, selecţie,
diviziune, compunere). Operatorii selecţie, proiecţie, produs cartezian,
reuniune şi diferenţă sunt ireductibili şi sunt consideraţi drept operatori de
bază, iar operatorii intersecţie, diviziune şi compunere pot fi deduşi din
operatorii anteriori şi sunt consideraţi operatori derivaţi.
Operatorii limbajului algebric permit exprimarea unor cereri
nerecursive. Dacă cererea este recursivă este necesar un operator special şi
anume închiderea tranzitivă a unei relaţii.
SEQUEL (Structured English as a Query Language) este un
limbaj algebric definit pentru prototipul relaţional SYSTEM–R. Operaţia
fundamentală a limbajului este SELECT, care are forma generală clasică.
Operatorii clasici UNION, INTERSECTION, DIFFERENCE şi
INCLUSION sunt implementaţi în limbaj. SEQUEL este singurul limbaj
relaţional care are integrată închiderea tranzitivă. Limbajul permite
reactualizări asupra bazelor (UPDATE, INSERT, DELETE) şi calculul
unor funcţii elementare (COUNT, SUM, AVG, MAX, MIN). Conceptul de
partiţionare a fost de asemenea introdus în SEQUEL şi realizat cu ajutorul
clauzelor GROUP BY şi HAVING.
O extensie comercială a acestui limbaj, adoptată de aproape toate
SGBD şi considerată drept standard în prelucrarea datelor relaţionale, este
SQL.
69
Limbaje predicative
Limbajele predicative se bazează pe calculul predicatelor. Cererile
sunt exprimate sub forma unor mulţimi de tupluri sau valori pentru care se
specifică, sub forma unor predicate, proprietăţile pe care trebuie să le
îndeplinească.
QUEL este un limbaj predicativ orientat pe tupluri, utilizat de
sistemul INGRES. Limbajul QUEL poate fi utilizat independent sau inclus
în limbajul de programare C. Limbajul este caracterizat de:
• declararea unei variabile tuplu pentru fiecare relaţie (prin
RANGE),
• absenţa cuantificatorilor în expresii,
• utilizarea unor operatori speciali pe mulţimi,
• integrarea operaţiilor aritmetice.
Exemplu.
Să se listeze numele cititorilor care au împrumutat cărţi scrise de
Cioran.
RANGE OF a IS carte
RANGE OF b IS cititor
RANGE OF v IS imprumuta
RETRIEVE b.nume
WHERE (b.codec = v.codec)
AND (v.codel = a.codel)
AND (a.autor = ’Cioran’)
Limbajul acceptă comenzi de inserare (APPEND), reactualizare
(REPLACE), suprimare (DELETE), precum şi funcţii de calcul (MAX, MIN,
SUM, COUNT, AVG). Cuantificatorul existenţial este reprezentat implicit
prin declaraţia RANGE, iar cuantificatorul universal este simulat cu ajutorul
funcţiei COUNT.
Exemplu.
Să se listeze numele cititorilor care au împrumutat toate cărţile din
bibliotecă scrise de Cioran.
RANGE OF a IS carte
RANGE OF b IS cititor
RANGE OF v IS imprumuta
RETRIEVE b.nume
WHERE
COUNT (v.codel
WHERE (b.codec=v.codec)
70
AND (a.codel=v.codel)
AND (a.autor=’Cioran’))
=
COUNT (a.codel WHERE (a.autor=’Cioran’))
QBE (Query By Example) este un limbaj predicativ orientat pe

domenii. Limbajul dispune de primitive de programare grafică a cererilor
de date şi a fost conceput pentru utilizatorii neiniţiaţi. Utilizatorii, pentru a
manipula datele, completează o mulţime de câmpuri predefinite pe un ecran
special.
Exemplu.
Să se obţină titlurile cărţilor scrise de Cioran, din care există în
bibliotecă mai mult de 10 exemplare.
Carte Codel Titlu Autor Pret Nrex Coded

P.X 'Cioran' >10
Dacă utilizatorul doreşte şi tipărirea, atunci indică rezultatul care îl

interesează sub forma unei variabile domeniu (notată în acest exemplu prin
X) prefixată de P (print).
Dacă condiţia care apare în interogare este complexă sau se doreşte
simplificarea scrierii unei cereri, se poate utiliza o casetă specială (box
condition) în care se introduce condiţia.
În limbaj sunt admise funcţiile COUNT, MAX, MIN, AVG, SUM,
iar pentru eliminarea dublurilor a fost introdus operatorul UNIQUE.
Exemplu.
Să se obţină pentru fiecare autor, preţul celei mai scumpe cărţi şi
numărul exemplarelor scrise de acesta, care să găsesc în bibliotecă (tabelul
sortat!!!).

GROUP BY MAX SUM
În QBE există posibilitatea de a crea o nouă relaţie care poate fi o

schemă virtuală care reflectă modificările din relaţiile de bază sau o
imagine în care modificările nu sunt stocate.
Exemplu.
Codurile cărţilor scrise de Popa sau care au titlul „Geometrie“.
71
Algebric:
R1 = SELECT(carte, autor = 'Popa')
R2 = SELECT(carte, titlu = Geometrie')
R3 = R1 ∪ R2
Rezultat = PROJECT (R3, codel)
SEQUEL:
SELECT codel
FROM carte
WHERE autor = ’Popa’
OR titlu = ’Geometrie’
QBE:
P.X 'Popa'
P.Y 'Geometrie'
Exemplu.
Numele cititorilor care au împrumutat cel putin o carte scrisa de
Cioran.
Algebric:
R1 = PROJECT(cititor, codec, nume)
R2 = SELECT(carte, autor = 'Cioran')
R3 = PROJECT(R2, codel)
R4 = PROJECT(imprumuta, codel, codec)
R5 = JOIN(R4, R3, codel)
R6 = JOIN(R5, R1, codec)
Rezultat = PROJECT(R6, nume)
QBE:
Cititor Codec Nume Dep
Y P.X
Imprumuta Codel Codec Dataim Datares Dataef

Z Y

Z 'Cioran'
SEQUEL:
SELECT nume
FROM cititor
WHERE codec IS IN
72
SELECT codec
FROM imprumuta
WHERE codel IS IN
SELECT codel
FROM carte
WHERE autor = ’Cioran’
Utilizarea limbajelor de prelucrare a datelor relaţionale

în contextul limbajelor de programare
Două abordări:
• integrarea,
• extensia.
Integrarea LMD-ului într-un limbaj de programare.
Se consideră limbajul de prelucrare independent de limbajul de
programare şi există construcţii speciale care permit utilizarea acestuia în
limbajul gazdă. De exemplu, comenzile SQL pot fi integrate în limbajul
PL/1. Ele sunt prefixate de caracterul $ pentru a le distinge de comenzile
PL/1. Pentru a realiza integrarea, este necesară fie o precompilare a
cererilor, fie o interpretare la execuţie. Precompilatoarele actuale acoperă
majoritatea limbajelor semnificative existente. Alegerea unui precompilator
particular depinde de domeniul aplicaţiei.
Extensia limbajului de programare cu un LMD
Se consideră un limbaj de programare şi se realizează extensii ale
acestuia cu clauze specifice limbajelor de prelucrare a datelor.
Un exemplu tipic este extensia PASCAL/R care permite definirea unui
nou tip de date, şi anume tipul RELATION. De exemplu, relaţia carte este
definită:
TYPE car = RECORD
codel: TEXTE;
titlu: TEXTE;
autor: TEXTE;
nrex: INTEGER;
pret: INTEGER;
coded: TEXTE
END;
abc = RELATION OF car;
VAR carte: abc;
73
Exemplu.
Să se obţină o relaţie având numele rezultat, ce conţine toate cărţile
scrise de Cioran care au preţul mai mare de 150000.
VAR rezultat: abc;
…
BEGIN
rezultat:=[];
FOR EACH x IN carte DO
IF(x.autor = ’Cioran’) AND (x.pret >= 150000)
THEN rezultat:=rezultat + [x]
END;
Relaţia rezultat poate fi construită şi direct prin atribuirea:
rezultat := [EACH (x) IN carte:
(x.autor = ’Cioran’) AND (x.pret >= 150000)];
PROIECTAREA BAZELOR DE DATE
RELAŢIONALE
3.1. Preliminarii
Modelul relaţional a fost conceput şi dezvoltat de E.F. Codd. El este

un model formal de organizare conceptuală a datelor, destinat reprezentării
legăturilor dintre date, bazat pe teoria matematică a relaţiilor. Este modelul
cel mai accesibil pentru utilizatorul bazei de date deoarece structura sa fizică
este aceeaşi cu cea a datelor care trebuie prelucrate. În general, datele se
prezintă sub forma unor tabele (relaţii) în care liniile constituie
înregistrări, iar coloanele sunt atribute ce caracterizează aceste
înregistrări.
Obiectivele modelului relaţional, considerate de către E.F. Codd, sunt
următoarele:
• să permită un grad înalt de independenţă a datelor;
• să furnizeze baze solide pentru tratarea semanticii, coerenţei şi
problemelor de redundanţă a datelor;
• să permită dezvoltarea limbajelor de prelucrare a datelor.
Spre deosebire de modelul ierarhic şi reţea unde apar două elemente,
şi anume tipul entităţii şi relaţiile dintre două entităţi, modelul relaţional
este alcătuit numai din relaţii şi prin urmare, orice interogare asupra bazei
de date este tot o relaţie. Modelul relaţional a fost definit cu o deosebită
rigoare matematică, furnizând un mijloc performant de studiu al
proprietăţilor logice ale unui sistem de baze de date. Referitor la partea de
prelucrare a datelor, modelul relaţional este orientat spre mulţimi, în timp ce
modelele ierarhic şi reţea sunt orientate spre fişiere.
Pentru modelele ierarhic şi reţea, programatorul trebuie să proiecteze
programe care să acceseze baza de date, înregistrare cu înregistrare, utilizând
legături fizice între înregistrări. Modelul relaţional a permis introducerea
unor limbaje neprocedurale de prelucrare a datelor. Modelul relaţional nu
este orientat spre sistemul de calcul, deci modelul nu include regulile,
structurile şi operaţiile referitoare la implementarea fizică a unui sistem de
baze de date. De fapt, unul dintre obiectivele modelului este acela de a face
o distincţie între aspectele fizice şi logice ale unei baze de date
(independenţa datelor).
1
Modelul relaţional, deşi are unele imperfecţiuni, a fost adoptat în
ultimele decenii de majoritatea programatorilor din domeniu, tocmai datorită
acestor trei calităţi: este simplu, riguros din punct de vedere matematic şi nu
este orientat spre sistemul de calcul.
Definirea unui SGBD relaţional impune analizarea caracteristicilor pe
care trebuie să le prezinte un model de date pentru a fi considerat relaţional.
Există diferite modalităţi pentru a defini acest concept:
• prezentarea datelor în tabele supuse anumitor operaţii de tip
proiecţie, selecţie, reuniune, compunere, intersecţie etc. (definiţie
simplă);
• un sistem de baze de date ce suportă un limbaj de tip SQL –
Structured Query Language (definiţie practică);
• un sistem de baze de date care respectă principiile modelului
relaţional introdus de E.F. Codd (definiţia folosită cel mai
frecvent).
E.F. Codd a publicat un set de 13 reguli, numite reguli de fidelitate, în
raport cu care un SGBD poate fi apreciat ca relaţional. Ulterior, cele 13
reguli de fidelitate ale lui Codd au fost extinse la un număr de 100. Trebuie
remarcat că nu există un SGBD care respectă toate regulile definite de Codd.
Nu trebuie să apreciem un SGBD ca fiind relaţional sau nu, ci măsura în care
acesta este relaţional, deci numărul regulilor de fidelitate pe care le respectă.
3.2. Caracterisicile modelului relaţional
Dintre principalele caracteristici ale modelului relaţional se remarcă:

• nu există tupluri identice;
• ordinea liniilor şi a coloanelor este arbitrară;
• articolele unui domeniu sunt omogene;
• fiecare coloană defineşte un domeniu distinct şi nu se poate repeta
în cadrul aceleiaşi relaţii;
• toate valorile unui domeniu corespunzătoare tuturor cazurilor nu
mai pot fi descompuse în alte valori (sunt atomice).
Comparativ cu celelalte modele de date, modelul relaţional are
avantaje remarcabile dintre care se remarcă:
• fundamentarea matematică riguroasă,
• independenţa fizică a datelor,
• posibilitatea filtrărilor,
2
• existenţa unor structuri de date simple,
• minimizarea redundanţei,
• supleţea în comunicarea cu utilizatorul neinformatician etc.
Ca limite ale modelului relaţional pot fi menţionate:
• rămâne totuşi redundanţă,
• ocupă spaţiu,
• apar fenomene de inconsistenţă,
• nu există mecanisme pentru tratarea optimă a cererilor recursive,
• nu lucrează cu obiecte complexe,
• nu există mijloace perfecţionate pentru exprimarea constrângerilor
de integritate,
• nu realizează gestiunea cunoştinţelor etc.
Un model relaţional este caracterizat de trei elemente:
• structura relaţională a datelor (caracteristica structurală),

• operatorii modelului relaţional (caracteristica de asigurare a
prelucrării),
• regulile de integritate care guvernează folosirea cheilor în model
(caracteristica de asigurare a integrităţii).
Aceste trei elemente corespund celor trei componente ale ingineriei
software: informaţie, proces, integritate.
3.2.1. Structura datelor
Conceptelor descrise formal drept relaţie, tuplu sau atribut, le

corespund uzual denumirile tabel, linie sau coloană, iar fizic fişier,
înregistrare sau câmp.
Un domeniu este o mulţime de valori care se poate defini fie
enumerând elementele componente, fie specificând o proprietate distinctivă
a valorilor. Domeniului îi corespunde, atât uzual cât şi fizic, conceptul de
tip de date.
Un tip de date este o mulţime de valori, şi anume mulţimea tuturor
valorilor care satisfac o anumită constrângere a tipului. Un tip de date poate
fi definit de către sistem sau de către utilizator. De asemenea, fiecare tip are
asociat un set de operatori care pot fi aplicaţi valorilor tipului respectiv.
Tipurile constrâng operaţiile prin faptul că este necesar ca operanzii unei
operaţii să fie de tipurile definite pentru operaţia respectivă.
3
Tipurile pot fi oricât de simple sau de complexe. Se pot distinge tipuri
de date ale căror valori sunt numere, şiruri, date calendaristice, înregistrări
audio sau video, hărţi, puncte geometrice etc.
Orice tip de date este scalar (atomic, încapsulat) sau nescalar. Tipul
nescalar are componente vizibile utilizatorului şi direct accesibile.
Trebuie făcută distincţia între un tip şi reprezentarea sa fizică,
deoarece tipurile sunt legate de model, iar reprezentarea fizică este un aspect
legat de implementare.
Fie D 1 , D 2 , ..., D n domenii finite, nu neapărat disjuncte. Produsul
cartezian D1 × D2 × ... × Dn al domeniilor D 1, D 2, ..., Dn este definit de
mulţimea tuplurilor (V1, V2, ..., Vn ), unde V1 ∈ D1 , V2 ∈ D 2, ..., Vn ∈ Dn .
Numărul n defineşte aritatea tuplului.
O relaţie R pe mulţimile D1 , D2 , ..., Dn este o submulţime a produsului
cartezian D 1 × D2 × ... × D n, deci este o mulţime de tupluri. Există un alt mod
de a defini relaţia, şi anume ca o mulţime finită de funcţii. Asociem fiecărui
domeniu D i un atribut A i şi definim relaţia R = {f 1 , f 2 , ..., f m}, unde
fi : {A1, A2, ..., An } → D1 ∪ D 2 ∪ ... ∪ Dn şi fi (Aj ) ∈ D j pentru orice valori ale
lui i şi j. În această definiţie nu mai este restricţionată ordinea.
Definirea unei relaţii ca o mulţime de tupluri sau ca o mulţime de funcţii
se referă la mulţimi care variază în timp (se adaugă, se şterg sau se modifică
elemente). Pentru a caracteriza o relaţie este necesară existenţa unui element
invariant în timp, iar acest invariant este dat de structura relaţiei (schema
relaţională). Mulţimea numelor atributelor corespunzătoare unei relaţii R
defineşte schema relaţională a relaţiei respective. Vom nota schema
relaţională prin R(A1, A2, ..., An ).
De exemplu, pentru modelul de date analizat în această lucrare,
VESTIMENTATIE(cod_vestimentatie, cod_designer, cod_model,
cod_prezentare, denumire, valoare, descriere) reprezintă o schemă relaţională.
Putem reprezenta o relaţie printr-un tabel bidimensional în care fiecare
linie corespunde unui tuplu şi fiecare coloană corespunde unui domeniu din
produsul cartezian. O coloană corespunde unui atribut. Numărul atributelor
defineşte gradul relaţiei, iar numărul de tupluri din relaţie defineşte
cardinalitatea relaţiei.
Bazele de date relaţionale sunt percepute de către utilizatori ca o
mulţime de tabele. Tabelul reprezintă structura logică dintr-un sistem
relaţional, nu structura fizică. La nivel fizic, sistemul poate stoca datele în
diferite moduri, folosind fişiere secvenţiale, indexări, înlănţuiri de pointeri etc.,
cu condiţia să poată realiza corespondenţa dintre reprezentarea stocată şi
tabelele de la nivelul logic.
4
Bazele de date relaţionale respectă principiul informaţiei (principiul
reprezentării uniforme), care afirmă că întregul conţinut informaţional al bazei
este reprezentat într-un mod unic, şi anume, ca valori explicite ale celulelor
unui tabel. Această modalitate de reprezentare este singura disponibilă, la nivel
logic, într-un sistem relaţional.
Când se inserează tupluri într-o relaţie, de multe ori valoarea unui
atribut este necunoscută sau nu este aplicabilă tuplului respectiv. Pentru a
reprezenta valoarea acestui atribut a fost introdusă o valoare convenţională
în relaţie, şi anume null. De fapt, null nu reprezintă o valoare, ci absenţa
uneia. Un null nu este acelaşi lucru cu o valoare numerică egală cu zero sau
cu un şir de caractere vid. Zerourile şi spaţiile libere (şirul vid) sunt valori,
pe când null semnifică absenţa unei valori. Prin urmare, null trebuie tratat în
mod diferit faţă de alte valori şi trebuie înţeles că termenul „valoare nulă“
este depreciativ.
Evident, este necesară o aritmetică şi o logică (polivalentă) nouă
(fig.3.1) care să cuprindă acest element. De exemplu, ce valoare are „10 >
null“ ? Răspunsul este null. În general, rezultatul operaţiilor aritmetice sau
logice este null când unul din operanzi este null. Prin urmare, „null = null“
are valoarea null, iar ¬ null este null.
Întroducerea null-urilor în modelul relaţional constituie o problemă
controversată, deşi Codd tratează null ca parte integrantă a modelului. Alţii
consideră această abordare greşită şi prematură. Trebuie remarcat că nu toate
sistemele relaţionale acceptă null-urile.
AND T F Null OR T F Null
T T F Null T T T T
F F F F F T F Null
Null Null F Null Null T Null Null
Fig. 3.1. Tabele de adevăr pentru operatorii AND şi OR

Tabelul vizualizare (view, filtru, relaţie virtuală, vedere) constituie un
filtru asupra tabelului iniţial, care conţine numai informaţia necesară unei
anumite abordări sau aplicaţii. De fapt, vizualizarea este o expresie
relaţională căreia i se atribuie un nume.
5
Dacă baza de date conţine tabele reale depuse pe disc, o vizualizare
este virtuală deoarece datele pe care le conţine nu sunt în realitate memorate
într-o bază de date. Este memorată numai definiţia vizualizării. Vizualizarea
nu este definită explicit, ca relaţiile de bază, prin mulţimea tuplurilor
componente, ci implicit, pe baza altor relaţii obţinute prin intermediul unor
expresii relaţionale. Stabilirea efectivă a tuplurilor care compun vizualizarea
se realizează prin evaluarea expresiei atunci când utilizatorul se referă la
acest tabel.
Utilizarea vizualizărilor este avantajoasă, deoarece:
• asigură securitatea tabelului iniţial (care este protejat de ştergeri,
modificări etc.) prin capacitatea de a ascunde datele;
• permit vizualizarea simultană a aceloraşi date de către diverşi
utilizatori;
• sunt concise, punând la dispoziţie capacităţi „macro“;
• asigură independenţa logică faţă de date (imunitatea programelor
de aplicaţie faţă de modificările din structura logică a bazei de
date).
Există totuşi limitări în utilizarea acestor tabele, în special legate de
problema reactualizării. De exemplu, coloanele calculate nu pot fi
reactualizate. De asemenea, inserarea, reactualizarea şi ştergerea nu sunt, în
general, recomandate şi sunt permise numai cu anumite restricţii care sunt
specifice fiecărui SGBD. De exemplu, Oracle9i rezolvă problema dificilă a
reactualizării vizualizărilor, în anumite situaţii, utilizând o clasă specială de
declanşatoare (TRIGGER de tip INSTEAD OF).
3.2.2. Reguli de integritate
Regulile de integritate sunt aserţiuni pe care datele conţinute în baza

de date trebuie să le satisfacă. Trebuie făcută distincţia între regulile
structurale care sunt inerente modelării datelor şi regulile de funcţionare
(comportament) care sunt specifice unei aplicaţii particulare.
Există trei tipuri de constrângeri structurale (de cheie, de referinţă, de
entitate) ce constituie mulţimea minimală de reguli de integritate pe care
trebuie să le respecte un SGBD relaţional. Restricţiile de integritate
minimale sunt definite în raport cu noţiunea de cheie a unei relaţii.
O mulţime minimală de atribute ale căror valori identifică unic un
tuplu într-o relaţie reprezintă o cheie pentru relaţia respectivă.
6
Prin urmare, o cheie a unei relaţii R este o mulţime K de atribute,
astfel încât:
(1) pentru orice două tupluri t 1 , t 2 ale lui R ⇒ t 1 (K) ≠ t 2 (K);
(2) nu există nicio submulţime proprie a lui K având proprietatea (1).
Fiecare relaţie are cel puţin o cheie. Dacă există diferite chei posibile,
ele se numesc chei candidat. Una dintre cheile candidat va fi aleasă pentru a
identifica efectiv tupluri şi ea va primi numele de cheie primară. Cheia
primară nu poate fi reactualizată. Restul cheilor candidat vor purta numele de
chei alternative sau secundare. Atributele care reprezintă cheia primară pot fi
subliniate sau urmate de semnul „#“.
O cheie identifică linii şi este diferită de un index care localizează
liniile. O cheie secundară este folosită ca index pentru a accesa tupluri. Un
grup de atribute din cadrul unei relaţii care conţine o cheie a relaţiei poartă
numele de supercheie.
Fie schemele relaţionale R1(P1, S1) şi R2(S1, S2), unde P1 este cheie
primară pentru R1, S1 este cheie secundară pentru R1, iar S1 este cheie
primară pentru R2. În acest caz, vom spune că S1 este cheie externă (cheie
străină) pentru relaţia R1.
De exemplu, cod_casa_moda este cheie externă pentru relaţia
CREATOR şi este cheie p irmară p entru relaţia CASA_ MODA. Cheia
primară poate conţine cheia externă. De exemplu, relaţia ACCESORIU are
cheia primară formată din atributele cod_accesoriu şi cod_vestimentatie, iar
atributul cod_vestimentatie fiind cheie primară în relaţia
VESTIMENTATIE, devine cheie externă în relaţia ACCESORIU.
Modelul relaţional respectă trei reguli de integritate structurală.
 Regula 1 – unicitatea cheii. Cheia primară trebuie să fie unică şi

minimală.
 Regula 2 – integritatea entităţii. Atributele cheii primare trebuie să
fie diferite de null.
 Regula 3 – integritatea referirii. O cheie externă trebuie să fie ori
null în întregime, ori să corespundă unei valori a cheii primare
asociate.
Uneori constrângerile de integritate sunt implementate procedural,
folosind o clasă de proceduri (declanşatori) precompilate, stocate împreună
cu baza de date şi invocate automat ori de câte ori are loc un anumit
eveniment. Aceste proceduri nu reprezintă o modalitate recomandată de
implementare a constrângerilor de integritate deoarece, fiind proceduri, sunt
7
mai dificil de optimizat de către sistem şi, de asemenea, sunt executate doar
atunci când apare evenimentul specificat (declanşator).
Declanşatorii trebuie utilizaţi cu precauţie, sau deloc, dacă există o
modalitate alternativă de rezolvare a problemei respective. Ei pot crea
probleme practice datorită fenomenului „declanşatori în cascadă“ (lanţ de
declanşatori). De asemenea, dacă acelaşi eveniment determină pornirea mai
multor declanşatori diferiţi, atunci ordinea în care pornesc poate fi
importantă sau poate fi chiar nedefinită. Există posibilitatea ca un
declanşator să se declanşeze singur, recursiv. Dacă sunt disponibile, soluţiile
declarative sunt de preferat celor procedurale.
3.2.3. Operatorii modelului relaţional
Operatorii modelului relaţional definesc operaţiile care se pot efectua

asupra relaţiilor în scopul realizării funcţiilor de prelucrare asupra bazei de
date. Modelul relaţional oferă două mulţimi de operatori pe relaţii, şi anume:
algebra relaţională şi calculul relaţional. La rândul său, calculul relaţional
este de două tipuri: orientat pe tupluri sau orientat pe domenii.
Operatorii algebrei relaţionale sunt fie operatori tradiţionali pe
mulţimi (UNION, INTERSECT, PRODUCT, DIFFERENCE), fie operatori
relaţionali speciali (PROJECT, SELECT, JOIN, DIVISION). Aceşti
operatori vor fi analizaţi în secţiunea 3.4.
Calculul relaţional reprezintă o adaptare a calculului predicatelor la
domeniul bazelor de date relaţionale. Ideea de bază este de a identifica o
relaţie cu un predicat. Pe baza unor predicate iniţiale, prin aplicarea unor
operatori ai calculului cu predicate (conjuncţia, disjuncţia, negaţia,
cuantificatorul existenţial şi cel universal) se pot defini noi relaţii.
Variabilele care apar în construcţiile calculului relaţional orientat pe domenii
sunt variabile definite asupra domeniilor, iar cele care apar în construcţiile
calculului relaţional orientat pe tupluri sunt variabile definite asupra
relaţiilor, adică valorile acestora reprezintă tupluri.
Echivalenţa dintre algebra relaţională şi calculul relaţional a fost
demonstrată de J.D.Ullman. Această echivalenţă arată că orice relaţie posibil
de definit în algebra relaţională poate fi definită şi în cadrul calcului
relaţional, şi reciproc.
8
3.3. Proiectarea modelului relaţional
Problema proiectării bazelor de date poate fi enunţată în următoarea

manieră: fiind dat un volum de informaţii care trebuie reprezentat într-o bază
de date, cum se poate alege o structură logică adecvată pentru acesta?
Proiectarea bazelor de date este mai mult o artă, decât o ştiinţă. Există
câteva principii ştiinţifice care pot fi invocate pentru a rezolva problema, dar
există multe aspecte legate de proiectare pe care aceste principii nu le
abordează şi evident, nu le rezolvă. Teoreticienii şi practicienii au propus
metodologii de proiectare mai mult sau mai puţin riguroase, dar găsirea
proiectării logice optime rămâne o problemă complexă şi dificilă. Pot exista
criterii obiective care să favorizeze o abordare în raport cu celelalte. În
capitolul 2 s-a prezentat o abordare (proiectarea modelului E/R) care are
meritul că este frecvent utilizată în practică.
În practică, se încearcă obţinerea unei scheme conceptuale corecte,
adică realizarea proiectării logice abstracte independent de hardware, de
sistemul de operare, de SGBD, de limbaj, de utilizator etc. Este importantă
atât obţinerea structurilor de date corecte, cât şi realizarea integrităţii datelor.
De asemenea, trebuie ca designul să fie robust, în sensul că nu va fi invalidat
prin ivirea unor noi cerinţe ale aplicaţiei, care nu au fost prevăzute în
momentul proiectării iniţiale.
Pentru rafinarea proiectării modelului de date, pentru obţinerea
schemei conceptuale a bazei de date relaţionale, se pleacă de la o formă de
modelare semantică specială a datelor, mai precis de la diagrama E/R.
Ideea generală este de a reprezenta entităţile şi legăturile dintre
acestea sub forma unor tabele speciale (relaţii). Vor fi prezentate 9 reguli
care arată maniera în care se transformă entităţile, relaţiile şi atributele
acestora, în vederea obţinerii schemei conceptuale.
Ca formalism, în diagrama conceptuală, simbolul „×“ indică
plasamentul cheii externe. Dacă simbolul este subliniat („×“), se exprimă şi
faptul că respectiva cheie externă este conţinută în cheia primară.
9
3.3.1. Transformarea entităţilor
 Entităţile independente devin tabele independente. Cheia primară

nu conţine chei externe. De exemplu, entitatea independentă
PREZENTARE generează un tabel independent pentru care
atributul cod_prezentare reprezintă cheia primară.
 Entităţile dependente devin tabele dependente. Cheia primară a
entităţilor dependente conţine cheia primară a entităţii de care
depinde (cheie externă) plus unul sau mai multe atribute
adiţionale. De exemplu, cheia primară a entităţii dependente
ACCESORIU este formată din atributul cod_vestimentatie, care
reprezintă cheia primară a entităţii de care depinde
(VESTIMENTATIE), plus atributul adiţional cod_accesoriu.
 Subentităţile devin subtabele. Cheia externă se referă la
supertabel, iar cheia primară este această cheie externă. De
exemplu, cheia primară a subentităţii MODEL este cod_angajat
care este o cheie externă (cheie primară a entităţii
ANGAJAT_TEMP).
3.3.2. Transformarea relaţiilor
 Relaţiile 1:1 şi 1:n devin chei externe. De exemplu, relaţia creeaza

(CREATOR_creeaza_VESTIMENTATIE) devine coloană în
tabelul VESTIMENTATIE. Atributul cod_creator, care este cheie
primară în tabelul CREATOR, va fi cheie externă în tabelul
VESTIMENTATIE. Relaţia 1:1 plasează cheia externă în tabelul cu
mai puţine linii.
 Relaţia m:n devine un tabel special, numit tabel asociativ, care are
două chei externe pentru cele două tabele asociate. Cheia primară
este compunerea acestor două chei externe plus eventuale coloane
adiţionale. Un tabel asociativ se desenează punctat. De exemplu,
relaţia participa (CASA_MODA_participa_PREZENTARE), care
este de tip m:n, devine tabel asociativ având cheia primară formată
din atributele cod_casa_moda şi cod_prezentare.
 Relaţiile de tip trei devin tot tabele asociative. De exemplu, relaţia
primeste ce leagă entităţile ANGAJAT_TEMP, PREZENTARE şi
CASA_MODA, devine tabel asociativ. Cheia primară a tabelului
este compunerea a trei chei externe: cod_angajat, cod_casa_moda
10
şi cod_prezentare. Practic, în acest caz, este preferabil să fie
introdusă o cheie primară artificială.
3.3.3. Transformarea atributelor
 Un atribut singular devine o coloană.

 Atributele multiple devin tabele dependendente ce conţin cheia
primară a entităţii şi atributul multiplu. Cheia primară este formată
dintr-o cheie externă, plus una sau mai multe coloane adiţionale.
De exemplu, o persoană de contact poate cunoaşte mai multe limbi
străine. În acest caz, atributul limba_cunoscuta este multiplu şi va
genera tabelul dependent LIMBA.
 Entităţile devin tabele, iar atributele lor devin coloane în aceste
tabele. Ce devin atributele relaţiilor? Pentru relaţii 1:1 şi 1:n,
atributele relaţiilor vor aparţine tabelului care conţine cheia
externă, iar pentru relaţii m:n şi de tipul trei, atributele vor fi
plasate în tabelele asociative.
Tabel Reprezintă Cheie primară

Independent entitate independentă nu conţine chei externe
Subtabel subentitate o cheie externă
entitate dependentă o cheie externă şi una sau mai
Dependent
Atribut multiplu multe coloane adiţionale
relaţie m:n două sau mai multe chei externe
Asociativ şi (opţional) coloane adiţionale
relaţie de tip 3
Fig. 3.2. Clasificarea tabelelor
11
LIMBA INFO_CONTACT
FIRMA_PUB cunoaste are
ORGANIZATOR
are ×
PERS CONTACT
face ×
are
PUBLICITATE×
organizeaza LOCALIZARE
FIRMA_SEC LOCATIE
se_face
are
are
×
ANGAJAT_SEC PAZA × × FINANTEAZA SPONSOR
PREZENTARE
×
asigura PARTICIPA
SOC ASIG
CASA MODA × PRIMESTE

prezinta
lucreaza
ANGAJAT_TEMP
×
CREATOR MODEL
×
creeaza prezinta
lucreaza_la
face × ×
VESTIMENTATIE
× are AGENTIE
are refera
×
× ACCESORIU ISTORIC ×
Fig. 3.3. Diagrama conceptuală.
12
Cele patru tipuri de tabele (independente, dependente, subtabele şi
asociative) se deosebesc prin structura cheii primare (figura 3.2.).
În figura 3.3 este prezentată diagrama conceptuală pentru proiectarea
modelului relaţional comentat. Ea a fost construită din diagrama E/R prin
adăugarea tabelelor asociative şi prin marcarea cheilor externe.
În continuare va fi prezentată modalitatea efectivă de trecere de la
diagrama entitate-relaţie la diagrama conceptuală pentru modelul de date
real analizat în capitolul 2.
Entităţile independente PERS_CONTACT, ORGANIZATOR,
PREZENTARE, PUBLICITATE, SPONSOR, FIRMA_PUB,
CASA_MODA, CREATOR, ANGAJAT_TEMP, ACCESORIU,
LOCALIZARE, FIRMA_SEC, ANGAJAT_SEC, SOCIETATE_ASIG,
INFO_CONTACT, AGENTIE, LOCATIE devin tabele independente.
Cheile primare ale fiecărei entităţi au fost specificate în capitolul 2.
Entităţile dependente ISTORIC şi ACCESORIU, care intervin în
model, devin tabele dependente, iar cheile primare au fost specificate în
capitolul 2.
Subentitatea MODEL devine subtabel, având aceeaşi cheie primară cu
superentitatea ANGAJAT_TEMP, adică atributul cod_angajat.
Relaţiile de tip one-to-one şi one-to-many devin chei externe.
Relaţia PERS_CONTACT_are_LOCALIZARE devine cheie externă în
tabelul PERS_CONTACT. Dacă restricţia că o persoană de contact are o
singură localizare este eliminată, atunci cardinalitatea relaţiei devine 1:n, iar
atributul cod_pers_contact devine cheie externă în tabelul LOCALIZARE.
Toate comentariile anterioare rămân valabile şi pentru entităţile
FIRMA_PUB, FIRMA_SEC, PREZENTARE, ORGANIZATOR,
CASA_MODA, SPONSOR, SOC_ASIG, CREATOR, LOCATIE,
ANGAJAT_TEMP şi AGENTIE, care sunt legate de entitatea
LOCALIZARE, permiţând astfel localizarea tuturor structurilor modelului.
Relaţia PERS_CONTACT_are_INFO_CONTACT devine cheie externă în
tabelul PERS_CONTACT. Dacă restricţia că pentru o persoană de contact
există o singură posibilitate de contactare este eliminată, atunci
cardinalitatea relaţiei devine 1:n, iar atributul cod_pers_contact devine cheie
externă în tabelul INFO_CONTACT. Toate comentariile anterioare rămân
valabile şi pentru entităţile FIRMA_PUB, FIRMA_SEC,
ANGAJAT_TEMP, PREZENTARE, ORGANIZATOR, CASA_MODA,
SPONSOR, SOC_ASIG, CREATOR, LOCATIE şi AGENTIE, care sunt
legate de entitatea INFO_CONTACT, permiţând astfel accesarea tuturor
structurilor modelului.
13
Relaţia FIRMA_PUB_face_PUBLICITATE devine cheie externă în tabelul
PUBLICITATE.
Relaţia PUBLICITATE_se_face_pentru_PREZENTARE devine cheie
externă în tabelul PUBLICITATE.
Relaţia ORGANIZATOR_are_PERS_CONTACT devine cheie externă în
tabelul PERS_CONTACT.
Relaţia FIRMA_SEC_are_ANGAJAT_SEC devine cheie externă în tabelul
ANGAJAT_SEC.
Relaţia SOC_ASIG_asigura_PREZENTARE devine cheie externă în tabelul
PREZENTARE.
Relaţia CASA_MODA_lucreaza_CREATOR devine cheie externă în tabelul
CREATOR.
Relaţia CREATOR_creeaza_VESTIMENTATIE devine cheie externă în
tabelul VESTIMENTATIE.
Relaţia VESTIMENTATIE_are_ACCESORIU devine cheie externă în tabelul
ACCESORIU.
Relaţia MODEL_prezintă_VESTIMENTATIE devine cheie externă în tabelul
VESTIMENTATIE.
Relaţia CREATOR_face_ACCESORIU devine cheie externă în tabelul
ACCESORIU.
Relaţia PREZENTARE_prezinta_VESTIMENTATIE devine cheie externă în
tabelul VESTIMENTATIE.
Relaţia PREZENTARE_are_LOCATIE devine cheie externă în
PREZENTARE.
Relaţia MODEL_lucreaza_AGENTIE devine cheie externă în tabelul
MODEL.
Relaţia MODEL_are_ISTORIC devine cheie externă în tabelul ISTORIC.
Relaţia ISTORIC_refera_AGENTIE devine cheie externă în tabelul
ISTORIC.
Relaţiile de tip many-to-many devin tabele asociative, având două
chei externe pentru cele două tabele asociate.
Relaţia ANGAJAT_SEC_paza_PREZENTARE devine tabel asociativ
(PAZA).
SPONSOR_finanteaza_PREZENTARE devine tabel asociativ
(FINANTEAZA).
CASA_MODA_participa_PREZENTARE devine tabel asociativ
(PARTICIPA).
Relaţiile de tipul trei (adică cele care leagă cel puţin trei entităţi)
devin tabele asociative, având chei externe pentru fiecare dintre tabelele
asociate.
14
Relaţia primeste, care leagă entităţile ANGAJAT_TEMP, PREZENTARE şi
CASA_MODA, devine tabel asociativ (PRIMESTE). În acest caz, s-a
considerat o cheie primară artificială (atributul cod_primeste). Tabelul
asociativ are drept chei externe atributele: cod_angajat, cod_casa_moda şi
cod_prezentare.
Atributele multiple devin tabele dependendente ce conţin cheia
primară a entităţii şi atributul multiplu.
Atributul limba_cunoscuta este multiplu (relativ la entitatea
PERS_CONTACT) şi va genera tabelul dependent LIMBA. Acesta va avea
drept cheie primară atributele cod_pers_contact şi limba_cunoscuta. Tabelul
mai conţine trei atribute ce reprezintă nivelul de cunoaştere (scris, citit,
vorbit) a limbii.
Atributele entităţilor devin coloane în tabelele corespunzătoare. Pentru
relaţii 1:1 şi 1:n, atributele relaţiilor vor aparţine tabelului care conţine cheia
externă, iar pentru relaţii m:n şi de tipul trei, atributele vor fi plasate în
tabelele asociative.
Tabelul asociativ PRIMESTE va avea ca atribute, pe lângă cele ce constituie
cheia primară, suma, data_achitare, cont, banca.
Schemele relaţionale corespunzătoare diagramei conceptuale din
figura 3.3. sunt următoarele:
MODEL(cod_angajat#, cod_agentie, inaltime, nr_pantof, info)
ANGAJAT_TEMP(cod_angajat#, nume, prenume, data_nastere,
nationalitate, sex, cod_localizare, cod_info_acces, tip)
PUBLICITATE(cod_publicitate#, cod_firma_pub, cod_prezentare, tip,
nume, suma, observatii)
FIRMA_PUB(cod_firma_pub#, nume, info, director, observatii,
cod_localizare, nume_pers_contact, cod_info_acces)
ORGANIZATOR(cod_organizator#, denumire, banca, cont, cod_info_acces,
informatii, cod_localizare)
PERS_CONTACT(cod_pers_contact#, cod_organizator, nume, prenume,
directie, cod_localizare, cod_info_acces)
PREZENTARE(cod_prezentare#, denumire, data_start, data_final,
cod_soc_asig, cod_organizator, cod_locatie)
LOCATIE(cod_locatie#, denumire, tip, cod_localizare, cod_info_acces,
capacitate)
SPONSOR(cod_sponsor#, tip, nume, info, cod_localizare, cod_info_acces)
15
CASA_MODA(cod_casa_moda#, nume, cifra_afaceri, proprietar, director,
istoric, data_creare, cod_localizare, cod_info_acces)
CREATOR(cod_creator#, nume, prenume, data_nastere, data_angajare, tip,
mod_angajare, info, cod_casa_moda, cod_localizare, cod_info_acces)
VESTIMENTATIE(cod_vestimentatie#, denumire, valoare, descriere,
cod_creator, cod_model, cod_prezentare)
ACCESORIU(cod_vestimentatie#, cod_accesoriu#, cod_creator, descriere,
tip, valoare)
AGENTIE(cod_agentie#, nume, data_creare, director, cifra_afaceri, info,
cod_localizare, cod_info_acces)
ISTORIC(cod_model#, data_angajare#, data_final, cod_agentie, conditii)
LOCALIZARE(cod_localizare#, adresa, cod_postal, oras, tara)
INFO_CONTACT(cod_info_acces#, telefon_fix, telefon_mobil, mail, fax)
FIRMA_SEC(cod_firma_sec#, nume_firma, tip_servicii, director,
cod_localizare, cod_info_acces, observatii)
ANGAJAT_SEC(cod_angajat#, nume, prenume, data_nastere, specializare,
nivel, observatii, cod_info_acces, cod_firma_sec)
PAZA(cod_angajat#, cod_prezentare#, tip_paza, dotare, observatii)
SOC_ASIG(cod_soc_asig#, conditii, suma, director, observatii,
cod_localizare, nume_pers_contact_firma, cod_info_acces)
PARTICIPA(cod_prezentare#, cod_casa_moda#, tip, data)
FINANTEAZA(cod_sponsor#, cod_prezentare#, suma, banca, cont_emitent,
data_emitere, cod_ordin_plata)
PRIMESTE(cod_primeste#, cod_angajat, cod_prezentare, cod_casa_moda,
data_achitare, suma, cont, banca)
LIMBA(cod_pers_contact#, limba_cunoscuta#, niv_scris, niv_citit,
niv_vorbit)
16
3.4. Regulile lui Codd
Un SGBD relaţional îndeplineşte funcţiile unui SGBD, dar cu anumite

particularităţi care decurg din concepţia de organizare a datelor, respectiv
din modelul relaţional. Fiecare SGBD relaţional implementează modelul
relaţional într-o manieră proprie, care îl diferenţiază de restul sistemelor
relaţionale. Caracterizarea unui SGBD relaţional se poate realiza la nivelul
clasei sistemelor relaţionale, în sensul caracterizării globale, unitare în raport
cu celelalte tipuri de SGBD-uri, sau la nivelul SGBD-ului relaţional
individual în sensul caracterizării particularităţilor sale, în raport cu alte
SGBD-uri relaţionale.
Realizarea funcţiilor SGBD-urilor relaţionale se face cu ajutorul unor
mecanisme de lucru specifice, care le separă de sistemele nerelaţionale.
Dintre mecanismele de lucru de care dispune un SGBD relaţional se pot
menţiona:
• un limbaj relaţional pentru descrierea datelor la nivel fizic, logic şi
conceptual;
• un limbaj relaţional pentru prelucrarea datelor;
• mecanisme pentru controlul integrităţii semantice a datelor;
• mecanisme pentru optimizarea cererilor de date;
• mecanisme pentru asigurarea coerenţei datelor;
• utilitare pentru generarea de rapoarte, pentru generarea de
aplicaţii, pentru generarea unor statistici referitoare la starea şi
activitatea bazei de date etc.
În anul 1985, E.F. Codd a publicat un set de 13 reguli în raport cu care
un sistem de gestiune a bazelor de date poate fi apreciat ca relaţional. Niciun
sistem de gestiune a bazelor de date pus în vânzare pe piaţa comercială nu
respectă absolut toate regulile definite de Codd, dar acest lucru nu împiedică
etichetarea acestor sisteme drept relaţionale. Nu trebuie apreciat un SGBD
ca fiind relaţional sau nu, ci măsura în care acesta este relaţional, deci
numărul regulilor lui Codd pe care le respectă.
Regulile lui Codd au fost şi sunt cauza multor controverse. Unii le
consideră doar un exerciţiu academic, alţii pretind că produsele lor satisfac
majoritatea regulilor. De fapt, discuţiile în jurul acestor reguli au generat o
cunoaştere mai bună a caracteristicilor esenţiale ale unui SGBD relaţional,
atât din punctul de vedere al utilizatorilor, cât şi din cel al producătorilor de
software.
17
Regulile pot fi organizate în următoarele cinci domenii de
funcţionalitate: reguli fundamentale, reguli structurale, reguli de integritate,
reguli de prelucrare a datelor şi reguli privind independenţa datelor.
Regula 1 – regula gestionării datelor. Un SGBD relaţional trebuie să
fie capabil să gestioneze o bază de date prin posibilităţile sale relaţionale.
Practic, nicio implementare curentă de SGBD nu respectă această regulă,
deoarece implementările conţin atât caracteristici relaţionale cât şi
nerelaţionale.
Regula 2 – regula reprezentării informaţiei. Într-o bază de date
relaţională, informaţia este reprezentată la nivel logic sub forma unor
tabele ce poartă numele de relaţii. Este regula cea mai importantă şi
conform lui Codd, un SGBD care nu respectă această regulă, nu poate fi
considerat relaţional. Chiar şi meta-datele, conţinute în catalogul de sistem,
trebuie să fie stocate ca relaţii.
Regula 3 – regula accesului garantat la date. Fiecare valoare dintr-o
bază de date relaţională trebuie să poată fi adresată în mod logic printr-o
combinaţie formată din numele relaţiei, valoarea cheii primare şi numele
atributului.
Regula 4 – regula reprezentării informaţiei necunoscute. Un sistem
relaţional trebuie să permită utilizatorului definirea unui tip de date numit
„null“ pentru reprezentarea unei informaţii necunoscute la momentul
respectiv. Într-un SGBD relaţional trebuie să putem face diferenţa între
valoarea zero, un şir vid de caractere şi o valoare necunoscută.
Regula 5 – regula dicţionarelor de date. Asupra descrierii bazelor de
date (informaţii relative la relaţii, vizualizări, indecşi etc.) trebuie să se
poată aplica aceleaşi operaţii ca şi asupra datelor din baza de date.
Descrierea bazei de date este reprezentată la nivel logic sub forma unor
tabele care pot fi accesate în acelaşi mod ca şi datele efective. Prin urmare
există un singur limbaj de prelucrare atât a meta-datelor, cât şi a datelor.
Regula 6 – regula limbajului de interogare. Trebuie să existe cel puţin
un limbaj pentru prelucrarea bazei de date. În general, toate implementările
SQL respectă această regulă. Limbajul permite utilizatorilor să definească
relaţii şi vizualizări, să prelucreze datele interactiv sau prin intermediul
programului, să regăsească informaţia şi să o poată actualiza, să verifice şi să
corecteze datele de intrare, să implementeze constrângeri, să stabilească
limite pentru tranzacţii etc.
Regula 7 – regula de actualizare a vizualizării. Un SGBD trebuie să
poată determina dacă o vizualizare poate fi actualizată şi să stocheze
rezultatul interogării, ce defineşte vizualizarea, într-un dicţionar de tipul
18
unui catalog de sistem. Trebuie să existe un mecanism prin care să se poată
determina dacă anumite vizualizări pot fi actualizate sau nu. Regula
stabileşte că toate vizualizările care sunt teoretic reactualizabile pot fi
reactualizate şi de către sistemul de gestiune. Nu au fost încă descoperite
condiţiile pentru identificarea tuturor vizualizărilor care pot fi teoretic
reactualizate.
Regula 8 – regula limbajului de nivel înalt. Capacitatea de tratare a
unei relaţii de bază sau a unei vizualizări ca pe un singur operand se aplică
atât pentru operaţiile de regăsire a datelor, cât şi asupra operaţiilor de
inserare, actualizare şi ştergere a datelor. Un SGBD relaţional nu trebuie să
oblige utilizatorul să caute într-o relaţie, tuplu cu tuplu, pentru a regăsi
informaţia dorită. Operaţiile de prelucrare a datelor pot să fie aplicate atât în
mod interactiv cât şi prin program, într-un limbaj gazdă.
Regula 9 – regula independenţei fizice a datelor. Programele de
aplicaţie şi activităţile utilizatorilor nu depind de modul de depunere a
datelor sau de modul de acces la date. Într-un SGBD relaţional trebuie să se
separe aspectul fizic al datelor (stocare sau acces la date) de aspectul logic al
datelor.
Regula 10 – regula independenţei logice a datelor. Programele de
aplicaţie trebuie să fie transparente la modificările de orice tip efectuate
asupra datelor. Orice modificare efectuată asupra unei relaţii nu trebuie să
afecteze operaţiile de prelucrare a datelor.
Regula 11 – regula independenţei datelor din punct de vedere al inte-
grităţii. Regulile de integritate trebuie să fie definite într-un sublimbaj
relaţional de date, nu în programul de aplicaţie. SQL permite definirea de
restricţii privind integritatea datelor şi stocarea lor în catalogul de sistem. Cu
cât sunt mai multe constrângeri de integritate care pot fi întreţinute mai
degrabă de către SGBD, decât în cadrul fiecărui program aplicaţie, cu atât
garantarea calităţii datelor este mai bună.
distribuirii. Distribuirea datelor pe mai multe calculatoare dintr-o reţea de
comunicaţii de date nu trebuie să afecteze programele de aplicaţie. ANSI-
SQL nu menţionează regula în specificaţiile sale, deoarece este destul de
greu de respectat. De observat că regula nu cere ca SGBD-ul să accepte o
bază de date distribuite pentru a fi relaţional, dar stabileşte că limbajul de
interogare va rămâne acelaşi atunci când se va introduce această capacitate,
iar datele vor fi distribuite.
19
Regula 13 – regula versiunii procedurale a unui SGBD. Orice
componentă procedurală a unui SGBD trebuie să respecte aceleaşi restricţii
de integritate ca şi componenta relaţională. De exemplu, dacă în partea de
prelucrare a datelor a limbajului relaţional valoarea dintr-o coloană este de
tipul not null, orice altă metodă procedurală de accesare a acestei coloane nu
trebuie să permită introducerea unui null în această coloană. Prin urmare,
regulile de integritate exprimate într-un limbaj relaţional de un anumit nivel
nu pot fi distruse de un limbaj de nivel inferior.
Deoarece regulile lui Codd sunt prea severe pentru a fi respectate de
un SGBD operaţional, s-au formulat criterii minimale de definire a unui
SGBD relaţional.
Un SGBD este minimal relaţional dacă:
• toate datele din cadrul bazei sunt reprezentate prin valori în tabele;
• nu există pointeri observabili de către utilizator;
• sistemul suportă operatorii relaţionali de proiecţie, selecţie şi
compunere naturală, fără limitări impuse din considerente interne.
Un SGBD este complet relaţional dacă este minimal relaţional şi
satisface în plus condiţiile:
• sistemul suportă restricţiile de integritate de bază (unicitatea cheii
primare, constrângerile referenţiale, integritatea entităţii);
• sistemul suportă toate operaţiile de baza ale algebrei relaţionale.
20
4. NORMALIZAREA RELAŢIILOR
4.1. Preliminarii
În procesul modelării unei baze de date relaţionale, o etapă importantă o
reprezintă normalizarea relaţiilor conceptuale. Aceasta presupune obţinerea de
relaţii „moleculare“, fără a pierde nimic din informaţie, având scopul de a
elimina redundanţa şi anomaliile reactualizării informaţiilor. Tehnica
normalizării permite determinarea unei scheme conceptuale rafinate, printr-un
proces de ameliorare progresivă a unei scheme conceptuale iniţiale a bazei de
date relaţionale. După fiecare etapă de ameliorare, relaţiile bazei de date ating
un anumit grad de perfecţiune, deci se află într-o anumită formă normală.
Trecerea unei relaţii dintr-o formă normală în alta presupune eliminarea unui
anumit tip de dependenţe nedorite, care sunt transformate în dependenţe
admisibile, adică dependenţe care nu provoacă anomalii.
Procesul de ameliorare progresivă a schemei conceptuale trebuie să
satisfacă următoarele cerinţe:
• să garanteze conservarea datelor, adică în schema conceptuală
finală trebuie să figureze toate datele din cadrul schemei iniţiale;
• să garanteze conservarea dependenţelor dintre date, adică în
schema finală fiecare dependenţă trebuie să aibă determinantul şi
determinatul în schema aceleiaşi relaţii;
• să reprezinte o descompunere minimală a relaţiilor iniţiale, adică
nici una din relaţiile care compun schema finală nu trebuie să fie
conţinută într-o altă relaţie din această schemă.
Există două metode pentru a modela baze de date relaţionale fără
anomalii sau pierderi de informaţie.
• Schema descompunerii pleacă de la o schemă relaţională
universală care conţine toate atributele bazei de date. Schema se
descompune prin proiecţii succesive în subrelaţii. Descompunerea
se opreşte atunci când continuarea ei ar duce la pierderi de
informaţie. Algoritmii de descompunere se bazează, în general, pe
descrierea formală a dependenţei dintre atribute.
• Schema sintezei pleacă de la o mulţime de atribute independente.
Utilizând proprietăţi de semantică şi legături între atribute se pot
compune noi relaţii, astfel încât acestea să nu sufere de anumite
anomalii pe care dorim să le evităm. Algoritmii de sinteză se
bazează în general pe teoria grafurilor pentru a reprezenta
legăturile între atribute.
21
4.2. Dependenţe funcţionale
Unul dintre conceptele principale asociate normalizării este cel de

dependenţă funcţională, care descrie formalizat legăturile dintre atribute.
Dependenţa funcţională este o proprietate a semanticii atributelor dintr-o
relaţie. Semantica indică modul în care sunt legate atributele şi specifică
dependenţele dintre ele. Atunci când există o dependenţă funcţională, ea este
specificată ca o constrângere între atribute.
O relaţie universală este o relaţie ce grupează toate atributele care
modelează sistemul real cercetat. Fie E, mulţimea dependenţelor considerate
de proiectantul bazei pentru o schemă relaţională sau pentru o relaţie
universală.
Plecând de la o mulţime de proprietăţi formale ale dependenţelor,
proprietăţi considerate drept reguli de deducţie (axiome), poate fi obţinută
mulţimea maximală de dependenţe asociate lui E. Această mulţime defineşte
închiderea lui E.
Fie R(A1 , A2 , ..., An ) o schemă relaţională şi fie X, Y submulţimi de
atribute ale lui R. X determină funcţional Y sau Y depinde funcţional (FD)
de X, dacă pentru orice relaţie r (valoare curentă a lui R) nu există două
tupluri care să aibă aceleaşi valori pentru atributele lui X şi să aibă valori
diferite pentru cel puţin un atribut din Y. Cu alte cuvinte, o valoare a lui X
determină unic o valoare a lui Y. Notaţia utilizată pentru desemnarea
dependenţei funcţionale este X → Y. Altfel spus:
Definitie: Fie R un tabel relational si X si Y două submultimi de coloane
ale lui R. Spunem că X determină functional pe Y sau că Y depinde
functional de X dacă nu există două rânduri în tabelul R care să aibă aceleasi
valori pentru coloanele din X si să aibă valori diferite pentru coloanele din Y.
Dependenţa funcţională X → Y reprezintă o constrângere aplicată
tuplurilor relaţiei R, în sensul că oricare două tupluri din R care au aceeaşi
valoare pentru X trebuie să ia aceeaşi valoare şi pentru Y.
Dacă pentru fiecare valoare a lui X există cel mult o valoare a lui Y,
spunem că X este determinant iar Y este determinat.
Comparând toate submulţimile de atribute ale unei relaţii şi
determinând legăturile dintre ele, se pot obţine toate dependenţele
funcţionale pe care o relaţie le satisface. Această abordare nu este eficientă,
consumând mult timp. Există posibilitatea ca, ştiind anumite dependenţe
funcţionale şi utilizând reguli de deducţie, să fie obţinute toate dependenţele
funcţionale.
22
Fie X, Y, Z, W mulţimi de atribute ale unei scheme relaţionale R şi fie
următoarele reguli de inferenţă (axiome) prin care noi dependenţe
funcţionale pot fi deduse din cele date:
Ax1 – reflexivitate. X → X. Mai general, dacă Y ⊆ X, atunci X → Y.
Ax2 – creşterea determinantului. Pot fi considerate trei formulări echi-
valente pentru această axiomă.
1. Dacă X → Y şi X ⊆ Z, atunci Z → Y.
2. Dacă X → Y şi W ⊆ Z, atunci X ∪ Z → Y ∪ W.
3. Dacă X → Y atunci X ∪ Z → Y ∪ Z.
Ax3 – tranzitivitate. Dacă X → Y şi Y → Z, atunci X → Z.
4.3. Necesitatea normalizării
Anomaliile care apar în lucrul cu baze de date se produc datorită

dependenţelor care există între datele din cadrul relaţiilor bazei. Aceste
anomalii fac extrem de dificil lucrul cu baza de date. Aceste anomalii vor fi
comentate cu ajutorul unui exemplu.
Se consideră o vizualizare (VP) asupra schemei relaţionale
PREZENTARE ce conţine doar atributele cod_prezentare#, denumire,
luna_start, cod_organizator. Aceste atribute reprezintă pentru fiecare
prezentare de modă: codul acesteia, denumirea, luna în care începe prezentarea
şi codul organizatorului.
Se consideră constrângerea: „toate prezentările de modă cu acelaşi
nume încep în aceeaşi lună“.
cod_prezentar denumire luna_start cod_organizato

e r
1 primavara mai 11
2 primavara mai 37
3 primavara mai 11
4 iarna martie 32
5 toamna august 11
Fig. 4.1. Vizualizarea VP
Datorită dependenţei introduse pot exista: anomalii la inserare,

modificare sau ştergere, redundanţă în date, probleme de reconexiune.
1. Redundanţă logică. Cuplul (primavara, mai) apare de trei ori.
23
2. Anomalie la inserţie. Dacă se doreşte includerea unei prezentări
de modă, care va incepe în luna aprilie şi va avea denumirea
„veselie“, atunci perechea (veselie, aprilie) poate fi inserată în
relaţia VP doar dacă se defineşte o nouă valoare pentru cheia
primară.
3. Anomalie la ştergere. Dacă este ştearsă înregistrarea pentru care
codul prezentării are valoarea 4, atunci se pierde informaţia că
prezentarea având denumirea „iarna“ a început în luna martie.
4. Anomalie la modificare. Dacă se modifică luna de început a
prezentării „primavara“ de la mai la februarie, atunci costul
modificării este mare pentru a modifica toate înregistrările, iar
dacă se modifică doar o înregistrare atunci constrângerea nu va
mai fi verificată.
Anomaliile au apărut datorită dependenţei funcţionale (constrângerii)
introduse anterior.
Normalizarea are drept scop: suprimarea redundanţei logice, evitarea
anomaliilor la reactualizare, rezolvarea problemei reconexiunii. Există o
teorie matematică a normalizării al cărei autor este E.F. Codd. Soluţia lui
E.F. Codd este construirea unor tabele standard (forme normale).
Normalizarea este procesul reversibil de transformare a unei relaţii, în
relaţii de structură mai simplă. Procesul este reversibil în sensul că nicio
informaţie nu este pierdută în timpul transformării. O relaţie este într-o formă
normală particulară dacă ea satisface o mulţime specificată de constrângeri.
Procesul normalizării se realizează plecând de la o relaţie universală ce
conţine toate atributele sistemului de modelat, plus o mulţime de anomalii.
Orice formă normală se obţine aplicând o schemă de descompunere.
4.4. Forme normale
Formele normale ale relaţiilor din baze de date relaţionale sunt

definite în raport cu anomaliile care pot apărea în lucrul cu aceste relaţii,
deci în funcţie de dependenţele nedorite care se manifestă în cadrul relaţiilor.
Pe măsură ce relaţia este transformată în forme superioare, devine din
ce în ce mai restrictivă ca format şi mai puţin expusă anomaliilor la
reactualizare. Altfel spus:
Definitie: Normalizarea reprezintă procesul de descompunere a unui
tabel relational în mai multe tabele care satisfac anumite reguli si care
stochează aceleasi date ca si tabelul initial astfel încât să fie eliminate
redundanta în date si anomaliile la actualizare.
24
Prima formă normală (FN1)
O relaţie este în prima formă normală dacă fiecărui atribut care o

compune îi corespunde o valoare indivizibilă (atomică). În plus, un tuplu nu
trebuie să conţină atribute sau grupuri de atribute repetitive.
Această formă figurează ca cerinţă minimală în majoritatea sistemelor
relaţionale.
Algoritm AFN1 (aducerea unei relaţii în FN1 prin eliminarea
atributelor compuse şi a celor repetitive)
1. Se introduc în relaţie, în locul atributelor compuse, componentele
acestora.
2. Se plasează grupurile de atribute repetitive, fiecare în câte o nouă
relaţie.
3. Se introduce în schema fiecărei noi relaţii de la pasul 2 cheia
primară a relaţiei din care a fost extras atributul repetitiv.
4. Se stabileşte cheia primară a fiecărei noi relaţii create la pasul 2.
Aceasta este compusă din cheia introdusă la pasul 3, precum şi din
atribute proprii ale acestor noi relaţii.

O relaţie R este în a doua formă normală dacă şi numai dacă:
• fiecare atribut care nu este cheie (nu participă la cheia primară)
este dependent de întreaga cheie primară.
A doua condiţie exprimă necesitatea dependenţei totale de cheia
primară. Această formă normală interzice manifestarea unor dependenţe
funcţionale parţiale în cadrul relaţiei R.
Fie relaţia R(K1, K2, X, Y), unde K1 şi K2 definesc cheia primară, iar X şi Y
sunt mulţimi de atribute, astfel încât K1 → X. Din cauza dependenţei
funcţionale K1 → X care arată că R nu este în FN2, se înlocuieşte R (fără
pierdere de informaţie) prin două proiecţii R1(K1, K2, Y) şi R2(K1, X).
Caracterul reversibil al normalizării
Prin caracter reversibil al normalizării se întelege faptul că descompunerea

se face fără pierdere de informatie, adică tabelul initial poate fi reconstituit
prin compunerea naturală, pe atribute comune, a tabelelor rezultate.
25
Pentru un tabel R care se descompune prin proiectie în mai multe tabele: R1,
R2, … Rn, conditia de descompunere fără pierdere de informatie presupune
ca în urma operatiei de compunere naturală a tabelelor R1, R2, … Rn să se
obtină tabelul R.
Regula Casey-Delobel (caz particular de descompunere fără pierdere de

informatie):
Fie un tabel R(X, Y, Z) care se descompune prin proiectie în tabelele R1(X,

Y) si R2(X, Z) unde prin X notăm setul de coloane comune ale tabelelor R1
si R2, iar prin Y si Z, coloanele specifice lui R1, respectiv R2. Conditia de
descompunere fără pierdere de informatie presupune ca tabelul R să fie
obtinut prin compunerea naturală a tabelelor R1 si R2.
În SQL:
SELECT R1.X, R1.Y, R2.Z

FROM R1, R2
WHERE R1.X = R2.X
Algoritm AFN2 (aducerea unei relaţii în FN2 prin eliminarea depen-
denţelor funcţionale parţiale din cadrul unor relaţii aflate în FN1)
1. Pentru fiecare dependenţă funcţională parţială se creează o nouă
relaţie având schema formată din determinantul şi determinatul
acestei dependenţe.
2. Se elimină din cadrul relaţiei iniţiale atributele care formează
determinatul dependenţei parţiale.
3. Dacă în relaţia iniţială există mai multe dependenţe parţiale cu
acelaşi determinant, pentru acestea se creează o singură relaţie cu
schema formată din determinant (luat o singură dată) şi din
determinaţii dependenţelor considerate.
4. Se determină cheia primară a fiecărei noi relaţii create. Aceasta va
conţine atributele din determinantul dependenţei funcţionale
parţiale care au stat la baza constituirii relaţiei.
5. Dacă noile relaţii create conţin dependenţe parţiale, atunci se face
transfer la pasul 1, altfel procesul de aducere la FN2 s-a terminat.
26
Exemplu
Fie schema relaţională PARTICIPA (cod_prezentare#,
cod_casa_moda#, tip, data, data_start, data_final, denumire)
Pentru relaţia PARTICIPA sunt adevărate dependenţele:

{cod_prezentare} → {data_start, data_final, denumire}
{cod_prezentare, cod_casa_moda} → {data, tip}
Relaţia PARTICIPA este în FN1, dar nu este în FN2 deoarece
atributele data_start, data_final şi denumire nu depind de codul casei de
modă, deci nu depind de întreaga cheie primară.
Pen tru a o b iţne o relaţie în FN2 se aplică reg u al Casey Delo b el şi
relaţia PARTICIPA se proiectează în două relaţii:
PARTI1(cod_prezentare#, data_start, data_final, denumire)
PARTI2(cod_prezentare#, cod_casa_moda#, data, tip).
Notă (reamintim C2):

Entitatea PREZENTARE are atributele: cod_prezentare, denumire,
data_start, data_final, cod_organizator, cod_soc_asig, cod_locatie.
Entitatea CASA_MODA are atributele: cod_casa_moda, nume, cifra_afaceri,
proprietar, director, istoric, data_creare, cod_localizare, cod_info_acces.
Atribute ale relatiei PARTICIPA
tip = variabilă de tip caracter, de lungime maximă 15, care reprezintă
modalitatea în care o casă de modă participă la o prezentare, în sensul că
poate fi organizator sau neorganizator.
data = variabilă de tip dată calendaristică reprezentând ziua în care defilează
modelele casei de modă. Atributul nu este multiplu, deoarece s-a presupus că
defilarea unei case de modă are loc într-o singură zi.
Alt Exemplu:
Fie tabelul VANZARI care se foloseste la înregistrarea tranzactiilor unui

magazin ce vinde articole la comandă.
VANZARI (cod_client#, cod_comanda#, cod_articol#, nume_client,

nr_telefon, data, nume_articol, cost_articol, cantitate)
A1 C1 P1 Popescu 415355 08.10.04 camasa 400000 2

A1 C1 P3 Popescu 415355 08.10.04 tricou 200000 1
27
A2 C2 P1 Ionescu 596322 09.10.04 camasa 400000 3
A2 C2 P3 Ionescu 596322 C2 09.10.04 tricou 200000 2
A2 C2 P2 Ionescu 596322 09.10.04 pantaloni 800000 1
A1 C3 P3 Popescu 415355 10.10.04 tricou 200000 3
A3 C4 P1 Marinescu 546229 C4 10.10.04 P1 camasa 400000 1
Tabelul de mai sus prezintă următoarele deficiente:
a) redundante în date:
- informatia (P1, camasa, 400000) este specificata de 3 ori
- informatia (A1, Popescu, 415355) este specificata de 3 ori
- informatia (A2, Ionescu, 196322) este specificata de 3 ori
- s. a. m. d.
b) anomalii la actualizare:
- anomalie la insertie
Dacă magazinul achizitionează un nou articol (P4, pantofi, 980000)
informatia nu poate fi introdusă în tabel (un nou tuplu) pentru că s-ar
introduce o valoare Null în cheia primară (cod_comanda).
- anomalie la stergere
Dacă este anulat articolul P2 în cadrul comenzii C2 se pierde informatia
referitoare la numele si costul articolului respectiv.
- anomalie la modificare
Dacă se modifică numărul de telefon al unui client, modificarea trebuie
facută în toate tuplurile (liniile) unde apare numele acelui client.
În tabelul VANZARI există următoarele dependente functionale în
care determinantul nu este cheie a tabelului:
(cod_articol) → (nume_articol, cost_articol)

(cod_comanda) → (data, cod_client, nume_client, nr_telefon)
(cod_client) → (nume_client, nr_telefon)
Pen tru a o b iţne o relaţie în FN2 se aplică reg u al Casey Delo b el şi
relaţia VANZARI se proiectează în trei relaţii:
VANZARI1(cod_articol# nume_articol, cost_articol)

VANZARI2(cod_comanda#, data, cod_client, nume_client, nr_telefon)
VANZARI3(cod_client #, nume_client, nr_telefon)
28
Intuitiv, o relaţie R este în a treia formă normală dacă şi numai dacă:
• fiecare atribut care nu este cheie (nu participă la o cheie) depinde
direct de cheia primară.
Fie R o relaţie, X o submulţime de atribute ale lui R şi A un atribut al
relaţiei R. A este dependent tranzitiv de X dacă există Y astfel încât X → Y şi
Y → A (unde A nu aparţine lui Y şi Y nu determină pe X). De exemplu, dacă
au loc dependenţele K 1 , K 2 , K 3 → A1 şi K 1 , K 2 , A1 → A 2 , atunci K 1 , K 2 , K 3
→ K 1 , K 2 , A 1 şi K 1 , K 2 , A 1 → A 2 . Prin urmare, A2 este dependent tranzitiv
de K 1 , K 2 , K 3 .
Formal, o relaţie R este în a treia formă normală dacă şi numai dacă:
• fiecare atribut care nu este cheie (nu participă la o cheie) nu este
dependent tranzitiv de nicio cheie a lui R.
A doua condiţie interzice utilizarea dependenţelor funcţionale tranzitive
în cadrul relaţiei R.
Prin urmare, o relaţie este în FN3 dacă şi numai dacă fiecare
atribut care nu este cheie depinde de cheie, de întreaga cheie şi numai de
cheie.
Pentru a obţine o relaţie FN3 se poate aplica regula de descompunere
Casey-Delobel. Fie relaţia R(K, X 1 , X 2 , X3 ), unde atributul X 2 depinde
tranzitiv de K, iar K este cheia primară a lui R. Presupunem că K → X 1 →
X2 . Din cauza dependenţei funcţionale X1 → X 2 care arată că R nu este în
FN3, se înlocuieşte R (fără pierdere de informaţie) prin două proiecţii R1(K,
X1 , X 3 ) şi R2(X 1 , X2 ).
Dependenţa tranzitivă poate fi mai complexă. Fie K 1 o parte a cheii K.
Tranzitivitatea poate fi de forma K → Y → X 2 unde Y = {K 1 , X 1 }. În acest
caz, R poate fi descompusă în R1(K, X1 , X 3 ) şi R2(K 1 , X 1 , X2 ).
Algoritm AFN3 (aducerea unei relaţii FN2 în FN3 prin eliminarea
dependenţelor funcţionale tranzitive)
1. Pentru fiecare dependenţă funcţională tranzitivă se transferă
atributele implicate în dependenţa tranzitivă într-o nouă relaţie.
2. Se determină cheia primară a fiecărei noi relaţii create la pasul 1.
3. Se introduc în relaţia iniţială, în locul atributelor transferate, cheile
primare determinate la pasul 2.
29
4. Se reanalizează relaţia iniţială. Dacă în cadrul ei există noi
dependenţe tranzitive, atunci se face transfer la pasul 1, altfel
procesul de aducere la FN3 s-a terminat.
Exemplu
Fie schema relaţională PREZENT(cod_prezentare#, data_start,
data_final, denumire, cod_locatie, capacitate, cod_info_acces).
Pentru relaţia PREZENT sunt adevărate dependenţele:
{cod_prezentare} → {data_start, data_final, denumire, cod_locatie}
{cod_locatie} → {capacitate, cod_info_acces}
Relaţia PREZENT este în FN2, dar nu este în FN3 deoarece atributele
capacitate, cod_info_acces depind indirect de cheia primară, prin
intermediul atributului cod_locatie.
Pentru a obţine o relaţie în FN3 se aplică regula Casey-Delobel şi
relaţia PREZENT se proiectează în două relaţii, prin eliminarea
dependenţelor funcţionale tranzitive.
PREZENT1(cod_prezentare#, data_start, data_final, denumire, cod_locatie)
PREZENT2(cod_locatie#, capacitate, cod_info_acces)
Forma normală Boyce-Codd (BCNF)

Determinantul este un atribut sau o mulţime de atribute neredundante,
care constituie un identificator unic pentru alt atribut sau altă mulţime de
atribute ale unei relaţii date.
Intuitiv, o relaţie R este în forma normală Boyce-Codd dacă şi numai
dacă fiecare determinant este o cheie candidat.
Formal, o relaţie R este în forma normală Boyce-Codd dacă şi numai
dacă pentru orice dependenţă funcţională totală X → A, X este o cheie a lui
R.
Algoritm ABCNF (aducerea unei relaţii FN3 în BCNF prin
eliminarea dependenţelor funcţionale ai căror determinanţi nu sunt chei
candidat)
1. Dacă relaţia conţine unul sau cel mult două atribute, atunci nu pot
exista dependenţe noncheie şi deci relaţia este în BCNF.
2. Dacă relaţia conţine mai mult de două atribute, se caută dacă ea
conţine dependenţe noncheie. Dacă nu există astfel de dependenţe,
relaţia este în BCNF.
3. Pentru fiecare dependenţă noncheie X → Y se creează două relaţii.
Una dintre ele va avea schema formată din atributele {X, Y}, iar
30
cealaltă va avea schema formată din toate atributele relaţiei
iniţiale, mai puţin Y.
4. Se reiau paşii 1, 2, 3 pentru relaţiile obţinute la pasul 3.
Exemplu
Se consideră relaţia FINANTEAZA1, ce leagă entităţile
PREZENTARE şi SPONSOR. Ea are cardinalitatea many to many şi va
genera un tabel asociativ. Se presupune că acest tabel are schema
relaţională:
FINANTEAZA1(cod_prezentare#, cod_sponsor#, nume_prezentare,
cod_ordin_plata).
Pentru exemplul analizat se presupune că numele prezentărilor sunt
unice. Prin urmare, în orice moment fiecare prezentare are un cod unic şi
un nume unic. Cheile candidat sunt {cod_prezentare, cod_sponsor},
respectiv {nume_prezentare, cod_sponsor}.
Între atributele relaţiei există dependenţele:
{cod_prezentare, cod_sponsor} → {cod_ordin_plata}
{cod_prezentare} → {nume_prezentare}
Tabelul nu este în BCNF deoarece conţine doi determinanţi,
cod_prezentare şi nume_prezentare, care nu sunt chei candidat pentru
tabelul respectiv. Ambele atribute sunt determinanţi deoarece fiecare îl
determină pe celălalt.
Soluţia problemei constă în divizarea relaţiei în două proiecţii
conform tehnicii Casey-Delobel.
PREZENTARE(cod_prezentare#, nume_prezentare)
FINANTEAZA(cod_prezentare#, cod_sponsor#, cod_ordin_plata)

Dacă BCNF elimină redundanţele datorate relaţiilor singulare, FN4
elimină redundanţele datorate relaţiilor m:n, adică datorate dependenţei
multiple.
Intuitiv, o relaţie R este în a patra formă normală dacă şi numai dacă
relaţia este în BCNF şi nu conţine relaţii m:n independente.
Exemplu
Fie schema relaţională
PERS_CONTACT(cod_pers#, limba_cunoscuta, nr_telefon).
Se presupune că o persoană de contact poate cunoaşte mai multe limbi
străine şi poate avea mai multe numere de telefon. Între atributele relaţiei
există multidependenţele:
31
cod_pers# →→ limba_cunoscuta
cod_pers# →→ nr_telefon.
Pentru a aduce relaţia PERS_CONTACT (care este în BCNF) în FN4,
aceasta se va diviza în două proiecţii :
PERS_CONTACT1(cod_pers#, limba_cunoscuta)
PERS_CONTACT1(cod_pers#, nr_telefon).

Semnificaţia lui FN5 este mai mult „academică“, ea apărând rar în
practică. A cincea formă normală îşi propune eliminarea redundanţelor care
apar în relaţii m:n dependente. În general, aceste relaţii nu pot fi
descompuse. S-a arătat că o relaţie de tip 3 este diferită de trei relaţii de tip
2. Există totuşi o excepţie, şi anume, dacă relaţia este ciclică.
Intuitiv, o relaţie R este în forma normală 5 dacă şi numai dacă:
1. relaţia este în FN4;
2. nu conţine dependenţe ciclice.
Exemplu
Se consideră o relaţie ce conţine informaţii despre creatori,
vestimentaţiile create de aceştia şi accesoriile corespunzătoare. Se consideră
schema relaţională CREARE(cod_vestimentatie#, cod_creator#,
cod_accesoriu#).
Se presupune că fiecare creator poate crea una sau mai multe
vestimentaţii. Fiecare vestimentaţie poate fi creată de unul sau mai mulţi
creatori. Similar, fiecare creator este responsabil de crearea unuia sau a mai
multor accesorii, iar fiecare accesoriu este creat de unul sau mai mulţi
creatori. Fiecare accesoriu apare în una sau mai multe vestimentaţii, iar
fiecărei vestimentaţii i se ataşează unul sau mai multe accesorii.
Mai mult chiar, dacă creatorul C creează vestimentaţia V, iar
accesoriul A este ataşat lui V, iar C este este responsabil de A, atunci C
creează accesoriul A pentru vestimentaţia V.
Ţinând seama de constrângerile impuse modelului se obţin
dependenţele:
{cod_vestimentatie#, cod_creator#} → {cod_accesoriu}
{cod_vestimentatie#, cod_accesoriu#} → {cod_creator}
{cod_accesoriu#, cod_creator#} → {cod_vestimentatie}.
Datorită dependenţelor formulate anterior, relaţia nu este în FN5. Ea
se poate rupe prin proiecţie în trei relaţii:
CREARE1(cod_vestimentatie#, cod_creator#)
32
CREARE2(cod_vestimentatie#, cod_accesoriu#)
CREARE3(cod_creator#, cod_accesoriu#).
În acest caz, sunt evidente relaţiile:
CREARE ≠ JOIN(CREARE1, CREARE2)
CREARE = JOIN(JOIN(CREARE1, CREARE2), CREARE3).
Concluzii:
1. FN1 → FN2 elimină redundanţele datorate dependenţei netotale a
atributelor care nu participă la o cheie, faţă de cheile lui R. Se
suprimă dependenţele funcţionale care nu sunt totale.
2. FN2 → FN3 elimină redundanţele datorate dependenţei tranzitive.
Se suprimă dependenţele funcţionale tranzitive.
3. FN3 → BCNF elimină redundanţele datorate dependenţei
funcţionale. Se suprimă dependenţele în care partea stângă nu este
o supercheie.
4. BCNF → FN4 elimină redundanţele datorate multidependenţei. Se
suprimă toate multidependenţele care nu sunt şi dependenţe
funcţionale.
5. FN4 → FN5 elimină redundanţele datorate dependenţei ciclice. Se
suprimă toate join-dependenţele care nu sunt implicate de o cheie.
6. BCNF, FN4 şi FN5 corespund la regula că orice determinant este
o cheie, dar de fiecare dată dependenţa cu care se defineşte deter-
minantul este alta şi anume dependenţa funcţională,
multidependenţa sau join-dependenţa.
7. Descompunerea unei relaţii FN2 în FN3 conservă datele şi
dependenţele, pe când descompunerea unei relaţii FN3 în BCNF
şi, respectiv, a unei relaţii BCNF în FN4 conservă doar datele.
33
Limbajul SQL de interogare a datelor (DQL – Data Query
Language) include o singură comandă SELECT, care este cea mai
folosită pentru a obţine date din baza de date, astfel încât acestea să fie
prelucrate de o anumită aplicaţie sau să fie afişate. Rezultatul unei
instrucţiuni SELECT, numit şi set de rezultate, este returnat sub forma
unui tabel. Deoarece SQL este un limbaj neprocedural, se specifică
rezultatele pe care le doriţi să le obţineţi, nu şi modul lor de obţinere.
Instrucţiunea SELECT de bază
Cererea (interogarea) este realizată de instrucţiunea SELECT. Cu ajutorul

ei pot fi extrase submulţimi de valori atât pe verticală (coloane), cât şi pe
orizontală (linii) din unul sau mai multe tabele. Sintaxa comenzii este
simplă, apropiată de limbajul natural.
SELECT [ALL | DISTINCT]
{* | listă de atribute selectate | expr AS alias}
FROM { [schema.]tabel [alias_tabel] }
[WHERE condiţie]
[GROUP BY listă de expresii
[HAVING condiţie]]
[ORDER BY {expresie | poziţie | c_alias} [ASC | DESC]]
Forma elementară a instrucţiunii SELECT conţine două clauze:

SELECT [DISTINCT] - Specifică lista de coloane care
urmează să fie returnate în setul de rezultate, separate prin virgule. Se
poate folosi simbolul asterisc (*) în locul listei de coloane pentru a selecta
toate coloanele dintr-un tabel sau dintr-o vizualizare. Cuvântul cheie
DISTINCT poate fi adăugat după cuvântul cheie SELECT pentru a
elimina rândurile duplicate din rezultatele interogării.
FROM - Specifică lista tabelelor sau vizualizărilor din care
urmează să fie selectate datele. În locul numelor reale ale tabelelor sau
vizualizărilor se poate folosi sinonime, adică pseudonime pentru tabele
sau vizualizări definite în baza de date.
Prezenţa clauzelor SELECT şi FROM este obligatorie deoarece acestea
specifică coloanele selectate, respectiv tabelele din care se vor extrage
datele. Tabelele specificate în clauza FROM pot fi urmate de un alias,
care va reprezenta numele folosit pentru referirea tabelului respectiv în
cadrul instrucţiunii.
1
Eliminarea duplicatelor se poate realiza folosind clauza
DISTINCT. Dacă nu se specifică parametrul DISTINCT, parametrul ALL
este implicit şi are ca efect afişarea dublurilor.
Simbolul “*” permite selectarea tuturor atributelor din
tabelele asupra cărora se execută cererea. Atributele sau expresiile din
lista clauzei SELECT pot conţine alias-uri, care vor reprezenta numele
câmpurilor respective în cadrul tabelului furnizat ca rezultat de
instrucţiunea SELECT.
Clauza WHERE poate fi folosită pentru a impune anumite
condiţii liniilor din care se vor extrage atributele specificate în clauza
SELECT.
Clauza GROUP BY grupează înregistrările după anumite
câmpuri; în cazul prezenţei acestei clauze, clauza HAVING poate impune
restricţii suplimentare asupra rezultatului final.
Ordonarea înregistrărilor se poate face cu ajutorul clauzei
ORDER BY. Cu ajutoru l p arametrilor ASC şi DESC se p o ate sp ecifica
ordonarea crescătoare, respectiv descrescătoare a înregistrărilor. Pentru o
secvenţă crescătoare valorile null sunt afişate ultimele. Dacă nu se face
nici o specificaţie, atunci ordinea de returnare este la latitudinea server-
ului.
În exemplul următor se selectează coloanele:

COD_G EN_ FILM, MPAA_RATING_COD şi TITLU_FILM din
tabelul FILM.
SELECT COD_GEN_FILM, COD_ RATING, TITLU_FILM
FROM FILM;
Pseudonime pentru numele coloanelor
In setul de rezultate din interogări numele coloanelor din tabel

apare automat ca titlu de coloane în interogare. Dacă se doreşte un alt
nume pentru coloanele unei interogări se folosesc pseudonime.
Pseudonimele (aliases) specificate devin numele coloanelor din setul
de rezultate. Pseudonimele nu există decât după rularea instrucţiunii SQL,
aşa că nu pot fi folosite în alte părţi ale instrucţiunii SQL. Pseudonimul
unei coloane este specificat prin plasarea cuvântului cheie ”AS" după
numele coloanei în lista SELECT (cu cel puţin un spaţiu înainte şi după),
urmat de numele dorit pentru a fi atribuit coloanei în setul de rezultate.
SELECT COD_GEN_FILM AS GEN, MPAA_RATING_COD AS
RATING, TITLU_FILM AS FILM
FROM FILM;
2
Dacă în interiorul alias-ului apare un spaţiu liber sau caractere
speciale, atunci alias-ul trebuie scris între ghilimele.
SELECT dateres–dataim ”numar zile”
FROM imprumuta;
Sortarea rezultatelor
Rezultatele interogărilor sunt deseori mult mai utile dacă se

specifică pentru rândurile returnate o ordine care să aibă o semnificaţie
pentru persoana sau aplicaţia care foloseşte informaţiile. În SQL, acest
lucru este făcut prin adăugarea în instrucţiunea SELECT a clauzei ORDER
BY, cu o listă de una sau mai multe coloane care vor fi folosite pentru
sortarea rândurilor în ordine ascendentă sau descendentă, în conformitate cu
valorile datelor din coloane. De asemenea, se ţine seama de următoarele
aspecte:
Ordinea prestabilită pentru fiecare coloană este ascendentă, dar se
poate adăuga cuvântul cheie ASC după numele coloanei pentru obţinerea
unei ordonări ascendente sau cuvântul cheie DESC pentru obţinerea unei
ordonări descendente.
Nu este obligatoriu ca numele coloanelor din lista ORDER BY să
fie incluse şi în lista de rezultate (adică în lista SELECT).
Motorul SQL din SGBD va găsi cea mai bună cale de ordonare a
coloanelor. În general, sortarea datelor este un proces costisitor din punct
de vedere al resurselor de calcul, aşa că majoritatea sistemelor SGBD
folosesc un index pentru accesul la rânduri în ordinea dorită, presupunând
că există, şi fac o sortare propriu-zisă numai ca ultimă soluţie.
Se poate folosi pseudonimele coloanelor în clauza ORDER BY,
dar dacă se face acest lucru se forţează motorul SQL să sorteze rezultatele
abia după rularea interogării.
În locul coloanelor, se poate specifica în lista de ordonare poziţia
relativă a coloanelor. De exemplu, clauza ORDER BY 1,2 va sorta
rezultatele în ordine ascendentă după primele două coloane din setul de
rezultate. Numărul specificat nu are nici o legătură cu poziţia coloanei în
tabelul sau vizualizarea sursă. Această opţiune nu este agreată în
programarea SQL formală, deoarece dacă ulterior cineva modifică
interogarea, este posibil să amestece coloanele din lista SELECT, fără să-
şi dea seama că astfel schimbă şi coloanele folosite pentru sortarea
rezultatelor.
Exemplu:
SELECT MPAA_ RATING_COD AS RATING,
COD_GEN_FILM AS GEN, TITLU_FILM AS FILM
3
FROM FILM
ORDER BY MPAA_RATING_COD, COD_GEN_FILM ;
Dacă dorim să ordonăm acum crescător după rating şi descrescător

după gen, atunci instrucţiunea de mai sus modificată va fi
SELECT MPAA_ RATING_COD AS RATING,

COD_GEN_FILM AS GEN, TITLU_FILM AS FILM
FROM FILM
ORDER BY
MPAA_RATING_COD ASC, COD_GEN_FILM DESC;
Observaţie:
Oracle va afişa titlu de coloana la dimensiunea maximă a valorilor
din coloana(de ex. dacă în coloana RATING val cea mai mare este de 5
caractere, interogarea va afişa RATIN). În noua versiune de SQL produs
de Oracle, iSQL*Plus, nu mai prescurtează.
Exemplu :
SELECT titlu, autor, pret, coded as domeniu
from carte
order by coded, autor;
SELECT titlu, autor, pret, coded as domeniu

from carte
order by coded desc, pret;
Se observa ca domeniu este trunchiat la 5 caractere, DOMEN
4
Utilizarea clauzei WHERE pentru filtrarea rezultatelor
SQL foloseşte clauza WHERE pentru a filtra rândurile ce urmează

să fie afişate. O interogare fără o clauză WHERE returnează un set de
rezultate care conţine toate rândurile din tabelele sau vizualizările referite
în clauza FROM. Dacă este inclusă o clauză WHERE, sunt folosite
regulile algebrei booleene, evaluând clauza WHERE pentru fiecare rând
de date. În rezultatele interogării sunt afişate numai rândurile pentru care
clauza WHERE este evaluată la valoarea logică „adevărat".
Operatorii utilizați în clauza WHERE se impart în patru categorii:
- Operatori de comparare
- Operatori conjuctivi
- Operatori logici
- Operatori aritmetici
Operatori de comparare
Operatorii de comparare sunt folosiţi în clauza WHERE pentru

compararea a două valori, având ca rezultat o valoare logică de „adevărat" sau „fals".
Cele două valori comparare pot fi constante furnizate în clauza WHERE, valori ale
unor coloane din baza de date sau combinaţii ale celor două. Operatorii de comparare
care pot fi folosiţi în clauza WHERE sunt prezentaţi în tabelul următor:
5
Operator Descriere
= Egal cu
< Mai mic decât
<= Mai mic sau egal
> Mai mare decât
>= Mai mare sau egal
!= Diferit de
<> Diferit de (standard ANSI)
Exemple din schema FILM:
• Să se afişeze toate filmele pentru care RATING are valoarea PG-13.

SELECT MPAA_RATING_COD AS RATING, TITLU_FILM
FROM FILM
WHERE MPAA_ RATING_COD = 'PG-13'
ORDER BY TITLU_FILM;
• Să se afişeze filmele pentru care COD_RATING are altă valoare decât
PG-13.
SELECT COD_RATING AS RATING, TITLU_FILM
FROM FILM
WHERE COD_RATING <> 'PG-13'
ORDER BY TITLU_FILM;
• Să se afişeze toate filmele cu preţul de vânzare cu amănuntul pentru
formatul DVD(DVD Retail Price) mai mare de 25.00, în ordinea
crescătoare a preţurilor.
SELECT PRET_VANZARE_DVD, TITLU_FILM
FROM FILM
WHERE PRET_VANZARE_DVD >= 25.00
ORDER BY PRET_VANZARE_DVD DESC;
Exemple pe schema BIBLIOTECA
• Să se obtină codul cărtii care are data restituirii >..

SELECT codel
FROM imprumuta
WHERE datares >= ’05–oct–09’;
6
• Să se obţină titlurile şi numărul de exemplare ale cărţilor care au
nrex>100 ;
SELECT titlu, nrex
FROM carte
WHERE nrex>100;
Operatori conjunctivi
Uneori sunt necesare condiţii multiple pentru a îngusta setul de

rezultate al unei interogări. Atunci când sunt folosite mai multe condiţii,
ele trebuie să fie combinate din punct de vedere logic în clauza WHERE,
iar aceasta este sarcina operatorilor conjunctivi. Aceşti operatori sunt:
• AND (ŞI) - Clauza WHERE este evaluată ca „adevărată" dacă
toate condiţiile conectate cu operatorul AND sunt adevărate.
• OR (SAU) - Clauza WHERE este evaluată ca „adevărată" dacă
oricare din condiţiile conectate cu operatorul OR este adevărată.
Operatorul AND are prioritate mai mare şi, ca urmare, este evaluat
înaintea operatorilor OR.
Exemple de folosire a operatorilor conjunctivi:
• Să se afişeze toate filmele pentru care categoria RATING este PG-

13 şi preţul de vânzare cu amănuntul pentru formatul DVD este
19.99 sau mai mic, în ordinea crescătoare a preţurilor.
SELECT COD_RATING AS RATING,

PRET_VANZARE_DVD AS PRET, TITLU_FILM
FROM FILM
WHERE COD_RATING = 'PG-13'
AND PRET_VANZARE_DVD <= 20.00
ORDER BY PRET_VANZARE_DVD;
7
• Să se afişeze toate filmele pentru care categoria RATING este PG-
13 sau preţul de vânzare cu amănuntul pentru formatul DVD este
19.99 sau mai mic, în ordinea crescătoare a preţurilor.

PRET_VANZARE_DVD AS PRET,
TITLU_FILM
FROM FILM
WHERE COD_RATING = 'PG-13' OR
PRET_VANZARE_DVD <= 20
• Afişaţi toate filmele pentru care categoria RATING este PG-13 şi

sunt din genul dramă sau acţiune/aventură.

PRET_VANZARE_DVD AS PRET, TITLU_FILM
FROM FILM
WHERE COD_GEN_FILM= 'ActAd'
OR COD_GEN_FILM = 'Drama'
AND COD_RATING = 'PG-13'
ORDER BY COD_GEN_FILM, COD_RATING;
• Să se adauge parantezele necesare, astfel încât să obţinem filmele

cu categoria PG-13 şi genul acţiune/aventură sau dramă.
SELECT COD_GEN_FILM AS GEN,
COD_RATING AS RATING, TITLU_FILM
FROM FILM
WHERE (COD_GEN_FILM = 'ActAd'
OR COD_GEM_FILM = 'Drama')
AND COD_RATING='PG-13'
ORDER BY COND_GEN_FILM, COD_RATING;
Operatori logici
Operatorii logici folosesc cuvinte cheie în locul simbolurilor la

formarea expresiilor de comparare. La oricare dintre aceşti operatori poate
fi adăugat cuvântul cheie NOT, pentru a inversa valoarea logică a
comparaţiei.
8
IS NULL
Operatorul IS NULL este folosit pentru a determina dacă o valoare
este nulă.
Exemple:
• Să se găsească toate conturile de clienţi active, adică toate conturile
pentru care coloana DATA– TERMINATA conţine o valoare nulă:
SELECT ID_CONT_CLIENT
FROM CONT_CLIENT
WHERE DATA_INCHEIERE IS NULL;
• Să se găsească toate conturile inactive, adică toate conturile pentru

care coloana DATA– TERMINAT conţine o altă valoare decât
NULL:
SELECT ID_CONT_CLIENT
FROM CONT_CLIENT
WHERE DATA_INCHEIERE IS NOT NULL;
BETWEEN
Operatorul BETWEEN este folosit pentru a determina dacă o
valoare se încadrează într-un interval special. Intervalul este specificat
folosind o valoare minimă şi o valoare maximă, fiind un interval inclusiv,
ceea ce înseamnă că include şi valori specificate.
Exemple:
• Să se afişeze toate filmele cu preţul de vânzare cu amănuntul pentru
formatul DVD între 14.99 şi 19.99, ordonate crescător după preţ.
SELECT TITLU_FILM, PRET_VANZARE_DVD
FORM FILM
WHERE PRER_VANZARE_DVD BETWEEN 14.99 AND 19.99
ORDER BY PRER_VANZARE_DVD;
• Să se afişeze toate filmele pentru care preţul de vânzare cu amănuntul

pentru formatul DVD nu este în intervalul 14.99-19.99, ordonate
crescător după preţ.
SELECT TITLU_FILM, PRET_VANZARE_DVD
FORM FILM
WHERE PRET_VANZARE_DVD NOT BETWEEN 14.99 AND 19.99
• Să se afişeze toate conturile de clienţi în luna ianuarie 2009.
SELECT ID_CONT_CLIENT, DATA_INSCRIERE
FROM CONT_CLIENT
WHERE DATA_INSCRIERE BETWEEN ”2009/01/01”
AND „2009/01/31”;
9
Tabelul DUAL se află în schema SYS şi poate fi accesat de către
toţi utilizatorii. Tabelul este util atunci când se afişează valoarea unei
constante, pseudocoloane sau expresii care nu este construită pe baza
datelor vreunui tabel. În general, tabelul DUAL este utilizat pentru a
completa sintaxa instrucţiunii SELECT, întrucât clauzele SELECT şi
FROM sunt obligatorii.
Să se afişeze data şi ora curentă.
SELECT TO_CHAR(SYSDATE,’DD/MM/YY HH24:MI:SS’)
FROM DUAL;
LIKE
Operatorul LIKE este folosit pentru a compara o valoare de tip
caracter cu un tipar*(pattern), returnând valoarea logică “adevărat” dacă
valoarea de tip caracter se încadrează în tipar şi “fals" în caz contrar.
Pentru definirea tiparului pot fi folosite două caractere de înlocuire:
• Liniuţa de subliniere (_) - Caracterul liniuţă de subliniere poate fi
folosit drept caracter de înlocuire poziţional, ceea ce înseamnă că se
potriveşte cu orice caracter aflat pe poziţia respectivă în şirul de
caractere evaluat.
• Procent (%) - Simbolul procent (%) poate fi folosit drept caracter
de înlocuire nepoziţional, ceea ce înseamnă că se potriveşte cu
orice număr de caractere, indiferent de lungime, reprezentând orice
secvenţă de zero sau mai multe caractere, şi „_“, reprezentând un
singur caracter.
Exemple de tipare:
Tipar Interpretare
Now% Se potriveşte cu orice şir de caractere care incepe cu
„Now".
N_w Se potriveşte cu orice şir de caractere format din
exact trei caractere, care începe cu „N" şi se termină
cu „w".
10
%N -w% Se potriveşte cu orice şir de caractere care conţine
litera „N", urmată de orice alt caracter, urmat de litera
„w" (1a începutul, la sfârşitul sau undeva în mijlocul
şirului de caractere)
%Now% Se potriveşte cu orice şir de caractere care conţine
„Now" (1a inceput, la sfârşit sau în mijloc).
%Now Se potriveşte cu orice şir de caractere care se termină
cu „Now".
Datele din bazele de date relaţionale fac întotdeauna diferenţierea

literelor mari de cele mici. O literă mica din date nu se potriveşte cu o
literă mare din tiparul unei clauze LIKE, şi invers.
Exemple de utilizare a operatorului LIKE:
• Să se afişeze toate titlurile de filme care conţin şirul de caractere
„on":
SELECT TITLU_FILM
FROM FILM
WHERE TITLU_FILM LIKE '%on%';
• Dacă se intenţionează să se găsească titlurile care conţin cuvântul
„on", nu literele „on" din alte cuvinte, ar fi trebuit să includă în
tipar şi spatiile necesare, ca în exemplul următor:
Exemple
Să se afişeze cartile ale căror titlu conţine cuvântul „Baza“, sau
pentru care al treilea caracter din autor este „p“.
SELECT titlu, autor
FROM carte
WHERE titlu LIKE '%Baza%' OR autor LIKE '__p%';
11
IN
Operatorul IN este folosit pentru a determina dacă o valoare face
parte dintr-o listă de valori. Lista poate fi specificată ca valori literale,
folosind o listă de valori separate prin virgule şi încadrate între paranteze,
sau poate fi selectată din baza de date folosind o subselecţie (o
subinterogare), care este o interogare în cadrul unei alte interogări.
Exemple de utilizare a operatorului IN:

• Să se afişeze toate filmele pentru care COD_GEN_FILM este
Drama, Forgn.
SELECT COD_GEN_FILM AS GEN, TITLU_FILM

FROM FILM
WHERE COD_GEN_FILM IN ('Drama', 'Forgn')
ORDER BY COD_GEN_FILM, TITLU_FILM;
• Să se afişeze toate filmele pentru care descrierea genului conţine

cuvântul „and". Aveţi nevoie de o subinterogare prin care să
găsiţi toate valorile COD_GEN_FILM care conţin cuvântul
„and" în descriere. Operatorul IN este apoi folosit pentru a găsi
filmele care au unul dintre codurile selectate de subinterogare.
SELECT COD_GEN_FILM AS GEN, TITLU_FILM

FROM FILM
WHERE COD_GEN_FILM IN
(SELECT COD_GEN_FILM
FROM GEN_FILM
WHERE GEN_FILM DESCRIPTION LIKE '% and %')
ORDER BY COD_GEN_FILM AS GEN, TITLU_FILM;
• Să se afişeze toate cartile din domeniile ’I’si ’M’.

SELECT TITLU, AUTOR
FROM CARTE
WHERE CODED IN(’I’,’M’);
12
EXISTS
Operatorul EXISTS este folosit pentru a detemina dacă o

subinterogare conţine înregistrări. Dacă în setul de rezultate al
subinterogării nu există nici un rând, operatorul returnează valoarea
„false”; dacă setul de rezultate conţine cel puţin un rând, valoarea devine
„adevărat”.
Exemple de utilizare a operatorului EXIST:
• Proprietarul magazinului a auzit că filmul The Last Samurai se

închiriază bine atât în format DVD, cât şi-n format VHS şi vrea să
se asigure că în inventarul magazinului există o copie VHS.
Tabelul FILM_COPIAT conţine un rând pentru fiecare copie a
unui film din inventarul magazinului, aşa că puteţi folosi o
subinterogare pentru a afla dacă există copii VHS ale filmului în
inventar. De cele mai multe ori, operatorul EXISTS este folosit in
conjuncţie cu o formă mai complexă de subinterogare, numită
subinterogare corelat. (correlated subquery),în care valorile
datelor din interogarea externă (ID_FILM, în acest caz) sunt
comparate cu rândurile din interogarea intenă.
SELECT ID_FILM, TITLU_FILM

FROM FILM M
WHERE TITLU_FILM = 'The Last Samurai'
AND EXISTS
(SELECT ID_FILM
FROM FILM_COPIAT C
WHERE M. ID_FILM = C. ID_FILM);
• Dacă inversaţi logica, folosind operatorul NOT EXISTS, puteţi
afişa titlul filmului numai dacă nu există o copie VHS în inventar.
SELECT ID_FILM, TITLU_FILM
FROM FILM M
AND NOT EXISTS
(SELECT ID_FILM
FROM FILM_COPIAT C
WHERE M. ID_FILM = C. ID_FILM);
13
Operatori aritmetici
În SQL, operatorii aritmetici sunt folosiţi pentru efectuarea

calculelor matematice – la fel ca şi în formulele dintr-o foaie de calcul
tabelar sau într-un limbaj de programare, precum Java sau C. Cei patru
operatori aritmetici din SQL sunt:
Op Desc
erator riere
+ Adun
are
- Scăd
ere
* Înmu Ca şi în cazul operatorilor
lţire conjunctivi, dacă se amestecă
/ Împă operatorii aritmetici în aceeaşi
rţire instrucţiune SQL fără a folosi
paranteze, ordinea în care sunt
evaluate operaţiile este determinată de prioritatea predefinită. Din fericire,
prioritatea operatorilor din SQL este cea pe care o folosim în operaţiile
matematice obişnuite.
Exemple de utilizare a operatorilor aritmetici:
• Cât v-ar costa să cumpăraţi copiile VHS şi DVD ale filmului The Last
Samurai?
SELECT PRET_VANZARE_VHS + PRET_VANZARE _DVD
AS COST
FROM FILM
WHERE TITLU_FILM = 'The Last Samurai';
• Cât v-ar costa aceeaşi achiziţie dacă aţi avea un bon valoric de 8 ron?
SELECT (PRET_VANZARE _VHS + PRET_VANZARE _DVD) - 8
AS COST
FROM FILM
• Dacă taxele sunt de 8.25% (0.0825), cât reprezintă taxele de vânzare
din costul achiziţiei anterioare?
SELECT (PRET_VANZARE _VHS+ PRET_VANZARE _DVD) *
0.0825 AS TAX
FROM FILM
• Care este costul mediu pentru o copie a filmului The Last Samurai?
SELECT (PRET_VANZARE_VHS+PRET_VANZARE _DVD) / 2
AS AVG_COST
14
FROM FILM
Funcţii SQL elementare
O funcţie este un tip special de program, care returnează o singură

valoare de fiecare data când este apelată. Termenul provine de la
conceptul matematic al unei funcţii. În SQL, funcţiile necesită
întotdeauna specificarea unei expresii, care deseori include numele unei
coloane. Cel mai des, funcţiile sunt folosite în lista de coloane a unei
instrucţiuni SELECT, sunt apelate pentru fiecare rând prelucrat de
interogare şi, ca urmare, returnează o singură valoare pentru fiecare rând
din setul de rezultate. Uneori este folosit termenul funcţie de coloană,
pentru a indica faptul că o funcţie este aplicată unei coloane dintr-un tabel
sau o vizualizare. Un număr de funcţii sunt furnizate de producătorul
DBMS şi se pot scrie propriile funcţii, folosind un limbaj special livrat
împreună cu sistemul DBMS, cum ar fi PL/SQL pentru Oracle sau
Transact SQL pentru Microsoft SQL Server şi Sybase Adaptive Server.
Atenţie la folosirea funcţiilor SQL în condiţiile WHERE. În cele
mai multe situaţii, pentru o coloană căreia îi este aplicată o funcţie nu
poate fi folosită indexarea. Ca urmare, în cazul tabelelor mari, utilizarea
funcţiilor în condiţiile WHERE poate duce la probleme de performanţă cu
adevărat memorabile.
Funcţiile pot fi clasificate în multe moduri, dar majoritatea
specialiştilor le împart după ceea ce fac.
Funcţii pentru caractere
Funcţiile pentru caractere sunt numite astfel deoarece manipulează

date de tip text.
Concatenarea şirurilor de caractere
Funcţia de concatenare a şirurilor de caractere reuneşte mai multe
şiruri de caractere pentru a forma o singură valoare în rezultatele
interogării. Funcţia standard de concatenare a şirurilor de caractere din
SQL este apelată cu două bare verticale (||), dar există şi excepţii, cum ar
fi Microsoft SQL Server, care foloseşte semnul plus (+) pentru
concatenarea şirurilor de caractere.
Exemple de concatenare a şirurilor de caractere:
• Magazinul de produse video vrea să trimită fiecărui client o
scrisoare care începe cu formula "Client", plus prenumele şi
numele persoanei. Numele sunt stocate în tabelul PERSON. Soluţia
acestei cerintţe în Oracle:
15
SELECT 'Client' || NUME_PERSOANA||
' ' || NUME_FAMILIE_PERSOANA AS SALUT_CLIENT
FROM PERSOANA;
Aceeaşi soluţie, modificată pentru a funcţiona în Microsoft SQL
Server :
SELECT ‚Client' + NUME_PERSOANA +
' ' + NUME_FAMILIE_PERSOANA AS SALUT_CLIENT
FROM PERSOANA;
<nume angajat> castiga <salariu> lunar, dar doreste <salariu de 3
ori mai mare>
SELECT last_name||'castiga'||salary||'lunar, dar doreste'||salary*3 "salariul
ideal"
FROM employees;
UPPER
Funcţia UPPER este deseori folosită în condiţiile WHERE.
Funcţia UPPER transformă literele dintr-un şir de caractere în litere mari.
Numerele şi caracterele speciale sunt lăsate ca stare.
Exemple:
• Să se afişeze comediile (COD_GEN_FILM = 'Comdy') scriind
titlurile cu majuscule.
SELECT UPPER(TITLU_FILM) AS TITLU_FILM
FROM FILM
WHERE COD_GEN_FILM = 'Comdy';
• Să presupunem că nu vă amintiţi dacă valorile COD_GEN_FILM

au fost stocate cu litere mari, litere mici sau combinaţii ale
acestora. Dacă în condiţia WHERE transformaţi valorile în litere
mari, puteţi obţine rezultatele corecte indiferent de modul de
stocare.
SELECT UPPER(TITLU_FILM) AS TITLU_FILM
FROM FILM
WHERE UPPER(COD_GEN_FILM) = 'COMDY';
LOWER
Funcţia LOWER este inversa funcţiei UPPER — transformă
literele dintr-un * de caractere în litere mici.
Exemple de utilizare a funcţiei LOWER:
• Să se afişeze comediile (GEN_COD_FILM = 'Comedy') scriind
titlurile cu minuscule.
SELECT LOWER(TITLU_FILM) AS TITLU_FILM
16
FROM FILM
WHERE GEN_COD_FILM = 'Comedy';
• Se poate folosi funcţia LOWER într-o clauză WHERE, atunci când

nu ştiti sigur ce tip de litere obţine textul pe care vreţi să-1
comparaţi. Afişaţi toate filmele care au în titlu cuvântul „of ",
indiferent dacă este scris cu litere mari sau mici.
SELECT TITLU_FILM
FROM FILM
WHERE LOWER(TITLU_FILM) LIKE ' % of %'
OR LOWER(TITLU_FILM) LIKE 'of % '
OR LOWER(TITLU_FILM) LIKE ' % of ';
SUBSTR
Funcţia SUBSTR apare în majoritatea implementărilor SQL, dar

uneori are un nume puţin diferit. De exemplu, funcţia se numeşte
SUBSTRING în Microsoft SQL Server, Sybase Adaptive Server şi
MySQL, dar SUBSTR în Oracle şi D132. Funcţia returnează o porţiune a
şirului de caractere, în funcţie de parametrii furnizaţi, care specifică
numele coloanei, poziţia de început a subşirului în datele coloanei şi
lungimea subşirului returnat (numărul de caractere). Deşi este o utilizare
mai puţin obişnuită, funcţia SUBSTR acceptă şi un şir de caractere literal
în locul numelui unei coloane. Iată forma generală a funcţiei, urmată de
un exemplu:
SUBSTR (numele coloanei, poziţia de început, lungimea subşirului
• În tabelul PERSON, unele persoane au al doilea nume în întregime,
alţii au numai initiale. Afişati numele complet al persoanelor al
căror nume de familie începe cu litera „B", sub forma unui singur
şir de caractere care conţine prenumele, iniţiala şi numele de
familie.
SELECT NUME_PERSOANA || ' ' ||

SUBSTR(PRENUME_PERSOANA, 1, 1) || ' . ' ||
NUME_FAMILIE_PERSOANA AS NUME_INTREG
FROM PERSOANA
WHERE SUBSTR(NUME_FAMILIE_PERSOANA, 1, 1)='B'
Observaţi folosirea funcţiei SUBSTR în clauza WHERE pentru a

elimina din rezultate persoanele al căror nume de familie nu începe cu
litera „B". Ar trebui să vă puteţi deja gândi la alte moduri de a face acest
lucru, prin folosirea operatorului LIKE.
17
LENGTH
Funcţia LENGTH returnează lungimea unui şir de caractere.

Microsoft SQL Server şi Sybase Adaptive Server folosesc numele LEN
pentru versiunea proprie a acestei funcţii.
Exemple:
• Să se afişeze lungimea titlului pentru filmul a cărui valoare
ID_FILM este 1. Presupunem că folosiţi o bază de date oracle,
DB2 sau MySQL.
•
SELECT TITLU_FILM, LENGTH (TITLU_FILM) AS LENGTH
FROM FILM
WHERE ID_FILM = 1;
•
SELECT TITLU_FILM, LENGTH (TITLU_FILM) AS LENGTH
FROM FILM
WHERE LENGTH (TITLU_FILM) < 10;
Funţii matematice
Funcţiile matematice manipulează valori numerice, în conformitate
cu regulile matematicii.
ROUND
Funcţia ROUND rotunjeşte o valoare la un număr specificat
de zecimale. Valoarea numerică este furnizată prin primul parametru, iar
numărul de zecimale prin cel de-al doilea. În continuare este prezentat
formatul general al funcţiei ROUND.
ROUND (expresie numerică, număr de poziţii zecimale)
• Care este costul mediu al unei copii a filmului The Last Samurai,
rotunjit la două zecimale?
SELECT ROUND((PRET_VANZARE_VHS +
PRET_VANZARE _DVD) / 2, 2) AS AVG_COST
FROM FILM
Alte funcţii matematice

Tabelul care urmează prezintă funcţiile matematice cel mai
18
des întâlnite. Pentru toate, sintaxa generală este aceeaşi:
NUME_FUNCTIE (expresie)
Funcţie Descriere
ABS Valoarea absolută a unui număr dat
COS Cosinusul trigonometric al unui unghi specificat în radiani
EXP Valoarea exponenţială a unui număr dat
POWER Ridică un număr la o putere (numărul şi puterea sunt fumizate
ca parametri)
SIN Sinusul trigonometric al unui unghi specificat în radiani
TAN Tangenta trigonometrică a unui unghi specificat în radiani
Funcţii de conversie
Funcţiile de conversie transformă date dintr-un tip de date în altul.
CAST
Funcţia CAST transfo rmă d ate dintr-un tip de date în altul. Iată
sintaxa generală a funcţiei CAST, urmată de un exemplu:
CAST (expresie AS tip de date)
• Afişati preţul pentru formatul DVD al filmului The Last Samurai,
cu un simbol dolar în faţa sumei. Valoarea numerică trebuie să fie
convertită într-un şir de caractere pentru a putea fi concatenată cu o
valoare literală conţinând simbolul dolar.
SELECT '$' || CAST(PRET_VANZARE _DVD AS
VARCHAR(6)) AS PRET
FROM FILM
Funcţii de agregare şi gruparea rândurilor

O funcţie de agregare (aggregate functions) este o funcţie care
combină mai multe rânduri de date într-un singur rând. Tabelul următor
prezintă funcţiile de agregare acceptate în majoritatea implementărilor
SQL:
Funcţie
Descriere
AVG Calculează valoarea medie pentru o coloană sau o
expresie.
COUNT Numără valorile dintr-o coloană.
MAX Găseşte valoarea maxină dintr-o coloană.
MIN Găseşte valoarea minimă dintr-o coloană.
19
SUM Însumează valorile dintr-o coloană.
Exemple:
• Care este preţul mediu al unui DVD?
SELECT ROUND(AVG(PRET_VANZARE _DVD),2) AS
AVG_PRET
FROM FILM;
• Câte filme există în tabelul FILM?
SELECT COUNT(*) AS NUM_FILM
FROM FILM;
• Câte genuri diferite de filme sunt reprezentate în tabelul FILM?
SELECT COUNT(DISTINCT COD_GEN_FILM) AS NUM_GEN
FROM FILM;
• Care sunt lungimea minimă şi maximă a titlurilor filmelor?
SELECT MIN(LENGTH(TITLU_FILM)) AS MIN_LENGTH,
MAX(LENGTH(TITLU_FILM)) AS MAX_LENGTH
FROM FILM;
Clauza GROUP BY
GROUP BY cere sistemului DBMS să grupeze rândurile selectate

de interogare pe baza valorilor din una sau mai multe coloane şi să aplice
funcţia (sau funcţiile) de agregare fiecărui grup, returnând un rând pentru
fiecare grup din setul de rezultate.
Sistemul DBMS va ordona rândurile selectate de interogare după
coloanele din clauza GROUP BY, aşa că grupurile vor fi returnate în
ordine ascendentă, exceptând cazul în care se adăugă o clauză ORDER
BY care specifică un alt mod de ordonare.
Iată un exemplu:
• Afişati fiecare cod de gen, împreună cu numărul de filme asociate
fiecărui cod.
SELECT COD_GEN_FILM AS GEN, COUNT(*) AS COUNT
FROM FILM
GROUP BY COD_GEN_FILM;
Ce se întâmplă dacă scoateţi clauza GROUP BY din această
interogare? Sistemul DBMS retumează un mesaj de eroare şi, din
nefericire, mesajul de eroare este deseori destul de criptic. Functia
COUNT(*) este o functie de agregare şi, în absenta clauzei GROUP BY,
retumează un singur rând de date.
Exemplele care urmează arată modul general de constituire a
subansamblelor virtuale folosind clauza GROUP BY. Fiecare expresie
care apare în SELECT trebuie să aibă aceeaşi valoare pentru toate liniile
20
care aparţin aceleiaşi partiţii. Numele coloanelor din GROUP BY nu
trebuie să figureze obligatoriu în lista de la SELECT.
Clauza WHERE are prioritate fata de GROUP BY. Nu se poate
utiliza alias de coloana in clauza GROUP BY.
Pentru a returna informatie corespunxatoare fiecarui grup, pot fi
utilizate functiile agregat. Acestea pot aparea in clauzele SELECT,
ORDER BY si HAVING. Se poate utiliza functie grup in clauza WHERE?
Este corect …WHERE AVG(sal) > 200? NU!
Cand se utilizeaza GROUP BY, server-ul sorteaza implicit
multimea rezultata in ordinea crescatoare a valorilor coloanelor dupa care
se realizeaza gruparea.
Grupurile sunt formate si functiile grup sunt calculate, inainte ca
clauza HAVING sa fie aplicata grupurilor.
Exemplu:
Să se obţină numărul de câte ori a fost împrumutată fiecare carte.
SELECT codel, COUNT(*)
FROM imprumuta
GROUP BY codel;
Exemplu:
Pentru fiecare domeniu de carte să se obţină numărul cărţilor din
domeniu, media preţurilor şi numărul total de exemplare.
SELECT coded,COUNT(*), AVG(pret),SUM(nrex)
FROM carte
GROUP BY coded;
Dacă în comanda SELECT apar atribute coloană (nu funcţii grup) şi
se utilizează clauza GROUP BY atunci aceste coloane trebuie obligatoriu
să apară în clauza GROUP BY.
Exemplu:
Să se obţină pentru fiecare autor, media preţurilor cărţilor din
bibliotecă.
SELECT autor, AVG(pret)
FROM carte
GROUP BY autor;
Exemplu:
Pentru departamentele în care salariul maxim depăşeşte 5000$ să
se obţină codul acestor departamente şi salariul maxim pe departament.
SELECT deptno, MAX(sal)
FROM emp
GROUP BY deptno
HAVING MAX(sal)>5000;
21
Exemplu:
SELECT MAX(AVG(pret))
FROM carte
GROUP BY autor;
Exemplu:
Să se afişeze numele şi salariul celor mai prost plătiţi angajaţi
din fiecare departament.
SELECT ename, sal
FROM emp
WHERE (deptno, sal) IN
(SELECT deptno, MIN(sal)
FROM emp
GROUP BY deptno);
Exemplu:
Să se obţină pentru fiecare carte, codul său şi numărul de
exemplare care nu au fost încă restituite.
SELECT codel, COUNT(*)
FROM imprumuta
WHERE dataef IS NULL
GROUP BY codel;
Exemplu:
Să se obţină numărul cărţilor împrumutate cel puţin o dată.
SELECT COUNT(DISTINCT codel)
FROM imprumuta;
Exemplu:
Să se afişeze numărul cărţilor împrumutate cel puţin de două ori
(pentru fiecare carte împrumutată mai mult decât o dată să se obţină
numărul de câte ori a fost împrumutată).
SELECT COUNT(COUNT(codel))
FROM imprumuta
GROUP BY codel
HAVING COUNT(*)>1;
22
În cererea anterioară COUNT(codel), reprezintă numărul care arată
de câte ori a fost împrumutată fiecare carte, iar COUNT(COUNT(codel)),
reprezintă numărul total al cărţilor împrumutate.
Exemplu:
Pentru fiecare departament codul dep si numarul de angajati.
1 select department_id, count(*)
2 from employees
3* group by department_id
SQL> /
DEPARTMENT_ID COUNT(*)
------------- ----------
10 1
20 2
30 6
40 1
50 45
60 5
70 1
80 34
90 3
100 6
110 2
1
12 rows selected.
Pentru departamentele cu mai mult de un angajat se afiseaza codul dep si
numarul de angajati.
1 select department_id, coun
2 from employees
3 group by department_id
4* having count(*)>1
SQL> /
DEPARTMENT_ID COUNT(*)
------------- ----------
20 2
30 6
50 45
60 5
80 34
23
90 3
100 6
110 2
8 rows selected.
Se afiseaza numarul departamentelor cu mai mult de un angajat.
1 select count(count(*))
2 from employees
3 group by department_id
4* having count(*)>1
SQL> /
COUNT(COUNT(*))
---------------
8
Exemplu:
Sa se afiseze numărul de cărţi imprumutate din fiecare domeniu.
SELECT d.intdom, COUNT(*)
FROM domeniu d, carte c, imprumuta I
WHERE c.codel = i. codel
AND c.coded = d.coded
GROUP BY intdom;
Exemplu:
Lista codurilor cititorilor care au mai mult de 3 cărţi nerestituite la
termen.
SELECT codec
FROM imprumuta
WHERE dataef IS NULL AND datares < SYSDATE
GROUP BY codec
HAVING COUNT(*) > 2;
Exemplu:
Pentru fiecare domeniu de carte care conţine cel puţin o carte şi
unde preţul oricărei cărţi nu depăşeşte o valoare dată, să se obţină: codul
domeniului, numărul cărţilor din domeniu şi numărul mediu de
exemplare.
SELECT coded, COUNT(*), AVG(nrex)
24
FROM carte
GROUP BY coded
HAVING COUNT(*) >= 1
AND MAX(pret) < &pret_dat;
Exemplu:
Codurile domeniilor care nu contin carti.
SELECT coded
FROM carte
GROUP BY coded
HAVING COUNT(*) = 0;
Nu este corect, deoarece se iau in considerare NUMAI codurile
domeniilor care apar in tabelul CARTE.
SELECT intdom
FROM domeniu d
WHERE 0 = (SELECT COUNT(*)
FROM carte
WHERE coded = d.coded);
Urmatoarea cerere este corecta?
SELECT intdom
FROM domeniu d,(SELECT coded, COUNT(*) a
FROM carte
GROUP BY coded) b
WHERE b.coded = d.coded)
AND b.a = o;
Exemplu:
În ce interogări este necesară utilizarea cuvântului cheie
HAVING?
A. când este necesar să eliminăm linii duble din rezultat;
B. când este necesar să ordonăm mulţimea rezultat;
C. când este necesar să efectuăm un calcul pe grup;
D. când este necesar să restricţionăm grupurile de linii returnate.
Operatori pentru interogări compuse

Uneori este util să se ruleze interogări multiple şi să se combine
rezultatele într-un singur set de rezultate.
UNION
Operatorul UNION adaugă rândurile din setul de înregistrări al
25
unei interogări la cel al unei alte inregistrări şi, în acelaşi timp, elimină
rândurile duplicate, într-un mod similar cu cel al cuvântului cheie
DISTINCT. Operaţia este permisă numai dacă interogările sunt
compatibile din punctul de vedere al uniunii, ceea ce înseamnă că au
acelaşi număr de coloane şi că tipurile de date ale coloanelor
corespondente sunt compatibile.
Iată un exemplu:
• Afişaţi pe o singură coloană toate valorile nenule pentru taxa de
inchiriere şi taxa de întârziere din tabelul FILM_ÎNCHIRIAT.
SELECT INCHIRIAT_FEE AS FEE
FROM FILM_INCHIRIAT
WHERE INCHIRIAT _FEE IS NOT NULL
UNION
SELECT LATE_OR_LOSS_FEE AS FEE
FROM FILM_INCHIRIAT
WHERE LATE _OR_ LOSS FEE IS NOT NULL;
UNION ALL
UNION ALL funcţionează la fel ca şi operatorul UNION,
exceptând faptul că rândurile duplicate nu sunt eliminate.
INTERSECT
Operatorul INTERSECT găseşte valorile selectate dintr-o
interogare, care apar şi într-o altă interogare. În esenţă, găseşte intersecţia
valorilor din cele două interogări. Totuşi, doar un număr mic de sisteme
DBMS (cele mai importance fiind Oracle şi DB2) implementează acest
operator. Nu-1 veţi găsi în Microsoft SQL Server sau MySQL.
Iată un exemplu:
• Există în tabelul FILM filme pentru care preţul pentru DVD este
egal cu preţul pentru VHS?
SELECT INCHIRIAT_FEE AS FEE
FROM FILM_ INCHIRIAT
WHERE INCHIRIAT _FEE IS NOT NULL
INTERSECT
SELECT LATE_OR_LOSS_FEE AS FEE
FROM FILM_ INCHIRIAT
WHERE LATE OR_ LOSS FEE IS NOT NULL
26
EXCEPT
EXCEPT este operatorul standard ANSI/ISO care găseşte
diferenţele dintre două seturi de rezultate, returnând, în esenţă, valorile
din prima interogare care nu apar în cea de-a doua interogare. Foarte
puţine sisteme DBMS implementează acest operator. În unele
implementări, precum Oracle, operatorul se numeşte MINUS, nu
EXCEPT.
27

baze-TOATE SUBIECTELE

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

baze-TOATE SUBIECTELE

Uploaded by

Copyright:

Available Formats

1.

Care este forma corecta pentru a adauga constrangeri la nivel de coloana si

Probleme pentru examenul de licenta

1. O baza de date relationala este

CARTE(codc CHAR(5), titlu VARCHAR2(30), autor VARCHAR2(30), pret NUMBER(8,2), nrex

a. CREATE TABLE CARTE

CARTE(codc CHAR(5) , titlu VARCHAR2(30), autor VARCHAR2(30), pret NUMBER(8,2), nrex

a. CREATE TABLE CARTE

selectand cartile care au coddom=’I’

b. CREATE TABLE CARTE_INFO

a. ALTER TABLE SALARIAT ADD Cod_Funct NUMBER(2), ALTER COLUMN ADD

si sa contina salariatii care au salariu >100?

a. ALTER TABLE SALARIAT

a. ALTER TABLE IMPRUMUTA

a. INSERT INTO FAC

a. SELECT COD_FAC, COD_PROF, NUME, SALARIU

a. Poate fi scrisa in Oracle SQL folosind un simbol (+) in clauza

a. SELECT codcarte, COUNT(*), AVG(pret)

a. SELECT NUME, PREN, DENUMIRE

a. SELECT x.titlu, x.pret

Presupunem că tabela Curs_Student conŃine următoarele date:

Coloana Cursuri conŃine mult prea multa informaŃie.

1.1 Să se aducă tabela CURS_SUDENT la FN1. Pentru aceasta să se creeeze

Amintim că o tabelă este în prima formă normală(FN1) dacă valorile tuturor

1.2 Să se aducă tabela CURS_SUDENT la FN2. Pentru aceasta să se creeeze

2. Să se aducă tabelul Profesor la FN3 şi să se creeze tabela Titlu, rezultat în

Amintim ca regulile de integritate sunt;

5. Să se implementeze FN1 pentru tabelul MASINA:

6. Să se aducă la FN2 tabelul ATASAT_LA, prin spargerea lui în 2 tabele

7. Tabelul ATASAT_LA _2A rezultat de la 6. să se aducă la FN3, realizând tabelele

Avem relaŃiile următoare

9.Să se aducă relaŃia EXECUTA_1 rezultat de la 8, în FN3 cu regula Casey-

10. Să se aducă la forma BCNF (Forma normală Boyce-Codd )

(Formal, o relaŃie R este în forma normală Boyce-Codd dacă şi numai dacă

a. Un limbaj realizat de Dr. E. F. Codd

b. Un limbaj folosit pentru comunicarea cu bazele de date relaŃionale

c. Un limbaj folosit pentru definirea diagramelor ERD

d. Folosit pentru definirea şi modificarea obiectelor unei baze de date

e. Folosit pentru definirea paginilor web

a. O structură denumită de date, cum ar fi un tabel, o vizualizare sau un

b. Un produs software furnizat de un producător de baze de date

c. O colecŃie de date interrelaŃionate gestionate ca o singură unitate

d. Definită în acelaşi mod de toŃi producătorii de software

e. Implementată diferit de diferiŃi producători

3. Un sistem de gestionare a bazelor de date este

a. O structură, cum ar fi un tabel, o vizualizare sau un index

b. O colecŃie de date interrelaŃionate gestionate ca o singură unitate

c. Un produs software furnizat de un producător de baze de date

d. Deseori abreviat sub forma DBMS

e. O structură denumită de date, cum ar fi un tabel, o vizualizare sau un

4. Exemple de sisteme RDBMS sunt

e. Microsoft SQL Server

5. Componentele unei baze de date relaŃionale includ

7. Scopul normalizării este de a rezolva următoarele probleme

a. Începe de la tabele, pentru a ajuta proiectanŃii să descopere vizualizările de

b. A fost dezvoltat de Dr. E. F. Codd

c. A fost dezvoltat de Oracle

d. Este aplicat sistematic fiecărei vizualizări de utilizator

a. Trebuie determinat înaitea procesului de normalizare

b. Poate fi compus dintr-un singur atribut

c. Poate fi compus din zero sau mai multe atribute

d. Poate fi compus din mai multe atribute concatenate

10. Prima formă normală rezolvă anomaliile cauzate de