CURS 14 - RECAPITULARE

Concepte fundamentale în teoria bazelor de date

- Sinteză teoretică -
Modelul relațional de date

Model de date = limbaj + semantică de reprezentare și manipulare a datelor

Model conceptual: proiectare, concepere
(de ex., definim datele specifice unui domeniu și relațiile dintre acestea)
Model logic: concepere și dezvoltare (modelul logic, sau relațional, a fost propus de Tedd Codd în 1970 - laboratoarele IBM).

(de ex., creăm tabele, definim și utilizăm datele într-un SGBD - MS Access)
Model fizic: administrare
(de ex., se implementează operații, prelucrări, modele de stocare pe disc, indecși, algoritmi etc.)

Într-o aplicație cu baze de date a unei companii sau instituții:

 O BD se compune din tabele (numite și relații).
 Coloanele unei tabele sunt denumite câmpuri (atribute).
 Fiecare câmp are un domeniu asociat (coloane din tabele).
 Datele într-o tabelă sunt organizate sub formă de înregistrări sau tupluri (linii de date).
 O tabelă are o cheie primară și poate avea 0, 1 sau mai multe chei externe.
 Nu există o ordine impusă înregistrărilor într-o tabelă.

pg. 1 Baze de Date Liana ANICA-POPA

Definiții

Tabelă (Relație): Colecție omogenă de date, compusă din coloane și linii de date.

Câmp (atribut) al unei tabele: caracteristică sau proprietate, considerată esențială pentru descrierea unui subiect abstract sau
concret din baza de date.

Valoare (realizare) a unui câmp: o dată concretă, atribuită unui câmp dintr-o tabelă.

Domeniu al unui câmp – o coloană de date: ansamblu de valori (realizări) atribuite unui câmp dintr-o tabelă.

Structura unei tabele: ansamblul câmpurilor (denumirilor coloanelor) dintr-o tabelă.

Gradul (dimensiunea) unei tabele: numărul de câmpuri din structura unei tabele.

Înregistrare (tuplu) dintr-o tabelă – o linie de date a unei tabele: ansamblul format din câte o valoare (realizare) atribuită
fiecăruia dintre câmpurile care alcătuiesc structura unei tabele.

Cardinalitatea unei tabele: numărul de înregistrări (tupluri) dintr-o tabelă.

Cheia primară (principală) a unei tabele: un câmp, sau un ansamblu minimal de câmpuri, care identifică în mod unic o înregistrare
(un tuplu) dintr-o tabelă.

Cheia externă (secundară) a unei tabele: un câmp, sau un ansamblu minimal de câmpuri, cu rol de cheie primară într-o altă tabelă,
ce asigură legătura logică între tabelele implicate.

Restricție de integritate referențială: o condiție (logică) ce verifică dacă valorile unei chei externe se regăsesc în domeniul
cheii primare de proveniență.

Cheie candidat: ansamblul minimal de câmpuri care identifică în mod unic înregistrările dintr-o tabelă.

pg. 2 Baze de Date Liana ANICA-POPA

Dependentă funcțională între atributele unei scheme de relații

Dependența funcțională (DF) dintre două atribute ale unei tabele reprezintă relația (legătura) definită între acestea. De
exemplu, valoare unui atribut (sau grup de atribute) poate fi determinată prin (pornind de la) valoarea altui atribut (sau grup de
atribute).
O dependența funcțională (DF) se notează astfel:
X → Y,
adică atributul X determină funcțional atributul Y,
sau Y depinde funcțional de X.
O valoare a atributului X are cel mult o valoare corespondentă în domeniul atributului Y. Altfel spus, unei valori date a lui X îi corespunde
mereu aceeași valoare a lui Y. X se numește atribut determinant, iar Y - atribut determinat

- Exerciții -
Exercițiul I
Obiectiv de învățare:
Identificarea și exemplificarea conceptelor fundamentale din teoria bazelor de date – modelul relațional al datelor

Se dau tabelele:
Parcela TipSol TipSolPeFiecareParcela
CodPar DataAchiz SuprPar CodTipSol DenTipSol #CodPar #CodTipSol
111 12/08/2009 65 1000 cernoziom 111 1000
222 15/11/2000 20 2000 cenușiu 111 2000
3000 brun-roșcat 111 3000
4000 brun-cenușiu 222 1000
5000 turbă 222 4000
... ... ... ... ... ...

pg. 3 Baze de Date Liana ANICA-POPA

Cerințe:

Ex1. Care este definiția conceptului de tabelă? Scrieți trei exemple.

Exemplu: TipSol
Ex2. Care este definiția conceptului de structură a unei tabele (schemă de relație)? Scrieți trei exemple.
Exemplu: StrParcela={CodPar; DataAchiz; SuprPar}
Ex3. Care este definiția conceptului de câmp? Scrieți trei exemple.
Exemplu: DenTipSol este un câmp al tabelei TipSol;
Ex4. Care este definiția conceptului de valoare (realizare) a unui câmp? Scrieți trei exemple.
Exemple: #12/08/2009# este valoare a câmpului DataAchiz; 3000 este valoare a câmpului CodTipSol; „cernoziom” este o
valoare sau realizare a câmpului DenTipSol.
Ex5. Care este definiția conceptului de domeniu? Scrieți trei exemple.
Exemple: DomeniuCodPar= {111; 222}; DomeniuDataAchiz = {#12/08/2009#; #15/11/2000#};
DomeniuDenTipSol = { “cernozion”;”cenusiu” ;”brun-roscat”; „brun-cenusiu”; „turba”};
Ex6. Care este definiția conceptului de înregistrare (tuplu) a unei tabele? Scrieți trei exemple de înregistrări.
Exemple: Inregistrare Parcela = {111; #12/08/2009#; 65}; Inregistrare TipSol = {1000; „cernoziom”};
Inregistrare TipSolPeFiecareParcela = {111; 1000}.
Ex7. Care este definiția conceptului de grad (dimensiune) a unei tabele? Scrieți trei exemple.
Exemple: Grad Parcela = 3; Grad TipSol = 2; Grad TipSolPeFiecareParcela =2
Ex8. Care este definiția conceptului de cardinalitate a unei tabele? Scrieți trei exemple.
Exemple: Card Pacela = 2; Card TipSol = 5; Card TipSolPeFiecareParcela = 5
Ex9. Care este definiția conceptului de cheie primară (principală) a unei tabele (PK)? Scrieți trei exemple.
Exemple: CodPar este cheie primară în tabela Parcela; CodTipSol este cheie primară în tabela TipSol; #CodPar,#CodTipSol
este cheie primară în tabela TipSolPeFiecareParcela
Ex10. Care este definiția conceptului de cheie externă (secundară) a unei tabele (FK)? Scrieți exemple.
pg. 4 Baze de Date Liana ANICA-POPA
 Exemplu: #CodPar este cheie externă în tabela TipSolPeFiecareParcela
Ex11. Care este definiția conceptului de restricție de integritate referențială (RIF)? Scrieți un exemplu.
Exemplu: Valoarea 222 a cheii externe #CodPar din tabela TipSolPeFiecareParcela trebuie să existe deja printre valorile
atribuite câmpului CodPar – cheia primară a tabelei Parcela.

Exercițiul II

Obiectiv de învățare:
Identificarea și exprimarea unei dependențe funcționale, DF.

Ce aplicăm pentru rezolvare?

O dependență funcțională – DF – se notează X→Y
și există dacă
pentru o valoare a lui X va corespunde mereu aceeași valoare a lui Y.
Caz general
Să luăm în considerare schema următoarei relații: R (A, B, C, D, E)
Această relație este definită în extensie de următoarele înregistrări (tupluri, sau linii de date):

R
A B C D E
a1 b2 c2 d3 e2
a1 b2 c2 d1 e4
a2 b3 c2 d1 e5
a2 b4 c5 d1 e5

Ex1. Care dintre următoarele dependențe funcționale se aplică lui R?

a. B→A c. B→C b. E→A d. E→D e. B→D f. E→B g. D→E h. C→A

pg. 5 Baze de Date Liana ANICA-POPA

Caz practic

Ex2. Care sunt dependențele funcționale pe care le identificați în tabela Vânzări?

Vânzări
NrFV DataFV CodCl NrDocIncas DataDocIncas
17 4/01/2021 115599 2 12/02/2021
17 4/01/2021 115599 4 15/02/2021
18 4/01/2021 772266 5 15/02/2021
19 10/01/2021 772266 5 15/02/2021

Inspirați-vă din realitatea economică pe care o cunoașteți:

 factură de vânzare este emisă unui client;
 un document de încasare este emis de un client, pentru achitarea uneia sau a mai multor facturi.

Întrebări pregătitoare
I1. Câte documente de încasare au fost primite pentru fiecare factură?
I2. Câte facturi au fost încasate prin intermediul unui document de încasare?

Soluție:

a. NrFV → DataFV c. NrDocIncas → DataDocIncas

b. NrFV → CodCl d. NrDocIncas → CodCl

pg. 6 Baze de Date Liana ANICA-POPA

 Normalizarea bazelor de date
- Sinteză teoretică -

Normalizarea este un proces de optimizare a structurii unei baze de date prin care se vizează minimizarea redundanței datelor și
eliminarea anomaliilor de adăugare, actualizare și ștergere a acestora.

Teoria normalizării se bazează pe două concepte principale:

1. Dependențe funcționale - reflectă relații între / restricții asupra date/lor (prezentată mai sus)
2. Forme normale – servesc la definirea unor relații (tabele) bine concepute, structurate.

2. Normalizarea
Formele normale FN1, FN2, FN3

Formele normale sunt proprietăți pe care schemele de relații (structurile tabelelor unei baze de date, BD) trebuie să le verifice
pentru a evita anomaliile de actualizare. Orice formă normală se aplică unei scheme de relații (unei tabele).

2.1. Forma normală 1 (FN1)

Definiție FN1:
O tabelă (sau relație) verifică FN1 dacă și numai dacă atributele sale au valori unice și nenule (sau atomice).

Concret, în etapa de normalizare FN1, un economist implicat într-un proiect de normalizare a unei bazei de date identifică și
rezolvă următoarele cazuri posibile:

a. Cazuri de sinonimie: două (sau mai multe) atribute cu denumiri diferite, dar cu aceeași semnificație.
Soluție FN1: se păstrează doar un atribut, sinonimele sale se elimină din DD.

b. Atribut deductibil: valorile sale pot fi deduse din cele ale altor atribute, prezente în DD.
Soluție FN1: se elimină din DD atributul deductibil.

c. Caz de omonimie: două atribute cu aceeași denumire, dar cu semnificații diferite.

Soluție FN1: se redenumesc corespunzător și se păstrează în DD.
pg. 7 Baze de Date Liana ANICA-POPA
 d. Cazuri de atribute calculate: valorile acestora pot fi determinate cu ajutorul unor expresii de calcul, utilizând celelalte
atribute – operanzi primari - din DD.
Soluție FN1: se elimină aceste atribute calculate din DD.

e. Atribute repetitive: atribut ce a fost gândit pentru a colecta mai multe valori într-un singur șir, fiind astfel ne-atomic.
Soluție FN1: se regândesc structurile de date așa încât să nu mai existe niciun atribut repetitiv.

f. Atribute decompozabile: atribute devenite decompozabile în momentul în care devin necesare întocmirii de diverse rapoarte
pe baza unor criterii aflate în interiorul valorilor acestora.
Soluție FN1: criteriul se scoate în afară, definindu-se astfel încă un atribut distinct de cel care îl includea inițial.

2.2. Forma normală 2 (FN2)

Definiție FN2:
O tabelă (sau relație) verifică FN2 dacă și numai dacă:
a) ea se află în FN1
ȘI
b) toate atributele NON-CHEIE ale tabelei depind funcțional COMPLET de cheia sa primară.

Concret, în etapa de normalizare FN2, un economist implicat într-un proiect de normalizare a unei bazei de date parcurge
următoarele etape:
1) datele reținute în DDFN1 sunt repartizate în tabele distincte (de exemplu, Client, Factura, Parcela, Ferma etc.);
2) se identifică atributul sau atributele ce ar putea îndeplini rolul de cheie primară în fiecare tabelă;
3) valorificând informațiile oferite de regulile de gestiune elaborate, se analizează dacă toate dependențele funcționale (DF)
dintre atributele non-cheie și cheia primară a fiecărei tabele sunt complete;
4) se completează structurile tabelelor cu atributele rezultate din regulile de gestiune ca necesare pentru asigurarea coerenței
datelor și a legăturilor logice dintre tabele.

Remarcă: Rezolvarea situațiilor descrise de regulile de gestiune, RG, presupune

fie crearea de chei externe în tabelele existente,
fie crearea de tabele noi, cu chei primare compuse din mai multe chei externe (urmate, sau nu, de atribute dependente funcțional
complet de toate componentele cheilor primare astfel stabilite).
pg. 8 Baze de Date Liana ANICA-POPA
2.3. Forma normală 3 (FN3)
Definiție FN3:
O tabelă (sau relație) verifică FN3 dacă și numai dacă:
a) ea se află în FN2
ȘI
b) orice dependență funcțională TRANZITIVĂ dintre atributele sale a fost eliminată.

Dacă în tabela T (A, ..., B, ..., C, ...) există dependențele funcționale:

A  B
B  C, de unde rezultă:
-------------------
A  C ,
atunci relația A  C se numește dependență funcțională tranzitivă (DFT) între atributele A și C.
Conform definiției FN3, această DFT trebuie să fie eliminată din tabelă și, implicit, din baza de date.

Soluția de aducere a structurii tabelei T în FN3 – forma normală 3 – este următoarea:

a) se creează o tabelă nouă (numită aici Tnouă), cu B - cheie primară și C - atribut non-cheie;
Tnouă ( B, C)
b) în tabela T, A rămâne cheie primară; atributul C, în raport cu care s-a înregistrat dependența funcțională tranzitivă, se elimină
din tabela T; pe baza cheii primare B a tabelei notate Tnouă, se va crea, în tabela T, cheia externă #B (sau B ).
T ( A, …, #B,… )

- Exerciții -

Exn1) Determinarea, prin normalizare, a structurii unei BD pentru gestiunea reparațiilor utilajelor
agricole ale unui complex cerealier
O echipă mixtă, de economiști și specialiști IT, a elaborat următoarele:
pg. 9 Baze de Date Liana ANICA-POPA
 A. Dicționar de date (DD)

{ CodUtilajReparat, DenumireUtilajReparat, NumărBonReparație, DatăBonReparație, MarcăSalariat, NumeSalariat,

Adresă, Localitate, Județ, CodPostal, CodPiesă, DenumirePiesă, UnitateMăsură, Cantitate, CostUnitar, Valoare,
IdPiesă, CodCategoriePiesă, DenumireCategoriePiesă }

B. Reguli de gestiune (RG)

RG1. Un bon de reparații este întocmit de un salariat; un salariat poate întocmi mai multe bonuri de reparații.
RG2. Un bon de reparații este întocmit pentru un utilaj.
RG3. Pe un bon de reparație pot fi specificate mai multe piese, cu cantitatea consumată și costul său unitar; o piesă poate
figura, într-o cantitate și cu un cost unitar specificate, pe mai multe bonuri de reparație.
RG4. O piesă aparține unei singure categorii.

Cerință:
Să se proiecteze, prin metoda normalizării, structura unei baze de date dedicate.

Soluție:
Forma normală 1 (FN1)
Definiție FN1:
O tabelă (sau relație) verifică FN1 dacă și numai dacă
atributele sale au valori unice și nenule (sau atomice).

Atribute eliminate:
◘ IdPiesă, sinonim cu CodPiesă
◘ Valoare – atribut calculat Valoare = Sum ([Cantitate] * [CostUnitar])

Nu există în DD omonime, atribute deductibile, repetitive, decompozabile.

Prin urmare, obținem:

pg. 10 Baze de Date Liana ANICA-POPA

DD = {CodUtilajReparat, DenumireUtilajReparat, NumărBonReparație, DatăBonReparație, MarcăSalariat, NumeSalariat,
FN1
Adresă, Localitate, Județ, CodPostal, CodPiesă, DenumirePiesă, UnitateMăsură, Cantitate, CostUnitar,
CodCategoriePiesă, DenumireCategoriePiesă }

Forma normală 2 (FN2)

Definiție FN2:
O tabelă (sau relație) verifică FN2 dacă și numai dacă:
a) ea se află în FN1
ȘI
b) toate atributele NON-CHEIE ale tabelei depind funcțional COMPLET de cheia sa primară.

Aplicând forma normală 2, atributele din dicționarul de date adus în FN1 (DDFN1) se grupează, mai întâi, în structurile tabelelor
noii baze de date.
Se creează tabelele, se stabilesc, în fiecare tabelă, cheile primare și atributele non-cheie, sunt definite cheile externe, apărute
prin valorificarea RG1, RG2, RG4, precum și noua tabelă - creată pe baza RG3.
Astfel, structura bazei de date în forma normală 2 (FN2) pentru gestiunea reparațiilor utilajelor agricole ale unui complex
cerealier este următoarea:
BDFN2
Utilaj (CodUtilajReparat, DenumireUtilajReparat)

BonReparație (NumărBonReparație, DatăBonReparație, #MarcaSalariat, #CodUtilajReparat)

(Cheie externă, creată pe baza RG1) (Cheie externă, creată pe baza RG2)

Salariat (MarcaSalariat, NumeSalariat, Adresa, Localitate, Județ, CodPostal)

CategoriePiesă (CodCategoriePiesă, DenumireCategoriePiesă)

Piesă (CodPiesă, DenumirePiesă, UnitateMăsură, #CodCategoriePiesă)

(Cheie externă, creată pe baza RG4)
Bon_PieseConsumate (#NumărBonReparație, #CodPiesă, Cantitate, CostUnitar) (tabelă nouă, creată pe baza RG3)

pg. 11 Baze de Date Liana ANICA-POPA

Forma normală 3 (FN3)
Definiție FN3:
O tabelă (sau relație) verifică FN3 dacă și numai dacă:
a) ea se află în FN2
ȘI
b) orice dependență funcțională TRANZITIVĂ (DFT) dintre atributele sale a fost eliminată.

În tabela Salariat (MarcaSalariat, NumeSalariat, Adresa, Localitate, Județ, CodPostal) a fost identificată următoarea dependență
funcțională tranzitivă:
MarcaSalariat  CodPostal
CodPostal  Localitate, de unde rezultă:
------------------------------------
MarcaSalariat  Localitate

Relația MarcaSalariat  Localitate se numește dependență funcțională tranzitivă (DFT) între atributele MarcaSalariat și
Localitate.

Conform definiției FN3, această DFT trebuie să fie eliminată din tabela Salariat și, implicit, din baza de date.

Soluția de aducere a structurii tabelei Salariat în FN3 – forma normală 3 – este următoarea:
c) se creează o tabelă nouă, Domiciliu, cu CodPostal - cheie primară și Localitate - atribut non-cheie;
Domiciliu (CodPostal, Localitate)

d) în tabela Salariat, MarcaSalariat rămâne cheie primară; atributul Localitate, în raport cu care s-a înregistrat dependența
funcțională tranzitivă, se elimină din tabela Salariat; pe baza cheii primare CodPostal a tabelei notate Domiciliu, se va crea,
în tabela Salariat, cheia externă #CodPostal (sau CodPostal ).

Salariat (MarcaSalariat, NumeSalariat, Adresa, Localitate Județ, #CodPostal)

pg. 12 Baze de Date Liana ANICA-POPA

Celelalte tabele nu au dependențe funcționale tranzitive (DFT) între atribute; prin urmare, structurile acestora nu suferă
modificări în etapa FN3.

Așadar, structura bazei de date dedicate gestiunii reparațiilor utilajelor agricole ale unui complex cerealier, ce verifică
forma normală 3 (FN3), este:
BDFN3
Utilaj (CodUtilajReparat, DenumireUtilajReparat)

BonReparație (NumărBonReparație, DatăBonReparație, #MarcaSalariat, #CodUtilajReparat)

(Cheie externă, creată pe baza RG1) (Cheie externă, creată pe baza RG2)
Domiciliu (CodPostal, Localitate)
Salariat (MarcaSalariat, NumeSalariat, Adresa, Localitate Județ, #CodPostal)
CategoriePiesă (CodCategoriePiesă, DenumireCategoriePiesă)

Piesă (CodPiesă, DenumirePiesă, UnitateMăsură, #CodCategoriePiesă )

(Cheie externă, creată pe baza RG4)

Bon_PieseConsumate (#NumărBonReparație, #CodPiesă, Cantitate, CostUnitar) (tabelă nouă, creată pe baza RG3)

Exn2) Se dă tabela:
Varianta a : Varianta b :
FoaieMatricola FoaieMatricola

NrMatricol CodCurs DenCurs Nota #NrMatricol #CodCurs DenCurs Nota

12323445 Obli01 Baze de date 10 12323445 Obli01 Baze de date 10

23434567 Opt07 Actuariat 7 23434567 Opt07 Actuariat 7

77888990 Obli01 Baze de date 9 77888990 Obli01 Baze de date 9

23434567 Obli01 Baze de date 6 23434567 Obli01 Baze de date 6

In ce formă normală se află? Justificați răspunsul.

pg. 13 Baze de Date Liana ANICA-POPA
Exn3) Se dă tabela:

Cal (CodCal, Nume, DataNastere, CodRasa, CNPProprietar)

Formulați regula de gestiune care a condus la crearea cheii externe CNPProprietar.

Exn4) Se dă tabela:

InscrieriCurse (#CodCal, #CodCursa, DataInscriere, TaxaInscriere)

Formulați regula de gestiune care a condus la crearea tabelei InscrieriCurse.

Exn5) În care dintre formele normale de mai jos este soluționat cazul dependențelor funcționale tranzitive dintre atribute?
a) FN2
b) FN5
c) FN3
d) În niciuna.

SQL
- Sinteză teoretică -

SQL- Structured Query Language - înseamnă limbaj de interogare structurat.

SQL - Sintaxa generală a unei fraze de selecţie

SELECT [<domeniu:> ALL| DISTINCT | DISTINCT ROW | TOP <n>] <Lista

câmpuri / expresii>
FROM <surse de date>
[ WHERE <condiţii_filtrare_date> ]
[ GROUP BY <lista criterii de grupare> ]
[ HAVING <condiţii> ]
[ ORDER BY <câmp1> [ASC / DESC] [, <camp2>, ...] ]
pg. 14 Baze de Date Liana ANICA-POPA
SQL - Sintaxa generală a unei fraze de acțiune, pentru modificare / actualizare a unui set de înregistrări
dintr-o tabelă
UPDATE <nume_tabelă>
SET <câmp1> = <expresie> [, <câmp2>=<expresie>, …]
[ WHERE <condiţie1> AND/OR <condiţie2>…]

SQL - Sintaxa generală a unei fraze de acțiune, pentru ștergere a unui set de înregistrări dintr-o tabelă
DELETE <Lista câmpuri / expresii> / * / /
FROM <nume_tabelă>
[ WHERE <condiţie1> AND/OR <condiţie2>…]
SQL - Sintaxa generală a unei fraze de acțiune, pentru adăugare a unei înregistrări într-o tabelă
INSERT INTO <nume_tabelă> (<câmp1>, <câmp2> ...)
VALUES (<valoare1>, <valoare2>...)

SQL - Sintaxa generală a unei fraze de acțiune, pentru crearea unei tabele noi
SELECT listă_campuri INTO nume_tabela_noua
FROM sursa_date
[WHERE <condiţie_1> [AND/OR <conditie_2> …]

SQL - Sintaxa generală a unei fraze de acțiune, pentru transferul (adăugarea) de înregistrări (de tip
Append)
INSERT INTO <tabelă destinație> (<listă_câmpuri destinație>)
SELECT listă_câmpuri_surse
FROM sursa_date
pg. 15 Baze de Date Liana ANICA-POPA
[WHERE <condiţie_1> [AND/OR <conditie_2> …]

SQL - Sintaxa generală a unei fraze de interogare încrucișată (Crosstab)

TRANSFORM <valoare de calculate și afișat>
SELECT <criterii de grupare pe linie>
FROM <surse de date>
[WHERE <condiţie 1> AND/OR <condiţie 2>…]
GROUP BY <criterii grupare linii>
PIVOT <criteriu grupare pe coloană>;

SQL - Sintaxa generală a unei fraze de interogare UNION

<Interogare 1>
UNION [ALL]
<Interogare 2> …
[UNION [ALL]
<Interogare n> [ ... ]];

Câteva remarci:
UNION nu permite duplicate, pe când UNION ALL da.
Toate interogările dintr-o operație UNION trebuie să solicite același număr de câmpuri; cu toate acestea, câmpurile pot să nu aibă aceeași
dimensiune sau același tip de date.
Utilizați aliasuri numai în prima instrucțiune SELECT deoarece acestea sunt ignorate în oricare alta. În clauza ORDER BY, referiți câmpurile
așa cum au fost denumite în prima instrucțiune SELECT.
Puteți utiliza o clauză GROUP BY sau HAVING în fiecare instrucțiune de interogare pentru a grupa datele returnate.
Puteți utiliza DOAR o clauză ORDER BY la sfârșitul ultimei interogări pentru a afișa datele într-o ordine specificată.

pg. 16 Baze de Date Liana ANICA-POPA

 - Exerciții SQL -

BD Aprovizionări. Modelul logic al datelor

Fraze SQL

qEx1) Lista materialelor aprobate spre achiziție

SELECT * (Caracterul * înseamnă “toate câmpurile”.)
FROM Material

qEx2) Lista facturilor de aprovizionare (achiziție) emise acum 45 zile

SELECT *
FROM Factura
WHERE datafa = Date() - 45

qEx3) Lista denumirilor și caracteristicilor merceologice ale materialelor ale căror denumiri încep cu litera „u”
SELECT denm, carm
FROM Material
WHERE denm like "u*"

pg. 17 Baze de Date Liana ANICA-POPA

qEx4) Lista materialelor ale căror denumiri încep cu o literă specificată de utilizator:
SELECT *
FROM Material
WHERE denm LIKE [Litera specificata] & "*"

qEx5) Lista facturilor de achiziție emise de furnizorul „SC Mega SA“

SELECT Factura.*
FROM Factura INNER JOIN Furnizor ON Factura.codfz = Furnizor.codfz
WHERE Furnizor.denfz LIKE "SC Mega SA"

qEx6) Lista facturilor de achiziție plătite în ultimii N ani

 Cu subinterogare :
SELECT *
FROM Factura
WHERE nrfa IN (SELECT PlatiFacturi.nrfa
FROM PlatiFacturi INNER JOIN DocPlata ON PlatiFacturi.NrDP = DocPlata.NrDP
WHERE year(DocPlata.DataDP) > year(Date()) – [N] )

qEx7) Lista facturilor de achiziție, plătite sau neplătite:

SELECT *
FROM Factura LEFT JOIN PlatiFacturi ON Factura.nrfa = PlatiFacturi.nrfa;

qEx8) Lista materialelor de achiziționat, inclusiv a celor ce nu figurează pe facturi (neaprovizinate încă):
SELECT *
FROM Linie_fa RIGHT JOIN Material ON Linie_fa.codm=Material.codm;

qEx9) Afișarea facturilor neplătite:

 Cu subinterogare:
SELECT nrfa
FROM Factura
WHERE nrfa NOT IN (SELECT nrfa
FROM PlatiFacturi)
pg. 18 Baze de Date Liana ANICA-POPA
qEx10) Afișați numărul materialelor achiziționate pe fiecare factură din anul trecut
SELECT Linie_fa.nrfa, COUNT(Linie_fa.codm) AS NumarMateriale
FROM Factura INNER JOIN Linie_fa ON Factura.nrfa = Linie_fa.nrfa
WHERE YEAR(Factura.datafa) = YEAR(Date()) -1
GROUP BY Linie_fa.nrfa

qEx11) Afișați cantitatea totală din fiecare material facturat acum doi ani
SELECT Linie_fa.codm, SUM(Linie_fa.cantaa) AS CantitateTotala
FROM Factura INNER JOIN Linie_fa ON Factura.nrfa = Linie_fa.nrfa
WHERE YEAR(Factura.datafa) = YEAR(Date()) -2
GROUP BY Linie_fa.codm

qEx12) Afișați valoarea totală achitată din fiecare factură scadentă în ultimele 60 zile
SELECT Factura.nrfa, SUM(PlatiFacturi.SumaAchitFa) AS TotalAchitatFact
FROM Factura INNER JOIN PlatiFacturi ON Factura.nrfa = PlatiFacturi.nrfa
WHERE Factura.datascadfa > Date() - 60
GROUP BY Factura.nrfa

qEx13) Realizați un top 3 facturi cu cele mai mari valori, scadente în următoarele 45 zile
SELECT TOP 3 Factura.nrfa, ROUND(SUM(Linie_fa.cantaa*Linie_fa.pretua),2) AS ValoareTotala
FROM Factura INNER JOIN Linie_fa ON Factura.nrfa = Linie_fa.nrfa
WHERE Factura.datascadfa between Date() and Date() + 45
GROUP BY Factura.nrfa
ORDER BY SUM(Linie_fa.cantaa*Linie_fa.pretua) DESC

qEx14) Situația numărului de facturi pe furnizor și pe material - Interogare Crosstab (încrucișată)

TRANSFORM Count(Linie_fa.nrfa) AS NumărFacturi
SELECT Factura.codfz
FROM Factura INNER JOIN Linie_fa ON Factura.nrfa = Linie_fa.nrfa
GROUP BY Factura.codfz
PIVOT Linie_fa.codm
pg. 19 Baze de Date Liana ANICA-POPA
qEx15) Situația facturilor scadente și a documentelor de plată din anul acesta:
SELECT Factura.nrfa as A, Factura.datascadfa as B, Furnizor.denfz as C
FROM Factura INNER JOIN Furnizor ON Factura.codfz = Furnizor.codfz
WHERE YEAR(Factura.datafa) = YEAR(Date())
UNION ALL
SELECT DocPlata.NrDP, DocPlata.DataDP, PlatiFacturi.SumaAchitFa
FROM DocPlata INNER JOIN PlatiFacturi ON DocPlata.NrDP = PlatiFacturi.NrDP
WHERE YEAR(DocPlata.DataDP) = YEAR(Date())
ORDER BY B
Notă: UNION nu permite duplicate, pe când UNION ALL da.

qEx16) Creați o tabelă nouă, intitulată MaterialLichid, cu materialele lichide.

SELECT codm, denm, umm, carm, starem INTO MaterialLichid
FROM Material
WHERE starem LIKE “lichid“

qEx17) Creșterea cu 1.25% a prețului unitar pentru materialele aprovizionate în cantități mai mici de 5.
UPDATE Linie_fa
SET pretua = pretua*1.0125
WHERE cantaa<5

qEx18) Ștergerea furnizorilor cu sediul într-o localitate specificată de utilizator.

DELETE codfz, locfz, denfz, adrfz
FROM Furnizor
WHERE locfz Like [Localitate specificata]

pg. 20 Baze de Date Liana ANICA-POPA

 Operatorii algebrei relaţionale

Algebra relaţională – o colecţie de operatori care au, ca operanzi, relaţii (tabele), iar rezultatul returnat este tot o relaţie
(tabelă).

Operatorii primari ai algebrei relaţionale (Codd, 1972):

◘ operatori tradiţionali:
 reuniunea (union)
 intersecţia (intersect)
 diferenţa (difference)
 produsul cartezian (cartesian product);
◘ operatori speciali:
 selecţia (restrict sau select)
 proiecţia (project)
 compunerea (join)
 diviziunea (divide).

A se parcurge cursul aferent algebrei relaționale, aflat la dispoziția dumneavoastră pe online.ase.ro.

pg. 21 Baze de Date Liana ANICA-POPA